Long walk (Shift-Dir.)

[Yermak]

I request a short change for Long walk.
Imagine you pressed Shift-RightArrow from this position and the corridor appeared to have a dead-end:

  Code:

#.########
#@........
##########


Right now you will stop like this:

  Code:

#.###########
#..........@#
#############


I ask for it to be this:

  Code:

#.###########
#..@........#
#############


Another two examples of how it should work (just in case):

  Code:

#.########    #.###########
#@........ -> #...@.......#
#.........    #...........#
#########     #############


  Code:

#.########    #.###########
#@........ -> #..@........#
#.........    #.........###
#.......#     #.......###
#.....###     #.....###
#...###       #...###
#.###         #.###
#.#           #.#


In other words, if during your long walk you came to the point (that is not your starting) from which you would stop receiving new information about the map, you should stop at this point.

[Lasty]

I would hate to remove the ability to shift-dir through explored territory, but I would like it if shift-dir stopped when exploring new territory and finding a dead end.

[johlstei]

Isn't the whole map a dead end once you've explored it? There's definitely room for improvement here, but what you are truly asking for is more ambiguous than you give it credit for.

[Yermak]

I would hate to remove the ability to shift-dir through explored territory.

Isn't the whole map a dead end once you've explored it?

if during your long walk you came to the point (that is not your starting) from which you would stop receiving new information about the map, you should stop at this point.

Probably, I should've stated this more clearly: "(the first such point isn't one you started to move from)".

[Quazifuji]

Isn't the whole map a dead end once you've explored it? There's definitely room for improvement here, but what you are truly asking for is more ambiguous than you give it credit for.

I don't think so. If, during a long walk that is revealing unexplored tiles (does not apply to a long walk through explored tiles), a point is reached such continuing the long walk will not reveal any more tiles, the long walk is immediately ended. I don't know how hard this is to code, but I'm fairly certain it's not ambiguous.

[Patashu]

Isn't the whole map a dead end once you've explored it? There's definitely room for improvement here, but what you are truly asking for is more ambiguous than you give it credit for.

I don't think so. If, during a long walk that is revealing unexplored tiles (does not apply to a long walk through explored tiles), a point is reached such continuing the long walk will not reveal any more tiles, the long walk is immediately ended. I don't know how hard this is to code, but I'm fairly certain it's not ambiguous.

The algorithm is simple to describe and unambiguous, but I don't know if it is easy or hard to code.

If, in the direction you walk, a wall appears...
...And the wall's edge* can be followed, in both directions, until it reaches the line running through your character diagonaldicular** to your line of movement before it has run out of LoS...
...Then stop exploring.
....Else, keep checking every tile ran until that run ends.
*Boundary between wall and room.
**If running diagonally, perpendicular. If running orthogonally, 45 degrees either side of the line of movement. Sorry, I don't know of a better word so I made one up.

Basically, the goal is, if there's a side passage I could explore, run until it would start to be a waste of steps if I decided I wanted to go down that side passage.

Some worked examples:

  Code:

1.

#.########    #.###2#######
#@........ -> #...@00000001
#.........    #....2......#
#########     ######2######

0 is the line of your travel.

The discovered wall in your running direction is 1.

2 is the lines at 45 degrees to the line of your travel.

The boundary between wall and room, traced from 1 in both directions, passes line 2 before it is followed out of LoS, so stop running.

2.

#.########    #.###2#####.#
#@........ -> #...@00000001
#.........    #....2......#
#########     ######2######

In this case, tracing from 1 counterclockwise around the room, we find ourselves falling out of LoS before we have passed line 2. So, we keep running for now. (This will be rechecked every tile.)

3.

#.########    #.###2#######
#@........ -> #...@00000001
#.........    #....2......#
#####.###     ######2.#####
                     2#

In this case, tracing from 1 clockwise around the room, we find ourselves falling out of LoS before we have passed line 2. So, we keep running...

#.####2######
#....@0000001
#.....2.....#
#######2#####
      #.2

Now tracing from 1 CW around the room we fall out of LoS after we have passed line 2. So we stop running here.

4.

#.#########
#.@........
#..........
#..........
#..........
#.........
#.........
#........
#.......
#.....

->

#.#########6
#.........3#
#........3.#
#.......3..5
#......3...#
#.....@22222
#....320...#
#...3.2.0..#
#..3..2..0.#
#.3...2...04
#65###2#4##1

0 is the line of travel, 1 is the detected wall in line of travel, 2 is 45 degree angle lines, 3 is 90 degree angle lines (nearest diagonal).

If an opening in the room was at 4, I would want to keep running.
If an opening in the room was at 5, I would want to keep running.
If an opening in the room was at 6, I would want to stop running.

[Tedronai]

I really like this proposal, but I have the feeling that minor things like this are only implemented if you do it yourself and submit it as a patch.

Thus I tried implementing it myself. The approach I used is as follows:

"If you discover new cells and none of the new cells is DNGN_FLOOR then stop"

As far as I can see this could be added in the function runrest::run_should_stop() in travel.cc since this function is called when "long walking" and not when auto-exploring.

However I ran into a problem: When I check if cells are "new" both known() and seen() always return true. This is probably because some other part of the program marks them as known before run_should_stop() is called.

Are there different approaches for finding out which cells have been newly discovered? Or should this feature be added in a different part of the code?

If somebody wants to have a look, relevant files should be travel.cc and map_knowledge.cc for the most part. I'd be grateful for any suggestions on how to implement this :) (I'll have another look this evening)