Zugg Software :: View topic

Posted: Thu Apr 13, 2006 2:09 am

The %1..%99 parameter variables are used for 2 things:

1) In triggers, they refer to the matching substring text
2) In variables and aliases, they refer to arguments passed to the function or alias.

In zMUD, the %1..%99 are replaced with their corresponding string values *before* any parsing is done.

In CMUD, the %1..%99 are parsed as normal variable references and replaced with their value at execution time.

This could be a big change for some scripts if you are doing something really tricky and using %1..%99 to generate code. However, the CMUD method is safer and more easily understood.

Consider the following trigger:

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

I'm in full support of this change. I'm fairly sure I use the {%1} syntax for my stuff so it shouldn't make a difference to me at least.

Are the %variables going to be different types based on the (%w) (%d) and so on?

Eg if you have a trigger to match numeric paramaters, the %1 becomes an integer if you have a trigger to match a word or number of words it gets assigned to a string?

Or will they all be treated as strings? (which is probably still fine, because you can %eval(%1+%2) and get numeric results if they're both numbers, right?

Magician Joined: 09 Oct 2003 Posts: 459 Location: USA

to quote a whiny golden robot: 'Thank the Maker!'

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I like the change even though it will heavily affect my scripts. It is a good incentive for me to tweak around with all my stuff. It also sound like this will eliminate the early expansion issue, so I wonder how references such as %%1 will be affected. The only thing I can really think of that requires that syntax was the pattern matching operator ~=, which should simply be removed. Other uses of %%n should be easily correctable since they were generally use in various commands where the parameter type will prevent normal variable expansion. So it seems like an excellent improvment, of course the bonus is the savings in support questions. I will gladly exchange having to correct all my scripts to not have to tell 50 more new users how to add delimeters.

Posted: Thu Apr 13, 2006 4:32 pm

Yeah, I'm actually still working with the %%1 syntax to determine what to do about it.

In case people are interested, what I'm doing right now is going through my master test script and getting it working with the new compiler. This script automatically tests mosts parts of the parser, and tests each and every %function. I'm also trying to expand it to test the commands that are possible to test in an automatted script.

This test script has been developed for zMUD over the years and contains a bunch of wierd syntaxes. Everytime I had a wierd parsing problem in zMUD I would add a test case to this script. So it has some pretty wierd stuff in it. It probably doesn't cover everything that people are already doing in zMUD, but it should cover most of it. I had a few things like "%1" that I've had to change. Everytime I find something that requires a change like this, I make a post to the forums to tell people about the change.

I'm hoping to finish with the existing test script today and then add the command testing.

But back to the %%1 syntax: I'm hoping to get rid of this.

Posted: Thu Apr 13, 2006 5:16 pm

OK, here is what I'm proposing for using %1 with the =~ pattern matching:

CMUD will have a new function called %pat which returns the specified pattern from the previous =~ pattern matching. So, for example:

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

I have seen a strange side effect in zMUD, which I believe is related to the parsing of the arguments. It may be a desired behavior by the definition within zMUD, but it can wreak havoc on my scripts because I don't expect this sort of behavior.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I doubt Zugg will change that one. It was done intentionally so you could do something like:
#ALIAS give {~give %1 to}
Then typing 'give bag10247 larkin' would produce the correct result of 'give bag10247 to larkin'.

The idea being that unexpected parameters should have something done with them, even if all it does it let the user know there is a problem. Believe it or not it is documented. Albeit where no one can find it...under the %param function and also I think %numparam.

Posted: Thu Apr 13, 2006 11:35 pm

Yep, Vijilante is correct. Although I'm open to discussion about a better way to handle this. I think it's a useful feature, but I agree that the current implementation falls into the "wierd" category. Also, I have to admit that the new compiler doesn't yet handle this either because it's "wierd". So it's on the list of things I'm still working on.

You could always add a %-2 to the alias to force it to append everything from the second argument on. Although this %-2 syntax I think is also pretty wierd (and also not yet handled in CMUD).

Makes me wonder some days how all of this wierd stuff got added to zMUD in the first place. That old parser is just kludged and kludged with all sorts of wierd features thrown into it.

Beginner Joined: 03 Apr 2006 Posts: 12

great upgrade!

Would commands/functions which extract values out from variable/item in the same way(transfer the value as it is without parsing)?
Rolling Eyes

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

Yes, Vijilante, I had guessed that was why it works this way. However, if I want the arguments, I use the %-1. I expect that if I don't use %-1, I don't get the arguments tacked on. To me, this makes a whole lot more sense, and it gives me better control over the behavior. The way it is now, I have to make my own kludge to get around this kludge, and it's just not pretty or efficient.

Magician Joined: 17 Apr 2005 Posts: 496

What about referencing variables based %1, %2, etc.? For example:

Posted: Fri Apr 14, 2006 4:50 pm

gamma_ray, using %1..%99 in triggers still works just as it did in zMUD. Changing that would break most all triggers and I'm not about to do something that incompatible.

Apprentice Joined: 29 Jun 2001 Posts: 198 Location: USA

Wizard Joined: 14 Aug 2004 Posts: 1269

I have a few zMUD scrpts that work perfectly but are flagged as having Syntax Errors. I tried to fix them so they weren't Syntax Errrors, but failed and gave up. Now I'm afraid they might not work (or compile) in CMUD, so I'll post extracts that fail Syntax Checking:
This matches my prompt (and is set to trigger on prompt): trigger (Perl regular expression) on ^((.+))>

SubAdmin Joined: 18 Nov 2001 Posts: 5182

The only one I can find an answer to is the last one. Use the right encapsulating delimeter and everything becomes happy.

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

1) ZMud has a bit of a problem with one-line code-blocks arranged like a multi-line one. The code SHOULD work fine now and WILL work without syntax errors due to the reworked pretty-printer in CMud (based on what Zugg's told us so far, so actual results might be different).

2)probably your use of =~ or perhaps something else not shown.

