Some callers create an explosion with damage forced to zero. Others
create an explosion with damage non-zero. Only the non-zero case needs
to examine nearby objects. Split object_create_explosion_sub so that
the zero-damage case can skip that logic, and the arguments required to
implement it.
If exactly one object will always be needed, use an overload that
returns the object id. Otherwise, use an overload that only returns
whether at least one object was created. This simplifies callers that
always request exactly one object.
If at least two robots would be dropped, and a drop failed, then
object_create_robot_egg would report failure to the caller. Callers
that check the return code treat any failure as total failure, but that
is not guaranteed to be true. If the game successfully dropped one
robot and failed when dropping a second, then the caller would receive a
status of failure.
Fix this by returning a status of whether at least one object was
created.
Instead of creating the powerup from a player, then overwriting the
location and velocity of the powerup, and fixing up its segment, create
the powerup directly where it should be, with the intended velocity.
Instead of creating the powerup from a player, then overwriting the
location and velocity of the powerup, and fixing up its segment, create
the powerup directly where it should be, with the intended velocity.
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>
Descent tracked hoard orbs by borrowing the player's proximity bomb
slot. Commit 829e95b6f8 moved proximity
bomb tracking to its own slot, but failed to update the player
death/deres logic accordingly. This caused multiple inconsistencies
when a player was killed in hoard mode:
- The killed player saw the orb drop as expected.
- The killed player _also_ kept the orb in inventory after respawn,
because the counter was not reset.
- Other players saw no orb drop.
Fix the inappropriate retention by resetting the orb count in
init_player_stats_new_ship. Fix the inappropriate failure to drop by
adding a new unconditional field to the player death/deres message. In
hoard games, use it to pass the orb count. In other games, ignore it.
Fixes: 829e95b6f8 ("Separate hoard/proximity tracking")
Reported-by: snytek <https://github.com/dxx-rebirth/dxx-rebirth/issues/526>
When a robot drops a robot, the dropped robot is not added to the
level's running accumulated_robots counter, but when the player destroys
that robot, the destruction will be counted. This imbalance allows the
expression counting the number of not-yet-destroyed robots to underflow,
which then confuses the matcen logic into not creating new robots.
Fix this by incrementing the accumulated_robots count as each dropped
robot is created.
Reported-by: ziplantil <https://github.com/dxx-rebirth/dxx-rebirth/issues/466>