kanet32

Ahh, I see; sorry, I misinterpreted you there.

Uhh, I don't know if you missed what I said, but, for this, modding tools aren't required. I already did it and posted the modded files earlier in the thread. (The links are around the middle of the post.) Or, did you see that and it didn't work for you?

If it helps, I figured out why my altered executable wasn't working for some people. Turns out, the pre-order version of the game has a different executable than the post-order version. Something to do with the pre-order bonuses, presumably. So, unfortunately, if you didn't have a pre-order version of the game, the executable I uploaded wouldn't've worked for you anyway. XSHAPE really should still work for everyone, though, so as long as you're willing to trust XSHAPE (which is open-source) you should be safe to use my XComGame.upk. Just in case people are actually using my modded files, I'll post updated ones when the next patch comes. I have a friend who has a non-pre-order version of the game, so I can probably get both versions of the executable so it'll work for (hopefully) everyone. Everyone playing it on Steam, anyway.

Ahh, yeah, the fact that there was a 1 in the ASCII was a coincidence. Any constant values would be stored as integer values (as in, two's complement binary-encoded integer values) or, in the case of 0s and 1s, as the special 0 and 1 bytecode. In your case, you'd be looking for a 26 in the hex somewhere. Like I said, though, changing a 0 or 1 to any other value is currently impossible, because it requires expanding the size of the file by one extra byte (the "IntConst" byte). We need to figure out how to update the file lengths in the UPK before we can do anything like that.

The reason I ask is because I think now that the UPKs aren't simple file archives. They must include metadata about the functions and classes stored in them. Hence why I'm assuming figuring out the UPK format will help us figure out how to change the stored object lengths. (Although, honestly, even if all they DID store were files, I would assume changing the lengths of those files would affect how the archive was parsed. I'm assuming the lengths of files in most archive formats isn't implicit.)

Good info... When you change the length of a function, when does it fail? When the game launches? Is it a catastrophic failure, or is it something more subtle? That information comes from Solver, in the last page of the analysing the game scripts thread. I think it was a crash when the game launched, but Solver didn't say exactly.

Ahh, yeah, definitely the float thing. Just double-checked. Yeah, for converting integer values to hex, use Google. A constant will only be stored as a float value if it's got a fractional component to it, otherwise it'll be stored as an integer. And, what do you mean, changing it from 1 to 4? You mean, in the decompiled source that UE Explorer shows?

Well, first of all, I'm not sure how you got 1 = 0x3f800000... 1 is 0x1. I'm honestly a bit bewildered about this. Second, unfortunately, there's special bytecodes for constant 0 and 1 in UnrealScript. You're looking for 0x25 for 0, 0x26 for 1. So you'd need to search for 0x26. The reason this is a problem is because if you want to change it to 2, you're going to need to change it from 26 to 2C 02, because any constant other than 0 or 1 has to be preceeded by 2C (or a different code, for different types). And as we just learned a few minutes ago, you can't change the lengths of functions. Changing 26 to 2C 02 would add one byte to the function's length, causing the altered script to be rejected. This specific change is going to have to wait until we know how to alter the object lengths in the UPK files.

So, have you just been editing the UPKs in a hex editor, or using a repacking tool? I guess we need (in the short term) to figure out what the UPK format is, so we can change the function sizes. Maybe Gildor's tools are open source, or the format is documented somewhere.

Yeah, I missed the bit where you said they were just accessor methods. (And even still, it was just a wild guess on my part.) Sorry, I've no idea here. If I had some time, I'd try reading through them following the logic from that UnrealScript decompiler I posted a while back (BytecodeReader.cs, which I assume is what you're looking at to find the instruction codes) and see if I could figure out what was happening there. To be honest, at this point I'd probably recommend not trying to make such large changes to the compiled scripts. My guess is pretty soon someone with knowledge of the UDK will come in and give us instructions on how to set it up to decompile and recompile UnrealScript. There's a lot of room to manoeuvre just in changing constants or operators around for the time being. (Though, if you do continue forging ahead learning the bytecode, by all means continue letting us know what you find.)

Well, I can tell you that most of the times I've seen any bytes over 0x60 that weren't constants, they were function calls. The fact that a few bytes later you have 0x16 (EndFunctionParams) seems to support that. So, I'd wager that the C3 04 and BE 04 are both function calls. Since they're little-endian, it's actually 0x04C3 and 0x04BE, which would be 1219 and 1214, respectively. Depending on which UPK you're looking at, those could be different functions. In XComGame.upk, they're... From ImportTable.txt: 1219 = Function'Engine.ResetDesiredRotation' 1214 = Function'Engine.PostBeginPlay' Or possibly, from ExportTable.txt: 1214 = ObjectProperty'UIScreen.m_kTacMgr' 1219 = IntProperty'UIScreen.GetCurrentView.ReturnValue' But those are both properties, not function calls, and the 0x16 really seems to imply function calls. Alternatively, if you're looking in XComStrategyGame.upk... From ExportTable.txt: 1214 = Function'UIBriefing.SetupIntroBink' 1219 = ObjectProperty'UIBriefing.OnMovieLoaded.LoadedArchetype' The first one is a function; if the second block of code in your screenshot is your modified code, maybe the problem is that your changed code is calling an ObjectProperty as though it were a function? Maybe? I haven't really dug that deep into the bytecode, so this is all guesswork. EDIT: Just re-read what you wrote, and you said both functions are from the game and just return a value, so now I have no idea why there'd be a function call in there. Maybe it's something like C# properties, where accessing a property actually calls a function? I'm used to C++, myself, where everything is much more ordered and reliable. Variables are variables and functions are functions.

This may be a silly question, but have you tried seeing what UE Explorer decompiles it to? Or does UE Explorer choke on it as well? I'm assuming you've already tried this, but since you haven't mentioned it, I figure it's possible you didn't even know about UE Explorer and have been reading through all the scripts in bytecode all this time. (If so, respect. That's some Story of Mel s*** there.)

Yeah, that's the expected result, but I believe Solver is saying that it actually DOESN'T work like that when you're calling a function. Even if execution will never reach a function call, the interpreter will check that call in advance to make sure its parameters are correct. So while execution never reaches that line, it will still cause a crash because it's being checked for correctness before execution even begins.

In this post, DaemonJax basically goes over the whole process in broad strokes. If you missed it, it might help. And yeah, UnrealScripts don't seem to be compiled so much as they're compressed. The "compiler" just seems to tokenise everything and replace the tokens with indices into various tables. There's one for native operators and library functions, one for variable and class names, one for exported functions, and one for imported functions. The most complex thing it seems to do is generate jumps for conditionals (but not for the ternary operator :?, which is actually a single three-"operand" instruction)

Actually, I don't have the job; Dreadylein's already taken care of it! Dreadylein's also worked out some more detail on the NTL format, so you might want to wait a bit before trying to write that parser.