A follow-up of sorts to #2801, but independent of it. If a directive line is not split, the HUD should handle it properly rather than Asserting and displaying the same line twice.
* Fix underline length calculation in message scrollback
* Use SCP_string for message source (which allows ships with long display names to work without crashing) and message text
* Upgrade assorted functions to work with SCP_string
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 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.
If an event with a directive contains both an is-destroyed/is-destroyed-delay for a wing with multiple waves AND the event's Sexp_useful_number is 0 (either the event contains an "is-event-*" SEXP (or one of the "-delay" ones with the optional third argument not set), and that SEXP didn't return true, or some part of the event evaluated to SEXP_CANT_EVAL) AND the wing currently has 0 ships in the mission (so Directive_count gets set to DIRECTIVE_WING_ZERO to mark the directive as being "temporarily" true, until the next wave arrives), then the directive winds up in the list of displayed directives without actually having a born_on_date set, so it fails this assertion. Since this is caused by the data supplied (in the mission) rather than a coding mistake, and since this assertion doesn't actually seem to be guarding against anything (because nothing bad happens if the comparison happens anyway, just with a born_on_date of 0), and it behaves just fine in Release builds where the assertion isn't checked, the simplest solution would seem to be to just remove the assertions altogether.
Found this issue while testing with demo data, so blame whatever Canadian wrote the first demo mission to make the "Destroy Libra" event check for either Libra being destroyed OR an event (that can't ever become true until after at least one wave of Libra gets destroyed) becoming true.
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.
Goober5000