Object Drops in one Procedure

witch wyzwurd
12 Feb 2007, 12:35
I'm meaning to group all of my drop {lose <object name>} commands in a procedure. So I created a procedure titled "drop_procedure". Then for an object named <ball>, I programmed (cold code):

drop {
do <drop_procedure>
}

Then within "drop_procedure" I programmed (using QDK):

if "#quest.originalcommand#" is equal to "drop #@ball#" then Take "ball" from the player.

But the "ball" remains in the player's possession, which tells me my command doesn't work. I've used only the "Take..." part of the command and the "ball" is dropped, so I know it's the first half of my command that is bad. I've also tried lose #@ball#, drop @ball, drop ball, lose ball, etc.

I've tried #quest.command# also. I've even made up a silly "equal to" message like "throw," but when I type in "throw" the ball is still not dropped.

I want the player to be able to click "Drop" from the menu and have Quest process the command using my procedure (without using flags). I have to use the string command because other objects are also listed in the procedure and I don't want them to be dropped if all I want to drop is the ball.

I find it easiest to include all of my object's drop commands in one area, for quicker editing, reading, and comparing.

I'm using 3.53 still, and need an answer for this version.

Thank You :}

Freak
12 Feb 2007, 12:52
Try adding a line of debug code; right above that, put the line Print Text "DEBUG: Comparing [#quest.originalcommand#] against [drop #@ball]."

witch wyzwurd
12 Feb 2007, 13:53
Okay, that helped. I learned that quest.originalcommand returns the object's alias rather than it's original name. But...

The real name is: Ball
The alias is: Rubber Ball
And it has alternative names, like: the rubber ball; the ball...

So now the ball is dropped using "drop rubber ball" but not using "drop the rubber ball." That's why I used #@Ball#, but when I do that I get the message: "DEBUG: comparing [drop rubber ball] against [drop ]"

How do I include all the names for an object then? I know quest.command checks for synonyms, but an alt name for an object isn't a synonym.

Thanks

Alex
12 Feb 2007, 14:07
There are a few ways you could do this:

- Instead of checking the entire command, just check the object. #quest.lastobject# should equal the real name of the object, even if a synonym or alias or alt-name was used.
- Call your procedure with a parameter, e.g. in your "ball" object code, use:

drop do <drop_procedure(ball)>

Then in your procedure, check the parameter:

if ( $parameter(1)$ = ball ) then ...

Freak
12 Feb 2007, 14:13
Add the value of "$thisobject$" to that text. See if that helps.

BTW, why do you even want to put all drop commands together? I've generally found that it's more useful to organize actions by the objects involved than the verbs.

paul_one
12 Feb 2007, 15:15
Right, you need a prefix of "the".. Not including "the" in the name.

Then you can but as the name "ball" and Alias "Rubber Ball" and Alt "ball;rubber ball; bl".

witch wyzwurd
12 Feb 2007, 18:42

Instead of checking the entire command, just check the object. #quest.lastobject# should equal the real name of the object, even if a synonym or alias or alt-name was used.

I went with this option and it works great! :} Thanks Alex

BTW, why do you even want to put all drop commands together?

Well, it kinda went like this... Aaarrggghhh! Quest erased my drop and take scripts again in QDK (3.53), so I guess I'll open WordPad and cold-code these commands. :{ I know, instead of having to lose the scripts in the drop or take section within each object's window or switch back and forth from WordPad to QDK, I'll put them in the Procedure menu box so I can edit them there without a problem of QDK messing up. And by going this this, I learnt that I like them together, because I can view them all together, so their messages have a continuity.

Does 4.0 get rid of that QDK error?

007bond
15 Feb 2007, 07:47
i don't understand what you're trying to do by manually creating a drop procedure.
Doesn't it have a drop command built in?

witch wyzwurd
15 Feb 2007, 17:49
Yah, it does 007, but if you've ever experienced the bug in 3.53 that changes your script when you haven't wanted that to happen, then you'd understand.

Alex
19 Feb 2007, 13:08
QDK 3.53 does sometimes have problems where changing script somewhere leads to a change somewhere else.

In QDK 4.0, the script editing functionality has been completely rewritten, which means this can no longer happen.