|
2011-08-01 18:40
|
|
|
2011-08-01 18:42
|
No-Ending-Debriefing.png (201,630 bytes) |
|
|
Please ignore the "0000001" and "0000002" links under the section "Effects of bug" above. They were automatically added by mantis erroneously because I numbered the bug effects with a number symbol. |
|
|
Also, look inside the "Saves.zip" for the complete logfiles. |
|
|
Also, I just noticed Mantis didn't include the steps to reproduce the bug that I gave it. So here it is again: Procedure to reproduce problem: As far as I can tell, just play through the game to the end (or load my "before" pilot) and successfully get to the node, using the 3.6.13 build on a Mac. (I don't think you need my specific OS version, graphics chip, or nightly build to reproduce). If you make it to the jump node, then a debriefing screen will display showing "No Debriefing for mission: SM3-10.fs2" and right above that in the debug build: "[name: SM3-10.fs2, mod: 08/18/09 at 13:30:00]" and the ending movies ("end game", "end game part 2a") will NOT play, and the movies will NOT be added to the list of cutscenes playable in the Tech Room. However, If you DON'T successfully make it to the jump node, then the end movie, and pilot death movie ("end game", "end game part 2b"), WILL both play and be added to the playable cutscenes (though the "end game part2a" cutscene will still NOT be played or added of course). |
|
|
Does the same thing happen with an Antipodes 8 build? |
|
|
I'm working on testing that right now. I'll let you know in a few days. |
|
2011-08-04 15:25
|
|
|
|
The same thing happens with Antipodes 8 if I use my saved pilot (from 3.6.13 at the final mission). But that also happens with 3.6.12 also (if I use my saved pilot from 3.6.13). So I don't think that test is very helpful until I can play from the beginning using a new pilot. With Antipodes 8 I wasn't able to start from a new game and play to the end, due to it making my Sidewinder Joystick go nuts (ship continuously rotates to the right uncontrollably in Antipodes 8, but not in regular 3.6.13 builds--but that's another issue). So I used my saved pilot from the regular build and played the last mission with the keyboard. But because the saved pilot from 3.6.13 seems to ALWAYS trigger the bug, regardless of the build used, it appears something may be corrupting the pilot file at some other point in the game. Once I can actually play Antipodes 8, I'll try playing through to the end. But for now, it's simply unplayable for me due to the aforementioned joystick calibration problem. I'll have to play through 3.6.12 again to be sure, but I believe the bug did NOT happen when using a clean install of 3.6.12 and starting from a new pilot. In case it's helpful, I uploaded a logfile from Antipodes 8 above (using my saved pilot from 3.6.13). Though it doesn't appear to show anything different than the 3.6.13 logfile. It seems to me that it should be at least a little easier to figure out what's causing this, considering that my saved pilot always causes the bug in a 100% repeatable and predictable manner, regardless of build (hopefully?). |
|
|
And just to be clear: Playing through to the end on the 3.6.13 builds ALWAYS causes this bug for me (at least in the Mac version). I've played through twice, using a clean install of everything, and a new pilot each time. 100% repeatable on my end. |
|
|
Well, this sounds more and more like pilot file corruption. Which is something Antipodes 8 fixes; however if you import an old pilot file (a process that _isn't guaranteed to work_), corruption may import over as well. My question was more "Can you recreate this bug using a completely new pilot file with AP8?". Sorry for not being clear. In the end, this is pretty much pointless. Noone will really look at pilot file issues with the old pilot files, because there's a replacement already on the horizon. the best option, if you encounter it, is to create a new pilot, as onerous as that may sound. |
|
|
Just for completeness sake, here is the solution to this bug (though I'm sure everyone is aware of this by now): Re-Adding the following code to the "case GS_EVENT_DEBRIEF" section of "freespace.cpp" fixes the bug completely: if (Campaign_ended_in_mission && (Game_mode & GM_CAMPAIGN_MODE) /*&& !stricmp(Campaign.filename, "freespace2")*/) { gameseq_post_event(GS_EVENT_END_CAMPAIGN); } else { gameseq_set_state(GS_STATE_DEBRIEF); } Problem is unrelated to pilot file corruption, and is caused by the lack of logic leading to a "GS_EVENT_END_CAMPAIGN" state when the player warps-out while in the jump node in the last mission. Re-adding the above code fixes the bug. Though a more elegant code solution may be preferable. |
|
|
Also, I have confirmed that this bug is still present in 3.6.14 RC4 and Antipodes. |
|
|
How did I miss this ticket? Thanks for the thorough testing. Can you compare it with retail as detailed in the other ticket? |
|
|
No problem. This bug did *not* happen in retail (or in any FSO branch before 3.6.12), as the below code was still present up until, and including, FSO branch 3.6.10--in 3.6.12 it was mistakenly commented out (in 3.6.13, the comments themselves were completely removed; so please see the "freespace.cpp" of the 3.6.12 branch for the code I'm referring to). So, just to be crystal clear: If you go to the "case GS_EVENT_DEBRIEF" section of "freespace.cpp" in the 3.6.12 branch and copy the commented-out code (see below), and then paste it into the same place in the "freespace.cpp" of the 3.6.14 RC4 branch (and un-comment it), then it will fix the bug and return the behavior of the final cutscene to the *original retail* behavior (in other words, the cutscene will work again. Right now it *never* plays under any circumstance, since the logic doesn't exist to make it play). In the "freespace.cpp" of branch 3.6.12 it says this: case GS_EVENT_DEBRIEF: // This IF block isn't needed because it's not part of the end-campaign logic. // The supernova code and end-campaign sexp handle it all. - G5K // // // did we end the campaign in the middle of a mission? // if (Campaign_ended_in_mission && (Game_mode & GM_CAMPAIGN_MODE) /*&& !stricmp(Campaign.filename, "freespace2")*/) { // gameseq_post_event(GS_EVENT_END_CAMPAIGN); // } else { // gameseq_set_state(GS_STATE_DEBRIEF); // } // gameseq_set_state(GS_STATE_DEBRIEF); //Player_multi_died_check = -1; break; So, in the 3.6.14 branch, it needs to be changed from this: case GS_EVENT_DEBRIEF: gameseq_set_state(GS_STATE_DEBRIEF); break; To this: (or to something similar/better/less-hacky, if you want): case GS_EVENT_DEBRIEF: // This IF block isn't needed because it's not part of the end-campaign logic. // The supernova code and end-campaign sexp handle it all. - G5K // Edit: Woops! Actually this IF block *IS* needed in order for the final cutscene // to play properly, and is a vital part of the final campaign logic--though a // bit of a hack that has been present from the original Volition code, // and that could probably use some improving. // Did we end the campaign in the middle of a mission? Play final "victory" cutscene. if (Campaign_ended_in_mission && (Game_mode & GM_CAMPAIGN_MODE) /*&& !stricmp(Campaign.filename, "freespace2")*/) { gameseq_post_event(GS_EVENT_END_CAMPAIGN); } else { gameseq_set_state(GS_STATE_DEBRIEF); } break; Thanks for looking into this Goober! |
|
|
One additional note regarding this bug's (2478) relationship to Mantis issue 2482: Once this bug (2478) is fixed and the cutscenes once again work like retail and *do* play for both the "good" and "bad" ending, it then causes the campaign to not be ended (just like in retail), as there is no "GS_STATE_DEBRIEF" after the cutscene finishes playing. Which then leads to the minor "bug" mentioned in 0002482 However, if the player did *not* get to the node before the supernova, and dies, and gets the "bad" ending, they may not *want* to have the campaign end and have to start over! As they probably would want to be able to play the end again and actually get to the node in time! This may be why the Volition developers left the campaign un-ended. Though that's something to be addressed in the 2482 Mantis issue. |
|
|
Okay, finally got back to looking at this. As it turns out, the code follows two different paths depending on how you leave the mission, which is what was confusing me. If you die, it goes through the normal supernova screen which worked as you would expect. But if you jump out successfully, it goes to the debriefing screen, which is where I erroneously removed code. I'm now putting the code back in. |
|
|
Marking as fixed. Thanks to jon118 and Yarn for their detective work. |
- Anonymous
