Zugg Software :: View topic

Magician Joined: 18 Dec 2006 Posts: 317 Location: Denmark

I want to organize my scripts into packages so they are easily shared between different session packages and also to be able to share them with others.

So I have made a global package that can be opened from different session. So far so good. But what if I want to make a hierarchy of packages where some depends on others? In the manual it says:

Posted: Sat Nov 06, 2010 2:07 pm

Packages are self-contained and you can't have a hierarchy of packages. What you can have are packages that use common variables and or events to communicate.

For example, in one mulitple package setup I do I register a global variable of the packages available. In another setup I raise various events to communicate between the packages.

Magician Joined: 18 Dec 2006 Posts: 317 Location: Denmark

Well, the default session package is not self-contained so why does the rest have to be? Or am I wrong?

My plan is to make a package with all the basic elements like a command queue and so on. Then on top of that a combat package, a training package and so on.

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

Package dependencies is a future feature that hasn't really been touched on yet. Given that there's no ability to check on the existence/status of a package, and generally no distinction between reported results for uninstalled, undefined, and disabled, any type of user-created dependancy check is going to be incomplete and/or insecure (ie, the user could change the data.) Thus, while you could perhaps cleverly script a package-management system that uses SQL/COM scripting (to drill into the sessions.db file) and various triggers to monitor state variables and the like, basically it will be far, FAR easier and less hassling to simply build your packages to be completely standalone.

Posted: Sat Nov 06, 2010 4:56 pm

Kjaerhus, I'm not sure what you mean when you say the default package is not self contained? How is it not self-contained. Maybe I misunderstand you, so exactly what do you mean by self-contained. Can you give an example or two, of exactly what you want to do.

While Matt is right you can not check for the existence of a package, you can use the %class function to check if a particular module is enabled or not. I have used this as well for enabling optional packages in my own package management systems.

Magician Joined: 18 Dec 2006 Posts: 317 Location: Denmark

Posted: Sun Nov 07, 2010 12:36 am

Yes that is the way they work. I did not understand what you meant. I thought you wanted to have hierarchical package structure, i.e. a package with a package.

What you're describing is easily doable with just some planning and the tips we provided earlier.

Magician Joined: 18 Dec 2006 Posts: 317 Location: Denmark

Magician Joined: 18 Dec 2006 Posts: 317 Location: Denmark

Also I'd love to know whether there is a command to copy a setting from one package to another. Say if I want to make the whole GUI interface in a package and then create a setup alias that when called copies the GUI elements to the session window. It's ofcourse important that I can give the copies an ID so I can overwrite them.

I can make a setup script that creates all the GUI, but there are so many settings on an element that it would be easier to just make them using the editor.

Important thing is that the end user needs only fire off a command to get the GUI elements and that he can do it as many times as he likes.

EDIT: Perhaps the smartest thing would be if I could create a GUI element by a piece of xml. Is that possible?

Wizard Joined: 22 Mar 2007 Posts: 2320

There are no "best practices" yet. Generally, you can organize your packages however you want. The only trick is that if you have one secondary package using variables or aliases defined in another, you need to set the package to see the other.
In one mud, I set up all my magic-related stuff in one package, all my mapping stuff in another, all my crafting stuff in a third. I minimized the crossover necessary between these packages, making them as independent of each other as possible. But I also set up a couple packages of helper functions and aliases, which were utilized in many of my packages. How you do it is up to you. I do recommend as much compartmentalization as possible, except for packages specifically set up to provide general-purpose functionality needed in many packages. One example--my general function package has a function called @intersection() which would return the set intersection of two stringlists. I used that in several other packages.

Magician Joined: 18 Dec 2006 Posts: 317 Location: Denmark

Wizard Joined: 22 Mar 2007 Posts: 2320

GUI items? Not sure what you are asking for.

Sorcerer Joined: 10 Oct 2000 Posts: 706 Location: USA

Rahab, Are your packages out in the package library? It would interesting to install them and see how they interact with each other give us other package developers some good ideas.

Wizard Joined: 22 Mar 2007 Posts: 2320

I have one package in the library, but it is specific to Dartmud, for tracking skill improvements. I am working right now on a package I hope to put in the library. It will essentially be a relational database code based on Cmud variables. I could have waited for Zugg's eventual overhaul of the db code, but that will probably be another year at least. Or I could have used an external database driver. But I'm hoping my code will be simple enough for people who don't want to learn SQL, lacking advanced features that will confuse someone who just wants to track pc acquaintances or crafting recipes, while having features that are especially useful in a mud environment such as db variables suitable for inclusion in a trigger pattern.

Posted: Tue Nov 09, 2010 5:22 pm

