Thanks to Zarf for answering my previous query. I now have a question concerning the after the deciding the scope of the player rule. I am using the extension disambiguation Control, and it creates an object called no-object then places it in scope with the aforementioned rule. The problem is that I have a room which is loaded with things because it is sort of a game-within-a-game. The after deciding the scope rule triggers so many times that, when rules tracing is on, it buries listing of the other rules. Worse, rule tracing while in that room just stops, presumably because there are just too many after rules being triggered.
So is there some way I can bypass the after rule, if only temporarily while testing? I know I can remove the extension – and that works – but I have a lot of code that uses the extension, and it is a pain in the neck trying to comment and uncomment all of it out.
You could comment out that rule in the extension, or you could silence it. Either way, you’ll have to remember to undo those edits if you don’t want nasty surprises down the road.
Because silencing a rule’s tracing is effectively making the trace code tell a lie, it’s not surprising that there’s no way to do this in I7. Still, if you really want to, it can be done in I6. The rule will need a parenthetical name for this to work, so you’ll have to put one in Jon’s code. I used ``the guess-checking rule’'. Then write something along these lines:[code]Include (-
[ SilentGuessCheck result; @push debug_rules;
debug_rules=0;
result=(+ the guess-checking rule +)(); @pull debug_rules;
return result;
];
-).
The silent guess-checking rule translates into I6 as “SilentGuessCheck”.
The silent guess-checking rule is listed instead of the guess-checking rule in the after deciding the scope rulebook.[/code]You might also want to look into why the rule is firing so often. That might be a symptom of a story or extension bug, which, one fixed, will make your original goal moot.
That doesn’t sound normal at all. Can you copy/paste your story into a new project, remove as much extraneous code as possible (without losing that behavior), and post the reduced source text here? It might be an Inform bug, in which case I’d like to get it into the issue tracker. A reduced test case will help us find out.
Thanks EmacsUser. As you suggested, I would much rather figure out the problem than simply bypass it. Until now, I didn’t know it was a problem. It isn’t the extension; it is my code. I have no idea why the deciding the scope activity fires so often when the after deciding the scope of the player rule is added. I’ve pinpointed when it occurs, i.e., between which versions of the game, but I’m not sure yet what I did to cause it.
As for my second concern, the rules tracing simply stopping, turns out that was my fault. No bug; I fixed it.
It’s hard to tell what’s going wrong without seeing any code.
It might perhaps be that you’re doing something that tests scope (at least testing visibility or touchability involves testing scope) from inside an after deciding the scope rule, which would result in an infinite loop. Something like:
After deciding the scope of the player: if the holy grail is not visible, say "No luck."
If so, then that is probably the problem.
Thanks Felix, that gives me something to think about. However, I am not using any Before deciding the scope or After the deciding the scope (or over-riding the rule for deciding the scope) rules, and the number of firings is finite (it seems to increase as the number of things in the room increases).
I’ll post the problem if I figure out what it is. Suggestions are welcome.
To an extent, this is normal. I7 doesn’t cache the scope between checks, most actions apply to visible objects, and visibility checks test scope every time, so it’s entirely possible for routine action processing to iterate the scope an enormous number of times, depending on how complicated the current environment is. You might look into extensions like Scope Caching to address the matter - though that can cause its own complications.
Yes, I just found the source of the overactive scope activity. It resulted from my rather liveral use of the visible property in phrases such as “now all the visible…” and “repeat with n running through visible …”.