gcc treats the intervening lines since the last `if` as sufficient to
recognize this as not misleading. clang does not. Change the indent to
calm clang.
Define separate enum values for rotation data in both the high bits,
where it is usually kept, and the low bits, where it is sometimes used
for math or comparisons.
Define an enum value to represent the composite of the index and the
rotation, since the composite is not suitable for use as an array
subscript. Add helper functions to extract the component pieces.
A declaration is useful if it declares an external function. A static
inline declaration, if not followed by the definition later in the same
translation unit, will not be useful. Remove such declarations, and
rely on using the definition as a declaration for those files that
actually call partial_range() or similar functions.
The minimum supported compiler versions now provide a depth-efficient
implementation of std::make_index_sequence, which removes the last
reason to carry a private implementation. In the case of clang, it
appears to have a special compiler intrinsic used to implement its
std::make_index_sequence.
Switch to the compiler-provided version for both gcc and clang.
Otherwise, unless FrameTime exceeds Final_boss_countdown_time in a
single frame, the time never advances and the level never ends.
Fixes: 215252b8ca ("Fold Final_boss_is_dead into Final_boss_countdown_time")
As documented in zico's commit 38fabd7c49, robot smart mines have a
different ID number than player smart mines. Rename the test functions
to clarify that they only recognize player smart mines, but not robot
smart mines.
git grep -l is_proximity_bomb_or_smart_mine | xargs sed -i -e 's/is_proximity_bomb_or_smart_mine/is_proximity_bomb_or_player_smart_mine/g'
It has always been here, but appears to serve no purpose.
`multi_explode_robot_sub` clears `Stolen_items`, so at first look, this
swap seems to be preserving the prior values. However,
`multi_send_robot_explode` does not use `Stolen_items`, and after
`multi_send_robot_explode` completes, `Stolen_items` is explicitly wiped
again. Thus, removing the whole block will let the wipe performed by
`multi_explode_robot_sub` stand, producing the same result with less
code.
Commit 829e95b6 meant to remove the restriction that the game not be
hoard mode, but incorrectly also removed the restriction that the game
be multiplayer. Restore the multiplayer restriction.
Reported-by: zicodxx <https://github.com/dxx-rebirth/dxx-rebirth/issues/433>
Fixes: 829e95b6f8 ("Separate hoard/proximity tracking")
This removes the need to walk all objects when creating a new one, since
each object can have a private generation counter, unaware of other
objects. For compatibility with demos, mix in the object's index when
writing the signature value.
This was requested by a user in early 2018. However, the proposed
prototype was susceptible to various forms of desynchronization, and was
unsuitable for merging. No further revisions were proposed, and the
feature languished. This commit enables the guidebot in cooperative
games and addresses the known synchronization problems, as well as some
other bugs that were uncovered during light testing. This is classified
as an experimental feature because it has not been heavily tested in
complicated games.
Requested-by: cfeuersaenger <https://github.com/dxx-rebirth/dxx-rebirth/issues/364>
`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>
