Solver

Crashes I've had so far are that the game crashes on startup if the functions are not at the expected offsets within a class, or if the name of the function does not match the name which is referred to near the end of the function bytecode - byte number 0x45 in the two functions I posted.

Aren't upk files used in all Unreal engine games? If so, I'd expect the format to be well known - the engine itself has been used in an absolute truckload of games.

Hex editor only. I assume if UPKs just used a simple LZO compression, a repackaging tool would have been available by now. Besides, it doesn't seem all that important to compress them per se, the important part seems to be to have a compiler for the scripts.

Aha, yes, the object lengths are the problem, the offsets are being stored somewhere within the class, even though it's not immediately obvious. Duh, an idiot, should have realized that at once. EDIT: Okay, definite conclusion - changing functions in a way that also modifies their length is a pain. You have to pad them, and that still messes up some names somehow. An actual compiler would be better :D

Those are names, not indices. UE Explorer shows those function indices under "index". And these still wouldn't make sense.

Hmm, do you know if the class itself stores its length somewhere? I observe that changing a function's length messes up what UE Explorer sees, though the functions themselves do not store their length. Perhaps there is some padding required or something to make functions align correctly. That is a possibility. I didn't of course think these would be large changes - just the most primitive stuff by making some functions return true, but that's also non-trivial. If scripts can be recompiled into the UPK files properly through someone's knowledge or a Firaxis tool, great! Definitely looking forward to that.

Both functions in my screenshot are existing unmodified functions of the same form, to make conclusions about how the simplest function works. I've seen that they can correspond to indexes also, 1214 or 1219. Doesn't make sense. This is XComGame.upk, and neither of the functions at those indices makes sense. The two functions I looked at there relate to weapon properties. What does PostBeginPlay (an initialization function) or a map rotation function have to do with it? Nothing probably. UE Explorer shows various interpretations, as references to objects/names/etc., but nothing really seems to make sense. Also, these are both super-simple functions. They should not call anything. EndFunctionParams is there, I assume, for this function's own parameter list, not for a function that it calls. Calling another function seems to require a 0x1B (VirtualFunction) opcode, or a FirstNative opcode, or somesuch. These are mostly guesses, this is after all the first time I am looking at UE code. EDIT: And no, doesn't look like C# properties. Accessing an instance variable is pretty straightforward. Sequence 0x2D, 0x01 and a third byte does in these two cases. 0x2D means a boolean type, 0x01 means an instance variable in this class, the third byte is the index of said variable. Definitely C++ style more than C# property style.

Backups are a must. Also, the program should handle UPKs *and* the modified ini, as modpatcher does. The program should have an "install mod" or whatever option that lets the user select upk and/or ini files, and then handles everything automatically. Makes a backup, does hashes, patches resources, etc. The user shouldn't have to use the command line or make backups manually or do anything else.

I'm pretty hardcore but I am using UE Explorer :D And it chokes on that bytecode I write from scratch to replace that certain function. I know I got the function ID and its return address right, from the existing code, so there's only a couple of places I might have gotten wrong. Will see...

Wrote the bytecode from scratch :D Doesn't correspond to proper UE code, there's something about it that I do not understand. A certain byte, I think. Here's code for two almost identical functions, both of which are bool functions returning a single variable, as in bool () { return m_someVar; } - these are some of the simplest functions possible. Image First 16 bytes are the same except for what appears to be the function ID. Second 16 bytes are equal except the byte 0x18, which points to the object where the function's return value will be stored. It is the byte 0x20 that I do not understand, interpreting it either as a pointer to an object or a name makes no sense, it's not really related to what the function does. Bytes 0x24 and 0x25 may be storage space for the parameters, as byte 0x28 (value 0x16) is an opcode indicating that the parameter list is over. Byte 0x30 (value 0x04) indicates that a return value follows. Byte sequence 0x2D 0x01 says that it's a boolean instance variable, and next the byte 0x33 is a pointer to the m_someVar variable. Sequence 0x04 0x3A indicates that it should be returned as an int type, followed by the location for the return value in byte 0x39. Byte 0x3D says the script is over, then there's a reference again to a variable (not really sure why), and the bytes 0x45 and 0x46 respectively refer to the name of the function, and a comparison operator (probably the operator to use to compare this function's return value). Mind you, if the bytes 0x30 and 0x31 get just changed to 0x04 0x27, that returns true, and the subsequent reference to a variable remains there without disturbing anything. I tried using a code built like this for a function that calls another function, but it doesn't work at all. My problem is likely the byte 0x20, I have no idea what goes there.

Well, I never knew how the engine works - it might have been programmed to check unreachable code as well for all I knew. But yes, what I'm getting at it what kanet is saying, or at least so it seems so far. Leaving a function call with invalid parameters, or leaving code that prepares parameters while the function call itself is removed, makes the game crash - even if the code appears to be correct upon inspection in UE Explorer. It's actually difficult for me right now, I easily changed two functions to return true, but can't for the life of me make a third function return true.

Note: if modifying a function that does not call any other function, invalid code is okay. That is, if you have a function like bool somefunc() { statement; anotherStatement; } and change it to bool somefunc() { return true; nowInvalidStatement; } it works. But, if you have a function that calls another function, you have to take care to remove the extra parameters, space for return values, etc., or the game crashes.

OK, with the tips here, I succeeded in modifying the scripts so that any weapon is considered to be free-fireable. It shows that very dirty modifications of scripts work, and invalid code is ignored if the function terminates earlier with valid code. On the downside, while it says "free aim" in the game, that modification alone doesn't help the UI - it still highlights the aliens and won't let you choose an arbitrary spot to fire at. Let's see if I can get around that.

Interesting that the bytecode is extremely verbose. I want a function just returning a constant value, and that's about 70 bytes of bytecode. Well, experimentation is warranted.

I could use a bit of workflow help here due to my unfamiliarity with Unreal. I'm trying to modify a script to get it loaded through XSHAPE. Assuming I can get the bytecode right, what is it exactly that I should modify? Bytecode in the decompressed UPK file itself, or the .*property files after extracting the UPK? If the latter, how do I get them back into the UPK?