Shield impact sounds now re-use the shield quadrant calculated by the collision code instead of naively recalculating based on global hitpos, allowing the hull impact sound to play if the shot pierces shields or was fired from within the shield mesh, and simplifying the relevant calculations in the process.
Adds a new "+Pulse Interval:" countermeasure field that enables the new behavior; all countermeasures that don't have this field defined still use the old behavior of the global frame counter.
This changes countermeasure logic quite a bit, but I attempted to mitigate performance implications by re-using an existing traversal of the object list in order to build the list of active countermeasures each frame. If any countermeasures are actively pulsing in a frame, the object list is traversed again, looking for homing weapons. Each homing weapon then goes through the active countermeasure list and checks to see if it got decoyed. Most of this central logic is unchanged from the old behavior, although no longer separated into two functions, and it should be more efficient since it's using a prepared list of active countermeasures instead of traversing the object list looking for countermeasures for every homing missile (which are themselves found by traversing the object list).
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.
If the descripting of a weapon is too long it would currently cause a
very unhelpful assertion message. This fixes that by checking the length
of the lines when parsing the weapon description. I removed the
assertions since the string is just cut of if it is too long so that
fixes the actual assertion.
I also added two unit tests for making sure that too long descriptions
cause warnings.
THe flagset changes misplaced the post-parsing flag processing so that
it was only executed if a special flag was found. That was not the case
previously and this restores that behavior. I also simplified the code a
bit while I was at it.
This fixes#1191.
Make sure we've got initialized values in the secondary pattern indexes
for a ship_weapon and also allow linked/dual fire to be in sequence
instead of swapping in the base weapon at the beginning of each pattern
loop.
The codebase had quite a few instances of .size() being called and then checked to see if it was 0 or not (or less than 1, or greater-than-or-equal-to 1, which are basically equivalent), when .empty() could be called instead (negated or not, depending on what the original condition was).
It was setting the Pierce_shields flag based on whether or not the Beam flag was set, rather than based on whether or not the beam flag was explicitly provided; as such, a TBM entry for a non-piercing beam that contained a "$Flags:" entry but didn't re-set "no pierce shields" could spontaneously regain its piercing status (explicitly setting "beam" again will re-add piercing, but this should match previous behavior).
Starting with git 127976c (#851), FSO fails to start, displaying an
error. This is my attempt to fix it. FSO starts, but I do not know how
to check that the flags are parsed correctly.
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.
TRBlount