iFrotz & Frotz in Linux producing bad error in new I7 game

This was discovered in my 2nd round of beta testing for a game I’m trying to wrap up soon. I ran it by Zarf earlier today, but he doesn’t know what it is. He also asked if I had debug mode on, but I do not.

This problem only occurs in the Linux and Mac versions of Frotz. If you save in a different 'terp then load it in Frotz however, the problem does not occur. Though personally I get ‘failed to load the terp’ error when trying to load the game in Gargoyle on my Linux machine at work. It loads fine in the Linux version of Frotz, but again I can’t save/restore without getting this error:

[spoiler]>save

Enter a file name.

Default is “LunarBase1.sav”: test.sav

Ok.

restore

Enter a file name.

Default is “test.sav”: test.sav

Ok.

[stopped: success]

[Procedural rulebook]

[Turn sequence rulebook]

[parse command rule]

  [before Reading a command rulebook]

  [for Reading a command rulebook]
 [before Constructing the status line rulebook]
  [after Constructing the status line rulebook]



  [before Printing a parser error rulebook]

  [for Printing a parser error rulebook]

I beg your pardon?

  [after Printing a parser error rulebook]
 [before Constructing the status line rulebook]
  [after Constructing the status line rulebook]

n

  [after Reading a command rulebook]

  [before Deciding the scope rulebook / on O64]

  [for Deciding the scope rulebook / on O64]

  [after Deciding the scope rulebook / on O64]

[generate action rule]

  [Setting action variables rulebook]

        [standard set going variables rule]

        [determine visibility ceiling rule]

        [Setting action variables for exiting]

  [Procedural rulebook]

  [Action-processing rulebook]

        [announce items from multiple object lists rule]

        [set pronouns from items from multiple object lists rule]

        [before stage rule]

              [Before rulebook]

        [basic visibility rule]

        [basic accessibility rule]

        [carrying requirements rule]

        [instead stage rule]

              [Instead rulebook]

                    [Instead of going east from the moon when chunk1 is true

and the player is carrying the sample tube]

                    [Instead of going west from the moon when chunk1 is true

and the player is carrying the sample tube]

                    [Instead of going west when JohnTalk3 is true]

                    [Instead of going west when JohnRage is true]

                    [Instead of asking someone to try doing something]

        [requested actions require persuasion rule]

        [carry out requested actions rule]

        [descend to specific action-processing rule]

              [specific action-processing rulebook]

                    [work out details of specific action rule]

                    [investigate player's awareness before action rule]

                          [player's action awareness rulebook]

                                [player aware of his own actions rule]

                                [stopped: success]

                          [stopped: success]

                    [check stage rule]

                          [check Going rulebook]

                                [First check going when the player encloses

the hose or the hose is dragging]

…[/spoiler]

The status bar is also filled with the same sort of debug garble after restoring the save file. It continues on in this fashion for a bit longer, then the game appears normal… then back into this sort of stuff after the next action. I’m dreading doing a comparison between the beta 1 release and beta 2 release, but the fact that I receive no errors at all in WinFrotz or Gargoyle for Windows (and another tester says it works fine in Gargoyle for Mac) makes me think this could be an interpreter bug.

Can you forward me the source and binary?

Okay, will do. Thanks for looking into this.

The debug messages are from the I7 libraries, not Frotz. The next step is to pare down the source code to the absolute minimum required to trigger the bug. What happens if you do have debug mode turned on?

Looks like the same thing. I also noticed today that after the error gets thrown, if I hit enter it repeats:

[code]> [before Constructing the status line rulebook]
[after Constructing the status line rulebook]

  [before Printing a parser error rulebook]
  [for Printing a parser error rulebook]

I beg your pardon?
[after Printing a parser error rulebook]

 [before Constructing the status line rulebook]
  [after Constructing the status line rulebook]

[/code]

Perhaps this will help narrow it down some. I also re-released the files in the Linux version (Originally used Windows) of Inform just to make sure that doesn’t make a difference and it doesn’t. It still gives the error in Linux Frotz, and flat out refuses to load in Gargoyle.

For the time being I will be just be recommending that Mac/Unix users use the latest version of Gargoyle, as a resulution to this doesn’t seem to be in sight soon.

(The non-working Gargoyle for Linux I mentioned earlier is an older version)

Note that Gargoyle comes with three different Z-Code interpreters: Bocfel, Nitfol and Frotz. The default is Bocfel if you simply run “gargoyle”. You can always try the other two.

Were you ever able to come up with a test case of 10 or so lines that would trigger this bug? I’m very eager to see something like that and figure out what needs to be fixed in Frotz.

No, I was busy working on just getting the final touches put on for the comp release and didn’t have time. I do still plan on trying to narrow it down for you though, esp. if I end up making a new version of the game after the comp.

Sorry if this is bumping an old topic. I have had a similar thing just now with frotz.
I am pretty sure I have debug mode on; though I never turned it on. But the background is blue, showme command is there. This is because the Linux compiler tools, command line or gnome inform7, don’t allow me to make a release, even though I chose release.
So, I do have some of the same problem. When saving and loading that compile in frotz I have the tree of index, just like the person above posted.
Is this linux problem of not making a proper release file a known bug, or am I missing something.
Thanks.

There is a known bug in the Linux front-end to do with releasing game files when the “Bind up into a Blorb file for release” option is turned off - see http://inform7.com/mantis/view.php?id=653

This bug has been fixed by Philip, but there’s not been a release of the Linux package made since then, so you won’t have access to it unless you’re comfortable with rebuilding from source. Apart from that, your best option would seem to be re-enabling the “Bind up into a Blorb file for release” setting.