More specifically, we are caring about mission.apsDroidLists. The other lists being reversed
doesn't have any measurable impact on the game (that I can think of).
This just affects how the Gamma-1 first transporter load is determined. Now, what should happen, is the first set of units the player sends off from Beta-end should be the ones to appears when first arriving at Gamma-1. This works perfectly when not loading saves due to how the droid lists are "added" to. Note that I will be assuming four groups (the max) were sent off in this hypothetical situation.
"Adding" to a droid list pre-pends the linked lists like so (for visual purposes):
empty = []
first group = [1]
second = [2][1]
third = [3][2][1]
fourth = [4][3][2][1]
Now, when we win Beta-end, assuming no save reloads, the game simply reverses the mission.apsDroidLists[selectedPlayer]...
[1][2][3][4]
Then finds the transporter, fills it up with the first 10 units (if that many). And this works like we would want since group 1 is now in the front. However, loading a save, the droid lists takes on an order of...
[4][3][2][1] (as represented in the save file)
and starts "adding" them back to the relevant list in function loadGame()->loadSaveDroid(..., listToAddTo) (keep in mind the pre-pending)...
[1][2][3][4]
So the list is now, effectively, already reversed. To make things complicated, we sort transporters and commanders while loading these lists. Sorting the commanders causes another issue: The commanders being sorted breaks the order of the list...
[1][2][3][4][commanders] (if commanders are present)
Then, when the player wins the mission, the game reverses the above representation of mission.apsDroidLists[selectedPlayer]...
[commanders][4][3][2][1]
And then finds the transporter and starts sucking up the first 10 units for Gamma-1. This includes every commander plus parts of group 4 (the last group sent off).
And, to put the cherry on top, you can get your original group 1 again by simply loading a save and creating another save while on the reloaded save. Thus some people might not experience this bug at all if they reloaded a few more times, or, don't put any commanders into the transporter loads, or, whatever crazy combination happens.
To fix this issue we:
- Elect not to sort commanders in the mission.apsDroidLists in loadSaveDroid() since commanders in this list don't have a group (they lose their group when embarking on a transporter).
And either:
- Save a reversed copy of mission.apsDroidLists just before we write them to file, or
- Reverse mission.apsDroidLists after we load a save at the end of a successful loadGame().
Which should fix this years old issue. Thoughts?
Below is a save that is a setup for Beta-end. Send off the transporter, turn on cheat mode, use the "let me win" cheat when offworld, and make sure to use the "biffer baker" cheat so the AI don't ruin any test results.
sub-2-8s.zip