OldUnreal (Engine)

I'd like to see this topic continue on. It was very interesting. Let's start it off with a previous post by Pcube:

In my eyes 227 is more official than the darned 226b patch. Unreal Gold caused way more inconsistencies than 227 has (or can) mend, so whatever.

And no, there is no advantage to running 226f other than perhaps being able to say "I'm running the last official unreal 1 (non gold) patch." 226b, the gold patch, does support RTNP, but 226f does little more than provide the worst networking possible. Oh well.

this is going by memory, some may be wrong or off

224:
worst net code, missing NetUpdateFrequency/Priority etc etc
inconsistent Mesh vs LODMesh on certain meshes {ie moon1m} that cause mismatches on future versions
broken Case: Switch implementation{just crashes?}
working doppler like 225f? {don't know}
(I don't know any others because I havent used 224 much}
enhanced renderers via OMP

225f
Galaxy has working doppler
Most compatible non-227 server next to {probably} 224 for official
brokenish 3d sound {personally with stereo I can hear what direction things are coming from, probably from use of 225f for millennia}
Worst renderer support, only works with glide wrapper/software reliably on newer hardware
generally seen as most stable for server use

226f
broken join with password support, must join with open ip?password= unlike 225f/224
broken doppler in galaxy
broken replication on some effects {ie ringexplosion}
can't connect to 226b, see 226b section
enhanced renderers via OMP
maps built with inherent incompatibility with 225f and below

226b
net incompatibility due to 226b conformed to 225f instead of 226f, or 226f wasnt conformed to 226b, I don't know the exact timeline for which came first but the general idea is that legend messed up
enhanced renderers via OMP
broken doppler in galaxy
maps built with inherent incompatibility with 225f and below


all non-227 versions:
susceptible to "replication blackouts" where replication stops working for no apparent reason
no dynamic array support, although it does compile unlike TMAP which immediately throws a compiler error
no "perfect" 5.1 surround support, though it claims to have "3d sound" which I assume is supposed to be spatial separation via stereo
numerous script errors that I could never name in this post alone
numerous crashes from script/native/c++ that I can't name in this post alone
no skeletal mesh support
old 3d implementations without OMP


227 fixes all of these, except the doppler problem in galaxy, only because we quite literally can't. galaxy is partially closed source and is outdated, so we added fmod/alaudio instead, and nothing we can do about the meshes since it's already FUBAR'd like 226f incompatibility. we chose the more popular versions to be compatible with. we also upgraded OGL and added d3d8/9. the default direct3d implementation is now D3D7 instead of 6 I believe.

Can't forget all the new natives we added, but thats what changelogs are for. I'm sure theres lots of things i've forgotten.

All I can say about the above is ...

It's plain retarded not to upgrade imo. Or you have a REALLY good reason, like, "lol internet exploded".

I also forgot to mention, but I can't give details.. for fear of others exploiting.

227f {and above} protect against an extremely serious bug that can potentially cause you to be at risk to remote file execution, your files are also at risk.

as far as I know, this was only fixed in UT3 and above. I don't have 2k4 installed right now to test.

edit: aaaaaaaaaaaaaaand I cant even find the cds, but the case for it. Hurray legal torrenting.

But I guess it's time to install it since my CD drive works.

Well, actually, there's one minor detail as to why 225f might be preferable to 227... 225f is compatible with 226f clients, whereas 227 (and gold of course) are not. Yes, I know that it was impossible to ensure this compatibility since 227 was built for gold compatibility, but 225f somehow achieves true universal compatibility.

Of course, only a Jackson would use 226f... so who cares.

To be honest, everyone should either have 227 or 225.

227 fixes a lot of very well-known problems as well as provide extra stuff. You should have 225 for its compatibility but in the end 227 is turning out to be the best patch, aside from 226b for gold which isnt very compatible from what I understand but is quite stable.

I dunno honestly, i find 227 a lot better due to the fact i don't seem to crash as much with it compared to the others. In my book that's a good thing.

Also.

Casey.

agreed wit spike.

a few crashes due to some freakshow errors, but thats usually just my UMSN code.. still workin on it =]

Official vs Unofficial? Well it's this simple. If Epic makes a patch, it's official. If a community makes a patch, it's unofficial. That surely doesn't matter though, does it? Yeah there is always gonna be people who will be (for obvious reasons) weary of an "unofficial patch", until at least you have a final version out there. But seeing how the Unreal community is adopting 227 anyway the matter of Official or Unofficial becomes fairly pointless. If you make something that's technically better, then it's technically better. No matter if you made it in an office or your mother's basement.  :D

Offically we are assigned to create this patch as code maintenance, but we aren't epic games employees, and they like our work, that's as official as it gets.. it's some hybrid semi-official fan-made patch, some weird category.

A true "fan made" patch for this game would not use the src at all : specifically.. deus ex's infamous "Shifter" mod

the original unreal team was comprised of people like us, anyway. random people assembled on the internet to create a code base for a game. So I read, anyway.

imma show this to some friends who deny patching. tnx!

225f PerObjectConfig; is broken and it has some other bugs.
227f is far better.

226b
net incompatibility due to 226b conformed to 225f instead of 226f, or 226f wasnt conformed to 226b, I don't know the exact timeline for which came first but the general idea is that legend messed up

It should be a bug in 226f, because who would release a b version before f? And the file upload dates on BU also say that it's true.

226b
net incompatibility due to 226b conformed to 225f instead of 226f, or 226f wasn't conformed to 226b, I don't know the exact timeline for which came first but the general idea is that legend messed up

It should be a bug in 226f, because who would release a b version before f? And the file upload dates on BU also say that it's true.

I can only repeat the general problem with these "release numbers" - in this case I assume its 226b because it was developed in another company with a different approach: to release a gold version with upak extension.
As a complete package, pretty similar to anthology nowadays. I'm not even 100% sure if Legend ever used the "b" themselves in any announcements.

Also the "f" was never designated to mean "final", it's just a release number, a good example for this is 224v.
Oh and don't forget 226f was never planned, it was only made because of a big petition at this time. The result we all know was a lousy "rip out of UT" which had major net problems, because they never wanted to make it, they were only forced to and they did it to satisfy the community and that's indeed the biggest difference between 226 and 227- they maybe have the better coders, but we have the love to make it right.

Aside this I have to admit that I always had the impression that 224 was the best client before 227. In 226 the gameplay always felt a lil bit..."rubber-like", like chewing gum maybe. At least that was my impression so I played myself mainly with 224 until 227's release.

Oops, I meant "who would release an f version before b", dam typos

so far as I know, there's 2 different 226b's.. one for Unreal which WAS released before 226f, and then the 226b for UnrealGold. It was probably only called "b" to signify that it was like a secondary 226 version since it was for Gold, quite possibly. I could be wrong.

No, that was 226a and indeed gold came before 226f, so 226f is the wrong one, I dunno the official explanation, but I think Smirftsch can confirm it, there was something about handling of something, which was broken, I think something in Unrealshare was missing even, hence why you get that load error and why gold crashes on 226f.
I think 226f was the deviation as Epic didn't care for compatibility with the gold version.

it's actually a simple mistake and a simple fix for that

when building in ucc you can conform to the previous build of unreal, and they conformed to 225f instead of 226b, simple as that

the original unreal team was comprised of people like us, anyway. random people assembled on the internet to create a code base for a game. So I read, anyway.

ZOMG THEY HAD A CASEY?! NUH UH. LIAR.

Hmm. If 226f came after 226b, doesn't that mean it would be impossible to conform 226f to 226b? Wouldn't that require 226f, which does not contain RTNP, to have the entire nametable and whatever else of 226b, including all of the RTNP stuff?

The nametable was broken in 226f as far as I know.

conforming seems to align the nametables of known variables/classes/etc, if ones don't exist in the previous version it adds them to the end I assume, UPak is seperate so its a non issue.

If you use ucc conform to conform 226f to 226b, the compatiblity issue is gone. but then 227 would need to be conformed to the conformed version ot 226f > 226b

then you achieve true compatibility.

though, I believe there might be another way to make it work without using conform at all.. but a new/modified net driver

Hmm. If 226f came after 226b, doesn't that mean it would be impossible to conform 226f to 226b? Wouldn't that require 226f, which does not contain RTNP, to have the entire nametable and whatever else of 226b, including all of the RTNP stuff?

As casey already said, if it would have been conformed in the correct order, one version after another there would be no compatibility issue.
But both 226f and 226b were conformed against 225 and not against the previous 226 version (and I honestly don't care which version came first).

Of course updating one of the 226 versions and then conforming 227 against that would fix all compatibility issues, but then again, why would people update 226 and not if they are already updating anyway, to 227?

If the reason not to use is they don't trust Oldunreal, they wouldn't trust such an update too. If the reason is they don't like the 227 features, they don't need to use them. If the reason is the gameplay- the gameplay wasn't changed.

Even if it is possible, it's not worth the work because the true problem is, that a 226f and 226b client can't be distinguished before real login and the login won't happen because it's crashed before. To catch that is maybe even completely impossible without changing at least one of the 226 versions.

Hmm. If 226f came after 226b, doesn't that mean it would be impossible to conform 226f to 226b? Wouldn't that require 226f, which does not contain RTNP, to have the entire nametable and whatever else of 226b, including all of the RTNP stuff?

As casey already said, if it would have been conformed in the correct order, one version after another there would be no compatibility issue.
But both 226f and 226b were conformed against 225 and not against the previous 226 version (and I honestly don't care which version came first).

Of course updating one of the 226 versions and then conforming 227 against that would fix all compatibility issues, but then again, why would people update 226 and not if they are already updating anyway, to 227?

If the reason not to use is they don't trust Oldunreal, they wouldn't trust such an update too. If the reason is they don't like the 227 features, they don't need to use them. If the reason is the gameplay- the gameplay wasn't changed.

Even if it is possible, it's not worth the work because the true problem is, that a 226f and 226b client can't be distinguished before real login and the login won't happen because it's crashed before. To catch that is maybe even completely impossible without changing at least one of the 226 versions.

Maybe following your logic, but it is not true....
I know many people who use your OMP patches, but not 227 (refusing to use it also for other reasons). A simple 226 fix might work really.