Zugg Software :: View topic

Posted: Wed Apr 15, 2009 4:26 pm

I have an alias, chant, that checks my position, and stands me/returns to previous position if i'm not standing.

Posted: Wed Apr 15, 2009 5:28 pm

First of all, I don't see why you're calling a local variable only to have it set to the position variable anyway. You're better off just using the @position. In fact, looking at the script in script editor, it appears that you putting the $postion=@position is the reason why it's not working.

Changing it to:

Posted: Wed Apr 15, 2009 5:32 pm

The proper way to prevent recursive calls is to use the ~ character in CMUD. So unless you have changed the ~ to \ in the Special Character preferences, you should just do:

~chant %params

That should take care of your syntax errors.

Posted: Wed Apr 15, 2009 5:48 pm

Ahh, well now that i look at it i don't need to assign a temporary state for the position, BUT that still shouldn't have given me an error.
That being said, using $pos also gave same problems. As i was remarking out the #local the highlighting changed and I tried this:

Posted: Wed Apr 15, 2009 6:23 pm

If you insist on using the local variable, it will always give an error when doing @position.

The correct way of doing that would be to change it to the proper format of:

$pos=@{postion}

But again, there is no need whatsoever for you to use a local variable in here. You're just taking that much more time to compile the script. Not sure about using the MUD's anti-recursive alias, but give it a try.

Charneus

Posted: Wed Apr 15, 2009 6:49 pm

I've already remarked out the code, I don't' delete, just remark it out usually, and noticed this while I was removing the local variables.

I was unaware that when assigning a value to a local from a global variable you need to use the $local=@{global} syntax. That removed the error when I tested it.

Perhaps this should be added to the local variables help page?

Also the #local link on this page
http://forums.zuggsoft.com/modules/mx_kb/kb.php?page=3&mode=doc&k=2742
leads to #location

Posted: Thu Apr 16, 2009 5:05 pm

No, no, you don't need the $pos=@{postion} syntax. The $local=@varname syntax works fine. So let's not get everyone confused on this.

I tried the original script, and there does seem to be a nasty compiler bug in there somewhere. The $position=@position is actually working, but it is causing the following line to be parsed incorrectly if it isn't a command. For example, if you move the "stand" and "~chant %params" *after* the #EXECUTE line, then it works correctly.

The correct *syntax* for your script should be this:

Posted: Thu Apr 16, 2009 5:54 pm

Whoops! My mistake about the @{position} bit, then.

I know I was thinking of something else where you HAD to use @{variable} but now I can't remember it for the life of me.

To be honest, though, he still has no need to use a local variable, I'd imagine, since the global is already defined and is being referenced here anyway. *shrug*

Sorry for the incorrect information, wrym. :P

Charneus

Posted: Thu Apr 16, 2009 6:01 pm

I have narrowed this down to the actual #LOCAL command. Here is the smallest script that shows the problem:

Posted: Thu Apr 16, 2009 6:49 pm

Posted: Thu Apr 16, 2009 6:51 pm

Whoho, I'm not crazy, and WEEE! more obscure bug fixes!

Thanks for the help.

Posted: Thu Apr 16, 2009 8:03 pm

Wow, this one was really obscure and hard to find.

Turns out there were TWO bugs with this. The first bug was with the #LOCAL command as I indicated above. The command wasn't getting closed in the parser, so when it got to the next line, it still thought it was parsing local variable names.

However, after I fixed this I was still having trouble with the ~chant stuff. Turns out that when sending text to the MUD without the #SEND command (as when just saying "stand" on a line by itself), it also wasn't resetting one of the internal variables. So it considered the next line a continuation if it didn't start with a command or text. The ~ was messing this up. And rather than kludging it, I found the place were the end-of-line wasn't resetting the "send text" state and fixed that.

So now it all works. These obscure errors could definitely be causing some weird problems in scripts that send commands to the MUD without the #SEND command, so I'm glad we got it tracked down.

Just goes to show that when you have something that just doesn't seem to be working correctly, rather than look for weird workarounds, like putting \ in front of the text instead of ~ you should definitely report it to make sure it's not another strange bug.

Anyway, WOOT it's fixed now. Not what I was planning to work on today, but I'm glad I did.