* Add control_info driver sources
* Properly deal with cockpits and their 'objnum's
* Add driven animation sets to weapons and cockpits
* enumify objnums
The general expectation is that model filenames can be specified as 'none' or '<none>' for no model, but as discovered by no tea, this was not consistent across the code base. For example, `$Model File: none` was handled as expected but `$External Model File: none` was not. This PR makes the handling consistent for all ship, weapon, and shockwave POF files, and also adds some extra checks when models are loaded.
Add `const` to the `eval_enemy_obj_struct` struct so its values aren't inadvertently overwritten. Handle a bit of const-correctness propagation. Also add default member initialization to the struct.
The code has always checked a per-weapon-class value called `lock_fov` when comparing the dot product of a ship to its target to see if it can lock on to it, however the weapon table hasn't ever included a way to set this value; it's always the default value of 0.85. This just adds "+Lock FOV:" entries to aspect/javelin homing missile parsing after "+Seeker Strength:", which will set `lock_fov` as long as the supplied input is between 0 and 360 degrees.
Add some extra logic implied by the `Begun_detonation` flag. Missiles that are homing can have their targets, headings, speeds, and lifetimes changed for various reasons. If a missile has begun detonation, particularly if it is in "detonation limbo" because it is flying across a bowl-shaped turret, we don't want to change any of that. The "detonation limbo" weapon lifetime is only accurate if all of those values remain constant.
Follow up to #4006.
For certain calculations involving armor, the `GetDamage` function needs to know if the damage is being applied by a beam so it can apply the calculations with the proper frametime. The parameter was not provided in all cases, so this fixes that.
Follow-up to #1609.
When weapon flags are parsed in a modular table and override the previous set of flags, certain flags must be kept to preserve the behavior of the weapon. The previous `preset_wi_flags` technique only worked if all such flags (homing, has-display-name, even whether the weapon turns) were set in the same modular table. If a modular table overrode the flags but didn't specify those lines over again, mysterious and subtle bugs would occur.
This modifies the flag parsing to explicitly preserve all appropriate flags from the existing weapon entry, which fixes the bug. It also allows all of the flags to be specified in one place, rather than scattering `preset_wi_flags` assignments throughout `parse_weapon`. And this also adds quite a few flags to the flag list that were not handled at all under the previous design.
Finally this fixes a few incorrect assignments of default values to fields that should only happen the first time a weapon entry is parsed.
For mods which want primary weapons to 'detonate', setting the detonation range is not reliable because, due to rounding imprecision, either the range (which detonates) or the lifetime (which does not) may happen first. So this adds a flag to always detonate a weapon when its lifetime expires. Secondary weapons have this flag by default, but primary weapons can add this flag in the $Flags list. Additionally, if the detonation range and the predicted range due to lifetime are equal, the flag is added automatically.
Resolves#5521.
#5328 added a very useful culling for particles created by specific particle effects (ie weapons, now beams), though in an effort to simplify the culling process, that PR removed the necessary culling of default smoke on ships. This PR restores the culling of default smoke while also keeping the new culling of particle specific effects. Tested and works as expected, including fixing the slowdowns caused by the aforementioned removal of smoke effect culls.
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.
Goober5000