When `apply_force_damage` was called to damage a robot, it tested if the
`ctype.laser_info.parent_signature` of the other object matched
`ConsoleObject->signature` and, if so, awarded points to the console
player. This allowed the player to sometimes get points for ramming a
robot to death, but was buggy. When the player rams a robot, the player
is the other object, so accessing `ctype.laser_info` is wrong.
Historically, the player's signature was zero and player
`ctype.laser_info.parent_signature` (an inactive and therefore incorrect
branch of the union) happened to be zero, so the test succeeded. Commit
44753209d6 changed the layout of
`struct player_info` such that
`ConsoleObject->ctype.laser_info.parent_signature` was not zero, causing
the player not to be his own parent. Prior to this commit, the player
could still wrongly fail the test if the `player_info` member that
aliased `laser_info.parent_signature` was nonzero. In the commit
preceding the obvious break, `player_info.player_flags` aliased
`laser_info.parent_signature`, so a player with certain flags (such as
invulnerability) would wrongly fail the test. The exact manifestation
has changed over time as `struct player_info` gained members.
Restructure the test so that a ramming kill always awards points,
without checking ancestry.
Reported-by: Descender1032 <https://forum.dxx-rebirth.com/showthread.php?tid=1006> (no commit identifiers given)
Fixes: 44753209d6 ("Move homing_object_dist to object.ctype.player_info")
Like many things in the main game loop, lavafall handling was
historically done on a per-frame basis, then its effects were scaled to
FrameTime to normalize the results. Ignoring rounding errors, this
produced roughly equivalent damage for high framerate users (who
experienced many but small damage hits) and low framerate users (who
experienced few but large damage hits). However, the randomized
movement was not scaled to FrameTime, which caused differing results for
high framerate users versus low framerate users. Commit b36c6f20c7
tried to fix this by forcing scrape_player_on_wall to run at a capped
maximum effective frame rate, then scaling the damage in
check_volatile_wall accordingly, so that high framerate users would
experience fewer damage hits, but the ones they received were larger,
thus maintaining approximately the same damage as before.
Prior to b36c6f20c7, damage was always scaled to FrameTime. In
b36c6f20c7 and later, damage scaled to max(FrameTime,
DESIGNATED_GAME_FRAMETIME), causing users with a high frame rate (and
thus low FrameTime) to take more damage on each pass. This damage
increase was balanced by an added hack in scrape_player_on_wall to limit
the frequency of the scrape so that high framerate users would skip some
scrapes, giving them a virtual frame rate appropriate to
DESIGNATED_GAME_FRAMETIME. However, the damage is only balanced if the
new governor is used consistently. It is not used consistently, so it
caused a regression for passable lava surfaces. Scraping on a solid
lava surface goes through scrape_player_on_wall and respects the
governor. Touching a passable lava surface (only available in Descent
2) bypasses scrape_player_on_wall and jumps directly to
check_volatile_wall, thereby bypassing the governor. This allows high
framerate users touching a passable lava surface to take many hits (as
they always did), but not receive the full benefit of downward scaling
the damage (as they once did) due to the new max() expression. Thus,
they are damaged frequently, but still take damage consistent with being
damaged infrequently.
Fix this by moving the hack from scrape_player_on_wall to
check_volatile_wall, so that both solid lava surfaces and passable lava
surfaces respect the governor. The governor is still an ugly hack that
should not be global, but this is a spot fix for the immediate problem.
Fixes: b36c6f20c7 ("Made scrape_player_on_wall() based on a timer. Due to the player being pushed away from the lava/water surface in every frame in a random vector (wrong, too), player movement per frame was not enough to counter this on FPS rates > ~120 which made damage scaling per frame nonsensical in these situations. Instead, execute scrape results in intevals based on DESIGNATED_GAME_FRAMETIME (or per frame if FrameTime>DESIGNATED_GAME_FRAMETIME) which fixes the issues and generally works much better for the purpose of this function.")
Commit f4b21088a0 ("Track vulcan ammo explicitly") fixed an original
retail bug that prevented the thief from stealing energy weapons,
because the thief could only steal weapons for which the player had ammo
and energy weapons never have ammo. This went unremarked for several
years, until a recent report of the new semantics as a game-breaking
regression because the thief is now "ridiculously potent".
Address this report, as well as an intermittently raised issue from
various users over time, by adding two new knobs to both the single
player "Gameplay" menu and the multiplayer setup screen: "Remove Thief
at level start" and "Prevent Thief Stealing Energy Weapons".
"Remove Thief" deletes the thief object during level load. It has no
impact on save games, and changing it after entering a level has no
effect on any thief already in the level.
"Prevent Thief Stealing" is checked at the moment of theft and, when
enabled, prevents stealing primary weapons other than Vulcan/Gauss.
This can be changed at will in single player and is immediately
effective. In multiplayer, this option can only be changed by the game
host in the pre-game setup.
For both knobs, there is one pair of checkboxes to control this as a
player preference, which applies in single player games. There is a
second pair of checkboxes in the multiplayer setup, which applies only
to multiplayer games. Therefore, in multiplayer, the host chooses thief
settings and all clients use the host's choice. The host may configure
the thief differently in multiplayer from how the host plays in single
player.
For users who wanted to remove the thief, no specific tally has been
kept for who requested it or when. Now that the code is being updated,
this is thrown in as an easy addition.
Reported-by: MegaDescent <http://forum.dxx-rebirth.com/showthread.php?tid=980> (for the thief stealing energy weapons as a game-breaking regression)
Delete stub "compiler-type_traits.h" header. Redirect all uses to the
standard <type_traits> header.
git grep -wlz 'compiler-type_traits.h' -- '*.cpp' '*.h' | xargs -0 perl -p -i <<EOF
BEGIN {
$i = 0;
}
if (($i == 1 && $_ eq "\n") || ($i < 2 && /^#include "/)) {
# First blank line or first user-include after a system-include.
# Print, then never again for this file.
print "#include <type_traits>\n";
$i = 2;
} elsif ($i == 0) {
$i = 1 if (/^#include </);
} elsif ($_ eq "#include \"compiler-type_traits.h\"\n") {
# Remove this line if found.
$_ = '';
}
# Reset state machine when moving to next file.
$i = 0 if eof;
EOF
All supported compilers have an acceptable <type_traits>. Commit
4cb3d46148 ("Move <type_traits> test to Cxx11RequiredFeature") made
<type_traits> support mandatory in August and no one has objected.
Remove the indirection and use namespace std directly for type_traits
members.
Previously, valptridx used PREFIX for allow-invalid+mutable, c#PREFIX
for allow-invalid+const, v#PREFIX for require-valid+mutable, vc#PREFIX
for require-valid+const. Convert the types, factories, and all usage
sites to specify a qualifier for all four combinations:
im#PREFIX -> allow-invalid+mutable
ic#PREFIX -> allow-invalid+const
vm#PREFIX -> require-valid+mutable
vc#PREFIX -> require-valid+const
Changes to common/include/valptridx.h and common/include/fwd-valptridx.h
are manual. All other changes are generated by:
git grep -lz -e '\(obj\|seg\|clwall\|wall\|actdoor\|trg\)\(ptridx\|ptr\|idx\)\(_t\)\?\>' | xargs -0 sed -i -e 's/\<\(v\?\)\(\(obj\|seg\|clwall\|wall\|actdoor\|trg\)\(ptridx\|ptr\|idx\)\(_t\)\?\)\>/\1m\2/g'
for the 'm' prefix and:
git grep -lz -e '\(obj\|seg\|clwall\|wall\|actdoor\|trg\)\(ptridx\|ptr\|idx\)\(_t\)\?\>' | xargs -0 sed -i -e 's/\<\([cm]\(obj\|seg\|clwall\|wall\|actdoor\|trg\)\(ptridx\|ptr\|idx\)\(_t\)\?\)\>/i&/g'
for the 'i' prefix.
clang becomes confused trying to determine which vm_distance_squared
constructor to use for a literal input of 0x7fffffffffffffff, even
though the size of the input requires it to be `long` and only one
constructor can take a `long`. Switch from an explicit
0x7fffffffffffffff to the symbolic constant INT64_MAX, which has the
same value, but a platform-appropriate suffix to force the compiler to
pick the right type.
For general clarity, switch some other instances of integer maximum
literals to symbolic constants of the same value.
This commit has no effect on the generated code (except for changes to
line numbers).
Reported-by: kreatordxx <https://github.com/dxx-rebirth/dxx-rebirth/pull/324>
Fixes: 17208cca79 ("Disallow int for vm_distance_squared")
Movement handling has an ugly hack that tries to grab powerups near the
console player, but it reuses general collision handling and fails to
check whether the player is alive.
Add a liveness check. Place the check so that it happens once, before
the objects are scanned, rather than being needlessly repeated for every
object.
Refactor the collision code to let the movement hack skip the parts it
does not need.
Reported-by: ryusei117 <https://github.com/dxx-rebirth/dxx-rebirth/issues/302#issuecomment-275816259>
Replace calls to window_close(Game_wind) with returning window_event_result::close to game handler. Applies to when DoEndGame() is called, DoGameOver() is called, aborting in the kmatrix screen (multiplayer game) during AdvanceLevel() and playing one demo frame causes playback to stop in GameProcessFrame(). Closing a window within its handler is problematic - it can result in an unstable state.
It was a convenient transition macro, but its presence was always
intended to be temporary. Expand it to ease the conversion of usage
sites that already have access to local player data through a local
variable.
It was a convenient transition macro, but its presence was always
intended to be temporary. Expand it to ease the conversion of usage
sites that already have access to local player data through a local
variable.
Rename symbol EDITOR to DXX_USE_EDITOR to show that it is a DXX
symbol, not one inherited from a library. Move it to dxxsconf.h to
shorten the command line.
This is a mostly automated transform, but the changes to SConstruct were
manual.
git grep -wl EDITOR -- '*.h' '*.cpp' | xargs sed -i -e 's/^\s*#ifdef \(EDITOR\)\>/#if DXX_USE_\1/' -e 's/\s*#\(el\)\?if \(.*\)defined(\(EDITOR\))/#\1if \2DXX_USE_\3/' -e 's/^\s*#ifndef \(EDITOR\)\>/#if !DXX_USE_\1/'
It was a convenient transition macro, but its presence was always
intended to be temporary. Expand it to ease the conversion of usage
sites that already have access to local player data through a local
variable.
