* Allow mods to set threshold at which shield stops taking damage
FSO logic dictates that shields collisions and any related sound or visuals related to shields are skipped if the shields are under 10%. This is rather unintuitive especially for mods, so this PR creates a game setting value that allows mods to set this value.
Also, this PR fixes a bug where the HUD shield gauge would try and incorporate this feature but did not do it correctly. Specifically, the gauge skips shield segment rendering if the raw shield strength was 0.1 not the percent. Incorrectly using the raw value results in HUD shields being rendered (albeit faintly) even if the damage was skipping the shield and directly damaging the hull. In other words, if the shield segment was 8%, the shield segment would show faintly even the shield is skipping damage.
Tested and works as expected. Also happy to discuss or answer any questions!
* update local variable name for clarity
* rename `ship_quadrant_shield_strength`
* cleanup with updated get percent function
* more cleanup
* wording and safety tuning
* use correct default number
* One fix and one enhancement to AI shield behavior
This PR adds one fix and one enhancement to AI shield behavior.
1) Fix: Testing, especially in FotG, revealed an edge-case bug with shield management where the AI will not direct shield energy to a quadrant if it was hit when that quadrant was down. In other words, if a shield quadrant is knocked down to 0 and continues to be shot the AI will not realize it needs to direct energy to that quadrant. This is because `quadrant` is set to -1 if a shield segment is down. This ensures that the resulting effects and damage calculations properly ignore that quadrant downstream, but it also results in `aip->last_hit_quadrant` being set to -1. This PR adds a fix to properly record which shield was actually hit, so that the AI knows to direct energy to that quadrant.
2) Enhancement: In combat situations with fire coming from many directions, it is good practice to keep shields equalized, so this PR adds a flag for the AI to always attempt to balance shields, even if it is being fired upon (instead of the current behavior to always direct energy to the hit shield quadrant).
Both flags are tested and work as expected.
* fix copy paste
* rename to avoid previous confusion
* also make as ai class flag
Remove the `n_quadrants` field because it is entirely redundant to the size of `shield_quadrant`. Also, be more rigorous about the difference between `shield_get_quad(i)` (which can fluctuate) and `shield_quadrant[i]` (which gives the exact quadrant strength). Finally add some C++ casts and move some checks to better places.
There is a rather large design flaw in FreeSpace debriefings... debriefing SEXPs can refer to in-mission ship data, while all ships (and all objects) are deleted as soon as the mission completes. Specifically, `obj_delete()` is called which sets all objects to `OBJ_NONE` and marks them as freed, although the data still exists in the various arrays. This is the use-after-free problem, but applied to the in-game object system, rather than memory accessed by pointers.
It's probably best to defer fixes to an as-needed basis. As for hitpoint SEXPs, this change updates them to use the object and ship references from the ship registry, since the ship registry is not cleared by the time the debriefing is loaded. (Using `objp->instance` and `shipp->objnum` at this point would be problematic.) Since subsystems are also cleared at this point, this also updates the warning messages in those functions.
Fixes an Assert seen in debug mode in Inferno.
This advances the versions for Clang to 16 and GCC to 13 along with
fixing any warnings these new versions are detecting now.
The new image versions also include Vulkan so the additional workflow
step for installing that is not necessary anymore.
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.
A conditional originally added to shield_add_strength() to make shields not recharge beyond the recharge limit forgot to check that the amount shields are changing by was positive (unlike a couple other conditionals added/modified around the same time), so a call to shield_add_strength() with a negative delta (e.g. when transferring energy from shields to weapons) when the current shield strength is at or above the recharge limit (i.e. full strength when a recharge limit isn't specified) would immediately return without doing anything. This would, of course, result in no change to shield strength... so if you had full shields and had drained your weapon batteries dry, you could get free energy by hitting the button to transfer energy from your shields.
This introduces a new mechanism for handling bit flags. Instead of using an int (or two, or three) to write bits into, this uses the std::bitset in a wrapper class that accepts an enum class as input. This means that certain classes of errors we've had a few of in the engine, where a coder used the wrong set of flags or checked them against the wrong variable (SF_STEALTH vs SIF_STEALTH, for example) can now be detected at a compiler level rather than not at all.
wookieejedi