Does this cover bugfixes made as of April 7?chief1983 already linked you to the list of commits in the 3.7.4 branch, but in general here's the goal with release branches: bugfixes (especially for crashing bugs) get backported; new features do not. Anything in between is going to be considered on an individual basis, but generally leaning towards "don't backport"; the idea is to keep the branch as stable as possible.
I'm trying to learn all this terminology, what do you mean by 'backporting'?The main branch is the master branch; it's what nightly builds get built off of. 3.7.4 has its own branch; since they're separate branches, commits to master don't affect the 3.7.4 branch in any way. So if a bugfix gets merged, it needs to be separately ported "backwards" to the 3.7.4 branch (current master/nightly builds are 3.7.5).
ERROR: 00005.fs2(line 57):
Error: A file name was expected but no name was supplied!
File: parselo.cpp
Line: 331
Int3(): From c:\code\fs2_open_3_7_4_rc2\code\globalincs\windebug.cpp at line 1260
$Ani Filename:
Add validation when parsing a file specBad data (i.e. data provided by a modder/FREDer that doesn't actually make sense for the engine to attempt to do anything with) should never trigger an assertion; that's why the error message was introduced. In this particular case, however, the relevant code already tests for an empty filename string and handles it accordingly, so the error is just breaking working missions (which we try not to do if we can avoid it). It might, in this case, have been better to fix the specific kind of empty file name problem Taranis found rather than generating an error every time a filename is expected but not provided; unfortunately, there's no mention of what the assertion was in the commit or PR description.
This issue was spotted by Taranis who encountered an assertion caused by
an empty file name. This check will make sure that every string parsed
as a file name will at least contain one character.
It might, in this case, have been better to fix the specific kind of empty file name problem Taranis found rather than generating an error every time a filename is expected but not provided; unfortunately, there's no mention of what the assertion was in the commit or PR description.
I think most of the conversation happened in IRC. The assertions in fictionviewer.cpp don't look familiar but the actual assertion may have happened outside of the fiction viewer code. I think the assertion happened somewhere in cfile where the filename was checked for the first time. I'm fine with changing the code so an empty string is a valid filename but if FRED writes missions with invalid filenames that also needs to be fixed.Well, that's the odd thing; as far as I can tell, FRED has always defaulted ani_filename to "<default>", so it would seem that... a nonzero number of FREDers are manually erasing that for whatever reason. Unless all of these missions happen to be contained within the two campaigns Lykurgos88 mentioned (in which case it might be less effort to just fix those missions and call it a day), it would seem we need to continue to support those missions that are otherwise perfectly fine.
@AdmiralRalwood
Thanks for the clear-up!
There are actually a couple of other (somewhat longstanding) bugs that I'm trying to reproduce with RC2, but one of them is actually presented in a mission that is now blocked because of this "filename" check. So is there a possibility for a RC3 before final release?
The bug is related to in-game event where player is using joystick and is suddenly denied of any input --> ship starts turning around slowly instead of staying still like it was supposed to in older FSO builds. I will try to get a more specific description and examples when I get a chance. (note that the joystick is perfectly calibrated in this case and doesn't make any twitch movements on its own)
Another potential bug that comes to my mind is how the optional framebuffer shockwaves react with FS1 explosions. Unlike with FS2 explosions which seem to work nicely, the FS1 era shockwave explosions can cause microlag and nasty looking square shaped distortions. Even the background nebulas can get 2 second long color changes, which never happens with FS2 shockwaves.
I will try to remember all the other oddities as well that I have encountered and post them here in the following days. ;7