Run-time problem P47

I’m getting this bug in my project:

  • Run-time problem P47 (at paragraph 925 in the source text)

I want to check what it means by paragraph 925. Is that the same as line 925 (if I drop it into a word processor with line numbers)? And is it referring to the Englishy Inform 7 source or the auto.inf file?

I’m triple checking this because in either source, I see nothing relevant at line 925 to my problems. Then I wonder if it’s just acting weird because extensions aren’t in an order that makes it happy, or something similarly difficult to nail.

Cheers,

  • Wade

As an addendum, I’ve now identified the exact line that’s causing the crash (by putting debug messages between every line of code in the danger area). But I don’t know why it’s crashing.

A Glimmr animation is running during the ‘when play begins’ sequence, and when I try to delay input until the animation is done, the following call causes a ‘Phrase applied to an incompatible kind of value’ runtime error after the delaying ‘while’ loop has run three times:

(- glk_select(gg_event); -)

Sorry if this has been a little gobbledegooky. Erik Temple’s been helping me with this issue, but when I last spoke to him, neither of us had been able to identify what exactly the line that was prompting the error, which I’ve now done.

  • Wade

Hm, that line itself definitely isn’t the culprit for the run-time error. (Also, you mention a crash, but I assume you’re not actually seeing a crash–just the error?)

Glk_select is the call that tells the virtual machine to wait for an event–either input from the player, or an internal event such as a tick of the timer. So the fact that you isolated the problem to that suggests that it’s happening in the rules triggered by the timer–more than likely, these would be animation or drawing rules. More to the point, I think you said that only a brief prelude-type animation triggers the problem, and that if you remove that, it goes away. So, the problem would specifically be in the “animation rules” that control that animation, or in the rules that draw the images themselves.

–Erik

Yes, and it refers to the I7 source text (the story.ni file in your I7 project). Unless the error is occurring in an extension – it looks like P47 drops the information about which source file is involved, so it could be line 925 of one of the Glimmr files.

Thanks for the pointers, guys. I’ll keep looking into it.

  • Wade

Well, that weren’t easy!

I began opening each Glimmr extension and looking at what was on line 925. In the 9th one I opened, Automap, line 925 looked significant re: Erik’s earlier post:

“follow the window-drawing rules for the assigned window of the current graphlink;”

and it’s inside a glulx timed activity rule. Adding debug messages around here revealed that the current graphlink is nothing at the moment of the runtime error. So there’s the cause. Looks like a clash between the automap extension and the animation procedures, at least in this pre game-has-started environment. Now I gotta work out how to fix it. But I feel like I had to zoom a microscope in about 12 times over 2 days to find the trouble line, so I am feeling that I-found-it satisfaction right now.

  • Wade

Or as we say in Quenya: Utúvienyes!

You Elvish? :wink:

I had to look up what Quenya was. But as soon as I did, I realised that deep down, I probably did recognise that word from back in my time with MERP.

  • Wade

Ah yes, that would be the rule that pops a button back after it’s been pressed. I’m not surprised that I missed that: I was not thinking of animation when I threw Glimmr Automap together, and since Glimmr Automap is kind of an unwanted orphan, I didn’t test it with animation either.

But the problem is bigger than just animation–that rule would incorrectly trigger for any timer event. I will try to put up a patched version tonight, but basically you just need a when clause in the rule pramble to restrict it to the right situation. The best restriction would be “when there is a depressed button” (not sure of the actual code), but probably something like “when the map-window is g-present” would probably work for your game, as long as you won’t be using the timer during the game proper.

I am sad to have to point out that this is a very minor problem, and it won’t fix any of your other issues…

–Erik

Thanks Erik . Well, good news is I’m not sure I have any other issues that need fixing. The animation used to be happening at the wrong moment, but I fixed that by giving the rule which runs it a name (it didn’t have one, but all the other ‘when play begins’ rules did). I didn’t realise that unnamed rules run after named ones in a rulebook? I’m only getting into the biz of naming rules in this project.

Anyway, so the animation’s at the right place. If this timer issue can be addressed somehow, then it should run. I will be using timers around the place, though, in startup and in-game. I wouldn’t if the new glk sound powers were supported around the traps (I’m basically using the timers to fade audio), but they aren’t.

I’m still now sure why I couldn’t turn on an echo stream, but (a) that wasn’t one of the original problems, so I don’t mind if I still can’t :wink: and (b) maybe I’ll now find that works, or can be got working, anyway.

  • Wade

Well, if your animation’s not running now, then you have another problem. This issue is not causing the animation to fail. It’s just triggering an extra timer rule which has no practical effect other than printing a run-time error.

If you want to test that, fix this the cheap-bastard way and give current-graphlink a value before you trigger any animation (set it to the name of one of the Glimmr Automap buttons).

–Erik

Reading your post sent an actual chill through me, Erik. But!.. I just added that ‘when the map window is present’ clause to the timing phrase in Automap, then tried it. And suddenly everything worked. Two animation sequences, then into the frontend menu. Then I poked at the game and I also saw evidence that the timing phrase was now functioning fine in-game, too.

I am going to punch a piece of wood, but I think this problem has been deproblemed.

  • Wade

I’m glad to hear it, but very surprised too! Cheers!

Here’s the new code for the extension, if you want to patch:

A glulx timed activity rule when there is a g-present map-display window (this is the redraw button from timer rule): if the current graphlink is a UI-button: if the image-ID of the current graphlink is the depressed state of the current graphlink: stop the timer; follow the window-drawing rules for the assigned window of the current graphlink.

Thanks for the patch.

My crummy version of the patch was working in the meantime, and now I’ve put in your good one. I’ve discovered a new problem related to the same timer stuff. Though bizarrely, it only happens in Gargoyle, not Zoom.

Basically, after the first time you click one of the zoom buttons on the map ui, you can no longer type at the prompt. It vanishes. You can then continue to click buttons on the automap and they work, but you can’t type stuff anymore. In Zoom, you can keep typing.

The last debug line before the action ends (in both Gargoyle and Zoom) is:

[Glimmr Automap]: Drawing UI-button UI-query (Figure of UI-query) at origin (171,419). Graphlink set from (171,419) to (184,432): waiting.

  • Wade

Possibly it’s trying to print to a text window without cancelling line input first?

Wow, you’re right. I say ‘wow’ because, when I first read what you said, I didn’t actually understand what it meant :wink: But then I looked at another recent topic where you were talking about line input, and then I realised the debugging ‘say’ message I threw into the rule sounded like it was doing exactly what you just said. So I removed that and it fixed it. Thanks again.

  • Wade

This is one of the reasons for using the Glimmr debugging console–if your debugging info is printed to its own window or dumped to the console (the latter is much faster, at least on Gargoyle), you won’t have an issue with printing while the main window waits for input.

You will likely run into this issue very often as you test, because Zoom (the IDE interpreter) is very lax and allows printing to the window while input is pending, whereas Gargoyle strictly follows the spec and does not allow it. The result is that bugs may seem to mysteriously crop up in Gargoyle, when in fact they are basic problems with Zoom’s implementation of Glk.

–Erik