Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD Beta Forum Goto page 1, 2  Next
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Thu Apr 13, 2006 2:09 am   

Changes to %1..%99 parameter variables
 
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:
Code:
#TRIGGER {Zugg tells you '(*)'} {#VAR tell %1}

OK, now let's look at how zMUD handles this. Imagine the line from the MUD:

Zugg tells you 'hi;#KILLALL'

Now, zMUD replaces %1 with it's substring text and you get the following script executing:

#VAR tell hi;#KILLALL

To prevent this kind of abuse, zMUD does all sorts of tricks in not matching the special characters like ;. In old versions, this trigger simply wouldn't fire. In newer versions, the * matches the special characters, but the result is "quoted" so that you get:

#VAR tell hi~;#KILLALL

instead. This is a kludge.

Also, consider this other case:

Zugg tells you 'hi test'

This causes the following script to be executed:

#VAR tell hi test

which probably isn't what you wanted. This assigned the value "hi" to @tell and makes "test" the default value of the variable.

The common way to get around this in zMUD is to put {} around the %1 in the trigger:

#VAR tell {%1}

so that spaces in %1 don't mess things up.

What a mess. CMUD fixes this by parsing %1..%99 as normal variables. The text isn't substituted until the variable is referenced. So, in the above examples, the "hi test" text is substituted when the variable assignment is actually executed, so the entire "hi test" goes into the value.

In CMUD, it's really just like using normal variables:

#VAR tell @varname

where @varname has the value "hi test" in the above example. This also means that #IF commands get a bit easier. In zMUD, it was common to see trigger commands like this:

#IF ({%1}={heal}) {cast heal}

In CMUD you don't need all of this crap. You can simply do:

#IF (%1="heal") {cast heal}

and it will work as expected no matter whether there are spaces in %1 or not. NOTE: The above zMUD syntax will still work in CMUD, but see (1) below.

This is a much more natural way to handle %1..%99 variables. But this change will cause several things in existing scripts to break:

1) In zMUD, you can put %1..%99 in quotes and they still get expanded. So, you can do: #VAR tell "%1" as an alternative to using {%1} and it works. In CMUD this won't work. Variables within quotes are not expanded, and in CMUD, %1 is a normal variable. So "%1" remains a literal string and is not expanded. This is more consistent, but might cause problems in existing zMUD scripts.

2) If you are relying upon %1 being expanded before the script is parsed in order to create runtime aliases or scripts "on the fly" then those scripts won't work anymore. You will need to explicitly call the #EXEC or %exec commands to execute the value of a variable as a script.

If anyone can think of anything else that would break as a result of this change, let me know. I think this is another example of fixing a "wierdness" in zMUD, but I'm always interested in discussion.
Reply with quote
Rainchild
Wizard


Joined: 10 Oct 2000
Posts: 1551
Location: Australia

PostPosted: Thu Apr 13, 2006 3:28 am   
 
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?
Reply with quote
slicertool
Magician


Joined: 09 Oct 2003
Posts: 459
Location: USA

PostPosted: Thu Apr 13, 2006 8:35 am   
 
to quote a whiny golden robot: 'Thank the Maker!'
_________________
Ichthus on SWmud: http://www.swmud.org/
Reply with quote
Vijilante
SubAdmin


Joined: 18 Nov 2001
Posts: 5182

PostPosted: Thu Apr 13, 2006 9:04 am   
 
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.
_________________
The only good questions are the ones we have never answered before.
Search the Forums
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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:
Code:
a="100 coins"
#IF (@a =~ "(%d) coins") {split %pat(1)}

would display "split 100"

In zMUD you could use "split %1" in the command. But in CMUD, the %1..%99 refer to the arguments passed to a script. This is actually very similar to how it was implemented already in zMUD, but zMUD had a "kludge" that whenever you specified %1..%99 it checked the previous subpattern list and used that instead of the script arguments. This is why you needed %%1 to refer to the script arguments in these cases.

This was a bad "overload" of the %1..%99 and I think just using a new function like %pat works better.

The nice side effect of this is that you don't need to try and combine everything into a single expression. The =~ operator actually returns the position of the match, just like the %match function. In fact, they are implemented the same way. So now you can do stuff like:

