Instead of forcing one call, then conditionally doing 3 more, make the
loop run for 4 passes, and make the call after the conditional exit,
instead of before.
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
```
attempt_to_steal_item_3 always fails if the thief is not in
AIM_THIEF_ATTACK mode. The caller will call attempt_to_steal_item_3
repeatedly in some cases, but the mode does not change during the calls,
so if one fails for this reason, then all will fail for this reason.
Lift the check into the caller so that the loop of repeated calls can be
skipped if the mode check fails.
Use `object &` instead of `vmobjptr_t`. This should generate equivalent
code, but produce smaller debug information and may require less
inlining by the compiler.
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.
Iterating over it returns each side number in turn. This allows
converting many loops of the form:
```
for (int i = 0; i < MAX_SIDES_PER_SEGMENT; ++i)
```
to the compact form:
```
for (const auto i : MAX_SIDES_PER_SEGMENT)
```
The compact form brings the usual benefit of range-based for: delegating
iteration to the compiler prevents the loop body from skipping a step,
and makes clear in the code that this is the case.
Previously, the guidebot menu was given the full screen dimensions and
drew on only part of them, allowing the rest of the screen to be visible
due to not repainting it. Change to make the escort_menu window the
size that the user sees.
Commit dc79bb8e4a intended to clean up processing guidebot messages,
but accidentally allowed the guidebot to report certain status messages
before its cage was opened. Normal missions still do not report these
messages, but some custom levels do.
Reported-by: ziplantil <https://github.com/dxx-rebirth/dxx-rebirth/issues/438>
Fixes: dc79bb8e4a ("Remove hack for bypassing buddy time restriction")
This was requested by a user in early 2018. However, the proposed
prototype was susceptible to various forms of desynchronization, and was
unsuitable for merging. No further revisions were proposed, and the
feature languished. This commit enables the guidebot in cooperative
games and addresses the known synchronization problems, as well as some
other bugs that were uncovered during light testing. This is classified
as an experimental feature because it has not been heavily tested in
complicated games.
Requested-by: cfeuersaenger <https://github.com/dxx-rebirth/dxx-rebirth/issues/364>
Remove use of object_guidebot_cannot_reach and instead track the
reachability of the object as a separate flag. This allows the game to
remember when an object was found, but unreachable. Previously, it
would store only that some unreachable object was found. Now, it stores
the index of the unreachable object. This extra information is not used
yet.
Reported-by: Dainslaif <https://github.com/dxx-rebirth/dxx-rebirth/issues/421>
Fixes: c3cead4319 ("Move Escort_goal_index to d_unique_buddy_state")
Utility xrange, inspired by the Python2 feature of the same name,
provides an object that returns successive values from [start, end). It
is useful when the end index is known in advance, and is particularly
helpful when that index is expensive to recompute.
