the-infocom-files / leathergoddesses

Leather Goddesses of Phobos
4 stars 3 forks source link

Objects are listed in the wrong order in Among the Dunes (Add <ORDER-TREE? REVERSE-DEFINED>) #27

Open eriktorbjorn opened 4 years ago

eriktorbjorn commented 4 years ago
>NORTH
Among the Dunes
   You are in a tiny basin, protected by dunes from the fierce Martian winds.
The dunes are impassable, except to the south.
   The alien may have died of acute chapped lips (a perennial problem in the
arid Martian climate). If so, it was a sudden death, for the lip balm near the
body is completely unused.
   A strange alien, probably a member of one of the ancient warrior races of
Mars, lies dead at the base of a dune.
   Lying next to the body, partially buried in the sand, is a strange coded
message.
   Trent trails along.

The description of the lip balm refers to the alien, even though the alien itself isn't described until the next paragraph. This is probably a matter of Zilf creating objects in different order than ZILCH, because this is what it looks like in the original version (both regular and Solid Gold):

>NORTH
Among the Dunes
   You are in a tiny basin, protected by dunes from the fierce Martian winds.
The dunes are impassable, except to the south.
   A strange alien, probably a member of one of the ancient warrior races of
Mars, lies dead at the base of a dune.
   Lying next to the body, partially buried in the sand, is a strange coded
message.
   The alien may have died of acute chapped lips (a perennial problem in the
arid Martian climate). If so, it was a sudden death, for the lip balm near the
body is completely unused.
   Trent enters just a few steps behind you.

The order the objects here are defined in after AMONG-THE-DUNES are:

Object Order in original Order in Zilf
LIP-BALM 3 1
CODED-MESSAGE 2 3
MESSENGER 1 2

So clearly the original lists the objects in the inverse order they were defined. Zilf's ordering seems... random? Adding <ORDER-TREE? REVERSE-DEFINED> to leathergoddesses.zil makes the ordering the same as for the official release. At least in this particular case.

This isn't the kind of bugs I'm usually looking for, so I don't know how many others I've missed. Perhaps ORDER-TREE? should be added to the whole lot, and then give them all a quick playthrough to see that nothing obvious broke?

eriktorbjorn commented 4 years ago

I looked through a couple of early games, and some of the later (Solid Gold) ones, and while the objects don't always seem to follow the inverse definition order, it at the very least seems to be pretty common.

eriktorbjorn commented 4 years ago

I asked about this in the Facebook group, and while I didn't get much clarity about what the best fix for this is, I did get this message from Jesse McGrew:

The default tree ordering is default because at least some of the Infocom games expose it: changing it will make them produce different output, even if they can still be played to completion. This is one of the unfortunate realities of trying to write a compiler that can handle the source code for all these projects that were written over a span of years. There never was a single version of ZILCH that could compile all the Infocom games and produce functionally identical output to the released versions, because the language was evolving the whole time they were being written, but that's what ZILF is trying (in vain) to do.

And also this:

The ordering is predictable, it's just weird. By default, the first child of an object is the first child encountered in the source code, and then the rest of the children are linked in reverse order. That is, given:

The links will be: = A = D = C = B
eriktorbjorn commented 4 years ago

Note to self: Don't confuse object numbering with tree ordering. They are two different things.

That said, having gone through the data file in Zarf's collection, I've come to the tentative conclusion that ZILF emulates the tree order of ZILCH up to some time November 1985. After that, ZILCH appears to have started using the equivalent of <ORDER-TREE? REVERSE-DEFINED>.

In practical terms, All games up to and including Spellbreaker should have the correct object ordering when compiled with ZILF. From Ballyhoo and upwards, it's the REVERSE-DEFINED order instead. I didn't notice any object ordering glitches in Ballyhoo. There were some in Trinity, though that may have been object numbering, not tree ordering.

So this is the first game where tree ordering is clearly the problem.

Some games have official releases where the object ordering changed from the initial release. All the Solid Gold releases except the one for Leather Goddesses of Phobos, obviously, but also the Enchanter series. (You can tell because the spells are ordered differently in your spellbook depending on release.)

So my plan now is to compare the ZILF compiled games to the official releases, and see if the tree order matches. If it doesn't, I'm going to check if <ORDER-TREE? REVERSE-DEFINED> fixes that. If the order changed between official releases, I'm going with the earlier release because if the author did have an intended ordering that should be the better match.

eriktorbjorn commented 4 years ago

I have now gone through every single officially released Infocom game, and compared the tree ordering in the official releases. The conclusion seems pretty clear: We should add <ORDER-TREE? REVERSE-DEFINED> here. I've filed bug reports for all the other games where I think it should be done, and to the games where I could make a case for it but am not sure.

I have not filed bug reports for the Enchanter series. I think it's pretty clear what the original intention was there.