Zugg Software :: View topic

Apprentice Joined: 06 Apr 2004 Posts: 173

After clicking on the db button, closing it, and reopening it, the dialog box for the database wont completely repaint.
Also sorta along those same lines.....

when highlighting multiple triggers, using shift downarrow, the interface wont highlight till you stop hitting the downarrow... so you basically can't see what you're doing until you're done doing it.

Posted: Mon Jul 02, 2007 5:33 pm

The DB module was ported directly from zMUD and is not integrated into CMUD and does not use the new window docking system or the themed controls. This will be fixed when the database module is rewritten for CMUD to use SQL databases. Until then you'll just need to work around the repaint problem.

For the triggers list, using shift-downarrow seems to work fine for me here. If you are holding down the key, then it doesn't update the window until you release the button. This is just how Windows works. Windows won't repaint the display (paint is at low priority) when the system is busy doing something else (like processing your key press). If Windows repainted the screen everytime, then it would be very slow.

The best way to select multiple triggers is to click on the first trigger, and then shift-click on the last trigger.

Posted: Mon Jul 02, 2007 6:14 pm

This is known bug. This is because the database component is the original from zMUD. It will be fixed as part of the DB rewrite planned for later this year.

Apprentice Joined: 06 Apr 2004 Posts: 173

I dun fink that's the way windows works, but whatever. It doesnt have to do database changes, it just has to redraw, and it's as if I were resizing the screen... How would I know the current screen size if it didn't update while I was sizing it?

Apprentice Joined: 06 Apr 2004 Posts: 173

also along those same lines.... if I select 30 triggers, and a trigger is created in the background, all the trigger selection progress that I make is lost. Also saving a trigger when another trigger has been created in the background, all progress is lost. I have to reopen the trigger window in order to save the trigger I was working on - kinda a nuisance... especially because theres no indication that it didn't get saved.

Apprentice Joined: 06 Apr 2004 Posts: 173

Imagine this: hold your mouse over text, and left click... continue to drag your mouse, what do you see, it highlights the text(as you slide the mouse)
NOT WHEN YOU RELEASE IT.
Open up an AIM window, or microsoft Word document. select SHIFT then start to down arrow (in the input box for AIM), ALL TEXT IS HIGHLIGHTED AS YOU DRAG (shift down)
oh well maybe I'm using those programs incorrectly....

Apprentice Joined: 06 Apr 2004 Posts: 173

PS: Thanks for the info about the db rewrite in progress, I didn't realize that was the case.

Posted: Tue Jul 03, 2007 5:24 pm

The settings list in the CMUD editor is a *TreeView* and not just a normal Windows "List". The Windows TreeView component works differently than a normal list...you can't just drag the mouse to select more than one line. You need to find another program that uses a tree view to compare it...you can't compare it to selecting normal text in Word or anything like that. In any case, it's not something I have much control over within CMUD.

As far as the selection being lost when a trigger fires...yes, that is correct. It is not a good idea to be editing your triggers when they are running in the background. When a new trigger is created, the database view in the settings editor needs to be refreshed to show the new trigger. This is going to clear your selection progress. Nothing I can do about that. But you shouldn't need to reopen the trigger window. The trigger that you were already editing should still be shown in the trigger window and you should still be able to edit it and save it. It's only the selection that should be cleared.

Apprentice Joined: 06 Apr 2004 Posts: 173

is there any way it can be done like the way you did it in zmud? I *believe* you had a copy of the database, and would turn an icon yellow when the copy was "tainted." Having a copy meant that the database view was somewhat static, but that the editing process was unaffected by subtle changes to the database.

Posted: Wed Jul 04, 2007 1:55 am

You can kind of do that right now by turning off the "Auto Update" option in the View menu. This will turn off the background updating of the editor. However, this isn't recommended because it can cause the editor screen to get out-of-synch with the internal database, and if this happens, then you start getting crashes and corrupted settings.

I have plans for sometime in the future to decouple the settings editor from the database. In the current implementation, the settings editor is really a database editor...it edits the data stored in your *.PKG file directly and doesn't know anything about the internal memory of CMUD. This makes the editor robust and ensures that you don't lose any data or get it corrupted, like zMUD could do.

