The warning fired for any 3D shockwave model without a glow map, but it turns out that situation is fine. Drop the warning along with the cmdline include it required.
Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
Check each 3D shockwave model when it is loaded and warn if none of its textures has a glow map. The check is skipped when glow maps are disabled, since they are not loaded then.
Co-authored-by: Claude Opus 5 (1M context) <[email protected]>
A 3D shockwave's glow map already takes its frame from the shockwave's
elapsed time so the animation spans the shockwave's life. Do the same
for an animated base texture, and skip the radius fade for it, since the
artist's frames then control the brightness the way they do for the glow.
A static base texture still fades with the radius.
Co-Authored-By: Claude Fable 5.1 <[email protected]>
* Fix two shockwave bugs
Bug:
Ship and SEXP created shockwaves with 0 speed last forever. A shockwave speed <= 0 is an "instant" shockwave, but the speed is used as a denominator for total_time. Dividing by 0 that creates in infinite shockwave (frozen at its initial radius of 1.0).
Fix:
Thus, add a safeguard to protect against the infinite duration. Note, ship-death and sexp shockwave run shockwave straight to shockwave_create(), whereas weapon shockwaves run weapon_do_area_effect() if <= 0 speed.
Bug:
It is possible the shockwave may have lifetime shorter than one frame (e.g. high speed, small radius), which by default results in shockwave applying no damage.
Fix:
Provide optional fix to ensure shockwave is not killed until after this frame's damage pass has run.
Tested and work as expected.
* just the 1expire fix
* comment cleanup
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]>
This makes it so that the "3D"/"2D" display is actually respected in the in-game options menu, rather than just having an ambiguous checkbox labelled "Shockwaves".
* 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 general expectation is that model filenames can be specified as 'none' or '<none>' for no model, but as discovered by no tea, this was not consistent across the code base. For example, `$Model File: none` was handled as expected but `$External Model File: none` was not. This PR makes the handling consistent for all ship, weapon, and shockwave POF files, and also adds some extra checks when models are loaded.
For certain calculations involving armor, the `GetDamage` function needs to know if the damage is being applied by a beam so it can apply the calculations with the proper frametime. The parameter was not provided in all cases, so this fixes that.
Follow-up to #1609.
Follow-up to #5040. This extends the checks to most iterations over `obj_used_list` in FSO. There are a few exceptions such as `waypoint_add` and `waypoint_remove`, plus a few others. And none of the object iterations in FRED have the guard because FRED does not use the same object life cycle as FSO.
* Add Option to allow weapons that hit player to place per-weapon sound
Weapons that lasers or missiles that hit the player also play a hard coded sound, which is not ideal when trying to give valuable audio feedback to player.
This PR allows modders to stop the behavior and have the weapon class impact sound specified in the weapons table play instead of the hard coded sounds.
Tested and works as expected.
* add per class shockwave and weapon sounds
* naming update
There is a bit of code that detonates a missile if it misses impacting on a subsystem. On Nyctaeus's Arachnas model, missiles could reach the center point of the main beam turret submodel without actually hitting any part of the submodel. The fail-safe code would set the missile to detonate in that case, but on low-FPS systems the weapon would be able to actually hit the turret before it detonated. On high-FPS systems, there is a clean miss.
This reworks the code to delay the missile detonation until it reaches the other side of the submodel, so it has time to hit some other part of it. It also reduces the detonation time from 1/100 of a second (which is more than one frame on 120 FPS systems) to 1/1000 of a second (which is always less than one frame).
* Prevent Crashes from Weapons being deleted during the collision process
This puts in some safety checks to keep FSO from crashing while doing collision detection when close to the object limit.
* Remove Problematic Assertions and INT3's
Keeps FSO from crashing when low on Object slots from failed weapon and beam creations.
* Simplify Code with a good suggestion
Co-authored-by: Asteroth <[email protected]>
Co-authored-by: Asteroth <[email protected]>
Fixes 2526 by making the array a vector and also adds a Shockwaves always damage bombs game_setting.tbl setting and a Shockwaves_consistently_apply_damage game_settings.tbl setting. The second one keeps bombs and asteroids from being hit more than once by shockwaves, like ships do!
This is a system for storing arbitrary data in the config file and then
easily retrieving it later on. This has full Lua support for exposing
the available options in a custom UI and changing the values of the
options. This ported some of the existing command line options over to
the new system which is opt-in for the moment by using a mod_table flag.
This adds a new class which allows to create type safe resource handle
types. At the moment, the engine uses ints pretty much everywhere for
providing handles to resources created by the specific subsystems. Since
all ints are the same to the C/C++ typesystem it is perfectly legal to
pass a sound handle to the graphics API as a buffer handle which will
obviously cause issues.
This adds a new type called "ID" which is a wrapper class for a generic
handle but with added type safety. An instance of this class cannot be
passed to a function expecting another type of handle which provided
compile-time type safety for these APIs.
As an initial test I converted the game sound handles to this new type.
I already found a bug in the mainhall system thanks to this new type.
The mainhall used the game sound handles as sound instance handles which
probably meant that that specific code never really worked right. I
removed the code since there was no better alternative for fixing it.
If framebuffer shockwaves were enabled and a 3D shockwave was created, FSO would use a hardcoded reference to the second slot of the Shockwave_info vector to generate the framebuffer shockwave for it. This only makes sense if and only if:
- the 3D shockwave command-line flag is also enabled
- the default 3D shockwave and default 2D shockwave are both present and loaded
- its the first mission of the session (because after that any shockwave not in the 0th index got unloaded)
I've changed the code so that which index the default 2D shockwave got loaded into gets tracked and used instead of a hardcoded index... and if both default shockwaves are loaded, the first two Shockwave_info indices are both kept between missions instead of just the first. This should allow framebuffer shockwaves to work with 3D shockwaves, regardless of whether or not it's the first mission of the session and whether or not a custom 2D shockwave was loaded (and happened to wind up at index 1). Slight downside in that missing the default 2D shockwave file, but having a custom 2D shockwave loaded, will now result in framebuffer shockwaves not being drawn at all, rather than using the custom 2D shockwave by accident; not sure that's really all that much of a problem, though.
After someone tripped an assertion in the shockwave code which provided no details, I found some... questionable vector-related code. I changed all the code I could find that looped through the vector with iterator-based code, converted most Asserts into Assertions for more informative debugging, and added a couple Assertions to check previously-unchecked assumptions (which theoretically should never be tripped, but we'll see). A test build with the vector fixes resulted in the assertion no longer tripping so I'm fairly sure the improper erasure of the vector was causing problems (leftover data from a previous mission with a model number that no longer made sense because the model was unloaded).
