Anderkent

You're probably playing with trailing roulette on. That option is broken on a mac right now.

habadabeer, you should drag the *directory* containing the script, not the script itself into the `cd` command.

Okay, so there are two parts to it. First, the 'simple' part is finding the hex code for the block that you want to modify, and figuring out how you need to change it so that the code does what you want instead. I don't have UE Explorer on this machine, but if you decompile that block and open the buffer for this function, you can mouseover different blocks to find the hex for the 'if(BARRACKS().HasOTSUpgrade(1)); ++iCapacity;' block. To replace it with a `iCapacity = iCapacity + n` statement you'll have to figure out how to encode that statement in hex (it'll be a combination of let (0x0F <lhs> <rhs> IIRC), a reference to iCapacity for the lhs (local variable : 0x00 <.iCapacity> in pseudocode), and a plus operation for the right hand side (I don't remember the bytecode for +, but you should be able to find the bytecode for one of the `iCapacity += 2` blocks, and reuse that). Once you have found both what you're replacing and know what you want to replace it with, use PatcherGUI to apply your changes to the file (see https://github.com/wghost/UPKUtils/blob/master/doc/PatchUPK_Readme.txt). If that succeeds, decompiling the file with UE Explorer should produce the code that you wanted to see. However, you'll notice that all the if statements are shifted around and generally messed up. That's because an if statement in bytecode is really something like this: 0x07 (jump-if-false) <to-offset> <condition> where to-offset is a reference to the memory offset in the function, as shown in the 'token view' in ue explorer. These locations have shifted, because your code has different size than previous ones, but all the jumps still point to the old offsets. To fix that, you'll have to correct all the to-offset so that they point to the right offsets; use UE token view to find the offset for the 'first instruction *after* the if' (so for example for the ' if(m_bExtendSquadForHQAssault) { iCapacity = 6; }' block, the 'next instruction' is the start of the next block: if(m_bReinforcementsForHQAssault) { iCapacity += 8; }). I hope that helps. I don't think I can make this more explicit without basically writing this for you, so just try it and report back if you hit a block somewhere.

Is `n` a constant there? Or some variable that I don't recognize? Basically I believe you'll have to do the following: 1. Define the logic change using mod script pseudocode (i.e. find the hex for the previous / next bits of code, replace any struct/type/var references with pseudocode references) 2. Correct all jump offsets in if statements in those functions to account for the shifted token positions. You can use the token view in ue explorer to find those - do the first step first, decompile the modified file (which will shift all your if statements in a weird way, but hold on), then take note of the token offsets of every 1. start of if 2. the first instruction *after* the if is closed, and correct the 'jump if not' at the beginning of the if statement to jump to the right token.

Ugh. OK, finder is creating some files in those directories that the install script doesn't know how to handle. To fix this, remove the .lw_install file from your game installation directory (probably '~Library/Application\ Support/Steam/SteamApps/common/XCom-Enemy-Unknown/')

Hi Alex, are you playing with trailing roulette? We've seen reports of it causing crashes. Unfortunately I don't know how to debug that, and AFAIK core LW devs do not have macs. Generally, turning on autosave is a good idea :P If the uninstaller isnt working, you can 'verify local files' in steam and wipe the config cache (in `~/Library/Application Support/Feral Interactive/XCOM Enemy Unknown/XEW/MacInit`) which should restore the game to its original unmodded state. The installer script is supposed to pick up whether it's called as ./uninstall or not, but possibly the name change wasn't picked up properly.

Haha thank you. Everything works now :)

Thanks! I know the mods do similar things, the point is more to learn how this works than to achieve the steam changes. Also I don't think those work with LW :P With the help of the docs, I got it to set the right virtual size. The game now crashes at mission start, not at launch :D That's progress! (i think my jump offsets are wrong, so the 'loop continue' jump is always hit, instead of conditionally) One issue I had with pseudocode is that I can't seem to get struct type references to work. From the docs it seems like 35 // struct 19 05 00 00 // field: iType 1C 05 00 00 // struct: XGBase.TTerainTile 00 01 // [end of struct ?] should be replaceable with 35 // struct <XGBase.TTerainTile.iType> // field: iType <XGBase.TTerainTile> // struct: XGBase.TTerainTile 00 01 // [end of struct ?] but doing so causes the mod to fail to apply.

I don't remember the exact path, but it'll be under `~/Library/Application Support/Feral Interactive/`, something like `XCOM/XEW/MacInit`.

