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

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD General Discussion
cypren
Wanderer


Joined: 03 Nov 2000
Posts: 59

PostPosted: Sat Feb 10, 2007 4:25 pm   

Separating variables from the package that creates them
 
I'm trying to create a package which can function as an independent "library" module shared between multiple characters with their own unique settings. I don't want to clone the package, because I want changes to the central components to be persisted across all characters. In effect, the triggers, aliases and so on should be in the centralized package, and all session-specific variables that they create should be created in the character's own "home" package so that they do not interfere with other characters that may be using the common library.

I'm having some limited success using class specifiers when creating and referencing every variable, e.g.:
Code:
#VAR myVar "foobar" _nodef {/Variables/MyClass}
#ECHO @/Variables/MyClass/myVar

However, while triggers see the "root" as the main game window (and can reference variables and functions from the package using "/myPackage/myClass/myVar"), aliases treat the included package as their "root" and cannot address the game window. (Attempting to do so results in a new class such as "/myPackage/myWindowName/myClass/myVar"). This even holds true if the entire class/variable structure is created in the primary window before the alias is run -- it will simply create a second copy in the package root instead of using the existing one in the window root.

Since my triggers and aliases depend on some of the same variables (for things such as pushing spells into a spellcasting queue with an alias, then working through the queue as time and mana permit with triggers/alarms) this is resulting in broken functionality all over. Has anyone else experienced this phenomenon? And have you found a work-around for it that doesn't require simply putting all the variables into the "common" package?
Reply with quote
Fang Xianfu
GURU


Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom

PostPosted: Sat Feb 10, 2007 4:33 pm   
 
The syntax you're looking for is this:

@//ModuleOrWindow/Class/Name

The only problem is that this won't work for defining variables, only for referencing them. Once the variables are created you won't have a problem because the scripts in the common package will check outside their current package if they can't find it inside.

Beware when doing this thought because settings inside windows will NEVER be visible to ANY settings outside that window. The only exception is when you explicitly reference a variable inside a window using the syntax above - there's still no way to set it from outside the window.
_________________
Rorso's syntax colouriser.

- Happy bunny is happy! (1/25)
Reply with quote
shalimar
GURU


Joined: 04 Aug 2002
Posts: 4662
Location: Pensacola, FL, USA

PostPosted: Sat Feb 10, 2007 4:39 pm   
 
Maybe you could work it as a seperate Session with no network connection and tap into it via the @sessionname.variablename syntax that worked in zMUD?
_________________
Discord: Shalimarwildcat
Reply with quote
cypren
Wanderer


Joined: 03 Nov 2000
Posts: 59

PostPosted: Sat Feb 10, 2007 5:01 pm   
 
The @// syntax was exactly what I needed. It doesn't work for "varname = value" assignments, but it does work as the class parameter to the #VAR command. My package is now pushing all of its character-dependent settings to a dedicated "preferences" package that will be unique for each character, but still addressable by things other than the primary window. Everything's working great!
Reply with quote
Fang Xianfu
GURU


Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom

PostPosted: Sat Feb 10, 2007 5:20 pm   
 
cypren wrote:
it does work as the class parameter to the #VAR command

It does? I get syntax errors when I try it, how are you using it?

EDIT: Never mind, I got it working! Thanks for the tip-off.
Reply with quote
cypren
Wanderer


Joined: 03 Nov 2000
Posts: 59

PostPosted: Sat Feb 10, 2007 5:22 pm   
 
Code:
#VAR myVarName "myValue" _nodef {//myPackageName/myClassName}

I redid all the variables in my triggers and scripts (regex replace, I love you!) and it works like a charm now. Not a single variable is being created in either the main window or the package that contains all the functions.
Reply with quote
Fang Xianfu
GURU


Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom

PostPosted: Sat Feb 10, 2007 5:29 pm   
 
One thing I've noticed, though, is that if you try to define a variable like this:

#var test 1 _nodef //untitled/test

from a window that isn't the "untitled" window (I'm using the untitled session to test this), the variable is created inside the window that executed the command but the test class inside the untitled window is still created. Anyone else able to reproduce this?
_________________
Rorso's syntax colouriser.

- Happy bunny is happy! (1/25)
Reply with quote
cypren
Wanderer


Joined: 03 Nov 2000
Posts: 59

PostPosted: Sun Feb 11, 2007 4:12 am   
 
Fang Xianfu wrote:
One thing I've noticed, though, is that if you try to define a variable like this:

#var test 1 _nodef //untitled/test