3)can't end a function with a blank argument. Either supply a value, or remove the comma.

4)In this case, <> is seen as an MXP tag. MXP tags--even when used in #SUB and #MXP--must be quoted in some way, whether that be with a tilde (~) or actual quotes ("<"). Which one you use is dependant on function/command behavior.

Magician Joined: 29 Nov 2005 Posts: 482

Wizard Joined: 14 Aug 2004 Posts: 1269

Magician Joined: 29 Nov 2005 Posts: 482

well one of the >< is used for a special MAP DIR character i think its >

so you might try unchecking that as well if thats not your intention. as to expansion you might also check the allow to expand in your preferences under parsing i think it is.

Just a note though its always better to try to have a coded idea to test. what you will find is the "SCRIPT PARSER" that checks the content isnt always perfect. It is looking for a specific set of rules. This is why usually things like QUOTE chars can fix problems or bracing things the right way to keep them together. like that 3rd example. Play around with it you will get it. Without code its always harder to figure out what you are trying to do for sure

Posted: Mon Apr 17, 2006 5:13 pm

First, I should mention that the parser/compiler in CMUD is greately improved over the syntax checker in zMUD. That is actually what is taking all of the time to get CMUD released right now. Things that could be ignored by the syntax checker need to be fixed in order to compile/execute scripts. Kludges that were made to the syntax checker in zMUD to deal with stuff like COM had to be fixed in CMUD.

So, a) a lot of stuff that gives a syntax error in zMUD is fixed in CMUD. and b) you need to be careful adding extra quotes and delimiters just to make the syntax checker happy since that might cause your script to not work properly in CMUD.

For example, take a look at your first example:

Wizard Joined: 14 Aug 2004 Posts: 1269

Thanks Zugg. Actually I was concerned with my scripts working in CMUD - even if they fail the Syntax checker, they do work in zMUD - in fact I had to go to some lengths, e.g. this syntax:

Posted: Tue Apr 18, 2006 1:06 am

Well, it's a valid concern. In a lot of ways, adding a bunch of wierd stuff in zMUD to get it to pass the syntax checker could actually cause more trouble down the line with CMUD.

The normal zMUD parser is *very* forgiving. In many ways the old zMUD parser is very simplistic, so it ignores a bunch of extra delimiters in a lot of cases, and it treats *everything* as a string. The CMUD parser is more formal about the syntax and the data types. If I don't specifically add a certain syntax "rule" to the new parser, then it doesn't work. Where as with the old zMUD parser, instead of telling it each "rule" it was more of a string matcher and would just throw out stuff it didn't understand.

Let me say this another way: For example, your {"%literal(%1)">} is perfectly valid syntax, so the syntax checker doesn't complain. Since zMUD treats everything as a string and strips extra delimeters (like the {} and the quotes), zMUD is able to convert this properly. But because CMUD is more picky about delimeters like {} and " quotes, you get the wrong result in CMUD in this case.

Using the correct CMUD syntax of {%literal(%1)">"} also works in zMUD (or should...I'd need to see the specific special characters that cause it to fail to help more), but since this syntax follows the correct CMUD syntax rules, it also works in CMUD.

This is going to be the biggest headache for people converting to CMUD. Stuff that was added to zMUD just to "make it work" might end up getting in the way. Hopefully it will be worthwhile for people to fix these kind of cases to end up with more reliable (and faster) scripts in CMUD.

Originally, anything that failed the syntax checker in zMUD wouldn't work in CMUD. But I've fixed so many problems with the syntax checker that all bets are off now. In fact, this will probably end up causing a pretty rocky early beta testing phase since I'm not very confident that the "fixes" to the parser won't generate more problems then it fixes. So it will probably take a few beta versions to get this new parser working well. It's hard for me to test all possible syntax cases myself.

Magician Joined: 29 Nov 2005 Posts: 482

dont worry zugg we will break it for you :)

Wizard Joined: 14 Aug 2004 Posts: 1269

It's possible to have a ~ (and many other symbols, like #:<.) in my prompt right before the > (and/or in an earlier position), and I didn't have double quotes around the >. I'm pretty sure this combination caused my workaround on an earlier version of zMUD. I certainly can't reproduce it right now though, so perhaps it is fixed on newer zMUD versions.