But the downside of this design is that the editor *must* stay in synch with the database. When you run a script that adds a trigger, or changes a variable, CMUD writes that change to the database in the background, and the settings editor sees this change in the database immediately.

Without this design, it would be like having two people editing the same database at the same time...you could end up with all sorts of data corruption problems.

Changing this design to decouple the tree-view from the database could solve some of these issues, but it also adds new issues about how to handle data that is changed in the background. The main reason I'm doing the decouple is to get away from some bugs in the DevExpress database tree-view component that I'm using that causes some of the problems when you turn off the Auto Update feature. But even when I decouple the database, it will still work mostly like it does now regarding background database changes.

Given all of that, the current version really does work the right way for most people. As I've said, the only thing it causes is that you lose your selection. But I don't know why you are trying to have a persistent selection in the first place. The only reason to have multiple items selected is if you are going to delete them, or drag them to another class. And if you are making those kinds of major changes, you should really be doing it offline.

For example, imagine that you are moving a variable from one class to another. While you are dragging the variable, a MUD trigger fires that changes the value of the variable. Now you can end up with two variables with the same name...one in the new folder that you drag/drop into, and one left in the old folder from when the trigger fired. The only way to prevent this would be to stop all MUD input from being received while you are dragging/dropping, and that's not a good solution for most people either. Again, think of this as two people editing the same data record at the same time...who should win? Should your interactive change have priority, or should the background trigger have priority? No matter which has priority, you will end up with the wrong data at some point. It's just a really bad idea to be making lots of structural changes to live data.

The problem that you mentioned that prevents you from saving your changes when a background trigger fires is something that you posted in another thread, and as I said in that thread, I cannot reproduce that problem and you should post more info to that other thread so we can track down that problem. It certainly doesn't cause any problems having a background trigger running when I've been testing it, so some of the problems you are having may be something specific to your own settings file and scripts.

Probably more than you wanted to hear. The short answer is "No, I am not going to do it like zMUD". zMUD had huge problems with corrupted settings files because of these very issues, and one of the main design goals in CMUD was to use databases and prevent data corruption.

Apprentice Joined: 06 Apr 2004 Posts: 173

I really appreciated the comment! I think it's really nice to get an inside view into where you're headed with the product, and also some of the challenges. Everyone has ideas, but I think we all understand that this is your baby. It's rather well thought out, and even if there's an alternate way of doing something there can only be one product and there's tooons to do.

About the editing only while offline, that's an ideal rarely able to be indulged in. I find I have to do a lot of editing while I'm playing... partly so that I can test the triggers, partly because I like chatting with others, partly because I don't like being away from the game too long. And besides, if you had a great product like CMUD would you be only using it offline! -gasp- I THINK NOT! OOOh and then theres all the Auto updating stuff that I've been writing... hahah yeah I found that when people use their skills it's best to let the CMUD system make a trigger out of it even while I'm not paying attention. I have some rather clever capturing triggers now, they only capture unique triggers, but it causes me to have to move stuff around a lot, hence the database questions.

Anyway, thanks a lot for all your help Zugg, I'll probably need it in the future with something or another.

Graham

Posted: Wed Jul 04, 2007 11:39 am

If you're that bothered by the offline-editing thing, you could just get into the habit of turning off trigger processing while you're editing. That was good practice back in zMUD too and isn't too hard to start doing. There's a keyboard shortcut for it.

Posted: Thu Jul 05, 2007 5:27 am

Another alternative is to open two instances of CMUD. I've done this myself. One will be online and the other can be for you offline coding.

Posted: Thu Jul 05, 2007 5:13 pm

Tech: That could actually cause problems too, since you still would have two programs trying to edit the same database record. If both copies of CMUD are accessing the same *.PKG file, then the background save thread in one of them could fail and then stop writing updates to the database properly. It's not a method I would recommend.

Posted: Sat Jul 07, 2007 12:14 am

I usually maintain a separate session and packages for coding that I manage separately from my MUD. Only when a version is complete do I move it over to the packages that my main MUD session uses.