Q about the attributes of a kind, and Q about multiple declaratives in one sentance

Authoring Inform 7
1

One thing that I am still pretty confused about, with Inform 7, is when you can and cannot declare multiple things in one sentence. I assume these are not the same situation, but I am not sure the difference:

[This works - assigning multiple properties to an object ]
	The ImpossibleDoor is a closed, locked door.

[ But none of these do, trying to assign multiple properties(?) to a thing or kind ]
[
	A thing can be flippable, raisable and lowerable.
	A doorstop is a flippable, raisable, lowerable thing.
	A doorstop is a kind of thing which is flippable, raisable and lowerable.
	A doorstop is a kind of thing which can be raised or lowered. 
	A doorstop is a kind of thing that can be raised or lowered. 
	A doorstop can be raised or lowered and is usually raised.
]
 
[ It seems you have to have to split each item out.  Surely there is a more elegant way? ]

A thing can be flippable.  A thing can be raisable.  A thing can be lowerable.
A doorstop is a kind of thing.  A doorstop is flippable.  A doorstop is raisable.  A doorstop is lowerable.  A doorstop can be raised or lowered.  It is usually raised.

Q 2 - now that I have a kind that is ‘raisable’ What is the difference now between ‘touchable’, ‘enterable’, etc… and raisable where the former would be accepted in the condition(?) below but not the latter?

