* avoid undefined behavior from UNREACHABLE on reachable code paths
UNREACHABLE expands to __assume(false) / __builtin_unreachable() in
release builds, which is undefined behavior if the code is ever actually
reached. Many UNREACHABLE sites only guard against unexpected-but-
possible runtime states (values from tables, mission/save files, network
packets, scripting, or user input), so reaching them should degrade
gracefully rather than invoke UB.
Replace UNREACHABLE with Assertion(false, ...) at all such sites. It
still pops an error in debug builds, but in release it is a harmless
no-op that simply falls through to the following code. Sites that are
genuinely unreachable by local invariants (e.g. a switch over a bounded
random number) are left as UNREACHABLE.
A few converted sites had no safe fall-through -- an uninitialized read,
null dereference, or null call would have followed -- so they also get a
minimal recovery: initialize the value, guard the dereference, return
early, or skip the offending item.
Where the converted site was a simple guard of the form
if (x) { Assertion(false, ...); return; }
hoist the check onto the invariant instead:
Assertion(!x, ...);
if (x) { return; }
This states the expectation directly and shows the offending value in
the debug popup, while keeping the same graceful runtime degradation.
Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
* addendum
After consultation with Lafiel, use UNREACHABLE in situations that are effectively impossible even if not provably impossible. UNREACHABLE = "this shouldn't ever happen"; Assertion = "if this ever happens, it's a coding error". Also fix a few other sites and change a couple to Warnings.
---------
Co-authored-by: Claude Opus 4.8 (1M context) <[email protected]>
* AI Cleanup and Flag Fixes
This PR does 3 things.
1) Cleanup `ship_subsystem_in_sight` so it properly returns a bool, which is the return type of the function. Also update `ai_big_maybe_follow_subsys_path` to be a bool instead of int.
2) Adds `+subsystem attack pathing extra distance:` for use within `"$improved subsystem attack pathing:"`. FotG found, especially with the new strafing values we use, could really use the ability to set at what distance `ai_new_maybe_reposition_attack_subsys()` determines if it wants to pick a new point or not. By default the value was 2000.
3) In FotG we started using the `standard_strafe` mode more now thanks to #6511, but we have now discovered some inherit issues with it, namely that it will prematurely trigger `ai_big_strafe_maybe_retreat` because the distance it uses for determining if a collision is going to occur is `dist_normal_to_target`, which commonly resulted in the AI flying to a point to start a strafe, then thinking it would collide with the target and then retreating from strafe mode, only to realize it was now far enough to re-engage strafe mode, which commonly resulted in AI just flying around not accomplishing much. This PR adds a flag which instead uses the `distance_to_target` and a check to see if the ship is even facing the target.
Overall all are tested and work as expected. Happy to change or tune however requested, especially regarding point 3.
* clang cleanup
* cleanup copy paste name
* remove un-needed exposed float
Currently, the `$better combat collision avoidance for fightercraft:` flag only checks for possible big ship collisions when in normal chase mode (`AIM_CHASE`), but strafing a big ship is a separate AI mode (`AIM_STRAFE`). Per discussion with Asteroth, strafe attacking should also check for better collision avoidance, as the modder likely would expect that to fall under this AI flag. Also took the chance to make the collision avoidance check into a function to improve maintenance and usability.
Most places in the code that use `vm_vector_2_matrix` do so on already-normalized vectors. Changing these to `vm_vector_2_matrix_norm` avoids redundant normalization.
This function call checked the acceleration of the targeted object, rather than the active object as it should have. Fix it to check the active object. For mods that use `$Random Sidethrust Percent:` (such as Inferno), this fixes a bug that could cause an invalid memory access in situations where the targeted object is -1.
* Allow Modders to Tune Strafing
Many mods change ship velocities and damp values, but this commonly leads to poor behaviors attacking large ships within strafe mode (which is the main method for attacking big ships in a sustained way). As an example, FotG has damp and velocity values that are higher than base FS, thus the defined strafe values result in behavior where fighters never can complete a sustained firing pass against a large ship unless they are sitting and parking (which does not fit our goals to match the movie).
The values for dictating how strafe behavior occurs are easily editable by changing some key values, which this PR exposes to modders. Furthermore, mods may give large ships very long range weapons, so being able to set how far away a ship should do a strafe run begins is very valuable.
In testing it was very easy to get desired behavior of having AI do long sustained strafing runs. I estimate other mods will likely be able to leverage these values to tune strafing behavior.
I did numerous tests and evaluations finding the best balance of values to expose. I would be happy to discuss these changes in detail too, as I know this exposes a number of values.
* clang
* incorporate feedback
* Adds particle effect offset.
* bugfixing
* Switches to a cleaner approach.
* Futureproofing for particle parenting.
* actually let's just bundle parenting into this one
* working on turrets
* grinding toward turret correctness
* still grinding toward correctness
* Gets turrets working correctly.
* Fixes merge artifact
* appeases clang-tidy
* Updates some comments.
* Updates some comments.
* Tiny bit of cleanup.
* Deduplicates comments.
`ai_get_weapon` is not guaranteed to return a valid `wip`, so check for that here. This should now cover all uses of `ai_get_weapon` in the codebase.
Fixes an Event Horizon crash reported in Discord. Follow-up to #5842, commit 8dbe0e7.
Add "tactical" versions of disable and disarm goals which only perform the specific task without implying anything else. The target ship is not protected and attack goals are not cleared from other ships.
There is also a new AI profiles flag to make this the default hud squad message command instead of the classic disable/disarm.
This initializes `mc_info` to the correct values when it is constructed, removing the need for `mc_info_init`.
This PR also fixes a group of incorrectly inverted assignments in beam.cpp.
Follow-up to #5040. This extends the checks to most iterations over `obj_used_list` in FSO. There are a few exceptions such as `waypoint_add` and `waypoint_remove`, plus a few others. And none of the object iterations in FRED have the guard because FRED does not use the same object life cycle as FSO.
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.
Adds gravity! Applies on a per-mission basis, and weapons, ships, debris, and asteroids now have a configurable "gravity const" which multiplies the effect of gravity on them, by default everything except debris is 0 (meaning no effect even when the mission has gravity). AI and the lead indicator will also lead for ballistic trajectories as well, given a gravity-affected weapon. No FRED support or gravity direction control yet, to come in later PRs.
