If I want to kiss or talk to a portrait, for example. But I don’t want it to show up in the room description as a separate item. And, it is in a region, not just in a single room. I suppose if a person cannot be in a region then I could solve this by having it follow the player, provided I can suppress the various messages that indicate this is happening. The BACKDROP kind works fine except when it comes to the stuff that you can’t do because it is not “animate.”
I tried overriding KISS for example with “Before kissing:”, but this still resulted in me being unable to kiss because “you can only do that to something animate.”
Is there some way to override this check, or do I have to change its kind and then suppress the various messages in some way?
I’m befuddled. Any help is as always greatly appreciated.
You can have a person be part of a backdrop; that might solve your problem.
I also think that you get the “you can only do that to something animate” line because the understand line for kissing in the standard rules contains a “[someone]” token rather than a “[something]” token. So you could also define a new action that has a “[something]” Understand line (or even write that line for the existing kissing action) and then use rules for kissing to take care of the portrait.
I would advise against that – if you try kissing a table, it will say “You can only do that to something animate” (I think), which will be highly misleading if you can kiss the portrait.
A better idea would be to just write a generic rule for kissing unkissable things and a specific rule for kissing kissable things:
Carry out kissing: say "That's not very kissable."
Carry out kissing a person: say "You don't have that kind of relationship with [The noun]."
Carry out kissing the portrait: [whatever you want to happen]
Or you could just give an object the ‘animate’ attribute without assigning it to an i7 kind of person or man or woman, etc. The way I understand it, i7 manual tells you to sort objects into sentient and non-sentient by giving them ‘kinds’, but the actual code parser ignores this information and only looks at whether objects have the ‘animate’ attribute (which they get automatically when they are assigned to a sentient kind).
So, this gives you a convenient hook to make an animate object that belongs to a non-sentient kind…
The Starting Room contains an animate scenery thing called a built-in AI.
However, there were cases where, for a reason I didn’t understand (perhaps some kinds won’t allow it), I wasn’t able to successfully assign certain objects the animate attribute. This was solved by an i6 hack, forcing the attribute upon them, like so…
[code]A built-in AI is a backdrop. The built-in AI is in every room.
Include (- has animate -) when defining the built-in AI.[/code]
Hope that’s helpful. It’s been a while since I came upon that solution – I looked it up in my code for you but I may have misrecalled the way I arrived at it. Anyway, it worked, but I don’t use the i6 hack anymore – I ended up commenting it out for some reason. Possibly because at one point I decided to change a lot of my ‘kinds of backdrop’ into ordinary ‘scenery’ objects of various kinds.
Sorry to quote myself (especially since I don’t think my solutions were the most relevant) but I made a mistake here that I feel I should correct for the record. The line above will not work on its own – not without also adding something like this…
A thing can be inanimate or animate. A thing is usually inanimate.
The animate property translates into I6 as "animate".
Which I overlooked in my code previously. This is why I was able to comment out the ‘(- has animate -)’ hack which I had previously been forced to apply separately to every single object I wanted to be an animate non-person in my game. With the lines above, though, one can avoid all that customisation, just by creating a permanent i7 hook into the buried i6 property ‘animate’.