* take a model reference when a ship changes class
ship_model_change() only loaded the model when the class had none, so a ship
switched to a class whose model had been loaded only by a select-screen
preview adopted that preview's single reference. Closing the screen then
freed the model from under the ship, and the first simulation frame asserted
in model_get(). This is what happened on a replayed mission with a restored
loadout: ship select was skipped, the weapon-select overhead loaded the new
class once, the commit switched the player to it, and the screen close
released it.
Load unconditionally, as ship_create() already does, so the ship holds its own
reference.
Co-Authored-By: Claude Fable 5.1 <[email protected]>
* reject stale model ids in model_unload and release select-screen handles at level close
model_unload only used the slot part of the id it was given, so a handle kept
across missions would free whatever model had since been loaded into that slot.
Validate the id against the slot's occupant and warn instead.
Two holders could present such handles: the weapon-select icon models under a
scripted UI that overrides the state hooks (the native close never runs), and
the ship-select 3D model global, which was never reset between missions.
Release the select-screen handles from game_level_close, and unload the
ship-select model on screen close and on every selection change.
Co-Authored-By: Claude Fable 5.1 <[email protected]>
* consolidate the select-screen resource release
The weapon side released its icons, anims, and ship class data from two
functions keyed on whether the screen was open, and the level-close path added
a third copy. Give the weapon side the same shape as the ship side: one
unconditional weapon_select_common_close(), with weapon_select_close() left as
pure UI teardown. common_select_level_close() now just calls the two common
closes, and common_select_close() calls it in turn. The ship-select 3D model
is released from ship_select_common_close() so both paths cover it.
Co-Authored-By: Claude Fable 5.1 <[email protected]>
---------
Co-authored-by: Claude Fable 5.1 <[email protected]>
During phase 1 of the FS2 ship/weapon select animation, the wireframe
is supposed to be revealed as the scanline moves down. That relied on
the clip plane set up for the grid carrying over to the wireframe
render. 90a2676f1 replaced the grid's clip plane with line trimming,
which left the phase 1 wireframe unclipped, so it popped in all at once.
Clip the wireframe in both phase 1 and phase 2.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
light_apply_rgb works in the model's local frame, but nothing rotated the
lights into that frame before insignias were drawn: light_rotate_all() was
only called for the briefing and tech room lights, and even then it skipped
Static_light, the separate copies of the sun lights that light_apply_rgb
reads. So the sun term used a stale, never-set direction and the point
lights were treated as if they sat at the model's origin.
Rotate the lights, including the sun copies, once the insignia's instance
is set up, and light each vertex at its actual position, which includes
the insignia's offset.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
When a destroyed subsystem was repaired, its submodels were only restored if the repair was done through a SEXP. A subsystem repaired by a support ship, by automatic repair, by a script, or through the debug console regained its hitpoints but not its submodels, so a ship could have a working turret with no model. Any -destroyed form also remained visible.
All of these now call restore_subsystem_submodels, which brings back the subsystem's submodels and hides the -destroyed submodel linked to a special-point subsystem. The -destroyed form of an ordinary submodel is hidden when the submodels are next replicated. The SEXP code uses the same function, with no change in its behavior.
Destruction outside do_subobj_destroyed_stuff now goes through a new blow_off_subsystem_submodels function, which do_subobj_destroyed_stuff also uses. It blows off both of the subsystem's submodels and shows any linked -destroyed submodel, unless the subsystem has "no disappear". This handles the cases where a subsystem appears destroyed without going through do_subobj_destroyed_stuff:
- the subsystem is destroyed at the start of the mission
- the subsystem was destroyed in the previous mission of a red-alert sequence
- the ship changes class while the subsystem's submodels are blown off
Previously the first two blew off only the first submodel, ignored "no disappear" for it, and never showed a linked -destroyed submodel; the third did nothing. For red alert, subsystems with no hitpoints at all are not treated as destroyed. For a class change, the visible state is carried over rather than inferred from hitpoints, so a subsystem set to zero without being blown up, or repaired without its submodels, keeps its appearance.
Red alert also restores the submodels of a subsystem that the mission file starts destroyed if the previous mission's data gives it hitpoints. Ship-copy-damage now shows or hides the -destroyed submodel linked to a special-point subsystem to match the copied state.
As before, the link between special-point subsystems and -destroyed submodels requires "$Link special-point subsystems to -destroyed submodels:" in game_settings.tbl.
The multiplayer hitpoint-update path is not changed. A client receives subsystem hitpoints separately from the notification that a subsystem was destroyed, so a hitpoint update sent just before the destruction could arrive after it and wrongly restore the submodels.
Co-Authored-By: Claude Fable 5.1 <[email protected]>
Fix bitmap and model handle leakage in the ship/weapon select screens, and make release symmetric with load:
* Initialize each team only once in `ship_select_common_init`
* Unload every team's map in `ss_unload_team_icons`, not just the active one.
* Add a per-team unload helper and use it in the load-all functions
Also drop the stray per-icon Cur_Anim unload, and call `wl_free_ship_class_data` before loading in `wl_init_ship_class_data`.
Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
Convert the mission ship/weapon select screens' per-class UI state from dense MAX_SHIP_CLASSES / MAX_WEAPON_TYPES arrays to sparse containers keyed by loadout-pool membership, matching the Ss_pool / Wl_pool maps they shadow:
ss_icon_info Ss_icons_teams[][MAX_SHIP_CLASSES] -> SCP_map<int, ss_icon_info>[]
wl_icon_info Wl_icons_teams[][MAX_WEAPON_TYPES] -> SCP_map<int, wl_icon_info>[]
wl_ship_class_info Wl_ships[MAX_SHIP_CLASSES] -> SCP_map<int, wl_ship_class_info>
int Plist[] / Slist[] + manual size counters -> SCP_vector<int>
The ship-select active list is replaced outright by a vector of ship classes rebuilt on each interface sync, plus the existing scroll offset. active_list_remove() was dead code and is deleted.
Behavior fixes required by the conversion:
* wl_set_disabled_weapons now computes usability flags for the pool
weapons plus every weapon currently in a slot's banks, instead of all
weapon classes. (Bank weapons are not guaranteed pool members.)
* The two mouse-region handlers that read Plist[Plist_start+index] for
raw indices 0..3 now bounds-check against the list size (as does
ss_get_ship_class_from_list).
* wl_unload_icons and the ss unloaders early-return on a null team
pointer instead of asserting and dereferencing.
The ship side loads icons for every pool class including exhausted 0-count entries while the weapon side loads only positive counts, preserving the existing asymmetry.
Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
team_data was the last persistence-adjacent structure sized by MAX_SHIP_CLASSES: four parallel ship arrays plus four parallel weapon arrays (one slot per mission-file loadout line, holding a class or a sexp variable name, and a count or a sexp variable name) with manual num_*_choices counters, plus a dense per-class weapon_required flag array. Convert all of it to the sparse-container family:
ship_list / ship_list_variables / ship_count / ship_count_variables
-> SCP_vector<loadout_entry> ship_choices
weaponry_pool / weaponry_count / weaponry_pool_variable /
weaponry_amount_variable
-> SCP_vector<loadout_entry> weapon_choices
bool weapon_required[MAX_WEAPON_TYPES]
-> SCP_set<int> required_weapons
where loadout_entry is {class_index, count, class_variable, count_variable}, with empty variable strings meaning the value was given literally. num_ship_choices / num_weapon_choices become .size().
Intentional behavior fixes, all previously latent memory errors or
data bugs:
* is_ship_assignable stored an alt ship CLASS in a variable used as a
loadout list INDEX when default_to_this_class was false, then
swapped to ship_list[class] - garbage for any mission where the two
domains diverge. It now swaps to the alt class itself, per the
evident intent.
* The default-ship fallback read ship_list[0] even when a team had
zero ship choices; it now leaves default_ship at -1, and
ss_fixup_team_data guards its append of the default ship accordingly.
* FRED2's dumpstats indexed Ships[] with a ship class when printing
loadout entries; it now prints the entry's class or variable name
directly.
* Team parse now clears the previous mission's entries explicitly
rather than relying on overwrite-in-place.
This clears the largest remaining cluster of MAX_SHIP_CLASSES references on the way to lifting the ship class limit.
Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
- A parse flag to indicate when the mission is being parsed, and a new `ship_class_index()` accessor in the ship registry, both currently unused
- Make the ship registry more robust, especially in FRED: properly update it when ships are renamed or deleted
Convert ship/weapon loadout pools from naive per-class arrays to ordered maps that list loadout entries. Each entry represents a ship/weapon class and its count. An absent entry means the class is not in this mission's loadout. Since these are ordered maps, iteration of the map keys occurs in the same sequence as iteration of `Ship_info` or `Weapon_info`.
Includes several bugfixes:
- `csg_read_loadout` now clears both pools before reading. Previously the pools were only zeroed in `mission_campaign_init`
- `restore_wss_data`: non-transmitted classes are now absent rather than memset to 0
- a copy-paste bug where the weapon pool entries were bounds-checked against MAX_SHIP_CLASSES
- `wss_maybe_restore_loadout`: the pool write-back now preserves loadout membership instead of writing a count for every class
- `ss_dump_to_list`/`ss_swap_list_slot`: returning a slot ship whose class is not in the pool now makes it available instead of silently losing it. Unreachable in retail but reachable via script
- off-by-one errors in the Lua `Ship_Pool`/`Weapon_Pool` indexers
Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
* Fix C4709 Warnings on latest VS
* more
* suppress false positive
* Switch to using any/none_of
* Address Feedback
* Fix Line endings?
* Fix commits and strip out flag_combinator
* more fixes
* nolint
* fix stale color_to_draw causing draw_model_icon crash with model_id of -1
In draw_wing_block(), color_to_draw was initialized once outside the
slot loop while bitmap_to_draw was reset every iteration. Once any
slot in the wing took the model-icon path, color_to_draw stayed
non-NULL for all remaining slots. A later slot whose icon had no
model (model_index == -1) and no bitmap frame to draw (e.g. a carried
icon that has not moved yet, or an icon ani with missing frames) then
fell into the color branch and called draw_model_icon() with a model
index of -1, crashing in model_clear_instance().
Reset color_to_draw each iteration, and give draw_model_icon() the
same model_id guard that draw_model_rotating() already has.
Co-Authored-By: Claude Fable 5 <[email protected]>
* guard against NULL color_to_draw when an icon ani is missing frames
In draw_ship_icon_with_number() and wl_render_icon(), a bitmap-based
icon takes the bitmap branch initially, so color_to_draw is never
assigned. If a hot/selected/disabled state then swaps in an icon ani
frame that does not exist (e.g. a single-frame or truncated icon ani),
the frame index is -1, the final dispatch falls into the color/model
branch, and gr_set_color_fast() dereferences a NULL color.
Fall back to the normal icon color in that case.
Co-Authored-By: Claude Fable 5 <[email protected]>
---------
Co-authored-by: Claude Fable 5 <[email protected]>
* Extract shadows into own shader and render pass
# Conflicts:
# code/def_files/data/effects/main-g.sdr
* Consolidate render queue code
* More cleanup
* Fix missing clear of shadow buffer inter frame
* Request capability for viewport layer rendering
* instanced shadows
* Fix issues
* Switch to PCF+PCSS and proper textures for it
* Smooth PCSS toggle
* Fix for windows
* Fix OGL error
* Cleanup of old flag
* Expose shadow smoothness
* Fix missing uniform
* Make number of shadow cascades dynamic
* Progress on cockpit shadow integration
* Wrangle Cockpit and show-ship shadows into correct behaviour
* Cleanup
* make player ship shadow table options more intuitive
* Cleanup
* Only read from correct set of shadow maps, also stretch first main-scene map to 0
* Remove now non-necessary validation
* Make shadow cascade buffer more typesafe and less wasteful
* Don't allocate cockpit cascades if not used
* Cleanup
* Final fixes
* Fix Warnings
* clang tidy
* Fix missing fallback for shader precaching
* That weird FOV multiplier that always ruins your day
* Avoid shadow geometry artifacts by using hardware depth clamping
* Correctly handle shadow cascade overrides with hardcoded length
* GCC9 and its sad state of C++17 support.
* Address Feedback
# Conflicts:
# code/graphics/shadows.cpp
brief_stage owns its icons and lines buffers through raw pointers, so the
implicitly generated copy/move operations silently alias those buffers
across two stages. Delete them and provide a custom swap() that
exchanges members (keeping each slot with a distinct buffer), plus a
reset() that restores the default-constructed state.
Update brief_compact_stages, the only code that assigned brief_stage
objects: shift stages down by swapping (equivalent, since the removed
stage buffers were already freed and the tail is cleared afterward) and
clear the tail entries with reset().
Co-Authored-By: Claude Fable 5 <[email protected]>
Turrets with initial animations flip animation angles every frame in the techroom. The commit returns TriStateBool from model_get_cached_ui_render_instance specifically so callers can run setup only when a new instance is created, but only `render_tech_model` (the Lua path) actually checks it.
Since the instance is cached and persists across frames, every frame re-runs clearShipData + initial-animation start on an already-animated instance, re-applying the initial animations relative to the current (already-animated) pose. This is what seems to produces the per-frame flip/jitter.
This PR caches it to prevent this, and fixes#7526. Tests confirm it works as expected.
After a drag-drop that consumed the last unit of a roster class, the
active list could shrink while SS_active_list_start was non-zero,
making items above the stuck offset (including default ships returned
to the pool, such as Seth fighters) unreachable: the up-arrow handler
short-circuits when size <= max_show without resetting the offset.
- Clamp the preserved scroll offset in ss_synch_interface() against
SS_active_list_size - MAX_ICONS_ON_SCREEN.
- Harden common_scroll_down_pressed() to reset *start to 0 when the
whole list fits on screen.
Fixes#6240
Co-authored-by: Claude Opus 4.7 (1M context) <[email protected]>
Ship_info is already an SCP_vector but MAX_SHIP_CLASSES (500) is held in
place by fixed-size structures throughout the engine and editors. This
converts the seven file-format-adjacent arrays whose persistence touches
the .csg campaign save and .plr pilot file formats:
campaign::ships_allowed [MAX_SHIP_CLASSES] -> SCP_vector<ubyte>
campaign::weapons_allowed [MAX_WEAPON_TYPES] -> SCP_vector<ubyte>
loadout_data::ship_pool [MAX_SHIP_CLASSES] -> SCP_vector<int>
loadout_data::weapon_pool [MAX_WEAPON_TYPES] -> SCP_vector<int>
scoring_struct::kills [MAX_SHIP_CLASSES] -> SCP_vector<int>
scoring_struct::m_kills [MAX_SHIP_CLASSES] -> SCP_vector<int>
scoring_struct::m_okKills [MAX_SHIP_CLASSES] -> SCP_vector<int>
The CSG and PLR file formats already store explicit counts and key by
ship/weapon names, so no on-disk format change is needed. Existing
read/write loops already iterated by ship_info_size() / weapon_info_size()
and just compile through against the new vector types.
Vectors are sized to ship_info_size() / weapon_info_size() in
scoring_struct::init(), mission_campaign_clear(), player_loadout_init(),
and the campaign-pool reset paths in csg.cpp and multi_campaign.cpp.
All of these run after weapon_init() / ship_init(), so the sizing
invariant holds. scoring_struct globals constructed at static-init time
start with empty vectors; first index access is always post-table-parse.
Multiplayer stats sync (multimsgs.cpp) now derives offsets and counts
from the vector size; added USHRT_MAX assertions on the sender side
since the wire protocol packs offset/count as USHORT. The FSTracker
sync (multi_fstracker.cpp) clamps vmt->num_ships down to the local
mod's kills.size() before transmission and guards the receive-side
write so a tracker payload with more ship slots than this mod has won't
overrun the vector.
The MAX_SHIP_CLASSES cap itself stays in place at ship.cpp:2327; this
is one prerequisite toward lifting it. The other ~25 fixed-size
ship-class-indexed structures (team_data, Ss_pool_teams, Wl_ships,
FRED2 editor arrays, qtFRED Editor::_ship_usage, etc.) remain to be
addressed in follow-up PRs.
Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
* add wing display names
Adds display name capability for wings, matching the pattern and infrastructure of display names for ships. As in #7234, wing display names take precedence over ship display names, if both are provided; because if ship display names took precedence, a ship would have the same display name in every wave.
All the relevant display locations are handled, including the HUD, escort list, message box, and mission log. Lua API support is provided as well.
Adds full support for both FRED and QtFRED, including the always-save-display-names setting.
Addresses #7189 and the last request from #1730.
* add help text from #7234
Some code refactoring to allow mission titles to be strings of any length. Titles that are too long to actually display (based on string width) will be visibly truncated using `font::force_fit_string`, but the underlying title will not be affected. Multiplayer is still subject to the 31-character length limit, so titles sent over the network will still have characters truncated.
Also removes some redundant calls to `gr_get_string_size`, since `font::force_fit_string` returns the fitted string width.
* use std::move() for local variables that are copied but not reused
Addresses ~140 Coverity "Variable copied when it could be moved"
defects across 74 files. Every std::move() targets a local variable
whose value is consumed by push_back, emplace, assignment, lambda
capture, or a function call and is never read again afterward.
Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
* clang: use std::make_shared
* clang: use std::make_unique
* address feedback
---------
Co-authored-by: Claude Opus 4.6 (1M context) <[email protected]>
* Implement Photo Mode
* fix gr string errors
* return raw char array
* control conflict groups and better photo param defines
* better param identification in real time
* make photo mode hude dynamically sized
* fix xstrs after all changes
* missed a few
* use modern loop
When a player enters the mission loop screen from the main hall, there was no code to handle the stopping of main hall music and ambient sound. Add code to handle this specific case.
Also fix `Loop_sound` not being initialized to -1 `in loop_brief_init()`, which caused an assert when closing the loop brief screen if no branch brief sound was defined for the mission.
Fixes#7330.
Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
Just as special tokens are replaced in debriefings, replace them in command briefings and briefings as well.
Change `string_replace_tokens_with_keys` to `message_translate_tokens` (since it's the same thing) and add a `replaceContainers` script API function to complement `replaceVariables` and `replaceTokens`.
Also replace every category of token in `sexp_modify_variable` and add comments to places where token replacement might be expected but happens elsewhere.
Rewrite `force_fit_string` to be more robust and to remove the potential for memory access violations. Also audit all of the length parameters in the calling functions - some of them were the buffer size, not the length. This should fix the mysterious crash in the mission log screen.
* Allow Display Name to be used in Kills Stats by Ship Class
Currently, the display that is shown for kills by ship type does not use display name of the ship class, which makes the ship classes look different than the other areas where they are displayed throughout the game. This PR fixes that by using display name when rendering the kill stats. Note, this PR does not edit the pilot file structure at all, it simply just tunes how the names are displayed/rendered.
Importantly though, display names do not have to be unique, while the ship class names do. Thus, this PR also consolidates the number of kills of ship classes with the same display name (For example, FotG uses classes like `X-wing#Red` and `X-wing#Blue`, but both have the same display name of `X-wing`, so this consolidation means FSO will simple display `X-wing` with the sum. Overall, mods not using display name will be unaffected, while mods that do use display name will now have it properly work in the barracks and debrief rendering.
Tested and works as expected.
* remove flag for now
* move assert
* use handy get_display_name
FSO doesn't appear to use this any longer. And even when it was enabled the
requirements made it largely useless anyway. Removing to clean up cfile a
bit and so we don't have to keep maintaining it.
* Extra Visual Indication for `Scramble` Missions
Currently, if a mission is set as scramble then there is no visual way for the player to see that the Ship Selection and Weapon Loadout screens are locked, instead the player has to click on the buttons and hear the fail sounds or assess that the hover states are not triggering. This PR adds a text line right below the words Weapons Loadout that states "Ships/Weapons Locked" (XSTR 749) if the mission is scramble thus the player can easily see this right away and not have to check the buttons on every mission.
Tested and works as expected. Happy to put behind a flag if desired.
* whitespace
* incorporate feedback
* Few Minor Visual Indicator Enhancements to Loadout
This PR adds a few visual indicator tune-ups to the loadout screens.
1.
Currently, if a mission is set as `scramble` then there is no visual way for the player to see that the Ship Selection and Weapon Loadout screens are locked, instead the player has to click on the buttons and hear the fail sounds or assess that the hover states are not triggering.
This PR adds a text line right below the words `Weapons Loadout` that states "Ships/Weapons Locked" (XSTR 749) if the mission is `scramble` thus the player can easily see this right away and not have to check the buttons on every mission.
2.
Currently there is a nice orange coloration of the player ship icon in the Ship Selection wing loadout. This immediately shows the player which ship is theirs, but this usefulness does not translate to the Weapon Loadout screen. The player must select another ship, besides the player ship, to have the player ship show up as orange.
This PR adds a bool `always_highlight_ply` which is specifically for the weapon `draw_wing_block` function when called as as part of the weapon loadout routine.
Both PRs are tested and work as expected. I currently have these PRs on without a flag, but if folks really do not want the PRs or would prefer them to be behind a flag, then I'm happy to do that, too.
* separate PRs
Ships that red-alerted, but that departed before red-alert was triggered, would have 0 weapons on the subsequent mission. Since exited ships do not store weapon information, that information was never saved in the red-alert status, and so `num_primary_banks` and `num_secondary_banks` would inadvertently be set to 0. This bug has been around since the pilotfile upgrade in 2013, and apparently was common knowledge among several players, but was never reported. :-/ The fix is easy enough: skip setting weapon information if that information is not saved in red-alert status. (We should also skip setting subsystem information in the same circumstances, although that did not cause any subsystem misbehavior.)
Use `std::unique_ptr` rather than `vm_malloc` and `vm_free` to handle optional strings in ship classes. This makes the code more robust and increases memory safety. This also allows several string variables to be consolidated in the ship class and weapon class script APIs.
Also add new `stuff_string()` overloads and a new `F_TRIMMED` string parsing type to handle the new fields and the string trimming done inside `stuff_malloc_string()`.
Several changes related to the volumetrics model fix:
1. Update the `model_load()` prototype with better parameter names, including a new `ErrorType` enum defined in pstypes.h
2. Update the `MIN`, `MAX`, and `CLAMP` macros, all of which were susceptible to performance issues because they duplicated their tokens. This could cause functions or calculations to be re-run unnecessarily. Since the codebase is now on C++17, `std::clamp()` can be used.
3. Update the rest of the codebase to fix any associated issues.
