XCOM Modding: Need of a centralized source of information?

[anUser]

Hi everyone,

 

I've been learning how to mod my XCOM for the last 2-3 weeks using this forum as the main, if not only, source of information. On one hand I feel enormously thankful to all the people here, staff and comunity, for all their unvaluable work, but on the other hand I feel the need of a centralized source of information where those willing to spend some time teaching themselves could find all what's been researched so far. Oh, and it's not that I haven't googled for info, just couldn't find much else.

 

I know it's some sort of prsonal preference, the way I see it there's who learns by tutorials (for whom the forum soution may be ok) and those who learn by manuals, like myself, who need to understand things before making any sense of it, but in any case it ssems to me it wouldn't hurt to have such centralized source of info.

 

But in the end I'm a nooby here so I ask you people that have been modding for longer and with greater succes, what are your thoughts about it? I personally would love a wiki with every function and class known, it' package and it's header in hex, return values and local variables, some sort of map for function calls and such, etc. On the forum I've found very useful those R&D threads on specific topics, but there's not even a sticky with the table of hex values. But again, I'm the last to join this party so you'll know better.

[Amineri]

It would be nice if some of the info was organized, and didn't get buried 10 pages back :)

 

There is the Nexus wiki, but the only xcom related thing there is:

http://wiki.tesnexus.com/index.php/XCOM:EU_DefaultGameCore.ini_settings

 

There's no link on the main wiki page to anything xcom -- the whole structure would have to be created. Though looking at the other games, there's not a lot of structure there either.

[dubiousintent]

For what it is worth, I have found that there are tutorials and documentation on the Unreal game engines (v2 & 3) on the 'Unreal Developer Network' site. This information pertains to the general engine itself and 'unreal scripting' as generic background tools for developing games, not specific implementations such as the XCOM game itself or mods for it. I believe that at the moment that is the closest you are going to find anything in the way of 'manuals'.

 

The Unreal Engine Explorer evolved from such a background. Given 'XCOM: EU 2012' is a complete rewrite, the information from the previous iterations of the game should not be expected to still be valid. However, I have seen 'trainers' and 'save game editors' based upon earlier games released within days of the latest formal game release that could make 'in memory' changes to soldier stats during a mission. So obviously there is some overlap. But to date no one has appeared to make an effort to collect the lessons learned into an organized structure.

 

The lack of organization on the Nexus Wiki is more due to a lack of persevering oversight than capability. Someone has to mobilize their desire to see such a structure from concept to implementation. That takes dedication of time to a less attractive objective than merely 'having fun'. So far, such dedication has not emerged from the community.

 

-Dubious-

Edited March 10, 2013 by dubiousintent

[SeraphicLaw]

I haven't spent very much time here, but from the perspective of a new modder, this is the only resource for information on modding XCOM there is and the community here isn't very active - it seems like there are a lot of people who want to mod for personal use, find what they want to tweak and tinker, and then there are a handful of people with the capability to create installers and wrap up entire mod packages - neither one of these groups seems terribly interested in making a roadmap to 'how we got here', I think mainly because from what I can tell they either lack the ability/interest to show others what they did or they're still struggling to try and mod significant portions of the game to no avail.

 

Either way, I do agree - there are several changes that I've seen some mods are capable of that aren't documented or shared anywhere, so no one can learn to either do this manually or make similar changes for their own mods. or at the very least get everyone up to where they are so we can stop relearning the same things people have already worked out and get down to the big issues that are stumping some people.

[anUser]

Actually my post was meant to be more of an offering than a complaint, I obviously didn't put it out well. My apologies.

 

The lack of organization on the Nexus Wiki is more due to a lack of persevering oversight than capability. Someone has to mobilize their desire to see such a structure from concept to implementation. That takes dedication of time to a less attractive objective than merely 'having fun'. So far, such dedication has not emerged from the community.

 

