Giving Items to Inanimate Objects?

Following recent discussions on 'take all' and the meaning of 'it', one other oddity I'd like to raise is the default response for 'give A to B' when B is inanimate. As inanimate objects can't 'want' anything, I would expect something like "You can't do that" rather than "It doesn't want it"?

Perhaps a related issue is that 'animate' objects can only be male or female? Is there a case for introducing an 'other animate' type?


...which could also be the default type of the player!


In the case of a robot/android this would be another type of non-sex animate type that could be implemented.


Being "male" determines that an object is referred to as "he".
Being "female" determines that an object is referred to as "she".
Being "inanimate" determines that an object is referred to as "it".

What would "other animate" do that "inanimate" doesn't do already?

It's maybe not obvious, but these types only determine the grammatical gender of an object.

I think "It doesn't want it" is a perfectly good response. If you try to give an object to a statue, or a mirror, or a rock, it makes perfect sense that you will be able to offer the item, but an inanimate recipient won't respond. The wording seems a bit silly in some cases, but in those cases the player was entering a silly command.

Or another way to think about it: If there was a "other animate" option, where do you draw the line? Is a statue "other animate" or "inanimate"? You don't know until it moves. So Quest lets the player choose. If the player types "put ring on statue", they're treating it as inanimate, and the response line is appropriate. If the player types "give ring to statue", the player is assuming the statue is animate, and the response is appropriate.

The living-vs-static distinction, as far as Quest is concerned, is determined by what the player is trying to do. The "inanimate" type is just a flag that the object should be referred to as "it".


What would "other animate" do that "inanimate" doesn't do already?

Without the distinction, the only practical default response to an inanimate object being given an item is "It doesn't want it", which effectively brings the inanimate object to life! ...and, as a player, I may then be tempted to offer more items.

...it also seems odd that, by default, the player is an 'inanimate object'.

Or another way to think about it: If there was an "other animate" option, where do you draw the line? Is a statue "other animate" or "inanimate"? You don't know until it moves.

Sorry, I don't follow this argument? What line do you mean? The game designer should be deciding if the statue is 'animate' or 'inanimate' and providing responses appropriately? The player finds out through interaction with the statue. I'm pointing out that the default response to 'give' is making all statues seem 'animate' regardless of the designer's intentions.


I do not think we will be changing this, but if you want to do that for your game you can override the DefaultGive template to this:

DefaultGiveFunc(object1, object2)

Then create a function DefaultGiveFunc that returns a string, and has two attributes, obj1 and obj2. Then paste in this code:

if (DoesInherit(obj1, "npc_type")) {
  return (WriteVerb(obj1, "do") + " not want " + obj2.article + ".")
}
else {
  return ("That doesn't work.")
}

In the case of a robot/android this would be another type of non-sex animate type that could be implemented.

When I make a generic robot type, I make it male (or female) but not named, then change the pronouns to "it" and "its".

Then I make it a surface and change the prefixes to "which is carrying" and "It is carrying", and set it to list children when examined.

Then I set up Use/Give on it. Under "Give something to this" I put msg("The robot has not been programmed to take things.").

Then I add a "speak to" verb, which prints: The robot emits a series of "blips" and "bloops".

I add a take message: The robot is much too heavy to pick up.

Finally, I add Pixie's NpcLib and the give the robot plenty of stuff to do during play.


I do not think we will be changing this

If I'm the only one who thinks this is an issue, that makes sense.

you can override the DefaultGive template

I think you are overestimating my technical knowledge! Where and how exactly do I make that change? Does it mean tinkering with the published version of the game or can I do it within Quest (high level or code view)?


Where and how exactly do I make that change?

Best method:
http://docs.textadventures.co.uk/quest/overriding.html


Easy out:
https://github.com/KVonGit/QuestStuff/wiki/GIVE-TO-something-inanimate


Thanks KV, but my focus here is simply to avoid scenery objects seeming more important than they really are. To bring two classic games up to date I added hundreds of scenery objects for everything mentioned in location descriptions (walls, paths, ceilings, dust, flowers, doors...). I would hate to mislead the player into wasting time interacting with any of these objects because of an animate default response. If there is an easy way to change the response in one place, I'll take that route.


Sorry KV, my responses are a bit out of step! I've installed the code to change the default give response, and am happy with the result. Thanks!


If there is an easy way to change the response in one place, I'll take that route.

I'm not quite sure I'm following you.

If you follow that link, it shows you how to add the code Pixie suggested in full code view. You'd only need to do that once in each game.


If you don't want to add that code to each game, you could create a library and add it to each game.

GiveLib.aslx

<?xml version="1.0"?>
<library>
  <dynamictemplate name="DefaultGive">DefaultGiveFunc(object1, object2)</dynamictemplate>

  <function name="DefaultGiveFunc" parameters="object1, object2" type="string">
    if (DoesInherit(object1, "npc_type")) {
      return (WriteVerb(object1, "do") + " not want " + object2.article + ".")
    }
    else {
      return ("That doesn't work.")
    }
  </function>
</library>

If adding a library to every game seems like too much work, you'd have to edit the core files in the Quest program's directory in the Program Files directory (or the Program Files (x86) directory) in your computer. This is dangerous (especially if you don't know how everything in that directory works, individually and together), plus you'd need Administrative Privileges in Windows to do that (which I believe most people do, but it's really a 50/50 shot; you may or may not be the master of your PC).


Sorry KV, my responses are a bit out of step! I've installed the code to change the default give response, and am happy with the result. Thanks!

You're cool, DavyB! Glad you got it working!


This topic is now closed. Topics are closed after 60 days of inactivity.

Support

Forums