do_simple_move returns one if the call itself succeeded -- that is, do_simple_move's procedure ran completely and the character moved in the direction: whether the player actually moved or not is irrelevent, do_simple_move returns its own success or failure to complete. If a spec proc overrided the move by doing its own thing and returning '1', then the call definitely failed because it was blocked intentionally by a spec proc (ie: a guild guard). do_simple_move is not responsible for the activities of special procedures it calls... that is: the return value regards do_simple_move, not its children. Move procs are particularly for things like guildguards -- that is, to block movement, not to cause it. > Since do_simple_move is making calls to spec_procs, it needs to handle the > case where the proc causes the players to change rooms. I cannot do it > using return values without significant redesign. Spec_procs return nonzero > if a command was handled, 0 otherwise. This does not indicate whether the > player moved, only that the command was handled. A case in point would be > the guild guards which conditionally disallow movement in a particular > direction. A return value of nonzero in that case indicates that the player > did NOT move. No.. a spec proc returns 'TRUE' to override or block the normal action.. a spec proc returns 'FALSE' to allow the movement and normal activity to continue - whether an action was 'handled' is irrelevent. It is unnecessary and excessive for a proc to implement the move themselves -- it's almost like the object picked up the player and dropped them in the target room, sure they won't be penalized for fleeing, because if the proc is returning 1 then it is choosing to override the normal behavior. -Mysid -- +---------------------------------------------------------------+ | FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html | | Archives: http://post.queensu.ca/listserv/wwwarch/circle.html | +---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/06/01 PST