View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001967 | FSSCP | --------- | public | 2009-07-22 16:34 | 2009-11-14 18:14 |
| Reporter | chief1983 | Assigned To | Goober5000 | ||
| Priority | normal | Severity | crash | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | 3.6.11 | ||||
| Fixed in Version | 3.6.11 | ||||
| Summary | 0001967: Play 2 missions in a row with different wing names = crash | ||||
| Description | So 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 Information | Between 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. | ||||
| Tags | No tags attached. | ||||
|
|
Could you link some test missions for this? |
|
|
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. |
|
2009-07-27 18:52
|
|
|
|
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. |
|
|
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. |
|
2009-07-27 20:05
|
|
|
|
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. |
|
|
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. |
|
|
This is reproducable with retail data now, in case no one noticed and someone would like to take a stab at it. |
|
|
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. |
|
|
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? |
|
|
...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. |
|
|
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... |
|
|
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. |
|
|
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. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2009-07-22 16:34 | chief1983 | New Issue | |
| 2009-07-27 02:09 | portej05 | Note Added: 0011107 | |
| 2009-07-27 06:01 | chief1983 | Note Added: 0011109 | |
| 2009-07-27 18:52 | chief1983 | File Added: Wingnametest.fs2 | |
| 2009-07-27 18:54 | chief1983 | Note Added: 0011111 | |
| 2009-07-27 19:32 | chief1983 | Note Edited: 0011111 | |
| 2009-07-27 19:34 | chief1983 | Note Edited: 0011111 | |
| 2009-07-27 19:42 | chief1983 | Note Added: 0011112 | |
| 2009-07-27 19:42 | chief1983 | Assigned To | => chief1983 |
| 2009-07-27 19:42 | chief1983 | Status | new => closed |
| 2009-07-27 19:42 | chief1983 | Resolution | open => unable to reproduce |
| 2009-07-27 20:01 | chief1983 | File Added: Wingnametest_2.fs2 | |
| 2009-07-27 20:05 | chief1983 | File Deleted: Wingnametest_2.fs2 | |
| 2009-07-27 20:05 | chief1983 | File Added: Wingnametest_2.fs2 | |
| 2009-07-27 20:39 | chief1983 | Note Added: 0011113 | |
| 2009-07-27 20:39 | chief1983 | Status | closed => assigned |
| 2009-07-27 20:39 | chief1983 | Resolution | unable to reproduce => open |
| 2009-07-27 20:46 | chief1983 | Assigned To | chief1983 => |
| 2009-07-27 20:46 | chief1983 | Status | assigned => new |
| 2009-07-27 21:07 | chief1983 | Note Added: 0011114 | |
| 2009-11-02 22:07 | chief1983 | Note Added: 0011221 | |
| 2009-11-13 08:26 | Goober5000 | Note Added: 0011260 | |
| 2009-11-13 08:26 | Goober5000 | Assigned To | => Goober5000 |
| 2009-11-13 08:26 | Goober5000 | Status | new => resolved |
| 2009-11-13 08:26 | Goober5000 | Resolution | open => fixed |
| 2009-11-13 08:26 | Goober5000 | Fixed in Version | => 3.6.11 |
| 2009-11-13 15:41 | chief1983 | Note Added: 0011265 | |
| 2009-11-14 06:02 | Goober5000 | Note Added: 0011269 | |
| 2009-11-14 07:59 | chief1983 | Note Added: 0011271 | |
| 2009-11-14 08:05 | portej05 | Note Added: 0011272 | |
| 2009-11-14 18:14 | Goober5000 | Note Added: 0011283 |
