[DGD] object finding

[Noah Gibbs]

  You can't, in general, have a standard LPC list of all the indices.  In most
MUDs, you *will* have more active object indices than the maximum size of an
LPC list.  This is why the Kernel lib stores this stuff as a linked list,
incidentally, and why you really don't want to iterate through all of it in one
go (you may easily have more objects than RAM).

  I don't think you can easily say "give me the object for this index", though
you can do the reverse.  You pretty much have to iterate through all the
objects in one way or another.

  There *are* some cute ways to use find_object() to do roughly this if you
know that the object type you're playing with composes most of the MUD's data
size (for instance, if you have a single object type and you're looking through
all instances of it).

--- Shentino <shentino at gmail.com> wrote:

> Is it possible to translate directly from an object index into an
> object without knowing the path?
> 
> I ask because I forsee a future crash wiping out my LPC object
> database and I'd like a way to reconstruct it.
> 
> Basically, I'd like to, using as little other information as possible,
> derive the existence or non-existence of a specific object.
> 
> About the only solution I can think of is the Klib's ObjRegD (which
> I'm trusting not to crash), but that has to be searched.
> 
> I'm thinking that since the object table is a flat list of objects
> indexed by, er, index number, it might be possible to do this directly
> from LPC level code.
> 
> __________________________________________
> http://mail.dworkin.nl/mailman/listinfo/dgd
> 




__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com