I’ve got an object (a rake) and I want it to be gettable in a dark room.
I used a visibility rule and a deciding the scope of the player rule pairing to make this work, and it does if you type GET RAKE in the dark, but not if you type GET ALL in the dark. Is this an idiosyncracy of GET ALL, or is the rake just not in scope at that point? This demo demonstrates the discrepancy:
"Rake of darkness" by Wade Clarke
Lab is a room. "A sign says, 'The room east of here is dark, but there's a rake in it.'".
Dark Lab is east of lab. Dark Lab is dark.
a rake is in Dark Lab.
A visibility rule when in darkness:
if the noun is rake:
there is sufficient light;
After deciding the scope of the player when rake is in the location:
place rake in scope;
test me with "e/get all/get rake".
Here’s a quick workaround, but I don’t know what might have been broken incidentally by the change.
The issue is that, after construction of the multiple object list using the deciding whether all includes rules that you have provided, a routine called ReviseMulti() drops any object that doesn’t share the same scope ceiling as the actor. Since the actor is the player and “in” the darkness object by I6 rules, but the rake is in Dark Lab by those same rules, the rake gets cut, leaving nothing. The following includes a modified ReviseMulti() that OKs the situation where the actor is in thedark but the object in question is in real_location.
Working Example?
"Take Rake"
Lab is a room. "A sign says, 'The room east of here is dark, but there's a rake in it.'".
Dark Lab is east of lab. Dark Lab is dark.
A rake is in Dark Lab. A rock is in Dark Lab.
[A visibility rule when in darkness:
if the noun is rake:
there is sufficient light;] [not functional in example; taking action does not require light]
After deciding the scope of the player when rake is in the location:
place rake in scope;
[After deciding whether all includes:
say "MOL = [multiple object list]." [doesn't ever list anything, but >TRACE 4 output shows different information]]
test me with "e/get all/get rake".
[Apparently the rake is being dropped by ReviseMulti(). This happens during a check for shared scope ceiling, because ScopeCeiling of player is thedark while for rake it is Dark Lab.]
Include
(-
! ==== ==== ==== ==== ==== ==== ==== ==== ==== ====
! Parser.i6t: ReviseMulti
! ==== ==== ==== ==== ==== ==== ==== ==== ==== ====
[ ReviseMulti second_p i low sc1 sc2; ! NEW LOCALS
#Ifdef DEBUG;
if (parser_trace >= 4)
print " Revising multiple object list of size ", multiple_object-->0,
" with 2nd ", (name) second_p, "^";
#Endif; ! DEBUG
if (multi_context == MULTIEXCEPT_TOKEN or MULTIINSIDE_TOKEN) {
for (i=1,low=0 : i<=multiple_object-->0 : i++) {
if ( (multi_context==MULTIEXCEPT_TOKEN && multiple_object-->i ~= second_p) ||
(multi_context==MULTIINSIDE_TOKEN && multiple_object-->i in second_p)) {
low++;
multiple_object-->low = multiple_object-->i;
}
}
multiple_object-->0 = low;
}
if (multi_context == MULTI_TOKEN && action_to_be == ##Take) { ! THIS SECTION RELEVANT
#Ifdef DEBUG;
if (parser_trace >= 4) print " Token 2 plural case: number with actor ", low, "^";
#Endif; ! DEBUG
if (take_all_rule == 2) { ! this variable set by Descriptors()
for (i=1,low=0 : i<=multiple_object-->0 : i++) {
! print "<take_all_rule == 2 check for ", (name) multiple_object-->i, ">^";
sc1 = ScopeCeiling(multiple_object-->i); ! NEW LINE
sc2 = ScopeCeiling(actor) ; ! NEW LINE
if (sc1 == sc2 || (sc2 == thedark && sc1 == real_location or thedark)) { ! THIS LINE MODIFIED
! print "<shared scope ceiling observed>^";
low++;
multiple_object-->low = multiple_object-->i;
}
else {
! print "<", (name) multiple_object-->i, " does not share scope ceiling with actor>^";
}
}
multiple_object-->0 = low;
}
}
i = multiple_object-->0;
#Ifdef DEBUG;
if (parser_trace >= 4) print " Done: new size ", i, "^";
#Endif; ! DEBUG
if (i == 0) return NOTHING_PE;
return 0;
];
-) instead of "ReviseMulti" in "Parser.i6t".
For clarification, when you say, “I don’t know what might have been broken incidentally by the change”, do you mean the change you’ve made to ReviseMulti?
Yes. I don’t think that the very limited change should have much impact outside of the situation that you’ve set up here, but this is my first encounter with ReviseMulti(), so I’m not sure what else it may interact with. (It seems pretty specific, though.)
EDIT: To further clarify, the modification can only produce a result different from normal when:
a taking action is being parsed
an “all” word (all/each/every/everything/both) was used in the player's command
the player is in the darkness object (thedark) and
3a) the object in question is in the real_location (your case) or
3b) the object in question is also in the darkness object (seems unlikely)
the object in question was added to the multiple object list by other rules (e.g. normal rules or your special ones)
So it should be safe. (You’ll notice that both the yourself object and the rock that I added to the Dark Lab are ignored, because of #4 above.)
Sorry, I haven’t had time to try it yet. It looks good on paper, though I also got nervous about any caveats like not being sure what else it may interact with. However I will report back in this thread once I have actually tried it. Thanks