Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD Beta Forum Goto page 1, 2, 3  Next
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Thu Jul 27, 2006 6:29 pm   

Multiple sessions/packages - Design Discussion
 
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:
Code:
Common Packages
Character Window 1
  Packages specific to Character 1
Character Window 2
  Packages specific to Character 2

Notice that the Windows need to own the Packages? OK, but we decided that packages should own the windows, so the structure we really get is this:
Code:
Common Packages
Package for Character 1 (Warrior Package)
  Window for character 1
Package for Character 2 (Priest Package)
  Window for chacacter 2

OK, that can work fine. In the Files tab of the Session icon, you just give it this list of packages:
Code:
Common Packages
Warrior Package
Priest Package


* Scenario C just has multiple windows for each network host, but doesn't need specific settings for each. You just need a set of common aliases, macros, etc for doing admin work. So you might have this:
Code:
Common Packages
  Window for host A
  Window for host B

But perhaps you *do* want specific settings for certain hosts. For example, what if you admin hosts on different operating systems, so you want to set up some special aliases or triggers. So, you might want this:
Code:
Common Packages
Package for Host A
  Window for host A
Package for Host B
  Window for host B

and now this is the same as Scenario B. So this seems fine. The difference in this case is that it is *not* loading the package list saved for each session in the main session database. It is opening a connection to a host as a generic SessionWindow. No layout is loaded for each session. In fact, the "Favorites" list of hosts might be completely different than the initial list of sessions. In fact, each "Session" icon from the initial screen might have it's *OWN* list of "Favorites" for hosts to connect to. For example, you might have a session icon for "Admin MUDs" where the Favorites is a list of the MUD hosts that you admin. And you might have a different session icon for "Router Admin" where the Favorites is a list of all the Cisco routers you need to manage. There might need to be an option when adding a host to this list as to whether you want to add to the common list (like with a generic telnet client that stores a recently connected list), or whether you want to add it to the session-specific "Favorites" list.

* Scenario D is loading multiple sessions, each with their own layouts. Each session would have it's own list of packages to load. We want each session to be independent of each other. So what we want in this case is a completely separate interface for each session. Each session has it's own toolbar and main window. It's really just like running multiple copies of CMUD. In fact, allowing multiple copies of CMUD to run might be the best way to implement this. zMUD did a poor job of this, but had a kludge where each layout could be put into it's own "tab". It has a master set of tabs for multiple sessions. CMUD doesn't really handle this at all right now. When you load a new session, it just loads the new session as a new package. So it's really just doing Scenario B and not allowing multiple layouts for multiple sessions.

Shared Packages
OK, so far so good. But now let's throw some user-created Packages into the mix. For example, let's assume there is a Package called "Auctions". This package has a window that displays all auctions from a MUD and has some triggers to highlight different auctions in different colors, or maybe play a sound when a certain item is auctioned. It has a ChatWindow associated with it. This window has a command line, and there are some aliases for easily working with auctions. It also has a right-click menu for performing common auction commands.

So, this package looks something like this:
Code:
Action Package
  ChatWindow for auctions (AuctionWindow)
  Published Triggers
    #CAPTURE trigger brings auction text to the AuctionWindow
  Private Triggers
    Various color triggers
  Private Menus
    Right-click menu for auction commands
  Private Aliases
    Various auction commands

Now, this should be a standalone package that someone could design and then upload to the Shared Package Library. Let's see how this package gets used in our scenarios:

* Scenario A : Once again, this is simple. We just have this:
Code:
Auction Package
  AuctionWindow...
MUD Session Package
  SessionWindow for main session
  Session-specific aliases, triggers, etc.

The Published Triggers class in the Action Package causes matching text in the SessionWindow to be captured into the AuctionWindow. This is the simple case that CMUD was designed to handle. No problem here.

* Scenario B : At first glace, this isn't too bad. Just add the Auction Package to the list of packages loaded for the main session. Then you have this:
Code:
Common Packages
Auction Package
  AuctionWindow...
Package for Character 1 (Warrior Package)
  Window for character 1
Package for Character 2 (Priest Package)
  Window for chacacter 2

But now we run into our first problem. Since both characters are connected to the same MUD, they both see duplicate Auction messages. So our AuctionWindow gets duplicate messages. We could probably issue a MUD command in some of the windows to turn off the auction channel, but we'd like a more general way to handle this. So there needs to be some way to indicate which Windows the Published Triggers in the Auction Package really work for.

This is an extension of the problem we saw in CMUD 1.01 with the #CAPTURE command causing trigger loops. Each ChatWindow was processing the same triggers as the main SessionWindow, so each ChatWindow would get into an infinite loop doing a Capture of it's own text. As a temporary solution, I set ChatWindows in 1.03 so that they ignored any common triggers.

