R&D to Increase Squad Size

[johnnylump]

Forgot to report that I came very close to getting this... The above code has been more optimised but I hit another brick wall. Have not updated new code. I could not refresh the UI soldiers list and screen when scrolling through the boxes.

 

Don't know if this will help, but I have located at least some of the ActionScript (Flash coding) used in squad selection. It's in command1.upk. The packages are called SquadSelect_UnitBox, SquadList and SquadSelect.

 

I notice a particular hex string

96 09 00 04 01 08 0a 07 06 00 00 00 4f 96 09 00

sets variable MAX_UNITS to 6. Changing the 06 to something larger should change the Max_Units value. However, I suspect some significant recoding would be necessary to fit more than 6 squaddies on the screen.

 

Interestingly, this MAX_UNITS=6 string occurs twice in command1.upk;

96 09 00 04 01 08 0a 07 06 00 00 00

 

(I added some more hex to the above one to ensure it was the one unique to Squadlist.)

 

I have not located the function the other one resides in, but it may also be a necessary change, or it may be related to something different.

 

See the "UI Editing" thread for details on how to extract and view ActionScripts. PM me if you'd like me to email the extracted swf with these functions.

Edited January 20, 2013 by johnnylump

[Bertilsson]

Earlier today I did a little peeking into XComGame.upk with EU Explorer and discovered the following line of simulated code inside a for-loop inside XGPlayer.LoadSquad()

kSpawn = arrSpawnPoints[I];

I figured if that code was changed to this:

kSpawn = arrSpawnPoints[0];

or this:

kSpawn = arrSpawnPoints[I%5]; 

Then there should no longer be an issue with soldiers ending up away from the others. Instead Everyone should team up inside a single valid spawn spot, or in the latter case evenly sharing all 6 available spawn spots.

 

Since my hex-coding skills are less than h3x0r I asked amineri to help me out by creating the hex-change for alternative 1, which seemed to be the least complicated to implement.

 

A lot quicker than expected she returned a little hex-change that I have now included in a little toolboks mod below (with a nostalgic but completely unreasonable number of 26 soldiers per mission and 40 in barracks) :

MOD_NAME=Unlimited number of soldiers
AUTHOR=amineri
DESCRIPTION=Lots and lots of soldiers

Version: 0.1

Compatible with XCOM Enemy Unknown versions:
 - Patch 4 ( Changelist: 356266 )

UPK_FILE=XComGame.upk
OFFSET=8571402
[MODDED_HEX]
{All XCOM-soldiers spawn in a single tile}
0F 00 A7 94 00 00 10 25 00 AD 94 00 00 0B 0B 00 A8 94 00 00 06 4E 02 82 9B 38 3A 19 01 E9 F9 FF FF 09 00 AB FE FF FF 00 01 AB FE FF FF 38 3A 24 00 16 18 33 00 12 20 B2 00 00 00 1D 00 8C 00 00 00 00 1B CA 3C 00 00 00 00 00 00 10 00 A8 94 00 00 00 AC 94 00 00 16 16 0F 00 AB 94 00 00 1C 3D FC FF FF 1B 58 03 00 00 00 00 00 00 10 00 A8 94 00 00 00 AC 94 00 00 16 4A 4A 4A 4A 4A 4A 4A 16 19 00 AB 94 00 00 30 00 00 00 00 00 00 1B FC 62 00 00 00 00 00 00 35 D5 44 00 00 D6 44 00 00 00 00 10 00 A8 94 00 00 00 B1 94 00 00 16
 
[INI]
NUM_STARTING_SOLDIERS=40
SKYRANGER_CAPACITY=26

I have tested it out and it works perfect with the following "minor details" :ermm:

• You can only pick 6 favourite soldiers to bring on the mission, the rest will be autoselected for you by the game
• You have to equip everyone except your 6 favourites via the baracks before mission.
• You will only receive after mission report regarding your 6 favourites.
• It looks pretty weird to have a lot of soldiers in a single tile, all aiming around independently.

