Bertilsson

Most of the below you probably already know but for future reference and the small chance that any of it will be helpfull to you... I use UE Explorer 1.2.4.1 to export all functions I make changes to and edit them separately in hxd before importing them back. (it is a little extra work but pays of in the end, and as bonus you can cut and paste freely in the code and easily identify and correct any resulting size mismatch, in addtion to view buffer and HxD being alligned from byte 0, not to mention that it makes using the Jump Assistant tool much easier to use... ) That way I can restore and apply mods on functional level in this kind of situation.... I guess you could do it in reverse by exporting your existing functions, and then open a backup of the upk-file and export the originals to have both versions. Then you can replace all functions (worst case) with originals and apply them one by one until you find the one causing the crash. One important thing to observe is that UE Explorer don't actually save changes to the upk.file until you exit the program (but you can import and export freely regardless and everything is updated in the tool). The most common reason for me to end up with crash is miscalculated jump offsets or forgetting to modify the header offset (decimal byte 41-44) which should always point to address of 53 token +1 If you look at a function in View Tokens mode in UE Explorer and token 53 is missing, the reason is that you have not calculated header correctly. It is easy fixed by adding ~255 bytes to current value and look in view tokens again to find correct value and add 1 to it.

yes

Download Resource Hacker Open XComGame.exe with Resource Hacker CTRL + F --> PANIC_ABDUCTION_CONTINENT_EASY Change values Press Compile Script-button File menu --> SaveEdit: And if you change SHOOT_WHEN_PANICKED=1 to 0 then you will not need toolboks.

Is there anything windows specific regarding the compression of the upk-files? If not, is there any reason why not the mac upk-files could be decompressed in windows and modded in windows using hxd and ue explorer? And is there any indication that the upk-files themselves are any different between the different mac versions? Edit: I assume that if decompress and UE Explorer can be used it would not be much more work involved in converting to mac than what may be required for windows if Enemy within turns out to be not so minor... Still a lot of work though.

