If a modular table broke the weapons limit, it would warn about too many weapon classes, and then not actually skip the entry, because of the "if(!replace)" conditional around it, resulting in nonsensical parsing errors. Rather than just fix this error, it was suggested on IRC (by The_E) that these problems should instead cause immediate errors. Upon reflection, this makes more sense: if the mod exceeds the limits, there's little point in loading it anyway and having things be missing.
Hopefully, eventually, these limits will be removed altogether, but until then, exceeding them should not just be a dismissible warning.
This goes directly below +Muzzleglow: in $Beam Info: and causes the muzzle glow to be rendered along a projected poly instead of a bitmap.
Takes a float argument that is the length of the glow.
As opposed to detonating all missiles within a radius. Is more
efficient than previous code that traversed the entire missile object
list to find all the missiles to detonate
Add to weapons tbl/tbm
$Countermeasure:
+Single Missile Kill: False
Trivial efficiency improvement by calculating a pointer once & reusing
it. Add more countermeasure nprintf messages
Add to weapons tbl/tbm
$Countermeasure:
+Missile Detonation Radius: 40
"$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
Goober5000