Zugg Software :: View topic - Multiple sessions/packages

Posted: Thu Jul 27, 2006 6:29 pm

OK, I think I've run into a real design problem. So I'm going to use this thread to "think out loud" and maybe the resulting discussion will help me figure this all out.

Remember when I posted a thread asking about windows and packages and whether windows should own packages or whether packages should own windows? Well, it seemed like an easy choice at the time, but I think now everyone is starting to realize how much more complicated this all is.

So, lets look at this whole issue with multiple windows and multiple sessions and see if we can sort it out. Warning, this is going to be a LONG post.

First, let's create some definitions for different types of "windows" so that we can all use the same terminology. Otherwise we will get hopelessly confused.

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.

ChatWindow: This is a window that is used to capture text from the main SessionWindow. Typically created using the #WINDOW or #CAPTURE commands. It has a text output region, and might have a command line. It might have pre and post text that is combined with the command line to send chat commands to a specific person or chat channel. It is typically connected to the same network socket as the main SessionWindow. I also sometimes call these "ChildWindows", since they inherit the network connection from their parent SessionWindow.

CustomWindow: This is a customized window created with a zApp ZML text definition. It can contain different controls, such as buttons, text boxes, etc. A subset of this window is the "StatusWindow" which can contain text items added with the #STWIN command. These windows do not typically have a network connection.

ModuleWindow: This refers to the windows of various modules, such as the AutoMapper, Editor, Database, and Settings/Package editor. These are still windows that can be docked, but they are for a specific purpose. Currently, CMUD only allows a single instance of these windows. For example, there is a single Settings flyout window.

I design software based upon analyzing different types of usage scenarios. So let's look at some common ways someone might want to use CMUD:

Scenario A: Novice MUD Player :

Creates a single SessionWindow. Uses the default layout of the various ModuleWindows. Might create a simple ChatWindow for capturing Tells. Does not multiplay. They want the layout of their windows to get saved and restored automatically. They don't want a lot of complexity.

Scenario B: Multiplaying on the same MUD :

Connect to a specific MUD host. But have multiple windows connected to the same host logged into multiple characters on the same MUD. Each character has it's own SessionWindow with it's own socket connection. There might also be multiple ChatWindows. Again they want the layout of their windows to get saved and restored automatically. This is a common setup and when they play this MUD, they always play with this setup and multiplay all characters at the same time.

Scenario C: Admin of multiple MUDs :

An Admin wants to be able to connect to multiple MUD hosts and monitor them all at once. However, the list of hosts being connected might change. In other words, connecting to a single session icon doesn't cause a whole bunch of SessionWindows to be automatically created (as in Scenario B). Instead, you get a single SessionWindow, and then, perhaps, have a pulldown box of other "favorite" sessions. Each time you select a host from the Favorites list, a new SessionWindow is opened to that MUD host. You do NOT want to automatically save the layout since each time you might want to connect to a different set of hosts (If the hosts are always the same, then you simply have an extension to Scenario B where each SessionWindow is connected to a different host). However, you don't tend to have a fancy layout for each MUD host. You just want each MUD host to go into it's own text window.

Scenario D: Full Multiplaying on Different MUDs :

This is the most complex scenario. In this case, you already have a session defined for each MUD that you play. Each MUD session has it's own saved layout with multiple windows. What you want to do is play multiple sessions at the same time. This would be just like running multiple copies of CMUD. Each session has it's own layout. There is no interaction between the sessions.

OK, that list of scenarios goes from simplest to more complicated. Let's look at some of the complications.

Packages

Each session has a list of packages to be loaded. This list is defined when you click the Edit button for a session and go to the Files tab.

* Scenario A just has a single session, so that's easy.

* Scenario B is also really a single session with just multiple windows. You still have a single list of packages you want to load for this particular multiplaying MUD. However, in this case you want the individual SessionWindows to own their own settings. For example, a SessionWindow playing my Warrior will have different triggers, aliases, and macros from a SessionWindow playing my Priest. I might have some common MUD-specific commands that are valid for all SessionWindows. So it seems like you'd want a structure something like this:

Wanderer Joined: 13 Jun 2005 Posts: 51

