I just added some Glimmr extensions to an already functioning project, and then it wouldn’t compile.
The message is "In Part SR2 - Variables and Rulebooks, Section SR2/7 - The Standard Rulebooks in the extension Standard Rules by Graham Nelson:
Problem. You wrote ‘The specific action-processing rulebook has a truth state called action in world’ , but ‘action in world’ already has a meaning, which this would clash with."
I text searched the Glimmr Automap extension, and every extension it calls, and couldn’t find the phrase ‘in world’ contained anywhere. I also got the computer to search the contents of all files in my extensions folder, and it couldn’t find the phrase either.
The problem is obviously some clash from what I added, but I can’t find the source. Anyone have any ideas?
At first whiff, this smells a bit like a inclusion-ordering bug. Are your extension inclusions ordered as prescribed in the docs for the Glimmr extensions you are using?
Yeah, the extensions are ordered like this, as per the advice in Glimmer Automap:
Include Glimmr Automap by Erik Temple.
Include Glimmr Automap Tileset by Erik Temple.
Include Glimmr Bitmap Font by Erik Temple.
Those 3 together, and on their own in a project, compiled okay. When I added this block to a project with other extensions, then the errors come. The errors change depending on whether I put the block first or last.
I haven’t called any of the extensions incorporated into the Glimmr ones in my project - no Flexible Windows, no Fixed Point Math.
I’ve got:
Numbered Disambiguation Choices
Basic Screen Effects
Introductions
Plurality
Variable Time Control by Eric Eve
Glulx Status Window Control
Default Messages
dicelock
exit lister
Extended Banner
hitenterhack (my own)
Menus
Punctuation Remover
That’s a long list! If no one else has any better informed ideas, I would try (1) temporarily turning off any inclusions that are purely passive,* and if that doesn’t immediately lead to any insights (2) try reordering the inclusions by trial and error to see whether you can eliminate the error. From personal experience, you may see the particular error change as you reorder things, but you should eventually hit on an ordering that works.
By which I mean any that are trivial to disable due to having no hooks in your own code. Punctuation Removal, exit lister, dicelock, and maybe a few others probably fit the bill.
Heh… yeah I’m moving them around atm. I notice the error messages thrown change when I move Glimmr Automap and Glulx Status Window Control before or after each other. But I haven’t found an order that works yet. I’ll keep fiddling.
Ok, I’m pretty certain a functional Automap and Glulx Status Window Control can’t coexist in their present forms.
I have the mini test project (not the one with a dozen extensions) which works fine with only these 3 extensions included:
[Include Glimmr Automap by Erik Temple.
Include Glimmr Automap Tileset by Erik Temple.
Include Glimmr Bitmap Font by Erik Temple.]
When I add Glulx Status Window Control to this project, it throws the error messages I was getting in the big project. I tried slotting GSWC into each of the 4 possible positions amongst the 3 Glimmr extensions and it’s unable to escape the errors.
It could be that there is code in these extensions that is in direct conflict. However, because of the bugged-out error message you’re getting from I7, you’ll probably have to check the extensions manually to be sure. On the other hand, the buggy message itself still suggests to me that the problem is really in the way I7 is trying to order the included code into a single set of instructions for the I6 compiler. This is an area of I7 that is unfortunately very buggy, and also very difficult to debug. So, before I spent time going through the code of these extensions (and their dependencies) looking for conflicts, I would try to outsmart the extension-ordering system.
To that end, my next suggestion is probably to copy the text of Glulx Status Window Control into the body of your project so that you don’t have to tax the extension-ordering mechanism with it. Can you get it compile that way?
Argh!.. I experimented with taking the contents of extensions (Glulx Status Window Control, Flexible Windows, etc.) and copying them one at a time into the listing. This didn’t produce anything that worked or changed the situation.
So I started approaching this problem from the opposite direction. I got the mini project and started adding into it extensions that are also used in the big project, one at a time, compiling after each addition. I also copied over any i6 hacks and other dumped extensions that appear in the big project. Eventually I had the mini project containing all of the big game’s extensions and hacks, and running fine with automap.
Then I copied all the extensions and hacks over into the big project, retaining their arrangement from the miniproject, and it gave the same silly error message again when I tried to compile. As far as I can tell, there’s no controversial content left in the big project to experiment with. No more extensions whose contents I dumped into the main source, no more i6 hacks. Is there any chance plain old length could have anything to do with it? The big project is at 22k words. I suggest size because if I hack off everything in the big project after the first room (IE 40 more rooms and 100+ objects, all in plain old I7 code, no more I6), the thing boots.
It’s unlikely, but possible—there was a bug of that sort fixed in 6F95.
If you want, you can open an I7 bug and send the project to bugs@inform7.com, and I will start working on it from that end. You can also be mark the report as private if you’d prefer that the source not be publicly visible. We might also want a bug about that problem message not pointing to wherever it thinks the already existing meaning was established.
In my experience, very bizarre things can result in this sort of error. Once, I traced the problem to whether an include line was in an extension or in the story source–despite the fact that the line was in the same location if you imagine the I7 source as a single long file. Another potential source of problems is repeated inclusions of the same extension. I’m not sure that’s the problem here, but it’s certainlymsomething I’ve seen.
The good bug-finding folk (Emacs, thanks) identified the bug. It was one they already had on file, but I uncovered a new instance of it. Short version is - a combination of an object with ‘world’ in its title (my game) and a table with ‘action’ as a heading (in a Glulx Hyperlinks extension) caused a crash unavoidable with 6G60. If I change the object name, I can probably avoid it. For more details, see inform7.com/mantis/view.php?id=962
Also, to Erik - when I said Glulx Status Window Control would not compile with Automap per se, I don’t think that was reliable. I think removing ‘include Glimmr Drawing Commands’ line from Automap (because they were already included in Canvas…) caused that crash. I think putting it back fixed it. More extension weirdness. Short version of THIS story is - what I said about THAT has not been verified.
Oh, the whole thing? I didn’t realise, what with me being me and transparently able to access it and all
My understanding is that the text has reduced to a case which no longer needs privacy. Anyway, I’ll let the bug folk unprivatise it if that was their intent.
If not - I’ve explained my version of it here, and the same bug has been documented publicly in this other case: inform7.com/mantis/view.php?id=550
I am extremely impressed that the bug trackers were able to suss this out.
Thanks for the follow-up. There are indeed all kinds of bizarre interactions that occur with inclusions, and it often takes trial and error to figure things out. There is actually a lot of labor invested in the little documentation sections in the Glimmr extensions that explain how to order your incluse directives!
