Zugg Software :: View topic

Posted: Tue Apr 11, 2006 11:03 pm

I've avoided having "typed" variables for a long time. But now I think it's starting to cause more complexity than simplicity.

For example, consider the following in zMUD:

Magician Joined: 29 Nov 2005 Posts: 482

I definatly would like to see a change here. I use a plethora of variable types in my scripting. As to a # command #vartype makes sense to me. I think this would vastly improve variable handling on my end. While you are messing with variables i had a note.

#VAR xyzpdq 2 --> Would create a new variable in root (if variable exists it updates it in its current class folder)
@xyzpdq = 2 --> This however creates a new variable in the root folder either way even if one does exist in another class folder.

Kind of annoying really. Just FYI

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

What about a #DIM or #DECLARE (not sure if they are currently used), but that's a pretty common syntax for defining a variable.

Magician Joined: 17 Oct 2001 Posts: 371 Location: USA

What about adding an parameter to the current #VAR command? If you want to change the type. The type would persist until that parameter is used again.

Magician Joined: 29 Nov 2005 Posts: 482

Posted: Wed Apr 12, 2006 12:52 am

As Belmyrddyn says just another parameter on an already existing command

#VA [variable] [value] [defaultval] [classname] [type]

Posted: Wed Apr 12, 2006 12:55 am

I think I'm leaning towards #VARTYPE too. In languages with things like DECLARE and DIM it is also typically allocating memory, which isn't done in this case. All we are doing is changing the variable type, so VARTYPE seems pretty clear.

Rainchild, as far as casting, I think you missed something in my example. It doesn't matter what the type of @hp or @maxhp are. What matters is the type of the @HpStr function. If @HpStr is set as an Integer type, then the compiler *evaluates* the function as a numeric function, so the / is interpreted as Integer Division regardless of @hp or @maxhp. If @hp is a string, then it is first converted to an integer before performing the division.

I've also decided to add *2* different "string" types. There is a "string (expanded)" type and a "string (literal)" type. In the above example with @HpStr, if the type is set to "String (expanded)" then it would return the string result "100/500" where each variable in HpStr is expanded. However, if the type of @HpStr is set to "String (literal)" then the result would be "@hp/@maxhp".

In other words, setting a variable to "String (literal)" prevents the dreaded variable expansion that zMUD is always doing. It means you don't need to use the %expand(var,1) syntax to expand a variable just once. A "String (literal)" is just a normal string value that is never messed with. I think this addition will really help a lot of people.

edb6377: We had another post in this forum about creating new variables. The #VAR command and the var=value syntax is really for changing the value of a variable, and you *want* this to search in other classes and packages (described in more detail in the other forum topic). What I'm doing in CMUD is adding a new command like #NEWVAR which creates a new variable in the current class. To create a variable in the root class, you would use the #NEWVAR ./varname syntax, also described in the other post.

Rainchild: Re: temporary variables. Yes, there are going to be temporary variables (called "Local" variables) in CMUD, but I'm not sure if it will be in the first beta yet.

Posted: Wed Apr 12, 2006 1:16 am

Is adding another parameter to #var not possible then?

Posted: Wed Apr 12, 2006 1:27 am

Well, I thought about adding another parameter to #VAR, and will still consider it. But it's already got so many, and setting the variable type would require you to also set the default value and class value (you can only omit optional arguments at the end of a command, and "type" would need to be added to the end of the argument list). This could cause some problems with people accidentally setting the default or class to something else when they really just wanted to change the type. Adding something like #VARTYPE seems like a cleaner solution.

What I might do is add something to the #NEWVAR command since this is brand new anyway. Seems like you'd most often want to set the type at the variable creation time anyway.

Posted: Wed Apr 12, 2006 1:42 am

Yes, that would be an issue, not the setting of default or class values, they can be sent blank fairly easily but I can imagine many people accidentally setting the wrong default or class when they meant to set the type just solely through forgetting to set blank default or class values. Wow that is a mouthful.

