2022-08-17 15:29 EDT

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0001967FSSCP---------public2009-11-14 13:14
Assigned ToGoober5000 
Product Version3.6.11 
Target VersionFixed in Version3.6.11 
Summary0001967: Play 2 missions in a row with different wing names = crash
DescriptionSo a starting wing name, and a starting TvT wing name have to be the same. Well, they are in the missions I created this crash with. But, between the two missions, there are different wing names in use. One uses the FS normal Alpha, Beta, etc, the other uses some new FotG nomenclature since I was lazy and didn't upgrade the first one yet. But, playing one and then the other causes a crash about how the starting wing names and starting TvT wing name have to be the same. Doesn't matter which one you play first.
Additional InformationBetween missions something isn't happening to clear out that problem. This could probably lead to other bizarre behavior as well depending on what else isn't being cleared between missions. Might be the reason for the standalone crashing on a second mission load but never the first.
TagsNo tags attached.
Attached Files




portej05 (reporter)

Could you link some test missions for this?


chief1983 (administrator)

Haven't made any using retail data yet, I'll probably try. Really all it would involve though is creating a test mission with retail data with different wing names, and then playing it after a regular retail mission. That should generate the same crash.


chief1983 (administrator)

Last edited: 2009-07-27 15:34

Ok, I haven't tested if it happens with this mission (I made it in FRED on my home PC over VNC from work) but it should be similar enough to the setup causing the crash on the FotG data. Play a retail mission and this new mission back to back, I think all you need to do is enter the game and then quit out of the mission, and it should generate a crash.

Edit: I may have missed something, as I'm now having a hard time reproducing this with the FotG data I was using previously. It may have somehow been fixed since report. This last test was done with a build based on trunk 5375.

Edit2: Now that I think about it, it could be tied to the scripted main hall that loads a mission for the menu background. Will investigate.


chief1983 (administrator)

Closing until I can reproduce it again, this doesn't seem to be working now. Might have inadvertently been fixed as a side effect of recent cleanup.


chief1983 (administrator)

All right, assuming these missions work with retail FS2, the second one should generate the error when loaded after the first one. Reopening as I think I figured out how to reproduce it reliably.


chief1983 (administrator)

One more thing, this is the text of the error string:

Error: The first starting wing and the first team-versus-team wing must have the same wing name.


chief1983 (administrator)

This is reproducable with retail data now, in case no one noticed and someone would like to take a stab at it.


Goober5000 (administrator)

Argh. This isn't caused by stuff not being cleared out, but by the mission header being *parsed twice* -- once before the stuff is cleared, and once after. The mission header needs to be parsed twice because some mission load stuff depends on it, but during the first parse, the custom wing names are inconsistent.

I fixed this (in revision 5648) by moving the error check to post_process_ships_wings.


chief1983 (administrator)

Ok but then wouldn't an individual mission cause a crash? The whole gist here is that it requires loading subsequent missions. What changes in that case that causes this but when either is loaded first they operate normally?


Goober5000 (administrator)

...huh? Can you rephrase that?

If I understand you correctly, the reason that it happened in subsequent missions was that during the parse of the mission header, the custom wing names were still set up according to the previous mission.


chief1983 (administrator)

That was my hunch. portej05 and I also noticed today that the mission object is mishandled by some memset commands possibly, so there's a chance that could have been related.

So in other words though, you're saying that you moved the first parse to after the clear as well, closer to where the second one occurs? Now that I've reread that it's starting to make sense. Oddly enough I'm less sober now than I was this morning...


portej05 (reporter)

Each time the mission object was reset, the SCP_vector in it was totally nuked, which may have led to crashes - the current nightly should be tested to see if this is a contributing factor.


Goober5000 (administrator)

This particular bug has nothing to do with memset, since you'll notice I said that the mission header is parsed both before *and* after the mission is reset. It was the "before" parsing pass that triggered the error, since I was performing error checking where I wasn't supposed to do so. Moving the error checking therefore fixed it.

Try testing any build after revision 5648.

-Issue History
Date Modified Username Field Change
2009-07-22 12:34 chief1983 New Issue
2009-07-26 22:09 portej05 Note Added: 0011107
2009-07-27 02:01 chief1983 Note Added: 0011109
2009-07-27 14:52 chief1983 File Added: Wingnametest.fs2
2009-07-27 14:54 chief1983 Note Added: 0011111
2009-07-27 15:32 chief1983 Note Edited: 0011111
2009-07-27 15:34 chief1983 Note Edited: 0011111
2009-07-27 15:42 chief1983 Note Added: 0011112
2009-07-27 15:42 chief1983 Assigned To => chief1983
2009-07-27 15:42 chief1983 Status new => closed
2009-07-27 15:42 chief1983 Resolution open => unable to reproduce
2009-07-27 16:01 chief1983 File Added: Wingnametest_2.fs2
2009-07-27 16:05 chief1983 File Deleted: Wingnametest_2.fs2
2009-07-27 16:05 chief1983 File Added: Wingnametest_2.fs2
2009-07-27 16:39 chief1983 Note Added: 0011113
2009-07-27 16:39 chief1983 Status closed => assigned
2009-07-27 16:39 chief1983 Resolution unable to reproduce => open
2009-07-27 16:46 chief1983 Assigned To chief1983 =>
2009-07-27 16:46 chief1983 Status assigned => new
2009-07-27 17:07 chief1983 Note Added: 0011114
2009-11-02 17:07 chief1983 Note Added: 0011221
2009-11-13 03:26 Goober5000 Note Added: 0011260
2009-11-13 03:26 Goober5000 Assigned To => Goober5000
2009-11-13 03:26 Goober5000 Status new => resolved
2009-11-13 03:26 Goober5000 Resolution open => fixed
2009-11-13 03:26 Goober5000 Fixed in Version => 3.6.11
2009-11-13 10:41 chief1983 Note Added: 0011265
2009-11-14 01:02 Goober5000 Note Added: 0011269
2009-11-14 02:59 chief1983 Note Added: 0011271
2009-11-14 03:05 portej05 Note Added: 0011272
2009-11-14 13:14 Goober5000 Note Added: 0011283
+Issue History