from a window that isn't the "untitled" window (I'm using the untitled session to test this), the variable is created inside the window that executed the command but the test class inside the untitled window is still created. Anyone else able to reproduce this?

I can confirm that. It only happens when trying to create from one window to another, though.

I would assume that relates to what you were saying earlier about there being no way to "publish" windows. Sounds like CMUD is making the publish check to create the variable and being denied, but failing to make the check when creating the class.
Reply with quote
Arminas
Wizard


Joined: 11 Jul 2002
Posts: 1265
Location: USA

PostPosted: Sun Feb 11, 2007 3:16 pm   
 
Have you considered creating different classes within the same package for different sessions?

Code:
#var test 0 _nodef {%title-%char/data}


This way the data is still saved within the package but is different for each session.

Also if you remove the package in this instance the data does not have to be cleaned up.
_________________
Arminas, The Invisible horseman
Windows 7 Pro 32 bit
AMD 64 X2 2.51 Dual Core, 2 GB of Ram
Reply with quote
cypren
Wanderer


Joined: 03 Nov 2000
Posts: 59

PostPosted: Sun Feb 11, 2007 7:17 pm   
 
There are two primary problems with that, from my perspective. The first is that I want this package to be usable in two concurrent CMUD sessions -- I multiplay frequently, and so do many other people, I'm sure -- and if you have two copies of CMUD open, the last one to write to disk will overwrite any changes the other may have made. I'm aware that I could open both characters in the same CMUD instance, but for various reasons (including my preference to be able to alt-tab to get between sessions instead of having to flip through the ten or so child windows in each session) I much prefer using two copies of the program.

The second is that eventually I would like to distribute this package along with the custom proxy/parser I wrote to enable full MXP support in Simutronics games. As I add more scripts and upgrade it, people will hopefully want to get the new versions, and if all of their custom settings are stored in the package, they'll have to export/import each time they upgrade or recreate them, neither of which is acceptable to me. I'd like it to be "plug and play".
Reply with quote
Arminas
Wizard


Joined: 11 Jul 2002
Posts: 1265
Location: USA

PostPosted: Mon Feb 12, 2007 2:50 pm   
 
cypren wrote:
-- I multiplay frequently, and so do many other people, I'm sure -- and if you have two copies of CMUD open, the last one to write to disk will overwrite any changes the other may have made.


Actually I had multi-playing in mind when I suggested this. If you use Variables that contain your information for instance %session-%char or %title-%char or %window-%char to create a DATA folder for a package the variables will/should contain different data for each char you are playing in.
Thus creating different classes/variables so that your configuration and data will go into different places and NOT be overwritten by the other instance/session that you have open.

If these variables are not up to the job. Meaning they give the same info or wrong info perhaps we can convince Zugg to add some that WOULD make this doable.

As for the information needing to be someplace other than the package it would be MORE plug and playable if you distributed two packages. One that only held your data, In something similar to the format suggested above. And one that held your triggers/alias/etc.
_________________
Arminas, The Invisible horseman
Windows 7 Pro 32 bit
AMD 64 X2 2.51 Dual Core, 2 GB of Ram
Reply with quote
Fang Xianfu
GURU


Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom

PostPosted: Mon Feb 12, 2007 4:05 pm   
 
It depends on how CMUD updates the data Arminas. If ALL the variables are written to disk from any particular instance of the program, even ones that haven't been changed, then settings from one will still overwrite settings from the other.

And the plug-and-play thing: there seems to have been a misunderstanding. I don't think anyone was ever suggesting an alternative that didn't use a separate package.
_________________
Rorso's syntax colouriser.

- Happy bunny is happy! (1/25)
Reply with quote
cypren
Wanderer


Joined: 03 Nov 2000
Posts: 59

PostPosted: Tue Feb 13, 2007 2:10 am   
 
The software does dump the entire package from memory to disk, by the way. You can test this yourself: open CMUD twice, change two different things in the same package, one in each copy, then save both to disk, exit, and reload. The package settings for both things will match whichever one was saved last.

A differential, multiprocess-safe update to a flat file of the type that you're suggesting, Arminas, is pretty unpleasant and tricky to code and I'd be shocked if Zugg thought it was worth the time and effort for a small gain most people won't ever see.
Reply with quote
Arminas
Wizard


Joined: 11 Jul 2002
Posts: 1265
Location: USA

PostPosted: Tue Feb 13, 2007 2:54 pm   
 
I am NOT suggesting dumping to a flat file. I am sorry I made it sound thusly.

