SYNOPSIS
    object P_VMASTER  "VMaster"

    object Set(P_VMASTER, object obj)
    object Query(P_VMASTER)

DESCRIPTION
    This property is used when implementing virtual objects.
    Its value is the master object of a group of virtual objects.
    Though the property is specified of type object, filenames may be used,
    too.

    If the gamedriver tries to load an object whose file does not
    exist, it asks several objects which could be virtuality masters
    to provide a replacement object, For this, it calls the lfun
    compile_object(string filename) in the objects. If one of the
    asked may-be-masters returns an object from this call, that object
    is used as if it had been compiled from the filename originally
    requested for.

    The probable masters asked are these in the given order:
      1. (loading object->Query(P_VMASTER) || loading object)
         -> compile_object(<full filename>)
      2. (environment(loading object)->Query(P_VMASTER) 
          || environment(loading object))
         -> compile_object(<full filename>)
      3. <pathpart of filename>/vmaster.c->compile_object(<base of filename>)
      4. <pathpart of filename>.c->compile_object(<base of filename>)
    In all this, <filename> usually ends in ".c"!

    Virtual objects are useful to implement largish areas in which most
    rooms have common features. The exits between the room may be written
    as if the room really exist in separate files, while in fact only those
    rooms with special features really exist as own file. All other rooms
    are generated on demand according to the creational rules of that areal.

    But remember this: MAZES are BORING TIMEWASTERS!

    The P_VMASTER property allows to separate the virtual room objects from
    the master controlling all the virtual rooms.

EXAMPLE
    Set(P_VMASTER, load_object("/d/beyond/rooms/cart/cartmaster");

AVAILABILITY
    Include: <properties.h>

    Applies to every object, queried by /secure/master.

SEE ALSO