----- Original Message -----
From: "Ronald Fenner Jr" <abbadon@MAC.COM>
> if your saying that your spec_proc does the actual movement I would
suggest
> that instead maybe you rethink your implementation of the system. for
> instance allow do_simple_move to handle all the movement for you and after
> it's moved the player check the room they are in and set the bit for the
> item if it's in their inventory. a spec_proc probably is not the best way
to
> do what you want to do.
You are describing exactly what I did. I did not recode the movement
commands, I invoked the existing ones. The problem is that the return value
of do_simple_move is ambiguous in certain cases. The comment states that it
returns 1 on success and 0 on failure. But it always returns 0 on
successful execution of a spec proc that handles one of the movement
commands. This represents an invalid assumption.
Here is the crude description of the call stack:
do_flee
-->do_simple_move
-->quest_stone
-->do_move
-->perform_move
-->do_simple_move
As you can see, do_simple_move ends up being called recursively and the
return value of the inner call is lost to the outer call. This is obviously
a situation that has come up before, because the need_specials_check
argument to do_simple_move exists to prevent an infinite loop in this
circumstance.
Perhaps a better method than putting my code in a spec_proc would be to
build in support for pre and post command procedures that one could
implement. Then my procedure would only get called AFTER a successful
movement command. Perhaps I'll pursue that one day, but for now I'll stick
with what I have. I would be surprised if I'm the only one putting movement
in a spec proc. Even if I am, I still think the return values in
do_simple_move need to be cleaned up. At least in the circumstance I have
described.
Mike
--
+---------------------------------------------------------------+
| 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