Previously, rendering the preferred bomb type could also change it if
the active type was exhausted. This is undesirable, since it depends on
the user to have a HUD mode which causes the bomb type to render.
Switch to only change the active type if the user tries to drop a bomb
while the active type is unavailable. Some call sites already switch
bomb types automatically on depletion. Those sites will still do so.
gcc and clang disagree about how to disambiguate when an identifier is
both a typename and a member. Avoid the disagreement by renaming the
member.
Reported-by: Kreeblah <https://github.com/dxx-rebirth/dxx-rebirth/issues/532>
As reported in pull #507, the D1 implementation of the reduction was
incorrect and never reduced laser power. Therefore, when D2 emulates
D1, D2 should emulate the effect of the bug, by not reducing laser
power.
The code that provides the 0.75x multiplier to laser bolts when they're fired
using the quad laser is present in D1 as in D2, however it is incorrect and
results in it not being applied. As such, it is more accurate to exclude the
multiplier when compiling D1.
Thanks to SaladBadger for the tip.
Commit 2bcc7bb371 restricted
Laser_create_new to only create lasers for known weapon types. This
seemed like a good idea, but broke custom levels that use undocumented
laser types. It also replaced logic that coerced invalid weapon numbers
into a type 1 laser with logic that prevented firing such weapons at
all. This rendered robots with unknown or broken weapon data unable to
fire.
Commit 0c30fa7cf3 relaxed the logic to
prevent firing only in editor builds, but allow firing unknown or
invalid weapon types in release builds. Firing unknown weapon types may
work. Firing invalid weapon types may cause the game to crash when data
is accessed beyond the end of the defined weapon data. This caused the
crash reported in issue #506.
Revert to the 0.58.1 rule that invalid weapons are coerced to be a
player level 1 laser. Add a diagnostic when such a weapon is fired,
since the level author should have requested that weapon explicitly if
that was intended.
Reported-by: heftig <https://github.com/dxx-rebirth/dxx-rebirth/issues/506>
Fixes: 2bcc7bb371 ("Only create lasers for known weapon types")
Defer decreasing energy/vulcan until the object is confirmed to be
created. This avoids charging the player for a shot that cannot be
created due to object exhaustion.
Defer updating Next_laser_fire_time, so that a player can immediately
try firing again.
Defer decreasing energy (for flares) or secondary weapon count (for
secondaries) until the object is confirmed to be created. This avoids
charging the player for a shot that cannot be created due to object
exhaustion.
If a guided missile is in flight, and its owning player dies, the
player's type is changed to OBJ_GHOST. The damage that killed the
player should have put the guided missile into autonomous mode, so for
this purpose, return that the missile is not actively guided.
Reported-by: Johnsondr80 <https://github.com/dxx-rebirth/dxx-rebirth/issues/437>
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'
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.
User TRUEpiiiicness reports that valptridx<player>::check_index_range
traps when "The Apocalyptic Factor"[1] level 14 boss fires its Omega-based
weapon. Code inspection shows that this is expected, since the original
designers assumed OMEGA_ID would only ever be used by players, and coded
various shortcuts accordingly. No one told the level author this. The
boss is an interesting concept and not difficult to support, so adjust
the code to handle this situation correctly:
- Check that the shooter is a player before checking its player ID.
Without this, a robot that happened to have the same ID as the player
would interpret robot data as player data, likely causing corruption
when it tried to update the omega cannon charge. Even if the robot ID
does not match, this step causes a diagnostic[2] reporting that a
robot ID is being misused as a player ID.
- Remove the shortcut that assumes the shooter is a player. Store the
shooter's actual type.
- Remove the unnecessary and counterproductive path that:
1. Uses the object pointer to get the player's ID
2. Uses that player ID to get a player pointer
3. Uses that player pointer to get an object number
4. Uses that object number to get an object pointer
When invariants are maintained, the pointer derived in step 4 is equal
to the pointer used at the start of step 1. Use that pointer directly
instead of rederiving it. The reported exception was due to step 2,
which requires that the player ID is in range. When the shooter is a
player, this is true. When the shooter is not a player, it may not
be true.
[1] http://www.enspiar.com/dmdb/viewMission.php?id=418
```
sha1sum af.hog af.mn2
133c52fb4b4e5fd40bf7b2321789841b727d1d0b af.hog
0bb5f0dd1803b0fc1aac7c2023eacc97e9ab872b af.mn2
stat -c '%s %Y %n' af.hog af.mn2
4024838 1094445016 af.hog
566 1013524628 af.mn2
```
[2] `similar/main/laser.cpp:560: BUG: object 0x555556078958 has type 2, expected 4`
Reported-by: TRUEpiiiicness <https://forum.dxx-rebirth.com/showthread.php?tid=1038>
