Up to Main Index                          Up to Journal for February, 2024

                    JOURNAL FOR SUNDAY 18TH FEBRUARY, 2024
______________________________________________________________________________

SUBJECT: Record @ref and includes
   DATE: Sun 18 Feb 19:07:24 GMT 2024

Once again I find myself strapped for time. Instead of Helm charts, Kubernetes
and AWS I’m up to my eyeballs in Google Cloud Platform (GCP) and Apigee. Quite
interesting, I’ve not used GCP much and had to cram in training for Apigee and
GCP all at once.

When I have been coding I’ve had to switch from currencies to a feature that
has been requested a few time and which I now need myself: record level @ref.

A normal field level @ref lets you reference fields in another record when
writing zone files. For example:


    %%
        Ref: O1
       Name: a rock
      Alias: ROCK
    Cleanup: @DEFAULTS
      Reset: @DEFAULTS

    This is a rock...
    %%
        Ref: DEFAULTS
    Cleanup: AFTER→2m JITTER→30s
      Reset: AFTER→2m JITTER→30s
    %%


Here a rock is defined and it references the CLEANUP and RESET fields from the
DEFAULTS record. After processing the O1 record would be the equivalent of:


    %%
        Ref: O1
       Name: a rock
      Alias: ROCK
    Cleanup: AFTER→2m JITTER→30s
      Reset: AFTER→2m JITTER→30s

    This is a rock...
    %%


This is what we have now in WolfMUD. A record @ref works in a similar way, but
allows you to bring in definitions from a whole record. The above example has
two @DEFAULTS references. With a record @ref only one reference is needed:


    %%
        Ref: O1 @DEFAULTS
       Name: a rock
      Alias: ROCK

    This is a rock...
    %%
        Ref: DEFAULTS
    Cleanup: AFTER→2m JITTER→30s
      Reset: AFTER→2m JITTER→30s
    %%


With a record @ref, any fields in the referenced record not preset in the
record with the record @ref are copied. In the above example, O1 references
DEFAULTS. The O1 record is missing the CLEANUP and RESET fields present in the
DEFAULTS record, so they are copied from DEFAULTS to O1.

Record and field @ref may be used together and record @ref maybe be nested or
chained together — that is, a record referred to by a record @ref may itself
have record @ref. As a final example:


    %%
        Ref: O1 @DEFAULTS
       Name: a rock
      Alias: ROCK
      Reset: @LONG SPAWN

    This is a rock...
    %%
        Ref: DEFAULTS @SHORT
    %%
        Ref: SHORT
    Cleanup: AFTER→2m JITTER→30s
      Reset: AFTER→2m JITTER→30s
    %%
        Ref: LONG
    Cleanup: AFTER→10m JITTER→30s
      Reset: AFTER→10m JITTER→30s
    %%


The O1 record references DEFAULTS, which references SHORT — DEFAULTS now has
the SHORT CLEANUP and RESET fields. The CLEANUP field is missing from the O1
record so it is copied from the DEFAULTS record. The O1 RESET field references
the LONG record RESET field and adds the SPAWN attribute. The final records
after all @ref are resolved:


    %%
        Ref: O1
       Name: a rock
      Alias: ROCK
    Cleanup: AFTER→2m JITTER→30s
      Reset: AFTER→10m JITTER→30s SPAWN

    This is a rock...
    %%
        Ref: DEFAULTS
    Cleanup: AFTER→2m JITTER→30s
      Reset: AFTER→2m JITTER→30s
    %%
        Ref: SHORT
    Cleanup: AFTER→2m JITTER→30s
      Reset: AFTER→2m JITTER→30s
    %%
        Ref: LONG
    Cleanup: AFTER→10m JITTER→30s
      Reset: AFTER→10m JITTER→30s
    %%


The examples used here are very simple. However, if you are writing large zone
files with standard items, for example guards, and you just want to vary a few
fields or attributes it can save a lot of typing.

The final piece of the puzzle are includes. Includes would allow you to import
any .wrj file into another .wrj file. For example, you could have a file with
standard items like boxes, barrels, trinkets and furniture. The standard items
could then be imported and referenced in multiple zone files. For example, the
zinara.wrj zone file could import standard items and mobiles:


    %%
          Ref: ZINARA
         Zone: City of Zinara
       Author: Andrew 'Diddymus' Rolfe
     Disabled: TRUE
      Include: SI→stdItems.wrj SM→stdMobile.wrj

    This is the city of Zinara.
    %%


Assume stdItems,wrj defined a bag with a reference BAG. You could then add it
to a location or mobile using ‘Inventory: SI:BAG’ or define a new bag based on
on the standard one using an @ref ‘@SI:BAG’. The ‘SI’ prefix, or any other, is
defined on the include when it is imported. This allows multiple items in
different files to be defined, all with a REF of BAG but with unique prefixes.

Record @ref are nearly complete and should be on the public dev branch within
the next few days, I just need time to document them properly. Includes will
be next and may differ to my ramblings above — I still need to work out a few
of the implementation details…

--
Diddymus


  Up to Main Index                          Up to Journal for February, 2024