Mystery House parser question

Authoring Other Development Systems
1

I have a strange question.

I’m looking into Mystery House (Sierra, Ken and Roberta Williams) and am having trouble understanding a piece of the parser logic. Specifically, when typing LOOK NOTE in a place where there is no note and the player doesn’t have one in inventory.

The response from the game is IM NOT CARRYING THAT
However, that phrase does not show up in messages.txt in the .dsk file.

As part of their archeological study Inspecting the Foundation of Mystery House, Aycock and Biittner posted some tools and logic extractions to github: GitHub - aycock/mh: Analysis tools for the 1980 Apple II game Mystery House

In dumpgame.out we see the following logic

if VERB = "LOOK" and NOUN = "NOTE" and OBJECT "NOTE" CARRIED then
	print "THERE IS WRITING ON IT"
if VERB = "LOOK" and NOUN = "NOTE" and OBJECT "NOTE" CARRIED then
	print "THERE IS WRITING ON IT"
if VERB = "LOOK" and NOUN = "NOTE" and OBJECT "NOTE" CARRIED then
	print "THERE IS WRITING ON IT"
if VERB = "LOOK" and NOUN = "NOTE" then
	print "YOU DONT HAVE IT"

But YOU DONT HAVE IT doesn’t appear when LOOK NOTE is performed. So something is overriding that case, but doesn’t override other, similar cases. :thinking:

In “Mystery House Taken Over” mhto.inf file I see that “note” and “read” have IM NOT CARRYING THAT and not YOU DONT HAVE IT. However, YOU DONT HAVE IT does show in mhto.inf when trying to burn the candle when it isn’t in the player’s possession (which is slightly different than the original’s apostrophe’d YOU DON'T HAVE IT)

So, it doesn’t seem to me that the original ever bothers with any proper “is the noun in question in scope” issues. The “light a candle you don’t possess” logic works as expected, based on dumpgame.out (i.e. IM NOT CARRYING THAT doesn’t jump in and override things). You can also LOOK GUN at any time to see the bullet count, even if you’ve never seen the gun at all. Why wouldn’t those cases have also been overridden with the IM NOT CARRYING THAT message?

Admittedly, dumpgame.out doesn’t contain EVERYTHING from the game, but I would have expected IM NOT CARRYING THAT to show up in messages.txt at the very least.

Does anyone have any insight into this message and what exact condition triggers the display of IM NOT CARRYING THAT? (maybe it’s a simple as there is some secret code somewhere that overrides only for notes? :person_shrugging:) Are there any other known cases of IM NOT CARRYING THAT displaying? Is there any known way to trigger the YOU DONT HAVE IT message that the original game logic indicates should happen?

1 Like
2

I guess the first thing to check is – are you playing the original game on an Apple II emulator? The Glulx port may not be accurate.

Hm, I don’t know the nature of ‘The Mystery House Occupation Kit’ used in that project. I mean, I don’t know to what extent they reverse engineered things from the outside, or dug code out of the game, or what. There are probably people on this board who do, though. Either way, I guess because MHTO is all remix, you probably can’t trust its output for to make inferences on the exact logic of the original program.

I’d say this is the key. dumpgame looks likes its parsing certain stuff into readable English for us, but I’m sure there will be code in there that doesn’t fit dumpgame’s probes, and which thus won’t come out that way.

I’m pretty sure the core of the game was written in assembly; this is slightly hard to verify with a sentence somewhere online that just says ‘It was written in assembly!’ The article you linked claims to have verified the point with a 1984 citation.

The reason I belabour this point is I want to make sure that the output of dumpgame isn’t just BASIC code. Because it reads exactly as Applesoft BASIC! Yet if the game was written in assembly, unless it was turned into assembly with a compiler, there should be no complete statements in the game that read like the output of dumpgame. I just wanted to be sure that dumpgame is constructing these lines itself by parsing assembly code.

See, looking at this line on its own, this is the kind of line that could have some other precondition that hasn’t been captured by dumpgame. For instance, if we simply haven’t been to a room with the note, the authors don’t need to bother to check whether we’re carrying it or not. They could just say, ‘No chance you have it,’ yet in this case acknowledge you might have played before and know about it, and so have to say ‘You don’t have it.’

Or… if the programming’s as sloppy as you say (which I don’t recall and haven’t doublechecked) this could be more important as a geography-oblivious block on looking at the note when you don’t have it, a block you say they don’t bother with in the case of certain other objects. e.g. Looking at bullets in the pistol.

So I’d say to truly answer your question, you’d have to dig into the logic in the assembly code, which is a step further than the github tools go. And very non-trivial :slight_smile:

-Wade

1 Like
3

Yes, I’m playing the original game on an emulator.
It is also true that the output of dumpgame.out is a translation of the machine code, by way of the author’s custom Python script, to convert the code into something human-readable. It is not attempting to output BASIC, but it is generating from the original assembly.

So far in my testing, the logic it produces has been accurate. I’ve read through it and found cases where I thought, “If this logic is true, then doing X should produce a bug.” and sure enough that bug exists. So there is at least some degree of trustworthiness to dumpgame.out from what I can ascertain.

The logic, as produced by that Python script, absolutely has a whole list of logic checks that could absolutely interrupt the output of YOU DONT HAVE IT but, to my original point, the actual string IM NOT CARRYING THAT is nowhere to be found at any point in the file. Which is very odd, considering how thoroughly that file has covered so many other cases, from start to endgame.

I appreciate your input, thank you!

2 Likes
4

OK, I finally thought of looking at the hex dump of the original ADVENTURE file on the Apple2 disk. Found the message in there, which seems to be where I’d expect it to be, i.e. clustered with other generic messages.

image

2 Likes
5

Ah cool. You’re way ahead. I was going to suggest doing something like this. And for people who aren’t Apple II au-fait, sometimes you can even just drop the disk image on a text editor like BBEdit or Notepad, and see English content that way. It will be scattered amidst a bunch of gobbledigook.

-Wade

1 Like
6

This is confounding. In the gamedump.out logic, only NOTE captures a failed LOOK, where everything else appears to default to THERE IS NOTHING SPECIAL (so far, in testing, this is proving to be the case). Yet the NOTE failure message ignores the one in the logic code and falls back to the one in the hex dump. So strange (both the result and the fact I’m spending so much time on this)

1 Like
7

Why would there be multiple identical lines? My guess is that the code is duplicated among different rooms. So, have you tried going to different rooms/locations and see if the message changes? Or perhaps after certain events/puzzles being solved.

1 Like
8

There are a lot of repeated lines, especially with regard to the NOTE. I think the original authors might have been struggling with “we have multiple notes, but they’re all called “note” and we need to untangle ambiguities” and kinda-sorta didn’t do a very good job with that. Rooms have specific logic attached to them, and I don’t see any room + read + note logic (though the totality of gamedump.out is a bit in question).

Such logic does exist for other things though. For example, if you GET NOTE anywhere, you’ll just get the note. But if you GET NOTE in the tower, it will print OK. That verb logic is exclusive to that location. Other things are attached to things like one of the boolean flags being set, or which specific room picture is being shown, but not for NOTE that I can tell.

2 Likes
9

This is a great example of the sort of headache you might be saving a future investigator by releasing your source code on @DeusIrae 's Source Code Amnesty Day.

2 Likes
10

I’m going to write up a full blog post on my findings in due time. This research is part of a pair of projects, which will all be published to my itch.io page.

2 Likes