I was suspecting that 8F had that function, but since terniary operations require that you declare the number of virtual memory bytes you are going to spend on each of the statements I was not very interested in testing it. But yes if works like a negation token then 1 or 2 bytes could be saved depending on if it also requires and end token or not. I just discovered a small bug related to the OTS naggers: If you buy Squad upgrade I only then the extra soldier will be correctly placed left of the existing soldiers but the remaining nagger will be put left of that. It does not affect centering at the original 6 slots, so it is really such a small bug that I will probably not try to fix it any time soon even though it is most likely a simple misplacement of m_iMaxSlots with or without +1. Edit: It was that simple. Fixed hex: F2 16 00 00 AB 1F 00 00 00 00 00 00 ED 16 00 00 00 00 00 00 00 00 00 00 F2 16 00 00 00 00 00 00 25 01 00 00 3A 1E 00 00 6F 05 00 00 B4 03 00 00 0F 00 F0 16 00 00 25 07 B6 00 96 00 F0 16 00 00 36 01 C8 16 00 00 16 14 2D 35 B9 16 00 00 C3 16 00 00 00 01 10 00 F0 16 00 00 01 C8 16 00 00 27 0F 00 EF 16 00 00 46 01 C7 16 00 00 0A 00 00 F0 16 00 00 16 14 2D 35 B8 16 00 00 C3 16 00 00 00 01 10 00 F0 16 00 00 01 C8 16 00 00 99 00 EF 16 00 00 01 C4 16 00 00 16 A5 00 F0 16 00 00 16 06 0B 00 07 48 01 19 19 19 2E B3 16 00 00 01 14 FB FF FF 0A 00 86 16 00 00 00 1B 91 0F 00 00 00 00 00 00 16 0A 00 C7 00 00 00 00 1B 1A 15 00 00 00 00 00 00 16 0C 00 D2 35 00 00 00 1B 14 05 00 00 00 00 00 00 2C 0C 16 14 2D 35 B7 16 00 00 C3 16 00 00 00 01 10 10 92 01 C4 16 00 00 26 16 01 C7 16 00 00 01 C8 16 00 00 27 06 C0 02 07 C0 02 19 19 19 2E B3 16 00 00 01 14 FB FF FF 0A 00 86 16 00 00 00 1B 91 0F 00 00 00 00 00 00 16 0A 00 A0 00 00 00 00 1B 5C 11 00 00 00 00 00 00 16 0C 00 FC 32 00 00 00 1B 0D 11 00 00 00 00 00 00 2C 0C 16 07 32 02 81 19 19 19 2E B3 16 00 00 01 14 FB FF FF 0A 00 86 16 00 00 00 1B 91 0F 00 00 00 00 00 00 16 0A 00 A8 00 00 00 00 1B F4 02 00 00 00 00 00 00 16 0C 00 54 28 00 00 00 1B 17 11 00 00 00 00 00 00 24 01 16 16 14 2D 35 B7 16 00 00 C3 16 00 00 00 01 10 10 92 01 C4 16 00 00 26 16 01 C7 16 00 00 01 C8 16 00 00 27 07 C0 02 81 19 19 19 2E B3 16 00 00 01 14 FB FF FF 0A 00 86 16 00 00 00 1B 91 0F 00 00 00 00 00 00 16 0A 00 A8 00 00 00 00 1B F4 02 00 00 00 00 00 00 16 0C 00 54 28 00 00 00 1B 17 11 00 00 00 00 00 00 24 02 16 16 14 2D 35 B7 16 00 00 C3 16 00 00 00 01 10 10 01 C4 16 00 00 01 C7 16 00 00 01 C8 16 00 00 27 0F 00 F1 16 00 00 25 07 BA 03 96 00 F1 16 00 00 36 19 19 2E B3 16 00 00 01 14 FB FF FF 0A 00 86 16 00 00 00 1B 91 0F 00 00 00 00 00 00 16 09 00 0F 23 00 00 00 01 0F 23 00 00 16 0F 00 EE 16 00 00 10 00 F1 16 00 00 19 19 2E B3 16 00 00 01 14 FB FF FF 0A 00 86 16 00 00 00 1B 91 0F 00 00 00 00 00 00 16 09 00 0F 23 00 00 00 01 0F 23 00 00 0F 10 10 35 08 17 00 00 11 17 00 00 00 00 00 EE 16 00 00 01 C7 16 00 00 01 C8 16 00 00 1C 15 17 00 00 00 EE 16 00 00 16 A5 00 F1 16 00 00 16 06 CB 02 0F 00 F0 16 00 00 25 07 62 05 96 00 F0 16 00 00 36 01 C8 16 00 00 16 0F 00 F2 16 00 00 10 00 F0 16 00 00 01 C8 16 00 00 07 54 05 2D 35 B9 16 00 00 C3 16 00 00 00 00 00 F2 16 00 00 0F 35 C2 16 00 00 C3 16 00 00 00 01 00 F2 16 00 00 1D FF FF FF FF 0F 35 BB 16 00 00 C3 16 00 00 00 01 00 F2 16 00 00 1D FF FF FF FF 0F 35 C1 16 00 00 C3 16 00 00 00 01 00 F2 16 00 00 1F 00 0F 35 C0 16 00 00 C3 16 00 00 00 01 00 F2 16 00 00 1F 00 0F 35 BF 16 00 00 C3 16 00 00 00 01 00 F2 16 00 00 1F 00 0F 35 BE 16 00 00 C3 16 00 00 00 01 00 F2 16 00 00 1F 00 0F 35 BD 16 00 00 C3 16 00 00 00 01 00 F2 16 00 00 1F 00 0F 35 BC 16 00 00 C3 16 00 00 00 01 00 F2 16 00 00 1F 00 14 2D 35 B9 16 00 00 C3 16 00 00 00 01 00 F2 16 00 00 27 0F 10 00 F0 16 00 00 01 C8 16 00 00 00 F2 16 00 00 A5 00 F0 16 00 00 16 06 C5 03 1B B1 2B 00 00 00 00 00 00 16 04 0B 53 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 00 00 00 02 01 82 00 AC 2B 00 00 00 00 00 00

