Booths are weird, aren’t they? Especially closeable ones. I have almost always gotten in the habit of implementing them as adjacent Rooms if they have doors, as getting doors to work on a booth is more work than worth, probably.
That said, let’s say, for the sake of argument, you are pot committed to using a closeable booth, and don’t want nonsensical responses to players trying to look at the door. Here is the pattern I backed into to implement that. Note, I don’t try to use real doors, but ‘fake’ them, and rely on booth status itself to keep things coherent. Also need to do some work to ensure only one ‘side’ of door visible at a time. Is there a cleaner solution I am missing? Looked briefly at expanding on ContainerDoor but that presumes a Complex Container, and adding the Inner Door implementation felt even kludgier.
containingRoom : Room 'Room with Booth' 'booth room'
"A room with a booth in it. "
// etc...
;
+ Openable, Fixture '(booth) door*doors' 'booth door'
"A functional enough door. "
// when booth is open, both sides of door can be visible!
// ensure outside of door only visible when outside booth
addToSenseInfoTable(sense, tab) {
if (gPlayerChar.isDirectlyIn(containingRoom))
inherited(sense, tab);
}
masterObject = standaloneBooth
;
+ standaloneBooth : Openable, Booth, Fixture
'standalone booth' 'standalone booth'
"A standalone booth, close but not claustrophobic. "
isLookAroundCeiling(actor, pov) { return true; }
;
++ Openable, Component '(booth) door*doors' 'booth door'
"A functional enough door. "
// and the converse, only visible on inside
addToSenseInfoTable(sense, tab) {
if (gPlayerChar.isIn(standaloneBooth))
inherited(sense, tab);
}
masterObject = standaloneBooth
;
As an additional step, could add ThingStates for open/closed to respond to player >X OPEN DOOR Kind of wild those don’t preexist in adv3!
(note example above not compiled/tested, streamlined from tested version)
EDIT: outside of door should be Fixture, not Component
IIRC to have bumped in this weird implementation in trying to implement a bathtub’s curtain when learning adv3, three or so years ago… perhaps I can recover the mess from a backup external HD, but don’t hold your breath…
(OK, a translucent door whose PUSH and PULL are synonyms of OPEN and CLOSE, well, perhaps was rather ambitious… but I think is an effort worth its value in the case of coding a classical thriller scene…)
Hm, I guess I don’t have anything exactly like yours. I have two doored booth situations, but one has a non-opaque material so closing the door on yourself isn’t a problem (and the sides of the door are the same), and the other one holds other Actors but the PC passes through it if trying to enter.
Without having tested the situation out, I think I would have started off with a ComplexContainer with a Booth for sub-location and tweaked from there, but not knowing how greatly you want to differentiate handling between the two sides of the door, maybe I would discover that wasn’t the way to go after all.
Are your booths of the type that send you to the dark if you close the door from inside? I note that the ComplexContainerBooth/ContainerDoor situation doesn’t work without extra gymnastics if the Booth walls are opaque: the door is never properly in scope when the Booth is “closed”, and getExtraScopeItems doesn’t fix it. If the Booth walls are fineMesh etc. you can interact with the ContainerDoor.
Also there is the question, how greatly do the handling of the two sides of the door differ? Is it more than what you can effect by
ContainerDoor
insideCond = gActor.isIn(theBoothObject)
desc = "<<if insideCond>>The inside of the door desc.
<<else>>The outside of the door desc.
dobjFor(KnockOn) {
action { "<<if insideCond>>Muffled because the inside
of the door is styrofoam.
<<else>>Loud noises because knocking on hardwood. ";
} }
// etc.
;
It is true I provisioned an interior light source I didn’t mention above. I didn’t think to try a transparent booth material, wouldn’t that also put everything in the containing room into visual scope from inside (or expose booth contents to outer room)? I can see how that would at least address the light and door visibility question.
Honestly, the two door sides are only necessary so you have a door when closed inside. It might allow differing open/lock capabilities but as you noted, nothing that couldn’t be addressed with if (insideCond) I guess I would be worried about fighting transparent booth artifacts though.
haven’t found the actual attempt to curtain the tub, but this is the tub as before… and after:
// adapted from the booth in the T3tourguide (pp. 187-8)
+ tub : Booth, Fixture 'simple white bath/tub/bathtub' 'bathtub'
"The bathtub is white, and of simple design"
interiorDesc = "The bathtub is empty; you can test sitting and lying on."
defaultPosture = standing
basicExamine() //if inside, the custom interiorDesc, else the normal desc
{
if(gActor.isIn(self) && gActor.canSee(self))
interiorDesc;
else
inherited;
}
;
As one can see, is a vanilla one, my idea back then was of adprose the tub re. open/closed and empty/full, the latter worked well, (at least from the TODO file, where I noted the idea of a “faucet/mixer puzzle” for a warm bath, neither too cold or too hot) but the former, well, perhaps is best that the failed attempts ended in the bit bucket…
Best regards from Italy,
dott. Piergiorgio.
ps. thanks for giving an excuse, (at the right time, too !) for look again at my old learning code; with hindsight, if I remove the reference to copyrighted settings (and improve the rather bad english…) perhaps will be a good, if not an excellent T3/Adv3 working source example…
Oh yes, you’re right… that’s why I was saying that the ComplexContainer/ContainerDoor route didn’t work without performing extra gymnastics. Your approach may possibly be the one that causes least gray hair in the end as far as making an opaque Booth with a door object (as mentioned, my Booths turned out to be wooden slat enclosures which passed sense info).
Interestingly, your addToSenseInfoTable is probably equivalent (I haven’t checked the nuances) to what I was doing with sightCond, mentioned in the TADbits.
One small suggestion comes to mind if you’re not trying to differentiate the sides of the door, but merely have a door in scope inside:
+ boothDoor: [Classes of choice] 'vw' 'name' "desc"
// in case you want to distinguish in descs/handlers
insideCond = gActor.isIn(booth)
// all the properties, descs, and verb handlers
;
+ booth: Booth, etc.
;
++ boothDoor
sightCond = insideCond && !booth.isOpen
; //this obj will copy all the descriptive stuff from the
//first declaration; the original shouldn't be in scope
//when the Booth is closed
Assuming you do your same linkage stuff to the Booth’s open state, etc.
Not tested…