I totally agree, but that's why I like wikis, because everyone can contribute with small bits of knowledge, so the only real work is setting up the structure. I'd even say that once it's done it would be easier for modders to post their discoveries in a prefixed template rather than posting it on the forum with all their due explanation. So what I'm proposing here is to open a debate about wheter it's worth of doing or not, and if considered so, what form should it take.

 

Anyway I was assuming there was a section on the site's wiki dedicated to xcom but I've just realized the ini settings page is under tesnexus, that would require collaboration from the staff.

 

Meanwhile, and just for starting, this is what I think could be useful in a wiki

- an entry per function and class, with it's discussion page to comment as it's being researched.

- function header in hex for easy location in the upk

- links to other functions called within (for functions) and methods (for classes)

- links to classes whose properties are read

- maybe a list with known values inside the function or class and their effects

- some sort of category system to group those elements related to a same game aspect or mechanic.

[johnnylump]

neither one of these groups seems terribly interested in making a roadmap to 'how we got here', I think mainly because from what I can tell they either lack the ability/interest to show others what they did or they're still struggling to try and mod significant portions of the game to no avail.

 

On the contrary, I have found this board to be very much operating in a collaborative spirit, and I would caution against any kind of sense of entitlement about what modders haven't done for you. It is a very, very small community, and I think modders like Bokuak, BlackAlpha, Drakous79, and lately Yzaxtol and Amineri have either 1) made available much or all of their work and/or 2) answered questions from newer posters as best they can. I know I've tried to do both.

 

As you've probably figured out, modding things beyond changes to DefaultGameCore.ini is very complex and time-consuming -- one missed byte and the game doesn't load, and it may take a long time to figure out where your mistake was. In other games, I have seen a lot of modders reject suggestions because a particular feature is "hard-coded." With X-Com, we're in fact taking on the "hard codes" and changing them. And every game patch overwrites our work, and we have to start over changing all the files. Most prior research still applies, but not all of it.

 

It's still very much a new frontier -- we're in experimenting and discovery stage; we've only been able to rescript functions for a very short time now, ever since twinj cracked function headers and the latest iteration of UExplorer made a lot of things more clear. I also think it takes some pre-existing programming knowledge to be able to re-script, as well, which may deter a lot of people from trying.

 

All that said, I certainly think a formal, organized archive of what has been discovered would be useful, particularly if more people are on here expressing interest in editing the upk files. It's simply not something I personally have time to take on and continuing working on my own mod. If contributing was made easy, I would do my best to include my work on it.

[Amineri]

<snip>

Anyway I was assuming there was a section on the site's wiki dedicated to xcom but I've just realized the ini settings page is under tesnexus, that would require collaboration from the staff.

 

Meanwhile, and just for starting, this is what I think could be useful in a wiki

- an entry per function and class, with it's discussion page to comment as it's being researched.

- function header in hex for easy location in the upk

- links to other functions called within (for functions) and methods (for classes)

- links to classes whose properties are read

- maybe a list with known values inside the function or class and their effects

- some sort of category system to group those elements related to a same game aspect or mechanic.

 

I would think that the Nexus staff would be happy to have a new game link on the main page ... that's what the Nexus wiki is for, after all.

 

As to the organization / structure -- well, to my mind ANYTHING would be better then nothing. The things you list look good, though ^_^ .

[SeraphicLaw]

On the contrary, I have found this board to be very much operating in a collaborative spirit, and I would caution against any kind of sense of entitlement about what modders haven't done for you. It is a very, very small community, and I think modders like Bokuak, BlackAlpha, Drakous79, and lately Yzaxtol and Amineri have either 1) made available much or all of their work and/or 2) answered questions from newer posters as best they can. I know I've tried to do both.

Dial it back there, Sparky. It was an observation, nothing more.

 

