* avoid undefined behavior from UNREACHABLE on reachable code paths
UNREACHABLE expands to __assume(false) / __builtin_unreachable() in
release builds, which is undefined behavior if the code is ever actually
reached. Many UNREACHABLE sites only guard against unexpected-but-
possible runtime states (values from tables, mission/save files, network
packets, scripting, or user input), so reaching them should degrade
gracefully rather than invoke UB.
Replace UNREACHABLE with Assertion(false, ...) at all such sites. It
still pops an error in debug builds, but in release it is a harmless
no-op that simply falls through to the following code. Sites that are
genuinely unreachable by local invariants (e.g. a switch over a bounded
random number) are left as UNREACHABLE.
A few converted sites had no safe fall-through -- an uninitialized read,
null dereference, or null call would have followed -- so they also get a
minimal recovery: initialize the value, guard the dereference, return
early, or skip the offending item.
Where the converted site was a simple guard of the form
if (x) { Assertion(false, ...); return; }
hoist the check onto the invariant instead:
Assertion(!x, ...);
if (x) { return; }
This states the expectation directly and shows the offending value in
the debug popup, while keeping the same graceful runtime degradation.
Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
* addendum
After consultation with Lafiel, use UNREACHABLE in situations that are effectively impossible even if not provably impossible. UNREACHABLE = "this shouldn't ever happen"; Assertion = "if this ever happens, it's a coding error". Also fix a few other sites and change a couple to Warnings.
---------
Co-authored-by: Claude Opus 4.8 (1M context) <[email protected]>
Add coverity[GLOBAL_INIT_ORDER] annotations to ~50 global variables
across 27 files. These were all analyzed and confirmed safe:
- ~48 OptionBuilder::finish() globals use a Meyers singleton
(OptionsManager::instance()), which guarantees safe init order.
Destruction is also safe due to shared_ptr ref-counting.
- 6 default-constructed container globals (vectors, maps) have no
cross-TU dependencies at construction or destruction time.
Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
Now that `snd_do_frame()` has been tightened up to specifically only adjust audio for the adjust-audio-volume sexp, the redundancy-avoiding code in `snd_set_volume()` is obsolete. So, set the sound volume immediately, even if it is a looping sound.
This is a two-for-one fix; the proper setting of volume fixes both #6504 and #6507.
Change `currentlyLoopingSoundInfos` and `currentlyLooping3dSoundInfos` from lists to maps. The data structure should keep track of the volumes currently, as opposed to historically, associated with each sound handle.
Since the map requires `util::ID` and its derivatives to be hashable, add `util::ID_Hash`.
Make some modifications to the adjust-audio-volume infrastructure:
1. Add an `aav_volume` array for ease of access to all three volume variables. Refactor `snd_adjust_audio_volume()` to use this array to avoid duplicating code.
2. Move `update_looping_sound_volumes()` to be handled in parallel with `audiostream_set_volume_all()`, and for the same reason: avoid setting the sound volume for every looping sound on every frame if the volume has not changed.
3. If the volume is to be adjusted immediately, apply the relevant changes without waiting for `snd_do_frame()` to be called on the next frame. Resolves#6291.
4. Fix some edge cases in `adjust_volume_on_frame()`.
This would crash because duplicate sounds were not being populated with the original entries. When snd_set_pos was called, the handle to the Sounds array would not be set, making our code think it was not loaded.
When game sounds were changed to allow named entries, it became possible for named entries to unexpectedly replace numbered entries. This was noticed most obviously in the ballistic rearm sound effect, which started using explosions rather than the standard rearm sound effects. This occurred because MV_Tiny and MV_Small were added into indexes 200 and 201.
To restore the original behavior, the code now prevents sound effects added via TBM from being placed into reserved indexes. The reserved indexes are instead assigned placeholders, which can subsequently be updated or left alone as the modder prefers.
This also makes the code a bit more robust including patching some sound validity checks in `gamesnd_game_sound_try_load` and `snd_load`.
When messages are distorted due to EMP effects, the voice volume should be controlled by the voice setting, not the effects setting. Fixes a bug noticed by @skdKitsune, a portion of which dates back to the original public source release.
Also, when volume is adjusted in `snd_set_volume`, make sure the correct voice volumes are used. Fixes a copy-paste bug from #5694.
* Create the ingame options game state
* Base working version of in-game options
* Cleanup + Optimization
* Localization pass
* more cleanup + documentation
* tooltips on option hover
* documentation and better inbounds check
* match case
* format strings instead of direct strings
* unused parameter
* address feedback
* localization id conflict with master
* Add this line back in
* pass the new option flags as well
* resolve xstr id conflict
The sound was passed the data from before the resampling took place so
it though it would be playing a stereo sound and rightly cause an
assertion. This fixes that by refreshing the properties after appliying
the resampling properties.
This does some refactoring to make it possible to cimpile and run FSO
without needing to link to FFmpeg. Since that eliminates support for
cutscenes or sound this is mostly useful for running a standalone server
which has no need for this anyway.
This reduces the image size of the standalone Docker image to only 20MB
and also resolves any licensing issues that might have existed.
The largest new feature is that it is now possible to include other
files into the RML by using the "include" tag. This is useful for making
markup files more modular.
Also added some more options for existing things (e.g. built-in detail
options).
This is similar to the other changes I already posted. Here the sound
instance handles are converted to their own handle type which will make
it easier to use the sound API.
This converts the previous int handles to a strongly-typed wrapper
handle which will make the API more self-documenting and will ensure
that wrongly used handles are detected at compile time.
I already found a few mistakes with these changes which I also fixed
here.
This was an issue since a lot of mods used wrong sounds and after the
FFmpeg changes the code would display a warning for those sounds by
default. This will restore the old behavior of printing the warning to
the log where it is easier to ignore if the mod does not explicitly
support 3.8.0.
This adds support for specifying multiple sounds for a single game sound
entry. The engine then selects which sound will be played based on the
strategy provided by the game data. This required a few changes to some
of the game code since previously every game sound had exactly one sound
file attached to it. The most notable change is that it is no longer
possible to determine the exact duration a sound can have so instead the
new code computes the maximum duration a sound can have and uses that
where appropriate.
This also adds support for randomizing the pitch and volume of the sound
to provide a more varied experience even if only a single sound is used.
One possible issue that exists is that the "sequential" strategy only
works globally at the moment so if two sources use the same game sound
concurrently then the two sources will share the sequence of sounds
since there is no sound instance data at the moment. That can be added
in a future change but should not present a huge issue for most
use-cases.
Visual Studio on Appveyor somehow causes deprecation error on _our_
definition of vsprintf. I have no idea why these changes introduced this
warning but I won't debug Visual Studio compiler bugs that I can't
reproduce with my Visual Studio version so I just disabled those
warnings.
This makes it easier to determine what takes the most time while loading
the mission (loading models) and how we could optimize that load time
(optimize model loading).
This is not a bug fix but it also shouldn't cause any regressions since
there are no actual code changes so this could be merged before the
release of 3.8.
@niffiwan discovered that some retail sounds trigger the newly
introduced so the warning needs to be suppressed for those few files.
See #1005 for the full discussion.
