Zugg Software :: View topic - [2.36] vs Zmud -- using inherited settings

Beginner Joined: 20 Aug 2008 Posts: 24 Location: Germany

Because i'm have multiple chars in the same mud i have setup my chars in zMud similar like this:

guest - main.mud
char1 - specific1.mud inherits main.mud
char2 - specific2.mud inherits main.mud
...
main.mud contains all the settings and functionality common for all characters,
It also contains settings in disabled classes like guilds|mage, guilds|bard or guilds|druid which are enabled if needed by atconnect scripts in specific1.mud, specific2.mud...

All things specific for one only (like special menu button additions or special strings for congratulations or current weapons ...)
are in the character specific file.

All of this is very easy and powerful and works very well because inherited settings are merged and when a inhrited script writes to a variable it writes to character specific variable or when a inherited buttons caption shows a variable it shows character specific variable...

In CMUD i tried to convert the common package to a module and then use it in each char.
But i have some trouble to create the same behaviour in CMUD now as i had in zMUD.

Some examples:

#1: i have a Button "Grats" in main.mud which does "#send {"laber: "@vGrats}" to send a congratulation defined in vGrats. vGrats is there simply defined as "gratuliert" (german ;)
in the specific file this variable its redefined as needed vGrats = "zaubert ein finsteres *Grats* in den Himmel"