Yes, there are posts where people are sharing information on their 'discovery process', and I've read a few of them to mod quite a bit in my game considering my limited knowledge. But, take the conversations on modding the ability trees as an example - they share a bunch of code which makes no sense to me and chat about it for a while before coming back with "hex edit these numbers to change this", which is grand and all (and the visual perk editor is a godsend, whoever did that) but there's no organization of these conversations after the fact. No attempt to draw a map so others can figure out how you got there - though in this case the end results are really all that matters for people looking to mod that, but many other things have been achieved through mods and could be achieved that I dont see openly shared or discussed (how do you find out where and how to change the Will lost to a soldier who is critically wounded, for example?). No attempt to lay down the basics so others who have an interest and capacity to learn to help you all in the discovery process so they aren't still stuck trying to figure out the basics you got long before - the community is small because hex editting is a daunting task. Write a very basic how-to for newcomers to figure it out and this process won't turn away so many people interested in diving in is all I'm saying.

[anUser]

@ johnnylump: I totally agree with you. If I ever suggested such thing is because I think there is an open an collaborative community, maybe small, but alive enough to carry on, slowly, yeah, maybe, but taking consistent steps into further modding XCom. About the need of previous knowledge... yes and no, actually people only need to know the basics of scripting, understanding the logic behind variables, functions, params/arguments and return values, and you can do pretty stuff. When it comes to re-writting entire functions then we'll need the programmers there to show their skills, but imo even people with no previous knowledge can contribute just gathering info.

 

@ seraphicLaw: Even if I were to agree with you, which I don't here, I must first say thay just complaining about it doesn't solve the thing. The reason I opened this thread was precisely to discuss ways for a better storing and sharing of information, if you've got any idea that could help please feel free to share it here.

[Amineri]

I write up very detailed notes / journals that document the discovery process I go through. I haven't posted them before, since they are just my working notes (which I keep so I can remember what I've done, and what I've tried already and it didn't work!).

 

Hidden in the spoiler at the bottom is a copy of my journal for unlocking the Foundry at the beginning of the game. It includes my dead-ends and some random musings. It's also a VERY long read (be warned) !

 

I'd be more than happy to put these up alongside the actual modlets I come up with -- in an appropriate space. Then those that were interested could (a) follow along to get an idea of how to look for stuff (b) follow up on sideleads that I didn't explore.

 

I feel like a forum post isn't exactly the best place for these notes, though, since I don't want to overload people with too much info. A wiki with a side-link to the detailed notes would be great, though!

 

 

 

XComStrategyGame.XGItemTree.CanFacilityBeBuilt

References LABS().IsResearched(kFacility.iTechReq) to determine if tech requirement is met

kFacility is defined with kFacility = Facility(iFacility);

LABS is likely a global variable

Changing this if-else statement would likely unlock ALL research-required facilities -- no good!

Need to look at the kFacility structure returned by Facility(iFacility)

Not in XGFacility.uc

Entry 10 in BuildFacility() in XGItemTree is "optional XComGame.XGGameData.ETechType eTechReq"

Changing the Foundry facility when the type is built to not require the tech should allow it to be built right away

Not sure where the enumerated type Etechtype is defined

XGTechTree has, under "GetFoundryResults(XComGame.XGGameData.ETechType eTech)"

if(eTech == 0 || (eTech == 56) || (!HQ().HasFacility(11)))

{

return arrResults;

}

Looks like Foundry is Facility 11, and the required eTech is 56 - eTech 56 is a placeholder

Back at XGItemTree, in the BuildFacilities() function, Facility 11 looks like:

BuildFacility(11, 115, 0, 0, 20, 1, 10, -3, 1, 11, 105);

Argument Order is:

01) 11 - int iFacility

02) 115 - int iCashCost

03) 0 - int iElerium

04) 0 - int iAlloy

05) 20 - int iMaintenanceCost

06) 1 - int iEngineers

07) 10 - int iTime

08) -3 - int iPower

09) 1 - int iSize

10) 11 - optional XComGame.XGGameData.ETechType eTechReq

11) - optional XComGame.XGGameData.EItemType eItemReq

12) 105 - optional XComGame.XGTacticalScreenMgr.EImage EImage

DefaultGameCore.ini show SHIV, SHIV Suppression, and PistolI not requiring any eTech, although they actually all require Experimental Warfare

It was right in XComGame.upk in XGGameData class -- has lots of enums defined