Hi all, Is there a summary of all patchergui syntax somewhere? I've been scanning the thread backwards, trying to find out how the pseudocode works, but it's quite an effort :tongue: The first posts only talk about direct hex manipulations. For context, I'm trying to do a toy mod - set steam locations to be constant, rather than randomized. I found the function in upkviewer, managed to decode the hex by referencing the unhood byte reader (https://code.google.com/p/unhood/source/browse/trunk/UnHood.Engine/BytecodeReader.cs), but not sure what the proper way to specify the transformations in the mod file are. (also, since I totally ignored the memory size thing so far, I expect it really won't work :tongue:) The annotated bytecode can be seen in this gist: https://gist.github.com/JacekLach/604f370127fe6232f887. As expected, it applies but the game crashes :tongue: ETA: ugh, found out why it crashes. Didn't notice that native calls have to be ended with 0x16. That means I'm over-budget on the function length though, so I guess I'll have to edit the wrapping if to fix jump offsets. Ugh. ETA2: So with the current code: MOD_NAME=Static Steam Vents - LW AUTHOR=Jacek `Anderkent` Lach DESCRIPTION=All your steam vents will spawn in the 6th column. Yay! UPK_FILE=XComStrategyGame.upk OBJECT=XGBase.GenerateTiles:AUTO [BEFORE_CODE] 07 // jump unless E0 03 // jump offset 96 00 F4 28 00 00 00 F6 28 00 00 16 // I < numSteamVents 0F 00 F5 28 00 00 A7 36 00 F7 28 00 00 16 // iTile = Rand(arrDeepRockTiles.Length) 0F // let 35 // struct 19 05 00 00 // field: iType 1C 05 00 00 // struct: XGBase.TTerainTile 00 01 // [end of struct ?] // struct object: 10 // dynamic array access // array index: [ 10 // dynamic array access // index [ 00 // local variable F5 28 00 00 // GenerateTiles.iTile // end of index ] // array: 00 // local variable F7 28 00 00 // arrDeepRockTiles // end of array // end of index // array: 01 // instance var C9 28 00 00 // m_arrTiles 26 // = 1 55 // Array.add( 01 C8 28 00 00 14 00 // m.arrSteamTiles 10 // arrIndex 00 F5 28 00 00 // iTile 00 F7 28 00 00 // arrDeepRockTiles 16 // Array.add) [AFTER_CODE] 07 // jump unless D9 03 // jump offset 96 00 F4 28 00 00 00 F6 28 00 00 16 // I < numSteamVents 0F 00 F5 28 00 00 A7 36 00 F7 28 00 00 16 // iTile = Rand(arrDeepRockTiles.Length) 0F // let 35 // struct 19 05 00 00 // field: iType 1C 05 00 00 // struct: XGBase.TTerainTile 00 01 // [end of struct ?] // struct object: 10 // dynamic array access // index: 92 // + 90 // * 2C 07 // 7 00 F4 28 00 00 // local: I 16 // end * 2C 0C // 12 = 5 + 7 16 // end + // array: 01 // instance var C9 28 00 00 // m_arrTiles 26 55 // Array.add( 01 C8 28 00 00 14 00 // m.arrSteamTiles 92 // + 90 // * 2C 07 // 7 00 F4 28 00 00 // local: I 16 // end * 2C 0C // 12 = 5 + 7 16 // end + 16 // Array.add) the patch applies and seems to decompile fine in UE, but game still crashes. Inspecting function bytecode, I think the virtual/file sizes are off? Isn't 'AUTO' supposed to handle that for me? (the values at offsets 0x28 and 0x2c are 'CD 04 00 00' = 205, and '7D 03 00 00' = 125 respectively; the buffer view seems to be 0x3BB long, and the token view ends with 0x4C4. am I doing something wrong?)

Are you running the steam version of xcom standardprice? I'm afraid the mod only works with steam. If so, three posts above yours is a fairly step-by-step instruction: http://forums.nexusmods.com/index.php?/topic/1918524-long-war-for-mac-osx-pointers-advice/page-14&do=findComment&comment=19586614

Happy to hear that Telmo!

Same issue, different place(s) :sad: LW_FILES=`find ${MOD_DATA_DIR}/ -type f | sed s,${MOD_DATA_DIR}/,,g` has to be LW_FILES=`find "${MOD_DATA_DIR}/" -type f | sed "s,${MOD_DATA_DIR}/,,g"` and SELFNAME=`basename $0` should be SELFNAME=`basename "$0"` Spaces truly are the doom of computers.

Hey Benn, It's probably yosemite related. Can you verify that the base game (without long war) works properly? Are you using any second wave options? I've heard before of training roulette not working on osx sometimes.

Can you post the entire contents of the terminal window? It seems there's something going wrong with the script picking up where it's being ran. Looking through the script, I think it might happen if you have spaces in the path; that's a stupid mistake and I'll get someone to fix it eventually, but for now can you try unpacking the script to /tmp, or some other directory path where names would not have spaces around? If that's difficult, you can try modifying the script instead: The line MOD_DATA_DIR="`dirname $0`/install-files" should instead say MOD_DATA_DIR="`dirname "$0"`/install-files" (note the extra quotes around $0). LMK if either of these helps.