If left as is, nothing more than, according to me, a greater potential. Besides, the code itself is fundamentally based on an understand instruction, so you’re right:
Understand the ThingAltname property as describing a thing.
I also find the use of relationships less tedious and more readable for linking synonyms to objects, but it’s probably a matter of preference.
I’m working on this theme because initially, I was looking for a way to streamline synonyms for people (who are also things) using the method proposed by the Straw into Gold example from the manual. Thanks to relations, a streamlined process becomes possible, without working with the tables and the famous room-property bug.
For example, it’s now very easy to use synonyms to adapt dynamically the presentation of objects according to those the player prefers to use to refer to an object or a person. Compared to a simple Understand instruction, here we can control what is written and not just what is read.
"The troupe"
The square is a room.
A person can be identified or unidentified.
A person is usually unidentified.
Definition: a thing is nearby if (it is in the location of the player).
ThingAltname is a kind of value.
The ThingAltnames are caravan, trailer, vardo, wagon, platform, stage, podium, minstrel, bard, gleeman, poet-singer, singer, storyteller, onlooker, passerby, spectator and idler.
A thing has a ThingAltname.
Understand the ThingAltname property as describing a thing.
Altnaming relates various ThingAltnames to one thing.
The verb to altname means the altnaming relation.
The verb to namemorph means the reversed altnaming relation.
After reading a command:
if (the player's command includes "[ThingAltname]"):
let LocalAltname be the ThingAltname understood;
repeat with LocalThing running through things which namemorph LocalAltname:
now the ThingAltname of LocalThing is the ThingAltname understood;
Rule for printing the name of a person (called LocalPerson) which is unidentified:
say "[an ThingAltname of LocalPerson]";
Belcyrd is an improper-named man in the square.
Minstrel, gleeman and bard altname Belcyrd.
The ThingAltname of Belcyrd is minstrel.
Dolaria is an improper-named woman in the square.
Storyteller, poet-singer and singer altname Dolaria.
The ThingAltname of Dolaria is singer.
Grimphy is an improper-named man in the square.
Onlooker, passerby, spectator and idler altname Grimphy.
The ThingAltname of Grimphy is spectator.
The theater troupe's cart is in the square.
Caravan and vardo altname the theater troupe's cart.
The old Grimphy's carriage is in the square.
Trailer and wagon altname the old Grimphy's carriage.
The stand is in the square.
Platform, stage and podium altname the stand.
square
You can see a minstrel, a singer, a spectator, a theater troupe's cart, an old Grimphy's carriage and a stand here.
>examine passerby
You see nothing special about the passerby.
>look
square
You can see a minstrel, a singer, a passerby, a theater troupe's cart, an old Grimphy's carriage and a stand here.
>examine bard
You see nothing special about the bard.
>look
square
You can see a bard, a singer, a passerby, a theater troupe's cart, an old Grimphy's carriage and a stand here.
>
Next steps for me are: to catch the name of a person in a snippet to make them identified and so proper-named (I’m stuck) and to dynamically describe non-person items thanks to the synonyms (a possibility not offered by Understand, as far as I understand.)
EDIT : done (not this code, but an improved version that is starting to go seriously off-topic). Honestly, using relations to automate and refine the naming of objects and people based on their commonness (or uniqueness), how they are identified by the player, and the player’s vocabulary preferences—I think it’s cool for making the game world feel more familiar as the player becomes more invested in it.
Sorry for digressing this way, it’s just that @rpatten 's use of tables in the thread reignited my desire to streamline the management of synonyms. A side question: I obviously couldn’t find any built-in understanding-type relation, but maybe I haven’t done enough research? That would have saved me from writing the code that @rileypb rightly found redundant.