[ WHY not 'one raisable thing' ? ]
[Raising is an action applying to one raisable thing.] [ <--- doesn't work ]

Raising is an action applying to one touchable thing.
Understand "raise [something]" as raising.
Understand "lift [something]" as raising.

[ oh sure, raisable works here... ]
Check raising:
	If the noun is not raisable, say "You can't raise [the noun]." instead;
	If the noun is raised, say "[The noun] is already raised." instead;
2

Yeah. “touchable” and “enterable” are pre-defined I7 properties that have rulebooks already written for them.

When you’re wanting something to be “flippable” there’s already a “device” kind in Inform that is meant to work like a switch and take the properties “switched on” and “switched off”. You might want to look at that as an example, or possibly make your doorstop a device so the player can inherently FLIP DOORSTOP.

2 Likes
3

On your question 2, the issue is that Inform only accepts a very small set of properties when defining new actions: visible, touchable, and carried (link to WwI). So you can’t actually define an action as applying to an openable or touchable thing at that level (there is probably a good reason for this, but I don’t know it).

You can limit the action’s applicability by properties when defining the grammar: Understand “blarg [something openable]” as blarging, or what have you. But in real life, it’s probably better to do that with a check rule with a custom rejection message, so the player doesn’t try to blarg something unopenable, get a default parser error, and conclude that blarging won’t be needed in this game.

2 Likes
4

See, those kind of IDK… ambiguities… are what is killing me about getting my mind around Inform7.

I can say “one touchable thing” or “one enterable thing” but after I specifically declare that a thing can be raiseable, I can’t say “one raiseable thing”. But later I can say “If the noun is not raiseable”.

I totally get how Inform7 is being parsed into Inform6 code. Frankly I can’t imagine how that is even possible to pull off as a coding project, and I have written simple interpreters and compilers myself. But, I do understand that just because it makes similar “english sense”, that doesn’t mean it parses into Inform 6. But that kind of subtlety keeps tripping me up.

5

No, only “touchable”, “visible”, and “carried” work here. This is a special case in the syntax. These aren’t properties or rulebooks. These are specific keywords that only apply to defining actions. (I7 doesn’t normally have much of a concept of keywords, but in this case, that’s the best way to think about it.)

2 Likes
6

So what I am understanding is

Q1 - Can’t say “thing can be this, that and the other” just a grammatical thing that doesn’t work. Accept it. Have to say: Thing can be this. Thing can be that.

Q2 - “One openable thing”, “One visible thing”, only works for adjectives that are pre-defined keywords. My own “raiseable” isn’t in that company. :frowning: But later it can be referred to as a property of a noun.

(Is it raisable or raiseable?)

7

If you declare “a thing can be hated and loved” it’s trying to make one property called “hated and loved” not a “hated” property and a “loved” property. That’s just the syntax.

Another is “one thing, preferably held”.

1 Like
8

Ah. This. This is the stuff I have to figure out, precisely. I get it now. Thank you.

1 Like
9

You’re not wrong – this is confusing. In most places, you can use your property like you’d like. But action definitions are a special case. And then grammar tokens in Understand statements are a different special case. And you can go ahead and use your properties again in your actions’ rule preambles, but then you have to be sure to say “noun” and not try to say “thing” in the body of the rule.

10

If it helps, these are brief notes I wrote for myself to help get my head round how this works:

An action needs two things to anchor it in the game world:

(i) a very basic description of how the action works in the game world → (e.g.) (Photographing) is an action applying to nothing/(one/two) (visible/touchable/carried/–) (thing(s)/value(s)) [and one…] [and requiring light].

  NB confusingly, 'visible' here means 'anything the actor is allowed to refer to' (more formally, 'in scope for the actor') not the more usual 'visible to the actor'. So it includes for example the compass directions and even objects out-of-play if the scope rules judge them to be 'in scope'  By default most objects not visible in the usual sense will be excluded from consideration by the scoping rules followed by grammar lines (see below), so there is usually a close but not complete alignment between 'in scope' and 'conventionally  visible'. Without specifying 'visible/carried', 'touchable' is the default. 'carried' is a more restrictive form of 'touchable' and includes only things directly carried by the actor.

(ii) grammar line(s) to recognise the action in what is typed by the player and declare a (usually) more restricted scope for the objects and/or values the action can refer to. → (e.g) Understand “photograph [someone]” as photographing.

built-in tokens:

[somebody] / [someone] → synonyms == a person in scope for the actor => the [second] noun (rather than ‘the person understood’)
[something] / [thing] → synonyms == a thing in scope for the actor- thing here means Inform’s usual more restricted sense, not object, so excludes rooms, directions and regions
[things] → a list of one or more things in scope for the actor
[other things] → a list of one or more things in scope for the actor which are not the other thing mentioned (e.g. a container)
[things inside] → a list of one or more things in or on the other thing mentioned (e.g. a supporter/container)
[something preferably held] → as with [thing], but choose a held object over others with same name, try implied take if present but not held
[things preferably held] → as with [things], but choose a held object over others with same name, try implied take if present but not held
[text] → an unparsed sequence of words => a snippet called ‘the topic understood’ †
[a time period] → a period of time †† => a time called ‘the time understood’

[description of objects/values] → matching any description of objects ([open door]) within sight of the actor, or of values [even number]
→ [description of directions] references directions. NB directions are ‘visible’ but not ‘touchable’ (see above)
→ prefixing ‘any’ e.g. [any open door] removes the restriction that an object must be in scope for the actor (or, to think about it another way, brings all matching objects temporarily into scope for this action)
→ [any thing] will allow any thing, in or out of the game world == [anything]; similarly [anybody], [anyone]
→ [any (description of rooms)] allows reference to rooms, not otherwise mentionable in typed commands
→ [anywhere] == [any room]
→ the Index indicates which built-in values have a corresponding Understand token
=> for values, a value called ‘the (kind) understood’
=> for objects, the [second] noun

† this is something of an exception, for historical reasons, to the general ability to refer to a successfully-parsed grammar token as ‘the (kind) understood’, which here would otherwise be ‘the snippet understood’. Using ‘the noun’ and ‘the second noun’ to refer to the first and second object parsed are also exceptions. But we say for example ‘the number understood’ or ‘the time understood’ or ‘the colour understood’ for values. There is also ‘the person asked’ for constructions such as ‘Bob, open the box’.
NB it is also possible to extract values from the player’s command or other snippets through ‘if (snippet) includes “[kind of value]”’ following which ‘the (kind) understood’ contains the matched value. e.g. ‘if the player’s command includes “[number]”’ => (if matched) ‘the number understood’

†† this special token is provided because [a time], which follows the general [description of values] pattern, matches only specific times of day but does not match ‘21 minutes’ for example, even though this is also of kind time. However, the parsed value is still referred to as ‘the time understood’ rather than ‘the time period’ understood.

3 Likes