"Wait for any key" crashes text capture

Authoring Inform 7
1

This produces a Glk error of “Reference to nonexistent Glk object.”

[code]include Text Capture by Eric Eve.
Include Basic Screen Effects by Emily Short.

Test is a room.

When play begins:
start capturing text;
wait for any key;
stop capturing text;
[/code]

This situation can be difficult to avoid when using text capture for testing and debugging of code that contains a small amount of screen effects. It seems like it could be fixed with a patch to Text Capture or to Basic Screen Effects. Do either of the authors have anything to say about this, or does anyone have any tips for avoiding the problem?

Thanks!

2

This seems to work during play (if you put that code in an “instead of jumping” rule instead of “when play begins”). Blah.

I suspect that the difference is that at the beginning of the game, the status bar gets redrawn inside VM_KeyChar(), which resets the output stream to the main window.

3

This is hacky, but solves the problem:

To wait for any key:
        (- CaptureAwareKeyPause(); -)

Include (-
[ CaptureAwareKeyPause   cap_stream;
	if (capture_active) {
		cap_stream = glk_stream_get_current();
		capture_active = 0;
		glk_stream_set_current(text_capture_old_stream);
	}
	
	VM_KeyChar();
	
	if (cap_stream) {
		glk_stream_set_current(cap_stream);
		capture_active = 1;
	}
];
-).

If your status-line-drawing procedure itself tries to use text capturing, you’re probably screwed.

4

Thanks for the code - I think something much simpler will suffice:

[code][ CaptureAwareKeyPause cap_stream;
if (capture_active) { rfalse; }

VM_KeyChar();

];[/code]

Doing this to all of the functions in Basic Screen Effects seems to solve most of the problems. I still got the error if I tried to restore undo state while capturing, but that’s a little easier to avoid.

I’m also having some weird issues, though. I don’t even know if they’re related to text capture. Not every time I run the program, but many times, the text just stops in the middle. I have the text capture limit set to 5280, but I’ve had the captured block (which was copied into an indexed text) cut off after 950 characters or so. And sometimes the whole game seems to stop mid-sentence. What do you think is happening?

5

I don’t know.

If the whole game locks up, then probably output got diverted to a memory buffer and never reset to the screen. I don’t know why that would happen.

6

Well, I’ve changed a few things and now the git application just crashes all the time. Is it possible I just need to increase a memory limit somewhere? What should I try?

7

No, that’s almost certainly not the problem.

8

Sorry, I meant “the git application” crashes, not glk. I’ve edited my post.

I just changed a line and it seems to have resolved the crashing at least once:

assert that "[the captured text]" includes "will do your bidding"

I changed this so that the captured text is saved in an indexed text variable before calling the phrase:

To assert that (message - an indexed text) includes (pattern - an indexed text):
9

It looks to me like Text Capture is being used here in situations I didn’t envisage (it was primarily written to support Implicit Actions), but if you come up with any changes you think should be incorporated into Text Capture to help avoid the kind of problems you’ve been encountering, do let me know.

10

Thanks, Professor! If I can get the Basic Screen Effects stuff tidied up, I’ll send it to you for inclusion in your extension. Meanwhile, I’ll try to solve the other issues. Is there a maximum length for indexed text? Maybe I’m exceeding that.

EDIT - okay, I looked that up and I definitely did need to increase the maximum indexed text length. Oddly, I had a few hiccups right after I did that but then the testing stuff started working pretty consistently. We’ll see how it goes in the long term.

11

Overrunning this should not cause a crash; it should just stop accepting new text. (In Glulx, that is. Zcode is less tolerant.)

12

So Zarf, you think the problem has something to do with redrawing the status line? Do you have any tips for debugging this? It’s still happening.

13

I don’t have anything to offer.

If the problem is really happening on some runs but not others – with exactly the same game input – then it could be an interpreter bug rather than a game bug. But you’d think that would have turned up before.

14

I’m not ready to come to that conclusion - I haven’t seeded the random number generator.

I’m trying that now. I got exactly one case where I got the error, and it didn’t happen again, even with the same random number seed. But I might have seeded the random number generator too late. I moved the rule earlier and am trying some more, but so far no glk errors.

15

I have a version now that crashes every time… BUT it doesn’t crash at the same point every time. So that points to interpreter problems?

16

Maybe. This is in the IDE interpreter? Mac or Windows?

What happens if you run the compiled game (output.ulx) in Gargoyle?

17

What’s your current code look like?

18

You can check it out from github. github.com/i7/kerkerkruip/blob/ … e/story.ni

This isn’t the exact same code that was crashing, but it stopped crashing anyway. The problem seems to come and go.