It’s one I described before: it’s making an indirect call to address 0. It gets the address probably from @get_prop or another opcode I forget right now (on my phone). The bug is probably several opcodes back, but it only manifests when trying to disassemble address 1.
To find that I would try hacking both Frotz and Parchment to print out the Z-Machine PC for every opcode executed, then see where they differ. (If you try this, though, watch out for calls to @random.)
Calling address 0 is legal, and should result in a false return value: 6.4.3: “A routine call to packed address 0 is legal: it does nothing and returns false (0).”
How did I miss that? Thanks Cas!
While this thread is here… there seems to be a couple bugs when trying to play my game In a Manor of Speaking.
iplayif.com/?story=https%3A//dl. … ing.gblorb
For some reason, the line at the top doesn’t display the full location name, and the first command you type in doesn’t print correctly. Other times when I load it up, the top bar doesn’t show up at all (but when this happens, the first command isn’t messed up), which is also a bit odd. I’m using Firefox 24.0 on Win 7.
The status line is known to work poorly when Quixe (the Glulx interpreter) is embedded in Parchment.
Yes, unfortunately Quixe is still a second class citizen.
Okay, I think I’ve fixed @call 0. Sherlock no longer crashes. But it interprets every valid command as the go verb.
Although this turned out not to be the culprit, it did bring to mind a couple of things.
First, Bocfel does not handle this Sherlock issue. If attribute 48 is used, Bocfel exits with an error message. Does anybody know what game command(s) trigger this behavior? If ignoring this attribute is required to complete the game, I’ll obviously want to add special Sherlock support, but if it’s something obscure, I’m less inclined to do so.
On that note, Sherlock 21-871214 also tries to test attribute 302. Unlike the attribute 48 bug (which appears to be an off-by-one error; see the routine at 0x22398), attribute 302 is explicitly set: see address 0xdfd7:
TEST_ATTR G78,#012e [FALSE] dfe5This is triggered by something like “empty coat into coat”. Not especially useful information, but worth noting I figure.
Did someone say “Infocom bugs”?
The attribute 48 bug in Sherlock is caused by destroying one of five objects. I’m pretty sure you can’t get the emerald without triggering it, so yes, it’s necessary.
These commands will trigger the bug in Bocfel, in either release of Sherlock:
KNOCK ON DOOR. U. N. GET NEWS. SHOW HIM IT. S. D. N. GET BOOK. OPEN IT. LIGHT MATCH. BLOW OUT MATCH
Ah hah, thank you for pointing this out. The next version of Bocfel will contain a fix for this problem.
To bump this topic, I can verify Stuff is Getting Fixed. I built Threediopolis and ran it on the web with an old version (1/2012) and the yes/no froze up. I downloaded the latest link from this topic(thanks Laroquod for sharing it!) and it worked! I’m very pleased about this.
I’ll be updating parchment more from now on.