"$Detonation Radius:" and "$Arm radius:" would both rely on wp->homing_pos being set if wp->homing_object was; however, during free flight time, wp->homing_pos remains uninitialized (a null vector). As a result, their vm_vec_dist() calls would be comparing with the distance from the mission origin (coordinates 0,0,0) instead of the actual location of whatever they were homing in on. In the case of detonation radius, this would result in instant detonation on launch if you fired within det_radius of the mission origin. In the case of arm radius, this would result in the weapon being armed during free flight if launched within the arm_radius of the origin (and yes, you could theoretically experience the effects of both of these bugs simultaneously).
Theoretically, this solution is still less than ideal (a target sitting exactly on the mission origin could cause wonkiness), but it's consistent with the IS_VEC_NULL() checks elsewhere in weapons.cpp. A "proper" solution would basically require rewriting the entire homing code... which, obviously, if somebody would like to volunteer for, I wouldn't stop you ;). In the meantime, firing a homing weapon at a target sitting on the mission origin is even less likely than firing a weapon with one of the affected attributes within a certain distance of the mission origin, which was already pretty uncommon (it took a weapon with an abnormally large detonation radius of 1 kilometer to even realize this bug existed).
This adds extra sanity checks to the Weapon Damage Decay code and also
adds a new parameter for weapons that can GAIN damage is they approach
the end of their lifetime.
This adds the $Daamge Time: and +Min Damage: entries to weapons.tbl.
These parameters are used to create damage attenuation for non-beam primary weapon.
This adds two weapons.tbl entries that allow a weapon to have a range of
possible fire delay times which results in random firing time. simulates
real life firing time error for the most part.
Overhaul hudartillery.cpp to use STL containers (removes hardcoded limits on maximum number of strike types, simultaneously active strikes, and projectiles per strike), use modular tables, allow for different shape options, and allow beams as the weapon.
If "@Laser Color2:" is defined for a weapon and you override that weapon with a modular table (even if that override entry doesn't actually contain any data), the weapon's laser_color_2 value would get defaulted to its laser_color_1 value. Now, only do that if changing laser_color_1 and the RGB values of the two colors matched before.
git-svn-id: svn://svn.icculus.org/fs2open/trunk/fs2_open@11319 387891d4-d844-0410-90c0-e4c51a9137d3
By adding an "+Area Of Effect" line after "+New Style:" or "+Old Style:", it causes every ship caught in the weapon's shockwave or blast to suffer electronics disruption. Requested by Black Wolf.
git-svn-id: svn://svn.icculus.org/fs2open/trunk/fs2_open@11173 387891d4-d844-0410-90c0-e4c51a9137d3
These allow munitions to be attacked by the AI without needing to set the "bomb" flag; "turret interceptable" means it can be attacked by turrets, "fighter interceptable" means it can be shot down by fighters, and "interceptable" sets both flags simultaneously. Requested by Rheyah.
git-svn-id: svn://svn.icculus.org/fs2open/trunk/fs2_open@11171 387891d4-d844-0410-90c0-e4c51a9137d3
Related to weapon substitution code
Also a gcc warning (sequence point)
git-svn-id: svn://svn.icculus.org/fs2open/trunk/fs2_open@10301 387891d4-d844-0410-90c0-e4c51a9137d3
MageKing17