Players are not robots, but the show-path cheat tried to pretend they
are, and triggered a BUG warning[1] when looking up robot information
from the player object. Fix this by passing in the robot_info when the
caller is providing a robot, and a named `nullptr` value (as
`create_path_unused_robot_info`) when the caller is providing a
non-robot object.
[1] As below, but repeated many times
```
similar/main/ai.cpp:1905: BUG: object 0x555555858550 has type 4, expected 2
similar/main/ai.cpp:1974: BUG: object 0x555555858550 has type 4, expected 2
```
Zero the entire array, rather than adjusting the loop to account for the
count of segments in the level. The array may not need to be zeroed at
all, but this is cheap and guarantees consistent results.
Use `object &` instead of `vmobjptr_t`. This should generate equivalent
code, but produce smaller debug information and may require less
inlining by the compiler.
Every caller passes `1`, so remove the parameter and always use `1`.
For backward compatibility with the previous network protocol, continue
to send a `1` in the network message.
- Write a more specific message on failure
- Defer writing a success message until `spit_powerup` succeeds
- Defer the sound too
- Rewrite the success message to tell how much ammo remains
Commit 8c8b7419b6 defined Shift-F5 and Shift-F6 to adjust the VR
handling. However, Shift-F5 and Shift-F6 already had a meaning: drop
primary weapon / drop secondary weapon. The ordering of the logic
causes the new VR handling to suppress the old drop handling, thus
preventing players from dropping weapons. Disable the VR meaning for
these keys so that drop-weapon works again, since F1 documents those
keys as drop-weapon.
Fixes: 8c8b7419b6 ("Improved conditionals for stereo vs non-stereo modes.")
v29_trigger and v30_trigger define a field `time`. v29_trigger never
initializes it. v30_trigger initializes it from the uninitialized
v29_trigger in legacy mode, and from a file field otherwise. No program
logic ever reads this member, so remove it.
Commit 7f2df64649 converted `mission_menu` to inherit from `listbox`,
but introduced an off-by-one bug in the handling of subdirectories.
`listbox` must be told how many strings it is given. Subdirectories
have one extra string, to represent the `listbox_go_up` element. The
count passed to `listbox` incorrectly failed to adjust for the generated
go-up element, causing listbox not to show the last string in the list.
Change the logic to adjust the count to include the extra element.
Fixes: 7f2df64649 ("Make mission_menu inherit from listbox")
Reported-by: AlumiuN <https://github.com/dxx-rebirth/dxx-rebirth/issues/629>
The contents of the output buffer are undefined if PHYSFSX_getRealPath
fails, so mark the function as [[nodiscard]] and modify all callers to
check that the function succeeded.
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.
