Re: Wait States

From: Chris Herringshaw (
Date: 08/03/95

That's a very good idea, and would work quite well.  There does seem
to be some misunderstanding of the WAIT_STATE by some of the list
members.  Another solution would be an event driven system.  I coded
such a massive beast last year, and I posted pseudo code and the
generalization last fall.  I think my example was a thunderstorm
passing through the area.  Can someone who knows where the list 
archive is possibly repost this message by me?  It provides another
possible solution not only for delayed spell effects, but delays
and events in general.

Definitely not for the light of heart coder, though.

Thank you!

Christopher Herringshaw       | University of Michigan Medical Center
Special Projects Development  | 1500 East Medical Center Dr. B1-240TC             |        Ann Arbor, Michigan 48109-0704 |                  +0101 (313) 747-2778      

On Wed, 2 Aug 1995, Lincoln Chan wrote:

> Ok, check this out...wait state just puts a lagger on the character input,
> that's all!  It doesn't stop the mud or the character from running its
> subroutines.  Now, the closest thing I can think of which you can do is
> fairly complex.  It'd probably a living hell for you to code, but when
> finished, would accomplish what you'd want it to do...
> First, study the bloody affect_to_char'll need to understand
> how that works!  What you're going to do is essentially create a structure
> that's part of your char_data.  In this structure, you'll need to include
> what spell was casted, at who, and how much longer it has to wait.
> Then, you'll have to write a void routine which counts down everyone of
> these structures which exist on your character.  (See where the
> affect code comes in?  It's like counting down the duration of a spell,
> except in this case, you're going to run this countdown every 1 or 2
> seconds instead of 70 seconds.)
> Finally, when this "structure" gets "unaffected", you'll do a quick check
> to see if the victim is still in the room...and then fire off the spell
> that was waiting to be casted all this time.
> You *could* attempt to use the present state affect structure to do this...
> Add a new structure which basically lets the updater know if it should
> be updated every 70 seconds, or every 2 seconds.
> What it basically boils down to is this:  You cast 'instakill' on the
> victim.  You need to wait 2 seconds while your fingers twiddle to actually
> get this spell going.  Meanwhile, your target is dancing in your face
> and kicking your ass.  Finally, the 2 seconds are up, and after checking
> to see that the victim is still alive an in the room, you blast his ass.
> Simple...when you cast 'instakill', affect your character with some hokie
> "invisible" spell called "waitstate".  This spell duration counts down
> every second instead of every tick (thus, the duration of 2 would be gone
> in 2 seconds).  When the spell is unaffect_from_char, quick check...was
> the spell a waitstate spell?  Yes?  Then blast the victim!
> Heh, this sounds pretty confusing and all...but the hardest part is adding
> that small structure into affects that tells the mud if the affect is a
> 70 second per duration affect, or a 1 second per duration affect.
> After's all pretty easy.  Sorry for the long post, looks like
> I got carried away with this idea.
> linc aka Aladdin of Eternity DikuMUD
> PS: to clarify what I mean by using the existing structure, just use
>     af.modify to be what spell it is and add as a char_data...
>     Who knows, there are lots of cool ways to do this.

This archive was generated by hypermail 2b30 : 12/18/00 PST