Another couple of brainteasers...

Well, after my system crashed, and I backed up all of my work, reset the system and re-installed Inform 7 and re-loaded my work, something positive actually happened–my compile time is MUCH shorter! I am now at about 64000 words. Previously, before the crash, compile time was almost 40 cycles(about 2-4 minutes); now, it’s less than a minute. How did this happen? I backed up everything via a flashdrive(USB stick–16GB)–it’s still connected, could this be what’s speeding it up? I don’t recall choosing to use it as a memory-booster(I was offered that choice, but I didn’t opt for it).

Second question–
I have created a room that has a number of pieces of equipment, each one with a somewhat removed control device. I don’t want the player to be able to manipulate the controls while on–or in–one of the machines. My question is, does the program distinguish between ‘on’ and ‘in’…?? Specifically, will I have to write an instead rule for both–(for example)

Check turning the crank: if the player is on something: say "You can't reach the crank from here."; if the player is in something: say "You can't reach the crank from here."
Or, can I use ‘if the player is enclosed’…??

Yes, Inform distinguishes between on and in. A succinct way to write your rule might be:

Check turning the crank while the player is on a supporter or the player is in a container: say "You can't reach the crank from here."; stop.

Two important points:

  1. You can’t just say “If the player is in something,” because the player will always be in a room. You should specify “in a container”.

  2. Check rules do not automatically stop the action. If you want a check rule to block further progress, you have to explicitly tell it to stop.

If you have a number of similar circumstances to deal with, you could consider changing the accessibility rules:

Rule for reaching outside a container: 
    say "You can't reach that from here.";
    deny access.

Rule for reaching outside a supporter: 
    say "You can't reach that from here.";
    deny access.

Speaking from my experience on a not-too-recent Macbook Air, that sounds like a long time for a game of that size – could it be that your skein had gotten bushy and was weighing it down? The larger the skein, the longer its takes to compile. Maybe when you restored, the skein was lost and a new empty one was created? - Jack

It could be a virus checker:

Thanks, Mike, for the tips. I guess I have a long way to go before I truly know all of the ins and outs of Inform.

Honestly, I don’t really use the skein. I prefer to just get into the game and test it manually, so maybe I’m missing something by doing it this way…??

I think a thorough re-read of the manual is in store. So far I have been pretty much getting by on rules, clauses and assertions, plus whatever I pick up here, because I just can’t wait to get it all typed and working.

Thank you all for the hints.

By the way, B&J, I do think that the skein had grown heavy because I am constantly going in and play-testing–but when I looked at the skein it had only gotten so big(maybe it reached its limit display-wise). Then came the crash/reset–maybe only a fraction of the skein(whatever was displayed) got through. I just reset the skein, now it is truly empty and compiling now takes only about 20 seconds(now about 65000 words).

I suspect Windows Defender is still slowing things down, as described in the thread . A compile should only take a couple of seconds for a game that size.