I’m not sure if this is a problem with the “can’t push people” rule, or something wrong with my code.
Here’s code with a pirate whose printed name is chosen in when play begins, and a sailor whose printed name is always the same. (What I want to work is the pirate, and the sailor is just a test case.)
[code]“Pirates” by Q.
When play begins:
if a random chance of 1 in 2 succeeds:
now the printed name of pirate1 is “Pete”;
otherwise:
now the printed name of pirate1 is “Alice”.
Deck is a room.
Pirate1 is a person in Deck. Understand “pirate” as pirate1. “Pirate [printed name of pirate1] is standing here.”
Sailor1 is a person in Deck. Understand “sailor” as sailor1. “Sailor [printed name of sailor1] is standing here.”
The printed name of sailor1 is “Jones”.
Understand “Jones” as sailor1.[/code]
Here’s the output:
Using actions, I see that the “can’t push people” rule is working correctly in the case of PUSH PIRATE, but I can’t see why it’s working differently than PUSH SAILOR.
Okay. Something is wrong with how Inform is forming capitalized versions of proper names when printing [A noun] or [The noun] (but not [a noun] or [the noun]). I don’t know why it’s working that way, but that seems to be what the problem is.
This definitely needs to be filed as an Inform bug, which I will do next.
The following will replace the affected responses that I could find in the Standard Rules:
When play begins:
now the can't push unpushable things rule response (A) is "[if noun is proper-named][noun][else][The noun][end if] [cannot] be pushed from place to place.";
now the can't turn people rule response (A) is "[if noun is proper-named][noun][else][The noun][end if] [might not like] that.";
now the can't push people rule response (A) is "[if noun is proper-named][noun][else][The noun][end if] [might not like] that.";
now the can't pull people rule response (A) is "[if noun is proper-named][noun][else][The noun][end if] [might not like] that.";
now the report touching other people rule response (A) is "[if noun is proper-named][noun][else][The noun][end if] [might not like] that.";
now the can't rub another person rule response (A) is "[if noun is proper-named][noun][else][The noun][end if] [might not like] that.";
now the innuendo about squeezing people rule response (A) is "[if noun is proper-named][noun][else][The noun][end if] [might not like] that.";
[now the requested actions require persuasion rule response (A) is "[if noun is proper-named][noun][else][The noun][end if] [have] better things to do." (A);
now the carry out requested actions rule response (A) is "[if noun is proper-named][noun][else][The noun][end if] [are] unable to do that." (A); ]
…only there seems to be (note the two last ones are commented out) an additional problem replacing responses for rules that are defined as I6 routines under the surface. (Two bug reports, then.)
Assuming you’re not planning to use NPC ordering for anything, you can further address that issue with
Instead of asking someone to try doing something:
say "It doesn't look like [the person asked] wants to take orders from a cabin girl like you."
If you are planning to use NPC ordering, then, well, say and it’s probably possible to get around that irritation also, just more long-windedly.
Ah, perfect – thanks, both of you. I was planning on making custom “instead of” rules for this NPC anyway, but this cropped up in testing before I’d made the rules, so I thought I’d just check about the possibility of a bug here.