Zugg Software :: View topic - [1.34] #al test {~test %1 %2 %3}

Posted: Sun Jul 08, 2007 4:05 am

#al test {~test %1 %2 %3}

Sends "test 123" to the mud instead of "test 1 2 3".
Is there a way to do this without it stripping the spaces? Is this a bug, an intention, or just due to my misuse of ~?

Apprentice Joined: 12 Jul 2004 Posts: 190 Location: Canada

There is a way to do this... though I'm not sure whether the above could still be considered a bug... try:

Posted: Sun Jul 08, 2007 1:22 pm

That does work, Thinjon, but this definitely seems like a bug.

Apprentice Joined: 12 Jul 2004 Posts: 190 Location: Canada

Aye, I agree... but figured I'd offer an alternate solution in the meantime :)

For bonus points... if you don't know beforehand how many parameters you need to support:

Posted: Sun Jul 08, 2007 10:01 pm

What I do is replace simple commands to the mud, such as:

dstab <target>
shoot <target> <dir>
flay <target> <defense>

With something more intuitive.
#al dstab {#IF (%null(%1)) {dstab @target} {dstab %1}}
In most cases this is enough, but sometimes a command requires 2 parameters from me, which complexifies things.

#al shoot {
#SWITCH (%null(%2) && %len(%1)>2) {~shoot %1 @dir}
(%null(%2) && %len(%1)<3) {~shoot @target %1}
(%null(%1)) {~shoot @target @dir}

That lets me use a really loose syntax. "shoot zugg". "shoot w" etc. Will all shoot someone, somewhere.
Really though, this is no big deal. I've just renamed those few aliases to "shootT", "flayT" etc. Its still (probably) a bug though.

Wanderer Joined: 09 Jun 2006 Posts: 62 Location: Florida

Instead of listing the paramaters out, you can also use %0 if you don't particularly care about the order they're sent or any of that. This has been working fine for me as a workaround for this issue. Also, if you don't want to have to keep doing the %eval(%concat()) bit, you can put a %char(32) inbetween each argument and it'll send a literal space as well... I guess it's a question of style, no? :D

Posted: Sun Jul 08, 2007 10:08 pm

One quick question, pretty unrelated.

#al test {script referencing the %1-%99 directly}
#al test {$var1=%1;$var2=%2;%var3=%3, etc
<script referencing the assigned local vars>}

I kind of assumed that if I access the parameters directly with %1-99, then this is the same thing as assigning them to local vars and performing functions on the local vars, so far as the speed bonus. I thought local vars were only quicker in comparison to globals.

Is this the case? Or not?

Posted: Sun Jul 08, 2007 10:28 pm

From the speed tests I've seen, it really depends on the script. The scripts I were running (which were veritably massive - 10000 database operations kind of massive) the difference was a matter of a few milliseconds, a tiny slice of the time the script took. The benefit of local variables in this situation is mostly readability. Also, you can avoid the messy assignment syntax and have CMUD do it for you:

#alias test($var1,$var2,$var3) {whatever}

Posted: Mon Jul 09, 2007 6:38 pm

I've added this to the bug list. The problem is that even with the ~, the parser is detecting the "~test" as a possible alias call and is sending the arguments to the alias instead of formatting them for display to the MUD. So it's just like having:

alias 1 2 3

where 1 is passed into %1, 2 is passed into %2, etc, without the spaces. Anyway, the ~ is supposed to turn this off, but it obviously isn't working as intended.