I also fixed a few issues where the internal char array was used as a
mutable string which changed the string after it was parsed which is not
good(TM).
This also replaces all user-facing occurences of usages of name to use
the new function so that the correct, possibly translated, name is displayed
to the user.
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.
Applies the 'static' keyword to various sihp related routines. This both
makes it more clear to the developer where those routines might be used
as well as allowing the compiler to leverage that knowledge and potentially
make additional optimizations.
Signed-off-by: Peter Mitsis <[email protected]>
This assertion could be hit if the player died and the engine tried to
play a sound for the now destroyed ship. Since the existing code already
had a check for the case that the object is an observer I just added
another case for OBJ_GHOST.
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.
The code probably tried to check if the sound is available but since the
sounds vector is not long enough if the sound is not specified in the
table it would cause an out-of-bounds failure if the sound was missing
from the table. Furthermore, the current code would only have worked if
the sound was preloaded since the id is -1 until the sound is loaded for
the first time.
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.
All transformations are now handled by shaders so there is nothing
special going on in the graphics API specific code anymore. Since model
uniform buffers require access to these matrices I moved the matrix
handling out of the graphics API code.
The gun convergence code would detect if the target was within the minimum distance and move the predicted target point farther away if so, but wouldn't also alter the dist_to_aim variable to match; since predicted_target_pos is used by the autoaim code while dist_to_aim is what automatic convergence uses, this meant automatic convergence didn't respect the minimum distance at all.
Looks like this was broken in 7bb10d8408.
SND_MISSILE_START_LOAD and SND_BALLISTIC_START_LOAD (indices 33 and 200, respectively) could never actually play due to a logic error (they checked that a variable was true and the loop was on the last bank, when those conditions being met earlier in the function set that same variable to false). As far as I can tell, this broke back in 2006 with commit f300716e93.
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.
I just encountered this assertion while debugging another issue. As far
as I can tell, this can happen if the ship dies the same frame that
change_ship_class is called. Since a negative hull_strength value is a
valid value this assert is invalid. The CLAMP should ensure that the
following code still behaves as expected.
Fixes pointer access violation when docked ships warp out by moving dock_undock_all call to red_alert_delete.
It was previously thought that dock_undock_all() was supposed to be within ship_cleanup() and was safe to do so. Nope.
dock_evaluate_all_docked_objects makes the assumption that the dock_list is still valid, so if the function called by it happens to nuke the dock_list (like with ship_cleanup) then it'll work with invalid pointer values.
It was previously thought that dock_undock_all() was supposed to be within ship_cleanup() and was safe to do so. Nope.
dock_evaluate_all_docked_objects makes the assumption that the dock_list is still valid, so if the function called by it happens to nuke the dock_list (like with ship_cleanup) then it'll work with invalid pointer values.
This is a bit complicated to explain, so stick with me.
When transferring energy from shields to weapons (or vice versa), the values modified are the so-called "target deltas" rather than directly modifying the shield strength or weapon energy values. The ship_chase_shield_energy_targets() function carries out actually meeting these targets without exceeding a change of ETS_RECHARGE_RATE percent per second. At least, that's what it's supposed to do, and obviously works that way when the target delta is positive.
When the target delta is negative, however, a logic error with the conditional meant to limit the rate of change instead functions backwards; if the amount of desired change exceeds the per-frame limit, the amount of change is set to the total desired change, and if the amount of desired change is smaller than the per-frame limit, than the amount of change is the per-frame limit (even though that's more than the amount that's supposed to be drained).
Since the target delta is modified by the amount by which the value changed, this leads to an interesting consequence whereby the "extra" amount taken away is added back in the next frame... which has another interesting side-effect if the "extra" drain tried to reduce shields below 0. Namely, the shield code doesn't let it, while ship_chase_shield_energy_targets() remains blissfully unaware that the actual change was smaller than requested. So on the next frame, you spontaneously get some fraction of a percent of your shields back. Which, naturally, you can then transfer energy from to your weapons ad infinitum; the amount is small, but you can continually transfer it, so you're getting weapon energy out of nowhere.
Now, straight-up fixing the logic error would be a major retail balance change; if transferring energy from your shields to your weapons only gradually reduced your shields, instead of taking a huge chunk at the start, it would be a much safer option. Therefore, the only non-balance-changing fix is to just remove the broken conditional entirely (so that it always drains the full amount instantaneously, regardless of how big or small it is).
I've left the fixed conditional commented out so that somebody, when we're not in a feature freeze, can add an AI profile or mod table flag to restore the check, allowing for slow energy transfers.
secondary_animation_position wasn't being set by the ship_weapon constructor, which could cause potential issues with whatever uninitialized data it wound up being set to (like, say, being unable to fire any weapons in the second secondary bank until you've cycled through it once). Since it depended on uninitialized data, the behavior could even change between 32-bit and 64-bit builds (and Release/Debug, of course).
While I was at it, I also noticed some variables were getting set twice; in one instance (primary_animation_done_time), it was even being set to the wrong value the second time (according to the pre-flagset code that used memset() on it and then overrode some values that shouldn't have been zero). Not sure what problems that could've caused; possibly some issues with animations and primary weapons, I guess, if the "done" timestamp was invalid when it shouldn't have been.
* Adds a warning for debug users when an unknown ship_state is passed to red_alert_delete.
* Removes commented-out code
* Doxy's ship_cleanup()
*Conform to each file's style.
*Extend ship_cleanup to better handle red-alert deletion.
*Also treat cleanup_mode as a flagset, instead of an enum as it was previously.
* Looks like a shallow copy wasn't enough, so this fix creates ship_weapons::clear() which is called by ship_weapons's constructor and by ship::clear().
asarium