But what we see is that each Package somehow needs to be told what windows apply to it. For example, we need a way to tell the Auction Package to only run triggers on the Window for Character 1.

We do *not* just want to put the Auction Package "within" one of the other character packages. Remember that each package should be self-contained. We shouldn't need to modify the Warrior Package, for example, by adding the Auction Package to it.

* Scenario C : Since the package list of each SessionWindow doesn't get loaded, we just have the same as Scenario A, so this is fine.

* Scenario D : Since each session is loaded independently (like multiple copies of CMUD), then you simply add the Auction Package to whatever other session packages you want to have it. So there are no additional problems here either.

Back to the problem
OK, so how do we tell the Auction Package to only look at the MUD output of a specific window (or set of windows)? We don't want to store this in the package itself...the package needs to be generic and work for anyone with any set of windows. We don't just assign it to the "primary" SessionWindow, because in Scenario B, there isn't any "primary" window. So the kludge of not processing triggers for ChatWindows doesn't help because we have multiple SessionWindows in this case. Maybe you even want to allow a package to process triggers from the text of a ChatWindow?

This is where I get stuck. I can't store the list of allowed windows with the AuctionPackage, because it has no idea what windows might exist when it is loaded. I can't store it into the specific character packages (like WarriorPackage) because then I've created an undesired dependancy between the WarriorPackage and the AuctionPackage and they are supposed to be independent. So where do I store this dependency?

I guess the only place this might be stored is in the same place where the original list of packages to load is stored...in the session database. After all, when you go to the Files tab of the session icon, you see the following list:
Code:
Auction Package
Warrior Package
Priest Package

This is the list that is telling CMUD what to load when you select this session icon. This is the only place that already knows which packages are being loaded. So, somehow I need to set up an interface in this screen where you can specify that the Auction Package is only processing it's published triggers for the Warrior Package and not the Priest Package.

OK, so now my brain is full (your's has probably exploded by now). I'm going to take a break and think about this some more. I hope I don't regret posting this. It's pretty complicated and takes a while to understand and I'll probably get some posts that don't fully understand the issues, but maybe someone with a fresh perspective will be able to help with this mess.

All I know is that multiple sessions and multiple packages are a complete mess in CMUD and I'm not even sure how to fix it right now.
Reply with quote
yejun
Wanderer


Joined: 13 Jun 2005
Posts: 51

PostPosted: Thu Jul 27, 2006 7:52 pm   
 
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.


Last edited by yejun on Thu Jul 27, 2006 8:24 pm; edited 1 time in total
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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).
Reply with quote
Taz
GURU


Joined: 28 Sep 2000
Posts: 1395
Location: United Kingdom

PostPosted: 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.
_________________
Taz :)
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
yejun
Wanderer


Joined: 13 Jun 2005
Posts: 51

PostPosted: Thu Jul 27, 2006 8:54 pm   
 
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.
Reply with quote
Kjata
GURU


Joined: 10 Oct 2000
Posts: 4379
Location: USA

PostPosted: Thu Jul 27, 2006 9:10 pm   
 
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:
Code:

Warrior Package        Thief Package       Priest Package
      |                       |                  |
Auction Package        Health Package      Health Package
Health Package         Weapons Package     Spells Package
Weapons Package     
_________________
Kjata
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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
Code:
#WINDOW Tells

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

If there wasn't any Tells.pkg or Tells.mud file, then you get this:
Code:
Default Package
MUD Character Package
  Main MUD SessionWindow
  Tells ChatWindow (child of main sessionwindow)


OK, what were the main reasons to save a Tells.MUD file back in zMUD in the first place? Well, the *.MUD file was were the position of the window was stored, along with other window-specific settings, such as colors. There *might* be some people who defined some triggers in the Tells.MUD file to use the #SUB command to reformat the text coming in, or use the various #CW commands to change colors of particular words to highlight them. Or maybe a #SUB command to add a timestamp to the incoming text. Stuff like that. Certainly aliases, macros and most other settings were ignored in child windows. Variables might have been used by the triggers to keep track of counters and stuff, but that's about it.

If the Tells.MUD file contained specific triggers or othe settings, then those should certainly go into a package. But if the *.MUD file was just used for window position and colors, we don't need to create a whole package for it, do we?

But in the second example, where the child window is in the same package as the main window, where do the colors and positions of the child window get stored? Ahh, remember that Windows have their own Preferences. If you go into the Preferences screen and select the Advanced menu in the upper-left corner, you can select which window or which package you want to view/set the values for.

This is a real kludge in CMUD. When you go into the Preferences, are you changing the options for the Window or for the Package? Can you guess? You are actually changing the options for the Window, but it is kludged so that changing an option for the first window defined in the package also changes the root options for the package preferences themselves. This is nasty.