Dynamic OTS nagger locations: Object Code: Hexcode: XcomStrategyGame.upk, decimal offset 2379041 F2 16 00 00 AB 1F 00 00 00 00 00 00 ED 16 00 00 00 00 00 00 00 00 00 00 F2 16 00 00 00 00 00 00 25 01 00 00 3A 1E 00 00 6F 05 00 00 B4 03 00 00 0F 00 F0 16 00 00 25 07 B6 00 96 00 F0 16 00 00 36 01 C8 16 00 00 16 14 2D 35 B9 16 00 00 C3 16 00 00 00 01 10 00 F0 16 00 00 01 C8 16 00 00 27 0F 00 EF 16 00 00 46 01 C7 16 00 00 0A 00 00 F0 16 00 00 16 14 2D 35 B8 16 00 00 C3 16 00 00 00 01 10 00 F0 16 00 00 01 C8 16 00 00 99 00 EF 16 00 00 01 C4 16 00 00 16 A5 00 F0 16 00 00 16 06 0B 00 07 48 01 19 19 19 2E B3 16 00 00 01 14 FB FF FF 0A 00 86 16 00 00 00 1B 91 0F 00 00 00 00 00 00 16 0A 00 C7 00 00 00 00 1B 1A 15 00 00 00 00 00 00 16 0C 00 D2 35 00 00 00 1B 14 05 00 00 00 00 00 00 2C 0C 16 14 2D 35 B7 16 00 00 C3 16 00 00 00 01 10 10 92 01 C4 16 00 00 26 16 01 C7 16 00 00 01 C8 16 00 00 27 06 C0 02 07 C0 02 19 19 19 2E B3 16 00 00 01 14 FB FF FF 0A 00 86 16 00 00 00 1B 91 0F 00 00 00 00 00 00 16 0A 00 A0 00 00 00 00 1B 5C 11 00 00 00 00 00 00 16 0C 00 FC 32 00 00 00 1B 0D 11 00 00 00 00 00 00 2C 0C 16 07 32 02 81 19 19 19 2E B3 16 00 00 01 14 FB FF FF 0A 00 86 16 00 00 00 1B 91 0F 00 00 00 00 00 00 16 0A 00 A8 00 00 00 00 1B F4 02 00 00 00 00 00 00 16 0C 00 54 28 00 00 00 1B 17 11 00 00 00 00 00 00 24 02 16 16 14 2D 35 B7 16 00 00 C3 16 00 00 00 01 10 10 92 01 C4 16 00 00 26 16 01 C7 16 00 00 01 C8 16 00 00 27 07 C0 02 81 19 19 19 2E B3 16 00 00 01 14 FB FF FF 0A 00 86 16 00 00 00 1B 91 0F 00 00 00 00 00 00 16 0A 00 A8 00 00 00 00 1B F4 02 00 00 00 00 00 00 16 0C 00 54 28 00 00 00 1B 17 11 00 00 00 00 00 00 24 01 16 16 14 2D 35 B7 16 00 00 C3 16 00 00 00 01 10 10 01 C4 16 00 00 01 C7 16 00 00 01 C8 16 00 00 27 0F 00 F1 16 00 00 25 07 BA 03 96 00 F1 16 00 00 36 19 19 2E B3 16 00 00 01 14 FB FF FF 0A 00 86 16 00 00 00 1B 91 0F 00 00 00 00 00 00 16 09 00 0F 23 00 00 00 01 0F 23 00 00 16 0F 00 EE 16 00 00 10 00 F1 16 00 00 19 19 2E B3 16 00 00 01 14 FB FF FF 0A 00 86 16 00 00 00 1B 91 0F 00 00 00 00 00 00 16 09 00 0F 23 00 00 00 01 0F 23 00 00 0F 10 10 35 08 17 00 00 11 17 00 00 00 00 00 EE 16 00 00 01 C7 16 00 00 01 C8 16 00 00 1C 15 17 00 00 00 EE 16 00 00 16 A5 00 F1 16 00 00 16 06 CB 02 0F 00 F0 16 00 00 25 07 62 05 96 00 F0 16 00 00 36 01 C8 16 00 00 16 0F 00 F2 16 00 00 10 00 F0 16 00 00 01 C8 16 00 00 07 54 05 2D 35 B9 16 00 00 C3 16 00 00 00 00 00 F2 16 00 00 0F 35 C2 16 00 00 C3 16 00 00 00 01 00 F2 16 00 00 1D FF FF FF FF 0F 35 BB 16 00 00 C3 16 00 00 00 01 00 F2 16 00 00 1D FF FF FF FF 0F 35 C1 16 00 00 C3 16 00 00 00 01 00 F2 16 00 00 1F 00 0F 35 C0 16 00 00 C3 16 00 00 00 01 00 F2 16 00 00 1F 00 0F 35 BF 16 00 00 C3 16 00 00 00 01 00 F2 16 00 00 1F 00 0F 35 BE 16 00 00 C3 16 00 00 00 01 00 F2 16 00 00 1F 00 0F 35 BD 16 00 00 C3 16 00 00 00 01 00 F2 16 00 00 1F 00 0F 35 BC 16 00 00 C3 16 00 00 00 01 00 F2 16 00 00 1F 00 14 2D 35 B9 16 00 00 C3 16 00 00 00 01 00 F2 16 00 00 27 0F 10 00 F0 16 00 00 01 C8 16 00 00 00 F2 16 00 00 A5 00 F0 16 00 00 16 06 C5 03 1B B1 2B 00 00 00 00 00 00 16 04 0B 53 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 00 00 00 02 01 82 00 AC 2B 00 00 00 00 00 00 The reason why I like the JumpAssistant tool: Edit: I have now tested that the dynamic OTS naggers does not cause any issues if skyranger capacity exceeds the 12 slots. No problem having 14 soldiers... The 2 without dedicated slots end up in slot0 just like before and they quantum physically share spawn locations with soldier 7 and 8 in the tactical game. So except for the missing pawns 6-11 I say this mod is pretty much complete now :D Edit humm... something is broken in the attached toolboks mod... Don't use it yet. False alarm it is working as it should and it is compatible with long war 2 beta Edit: Later code exist: http://forums.nexusmods.com/index.php?/topic/804076-rd-to-increase-squad-size/?p=8745567

