Per dicussion on Discord and and Github, `set-object-position` does not work properly and the fix would involve making it act the same way as `ship-maneuver`. With discussions with Goober (who originally made it), we have decided to deprecate the sexp. I have talked with folks who have used it thus I am not removing it from FRED with this PR but I am open to discussion on that point.
Set-secondary-weapon and set-secondary-ammo have been up to know been allowed to exceed tabled cargo sizes, as long as you didn't put a value for requested_ammo in the sexp.
The limits would be inherited from the last secondary weapon in the slot, definitely not idea behavior.
Now includes matching changes to set-primary-ammo
The default fade argument is `true`, as specified by the sexp help, not false. This probably doesn't matter here as the multi packet should receive all sexp arguments anyway, but better to be consistent.
Enhances play-sound-from-file, etc. to allow more than one audio stream to be played at the same time, provided all stream are referenced by audio handles contained in variables.
This bug has been around since the original public source code release!
The error message character calculation did not agree with the actual error check. This PR fixes that. Thanks to Novachen on Discord for discovering this.
The grant-medal and was-medal-granted sexps will now translate medal names, in the same way that tech-add-intel-xstr translates intel entries. There is also some minor cleanup and the specifying of correct default -1 numbers for the xstr-capable sexps.
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.
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.
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.
wookieejedi