It has been drawn to my attention that the release version of Terminator often (always?) prints a message saying “You’ll have to say which compass direction to go in” when that is not appropriate. Apologies if you encounter this; it did not appear when I ran the game in the IDE, and just now I tested running the game in the IDE and running a freshly released version and the error appeared in the released version but not the IDE. So I don’t know how to fix the error.
I’m attaching a release build of the game, which doesn’t seem to have this error, to this post. I’m not sure if this is within the rules of the competition but I would rather have a playable version of the game available than not be disqualified in any case.
Per the rules of the competition, the submitted version is final - but you seem to have a special case here, if the behavior under the IDE does not match the behavior in the released version.
I’m a little confused by your explanation though and would like to ask for more info. If you don’t know how to fix the error, and it’s showing up in the release build, where did this fixed version come from?
I’d assume Matt used a good deal of sleuthing to guess where the message might be popping up, until one of his guesses worked. It’s one of those “heisenbug” things. It’s probably best sleuthed by placing
say “marker 1”
say “marker 2”
and then seeing where the offending text popped up (Matt, maybe that’s how you did it?) This, however, is time-consuming, tedious, and awful, and what’s more, it allows for entirely different text to slip into the release code if the programmer is not careful. I have a special nonsense word I use that I can search and replace, which helps.
I don’t think this renders the game unplayable–however, it is a tricky bug, and if it’s due to any Inform flakiness, this seems like about the only sort of case where this could be added.
I can vouch that Matt was aware of this bug but unable to reproduce it & he got it from more than one tester.
Tester opinion:
[spoiler]I was also able to tune it out relatively quickly. While it’s an obvious bug, I think Matt’s explanation is adequate and reasonable even if you decide against allowing an update, and the game does so much other technical stuff, people can dismiss it as a one-off. And having left debug text in my code for an IFComp game (which spoiled a puzzle,) I sympathize.
My personal opinion is that it would be neat (in an ideal world) to give each author a mulligan for what they feel are their worst bugs in a couple weeks, but that is probably way more administration than you need, since you’d have to trust/verify. I hope players are sympathetic to that something can slip through, and I hope my explanation helps that.
In this case because the bug happens in release not debug, you can’t use RULES ALL, and you can’t use a “safe” stub like debug-say to track things only in debug mode, e.g.
chapter debuggage
debug-state is a truth state that varies.
to debug-say (x - text):
if debug-state is true:
say “DEBUG TEXT: [line break]”;
section dbs - not for release
when play begins:
now debug-state is true;
And also, the text in question is produced by an i6 file and not in the Standard Rules, making it even nastier to figure what’s going on.[/spoiler]
Sequitur is correct–this is a Release for Testing version. (So you can do “rules” and “actions” if you like.) I had meant to say that in the original post but it came out as “release build.”
As Andrew said, I got this bug report from multiple testers and it’s at least partly my fault that I continued to test in the IDE rather than using the file that I was sending them.
Well–yeah. But I think in cases like this, you don’t want to just quit, give up and release nothing. Bugs can and will be fixed & you focus on what you can control, and what will affect mechanics, etc. Time is an issue, and even when you account for blindside bugs, there still never seems to be enough time.
Nevertheless, perhaps there is a way to activate RULES in a release build–or a module that can do so with I6 tinkering? (e.g. RULES works but nothing else, like TREE or TRACE.) It might help a programmer catch this sort of tough bug.
The state of Inform 7 development is so sad that an author cannot trust his IDE and blames himself for doing so.
I myself thought it was totally fine to use the IDE interpreter until some combination of extensions or code caused my game to lock up, an issue that the release builds didn’t exhibit under Zoom/Parchment. Is it well known that one shouldn’t use the IDE?
Well, I think there’s something known about bugs in CocoaGlk (which is something in the interpeter that the IDE uses) that aren’t in garglk (which is the equivalent thing in the interpreter that Gargoyle uses), or something like that. That means Zoom and the IDE interpreter aren’t always reliable. I haven’t been following it that much because I don’t understand glk.
My thing seems like a different issue, because even in the same interpreter (Zoom) it’s manifesting in release builds but not testing builds. So it’s probably a difference in the builds rather than in the interpreters–I expect that if I could run the release build in the IDE I’d get the same bug.
I’ve held off moving up to 6L, but largely because I have old projects started in 6G & I’m too lazy to sharpen my own code so it builds in 6L.
If your problem can be reproduced regularly, definitely file a bug report–the debugging abilities do put an extra strain on the IDE. inform7.mantis.com. I’ve gotten quick responses.
Also, in this case, potential bugs in 6G extension code may not be exposed until 6L, since 6L flat out does more. The more ambitious a development system becomes, the more old bad code (of developers at any level) gets exposed.
I think you can basically run the same build that runs in the IDE in an external interpreter. I don’t have a Mac anymore, but I think you can find it in the Inform app package itself.
If you want to be able to run RULES and ACTIONS in a release build, I think you can just do this:
Include (- constant DEBUG; constant STRICT_MODE; -) after "Definitions.i6t".
If the difference between the version that works and the version that doesn’t is whether or not you hit “release for testing”, then I’m good with calling it the same version.
Send me a new build and I will get it into the zip. (This will not save you from people who already downloaded it, of course, but for anyone else.)