Was: Xapobj and houses Now: mobile_activity is bad!

From: Patrick Dughi (dughi@imaxx.net)
Date: 09/19/99


> >     log("SYSERR: Illegal value(s) passed to obj_to_room, object=%x room=%hd
> > top_of_world=%hd", object, room, top_of_world);
> I figured out something more .. the objects that was saved in the house
> was bad. So I deleted the objects and saved some new into it(basicly put
> some breads into a house). Then there wasnt any error-logs, but none of
> the object was loaded on bootup. Is the patch even combatible with
> houses, as I cant figure out why it wont load!
>

        Hm. I never did test the house objects.  I suppose I can go back
and see if they work, in which case I'll release a patch when my company
isn't flying me from portland to san jose to austin and back.  I'm sure
though, the fix is simple.  I would bet that the problem stems from the
fact that xap objects is made to generate a rent file, with the rent type
(normal, crashsave, etc) as the first thing.  Perhaps it would be a good
idea if you experimented with removing those dependancies.

        In other news, I found ..well.. I delt with what had become an
increasingly annoying problem.  Basically, the problem was
mobile_activity.  That's not to say the problem was _in_ mobile_activity,
but rather that it had a design flaw.

        Mobile activity contains a simple for loop, with the added cavet
that instead of iterating to ch->next, it saves ch->next in a var and then
iterates to that.  This is so a mob can concievably
extract/purge/otherwise kill itself.  However, the problem that is left -
what happens if a mob extracts/purges someone else?  No problems, except
for that we're saving the value of 'next' before we operate.  This could
in some circumstances become an issue as we opetate on a mangled pointer.
We can't work off the current mob else we loose the ability to have a mob
purge itself.  So, there's a few solutions;

1) never extract chars in a spec-proc, or via mob actions in
mobile_Activity, except ones self.
2) queue everyone to be deleted and deleted them in a seperate loop.
3) think of something more inventive.

1- too limiting
2- mobs that ought to die can still fire off actions before they croak -
  You'd want to add a flag for ability to do mobacts or not... maybe some
higher level sanity checking too.

3- i thought up something more inventive, but barely so.  I changed mobile
activity to work on a given char_data struct.  Instead of just running
through the list, I have a follow_type struct list which contains all
npcs.  Because I'm currently allocated/deallocating this list each time I
run through it (which may not be efficient, but it was just a test.. i'll
make two or more lists later so it will be efficient) i can just do a
'while(head-of-list)'.  Each call to extract_char automatically removes
its entry from the list, so, we don't have any problems at all with
referencing the next valid item.

        This is kinda neat, and sides, is something everyone should be
aware of.  Bout to run off to the airport, but I thought I'd through this
one out to those of you to whom this is important.  That would be the
small group of people who dislike having the mud crash.

        I'll whip up a patch for this in a bit, when I can find some way
to make it better.
                                                        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 : 12/15/00 PST