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.)
* keep from crashing
* Also, bash the number of waves if necessary
* Add Debug warning to modders
* address feedback
* formatting
---------
Co-authored-by: Goober5000 <[email protected]>
This refactors the ship registry and the OSWPT struct to store data as indexes rather than pointers. This is a prerequisite for making these collections dynamic in the future. See also #5800.
If consecutive red-alert missions have different numbers of ships in a wing, then calculating the number of waves will not be correct. This necessitates the addition of wing status to the stored data for red-alert sequences.
Not only must wing data be stored in `Red_alert_wing_status`, but also in the CSG file. This necessitates a version bump. Fortunately, the current design of CSG files allows extra data to be added to a section without breaking old builds, since the CSG loader will just skip over the unrecognized data.
This also renames `red_alert_wingman_status` to `red_alert_ship_status` since it's not limited to wingmen, as well as fixing the omission of exited ships if they are in the player's wing but don't have the red-alert-carry flag.
Fixes#5637. Follow-up to #4457 and #5609.
Two fixes for red alert missions:
1. Since any ship in the wing can be stored, not just the wing leader, the "prospective name" check should check for all possible names in each wave
2. If a wing wasn't actually stored, the red alert code should not reset the wing's wave number to 0
Follow-up to #4457.
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.
This range check is to ensure that the ship's hull is in a valid range, so it should therefore check that the hull is less than the max strength, not less than the current strength. This was inadvertently changed in 593be42e66 and a04e83ab01, but retail behavior is to set the exact hull from the previous mission.
Tested for both regular ships and delayed-arrival ships. Fixes#4472.
- support sync state before entering mission
- return to briefing for sync and stats saving
- handle campaign progression properly
- initialize net_player state properly (fixes#2560)
This can be used for mark parts of the code which should be unreachable
in normal execution. In debug mode, if such a statement is reached an
Error dialog is shown which aborts the execution. In release mode the
macro is replaced with a compiler specific expression that lets the
compiler know that this part is unreachable which allows it to optimize
the code better.
This adds a new class which allows to create type safe resource handle
types. At the moment, the engine uses ints pretty much everywhere for
providing handles to resources created by the specific subsystems. Since
all ints are the same to the C/C++ typesystem it is perfectly legal to
pass a sound handle to the graphics API as a buffer handle which will
obviously cause issues.
This adds a new type called "ID" which is a wrapper class for a generic
handle but with added type safety. An instance of this class cannot be
passed to a function expecting another type of handle which provided
compile-time type safety for these APIs.
As an initial test I converted the game sound handles to this new type.
I already found a bug in the mainhall system thanks to this new type.
The mainhall used the game sound handles as sound instance handles which
probably meant that that specific code never really worked right. I
removed the code since there was no better alternative for fixing it.
This happened in BtA where a script changed the font after rendering its
UI. Since the briefing code didn't account for that, the word wrapping
code used the wrong font for calculating how long a line would be which
made the display look wrong.
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.
* 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.
*Use existing methods to determine dock status and find the head of the dock list.
*Fixes a derp with dock_dead_undock_all()
*Doccument some docking methods in object.h
*Address requested changes.
This introduces a new mechanism for handling bit flags. Instead of using an int (or two, or three) to write bits into, this uses the std::bitset in a wrapper class that accepts an enum class as input. This means that certain classes of errors we've had a few of in the engine, where a coder used the wrong set of flags or checked them against the wrong variable (SF_STEALTH vs SIF_STEALTH, for example) can now be detected at a compiler level rather than not at all.
Goober5000