Infocom Game Mods - 2021 Friendly Versions

Oh, I think the word I was looking for was ‘cracking’:


I think that project needs some kind of manifesto what the goal is and how far to take the changes. My own preference would be conservative and only fix the bugs and make them compile nicely in ZILF but not to change the game play. The game should be as close as possible to how they were intended to be.

I would like to help to go through all of your reported issues and fix them. It wouldn’t be much work because you often identified exactly what needs to be done!

The modded games could spin of from these “perfected” games as a seperate project.

1 Like

Yes I’m very much on the mod side. I think fixing and preserving the original games is very important but alongside this I would really love to see what the community can come up with to make the games more enjoyable for the modern player. If that means softening them then so be it, we are after all not removing the original games so if you like your Infocom hard core then this will always be there.


1 Like

Have you, before or during your testing, looked at Graeme Cree’s ot Nathan Simpson’s Infocom bugs lists?


I remember introducing my son to Zork I some years ago and within 20 minutes he found a bug I’ve never seen listed as a known one…although I haven’t checked in a long time, so it may be known now.

I can’t remember how he did it exactly, but it had something to do with the rope and the railing in the Dome Room. It caused Frotz to print some garbage characters.

Edit: I verified it in my own interpreter at the time, but I don’t recall the details.

1 Like

BEWARE !! BOX galore ahead !!! :smiley:

Best regards between the grins,
dott. Piergiorgio.

1 Like

and, believe it or not, there’s people bent into preserving crackers’s custom title screens (often little gems of coding):

sizeable collection of “custom title screens”…

1 Like

The rope one is known –

“In version 2, if you are at Dome Room with the rope tied to the railing, then JUMP gives no output.”

“No output” in the original can mean garbage characters in a different interpreter.


Nope, that’s not it, and it wasn’t version 2.

1 Like

I’ve tried (not always successfully) to stay away from them, because I wanted to go into testing reasonably blind. Also, some of the bugs are unique to the preserved source code because changes were made past the last official release, and a few other are caused by differences between ZILF and ZILCH.

But of course, those bugs should still be tested at some point to see if they’re still there.

I didn’t see anything in that particular room, so maybe it was fixed in later versions? Or I’m overlooking something obvious. That sort of thing usually happens if you try to write the description of an invalid object, e.g. object number 0. The exact garbage it prints is probably implementation-specific. It happens in Infocom’s own interpreters, too.

Such errors are pretty rare in the wild, but here are some easy-to-reproduce examples:


Trying to destroyJohnson with a ck it's k feher x is silly.


The b   doesn't respond to your gesture.
[the splinter]

The splinter illuminates the b   rather poorly.

The second Trinity example is more of a parser bug, actually. “SHINE” is not correct syntax, and it’s supposed to ask the player to specify what he wants to shine the splinter at. If you type “SHINE SPLINTER” instead that’s what it does, but apparently once it has inferred that it’s the splinter you want to shine it thinks it has everything it needs. (I think that bug was fixed in Beyond Zork, but quite possibly not in any other game. I don’t think many games ever try to infer the direct object - the splinter, in this case - only the indirect one.)


To go back to modernization, rather than bug fixing, for a moment… Would it be sacrilege to adjust the Zork I thief in any way? He’s easy enough to avoid, but it’s a little annoying to have stuff stolen. Not as much of a problem with unlimited carrying capacity, I guess.

1 Like

Well - that’s the beauty of the source code and ZILF, we can create unlimited Mods. :slightly_smiling_face:

It’s hard to keep the conversation focused on mods which is something I’m keen to push and experiment with. The mod conversation always goes back to bug fixing which is not really what I had in mind.

We’re limited only by imagination and file size. Maybe you can talk to the Thief and convince him to help you, maybe you can build in extra weapons or other uses for weapons - for example the sword, you really only need it to kill the Troll, after that you can actually drop it. Seems a little wasted.

That said, maybe it’s not something of any real interest (Mods I mean), I guess if it was it would have been ran with by now.

Adam :slightly_smiling_face::v:

1 Like

Well, surely you want a solid foundation to build that mod on? Particularly Zork I-III seem to have gone through a lot of iterations, and unfortunately the latest source code (which I think was never actually used to produce any officially released versions) has some pretty surprising bugs. For instance in Zork III you don’t need to worry about the lantern running out, because it does you can simply light it again.