Except for the list above I have not been able to find any problems or bugs what so ever (The increased squad size I and II in OTS works).

 

but I did notice that It was kind of tiresome that TAB selects the closest soldier with action points left during turn one. If the implementation had been arrSpawnPoints[i%5] instead then the TAB order would have worked much better as everyone would have been spread out on 6 tiles instead.

 

I think it may actually be time to at least start thinking about rebalancing mods with regard to bigger XCOM-Squads.

 

Sure it is very far from perfect but it is actually very playable and the issues with the interface may possibly be solved one day and even if not I think it would be worth living with it as it is.

And if the soldiers are spread out evenly on all six spots then it should really not be a big deal that a couple of them are paired until moved, even if a better solution would be... better! :smile:

 

Regarding the soldier selection I suspect that it may be more viable to modify the barracks-interface to be able to select skyranger crew very much like the original XCOM, but I sure can't do it, so it is just a theory.

Edited June 30, 2013 by Bertilsson

[johnnylump]

Great find. Now if we can find a way to offset soldier 7-12's position by 1 tile.

 

Absent squad select interface updates, my thought for picking additional soldiers would be via small item equipped in the barracks. Then you would know who would be assigned to the squad and could outfit them ahead of time.

[Bertilsson]

The offseting soldier 7-12 might be a bit tricky since at least one mission (construction site on a roof in India) actually have spawn spots next to a solid wall on the left, and a ramp on the other side going up to normal level for the rest of the map.

 

But if it is possible to validate the spawnspot neighbor spots before selecting them or offset in a given direction relative to in which direction the soldier is looking, then it should be safe.

 

One idea I talked to amineri about was to modify the discard-soldier button to modify status from active to something else not available for mission. That way you can indirectly select who will go on the mission by grounding the ones you want to leave behind.

 

One other idea was to make it reverse so instead of your best available soldiers being added, you get the least experienced one from bottom of the list to and perhaps rename OTS upgrades to "Bring a Rookie to Work" (amineris name for it).

 

Amineri also proposed making the extras completely random as an alternative.

 

All except the random alternative is assuming that a proper update of the squad-selection screen cannot be done.

 

I also tested to increase and decrease MAX_UNITS=6

Not very surprising increasing it did not make more boxes appear but decreasing it to 3 works to limit the number of freely selectable soldiers. You still see them standing and they are selected as "on mission" but you cant remove them because they have no box for it. So it is defintively involved.

[Amineri]

The alien pod placement code in XComAlienPod.GetDistributedLocationAround uses the following line to insure that aliens are placed in terrain:

    vLoc_Out = XComTacticalGRI(WorldInfo.GRI).GetClosestValidLocation(vLoc_Out, kUnit,, false, true);

This function is one that places the aliens in the 3x3 tile square surrounding the designated spawn point. They also do some height checking since this function is also used by the patrol routine when warping patrolling pods around the mission map. When patrolling the code uses slightly larger 2x3 array positioning to distrubute the aliens. All of this is done to make the alien turn go faster, I think.

 

Regardless, there are functions to test whether a point is valid, and to find the nearest valid location.

 

There's even the function:

    vLocation.Z = class'XComWorldData'.static.GetWorldData().GetFloorZForPosition(vLocation, true);

to make sure that newly placed units are on the ground and not floating in the air or underground.

[johnnylump]

 

One other idea was to make it reverse so instead of your best available soldiers being added, you get the least experienced one from bottom of the list to and perhaps rename OTS upgrades to "Bring a Rookie to Work" (amineris name for it).

 

Interesting thought. My concern about this is that it creates weird and gamey incentives in managing your roster. Basically I'd want to avoid adding rookies unless I absolutely had to -- because hiring rookies now hurts my ability to win missions. Not sure if I'd go so far to just keep eight troops on the roster, but some players might, and I'm not sure we want to encourage that. And if you make it "rookies-only" -- not allowing squaddies or greater -- then the incentive is to constantly add rookies, even to the point of dropping squaddies when you hit the barracks maximum, to keep at the eight-soldier squads.

 

