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.
Bombs can give points for being shot down. This was being handled by a full-blown pair of damage_ship/damage_ship_id arrays, just like ships have for scoring purposes. This is ridiculous overkill when most bombs are shot down with a single pull of the trigger and means we were storing a couple hundred bytes of data that would be completely unused for the vast majority of projectiles. Now, whoever shoots down a bomb gets the points for it; period. Simple, and we can remove all scoring data from the weapon struct.
This seems preferable to storing an entire mc_info object on every weapon, when the vast majority of projectiles (by the very nature of the fact that they still exist) won't have collided with anything.
On the other hand, I'm not wild about allocating and freeing memory every time a weapon collides with a ship or debris. If anyone has a better solution, I'm all ears.
asarium