I have done some testing now and as far as I can tell everything except pawns for slot 6-11 works exactly as they should :smile: And OTS naggers locations could probably be made dynamic with very little effort... And if it turns out to be effort involved I recommend getting rid of them by simply assigning them to low slot values which makes them never appear.

Broken slots repaired (by making space to put back m_iMaxSlots = kSkyranger.GetCapacity(); ) with 3 bytes to spare... 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(); tmpIndex = 6; I = 1; J0xA4: // End:0x10A [Loop If] if(I <= 12) { m_arrFillOrderIndex.AddItem(tmpIndex); tmpIndex += ((I % 2) ? 0 - I : I); ++ I; // [Loop Continue] goto J0xA4; } m_arrUIOptions.Add(12); //return; } Hex code in XComStrategyGame.upk, decimal offset 2375915 D4 16 00 00 AB 1F 00 00 00 00 00 00 CE 16 00 00 00 00 00 00 00 00 00 00 D4 16 00 00 00 00 00 00 39 00 00 00 24 07 00 00 1A 01 00 00 C5 00 00 00 1B 57 21 00 00 00 00 00 00 00 D4 16 00 00 00 D3 16 00 00 00 D2 16 00 00 4A 16 14 2D 01 C6 16 00 00 2D 00 D0 16 00 00 0F 00 CF 16 00 00 19 00 D1 16 00 00 0A 00 53 37 00 00 00 1B 8B 0E 00 00 00 00 00 00 16 0F 01 C4 16 00 00 19 00 CF 16 00 00 0A 00 E7 3D 00 00 00 1B AF 0E 00 00 00 00 00 00 16 0F 00 E5 16 00 00 2C 06 0F 00 95 16 00 00 26 07 0A 01 98 00 95 16 00 00 2C 0C 16 55 01 C7 16 00 00 03 00 00 E5 16 00 00 16 A1 00 E5 16 00 00 45 FD 00 95 16 00 00 2C 02 16 0C 00 93 25 00 95 16 00 00 16 09 00 00 95 16 00 00 16 A5 00 95 16 00 00 16 06 A4 00 54 01 C8 16 00 00 2C 0C 16 04 0B 53 0B 0B 0B 00 00 00 02 01 02 00 FC 12 00 00 00 00 00 00 Edit: Those 3 bytes could be used to make size of m_arrFillOrderIndex = m_iMaxSlots ;)