My preference is to give players control if we can. My proposal is a small backpack item -- call it enhanced comms or something -- that can be unlocked by the first squad size project. It's free to build in engineering. The player gives the item to however many additional soldiers are allowed by the skyranger capacity; those soldiers are added to the mission list when it starts (in addition to the six designated on the equip screen). This gives them exact control over who is going.

 

An advantage here is that it allows modders to go big with squad size if the want. I really don't want more than eight troops on missions for Long War, but if someone wants twelve, they can go there.

 

The possibility here is user error, which we can try to avoid by preventing exploits and informing players of negative outcomes:

 

* A soldier on the dropship screen (one of the primary six) has the item. Outcome should be that one less soldier goes on the mission; that is, the item doesn't help.

 

* The player builds and equips more of these items than is allowed by Skyranger capacity -- that is, squad size is eight; player builds and equips three enhanced comms items, which would only work if the max was nine or more. Outcome should be that the code picks which two of the three equipped with the item actually go on the mission via whatever algorithm we like.

 

There's a slight nerf to xcom with this (in that the two bonus troopers lose access to a small item slot) which I can more than live with.

[Bertilsson]

Wouldn't it be safer from user error and easier to implement that the object has reveresed effect?

 

Soldiers for the next mission would be picked by the same algorithm as today, top down, and if player wants to make any exception from that all he/she has to do is to give soldiers that should not be available for missions an exception item. It could be called anything from latrine duty to R&R :smile:

Edited July 6, 2013 by Bertilsson

[johnnylump]

IMO I'm afraid that sounds much more complex and fraught with potential error.

 

You'd be asking players to memorize the selection algorithm and then constantly adjust to changing but unseen outputs from it that are created by the passage of time. Fine, it's a simple algorithm, but it means every time someone, say, is injured or comes off injury, is promoted, or a new rookie is hired, or goes into or out of the psi lab, they may have to be equipped or unequipped with this 'don't go' item. The player will have to repeatedly check all soldiers for it to ensure they don't go, which sounds very tedious to me. With so many troops potentially equipped with this don't-go item, it seems more likely it will accidentally be sent on a mission through player inattention to the 'main six' on the dropship screen.

 

With an equip-to-go item, you pick your 7th and 8th, and go. For the second error I mentioned, it largely requires the player to make two active and conscious mistakes: building more items than is needed, and then equipping more items than is needed. For the first, as above, it requires the player to ignore the loadouts of soldiers on the dropship screen, but there should be only two items in circulation (absent the conscious mistakes), making that error, while more impactful in a lost bonus soldier, overall less likely to occur.

 

For the third issue -- losing a small item -- it is possible this could be remedied by giving the item the 'deep pockets' perk, granting an extra small item. Then it will only impact soldiers with deep pockets, who can't benefit from it twice.

Edited July 6, 2013 by johnnylump

[Amineri]

I think the Deep Pockets perk idea on the item is a great one. As long as no armor provides more than 2 small item slots, it's not possible to go over the current limit of 3 small items.

 

Since item perks and regular perks are stored distinctly (regular perks set bit 0, item perks add/subtract from bits 1 and up), it's possible to distiniguish between Deep Pockets from item and Deep Pockets from perk, and have the number of small items slots reflect both the item and the perk (e.g. the Comms + Deep Pockets perk adds 2 small item slots, one of which is taken by the Comms item).

 

The issue with this is that an armor with 2 small items on a soldier with Deep Pockets who then equips the Comms item ends up with 4 small items, which cannot be displayed. However for later game armors with only 1 small item slot, there would be 3 small items slots, 1 of which has to be filled with the comm item.

 

As a sort of hack fix, the number of small item slots can be capped at 3.

[TheOldOne822]

you can have more small items than can be shown and use the keyboard for them. That is not the best idea but does work.

 

You can also change the hex of the 3 item mod to have items overlap a little to get 4 small items to show. I tested that and it does work.