I tend to use the terms FOLDER/Class interchangeably when speaking about Zmud/Cmud.

Here is a very simplified explanation.

Create two packages.

Package1 contains triggers/aliases/macros/alarms/buttons

Package2 contains Functions/Variables

When you access the Functions/Variables in Package2 You use the variables I mentioned before within Package1. Example

#var test 0 _nodef {//Package2/%title-%char/data}

To set the value of one of your Variables and.

@//Package2/%title-%char/data/varname

To READ one of your variables. or

@//Package2/%title-%char/data/funcname()

To use one of your functions.

To use database variables.

#class {//Package2/%title-%char/data}

#addkey dbvarname {key=value}

#class

Now the issues I mentioned.

The %window command currently displays a string list of windows. Good except it only lists ONE window many times. Example

Avalon|Avalon|Avalon

%title in this example is going to be the same unless changed for all sessions to the same mud.

%session would be a good one except sessions can ALSO have the same name. though they normally wouldn't.

And the %char command is blank unless someone actually sets their char name in the sessions edit screen.

This is why I suggested that maybe Zugg would make us a predefined variable that we could use for creating unique references to a %char/%window pair.
_________________
Arminas, The Invisible horseman
Windows 7 Pro 32 bit
AMD 64 X2 2.51 Dual Core, 2 GB of Ram
Reply with quote
Fang Xianfu
GURU


Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom

PostPosted: Tue Feb 13, 2007 3:14 pm   
 
You seem to have missed the point Arminas. If you save your variables in a single package using that syntax, the last-saved data will overwrite.

For example:

Two instances of the program, CMUD1 and CMUD2, are both open at once. CMUD1 and CMUD2 both open Package, which contains two variables. I'll call them @Char1 and @Char2 - Char1 is the name of CMUD1's character and Char2 is CMUD2's. Both variables default to 0.

To start, CMUD1 and CMUD2 both contain both variables, and all four variables are 0. CMUD1 then uses %char to change the Char1 variable to 1. CMUD1 now contains @Char1=1 and @Char2=0 - it saves the change to the disk, meaning the package on the disk now contains @Char1=1 and @Char2=0.

But CMUD2 doesn't update its data from the disk. It still contains @Char1=0 and @Char2=0. If it then uses the same script to change Char2 to 1, it will contain @Char1=0 and @Char2=1. It'll save these changes to disk, overwriting the change made by CMUD1. Even though @Char1 hasn't changed, the value 0 is still stored by CMUD2 and the value set by CMUD1 is lost. The final result is that @Char1=0 and @Char2=1 in the file saved on the disk.

I understand that the easiest reponse to this is "Well, don't open the program more than once" and I agree that it was probably never intended to be opened more than once. But what you're suggesting won't help in this situation.
_________________
Rorso's syntax colouriser.

- Happy bunny is happy! (1/25)
Reply with quote
Arminas
Wizard


Joined: 11 Jul 2002
Posts: 1265
Location: USA

PostPosted: Tue Feb 13, 2007 3:51 pm   
 
Thank you Fang. I didn't understand what you meant. I was thinking your OWN variables and not cmud's internal ones. Still I think given this situation and baring Zugg completely changing the way multiplaying works it would be good for him to give us something that does NOT change.
_________________
Arminas, The Invisible horseman
Windows 7 Pro 32 bit
AMD 64 X2 2.51 Dual Core, 2 GB of Ram
Reply with quote
cypren
Wanderer


Joined: 03 Nov 2000
Posts: 59

PostPosted: Tue Feb 13, 2007 10:09 pm   
 
Fang Xianfu wrote:
I understand that the easiest reponse to this is "Well, don't open the program more than once" and I agree that it was probably never intended to be opened more than once. But what you're suggesting won't help in this situation.

Just to point out, zMUD actually won't allow you to open more than one copy of the program at a time, while CMUD will. This may be an oversight, but my hope is that it's an intentional change in the way the software is designed to work. I much prefer the "segmented" sessions for multiplaying (allowing me to alt-tab between two complete UIs) to the zMUD "unified" system where it was all forced together in one mess of tabs and containers.
Reply with quote
Tech
GURU


Joined: 18 Oct 2000
Posts: 2733
Location: Atlanta, USA

PostPosted: Wed Feb 14, 2007 12:35 am   
 
The program was designed to have multiple copies open, so be sure to thank Zugg for that. I don't multiplay, so I can't speak to it's merits however.
_________________
Asati di tempari!
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD General Discussion 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