Differentiating between entering onto and into

#1

The same action, “entering”, is used for both getting on top of things and into things,
and I can’t figure out a way to specify which when writing a rule (for making a custom supporter-kind or container-kind).

For example:

There is a room.
The horse is here.

Instead of entering the horse:
    now the player is on the horse.

Produces the result:

I know it’s easy to work around this, but I’m just curious as to how it’s working.
Is there an I6 code specifically for supporters and containers?

#2

When you write the rule for “entering the horse,” the compiler will assume that the horse is an enterable container (which means that during play the game will talk about being “in” the horse), unless a declaration elsewhere in the code specifies otherwise.

Try this:

[code]There is a room.
The horse is here. The horse is an enterable supporter.

Instead of entering the horse:
now the player is on the horse.[/code]

(Andrew Plotkin) #3

Mm, not true – the compiler doesn’t make assumptions based on rule headers like that. The horse winds up as neither a container nor a supporter (nor enterable). When you forcibly move the player to a generic thing like that, the room header is “(in the X)” by default.

(If you wrote “The saddle is in the horse,” then the compiler would assume the horse is a container.)

#4

Thanks for the replies! Yes, making the horse a supporter works as a workaround, but what if I want to make the horse an animal and not a kind of supporter?

Zarf, is there a way to force a room header for when being on or in a specific generic thing or kind of thing?

(Hanon Ondricek) #5

The “Rideable Vehicles” extension is built into Inform 7:

#6

Thanks Hanon! I looked at the code of that extension and I found the snippet of I6 code that seems to make the difference:

Include (-
	has enterable supporter,
-) when defining a any kind or thing here.

That will make the header say “on” instead of “in”, without implementing other supporter features on the kind.

#7

Whoops, thanks for the correction. I was getting it confused with the assumptions that the compiler makes based on certain declarations – “A bucket is here. In the bucket is a turnip,” automatically turns the bucket into a container, for example.