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.
ID:159172
![]() Apr 29 2009, 6:46 am
|
|
_> 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. |
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) Together with something like that and lowering the Lag time on walk_rand() it should be easier to test whether bumps occur or not. |
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
|
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.
|
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) Obviously, this does not take into account having future calls to it override past ones. |
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. |
sorry for the bump, bad pun....
var/dirs=pick("NORTH", "SOUTH", "EAST", "WEST", "NORTHEAST", "NORTHWEST", "SOUTHEAST", "SOUTHWEST") var/dirs=pick("NORTH", "SOUTH", "EAST", "WEST", "NORTHEAST", "NORTHWEST", "SOUTHEAST", "SOUTHWEST") neither one call bump() for me atall. |
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. |
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).
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.