Obviously won't do anything if "repair disabled subsystems" ship flag isn't set. If both subsystem-specific flags get set at the same time, whichever one would be default behavior (based on the presence or absence of the ship-wide flag) gets removed and a Warning generated.
Can either be set for individual subsystems via the "autorepair if disabled" flag, or set for an entire ship via the "repair disabled subsystems" flag. It will, by necessity, only have an effect if the ship's "$Subsystem Repair Rate:" is a positive number.
This makes them behave more like ship flags and should bring them around towards how modders intuitively expect using a modular table to override a ship's allowed weapons to work.
Fixes Mantis 3176.
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).
Goober5000