Now then thinking about that and programming you usually decide types at the time of declaration so making it a part of #NEWVAR seems very sensible and then of course for altering already existing variables that is where the #CAST/%cast() would come in much like in programming.

As you have already said #VAR is really for changing already existing variables and definitely will be in CMUD so although you might expect to be able to change the type using #VAR it's no big deal that we may have to adopt a new command/function to do so after all we need to start adopting a new way of thinking about #VAR.

Beginner Joined: 03 Apr 2006 Posts: 12

that's sound great!

as we are used to writing #var, #nvar or #vart is more preferable for the ab. of #newvar or #vartype.

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

If I have a trigger on my prompt and %1 is my hp and %2 is my max hp and I want to work out what percentage of health I'm at I would like to do something like (although I'd use a status bar or guage, but #SAY is for the example):

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

I know that novices will have some difficulties with variables types at first, but I'd rather they simply learn how from a mentor or by reading a help file than to teach them bad practices.

And, using an "AS" syntax is more VB-style than zMUD-style. It would be more natural to %cast(expression, type), though we already have %int, %float, etc, that do this same basic thing, right?

GURU Joined: 10 Oct 2000 Posts: 873 Location: USA

Posted: Wed Apr 12, 2006 5:55 pm

Rainchild: In your example, using %float is still the solution. As Larkin mentioned, we already have %int, %float, and %string to perform type "casts". Those will continue to be useful for temporary "on-the-fly" type conversions.

I also agree with Larkin that it's better to try and teach people the proper way of programming. It's always better and more efficient to to (@hp*100)/@maxhp (perform the multiplication first, then the division) since this avoids any floating point math. And it's good for novices to learn this, since it applies to any other programming they might do in the future. The problem with floating point is that you end up with all of those extra decimal places (like 56.66666666666...) and then end up having to use the annoying %format function to make stuff look right.

Tarn: In your example of #show @a/@b there are a couple of things going on here:

1) Look at the command and see what arguments it expects. The argument type expected is shown in the Command/Function wizard (press F1)
2) Next, the type of the variables is checked as needed for operations like + which are ambiguous. For an operation like / where only numbers make sense, any strings that can be converted to numbers are automatically converted.

For the command arguments, there are really only 3 major argument types: expression, string, commands. For expressions, they are evaluated as mathematical expressions. For string, any variable references are expanded and there can be a lot of implied concats. For commands, the arguments are compiled as a normal command script.

For the #show command, if you look at the F1 help you will see that it's argument is a "string" type. This means that variables are expanded. So, the code

GURU Joined: 10 Oct 2000 Posts: 873 Location: USA

Posted: Wed Apr 12, 2006 8:20 pm

In general, something like + (or () or {} or any other "special" character) is only a string when it is surrounded by double-quotes. That's a good rule of thumb that will keep you from getting into trouble.

However, with that said we probably need to talk about "implied concat" which has always been one of the trickiest things in zMUD, and which CMUD still handles.

"Implied Concat" is the concatenation of strings without using the explicit %concat function and often without even using quotes. This has been a "feature" in zMUD since the beginning and continues to be implemented in CMUD even though it can be tricky sometimes.

Implied Concat happens only when zMUD/CMUD is in string expansion mode. So, refering to the previous post, if the argument for a command is "string" or if you set the VARTYPE of a variable to "string (expansion)" then you are enabling Implied Concat.

Here is an example of Implied Concat:

GURU Joined: 10 Oct 2000 Posts: 873 Location: USA

Wanderer Joined: 01 Oct 2005 Posts: 54

Do these type of variables not work anymore with cmud?

Using 1.03 ATM
Like #TR {%1 MANA %2 HP %3} {%1.mana=%2}

Wizard Joined: 03 Mar 2001 Posts: 1127 Location: London

I don't think that's correct syntax for CMUD or zMUD, though may have worked in zMUD

Assuming they're numbers you're trying to capture, what you should have is
#TR {(%d) MANA (%d) HP (%d)} {%1.mana=%2}

Posted: Thu Jul 20, 2006 10:38 pm

It's the %1.mana that doesn't work yet in CMUD.