Kjaerhus, I'm not sure exactly what you're looking for when you ask for best practices. Beyond what has already been mentioned it comes down to how you want to organize your code. Compartmentalization is always to limit dependencies across packages. Then it's a matter of checking for the existence of optional packages, and determining the best way to communicate based on your usage scenario.

Most, if not all GUI elements have a corresponding command to create them, though this is not always practical. The #BUTTON command is a great example of this. This is typically a moot point since GUI elements can be distributed with a package as well. Then enable the package for the desired window, and the GUI elements are now available.

A better approach to get help here may be to describe the packages you are trying to create, what they do, and exactly how you would like things to work. Then we can provide insight as to what approaches would work best.

Rahab, in lieu of the db code rewrite why not use the integrated SQLite feature. I had a similar DB based package, that I converted over to SQLite. The only drawback there of course is that you don't have the DB GUI, which you may or may not need.

Wizard Joined: 22 Mar 2007 Posts: 2320

Tech,
Yeah, I did consider that, and I happened to recently refresh my memory of SQL. That actually plus trying to learn Java was partly what inspired me to reconceive how I was approaching storing information within Cmud, which previously was being done by dozens of stringlists and db variables, and scripts specific to each application.

I might take another look at using SQLite. It occurs to me that I could actually use the same function and alias names I have already created for the project, so I wouldn't have to change any scripts using the package. I would just have to change the internal code within those functions to use SQLite commands instead of pushing data around Cmud variables. I have what I think is a slick Cmud interface, where an alias will display all the key-value pairs for a record, with MXP links which allow editing the values or displaying the corresponding record if the value is a record ID (or list of IDs).

[edit] Actually, I should take a look at your package, to see whether I can build on top of that.

Magician Joined: 18 Dec 2006 Posts: 317 Location: Denmark

Magician Joined: 18 Dec 2006 Posts: 317 Location: Denmark

Posted: Wed Nov 10, 2010 11:18 pm

If you are truely trying to mimic StormFront, I would suggest you make your button panels into seperate windows.
With the #MAKEWINDOW command you can even remove the scrollbars and get nitty-gritty with it.

Then the windows would all be in the package and the end user could arrange them to his/her whims.
The only problem is i don't think there is a way to share the associated layout file for such a complex scheme, to allow out-of-the-box playing without having to dock things first.

Unless.....

#MAKEWINDOW can specify window positions as well... you might want to make an alias to throw out default values, or several for that matter, for various screen resolutions.

Magician Joined: 18 Dec 2006 Posts: 317 Location: Denmark

I think everything right now falls with the lack of support of setting all parameters for settings through the command line. There are simply too many things you can do in the editor which cannot be done if you want to create your settings from some sort of setup script.

The only solution I see right now is to share the packages and provide the used xml for the windows in the session packages so people can manually set this up. Regarding the layout file and the map there is a small problem I think as these have to be downloaded somehow.

Perhaps this could be an idea for the next version of CMUD. Instead of adding lot's of new features for the few it would be great if expert users could create "super packages" that is out-of-the-box environments for playing a certain mud. That would really open CMUD for non-expert users that want to use all their time playing muds and not troubleshooting client-related issues.

Posted: Sun Nov 14, 2010 8:18 pm

What you're describing is the feature set Zugg hopes to implement when he integrates the zApp functionality.

I still have a hard time understanding what you are trying to do that has to be created at run-time but can't be distributed with the package itself.

Maybe a screenshot of you desired end-state would help.

Posted: Sun Nov 14, 2010 11:48 pm

I can't speak for him really, but I can supply a screenshot of Stormfront to give folks a better idea of the complex layout they use:

Notice the right panel is a superwindow for a bunch of tiled windows, complete with a scrollbar (that disappears when not needed!) for if the superwindow is too big for the screen.
When you look in a container it makes a temporary window displaying the contents (I could code that part) into one of the side panels, but you can also drag objects between windows to move them between containers.

I don't think we can do those currently in CMUD.

Magician Joined: 18 Dec 2006 Posts: 317 Location: Denmark

Posted: Mon Nov 15, 2010 7:52 pm

Can you post a screen shot of what you have done in CMUD that you can't distribute via package. That's the part I'm struggling with. If you can create it in CMUD, which it seems you can, I'm not clear as to why you can't distribute it as a package. That part is not clear to me.

Are you saying you also want to distribute your map file?
Are you saying you want to be able to control the exact initial layout of windows?

If I find time I may try and mimic some of the storm front layout and put it in a package. I'm sorry if I seem dense or redundant, but it's still not clear to me what exactly is not working for you. I think I understand that StormFront layout is an example of your desired end-state, but what specific problem is preventing you from getting there?

Magician Joined: 18 Dec 2006 Posts: 317 Location: Denmark