The __ALIGNED(x) macro may be used to tell the compiler to align the
symbol's address to an 'x' byte boundary. Note that 'x' must be a
power of two.
Signed-off-by: Peter Mitsis <[email protected]>
The likely() and unlikely() macros may be used as hints to the compiler to
indicate whether a branch is likely or unlikely to be taken so that it may
generate code accordingly.
Signed-off-by: Peter Mitsis <[email protected]>
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).
matches_version_specific_tag() now uses the previously-FRED-only scan_fso_version_string() function, meaning it now supports version-specific comments with as few numbers as ;;FSO 3;; to as many numbers as ;;FSO 3.7.3.20151106;;, instead of you being required to supply exactly 3 numbers.
A few comparisons weren't excluding their upper bounds properly, and the documentation for the l_Wing length function was the documentation for the l_Mission_Wings length function.
The l_Mission_Wings indexer will return an invalid wing if supplied an invalid name/index. However, you had no way of telling that this was the case because there was no isValid() function to test its validity.
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.
The function can get called with an m_cur_msg of -1 if there are no messages defined by the mission; since this is apparently intended behavior (and causes no problems thanks to the immediately-following if-statement), may as well change this assertion.
The purpose of this function is to provide modders the capability to jump to a mission using LUA scripts. There is an optional argument for jumping to a hub mission, a good example is the JAD campaign map.
Routines in the lighting module that do not have any arguments do not
need the 'void' keyword in either their definitions or declarations.
Signed-off-by: Peter Mitsis <[email protected]>
The following global variables from the lighting module were unused
and are being removed:
int cell_shaded_lightmap = -1;
int spec = 0;
Signed-off-by: Peter Mitsis <[email protected]>
We were declaring an array of NUM_TURRET_ORDER_TYPES ints, and then only specifying the first oindex of them; the memcpy() could've been changed to multiply by oindex instead, but it seemed cleaner to just reset new_target_order to -1 in all values and get rid of the redundant per-ship reset.
Discovered by triggering an Int3() in aiturret.cpp (line 1167 as of this writing) and finding uninitialized values in the turret_targeting_order array.
Peter Mitsis