Visible but unreachable

[troglodyte111]

What is the easiest way to have an object that is visible but cannot be reached? For example an item high up on the wall, where to reach it I would need to climb something first. I can set a script for "take" that prints a message about not being able to reach, but must I then also find all other scripts that try to use it (unlock, open,...) and amend them as well? I am looking for a "reachable" attribute but cannot find any.

I guess I can have the object mentioned in the room description but not actually in the room. But then I cannot even "look" at it.

[Pertex]

So this unreachable item should only be shown in the room description but you can't interact with it? or you can only look at it?

[troglodyte111]

Yes, you can only look at it. Other attempts to meddle with it should result in "You cannot reach it".

[Pertex]

First thought was just creating a command in this room like this:

but the "You cannot reach it" for other commands is the problem

[KVonGit]

Building off of Pertex's idea, you could:

• create the object (I call mine a frob)
• create a special room command to handle examining the frob (like Pertex says)
• create a second special room command to handle the other commands

---

---

---

Important

The "EXAMINE" command must be added before the "catch-all" command, else EXAMINE will not work.

---

<!--Saved by Quest 5.9.9166.36226-->
<asl version="580">
  <include ref="English.aslx" />
  <include ref="Core.aslx" />
  <game name="Out of Reach">
    <gameid>3d6f4308-cded-4130-97bf-654288deafda</gameid>
    <version>1.0</version>
    <firstpublished>2025</firstpublished>
  </game>
  <object name="room">
    <inherit name="editor_room" />
    <description type="string"></description>
    <object name="player">
      <inherit name="editor_object" />
      <inherit name="editor_player" />
    </object>
    <object name="frob">
      <inherit name="editor_object" />
    </object>
    <command name="x_frob_cmd">
      <pattern>look at frob; look frob; x frob; examine frob; exam frob; ex frob</pattern>
      <script>
        msg ("It looks just like every other frob you've ever seen.")
        obj_list = NewObjectList()
        list add (obj_list, frob)
        game.lastobjects = obj_list
      </script>
    </command>
    <command name="fake_frob_cmd_catcher">
      <pattern>#text# frob</pattern>
      <script>
        msg ("You cannot reach it.")
        obj_list = NewObjectList()
        list add (obj_list, frob)
        game.lastobjects = obj_list
      </script>
    </command>
  </object>
</asl>

---

Alternatively

If you are using the Quest app for Windows, this might help: https://archive.textadventures.co.uk/forum/samples/topic/3997.html

That is an old Quest Forum post where The Pixie provides an example game to use a transparent container to make objects unreachable.

[troglodyte111]

Many thanks for explaining this, much appreciated! It works well but a detail: I also need to set he scope of the new commands to the current room, or it will also try to match with frobs in other rooms. And for "qwerty frob" it says it cannot reach it instead of complaining that it does not understand "qwerty" but I guess I can live with that. Or is there a function for testing if a word is a recognizable verb?
I don't use windows so have to do with the online version.

[KVonGit]

Oh, sorry! I thought I checked to be sure nonsense like GNARFLE FROB wouldn't go through, but I guess I misspelled "frob" when I checked, because it replied that it didn't understand my command. Now, testing again, GNARLFE FROB just says "You cannot reach that."

If the solution from angelwedge doesn't work for you, I have another idea, but I think Angel's approach is probably better.

[angelwedge]

My first thought would have been putting it in a transparent container, as that's what the "reachable" property in the game normally represents.

Second thought would have been messing around with custom backdrop scope functions for the room… if the text the player entered matches the name of the unreachable object, substitute out the current command pattern for a stub command which can display an appropriate message if the unreachable object is chosen; or refer to the original command if it's a false positive (like if the "frob" is unreachable, but the player types "get f" and chooses something else from the disambiguation menu).

Don't know how that compares to Pertex's solution, but if you want to try it poke me and I'll see if I can help.

[troglodyte111]

Thanks. Adding a container pushes the problem to the container, and I get messages that it isn't open instead of unreachable. The backdrop scope idea might work but sounds complicated and potentially dangerous, also I don't know how to do that on the online version.

I confess I forgot about the disambiguation and abbreviations. I guess I have to extend the pattern to include "f", "fr", "fro" and ensure I have no other object there.

This should not be an uncommon problem, I am surprised there is no standard attribute "reachable".

[angelwedge]

OK… for the background scope solution, I'm imagining something like this off the top of my head. I'll write it in a form that you could put in the unreachable object's initialisation script, so it's possible to do in the web editor. If you're doing this for multiple objects, it might be easier to put the scope script on the game object rather than the room; but if you're only doing it for one object, you can put it on the room.

