In my code I have a chasm that, if not spanned by anything, cannot be crossed.
The attributes for the chasm are spanned and unspanned.
I mistakenly coded
“Instead of going north when the chasm in unspanned, say ‘(yadda yadda)’”
(notice the IN above, instead of IS?)
The compiler didn’t catch this, and compile was successful, but the game didn’t do what I wanted it to. I had a hard time figuring out what was wrong with the code.
As far as I know, this only appears in “when…” clauses.
That’s pretty weird! I looked at the generated I6 code and it seems like the I7 compiler is pretty much ignoring the “when” clause here.
I’ve reported it as a bug.
As an aside, you probably don’t want your rule to be “instead of going north when chasm is unspanned” but “Instead of going north from [relevant room] when chasm is unspanned.” The first rule will prevent the player from going north anywhere on the map when the chasm is unspanned.
Hi Matt, thanks for reporting it as a bug, and also for the aside note. Yes, I had the location restriction on that line in my code, I shortened it for the purposes of this bug example.
I wonder if I7 tried to work that out by making “unspanned” a phantom location. Or even better a phantom chasm in a phantom unspanned.
A phantom chasm sounds like a cool idea
Every turn when north in south not on east in west on the player not in nothing: say “Things have got pretty confusing round here.”
I guess I7’s parsing of in/on conditions isn’t quite perfect. (It isn’t creating any phantom objects or rooms.)
It seems that these conditions compile in “if” statements too, but evaluate to false rather than true.
The condition “the chasm is in [an] unspanned [object]” would be meaningful. The compiler seems to be trying to parse it that way, but doesn’t generate correct code.
In an “if” statement, it gets closer, but there’s still a spurious condition that prevents it from evaluating true.
! [2: if chasm in unspanned] if ((((Adj_87_t1_v10(ContainerOf(I126_chasm)))) && (self == I126_chasm)))