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.

Cool, the files seem to fix the crashes as far as I can see. There are minor visual annoyances (fatigued being dead) that wghost already sent me workarounds for, but other than that there's nothing clearly wrong! thither, since you seem to actually be playing the campaign on a mac (as opposed to me just playing around with the mod :P), I'd recommend you reach out to her as well. Your testing will probably have fuller coverage. To reiterate the install process (for your script): 0. Ensure the game was started at least once without the mod (fails to load menu if it never phoned home) 1. Unpack the file 2. Replace .upk files, remove corresponding .upk.uncompressed_size 3. Replace Localization files in two directories (under XComGame, and in MacOverrides near the binary) 4. Replace Config files under XComGame 5. Delete files under MacInit in ~/Library/Application Support/Feral Interactive/blahblah 6. Move DefaultGameCore.ini to MacInit/XComGameCore.ini and DefaultLoadouts.ini to MacInit/XComLoadouts.ini (all the other files will be generated from XComGame/Config) 7. Block phoning home in /etc/hosts 8. While on b13, replace the .upk files with ones from wghost - i assume the script won't have to do that I believe following these will give you a fully functional game. I've noticed some lags (for example when buying items), I'm curious if that also happens to you; I'm doing lots of things at the same time so the machine might just be kinda busy).

You should copy the localization files to `Library/Application Support/Steam/SteamApps/common/XCom-Enemy-Unknown/XCOMData/XEW/XComGame/Localization` and `Library/Application Support/Steam/SteamApps/common/XCom-Enemy-Unknown/XCOM Enemy Unknown.app/Contents/Resources/MacOverrides`, not the Feral Interactive/XEW folder. I believe when I only dropped them in MacOverrides my home screen still said 'Single Player' rather than Long War, though everything else worked.

Aha! Yeah, that's it. I remembered I saw it before, you just have to run the executable directly instead of using the wrapper so that you get console output in addition to the logs: ⚙ ⮀ 12:47:34 ⮀tumbstone ⮀ ...m-Enemy-Unknown ⮀ XCOM\ Enemy\ Unknown.app/Contents/MacOS/XCOM\ Enemy\ Within Setting breakpad minidump AppID = <censor> Steam_SetMinidumpSteamID: Caching Steam ID: <censor> [API loaded no] XCOM Enemy Within(24323,0xb0925000) malloc: *** error for object 0x410030: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug [2] 24323 abort XCOM\ Enemy\ Unknown.app/Contents/MacOS/XCOM\ Enemy\ Within I'll PM jl for the files.

We discussed this a bit on the linux thread (http://forums.nexusmods.com/index.php?/topic/1847250-linux-version-of-long-war-zip-install/page-9&do=findComment&comment=17244684). My current idea for the best approach is to: 1. Do the usual install first: Copy over .apks, remove .upk.uncompressed_size, copy over config and localization (put localization files both in the game folders and macoverrides) 2. Remove all files in `~/Library/Application Support/Feral Interactive/XCOM Enemy Unknown/XEW/MacInit` 2. Move DefaultGameCore.ini from the mod to `~/Library/Application Support/Feral Interactive/XCOM Enemy Unknown/XEW/MacInit/XComGameCore.ini`, and same for DefaultLoadouts.ini -> XComLoadouts.ini When I did a quick test of this, the mod seems to work fine if the game starts. However I got crashes on startup ~50% of the time. Not sure what could cause that, the logs are not helpful. Perhaps I did some change that I forgot about, I'll try to do this from a clean install someday.

The only change to the osx executable is a modification of the filenames, that causes them to read the files from disk. Things to try next: - Do not modify the executable, see if just overwriting the ini files is sufficient - Extract resources from the executable, compare embedded .ini files with the ones on disk - Do only half the executable mod (either for game core or loadouts .ini), see if the glitch still triggers on one/both. One - probably changed ini file, both - probably something wrong with the modification itself rather than the config Previous thread about this issue (not much there): http://forums.nexusmods.com/index.php?/topic/1285621-os-x-issues/

All very good points! Alas, I'm too busy today to look into it. We found an overrides directory, it's in ./XCOM Enemy Unknown.app/Contents/Resources/MacOverrides but only contains localisation files (XComGame.*, XComUIShell.*) The configs seem mostly in line; I don't have a windows config set on hand to compare, but diffing with my backup files there are only a couple suspicious changes: diff Config/DefaultEngine.ini Config.backup/DefaultEngine.ini [I] diff --git 1/Config/DefaultEngine.ini 2/Config.backup/DefaultEngine.ini index 8bd4836..8b022ed 100755 --- 1/Config/DefaultEngine.ini +++ 2/Config.backup/DefaultEngine.ini @@ -1404,7 +1404,8 @@ TEXTUREGROUP_WorldSpecular=(MinLODSize=256,MaxLODSize=1024,LODBias=0,MinMagFilte [Windows.StandardUser] MyDocumentsSubDirName=XCOM - Enemy Within -+DirsToCreateAtStartup=Saves +;FERAL OLL 02-Apr-2014 don't create this unused Saves folder fbug://11850 +;do not add the creates dirs on startup key commented out (it will still get read). [FullScreenMovie] +SkippableMovies=XEW_Logo_2KFiraxis @@ -1566,10 +1567,15 @@ MyDocumentsSubDirName=XCOM - Enemy Within +SkippableMovies=XEW_TP_BaseAssault-Lose ; PC Startup movies -;+StartupMovies=XEW_Logo_2KFiraxis -;+StartupMovies=XEW_UE3TechLogo -;+StartupMovies=XEW_Legal_PCConsole +;#if FERAL_PORT // OLL 26-Sept-2013 - Play Feral movie. ++StartupMovies=feral +;#endif FERAL_PORT ++StartupMovies=XEW_Logo_2KFiraxis ++StartupMovies=XEW_UE3TechLogo ++StartupMovies=XEW_Legal_PCConsole +;#if FERAL_PORT // OLL 26-Sept-2013 - This movie is missing from our data. ;+StartupMovies=Black +;#endif ; Loading screen configuration !LoadMapMovies=ClearArray (this seems like a really minor change of not creating an unused directory though :tongue:) I believe the merged ini files show up in: ~/Library/Application Support/Feral Interactive/XCOM Enemy Unknown/MacInit/ I guess if someone's really bored they can remove all `Suppress=` lines from XComEngine.ini and read through logs to try and find something... Good luck :tongue:

Plausible for the crashes (the game sometimes crashes with a double free). Not sure about the weird graphical glitch, though i suppose if one of these 'borrowed' variables is ui-related and keeps some ui object alive longer than it should it could manifest in this way? How did you figure that one out, wghost? I might be able to try a similar process on a mac.

I'll try playing a bit on the mac today, will report whether I get the issue as well.

FYI: some people are also reporting the graphics issue on reddit: http://www.reddit.com/r/Xcom/comments/2c603p/getting_long_war_to_work_on_osxsteam I still didn't have the time to run the missions for a prolonged time, so I don't know if it doesn't happen on my machine, or I just didn't get there yet. (I usually only work on my macbook, game on a pc). I think maybe reporting what machine / os version you're running on would be useful? FWIW, 2013 macbook pro on osx 10.9.2 here.

The logs will be in something like ~/Library/Application Support/Feral Interactive/XCOM/XEW/Logs. Can't remember the exact path right now.