Adding a third item slot?

[TheRealSFlo]

Is it possible to add a third utility slot to soldiers? It seems like Firaxis hard-coded it and I'm beyond frustrated.

 

You see, there is a stat tied to soldiers that governs the number of items they carry: eStat_UtilityItems.

 

However, instead of doing something sensible like just tying that stat to an integer value on armor, each piece of armor has a flag named bAddsUtilitySlot attached to it. The game appears to check that flag in 'XComGameState_Unit.uc' and assign the eStat_UtilityItems stat a value of either 1.0f or 2.0f based on that armor flag in the AddItemToInventory(), RemoveItemFromInventory(), and ValidateLoadout() functions.

 

So yeah. Instead of being a simple value we can easily modify, utility items seem to be assigned based off of an if statement in a class that we cannot override.

 

There something I'm missing here? Is there actually a way to modify this number that the game won't immediately switch back over?

[davidlallen]

I am having the same problem, on the zero end instead of the three end.

My Chryssalids keep equipping grenades but they have no fingers to throw them with.

http://forums.nexusmods.com/index.php?/topic/3874250-class-specific-armor-and-no-utility-slot/

I do not have any solution. Are you sure this function out of the class cannot be overridden?

[TheRealSFlo]

Nope. GameState classes cannot be overridden short of entirely recompiling XComGame.upk and replacing it with your mod. Thing's stuck as-is unless there's an ultra-clever workaround someone can come up with.

 

Pisses me off a bit. I get that they restricted access to GameStates to keep mods from breaking the game, but what in the hell is up with the if-then logic for slot stat assignments? I thought they said they were going to stop hardcoding stuff.

Edited March 16, 2016 by TheRealSFlo

[MachDelta]

Is it possible to come at this from the other end and intercept items (or their templates) and set their iItemSize=0? I didn't spend overly long looking at the scripts, but this might be a way of essentially stepping around anything that checks against eStat_UtilityItems - at which point you'd have to roll/borrow your own inventory validation methods and likely hook them through a screenlistener or somesuch, (unless you want an infinite inventory, I guess). Not sure if it's doable, just a thought I had.

 

Otherwise, like bountygiver said on Reddit, I imagine you'd be stuck with creating a custom GameState component and essentially building a second (utility item) inventory. Plus mangling UIScreens as needed.

[Lucubration]

Yes, the manner in which they implemented the inventory is extremely frustrating. I haven't found a simple way around it; as mentioned above, it'd take a lot of effort to work around the current system with a hack, or (and I kind of think we're going to want to do this eventually anyways) having a modding team blow it all away and create like a Community Edition XComGame.upk that extends a lot of the core functionality for modding.

Edited March 16, 2016 by Lucubration

[Perraine]

Maybe having a look at this thread?

 

http://forums.nexusmods.com/index.php?/topic/3838055-grenade-slotgrenadier-test-grenade-slot-unexpected-behavior/

 

Seems to go into some detail about Grenade Slots and Item Slots and so on ... not sure if it'll help though.

[traenol]

Basically, the only 'easy' way would be to completely overhaul the gamestate classes responsible(mainly unit) and 'fix' the code. The item size code was for the now depreciated and removed backpack code, and as such has no impact as far as I can tell.

 

A workaround of some kind could be done, but you would end up overriding so many different UI screens and other classes that it might actually be more work than its worth to add that 1 slot.

 

Also, the flags that it uses for the switch case make it so adding that flag to multiple items does not increase the number of slots more than 1 time. It is literally a 'has an extra slot' and not 'gains 1 more slot' :(

[FxsRMcFall]

Looked into this and indeed it seems like the sanctity of the utility item stat has been sacrificed in the name of some bug fix.

 

As far as working around the stat being stomped I am curious whether you could work around the problem by using the MP character template name. In every case where bAddsUtilitySlot stomps the stat, it avoids doing so if there is an MP template name specified with SetMPCharacterTemplate. If you just make it 'Soldier' or whatever the normal character template is ... I believe that would suffice. The side effects of the MP template name being set would probably be acceptable relative to the stat being stomped.

 

As was noted above unclamping the stat will have knock-on effects for other areas of the game. At the very minimum you would have to review UIArmory_Loadout and make anything there use the stat that wasn't already using it.