Zugg Software :: View topic

Wanderer Joined: 20 Oct 2006 Posts: 51

Before I get in to the problem I'm having, I want to state that I have used zMUD for 8 years now, and have purchased a few copies of it, for friends and to support Zugg, etc etc etc. In that 8 years, I have played one MUD primarily, and the settings I have created for that MUD are complicated and extensive, (781kb currently), so I certainly expected some work involved in porting them over to CMUD. I attempted to use CMUD during the beta period, and again after the public release, and had the exact same issue throughout. A couple days ago, I figured I would give it another shot, so I purchased CMUD, uninstalled the previous installation of 1.24 (just in case), and downloaded the newest. After installation, I loaded my settings file and CMUD tried to convert it, at which point it gave me an error and went no further. Like I said, I expected this kind of problem, having thousands of triggers & variables and hundreds of aliases/paths/etc. So I started the ordeal of adjusting the ones I found to be causing the problem via the Compatibility Report. After half an hour or so, I wanted to verify that my adjustments were going to work, so I saved the file, closed CMUD, and ran it again. Sure enough, CMUD attempted to convert my settings all over again, and destroyed the changes I had made. And yet again, I got an error at the end of the conversion process.

My settings being as large as they are, I doubt there is an easy way to track the exact cause of the bug, but I have sent bug reports through that error system, so hopefully you can locate and fix the cause.

My only serious complaint though, is the Package Editor itself. Over each generation of zMUD, starting at 4-point-something, I have become accustomed to the Settings Editor, and had to re-acquaint myself with each new version's. Every major change has been an improvement, and the new features offered things I wanted to harness, so the step up was one I made willingly. But the Package Editor in CMUD, so far, is disappointing. I dislike the layout very much. The fact that I have thousands of triggers means that displaying each individual one in the left pane is a nightmare for organization. Even sorted by classes, there are much too many. And beyond that, the left pane doesn't have a horizontal scroll bar, so I can't even see the full NAME of a trigger unless I click on it and view it in the right pane. The first n characters of many of my triggers, are identical. Clicking each to find which one ends in the trigger I'm looking for, is inefficient. And on top of that, I use the Search field constantly in zMUD, but I've found that if I View -> Toolbars -> Search, it stays while I have CMUD running, but as soon as I close it, the Search bar disappears again and I have to go back to View to re-load it the next time I run CMUD.

I understand CMUD is still a developing program, and these issues could very well be worked out in coming builds. I am by no means flaming Zugg, CMUD, the company, or any one/thing. I am only expressing my reactions to the program thus far, in hopes that these issues may be addressed in future versions.

That said, I am excited about CMUD in general, and the benefits such a major overhaul can offer. Your work is very impressive, Zugg, and congratulations on all your successes.

Posted: Fri Jan 19, 2007 7:55 am

As a suggestion, you -can- expand the left panel by dragging the right edge out some. That might help with your looking for trigger problem. As for the Search issue, I experience the same thing - might want to just use Ctrl+F for Find instead. Quicker than clicking on View->Tools->Search.

Charneus

Posted: Fri Jan 19, 2007 8:20 pm

If you are willing, send me the *.MUD file that you are importing and I'll take a look at the error message that you are getting during the conversion.

I don't know if it's too late, but remember that CMUD always makes a backup of your *.PKG file before it converts your *.MUD file. It only keeps one backup, but maybe it hasn't been overwritten again.

Also, select the Edit Session action and go to the Files tab and make sure your session is loading your *.PKG file and not your *.MUD file. If you put a *.MUD file in the filename field, then CMUD is going to try and auto-convert it to the new PKG format, overwriting your existing *.PKG file (after making a backup of the old file). My guess is that you started working on the PKG file, but then your session still had the MUD file which caused CMUD to try and reconvert it.

As far as the Package Editor, you didn't make any suggestions on how you thing it could be improved...you just complained. The zMUD settings editor wouldn't handle your huge number of settings any better. The multi-column listing used in zMUD would be awful for long triggers that all started with the same text.

Also, keep in mind that in the new Package Editor, the search function will match partial items. For example, entering "abc" in the search text will display all settings that contain "abc" in their name or values (depending upon what you search). So this can be useful for creating partial "views" of your data. Future versions will allow you to save these searches as "virtual folders" to make it easier to filter your data. And yes, future versions will allow you to keep the search bar open all the time.

However, you are stuck with the tree-view list on the left. Because of the hierarchical structure of settings (classes, trigger states, button states, submenus, etc), there is no way to display CMUD settings in a plain "list" like zMUD did. Only a tree-view will be able to show the relationships between settings. And there is no way in Windows to make a multi-column tree view. But as charneus mentioned, you can always just resize the left panel to display more text. Also, when you hover the mouse over a trigger, it will display the full trigger pattern in the mouse-over hint box.

Posted: Fri Jan 19, 2007 9:43 pm

Could you not add a left-right scrollbar to the tree view, Zugg? That seemed to be what he was suggesting.

Posted: Fri Jan 19, 2007 10:51 pm

Oh, sure, that would certainly be easy. But I got the feeling he was asking for more than that.

Wizard Joined: 03 Mar 2001 Posts: 1127 Location: London

Posted: Sat Jan 20, 2007 1:03 am

I've played with some layouts like that. Unfortunately it has several problems:

