nethack-gwaa-kiwi/nethack
1
0
Fork 0
Code Pull Requests Activity

Second fix to stuck travel

Browse Source 
There were at least two cases of travel oscillation that occurred,
even after my previous fix. To fix those, the guessing routine
would also have to consider distance to original target location.
I opted not to make that part more complex - as there was
no guarantee those changes would catch all of the oscillation cases.

Instead, when we're guessing where to move, and we would actually move
back to where we came from, stop travel, and give a message.

This should fix (and fuzzing seems to confirm) all of the travel
oscillation bugs for good, and it shouldn't affect actual good travel.
(Other than the player getting a YAFM in the occasional case of trying
to travel to a location with no travel path)
This commit is contained in:
Pasi Kallinen
2022-03-27 10:40:50 +03:00
parent 1d78d3c3f2
commit c763e26aa7
1 changed files with 9 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
src/hack.c
View File

@@ -1126,6 +1126,7 @@ findtravelpath(int mode)
int set = 0; /* two sets current and previous */
int radius = 1; /* search radius */
int i;
xchar guessx = -1, guessy = -1;
/* If guessing, first find an "obvious" goal location. The obvious
* goal is the position the player knows of, or might figure out
@@ -1231,11 +1232,15 @@ findtravelpath(int mode)
u.dx = x - ux;
u.dy = y - uy;
if (mode == TRAVP_TRAVEL
&& x == u.tx && y == u.ty) {
&& ((x == u.tx && y == u.ty)
|| (x == guessx && y == guessy))) {
nomul(0);
/* reset run so domove run checks work */
g.context.run = 8;
iflags.travelcc.x = iflags.travelcc.y = 0;
if (x == guessx && y == guessy)
You("stop, unsure which way to go.");
else
iflags.travelcc.x = iflags.travelcc.y = 0;
}
return TRUE;
}
@@ -1327,6 +1332,8 @@ findtravelpath(int mode)
ty = py;
ux = u.ux;
uy = u.uy;
guessx = u.ux - u.dx;
guessy = u.uy - u.dy;
set = 0;
n = radius = 1;
mode = TRAVP_TRAVEL;