Check the filenames used to initialize HUD gauges and mark the gauge as hi-res if the filename starts with 2_. Also add a script method to return this value.
Additionally, make accessor methods `const`.
Use a single canonical `frametime` value for all HUD rendering, in both `hud_render_preprocess` and `hud_render_all`. Previously, certain functions called through `hud_render_preprocess` were using the full frametime, rather than the half frametime needed for VR when the HUD is rendered twice.
Fixes#5882.
* 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
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.
* proof of concept
* Account for shadows
* Option to tie individual HUD gauges to the cockpit option
* Do this in a more user-friendly way
* Address feedback
* Add drop shadows to HUD text
* Add drop shadow to reticle
* Add control to toggle Drop Shadows
* Double render reticle shadows
* Use gauge_color instead of creating a temp var
* Add shadows to ETS gauges
* Set shadow default to false and adjust formatting
* Restore numbering for controlsconfig
* Allow mods to change Emp flash color, intensity, and string
EMP is the only text warning that does not use an entry in the strings table (and thus it's the only text warning gauge that mods cannot change and/or translate). This PR adds a string entry for it to allow mods to translate and change the string like all other HUD gauge text warnings.
Also, EMP flash has a hard coded color and strength factor for the flash, whereas generic pain and shield pain have a configurable flash strength factor (shield pain flash is based on shield color, while generic pain is based on damage dealt). This PR also allows modders to change the strength intensity and color following previously established methods.
This PR also fixes a case of "Launch" that fell through the cracks. The function is supplied the translated string, but within the function it does not check for the translation.
Everything is tested and works as expected.
* incorporate feedback
* convert to float during parse
* incorporate more feedback
* improve safety checks
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.
1) Fix part of the lookup logic in `hud_get_default_gauge_index`
2) Add back part of the lookup that was removed in #4003
3) Use custom checks with the `default_hud_gauges` list
4) Add a clarification comment to `default_hud_gauges`
Fixes#4171
A bit of cleanup, refactoring, and bugfixing...
1) The supernova code now uses enums to represent states, and those state transitions now all happen in `supernova_process` instead of being scattered around.
2) Some state transition bugs were fixed - e.g. the HUD is now disabled when the camera cuts to the external view, instead of when the camera stops moving; and the particles start and the simulation stops when the comments say they do.
3) There is now a game_settings.tbl flag to make the HUD countdown timer reach zero when the supernova hits, instead of reaching 5s. This only affects the HUD display; actual timing is not changed.
4) Don't apply lightshafts if the supernova glare is in effect - partial fix for #4152.
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.
* Fix limitations of GetColor script function
It is very valuable for custom HUD gauges to be able to show/use the IFF color of any given object. Previous scripting solutions were limited and did not account for traitor status, varying team combinations (i.e. TvT multiplayer), and other cases.
This PR allows scripters to get the IFF color of a given object properly, as it uses the same method that retail HUD gauges use.
Also, it turns out there was already a function `hud_get_iff_color` defined in `hud.h` It was never used though, as `hud_set_iff_color` both got the color then set it. I've added the color getting to the get function and the setting to the set function, that way the script function can easily just call the `hud_get_iff_color` function. If this is undesirable I can instead copy the entire logic of the function `hud_set_iff_color` into the script section.
Tested and works as expected.
* fix nil return
* clarify param comments
Previously, the damage display gauge only showed the integrity for subsystem types. This was fine if there were a 1:1 match, with each type only having 1 subsystem. If there were more then 1 subsystem of a given type though, it would not display accurate information to the player.
This PR sets the displayed subsystem integrity to that actual specific subsystem, not the aggregate. Tested and works as expected (screenshot attached) and fixes#3982.
1) When syntax checking for hud gauges, be sure to check all gauges available because the default ship may not be the ship chosen in the player loadout.
2) Add a warning to every hud gauge check if the gauge isn't found.
3) Don't report syntax errors for hud gauges in FSO, only FRED; because every place that use a gauge will fail gracefully.
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.
This is a minor follow-up to PR #2390. There are a few minor differences between untranslated strings and the internal strings in strings.tbl; this PR fixes them.
This adds the following functions to the scripted gauge API: drawCircle, drawRect, and drawLine. Also note that I created an additional function, for HUDGauge:renderCircle_unfilled, becuase the precedent shown by having two functions for `gr_unfilled_circle` and `gr_circle` and adding a fourth argument to `renderCircle` seemed to affect a lot of other functions.
Goober5000