I think throwing out this line in the init function: m_iMaxSlots = kSkyranger.GetCapacity(); results in this line the updatedata function: m_arrUIOptions[iOption].bUnavailable = iDropShipIdx >= m_iMaxSlots; To use m_iMaxSlots default value = 6. Adding it back into the init function requires 29 bytes and there is currently 24 available... So I guess it is time to look into the terniary operator, since getting rid of +1 only saves 3 bytes :)

I was thinking in the lines of terniary operator but didn't want to risk introducing anything that possibly did not work the way I expected it to (I was after all trying to work around something that didn't work that way), and decided to do it as plain and low tech as I possibly could instead. But yes there is room for optimization if needed :)

Fixed it. 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(); tmpIndex = 6; I = 1; J0x7B: // End:0xED [Loop If] if(I <= 12) { m_arrFillOrderIndex.AddItem(tmpIndex); // End:0xCB if((I % 2) == 1) { tmpIndex -= I; } // End:0xDF else { tmpIndex += I; } ++ I; // [Loop Continue] goto J0x7B; } m_arrUIOptions.Add(12); //return; } Hex code in XComStrategyGame.upk, decimal offset 2375915 D4 16 00 00 AB 1F 00 00 00 00 00 00 CE 16 00 00 00 00 00 00 00 00 00 00 D4 16 00 00 00 00 00 00 39 00 00 00 24 07 00 00 FD 00 00 00 C5 00 00 00 1B 57 21 00 00 00 00 00 00 00 D4 16 00 00 00 D3 16 00 00 00 D2 16 00 00 4A 16 14 2D 01 C6 16 00 00 2D 00 D0 16 00 00 0F 00 CF 16 00 00 19 00 D1 16 00 00 0A 00 53 37 00 00 00 1B 8B 0E 00 00 00 00 00 00 16 0F 00 E5 16 00 00 2C 06 0F 00 95 16 00 00 26 07 ED 00 98 00 95 16 00 00 2C 0C 16 55 01 C7 16 00 00 03 00 00 E5 16 00 00 16 07 CB 00 9A FD 00 95 16 00 00 2C 02 16 26 16 A2 00 E5 16 00 00 00 95 16 00 00 16 06 DF 00 A1 00 E5 16 00 00 00 95 16 00 00 16 A5 00 95 16 00 00 16 06 7B 00 54 01 C8 16 00 00 2C 0C 16 04 0B 53 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 00 00 00 02 01 02 00 FC 12 00 00 00 00 00 00 With DGC.ini skyranger capacity = 10 and no OTS upgrades: Soldier pawn 0-5 is properly placed in centre before scrolling exactly above slot 3-8 and maped correctly to each slot. Slot 2 and 9 has soldiers loaded and shows OTS naggers if soldiers are cleared from them. Slot 1 and 10 has soldiers loaded but they cannot be cleared. Slot 0 and 11 are hidden (if only someone had suspected that possibilily :wink: ) So I guess next step is to get rid of the naggers in updatedata and see if they are responsible for issue with slot 1 and 10... Edit: Rewrote entire post :smile:

I+1 did not help... Will try changing order and will also test if it helps to declare tmpIndex = tmpIndex + ... and move that around a little to see what happens. Edit tmpIndex += (I * (-1 ** I)); does not make any difference result is still: [6, 5, 3, 0, <> 0-11, ...]

I have now implemented this: 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(); tmpIndex = 6; I = 1; J0xA4: // End:0x105 [Loop If] if(I <= m_iMaxSlots) { m_arrFillOrderIndex.AddItem(tmpIndex); tmpIndex += ((-1 ** I) * I); ++ I; // [Loop Continue] goto J0xA4; } m_arrUIOptions.Add(12); //return; } with the plan to modify updatedata to use presence in m_arrFillOrderIndex to determine if slot should be disabled true or false. But tmpIndex += ((-1 ** I) * I); does not seem to handle the flip flop mechanism properly... It starts of well with slot6 slot5 and then it goes starts taking jumbo steps... Edit: Perhaps it should be tmpIndex += (-1 ** (I * I)) ? Guess I'll just have to calculate them manually to see what it does... :smile: Edit2: ehrm...**( i * i) would become very large very quick so I think I can abandon that theory right away... Edit3: -1 ** i can only be -1 or +1 depending on odd or even i... And that is the same as the left part of this ((i%2)*2-1) * (i+1);.... Which I did test calculate without problems.... So I guess it can only be +1 missing... Should be simple to test.

