`blast_nearby_glass` calls `check_effect_blowup`, but ignores the result.
If `check_effect_blowup` executes a blow-up effect, and the blown object
is a switch, the return value will instruct the caller to execute the
associated trigger. Since `blast_nearby_glass` ignores the return
value, it never executes a trigger. This was originally masked by a bug
that passed undefined data from `blast_nearby_glass` to
`check_effect_blowup`, which usually confused `check_effect_blowup` into
treating the explosion as not originating from the player. This
confusion then forced an early return when a switch was hit, effectively
accidentally making switches invulnerable to `blast_nearby_glass`.
Commit f6352e7 fixed the data confusion, allowing `check_effect_blowup`
to recognize that the explosion came from a player's weapon. However,
it did not add handling for the trigger, so now `blast_nearby_glass` can
destroy the switch without activating the trigger. This is at the least
annoying, and in some levels may make progress impossible. There are
two ways to resolve this:
- Fix the logic to always execute the switch when the switch is
destroyed, whether by direct hit or by `blast_nearby_glass`.
- Restore the quirk that switches are invulnerable to
`blast_nearby_glass`.
Conveniently, the `force_blowup_flag` is set by `blast_nearby_glass` and
clear for all other callers, so it can be used to recognize that the
caller will not handle the switch. Use this to implement choice 2.
Even with this change, a direct hit by a missile can still destroy a
switch and activate its trigger, since that is handled through
`collide_weapon_and_wall`. Thus, players can still use the technique of
using a guided missile to activate an otherwise impossible switch.
Fixes: f6352e7957 ("Pass correct object to check_effect_blowup")
Reported-by: wm4 <https://github.com/dxx-rebirth/dxx-rebirth/issues/419>
gcc-9 warns on taking the address of an unaligned member in a packed
structure. This structure does not need to be packed. Remove
__attribute__((packed)) and fix the code to implement I/O correctly
without packing.
gcc-9 rejects `std::enable_if<false,
std::integral_constant<std::integral_constant, 1> 0>::type` before it
notices that the whole expression is eliminated due to SFINAE. Use
`std::common_type` to coerce the inner integral_constant to an
appropriate integer type, which allows the expression to be well-formed
enough to reach the SFINAE check from enable_if, then be silently
removed from the overload resolution set.
Users who do not install Boost cannot include <boost/config.hpp>.
SConstruct handled this by disabling the macro DXX_BOOST_FALLTHROUGH,
but did not override gcc's default-enabled (via -Wextra)
use of -Wimplicit-fallthrough=3, so users would get a fallthrough
warning and the build would fail. Adjust this area to explicitly probe
for -Wno-implicit-fallthrough when Boost.Config is not available.
Fixes: 063bf29225 ("Enable -Wimplicit-fallthrough=5; fix resulting breaks")
Reported-by: Jayman2000 <https://github.com/dxx-rebirth/dxx-rebirth/issues/417>
Utility xrange, inspired by the Python2 feature of the same name,
provides an object that returns successive values from [start, end). It
is useful when the end index is known in advance, and is particularly
helpful when that index is expensive to recompute.
gcc-7 needs an additional cf_assert to inform it that e.idx is
constrained. Without this, it assumes e.idx could have any positive
value, then issues a fatal warning when INT_MAX does not fit in the
provided buffer.
common/arch/sdl/joy.cpp: In function 'void dcx::joy_init()':
common/arch/sdl/joy.cpp:281:6: error: '%u' directive output may be truncated writing between 1 and 10 bytes into a region of size between 0 and 4 [-Werror=format-truncation=]
common/arch/sdl/joy.cpp:281:6: note: directive argument in the range [1, 2147483647]
common/arch/sdl/joy.cpp:333:13: note: 'snprintf' output between 6 and 24 bytes into a destination of size 8
gcc-4.9 lacks std::cbegin, std::cend. Fortunately, nothing in the code
uses those, so remove tests for them.
Fixes: 5e434cbe95 ("Require availability of C++11 begin")
Commit 47a6f744d split out redundant code, but accidentally stored
temporaries in a `signed short` instead of a `fix` as they should have
been. This truncated some values, causing odd results whenever
quaternions were used. Fix the problem by storing the intermediate
results in a `fix`.
Fixes: 47a6f744d8 ("Factor out vms_quaternion_from_matrix division")
Reported-by: Ninjared <https://forum.dxx-rebirth.com/showthread.php?tid=1113>
Remove the fallback to Boost.Begin. C++14 is now the minimum supported
standard, and any conforming C++14 compiler should have a working C++11
std::begin.
Descent 1 mangles colors during `g3_init_polygon_model`, so this must
not be called on polygons not designed for mangling. Rearrange the
logic to allow Descent 1 to verify that polygon models are well-formed
without using the functions that mangle the colors.
Fixes: 42a2e3ab0b ("Avoid crash loading polymodels with invalid subcalls")
Reported-by: derhass <https://github.com/dxx-rebirth/dxx-rebirth/issues/416>
Windows std::ptrdiff_t is `int` instead of `long` as it should be.
Expand the values out to `long` (which is the same size as `int` on
Win32!) before printing them. This fixes format string warnings.
Reported-by: Ninjared <https://forum.dxx-rebirth.com/showthread.php?tid=857&pid=12555#pid12555>
Fixes: 42a2e3ab0b ("Avoid crash loading polymodels with invalid subcalls")
The highest-level tracking code assumed filenames would always fit in a
char[9]. This was true on DOS, but has not been true in Rebirth for
many years. Builds without fortification caused silent memory
corruption in this case.
Refuse to create highest-level entries if they would cause corruption.
Log a diagnostic telling the user that this happened.