Of course you could always base your mod on an older version of the source code, if that’s available.

1 Like

That last point is important. If you don’t have to leave equipment caches lying around, the thief is less of a bother.

On the other hand he is a significant part of the game’s tone. I wouldn’t want to entirely nerf him.


  • The thief will randomly steal items or treasures from your inventory. He will also randomly pick up items from the dungeon, as long as the player has touched them. (Both of these are as in traditional Zork.)
  • However, he will not touch the sword, not light sources, nor treasures that are puzzle requirements (e.g. the scepter). (But he’ll happily steal the egg, of course!)
  • Treasures go to his lair.
  • Non-treasure items will be discarded in an accessible adjacent room, or a couple of rooms away at worst. (Check to ensure that a discarded item is always reachable by the player.)
  • Maybe count items – if you’re hunting around to recover a couple of non-treasure items already, don’t steal any more of them.
  • Maybe add some messages indicating which way the thief goes when he leaves. Not every time, but enough to give the sense of a person walking around. Also helps you find stuff he took.
  • The thief won’t attack you unless attacked. (I can’t remember if traditional Zork works this way!)

There’s a conundrum here. If the thief can steal treasures, players may think that he’s putting the game in an unwinnable state – they don’t realize there’s a chance to recover them later! How much do we want to annoy players for tradition’s sake?


(The sword is an interesting case. Of course once you’re past the troll, the sword is dead weight! But when I played as a kid, the sword and lamp felt like essential adventuring equipment. If the thief stole the sword, that was a catastrophe; I immediately restored a recent save. Is it worth catering to this kind of assumption?)

1 Like

I felt that way too, which is why I had a hard time understanding the knife was better for fighting the thief.

I think the mistake was in not following up and making the sword more useful in some way.

1 Like

Interestingly, in the unreleased (and very buggy) version of Mini-Zork I the torch has the SACREDBIT, which should keep the thief from ever stealing it.

I couldn’t figure out at first why the thief would ever steal the sword, but I guess it’s considered a treasure while it’s glowing because its current “glow state” is stored in the TVALUE property. Cute. I guess that means he’ll mostly steal the sword if you’re fighting, but probably not if he just passes through?

Tricky, because the thief doesn’t actually walk in any particular direction. He simply moves to the next room (rooms are objects that are children of the ROOM object) that has the RLANDBIT (i.e. it’s on dry land) but no the SACREDBIT. I guess that’s a simple way of guaranteeing that he doesn’t get stuck in some remote part of the game.

I used to love the thief back when I first played the game. That is to say, I used to love reloading a savegame right before the big fight in his hideout, and then try to kill him with every weapon I could find in the game, including the scepter. Very satisfying.

But even before that, I don’t remember finding him all that annoying. Maybe because he seemed like a worthy opponent. That you could attack him at all was a tantalizing hint that if only found a few more treasures you might be strong enough to take him on.

Personally I found the Wizard of Frobozz to be much more frustrating than the thief, because some of his spells would kill you outright if you were unlucky (something the thief rarely did), and with some of the others the only thing you could do was to stand there and wait for them to wear off. That got old pretty quickly.

(I had similar problems with the less lethal but still pretty annoying jester in Zork Zero.)


Having recently replaying Zork III, I can also say that I find the random deaths in that game far more annoying than the thief in Zork I:

  • You can get randomly killed by a roc while swimming on the lake, and by a fish when at the bottom of the lake. I’m uncertain if either can happen without warning, but it looks like at the very least the fish can eat you without warning. The invisibility potion protects you, but not for long. You can also freeze to death, but you do get warnings about that.
  • As far as I can tell, while waiting for the guards in the museum to leave there is a 3% chance every move that they will spot you and kill you even if you’re not doing anything wrong. It looks like you can avoid that by repeatedly opening the door instead of just waiting, but that’s probably not by design.

Having an earthquake cut off part of the map is a bit cruel, too, but at the same time I thought the idea was kind of cool.


The original invisiclues, which already exist in Z-machine hint menu form, could be incorporated into the game files, presumably accessible by typing HINT.