ID:159172
 
I was wondering, does walk_rand automaticly avoid dense area's?
I have a Bump() proc set up correctly on my NPC that walk_rand()'s, however it NEVER seems to call bump.
Rushnut wrote:
I was wondering, does walk_rand automaticly avoid dense area's?

If such behavior was present it should be explicitly noted in the Reference entry, so I'd say no. It just causes randomly walking (although IIRC it does bias toward stepping in the movable's current dir, but that isn't really related to the matter at hand).

I have a Bump() proc set up correctly on my NPC that walk_rand()'s, however it NEVER seems to call bump.

Well, 2 options instantly come to mind
1) You might have done something [wrong] in Bump() that makes you fail to notice any effects of bumping.
2) You, very simply, are only experiencing the randomness in effect. In other words, you're being unlucky.
In response to Kaioken
_> Yea sure, not even I am that unlucky :O

Unless I really am that unlucky, then it MUST be the walk_rand, I'm 98% sure that my coding is correct, the 2% is for spelling mistakes ;)
For the love of all that is good and holy, build a 3x3 prison with the random walking mob in it.

And TEST it.
In response to Rushnut
Rushnut wrote:
I'm 98% sure that my coding is correct, the 2% is for spelling mistakes ;)

(At least 75% of spelling mistakes would probably prevent you from compiling in the first place :P)
I don't know what you have now, but it's very simple to just use a replacement Bump() override to indicate whether a bump occurs or not. e.g.:
atom/movable/Bump(A)
world << "[src] has just bumped into [A]."

Together with something like that and lowering the Lag time on walk_rand() it should be easier to test whether bumps occur or not.
In response to Mysame
Yet another option to make it easier to test. Personally I'd be too lazy to mess with the map to do this and later revert it, tho, :P
In response to Mysame
I have, bump is not called once
In response to Rushnut
Then isn't that a clear answer?
Seriously?
In response to Rushnut
Provided you've indeed called walk_rand() properly when doing that, there could well be some sort of problem in BYOND (or its documentation if you will). Do test it with a simple foolproof override like in my previous post. It's also possible to test whether a proc (Bump()) runs by using the world profiler in advance.
In response to Kaioken
I was fairly certain from past experience that it does avoid dense objects. I just did a quick test just to be safe, and yes, walk_rand does avoid dense objects.

4x4 world, dense turf around the edges, me in one of the non-dense corners, created a mob in there and had it walk_rand(it, 1). It runs around the 3 available tiles like a maniac, never triggering Bump, but when I bump something, I get my test output.

I would think this is desirable for walk_rand(), as it makes sense for it to avoid blockages. Besides, it's extremely simple to make your own walk_rand_dontAvoidDensity(), but not as easy to make one that does avoid it.
proc/walk_rand_dontAvoidDensity(source, lag)
while(1)
step(source, pick(NORTH, SOUTH, EAST, WEST)) // extend that if you want NE,NW,SE,SW
sleep(lag)

Obviously, this does not take into account having future calls to it override past ones.
In response to Loduwijk
Loduwijk wrote:
I would think this is desirable for walk_rand(), as it makes sense for it to avoid blockages. [...]

Correct, but regardless, a behavior of this significance should be noted in the documentation - more so, it the documentation shouldn't imply the opposite, as it currently does. So, of course, they should patch up that Reference entry.
In response to Kaioken
sorry for the bump, bad pun....

var/dirs=pick("NORTH", "SOUTH", "EAST", "WEST", "NORTHEAST", "NORTHWEST", "SOUTHEAST", "SOUTHWEST")
src.Move(dirs,dirs)


var/dirs=pick("NORTH", "SOUTH", "EAST", "WEST", "NORTHEAST", "NORTHWEST", "SOUTHEAST", "SOUTHWEST")
step(src,dirs)


neither one call bump() for me atall.
In response to Rushnut
And none should, since no movement attempt is ever taking place. The arguments you're using for both procs are wrong (in more than one way in Move() - look it up and see what the first argument should be).
Directions are numbers* (in bit flag 'format'), not text strings, so those are all invalid dirs.
*: The symbols NORTH, SOUTH etc are built in macros that turn into the respective numbers when they're compiled (or, they may be constant vars instead). Of course, using a text string that happens to contain one of their names is entirely different, and is still just that, a text string, like any other.
In response to Kaioken
Okay, now the step() one does bump. Thanks. my doors finally work!