Oh, right. I was thinking about orders but not full viewpoint switching.
Of course, none of the zork games would need that, though others might if the PC can switch. (Some of the middle segments in Hitchhiker’s Guide to the Galaxy come to mind, for instance..)
@zarf If you’re still looking for things to comment on in the code, the balloon is fertile ground because it’s surprisingly buggy for an Infocom game. Particularly in how it handles the receptacle. Much of it is handled by BALLOON-FCN when RARG is M-BEG, i.e. it’s handled when you’re inside the basket but not when you’re outside.
So from inside the basket:
>PUT OPENER IN RECEPTACLE
Done.
>PUT MATCHBOOK IN RECEPTACLE
The receptacle is already occupied.
But from outside the basket…
>PUT OPENER IN RECEPTACLE
Done.
>PUT MATCHBOOK IN RECEPTACLE
Done.
But even from the inside, there are oddities:
>PUT NEWSPAPER IN RECEPTACLE
Done.
>LOOK IN RECEPTACLE
The receptacle is empty.
That’s because anything you put in the receptacle gets the NDESCBIT so that it’s not listed as a visible object (though it’s still in scope), because the description of the balloon already prints that “A newspaper is nestled inside.”
But it also sets NDESCBIT even if you fail to put an object inside:
>PUT SWORD IN RECEPTACLE
The receptacle isn't open.
>DROP SWORD
Dropped.
>LOOK
Volcano Bottom, in the basket
You are at the bottom of a large dormant volcano. High above you light enters
from the cone of the volcano. The only exit is to the north.
The cloth bag is draped over the side of the basket. Directly in the middle of
the basket is a metal receptacle which is closed. A braided wire is dangling
over the side of the basket.
The sword is there, but not visible. Another glitch is in the way it handles the “inflate” verb, because it doesn’t check what you’re trying to inflate:
>INFLATE BALLOON
(with the letter opener)
It takes more than words to inflate a balloon.
>INFLATE SWORD
(with the letter opener)
It takes more than words to inflate a balloon.
Or how it prevents you from picking up the individual parts of the balloon:
>PUT NEWSPAPER IN RECEPTACLE
Done.
>TAKE RECEPTACLE
The receptacle is an integral part of the basket and cannot be removed.
>TAKE NEWSPAPER FROM RECEPTACLE
The newspaper is an integral part of the basket and cannot be removed.
>TAKE NEWSPAPER
Taken.
That’s because the action routine for the receptacle gets called both when the receptacle is the primary object and when it’s the secondary object.
Some of these I already knew about, others I discovered (or maybe just rediscovered?) in the last few days.
4 Likes
They may have been planning ahead: see also the existence of the PLAYER global variable, which is set to ADVENTURER and never changed.
I don’t intend to comment every single known bug, but general categories like this are worth noting. Thanks!
Hm, here’s one. In r48, does the SALTY-WATER have any function? I haven’t been able to get it by any means. Zork II - Nathan Simpson's list of Infocom bugs concurs that it’s not takeable, which means the object is entirely useless.
(If you could get it, it wouldn’t work with the current bucket code anyhow.)
1 Like
I don’t think it does. Earlier versions allowed you to fill the teapot with salty water in the Pool Room, but even just trying to drink it would print garbage when I tried it. I guess someone noticed how broken it was and how much work it would be to fix it, and just gave up. In Mainframe Zork the Pool Room is filled with brown colored goop, not salty water, so apparently it never worked?
Another thing I haven’t been able to find the use for is BROKEN-CASE. There’s code in there for asking the demon to smash the Wizard’s trophy case, but I don’t think you can actually get him to do it? There are a couple of other incorrect things you can ask him to do, like moving or taking the menhir, but I seem to recall the room description in the Menhir Room not being correct if you that?
Probably – but none of the logic in WATER-FCN changed, as far as I can see. (Comparing with r22.) Nor did the SALTY-WATER object itself change. I’m not sure what broke the <MOVE ,SALTY-WATER ,TEAPOT> path – must have been something in the parser – but then it was a matter of deciding not to fix it, rather than actively removing the code.
EDIT: Oh, I see it – they removed GLOBAL GLOBAL-WATER from the Pool Room. That was the deliberate change then.
The larger plan is now public: https://www.patreon.com/VisibleZorker
I have started a Patreon to do all the remaining Infocom games in Visible form. (All the v3/4/5 games, anyhow.)
One per month, starting in March.
8 Likes
What hooks into the interpreter does visiterp need?
(It hurts to see you using the abomination that is Parchment circa 2011. So no promises for when I’d get to it, but at some point when I’m rewriting ZVM I might as well add hooks…)
I know it’s terrible – recall the bug where saving twice in a row would break the save system! (I fixed that.) However, it’s lightweight and it only has to work with original Infocom games, not the full catalog of what Inform authors have done. So far, it’s solid.
(I admit that I’m nervous about what happens when v4 comes on the scene.)
Lemme see.
@print_addr, @print_paddr, @print, @print_ret opcodes: call _vm_report_string() on the unpacked string address. Also when printing an object name.
When pushing a function on the stack: call _vm_report_call(), passing the destination address and the argument list.
When popping a function off the stack: call _vm_report_return(), no arguments.
I also call _vm_report_call() in load_saved_save to ensure that the stack looks right after a restore.
Aside from that, the (cut-down) GnustoRunner calls reset_vm_report() at the top of its run() function. This resets the accumulated lists of prints/calls. At the bottom of run(), it does window.dispatchEvent(new Event('zmachine-update')). My event listener takes it from there.