This is an actual edge case bug. If no countermeasure was set, and then one was set, there might be a garbage timestamp set that would give an incorrect countermeasure delay on next use.
For coverity 1093612, this function *should* never return zero, but it is no catastrophic if it does. Allowing it to return a negative value in some unknown edge case would allow it to clobber some other global data.
So now add a check for negative values and take no action if those negative values are reached. Assert on debug.
A mission in Mantle caused an invalid vector access when checking whether to vaporize a ship whose ship type was -1. Turns out having "no type" is actually allowed, so I audited all `class_type` accesses throughout the code for potential -1 accesses. Most were properly checked but a few were not. A few others needed to be tweaked.
(I suspect this is something that would be on the Coverity list if it isn't already.)
Yes. I know, I know, we're not going to use this code anymore. But just in case, I don't want this memory leak to have the possibility to exist in the future.
* Add Game Option to refresh selected weapon in loadout
This PR adds an option to always ensure the viewed weapon is one that can actually be on the selected ship when first clicking on the weapon loadout.
If you go to the loadout in the briefing and view the weapons on your ship, then go and change your ship class and go back to the weapon loadout screen, you will see that the weapon shown in the window on the right side is from your very first viewing before you changed your ship class. Displaying a weapon not allowed on a ship by default can be confusing to players, especially on mods like FotG where most ships have unique weapons.
The player can still of course click on a non-allowed weapon to view it, but with this PR the player will be initially shown a selected weapon that is allowed on the ship when opening the loadout editor.
Tested and works as expected.
* update order to be near weapon bools
The code has always checked a per-weapon-class value called `lock_fov` when comparing the dot product of a ship to its target to see if it can lock on to it, however the weapon table hasn't ever included a way to set this value; it's always the default value of 0.85. This just adds "+Lock FOV:" entries to aspect/javelin homing missile parsing after "+Seeker Strength:", which will set `lock_fov` as long as the supplied input is between 0 and 360 degrees.
These functions have not been called from what I can tell since the source code was released. But they did happen to trigger a clang warning, so it's time to get rid of them.
* Add stage notes feature for mission messages
* don't keep notes outside the mission editor
* use F_MULTITEXT and do lcl_replacements
* this should be multitext too
The fix in #5578 assumed that a previously playing soundtrack would properly set the timestamp, but if no soundtrack was previously played at all, this wouldn't happen. So if we deliberately don't play a soundtrack, be sure to set the timestamp as if `event_music_do_frame()` had been called.
Fixes#5705.
John Fernandez