A few wild ideas.
1. All kinds of windows should be unified into scriptable forms. Every new session default own one form with one output component and one input component.

2. Specific Mud output and message by #cap will be sent to a named data stream, which is not necessary to be displayed at all or can be displayed on multiple windows.

3. An ansi display output component can be placed anywhere on a scriptable form, it should have a named input or multiple input to catch data from a named data stream. So all display related settings, fonts, colors etc will be saved with a scriptable form.

4. Packages are just readonly classes. Packaged owned form is dockable to a session owned form.

5. Session editor own the root of all packages, downloaded packages look like subclass of the root.

6. A user defined class can be exported to a package. Forms (not the session form) become user data can be put in a class. A downloaded package can be cloned to a class and become editable.

7.The whole interface will be consist of session owned forms only. A session form can contain package form, input and output components.

8. Package data and forms should be instanced/not shared by different sessions.

9. To display common data on different form, put a output component on each form to catch the same data stream.

I think 8 is the most important features I like to see in next version. My idea is to separate data, logic and representation as much as possible, settings are hierarchic stored.

Posted: Thu Jul 27, 2006 8:24 pm

Well, I'm not about to rewrite the entire application from scratch (again) Wink

But actually, behind the scenes things are not very different from what you are mentioning. The problem is that your idea still doesn't solve the issue.

The issue is that the AUCTION package is where the #CAPTURE trigger is defined. Your idea of named data streams is interesting, but it is still the AUCTION package that would need to define this data stream (like "AuctionDataStream"). The window to display this data stream (AuctionWindow) is still defined as part of the AUCTION package.

So you still have the problem of how to tell it which other windows need to be connected to this stream. In the example that I gave, how to you tell the Warrior Package to process the Auction trigger, but prevent the Priest package from sending duplicate data, WITHOUT modifying either the Warrior or Priest packages?

In other words, you have the AuctionWindow set up to display data from the AuctionDataStream. And you have the #capture command set up to send anything that looks like "* auctions: " to the AuctionDataStream. But how to do you tell the Warrior window to activate this #capture trigger? You can't put the #capture trigger within the Warrior Package because it has no knowledge of Auctions. Somehow, only the Auction Package can have the #capture trigger and somehow there needs to be a way to tell it which windows to capture data from.

But specifically:

1) That is what the "CustomWindow" is all about. This isn't implemented yet, but is planned before the beta. Whether or not a window is scriptable doesn't matter right now for solving this problem.

2) DataStreams are interesting concepts, but there still isn't a way to tell which windows need to be linked to which data streams. When you are writing a generic package like "Auctions" you don't have any idea what other windows you might have.

3) This is related to (1) but is how windows in CMUD already work. SessionWindows and ChatWindows are the same class object in CMUD. It's just that ChatWindows inherit from SessionWindows and therefore share the same input socket. Currently, there isn't any concept of "display related settings"...all settings are stored for the package and not the window. Although I'm certainly looking into "display related settings" to see how they might better be assigned to a window.

But remember that a "window object" is really no different than a "trigger object" or "alias object" in CMUD. They are all just parts stored in a package.

4) This is already how they work. When you click on a Package in the settings editor, see the little "ReadOnly" checkbox in the lower-right corner? Sessions don't own forms...only packages own forms.

5) This is already true. The tree in the Settings Editor already has a root that is hidden. Packages just look like top-level classes.

6) You can already do this. Create a package and then drag a class into that package.

7) Since a session doesn't own any form, this doesn't make much sense, but a session *does* own a "layout", so essentially a session contains all of the other package forms as part of this layout.

8) Unfortunately, data is an integral part of a package. CMUD Variables are stored the same way as aliases, triggers, macros, etc. Converting a package into something more like a C++ Class with a separate definition and separate data is an interesting idea, but well beyond the current CMUD implementation and would require a large rewrite, which isn't happening at this time.

9) This is the same as (3) isn't it?

So, while (8) is an interesting idea, it doesn't directly relate to solving the existing problem, and it's a huge change that would require a lot of thought. Remember, we have zMUD compatibility to worry about here. That constrains the design. While I'm willing to fix problems that zMUD had at the cost of some minor incompatibilities, I can't just start from scratch.