that simple example works very well in zMud but not in CMUD :(

#2: in main.mud i have some classes like guilds|druid, guilds|bard, guilds|mage ... all disabled. In specific#.mud i have an atConnect where classes needed by the char are enabled.
That works well in zMud but not in CMUD :( When there are specific additions to the guild class only these are shown, when there is no guilds class in specific#.mud nothing happens.
#T+ dosnt refer to the class in the other module.

#3 (more complex). In main.mud i have three buttons helping me in using weapons. Two are menus for selecting which weapon should be used for both hands, the third one toggles between use/unuse by taking the specified weapon from the specified inventory location and use it / or unuse ist and put it away to the specified inventory location (could be weapon belt, sword belt, sword shealth or backpack dependent on weapon type ;)
Weapons, their inventory location and method to put away (could be hang, lay or plug) are defined as menu classes in main but disabled. Current available weapons are defined in char specific var and the menu entries in main are enabled/disabled if this var changes (trigger on var-change)

This works very well in zMud but not in CMUD. it looks like references between modules/packlages are not working as expected :(

#4 i have Menu classes in main and added menuitems to specific if needed to extend the menu. That means i have the same menu class in main and specific and because these classes are merged in zMud everything is working well. In CMUD only menu entries defined in main are shown :(

I have some more such releationships between main and specific file where the functionality is located in main but refers to variables in specific.
(just following the OOP principles)

How can i have the same behaviour in CMUD without moving common things to each specific file?

--
I have some more issues, e.g. triggers like this: "({%dblist( ~"Name~")})" which are not longer working but that should be an other thread..

Posted: Fri Aug 22, 2008 7:23 pm

#1: I just tried it out using the following code and it works just fine. Try this code, or please explain a bit more as to why it doesn't work. Does it not send the text properly? Does it send the wrong text? Does it work for one character and not the other?

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I think starting with the basic terminology, and the short version of the scoping rules would be helpful.
1. A module is a container group for settings that controls the scoping behavior for those settings.
2. A package is a file that contains 1 or more modules, and the module scoping setting is relative to its containing package.
3. A window is a specialized module that has a fixed scope of 'self', and provides additional controls for being displayed.
4. All scripts require a window to execute in.
5. All scripts execute with the full scope of the window from which they are run, then if needed they have the full scope based on thier actual package+module settings.
That is the basic terminology, and the basic rules. I bolded the 4th item because that rule was the key in devloping the scoping system to a point that it just plain works without any real thought.

Now lets look at your specific problems, and how to solve them. I will start by saying that the move from zMud should have converted your specifc#.mud files to packages which would be associated with each session. Your main.mud might have required a manual conversion. After that conversion you should have changed the 'main' window in the new main.pkg to a module and set it to global scoping. Then you would include that package into each of your sessions. I think you managed to do all that already.

1. Button sending contents of @vGrats. Remove the vGrats variable from the module of the main.pkg. Create variable within the window for each of your specific#.pkg's. This works because the button needs a window to display in. Being in a global module all windows that use your main.pkg will display the button. When it is clicked on it knows what window that was from, and when it looks for the vGrats variable the scope of the window will be checked first. Since the variable exists within the specific#.pkg window that was the source of the click that value will be used.

2. First is that the atconnect alias has been replaced by the onConnect event. You will have to adjust the scripts for each of your specific#.pkg's. Next, double check that you did the conversion for your main.mud according to what I described above. You final result from the conversion should be a main.pkg which has a main module set with a global scope. Finally, double check that each of your specific# windows enables the main package.

3. I couldn't quite follow the setup you are using for this item. If you apply the experience you gain from fixing the first 2 of your items you should be able to solve this as well. Otherwise I would need a desciption of exactly where each control variable is, where the scripts are, and the expected behaviors.

4. Speedmenus are something that never really got played with in the scoping tests. Each class is a truly seperate entity. I think the best way to handle it is to adjust the name of the class in your main.pkg, and define an additional menu item to reference it.

5 unnumbered. If you look at the descriptions above all of these should work if your main.pkg has been properly set. Again read my description of how it should be set.

Beginner Joined: 20 Aug 2008 Posts: 24 Location: Germany

Thanks for your explanations. I understood this as far as possible.
When i coded things in Zmud i followed these OOP principles: inherit/overide/extend. The problem was: my package file also has variables which should
provide predefined values. (like "gratuliert" in my example)

Scope and Preference -- thats the key and that has been turned in CMUD. When variables defined in window would have higer preference
then it would work as before and would probably very powerful. Zugg said "You can think of a Module as a "super class". but that is not true.
Things inherited from a superclass can be overriden in descendent classes -- in CMUD a variable defined in window should override a inherited variable^^

Ok, it looks like a big job checking and adjusting each script carefaul^^
As you said above after removing vGrats from module its working as expected but the same solution for other variables are causing CMUD to hang
in endless loop when the variable will first be created by trigger (as i reported in other thread) :lol:

---
Hmm... i could possibly write module variables via onLoad event but... what happens if i have two open sessions which are sharing the same module ?
I have to check this ...

One question: is there a way to full qualify a object? something like this: /<package>/<module>/<class>/<subclass>/variable
or the same relative like this: ../<sisterclass>/variable :)
Its hard to find a description in the helpfile.

Beginner Joined: 20 Aug 2008 Posts: 24 Location: Germany

Argl... after some tests i noticed that:

Posted: Sat Aug 23, 2008 9:23 pm

It looks like you really need 3 different packages... Something akin to

Beginner Joined: 20 Aug 2008 Posts: 24 Location: Germany

Hmm... Ok. i see. Splitting the package could help.
Althow, as soon as two characters are sharing the same module package they are also share all variables in it.
Thus at least the "endless loop" issue should be solved so variables can automaticly be created in the window.

Whats about enabling / disabling packages per script? guilds, professions and races are more or less character specific, helperclasses for ingame games are not.
So it would be helpful if i could add packages to the window disabled but enable if needed. An command like #PKG+ "games_chess_pkg" for enabling a
pakages could be helpful in such cases... Oh sigh. i would need a separate package for each toplevel helperclass.

Phew, why the hell became things so much complicated. In zMud all very easy, one inherited readonly package all changes were local to the session,
no interferences between sessions happened.
I realy have the feeling that things are designed the wrong way in CMUD. Its not an programming laguage nor development environment, its just an
replacement for telnet ;) A helper application for playing mud and there the individual character instance should be in the center.
Each functionality, regardless from where inherited should only act upon this instance first and should never interfer with other instances inheriting the
same modules unless explicitely other specified.
Thats the way how zMud worked.