Zugg Software :: View topic - Poll about how Published Modules should work

Wizard Joined: 14 Aug 2004 Posts: 1269

I'd go with a radio box for all four options - it just looks like there's something missing if you leave out option 1.

SubAdmin Joined: 18 Nov 2001 Posts: 5187

Option 1 is totally unnecessary since there is no way it could ever become active. Without being attached to a window only alarms might possibly run, and I think those would even need a session in order to become active.

Posted: Sun Nov 26, 2006 8:29 pm

It might be useful for variables that hold sensative material... would you still be able to get at the variables if you referanced them modularly?
Or for housing 'Plug-Ins' when and if they come about.

SubAdmin Joined: 18 Nov 2001 Posts: 5187

I have been thinking a little bit more about this and have another idea if you haven't implemented anything yet, Zugg.

Posted: Thu Nov 30, 2006 6:14 pm

Vijilante, I've thought about doing that. The problem is that there is no way for one package to know which modules are in another package without reading the entire package. Also, module names are not unique. The same module name might exist in multiple packages. And remember that this information is stored with a *session* and not with the package itself. By storing the "enabled package list" with the session, it allows you to load the same package, but have it enabled or disabled for different character windows.

For example, if you have a "Fighter Package", then you have your main session with two Windows: "Warrior" and "Mage", then you just enabled the "Fighter Package" for the Warrior window, and not for the Mage window.

From a user interface point-of-view, the only way this would make sense is if the "List of enabled modules" was a tree-view with checkboxes next to each node, where you could click on the checkbox for the entire package to enable/disable all modules in the package, or just click the checkbox for an individual module within a package. But this would take a lot of time to code, and I'm still not sure how to efficiently store the data into a session in a way that would work even if the package was edited and the names of the modules were changed.

Anyway, something this complicated isn't going to get added soon, so I still need an easy way to handle the user interface option for case (4). Case (4) is already implemented in the code with a simple boolean test, so it's just the user-interface that needs to be set.

Posted: Thu Nov 30, 2006 6:27 pm

Posted: Thu Nov 30, 2006 6:39 pm

It will pick the module within the same package first. If both modules are outside of the current package, then it should pick the module that was loaded first. Only one would be updated.

That's why the //module/class/name syntax should only be used when absolutely necessary. The whole point of packages is that they should be independant. As soon as you start linking packages together with //module/class/name stuff, then you are creating package dependencies that could potentially cause problems. The syntax is only there for cases where you have no other choice.

Wizard Joined: 14 Aug 2004 Posts: 1269

Is there a //package/module/class/name syntax? There would be no ambiguity then.

Posted: Fri Dec 01, 2006 12:04 am

No, and that isn't planned right now. As I said, that breaks the independance of packages.

If someone can come up with an actual useful purpose for this kind of stuff, then I'll consider it. But if you want to access stuff in a different package, just make sure the module names are unique! Come on people, we can all think of stuff that could be added. But I'm not adding the kitchen sink to CMUD. There are already plenty of ways to do cross-package communication (unique module names, events, etc). I'm not going to spend hours and hours adding some new obscure syntax for //package... just because someone is worried about conflicts in module names.

Let's try to focus on stuff that really matters here.