Glk error????

I am trying to compile Kerkerkruip. The game compiles fine on its own, but adding Flexible Windows results in an interpreter crash after leaving the title screen for the game proper, in some interpreters. The CocoaGlk IDE terp gives the error as “glk_set_style_stream called with an invalid strid”. Browsing the .inf file, I can’t find any instance of the game calling glk_set_style_stream. Is there a chance that it is actually calling glk_set_style, which then calls the opcode corresponding to glk_set_style_stream? Currently only library calls to set style seem to be made (i.e., via VM_Style).

Oddly, the crash happens in both the Mac IDE (Git or Glulxe) and in Gargoyle (Git or Glulxe). However, the crash does not happen in Spatterlight, which uses Glulxe 0.4.3, or in Zoom 1.1.5, using either Git or Glulxe 0.4.7. This suggests that this may be a minor issue that some terps are pickier about than others, thought it does surprise me that Zoom is permissive whereas the Mac IDE terp is not.

Any thoughts?

–Erik

Certainly possible. I haven’t looked at the CocoaGlk source to be able to say for sure.

Well, it looks like it’s not likely to be that. I replaced the guts of VM_Style with a do-nothing routine, and the crash still occurs.

I’m having a heck of a time locating just where the crash happens (nothing is printed to the screen, so I can’t use print statements to debug it*). I guess my next step will be to see whether I can get EmacsUser’s debugging tools working with Kerkerkruip.

*I inserted char events all over the place, and found that a char event will delay the crash if placed in “before printing the banner text” or “for printing the banner text”, but not if placed in “after printing the banner text”. However, removing or replacing “for printing the banner” has no effect on the crash, including delisting the rule that calls the activity. So it may be that printing anything to the main window after the title page has cleared will cause the crash (the title screen prints fine). That doesn’t really make much sense, but that’s the best guess so far.

Looking at the CocoaGlk source code, this is indeed the case.

If you’re stuck, email me the failing auto.inf and I’ll see if I can figure anything out.

Thanks, David! I’ve figured it out. Kerkerkruip rearranges the startup rules so that the when play begins stage doesn’t happen until after the title screen is displayed. This causes FW’s startup rules to fire only after text has already been printed to the screen, and it’s the “allocate rocks” rule in FW that causes the problem, though the crash doesn’t happen until text is printed subsequently.

Rearranging the startup rules to place the allocate rocks rule before the initial printing of text to the screen seems to fix things.

–Erik

Oh good. :slight_smile:

Ahh, yeah, sorry. Don’t assume that any of the rulebooks work like normal in Kerkerkruip. :stuck_out_tongue:

OK, so it isn’t perfectly solved. Inform is acting up. Is there a better way than this to relist these rules?

The allocate rocks rule is not listed in the when play begins rules. The allocate rocks rule is listed before the show the title screen rule in the startup rules. The rock validation rule is not listed in the when play begins rules. The rock validation rule is listed before the show the title screen rule in the startup rules. The initial hyperlink request rule is not listed in the when play begins rules. The initial hyperlink request rule is listed before the show the title screen rule in the startup rules.

Inform likes the above just fine until you press the release button. In that case, it fails with a compiler error. The exact error depends on whether the relisting occurs in the story file or in an extension.

In the story file:

In an extension:

Again, these errors only appear on release, not if you run the game in the IDE. Any ideas why this is happening, or how to work around it?

–Erik

Ok, reported as issue 1064.