So basically there's a bit of UPK re-coding necessary to make any new slots actually functional
I definitely felt like I spent more time with the perk tree mod making the required upk changes than I did the sprite changes (although I ended up with more ambitious plans than simple displaying more perks).
On the other hand, the launch window sprite only really needed 4 changed to 6 in a bunch of places in the upk code to get working UPK-side (they didn't reference a variable or even a constant but instead had hard-coded the maximum of 4 launch interceptors in many places).
For those not familiar with the upk-side UI coding conventions that Firaxis used (and maybe are standard for Unreal Engine games??), each UI functionality is typically broken into two parts. The first part is named UI<name> and the second is named XG<name>UI. The XG<name>UI class is referenced in the code as the "manager". Typically each UI<name> class has a functin called GetMgr() that returns the appropriate manager class associated with the UI. The UI<name> class is always the one that contains the actionscript calls, and is also where any callbacks from the UI are first handled. Typically there is no or very little data handling in the UI class. Most data manipulation is handled within the XG<name>UI manager class.
For the squad select UI, there are two UI "driver" classes :UISquadSelect and UISquadSelect_Squadlist, while the "driver" class is XGChooseSquadUI. They appear to have slightly bent their naming convention here by not using the same core name. The UISquadSelect_SquadList appears to the the driver that handles individual soldier display info, call the actionscript functions SetAddUnitText, SetSelected, SetUnitHelp, and SetUnitInfo (all of which are defined in the actionscript package Squadlist).
Note that the barracks situation is a bit mixed up as there is one common "manager" XGSoldierUI that handles data for all of the various barracks-related UI "driver" classes
Went trawling through the code and didn't initially see any hard-coded references limiting display of soldiers to only 6 in either the driver or manager classes. However in the actionscript package Squadlist there is the const definition : static var MAX_UNITS = 6; I'm not sure if you already updated this or not to even get more than 6 boxes displaying on screen.
The actionscript package Squadlist has the following bit of code for SetSelected boundary checks against MAX_UNITS.
Another place that likely needs to be updated is the
simulated function Init(XComPlayerController _controller, UIFxsMovie _manager, UI_FxsScreen _screen, XGMission kMission, bool bNav)
local XGShip_Dropship kSkyranger;
PanelInit(_controller, _manager, _screen);
bCanNavigate = bNav;
kSkyranger = kMission.GetAssignedSkyranger();
m_iMaxSlots = kSkyranger.GetCapacity();
m_iCurrentSelection = ((m_iMaxSlots == 6) ? 5 : 4);
m_arrUIOptions is a dynamic array but only initialized to contain 6 elements, so would have to be increased to hold more.
m_arrUIOptions is a dynamic array of structs defined as:
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;
So, it basically contains pretty much all of the info displayed in each unit box (also note that it is hard-coded to only have two item strings, thus making display of a third or subsequent small item really challenging).
The other thing of note is the dynamic array m_arrFillOrderIndex. This appears to be what controls how the squadselect boxes are filled out "from the middle out", while the sprite is defined (as pretty much all the sprites are) from right to left.
The sprite box order should be :
5 4 3 2 1 0
The m_arrFillOrderIndex array basically remaps the fill order to:
4 2 0 1 3 5
Since the element of m_arrUIOptions is always referenced via code such as:
iDropShipIdx = m_arrFillOrderIndex.Find(iOption);
m_arrUIOptions[iOption].bUnavailable = iDropShipIdx >= m_iMaxSlots;
the m_arrFillOrder has to be taken into account in order to properly access the new sprites at positions 6 and 7.