Re: Using DG_Events to make Spell Casting Events Timed

From: Tseran (Tseran@SubDimension.com)
Date: 09/10/02


> The grand goal is to move to an event-based structure for a number of
> processes.  Combat rounds would be event based, allowing differing speed
> of weapons (and spells which enhance the speed of your attacks, for
> example).  Special attacks in combat would be event-based, allowing
> regular combat to be put on hold for the really impressive attacks, or
> just having a delay to other commands for the weaker ones (a flying
> dragon death spiral move would take far mor concentration than a kick to
> the groin, and be much more deadly, of course).

Lofty goal, something I plan to do myself.  I already have the framework
in place where all actions check to see if the character is doing
something that would interfere with what they want to do, if they are,
it says forget about it.  I personally love the idea, as I am quite
familiar with the event setting up code (see the CircleMUD Resources web
page at cmrsrc.8m.com and you'll see what I mean, been using them since
they came out years ago)

> The thing I want to work on first is a spell-casting system.
> Essentially
> I want cast_magic to to hand off to an event, which would then make a
> call
> to call_magic (assuming it was not interrupted, more on this below).
> I'm
> working with a mostly stock spell system here.  I want to change the
> system to events, then modify other aspects of it.

This is how I have my system set up as it stands:

1> at the end of do_cast, it checks if the caster is doing something
other than a spell, perhaps in the middle of combat.  If they are, it
sets up a start spell event to go off when the other event is over.
Otherwise, it starts the spell event immediately.  Why did I do this?
If the player is in the middle of combat, and hitting someone, they will
keep hitting them, and if it checks to see if they are doing anything,
and it keeps seeing the combat event queued, it will never cast.  So, in
this case, even if it sees the combat event, it will still queue up the
spell, and then when the combat event tries to re-queue, it will see the
spell event and hold off.

2>  In the start spell event, all the checks for target are placed
there, so that it can verify if the target is still in the room, or if
the target is still valid at the start of the casting, since by the time
the other event may have died, the target may no longer be valid.  This
is also where the mana is eaten up, and it is determined if the spell
casting is a failure.  If it suceeds, it makes another event, the
spell_event itself.

3> In the spell event itself, I have another check for targets (I may
end up doing a simple target check function to save on space, since I
don't want the code doubled when I don't need to) I do this second check
because again, during the casting time, the target may not be valid
again.  You never know what targets these days are gonna do.  Some of
them are called mobiles for a reason ;)  At this point, if all the spell
checks work, it will let the spell pass on to cast_spell.  Then the
magic will run its course.

I use the same event struct in the character for both the casting and
the start event, I just replace one with the other in the start_spell
event.  Then, in handler.c, in extract_char, I have a whole bunch of if
(EVENT(ch)) { event_cancel(EVENT(ch)); } lines for each event attatched
to a character.  Also, don't forget at the load of a character and in a
read_mobile to set all the events to NULL, otherwise you may end up with
some attempts at addressing the wrong memory locations.  As to being
damaged, that is something I put into the damage routine, it checks to
see if there is a casting event queued, if there is, it has a chance of
misfire, depending on the amount of damage taken, and then if it is, it
cancels the event and does a misfire...which has some fun events
itself.  Take a look at the website listed, there is a simple sample
event there, one that came with the dg event code, as well as one I put
together to make zone resetting event based, since that is a waste of
processor time as it is in my opinion, checking every few seconds when
the zones usually take several minutes to reset.  Also, the less
cluttered your heartbeat is, the easier it is to ignore that file ;)
Oh, and if there's any doubt as to how well I know my DG events and DG
scripts, remember the name on the web page, which was mentioned in the
dg scripts pl8...since some of the stuff in pl8 was taken from that
page ;)
--
Now with PGP Encryption!  Ask for your public key TODAY!

--
   +---------------------------------------------------------------+
   | FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
   | Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
   | Newbie List:  http://groups.yahoo.com/group/circle-newbies/   |
   +---------------------------------------------------------------+



This archive was generated by hypermail 2b30 : 06/25/03 PDT