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().
In ship::clear(), The E removed
memset(&weapons, 0, sizeof(ship_weapon));
but did not add a corresponding
weapons = ship_weapon();
This fixes that. Additionally, this PR removes one of the two uses of ship::clear() by tweaking hud_observer_init. Originally, the code used memcpy, but if the assignment operator works for ai_info, it should be suitable for ship too.
Swaps the order of the scripting call block and the cycle-to-next-bank-if-out-of-ammo block so that e.g. "$On Weapon Fired:" scripts for a specific weapon type (which checks the currently-selected bank) will work properly when firing the last missile in the bank. Fixes issue #1091.
Upgrades and deprecates the original jettison-cargo-delay sexp by removing the unused delay parameter and adding a new parameter to control the speed of jettisoning. It further fixes the physics calculations by using the dockpoint normal instead of the vector between the center of the host ship to the center of the cargo.
See also the thread on HLP: http://www.hard-light.net/forums/index.php?topic=92844.0
Fix unlimited transfer of energy to shields (energy lost)
Fix thresholds in ai balance shields, rearm timer & call4help
Fix scaling in shield pain flash
Fix variable number of shield segments in shield pain flash
Lastly includes formatting tidy-up in shield pain flash
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.
Designed to work around issues with gunpoints on animated subsystems,
and those gunpoints being in the "triggered" position, and thus there's
lines pointing to empty space in the weapon loadout screen.
Use this to specify an alternate model that has the gunpoints in the
"correct" position.
previous_primary_bank was only getting set if the ship had a ballistic weapon or if secondary banks were changed, so previous_secondary_bank wasn't getting set at all. I fixed the second problem my simply using the correct variables, and the first problem by consolidating the ballistic and non-ballistic code so that there was less code redundancy (without that redundancy, it's unlikely the mistake would've been made in the first place); I figured this was a better solution than just copying the code to set previous_primary_bank into the non-ballistic codepath.
Also simplified the code for setting the previous weapon bank according to asarium's suggestion.
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).
Ignore_List (the list of flags used to determine if a ship is an invalid target) was originally a statically-initialized bitfield stored in an int; the new bitset flags code added a set_default_ignore_list() function to provide the default values, but then forgot to call it anywhere. As a result, "hidden-from-sensors" (and the other, less-likely-to-be-noticed flags) was having no effect on the player's ability to target anything. This adds a call to set_default_ignore_list() to ship_init() so that the original functionality is restored.
A few things I noticed while working on ai-chase-ship-class, split out into a separate PR. Some code is reordered, some is cleaned up; nothing too extensive. The most notable changes are a) the modification of the Ai_goal_text function to work on the AI_GOAL_X #define directly rather than unnecessarily calculate the bit; b) changing the HUD text of "fly to ship" to "rendezvous with" plus the ship name; c) adding a Warning in ai_update_goal_references; and d) changing ship_name to target_name in ship_return_orders for clarity
MageKing17