Tweak WEAR and REMOVE to Allow Custom Wearables

[tajmone]

@AnssiR66, while editing lib_messages-runtime.i, to ensure that ANY worn item will be listed as "(being worn)" — not just clothing, since authors should be free to implement other types of custom wearables (e.g. headphones, VR headset devices, etc.) — I noticed that the current wear and remove verbs could be improved in that direction.

Here's the current definition of wear:

ADD TO EVERY OBJECT
  VERB wear
    CHECK my_game CAN wear
      ELSE SAY restricted_response OF my_game.
    AND obj IS takeable
      ELSE SAY check_obj_takeable OF my_game.
    AND CURRENT LOCATION IS lit
      ELSE SAY check_current_loc_lit OF my_game.
    AND obj IS reachable AND obj IS NOT distant
      ELSE
        IF obj IS NOT reachable
          THEN
            IF obj IS NOT plural
              THEN SAY check_obj_reachable_sg OF my_game.
              ELSE SAY check_obj_reachable_pl OF my_game.
            END IF.
        ELSIF obj IS distant
          THEN
            IF obj IS NOT plural
              THEN SAY check_obj_not_distant_sg OF my_game.
              ELSE SAY check_obj_not_distant_pl OF my_game.
            END IF.
        END IF.

    DOES
      IF obj IS NOT plural
        THEN "That's not"
        ELSE "Those are not"
      END IF.
      "something you can wear."

  END VERB wear.
END ADD TO.

As you can clearly see, it doesn't even check if an object is wearable, and will always produce the "[That's/Those are] not something you can wear." message.

I propose that we change the DOES body to check if the object is wearable or not, and if it is carry out and implicit taking and set it as Is worn, otherwise print the "not something you can wear." message instead.

And then do the same with the verb that handles removing worn items.

Suppose an author wants to implement a custom wearable that is not clothing and doesn't fit in the layered-clothing logic, e.g. a device of some type, like night vision goggles or a VR helmet. He/she would then only need to set it as Is wearable and the Hero could then wear it and remove it.

Currently, an author would have to redefine the wear verb for any custom wearable item, or create a custom class, whereas tweaking the verbs as proposed would spear him/her a lot of work, and allow to easily create wearable device instances (which is probably going to be one of the most common use cases).

Of course, this would need extensive testing, and ensuring that there are no conflicts or pitfalls with other verbs, and that they interact without problems with all the library classes; but this should be rather straight forward, and the test-suite should catch any undesired side-effects.

Although the Library only uses the wearable attribute for clothing items, with the recent re-vamping of the clothing system the new code is ready to allow custom wearables by simply setting the wearable and worn attributes.

[AnssiR66]

Yes, good point. We can tweak the 'wear' verb this way.

[tajmone]

Misc. Notes

Although it's been a while since I've looked into this, and I'm not so fresh on the details, I'm throwing-in some extra considerations on the question of how the StdLib should support custom wearable items.

• As mentioned above, the wear and remove verbs on object class don't take into consideration non-clothing wearable items and simply emit a message stating that the object can't be worn/removed. But ...
  • Authors can always use DOES ONLY — either on the specific instance or for an entire class of custom wearables — which would then make the current problem go away.
  • For the above reason, it might not be wise to implement a default wear action for non-clothing items, since we don't know all the details and conditions which authors might need (e.g. preventing multiple items of the same type to be worn simultaneously).
• The question that remains unaddressed is how the default wear and remove verbs should deal with the wearable attribute (defined on EVERY THING):
  • We can assume that authors implementing custom wearable items will set them as IS wearable. So, even though they'll most likely provide some custom wear and remove verbs for these types of wearables, should the default wear and remove verbs check the wearable attribute? or should we just assume that their body will never be executed due to a DOES ONLY custom verb taking over?
    1. Maybe adding an IF check for the wearable attribute in the body of the default wear and remove makes sense? I.e. do nothing if the item IS wearable? This would make sense if (and only if) the author did provide custom alternative verbs, but would lead to a responseless verb in all other cases!
    2. Leaving these verbs as they are would be safer if (and only if) end-authors take care of their custom werables, since they would never execute anyway, but if they do they provide a sensible response at least.

As you can see from the above considerations, it all depends on how authors implement their custom wearables and related verbs.

The real question here is whether the library should enforce some guidelines on how custom wearables should be implemented, or whether is should provide a default mechanism for handling non-clothing wearables (which end authors can still override via custom classes or DOES ONLY verbs on the specific instances).

Is one approach better than the other?

We probably should address this by coming up with practical examples of non-clothing wearable items that and adventure might need — e.g. a watch, a gun holster, etc., all items which are wearable but don't belong to the clothing class (maybe the holster does though, since it has to be worn on top of shirt but under a coat?).

Other examples might be wearable gadgets that are instances of library classes:

• A VR helmet (instance of device class).
• A head lamp (instance of lightsource class).

The whole idea is to extend the concept of werables from just clothing to anything that an author might need, whether it's a custom class or on an extension of a base Library class, or even just a single instance.

Before assuming that end authors will always use a DOES ONLY we should be careful, for in reality they might need multiple verbs to execute on some classes or instances, so using DOES ONLY might not be a viable solution — in this case, the problem would be that the default wear and remove verbs on object class will end up emitting the "[That's/Those are] not something you can wear." message (along the proper responses of the custom verbs). Since ALAN doesn't provide a keyword to end the VERB execution chain, the only alternative left is to use an IF statement within the VERB body, which in our case is only good if we knew what the end author is really up to.

Although this might look a trivial problem, it actually involves some hard decisions and requires documenting very well what authors can and can not do in terms of how custom wearables should be implemented.