Add `const` to the `eval_enemy_obj_struct` struct so its values aren't inadvertently overwritten. Handle a bit of const-correctness propagation. Also add default member initialization to the struct.
A mission in Mantle caused an invalid vector access when checking whether to vaporize a ship whose ship type was -1. Turns out having "no type" is actually allowed, so I audited all `class_type` accesses throughout the code for potential -1 accesses. Most were properly checked but a few were not. A few others needed to be tweaked.
(I suspect this is something that would be on the Coverity list if it isn't already.)
* Fixup HUD for slewing
* Fix Training Message box
* Lead indicator slew
* Fix HUD Message Head
* Correctly render messages
* Fix HUD offset handling
* HUD offset never makes any sense
* Cleanup offset code
* Remove unused parameter
* Fix Talking Head in RTT mode
This initializes `mc_info` to the correct values when it is constructed, removing the need for `mc_info_init`.
This PR also fixes a group of incorrectly inverted assignments in beam.cpp.
Follow-up to #5040. This extends the checks to most iterations over `obj_used_list` in FSO. There are a few exceptions such as `waypoint_add` and `waypoint_remove`, plus a few others. And none of the object iterations in FRED have the guard because FRED does not use the same object life cycle as FSO.
When iterating through `Ship_obj_list`, check the `Should_be_dead` flag before using the object. This fixes#4990 and adds defense-in-depth checks to guard against similar errors elsewhere.
I considered moving the `Ship_obj_list` removal from `obj_delete` to `ship_cleanup`, but decided it would be prudent to avoid fundamental changes to lifecycle management.
Adds gravity! Applies on a per-mission basis, and weapons, ships, debris, and asteroids now have a configurable "gravity const" which multiplies the effect of gravity on them, by default everything except debris is 0 (meaning no effect even when the mission has gravity). AI and the lead indicator will also lead for ballistic trajectories as well, given a gravity-affected weapon. No FRED support or gravity direction control yet, to come in later PRs.
* Adds Lead Indicator Behavior option to game_settings.tbl
* Adds dont merge lead indicators flag to weapons, allowing homing secondaries to have their own lead indicators no matter what.
* Removed unused variable that was added just for testing
* add explicit int to float conversion to appease build checks
* Move some things around to avoid potentially undefined values
* Clean-up + address feedback
* Remove redundancy
1) A comprehensive fix for the is_target_dying variable
2) Also do distance correctly for non-player target brackets by adding a check that we're dealing with the target before using the current target distance. Then also calc distance if it is not the player target.
3) Update comments and checks to be consistent
Many of these did not reflect how the variable was actually used, so update the comments.
Normally, when the player cycles through targets using (for example) the hostile targeting key, the targets will be shown in order of distance. In PR #4121, this was changed from bounding-box distance to center-distance, which has very little noticeable effect on the cycle except that it now agrees with the AI strategy for measuring distance.
However, when the player targets a hostile for the first time, or when the cycle resets after 1.5 seconds have passed, the first ship targeted will be the closest ship *or* the ship with the closest turret. And furthermore, when the target cycle continues, the next ship targeted will be the next ship farther away. There can be a dramatic difference between a turret, which may be very close, and the center of the ship, which may be very far away. The target cycle will continue with these far-away ships, and this has the effect of leapfrogging any ships that are closer that should be targeted first.
There isn't any easy way to tell that a ship has been targeted because of its turret, and not because of some other targeting key or because the cycle has restarted, but fortunately the bounding-box distance is a reasonable approximation because turrets tend to be on the bounding boxes. So this commit simply restores the distance functions to what they were before. The other fixes from #4121 are not related and remain in place.
Several careful tweaks to improve handling of distance as measured on the HUD.
1) Use `Player_ai->current_target_distance` for rendered HUD gauges which display the distance, because the distance is calculated in `hud_update_frame` (which is called from `game_simulation_frame`) and is used for a couple of these gauges already. This change makes it all consistent.
1b) Some gauges which depend on distance but do not actually display it (e.g. the lead indicator) still calculate their distance immediately before using it. I didn't change these because a) the calculation is still correct, even if redundant, and b) there is a small possibility of `hud_update_frame` changing the target after the distance is calculated, so these gauges are guaranteed to have the correct calculation.
2) On discovering that the `evaluate_ship_as_closest_target` specifically switched from bbox-distance to center-distance, I changed all "target closest X" functions to consistently evaluate center-distance. I believe Volition did this to prioritize small fighters when dogfighting next to large ships.
3) Moved `hud_target_change_check` below the computation of `Player_ai->current_target_distance` because it uses the computed distance to determine the acceleration trend. This way it will use the distance of the current frame, not the previous one.
4) Minor move of a `Target_static_looping` check into `hud_target_change_check` because it made sense.
In FS2, the HUD will automatically target the first turret on any BIG or HUGE ship. In FS1, this did not happen. This adds a flag to disable the new behavior.
The change is needed because the scan view cone is significantly constrained when any turrets or subsystems are targeted. This makes Playing Judas quite a bit more difficult than it was designed to be.
For compatibility purposes some mods want alt names to truncate at the hash symbol. But we can't actually do that at mission load,
since we have to save them again in FRED. So this commit processes the names just before the mission starts.
To further complicate things, some mods actually want the hash to be displayed. So this commit introduces the double-hash as an escape sequence for a single hash.
Since instance-specific fields have been moved to polymodel_instance and submodel_instance, the gun_submodel_rotation field should also be moved. This is also reworked a bit to keeping track of the rotation via the normal submodel instance angles.
This removes an unnecessary look_at field as well.
* 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
Admiral Nelson led me to discover that the HUD gauges expected "right" or no string at all for the gauge alignment. I added basic recognition of LEFT and RIGHT alignment. Someone more familiar with the HUD than me can flesh it out more.
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.
Retail has a hud_find_target_distance function that returns the distance between the player position and a bounding box. This is useful for the HUD because it shows the distance to the perimeter of an object like a jump node or a large ship. However, this function was re-used for the `distance` SEXP, resulting in the awkward situation where the distance is measured from one ship's center to another ship's bounding box. This can lead to unexpected results and it also means that the SEXP returns a different distance when the arguments are swapped.
This PR deprecates the original SEXP and introduces the new SEXPs `center-distance` and `bbox-distance` which use consistent methods for both ships. It also renames the `distance-ship-subystem` SEXP to `center-distance-subsystem` and adds a new `bbox-distance-subsystem` SEXP.
Goober5000