The scripted code previously didn't check to see if a weapon bank was valid before firing it, which could have led to memory problems and starting March 15 would actually crash the game. This adds a few safety checks.
This PR adds a table entry that allows modders to specify the damage threshold for when turrents become less accurate due to weapon subsystem damage. A Game table setting is easier to set once and tune, thus this PR allows that efficent exposure to the modder and does not require a large change or complex table entry.
The previous system was kind of hacky and made things a bit inflexible.
This improves that system quite a bit and also adds unit tests for the
hook variable functionality.
In aiturret.cpp there is a mprintf, `mprintf(("nothing ok to fire\n"));` which greatly pollutes the debug log in missions with turreted ships. I'm not sure what this message helps debug, thus I propose commenting it out.
Previously, using max and min delays resulted in guns firing that were not within the specified range. This PR fixes that while also simplfying the code. `frand_range` is already using in each of those functions so I figured it would be fine to use it and also simplify the code. That, instead of `next_fire_delay = (((float)rand()) / (((float)RAND_MAX + 1.0f) * (winfo_p->max_delay - winfo_p->min_delay + 1.0f) + winfo_p->min_delay))`.
When the `+Max Delay:` and `+Min Delay` for `Fire Wait` were added they were only added to primary firing and not turret firing. Specifically, `turret_set_next_fire_timestamp` uses only `winfo_p->fire_wait` while `ship_fire_primary` uses the delays. Checking with the original author DahBlount they specified it was an oversight, thus this PR fixes that and allows the delays to now work properly with turret firerates.
Extremely rare bug caused by use of multiple protect from weapon flags. One of the Ai-Turret functions was setting only one of the flags because "else if" was typed instead of "if".
This maintains the type information which can be used for enforce
const-correctness and also for implementing more advanced ways of
handling the type information.
This adds a new class which allows to create type safe resource handle
types. At the moment, the engine uses ints pretty much everywhere for
providing handles to resources created by the specific subsystems. Since
all ints are the same to the C/C++ typesystem it is perfectly legal to
pass a sound handle to the graphics API as a buffer handle which will
obviously cause issues.
This adds a new type called "ID" which is a wrapper class for a generic
handle but with added type safety. An instance of this class cannot be
passed to a function expecting another type of handle which provided
compile-time type safety for these APIs.
As an initial test I converted the game sound handles to this new type.
I already found a bug in the mainhall system thanks to this new type.
The mainhall used the game sound handles as sound instance handles which
probably meant that that specific code never really worked right. I
removed the code since there was no better alternative for fixing it.
Fabian Woltermann