The manual, in §3.25. The location of something, says:
And, sure enough, consider this:
[code]The Orchard is west of the Undertomb.
The stream is a backdrop.
It is in the Orchard and the Undertomb.
if the location of the stream is the Undertomb, say “Stream is in the Undertomb.”;
if the Undertomb encloses the stream, say “Stream is enclosed by the Undertomb.”[/code]
Nothing gets printed because the conditionals are never true.
Likewise, if I move to the Undertomb:
So clearly the stream does, in fact, have a location. Which, of course, it must in order for it to actually exist in the model world. So saying backdrops have no location is clearly false. Yet it’s demonstrably true that you can’t check for their location.
So the question is:
What is the rationale for not allowing the location of a backdrop to be checked?
I can somewhat see the argument being that “a backdrop does not just have one location, but many.” But clearly Inform is tracking whether a particular backdrop is in a particular location.
I don’t think the location of the backdrop that you get from the showme is the location in the sense that you’re likely looking for. From a brief check, what you get there is a single room, which is always the last room that the player was in that the backdrop is in. (Or out of play if there’s no such room, or maybe if the backdrop got removed from a room where the player was.)
This is because the backdrop is a floating object, which means that instead of actually being in all those rooms it gets moved to the player’s location whenever the player goes to a room that the backdrop is in. This is why you sometimes have to “update backdrop positions” in case a backdrop might have got moved into a room where the player was, as in §8.8 of Writing with Inform on moving backdrops.
If you want the room that the showme gives you as the location of the backdrop, then “holder of the backdrop” should work–unless the backdrop is contained/part of/worn by something, but man, I cannot think of a situation where that would make sense to do, let alone one where you’d then need to figure out the room it was in. (Maybe I should have a minicomp for making games like that.)
…in some ways the question is why Inform is showing you that location information, when it can be misleading, but it seems like there might be cases where it’d be useful to know that particular thing for debugging purposes.
I’ve found it useful before, when I messed up a conditional and a backdrop failed to update when the player moved. (Note to self: palantirs, never again.)
And as Matt said, I think Inform doesn’t let you check it with “if the location of the backdrop is…” because that value is seldom useful, and if you assume it works the same as the location of a thing you’ll get very strange bugs.
Here, again, you’re running into the limits of a fairly simplistic optimization for “multi-location” objects.
The question you want to ask is not “What is the location of backdrop B?” but rather “Is backdrop B in room R right now?” This is meaningful in Inform’s model. But Inform only works out the answers for R=(player’s location) on any given turn. Answers for any other location are not available without a bunch of extra work; peeking at the SHOWME data doesn’t give you anything useful.