Is the fact that actor containers cannot attract objects intended? It would be helpful to have because you may want to have, for example, a wall which the actor can examine while inside the container, but not while outside (in the room that contains the actor container). Given things can be #in the actor container, it makes sense for actor containers to be able to attract objects, as well.
Currently, this can be worked around by adding an condition for [look $] (#player is nested #in #container), but actor containers being able to attract objects would be nice, too.
Edit: Clarify that I meant nested #in, not simply #in.
Additionally, (look *) while inside an actor container does not override the room’s description (even though (look *) seemingly is for defining the description when a player is in something). I’m not sure if this is a vestigial behavior from Zork or Inform, or an oversight.
Also, note that if the player is inside a closed, opaque container, they are in darkness and can neither see the room’s description nor interact with items in the room that are outside the container (i.e. works as expected). However, when the player is holding an item which provides light while inside said container, “looking” allows the player to see the room description (probably not intended), while not being able to see or interact with the room’s other contents (as expected).
For your convenience, this is what I was using to try it out:
(current player #player)
(#player is #in #lab)
#lab
(room *)
(name *) Lab
(look *)
This is where you experiment. There is a box here.
#box
(name *) box
(actor container *)
(* is #in #lab)
(* is opaque)
(openable *)
(* is open)
#rock
(name *) rock
(item *)
(* provides light)
(* is #in #lab)
(* is handled)
#ball
(name *) ball
(item *)
(* is #in #lab)
(* is handled)
Actor containers can’t attract objects. This is intentional, but not set in stone. It is a very interesting suggestion. What should happen if both the container and the room attract the same object? What about supporters, or objects that are both containers and supporters?
I don’t get a clear picture of the suggested use-case where a wall is visible in the container but not in the room. Do you mean an inner wall of the container?
(look $) does not work properly when inside a container. This sounds like a bug. “LOOK” should trigger (look $) for the innermost container, and the default implementation of (look $) should delegate to the parent…
…except that the default implementation of (look $) should not delegate to the parent of a closed opaque container. This also sounds like a bug.
About the suggested use-case: yes, an inner wall of the container. Say you have a “dock” region with barrels in every room of this region. You’d like “wall” to refer to the “barrel wall” - except you can’t do that, because actor containers can’t attract objects. The best you could do is make a “fake out object” (in this case #barrelwall):
#barrel
(name *) barrel
(dict *) cask cylinder
(descr *) This is a wooden barrel made of white oak.
(actor container *)
(* is #in #pier)
#crate
(name *) crate
(dict *) box chest container
(descr *) This is a wooden crate.
(actor container *)
(* is #in #pier)
#barrelwall
(name *) barrel wall
(heads *) wall
(descr *) It's made of lightish-grey white oak.
(* is #in #pier)
(prevent [examine *])
(#player is nested #in $Obj)
~{ ($Obj = #barrel) (or) ($Obj = #crate) }
You can't see that here.
(perform [look])
(#player is #in $Obj)
{ ($Obj = #barrel) (or) ($Obj = #crate) }
(try [examine $Obj])
#pier
(name *) pier
(look *) The smell of fish is strong - though you aren't sure if it comes from the sea, or from the many barrels and crates of fish around you.
(room *)
#player
(current player *)
(* is #in #pier)
But I guess this is an instance where author-specified “screw the rules, this is what happens” overriding general restrictions might be a better idea.
There’s another use for this that I failed to mention. Say you wanted “fish” to be visible in barrels and crates, but not outside (in the dock). This is a use for attracting objects inside actor containers (but not into the room).
Here’s where it gets complicated: When you are in the docks, but neither in the barrel nor the crate, then you would still be able to see the fish in the barrel and the crate. At least that’s how normal objects work. And the parser should understand e.g. “take fish from barrel” (even if the action fails).
I think I would model this with two fish objects; one in the barrel and one in the crate. But then you run into disambiguation issues, so you’ll end up specifying things like:
(unlikely [examine #cratefish])
(#player is #in #barrel)
(unlikely [examine #barrelfish])
(#player is #in #crate)
But all right, suppose we go for a common floating fish object. If containers could attract objects, then the system would probably have to be designed so they end up in either the innermost or the outermost attractor that encloses the player. The docks should also attract the fish in this case, to allow the player to examine the fish from outside the containers before visiting one of them (and not just after). Entering a container and closing it would bring the fish inside. The question is if the fish should be inside already after entering, before closing.
By the way, the traditional way to approach this would be to have a barrel of fish and a crate of lobsters. Somebody should write a paper about how parser-based interactive stories are always told with uniquely distinguishable props.