Zugg Software :: View topic

Wizard Joined: 14 Aug 2004 Posts: 1269

The following (first one anyway) worked fine on zMUD and passes the zMUD syntax check:

Wizard Joined: 14 Aug 2004 Posts: 1269

Another one, simplified to:
#if (* = %6) {#echo test}
gives:
Error compiling script:
unmatched parenthesis

zMUD treated the "*" as a string. In CMUD it looks like I need to put quotes around the * to get the script to compile.

Posted: Tue Nov 07, 2006 12:19 am

%2 in CMUD should reliably be set as the whole of whatever is passed to it even if it contains spaces.

In any case you shouldn't create a variable with a space in the name so even if that was in a trigger or an alias you would need to check %2 before passing it to #var.

Wizard Joined: 14 Aug 2004 Posts: 1269

That is exactly what I mean - it's not "safe" - I would have to check %2 for spaces. If I use the = syntax for setting the variable, and %2 contains a space, at least I might get the first word of %2 echoed to the mud and know there was a problem. Anyway, this code is actually in an alias, so I'm not too concerned about safety.

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

According to what I've seen Zugg say about the new CMUD parser, using something like #VAR %2 {the value here} should work even if the %2 contains spaces or other special characters. It's not pre-parsed the way it was in zMUD, and should have implicit quotations, you might say. Try it and see? (It worked for me.)

Posted: Tue Nov 07, 2006 10:57 am

You reliably created and was able to use a variable with a space in its name?

Posted: Tue Nov 07, 2006 9:03 pm

With the syntax:

#VAR %2 value

CMUD thinks you are trying to assign something to the %2 variable, which isn't allowed since %1..%99 are read-only arguments. It sounds like what you are trying to do is use %2 as the name of a variable and you want to perform an indirect assignment to that. So think about how you would do this if the name of a variable was in a normal variable. For example, if a=abc and you wanted to assign a value indirectly to a variable @abc, then you would use the syntax:

#VAR @{a} value

So, to use %2 as the name of the variable, you would use the syntax:

#VAR @{%2} value

Now, I just tried this and even though the @{a} syntax worked, the @{%2} doesn't seem to be working, so that's a bug that I'll add to the bug list. But that shows the correct syntax for indirect assignment.

The a=value syntax cannot be used for indirect assignment. You must use the #VAR command for advanced assignments like this.

Also, variables names cannot contain spaces. If you end up with a space in a variable name, then you will probably have all sorts of problems using it reliably. So just don't do it. Replace spaces with the _ character using %replace.

An alternate way to do stuff like this is via #EXEC:

#EXEC {%2 = @%1}

No need to use %expand. Also note that while the @%1 syntax works, it's better to use the standard @{%1} syntax to make it clear that you are performing an indirect operation.

Wizard Joined: 14 Aug 2004 Posts: 1269

OK, thanks Zugg. Indeed, I believe %2 is a variable name. I've just realised looking at this alias in zMUD (for which the above is only a part of the code), that I'm not actually using this alias anywhere and replaced it with a function that I created with the same name.

What about this:
#if (* = %6) {#echo test}
Should it be supported? Should a * in this position be assumed to be a string?

Posted: Wed Nov 08, 2006 12:00 am

If you are testing %6 against the string "*" then you'd better put quotes around *. That's the kind of stuff that CMUD is going to be picky about that you need to be more careful with.

Posted: Wed Nov 08, 2006 9:53 am

Am I being thick? I'm sure in zMUD using trigger matches was fine for creating variables.

#TRIGGER {^(%w) is an (%w).$} {#VAR %1 %2}

So you get a line "Taz is an idiot." and it would set the variable Taz with a value of idiot.

Or are we talking about something entirely different here?

Wizard Joined: 14 Aug 2004 Posts: 1269

Zugg didn't say that that didn't work in zMUD. He said that it wouldn't work in CMUD as %1 is a read-only parameter in CMUD.

Edit: However, I've just tried your example, and it does work in CMUD!

Posted: Wed Nov 08, 2006 5:59 pm

Yeah, I looked into the code and found that the #VAR command *does* implement the %1 functionality. I must have added it and forgotten about it. However, %1=%2 still doesn't work, and probably won't be supported in CMUD since that's more of a parser syntax issue.

Anyway, thanks for correcting me on the #VAR command. I still think it looks a bit strange, and it probably won't work with named arguments. But I'll try not to mess with it and break it for zMUD compatibility.

Magician Joined: 13 Oct 2000 Posts: 463

I think CMud needs a 'quirks mode' like browsers have. Essentially two parsing engines... one completely CLEAN, old bad habits get the smackdown... and one that is sloppy, with zMud style quirks allowed.

More work now, but 5 years down the road you could 'phase out' the quirks and people would have had a ton of time to get used to the right way of doing it. And then you'd never have to maintain zMud compatibility again, and your burden would be reduced... 5 years in the future. In return for more pain now.

I dunno if it's worth the tradeoff, but it is a thought. :-)

Posted: Wed Nov 08, 2006 8:58 pm

No, absolutely not, sorry. We had this discussion early in the beta testing and I'm not going to rehash it again. If this was just a simple upgrade to zMUD, then obviously all of the old quirks would still work. But this is a new product and it's time to stop kludging it with stupid quirks just for compatibility. People are going to need to fix their scripts if they want the benefits of CMUD. If someone isn't willing to do this to get faster and better scripts, then they should just stick with zMUD (or use some other client).

The fact that Microsoft had a "quirks mode" just to support sloppy web site design was a bad idea. It just caused more and more bad web sites to proliferate. The Mozilla people did the correct thing and focused more on implementing standards and not quirks, and the popularity of Firefox has caused web designers to start building better and more standard web pages.

This is the time *now* to deal with it. I can't just phase it out later. People would complain no matter when it was changed. But right now, people switching from zMUD to CMUD are expecting differences and are more willing to make changes then they would be later. There is also no way to support two parsing engines with the new features. Then you'd get someone complaining that "local variables aren't working" when the problem is that they are using the old parsing engine.

No, if people want the old parsing engine, then they still have zMUD. People who want the new features and improvements of CMUD have to fix their scripts. Things like the Compatibility Report will help with that.