Override Built-in Synonyms?

I have a feeling that this isn’t going to be an easy one, and that I might have to deal with it with logic rather than with syntax.

I was dissappointed to learn that “screw” is the same as “turn”. I had counted on having a lot of devices: radios, plane consoles and such, where I’d hate to stop the player from “turn knob”, the most obvious way I can think of to tinker with these devices. In fact I’ve already programmed what happens when you turn the radio’s knobs.

I’d also hoped to throw a screwdriver into the mix and allow the player to unscrew parts from the plane. But screw means turn, so now I can’t tell him he’s not allowed to unscrew anything unless he’s carrying a screwdriver, even though I want him turning knobs with his bare hands but not loosing screws with them.

I’d love to decouple these two words. In leui of that I guess I’ll have to write a bunch of rules about screwing and unscrewing when the player is not holding the radio and is not holding the screwdriver and is not sitting in the plane, and whether it looks like he is unscrewing something from the plane or turning a knob on the plane, and so forth. Ergh.

Maybe it would be easier to define only a handful of things as screwable/turnable in the first place, and try to let context determine response from there?

Advice appreciated.


PS: Screw = Unscrew too? That’s even worse.

This can be done (in this case) as easily as: Understand the command "screw" as something new. … at which point “screw” is no longer associated with any action at all and is thus free for your use. (See ch. 16.3. Overriding existing commands). There are some cases where you need to be careful, because the word is associated with more than one action. In those cases, you’ll have to remember to re - associate that grammar as if you were defining it for the first time. For example, if you “understand the command ‘take’ as something new” you’ve not only eliminated “take cat” but also “take inventory.”

Oh, awesome. Then that will be easier to deal with than I’d anticipated. Thanks!

How dangerous would it be to

Understand the command "read" as something new.

In other words, in the case of read/examine, are there obvious unintended consequences like the “take inventory” example?

There are a couple of books in my game, and I’d like to differentiate between looking at them and reading them.