The problem with doing it that way is that it results in at least 7 slots shown regardless of skyranger capacity. Even if skyranger capacity is 1 you will still end up with a soldier in slot 6 and you would have slot 0-5 turned into the weird empty kind where you can load soldiers that doesn't show up on mission. So it would then require some other mechanism to make sure the unused slots are either hidden or disabled...

I think I finally agreed with myself and I that this was the different wanted fillorders for each kSkyranger.GetCapacity()-scenario: 1 = [0] 2 = [1, 0] 3 = [1, 0, 2] 4 = [2, 1, 3, 0] 5 = [2, 1, 3, 0, 4] 6 = [3, 2, 4, 1, 5, 0] 7 = [3, 2, 4, 1, 5, 0, 6] 8 = [4, 3, 5, 2, 6, 1, 7, 0] 9 = [4, 3, 5, 2, 6, 1, 7, 0, 8] 10 = [5, 4, 6, 3, 7, 2, 8, 1, 9, 0] 11 = [5, 4, 6, 3, 7, 2, 8, 1, 9, 0, 10] 12 = [6, 5, 7, 4, 8, 3, 9, 2, 10, 1, 11, 0] And from that i find that kSkyranger.GetCapacity() / 2 is correct for first item in all scenarios. m_arrUIOptions.Add(kSkyranger.GetCapacity()); works in all scenarios I have tested. It results in same number of slots shown as skyrangercapacity in DGC.ini and it increase the number of available slots when OTS upgrades are bought. (The ots-naggers are never shown) I will definitively look closer into the wolframalpha suggestion later tonight.

Unless someone can figure out how to make the below code shorter in bytes it looks like we may be stuck with linear fillorder after all... 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(); iNewIndex = 0; m_iMaxSlots = kSkyranger.GetCapacity(); tmpIndex = m_iMaxSlots / 2; J0xAF: // End:0xF6 [Loop If] if(iNewIndex < m_iMaxSlots) { m_arrFillOrderIndex.AddItem(tmpIndex); tmpIndex += 1; //Only 16+1 bytes left to replace 1 with (((iNewIndex%2)*2)-1)*(iNewIndex+1) ++ iNewIndex; // [Loop Continue] goto J0xAF; } m_arrUIOptions.Add(m_iMaxSlots); //return; } Reference to iNewIndex is 5 bytes each... That leaves 7 bytes to do two multiply operations, one add operation, one minus operation and a modulus operation... So at least short term, which poison is worst? Pawns not alligned leaving first soldier in middle of the screen but belonging to slot at far right? Or soldier pawns alligned with slots placing first soldier in the right corner?

Something like this psuedo code should probably do the trick: ignoreCounter = 0 foreach GetWorldInfo().AllActors(class'XGUnit', kUnit) { if(kUnit.RoomLocation == 1) { ++ ignoreCounter if (ignoreCounter > 5) { kUnit.xlocation = kUnit.xlocation - someoffsetvalue } } } However I am not even close to translating that into something real, so in the end it is a safe bet I won't be the one doing it :)

I think that replacing Unit6 with Unit0, Unit7 with Unit1... in SeqEvent_HQUnits.AddUnit will have that result. It should be relatively easy to test... I will do that after fixing the fillorder tonight. Edit: But putting soldiers on top of each other isn't really desirable until someone figures out how to offset them from that location. Edit2: And on second thought, addUnit is probably never fed slot ID's above 5 so it will probably never reach case 6 where unit6 is assigned... So well... somewhere earlier in the chain is probably a better choice... Getting them on screen is in any case not a big problem, placing them outside the fixed locations is...

Urrhh.... Did not notice anything shiv specific related to this so, yes, I'm going to assume they are treated like any soldier until it turns out different :)

Well, sort of got it, I still had a few miles to go before figuring out the correct values for odd capacity numbers which must be this: :smile: 1 = [0]2 = [1, 0]3 = [1, 0, 2]4 = [2, 1, 3, 0]5 = [2, 1, 3, 0, 4]6 = [3, 2, 4, 1, 5, 0]7 = [3, 2, 4, 1, 5, 0, 6]8 = [4, 3, 5, 2, 6, 1, 7, 0]9 = [4, 3, 5, 2, 6, 1, 7, 0, 8]10 = [5, 4, 6, 3, 7, 2, 8, 1, 9, 0]11 = [5, 4, 6, 3, 7, 2, 8, 1, 9, 0, 10]12 = [6, 5, 7, 4, 8, 3, 9, 2, 10, 1, 11, 0]

