Re: [flame] [new proto allocation]

From: JTRhone (
Date: 02/17/97

> I'm a bit wary of realloc.  The man page (tiny little thing) seems to
> indicate that the data in the block you're reallocating may or may not be
> moved.  It seems like that could cause some problems with pointers to that
> data.  Do you update every relevant pointer, or is this simpler than it
> looks?
> Sam

Let's chat about a particular proto list for now, say obj_proto list.
Well the most obvious pointers that come to mind to me are the strings
that say the obj_proto list points to for each object.  Since all the
loaded objects in the world (for the most part, excluding mail and other
obscure objects) are pointing to the strings on the protos, it's pretty
important that we make sure those pointers are not violated during a
realloc.  Thinking about it though, I realize that those strings are not
part of the proto list, they're somewhere else in heap world, so even if
the obj_proto list is moved (which I would assume is very possible,
especially on the first realloc after bootup) I don't think those strings
are something to be worried about.  What I would be wary of, and have
been, is not to keep any globals hanging around which relate to specific
addresses of any part of the actual obj_proto list itself.  For example,
if I had kept a global object ptr around pointing to obj_proto[4], if that
obj_proto list was moved, like you pointed out, there would be a problem
later on when we tried to reference it.  Hopefully any pointers like these
are pointing to specific instantiations of the object and not pointing
to the obj_proto itself.

In an olc sense, say you had something like
which was a ptr to the mob_proto that ch was last editting, so they could
just type some shortcut and edit the last mob they were workin on.
In that case, there is definitely a potential problem if the mob_proto
list is moved by realloc.  Heh, a better way would just be to have an int
on pc_specials, containing the vnum of the last editted mob.

This is all rhetoric I think, I have been trying to think of specific
cases where examples like that come into play.  I have searched too,
through the code to some degree, but havent found anything that would
choke if a proto list was moved.  Good point though, gives me some more
potential bugs to hunt for :)


Such as there is a mobile_activity() function which scans thru the
character_list every few pulses and makes mobs do nifty things, I have
added similar functionality to rooms, objects and zones.  An neat example
of how this can be fun is with the environment capabilities if one scans
through the room list and checks for certain room flags at predetermined
intervals.  For example, drifting objects (or sinking whatever).  Every
scan through the list, check any room that is flagged with some type of
WATER, and check it's contains list for objects that float, sink or drift
depending on the objects flags and their weight.  Say I find a 30 pound
sword that is not flagged BOUYANT and is sitting on top of a pond.  I
check some things, such as the rooms->sink_to vnum, convert it to rnum,
validate it, then drop the object to that room, with appropriate messages
to both rooms.
So how is this related to OLC?  Well as soon as a builder flags a room
UWATER, or WATER_SWIM, or etc (or even FLIGHT for that matter), I have a
menu pop up that contains environment information, such as the afore
mentioned drift_to, drop_to, float_to ints, as well as some other nifty
stuff.  Advanced toying with this idea, has lead a couple of my builders
to produce some very kewl river currents, where one time I sat and watched
a twig float all over some river and I was in awe (heh yeah i need to get
out more.)

Just an idea.  It's cool to kill a flying pixie and watch them fall 80
feet to the ground where their inventory scatters for a few rooms.

jtrhone aka Vall RoA

< no corny sig needed, RoA speaks for itself >

| Ensure that you have read the CircleMUD Mailing List FAQ: |
|   |
|    Or send 'info circle' to     |

This archive was generated by hypermail 2b30 : 12/18/00 PST