Not at all – in fact there’s an example in the Recipe Book that does this (#285 “Pages”). You might want to check out the other Recipe Book examples in RB 9.6 “Reading Matter” as well.

Perfect, thanks Mike.

Well, this is weird.

[code]Understand the command “screw” as something new.
Understand the command “unscrew” as something new.

Screwing is an action applying to one thing.
Understand “screw [thing]” as screwing.

unscrewing is an action applying to one thing.
Understand “unscrew [thing]” as unscrewing.

[the usual check and carry out code omitted][/code]

It’s working, in that it checks my conditions, carries out the screwing and unscrewing in the way that I’ve defined, etc., but then…

It didn’t decouple itself from turn here… plus I find it a little mysterious that “turn” aligned itself with my “unscrew” rather than my “screw”…

Anyone know what the heck is going on?

Apologies for any unintended innuendo/humor in this post.

My “screwing” and “unscrewing” actions are so complex (apologies again) that I figured it might be better to redefine “turn”.

[code]Understand the command “turn” as something new.

Turning is an action applying to one thing.
Understand “turn [thing]” as turning.[/code]

gets me the message

What the heck? I could swear I had this type of thing working before.

I decided to do this instead:

[code]Tool Unscrewing is an action applying to one thing.
Understand “unscrew [thing]” as Tool Unscrewing.

Check Tool Unscrewing:
If the noun is not the pprightwing and the noun is not the ppleftwing and the noun is not the rightwing and the noun is not the leftwing and the noun is not the wings and the noun is not the rudder and the noun is not a part of the jeep,
say “that’s not something you can unscrew.” instead.

Check Tool Unscrewing:
If the player is not carrying the screwdriver, say “You don’t have a screwdriver.” instead.[/code]

Now here’s the weird part:

turn plane
You don’t have a screwdriver.

Not only is it still confusing “tool unscrewing” or “unscrewing” with “turning”… but it why didn’t the earlier, more specific condition fire before the later, less specific condition?

OK, scratch that last question. That was not an unscrewing message that time, but an identical screwing one.

However, I really need help with making “screwing” and “unscrewing” something different from turning, and not just hiding their relationship in the message content, because I use “turn knob” in a radio puzzle that I haven’t integrated yet.

So first things first: Define “screw” as something new? Or use “Tool unscrewing”?

And then, how to make sure “turn” doesn’t engage screwing or unscrewing code? Should I paste all of the relevant code here?

This is my last puzzle, which I’d hoped to get done today, so I can move on to making interesting dialog and pretty descriptions. :frowning:

Well “rotate”, “twist”, “unscrew” and “screw” are all synonymous with “turn” by default, but I would have thought your code to decouple “screw” and “unscrew” would have worked. When I try it with this basic code:[code]The lab is a room. The plane is in the Lab.

Understand the command “screw” as something new.
Understand the command “unscrew” as something new.

Screwing is an action applying to one thing.
Understand “screw [thing]” as screwing.

unscrewing is an action applying to one thing.
Understand “unscrew [thing]” as unscrewing.

Check Unscrewing: say “That’s not something you can unscrew!” instead.[/code]… I get:

I seem to remember that with commands that are defined in the index as “same as” another (as opposed to just being grammar for the command), you sometimes have to redo the whole group, but that doesn’t seem to be the issue here.

Hm. Let me think.

If you knew this group better, you’d know there’s nothing to apologize for. :smiley:

Ok, that you definitely can’t do. Even if you decouple the grammar for a command, that action’s name is still reserved for good. You could, for example, eliminate all grammar for “taking” and define a whole new action in its place (using the grammar “get,” “take,” etc.) but you could never call it “the taking action.”

I’m still confused about your main issue. Check in the actions index and see that your unscrewing and screwing actions are listed as “New actions defined in the source.” You’ll probably have to scroll down, since they’ll be below the standard actions. Then check each of these actions, as well as the “turning” action, (by clicking on the magnifying glass icon next to it), and see what grammar is defined as “Typed commands leading to this action.” Let us know what you find.

OK, don’t think too hard…

After converting and unconverting and reconverting my code to “screw” vs “tool screw”, it appears to be working now. Must have been some sort of dumb syntax thing.

I’ll let you know if that changes.

Thanks so much for the help… I’m getting close to the finish line!

Confused again.

Skinny Mike, why is

Understand the command "screw" as something new.

OK, as you said earlier in the thread, and

Understand the command "turn" as something new.

Not ok?

Here’s the reason I ask.

I had this in a separate file which tested ok:

Understand the command "read" as something new.

(In fact, didn’t someone supply me with that suggestion here?)

But when I integrated it into my larger game I got the error:

I even tried moving it to the beginning of the code in case it was an order thing, but I got the same error.

Can I not do this? If not, why did it work in my small tester file?


Edited to add: Found this exact code in the recipe book, 16.9. Understanding kinds of value !

Edited to add: OK, I’m a big giant dork. I was getting the error because I had put that “read” line in twice, while integrating my various testers. I’m still curious, however, about the difference between redefining “screw” verses “turn”. Is it because one is the original action and the other is the synonym?

Mike wasn’t saying that you can’t do the “Understand…”, that part’s fine. But you can’t do

Turning is an action applying to one thing.

Because “turning” is already defined as an action in the standard rules and you need to use some other name, like “twisting” or whatever.

That’s why you got the error with reading (note what the error message says: the problem isn’t the “Understand…” line, it’s that you defined the reading action twice.)

It’s important to note that there is a difference between the name of an action used internally in code, and the words you assign to that action that the player can use in the game.

“Turning” is an action that is defined in the standard rules. You can’t undefine or redefine an action once it’s been defined, so you can’t make a new action and call it turning. However, there is nothing preventing you from redefining the word “turn” to make it refer to something else. So this code actually completely legal:

Understand the command "turn" as something new.

This has no effect on the turning action, which still exists. All it means is that the player cannot perform the turning action by typing “TURN ________”. The game will just say “That’s not a verb I recognize,” unless/until you redefine the word “turn” to mean something else.

It is entirely possible (and sometimes desirable) to “remove” an action from the game by redefining all of its synonyms as something new.

Sorry for bursting into this discussion, but I’d like to suggest that you also add the following special cases of “turn”, “screw” and “unscrew”, just for increasing the comical factor of your textadventure:

(the parser-answers in the examples below are placeholders only)

[code]>TURN ME ON
This is no porn adventure.

You wish. :wink:

Screw yourself, kid.

Don’t be rude!


Believe it, they are crazy gamers like me who would type in such goofy commands to see the parser’s reaction. Other players would probably never think of them anyway, but they should be implemented IMO. :mrgreen:

EK… very nice. That will go well with the “spank monkey” and “choke monkey” messages I couldn’t resist putting in, since my game contains a monkey and all.

On the note of adding funny messages, is there a way to do this?

Instead of examining the player's face: say "There's no mirror around here, you know."

Other people have examinable faces in the game, so it seems useful to address this. I’ve also needed it before for other things, but managed to get around it in other ways.

And actually, on that note again…

When examining “face” and the like when other people are in the room, the game always asks “Who’s face, yours or Granny’s?”

This wasn’t so bad when “face” was the only bit of code to deal with. But I like to flesh out everything mentioned in the descriptions, so now hands, hair, nose, eyes, and so forth are added to the list.

Is there a way to say, blanketly, something like

When examining face when people besides the player are in the room, assume the face belongs to the other person