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 Previous  1, 2, 3
Zugg Posted: Thu Jul 27, 2006 6:29 pm
Multiple sessions/packages - Design Discussion
Zugg
MASTER


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

PostPosted: Fri Jul 28, 2006 7:02 pm   
 
Of course you can. You click on the window, then click Prefs and now you are changing the preferences for that window/module. You can change fonts, colors, etc. It would be silly to not allow you to change fonts.
Reply with quote
yejun
Wanderer


Joined: 13 Jun 2005
Posts: 51

PostPosted: Fri Jul 28, 2006 7:11 pm   
 
But those preference will not be saved, as you said these automatically created module will go away once I close the window.

And is this Prefs same as main window, including everything? IMHO a lot of Prefs will not apply to captured window.

Currently in cmud, a lot of messages will go into captured window, like tick timer message, command echo. Is this a bug or an intended behavior?

Sorry for asking so many questions reguarding captured window, but it is one of the main reason I am using zmud.
Reply with quote
Zugg
MASTER


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

PostPosted: Fri Jul 28, 2006 7:17 pm   
 
Of course they will be. By default it will save the module to the "ModuleName.Pkg" package file. All settings and preferences in CMUD are automatically saved in the background. You can always go into the settings editor and change the name of the file that it is saved to if you don't like the default.

And yes, it's the same Prefs window. While some of the Prefs don't apply to a capture window, most of them do, and it would be impossible to decide which preferences are needed and which are not. As we discussed previously in this thread, the vast majority of stuff in the Preferences apply to windows.

Not sure what you mean by messages going into a capture window. It certainly depends upon the trigger that is running. And if the capture window has a command line, then any command that you enter in that command line will get echoed to the window. If you have the tick timer enabled in the capture window, then it will display the tick message.

However, if these are things from the main window that are going to the capture window, then it's probably the same bug that is causing things like buttons to get moved from the main window into the capture window. As I have said, the current 1.03 version of CMUD has *so* many bugs with handling multiple windows that it's probably not even worth reporting them. The multiple window/session stuff is getting rewritten based upon the discussion in this thread, so any existing issues won't apply to the new code...the new code will probably have plenty of brand new bugs ;)
Reply with quote
Zugg
MASTER


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

PostPosted: Sat Jul 29, 2006 12:46 am   
 
I started doing the code changes for this today. It's pretty messy. The good news is that mostly it's cleaning up existing messes. A lot of the code is more straightforward now. The bad news is that I've got some wierd memory overwrite bug, and my memory tools are not able to help me find it. Something deep in the database is getting overwritten, which causes all sorts of wierd crashes all over the place. I've been all through the code and can't find the problem, so it looks like I need to stop for the day and start fresh again tomorrow.

I really hate these kinds of bugs, especially when it involves 3rd party code. What's wierd is that it's crashing when loading the existing SQLite *.PKG database into the in-memory database, and I didn't really change much involving that. It's doing it on multiple PKG files that loaded into 1.03, so I don't think the files are corrupted. But somehow, after loading the records (which seems to work), when the SQLite PKG file is closed, then it generates a wierd memory corruption error within the 3rd party database code. Oh well, hopefully I'll find it tomorrow. Right now I'm brain dead again.
Reply with quote
Rainchild
Wizard


Joined: 10 Oct 2000
Posts: 1551
Location: Australia

PostPosted: Sat Jul 29, 2006 1:37 am   
 
I'm out of the office for a day and what happens? A 4 page long discussion of upmost importance!

Oh well, hehe. I'm a bit late but I was going to post a couple of things.

1- I really like the concept of the named data streams, they're not really on-topic here but could be pretty useful.

2- Not firing on the same message twice between sessions might be nice, but as Kjata pointed out there's a few gotcha's we would have to work through. Personally when having multiple characters in zMUD (typically my imm and my mortal) I pick one of them to have the chat channels turned on, and one with them off, so I don't confuse my conversation, eg I've accidentally bidded on an auction item with my imm instead of my mortal which was kinda messy.

3- Back on page 1 I was going to suggest that you make a window work like a 'class folder' but it seems like you have come up with the idea on your own and called it something that makes sense, hehe. I guess we could extend the package library in future to perhaps allow 'download selected module into your existing package file' for the example of only wanting the "Math Routines" from "Zuggs Useful Package". That's also not particularly relevant for this current topic though hehe.
Reply with quote
Taz
GURU


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

PostPosted: Sat Jul 29, 2006 4:24 pm   
 