Did some testing and finally got it. XMarksTheSpot was correct all the time. As long as the fill-order array is only populated with existing slotnumbers there is no problem. And if implemented the way he suggested to begin with then that will always be true. On skyranger capacity = 6 it will populate 0-5 slots like vanilla. On skyranger capacity = 8 it will populate 0-7 slots with 2 pawnless in slot 7 and 0. On skyranger capacity = 10 it will populate 0-9 slots with 4 pawnless in slot 9,0 and slot 8,1 And this would be the fillorder each skyranger max capacity: 1 = [0] 2 = [1, 0] 3 = [1, 2, 0] 4 = [2, 1, 3, 0] 5 = [2, 3, 1, 4, 0] 6 = [3, 2, 4, 1, 5, 0] 7 = [3, 4, 2, 5, 1, 6, 0] 8 = [4, 3, 5, 2, 6, 1, 7, 0] 9 = [4, 5, 3, 6, 2, 7, 1, 8, 0]10 = [5, 4, 6, 3, 7, 2, 8, 1, 9, 0]11 = [5, 6, 4, 7, 3, 8, 2, 9, 1, 10, 0]12 = [6, 5, 7, 4, 8, 3, 9, 2, 10, 1, 11, 0] And... no I still got it wrong for the odd max capacity where second soldier would end up on the left side of the first instead of the right side...

Definitively worth doing as plan B when you get tired of waiting for me to fix the upk or if we simply never get to an agreement about what would be right :D

Did you try this experiment? http://forums.nexusmods.com/index.php?/topic/804076-rd-to-increase-squad-size/?p=8670598 I'm not trying to be stubborn intentionally, even if that often is the result... :smile: Edit: I suspect that it seems to work but on closer examination places the topmost on-mission-soldier in the barracks in the rightmost slot... But I promise I will do additional testing tomorrow and if you are correct I will stop being stubborn about it :smile: Oh wait, no it should place the first soldier in the first available pawn location which will then be shared by an additional soldier I think... defintively need to sleep :tongue: The results from my previous testing was posted here: http://forums.nexusmods.com/index.php?/topic/804076-rd-to-increase-squad-size/?p=8683951

I thought about that idea as well, but I assume it is ten times more difficult to implement there than in the upk... I don't think it should be to hard to implement any of the fillorders discussed... The main issue was that I was confused about what to implement. Edit: And what implications it would have on scalability. Edit2: I will most likely aim to implement this one tomorrow as it seems to be meeting all goals: [3, 2, 4, 1, 5, 0, 6, 7, 8, 9, 10, 11], however it will most likely also require that m_arrUIOptions.Add(m_iMaxSlots) respects whether OTS upgrades have been bought or not with skyranger capacity = 4 (which I will be more certain about after sleeping on it :smile: )

Yes in linear fillorder it works because soldier 0-5 ends up in slot 0-5. But if that was not true then I am pretty sure we would end up in the scenario I described, so yes I agree that the first six soldiers need to be in the first six slots, which will not happen if we make the fillorder like this: [6, 5, 7, 4, 8, 3, 9, 2, 10, 1, 11, 0]. I have also made a small test the pawnlocations can be swaped around in SeqEvent_HQUnits.AddUnit, so as soon as a fill order has been decided it is a simple matter of re-aligning the pawnlocations so that the soldier in slot 0 is shown above slot zero (when scrolled max right). the fill-order I think would be easiest to implement would be: [3, 2, 1, 0, 4, 5, 6, 7, 8, 9, 10, 11] as it would be one reversed loop 3 to 0 followed by a normal loop 4 to 11. The most correct that would require no re-mapping of the pawns would be: [3, 2, 4, 1, 5, 0, 6, 7, 8, 9, 10, 11] And if someone figures out how to actually add additional pawnlocations then [6, 5, 7, 4, 8, 3, 9, 2, 10, 1, 11, 0] would be the best one.