This adds a mission file option for ships which allows specifying a
different string which should be used for displaying the name of the
ship to the user. This name will not be used in SEXPs or other ship
lookup functions so it can be freely translated and two ships can also
have the same display name.
The new feature can be used by adding $Display name: <string> after $Name
for a ship in a mission file. I think I added proper support for FRED
(and qtFRED) so that this new value is properly saved but it would be
great if someone could test that.
This implements one of the features requested in #1730.
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 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.
This reverts commit 2aa569c1e7.
As discussed in #386 hud_squadmsg_is_target_order_valid actually doesn't properly catch cases where the target_objnum may be -1.
* Frees cpAudio pointer in VOICEREC_deinit()
* Validates that the ship/wing can actually take orders, and validates that it can take the specific order in question before trying to send it.
* Reports the confidence of the voice match if DEBUG_ON is set.
* Various commenting changes based on the patch.
Not included: using confidence to discard voice matches that fall below a certain confidence level. I haven't noticed a tendency towards spurious matches, and I didn't want to introduce this without additional data, especially when it might cause problems for people with different accents (and ESPECIALLY without a setting to tweak the threshold value, which the original patch did not have; it was hardcoded at 90%).
Could cause orders to be grayed out for the wrong ship, due to it happening to have an objnum matching the instance of the ship you were ordering.
git-svn-id: svn://svn.icculus.org/fs2open/trunk/fs2_open@11305 387891d4-d844-0410-90c0-e4c51a9137d3
These allow munitions to be attacked by the AI without needing to set the "bomb" flag; "turret interceptable" means it can be attacked by turrets, "fighter interceptable" means it can be shot down by fighters, and "interceptable" sets both flags simultaneously. Requested by Rheyah.
git-svn-id: svn://svn.icculus.org/fs2open/trunk/fs2_open@11171 387891d4-d844-0410-90c0-e4c51a9137d3
Goober5000