Although not used very often, ai_info.target_signature should be set to -1 whenever no target is specified, just like everywhere else to make sure that the code is as predictable as possible.
(Found while trying to figure out why the heck would the Object update packet send this at all??)
Switch from 3x specific is_arriving functions to a single with params
Change flag names; replace "ndl" with "dock_follower"
Change dock-arrival helpers to not set follower flag on leaders
There's a number of issues fixed here:
* Radar blips of docked ships were the wrong colour in stage 1
* You could target docked ships in stage 1
* Docked ships thrusters were visible in stage 1
* Hyperspace warptype ship could initially appear at their
warp-destination, then spring back to the correct location to complete
the rest of their warpin (because a docked ship had higher speed than
the dock leader)
There may also be a number of other subtle bugs with docked warpin;
e.g. I suspect (but haven't tested) that AI turrets could fire on
docked ships during warpin
These should also be fixed
Lastly, fixes issue #1867
These were all cases where the parameter was the new value when setting
a variable. The variables should always be initialized when that code is
reached but it is still better to check the pointers before using them.
These were found by @niffiwan.
This will automatically call the destructor of a type of Lua calls the
garbage collector for an object of that type. This is the last step
towards fully supporting non-trivial objects in the Lua API and all
previous workarounds have been removed.
This adds a new AI goal which is equivalent to play-dead except that it "sticks". It doesn't clear the goal list
so it will continue playing dead until the goal is removed or another goal with a higher priority is added.
This maintains the type information which can be used for enforce
const-correctness and also for implementing more advanced ways of
handling the type information.
This adds a mission file option for ships which allows specifying a
different string which should be used for displaying the name of the
ship to the user. This name will not be used in SEXPs or other ship
lookup functions so it can be freely translated and two ships can also
have the same display name.
The new feature can be used by adding $Display name: <string> after $Name
for a ship in a mission file. I think I added proper support for FRED
(and qtFRED) so that this new value is properly saved but it would be
great if someone could test that.
This implements one of the features requested in #1730.
Lua's Ship.TargetSubsystem VIRTVAR, when set, would write to an attribute of the Ships[] array based on an objnum instead of a ship instance index. Since MAX_OBJECTS is drastically higher than MAX_SHIPS, then depending on how many objects happen to be in the mission, an out-of-bounds array access can be easily generated. This commit makes sure to use the objnum instead as an index to the Objects[] array, and then retrieve the ship instance from it.
Goober5000