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 xxviper@umich.edu | Ann Arbor, Michigan 48109-0704 http://www.umich.edu/~xxviper | +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 code...you'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 that...it'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 af.target 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