much better running in tunnels

[tiger_eye]

EDIT: new patch in reply below. It has slightly better running behavior, correctly handles interesting NPCs (which are the ones that can chat), and runs around known traps in tunnels if possible.

I attached a patch to make running in tunnels (via 'shift-direction') much more robust. I think I tested it thoroughly, but this is actually kind of tricky, so PLEASE, PLEASE, PLEASE try this out and let me know if you find anything odd.

Also, other actors no longer behave as terrain that block or control your movement. You will run right past or right through other characters. [EDIT: snip]

Below is a graphical summary of running behavior:

Code: Select all

# = wall
. = floor (untraveled)
! = edge of map
@ = friendly NPC
o = run path
x = end of run path
|/-\ = starting position and direction

####
#ooo
#o##
#o#
#|#

.###
#x..
#o##
#o#
#|#

####
##oo
#o##
#o#
#|#

##o#
##o#
#o##
#o#
#|#

###o#
###o#  
##o##
#o##
/##

####
##o##
#o#o##
/###o#

!####
!oooo
!o###
!o#
!o###
!ooo-
!####

#######
.......
###x###
###o#
###o#
###|#

#######
..@....
###x###
###o#
###o#
###|#

########
-oox....
####.###
####.#
####.#

#######
ooo....
###\###
###.#
###.#

#######
...|...
###o###
###o#
###o#

#######
..\....
###o###
###o#
###o#

###.#
###.###
.......
###x###
###o#
###o#
###|#

###o#
###o#
###o###
...o...
###|###
###.#
###.#

###.#
###.#
....#
###x#
###o#
###o#
###|#

###o#
###o#
###o#
...o#
###|#
###.#
###.#

#####
oooo#
###|#
###.#
###.#

Please note that when a tunnel branches, the player stops before the branch. This is obviously for safety reasons (you don't want to be exposed, do you?). After stopping at a branch, a player may immediately run in any branch direction. This is for convenience. For example, this is why the following is allowed:

Code: Select all

###o#
###o#
###o###
...o...
###|###
###.#
###.#

and

###.#
###.#
###.###
....ooo
###/###
###.#
###.#

and even

###.#
###.#
###.##
....o##
###/#o##
###.##o#
###.#

Is there any other behavior you want or don't want? Much of the behavior listed here is actually new, so, again, please let me know if you encounter anything weird with it (hopefully you won't).

[Susramanian]

Wonderful! The poor running in ToME has been bugging me since the start.

I just Just tested it some, and didn't find anything obviously wrong. One thing that might be nice would be to treat known traps as walls for the purposes of interruption and pathfinding. So we get stuff like this:

Code: Select all

####
#^oo
#o##
#o#
#|#

[tiger_eye]

Thanks for testing it out, Sus!

One thing that might be nice would be to treat known traps as walls for the purposes of interruption and pathfinding.

Hmm, I do see your point: why not just run around traps rather than stopping at them? There is, however, a possible drawback, such as the following (running past a trapped branch):

Code: Select all

#o#
#o###
#o^..
#o###
#|#

I'll look into finding a good solution to this; thanks for bringing it up. Anything else?

[martinuzz]

Maybe you can incorporate the mechanic that makes you stop once on an item, but continue running over it the second time;
Stop once at a trap, treat it as a wall the second time. It would not completely solve the trapped branch problem, but at least give the player the option to explore the branch the first time he runs by.

[marvalis]

The logic is simple: you should only continue if the traps is in a corner. In all other cases you should stop (except when you are in a room: 5+ walkable squares next to the trap). Checking if the trap is in a corner:

If there are two passable terrain next to the trap
then
local x=passable_square1.x-passable_square2.x
local y=passable_square1.y-passable_square2.y
if x,y=-1,1 or x,y=1,-1 or x,y=1,1 or x,y=-1,-1 then continue to run without stepping on the trap
else stop walking
end
end

Something like this? It would require two functions, one that checks and returns the number of walkable squares around the trap, and another that returns the x and y values of those squares.

I have no idea if this is possible, just thinking out loud.

[tiger_eye]

Okay, I think I can rig something up for traps later today. This will merge a little what the engine is supposed to take care of and what the module is supposed to take care of, but it should mostly "just work" and not be too much of an issue for other modules.

btw, marvalis, with your logic the following would happen even though it's possible to run around it:

Code: Select all

##.#
##.#
#^.#
#x##
#o#
#o#
#|#

The point is that, you know, this is tricky, but I think I have an easy(-ish) solution that will run past the above trap and stop for the below trap:

Code: Select all

.####
#^...
#x###
#o#
#o#
#|#

[marvalis]

Nice, yes I never really thought about that.

[tiger_eye]

New patch!
I'd say this is ready to be added to svn. This patch includes a few key improvements over the last one:

(1) Slightly modified the running rules to correctly handle a couple more configurations.

(2) NPCs are interesting (or "noticed") if they can chat. There is no need to add "notice = true" to their entity.
and
(3) Run around known traps in tunnels if possible! (if you're interested, I used a "phantom step" into the trap followed by the usual checks to accomplish this)

[tiger_eye]

One teeny, tiny tweak to correctly handle the following situation:

Code: Select all

####
#ooo
#o##
/.#
###

Third time's the charm, right? I think this is ready for prime-time.

[tiger_eye]

Corrected a couple oddities that resulted from dodging traps. Also, running will now stop for stores...

...and somebody is going to have to explain to my why stores are treated as traps in the code!

[tiger_eye]

Aw crap, not all stores are "trap" stores. The following patch will notice all stores.

[darkgod]

Thanks!
Applied