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?

Does this enable using modified scripts in-game? If so, then this is the holy grail. As far as I understand, there's yet no way to actually get a modified script back into a upk to result in a new upk.

For decompressing with that tool, what worked for me was decompress -export -all -lzo xcomgame.upk That's lzo with lowercase L. But I haven't been able to get UE Explorer to show me anything. I'm well familiar with programming, but also haven't touched the unreal engine before.

Access to scripts has been gained? Awesome! Is it possible with the same toolchain to also pack the modified scripts back and use them?

Interesting - I tried getting free aim through assigning the Explosive property to weapons (seeing how the free-aim capable weapons are rockets and grenades), but that resulted in no evident change. DestroyTerrain is presumably something different from just destroying environment, as regular weapons (especially lasers) destroy quite a bit of the environment when you miss.

I haven't seen any direct evidence of the AI being smarter on Classic. It seems to be following the same routines, except that they sometimes give different results due to other factors, like larger alien groups and firing accuracy, which emboldens them to take the shots. I have very good reason to believe that there are no additional behaviour algorithms per se that get enabled on Classic.

Really it seems that what is needed is a level between Normal and Classic. The difference between the two is huge. A non-exhaustive list of what Classic has over Normal: - Countries start with more panic, at least someone will likely reach level 5 in the first month. - Less funding in personnel and money from the Council - You do not have a Satellite on standby, must build one - Your base has less power, requiring a generator sooner - You do not start with the OTS, meaning extra time and money to be spent to get 5-man squads - Your soldiers start with 1 less HP, which is very important early on - Aliens get +10 aim and +10 critical chance, so they aim better and do more damage - Thin Men get 4 HP instead of 3. Important because it means they can not be killed outright by grenades. - Outsiders get 5 HP instead of 3, making them more difficult to capture - The first terror attack (hi Chryssalids!) happens at least a week earlier All of that together is a big leap. My first attempts on Classic, I was holding on for dear life after 2 months, first attempt on Normal I didn't lose a single soldier until the alien base, while having money to spare and happy countries. So it seems like it was a good idea to create an in-between level.

What I did in my first mini-mod was to create a new difficulty level, where everything is the same as on Classic, except that countries start at lower panic levels and decreasing panic is slightly easier. In my experience with Classic as it is in the game, the main difficulty arises from how quickly you lose nations. You have to launch a satellite in the first month usually to avoid losing a nation, and the money you spend on Satellites detracts from your ability to spend it on other improvements. So with that simple modification, it's a lot more manageable (though I am still playing unmodded classic). Your proposal is actually aimed at making the tactical part easier. I'd say that starting with 6 soldiers would make most early missions a cakewalk. But it depends on what you find harder and what you want to make easier. If it's the strategy layer, decrease panic. If it's the combat layer, start with 6 rooks.

It is the script part I am worried about - has anyone managed to get access to the scripts yet?

I've done some of that in a UFO Classic mini-mod I published last night, and I want to do more. I am extremely familiar with other Firaxis games, but not really with Unreal engine games. Sadly, it seems that we're getting access to a very limited set of modding tools, unless more gets released. One of the things I am trying to accomplish now is making all items require construction time, even if it's short, no more of this instant laser rifle production. I also want a partial equipment loss from dead soldiers. Not losing all equipment (feasible), but only losing armor worn by killed soldiers, not currently sure if that is possible. Unfortunately, some key elements of the original game, like free aim and base defense missions, are very unlikely to be possible.