Zugg: Ah fair enough about the way CMUD starts up, I never realised that in zMUD the char screen was not the main form. Everything you said makes perfect sense and yes no one has come up with a decent reason why only the char screen should be shown, my reason is fairly pathetic in that it just doesn't seem right. As you say change takes getting used to, I suspect in a year to two years time it won't bother me at all and heck most of the time I fire up zMUD I press ESC to do some testing anyway so now in CMUD all I have to do is click in the untitled window.
_________________
Taz :)
Reply with quote
Zugg
MASTER


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

PostPosted: Sat Jul 29, 2006 5:35 pm   
 
Rainchild: We missed you! I kept waiting for you to chime in with your usual useful commentary and missed not having it :)

I think we got it figured out eventually. I'm still working on the code today, so we'll see how that goes. But so far I haven't run into any issues in the implementation of this design.

I did want to clarify something that I responded to yejun about saving a new capture window. The way it *actually* seems to work is that when you first use the #CAPTURE or #WINDOW command to create a new ChatWindow, it creates the Module at the top-level of your settings (remember, the Module is the Window). But it puts this Module into the same PKG file as your current character settings. It does *not* create a new PKG file with the same name as the chat window.

In other words, you now have a PKG file with the following modules:
Code:
Main MUD Window
  Triggers, aliases, etc
Tell Chat Window

The advantage of this method as the default is that you don't get a clutter of lots of PKG files for each window that you create. It keeps stuff self-contained within the single PKG file for your MUD character.

If you *want* to put the chat window into it's own PKG file, you just select the "Tell Chat Window" module in the settings editor and use the File/SaveAs (used to by Copy Package To) menu option to save the module to it's own PKG file.

In the settings editor, all of the references to "Packages" are mostly now "Modules". In other words, you create a "New Module" instead of "New Package". It's only when you save stuff that you are storing to a PKG package file, or when you click the Add to Package Library button in the module settings.

One complexity I haven't quite figured out how to handle yet: In the settings editor, you now have Modules, and there might be several modules that are being saved to the same PKG file (like in the above example). I need some way to show which modules are going to which PKG file. There are a couple of possibilities for this:

a) I could somehow display the PKG file as another "node" in the tree, so that you can see all modules within a specific PKG file. The problem with this is that it adds another level to the tree, and in most cases where you only have a single module stored in a single PKG, it just looks redundant and messy.

b) I could somehow color-code the items in the settings editor so that there was a unique background color for each package file, so you could easily see which settings belonged to which package, no matter how the tree view was sorted or displayed.

c) I could add a PKG selection dropdown box so that the settings editor only shows the contents of a single PKG file at a time.

I don't want to bias the discussion, but the more I think about option (c) the more I like it. It makes it easier to work on a single package and you can easily see exactly what is in a package and what isn't. Normal users would just see their main character PKG file and wouldn't see stuff like the Default Settings. So it would be less likely for a normal user to mess up a package they are using. It makes the settings editor clean and easy and hides the clutter of multiple packages.

The downside for advanced users is that it might be harder to drag/drop stuff from one PKG file to another. One idea is to make more use of the multi-tabbed feature of the settings editor. I don't know how many of you have tried this, but in the settings editor you can right-click on a package or class folder and select the Create Tab option and it will make a new tab in the settings editor that is rooted at the selected class. Once you have multiple tabs for multiple views of the settings, you can drag a setting from the tree view and drop it onto one of the tabs to move a setting to that tab. If you hold down the Shift key, the setting is copied instead of moved.

If the PKG file was part of the "view" that is assigned to a tab, then you could have multiple packages in multiple tabs and drag/drop between them.

