Zugg Software :: View topic

Posted: Mon Oct 26, 2009 2:39 am

I installed the new BETA version and when I load it, the main session window appears without a command line even though the option is checked. The preferences are the same as in previous versions.

Posted: Mon Oct 26, 2009 11:13 pm

Hold down the Shift key and click the Open Offline action to open your session and reset your layout file. Sounds like the toolbar layout got corrupted at some point. Remember to always try this first whenever you have problems with your window or toolbar layout (disapearing toolbars, windows,etc)

Posted: Sat Oct 31, 2009 3:58 pm

OK. Let's assume that the package is corrupt. Whatever that means, since I have no idea how I, using the settings editor, could possibly corrupt the settings package because I have no access to the stored data except through CMUD.
So I did as I was told. I manually copy the xml for each window and module in my package to separate files. Next, I uninstall 310B (I had this problem in 311B so I didn't even bother to use it, I just went back to what worked). After that, I installed 312B.
I now have a pristine session folder, no .pkg files, no .xly files, no .tbz files. I click on "open session offline" and I am presented with a blank window and an empty package. So far, so good. I then open the settings editor and I manually insert all the xml files from the "corrupt" package into the new package. The result? I have now two tabs with the same session name and two windows. One of the windows (the main one since it takes all the real estate, while the second one is a small window on top) has no command line, the other window (the small one on top) does. The onLoad scritps execute and send their output to both(!) windows. Now, one of the package tabs is deletable, the other isn't because it irepresents the main session window. Guess which one is deletable? The one with the command line. The one without the command line, which takes all the screen real estate, IS the main session window and so I am back to the start, no command line.
I tried starting fresh and and just adding one script at the time hoping to catch the section of code causing the "corruption". It doesn't matter what I copy into the settings window. The result is the same. The only way it will work is if I sit there and key in each script by hand. 100+ scripts give or take few.
My take on this? There is a serious problem with the package management. For one thing, it randomly bombs with "locked database file error" which means that SQL is waiting for a COMMIT to come its way, and never gets one.
There has to be something different between the way packages are being handled in 311 and 312 than they were in releases 310 and previous. I never had a problem going from release to release and this package has been around since 2.14.

So any ideas?

EDIT: In case you are wondering, I did try resetting the layout by holding the SHIFT key while clicking on "open session offline". What this does is reset the layout so that a random module from the session package is chosen to be the main session window. Needless to say, this makes the "session" unusable since the MUD it addresses doesn't exist. I suppose this is a low-priority bug and getting frozen at release 3.10 is the solution. I have sent you dumps of the problem.

Posted: Sun Nov 08, 2009 2:39 am

Excuse me, but isn't the ability to use a new release a problem that is somewhat important? Since package management is less than orthodox, that is, there is no simple way to restore a package except manually (I would love to know why), then the fact that the package doesn't load points to an internal problem. One important reason to think that this is the case is that this package is the product of the conversion to SQL management. In releases 3.08 and prior, the package was not an SQL database. I skipped 3.09 so 3.10 is where the package was converted. Now I find that the package won't load in 3.11 or 3.12. IMO this is worth investigating regardless of how many people were able to successfully transfer to the new release. If it happened to me, it will happen to someone else, and frankly, it shouldn't happen at all.

Posted: Mon Nov 09, 2009 6:04 pm

If your package doesn't load at all into 3.12, then you need to email me a copy of it. I didn't see anything in your post above that indicated you couldn't load the package at all.

If your XML import created multiple windows with the same name, then it sounds like you exported the XML from a package that was already corrupted and already had conflicting windows. All I can suggest is that you edit the XML in Notepad to remove the duplicate windows, or start pasting parts of the XML for your scripts, etc, a part at a time.

I know that from past posts you have a very complex set of packages. There have been plenty of bugs in various past beta versions that could have led to problems with your packages.

To determine the official "session window", CMUD looks for the first window in a package that has a command line and is marked with the "Use session network connection" option for the window. Sounds like you have multiple windows with this option selected, so CMUD is setting the wrong window as the main session window.

Posted: Sun Nov 22, 2009 4:38 pm

I finally was able to successfully use 3.12 by resorting to the following scheme.

A) I created an empty package which I called Garbage.

B) I copied my session pacakage to package Garbage.

C) I installed 3.12 and started my session with no package forcing cmud to create a new package.

D) I loaded Garbage as an additional package.

E) I copied Garbage to the empty session package piecemeal. Just doing a universal copy of all the settings fails because the classes and modules in the package get randomly assigned within the target package ignoring the structure imposed by the XML tree.

F) I deleted the Garbage tab.

G) I saved the session.

I did a comparison of the source and target packages (the old and new session packages) by looking at the sql files that contain them. I found no difference, so if the original package was corrupted, the corruption had to lie in the internal stuff that cmud maintains and not in the data itself.
Perhaps this is a problem. The user has no access to the internal constructs, so any corruption of these constructs must be caused by cmud itself.