Code:
a="You got 100 coins"
pos = (@a =~ "(%d) coins")   // sets @pos to 9, which is the position of the match
coins = %pat(1)  // retrieve the number of coins


This will also work with the %match and %regex functions. Instead of specifying variable names in the optional 3rd argument of these functions, you can just use %pat in later commands.

However, keep in mind that CMUD only maintains the *last* list of matching subpatterns. So if you do a (var =~ pattern) and then use %regex, then %pat will refer to the %regex and the results from the =~ expression are lost.
Reply with quote
Larkin
Wizard


Joined: 25 Mar 2003
Posts: 1113
Location: USA

PostPosted: Thu Apr 13, 2006 8:08 pm   
 
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.

Code:
#ALIAS test1 {#loop 3 {#say test1 %i;test2 blah %i}}
#ALIAS test2 {#loop 2 {#say test2 %i}}


Calling "test1 ha ha" gives the output

Code:
test1 1
test2 1 blah 1 ha ha
test2 2 blah 1 ha ha
test1 2
test2 1 blah 2 ha ha
test2 2 blah 2 ha ha
test1 3
test2 1 blah 3 ha ha
test2 2 blah 3 ha ha


It actually echoes the "ha ha" I passed into it because I never accessed the parameters. If I add something to display or "noop" the %-1, it omits the "ha ha" from the output lines. Will this side effect is going to change in CMUD? I'm also curious as to the reasoning behind why it is this way in zMUD.
Reply with quote
Vijilante
SubAdmin


Joined: 18 Nov 2001
Posts: 5182

PostPosted: Thu Apr 13, 2006 9:08 pm   
 
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.
_________________
The only good questions are the ones we have never answered before.
Search the Forums
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
wwwfisher
Beginner


Joined: 03 Apr 2006
Posts: 12

PostPosted: Fri Apr 14, 2006 5:43 am   
 
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
Reply with quote
Larkin
Wizard


Joined: 25 Mar 2003
Posts: 1113
Location: USA

PostPosted: Fri Apr 14, 2006 11:28 am   
 
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.
Reply with quote
gamma_ray
Magician


Joined: 17 Apr 2005
Posts: 496

PostPosted: Fri Apr 14, 2006 2:49 pm   
 
What about referencing variables based %1, %2, etc.? For example:

Code:

#ONINPUT "auto.fill" {^make (\d*) (.+)$} {
  #for {@{%t2}} {outr %t1 %i}
  } "" {regex}


The idea for that one is that you have several items which you can make and the only difference in making them is the ingredients which go into them. So the quick way is to set up an alias-trigger like the one above and then use vars lists for the ingredients, and the trigger just does a set of actions for each ingredient based on the list which is specified when you call it.

So, "make 3 health" would do "outr 3 %i" for each item in @health.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
Vorax
Apprentice


Joined: 29 Jun 2001
Posts: 198
Location: USA

PostPosted: Sat Apr 15, 2006 9:27 pm   
 
Quote:
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.

Could we have an advanced alias option to dismiss all unused parameters passed to an alias? With an option like that Larkin's output would look more like this:
Code:
test1 1
test2 1 blah 1
test2 2 blah 1
test1 2
test2 1 blah 2
test2 2 blah 2
test1 3
test2 1 blah 3
test2 2 blah 3
Reply with quote
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1269

PostPosted: Sat Apr 15, 2006 9:46 pm   
 
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 ^((.+))>
Code:
#VAR Prompt {"%literal( %1)">}
#IF (%left( %line, 1) = "(") {#NOOP Prompt already subbed.} {
  #IF (%roomdesc = "" AND %maplocked = 0 AND @AssumeAllRoomsHaveDescs = 1) {#LOOK}
  }
The } after #LOOK is what the Syntax Checker flags up.

This trigger value shows a Syntax error on the 2nd % character:
Code:
#if (%lower(@target) =~ %lower(%2)) {#echo Your target may have recited a scroll!}

This alias (called removeindexfromarray) shows a Syntax error on the final parenthesis:
Code:
#noop %arrset(%1,6,)

This command shows a Syntax error on the first close parenthesis:
Code:
#IF (%regex( @ActiveDoor, exit <@LastDir>)) {} {}

