Object default get message
Overcat
17 Jan 2007, 21:29Hey, folks.
The only problem with this is the default message for getting an object still appears:
How would I temporarily switch off the default get message?
I can do this with by creating my own "get" command, but this causes problems with disambiguation. ('command <get #@object#>' will disambiguate two local widgets, even if one of them is in your inventory. ie. you already have one of them, so it shouldn't disambiguate.)
gain {
msg < You stick your hand inside the wet, loamy soil. After digging around with your fingers, you pull up a long, glittering chain. It is a necklace.>
remove <Vestigian_Forest_0_-10_0_glitter>
hide <Vestigian_Forest_0_-10_0_glitter>
hide <Vestigian_Forest_0_-10_0_soil>
move <it_cl_necklace01; inventory>
show <it_cl_necklace01>
}
The only problem with this is the default message for getting an object still appears:
You pick it up.
You stick your hand inside the wet, loamy soil. After digging around with your fingers, you pull up a long, glittering chain. It is a necklace.
How would I temporarily switch off the default get message?
I can do this with by creating my own "get" command, but this causes problems with disambiguation. ('command <get #@object#>' will disambiguate two local widgets, even if one of them is in your inventory. ie. you already have one of them, so it shouldn't disambiguate.)
paul_one
17 Jan 2007, 22:58take doaction <it_cl_necklace01;gain>
I think that should work..
..This may probably have more success than the first one.
I think that should work..
or take <|xn>
..This may probably have more success than the first one.
Overcat
17 Jan 2007, 23:58Oh yeah. I'm an idiot. Thanks.
I actually solved this using verbs, instead. (More round-about, I know.) I created a get verb. This is essentially the same as creating a get command, and here is where my other problem persists: disambiguation.
One of the reason's why I want to have my own get command is so that I can alter the default messages somewhat. I'd like to indent them. Around 4 spaces or so - you cannot add those 4 spaces with the error tag because they get clipped. By creating a command, I can msg out the errors and add my leading spaces (indents). This, however, causes a problem. Typing 'get widget' disambiguates widget objects both in the room and in my inventory. I of course don't want to get something I already possess!
Any suggestions?
I actually solved this using verbs, instead. (More round-about, I know.) I created a get verb. This is essentially the same as creating a get command, and here is where my other problem persists: disambiguation.
One of the reason's why I want to have my own get command is so that I can alter the default messages somewhat. I'd like to indent them. Around 4 spaces or so - you cannot add those 4 spaces with the error tag because they get clipped. By creating a command, I can msg out the errors and add my leading spaces (indents). This, however, causes a problem. Typing 'get widget' disambiguates widget objects both in the room and in my inventory. I of course don't want to get something I already possess!
Any suggestions?
Overcat
18 Jan 2007, 15:31Which reminds me.
Suppose I have a 'push' command or verb. It is used to push objects around. There is a rock in the current room, and I need to push it, so I type 'push rock'. The problem is I have a little rock in my pocket, which happens to have 'rock' in it's alt property. Quest now disambiguates between the rock in the room and the one in my pocket. I patently do not want to push the rock in my pocket!
I could fix this by changing the command from 'command <push #@object#>' to 'command <push #object#>'. The second command would loop through only the objects in the room to find one that matched. Three problems with that, though:
1) slow-down, if there are many objects in the room
2) I can't read the alt property to scan for appropriate items
3) I'd have to create my own disambiguation routine for similarly-named objects that do exist in the room
Any thoughts on this, guys?
Suppose I have a 'push' command or verb. It is used to push objects around. There is a rock in the current room, and I need to push it, so I type 'push rock'. The problem is I have a little rock in my pocket, which happens to have 'rock' in it's alt property. Quest now disambiguates between the rock in the room and the one in my pocket. I patently do not want to push the rock in my pocket!
I could fix this by changing the command from 'command <push #@object#>' to 'command <push #object#>'. The second command would loop through only the objects in the room to find one that matched. Three problems with that, though:
1) slow-down, if there are many objects in the room
2) I can't read the alt property to scan for appropriate items
3) I'd have to create my own disambiguation routine for similarly-named objects that do exist in the room
Any thoughts on this, guys?
Cryophile
18 Jan 2007, 16:30Just check to make sure the object is not in the room Inventory?
paul_one
18 Jan 2007, 20:56So verbs will come up with this error too?
I thought verb's might be slightly more intelligent and only prompt the user is more than one object has the verb... Perhaps not... I haven't used/tested them yet.
There's the old obsolete function "getobjectname".. This way, you could check to see if there were objects in your inventory, and move them out to a temporary hidden room (I say move rather than hide because the object is still in the room - and more than one object with this alt will probably still cause disambiguation)..
I suppose you could also have a combination of the two - a command and a verb - although I don't know which is processed first (I'll experiment in a few mins).. If it's the command - you could get rid of the inventory, setting a flag. Then execute the command in 'normal' mode.. which should hit the verb... Then in the after-turn, check for the flag and return all objects in the hidden room to the inventory.
I thought verb's might be slightly more intelligent and only prompt the user is more than one object has the verb... Perhaps not... I haven't used/tested them yet.
There's the old obsolete function "getobjectname".. This way, you could check to see if there were objects in your inventory, and move them out to a temporary hidden room (I say move rather than hide because the object is still in the room - and more than one object with this alt will probably still cause disambiguation)..
I suppose you could also have a combination of the two - a command and a verb - although I don't know which is processed first (I'll experiment in a few mins).. If it's the command - you could get rid of the inventory, setting a flag. Then execute the command in 'normal' mode.. which should hit the verb... Then in the after-turn, check for the flag and return all objects in the hidden room to the inventory.
Overcat
18 Jan 2007, 21:21Just check to make sure the object is not in the room Inventory?
Right. But. I think Quest disambiguates before any code is run in either the command script or the verb action script. I just don't have a chance to make that check before the disambiguation window pops up. Hence why I thought maybe excluding the @ from the command. That disables the disambiguation.
I thought verb's might be slightly more intelligent and only prompt the user is more than one object has the verb
I'm gonna' test that hypothesis right now.
Let me know what you all come up with.
Overcat
18 Jan 2007, 21:30A verb disambiguates identically to a command, checking both your inventory and the current room. Because it disambiguates before any code is run, I think temporarily moving the inventory objects elsewhere won't work. It'll disambiguate before you get a chance to execute that sneaky manoeuvre.
paul_one
19 Jan 2007, 10:27There's beforeturn.
This should allow you to move them out before hand...
Do you know if commands are executed before verbs?
This should allow you to move them out before hand...
Do you know if commands are executed before verbs?
Overcat
19 Jan 2007, 13:22There's beforeturn.
Oh, yeah. I could check the status of the last command, then move the inventory items. Thanks. May use that.
Do you know if commands are executed before verbs?
Let me test...
It seems that verbs override commands with the same name.
verb <push; shove> msg < You can't push that.>
command <push> {
msg < Cmd push fired.>
}
and
verb <push; shove> msg < You can't push that.>
command <shove> {
msg < Cmd push fired.>
}
both result in the verb activity, but not in the command activity at all. That is, it isn't the case that they both fire - only the verb does.
I think Im Dead
19 Jan 2007, 17:48Are you testing for each object in #quest.currentroom#? If that doesn't ignore objects in a player's inventory you could also give each object a property of location with a value of the name of the room they are in. Then refine your search for each object in #quest.currentroom# & $objectproperty(location; #quest.currentroom#)$ as an object in the inventory would contain a location property of $name(player%userid%)$.
Overcat
19 Jan 2007, 17:55Are you testing for each object in #quest.currentroom#?
Yes. If I use the command <push #object#>. The problem there is I cannot reference the alt property for valid objects in the current room that may need disambiguation.
I am currently using the command <push #@object#>, but in the beforeturn script I put:
if ($left(#quest.command#; 4)$ = push) then {
for each object in <inventory> {
move <#quest.thing#; inventory-swapout>
}
property <PC; SwapInventory>
}
and in the afterturn script I put:
if property <PC; SwapInventory> then {
for each object in <inventory-swapout> {
move <#quest.thing#; inventory>
}
property <PC; not SwapInventory>
}
If that doesn't ignore objects in a player's inventory...
It does ignore the inventory. Fortunately, I don't need to use the command <push #object#>.