wghost81

Does this mean that all the existing map patches don't actually work in game? I'm asking because I'm working on LW b14b update for Linux/Mac right now, which includes all those patches.

Kaldreth88, suppose you have a function call you need to get rid of which looks like this: //SomeValue=SomeFunction(SomeParameter); 0F 00 <.SomeValue> 1B <SomeFunction> 00 <.SomeParameter> 16 You need to turn it into this: //SomeValue=5; 0F 00 <.SomeValue> 2C 05 A usual filler code to keep script file size looks like: 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B But it won't keep script memory size, which will result in jump offsets being shifted. Each variable reference has 4 bytes of file size (the reference itself) and 8 bytes of memory size (probably some additional internal object data). This means that for your filler code to have the same memory size as the original one, you have to replace some of the 0B's with filler variable(s). Like this: //SomeValue=5; 0F 00 <.SomeValue> 2C 05 //SomeParameter; filler code, this does nothing 00 <.SomeParameter> 0B 0B 0B 0B 0B 0B 0B 0B

tracktwo, he'll also need the return value. But the bad news is that I tested new import table entries and they do not work. :sad: Name entries work both under Windows and Linux, new export variables work in some cases under Windows (it is how Mutators are enabled, for example), but I wasn't able to make import table entries work. They get parsed by XCOM engine, but when I try to actually use them the game CTDs. :sad: Also the problem with new entries is that such mod creates a tons of compatibility issues. So generally I don't recommend using even new name table entries unless you absolutely can't do without them.

LeMagos, OK, I understood. Since iCapacity += value takes more space than ++iCapacity, you'll need to rewrite the function. Either in hex code or in pseudo-code. Because there are tons of if-else statements and those have jump offsets attached to them. And jump offsets will inevitably change as you're inserting the code inside. For starters try to just reconstruct the whole function as mod script with no changes at all. And then we can mod those changes in.

Yes, it is used for bomb missions to trigger "found the bomb" event.

Kaldreth88, so you're trying to mod one of the easter egg characters to be a female. There is indeed no GetNextFemaleVoice defined inside XComStrategyGame, so you'll have to do without it. I suggest generating a soldier with m_kSoldier = BARRACKS().CreateSoldier(...) and then changing all the values to whatever you want. LeMagos, @NULL tokens in your first decompiled code indicate that there is some error in the script. Both vanilla and LW versions have HasOTSUpgrade(2) calls: vanilla: LW Anyway, if you're trying to add some new code inside a function, you need to rewrite it partially or completely. In this case you need a complete rewrite, because of all the jump offsets. You need to code all the lines either in hex code or in pseudo-code (I suggest using pseudo-code with Patcher) and use AUTO modifier with object key: OBJECT=Object.Name:AUTO [REPLACEMENT_CODE] //the whole script in pseudo-code Here is an exampe of pseudo-code: // iCapacity = m_iCapacity; 0F 00 <.iCapacity> 01 <@m_iCapacity> But I still can't understand what exactly are you trying to do. Can you explain the main idea?

Kaldreth88, UPK Utils are Windows (Linux/Mac) command line tools. You can use PowerShell or cmd under Windows to work with these. Please, consult your Windows manual on how to work with command line tools. PatchUPK is the main tool to patch upk files. It accepts txt files, parses them and performs necessary modifications. You can use it directly via command line or you can use PatcherGUI which basically is a GUI wrapper around PatchUPK. PatchUPK has it's own readme which explains how keys and sections work. Also, there is a main UPKUtils readme which explains how to use different utilities. If you explain what exactly you are trying to do, I can guide you through it. LeMagos, I can't understand the question. What seems to be the problem here?

Krazyguy75, it shouldn't, as Z level is restricted to ground level only for these spawns. But with how things work in XCOM it can potentially happen. :smile:

I use the same randomization algorithm as for pod placement (in fact, all the placement mutators extend the same base class). I coded it so it generates an array of vectors which are randomly scattered inside LevelVolume. I then use farthest location to place the bomb and all the others to place nodes.

Standard bomb missions randomized: And some fun new maps to consider :smile:

wilsonkok, I'd rather get rid of this tutorial altogether as there are to many associated kismet-controlled objects I will need to move around. Or I can try to disable arrows only and tie Shen's explanations of how nodes work to "Reduce Beginner VO".

Be prepared... :smile: http://i.imgur.com/sHVBsdf.jpg

