well therein lies a problem :) as i was ploading and deleting imms that hadn't
logged in for over a month, and one of those imms was the problem pfile, which
i ended up just manually deleting a little while later, so that pfile is no
longer around... but here's the odd thing... within the pfile, the nesting
values were correct... the container object (that had previously been deleted
via olc weeks ago), was given a nest value of 0, as it was in his inventory...
the other few obj's, the first of which caused the mud to go into a loop, were
all nest value 1... but the weirdest thing is that the mud never hit the line
of code where the new rgObjNest slot was assigned... at the very beginning of
the for loop, where it does the initial create_object instance based on vnum,
that's where the rgObjNest slot got overwritten... later on through the program
flow is where it actually read the nest value of that item, which is why it
went into a loop... it saw itself in nesting slot 0 (after it overwrote that
slot), and then read in its own nesting value of 1, and tried to assign itself
to its own contents, as it checked for what was in nest position 0 and saw
itself there... i've since attributed this to some funkiness that was going on
w/ the server earlier... i have no clue if this is related, but someone's mud
went into a loop of its own and was eating around 99% of the processor for a
few hours, and among the bugs i experienced during that time were the
aforementioned pfile bug, plus things that have worked fine for years suddenly
screwing up, like when i would type "load obj 110" and it would display the
syntax as if i'd done something wrong, and one time it actually crashed on me
(and no, there's nothing wrong w/ object #110 :D), and my help command going
screwy as well, where i couldn't display help for anything, even 'help a' would
say no help files were found... anyway, i'll wrap this email up, and if it ever
happens again, i'll be posting right back here w/ details about it :)
Richard Lindsey.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Mon 7/12/2004 7:56 PM
To: Richard Lindsey
Cc: [email protected]
Subject: Re: rgObjNest corruption...
> but once this create_object line executes for the first
> content object, right after that, doing a "print rgObjNest[0]->name"
> results in the name of the object that was just created
That should only happen if the Nest was set to 0, as shown by this line:
rgObjNest[iNest] = obj;
So if the inner object is properly set with a Nest of 1, it will show up
in rgObjNest[1]. If it doesn't have a Nest of 1, it's not inside of the
container.
Just out of curiosity, is this the same pfile that keeps doing it? Does
it
happen on a specific object entry? If so, post the relevant object.
This sounds to me like it might be a problem in the pfile.