This is sort of like the issue in zMUD with global preferences vs MUD-specific preferences. The issue hasn't really been solved...it's just covered up.

Just look at all of the preferences...some apply to the window, some apply to the entire package. Actually, very few apply to the entire package. In the past, stuff like the Proxy Server has been global, but we can imagine different host windows that need different proxies. In zMUD, the spellchecking options were global, but we can imagine one window with spelling turned on (like a chat window) and another command line with spellchecking turned off (a programming window, or linux command shell).

In fact, *most* of the options are window-specific. And right now I don't think CMUD does a very good job with multiple windows. As we have seen, windows can suddenly grab the buttons from the main window, and stuff like that.

So I think I need to be more careful and make sure that it's really the *window* options that are being used. Packages have *settings* like aliases, buttons, triggers, etc. But it's the WINDOW option that has most of the "preferences". Just like Buttons have their own options, and triggers have their own options. 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.

The preference page that is probably most "package-related" is the Scripting page. But look at the first tab...those are options related to the window and not the full package. Things like the SendLines delay is really related to the network connection, not the package itself. And the Slow Walking stuff really just creates a bunch of triggers anyway, so it's just a different way of looking at certain triggers (those with #OK as their only command).

The only page that I can see that is truely package related is the Special Characters. The Special Characters are needed to parse the commands stored in the alias, triggers, etc. But we have talked about this in the past...should we be allowing people to change the special characters for their scripts? It certainly makes the parser/compiler slower and more complicated. Isn't it really just the command line where we need these options? And if it's the command line, then it becomes a window preference and not a package preference. We don't want scripts in the package library that all use different special characters. It makes it hard to provide support in the forums if people use different special characters for scripts.

So, does that leave us with *any* package-specific preferences? Or are they all window preferences?
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Thu Jul 27, 2006 9:24 pm   
 
Quote:
Anyway I don't think I will use package system at all

If that is how you feel, then you probably shouldn't be beta testing. The Shared Package Library is a huge part of CMUD and we all want it to work well. It's very hard for most users to use scripts in the Finished Scripts forum and we are trying to make it easier for people to share their code and ideas.

I think the problem is that the current package/session system is full of bugs and is not working. You might want to wait until those issues are solved and then come back to CMUD then.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
Taz
GURU


Joined: 28 Sep 2000
Posts: 1395
Location: United Kingdom

PostPosted: 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.
_________________
Taz :)
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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:
Code:
My Package
  Main SessionWindow
  Tells ChatWindow
  Buttons

OK, now where should CMUD display the Buttons that are defined in this package? Should they go into the Main window, or the child Chat window, or both? It's not obvious. However, if the Window owned the packages, then we would have something like this:
Code:
Main SessionWindow
  Main Package
    Buttons
  Weapon Package
  Health Package
    Gauges
Tells ChatWindow
  Tells Package

Now it is obvious which window contains the buttons and gauges.

But the purpose of Packages was to provide a way to share chunks of functionality. We had our AuctionPackage defined above and it created it's own AuctionWindow, and that seemed to make a lot of sense...the Auction Window was owned by the package.

So which is it? What's the correct hierarchy? Is it that we have different types of packages (some own windows, some dont) and different types of windows (some own packages and some don't)?

You can see why I'm driving myself crazy and going insane with all of this. There must be a SIMPLE way to handle all of this correctly...I'm just not seeing it.
Reply with quote
Taz
GURU


Joined: 28 Sep 2000
Posts: 1395
Location: United Kingdom

PostPosted: 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.
_________________
Taz :)
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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:
Code:
AuctionPro Package
  Published Triggers
    #CAPTURE trigger to send text to AuctionWindow
  AuctionWindow (regular auction window)
    Trigger to timestamp messages
    Trigger to recolor certain words
  InputWindow (new window to create auctions)
    (window option is set to tell it to Dock with AuctionWindow, command line enabled)
    Aliases for auction commands
    Buttons for auction commands

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).

Seems like this is pretty clear. It's obvious where the buttons get displayed, but it still encapsulates it all into a single package. In fact, rather then setting a window option to tell the InputWindow to be docked with the AuctionWindow, it's probably better to store a "layout" of windows with the package. This tells the package how to arrange the various windows when it's created. Maybe you want your package to add a fly-out window by default, or have windows tiled together in some form.

Currently only the main session icons can load a window layout, and this is rather restrictive since the main session icon really has no idea what all of the windows are that will be created by the various loaded packages.
Reply with quote
Taz
GURU


Joined: 28 Sep 2000
Posts: 1395
Location: United Kingdom

PostPosted: Thu Jul 27, 2006 9:56 pm   
 
