According to EatThePath's frame profiling, this one ship name lookup takes 2% of the frame time. It can be easily optimized by making use of the ship registry.
The original implementation of `ai_good_time_to_rearm` did not revert to being a "bad" time to rearm when the time was up. This fixes that and adds an AI profiles flag to toggle it.
Also converts `ai_rearm_timestamp` to use the new TIMESTAMP type.
* Allow `test_line_of_sight` to return intersecting object signature
The `test_line_of_sight` can currently provide the closest intersecting distance, but it would be very useful, especially for AI scripting, if this function could also return the signature of the intersecting object. This PR adds that functionality.
Tested and works as expected. Happy to discuss strategies for changing implementation, too. The extra, third return value for object signature was added to `getLineOfSightFirstIntersect` function because that function already returns 2 values. Thus, it will remain compatible with older scripts which only save the first 2 returned values.
* fix documentation
* fix typo
* return object instead of sig
* fix pointer
* use pointer pointer for full fix
* name clarification
* Add Animation Instance Flags
* Add SEXP barebones
* Unify and simplify animation parsing
* Clean up animation calling and use new animationlist api
* Add missing break
`Ai_flag_names[]`, `Object_flag_names[]`, and `Ship_flag_names[]` all had an associated `#define` containing their length that had to manually be incremented whenever new flag names were added to the list. This commit instead makes the number of flags in the list be computed by simple `sizeof` division, so now adding a new entry just requires adding the entry, rather than remembering to bump a `#define`. Tested in FRED to make sure populating `OPF_SHIP_FLAG` entries still works.
This assert catches any weapon's parent object type, which can include OBJ_GHOST, which is a dead player. OBJ_GHOST is being encountered in this function using BPC when the player dies via beam weapon and (likely) when the players weapon are hitting an enemy ship at the same time. Because the player ship can damage an enemy after it is dead, allow for that in this function.
PR #4500 added some checks, but accidentally compared `aip->target_objnum` to an object type (although the assertion message correctly retrieved the object type, leading to the bizarre assertion that `OBJ_SHIP`, i.e. 1, was an invalid target object type). This commit makes them all access the `Objects[]` array and retrieve the `.type`, just as the assertion message does (and the pre-#4500 conditional did).
Related to #4504, in that it's the source of the failed assertions, although I can't be sure it was the cause of the crashes without testing.
* Include more valid object types in this check
The previous version of the fix only included ships because it was believed to be the object that a ship used to be guarding. Now it's clear that this is an object that the ship is currently targeting *after* guarding something.
So remove the UNREACHABLE and manually check the valid object types with an assert. Then only continue with the function if it is the right target type.
* typo
* add subsystem indexer and ensure that ship_get_indexed_subsys and ship_get_first_subsys are independent
* also add reverse lookup from subsys to index
* update indexer to accommodate subsystem pointers being changed
* use clearer function names, and fix the type of subsys_list_indexer
* add assertions
* address latest feedbcak
1) Remove the extra branch in `check_ok_to_fire` that was added in SVN revision 10392, or commit 0d54630e83. If there was an actual Coverity error, this does not fix it at the proper location. More importantly, this breaks certain turret firing behavior.
2) Fix a couple of bounds checks.
3) Remove an incorrect stale comment.
This fixes the broken turret swarm weapons that were uncovered by the fixes in #2959.
For script hooks which use conditions, be more consistent about evaluating both objects involved, as well as evaluating the different types of objects.
Fixes#3874.
My guess is that, in `ai_ship_destroy`, if the dead ship's goal object has already died in the same frame, the `goal_objnum` will be -1 when `ai_formation_object_recalculate_slotnums` is about to be called.
There were two bugs that kept this from working until now:
1) The destination goal point was calculated to take the ship right through the center of danger. Flipping the vector now takes the ship away from danger as intended.
2) The original AI code did not turn the ship at all. The new code turns the ship toward its goal point.
The fixed behavior is tied to the new `$fix keep-safe-distance:` flag.
Mostly renaming of fields and functions, and moving some modelread sections into functions. This reorganization will put the code on a better footing for the model translation feature. No model translation code is included yet, and there should be no change in functionality.
By anchoring a dockpoint to a submodel, the dockpoint will move when the submodel moves. Historically this has been done by inspecting the path associated with a dockpoint, but this method will not work if there is no path or no rotation mode specified. Here is an alternate method that allows the submodel to be specified explicitly through a dockpoint property.
For a long time, bay door animations would not trigger if the player was arriving from the bay as the the only ship in the wing. This was fixed by adding a check for the player. This check uses the `Player_obj` to check if the ship is as player, which does not work on standalones since the `Player_obj` is always the Standalone Ship.
This PR changes the check to check if the flag `Player_ship` is set, which is a common strategy used to make these kinds of checks work on standalones.
Tests show the old behavior still works as expected.
* Allow AI flag for bay orientation to account for parent `uvec`
The previously added flag `Fighterbay_arrivals_use_carrier_orient` (#3698) incorporated the parent ship's `rvec`, which greatly helped align emerging ships from fighter bays. In parent some ships though, emerging ships still showed a `uvec` that did not match the parent ship (such as FotG's Star Destroyer). This PR allows the `Fighterbay_arrivals_use_carrier_orient` flag to take parent `uvec` into account.
Note, that departing the mission into a bay already has code to ensure a `wheels-down` landing.
PR is tested and works as expected/fixes `uvec` issue.
* only set uvec as lazy option