Elodran

You you should really move up in difficulty levels. Normal is handicapped in many ways, including aliens having less hit point (it's not that classic/impossible have more), you can have small number of aliens attacking you at any giving time, the AI is much less limited and will use things like grenades very infrequently. Classic is the level you should really be baselining at.

You need to use a hex editor to modify the byte code within the UPK file itself.

Sure, in XComStrategyGame.XGStrategySoldier.LevelUp, you could modify the function to also call GivePerk on the m_kSoldier member for that perk. Say when they reached Squaddie and picked up their class, you could also give them suppression. Not sure about the second.

I've tried those... it looks like there are 8 compressed sections within the saved game file. However, they each have a different header structure than the compressed UPK files do. Example: C1 83 2A 9E 00 00 02 00 6A 54 00 00 00 00 02 00 6A 54 00 00 00 00 02 00 09 69 63 5F So instead of having the signature, 0x9E2A83C1 followed by the block-size, it has some of the information duplicated twice (00 00 02 00 6A 54 00 00). I haven't been able to manipulate any of them to get them to decompress successfully with decompress.exe. Edit: Also, the later your saves, the more of these sections you have. I have one near the end of the game that has 25 of these sections...

In the UE Explorer the actual code I see in the decompiled version is this: function bool CheckForEdison() { local int iTech; iTech = 0; J0x0B: // End:0xBC [Loop If] if(iTech < 61) { // End:0x3F if((iTech == 0) || iTech == 60) { } // End:0xAE else { // End:0x6F if(TECH(iTech).iTechReq == 60) { } // End:0xAE else { // End:0x94 if((iTech == 4) || iTech == 49) { } // End:0xAE else { // End:0xAE if(!IsResearched(iTech)) { return false; } } } } ++ iTech; // [Loop Continue] goto J0x0B; } return true; //return ReturnValue; } If there is a way to make it use the symbols instead of the numbers there, that would be fantastic to know!

So I think I've tracked down the issue with the Edison achievement. I'm still learning how to pack the UPKs to get things working properly for me, but here's the issue for those that might want to go ahead and create the mod for it. If you look in the XComStrategyGame.XGFacilityLabs.CheckForEdison function, you'll see what essentially boils down to this code: function bool CheckForEdison() { local int iTech; for (iTech = 0; iTech < eTech_MAX /* 61 */; iTech++) { if (iTech == XComeGame.XGGameData.ETechType.eTech_None /* 0 */ || iTech == XComeGame.XGGameData.ETechType.eTech_PsiLabs /* 4 */ || iTech == XComeGame.XGGameData.ETechType.eTech_AutopsyZombie /* 49 */ || iTech == XComeGame.XGGameData.ETechType.eTech_PlaceHolder /* 60 */ || TECH(iTech).iTechReq == 60) { continue; } else if (!IsResearched(iTech)) { return false; } } return true; } The problem is, if you look at the table of research items, there is also this one: XComeGame.XGGameData.ETechType.eTech_Autopsy_END (= 59). However, when a research is completed (as seen in OnResearchCompleted()) or when setting up the game (as seen in Init() and InitNewGame()), that m_arrResearched index is never set to 1, which means we need to skip this as well. So we can either update InitNewGame() or, and my preference, is to update CheckForEdison() to also add the check for XComeGame.XGGameData.ETechType.eTech_Autopsy_END in the list of ones to skip. The updated code would look like this: function bool CheckForEdison() { local int iTech; for (iTech = 0; iTech < eTech_MAX /* 61 */; iTech++) { if (iTech == XComeGame.XGGameData.ETechType.eTech_None /* 0 */ || iTech == XComeGame.XGGameData.ETechType.eTech_PsiLabs /* 4 */ || iTech == XComeGame.XGGameData.ETechType.eTech_AutopsyZombie /* 49 */ || iTech == XComeGame.XGGameData.ETechType.eTech_AutopsyEnd /* 59 */ || iTech == XComeGame.XGGameData.ETechType.eTech_PlaceHolder /* 60 */ || TECH(iTech).iTechReq == 60) { continue; } else if (!IsResearched(iTech)) { return false; } } return true; } Again, I'm still trying to figure out how to patch these things (especially since I play on the Mac), but if someone wants to do it, the source of the problem has been found! =)

Yeah, I tried decompress.exe on a Windows VM but it just complained about it not being valid. I even tried pulling out some of the parts that I thought might just be fluff. I'll keep poking about and report back if I find anything out.

Yeah, I've sent a PM yesterday. We'll see.

Yeah, thanks. The problem is that data is either being encrypted or compressed and I'm trying to figure out how that is happening. Even doing a simple edit like changing a soldier's name from "Jorgen" to "Jorjen" results in many, many changes throughout the file. The saved data is supposed to be in JSON format, but that's not the case... at least, not without being processed first.

Anyone figured this out yet? I'm working on trying to map it out... I know that the Toolboks app can do some of it, but I haven't found any information out there on it. I'm going to go through and create a bunch of baseline save game files and start finding the diffs. If anyone knows information on it, that would be great! Thanks!

Steam version here as well and also on 10.9. Still not sure what is causing the issue. I was going to try and see if I could extract the DGC.ini from the executable to compare, but I haven't have a chance to figure out how to do that on the Mac yet.

Any Mac users out there attempting to mod and running into some graphical glitches? If make the change to the Enemy Within executable to change the .ini file names to .inx so that they are not reloaded from the server and then modify the DefaultCoreGame.ini file, after a few minutes of combat play I get a ghosted green or blue rendering of the screen. I'm going to try if simply modifying the game executable itself will cause these issues next, but just wanted to know if others were seeing this too. -David

I'm just happy that there is SOME information about getting the Mac mods working; gives me some incentive to actually try and power through it. I'm an old-time XCOM fan and used to do this stuff to the original game. Time to dust-off those reverse engineering skills again! If I actually start making progress to getting things up and running, I'll put my project on github so it's easy to get to.

Ah... thanks for the pointer. I was wondering what all of these extra bits in the header were. They seem to correspond to the following structures: struct FCompressedChunkHeader { int Tag; // equals to PACKAGE_FILE_TAG (0x9E2A83C1) int BlockSize; // maximal size of uncompressed block, always the same int CompressedSize; int UncompressedSize; TArray<FCompressedChunkBlock> Blocks; };The package tag being the same is what really threw me in a loop. Now I have somewhere to start. Thanks for the help!

I've seen a thread from a while back about OS X tools, but it's kind of fizzled and I cannot find any information elsewhere about it, so I thought I'd ask about some of the details to get some of my own versions of them rolling. First question I have is about decompressing the UPK files. I've gather that they use LZO compression, but I'm not sure which portions of the file are compressed. Also, looking at part of the XComStrategyGame.upk, there are lots of strings that are clearly not compressed, but if I uncompress the UPK on Windows, I see that contents surely get uncompressed. Does anyone have any guidance on how the compression works for UPK files? Otherwise, I'll have to start poking around at the differences between the compressed and uncompressed files to see if I can reverse engineer enough information to make it work. Thanks!