All the #'s and ; in this echo show Syntax Error despite it being within {} and even with me adding %literal around it:
Code:
#ECHO {%literal(Mazush: Oropher, #1 warlord (storeported tho);Pallnit, #1 warlord;Bahr, #1 warlord;Aryon, #1 warlord;Mazush, #1 warlord;Darech, warlord (#7 max);Taloth, warlord (#5 max);Mahz, warlord (#3 max);(estimaded positions);+ Some random legends (Argonui Farad Torgak Smrtici Fjanten Korzak);At most had 3 warlords at list at one time (#1 #7 whitie #3 darkie i believe).;All chars warlorded with ME leading 95% of time.)}

I know I could escape all of these special characters in the last example, but I'd rather not bother. Maybe an %escape() function would be useful to put the escape character in front all special characters. That echo was generated by an alias I have to make player notes.
Reply with quote
Vijilante
SubAdmin


Joined: 18 Nov 2001
Posts: 5182

PostPosted: Sun Apr 16, 2006 2:16 am   
 
The only one I can find an answer to is the last one. Use the right encapsulating delimeter and everything becomes happy.
Code:
#ECHO "Mazush: Oropher, #1 warlord (storeported tho);Pallnit, #1 warlord;Bahr, #1 warlord;Aryon, #1 warlord;Mazush, #1 warlord;Darech, warlord (#7 max);Taloth, warlord (#5 max);Mahz, warlord (#3 max);(estimaded positions);+ Some random legends (Argonui Farad Torgak Smrtici Fjanten Korzak);At most had 3 warlords at list at one time (#1 #7 whitie #3 darkie i believe).;All chars warlorded with ME leading 95% of time."

_________________
The only good questions are the ones we have never answered before.
Search the Forums
Reply with quote
MattLofton
GURU


Joined: 23 Dec 2000
Posts: 4834
Location: USA

PostPosted: Sun Apr 16, 2006 3:28 am   
 
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.
_________________
EDIT: I didn't like my old signature

Last edited by MattLofton on Sun Apr 16, 2006 3:33 am; edited 1 time in total
Reply with quote
edb6377
Magician


Joined: 29 Nov 2005
Posts: 482

PostPosted: Sun Apr 16, 2006 3:31 am   
 
Code:

#VAR Prompt {"%literal( %1)">}
#IF (%left( %line, 1) = "(") {#NOOP Prompt already subbed.} {
  #IF (%roomdesc = "" AND %maplocked = 0 AND @AssumeAllRoomsHaveDescs = 1) {#LOOK}
  }


This one here is one he needs to look at.. It appears it thinks #LOOK is looking for another piece of itself. I dont use #LOOK for anything personally not even what you are doing with it as it would appear

The rest of these are fixable although without the proper script its hard to tell if they are exact. I didnt do the last one cause it appears he already got it
Code:

#IF (%regex( @ActiveDoor, exit ~<@LastDir~>)) {} {}


Code:

#noop %arrset(%1,6,(MISSING STRING))


Code:

#if ({%lower(@target) =~ %lower(%2)}) {#echo Your target may have recited a scroll!}
_________________
Confucious say "Bugs in Programs need Hammer"
Reply with quote
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1269

PostPosted: Mon Apr 17, 2006 12:32 am   
 
Quote:
Use the right encapsulating delimeter and everything becomes happy.

Well I was using the encapsulating delimeter specified in the help file for #ECHO: curly braces. I didn't know one could use double quotes.

Code:
#IF (%regex( exit south, exit <@LastDir>)) {} {}

The <> around @LastDir was actually to force expansion of the variable and was not (and is not) interpreted literally. In fact it appears that is not, or is no longer, needed in my version of zMUD with the %regex function. However it IS still needed in %subregex, which I have as the action if that #IF statement is true. If I take out the <>, it doesn't match, so it can't be expanding the variable without it. I have tested this with:
Code:
#echo %subregex( exit south, exit <@LastDir>, "exit @OppDir")

This works fine with the <> in, but if I remove it, no substitution occurs when it should do. Perhaps this is a bug.

