R&D to Increase Squad Size

[TheOldOne822]

In addition to replacing m_strBackpackLabel with m_arrUIOptions[iSlot].item3 you would need to change the XComStrategyGame.upk

struct UISquadList_UnitBox
{
    var int iIndex;
    var string strName;
    var string strNickName;
    var string classDesc;
    var string classLabel;
    var string item1;
    var string item2;
    var int iStatus;
    var bool bPromote;
    var bool bEmpty;
    var bool bUnavailable;
    var bool bHint;

As you can see it's coded for only 2 items

[XMarksTheSpot]

Let me make sure I understand. The sprite has been updated to support 12 but the UISquadSelect_SquadList.Init() still only supports 8 so the last 4 on the sprite won't work.

Yeah, I suspect as long as the m_arrFillOrderIndex array doesn't contain the same number of items as the m_arrUIOptions array any unmapped slots won't work, which is currently the case.

 

Edit: I guess we also need to figure out how to hide/disable the extra selectionboxes when skyranger limit is less than 10 (+2 OTS upgrades=12)...

I think this is another side-effect of the m_arrFillOrderIndex and m_arrUIOptions arrays being of different lengths, the UISquadSelect_SquadList.UpdateData() method contains the following snippet:

iOption = 0;
while (iOption < m_arrUIOptions.Length)
{
    m_arrUIOptions[iOption].bEmpty = true;
    iDropShipIdx = m_arrFillOrderIndex.Find(iOption);
    m_arrUIOptions[iOption].bUnavailable = iDropShipIdx >= m_iMaxSlots;
    ++ iOption;
}

I believe whatever the m_arrFillOrderIndex.Find(iOption) returns (I suspect -1) is never greater or equal to m_iMaxSlots (which is the Skyranger's capacity), so the bUnavailable flag remains false at all times causing the UISquadSelect_SquadList.UpdateDisplay() method to then call AS_SetAddUnitText() on those slots thereby unhiding their sprites (they are hidden by default).

One simple hack might be to set the default value for bUnavailable to true, but in the long term re-writing the way the fill order array is filled is the preferred solution :smile:

 

I wouldn't be too surprised if replacing m_strBackpackLabel with m_arrUIOptions[iSlot].item3 would have desired effect (but making it item1 followed by 2 and 3 would have course make more sense) :smile:

Actually, it'd be surprising if that worked as the item1 and item2 variables are part of the UISquadSelect_SquadList.UISquadList_UnitBox struct and get their values from another struct, namely XGChooseSquadUI.TSoldierLayout. The values of the latter struct are in turn set by the following snippet in XGChooseSquadUI.BuildLoadout():

if (kSoldier.m_kChar.kInventory.arrSmallItems[0] != 0)
{
	kLoadout.item1.StrValue = Item(kSoldier.m_kChar.kInventory.arrSmallItems[0]).strName;
}

if (kSoldier.m_kChar.kInventory.arrSmallItems[1] != 0)
{
	kLoadout.item2.StrValue = Item(kSoldier.m_kChar.kInventory.arrSmallItems[1]).strName;
}

I haven't looked at it in detail, but I think the arrSmallItems array is initialized to hold up to 16 elements, so additional items beyond the standard two should be accessible in there. Even if the backpack label would be re-jiggered to be used as another item label this would still not be enough for mods introducing more than 3 small item slots.

What I'd propose is a different direction: I'd do away with the second item label, make the first one larger and able to auto-scroll vertically (perhaps sacrificing its horizontal auto-scrolling behavior in the process, but I'd call that acceptable). Instead of providing single strings to various variables the snippet above should then be re-coded to loop through the whole arrSmallItems array, concatenate all non-empty name strings with line breaks in-between and storing it all in item1.

How's that sound? :smile:

 

I just started looking into fillorder via loop now...

But I'm starting to think it would make more sense to unscramble it while I'm at it...

 

Puting soldier 0 in slot 0, soldier 1 in slot 1...

In the vanilla game the fill order is arranged in a way to fill out the slots from the center out with the squad leader being placed first. This is also reflected in the positions of the soldier pawns, the designated squad leader features prominently in the front. Personally I'd prefer it if this ordering could be kept, putting the squad leader (however insignificant its gameplay role may be) to the far right doesn't seem... right (ungh :pinch:)

Edited August 8, 2013 by XMarksTheSpot

[theoldone22]

To test I set small items to 16 and 17. pulling up the loadout screen worked at 16 but crashed xcom at 17.

Edited August 8, 2013 by theoldone22

[XMarksTheSpot]

To test I set small items to 16 and 17. pulling up the loadout screen worked at 16 but crashed xcom at 17.

Thanks for confirming that limitation, I suppose 16 small items slots is still more than enough :)

[Bertilsson]

I of course didn't notice that there was a page 16 available and merrily updated fillorder to be linear and m_arrUIOptions to be dynamic.

code is here: http://forums.nexusmods.com/index.php?/topic/804076-rd-to-increase-squad-size/?p=8721710

 

For the moment being I think I will leave it as it is, but I am very open to take the extra small steps to respect vanilla fill order as soon as we solve the issue with the extra slots.

[Amineri]

The structure at work here is the TInventory struct, which is defined in XComGame.upk >> XGTacticalGameCoreNativeBase.

struct native TInventory
{
    var int iArmor;
    var int iPistol;
    var const int arrLargeItems[16];
    var const int iNumLargeItems;
    var const int arrSmallItems[16];
    var const int iNumSmallItems;
    var const int arrCustomItems[16];
    var const int iNumCustomItems;

This is the structure that is used predominantly in the strategy game and is used to shuttle information between the tactical and strategy components. Once in the tactical game items are mapped into a more complex structure utilizing the XGItem and XGInventory classes. As you can see the hard-coding limits soldiers to a single armor and single pistol, and up to 16 each of small and large items.

 

Custom items are used to hold items that are "auto-equipped". The two key ones are the psi-amp that is equipped to psionic soldiers and aliens -- the second is the grapple.

[XMarksTheSpot]

For the moment being I think I will leave it as it is, but I am very open to take the extra small steps to respect vanilla fill order as soon as we solve the issue with the extra slots.

You already solved that issue by yourself :) By properly filling out the fill order array any slots beyond the skyranger's capacity stay hidden, as they should be.

[Bertilsson]

Yes, but the extra slots are "removed" from left to right... and that doesn't scale well with jagged fillorder...

 

Right now I'm thinking about a compromize where the first 4 slots should be filled jaggedly and slot 5-12 would be linear.

 

How about placing the soldiers like this?

11 10 9 8 7 6 5 4 0 1 2 3

Edited August 8, 2013 by Bertilsson

[TheOldOne822]

I'd like the vanilla fillorder but I think a linear fillorder is fine for now and may be necessary if the only way to have extra pawns is to run all pawns from the same slot and apply an offset.

[XMarksTheSpot]

Yes, but the extra slots are "removed" from left to right... and that doesn't scale well with jagged fillorder...

 

Right now I'm thinking about a compromize where the first 4 slots should be filled jaggedly and slot 5-12 would be linear.

 

How about placing the soldiers like this?

11 10 9 8 7 6 5 4 0 1 2 3

I'm not sure I'm following you here, as far as I can tell extra slots would be removed as they are defined in the fill order, from the outside in if using vanilla fill order. Am I missing something?