How can I create new .u scripts for a UE2 Version 926 Game?

[KidBuu]

Hello, I've recently come into possession of a MMORPG server for a game whose client was built using UE2, with the UCC.exe version 926.

Sadly, the ucc.exe used to build the game was not included.

I have made GREAT progression in terms of server side development, but alas close to none on the clients side.


We were able to compile Models, Animations, and textures for the game using another games ucc.exe (A version of Postal2), but for some reason... This does not work with the scripts, nor the maps.


We really need to be able to add new maps, as well as scripts that can extend off of the original scripts...

Would anyone be willing to help accomplish this task...

Or at least explain why Models, Animations, and textures work using the Postal2 ucc.exe, but not maps and .u files.


I'm wondering, would it be possible to hook the games loading functions in order to also load another games .u file formats....

[[]KAOS[]Casey]

Turfbattles?

Unfortunately, all the class offsets are compiled in at runtime. It would be pretty difficult to achieve this.

The reason why animations and such work is likely because their classes are unchanged with no new variables, or alterations to sizes of variables, and they aren't based off of AActor. This is similar to how we can create native mods for Unreal Gold, but there are no headers for Unreal version 225f -- but if you create a class based on a simple class -- say, UAudioSubsystem, which has not changed, there's a good chance it works because the alignments are the same.

Without the headers (or at least the.uc to recreate some headers) this is very unlikely.

Let's see what Han says.. he's more knowledgeable about this kind of thing than I am.

[han]

Altered hardcodes names can crappity smack up things big time too. Noticed that behaviour in Disney's Brother Bear. So why don't you name the game your are talking about?

[KidBuu]

Hey Casey, are you the same Casey that was trying to help us a few months ago?


The game is called Turf Battles, like Casey mentioned...

Its original name is Sephiroth, it was probably the first 3D MMORPG to enter into the Korean market, although since then it's had a lot of visual upgrades done to it so you can't even tell it's the same game it was in its first release way back when...

Some side notes... The original client seems to have had an additional layer added onto to process of loading these packages.

The engine.dll has a function called LoadStaticObject, which I'm assuming is the Unreal standard function for loading files...

Then on top of that it has a function called SEP_LoadStaticObject, SEP is the derived name of the game used in many files (short for Sephiroth).


I do know that it's possible to get this done, as a private server of the game has managed to do this... They were even able to create an entirely new character class that uses stolen models, animations, textures, and effects from World of Warcraft...

[han]

KidBuu: Does the game contain an Editor.u/dll?

Unfortunately, all the class offsets are compiled in at runtime. It would be pretty difficult to achieve this.

Actually building header for an UE game is more like a lot of concentrated detail work then in particular hard. As all classes are usually declared as dllexport including it's vtable entry, you get the virtual functions interface basically for free (which is important). The non virtual functions are even less of an issue. What ends up in beeing a lot of work is to get the binary layout of the classes right. However, you get at least the class binary size usually for free (as it's can be derived out of the (copy) constructors of the given object fairly easy. Also the static constructors which add certain properties to at least some of the classes are helpful. Also there are a lot of check() macros thrown in, which result in plain text and are always useful to figure out variable names (and types). Then there are a lot of accessor methods and last but not least there is plenty of code in the headers of ue1 game for small methods, these are usally pretty much helpful. However getting UCC to work is basically not much effort. And the next thing one should do ist do to dump the hardcodes names, declared in Core\Inc\UnNames.h. You can basically just iterate other them and dump them -- and as mentioned above, proven to be very important to get right. However, they are for free! Also if you have UCC working, you can throw code in which iterates other the properties of native unrealscript classes. So you would get a lot info about it, even if source was stripped. UCC is just getting Core right, which mostly doesn't change that much, but the UProperties and subclasses can give you a pretty hard time. The next step I usually do is to try to get and a render device build for the game. For that Player/Viewport/Actor/Pawn/PlayerPawn and FSceneNodes are important. In case of KHG the UTexture/FTextureInfo classes were a bit problematic, but KHG to 224 was a huge step, at least for Core package the diffences between ut432 and early UE2/WarfareBuild games is likely smaller.

[KidBuu]

KidBuu: Does the game contain an Editor.u/dll?

Unfortunately, all the class offsets are compiled in at runtime. It would be pretty difficult to achieve this.

Actually building header for an UE game is more like a lot of concentrated detail work then in particular hard. As all classes are usually declared as dllexport including it's vtable entry, you get the virtual functions interface basically for free (which is important). The non virtual functions are even less of an issue. What ends up in beeing a lot of work is to get the binary layout of the classes right. However, you get at least the class binary size usually for free (as it's can be derived out of the (copy) constructors of the given object fairly easy. Also the static constructors which add certain properties to at least some of the classes are helpful. Also there are a lot of check() macros thrown in, which result in plain text and are always useful to figure out variable names (and types). Then there are a lot of accessor methods and last but not least there is plenty of code in the headers of ue1 game for small methods, these are usally pretty much helpful. However getting UCC to work is basically not much effort. And the next thing one should do ist do to dump the hardcodes names, declared in Core\Inc\UnNames.h. You can basically just iterate other them and dump them -- and as mentioned above, proven to be very important to get right. However, they are for free! Also if you have UCC working, you can throw code in which iterates other the properties of native unrealscript classes. So you would get a lot info about it, even if source was stripped. UCC is just getting Core right, which mostly doesn't change that much, but the UProperties and subclasses can give you a pretty hard time. The next step I usually do is to try to get and a render device build for the game. For that Player/Viewport/Actor/Pawn/PlayerPawn and FSceneNodes are important. In case of KHG the UTexture/FTextureInfo classes were a bit problematic, but KHG to 224 was a huge step, at least for Core package the diffences between ut432 and early UE2/WarfareBuild games is likely smaller.

Not much of what you just said made sense to me, but that's because you know what you're talking about and I'm new to Unreal....


Yes it has both a Editor.dll and a Editor.u.

[han]

Yes it has both a Editor.dll and a Editor.u.

Ah nice. One can actually add wrapper for the UExporter around the one for class exporting which does not crash on the first native only class inside the file when using batchexport. So if the source was not stripped you, you are done afterwards when you just aim at doing UnrealScript.

[[]KAOS[]Casey]

Hey Casey, are you the same Casey that was trying to help us a few months ago?

Yup. same guy.

I knew Han would be able to pull some useful info out of his hat there.

When I examined the turfbattles engine/binaries it looked as if they had just written a new executable or to for startup but mostly left the original contents alone, and the engine might've been edited like lineage II's for the multi-map loading/unloading for large worlds

Edit:

Found the binaries they'd send me, here's a snip of the log build date and such.

Code: Select all

Log: Log file open, 07/11/12 11:24:03
Init: Name subsystem initialized
Init: Detected: Microsoft Windows NT 6.1 (Build: 7601)
Init: Version: 926
Init: Compiled: Jun  5 2006 15:52:33