Hi all,
I’m trying to implement a radio where the player can give instructions to characters who are not present. They would do this via the standard “Joe, do something” mechanism. These instructions would be allowed if the radio was on and set to the right channel.
I can’t seem to get past the fact that Joe isn’t present. I’ve tried playing with scope and reaching into where Joe is, but nothing seems to work.
Any ideas?
Thanks in advance
This works for me:
"Communication Problems" by PB
Lab is a room. Beaker is a person in the Lab. Tom, Dick and Harry are people.
After deciding the scope of the player:
if the radio is switched on:
place Tom in scope;
place Dick in scope;
place Harry in scope.
The radio is a device. It is in the Lab.
Persuasion: rule succeeds.
Test me with "beaker, jump/tom, jump/switch radio on/tom, jump/switch radio off/harry, wave"
Communication Problems
An Interactive Fiction by PB
Release 1 / Serial number 221024 / Inform 7 v10.1.2 / D
Lab
You can see Beaker and a radio here.
>test me
(Testing.)
>[1] beaker, jump
Beaker jumps on the spot.
>[2] tom, jump
You seem to want to talk to someone, but I can't see whom.
>[3] switch radio on
You switch the radio on.
>[4] tom, jump
Tom jumps on the spot.
>[5] switch radio off
You switch the radio off.
>[6] harry, wave
You seem to want to talk to someone, but I can't see whom.
>
Thanks. I must have been doing something stupid and didn’t see it. Indeed, adding a simple “after deciding the scope of the player” rule worked. It’s been a long day lol…
I just wanted to say that scope is a very tricky subject and there’s absolutely nothing stupid about not getting immediately how to do something out of the ordinary with it, whether or not an expert user could give a short solution to your issue.
Regarding the trickiness, there are a lot of other things that come into account if you want to tell Joe to manipulate their surroundings. Does Joe have light to see by? If you just put everything Joe can see in scope, you could end up with the parser giving disambiguation messages mentioning things the player hasn’t heard of yet, 'cause Joe hasn’t mentioned them. (Also the questions about Joe having light and what Joe can see are trickier than they sound, 'cause the visibility relation in Inform and thus the visible adjective are player-centric.)
If it’s compatible with your setting, I’d suggest making it a videophone of some sort to make things simpler, so we can just assume that they player can already see the same things that Joe sees.
You’re illustrating your point well here (the trickiness of scope), because contrary to your implication characters who are not the player don’t have to be able to see things to manipulate them:
Try this little vignette to illustrate this, plus some buggy weirdness:
"Communication Problems" by PB
Lab is a room. The cellar is a room. Tom is a person in the cellar. The gold ingot is a thing in the cellar. The gold ring is a thing in the Lab. The strongbox is a closed opaque container in the cellar. The gold bracelet is a thing in the strongbox. The demi-john is a closed transparent container in the cellar. The gold necklace is a thing in the demi-john. The gold crown is a thing.
Valuing is an action applying to one visible thing.
Understand "Value [something]"as valuing.
Report an actor valuing:
say "[unless the actor is the player][The actor] says [end if][if the noun is the ingot]'Priceless!'[otherwise]'A worthless bauble!'".
The block giving rule is not listed in any rulebook.
After deciding the scope of the player:
if the radio is switched on:
place Tom in scope;
The radio is a device. It is in the Lab.
Persuasion: rule succeeds.
When play begins:
Repeat with r running through things enclosed by the cellar:
say "Tom [if Tom can see r]can[else]can't[end if] see [the r].";
now the cellar is dark;
say "[line break][bold type]The cellar is now dark...[roman type][paragraph break]";
Repeat with r running through things enclosed by the cellar:
say "Tom [if Tom can see r]can[else]can't[end if] see [the r].";
Instead of jumping:
try tom trying valuing the ingot;
try tom trying valuing the bracelet;
try tom trying valuing the necklace;
try tom trying valuing the ring;
try tom trying valuing the crown;
Test me with "value the ingot/value the bracelet/value the necklace/value the ring/value the crown/switch on the radio/tom,take the ingot/tom,give me the ingot/tom,take the bracelet/tom,take the necklace/tom, take the ring/tom,take the crown/tom, value the ingot/tom, value the bracelet/tom, value the necklace/tom, value the ring/tom, value the crown/jump".
Note that the commands failing with ‘You can’t reach into the cellar’ are falling foul of the ‘Can’t reach into rooms’ rule called with the player as the actor, because Tom is in the cellar, and the object Tom is being asked to interact with would be out of scope for Tom in the light, even though Tom is in the dark and can’t see anything…
Oh, I know that NPCs can see in the dark in that sense, and you’re right, my reference to “everything Joe can see” implied the wrong thing.
But if the author doesn’t want that behavior – if they want it to be an issue that the communicant is in the dark and can’t see something – a part of what they may want to do is to leave things out of scope so the player can’t refer to the things (and they’re excluded from consideration for disambiguation).
I think the visibility relation (usually expressed via conditions such as ‘if Tom can see the ring’) isn’t player-centric (the viewer can be any thing- it doesn’t even have to be a person- so ‘if the ring can see Tom’ is equally valid).
But ‘visible’ on its own, as a convenience so that authors don’t have to continually specify ‘to the player’, does refer only to things that the player can see.
Of course,
To decide whether (viewed - a thing) is visible to (viewer - a thing):
if the viewer can see the viewed, yes;
no.
would allow you to write ‘if the ring is visible to Tom’ as an alternative to ‘if Tom can see the ring’.
Incidentally, I’ve just noticed a bug regarding the visibility of doors- they can only be seen from the room that is their current location. The same applies to backdrops. Obviously, for the player this doesn’t matter, because the current location of a door or a backdrop will also be the player’s location if it should be visible to the player. But for NPCs, of course, that’s not the case…
you’re right, I remembered the part that visible was player-centric and conflated that with the whole visibility relation.
Unfortunately, this strategy (keeping things out of scope for the NPC being commanded) falls foul of the ‘You can’t reach into the cellar’ bug illustrated above? The useful response would either be ‘Tom can’t see any such thing’ or, if Tom is in the dark, ‘It is pitch black and Tom can’t see a thing.’
I think something like “You’ve never heard of such a thing” would be more appropriate if the player is trying to refer to something they have no knowledge of, which would require having something like the Epistemology extension in play.
Things aren’t too bad if the room will always be lit and we assume a videophone. Attempting a good general solution to the “give instructions to a remote NPC” problem where there may only be audio communications and/or the room may be dark is a hard problem that would require making a lot of specific calls about defining behavior. So much so that I figured I’d just raise some of the complications and wait to hear more about what @keturion’s particular constraints are, if we haven’t scared them off by now and they want to bring them up. 
Yes, I suppose that although it’s actually true in this situation that Tom `can’t see any such thing’- the usual riposte to trying to refer to an object out of scope- in fact said object has been put out of Tom’s scope purely as subterfuge. There are perhaps two separate issues here:
(i) how to respond to the situation where the object is out of Tom’s scope, with a response that fulfils the same subtle function as ‘you can’t see any such thing’ i.e. ‘you can’t refer to that, but I’m not letting on whether that’s because it doesn’t exist, or just because it isn’t accessible to you at the moment’
(ii) how to respond to the situation where the object is (theoretically at least) in Tom’s scope but the player shouldn’t be aware of that- which if implemented also requires somehow tracking what the player should know about Tom’s surroundings.
At present, Inform responds to (i) with the unhelpful ‘You can’t reach into (the NPC’s location)’ message and to (ii) by not only assuming the player’s full awareness of the NPC’s surroundings, but also reporting results the player cannot see (e.g. ‘Tom picks up the gold ingot’)
I’m not sure there’s a good way around that without fundamentally changing the relationship between visibility and the object hierarchy, unfortunately.
Not sure that’s true- it just requires recoding the test for the visibility relation so that it has special routines to deal with floating objects. It’s not too difficult to determine if a door or backdrop should be present (and thereby visible) in a given location. And if the visibility ceiling of the viewer is the room, then a door or backdrop ‘found in’ that location should be visible.
Actually, leaving things out of scope for this case doesn’t even buy you anything! Inform doesn’t care that the doo-dad is not in the player’s location and the NPC can’t see it and it wasn’t put in scope. The player can still ask the NPC to act on it and they can.
??
I get the following output, whereby all requests falling foul of scope (discounting light) for Tom fail with the ‘You can’t reach into the cellar.’ riposte…
Tom can see Tom.
Tom can see the gold ingot.
Tom can see the strongbox.
Tom can’t see the gold bracelet.
Tom can see the demi-john.
Tom can see the gold necklace.
The cellar is now dark…
Tom can’t see Tom.
Tom can’t see the gold ingot.
Tom can’t see the strongbox.
Tom can’t see the gold bracelet.
Tom can’t see the demi-john.
Tom can’t see the gold necklace.
Communication Problems
An Interactive Fiction by PB
Release 1 / Serial number 221026 / Inform 7 build 6M62 (I6/v6.41 lib 6/12N) SD
Lab
You can see a gold ring and a radio here.
test me
(Testing.)
[1] value the ingot
You can’t see any such thing.
[2] value the bracelet
You can’t see any such thing.
[3] value the necklace
You can’t see any such thing.
[4] value the ring
“A worthless bauble!”
[5] value the crown
You can’t see any such thing.
[6] switch on the radio
You switch the radio on.
[7] tom,take the ingot
Tom picks up the gold ingot.
[8] tom,give me the ingot
You can’t reach into the cellar.
[9] tom,take the bracelet
You can’t reach into the cellar.
[10] tom,take the necklace
Tom is unable to do that.
[11] tom, take the ring
You can’t reach into the cellar.
[12] tom,take the crown
You can’t reach into the cellar.
[13] tom, value the ingot
Tom says “Priceless!”
[14] tom, value the bracelet
You can’t reach into the cellar.
[15] tom, value the necklace
Tom says “A worthless bauble!”
[16] tom, value the ring
You can’t reach into the cellar.
[17] tom, value the crown
You can’t reach into the cellar.
[18] jump
Tom says “Priceless!”
Tom says “A worthless bauble!”
Tom says “A worthless bauble!”
Tom says “A worthless bauble!”
Tom says “A worthless bauble!”
Furthermore, adding this:
After deciding the scope of Tom when we have waved hands:
place the crown in scope.
leads to this:
...
>[19] wave
You wave.
>[20] tom,value the crown
Tom says "A worthless bauble!"
Hi all,
Thanks for all this information. I haven’t been able to digest it yet. Indeed, I am encountering problems related to commands that have a noun and a second noun. I just haven’t really tackled them yet.
As an aside, I’m also having an unexpected problem related to the “spirit-possession” relation as described in “Puff of Orange Smoke” (7.5. Combat and Death) which allows dead characters to leave an inert body behind. The body is part of the person.
When giving commands and the person is actually present, there is no problem. However, when I place Tom in scope (he’s not present), I get a parser ambiguity: Do you mean Tom or Tom’s body? So far I can’t construct a “Does the player mean” rule to prevent this ambiguity. I’ve tried “Does the player mean asking a body to try doing something: it is unlikely”, but it doesn’t work.
In terms of the actual instruction being given: my game is puzzle-oriented, and to solve the puzzle at hand a particular instruction has to be given. It involves two objects that are not in the location of the interlocutor. But ideally, the player should be able to give any instruction involving any known objects.
In my game, all objects get the property “known” if the game has printed out the name.
There is always light.
Also, I don’t want to put Tom in scope unless a command is actually being given to him. But it seems the action “asking Tom to try …” isn’t constructed yet at the time scope is decided? I was then going to just apply a regex to the player’s command, but that seems like a crude approach.
Just as an aside, it seems to me that one problem with putting everything known in scope is that the player could then conceivably act upon them at a distance. Pushing buttons, taking things, etc.
Ideally, we’d only want to place the noun and second noun in scope if instructions are being given. Same for a rule to allow reaching in to Tom’s location.
In this approach gets too complicated, it might just be better to throw it out and try something else.
Why not? What unwanted behaviour are you trying to block?
What is the problem, exactly?
I cannot think of any obvious terrible side effects except that I’d have to write a rule or rules to prevent physical interactions with Tom (attacking, giving, etc).
If Tom were the only factor, I would probably not be concerned. But there are direct and indirect objects that also must be placed in scope, and interacting with these could have more far-reaching consequences. So if I’m going to limit them, I should probably limit him, too.
I’ll get back to you on the commands that take objects.