Re: [BUG]Bug in stock do_quit

From: Patrick Dughi (dughi@imaxx.net)
Date: 01/01/01


> Still, though, it occurred to me that this sort of thing has in the past
> caused problems with various different patches and snippets (most
> notably DG Scripts trying to reference a mob after it has been freed).
> It occurred to me that this could most likely be prevented if the
> freeing up of the character structure were delayed for a relatively
> short period of time, sort of a delayed clean-up.  Something like that
> could easily be accomplished by doing something like the following...
>
        Somewhere in the list I actually posted that this was a common
problem - not just for dg scripts but even things like mobile activity
where a mob action results in an immediate death (especially possible in
spec_procs and the sort) - or other alterations to the validity of a
potentially saved pointer to a character structure (think mob/char lists!)

        So, it did what you were suggesting, and just put them into a
seperate 'to be extracted' list.  At the end of each pulse, after
everything else had ran, THEN they'd be extracted for real.  As for
references saved in lists and the sort, it was done with a simple queue -
pop the top one off, run whatever it does - anytime a mob is extracted
remove him from this queue and put him on the 'to be extracted' list.
That way we don't look for the 'next' mob in the queu, we just keep
popping the top one.  If a mob completes his activities and isn't
extracted, put him in a new queue.  Pretty easy, but requires some changes
mostly in mobile activity, and fight.c, and of course, extract char.

        But, i did post the code a while ago.

                                                PjD

--
   +---------------------------------------------------------------+
   | FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
   | Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
   +---------------------------------------------------------------+



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