Zugg Software :: View topic

Posted: Sat Aug 12, 2006 6:06 pm

OK, now that we have Packages and Windows/Modules all straightened out, it's time to look back at the issue of Multiplaying and Multiple Sessions.

What is a Session?

First, let's define some terms:

Connection: A specific Host, Port, Username, Password that defines a socket connection to a remote server
Session: A list of packages to be opened, along with the Layout of the windows and Toolbars

Each "Window" can have it's own "Connection". However, we don't want to store the connection data (like passwords) in the *.PKG package file. We want to distribute packages via the Package Library, so they should not contain any login information.

This is like the list of which packages are enabled/disabled for a window. We decided to store this list with the Session, and so we will also store the Connection information with the Session.

So, a Session has a) list of packages to load, b) for each window, a list of enabled packages, and c) for each window, a list of connection information. I'll probably create a separate database table for the connection information and just store links to that table within the session so that if you change a password for a particular host:port:username it will get used for any window that points to that same connection data.

When a Session is loaded from the main selection screen, the packages are loaded into memory, and then the session's Layout is applied to the various windows, and the custom Toolbar layout is loaded.

When you exit CMUD, the current Layout and Toolbar information is saved in the session database. This allows you to return to exactly the same setup you had previously for a session. I'll probably make this "autosave layout" optional but enabled by default.

OK, that's how CMUD will work normally for single sessions, now let's look at multiplaying.

Easy multiple sessions

I never liked the multiplaying system in zMUD. You had to create a session icon for each character before you could then load them together and save it as a new multi-session icon.

If I'm using CMUD to connect to multiple hosts like a "normal" telnet program, I'd like to just select "New Session", enter a hostname and port, and get a new tabbed window connecting to that host. Same as using the existing #SESSION command.

In fact, I'd like a pull-down list of various Connections that I've used in the past so that I can quickly and easily open a window to a different host.

In this case, I do *not* want my entire screen layout changed. I just want a new window. Do I want any settings loaded for that new window? Well, probably. If I defined an alias or trigger for a particular host in the past, I'd probably want it loaded with that window.

This means we aren't really just creating a new window...we are really opening the primary package file for a session. But we are not loading the full screen layout for that session. And we don't want to require that it already be in the list of session icons.

So, this means we are not really loading an entire session. We are loading the list of packages for a session, but we are not loading the saved layout or toolbars. And the session pulldown list doesn't just have a list of session icons, but it has a list of the Connections database table so that it shows hosts that we have connected to, but not necessarily created session icons for.

Loading full sessions

If you want to load a completely different session along with it's saved layout, then I'm probably going to force you to run another copy of CMUD. The problem is that the docking window manager can only load a single window layout at a time. When you load a new layout, any existing layout is replaced. This makes sense if you think about it...what if each session had a different placement for the global "Reference" flyout window? A window can't be in two different places at the same time, so it doesn't make sense to have two different session layouts active at the same time.

zMUD kludged this. First, zMUD didn't have any "global windows" like the CMUD Reference, Settings, Status windows. The Status window in zMUD wasn't really part of the saved layout. zMUD just put each session "layout" into a separate tab. CMUD makes this even more complex by allowing you to customize your toolbars. Obviously if two different sessions have customized the main toolbar in two different ways, you can't have both of them loaded.

