Long War for Mac OS/X - pointers / advice?

[wghost81]

thither, Linux version keeps "hardcoded" copies of default game core and default loadouts ini files too. I haven't even figured out where, as it turned out to be unimportant: after disabling phone home via hosts file and manually copying defaultgamecore.ini and defaultloadouts.ini to corresponding XComGameCore.ini and XComLoadouts.ini game stopped any attempts to overwrite those files. May be you should try the same for Mac.

 

Anderkent, for LW "sources" (and current bugfixes) access you'll have to ask jonnylump.

[Amineri]

 

Has anyone tried just unlocking the config files (assuming it's necessary for the Mac version) but not installing any Long War package/config/localization files?

 

I seem to recall someone a while back reporting graphical glitches from just the executable edit.

 

Good instincts! I just tried only patching the executable in my vanilla install. A short way through the first combat mission I got the glitch. So it doesn't seem to be directly related to the Long War changes.

 

Is it possible that the files which are embedded in the executable are more recent than the ones on disk? Is there a good way of seeing what's in them, short of learning all kinds of stuff I don't want to know about OS/X ABIs and file formats?

 

 

There's a variety of stuff that goes into the XComEW executable under windows. The core Unreal Engine (the part that has to be compiled separately for each platform) is in there, as well as any native code that was compiled in by Firaxis (native code is accessed from the unreal script via a "native" keyword before the function/variable).

 

In windows, pretty much the only changes made to the executable were :

 

1) Updating the hashcode checks that are made for some of the package files. This only had to be done for EU, as it seems to have been removed for EW.

2) Three config files (DefaultGameCore.ini, DefaultLoadouts.ini, and DefaultMPGame.ini) are stored within the executable's Resource Cache and are read from there instead of from the loose file in the Config folder. To mod these we used to use ResourceHacker to edit the data within the executable, but now we simple disable the internal lookup. The mechanism of how this works (if it's necessary at all) may be different for the Mac in order to avoid the graphical glitches.

[Anderkent]

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/

Edited August 6, 2014 by Anderkent

[thither]

I've messed around with this for a while and my eyes are starting to glaze over, and I've got the game back to the point where it crashes on launch with the patched executable. The logs just stop dead halfway through the GPU info, right before it gets to the driver version.

 

I did take the time to grab an open-file log with opensnoop, though, maybe some of you guys can glean some useful information from it. This is from my currently-crashing version, with Long War applied (possibly incorrectly). In broad strokes, the game is reading from all three directories, "XCOM Enemy Unknown.app/Contents/Resources/MacOverrides/XEW", "Application Support/Feral Interactive/XCOM Enemy Unknown/XEW/MacInit", and "SteamApps/common/XCom-Enemy-Unknown/XCOMData/XEW/XComGame". Hopefully someone with more knowledge of how the game works can determine what it all means.

 

https://gist.github.com/timgilbert/7c1f42ee00b1d5495d4d

Edited August 7, 2014 by thither

[thither]

Aha! Right after I posted that I had a minor breakthrough. The crashes were because I had forgotten to remove the .uncompressed_size files again.

 

I was also able to launch the game with Long War without the patched executable and at least get to the main screen with the "long war" button, but it's not perfectly installed (second wave options again). I don't have more time to mess with it now but will try again tomorrow.

 

In the meantime this seems to confirm that patching the executable is not necessary on OS/X.

[Anderkent]

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.

[wghost81]

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.

b13 crashes on startup on linux due to memory management problems. I do have the necessary modfiles to resolve this (and I already did it on Linux), but I don't have permission to re-distribute those. I suggest you PM jonnylump about this.

[Anderkent]

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.

[thither]

Ok, yes, following Anderkent's advice and not patching the executable I was able to get the mod installed and working without the patched executable. I ran through the first mission and didn't experience any graphical glitches, and I had the expected complement of six operatives in red, and had all the right difficulty and second wave options in the beginning.

 

Copying the localization files from the mod directory to the "Feral Interactive/XEW" folder didn't seem to work, but copying them into MacOverrides did get them working (I'm assuming they get overwritten on every launch and copied from MacOverrides, though I haven't verified that).

 

I put my Feral Interactive directory under git control as well, and tonight I'll try messing around with it until I find the right combination. My install script will probably need some revisions, but it's actually getting fairly close.

[Anderkent]

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.