the enum for eTech_Exp_Warfare is 11, so there it is.

the enum for eFacilityFoundry is 11 also

the enum for Interceptor is 105 (oddly building a Foundry seems to require an Interceptor? :o) might be skyranger. It's actually in field 12, and is an image link.

Next to see whether PistolI and SHIV Suppression can stay locked until Experimental Warfare is completed. Foundry projects aren't defined in XGItemTree. Also a bunch of other foundry projects that don't directly require Experimental Warfare (probably).

Not in XGFacility_Engineering apparently, either

XGFoundryUI, in the UpdateTableMenu() function, calls TECHTREE().GetAvailableFoundryTechs() to get a list of available Foundry techs for displaying

The GetAvailableFoundryTechs() function is defined in XGTechTree in XComStrategyGame

It checks error-checking stuff too, but the main test is !ENGINEERING.IsFoundryTechResearched(iTech) && HasFoundryPrereqs(iTech), where iTech is the Foundry tech counter for the loop over Foundry techs

IsFoundryTechResearched returns true if the base has a Foundry -- that is checking to make sure the facility is built

HasFoundryPrereqs() is defined in XGTechTree

SHIV_Suppression (enum 16) checks ENGINEERING.IsFoundryTechResearched(1) to see if SHIVs are researched. If they are it can proceed.

Alien Grenades (enum 2) checks to see if Alien Grenades have ever been owned

For the others,

kTech = FTECH(iFoundryTech) ((maybe a remapping of foundry tech to lab tech? where defined?))

Then STORAGE().GetNumItemsAvailable(kTech.iItemReq) is checked to make sure prereq items are available.

Then the check is !LABS().IsResearched(kTech.iTechReq)

