My sword, your sword

Hi All,

Processing all the wonderful feedback I received for my IFComp entry, and looking where I might need to tweak things I come across the following:

On the throne, a gleaming sword rests, confirming
your authority as the rightful ruler of the realm.
Allowed actions: {seizing your sword}.
Good vs Evil.7 >seize my sword
With the broken axe handle in hand, you decide to seize your sword,
hoping it will serve as a suitable replacement for your shattered axe.
Good vs Evil.8 >i
Your muscles ripple beneath your sun-tanned skin.
You are definitely as good-looking as ever.
You are carrying your sword (wielded), an axe handle,
a bottle of wine (closed), and your loincloth (being worn).
Allowed actions: {marching west}.
Good vs Evil.8 >undo
You carefully place your sword back on the throne.

The game shows the sword as your sword in the room description, the action is known to the game as seizing your sword, and in the inventory it also shows up as your sword. But the command the player needs to use is seize my sword. Is this indeed the correct way owned things are handled? To me it is a bit confusing sometimes. When the player wants to examine himself/herself/itself, they are supposed to use x me instead of x you. But i (which I interpret as take MY inventory) shows the things owned by ME as YOUR …

1 Like

Yeah this is a bit awkward. Inform basically considers the player character (in game) and the player (sitting at the keyboard) as the same person by default. So the game tells you: “You are holding your sword”, and you might tell the game “I would like to put my sword down”, or whatever.

In my game, I manually ensured that the player could use both “your” and “my” to refer to things conceptionally owned by the PC, e.g.:

The armor is wearable and proper-named. The printed name is "your armor".
Understand "your/my/-- battle/combat/-- armor/armour/rattle" or "your/my/-- suit/set of/-- battle/combat/-- armor/armour" or "suit" as the armor.

(There’s probably a more general way to accomplish this that I never bothered to research, but this works well enough.)


You don’t need to specify “my” as a synonym. The parser lets you apply “my” to every object by default. It gives a disambiguation bias towards things in your inventory, but to the (classical) adventurer, everything you see is “mine”. :)


I see…

Order vs Chaos.18 >x my river
A dark and foreboding river, its waters shrouded in dense,
swirling mist, winds its way slowly through the landscape.

The by default suggests we can turn this off? How? I can imagine one does not always want to claim ownership…

1 Like

With great difficulty. You need to alter the LanguageDescriptors table in I6.


It’s more nuanced than that. When an object name is preceded by what the parser labels the ‘descriptor’ my, if (and only if) disambiguation is required the parser completely excludes any object not directly worn or carried by the actor (not the player).

So after

Lab is a room.

Bob is a man in the Lab.

Persuasion: rule succeeds.

A sword is a kind of thing. Understand "sword" as a sword.

The longsword is a sword. Bob carries the longsword. The scabbard is an open container. The scabbard is carried by Bob. The dagger is a sword. The dagger is in the scabbard. 
The bastard sword is a sword. The player carries the bastard sword.

you can get the following output:

You can see Bob here.

>bob, x sword
(the longsword)
Bob looks closely at the longsword.
[disambiguates to highest-scoring sword == longsword because it is directly held by the actor (Bob)]

>bob, x my sword
Bob looks closely at the longsword.
[disambiguates to only sword directly carried/worn by the actor (Bob) == longsword]

>bob, drop sword
Bob puts down the longsword.
[MULTIHELD token disambiguates to only sword directly carried by the actor (Bob) == longsword]

>bob, x sword
(the longsword)
Bob looks closely at the longsword.
[disambiguates to highest-scoring object == longsword because it is directly in the location]

>bob, x my sword
There is no reply.
[disambiguation excludes all swords as none is directly held/carried by the actor (Bob)]


It’s one of the many little features in the I6 parser that now get in the way more often than not. I think it would be better to remove these special features and instead say, for example, Understand "my" as a thing when the player encloses the item described or the player incorporates the item described.


Agreed. Further, I would submit that applying the descriptor ‘my’ to the actor rather than to the player is actually a bug. Also, more arguably, allowing ‘my’ to apply to any object so long as disambiguation isn’t required seems odd- but perhaps this fits into the parser’s paradigm of allowing unambiguous if ungrammatical input.

1 Like

Yeah, the nuance Peter describes (which I had forgotten about, thank you) is an unintuitive complication at best. It doesn’t fit into any good scheme that “get my foo” will return a parser error rather than disambiguating when there are two (poor) candidates. (But work fine if there’s only one.)

Also it interferes with games where some objects are unambiguously owned. (“My wand”, “Hermione’s wand”, “Ron’s wand” shouldn’t change descriptors just because they get dropped or picked up.)

1 Like

I’ve requested an improvement via the bug-tracker

1 Like

I doubt it causes many problems, but I’ve always been surprised that the terms ‘lit’ and ‘unlit’ exist as hard-coded optional parser descriptors- perhaps for the rare situation where there are ten candles on the table only one of which is lit…?- so, analagously to ‘my’, one can type ‘drop lit sword’ and thereby drop your unlit bastard sword- as long as you’re carrying only one sword- whereas ‘drop lit sword’ will fail if you are carrying more than one unlit sword, with ‘You can’t see any such thing’.

1 Like

Which would also be much better implemented in I7, now that we can use Understand lines instead of parse_name routines.

1 Like

Now that you mention this, that surprised me when I was creating my IFComp entry. I had a “dimly lit path” but forgot to put in an understand statement for the path. The game recognized x path and x lit path but not x dimly lit path and I could not figure out where the lit path part was coming from… Thanks for pointing this out!

Order vs Chaos.47 >x lit alcaz
Alcaz, your court mage, strikes an imposing figure,
wearing a mage's robe and carrying his staff of arcane magic.
He is studying the runic script on the marker.

I guess everything and everyone becomes enlightened lol

1 Like

Of course, as I’m sure you know, I7 Understand... as .... phrases (as far as parsing objects is concerned) are compiled to I6 parse_name routines- they’re just a lot easier than writing a parse_name routine directly!

Of course, it’s syntactic sugar, but it’s very useful syntactic sugar! Previously, if you wanted every object in the game to recognize “my” when carried, you’d need to either give everything a parse_name…or put it into the parser itself. So that’s what they did.

Now, a single Understand line can add conditional grammar to every object in one fell swoop, which is far, far easier!

Well, not quite- you could just add code to a thing class parse_name routine inherited by every thing in the game… which is exactly what an I7 Understand "lit [thing]" as a thing when the item described is lit phrase does. I wonder therefore if the hard-coded descriptors in the parser are a relic from a time before parse_name routines were introduced.

EDIT although actually it’s awkward that you also have to add the code to any thing or class providing its own parse_name routine, since this isn’t an additive property and providing a parse_name routine therefore supersedes any inherited one. The I7 compiler automatically adds the code to create such ‘pseudo-inherited’ parse_name routines for you. Out of the box, the only thing compiled with a parse_name routine is the player object, selfobj.

EDIT2 the pain of this when programming directly in I6 could be reduced by using the superclass operator

1 Like