// Just some setup stuff
room = this.parent
this.unreachable = true
this.unreachable_message = "You can't reach the " + GetDisplayAlias (this)

// If you have a lot of unreachable objects, or they can be moved to a different room while remaining unreachable,
//    then change `room.` to `game.` in all the remaining bit, and put it in the game's start script.

room.unreachable_allowed_commands = NewObjectList()
// You can add multiple commands to the list if there are any others you want to allow
list add (room.unreachable_allowed_commands, lookat)
// If the player entered multiple unreachable objects, or tried "put frob in frob", don't do this twice
list add (room.unreachable_allowed_commands, stub_unreachable)

// This is the scope script, which will be run every time a player in the room tries to run a command on an object
room.changecommandscope => {
  // First, we check if the command is "look at" or another permitted one
  if (not ListContains (this.unreachable_allowed_commands, command)) {

    // Then we look at the items that are currently in scope, filter it down to the unreachable ones,
    //    and see if any of them match what the player typed
    matched_objects = NewObjectList()
    // value is what the player typed for the object name, according to the current command's pattern
    value = StringDictionaryItem(game.pov.currentcommandvarlist, variable)
    foreach (obj, items) {
      if (GetBoolean (obj, "unreachable")) {
        // CompareNames will handle partial matches
        CompareNames (LCase (GetDisplayAlias (obj)), value, obj, matched_objects, matched_objects)
        // This next part makes it work if the object has an alternate alias
        if (HasAttribute (obj, "alt")) {
          foreach (alias, obj.alt) {
            CompareNames (LCase (alias), value, obj, matched_objects, matched_objects)
          }
        }
      }
    }
    // Now, matched_objects is a list of unreachable objects whose names match something the player typed
    if (ListCount (matched_objects) > 0) {
      // The player's trying to do things with an unreachable object, so we change the command
      stub_unreachable.real_command = command
      game.pov.currentcommandpattern = stub_unreachable
    }
  }
}

Then we have a new command, which will be run instead of the command the player typed if they attempt to do something to an unreachable object. We'll call it stub_unreachable (which the code above referred to), and give it a pattern which will never match (like the regular expression ^$).

It's code would look something like this:

message_printed = false
// currentcommandresolvedobjects is a list of all objects passed to the command
foreach (object, game.pov.currentcommandresolvedobjects) {
  if (GetBoolean (object, "unreachable")) {
    msg (obj.unreachable_message)
    message_printed = true
  }
}

// if we get here without printing a message, it means the player entered a name which could match the unreachable thing
//    but instead matched something else (possibly with disambiguation)
if (not message_printed) {
  // So we run the command the player originally tried:
  game.pov.currentcommandpattern = this.real_command
  do (game.pov.currentcommandpattern, "script", game.pov.currentcommandresolvedelements)
}

The initialisation script on each object sets the command on the room that contains it, as well as giving the object unreachable and unreachable_message attributes, which you can change later. When in a room that has that script, the player will be unable to do any command except those listed on an object for which unreachable is true.

This is weird stuff off the top of my head… so don't know if it will work. But it's the first idea that came to me.
Hope it works!

[troglodyte111]

Thanks! I'm just beginning to learn the system and am not quite at the level yet where I could debug something like this. It does look reasonable though!

[angelwedge]

Another idea (which I really should have thought of first) is putting the player and all reachable objects in a transparent room; then put that room and the unreachable object in an outer room.

Inside a transparent room, the player can see but not reach objects in the outer room. I can't remember off the top of my head, but I think it still displays the description for the inner room; so the player doesn't need to be aware that the outer room even exists.

This will, unfortunately, give the same ObjectNotOpen message as for putting the object in a transparent container; but this way I think the container itself won't show up in the object list.

But… you can change that message.
I'm not sure if it's in the editor somewhere, but you could always do something like:

bedroom.blockingmessage = "You can't reach it."

in your start script.

I'm not sure why the post suggesting a transparent container involved changing the template (desktop editor only) rather than giving the container a custom blocking message; maybe that's a newer feature since the forum post was written.

[troglodyte111]

That's creative! I'll try it next. Thanks!

[troglodyte111]

This works like a charm, so simple, perfect! Many thanks!!
My other post about pattern matching is now not at all urgent (though I am still a bit curious, I spent half a day chasing the error in my script).

[troglodyte111]

I revive this discussion since there is a problem.
If the player is inside a transparent container (ie an object and a room) there are two possibilities:

