|
The Raven Magician
Joined: 13 Oct 2000 Posts: 463
|
Posted: Tue Nov 07, 2006 9:37 pm
[1.13] %eval does not evaluate mathematical expressions. |
Reproduce:
Start a blank mud. No need to connect. Put this code into an alias:
#VAR Heading {90}
#VAR TurnStep {15}
#ECHO {Heading: @Heading Turn: @TurnStep ~%eval(((@Heading-1)/@TurnStep)*@TurnStep) = %eval(((@Heading-1)/@TurnStep)*@TurnStep)}
Result:
Heading: 90 Turn: 15 %eval(((90-1)/15)*15) = 0
Expected Result:
Heading: 90 Turn: 15 %eval(((90-1)/15)*15) = 75
If I execute: #ECHO %eval(((90-1)/15)*15) it displays the proper result, 75. But the %eval using variables fails. This confuses me, because simpler evals (like when I tried to make simpler example code to paste here) work fine using variables. For example, this works:
#VAR A 3
#VAR B 2
#ECHO %eval(@A/@B)
(correctly displays result of '1')
Can you explain the reason for this? I can't... it makes no sense to me. |
|
|
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
Posted: Tue Nov 07, 2006 10:30 pm |
In CMUD, the {} characters act as " quotes except that they allow the expansion of variables and functions. So, when you do:
#VAR Heading {90}
you are assigning the STRING value "90" to the variable. I'll see if I can improve the auto-detection of variable types, but the correct syntax is:
#VAR Heading 90
#VAR TurnStep 15
#ECHO {Heading: @Heading Turn: @TurnStep ~%eval(((@Heading-1)/@TurnStep)*@TurnStep) = %eval(((@Heading-1)/@TurnStep)*@TurnStep)} |
|
|
|
The Raven Magician
Joined: 13 Oct 2000 Posts: 463
|
Posted: Wed Nov 08, 2006 12:23 am |
How do I specify the type of a variable explicitly, rather than implicitly via syntax quirks?
I'd like to be able to do something like:
#VAR A {30} Integer
#VAR B {0100} String |
|
|
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
Posted: Wed Nov 08, 2006 1:50 am |
Use the %vartype function to change the type within a script, or set the type in the settings editor interactively.
But the #VAR syntax is pretty simple. Using "" forces a literal string type (no expansion of variables within the quotes), using {} forces a string type with variable and function expansion allowed. Using () forces expression evaluation. Using nothing sets the variable to be auto-typed.
You can also use the %int or %float functions to force the type. For example:
#VAR a %float(1)
will make @a a floating-point 1.0 variable.
Think of it this way...the whole reason to use {} in zMUD was to enclose something that contained spaces so that zMUD wouldn't parse it as multiple arguments. Well, if something is going to have spaces in it, then it's a STRING value, right?
I think people just got into the bad habit of using {} all the time in zMUD even when it wasn't needed, and this has caused a lot of sloppy scripts.
There's no way to add the simply syntax that you mentioned since it wouldn't be compatible with the current #VAR syntax (with default values and class folders as the 3rd and 4th arguments of #VAR) |
|
|
|
The Raven Magician
Joined: 13 Oct 2000 Posts: 463
|
Posted: Wed Nov 08, 2006 6:42 pm |
I always use {}, but I wouldn't call it a sloppy habit... it was more a 'cover my ass' habit, just in case a parameter had spaces that I was not expecting. "Don't trust input" is the safe programmer's creed. :-)
Thanks for the syntax update. |
|
|
|
Seb Wizard
Joined: 14 Aug 2004 Posts: 1269
|
Posted: Wed Nov 08, 2006 11:38 pm |
Yes, I also had been converting my scripts to use {} in the #VAR syntax as I came across them because I had been getting strange classes appearing out of nowhere, which I believe were the result of occasional spaces in parameters that I was assigning to variables. Now I'm going to have to back through my settings and see if I need to remove the {}!
|
|
|
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
Posted: Wed Nov 08, 2006 11:58 pm |
Well, keep in mind that I said there *was* a bug here. The expression evaluator should know that when you are doing math operations like * and / and the arguments on the runtime stack are strings, then it should check to see if the strings can be autoconverted to numbers and then go ahead and execute. As I've said, I really want the new "typed variables" in CMUD to be mostly hidden and not cause these kinds of problems.
|
|
|
|
|
|