When running a mod on non-windows, that isn't packed into VP files, the
mod can break when loading. On non-windows filesystems, the file
order isn't guaranteed to be alphabetical (but it is on Windows).
As a result, we load tables in an effectively random order.
Lots of mods rely on the filesystem ordering to e.g. implement a very
loose dependency system for their lua scripts.
Referenced on the forum here:
https://www.hard-light.net/forums/index.php?topic=95750.msg1885275#msg1885275
Here's a log from Solaris failing to run:
https://fsnebula.org/log/5d7b4414cb0d332b466b5ee2#True-138
Instead, always sort filesystem listing by name *before* applying the
provided sort order.
I've built a few different versions of this patch, and like this one the
best. The other ones I tried:
1. Adding a `CF_SORT_REVERSE_NAME` and using it everywhere that
`CF_SORT_REVERSE` is used, and replacing all uses of `CF_SORT_NONE` with
`CF_SORT_NAME`. I didn't like this as it was a much larger diff.
2. Adding a `CF_SORT_REVERSE_NAME` to the `scripting.cpp` call for
loading tables. I didn't like this one because this bug can in theory
impact non scripting tables.
Here's a log from Solaris working with the new build:
https://fsnebula.org/log/5d7b4f37cb0d332b3d6b5ed3#True-138
While it might be a reasonable enhancement in the future to build a proper dependency system for lua scripts and tables,
this is a much smaller and easier change, and doesn't require any work from modders.
As per the discussion in https://github.com/scp-fs2open/fs2open.github.com/issues/2092,
if you specify the turn time, these can behave quite weirdly.
Some mods that we don't want to break backwards compatability with use
that mode, but at least we can note the pitfalls in help.
Not sure why we didn't catch this earlier but this should hopefully fix
the crash. The cause was that we constructed an SCP_string from a null
pointer instead of using the empty string as the default.
This will write Mini dumps in the event that the executable causes a
crash. This will allow us to take a closer look at any crashes without
having to reproduce them.
This re-implements the eval_nums function to use C varargs, instead of C++11 template parameter packs. This is necessary because Visual Studio has a bug where template parameter packs corrupt heap memory somehow.
"Cloning" failure was actually being caused by the pilot verification function resetting all pilot info and then not loading controls from the file to replace them.
The Control_Config array would all be set to -1 and then would get written into the file the next time the player was saved, making it seem that the controls were not being copied.
The original and current code would reset controls to defaults when a pilot was created. And it would just let the old controls remain in case of a clone. The above problem would occur just as you hit accept on the bottom of the baracks screen.
Original behavior in Fred was accidentally removed when upgrading the FSO mission parser to keep it from crashing FSO from a bad sexp. But returning false is only necessary in FSO since in FRED, we can fix the error once we know about it.
NaN should propagate through the SEXP tree, but not all SEXPs do this properly. The problem was made worse after I introducted `eval_num()` which silently ignored NaN values. This commit adds new boolean arguments to `eval_num()` to flag NaN results, and changes all calls of `eval_num()` to properly handle the new arguments. Additionally, this adds `eval_nums()` and `eval_array()` functions to more smoothly handle cases where many numbers appear in a row.
Extremely rare bug caused by use of multiple protect from weapon flags. One of the Ai-Turret functions was setting only one of the flags because "else if" was typed instead of "if".
Lab_selected_index must remain unchanged until labviewer_change_model is
called. There the variable is used to determine if a new ship must be
created and updated afterwards.
Goober5000