When the code checks for the existence of an audio file, be sure to check all relevant extensions.
This fixes#4495. Tested with both ST:R personas as well as the Vasudan persona.
Before setting the `MQF_CONVERT_TO_COMMAND` flag, check to make sure the conversion will succeed.
This should ensure proper behavior for any case where command-conversion is needed. I've tested it with both a message that should not be converted and a message that should, and both behave as expected.
Follow-up to #4150 and #4078. Fixes#4356.
The FS1 behavior for converting wingmen messages to Command messages specifically applies to in-mission messages with multiple files corresponding to the possible senders. There is no situation where a built-in message needs to be converted, and in fact built-in messages can't usually be substituted because most built-in messages are distinct. This commit adds an extra check for that case. It has the effect of "fixing" #4149 even though that isn't really a bug.
FS1 has a feature which will occasionally convert a wingman message to a Command message. This adds a few more checks to that feature:
1) Make the command-conversion code and the alive-check code mutually exclusive;
2) If the filename is not a FS1-style persona, don't change either a) the filename, or b) the talking head
Fixes#3759.
Implements send-message-chain as described in issue #3185. Also fixes the default argument for message priority, and mirrors the default argument fix to qtFRED.
* 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
Several things going on here:
1) refactor `get_display_string()` to `get_display_name()` to be more precise
2) likewise, refactor `alt_name` to `display_name`
3) automatically generate display names when parsing the ship, ship class, and weapon class for the first time
4) remove the on-the-fly truncation of names with hash symbols
Basically this subsumes the `end_string_at_first_hash_symbol` logic into the display name. Rather than truncate the name every time it's displayed, truncate it once when it's parsed. This takes advantage of the previous display name infrastructure, since display names are a superset of the case of truncating the hash symbol.
This also has the benefit of now allowing hash symbols within display names. When updating Destiny of Peace, I noticed that "Lockheed Shuttle #4" would no longer display properly; and it was not previously possible to fix this even with display names.
I could pull out the `get_display_string()` and `alt_name` renaming into a separate PR if desired.
From the comments:
// Do some checks to see if we are actually going to play this message at all. These checks have been moved above the
// "if ( Num_messages_playing )" block because we don't want to cancel an existing message if we have nothing to replace it with.
Additionally, by not incrementing `Num_playing_messages` if the code skips to `all_done`, this prevents messages that aren't playing from delaying messages in the queue that are actually valid and should play.
This adds an ai_profiles flag that checks comm systems for non-player ships. If their comm system is damaged, they will not send messages and you will not be able to issue squadmsg orders.
See also:
http://scp.indiegames.us/mantis/view.php?id=1947
This moves towards defining the hooks in the code module that executes
them. Also provides the API necessary for better documentation of hooks.
This only covers a few hooks as a test and demonstration of the new API.
If no issues are found with this it can be extended in the future.
MESSAGE_SOURCE_SPECIAL indicates messages whose sender starts with "#", indicating that it's not a ship; however, the code was looking up the source as a ship name regardless, and if the message had a persona set, failing to find that ship name would result in the message failing to send. Commit f67596bc5e (a.k.a. SVN revision 5383) was supposed to fix this, however it was checking if q->source was MESSAGE_SOURCE_SPECIAL when q->source was one of the HUD_SOURCE_* #defines (specifically, MESSAGE_SOURCE_SPECIAL resulted in HUD_SOURCE_TERRAN_CMD). It turned out there was an unused HUD_SOURCE_* #define which behaves identically to HUD_SOURCE_TERRAN_CMD, namely HUD_SOURCE_IMPORTANT. By making MESSAGE_SOURCE_SPECIAL use HUD_SOURCE_IMPORTANT and changing the conditional to compare q->source to HUD_SOURCE_IMPORTANT, the intent behind the original fix can be carried out with minimal effort.
This also fixes issue #1706, which is basically the same as the original mantis issue.
This maintains the type information which can be used for enforce
const-correctness and also for implementing more advanced ways of
handling the type information.
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.
The code did not account for unicode escape sequences when inserting
scrambling characters which distorted the text and fequently caused
invalid UTF-8 sequences to appear in the text. This fixes that by
using the text iterators already present in the game code. I needed to
rewrite the logic of this block a bit since the previous logic could not
be converted to the way we need to handle unicode sequences at the
moment.
This fixes#1720.
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.
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 we tell it to free up the animation, I think it should happen regardless of whether or not the HUD_TALKING_HEAD gauge is currently active or not. Also, unloading an animation shouldn't crash even if one wasn't loaded in the first place... and if it does, we should probably fix that instead of slapping a band-aid on the calling function.
Before, if any parsing call failed it would throw an exception which
would have been propagated to the exception handler in main() which
terminates the program. This should fix that.
Goober5000