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.
Weapon names with a `#` should not display text after that `#` in the HUD. For the most part this works, but there were a few cases this didn't (such as primaries using the weapon name). This PR fixes two spots that fell between the cracks.
Every g3_start_frame must have a matching g3_end_frame. Thus, a return
in the middle of a function after an opening g3_start_frame must make
sure to call g3_end_frame before it leaves to avoid a dangling frame
context.
As described in the bug report at
https://github.com/scp-fs2open/fs2open.github.com/issues/1827
a floating point rounding issue could be the trigger for the problem.
Removed a lot of unused functions.
This is mostly a cleanup of a prior refactoring.
There where a lot of unimplemented functions remaining from renaming.
Removed several outcommented parts of code.
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.
Goober5000