1) The amount of space that you have for your script is severly limited, causing a lot more word wrapping and unreadable scripts. You really need as much horizontal space for the scripts as possible. This means putting the list *above* the script, rather than to the left or right. And, of course, then you have the new problem of not being able to see as many settings.

2) There is no each way to show the hierarchy of settings unless the Name view was *another* tree view. In other words, you have trigger states (which you kind of showed), but you can also have menus nested within each other more than 2 levels deep. And once the name list is also a tree, why have it somewhere different taking up space instead of integrating it with the folder view on the left.

3) "Simce a class doesn't really have many settings of it's own there's plenty of white space to put a list view underneath" That might be true for you, but I have seen *many* settings file where this isn't true and there are *lots* of settings within a particular class.

I think a lot of people forget about playing with some of the new settings features. For example, try turning *off* the folder display (click the folder filter button that is in the upper-left corner of the tree view). This will hide the folders and will only show the settings within the current folder. Now click on the drop-down arrow at the top of the tree view next to the name of the current folder...this allows you to easily navigate the class tree structure.

In other words, CMUD really already works the way that you want...it can show *just* the settings in the current folder in the tree view on the left. It essentially hides the full folder structure in the dropdown box at the top. I actually use the package editor this way all the time.

Anyway, I think people might want to wait until I have a chance to document the Package Editor next week before making too many comments. I think it actually already does a lot of what people want, but without documentation and examples it's hard for people to learn about the new features.

Wizard Joined: 03 Mar 2001 Posts: 1127 Location: London

1) I'd expect I'd still select an individual trigger if I wanted to edit a script properly. The list view would be more for a quick glance to ensure I'm picking the right thing to edit.

2) The tree in the left pane would be unaffected the way I'm thinking. The only difference is when you've selected a class - you'd see the list of aliases, macros, triggers etc in the right (would only see the initial trigger state listed there, not any of it's conditions - to view conditions you'd need to select that trigger specifically.)

3) I wasn't clear, sorry. I meant that a class itself doesn't have many switchable options (it's essentially just on or off, unless I'm missing functionality), unlike a trigger or button might.

Turning off the folder display definitely isn't for me, it doesn't seem to provide anything extra and I like being able to see a folder structure.

I don't want to do away with having all set settings in the tree at the left, I just want to be able to quickly view the contents of a class.

So ideally I'd like the settings editor to be like Windows Explorer, with classes/folders and settings/files (or expandable files if it's a trigger with #CONDs for example), but with the improvement that since CMUD has relatively few 'file types' (triggers, aliases, buttons etc) then it'd be able to view the file contents in the right pane when highlighted, but stick with the list when a folder is selected.

Not a drastic change I'm after, just an alteration to the view when a class is selected.

(there's also the search bar disappearing that JWhitney mentioned too)

Posted: Sat Jan 20, 2007 1:46 am

I think there's been a misunderstanding here. Guinn is suggesting that his example view ONLY appear when a class is selected, not any other kind of setting. The "windows explorer view" would only appear as part of a class' options page.

But it sounds like something similar to this is already supported by the tree view, which makes anything like that superfluous.

Wanderer Joined: 20 Oct 2006 Posts: 51

I don't think it would be superfluous at all. His description is exactly what I omitted in my original post. If it is not possible, then I will just have to trudge through using the Package Editor in CMUD and see if I can get used to it. But the Explorer-style editor is nearly perfect, for me at least. Left pane contains folders (classes), and right top pane contains files (triggers/aliases/etc) that belong to the selected class. Beneath that, the value/options/etc for the selected setting. As I said, if this is an impossibility, I'll just have to learn to adjust, but it would make things significantly easier for the move from zMUD to CMUD, considering how much re-coding I'm gonna have to do with my settings already.

In response to Zugg's response to my original post, yes, I'd be glad to send you the .MUD file. And yes, I did set it to load the .PKG file instead, still had problems though. The multi-column 'details' view in zMUD actually worked perfectly for me - the Pattern column was just made to be wider than the others. Forgive my previous post if it appeared to be nothing but complaint. My intention was only to offer my first impressions and opinions during the development phase - it was meant entirely as constructive criticism.

Posted: Sat Jan 20, 2007 6:56 pm

The problem with that sort of view is that things other than classes can be treed. Triggers and buttons can have states, menu classes can become quite complicated and many levels deep very quickly, and so on. Guinn's suggestion of an explorer-style view only when a class is selected is halfway between these things.

Magician Joined: 17 Apr 2005 Posts: 496

A little late in replying here, but in my admittedly brief test of CMud what I missed was being able to sort triggers by value. Consider the example:

{You cannot move to the *} {#nodir}
{A door prevents you from moving to the *} {#nodir}
{You move to the (*).} {#move %1}

If you're sorting by pattern, the first and last would appear to go together, but functionally (sort by value) the first and second go together and viewing them like that is generally easier for me. This is why I'd like to be able to see a list like the example and like what ZMud has now, where you can view the patterns -and- values of an entire group of triggers all in one window/view.

Wizard Joined: 03 Mar 2001 Posts: 1127 Location: London

But while triggers can be in a tree as well, if you're editing, you're likely to be searching initially by the first trigger rather than any conditions. Viewing just the initial states of settings within a class would be useful