 |
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
 Posted: Wed Aug 09, 2006 5:31 pm
More on Packages/Modules (public vs private)
|
Still trying to fine-tune the new module/window/package system that was discussed in other threads. As usual, I coming across a couple of situations during testing that are not handled as well as I'd like. Here are a couple example situations:
Example A : Tells Module
In this example, we want a simple module (window) that captures the "tells" from the main MUD window (or any other session windows). I want to highlight the name of the person in a different color. So, we have two triggers:
| Code: |
#TRIGGER {^%w tells you} {#CAPTURE Tells}
#TRIGGER {^%w} {#CW yellow} |
Now, obviously I want the first trigger to fire in the main MUD window and *not* in the Tells window. And obviously I want the second trigger to fire in the Tells window and *not* the main MUD window.
So how do we tell CMUD the difference between these two triggers? In zMUD you would put the Capture trigger in the main MUD window, and leave the Color trigger in the Tells.mud file. But with the modularity offered in CMUD, it would be nice if the Tells Module could be self contained. Then we could put it into a package and distribute it.
Example B : Global Triggers
In this example, I'd like to create some Color triggers that effect *every* window that I have open. For example, I'd like to highligh the word "Zugg" in every window:
| Code: |
| #TRIGGER {Zugg} {#CW red} |
How do I do this without putting this trigger into every window/module? Can't I create a "global module" and put this trigger into that module and have it fire for all other windows?
Possible Solution : Private/Global/External property
OK, I've given this some thought, and I think a possible solution is to expand upon the current "Published" property that Class folders have.
First, since a Module is really a type of Class folder (it contains settings), the first step is to add this property to the Module.
Next, we need to expand this concept to have three properties:
- Private
- Settings in this module/folder are Private can only be accessed by the current module.
- Global (or Public)
- Settings in this module/folder are Global and can be accessed from other modules within the same package. Settings cannot be accessed by the same module unless the Private property is also set.
- External (or Published)
- Settings in this module/folder can be accessed from other packages. But not from other modules in the same package unless the Global property is also set.
You can set any combination of these properties. Private means the settings are seen by its own module. Global means the settings are seen by other modules in the same package. External means the settings are seen by other packages.
So think of a Button as an example. If a button is Private, then it only gets displayed within the window that it is defined. If a button is Global, then it only gets displayed in *other* windows. If a button is *both* Private and Global then it gets displayed in it's own window AND the other windows. If a button is External, then it only gets displayed in windows of other packages.
The names of these properties might need to be changed, but that's the basic concept.
OK, so let's look at the examples above. In Example A, we mark the Tells Module as Global, and put the Capture trigger into this module. Then we put the CW Color trigger into a class folder and mark the class folder as Private. So, in this case, the Capture trigger gets seen by other modules, but not by the Tells module itself (so we don't get any infinite trigger loop). The Color trigger only gets seen by the Tells module and not by anyone else.
In Example B, we create a new module (without a window) and mark it as Global and place the color triggers in it. These triggers will get seen by all other Modules, causing the word "Zugg" in all other windows to get colored red.
In Example A, if we wanted to make our Tells module/window into a package, we would also set the module as External so that windows in other packages would see the Capture trigger.
Now, remember that at the Package level, we still have a list of which packages are enabled/disabled. So you could still have a package that had the Tells package disabled so that the Capture trigger wasn't active in any windows in that package.
I'm interested in feedback on this idea, and also suggestions for better names for these properties. But the idea is that we are controlling the "scope" of settings within folders and modules. We need a well-defined set of rules to follow to determine what settings are visible to any given window/module. This will determine what buttons are shown in a window, and what triggers are fired from text in the window. |
|
|
|
|
Dumas
Enchanter
Joined: 11 Feb 2003
Posts: 511
Location: USA
|
Posted: Wed Aug 09, 2006 8:22 pm
|
I like Private and External for what you have them. The terms are pretty straight forward. Global/Public wouldn't be proper for the other category because you still have to mark private to have the same module be able to access it. What can be used instead though? Shared, maybe, but still may be confused with External.
|
|
|
|
|
Rorso
Wizard
Joined: 14 Oct 2000
Posts: 1368
|
Posted: Wed Aug 09, 2006 8:22 pm
|
| Zugg wrote: |
In Example A, if we wanted to make our Tells module/window into a package, we would also set the module as External so that windows in other packages would see the Capture trigger.
|
Doesn't this mean you are triggering on incoming text in all windows? What if you only want to trigger on text from the main MUD output? Maybe I am misunderstanding how modules/packages work :P. |
|
|
|
|
Kjata
GURU
Joined: 10 Oct 2000
Posts: 4379
Location: USA
|
Posted: Thu Aug 10, 2006 3:16 am
|
I think you have been working with modules so much that you have forgotten about packages, Zugg. Remember that all modules are contained within packages, and that each package may contain one or more modules. With this structure, both scenarios are quite easy to solve.
Scenario A: Tells Module
This scenario should be renamed to "Tells Package". What the person does to solve this scenario is to create a Tells package that contains two modules (one with a window and one without a window). The module without a window in the Tells package would contain the following trigger:
| Code: |
| #TRIGGER {^%w tells you} {#CAPTURE Tells} |
The module with a window in the Tells package (the module has a name/id of "Tells" as given by the #CAPTURE command) will contain the following trigger:
| Code: |
| #TRIGGER {^%w} {#CW yellow} |
Scenario B: Global Triggers
This scenario is solved by creating a package with a module that has no window that contains the following trigger:
| Code: |
| #TRIGGER {Zugg} {#CW red} |
Summary
As you can probably see, the solution to these problems is achieved by the distinction created by packages with windows and packages without windows. Triggers that belong to a module without a window inside a package are applied to all modules with windows in all packages that have the package in question enabled. Triggers that belong to a module with a window inside a package are applied just to that module/window. |
|
_________________
Kjata |
 |
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Thu Aug 10, 2006 6:37 am
|
Rorso: As mentioned in the other thread on modules, each module has a list of which packages are enabled/disabled. So only the windows that enabled the Tells package would see the capture trigger.
Kjata: I know it sounds like I'm going in circles. Sometimes I get frustrated and think so myself. But you are tying the fact that a module has a window or not to how the scope of settings in that module are handled. You are essentially saying that any module with a window is "Private" and any module without a window is "Global".
Also, you need to consider the common situation where packages are not used at all. The intent of packages is to provide a way for advanced users to "package" certain functionality into a "black box" and distribute it via the shared package library. But the novice user shouldn't need to understand or use packages.
When a novice user does this:
#TRIGGER {tells you} {#CAPTURE Tells}
they expect it to work like it did in zMUD. It's a very common feature and needs to be simple. If you created a separate package file for each window that was created with #CAPTURE or #WINDOW then you'd end up with a mess of files to keep track of. Your character settings for a MUD would be scattered in many files.
I know that for one MUD I have the following windows: Main, Tells, Guild, Auction, Combat. I don't want to be forced to create a separate package file for each of these windows.
The current way CMUD is working (in 1.04) is that the #WINDOW and #CAPTURE commands create a new Module/Window within the *current* package. This keeps your settings for a single MUD character in a single package file. It's only when you want to generalize some functionality that you'd put it into a package and distribute it.
Look at your solution to "Scenario B". You are creating a whole new package file just for the global color triggers for a specific MUD. The character name "Zugg" might only exist on a single MUD. On another MUD where I had a different character name, I'd have to create another package for it's own global color triggers. These are not reuseable pieces of general functionality...they are very MUD and character specific and really defeat the purpose of making "black box" packages.
As I mentioned to Rorso, in the current scheme, each Module has a list of the packages that are enabled/disabled for that module. OK, so imagine you are building a package. How do you control which parts of that package are visible to other packages? Currently you have the Published property for a Class. Currently any top-level setting, or any setting within a "published" class is visible to other packages.
OK, fine, but what about to modules within your own package. Do your own modules within the package also see these published classes? Or do they see more than that? And how to you control what is seen and what is not.
Consider some examples where you have multiple windows/modules in a *single* package and look at how you determine what buttons are placed in which windows, and which triggers fire in which windows. You can decide to just make windowless modules Global and window modules Private. But that seems a bit restrictive. So why not allow these properties to be set on a module basis.
Certainly I would set the defaults as you mentioned. But I think the greater functionality is needed to prevent too many package files scattered around and makes Modules a lot more useful. |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Thu Aug 10, 2006 7:43 am
|
My gut feeling is that this discussion (this thread and the others) is getting too complicated.
Let's try to boil this down to something specific. Let's come up with the specific rules used in CMUD to search for settings within "scope". In other words, when a script uses an alias, where does CMUD look for this alias?
Here is the current proposal:
1) Look in the current class
2) Look in the parent class (and keep checking parent classes)
3) Look in the top level of the current module (this is essentially the same as the parent class in 2)
OK, that is the straightforward part. CMUD 1.03 already does this. The real questions start happening when you still haven't found the alias and need to start looking "outside" the current module.
So, here is the rest of the proposal:
4) Look in other enabled class folders within the current module that are marked as Global or External.
5) Look in other enabled class folders within *other* modules within the *same* package file that are marked as Global or External.
6) Loop through the list of other packages that are enabled for the current module and look in enabled class folders that are marked as External.
Remember that a Module acts just like a class folder in this search. Modules are really the root-level class folders.
To review: steps 1-3 make sense using the normal folder hierarchy and follow normal programming language scope rules where you look in the parent subroutine if you don't find a variable within the local scope. So there is probably little to debate about 1-3.
Step 4 handles the zMUD compatibility. In zMUD it will look in any enabled class for a matching setting. While this has some wierd side effects, we need to keep that compatibility in CMUD. Adding the requirement to mark a class folder with Global or External provides a bit more control than zMUD. You can essentially create private class folder subtrees with this method, which is useful.
Step 5 handles the other modules within the same package file.
Step 6 handles access to other packages.
So maybe by focusing on these "scope rules" we can make better progress, rather than looking at contrived scenarios. At least this will help me more directly in the implementation.
Reviewing what I just wrote, it looks like maybe we don't need all 3 of the originally proposed properties. Notice that the "Private" property isn't mentioned in these rules. So perhaps the Private property is just the inverse of the Global property. So maybe we only have "Published" and "Private", and you replace "Global" in the above steps with "not Private"? |
|
|
|
|
Kjata
GURU
Joined: 10 Oct 2000
Posts: 4379
Location: USA
|
Posted: Thu Aug 10, 2006 3:17 pm
|
I think you misunderstood me because I talked about solving the scenarios by creating packages. This is perhaps how it would be done from a power-user's perspective. But a novice user can still solve these scenarios in the same way without having to manage packages. The trick is in how CMUD handles the creation of new modules. The way you have it right now is the correct way.
| Zugg wrote: |
| The current way CMUD is working (in 1.04) is that the #WINDOW and #CAPTURE commands create a new Module/Window within the *current* package. This keeps your settings for a single MUD character in a single package file. It's only when you want to generalize some functionality that you'd put it into a package and distribute it. |
This is the way it should work. And it is in line with what I was saying about Scenario A already being solved. A typical user would create a trigger with a #CAPTURE command to capture their tells. When CMUD first comes upon this #CAPTURE command, it creates a new module within the current package (the only existing package for a novice user) with an id/name of whatever is the first parameter to #CAPTURE. Now, think about where the trigger that created this new module. It is within the same package as the new module, but inside the user's "main MUD module" (the module that defines the user's MUD session window). How did this trigger get inside the "Tells" module in Scenario A? It shouldn't be there. Notice that this capture trigger does not capture lines within the "Tells" module. I'll explain why below.
Now the user wants to have certain words within the "Tells" window to be colored in a certain way. In zMUD, you did this by going into the settings for the Tells window and creating whatever triggers you needed in there. In CMUD, this should not be any different (except that the UI makes it easier to do this). The user in this case would go into the "Tells" module within the current (and only) package, and create the coloring trigger there. Notice that by this trigger being inside the "Tells" module, it won't affect other module/windows, since this is where what I was talking about kicks in. Any setting (a trigger in this case) that is inside a module with a window affects only that module.
Let's consider Scenario B now. While this scenario is really simple, you should notice that this is entirely new functionality for CMUD. zMUD users won't go into CMUD expecting things to work like they do in this scenario, so there is no need to make it so a user that knows nothing about packages and modules is able to handle it without still not knowing anything about packages and modules.
Let me explain why this is new functionality. Think about how you would achieve this in zMUD - to have a global setting that applies to all windows. The short answer is, you can't. The long answer is that you can't do it to some extent. The user would have to create a new settings file that contains this global setting and then set this file as being inherited in multiple characters. Now each character window inherits the global setting. But there is still a problem. Capture windows won't inherit from this file, so the global setting won't take effect in these windows. My point is that a typical user won't go into CMUD, create a setting in the main MUD session module, and expect this setting to take effect in all capture windows which are really separate modules within the only existing package. Which leads me to my next point in the following paragraph, but let's quickly give a solution to this problem. Like I mentioned in my first post, the answer is to put this setting in a module without a window. For the novice user, this can be within the one and only package that exists, but they will need to create a new module in order to make a setting that applies to all windows within that package.
Finally, I disagree with the sequence you described for searching for settings. As I was getting to in the previous paragraph, the way you propose is counter-intuitive to how I believe a typical user will expect it to work, even more so coming from a zMUD background. Steps 1 through 3 are fine. This is straightforward and how most new users to CMUD would expect things to work. I have problems with Step 4 because after you've reached the top-most class, there shouldn't be a need to go down in the class hierarchy. I don't have as much a problem with Step 4 as I do with Step 5 however, although I do still find Step 4 unecessary.
Step 5 I believe will go against what many users would expect. As I mentioned before, currently in zMUD, a user created a trigger within the main settings with no expectation that this trigger will fire off of text in a child capture window. So lets assume that a user creates a trigger within the main MUD session module. Why should this trigger affect text that is captured to the "Tells" moule/window? If you think about your idea for creating global trigger that colorizes the word "Zugg", then this seems ok. But think about more complex triggers that people write that they may not want firing off of text that was already sent to a different window. They won't expect this to happen.
So the solution to the above paragraph would most like be to make the main MUD session package "Private" by default. Now you loose the ability to solve Scenario B in the way that you propose and we end up back with my solution - the user has to create a new module with no window that is marked as "Published" and contains this global setting. What about modules with a window created by the #CAPTURE and #WINDOW command? Would they be "Private" by default too? It seems like they must be, because a user certainly wouldn't expect a trigger that is created within the "Tells" module/window to be affecting text that is not captured to this window and is instead left in the main MUD session window. So which modules would be "Published" by default? It seems like it must be modules that do not have a window.
What about the original "Published" option that we had discussed for class folders inside packages (now class folders inside modules inside packages)? It seems that this is what you called "External" in this discussion. Step 6 looks fine then. Once CMUD has failed to find a setting within the current package, it should go to other packages that are enabled for the current module and look inside the "Published" ("External" for this discussion) class folders of its packages. But should it be any module within that package? I still believe it shouldn't look inside modules with windows, since package writers, like a typical user, wouldn't expect a setting that is within a module with a window to be applied to any other window regardless of where it is.
My proposed search algorithm is as follows:
Step 1: Look in the current class
Step 2: Keep going up through the class hierarchy
Step 3: Look in the top level class if reached
Step 4: Look in the "Published" class folders of other modules without windows within the same package
Step 5: Look in the "Published" class folders of other modules without windows within a different package that is enabled in the current module
So in the end, I don't see the need for the extra "Global" and "Private" properties. I can see what you mean about just setting their default values as I proposed in this post but allow power users to modify it, but I don't see why they would want to do that. I can't imagine why a power user would decide to make the settings for a "Tells" capture window/module be global and affect what is happening in their main MUD session window, instead of just putting these settings in a different module. One one hand, it makes for very disorganized settings if you have settings from what is essentially a child window affect main MUD session windows, and on the other hand, the user is already a power user and should know how to make the most of packages and modules. The situation is even worse for novice users that decide to randomly go about unchecking the "Private" attribute from various modules at random. And from a user support point of view, I believe these options would create more support requests by confusing users with the search algorithm for settings you propose, and because of the ones that change the default values of the "Global" and "Private" properties for various modules when they shouldn't have. Even further, helping these users to debug the problem will be a pain, since settings in modules that have these two properties set incorrectly will result in problems that vary wildly from user to user and which cannot be quickly determined to be caused by these two properties.
Then again, maybe you have an extremly good reason for doing it the way you propose that I'm just not seeing and this reason outweights the potential user support problems and potential confusion for users. |
|
_________________
Kjata |
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Thu Aug 10, 2006 5:06 pm
|
Kjata, that was a good post. You might have conviced me.
Basically, what you are doing is replacing the "Global" property with the "Has a window" property. I'm still a bit nervous about tying these two concepts together, but I also cannot think of any exceptions to your rules.
In fact, now you have me thinking that maybe the existing "Published" property shouldn't be at the class-folder level at all. Maybe this should be a Module property. As you said, if settings within a window should not effect anything outside of that window then it doesn't make sense to allow classes within a window to be published. If we force them to create a non-windowed module for their published classes, then we could also say that package producers need to create a specific non-window module to contain their Published settings.
This actually solves the other issue of having a class subfolder buried many levels deep that happens to have it's Published flag turned on. It's probably a bad idea to allow subfolders to do this. You either put it into the Published module, or you keep it in a non-published non-window module. And you don't allow windowed modules to be Published.
Hmm, let me think about this. On the surface it does seem reasonable. You seem to have a clearer understanding of this that I do :)
I'm still a bit nervous about eliminating my original Step 4. Looking in other enabled class folders is what zMUD already does. Seems like it would be a pretty big break in compatibility to get rid of this. Consider the following example in zMUD:
| Code: |
Combat Class Folder
F4 Macro key for doing combat
Non-Combat Class Folder
F4 Macro key for when we aren't in combat |
So we have two different definitions of the F4 macro key. We have scripts that enable and disable these class folders. When we go into combat, the first class folder is enabled and the other is disabled. When we exit combat, the non-combat folder is enabled and the combat is disabled. So our F4 macro is now context-sensitive.
This is a simple example, but I have seen other cases like this where you have aliases with the same name in different class folders where only one class folder is enabled at a time. Since zMUD looks in any enabled class folder for an alias, macro, etc, then this all works great.
CMUD needs to do something like this to maintain compatibility with this kind of script. Using your proposal, they would have to put these two folders into separate modules. You lose a lot of the "tricks" that can currently be performed by enabling and disabling class folders.
Finally, in your step 4, you say "look in the Published class folders of other modules without windows within the same package". I don't think this is quite right. I think it should look in any enabled class folder of other modules without windows, not just the ones with the Published flag.
We need a way to implement a global settings module that effects every window within the current package, but is still *not* published to other packages. So if a module doesn't have a window, then it's considered Global for the current package, but only modules marked as Published can be seen outside of the package.
So here is my modified proposal:
Step 1: Look in the current class
Step 2: Keep going up through the class hierarchy
Step 3: Look in the top level class if reached
Step 4: Look in other enabled classes within the same module (zMUD compatibility)
Step 5: Look in other enabled classes within other modules without windows within the same package
Step 6: Look in other enabled classes within modules without windows marked as "Published" within a different package that is enabled in the current module. |
|
|
|
|
saet
Apprentice
Joined: 12 Jun 2006
Posts: 106
|
Posted: Thu Aug 10, 2006 5:32 pm
|
Reading these discussions hurt my brain.
|
|
Last edited by saet on Thu Aug 10, 2006 5:49 pm; edited 1 time in total |
|
|
|
Kjata
GURU
Joined: 10 Oct 2000
Posts: 4379
Location: USA
|
Posted: Thu Aug 10, 2006 5:33 pm
|
You are right about eliminating the search in other enabled class folders within the same module once it has reached the top class folder. I completely forgot about that, and while it will always seem counter-intuitive to me to go back down the class hierarchy one it reaches the top, the break in compatibility far outweights this oddity. Who knows, perhaps I completely agreed with this before and now forgot why I did in the first place, but since this is the way it already works in zMUD, it needs to work that way in CMUD too.
| Zugg wrote: |
Finally, in your step 4, you say "look in the Published class folders of other modules without windows within the same package". I don't think this is quite right. I think it should look in any enabled class folder of other modules without windows, not just the ones with the Published flag.
We need a way to implement a global settings module that effects every window within the current package, but is still *not* published to other packages. So if a module doesn't have a window, then it's considered Global for the current package, but only modules marked as Published can be seen outside of the package. |
I see what you are saying, and you are right that it would be useful to have something like this. However, I'm not quite sure if it should be this way or not. I keep trying to see this from a novice user's perspective and what this user would expect CMUD to do by default without having to go into more advanced techniques. Would a novice user that creates a new module to put some global settings expect these settings to apply to all windows regardless of what package created it (lets assume an Auction package created another window), or would they expect these global settings in the new module to only apply to windows within that package? Frankly, I'm not sure of the answer myself.
Not having been a novice user for many years now, I would certainly appreciate the power of "global" settings that apply to any window within the current package, and actual global settings that apply to all windows regardless of package. But I can also see how this extra power might confuse a novice user that just wants all lines that contain a certain word to be colored a certain way regardless of what package defines the window (sort of like allowing users to customize third-party packages, if you will.)
Then you have the package writer's perspective. This user is a power user and would love to have a way to define global settings that apply to all of the modules within their package without having to publish them and mess up whatever settings the user of said package might have already defined.
I can't really make up my mind about either of these two options, so I guess I can agree with your modified proposal for searching for settings.
Man, it's really hard trying to design a product that is powerful enough for experienced users but simple enough and intuitive enough for novice users. I don't envy you Zugg when you have to go through this. Although once one is able to find just the right solution, the satisfaction is great.  |
|
_________________
Kjata |
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Thu Aug 10, 2006 6:34 pm
|
Yeah, it's tough sometimes. As Saet said: "Reading these discussions hurt my brain". I feel that way all the time And I don't have any co-workers or teammates to talk about this stuff with. I don't know what I'd do without these forums and the way to talk with users.
Forgetting how the novice user views this stuff is always a problem for me too. And most of the feedback I get early in the beta process is from more advanced users. The way I try to approach it is to work on the functionality first and get it working. Then I can mess with trying to make it more transparent for novice users. It's usually easier to hide the complexity than it is to add the complexity later.
But many times I feel like I'm too close to all of this, but I can't really take a break from it. I still need to be working on improving it and releasing new beta versions. Breaks (like my birthday) are helpful for getting some distance and getting fresh ideas. But these days it really helps to just "think out-loud" in this forum and gather ideas. As you've seen, I often get confused myself and end up making it more complicated than it should be. That comes from bouncing between "high level" forum ideas and then getting into the nitty-gritty coding. Often times something that sounded good on the forum becomes a lot more complicated when I actually try to implement it. Or when I start testing I encounter stuff that I hadn't thought about.
We all have to remember that zMUD itself is a very complex program developed over a long period of time. Even I forget about some of it's options and capabilities sometimes. So when implementing a new MUD client that is supposed to be compatible, it's easy to forget something that zMUD already does. And yet, at the same time, I am trying to add new functionality to CMUD and make the Package system really useful for advanced users. It can be a real challenge.
Anyway, thanks for reading this so carefully and responding so clearly. I think I have it clearer in my brain now, so I'm going back to the implementation and see if it works out this time.
One other thing that I thought about when I was having lunch today: I think I will keep a distinction between "Modules" and "Windows". We keep talking about a windowless-module or a windowed-module. How about we just call these Modules and Windows. Internally in CMUD they are the same thing with a different property set. But from the end-user perspective, it seems to make sense to create a New Window when you want a window and have a New Module function that creates a window-less module. This might help with some of the confusion.
In fact, I can imagine adding a #MODULE command that works similar to the #WINDOW command, except that it creates a new window-less module instead of a window. In fact, the #MODULE, #WINDOW, and #CLASS commands all work in a similar way now:
- #CLASS classname [ enable-flag ]
- Sets the current class to the specified classname. Creates the class if it doesn't already exist. If the enable-flag is present, a value of 1 (true) enables the class, a value of 0 (false) disables the class.
- #WINDOW windowname [ text ]
- Sets the current module to the specified window name. Creates the window if it doesn't already exist. If text is present, then the text is sent to the window without changing the current module.
- #MODULE modulename [ publish-flag ]
- Sets the current module to the specified modulename. Creates the module if it doesn't already exist. If the publish-flag is present, a value of 1 (true) publishes the module, a value of 0 (false) un-publishes the module.
|
|
|
|
|
yejun
Wanderer
Joined: 13 Jun 2005
Posts: 51
|
Posted: Thu Aug 10, 2006 10:31 pm
|
I think the problem is where the root is. Currently you make all module as root in its own context, so for same variable, alias, trigger will have different root when they are used in other module.
My suggestion is make each session as root. So session->(package->)module->class/triggers/alias/variables. As my understanding, current situation is module->package->module->..., that's really not something I could think straight.
For everything share between sessions, it will belongs to a global sessions or a dummy session.
Is everything describled in "Example A" already doable in zmud? If not, maybe it is not necessary for CMUD. I think all those problems come from trigger on captured window. If possible I would prefer triggers work on real mud connection only.
For "Example B", I prefer the opposite. |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Thu Aug 10, 2006 11:10 pm
|
No, yejun, I think you've gotten confused. It's currently package->module. The only thing that can exist in the root of the package is a module/window. Everything else must be within a module/window.
Sessions are something completely different. They are stored in a completely different database and contain stuff like login usernames, hostnames, etc. A session indicates which package files to load (in the Files tab). So, a session contains multiple packages. That's how it already is.
In any case, I have implemented the proposed scoping rules as described above and they are working very nicely now. I also made the distinction between Modules (no window) and Windows and that has cleaned up the user interface a bit. Only Modules can be published, and when the Published option is checked, the icon in the tree view changes to show a P in the module icon, so it's really easy to see what modules are published.
I was able to remove the temporary kludge that prevented child windows from firing triggers. The simple example of:
| Code: |
Tell Window
Trigger {zugg} {#cw red}
Main Window
Trigger {tells you} {#capture Tell} |
works great. And if I add a new module like this:
| Code: |
Color Module
Trigger {zugg} {#cw blue} |
then this works on both the Main Window and the Tell Window. It also works based upon trigger priority. If the trigger in Color Module has a priority number larger than the Tell Window trigger, then the Color Module runs last and all "Zugg" words are colored blue. If the trigger priority of the Color Module trigger is made less than the trigger in the Tell Window, then the Tell Window trigger runs last and Zugg is blue in the main window but still red in the Tell window.
If the Published flag is enabled for the Color Module, then it no longer colors either the Tell Window nor the Main Window since now the module is only published for other packages to use.
The only remaining issue that I can see is the list of packages to enable/disable for modules. Now that we have two types of modules (Windows and Modules), it seems like only the Window needs this list of enabled/disabled packages. It's probably not a good idea to have other packages interferring with non-window Modules. So I think this list of enabled packages should only be given to Windows. |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Thu Aug 10, 2006 11:13 pm
|
Also, making this into a re-useable Tells package also seems to work now. Here is the Tells package:
| Code: |
Published Module
Trigger {tells you} {#capture Tell}
Tell Window
Trigger {zugg} {#cw red} |
Since the Capture trigger is in a published module, it is not executed for stuff in the Tell Window, so we don't get any infinite loops. And when you include this package in a session, you get a tells window that sends any "tells you" line from other windows into the Tell Window.
This is just what I wanted. It's straightforward for normal users, but still easy for package developers. |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Thu Aug 10, 2006 11:16 pm
|
yejun: Example A is already doable in zMUD. In zMUD you can create a MUD file called Tells.mud and any triggers in this file will fire for text sent to the Tells window. There are many situations where you want triggers to run on windows that don't have a MUD connection. People use triggers all the time in other windows to color text, or add timestamps to the text, etc.
|
|
|
|
|
Dumas
Enchanter
Joined: 11 Feb 2003
Posts: 511
Location: USA
|
Posted: Fri Aug 11, 2006 1:09 am
|
and thankfully someone managed to come up with a good idea that you could quickly work with! Yay!
|
|
|
|
|
Tech
GURU
Joined: 18 Oct 2000
Posts: 2733
Location: Atlanta, USA
|
Posted: Fri Aug 11, 2006 1:34 am
|
Well it's takes a MASTER to help a MASTER.  Gooo Kjata. I have to post 15% more that what i currently have to get to 10% of her posts...
Glad it works Zugg... that means the chances of 1.04 next week are getting better. |
|
_________________
Asati di tempari! |
|
|
|
Kjata
GURU
Joined: 10 Oct 2000
Posts: 4379
Location: USA
|
Posted: Fri Aug 11, 2006 2:16 am
|
I'm a he, by the way. But don't worry about it, it happens. 
|
|
_________________
Kjata |
|
|
|
Darker
GURU
Joined: 24 Sep 2000
Posts: 1237
Location: USA
|
Posted: Fri Aug 11, 2006 1:53 pm
|
Don't let her fool you. It's a she.
Mwahaha. :)
I've lurked on this thread (as I do with most others) until the idea seems finalized before I decided to ask: What's the hierarchy of these package/module/window/class/folder concepts? I *thought* I had it down as Package -> Module -> Class -> (Trigger/Alias). But then I started seeing posts that seem to imply Modules could contain Packages. And hell if I know how Windows fit in there at all. I have better recall of the "There's a frog on the log in the hole in the bottom of the sea" ditty (maybe that's because I have kids).
I really think you need to use terms that are more self-evident as to their hierarchy. "Package"? "Module"? "Class"? No inherent description of relationship there. Nothing physical to relate to. You could swap the order of those terms and a newbie wouldn't know the difference. Non-coders wouldn't ever get it until they become specialized CMud coders, and it's cool that we're making techy converts and all, but a new user won't write home enthusiastically about that learning curve.
So in the spirit of half-thought, mostly just for kicks suggestions I've made in the past -- like that whole #MESSage command, heh -- I offer you these fine candidates for alternative hierarchy descriptors (in gradually fewer levels of granularity):
Stadium -> Level -> Section -> Row -> Seat
Store -> Aisle -> Shelf -> Item (I suppose you could tack "Mall" at the beginning if you had to. And city, state, ad nauseum)
Shoe -> Sock -> Toe
Family -> Member (of all of these, this one's the most seriously intended)
I prefer any of these, to "pkg/mdl/cls" except that you still have to reconcile the fixed term of Window with them somehow. And reeeally, they don't have to complement each other, or align themselves with concepts from real programming languages, but how techy-cool if they did. |
|
_________________
Darker
New and Improved, for your Safety. |
|
|
|
Kjata
GURU
Joined: 10 Oct 2000
Posts: 4379
Location: USA
|
Posted: Fri Aug 11, 2006 2:11 pm
|
It is Package->Module->Class->Settings.
The confusion mostly arises that before this topic, a Module could either be a "windowless" Module or a "windowed" Module, and it would still be called a Module. Zugg is doing away with that now and the structure should be:
Package->Module/Window->Class->Settings
So a Package will contain 0 or more Modules and 0 or more Windows, but at least one of either of them. A Module will contain 1 or more Classes, with a root Class existing by default. A Window has the same contents as a Module. And a Class may contain 0 or more Settings as well as 0 more Classes. |
|
_________________
Kjata |
|
|
|
Darker
GURU
Joined: 24 Sep 2000
Posts: 1237
Location: USA
|
Posted: Fri Aug 11, 2006 2:15 pm
|
Gracias
|
|
_________________
Darker
New and Improved, for your Safety. |
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Fri Aug 11, 2006 7:05 pm
|
The terminology probably isn't going to change much. I'm certainly not going to make sweeping changes to it.
"Classes" are from zMUD and will remain the same name for compabitility.
"Window" is pretty clear. People know what a window is and so this should be easy to understand. It is also the same term used in the #WINDOW command in zMUD, so this isn't going to change.
"Module" is probably the only thing subject to change since it is new functionality. A "Module" is a collection of Classes and Settings that does not have a window. It works much like a "Window" except that it doesn't have any visual component.
"Package" probably won't change. A "Package" is a collection of "Windows" and "Modules" that have been "packaged" together into a piece of stand-alone functionality. I think the term "package" is pretty good since it really means the same thing as the word normally means in real life. It's a "black box" of functionality that is wrapped up nicely for others to use. It also corresponds exactly with a single *.PKG file stored on your disk, or in the remote Package Library. |
|
|
|
|
Taz
GURU
Joined: 28 Sep 2000
Posts: 1395
Location: United Kingdom
|
Posted: Fri Aug 11, 2006 9:06 pm
|
Module = BlackHole 
Module = Wall  |
|
_________________
Taz :) |
|
|
|
Dumas
Enchanter
Joined: 11 Feb 2003
Posts: 511
Location: USA
|
Posted: Fri Aug 11, 2006 10:39 pm
|
Package is a good name. My early forays in programming were with Ada and packages are the way it differentiates between functions that do nothing but return a value and functions that actually do something. The name also seemed to be better in describing what ended up being Classes in C and C++.
|
|
|
|
|
|
|
|
|
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
|
|