There are tons of such warnings as XCOM scripts aren't very accurate. Most of the time they won't lead to anything bad, as UE is quite flexible in handling bad code (unfortunately, because it kinda encourages lazy programming). If it is indeed a script problem, you will see Error, not Warning message in the log. You can use pastebin.com for pasting the text and then just link it in your post. Disable hash check without installing any mods and see if it leads to freezes. If not, then it's a particular mod that causes the problem. Again, I'm not sure the one you're using is EU compatible, so it's definitely worth checking.

So, I was able to procedurally locate all the nodes and bomb on the map and move them around. It seems that I have more-or-less generic script for randomizing nodes/bomb placement (early alpha). Next thing I intend to do is enabling random LZ for bomb missions and randomizing bomb/nodes around new LZ location. If it works, we can move onto streaming bomb assets into different maps and adding a little more variety to the most hated missions of all time. :)

xextremex, try playing in offline mode.

The Bomb moved: http://i.imgur.com/Fb9IiyO.jpg I don't see any cover or visibility problems here, but I haven't tested it extensively. All the tutorials (with arrows and markers) are disabled and all the other kismet scripts appear to be working fine.

Turns out this was the easy part. :smile: Bomb tutorial sequence is conveniently named ... BombTutorial. :smile: So I just disabled it by calling SetEnabled(false) inside the mutator. Finally, I can shut Shen up! :smile: I think I need to release a separate mod called "Special mission tutorials disabled!" :smile:

Yes, I'm working on it. :smile:

Some more news from the scripting side of the things. :smile: I've tried to move power node around with mutator: http://steamcommunity.com/sharedfiles/filedetails/?id=400999709 XComRebuildWorldDataVolume works after moving (after re-spawning, to be precise). Power node provides cover, is clickable and increases countdown timer properly. Emitters also work as intended. Power node consists of several objects: 1. XComLevelActor - static actor, the node itself. 2. XComInteractiveLevelActor - invisible interactive actor, clickable. 3. Two Emitters - active and inactive node animations. 4. XComRebuildWorldDataVolume - a volume to rebuild local world data (like cover data). Bomb has even more objects: 1. Two XComLevelActors - the bomb and the floor objects. 2. XComInteractiveLevelActor - invisible clickable interactive actor. 3. Five different Emitters for different bomb states. 4. XComRebuildWorldDataVolume. BTW, XGBattle class periodically rebuilds the world data by calling DoWorldDataRebuild method. So, I guess, we can spawn XComRebuildWorldDataVolume at any time. Next thing to do is to move the Bomb itself. :smile:

Small font of the message makes my eyes hurt. So at first I couldn't read it properly. As far as I can see, you still have your game inside 'Program Files' folder. Despite that readme strongly recommends to move it some place else. As far as I remember, armor tint patches are for EW, not EU, so I won't be surprised if they won't work on EU. Those are actually two different games, so don't try to apply EW mod on EU unless mod readme specifically states it is compatible. (I don't really remember the whole story behind this as it was a long time ago, so I can't say for sure whether it'll work or not). Another thing regarding armor tints. As readme says, "Disable hash check" option removes hash check for the three commonly used packages only. You need to use "Advanced -> Disable hash..." option to disable has check for startup.upk. There are lot of simple mods, like "No Disappearing Corpses", for example. They are simple and confirmed to work by thousands of players. I suggest you start with this one. Move XCOM out of system protected folders, run PatcherGUI, disable hash check and phoning home and install just this one simple mod.

Congrats to you and respect to Feral!

EW initial release is buggy and practically unplayable anyway. Do they have some sort of money-back?

Seems, we have found the problem: EW patch3 XComGame.upk.uncompressed_size holds 12436252. So your game version is not EW patch3. Fortunately, I keep all the versions on my hard drive :smile: so I was able to identify yours: it is Changelist 394142 also known as patch0 or the initial release! Since most of my mods are version independent, they work correctly. But LW distro contains version dependent packages, that's why it's not working for you. So, you need to find a way to patch your game.

Good. It means that your version doesn't have the hash check. Now download Linux/Mac zip LW distro and manually copy XComGame.upk while still having XComGame.upk.uncompressed_size removed. If the game loads fine, continue copying all the other files one by one. Do not forget to remove corresponding uncompressed_size files.

Exit the game before you start to install any mods. And also close TexMod window if you have it installed. Please, read PatcherGUI readme on reporting bugs and asking questions. I need more information, right now I can only guess.