Fiddling with pathfinding

[ewert]

Ok I like streamlined superfast playstyles, and couple things about the pathfinder annoys me. I will just try to make the changes for myself if nothing else, but please feel free to give feedback / opinions / ideas.

Search range:
Computing power is insane nowadays. Is there a reason it is limited? Why do I have to manually run through explored areas to be closer to unexplored ones to auto explore again? Total MEH, will try to find where this is set to put it to 255 or something. My first glance found a max_pf_radius set to 100, but I swear it is much less in the actual explore function, will have to check further. Especially since I can mouseclick muuuuch further (I assume the actual 100 radius 500 path steps max).

Doors:
I think having the autoexplore be "careful" isn't really the best option, I prefer it to be autoEXPLORE not autoexplore-but-nah-lets-not-look-behind-that-door-ever. Carefulness should be the player, not the pathfinding algorithm. I already made a shortcut for opendoor next to my explore button, but problem is the autoexplore won't even stop next to the door easily always ... To be honest, for myself, I'd be happy if the explore automatically stops next to a door, but if you press it again (or for first time) NEXT to a door, it will open the door and proceed from there until disturbed as usual. Or at the minimum, if it finds and stops next to a door, if there is no explorable areas found on next action, open it and proceed from there.

Traps:
The autoexplore is sometimes obviously super stupid when it comes to bypassing trap grids. You can literally be next to an open corridor spot next to a trap, and it returns a "confused" message if you try to explore again. Maybe this will be getting too complex for a basic explore function to change though, so not too fussy about this one. MAYBE a "if pathing step = trap, check if any grid next to step1 are empty as well as next to step2 and use that". Again though, not a big issue.

Lets see what I find in the code ...

[ewert]

Ok dungeon level generation says max width is 198 and height 66, and if pathfinding uses radius/2 for max NWNESESW corners of pathfinding region, setting the radius to 400 ought to cover the whole levels. XD

[ewert]

Or ... update my game to the newest version, it seems the pathfinding code was changed? XD Will see how the newer one works...

[ewert]

Ugh. Automelee taken out, autosteponitems taken out, stops at first "explored" spot instead of until interrupt. This is so much worse, ouch... Why these major features taken out?

[ewert]

Looking at my old files vs new one, I think this part is the one that fixes exploring at least a bit:
/* Ewert: if second to last step, run it */
if (path_step_idx == 1) {
player->upkeep->running_withpathfind = false;
run_init(path_step_dir[path_step_idx]);
}

Would need formatting to the new code though.

Now I am wondering which version I had saved on my computer to play with, I thought I just had some older release as I don't currently have mingw installed and could not have compiled my personal versions. But maybe I just had a personal compiled version saved...

[Martina25]

I think your ideas for improving the pathfinder are on point. I especially agree that the max_pf_radius limit feels artificial. Maybe bumping it up to 255 is a good call if computing power allows it. Worth digging into the code, as it seems the algorithm behaves differently in practice than the settings suggest.

About the doors, that’s a solid idea to make autoexplore more dynamic. Maybe try adding a condition in the code for autoexplore to continue if the next action is opening a door? I’d do it like that myself. Good luck experimenting!

[ewert]

Gah, having trouble getting mingw etc. working on Win11, the instructions don't work as the .sh files won't run etc. ...

Anyone using mingw on win11?

[ewert]

Could get the Makefile.msys2 compiling when using msys, but no luck on the windows ones for win11/mingw/msys2 ...

[ewert]

Well, have compiling working with visual studio on win11, so there's that.

Something really weird going on with doing a while-loop for the explore, it won't trigger stopping when monsters seen which is ... I guess could be if the disturb/return within run_step just returns back into the loop, maybe.

Also, current nearest_unknown / pathfinding seems to be dungeon wide in the code now, and super "powerful" in that it even calculates "true" distances to all spots every time. Which is, umm, quite excessive for this purpose and even causes a slowdown sometimes. But maybe the problem is the while-loop ... will fiddle more. XD

[ewert]

Something weird going on that I can't figure out, if I put the find_nearest_unknown / move to it into a loop, the check for visible monsters doesn't work either within the loop or within the run_step command. It will just move through monsters.

Also, where is this annoying delay coming from, I have both base and movement delays set to 0ms, but the char is still moving with a very visible speed. I tried searching the source files, but couldn't find where a Sleep is called for it in the movement code. Only one I found was a 20ms sleep in one of the term event stuff for now, but putting it to 0ms didn't remove this delay.

The delay allows for holding a keypress down to "interfere" with last command, which is really strange. As in if I keep a non-repeating explore button down, if it is trying to go through a corridor it will actually interrupt the run...

I feel like maybe this strange activity where the function is seemingly not being done "in order" might be the cause if I loop the explore ... gah.