Property door_to appears twice in CreatePropertyOffsets?

In 6M62, as part of Output.i6t, a routine called CreatePropertyOffsets is created. It has a lot of lines that look like:

valued_property_offsets-->list_together = 10;
valued_property_offsets-->short_name = 16;
valued_property_offsets-->plural = 22;
valued_property_offsets-->article = 28;

I noticed that one property (door_to) occurs twice:

valued_property_offsets-->door_to = 47;
valued_property_offsets-->door_to = 165;

I don’t really understand what that routine is doing. It appears to be run as part of the initialise memory rule at startup. However, as far as I can tell, door_to is the only property appearing twice.

A peek at the actual value in the array shows that it is set to 165, with the first assigned value overwritten by the second as would be expected.

Two questions:

  1. Does anyone know what is the purpose of this routine? (A pointer to documentation would be fine.)
  2. Why does door_to appear twice?
1 Like

No documentation, but you can see how @draconis was using valued_proprty_offsets and related info to do what introspection was possible on I7 properties in Programatically printing all properties associated with object?

It turns out that the property_metadata, attributed_property_offsets, and valued_property_offsets arrays don’t exist anymore in v10.

Don’t know, but I’d suspect that the first assignment is a bit of dead code that never got removed and went unnoticed 'cause it was doing no harm. (And the redundancy doesn’t exist in v10.)

Thanks, Zed. Do you happen to know what drives the equivalent functionality (i.e. storing associations between properties and classes) in v10? (EDIT: It appears that this whole subsystem is significantly different in 10.1. Each property is given its own independent array.)

I think I have an idea of what CreatePropertyOffsets is doing: It’s storing the starting points (keyed by I6 property) of subarrays stored in the array property_metadata. Each subarray defines which specific objects and kinds are allowed to have that property (see WhetherProvides() and ScanPropertyMetadata()).

Looking at the way that property_metadata is defined:

Array property_metadata -->
    ! offset 47: property door_to
    "other side" K4_door NULL
    ! offset 165: property door_to
    "<nameless>" K4_door NULL

it appears that the double mention is an artifact of the twin uses of the door_to I6 property as both a default property of doors (originating in compiler hardcoding?) and from the declaration of an other side property mapped to I6 door_to in the the Standard Rules (Section SR1/5 - Doors).

1 Like