Is it a classic Infocom release without a hands-related bug?
It is a classic bug, I guess, but in this case I introduced it myself by removing the code that fixed it. The idea here was to fix bugs, not cause them! 
2 Likes
I noticed another bug I had introduced. I thought non-player characters couldnāt die in the game, but I was wrong so Iāve put back the code that dealt with that. (I hate it when that happens.)
So itās time for a new release again. Fortunately I found some other code that could be removed, so the game shouldnāt have grown since the last one.
3 Likes
Release 11 with better abbreviations, here.
Without abbrv 60,154 bytes
Zilf abbrv 54,068 bytes
Improved abbrv 53,388 bytes
1 Like
Interesting that while the version with the best abbreviations still grew slightly compared to the previous release. Oh well. If it becomes a problem, thereās always the debug commands that can be easily removed by changing the line <SETG DEBUGGING? T> to <SETG DEBUGGING <>> in mini2.zil. I donāt think Ozmoo handles command recording and playback anyway, does it?
The abbreviations are not the ābestā. You would, for example, save 3 bytes if you move āreceptaclā to before āe.ā and change it to āreceptacle.ā. Iām struggling to make the algorithm to identify it, thoughā¦
No.
Have updated the C64 disk image on Drive.
2 Likes
Thereās a Release 12 now. Iām done with my own testing, so unless someone else finds something this may very well be the final release. (And hopefully the end of me doing force pushes to the repository. Sorry about that!)
Edit: Annoyingly, Iāve made one change since that, but it was something the compiler should have complained about but apparently didnāt. So I guess it didnāt make any difference?
3 Likes
Release 12 with better abbreviations, here.
Size Diff release 11
Without abbrv 60,140 bytes (- 14 bytes)
Zilf abbrv 54,032 bytes (- 36 bytes)
Improved abbrv 53,370 bytes (- 18 bytes)
1 Like
Updated c64 disk image at Minizork 2 - Google Drive to use release 12 too.
2 Likes
I tried playing it for a bit, but after a while it started printing corrupted text. The first I noticed was that it printed āzzz.ā where I think it was supposed to say that the Wizardās āFreezeā spell wore off, and then āZā started responding with āopenojlojszTime passesā¦ā.
Is that a problem with the game or with the C64 emulator (VICE) that I used?
(In the meantime, I did make one tiny change that I think ZILF should have flagged as an error but didnāt. But I donāt see that making any difference. At least I hope it wouldnāt.)
Hm, interesting. The best way to tell would be to try the game in Frotz with the exact same commands.
I havenāt noticed any such problems while testing in Frotz. In Ozmoo, I canāt think of any way the āwaitā command would print garbage because of a ZIL error, and it worked at the beginning of the game (and I havenāt reproduced it since). So it felt more like some sort of memory corruption, but whether that was Ozmoo or VICEā¦ who knows?
I donāt know if this is a bug or if itās intended, but:
>i
You have:
A china teapot
The china teapot contains:
A quantity of water
A elvish sword
A brick
The brick contains:
A black string
A matchbook
A package of candy
A red crystal sphere
A lamp (providing light)
>drop all but lamp
china teapot: Dropped.
elvish sword: Dropped.
brick: Dropped.
black string: You're not carrying the black string.
matchbook: Dropped.
package of candy: Dropped.
red crystal sphere: Dropped.
But the message with the string, inserted in the brick, is a bit strange.
Having spent hundreds of hours debugging Ozmoo problems using Vice, I have never found Vice to be the problem. So most probably itās Ozmoo this time as well.
My best guess is that this has to do with the buffer used to access RAM hidden under I/O and ROM. Itās 4-5 pages by default, but I set it to 2 pages for this build. Sometimes one of them holds the page where the PC (program counter) points, and that page canāt be changed. Perhaps thereās a scenario where the other page shouldnāt be changed either but when thereās only two pages to choose from itās changed anyway.
Iāll try to reproduce the problem.
This is the type of bug that scares me, but I guess itās somewhat reassuring that it also happens in the full game.
On the other hand, I canāt reproduce it with Zork Iās sack. I think it may have something to do with the containers in Zork II having SEARCHBIT. Many containers in Zork I do as well, but not the sack. Adding it causes a similar bug:
>DROP ALL
brown sack: Dropped.
lunch: You're not carrying the lunch.
clove of garlic: You're not carrying the clove of garlic.
But without it, itās fine. Removing it from the brick fixes this particular problem as well, but what does that do? This is what Marc Blank had so say about SEARCHBIT in his ZIL manual:
12.1.5 SEARCHBIT
Means that one can see things inside of things inside the container that has this flag set. The
default is that one can only see things through one level of containment. OBJECTs with the
SURFACEBIT act as if they have the SEARCHBIT as well.
Steve Meretzky was a bit more passionate about the subject in his:
SEARCHBIT: A very slippery concept. It tells the parser to look as deeply into a container as it can in order to find the referenced object. Without the SEARCHBIT, the parser will only look down two-levels. Example. Thereās a box on the ground; thereās a bowl in the box; thereās an apple in the bowl. If the player says TAKE APPLE, and the box or the bowl have a SEARCHBIT, the apple will be found by the parser and then taken. If the player says TAKE APPLE, and the box and bowl donāt have the SEARCHBIT, the parser will say āYou canāt see any apple right here.ā Frankly, I think the SEARCHBIT is a stupid concept, and I automatically give the SEARCHBIT to all containers.
Iāll play around with it later to see if I can find any downside to removing that bit. There arenāt many ways to get deeply nested containers in Mini-Zork II anway.
Yeah, I noticed there was a difference between the teapot and the brick. The only objects that have the SEARCHBIT are the receptacle, the purple book and the brick. The receptacle shouldnāt be a problem because you canāt pick it up. The purple book, but not the brick, have the CONTBIT set. Does this make a difference? Or do the purple book acts in the same way?
I never noticed that! I guess CONTBIT isnāt required for the object to act as a container. Maybe itās so that you canāt open and close the brick, but it also means that āFIND STRINGā will cause the game to respond āBeats me.ā instead of āItās in the brick.ā
Apparently it does:
>INVENTORY
A lamp (providing light)
A purple book
The purple book contains:
A Flathead stamp
>DROP ALL
lamp: Dropped.
purple book: Dropped.
Flathead stamp: You're not carrying the Flathead stamp.
Edit: By the way, this may have changed in later games because I canāt reproduce this in, say, The Hitchhikerās Guide to the Galaxy.
I just looked a bit closer at The Hitchhikerās Guide to the Galaxy. There does indeed seem to be some code in MAIN-LOOP which checks if found objects are still relevant for the current command when dealing with multiple objects.
Itās probably overkill to introduce anything like that to Mini-Zork II, unless the SEARCHBIT thing absolutely, positively will not work.
Edit: It seems that Mini-Zork II does have a limited form of that. See the āmultiple exceptionsā comment. In The Lurking Horror, to pick an even later game at random, this logic was moved to a separate MULTIPLE-EXCEPTION? routine that āreturn[s] true if an object found by all should not be inclued when the crunch comesā.
Edit: And in some other games, that separate routine is called DONT-ALL. I guess that may be interesting if you were trying to trace which games were based on which older games.
Can you tell if the texts that should have been printed contain abbreviations?