Re: [THEORY] Structure...

From: Daniel Staudt (dstaudt@hotmail.com)
Date: 02/14/00


not a bad idea but how would you have olc save this back to disk?
how would it know what was diffrent from the obj and the inhereited except
for a item by item search which would take a long while


>From: Andrew Ritchie <object@ALPHALINK.COM.AU>
>Reply-To: Circle Discussion List <CIRCLE@post.queensu.ca>
>To: CIRCLE@post.queensu.ca
>Subject: Re: [CIRCLE] [THEORY] Structure...
>Date: Sun, 13 Feb 2000 09:01:36 +1100
>
>Dear all,
>
>I haven't contributed much in the past 6 months, my apologies.  However I'm
>going to join in this little discussion as I must admit I don't really
>think
>that the current object system in Circle and many other codebases is
>versatile enough.
>
>I agree, Axiem, that the current object system does not really fit in well
>with OLC. If you wanted 10 leather studded jackets, one of which was say 10
>years old rather than 8 years, you'd need to add a seperate entry to the
>.obj files.  Otherwise, when one jacket say gets very worn, all 10 jackets
>get very worn.
>
>I've implemented an INHERIT variable to my MUD (however it's my custom code
>so I can't send you a patch).  When you edit an existing object, say the
>studded jacket, it creates a new object in the database with the INHERIT
>variable set to the vnum it held previously.  Then, if you wanted to change
>say how rusty it is, you'd simply wack that under the INHERIT flag.
>
>An example (I've forgotten how database files in Circle are laid out, but
>you'll get the gist):
>
>This is what it would have looked like (notice the 'rusty' variables):
>
>10
>A studded leather jacket~
>A studded leather jacket is before you, and it looks great.~
>variable 8 9 0
>2variable 0
>rusty 1
>#
>11
>A studded leather jacket~
>A studded leather jacket is before you, and it looks great.~
>variable 8 9 0
>2variable 0
>rusty 8
>This is what mine looks like:
>
>10
>A studded leather jacket~
>A studded leather jacket is before you, and it looks great.~
>variable 8 9 0
>2variable 0
>rusty 1
>#
>11
>inherit 10
>rusty 8
>#
>
>-- end example --
>
>The server would automatically create a new object with the inherit flag at
>any time it wanted to change that object (through OLC or whatever) and that
>object had more than one 'instance' in the MUD world.
>
>Benefits are that it takes up way less room in your db files (if you want
>independant objects), but at the same time it allows different objects,
>which in the end helps promote roleplay (and other thnings).
>
>Just my $0.02, been nice to write to you all,
>
>Andrew Ritchie
>
> > -----Original Message-----
> > From: Circle Discussion List [mailto:CIRCLE@post.queensu.ca]On Behalf Of
> > Axiem
> > Sent: Sunday, February 13, 2000 8:08 AM
> > To: CIRCLE@post.queensu.ca
> > Subject: [CIRCLE] [THEORY] Structure...
> >
> >
> > I am currently really confused about how Circle MUD keeps track of items
> > and such, and then finds them with the [v]stat commands...and I think I
> > have a better idea for implementation of structures, and which allows a
> > much easier to deal with OLC, IMO. Object can also mean mobile in the
> > following:
> >
> > Instead of a 'generic' object structure, there'd be two structures for
> > objects. One would be used as information is being loaded from the
> > actual files. It would be indexed by vnum (of course), and contain all
> > essential information of the object (name, description, item values,
> > etc.). This structure would have absolutely no representation in the
> > MUD.
> > But when an object exists in a MUD, we use a different structure. We
> > keep track of this one by a different number (rnum?). Inside this
> > structure would be the vnum of the model object, and then temporary
> > flags. If whenever we want to reference the stats of that real object,
> > then we merely look at the vnum, and read the stats of the object with
> > that vnum. With OLC, then, if we wanted to change every single occurance
> > of a weapon, we wouldn't..we'd just change the stats of the original
> > vnum. The rnum object could have flags for enchanted, keep track of
> > where it is, etc. The vnum object would just stay in memory.
> >
> > Similar goes for mobs. As with rooms. Have a 'base' structure per vnum,
> > and then every occurance of that have a structure that points to the
> > 'base' structure for universal constants.
> >
> > Sounds good..I'm thinking about doing it..any
> > suggestions/comments/thoughts on the matter?
> >
> > -Axiem
> > -axiem@swbell.net
> >
> >
> >      +------------------------------------------------------------+
> >      | Ensure that you have read the CircleMUD Mailing List FAQ:  |
> >      |  http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html  |
> >      +------------------------------------------------------------+
> >
>
>
>      +------------------------------------------------------------+
>      | Ensure that you have read the CircleMUD Mailing List FAQ:  |
>      |  http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html  |
>      +------------------------------------------------------------+

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com


     +------------------------------------------------------------+
     | 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 : 04/10/01 PDT