If the mission is edited in a text editor, and a ship is given too many weapon banks, this can cause issues in the weapon firing code. Protect against this by checking the number of banks when the ship is created.
This adds several missing initializations of cargo titles for both ships and subsystems. Note that `Subsys_status` initialization needs to happen in `allocate_subsys_status()`, because subsystems can be allocated in red-alert or in the `ship-copy-damage` SEXP, not just parsing.
Follow-up to #6000. Fixes a rather insidious ERANGE error in Inferno.
Per #4294, this adds two new flag that, together, are equivalent to the legacy "immobile" flag but individually provide more fine-grained control. Since the physics for position and orientation have a bit of overlap, the new flag functionality simply reverts whatever position or orientation changes were done by the physics sim.
In the FRED and qtFRED ship flags dialogs, the "immobile" flag (aka "Does Not Move") is replaced by the two new flags, but in FSO the situation is more complicated. The old and new flags coexist and have overlapping functionality, so the mission designer must be careful to set and unset the appropriate flag (that is, it is possible for both "immobile" and "don't-change-position" to be set at the same time, in which case the ship cannot change position without both flags being unset). The `set-immobile` and `set-mobile` legacy SEXPs ensure that the new flags are removed so as not to conflict with the legacy flag, but the `alter-ship-flag` and `are-ship-flags-set` SEXPs and the `getFlag` and `setFlag` script functions use exactly what the FREDder/scripter specifies and nothing else.
(I attempted to completely replace "immobile" with the two newer flags, but it proved intractable to do this while maintaining reverse compatibility: retrofitting single-flag functions to apply dual flags for one particular situation made the functions harder to understand as well as introducing many edge cases and opportunities for bugs or "gotchas".)
Implements #4294.
* coverity - using `std::move` instead of copying, and change some parameters from value to reference
* coverity - fix or mark potential copy-paste mistakes
* coverity - various checking of parameter and return values
* coverity - miscellaneous fixes, and change some 'intentional' markers to 'false positive' markers
When loading a legacy mission that contains a debris field, FSO will try to index into an empty vector, causing an out-of-bounds exception. This can be seen by loading Derelict mission dl1-08, "The Horror in the Deep".
The `// Obsolete and only for backwards compatibility` code added in #6021 properly handles asteroid fields, but not debris fields; so the fix is simply to apply the logic to debris fields as well.
When a new mission is loaded, clear the parse names vector, in lieu of the old `Num_parse_names = 0;` line. This fixes a bug where FRED will complain about nonexistent ships when loading a different mission. Follow-up to #5937.
* One more follow-up to #6021
Update assertion message and mission saving check since older builds are not going to be able to read fields created with newer builds
* update to use empty
Break when you've found a match, instead of just mindlessly comparing the rest.
This is technically just an optimization and safety change, but potentially, before, if the loops had been switched, it would have caused unexpected behavior if two copies of the same flag were listed.
* base working version of unlimited debris types
* Proper FRED support
* make qtFRED handle asteroids properly
* fix qtFRED assertion
* further clean out MAX_RETAIL_DEBRIS_TYPES
* These should be sizes not POFs
* Move this to it's own method
* convert asteroid subtypes to a vector
* unlimit asteroid subtypes
* fix some global shadowing
* signed/unsigned mismatch
* Address feedback
To enforce type safety for arrival and departure locations, this converts them to enum classes. Various casts are added when appropriate to convert between the indexed and enum values.
Allows ships and wings to arrive behind a ship, to complement 'In front of ship'. In fact, the arrival code is nearly identical, with just a small tweak to distinguish ahead from behind.
Since the new arrival location represents a change in mission format, this also adds code to detect for its usage and set the mission format to 24.1. Most missions can continue to be saved as version 23.1.
This does two things:
1. Fix a bug in `mission_bring_in_support_ship` that assigns an incorrect parse object index to the support ship's ship registry entry. Since `Arriving_support_ship` is not an item of `Parse_objects`, it should not have an index.
2. Adjust the in-game join checks at the bottom of `parse_create_object_sub` to more scrupulously account for index mismatches and bounds errors, with a specific exception for the arriving support ship.
Turn `Parse_names` into a vector and add SCP_string overloads of ship registry functions. Refactor calling code to use registry as appropriate. Remove an unused overload of `mission_parse_get_parse_object`.
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.
* Make sure we handle unknown location types
Avoids edge-case gargabe pointer 1522974
* Make sure local vectors are at least set to zero
For coverity 1522985
* Make sure from_table is initialized
When creating a replacement texture object, for coverity 1522989
* Change to Unreachable to help Linters
This was a false positive uninitialized scalar, Coverity 1523726. Hopefully, changing to UNREACHABLE() will help linters avoid this false positive in the future.
* Initialize xyw on this struct instantiation
For coverity 1523730
* Add early return for ade_set_args if error
For coverity 1523732
1. The player can target other object types besides ships, so when creating an `object_ship_wing_point_team`, make sure it is a ship
2. A few recent mission features require a version bump, but not all missions use these features; so do a "soft bump" where the mission version is updated only if necessary
3. Remove an unneeded #include by adding a `struct team_data` declaration (see #5599)
Occasionally, FRED can save a mission with a wing's ships out of order; this can happen if ships are deleted and FRED finds a free index in the middle of the ship list. This can cause benign but confusing mismatches in the ship registry, the hotkey list, and other places -- and it's also possible some mismatches may not be so benign, e.g. in multiplayer. Anyway, it's better for the ships to appear in the order the wing expects them, so this adds a routine to swap them around if necessary.
Goober5000