Zugg wrote:
Currently only the main session icons can load a window layout, and this is rather restrictive since the main session icon really has no idea what all of the windows are that will be created by the various loaded packages.
Yes and exactly why your chat window doesn't show up until it receives it's first line! Ok perhaps this is what some people want but not me I want it there even if it's forever empty.
_________________
Taz :)
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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".
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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
Reply with quote
yejun
Wanderer


Joined: 13 Jun 2005
Posts: 51

PostPosted: Thu Jul 27, 2006 10:04 pm   
 
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.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
Taz
GURU


Joined: 28 Sep 2000
Posts: 1395
Location: United Kingdom

PostPosted: Thu Jul 27, 2006 10:09 pm   
 
Quote:
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".
*nod* *nod*

It's getting late for me now and my brain is starting to pack up so I may be wrong but I still believe there is an issue with 3 or more chars if only one has the auction/chat window specified and you don't want to play that char at that particular time only the others.

Quote:
You'd never publish just a particular window.
This is pretty much what I was thinking of doing for one particular muds chat window but granted it does have 1 trigger too for the capturing of chat. Other than that it only specifies word wrap indent differently and perhaps sizes and no command line though I couldn't get that setting to stick, a bug I suspect.
_________________
Taz :)
Reply with quote
Vorax
Apprentice


Joined: 29 Jun 2001
Posts: 198
Location: USA

PostPosted: Thu Jul 27, 2006 10:13 pm   
 
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?
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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:
Code:
My MUD Package
  Main MUD Window
    Triggers
    Aliases
    Buttons...

OK, now let's add a simple chat window. Let's execute the "#TRIGGER {* tells} {#CAPTURE Tells}" command:
Code:
My MUD Package
  Main MUD Window
    CAPTURE Trigger
    Other triggers
    Aliases
    Buttons...
  Tells window
    We can add triggers to timestamp or color the tells here

In this case, since the CAPTURE trigger is owned by the Main MUD Window, it doesn't fire again when text is sent to the Tells window. Only triggers within the Tells window, or triggers in the parent class (the top level) would get fired. Seems great!

Scenario B : Multiplaying chars on the same MUD
OK, now let's use Kjata's example and have 3 characters: Warrior, Thief, Priest. Here is how it might look:
Code:
Auction Package
  Published Triggers
    CAPTURE trigger to send text to AuctionWindow
  AuctionWindow
    Triggers to recolor auction text
Health Package (applies to all windows)
  Published Triggers
    Trigger on MUD prompt to get HP, Mana, etc
  Published Buttons/Gauges
    HP Gauge
    Mana Gauge
Warrior Package
  Warrior Window
  Weapon Package
    Aliases for weapon usage
Thief Package
  Thief Window
  Weapon Package
    Aliases for weapon usage
Priest Package
  Priest Window
  Spell Package
    Aliases for spells

Hmm, OK, it's complicated already. I like the idea of the global "Health Package". It's button gauges get added to all other windows. Hmm, except not the auction window...how does it know not to apply the health package to the auction window? But it can add gauges to the Warrior, Thief, and Priest windows. But no, it needs to have separate HP and Mana variables for each window. That gets back to the definition vs instance problem that yejun was talking about. So it's really more like this:
Code:
Auction Package
  Published Triggers
    CAPTURE trigger to send text to AuctionWindow
  AuctionWindow
    Triggers to recolor auction text
Warrior Package
  Warrior Window
  Weapon Package
    Aliases for weapon usage
  Health Package
    Triggers
      Trigger on MUD prompt to get HP, Mana, etc
    Buttons/Gauges
      HP Gauge
      Mana Gauge
Thief Package
  Thief Window
  Weapon Package
    Aliases for weapon usage
  Health Package
    Triggers
      Trigger on MUD prompt to get HP, Mana, etc
    Buttons/Gauges
      HP Gauge
      Mana Gauge
Priest Package
  Priest Window
  Spell Package
    Aliases for spells
  Health Package
    Triggers
      Trigger on MUD prompt to get HP, Mana, etc
    Buttons/Gauges
      HP Gauge
      Mana Gauge

But this means we are back to Kjata's situation where we need to allow "general" packages within "session" packages. Hmm, I guess I'd better go to dinner and let this stuff simmer a while longer.


Last edited by Zugg on Thu Jul 27, 2006 10:31 pm; edited 2 times in total
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
Taz
GURU


Joined: 28 Sep 2000
Posts: 1395
Location: United Kingdom

PostPosted: 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.
_________________
Taz :)
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD Beta Forum All times are GMT
Goto page 1, 2, 3  Next
Page 1 of 3

 
Jump to:  
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

© 2009 Zugg Software. Hosted by Wolfpaw.net