The %arrset() function, according to the help file, takes 3 arguments and none are marked as optional - that's why I had a trailing comma. I must not have tested it without - I have now, and it works. There should really be a function for this though like %arraypop, %arrayremove, (and while we are at it, %arrayput), etc.
Code:
#if ({%lower(@target) =~ %lower(%2)}) {#echo Your target may have recited a scroll!}

Thanks! That works - I didn't know that was valid syntax.

Thanks for all your help. It does look like some help file improvements are possible though. Wink
Reply with quote
edb6377
Magician


Joined: 29 Nov 2005
Posts: 482

PostPosted: Mon Apr 17, 2006 5:32 am   
 
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
_________________
Confucious say "Bugs in Programs need Hammer"
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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:
Code:
#VAR Prompt {"%literal( %1)">}
#IF (%left( %line, 1) = "(") {#NOOP Prompt already subbed.} {
  #IF (%roomdesc = "" AND %maplocked = 0 AND @AssumeAllRoomsHaveDescs = 1) {#LOOK}
  }

That first line is a mess. You've got %literal within double-quotes. Remember that in CMUD, variables and functions are not expanded within quotes. Double-quotes are used to represent literal strings. So, your first line will assign the value %literal( %1)> to @Prompt and will not execute the %literal function, nor will the %1 argument get expanded. The correct way to do this in CMUD is simply:
Code:
#VAR Prompt {%1">"}

Notice that I've put quotes around the literal text that I want to be treated as a string, but left %1 outside of the quotes so that it gets expanded. And with the way %1 is handled in CMUD, you don't need the %literal function call at all.

As someone mentioned, zMUD seems to have a problem with the #LOOK command. In zMUD, the argument for #LOOK is required. If you do the F1 help on the #LOOK command you will see that it requires the command to send to the MUD. So the correct command is "#LOOK look" in zMUD.

In your second example, it's the %2 within %lower that causes problems in zMUD and this works fine in CMUD.

In your third example, as people have already mentioned, you can't have a dangling comma at the end with no argument given. Just get rid of the comma before the closing parenthesis. The dangling comma will still be an error in CMUD.

In your next example, you should start to phase-out the use of <> and [] for immediate expansion or evaluation. In 99% of the cases where these are used, you no longer need then in CMUD and using them will just cause more problems that it solves. Again, it's important to remember double-quotes for literal strings, and to use normal {} braces for strings that you want variables expanded within. So the correct CMUD code for this is:
Code:
#IF (%regex( @ActiveDoor, {exit @LastDir})) {} {}
#IF (%regex( @ActiveDoor, "exit "@LastDir)) {} {}

Either syntax will work. In the first case, putting {} around the second argument tells CMUD to treat it as a string and expand any variables. In the second case, it uses implicit concat to combine the "exit " string and the @LastDir result.

Again, start thinking of {} as normal string quotes where variable expansion is allowed. PHP programmers should be used to this. In PHP, single quotes are used for literal strings, and double-quotes are used for strings with variable expansion allowed. In CMUD, double-quotes are used for literal strings and {} are used for strings with variable expansion allowed.

In your last example, just putting " double-quotes around it and getting rid of the %literal and {} is what you want. Again, it's a literal string with no variables that you want to be sent to the MUD verbatim. So just doing #ECHO "Mazush: Oropher, #1 warlord..." is all you need in CMUD.

Let's please try to keep this thread focused on CMUD. If you want to give Seb more advice on how to get his scripts working in existing zMUD, please create a new post over in the zMUD Discussion Forum.
Reply with quote
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1269

PostPosted: Mon Apr 17, 2006 10:44 pm   
 
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:
Code:
{"%literal( %1)">}
in order for zMUD to ignore zMUD special characters in my MUD prompt when I was assigning to a variable.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
edb6377
Magician


Joined: 29 Nov 2005
Posts: 482

PostPosted: Tue Apr 18, 2006 3:33 pm   
 
dont worry zugg we will break it for you :)
_________________
Confucious say "Bugs in Programs need Hammer"
Reply with quote
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1269

PostPosted: Tue Apr 18, 2006 3:35 pm   
 
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.
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD Beta Forum All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

© 2009 Zugg Software. Hosted by Wolfpaw.net