Abstracting this allows for the possibility of other compilers to have their
own implementation of marking a variable as potentially unused without using
the __attribute__ keyword (which is not supported on all compilers).
Signed-off-by: Peter Mitsis <[email protected]>
PR #445 was unfortunately incomplete; it fixed the time estimate for repairs, but not the actual repair part. I think I've identified which piece of code was preventing the actual repairs from working. This "repair_allocated > 0" conditional is actively preventing the "sip->sup_hull_repair_rate == 0.0f" branch from executing (so repair_allocated remains 0 and subsystems can't actually repair).
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.
Consolidated a few sequential calls, corrected a few instances of "ObjectB" being removed when "Object" was set, and removed a couple instances of hook variables that weren't set being removed.
CHA_ONTURRETFIRED wasn't clearing its hook variables. Neither was CHA_ONWPEQUIPPED or CHA_ONWPFIRED, CHA_PRIMARYFIRE, CHA_SECONDARYFIRE, CHA_ONWPSELECTED, or CHA_ONWPDESELECTED.
So it turns out it actually was the secondary code triggering the Assertion, because `ship_system->weapons.secondary_bank_weapons[]` was full of 0s. Subach HL-7 is weapon type 0, and obviously doesn't have a `cargo_size`. I see no reason to iterate through `MAX_SHIP_PRIMARY_BANKS`/`MAX_SHIP_SECONDARY_BANKS` if there aren't that many banks being used anyway.
Copy constructor and copy-assignment are made private and unimplemented (may cause problems on VS 2010/2013? I have a vague memory of something similar needing to be removed for 2010 to work; we could always wrap 'em in an _MSC_VER check, of course). Speaking of an _MSC_VER check, adds a define for `NOEXCEPT` to `noexcept`, but only if we're not using a version of Visual Studio prior to 2015 (when `noexcept` support was added). It *should* allow the move constructor for ship_info to be used whenever the vector resizes both pre- and post-VS 2015 (and on non-MS compilers), but it could use some testing. ship_info::clone() made public (and used for ship templates instead of copy-assignment), and ship_info::move() now takes a ship_info&& object (and move-assignment/constructor use std::move() to keep it an rvalue).
Adds a get_max_ammo_count_for_turret_bank() function that the weapon editor can use for turrets instead of trying to hack the behavior into get_max_ammo_count_for_bank somehow. Adjusts weaponeditordlg.cpp to use it, and also fixes missionparse.cpp so that ammo values get correctly converted from a percentage to the number of actual missiles (but only when FRED isn't running).
This creates the foundation of turret ammo through the "turret use ammo" subsystem flag. Turret ammo works in the same manner as ship ammo, where the ammo is equal to bank capacity divided by the cargo size of the weapon. This was tested using the Blue Planet: War in Heaven mod.
Test case: UEFg Narayana turrets 19 through 21, all of which contain Apocalypse torpedos with a $Cargo Size: of 2.5, were changed to use ammo with a $SBank Capacity of 20, resulting in a total ammo capacity of 8 torpedos. The Narayana was ordered to attack a GTCv Diomedes; it fired 8 torpedos each from turrets 19 through 21 before stopping. The mission was left to proceed for an additional 2 minutes, in which time the Narayana did not fire any more torpedos. Note: The Apocalypse takes 20 seconds to fire each 4 torpedo burst.
Conclusion: Success
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.
Apparently VS 2010 doesn't like vector::emplace_back() with 0 arguments. A push_back() of a generic ship_info object should provide basically the same effect.
Also added model_icon_angles to the ship_info() constructor, and model_icon_angles, thruster_glow_noise_mult, and min_engine_vol to ship_info::clone() and and ship_info::move().
Conflicts:
code/ship/ship.cpp
code/ship/ship.h
The E