Zugg Software :: View topic - Multiple sessions/packages

Posted: 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.

Wanderer Joined: 13 Jun 2005 Posts: 51

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.

Posted: 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 ;)

Posted: 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.

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

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.

Posted: 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.

Posted: 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:

Posted: 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.

Posted: 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".

Posted: 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.

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

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

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

I can probably think of one, except that technically you aren't working on it until the next beta series.

Posted: Sun Jul 30, 2006 12:56 am

Really Matt?? You can't mean the....*mapper* can you Wink

Posted: Sun Jul 30, 2006 1:25 am

*rofl*

Magician Joined: 29 Nov 2005 Posts: 482

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

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.

Posted: 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 :)

Posted: 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.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

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.

Posted: 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.

Magician Joined: 29 Nov 2005 Posts: 482

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

Posted: 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)

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

Posted: 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.