So CMUD is going to allow multiple copies of itself to be running (zMUD didn't allow this). I'll eventually make it so that you can drag a session icon from CMUD to your desktop and double-clicking that desktop icon will run another copy of CMUD and autoload that session.

User example: Sys Admin

Let's look at a sysadmin running CMUD for the first time. They don't care about the existing MUD icons, so they close the main session selection window. Then they select New Session from the File menu, or just type the #SESSION command in the command line to connect to their host:port.

As soon as they connect, CMUD stores the host:port information into it's Connection table. The existing Session icon in the main toolbar now has a pull-down menu associated with it. If you click on that pulldown, you will first see a list of existing session icons, followed by a list of host:ports in the Connection table that are not associated with any session icon.

OK, so the sysadmin is connected to a host and working fine. Now they want to connect to another host in a second window, so they use File/New Session or #SESSION to connect to another host. Now they have two windows that are tabbed-docked by default. The sysadmin can drag a tab and redock the windows so that they are side-by-side.

If you pull down the session toolbar menu, you would now see both hosts listed in that menu.

OK, the sysadmin is done and exits CMUD. CMUD creates a session icon for this session (because the sysadmin never created a new session icon...he just closed the original session selection window). CMUD saves the screen layout with this session icon.

The next time the sysadmin runs CMUD, he sees a new session icon. If he double-clicks that icon, it opens is previous saved layout (two windows side-by-side) and connects to both hosts. It's just like where he left it.

But let's say he just closed the session selection window again. Now, when he opens the pull-down menu for the Session toolbar button, each host that he connected to last time are shown in this list. He can just select one of them to connect to that host.

OK, so what's the problem?

This all sounds fine and good, but there are a couple of problems that I need to figure out.

First, should CMUD really automatically create a new session icon if the user didn't create one already? This is what zMUD does...it creates a new session icon every time you connect to a new host. And your session icon list can get full of icons you don't really want for MUDs that you just tried once.

But you can always delete an icon. And the user might be pissed if they connected to a bunch of hosts and then arranged their windows and then lost all of this work when they exited CMUD.

I will be adding a "Save Session As..." option to the File menu which will create a new session icon and let you save the existing layout to a new icon. This also allows you to save your *.PKG file to a different name. For example, if you just close the session selection window, you are working with the "Untitled" package. This gets saved to the untitled.pkg file, but it gets overwritten the next time you run CMUD. So the "Save Session As" option saves the untitled.pkg file to a different filename that is assigned to the new session icon.

The question is whether this saving to a new session should be done automatically or not? Should it always create a new session icon, forcing you to delete the clutter later? Or should it force you to use the Save Session As option to save your work? Or (most likely) should it prompt you when you exit whether to save your new session?

I think prompting is probably the way to go, but let me know otherwise.

Remember that if you already loaded a session icon to begin with, then it uses the AutoSave option of that session to decide whether to save it automatically. So in that case it wouldn't need to prompt you to save it.

Yes, I'm thinking "out loud" again. This is the functionality that I'm working on today, and I wanted to talk about it and see if anyone has additional comments or suggestions.

Remember that the GOAL is to keep it simple. I want CMUD to work more simply for multiple host connections. I'd compare it to a multi-file editor...in a multi-file editor you have a different tab for each file. So in CMUD you have a different tab for each network connection. Of course, with the docking stuff you can drag these tabs around for different layouts, which get saved for your session.

Wanderer Joined: 26 May 2004 Posts: 68

As a frequent multiplayer I thought I would drop my few cents.

Currently my system (in 7.21) is have folders with a mud in a folder, so I'm thinking, new mud, put it in a trial folder or something where all muds accessed only a few times get put in. That way you lose the clutter of new muds, and have a way to quickly access them. So it should do what it is already doing (except in a new new folder away from your usual stuff)

Package system =inheritance? (though to my understanding thats what the package system is all about. doesnt hurt to get clarification though)

Also, I would prefer to see some way of a session using multiple inheritance via a tree layout. As it is, the folders are nice, but accidentally hit enter in one of them and all you do is start a new blank session to no where.

For a MUD that allows multi play multiple inheritance would be very useful. E.g.

Realms of despair
---Warriors
------A
------B
------C
---Mages
------D
------E
------F

etc.. that way you dont need to fiddle around with stuff so much. A will inherit settings from the warrior files and the big realms of despair files. That way when you load A, you get all those in one simple package with a few variations from B and C. Unforunately as it is, I have to use the detailed view and sort by comments to get this done, not to mention I need to copy and paste then edit A's settings for B. Its a minorly annoying thing that could be simplified to get rid of a decent bit of redundancy I think.

As for the loading full sessions I'm not sure. The current layout system tends to show only the layout's tabs (which i guess is the point of the layout feature. to retain a set layout) so Im not overly fond of it. Nor do I have much of an opinion on it. The settings I load change with the seconds so a static layout really doesnt work so well for me. But if i wanted to play two different muds, then I totally agree.. a different layout for each mud would be useful to say the least. As would the fact they wouldnt all be on the same instance of the program allowing alt tab to do its work instead of shuffling through with ctrl-n (alt, w, window number doesnt work so well when you have 20+ windows open link live or not)

Posted: Sun Aug 13, 2006 2:14 am

xenapan, you might want to read the other threads here: http://forums.zuggsoft.com/phpbb/viewtopic.php?t=24065 and here: http://forums.zuggsoft.com/phpbb/viewtopic.php?t=24097 for more about packages. They will handle the inheritence stuff and they have a more general discussion of packages and what they can be used for. I think it will really help for what you are doing.

Posted: Sun Aug 13, 2006 5:26 am

I don't multi-play much, but think in terms of a sys admin, I definitely say prompting is the way to go.

Wanderer Joined: 13 Jun 2005 Posts: 51

I think the first problem is interface. Session windows should be completely separated from each other just like office documents. And name space should be completely seperated as well. I also think there should be some inter session communication method to be added.
If new session just like a new file in excel, and new connection window should behavior like a new sheet.

Another problem here is how data stored. From your description, I guess session file will be like an layout file, it remember location of loaded pkg file, pkg file include window settings, window settings include connection info and enabled packages. I would prefer everything for a session stored in one file, except external packages. So if I want to move a session to another computer, I only need copy session file and re-download external packages.

There should be "save window as", "import window" and "save session" in file menu. Therefore user can move one connection from one session to another session.

Posted: Wed Aug 16, 2006 6:23 pm

yejun: if you want sessions to be completely separate, then you run multiple copies of CMUD. Then they are totally separate. The issue is that *most* people do not want their sessions to be separate. They want to create scripts between their sessions, so that, for example, their Priest can heal their Warrior character automatically when their health gets low, and stuff like that.

But yes, essentially a session is like a new file and a window is like a new sheet.

Sessions are currently stored in the master sessions.db database file. The ensures data integrity and prevents problems with corrupt settings. For moving sessions between computers, I plan to eventually implement an XML import/export system similar to what I already have for packages.

"Save window as" doesn't make much sense, so I don't know what you want that to do. You can't save a window as a standalone entity. Windows are part of packages. And there is already a "Save Package as" option, but this is in the settings editor. Same thing with "import window"...you can do that in the settings editor since a window can be imported/exported just like any other setting, like triggers, aliases, etc. Remember that essentially a window is a "class folder" and can be imported/exported/moved just like any other class folder.

"Save Session", "Save Session As" are already in the File menu in the new version.