Table in a not for release section causes obscure error

Hi everybody,

the following section

[code]Section - Table of verb forms to be ignored by Libcheck - Not for release

[To be continued by the author …]

Table of blessed verb forms

evokes this error message, only when releasing the game (in Debug-Mode the error doesn’t show up):

The message links to a line in Section SR3/3 - Final question options (note: the suggested location might vary depending on the source text):

"UNDO the last command"	false				"undo"		immediately undo rule	--

We don’t know how to reproduce the error. Deleting “Not for release” from the section heading solves the problem, though. Maybe someone knows what causes this behaviour?


I cannot reproduce this error with this code: it works fine for me, even when releasing. (For both Z-code and Glulx.)

Now, the logic of the situation suggests to me that the inclusion of this Table is necessary for something else in your code. After all, labelling the section “not for release” and then releasing is the only situation in which the table is not included. Is it possible that you refer to the Table of Blessed Verb Forms somewhere in your code?

Thanks. I can’ spot incorrect code that is likely to cause that error, either. Even without referring to the Table of blessed verb forms at any time. Strangely enough, the error message implies that there is something wrong in the Standard Rules (Section SR3/3 - Final question options), which is in no way related to the table.

With a larger game source text we produced an error message suggesting that the error ocurred in a “after reading the command” rule. But I guess the problem must lie elsewhere and the error message might be arbitrary due to obscure circumstances.

We haven’t been able to reproduce the error in a clean evironment, either. It must be something in our source. But what can cause confusion like that?

If you’ve done something that causes a conflict with the Standard Rules, the compiler can give you an error that points to the Standard Rules. For instance, this simple code:

Lab is a room. Only if victorious entry is in Lab.

gives a compiler error (in 5Z71, at least) that has to do with the Final Question options, because the code I wrote interprets “Only if victorious entry” as a thing (as it should), and then when it comes to a table with a column entitled “only if victorious entry” it gets confused.

So it’s possible that there’s something somewhere in your code that creates a namespace clash, so that when it comes time for the compiler to interpret the standard rules it doesn’t understand them anymore. I don’t know what it might be, though – just talking about one way you could get a compiler error in the standard rules.

That error was discussed more here, though I don’t know what the OP’s error actually was. (I also don’t know why I can only find the .es version of that thread.)

It can take some time, but the best way to find the bug is to comment out all your code and then slowly comment in more and more of it until it stops compiling.

Thank you, that helped! I stripped it down to a working version, and the mistake was, of course, a rather silly but hard to find one.

The Table of blessed verb forms is defined in a Section marked “Not for release”. Somewhere else, in an I6 inclusion the table is referred to as

tab = (+ Table of blessed verb forms +);

The hole I6-Routine was excluded for release by #ifdef DEBUG; […] #endif; – But: The I7 section the code was in was not marked “Not for release”. So when releasing a game NI obviously wasn’t able to replace the expression (+ Table of blessed verb forms +). Anyway, the error message was quite misleading, wasn’t it?

Thank you both, Victor and Matt!


It’s worth reporting that as an error-reporting bug.

You can cut it down to:

"Test Case" by Andrew Plotkin

The Kitchen is a room.

Include (-
[ Foobar; return (+ totalnonsense +); ];

You get the same error message about “undo” in the Standard Rules, rather than “totalnonsense” in your code.

In general I6 inclusions are “at your own risk” – if they break, it’s your fault. But in this case it’s the I7 compiler that’s wrong, not the generated I6 file.

Already had, actually: