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
Zugg
MASTER


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

PostPosted: Mon Apr 03, 2006 4:35 pm   

Class path specifiers - change in CMUD
 
Along the theme of changing "wierdness" in zMUD with the new CMUD program, here is something else that I'm thinking of changing.

When you want to specify the full class path to a variable (or alias, etc), you use the / character and create something that looks like a full unix or dos file path. For example, if you have the class named "SubClass" within the main class named "Class1" and want to reference a varaible in the subclass, you can use the syntax:

#VAR /Class1/SubClass/varname value

OK, this is fine and logical. The problem comes in when using the . or .. to specify the root or parent path.

In zMUD, the use of . and / are mixed up. I remember having some discussion about this and people trying to convince me not to do it, but I don't rememeber any good reasons for doing this now. (maybe someone can find the original forum link for me).

So here are the proposed changes:

/varname

In zMUD, this refers to varname within the current class. In CMUD, this would refer to varname within the root class (package). This is a CHANGE in behavior.

./varname

In zMUD, this refers to varname within the root class. In CMUD, this would refer to varname within the current class. This is a CHANGE in behavior.

../varname

In both zMUD and CMUD this refers to varname within the parent class. This is unchanged.

Basically, these changes would make the class specifier the same as normal unix and dos filename paths. The parser doesn't care which way this is handled, but making it the same as normal paths would get rid of another "wierdness" in zMUD that is probably bugging people.

Comments?
Reply with quote
Guinn
Wizard


Joined: 03 Mar 2001
Posts: 1127
Location: London

PostPosted: Mon Apr 03, 2006 5:07 pm   
 
IMHO... make the change.

Another case where the positives for removing 'wierdness' and making cmud more standard will outweigh the problems with minor incompatibility for zmud scripts.
Reply with quote
Zugg
MASTER


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

PostPosted: Mon Apr 03, 2006 5:33 pm   
 
I'm also hoping that not very many people use this specific syntax. Also, it's something that I might be able to "auto-correct" during the import of old zMUD scripts.

The main use of /var in zMUD is to force it to create a new variable in the current class instead of just changing the value of an existing variable. To make this situation easier I'm also planning to add a new command called #NEWVAR.

#NEWVAR varname optional-value

would create a new variable with the name "varname" in the current class. You can still use the class path specifier to create the variable somewhere else if you want. But unlike the #VAR command, #NEWVAR isn't going to look for an existing variable and just modify it...it will force a new variable to be created.

This should help fix the other big problem in zMUD where you think that you are creating a new variable, but in fact are just modifying the value of another variable somewhere else. Since zMUD searches in all enabled classes for matching variables, sometimes you might not have any idea where the variable is that is getting modified.

Packages made this situation worse in CMUD. It was too easy to have conflicting variable names and accidentally modify a variable in another package with the same name. Using #NEWVAR should help ensure that the proper variables get created initially.

The way I think about this is like when using "new" in VBScript, or "dim" to initially "declare" or dimension the variables. This is something that would be done in the package initialization event to ensure that the proper variables for the package get created.

Anyway, I thought I should post this here since it's related to the current use of /varname in the #VAR command to force a local variable to be created.
Reply with quote
Rainchild
Wizard


Joined: 10 Oct 2000
Posts: 1551
Location: Australia

PostPosted: Wed Apr 05, 2006 12:08 am   
 
I would go with the change of syntax - try and get auto-correct to work.

With the package library you really are going to want variables to 'play nice'. So I really think you should change the way #VAR works to only check the current class and it's parent classes. If you want to modify something in a completely different class then you have to explicity specify it with a /path/directive.

So if we have the following classes and variables:

/zugg/hp
/zugg/mana
/rainchild/hp

and I have a script in /rainchild/hp-monitor/ which does a #VAR hp 123 it should process like this:

"Is there a variable 'hp' in /rainchild/hp-monitor?" No -> "Is there a variable 'hp' in /rainchild?" Yes -> Assign 123 to variable /rainchild/hp

now if I then do a #VAR mana 456 it should process like this:

"Is there a variable 'mana' in /rainchild/hp-monitor?" No -> "Is there a variable 'mana' in /rainchild?" No -> "Is there a variable 'mana' in /?" No -> Create and assign 456 to variable /rainchild/hp-monitor/mana

At no point in time should I assign or even see the variables 'hp' and 'mana' inside the /zugg class.

.... the same goes for expansion, if I do a #SHOW @hp it should process like this:

"Is there a variable 'hp' in /rainchild/hp-monitor?" No -> "Is there a variable 'hp' in /rainchild?" Yes -> #SHOW @/rainchild/hp (ie 123)

if I wanted to manipulate the variables in the /zugg class, I would have to explicity do that, eg #SHOW @/zugg/hp

===========================

I do see one potential issue is when you want to do a 'say my hp is @hp' from the command line, in theory I should have to specify 'say my hp is @/zugg/hp' but we all know nobody is going to want to type all that... I'm not really sure what's the best thing to do in this case. Obviously, you could do the recursive search, but then what happens if there's 3 variables all called 'hp'?

So, we probably need to discuss this mechanism a little, I'm leaning toward some method of a package saying "I define the following 'published' variables" and letting them be mapped/redirected by the user... for example, the user could tell both '/raincihld/hp' and '/zugg/hp' to be mapped to a single variable called /hitpoints... or they could tell /rainchild/hp to use /zugg/hp.

I feel that the command line should probably be in its own class too. Eg if I do a #VAR blah 123 on the command line, it should create the variable in /system/command_line or similar. You then map /zugg/hp and /rainchild/hp to /system/command_line/hp and can do your 'say my hp is @hp'.

I don't know if that's too complicated or not - but I think it's possibly more confusing to have 20 packages loaded, 8 of which have their own '@hp' variable, and then which one do you pick?
Reply with quote
Zugg
MASTER


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

PostPosted: Wed Apr 05, 2006 3:22 am   
 
Here is what CMUD currently does when you ask for a variable like @hp:

1) First, it checks the current class
2) Next, it starts checking the parent classes (assuming they are enabled).
3) Next, it looks anywhere in the current package for an enabled variable in an enabled class tree.
4) Finally, it looks in the top level of other packages.

So as it stands, only top-level variables in other packages can be modified without a class specifier. Otherwise, all variables changes stay within your own package.

In a sense, the top-level variables in a package *are* the published variables.

Stuff on the command line goes into the package specific to your MUD character. So, if you have put all of your important stuff into other packages, then the command line won't really effect the other packages (except for top-level variables).

When searching other packages for top-level variables, they are searched in the order that they are loaded. When searching elsewhere in the current package for an enabled variable, the search is based upon the "priority" value of the variable (every setting has a numeric priority now).

Allowing variables to be "remapped" by the user would be way too complicated.

Also, remember that this applies to other settings too, not just variables. So top-level aliases are "published" from other packages and become the main commands used to manipulate the package.

The exception to this is that a package can have an option to publish everything no matter what class it is in. For example, the main "Default Settings" package does this so that the macro keys in the /Default Settings/Keypad class can still be used without having to put them into the top level. It's possible that I might add this "Publish" option to class folders as well so that you can really control what gets published and what stays local. But that's how it currently is working.
Reply with quote
Kjata
GURU


Joined: 10 Oct 2000
Posts: 4379
Location: USA

PostPosted: Thu Apr 06, 2006 2:07 pm   
 
Here's a link to the old thread talking about this when class paths were first propossed:

http://forums.zuggsoft.com/phpbb/viewtopic.php?t=9331

Rainchild and I were the ones in favor of using standard filesystem syntax, but apparently it wasn't possible due to some backwards compatibility problems.
_________________
Kjata
Reply with quote
Zugg
MASTER


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

PostPosted: Thu Apr 06, 2006 5:05 pm   
 
Kjata, thanks very much for posting that link...you saved me a lot of time.

Looks like the original reason had to do with the old | syntax for class names. Also, it looks like the old parser couldn't tell the difference between / and no class at all and was treating @/varname the same as just @varname or something.

But it was a good discussion that pointed out some things for me to test and pay attention to. But it still looks like I can go with the "standard" syntax (which is the syntax recommended by Kjata in the original post in the first place ;)

OK, so it takes me 4 years to finally come around Wink
Reply with quote
Belmyrddyn
Magician


Joined: 17 Oct 2001
Posts: 371
Location: USA

PostPosted: Fri Apr 07, 2006 1:21 am   
 
Sort of in line with the idea you mentioned before about top-level script objects being "published" from packages - is there a possibility about having the ability to "lock" variables and prevent them from being edited at all from other scripts outside of the package that the variable is in?
_________________
Belmyrddyn
Reply with quote
Zugg
MASTER


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

PostPosted: Fri Apr 07, 2006 6:28 pm   
 
Just put the variable into a class folder within the package. Unless the Publish flag is set for the class folder then anything in the class will be private and not accessible to scripts outside the package. So no, there will not be an option for each setting...it's all controlled by what class you put the variable or alias or trigger into.
Reply with quote
Rainchild
Wizard


Joined: 10 Oct 2000
Posts: 1551
Location: Australia

PostPosted: Wed Apr 12, 2006 6:08 am   
 
Can we get a read-only flag for those 'published' variables? You know how OO programming works, where a class has functions and properties which may have get/set members, or may only have get members and not allow set. That's what I want to see from a package. Any package can read my published variable, but if they try to write to it they will be denied unless they use the setter function (if I provide one).

Mostly, I might have a package:

/Rainchild/PromptUtilities which keeps @/rainchild/hp updated automagically

and then I might have a second package:

/Rainchild/AutoBot which could rely on @/rainchild/hp being correct and can make its decision process to see if you need to rest or if you are ok to move onto the next mob
Reply with quote
Zugg
MASTER


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

PostPosted: Wed Apr 12, 2006 5:58 pm   
 
Not in the first beta release, sorry, but it's a good idea for later.
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD Beta Forum All times are GMT
Page 1 of 1

 
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