Crewed=yes/no (for units with survivors) cannot be overwritten by custom game modes

[GMBigB]

Ares 0.1.995. I only tested it with jumpjet units so far. If "Crewed" is set to "no" for a jumpjet unit, it cannot be overridden by a custom game mode. There won't be any survivors if the unit gets destroyed.

The problem does not occur with buildings, no matter if I use plain YR or Ares.

##### STEPS TO REPRODUCE #####
Add the following lines to [SHAD]:
Survivor.RookiePassengerChance=100
Survivor.VeteranPassengerChance=100
Survivor.ElitePassengerChance=100
Survivor.RookiePilotChance=100
Survivor.VeteranPilotChance=100
Survivor.ElitePilotChance=100
Survivor.PilotCount=1
Survivor.Side0=E1
Survivor.Side1=E2
Survivor.Side2=INIT

Changes in [SHAD]:
Crewed=no

Create a custom game mode with just
[SHAD]
Crewed=yes

There won't be a survivor if the unit gets destroyed. The other way round (Crewed=yes in rulesmd.ini and Crewed=no in mpxxxxmd.ini) will lead to random behaviour. If you start the game the first time, there might be no survivor during the whole game, if you start the game another time, there might be a survivor.

##### ADDITIONAL INFORMATION #####
This sounds overall like a ridiculous issue, but there is more to come as soon as I figured out what exactly is going wrong. The described bug is the only thing so far which can be reproduced at any time. My actual problems are IEs when my jumpjet unit (a hind transport for the soviets) leaves the weapon factory. This happens randomly (random regarding to game starts). There is nothing wrong with the code. If it works once, it always does as long as I restart YR. Then things might have changed.

[DCoder DCoder (dcoder1337)]

This sounds like a spinoff of bug:1453.

As for IEs, uploading the crashdump would help us determine the actual causes.

[GMBigB (gmbigb)]

After further investigation, I created issue #1527 for the IE, because I am now pretty sure that it has got nothing to do with this one.

[AlexB (alexander-b)]

The tag was called "Survivor.Pilots=" and not "Survivor.PilotCount=" as the manual suggested (has been fixed already). Thus, the default value would be used, defined by the "Crewed" setting in the rulesmd.ini. Inis loaded later like game modes and maps will not change this default value. But: a Crewed=no unit would not let anybody escape, so it was possible to deactivate pilots later.

I changed it to this: the default is -1, which means, use the actual Crewed= setting ingame, not the setting defined in the ini file read first. If you keep the default, Crewed=yes means 1 Pilot. Crewed=no means 0. Any number N above 0 means N Pilots.

Likewise, the Survivor.PilotChance tags will use the latest CrewEscape= value, and not default to the value used in rulesmd.ini. Again, -1 re-enabled this default, if you want to remove a value set in rules or game modes.

Fixes only in v02 branch.

[mevitar (mevitar)]

Confirmed as working in 12.115.1265. However, not sure if intended or not, but if the unit doesn't have the Crewed=yes tag initially, then pilots won't spawn even if Survivor.Pilots and Survivor.XXXPilotChance are set to valid values in the map file
From what you wrote, i assumed that a simple Survivor.Pilots was enough, but it wasn't - i had to set Crewed to yes in the map first.

[AlexB (alexander-b)]

Thank you! If and only if the unit is Crewed=yes in the final game, (that is, an INI sets it to yes and it isn't set to no in later INIs) the game will respect the latest Survivor.Pilots and friends. Thus this is indeed intended, and Crewed= would stop working otherwise.