But to summarize, we are still left with the same problem. How do we tell the Warrior package to send data to the Auction Package, but not get duplicate data from the Priest Package, and WITHOUT MODIFYING the Warrior Package (which might be used somewhere else where the Auction package isn't loaded).

Posted: Thu Jul 27, 2006 8:34 pm

Ok first off, nice post, great thought process!! I can't think of any other scenarios than what you have stated and there is only the one problem scenario. So how to handle.

1. Do nothing, let auction publish it's trigger and act on warrior and priest and so you get every auction twice. As you stated this doesn't look pretty, however in this scenario the user really knows what he is doing (disclaimer: we hope!!). The user is capable of adding in aliases to both his warrior and priest packages to easily turn auction output on and off. This is the easiest solution because you don't have to do anything and you put the onus of making things tidy on the user, the only thing you have to come to terms with is if you can allow this.

2. Give windows a method of declaring/defining themselves. They can send an alert to say that they have a connection to a certain host on a certain port. You also implement a method of aggregating this information and dealing with it in a certain way. Given this the auction package designer has the onus of making things tidy for his end user by handling the possibility of multiplaying. This isn't an easy solution it's an idea I've come up with it isn't fully fleshed it is ignorant of the true mechanics of CMUD and once again you have to come to terms with allowing the end user/designer to deal with the situation.

3. Implement your suggested solution. This is agreable to you since the end user doesn't fully have the onus of dealing with the situation, he may get double lines in the auction window to start with but he will turn to the package author or to these forums and we will readily have an answer on how to set his package setting in the UI. You came up with this idea I myself like it and believe it to be a sound one not only because it follows logically but because I know you know the true mechanics of CMUD and you have come up with the best possible solution available.

So there we go, I'm inclined to dismiss option 2 unless you merit it worth more discussion. Option 1 is already implemented and you can continue to use it until you have coded option 3.

Posted: Thu Jul 27, 2006 8:52 pm

Hmm, you just made me think of another option...

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.

This sounds like an interesting solution. The only problem is that it only addresses triggers. Are their any other problems with any other settings that might conflict? Doesn't seem like a solution could be this easy.

Also, I have forgotten about the "Events" that I want to add in the future. These were going to be special triggers that you could fire. So it's possible that multiple windows might all fire the same event based upon the same MUD text. But that is such a specialized situation that your method (1) seems appealing for it.

Wanderer Joined: 13 Jun 2005 Posts: 51

zMud layout is something I haven't figured out how to use yet. If I only have one session, the layout saved is fine. But if I made another session at different time and savd the layout as well, next time I when I open both session with saved layout, the interface will be completely screwed.

For that double captured problem, I think we just have to live with that problem. Because there is no way the package know whether these 2 are actual duplicated or just a coincidence. Trigger should be only processed on a raw data stream, because the cap message doesn't contain any extra information in it.

Anyway I don't think I will use package system at all, I will prefer write custom script for each session with copy and paste.

GURU Joined: 10 Oct 2000 Posts: 4379 Location: USA

I think CMUD should have two different type of packages: session packages and regular packages. Session packages contain one, and only one, session window along with whatever other settings are desired. Regular packages do not contain session windows but may contain normal windows and other settings.

The packages list for a session in the session database would now be two-tier. The first level would contain session packages and there has to be at least one session package. For each session package there would be a second level that would contain regular packages.

So lets take your example of a person multiplaying a warrior and a priest and take it a step further to add a thief. Lets say that the user has a Weapons package to deal with characters that use weapons like the warrior and thief, and a Spells package for characters that use spells like the priest. The user also has a Health package that monitors a character's health and the Auction package which is of interest to the user as a real-life person instead of any single in-MUD character. The package list in the session database for that session would look like this:

Posted: Thu Jul 27, 2006 9:21 pm

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

Posted: Thu Jul 27, 2006 9:24 pm

Posted: Thu Jul 27, 2006 9:28 pm

Kjata, that's an interesting idea. Let me think about it a bit more.

Certainly we shouldn't call both "packages". Your "Session Packages" are really just Session "Windows" I think. And I'd hate to confuse people even more on what a package is.

Posted: Thu Jul 27, 2006 9:29 pm

When you say "It is typically connected to the same network socket as the main SessionWindow." this surely means only 1 way outgoing to the mud not incoming and as such means directly to the mud hence aliases or anything sent is sent directly to the mud and not through any other window, nothing is ever received from the mud. This then would leave double incoming text reliant on other windows sending that text, as far as I know this can only be achieved by a trigger firing twice, yes a user could write an alias to make both their windows send to the auction window but that's their issue for being a freak. Is this the correct answer, I'm not sure if I've interpreted your question correctly, this basically states that the issue only exists for triggers and no other settings, if thats what you asked then great. So you add a trigger option that stores and timestamps the line, it's an option that can be turned off if it causes problems but I don't see how it would, the incoming lines have to match exactly text wise and within a very short time period, the only way I see that happening is if someone is spamming the channel but even then I think that time period would be longer than the one you would be using for matching timestamps and if not hey surely the spam protection is an added bonus.

Posted: Thu Jul 27, 2006 9:36 pm

Heh, and I just realized something about Kjata's post. It's really going back to having Windows own Packages. Or at least having a SessionWindow own a list of packages.

I need to go re-read that thread were we had the discussion, but it does seem like maybe we are getting back to this, which is how it worked in zMUD. In other words, when I create a window, it has a list of packages that are loaded for within that window. After all, many settings, like Buttons, Triggers, right-click Menus, etc are associated with a window and don't make any sense without a window.

This leads into the issue with Buttons appearing in the wrong window, which was another problem I wanted to talk about. Here is the setup:

Posted: Thu Jul 27, 2006 9:49 pm

Right we really need to think hard about this. Perhaps with multiplaying and only looking at two characters we are simplifying things too much. I like that Kjata suggested 3 characters because that made me think something about that model. He only had the auction package loaded into one character, that means the end user always has to have that character open even be it offline in order to have the auction window available even if they only want to play priest and thief. What happens if you tell each character to have the auction package to overcome this?

I think what is needed is a real time discussion/chat session with high end users and multiplayers to thrash some of this stuff out or we're likely to end up going round in circles and not getting the correct result.

Yes I can see why you're driving yourself crazy, this is damn complicated.

Posted: Thu Jul 27, 2006 9:49 pm

To continue my thinking out loud, let's consider an example of a new, super-nifty fancy AuctionProPackage! Wouldn't it be cool if a package could define multiple windows, and how they are docked with one and other, and then define where buttons go and everything. This is certainly the direction I am going with the zApp Scriptable Forms (and what yejun was thinking about in his first post). But let's not go overboard with it yet. Let's just think about a non-scriptable window that has two subwindows docked into tabs.

What we are trying to create is an auction system, were one window displays all of the incoming auction messages, but another window is used to keep track of outgoing stuff that we send (just as a silly example). In this example, the incoming auction messages are just like our previous AuctionPackage. That is just a window with no command line. Now we want to add a second tabbed window that has a command line. This implements some alias commands and displays any outgoing auction message that we send. Let's say that we want some buttons on this second window for creating a new auction, or something like that.

So what would this kind of package look like:

Posted: Thu Jul 27, 2006 9:56 pm

Posted: Thu Jul 27, 2006 9:58 pm

OK, now I'm starting to see Kjata's point. I think I'm saying the same thing with different words.

Notice that when I posted my last example, I didn't bother putting any "package" within the AuctionWindow or InputWindow...I just started listing the aliases, triggers, buttons, etc. In a way, these "windows" are acting like a package.

In other words, a Package still owns the Windows, but then if I allow a Window to work like a package and have it's own settings, then I think we have it. What gets published to the shared package library is still the top-level package. You'd never publish just a particular window. And the window is acting sort of like a class folder...it contains settings that pertain to that window.

If preferences are better defined at the window level and not the main package level, then it's easy to set various properties of each window separately (command line, colors, fonts, etc).

We still have the original issue of the multiple auction text, but I think the smart trigger method might still be the best for that.

Hmm, this might be getting better. I have no idea how I'll make a "window" act like a "class", but I'm trying hard not to worry to much about implementation details at this point. I mainly want to figure out how it *should* work, in concert with all of the various constraints such as "compatible with zMUD", and "doesn't require a complete rewrite".

Posted: Thu Jul 27, 2006 9:59 pm

Taz, actually CMUD is designed so that if you create your chat window first (using #WINDOW or #CAPTURE) and then save your Layout *after* the window is created, then it is supposed to create and show the windows when the layout is loaded again the next time. I know it's not doing that, but that is what I intended Wink

Wanderer Joined: 13 Jun 2005 Posts: 51

I can see why you have this problem.
If I make an analog to c++, by your definition all pakcages are just like a c++ class static methods, so all buttons, gauges are like static members of that class. (It is not possible to use non-static member directly in static method in c++)
When you use buttons, gauges you want them belong to the windows but keep functions static. So if use the same technique in c++, you should pass the self pointer/reference to all those static functions.

Posted: Thu Jul 27, 2006 10:08 pm

Yejun, that is basically correct. Neither zMUD nor CMUD were designed as object-oriented systems. They were based upon simple scripting language models. And even with ideas for expanding this functionality in the future, I still have to deal with this legacy stuff.

Posted: Thu Jul 27, 2006 10:09 pm

Apprentice Joined: 29 Jun 2001 Posts: 198 Location: USA

I'm not sure I understand why Scenario B is a single session when you're making two connections to the same mud in order to multiplay. It would seem that the easiest solution would be to cause Scenario B to use two seperate sessions (as Scenario D) and only load the auction package into one of them.

Perhaps I misunderstand the concept of sessions and packages?

Posted: Thu Jul 27, 2006 10:27 pm

OK, let me see if I can summarize the setup for the different scenarios before I go off to dinner. Just to clarify ideas in my own mind.

Scenario A : Novice MUD

First, here is the default single-window setup:

Posted: Thu Jul 27, 2006 10:29 pm

Vorax: What makes Scenario B different from D is that when you are multiplaying characters on the same MUD, you *want* them to be able to interact. For example, in my Warrior settings, I want to have a trigger that checks my HP and when it gets low, automatically tell my Priest character to heal me. So even though you are playing 3 characters in 3 windows, imagine that they are docked side by side and your character scripts can interact.

With Scenario D, it's like you are running different copies of CMUD, so none of the sessions can interact at all. That's the main difference.

Posted: Thu Jul 27, 2006 10:35 pm

I think yejun is write about the instance vs static stuff. What we really want the Health Package to do is create and maintain variables for @HP, @Mana, etc but *within* the relevant windows.

In other words, when the WarriorWindow receives the MUD prompt, the published trigger in the Health Package fires. But it should update the @HP and @Mana variables within the WarriorWindow itself, and not within the Health Package. Then, the Gauges created in the WarriorWindow would get their values from the variables within that same WarriorWindow.

That would allow us to just load the Health Package once and have it work for all of the character sessions, without having to load it into each window. The idea of having to load the same package multiple times into each window just makes me sick. There really needs to be a way to define the package once and then let it work on specific windows.

We still have the problem of how to tell the Health Package to *not* put gauges into the AuctionWindow, but that's something else I can worry about.

Posted: Thu Jul 27, 2006 11:05 pm

In Scenario B is that how you want it to be in both instances with the latter the preferred way? It's just that I don't think the first one reflects how it actually is now.

How do you propose to have a package that acts on everything, by what session will it be loaded? You have missed out the sessions and I think they are important and should be in the examples.

You have 3 character session icons Warrior, Thief and Priest. You have a package that can act on everything and it is loaded by the Warrior session. So you run all 3 sessions. Then you decide you have finished with Warrior and close it leaving Thief and Priest open. Warrior package closes, package that acts on everything closes as it's been loaded by Warrior, Thief and Priest are now missing functionality. Ok so you can get the package that acts on everything not to close but what if you never open Warrior and only open Thief and Priest they are once again missing functionality with the only way to get it being to open Warrior in at least offline mode.