1. The container is visible. Then the game will print "I can see a ..." and the name of the container, breaking the illusion that the player is in an ordinary room.
2. The container is not visible. Then this print will not occur. But also objects in the room will not be printed! Objects in the outer room will be mentioned (they can be looked at but are unreachable, as intended). Those within the container where the player is can be looked at and picked up, but will not be mentioned by "look".

I guess I could have a turn script to generate in-room descriptions for all objects in the room. Is there an easier way?

[angelwedge]

Hmm… I've not noticed that before. If the transparent container is scenery, objects inside it appear in the "places and objects" pane, but not in room descriptions. I guess I missed that, because the only time I've used it with a container that isn't an interactable object (like a cage or a fishtank), I was using a heavily tweaked room description.

My first thought would be to make the room description a script which moves all of the objects out of the transparent container before the room lists them (though that will only work if the room description is displayed before the "you can see" line), and set a turnscript to put them back again.

I tested this quickly…
The transparent container/room's description is this script:

msg ("Let's do the thing…")
if (not HasAttribute (object_returner, "return_targets")) {
  object_returner.return_targets = NewObjectDictionary()
}
foreach (obj, GetDirectChildren (this)) {
  if (GetBoolean (obj, "visible") and not GetBoolean (obj, "scenery") and not (obj = game.pov or Contains (obj, game.pov))) {
    if (not DictionaryContains (object_returner.return_targets, obj.name)) {
      dictionary add (object_returner.return_targets, obj.name, this)
    }
    obj.parent = this.parent
  }
}
object_returner.enabled = true
if (HasScript (this.parent, "description")) {
  do (this.parent, "description")
}
else if (HasString (this.parent, "description")) {
  msg (this.parent.description)
}

(the outer room's description is used to store the actual description of the room)

and I have a turnscript called object_returner which does this:

msg ("Running returner")
if (HasAttribute (this, "return_targets")) {
  foreach (name, this.return_targets) {
    obj = GetObject (name)
    destination = DictionaryItem (this.return_targets, name)
    if (not (obj = null or destination = null)) {
      obj.parent = destination
    }
  }
  this.return_targets = null
}
this.enabled = false

This is a very clunky way to do it; and I'm sure there should be a better way. But if you set the transparent container to be "scenery", everything seems to work without the player seeing that it's there.

[troglodyte111]

Oh, thanks! I am no stranger to programming but a newbie on this platform and need some time to digest this. I guess a simpler workaround is to have a room description script simply print out the objects.

I ran some tests. If pov is inside an invisible (or scenery) transparent container, then objects inside the container are not mentioned by "look" but can still be examined and picked. It does not matter if the container is open or closed, and the same holds for surfaces. If the container is not transparent all works as expected (pov cannot see out of it and sees all in it). If the transparent container is visible then "look" returns the same text as if pov is outside the container, i.e., "I can see a #container/room# in which there is a #frob#, which is weird since the pov is inside the container. Basically, for a transparent container "look" gives the same text whether pov is inside or not.

If the room/container is on top level, i.e. there is no parent room, then this anomaly will not occur (though why would one want that?)

I cannot imagine this is a feature. Should I report it as an issue or did I misunderstand something

[angelwedge]

I think that having scenery objects also hide their contents from room descriptions could be desirable behaviour in some situations; it's hard to know what the standard behaviour should be.

Maybe there should be a checkbox somewhere to let you choose the desired behaviour. I think that could be implemented by changing a single core function:

  <function name="RemoveSceneryObjects" type="objectlist" parameters="list">
    <![CDATA[
    result = NewObjectList()
    foreach (obj, list) {
      if (obj <> game.pov and obj.visible) {
        if (obj.scenery) {
          if (GetBoolean (obj, "sceneryshowchildren") and CanSeeThrough (obj)) {
            foreach (child, RemoveSceneryObjects (GetDirectChildren (obj))) {
              if (not ListContains (list, child)) {
                list add (result, child)
              }
            }
          }
        }
        else {
          list add (result, obj)
        }
      }
    }
    return (result)
    ]]>
  </function>

This would allow you to give an object a sceneryshowchildren flag, which causes its children to be shown even when the object itself is hidden because it's scenery.

[troglodyte111]

I applaud your drive to find a general solution. The case is even more complicated if there are nested invisible containers/rooms with pov in the innermost. The only objects listed in the description are the ones in the first non-transparent container, though in all intermediate rooms objects can be "looked at". I guess the scripts need to recur over enclosing rooms. I also tried non-transparent open containers, but apparently it is not possible to look out of an open non-transparent container.

I do think this is an issue, in the sense that the makers probably did not anticipate this. Would you report it? You can probably formulate the problem better than me.