In saveload/signal_sl.cpp
Code: Select all
@@ -268,6 +268,8 @@ static void DoFixups(FixupList &l, Instr
static void Load_SPRG()
{
+ _signal_programs.clear(); // Remove the skeletons of the previous loaded savegame if any.
+
uint count = ReadVLI();
for(uint i = 0; i < count; i++) {
FixupList l;
I suggest anyone that compiles the patchpack himself to add this change as soon as possible.
Thank you for the bugreport Valle ... now let's see if I remember how to push to the repo without messing things up.

Games involving speedsignals that are being loaded as first game do not affect the next loaded game as the above fix is nicked from there (comment is mine).
I mention them because they are an extention to the progsigs patch; while hthhs, for some reason, did it right the difference in code was not ported to the patchpack because I did not notice at the time of inclusion.
@Devs:
I know little about what exactly happens between loading savegames; is it normal that one has to clean up the "mess", which before was perfectly valid, from the previous savegame?
I mean is this a flaw in the design of this patch or is this just the way it is supposed to be?
Am I right in assuming (I admit, based on very little evidence) that a game is never really deleted, unless one exits OpenTTD, but is simply overwritten with new data?
I previously assumed that before loading a new savegamegame the previous game and all its data is sent to the bin by some automatic mechanism but apparently this is not true.
This issue is even reproducable if one goes to the main menu before loading a third savegame; the title game being the second. Since there is no way to save the title game at any point in time the assert can never be triggered there, eventhough the bad data is also present there (it has to be in order to crash the next loaded game).
Makes me wonder how much more data there is floating around, unnoticed because it does not trigger an assert ...