 |
| Zugg |
Posted: Thu Jul 27, 2006 6:29 pm
Multiple sessions/packages - Design Discussion |
|
Kjata
GURU
Joined: 10 Oct 2000
Posts: 4379
Location: USA
|
 Posted: Thu Jul 27, 2006 11:29 pm
|
Zugg, I'm sorry that I have to throw in another problem into the issue without providing any possible solutions, but I haven't had time to sit down and think about this whole issue completely. I have thought of a problem with the "smart triggers" feature that you proposed. Let's take the same Auction Package example that redirects text to a single Auction window. If all three characters receive the auction annoucement from the MUD, then the trigger in the Auction Package is invoked three times. However, with the "smart trigger" option, the trigger knows to only respond to the first time it is invoked. Now, suppose all this trigger does is remove the line from the MUD window and display it in the separate Auction window. It would display the auction annoucement only once like we want, but it will also remove the auction annoucement from just one MUD window instead of all three.
|
|
_________________
Kjata |
 |
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Fri Jul 28, 2006 12:00 am
|
Kjata, that's a good point. We want the trigger to #GAG the text from each window, so we really do want it to fire. So maybe this isn't functionality of a trigger, but is perhaps some "anti-spam" functionality of a text window. Might even be considered a useful feature since it would remove other duplicate text, such as multiple blank lines. But thanks for pointing this out...it's certainly not the trigger itself that we need to supress.
Taz, I think I was mostly rambling. I don't like the latter example. I don't like having to load the Health package within each of the other Windows. I'd like it to be global.
But your message reminded me of a common confusion that might be happening: You talked about sessions vs packages. so let me use this example to better distinguish the difference. We are *not* simply loading 3 existing sessions into a single session. The multiplaying session that loads the 3 others is it's very own session. The idea is that you would multi-play often enough to want a single session icon that automatically opens all 3 characters and sets up your layout correctly.
You *might* have individual session icons for each single character, but that's optional, and the only thing in common between the single-character session and the multi-playing session is that they load the same packages.
For example, you might have a "Warrior Single Character Session" and it would load the following packages:
| Code: |
Warrior Package
Auction Package
Health Package |
But your 3-character multiplayer session icon can load a completely different set of packages if it wants. What I'd *like* to see is something simply like this:
| Code: |
Warrior Package
Thief Package
Priest Package
Health Package
Auction Package |
Remember that packages should be mostly standalone. So we wouldn't put the Health package "within" the Warrior package. I'm assuming that we downloaded the Health package from the Shared library and have added it to our session. So the Warrior, Priest, and Thief packages are things we wrote ourselves that are MUD-specific, but the Health Package and Auction Package are more general-purpose packages that we just downloaded from the library and added to our sessions.
So, you can see that in the 3-character session, it is NOT just loading the other single-character sessions. The single-character sessions might not even exist. But the 3-character session and the single-character sessions share the same package (the Warrior package) which contains the command specific to that character on that MUD.
You can see that if we limit ourselves to Package discussions, it's all reasonably clear and simple. It's only when you start thinking about windows within these packages and how windows interact with the triggers, buttons, etc that things get complicated. |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Fri Jul 28, 2006 12:18 am
|
I don't know how many people here have played World of Warcraft and have played with UI MODs for it. I've recently started playing a bit again and have been amazed at how much improved the 3rd party UI MODs are from what they were a year ago. I don't think I could play without them now. They are similar to the full scriptable windows that we are talking about with zApp controls.
But one thing that is nice about them is that for each character you can just click the AddOns button before you log in and enable/disable the MODs that you want to load.
Now it's true that WoW just has a single "window" and doesn't have multiplaying and stuff like that, but I wanted to keep the Package modal simple like this. Maybe "Package" is the wrong word and we should call them "MODs" or "Plugins" or "Addon" or "Extensions" or something like that. But that's the concept I'm going for.
Firefox has the same concept. You open the Extensions window and select which extensions to enable, disable, upgrade, remove, etc. I modelled the Shared Package Library from that.
So, that led me to think that even though we might have this larger list of packages that are installed, we still want to select which packages are enabled for each *window*.
Right now, the Session Icon determines the list of packages that are loaded. But just because a package is loaded doesn't mean each and every window needs to use it. If each window had it's own checkbox list showing what packages are enabled for that window, then this might all work.
In the example of the Health Package, we just make sure that the Auction Window has the Health Package disabled. If we wanted to have a character window that did not have the Auction trigger applied (in other words, we *wanted* to see the auction text and NOT have it removed), then we would just go to the package list for that window and uncheck the Auction package.
Allowing each window to have a list of enabled packages would allow us to keep those packages global, and not need to place packages within windows. It might be easier to implement with the current CMUD code.
Right now, when you type a command in the command line, CMUD searches *all* packages for global aliases (or aliases within Published class folders) that matches the text. There is no way to enable or disable which packages are searched. If we implemented this package list for each window, then typing a command would only search the packages enabled for that window.
For example, we could make our "Weapon Package" and "Spell Package" global, and then just set the WarriorWindow to enable the WeaponPackage and set the PriestWindow to enable the SpellPackage. The windows would NOT "own" the packages...just determine which ones were enabled for a specific window.
So, now Kjata's 3-character example becomes something like this:
| Code: |
Auction Package
AuctionWindow (Enabled: self (Auction) is always enabled)
Health Package
Weapon Package
Spell Package
Warrior Package
Warrior Window (Enabled: self, Auction, Health, Weapon)
Thief Package
Thief Window (Enabled: self, Auction, Health, Weapon)
Priest Package
Priest Package( Enabled: self, Auction, Health, Spell) |
OK, now I'd still need to make sure that these packages can properly create/access variables that are *local* to the package that is currently executing. So when a line from the WarriorWindow is being processed by the HealthPackage prompt trigger, it would create @HP and @Mana within the WarriorPackage. But I think I can do that.
This also allows CMUD to determine which buttons get displayed in which windows. In this case we have Gauges in the Health Package and they get displayed in any window that enables the Health Package. So we don't get any buttons in the Auction window, just the Warrior, Thief, and Priest windows. And if CMUD is smart, then when it displays the button, it will evaluate the button caption and commands based upon the variables within the specific window. So the HP Gauge within the Warrior Window would display the @HP variable within the Warrior Package, and the HP Gauge within the Priest Window would display the @HP variable within the Priest Package.
So, we are back to the case where windows do not "own" any packages or settings. They simply maintain a list of packages that are enabled for that window. I think this handles the many<->many relationship that I was looking for. Before I was trying to force stuff into a simple hierarchy and it wasn't working.
How does this sound? Please try to think of any problems with this proposed setup. |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Fri Jul 28, 2006 12:25 am
|
Hmm, I guess I just violated one of my original rules. I just modified the WarriorPackage, and I originally said this was bad. Because back in our single-character session, we also load the WarriorPackage and within the WarriorPackage we have the WarriorWindow and it has a list of packages to enable/disable. According to our above example of the 3-character session, the WarriorWindow is set up to enable "self, Auction, Health, Weapon". But in the single-character situation, what if we don't have the same set of packages loaded?
Maybe it can just ignore a package that is enabled but not loaded? Or maybe it can prompt you to load that "dependent" package and then add it to your session list?
But the problem is that if we wanted to distribute our WarriorPackage to someone else, we would have this list of dependent packages that the other person using our WarriorPackage might not care about.
So, this is either a problem, or an opportunity to explore how we deal with dependent packages.
Or, maybe we somehow store the list of which packages are enabled for which windows in the session icon along with the list of loaded packages? |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Fri Jul 28, 2006 12:29 am
|
Ahh, I'm liking this idea more and more.
When thinking about the "child windows" that we just use for #capture, we simply have a window that removes the "self" reference so that triggers in the parent package are not fired. So, for a simple session we have this:
| Code: |
My MUD Package
Main MUD Window (Enabled: self (this means the settings in My MUD Package))
Tells ChatWindow (Enabled: none)
Triggers
these triggers would only fire on the Main MUD window because that's the only window with "self" enabled. |
Of course, I wouldn't call it "self" in the user interface. The user interface would probably display the "My MUD Package" instead so that it was obvious which triggers were being enabled or disabled for a window. |
|
|
|
|
Taz
GURU
Joined: 28 Sep 2000
Posts: 1395
Location: United Kingdom
|
Posted: Fri Jul 28, 2006 12:46 am
|
| Quote: |
| But your message reminded me of a common confusion that might be happening: You talked about sessions vs packages. so let me use this example to better distinguish the difference. We are *not* simply loading 3 existing sessions into a single session. The multiplaying session that loads the 3 others is it's very own session. The idea is that you would multi-play often enough to want a single session icon that automatically opens all 3 characters and sets up your layout correctly. |
Whoa, not how multiplaying works now in zMUD, people will be used to having three icons and open each of them, especially for the auto login. If they have any sense they will be doing that since you can have the Inherited .mud file set to the one that has common settings in and the Primary .mud file set to the one that has the char specific settings. If you think people are going to do what you said above this is total alien to the way it was in zMUD and only one char will login automatically, in fact where the hell are your three network streams coming from?
| Quote: |
| SessionWindow: This is the main MUD window that you see at startup. It typically has a command line and a MUD output region. It might have a status bar, and various toolbars. It is connected to a network socket to a specific MUD host and port. |
As far as I know at the moment it is impossible to get a character icon to open 3 SessionWindows each connected on it's own network socket to the same MUD host and port.
|
|
_________________
Taz :) |
|
|
|
Seb
Wizard
Joined: 14 Aug 2004
Posts: 1269
|
Posted: Fri Jul 28, 2006 12:50 am
|
| Zugg wrote: |
4. Perhaps CMUD could be made somehow "smarter" so that triggers ignore multiple exact lines from the same host/port. Especially if the data stream was somehow "timestamped". Seeing the exact same text string at almost the same time from multiple sources should be a clue that the text should only be processed once.
This could be made into some sort of trigger option. "Don't process duplicate lines" or something like that. Each trigger would just store the last few lines that were processed along with their time stamps and could decide not to process duplicate text. |
I thought of the exact same idea when I had finished reading your first post, except is there really any need for this to be stored on each trigger? It should really be a property of the Window object. (See below for more background info.)
| Zugg wrote: |
| But thanks for pointing this out...it's certainly not the trigger itself that we need to supress. |
No, it's just the #CAPTURE part of the trigger, i.e. the part that displays information. So actually is could be part of the Window object. The Window option could be called "Don't display duplicate lines". (See below for more on Windows.)
| Zugg wrote: |
While I'm on a roll, let me "think outloud" about the ChatWindow problem:
Currently in CMUD, when you use the #WINDOW or #CAPTURE command the first time, it looks for a package or MUD file with the same name, just like zMUD did. So, if you do
and there was a Tells.pkg or Tells.mud file, then it will try to do this:
| Code: |
Default Package
MUD Character Package
Main MUD SessionWindow
Tells.MUD Package
Tells ChatWindow |
|
I don't think this actually replicates zMUD behaviour very well. In zMUD, when you use the #WINDOW or #CAPTURE command the first time, it creates a ChildWindow of your SessionWindow, which will be for a specific character. Therefore this makes more sense to me:
| Code: |
Default Package
MUD Character Package
Main MUD SessionWindow
Tells.MUD Package
Tells ChatWindow |
This means that the default behaviour is now for each session (character) now has their own Tells window. This makes sense - tells are character specific. So are most other things, although not all - it's still a better default setup than the current one IMHO, and is nearer the behaviour that you get if there was no Tells.pkg or Tells.mud file.
| Zugg wrote: |
| In fact, when you click on a window object in the settings editor, the right-panel should probably be showing the preference options for that window object. |
Yes, actually this is what I was envisioning in CMUD back when we had the previous discussion on this. I think that instead of having one "Preferences" button, preferences (which are really properties) should be accessible from the Settings Editor (they are still settings afterall). This is much more logical and you can have preferences / properties applying to the object that they are most suitable to apply to, whether that is a Window object, a class or a whole package. It's a shame because the new Preferences Editor is well designed, graphically, but maybe some of this graphical design and the inheritance code can be reused.
| Zugg wrote: |
| So, here is a case where we have BOTH: A package owns some windows, but then those Windows own their own settings (which you can think of as the window owning a package). |
| Zugg wrote: |
| And the window is acting sort of like a class folder... |
Exactly what I was started thinking several posts previous! What we need is a special type of class folder that is a Window and therefore has a ton of other properties / preferences. But since it's still a class folder, you can still nest triggers or aliases or buttons underneath it. And it's all nicely self-contained in the one package.
I'm afraid I only skimmed the second page of this thread and haven't read the third page yet (it keeps growing while I'm reading and typing!) |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Fri Jul 28, 2006 12:57 am
|
Seb: Heh, keep reading :) I think things get improved in the later posts. But about the Tells Chat window issue, the reason it doesn't put it into the current package like you suggested is that a) Packages cannot contain other packages at this time, and b) if the Tells Package was within the "MUD Character Package" than the original CAPTURE trigger in the MUD Character Package would fire on text in the Tells Window, causing the infinite capture trigger loop that we are trying to fix. In any case, I think it works fine as a global Tells Package rather than specific to the MUD Character Package.
Taz: I've been talking more about how I *want* it to work, as opposed to how it does or doesn't work currently. I never liked the requirement in zMUD of having to make a single session icon for each character before I could multiplay. I wanted to just connect to the MUD, then add a new connection window for the 2nd character, then another connection window for the 3rd character and then save the entire thing as a session.
In CMUD, SessionWindows have the capability of connecting to different host/ports. The network connection is now a property of the *window* and not the session. So having 3 different windows each connected to a different host/port (or the same host/port) is possible in CMUD even though it wasn't possible in zMUD.
Auto login works the same as it always has. Each window has it's own host, port, character name, password, proxy settings, etc. So the same autologin trigger that fires for the first window will fire for all of the windows when they connect, and the #CHAR and #PW commands will send the username or password for the window being connected. So the single "global" autologin trigger works for all windows. |
|
|
|
|
Taz
GURU
Joined: 28 Sep 2000
Posts: 1395
Location: United Kingdom
|
Posted: Fri Jul 28, 2006 1:07 am
|
Ah there we go you see, this is where I've been having trouble keeping up with you, would it be too much to request if you can mark these things as how it will work rather than does, or shall we all assume that from now on anything discussed in this thread is theoretical and is how we would like things to happen?
|
|
_________________
Taz :) |
|
|
|
Taz
GURU
Joined: 28 Sep 2000
Posts: 1395
Location: United Kingdom
|
Posted: Fri Jul 28, 2006 1:08 am
|
Oh and I really should get to bed, it's now gone 2am 
|
|
_________________
Taz :) |
|
|
|
Taz
GURU
Joined: 28 Sep 2000
Posts: 1395
Location: United Kingdom
|
Posted: Fri Jul 28, 2006 1:09 am
|
| Quote: |
| Auto login works the same as it always has. Each window has it's own host, port, character name, password, proxy settings, etc. So the same autologin trigger that fires for the first window will fire for all of the windows when they connect, and the #CHAR and #PW commands will send the username or password for the window being connected. So the single "global" autologin trigger works for all windows. |
and the usernames and passwords will be stored as settings in the SessionWindows packages?
|
|
_________________
Taz :) |
|
|
|
Kjata
GURU
Joined: 10 Oct 2000
Posts: 4379
Location: USA
|
Posted: Fri Jul 28, 2006 2:34 am
|
I like the idea of each window specifying which packages are enabled on them. It's more natural that way.
I do see a problem though. One of the uses for packages is to create libraries that others can use to build more complex scripts/packages. Now, would a library loaded by a session be automatically enabled on all windows unless the window specifically disables it, or would it default to be disabled unles the window specifically enabled it? If the latter is the case, then the usefullness of packages that serve as libraries would be diminished since it wouldn't appear as if the package is acting as a "mod" for CMUD. However, if the former is the case, then the user is inconvenienced by always having to disable certain packages for each new window that is created.
Then we also once more run into the problem of dependent packages. What happens if the user disables a package in a window that is needed by another package? Right now CMUD has no way of knowing this has happened, since packages don't know their dependencies.
Finally, I agree that the enabled/disabled info for each package in each window should be stored along with the session and not inside the packages. This would allow for different combinations of packages in different sessions and not force the packages to be aware of each other. |
|
_________________
Kjata |
|
|
|
TonDiening
GURU
Joined: 26 Jul 2001
Posts: 1958
Location: Canada
|
Posted: Fri Jul 28, 2006 2:55 am
|
Skimming quickly, I've always sorted things out by the window I look at.
I'd prefer to think of from the view point of this window controlled these packages. If this windows #cap's stuff to another window well then that window and its packages can deal with it.
I'm running zMud connected to 4 MUDs - 2 Immortal & 3 Players windows. Player windows are button heavy. A bunch of docked multi-tabbed windows watch communication and messages. I focus myself in the 5 main windows of which there are 3 with multi-tabbed.
So if I wanted a health package, I'd load it seperately into the window of the 3 players. |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Fri Jul 28, 2006 3:09 am
|
| Quote: |
| shall we all assume that from now on anything discussed in this thread is theoretical |
Since hardly anything related to multiple sessions works at all in CMUD, I had assumed this entire discussion was theoretical. Also, since zMUD doesn't have packages, we can't really rely upon how zMUD works (or doesn't). The whole idea of the thread was to post the problem and then discuss possible solutions.
| Quote: |
| usernames and passwords will be stored as settings in the SessionWindows packages? |
No. Like the proposed list of which packages are enabled for which windows, certain window properties, such as the username and password are also stored in the session database. I didn't want someone accidentally sending a package to a friend and then realize it had their password in it ;) I really *do* try to think of this kind of stuff.
Kjata: You raise an interesting problem. Perhaps one of the options for a package should be whether or not it is enabled by default. "Libraries" of routines would be enabled by default, but packages that created things like buttons would be disabled by default.
I also agree that I'll eventually need to figure out how to deal with dependencies. But I've been ignoring this for now because I think it is theoretically straight-forward. I think each package just needs a list of the packages that it depends upon and the CMUD just keeps track and warns you if you try to remove a package that others depend upon. But for a while I can put that burden upon the user. Probably something I have to add before the public release, but it's not a design mind-block the way this window/session stuff is.
TonDiening: I think the way it would work from a UI point of view is that you'd select one of your Player windows, then choose to add the Health Package. This adds the Health Package globally, but only enables it within the Player window that you had selected. Then, either it displays a list of windows and asks you which other windows you want this newly loaded package enabled for, or else you select each other Player window and enable the Health package for that window.
So, you'd still just have a single global Health package, with it enabled by 3 windows. You wouldn't need to care that packages can't contain other packages or that packages are not owned by windows. If a window has a package enabled, then in a sense that window "owns" it, but this method allows multiple windows to enable and share the same package.
I still have to think about the "instance vs static" issue and see how that works. Obviously if a shared package has a button, then each window that enables that package needs some sort of "instance" of that button, otherwise every window would share a single button with a single caption. |
|
|
|
|
Kjata
GURU
Joined: 10 Oct 2000
Posts: 4379
Location: USA
|
Posted: Fri Jul 28, 2006 3:30 am
|
| Quote: |
| I still have to think about the "instance vs static" issue and see how that works. Obviously if a shared package has a button, then each window that enables that package needs some sort of "instance" of that button, otherwise every window would share a single button with a single caption. |
I think only variables need to have this "instance/static" property. A button should execute the same action regardless of the window that has its package enabled. Hoever, the button could make use of "instance" variables to refer to things that are specific to that window. This wouldn't be only for the commands the button execute, but also for a variable that may be used for its caption or to hold its current state.
So when designing a package, you would mark a variable as either being a "static" variable or an "instance" variable. CMUD would then make sure to keep a separate copy of an "instance" variable for each window that has the package enabled, while "static" variables would be shared by all windows that have the package enabled. |
|
_________________
Kjata |
|
|
|
TonDiening
GURU
Joined: 26 Jul 2001
Posts: 1958
Location: Canada
|
Posted: Fri Jul 28, 2006 5:03 am
|
How much would be dependant on usage?
The sample idea of push button -> loot corpse is one thing. I use buttons as dashboards. They have variable text, variable color/guage, variable id's to change its value.
From a management point of view for a user: adding the complexity of clicking instance/static might not be desirable?
I suppose it would depend on the package "install wizard" when a user downloads it. |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Fri Jul 28, 2006 6:31 am
|
Actually, Kjata is correct. The button *definition* is fixed. The caption and the action are static. It just needs to evaluate the caption in the context of the proper window. This means that the button can't cache it's caption value like buttons do now, or else it needs to store the cache within the window instead of within the button. Otherwise the button would need to re-execute the caption each time it is repainted, which is slow.
So, from the user's point of view, it's simple and static, but from a coding point of view it's more complicated. But that shouldn't be a problem.
And just marking variables static vs instanced is pretty much the way I see it to. It's up to the package designer. Novice users who are just using variables normally can easily ignore this option.
I can also see possibilities where a package might create aliases at runtime within the window rather than within the package, but that should be easy to handle too. So far I agree that variables seem to be the only things that might need to be instanced. I'll have to sleep on it. |
|
|
|
|
mr_kent
Enchanter
Joined: 10 Oct 2000
Posts: 698
|
Posted: Fri Jul 28, 2006 6:43 am
|
Brainstorming follows...
What if each package had access to the raw mud output and each package's triggers could be set to flag portions of the output as exclusive, shared, or ignored and then each package could be prioritized by importance.
The auction package would flag all auction text as exclusive and the main session window would never know it was sent. No gagging, no triggering in the main window...faster?
Basically, the main session window would receive whatever text is left over after packages have their way with the MUD output.
This seems like the cleanest, most straight forward way to me. Don't know if this is possible or not and I'm sure I'm not thinking of somethings, but is this a valid thought? |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Fri Jul 28, 2006 7:45 am
|
Mr_Kent, that is a very interesting idea! Let me think about that a bit more.
No, I haven't gone to bed yet ;) While I was in the "Shrine of Wisdom" (the shower) I had some more interesting thoughts about this subject.
I got a really crazy thought...
| Quote: |
| Is a Window really just a Package? |
Think about this for a minute. What if a package just had a flag that said "Create a window for this package". Packages that are just Libraries of useful routines would have this option turned off. But all of the other Packages we have been talking about would have it turned on. This essentially merges the primary window within a package within the package itself.
This also greatly simplifies the Preferences mess. No need to distinguish between window options and package options if a window and a package are the same thing!
Here are some examples that simplify our current scenarios:
Scenario A : Single MUD window
This is simple:
| Code: |
Main MUD Window
Triggers
Aliases
Buttons... |
Now, add a chat window. If a window and package are the same, then we are adding a new package, like this:
| Code: |
Main MUD Window
Triggers
Aliases
Buttons...
Tells Window
Triggers to recolor and timestamp tells |
This also solves another problem. If the #WINDOW command just created a second window (called Tells) within the main MUD Package (like it did before), then imagine the pain of the user when they want to add special color or timestamp triggers to the Tells window! Either the window needs to contain settings (which is hard to implement), or the user would have to create a new package, drag the Tells window into the package, then add the triggers to the package.
But with this new method, they wouldn't have to do that. The Tells window would be made into a global package from the beginning. It would never just be created within the Main MUD Window object. After all, the Tells window really *is* a global window...any other session window or script can access it via the :Tells: syntax. So it doesn't really "belong" to the Main MUD window.
Scenario B : Multiplaying
Using our 3 character example, we would get something like this:
| Code: |
Auction Package (window enabled)
Capture trigger (maybe based upon what Mr_Kent suggested)
Triggers to recolor and timestamp the window
Health Package (no window)
Instanced HP and Mana variables
Trigger to extract HP and Mana from prompt
Gauges for HP and Mana
Weapon Package (no window)
Aliases for weapon users
Spell Package (no window)
Aliases for spells
Warrior Window (package with window)
enables Auction, Health, and Weapon packages
Thief Window (package with window)
enables Auction, Health, and Weapon packages
Priest Window (package with window)
enables Auction, Health, and Spell packages |
Seems nice and clean. We get rid of a bunch of duplicate stuff. Before we had stuff like "Warrior Package, Warrior Window". Now those just get combined.
Multiple windows
OK, so this works the vast majority of the time. The only time it doesn't work is when you need multiple windows within a single package. When does this happen? Not very often. Which is why I like this method since it makes the majority of the cases simpler and leaves the complexity to a small minority.
Remember our AuctionPro Package that had two docked windows? That's an example of a single package (a single download from the package library) that contains multiple windows.
How would we handle this? Well, I think the easiest way is to allow a package *file* to contain multiple packages/windows within it. This is easy to implement. Right now, each package is assigned to a particular *.PKG file. It would be easy to have multiple packages pointing to the same *.PKG file. So, while you would only download a single "Auction Pro Package" file from the Shared package library, the actual contents of this file would look like this:
| Code: |
Auction Log Window (package with window)
Trigger to capture auction text from MUD stream
Triggers for color and timestamp
Auction Command Window (package with window)
(command line enabled)
Button for auction command
Aliases for auction command |
So, we have a single package file with 2 windows.
Now, this terminology could get a bit confusing. I propose that we reserve the term "Package" for the actual *.PKG file. Then, we use the term Module for each top level element within the package file. So in the above example, we have the "Auction Log Window" MODULE and the "Auction Command Window" MODULE loaded with the "Auction Pro PACKAGE".
If you have a Library of useful routines, you could group them into MODULES like this:
| Code: |
Math Routines
Functions for performing useful math
Network Routines
Functions for accessing the web |
and store both of these modules into a single "Zuggs Useful Routines" PACKAGE which can be placed into the "Package" library.
So, instead of getting too confusing, a Package refers to a PKG file, and a WINDOW becomes a MODULE. A MODULE has an option whether or not to create a WINDOW as part of it. Each Module can have one and only one Window.
Does this work? It certainly seems like it's the SIMPLE solution that I was looking for. It somehow feels right. But it might also just be late and I might just be brain dead, so let me know if you think of another problem with this solution. |
|
|
|
|
shalimar
GURU
Joined: 04 Aug 2002
Posts: 4692
Location: Pensacola, FL, USA
|
Posted: Fri Jul 28, 2006 8:27 am
|
It makes sense to me. I like it. But I do have one question.
Would having the windows be modules solve the problem of multiple sessions using the same named 'child window' module? |
|
_________________
Discord: Shalimarwildcat |
|
|
|
yejun
Wanderer
Joined: 13 Jun 2005
Posts: 51
|
Posted: Fri Jul 28, 2006 11:57 am
|
What about a window need to be created on the fly?
I think the interface for package writer is not necessary to be kept as simple as the end user interface. It can be no interface at all.
A package just need to know a few set of system event like loaded, new session, session closed. During each event, a simple initial script will be used to create a window on the fly with all kinds of window properties, fonts, size, location, name. More window can be created and destroyed at anytime as well. Do you expect end user to set all kind preference for every new window opened? I believe it is the task for script writer to make all those window look good. When a session closed, package unloaded, a similar script will do something like save a window location, size, fonts, etc as variables or use save layout command which can be reused during window creation.
If you make a window linked to a module, what happens if I use a capture command? A new module is created automatically? Where this module belong to, where its settings go? If I close that window lately, that module disappeared? |
|
Last edited by yejun on Fri Jul 28, 2006 12:11 pm; edited 3 times in total |
|
|
|
Taz
GURU
Joined: 28 Sep 2000
Posts: 1395
Location: United Kingdom
|
Posted: Fri Jul 28, 2006 12:05 pm
|
| shalimar wrote: |
| Would having the windows be modules solve the problem of multiple sessions using the same named 'child window' module? |
Yes it would if we go with the idea that each session is in effect a new instance of CMUD.
When zMUD first started out it came up with the empty window and then eventually you went to showing just the character/session screen is there any chance that CMUD will go the same way? It's just that for some reason and I don't know what it is showing an empty window at the start seems wrong to me. |
|
_________________
Taz :) |
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Fri Jul 28, 2006 4:35 pm
|
Mr_Kent: I thought about your idea a bit last night. There has always been a big reason zMUD didn't fire triggers on "raw" MUD input...raw MUD input contains all sorts of control codes, MSP, MXP, etc that you don't want to mess up the triggers. In fact, some MUDs put useless control codes within words just to mess up clients that do this for triggers. That is why we have always triggered on the final text that is being displayed.
Now, I have other methods to deal with the issue of gagged text still getting displayed for a moment and flashing, so let's not worry about that problem. But your idea really isn't any different than having a trigger execute the #gag command and stopping later triggers from seeing it. What we might be talking about is a different kind of #gag command that instead of just removing the text from the window, actually prevents other triggers from firing on the text. Right now, text is gagged at the end of the trigger loop, which gives you a chance to #ungag something in a later trigger. But I can certainly add a command or option that stops any other trigger from seeing it.
We already have a bit of this with the new "stop processing" option, which stops other triggers in the same package from firing. I'll have to think about whether I want to allow you to stop *all* triggers from firing, since this means one package could really interfere with another.
We already have trigger priorities, so there is already a welldefined way to control trigger order. And it's not the "package" that has access to the MUD stream, it's only the *triggers*. Remember that in the 3-character scenario, we haev *three* MUD streams, one for each character. Triggers already handle all of this, so I don't see any need to get packages more involved. In a sense, they already are since it's the triggers that care about the MUD stream.
Shalimar: Let's clear up the terminology a bit. If you open two different session icons then it's like running two copies of CMUD...the sessions do not interact at all and so all of there windows are independent. If you are talking about Scenario B or C where we have different windows connected to different network sockets, then remember that we are just running a *single* session icon, and it's the session icon that determines which packages are loaded.
You can list a package more than once in the session list. Then you can enable/disable which packages are active for which windows. I think CMUD will handle multiple packages and windows with the same name, but it might get confusing in the settings editor, and certainly there would be confusion using the :WindowName: command line syntax since it will just pick the first window that it finds with that name.
So I think we decided that it would be a bad idea to have multiple windows with the same name. And this would only happen if you listed the same package more than once in the session files list, which I don't expect people would do. |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Fri Jul 28, 2006 4:51 pm
|
yejun: I think you might still be thinking about scriptable windows, which don't exist yet and are really outside of this discussion. Scriptable windows are completely different objects. It's a terminology problem since everything seems to be a "window", but right now we are talking about session windows and not scriptable windows. Session windows are the same as modules, so yes, when you do a #capture command, a new module (window) would be created. All modules exist at the top level of the settings tree. By default, this new module would not have any other module enabled. I'll probably add some scripting commands to control the enable/disable list for a module.
And yes, if the user closes a window, the module for that window would also go away.
Taz: I made the change in how the startup window is shown for several good reasons. First, it makes CMUD work more like other Windows software. When you run MS Word, you get a blank document. When you run Excel you get a blank spreadsheet. When you run DreamWeaver you see the blank work area. When you run Delphi you see a blank project/form. With CMUD, you get a blank session window. It's easier for people to understand that if they want to work with this blank, default session window that they can just close the session icon selection window.
For example, in CMUD you can click the X button for the selection window, and then immediately just type #SESSION Host Port just like you might expect for a telnet client where you don't care about saving sessions. It allows you to open the mapper, or database module, or settings editor to work on files without opening a session first.
It's a lot more intuitive than remembering that you need to press ESC in zMUD to open a blank session. And for the majority of people who want to run a session icon, CMUD can open your session faster since the UI is already created for the main window.
If you look at the mouse clicks or keystrokes, CMUD *works* exactly the same way as zMUD. So people who have memorized certain keystrokes or mouse actions shouldn't care about the difference. The difference is all visual. With CMUD, it's more obvious that you have opened a program, and it's more obvious how you get to the blank session window. It was the combination of this and the fact that opening a blank session made CMUD work more like other Windows programs that made me make the change.
It also allowed me to remove several kludges from zMUD. Delphi has the concept of the "MainForm". The MainForm is displayed automatically when you run a Delphi program. In zMUD, I had to perform some tricks to prevent the MainForm from displaying. Delphi still creates the MainForm, but it gets hidden and then zMUD displays the Character Selection form instead. Depending upon what the user does, then the MainForm is displayed. If you Quit from the Character Selection, I had to perform some tricks to allow zMUD to shut down properly even though the MainForm had never been displayed. The code was a mess.
CMUD works the way Delphi intended. The MainForm is displayed, and then the Session Selection dialog is displayed on top. You can just click the X button in the corner of the main application window to close it, and this closes the MainForm and Delphi is happy.
Also, zMUD had to duplicate some stuff in the Character Selection menu. For example, some people needed to set their network Proxy settings before they could connect to a MUD. So zMUD had an Options menu that brought up a "subset" of the Preferences dialog. CMUD doesn't need to duplicate this. If you want to change the Proxy settings, you just click the main Prefs button in the main toolbar, just like you normally would. CMUD also doesn't need to duplicate stuff in the Help menu for entering your license key and stuff like that. It makes the Session Selection window a *lot* simpler since it doesn't need to "pretend" to be the MainForm when you start CMUD.
So, there are lots of reasons for the change. I haven't really heard of a reason to do it the zMUD way except that CMUD just feels different and change always takes some time to get used to. |
|
|
|
|
yejun
Wanderer
Joined: 13 Jun 2005
Posts: 51
|
Posted: Fri Jul 28, 2006 6:45 pm
|
So do you mean I cannot change font for the captured window?
In zmud it seems I cannot do it. In cmud the behavior is unpredictable. |
|
|
|
|
|
|
|
|
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
|
|