In fact, maybe I could even set up predefined tabs for the PKG files to start with. Hmm (yes, I'm thinking out loud again :)... Yeah, what if the settings editor just made a tab for each PKG file. That would allow you to still drag/drop settings, and yet would make each view clean and simple, only showing one PKG file per view. I could still make the Default Settings tab invisible by default.

OK, I think that's probably the way to handle this. Thanks for listening to my rambling Wink
Reply with quote
bortaS
Magician


Joined: 10 Oct 2000
Posts: 320
Location: Springville, UT

PostPosted: Sat Jul 29, 2006 6:19 pm   
 
I like option c best as well. It adheres to the KISS principle (Keep It Simple, Spock!). Hide the complexity, and only show it when people are ready for it. Every new user is a novice user, and that is what cMUD should target with the UI. Then, let the more advance users "unhide" the power features. I really like the "view only one package at a time" functionality.
_________________
bortaS
~~ Crusty Klingon Programmer ~~
Reply with quote
Zugg
MASTER


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

PostPosted: Sat Jul 29, 2006 6:38 pm   
 
Also, this is already what the fly-out settings panel does. You'll notice that "Default Settings" don't show up in the fly-out window. This window only shows the settings for the current package, and in the new version will only show the settings for the current "module/window".
Reply with quote
Zugg
MASTER


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

PostPosted: Sat Jul 29, 2006 11:00 pm   
 
Well, today was another marathon session of coding. Now that I finally have a clear understanding of how sessions, modules, packages, and windows should all work, I went into the code and started "fixing" everything that was kludged.

This was a bit scary. There were several areas dealing with packages where I hadn't really considered multiple sessions and windows, and when I was trying to get the first beta out, I think I might have been in too much of a hurry. The fact that I didn't really have a clear idea in my mind really showed in the code. Even in some of my variable and routine names I had confused "packages" with "windows".

So I went through and changed the stuff that really referred to a "window" to a "module" and made sure that anything that referred to a "package" was really referring to the SQL PKG database file, and not to a module.

This cleaned up a bunch of stuff. Along the way I found the memory problem from yesterday (I had hardcoded a typecast that I shouldn't have, so it was treating a Module Record as a Package record, which caused memory overwrites).

I've still got more work in the Settings editor to handle the "packages in tabs" stuff that I talked about today, and I still need to add the UI for telling it what packages should be enabled for which modules.

But, other than the UI stuff, I have finally got the code back to the state where it compiles, runs, and can successfully load and save existing PKG and MUD files again. Considering how many changes I made to the low-level package code, I'm actually surprised it didn't take longer (gee, I probably shouldn't say that :)

So, next week I'll finish adding this new stuff to the UI and I'll start doing some really serious testing of multiple modules based upon the Scenarios mentioned earlier. Now that I understand exactly how all of this should work, it shouldn't be too hard to get it all working finally.

Honestly, when I released the first CMUD beta, I really knew that multiple sessions and packages were a mess. But I figured there were plenty of other bugs to fix first (and I was right!). But I can always tell when there is a big problem if there is a section of the code that I really hate working on...and the package/window stuff was something that I hated to work on.

Now that it's all cleaned up and makes sense, I don't have any problem working on it now. And, in fact, I can't think of any areas in CMUD that I hate to work on anymore, except for maybe the DevExpress toolbar stuff. So, I think that's a good sign of better CMUD versions to come.
Reply with quote
Rainchild
Wizard


Joined: 10 Oct 2000
Posts: 1551
Location: Australia

PostPosted: Sat Jul 29, 2006 11:42 pm   
 
That's good news Zugg :) I know what you mean about portions of code you hate working on - its often like that at work, under deadline constraints so you just bung something together fast instead of doing it right and then its a nightmare to maintain further down the track. Oh the joys of working for people who have no clue about how software should be done, hehe.

I think that if I were a novice user 'c' sounds nice and simple. I think as an advanced user I may prefer 'a' where they are all in the single tree view, so if there's some option which can let you turn that on the 'a' view down the track that might be useful :)
Reply with quote
MattLofton
GURU


Joined: 23 Dec 2000
Posts: 4834
Location: USA

PostPosted: Sun Jul 30, 2006 12:54 am   
 
I can probably think of one, except that technically you aren't working on it until the next beta series.
_________________
EDIT: I didn't like my old signature
Reply with quote
Zugg
MASTER


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

PostPosted: Sun Jul 30, 2006 12:56 am   
 
Really Matt?? You can't mean the....*mapper* can you Wink
Reply with quote
Taz
GURU


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

PostPosted: Sun Jul 30, 2006 1:25 am   
 
*rofl*
_________________
Taz :)
Reply with quote
edb6377
Magician


Joined: 29 Nov 2005
Posts: 482

PostPosted: Sun Jul 30, 2006 3:51 am   
 
^^
_________________
Confucious say "Bugs in Programs need Hammer"
Reply with quote
MattLofton
GURU


Joined: 23 Dec 2000
Posts: 4834
Location: USA

PostPosted: Sun Jul 30, 2006 5:38 am   
 
Nope, I was referring to the DB module. Laughing

The mapper should be a piece of cake compared to that, it's in DB form already.
_________________
EDIT: I didn't like my old signature
Reply with quote
Zugg
MASTER


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

PostPosted: Sun Jul 30, 2006 7:28 am   
 
Actually, the DB is a piece of cake because it gets totally thrown out and rewritten from scratch using real database controls. And since the Zeos database stuff I'm using is fun and easy, I'm actually looking forward to the DB module.

The mapper, on the other hand, is a very complex program and it's easy to really break stuff, or kill the performance. And while it already uses a database, it is full of lots of ADO optimization kludges. So I have to strip out all of the ADO crap and then put SQL back in, and then re-optimize the whole thing and hope that it's still as fast (or faster). Not something I'm really looking forward to.

Also, after swaping ADO for SQL in the mapper, it all just works the same when I'm done. So it's lots of work for limited return. The return comes later because of the better database backend. Whereas with the DB module we will get a *lot* of *new* functionality as a result of using a *real* database (the current DB just uses a flat file...it's not really a database).

The DB module might take longer than the mapper, but I think it will be more fun :)
Reply with quote
Tech
GURU


Joined: 18 Oct 2000
Posts: 2733
Location: Atlanta, USA

PostPosted: Sun Jul 30, 2006 8:59 am   
 
Yay Zugg... I can understand what you mean about the mapper but I'm sure you'll find a couple things to put into the goodie bag for it.

I'm quite looking forward to the new DB modules. There were a few Eq optimization ideas or other sortings that would work well in a full database but not so well with the zMud DB. I'm looking forward to that code to put some of them into action.
_________________
Asati di tempari!
Reply with quote
Vijilante
SubAdmin


Joined: 18 Nov 2001
Posts: 5182

PostPosted: Mon Jul 31, 2006 2:33 am   
 
Having fully read through this thread finally, I love the final conclussion that was reached. There may still be some minor tweaking needed when it is put into practice and tested, but the thoughts sound right. I wish I had participated in the discussion leading up to this point, I did not though.

I am just looking forward to finally be able to import my settings from zMud and start making the right adjustments to them. I am quite sure that I am the only person crazy enough to not just completely override the mapper, but to have it done through a child window. So the rewrite I will have to do to get to a functional state are quite complex. So far though CMud wasn't even capable of keeping the packages in a good enough state for me to start working on that rewrite. I think last time I tried all my settings ended up being shown outside of any package.

The DB module and the Mapper can very definitely wait. There was a time I would have been all for work on the DB module, but that MUD is dead and gone. Although as the oldest module, it definitely needs help; I would say the mapper is more important since it is usable in all MUDs.
_________________
The only good questions are the ones we have never answered before.
Search the Forums
Reply with quote
Zugg
MASTER


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

PostPosted: Tue Aug 01, 2006 8:37 pm   
 
Well, I'm not having much luck with this. I don't know if I'm fighting a cold or something, but I just can't seem to think straight. For the last couple of days I've been trying to add the User Interface for the modules vs packages, and I'm coming across some really wierd bugs that I can't figure out. Stuff that used to work that has nothing to do with this is now crashing. Maybe it's another memory overwrite issue, but it's not getting caught by the memory manager, so that doesn't seem as likely. Maybe something else is corrupted. But it's hard to work on this when other stuff is breaking right and left.

I'm sure I'll figure it out, but it sure is frustrating.
Reply with quote
edb6377
Magician


Joined: 29 Nov 2005
Posts: 482

PostPosted: Tue Aug 01, 2006 9:12 pm   
 
AS always im sure you will perservere through this and succeed. I have no doubt its tough work getting this stuff to work and still provide a nice gui thats easy to understand and utilize. Keep at it zugg :) we have faith in ya. I look forward to seeing the optimizations you get running
_________________
Confucious say "Bugs in Programs need Hammer"
Reply with quote
Kiasyn
Apprentice


Joined: 05 Dec 2004
Posts: 196
Location: New Zealand

PostPosted: Wed Aug 02, 2006 8:41 am   
 
i haven't read (most) of the thread but why not:

all packages are loaded into one big global list
a window maintains a list of pointers to all the packages in the list it uses...

(no one owns a package or window, but they reference it.. when a package has nothing pointing to it it is deleted)
_________________
Kiasyn
Owner of Legends of Drazon
Coder on Dark Legacy
Check out Talon, an easy IMC connection.
Reply with quote
Tech
GURU


Joined: 18 Oct 2000
Posts: 2733
Location: Atlanta, USA

PostPosted: Wed Aug 02, 2006 12:35 pm   
 
The problem with that is that you got an unnecessarily long start up and a rather large memory foot print initially, especially for someone who has lots of packages (which I'm sure quite a few will).
_________________
Asati di tempari!
Reply with quote
Zugg
MASTER


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

PostPosted: Wed Aug 02, 2006 12:51 pm   
 
Kaisyn: that is essentially what the Shared Package Library already does. It's a master database of all "registered" packages. To "register" a package, you can click the Add to Package Library when viewing a package in the settings editor. It has the smarts to distinguish local packages from those packages on the server and can store both in the same database.

However, a package doesn't need to be "registered" to be used. You can simply click the Add button in the list in the Files tab of the session editor and add any *.MUD or *.PKG file. I decided to allow this so that the Package Library didn't get cluttered with a bunch of character-specific packages.

When you reference a "registered" package, it already stores a pointer (actually, the unique ID of the package) from the package library. For unregistered packages, it just stores the full file path of the *.MUD or *.PKG file.
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD Beta Forum All times are GMT
Goto page Previous  1, 2, 3
Page 3 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