[DGD] Re: Substituting LWOs for persistent objects

[Felix A. Croes]

"Mikael Lind" <mikkelin at gmail.com> wrote:

>[...]
> The above poses a problem for a game. The scenario is a mud with rooms
> (represented by POs), creatures (POs), and items (LWOs). If a creature
> enqueues a take-action for an item in a room, where the take-action is
> stored in the creature, and the take-action references the item via an
> object reference, and the take-action is to be executed during another
> execution round, then the item will be duplicated, which is
> undesirable. I am also thinking that the same problem would occur in
> many similar scenarios.

A simple solution for this particular case would be to enqueue the
"take-action" in the room, where it can refer to the item directly
without danger of duplication.  In many cases, problems can be
avoided by being careful regarding where you reference the item from.
Generally speaking, what you do is let the persistent object that
contains an item perform all actions that manipulate this item.


> I was thinking that some kind of indirection would be appropriate,
> where rooms and creatures associate handles (ints) with the items they
> contain, so that other POs may reference the items across execution
> rounds without duplication. The other POs would not store object
> references but instead an indirect name (string), perhaps on the form
> PON:IH, where PON is the persistent object name and IH the item
> handle. It would be possible to lookup indirect names and get a plain
> object reference to the LWO for manipulation. call_other() could also
> be masked by a second-level auto object in ~System to properly handle
> calls to indirect names.

For any kind of advanced mudlib you will need such "handles" for both
light-weight and persistent objects, because you want the mud client to
be able to refer to them, as well.  Integers that are either globally
(mud-wide) or locally (for one particular client only) unique would be
a good start.


Par Winzell <zell at skotos.net> wrote:

>[...]
> Is a LWO that never leaves really so 
> much less of a resource strain than a persistent object that it's worth 
> the hassle?

Unfortunately the answer to this question is "yes."

Regards,
Dworkin