openable_door_on_near_path should return 0 for no door and any non-zero
value for door-found. Commit 9fdf6005df changed the logic to return 0
for no door, and the side number value for door-found. This is wrong,
since WLEFT has integer value 0, so the caller will interpret a return
of door-found, side=WLEFT as no-door-found.
Fixes: 9fdf6005df ("Convert ai_static::GOALSIDE to sidenum_t")
If two or more events are delivered in the same loop, the previous
implementation would count joystick motion multiple times. Fix this by
moving the joystick interpretation to occur once, after all the events
have been processed.
Lists of these objects are unrolled by a template parameter pack
regardless of whether they are type compatible, so keeping the types
compatible does not improve code size. Store more precise types in the
structure, and avoid needing to store the constant values into a
structure at runtime.
- Use std::integral_constant instead of a static function that returns
the value
- Remove unused protocol_family
- Replace the enum with a typedef for the one type that the enum was
used to define
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.
- Change D1X to use D2X rules regarding Vulcan cannon pickup. The D1X
rules were confusing at best, and seem outright wrong in some ways.
- When a Vulcan cannon was picked up, it was treated as containing not
less than VULCAN_WEAPON_AMMO_AMOUNT rounds, regardless of what it
actually contained. D2X respected the actual contained count, even
when running in D1X emulation mode.
- In D1X single player, if the Vulcan cannon was not picked up, then
it could be treated as Vulcan ammo. If at least 1 unit of
ammunition was added to the player, the entire powerup would be
consumed, regardless of how much ammunition remained.
- In D2X single player, if the Vulcan cannon was not picked up, then
ammunition would be taken from it, but the powerup would only be
consumed if all its ammunition was taken.
- In D1X multiplayer, a player who already had a Vulcan cannon could
not get anything from touching a new cannon, and the cannon would
not be changed.
- In D2X multiplayer, a player who already had a Vulcan cannon could
take ammunition from the cannon, but the cannon could not be drained
below VULCAN_AMMO_AMOUNT. If the cannon had VULCAN_AMMO_AMOUNT or
less, then the player could not take ammunition. If the cannon had
more, the player could drain it to that level.
- Replace all that with a simplified version of the D2X rules:
- If the player does not have the cannon, the cannon is picked up
and removed from the mine. The player takes as much of its
ammunition as possible. If the cannon was well stocked, and the
player was nearly full, some ammunition will be lost. This is
unfortunate, but the game has always had this rule, and changing
it would require dropping one or more Vulcan Ammo packs to
represent the untaken ammunition.
- If the player already had that cannon, then the player takes as
much ammunition as the cannon has, while not exceeding the
ammunition cap. Other players, if any, are updated about how much
ammunition remains in the cannon. The cannon remains in the mine.
- Backport to D1X the network message for updating the contained
ammunition in a vulcan cannon. zico added the basic feature in
7684ce92, but only applied it to D2X. With the change to let D1X
multiplayer take ammunition from the cannon, D1X now needs the same
feature.
- Remove the special case to delete an empty cannon. Instead, let the
cannon remain in the mine without ammunition. This allows a player in
single player mode to leave behind a backup cannon, which could be
useful if the player is killed and wishes to rearm before returning to
the death site. Similarly, under the new rule that players in
multiplayer can drain the cannon down to 0 ammunition, this removal
allows the cannon to remain behind for someone else to take, rather
than allowing it to be deleted by a player who already had an instance
of it.
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.
Add periodic calls to send_endlevel_packet in kmatrix if
Control_center_destroyed is false.
Needed because after finishing the last level, kmatrix is called from a
different place where Control_center_destroyed is already false.
It looks like this issue was introduced in Rebirth 0.56 with the
split off of the ipx code (febe5d1). That commit removes the call to
multi_endlevel_poll2 from kmatrix_view, which did the same periodic
sends. (Maybe because in D1 Control_center_destroyed was always true
in kmatrix so it was not needed there.)
Reported-by: snytek <#520>
Fixes: febe5d1 ("Abstracting networking protocols")
clang-13 fails to sufficiently inline this construct, causing it to emit
an unnecessary call to check_null_pointer_conversion on a path where
m_ptr is already guaranteed to be non-nullptr. That call in turn
causes a linker error, since no other site using valptridx<wall> needs
check_null_pointer_conversion instantiated. Rather than provide the
instantiation, rework the logic to avoid the need for the dead call.
