> This might not work at all and you will want to add some sanity checking to
> make sure the victim isn't dead but have you tried (GET_FIGHTING(ch))
> instead of victim? I did this once and if I remember right it worked..
> Alittle differant of aa situation (I was using it for challenges in my
> Gladitor System..)
>
Just a general comment, since it looks like you're fairly aware of
the issues for the ice/etc damages, and in the vein of this last comment.
Watch out when you modify the fight system. It was designed with
the idea that all damage would be dealt out but once. There are no checks
for things like a dual weapon causing death, or an attack # less than the
total # of attacks doing the same thing. These will probably crash when
the attempt is made ot reference a free'd pointer. Of course, say they
flee, and combat continues, you'll have the odd circumstance where people
take damage from combat while not even in the room.
To be safe, anything which causes damage during the fight should
be folded into the one singular damage statement. It's a bit of an ugly
hack to go with the current code, to show misses, but still cause damage,
and then display a secondary (ice shield, etc) message - but it can be
done with some effort.
I was curious if anyone out there had created any other sort of
combat systems which don't have these potentially annoying situations? I
(you should have seen this coming) have written up one myself, but it's
still being beta-tested. My main concerns were twofold; crash & other
'wrong' situaiton avoidance, and pretty-printing of the combat messages
(catenation, or only flagged events - death, damage over certain #, etc).
Simply, I just have an event queue which is generated, and then
discharged. If someone dies or otherwise invalidates remaining events,
all events with themselves as the victim, or causer are removed. You can
also add events to the queue (say, someone parries, etc). The events are
actually just individual damages actually - the part responsible for
displaying messages is seperate and runs on a queue of "executed" events
(they're not tossed out - they're queued for description output - which
comes later).
Any other paragraph descriptions of ways around this?
PjD
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 04/10/01 PDT