Is there a safe/better way to ask a yes/no question? Or some other way around/through?
demo code
lab is a room.
include simple multimedia effects for v10 by mathbrush.
release along with a "bisquixe" interpreter.
when play begins:
say "resize this window please.";
if the player consents:
say "yes."
Okay, I think this is related to the extension Glulx Entry Points by Emily Short that my extension uses.
Basically, glulx can take in and put out a series of events from the outside world, like playing a song, or detecting when a song finishes, and so forth.
But, it doesn’t really like it when it’s waiting for one event and it receives another. So when that happens, it crashes. It happened to me several times when working on the music part of Bisquixe.
Resizing a window is an ‘outside event’ like I mentioned. The event it’s waiting for is the ‘yes/no’ event.
Just including Glulx Entry Points by itself causes this bug:
"Test room" by Brian Rushton
lab is a room.
include glulx entry points by Emily Short.
Release along with an interpreter.
when play begins:
say "resize this window please.";
if the player consents:
say "yes."
I’ll write more in a few minutes! But I don’t have a solution.
That is not a problem; getting an unexpected resize event is fine.
The problem is trying to print output while it’s waiting for (line) input. If the resize event handler tries to print to the story window, you get that error.
lab is a room.
include glulx entry points by emily short.
when play begins:
say "resize this window please.";
when play begins:
if the player consents:
say "yes."
So I’m guessing it’s kind of a timing thing? It also doesn’t crash if you omit the printed text altogether.
Oh, that’s really interesting. I have no explanation for why that behavior should occur. I think one of the tech wizards has been working on a replacement for Glulx Entry Points for several years (maybe incorporating it into base inform?) so hopefully that version will iron out some of these bugs.
Inform 7 makes avoiding printing-while-waiting-for-input especially hard because its criteria for printing linebreaks after rules is almost totally inscrutable. But if you can consistently use an event framework then it’s able to take care of it at a low level for you. I thought I had done that for Glulx Entry Points (after I split it up into other extensions), but I may have done so in stages, and it’s also possible I didn’t catch everything. It’s also possible that the GEP framework won’t help in this situation because I think the “if the player consents” phrase does its own event handling, so the GEP hooks wouldn’t be used.
I’m pretty sure I’ve accounted for everything in the upcoming Inform 7 release 11, which takes care of unwanted linebreaks at the lowest level, and could be helpful to look at. The question for right now is just which version of Glulx Entry Points are you using?
There’s flags down in the printing guts that decide when an inter-rule line break is appropriate. Changing one rule into two rules, as your examples show, can affect how those flags get set.
Here, I’ve update GEP for Inform 10.1.2, including reincorporating the parts that I had split out before. I’ve tested that it compiles, but not more than that, so it’s possible it will need a few more changes if Inform 10 changed how things work compared to 6M62. extensions/Emily Short/Glulx Entry Points-v10.i7x at 10.1 · i7/extensions · GitHub