FTECH must be some sort of global variable :( It also isn't defined anywhere apparent in the .upk files, so it must be hardcoded.

since only SHIV Suppression and Alien Grenades bypass the FTECH test, it may be that, even with a Foundry built, a SHIV may not be able to be researched, without modifying the code.

Will have to test -- it depends on the FETCH macro/global, which isn't visible.

The basic thing to unlock being able to build the Foundry right away is to modify the building creation in:

XComStrategyGame / SGItemTree / BuildFacilities

Structure is :

1B 61 04 to start : 1B is the virtual function call, and 61 04 is the pointer to the BuildFacility function

00 00 00 00 - four zeros follow (return value)?

The way the building number is passed is inconsistent

The first is passed with 0x26, the second with 0x04, third with 0x02. The optional variables make tracking it a bit tricky, but it always ends with 0x16, and the next starts with 1B 61 04 00 00 00 00 again

2C is used to indicate that the next variable is a single signed byte

1D indicates the next variable is a four-byte signed integer

24 indicates the next variable is a single unsigned byte

4A indicates skipping an optional argument

The section we are looking for reads (32 bytes):

1B 61 04 00 00 00 00 00 00 2C 0B 2C 73 25 25 2C 14 26 2C 0A 1D FD FF FF FF 26 24 0B 4A 24 69 16

|- function call/return -|

enum for Foundry --> 11

credit cost--> 115 0 0 20 1 10 -3 1 11 SKP 105 END

The line that calls BuildFacility(11, 115, 0, 0, 20, 1, 10, -3, 1, 11, 105); is broken down above.

The value we want to change is the 11, removing the lab tech requirement of Experimental Warfare. Properly, we should change the 24 0B to a 4A skip value, but doing so would reduce the size of the call by 1 byte, leaving a gap until the next call.

The IsResearched function will return a 1 if it is called with a zero (eTech_None), as the initialization functions sets m_arrResearched[0] = 1; So, simply changing the 0B to 00 should work.

Change:

1B 61 04 00 00 00 00 00 00 2C 0B 2C 73 25 25 2C 14 26 2C 0A 1D Fd FF FF FF 26 24 0B 4A 24 69 16

to (this works)

1B 61 04 00 00 00 00 00 00 2C 0B 2C 73 25 25 2C 14 26 2C 0A 1D Fd FF FF FF 26 24 00 4A 24 69 16

alternate: changing a '1' byte to 2C 01 (ALSO CAUSES GAME TO CRASH ON STARTUP)

1B 61 04 00 00 00 00 00 00 2C 0B 2C 73 25 25 2C 14 26 2C 0A 1D Fd FF FF FF 2C 01 4A 4A 24 69 16

third try : change number of required engineers to '2'

1B 61 04 00 00 00 00 00 00 2C 0B 2C 73 25 25 2C 14 2C 02 2C 0A 1D Fd FF FF FF 26 4A 4A 24 69 16

testing : even changing the 0A to 0B (to change the build days to 11 from 10) causes game crash

changing the 0A to 09, saving, then changing it back works fine, so it's not a save-issue with the hex editor

Problem was not running XSHAPE to fix the checksums in the .exe -- fixed -- first one works

Foundry is immediately available for building. SHIVs and Pistol I upgrade can be started immediately, as well as the SHIV suppression after SHIVs are researched in Foundry. Let's see if that can be fixed. Also, other foundry techs won't be checking for experimental warfare, either. What we want is for any foundry tech (except basic SHIVs) to check and see if experimental warfare is completed before being allowed.

The function that needs to be rebuilt is in XGTechTree, HasFoundryPrereqs()

function bool HasFoundryPrereqs(int iFoundryTech)

{

local TFoundryTech kTech;

// End:0x32 Loop:False

if(iFoundryTech == 16)

{

return ENGINEERING().IsFoundryTechResearched(1);

}

// End:0x6b Loop:False

if(iFoundryTech == 2)

{

// End:0x6b Loop:False

if(!STORAGE().EverHadItem(88))

{

return false;

}

}

kTech = FTECH(iFoundryTech);

// End:0xef Loop:False

if(kTech.iItemReq != 0)

{

// End:0xef Loop:False

if(STORAGE().GetNumItemsAvailable(kTech.iItemReq) == 0)

{

return false;

}

}

// End:0x132 Loop:False

if(!LABS().IsResearched(kTech.iTechReq))

{

return false;

}

return true;

}

Want something more like

if(iFoundryTech == 1) return true; // so SHIVs can still be researched

if(!LABS().IsResearched(11)) return false; // but any other project can't be researched until Experimental Warfare is done

... then the rest of the function. Might be difficult to squeeze it in there(!)

If SHIVS are unlocked at the beginning of the game, then could skip the SHIV suppression check... in fact, could skip it anyhow. If people want to not research SHIVs and research SHIV suppression after getting experimental warfare... great! xD

I think the check to see if we've ever had alien grenades can be removed also, since the later check to see if we currently have any them supercedes it.

Easiest to replace the

if(iFoundryTech == 16) {return ENGINEERING().IsFoundryTechResearched(1);}

with if(iFoundryTech == 1) return true;

and the

if(iFoundryTech == 2){if(!STORAGE().EverHadItem(88)){return false;} }

with if(!LABS().IsResearched(11)) return {false;}

The first function being replaced is pretty straightforward ... lots of extra bytes left over (42 bytes):

07 32 00 9A 00 DF 45 00 00 2C 10 16 04 19 1B 75 0B 00 00 00 00 00 00 16 0B 00 7C 2A 00 00 00 1B 65 14 00 00 00 00 00 00 26 16

Broken down:

07 32 00 -- Jump if-not, 0x32 bytes // need to change to 0x16 since function is shortened

9A 00 -- == operator

DF 45 -- local variable iFoundryTech

2C 10 -- defines the integer constant byte 16 // change to value '1' so it references SHIV research

16 -- end function, to the compare and jump if not equal

04 -- sets up return function // this is the end of the function, so keep this

19 -- ?? // can change this to 0x27 "true"

1B 75 0B -- virtual function call to ENGINEERING global // goes away

six zero bytes for return value // goes away

16 -- execute virtual function call // goes away

0B -- no op (?)

7C 2A -- reference to the XGFacility_Engineering.IsFoundryTechResearched.ReturnValue // goes away

1B 65 13 -- virtual function call to Is FoundryTech Researched // goes away

26 -- parameter '1' // goes away

16 -- make virtual function call // goes away

Replace ((offset 003C0E8E in my upk)) (42 bytes)

07 32 00 9A 00 DF 45 00 00 2C 10 16 04 19 1B 75 0B 00 00 00 00 00 00 16 0B 00 7C 2A 00 00 00 1B 65 14 00 00 00 00 00 00 26 16

with (14 bytes)

07 2E 00 9A 00 DF 45 00 00 2C 01 16 04 27 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B -- pad the rest with 0x0B no-ops if needed (padded with zeros)

The second function is being replaced is (49 bytes)

07 6B 00 9A 00 DF 45 00 00 2C 02 16 07 6B 00 81 19 1B 23 27 00 00 00 00 00 00 16 0C 00 80 40 00 00 00 1B 29 0D 00 00 00 00 00 00 2C 58 16 16 04 28

Broken down:

07 6B 00 -- jump if-not, 0x6B bytes // needs to be shortened for shorter function length

9A 00 -- == operator

DF 45 -- local variable iFoundryTech .. same as previous function // being replaced by call to LAB.IsResearched

2C 02 -- signed byte for 02 .. same as previous, but checking if 2 instead of 16 // gone

16 -- execute conditional jump

07 6B 00 81 19 -- Jump if not equal with memory address (?) // going away -- don't need second conditional

1B 23 27 -- virtual function call to STORAGE // don't need

16 -- execute virtual function call to retrieve address // don't need

0C -- ??

80 40 -- offset to XGStorage.EverHadItem.ReturnValue // don't need

1B 29 0D -- virtual call to EverHadItem // don't need

2C 58 - signed byte for 88 -- enum for alien grenades // don't need

16 -- execute call to EverHadItem // don't need

16 -- execute conditional jump on return of EverHadItem // don't need

04 28 -- return false if it didn't jump // can keep this

Change: ((offset 003C0EB8 in my upk))

07 6B 00 9A 00 DF 45 00 00 2C 02 16 07 6B 00 81 19 1B 23 27 00 00 00 00 00 00 16 0C 00 80 40 00 00 00 1B 29 0D 00 00 00 00 00 00 2C 58 16 16 04 28

07 67 00 9A 00 DF 45 00 00 2C 02 16 07 67 00 81 19 1B 23 27 00 00 00 00 00 00 16 0C 00 80 40 00 00 00 1B 29 0D 00 00 00 00 00 00 2C 58 16 16 04 28 // updated jump address for earlier shortened function

to

07 63 00 81 19 1B 8B 16 00 00 00 00 00 00 16 26 00 77 2C 00 00 00 1B BF 14 00 00 00 00 00 00 2C 0B 16 16 04 28 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B -- pad with 0x0B no-ops

The existing if(!LABS()IsResearched(kTech.iTechReq) {return false;} (51 bytes):

07 32 01 81 19 1B 8B 16 00 00 00 00 00 00 16 26 00 77 2C 00 00 00 1B BF 14 00 00 00 00 00 00 35 3B 1E 00 00 44 1E 00 00 00 00 00 DD 45 00 00 16 16 04 28

Broken down:

07 32 01 -- Jump if-not, to 0x132

81 19 -- ??

1B 8B 16 -- is a virtual function to the LABS global // this should be correct

The following six zeros are local variable space to hold the pointer to the labs struct (?)

26 is '1' // keep

77 2C is offset to XGFacility_Labs.IsResearched.ReturnValue // keep

1B BF 14 is is virtual function call to "IsResearched" // keep

35 is cast to Boolean operator // keep

3B 1E is the compare byte to bool check // keep

44 1E is the reference to the TFoundryTech class that kTech is based on // replace with 2C 11

DD 45 is the local variable kTech // remove

16 -- execute call to IsResearched // keep, since IsResearched is still being called

16 -- execute conditional jump // keep this execute

04 28 return false if we get here (didn't jump)

which local variable space do I need? can compare to if(!STORAGE().EverHadItem(88)) in function, since it has an identical structure

07 6B 00 81 19 1B 23 27 00 00 00 00 00 00 16 0C 00 80 40 00 00 00 1B 29 0D 00 00 00 00 00 00 2C 58 16 16 04 28

07 32 01 81 19 1B 8B 16 00 00 00 00 00 00 16 26 00 77 2C 00 00 00 1B BF 14 00 00 00 00 00 00 35 3B 1E 00 00 44 1E 00 00 00 00 00 DD 45 00 00 16 16 04 28

The in-between local variable-assignment (not being changed - for use in ToolBoks)

0F 00 DD 45 00 00 1B 35 0E 00 00 00 00 00 00 00 DF 45 00 00 4A 16

Need to adjust later if/jump address offsets to adjust for smaller earlier virtual functions

Need to change jump offsets in later functions to accomodate changes in function size

07 EF 00 9B 35 3C 1E 00 00 44 1E 00 00 00 00 00 DD 45 00 00 25 16 07 EF 00 9A 19 1B 23 27 00 00 00 00 00 00 16 26 00 7D 40 00 00 00 1B CC 0F 00 00 00 00 00 00 35 3C 1E 00 00 44 1E 00 00 00 00 00 DD 45 00 00 16 25 16 04 28

changed from EF to E7

07 E7 00 9B 35 3C 1E 00 00 44 1E 00 00 00 00 00 DD 45 00 00 25 16 07 E7 00 9A 19 1B 23 27 00 00 00 00 00 00 16 26 00 7D 40 00 00 00 1B CC 0F 00 00 00 00 00 00 35 3C 1E 00 00 44 1E 00 00 00 00 00 DD 45 00 00 16 25 16 04 28

07 32 01 81 19 1B 8B 16 00 00 00 00 00 00 16 26 00 77 2C 00 00 00 1B BF 14 00 00 00 00 00 00 35 3B 1E 00 00 44 1E 00 00 00 00 00 DD 45 00 00 16 16 04 28

changed from 132 to 012A

07 2A 01 81 19 1B 8B 16 00 00 00 00 00 00 16 26 00 77 2C 00 00 00 1B BF 14 00 00 00 00 00 00 35 3B 1E 00 00 44 1E 00 00 00 00 00 DD 45 00 00 16 16 04 28

Adjust Virtual File size in header from 013F to 0136

00000000 DF 45 00 00 AB 1F 00 00 00 00 00 00 DC 45 00 00 . E . . . . . . . . . . . E . .

00000010 00 00 00 00 00 00 00 00 DF 45 00 00 00 00 00 00 . . . . . . . . . E . . . . . .

00000020 DA 01 00 00 38 5F 00 00 3F 01 00 00 F7 00 00 00 . . . . 8 _ . . ? . . . . . . .

00000000 DF 45 00 00 AB 1F 00 00 00 00 00 00 DC 45 00 00 . E . . . . . . . . . . . E . .

00000010 00 00 00 00 00 00 00 00 DF 45 00 00 00 00 00 00 . . . . . . . . . E . . . . . .

00000020 DA 01 00 00 38 5F 00 00 36 01 00 00 F7 00 00 00 . . . . 8 _ . . ? . . . . . . .

*************** FINAL CHECK ***************************

This is the entire block of code being updated, with no gaps

DA 01 00 00 38 5F 00 00 3F 01 00 00 F7 00 00 00 07 32 00 9A 00 DF 45 00 00 2C 10 16 04 19 1B 75 0B 00 00 00 00 00 00 16 0B 00 7C 2A 00 00 00 1B 65 14 00 00 00 00 00 00 26 16 07 6B 00 9A 00 DF 45 00 00 2C 02 16 07 6B 00 81 19 1B 23 27 00 00 00 00 00 00 16 0C 00 80 40 00 00 00 1B 29 0D 00 00 00 00 00 00 2C 58 16 16 04 28 0F 00 DD 45 00 00 1B 35 0E 00 00 00 00 00 00 00 DF 45 00 00 4A 16 07 EF 00 9B 35 3C 1E 00 00 44 1E 00 00 00 00 00 DD 45 00 00 25 16 07 EF 00 9A 19 1B 23 27 00 00 00 00 00 00 16 26 00 7D 40 00 00 00 1B CC 0F 00 00 00 00 00 00 35 3C 1E 00 00 44 1E 00 00 00 00 00 DD 45 00 00 16 25 16 04 28 07 32 01 81 19 1B 8B 16 00 00 00 00 00 00 16 26 00 77 2C 00 00 00 1B BF 14 00 00 00 00 00 00 35 3B 1E 00 00 44 1E 00 00 00 00 00 DD 45 00 00 16 16 04 28

**** HEX BLOCK FOUND IN UNMODDED UPK ****

To test, hack in a large number of starting scientists to complete other projects and verify that they can't be completed.

Starting Scientists are set in XGFacility_Labs, in InitNewGame(), the line: m_iNumScientists = class'XGTacticalGameCore'.default.NUM_STARTING_SCIENTISTS;

XGTacticalGameCore is in XCOMGame.upk, but these values, to be changed, have to be hacked directly into the EXE with modpatcher

m_iNumScientists = class'XGTacticalGameCore'.default.NUM_STARTING_SCIENTISTS;

0F 01 E9 2B 00 00 12 20 6D FE FF FF 09 00 F4 FB FF FF 00 02 F4 FB FF FF

0F 01 E9 2B 00 00 2C 50 6D 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B

m_iTechConfirms = 3;

0F 01 DF 2B 00 00 2C 03

Modified Block

9D 2C 00 00 AB 1F 00 00 00 00 00 00 9D 2C 00 00

62 27 00 00 00 00 00 00 00 00 00 00 00 00 00 00

79 04 00 00 D4 85 00 00 8E 00 00 00 5E 00 00 00

54 01 E8 2B 00 00 2C 39 16 0F 10 25 01 E8 2B 00

00 26 54 01 E6 2B 00 00 2C 39 16 54 01 E5 2B 00

00 2C 39 16 0F 01 E9 2B 00 00 2C 50 14 2D 01 5B

27 00 00 27 14 2D 01 F0 2B 00 00 27 0F 01 DF 2B

00 00 2C 03 0F 01 DE 2B 00 00 26 04 0B 0B 0B 0B

0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 53

00 2C 39 16 0F 01 E9 2B 00 00 2C 50 14 2D 01 5B 27 00 00 27 14 2D 01 F0 2B 00 00 27 0F 01 DF 2B 00 00 2C 03 0F 01 DE 2B 00 00 26 04 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 53

79 04 00 00 D4 85 00 00 81 00 00 00 5E 00 00 00

Original Block

9D 2C 00 00 AB 1F 00 00 00 00 00 00 9D 2C 00 00

62 27 00 00 00 00 00 00 00 00 00 00 00 00 00 00

79 04 00 00 D4 85 00 00 8E 00 00 00 5E 00 00 00

54 01 E8 2B 00 00 2C 39 16 0F 10 25 01 E8 2B 00

00 26 54 01 E6 2B 00 00 2C 39 16 54 01 E5 2B 00

00 2C 39 16 0F 01 E9 2B 00 00 12 20 6D FE FF FF

09 00 F4 FB FF FF 00 02 F4 FB FF FF 14 2D 01 5B

27 00 00 27 14 2D 01 F0 2B 00 00 27 0F 01 DF 2B

00 00 2C 03 0F 01 DE 2B 00 00 26 04 0B 53

00 2C 39 16 0F 01 E9 2B 00 00 12 20 6D FE FF FF 09 00 F4 FB FF FF 00 02 F4 FB FF FF 14 2D 01 5B 27 00 00 27 14 2D 01 F0 2B 00 00 27 0F 01 DF 2B 00 00 2C 03 0F 01 DE 2B 00 00 26 04 0B 53

79 04 00 00 D4 85 00 00 8E 00 00 00 5E 00 00 00