Overwriting "to say x" or "to x"

A test case came up when releasing a game.

I’ve noticed that having redundant “to say x” means the second will apply. In simple terms, this means:

to say x: say "1.";
to say x: say "2.";
when play begins: say "[x]";

So this says 2.

Similarly with to x:

to x: say "3.";
to x: say "4.";
when play begins: x;

This says 4.

The test case here is, I have to wfak: if debug-state is true, wait for any key; in an extension.

This lets me create a debug binary that works with Zarf’s regtest.py without json. (e.g. it waits for a cursor to type in text). However, it freezes up in release mode, due to the “wait for any key.”

So I’ve created a parallel project I build from the command line, with to wfak: do nothing; tacked on at the end.

This seems to work well. I’m able to test a release build with simple applications of Zarf’s regtest. (I note it’s possible with json to react to wait for any key, but I am not ready to deal with that.)

But my question is: is there anything about redefining to x/to say x that would destabilize Inform?

I don’t think it has any disastrous consequences, but it’s not documented behavior, which means it could change in the future without notice. The officially documented way to do this is:

Section 1A - Not for release

To wfak: do nothing.

Section 1B - For release only

To wfak: wait for any key.
3 Likes

Thanks, I somehow wasn’t aware of “for release only.”

It also seems like, if the I7 implementors change things, I could create separate slightly different header files where “wfak” did something different.

Accounting for new behavior/specs that way might take a bit of time, but the peace of mind from being able to run a smoke test would be worth it … the key for me is being able to built a z8/ulx binary on the command line, then I can manipulate the source as I need/please!