Ancestors for each object type [REF: Job 188]

[brazilofmux]

Original issue 39 created by brazilofmux on 2006-09-09T01:40:03.000Z:

On Thu Mar 24 16:06:34 2005, Leona suggested:

Idea: Ancestors for all object types, set within the config file of MUX.
Some way of setting basic parent types up would save so many hassles, and
bother, code and whatnot.

[REF: Job 188]

[brazilofmux]

Comment #1 originally posted by brazilofmux on 2006-09-09T02:49:02.000Z:

See Issue 48 for a similar (but not identical) feature: default parents.

[brazilofmux]

Comment #2 originally posted by brazilofmux on 2006-09-09T04:54:33.000Z:

On Wed May 10 14:28:57 2006, Nidwe suggested: Config options that set a default
Master room/object/player Parent that would be set by default on all objects but can
be overided by local parents. This all a MUX administrator to code and overall theme
without running around @parenting every object to do so.

[REF: Job 290]

[brazilofmux]

Comment #3 originally posted by brazilofmux on 2006-12-24T01:41:11.000Z:

<empty>

[brazilofmux]

Comment #4 originally posted by brazilofmux on 2007-08-06T22:43:59.000Z:

The bulk of this appears to be handled by the Issue 48 change. If I read correctly,
the one remaining portion of Nidwe's comment would be to add a default zone.
Autozone does that in part for non-player objects already.

Per-type zoning seems like overkill.

[brazilofmux]

Comment #5 originally posted by brazilofmux on 2007-08-06T22:54:35.000Z:

Let's go with default parents for now and let the zone aspect bubble up on it's own.

This is not quite a duplicate of Issue 40, but Issue 40 was 'fixed'.

[brazilofmux]

Comment #6 originally posted by brazilofmux on 2007-08-06T22:54:37.000Z:

Let's go with default parents for now and let the zone aspect bubble up on it's own.

This is not quite a duplicate of Issue 40, but Issue 40 was 'fixed'.

[brazilofmux]

Comment #7 originally posted by brazilofmux on 2008-02-11T21:51:29.000Z:

Reopening this as between 2005 and 2007 things seemed to get confused. If I recall,
the original request was for ancestors as Penn implements them. I've added the Penn
helpfile on Ancestors below to clarify.

ANCESTORS

Objects can inherit attributes from other objects through the use of parents. An
object's parent, its parent's parent, its parent's parent's parent, etc. constitute
the object's "parent chain" and lookups work the way up the chain until an
inheritance occurs.

Ancestors are "virtual parents" that are assumed to be last on every parent chain.
There is one ancestor for each object type (room, exit, thing, player), and @config
lists the dbref of each ancestor object (@config ancestor_room, etc.) Under normal
circumstances, if an attribute can't be retrieved from an object or any of its
explicit parents, the attribute will be looked for on the appropriate ancestor. The
ORPHAN flag may be set on an object to cause lookups on that object to ignore
ancestors (like the pre-ancestor behavior).

Ancestors may themselves have parent chains, but these are (obviously) not virtually
terminated by ancestors.

Note that the choice of which ancestor to look up is based on the type of the child
object, as is the check of the ORPHAN flag. Also note that ancestors are not
checked for $-commands or ^-commands; you should use the master room for global
commands, instead.