Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: FrikgFeek on June 05, 2017, 03:10:08 pm
-
Whenever a fighter explodes with the -fb_explosions flag set in WCSO it causes this assertion. If the -3Dshockwave flag is set it will happen only on the 2nd mission loaded or when a mission is restarted, the first run will be fine.
If the -3Dshockwave flag isn't set it will happen on the first load.
Replacing the custom shockwave assets with MediaVPs ones seems to make no difference. Removing the shockwave name entry from the ships.tbl seems to make no difference. Some help on demystifying this would be highly appreciated.
I was running On the June 5th nightly fastdebug, but this was happening on June 2 as well.
I'm attaching a debug log from the crash as well as a very simple test mission. It will, obviously, require WCSOpen.
[attachment stolen by Russian hackers]
-
TIL the entire homing shockwave code is held up with shoestrings hope and duct tape wishes, basically.
Which is to say, it isn't held up at all. Framebuffer shockwaves just... don't really work. Unless you're using 3D shockwaves, and only play one mission at a time. Or you define and use (in every mission) custom 2D shockwaves, that might also work.
Point is, my earlier fix of the shockwave code's wonky handling of vectors only fixed a specific issue and now it looks like I'll have to rewrite a significant chunk of it to fix this problem.
-
Okay, so after further investigation it turns out I overlooked that 2D shockwaves have their own code branch for using their own bitmap for the distortion, so they worked fine. It's just 3D shockwaves that cause this problem... however, even if the 3D shockwave command-line flag isn't used, custom 3D shockwaves can still be defined, and if one winds up loaded before any custom 2D shockwaves, you'd hit this assertion (because it tries to find out how many frames are in a nonexistant animation).
I've opened a PR (https://github.com/scp-fs2open/fs2open.github.com/pull/1371) to fix this problem by simply keeping track of which index the default 2D shockwave got loaded into and, equally as importantly, making sure that if both the 3D and 2D default shockwaves are loaded, the 2D one doesn't get unloaded at the end of the first mission played in a session.
-
Error seems squashed now. Thanks! :yes: