Re: [CODE] spec_procs vs. events

From: Mike Breuer (
Date: 09/12/01

----- Original Message -----
From: "Ronald Fenner Jr" <abbadon@MAC.COM>

> Your best bet is to modify the spec_proc to a function with
> it only really needing to look at the room after the characters is moved
> not. perform_move is probably the best place to put a call to it.

Thanks for your advice.  I agree this is the quickest way to implement what
I am looking for while staying true to the current design.

I do not like the idea of having to place extra code in the movement
functions to handle one specific kind of object.  It is inefficient, and it
does nothing to advance the flexibility of the code.  I'm looking for a
cleaner solution.

What I am considering doing is modifying the spec_procs to make them into
event handlers, rather than simple procedures.  To lessen the impact in the
procs themselves, I will probably use the various assign procedures to
register "interest" in handling particular events.  I will probably have to
add a parameter to the procs indicating what the calling event is, so that
procs that register interest in more than one event can handle them
differently.  Events would probably be (off the top of my head):

EVENT_PULSE                  (1 << 0)

/* For convenience: */
EVENT_NONE                 0
EVENT_ALL                  0xFFFFFFFF /* 64-bit: 0xFFFFFFFFFFFFFFFF */

Only mobiles would receive EVENT_PULSE.  These changes could also provide an
opportunity to clean up the existing code by eliminating the need for "if
(cmd)" or "if (!cmd)" which appears near the top of many spec_procs.  This
system is much more flexible, and would even improve the efficiency of the
code slightly.  It would be nice if ACMD had a return value so that I could
have separate events for success and failure on the POST_PROCESS, but that
will have to wait for another day.  Any thoughts?


   | FAQ: |
   | Archives: |

This archive was generated by hypermail 2b30 : 12/06/01 PST