(Still) Trying to Learn How to Handle Enterable Objects

[KVonGit]

My previous attempts at enterable objects and vehicles never ended up working quite right. I now see this was because I was trying to make Quest behave like Inform.

A Quest game can surely do anything an Inform game can do, but the coding approach will usually be quite different. When I was using Inform 7, I didn't understand how different things are. Now that I've used Inform 6 (which is what Inform 7 converts the code to before compiling it), I have seen the light -- at least to some extent.

When I first asked how to handle this in Quest, the response in the forum was to switch the POV to a "player in a vehicle" object. I tried this back then, but I didn't understand scope at the time, let alone how we could use the game's scope backdrop script.

Okay... To be honest, at this very moment, I don't have a clear idea as to how we should handle an enterable container/vehicle when we can drop things inside of it. Nor could I just tell you how we should handle trying to take things which are outside of our closed container/vehicle.

As far as scope goes, if using the ChangePOV approach when the POV is the vehicle/container we can get inside, I would think:

• create an inaccessible room, to hold things when we drop them (I assume we can't just move things to the container itself, else it would show up in inventory)
• use the scope backdrop script to add everything in this room to scope while the POV is the vehicle/container
• add a script to move things from that room to the actual object upon exit
• I don't quite know how to easily handle commands attempting to touch things we can see on the outside when we are inside a closed, transparent object.

If the object is a surface (like a chair or a stool), I guess we'd only have to modify the go command. 🤔

If the object is a rideable vehicle, like a horse or a motorcycle, I guess the trick would be to make that a closed, transparent container, with the same code for a car, but saying something like "You can't reach that from up on the horse." rather than "You can't reach that from inside the car with the doors closed and all the windows up."

...or, like, one game I helped port to Quest started you off in a chair in your living room. In the original, you could reach the things on the coffee table, but you couldn't reach anything else in the room from the chair. There was another location (a pub) where you had to sit on a stool to get the bartender's attention in order to get you (and your dog) a drink. From the stool, you could only reach things on the bar, but there were many other objects (including the non-player variety) in that pub. I ended up including both the chair and stool objects in the port, but you couldn't sit in/on either of them. "No time to rest!"

---

The old Infocom (and current Inform) games have a global variable called HERE, and (most) objects in play are assigned a LOC. Normally, the player object's LOC is the same object as HERE, but, when we enter a vehicle, our LOC becomes the vehicle, while HERE is the vehicle's LOC.

That sounds like things would mostly work the same in Quest when changing the POV to the vehicle, and fairly smoothly, except for objects in scope (including the vehicle/container/surface we are currently in/on).

We can likely use TestTake and TestDrop to check if the POV object has a vehicle, container, or surface type to easily handle taking and dropping. I don't think we had those functions the last time I tried this.

It seems we might need like a drop_here attribute for the container and surface types, to use when the POV is the object (or in/on the object).

What about the go command, though? Is there a new function we can use to interrupt going if game.pov has no_going set to true, or something like that?

I don't know what else might come into play. It's all too much for my little brain. 🤯 😆