Zugg Software :: View topic - CMud/MXP thoughts, ideas, opinions, criticisms/etc. (Note: LONG. VERY LONG POST)

Wanderer Joined: 24 Jun 2008 Posts: 68 Location: Texas

Alright, so I've been running ZMud for roughly 8 years (At a guess. I started with 3.14 I believe, when I was about 16 years old and am now 24.) I've taken several goes at CMud since it came out, but it's just never really suited me as well as Zmud for the most part, but it has gotten acceptable enough for me to purchase it recently because I do believe it's slowly headed in the right direction.

My main complaint with Cmud is the fact that it isn't as user-friendly and simplistic as ZMud. I understand that with great power comes great responsi-.. Err.. Scratch that.. With increased power and flexibility, it is hard to keep things as simple and user-friendly as they once were. From what I see on these forums, CMud is a godsend to scripters and players looking for such power, but I find it to be a bit intimidating, despite my experience with MUDs. After all, they've consumed a good third of my life now.

First off, it's a bit of a pain getting swapped over from ZMud to CMud when really basic things about it are different without any sort of clear 'classic mode' options. Such as having to adjust to using shift-enter instead of ctrl-enter for creating new lines. Pretty basic, unnecessary complaint, I know, but when you've been doing things one way for years, it can be hard to adjust. I don't have any trouble with hitting shift-enter on my keyboard, but 9 times out of 10, I still end up hitting ctrl-enter from ingrained habit and send the line through to the MUD even though I wasn't finished with it yet. A simple to find option in the general preferences labeled "Classic: Use ctrl-enter instead of shift-enter" would be handy and obvious. Such an option may be available already, but I've yet to find it.

Another 'classic' option that would be nice to find easily (Assuming they even currently exist) would be the old-style 'pop-up' method for bringing up your top-line menus by hovering your mouse at the top of the screen. I always loved this feature of Zmud as it allowed me to have my MUD window full-screen and still have easy access to the menus. The current method of having it as a full window of itself that contains the actual MUD windows lacks desirability.. And while I realize that you can pop the window out of there and have it as a standalone, it just doesn't quite behave properly. Not only can you not get the menus to pop up when you hover up top (Or anywhere for that matter), but if you want the window maximized when you break it away, you can't get it to remember that's how you had it. Auto-save layout doesn't do the trick and you can't get to the main CMud menu to manually hit 'Save session layout'. There may be some way around all of this, but I've yet to find it and would appreciate hearing the method if it exists.

The general preferences are a little bit intimidating as well. Primarily the 'styles' section isn't very well defined, but it is also simple enough to figure out just by changing things and seeing what happens where. The tabs along the top under each section also don't stand out very well at first to a previous ZMud user who isn't used to each section having multiple tabs. They sort of just 'blend in' and don't 'pop' out very well. The controls for defining these general preferences for each individual module/frame are also fairly clumsy and difficult to figure out at first, but I'm not sure how I would handle it any better. All I know is that it took me a bit to even figure out what all of the options under the 'nameless' menu at the topleft of the general preferences was all about, much less how to properly manipulate.. At the very least, some sort of name for the menu would be handy.

Another thing that bothers me is dealing with frames. In ZMud, they work beautifully for me as far as functionality is concerned, but in CMud, they are just flat out beautiful. The main difference here being that as a MUD developer, I'd like a standardized method of getting players started out with frames without a lot of hassle. I understand that players can create and customize their own frames, but that is one of the things that is just so intimidating about CMud. It took me a while to get the hang of making the frames look just how I wanted them and I'd like a way to pass this schemata on to my players without frightening them towards their 'quit' command. In ZMud, this was simple using floating frames with predefined distances from the edges and percentage based widths/heights. Didn't matter what resolution the player was running, things would always come out looking right and very manageable with no player interaction needed other than typing 'frame all open'. In CMud, this simplicity is destroyed by it's power and customizability.

For example, in my MUD, I use 7 basic frames through which I can comfortably sort any data I may need to send to a player. In ZMud, these frames are created in this manner, every time the player types 'frame all open' after they connect: http://i184.photobucket.com/albums/x184/Nicoli_Darius/zmud/Clipboard01-2.jpg

When they type 'frame all close' or shut out of the mud, the windows are gone and next time they type 'frame all open', they come back, looking exactly the same.

However, since CMud creates unique settings files for each window created, whether locally or from the MUD server, this concept is a bit broken, since frames are more intended for personal customization in CMud. Basically, the first time the windows are created, they come out looking EXACTLY like they did in ZMud. To a tee. Exactly what I want to happen. But after that initial creation, they now each have individual settings files that don't have these default properties set to them. (Height, width, positioning, etc) The next time a player tries to open these floating frames, each one is created in the topleft corner, 1 line high and roughly 1/4 the width of the screen, all of them overlapping each other and none of them properly floating. (I.e. you clickoutside of them and they get hidden behind the main window instead of staying out front.)

I see 2 simple fixes for this. In the package editor, a checkbox that says 'Accept settings from MUD when opening frame' or some such. This way, your everyday run of the mill players can check these boxes and never have any issues, simply using the MUD-created frames and your more advanced players can customize them to look and behave exactly how they want them to. And the 2nd potential fix being some additions to the <FRAME> entity, allowing the MUD to 'override' the players settings.. The former option makes more sense than the latter, but either one would be great.. (For example, <FRAME action="open" name="test" left=4% top=4% height=15% width=20% floating OVERRIDE>

A workaround I've already found for this is to go into the package editor and set the package to 'read-only' so that when the player closes out of the MUD window, none of the frame data is saved. I don't consider this a very feasible option though. It's extra work for the less-apt players and also not in everyone's best interests.

And to take this a bit further and really override the need for EITHER of those options for CMUD users, some more fine-tuned controls over frame creation in CMUD would be nice, but likely more work and further away in the development process. For example, after a while of figuring out how the docking windows work and tinkering with things, I managed to come up with this layout locally on my machine: http://i184.photobucket.com/albums/x184/Nicoli_Darius/zmud/Clipboard01-1.jpg

It looks much prettier than anything you could ever HOPE to get with floating windows, what with the tabs and docking within tabs for the map/mapkey section, seperate preference files for each frame for things such as default colors, font size, etc.. The only problem here, is, as far as I know, there is no way that a MUD can tell the frames to open themselves up and dock this way. Once again, some changes to the <frame> entity would take care of this and make me one happy developer. Some examples:

<FRAME action="open" name="tes1t" height=15% width=20% dock="above _top"> (Create the inline test1 frame and dock it above the primary MUD window.)

<FRAME action="open" name="test2" height=15% width=10% dock="above test"> (Create the inline test2 frame and dock it to the right of the test1 frame, but above _top)

<FRAME action="open" name="test3" height=20% width=15% dock="right _top"> (Create the inline test3 frame and dock it to the right of the main window)

<FRAME action="open" name="test4" height=15% width=10% dock="below test3"> (Create the inline test4 frame and dock it to the right of the main window, but under test3)

<FRAME action="open" name="test5" height=15% width=10% dock="tab test4"> (Create the inline test5 frame as a tab that can be selected alongside test4 within the same framing space)

<FRAME action="open" name="test6" height=15% width=10% dock="left test5"> (Create the inline test6 frame and dock it to the left of test5, but within the tab created specifically for test5)

Keep in mind that these are crude examples, but should give an idea of what I mean and how I can create a standardized framing system for my MUD that looks and behaves exactly like the image I posted above: http://i184.photobucket.com/albums/x184/Nicoli_Darius/zmud/Clipboard01-1.jpg

I realize that I can just be a jerk about it and tell my players that if they want to use inline frames, they can figure it out for themselves like I did, but I really don't want to go that route. I like having a standard way of doing things and also like to have these sorts of features available to my entire playerbase that may be using CMUD as opposed to just those minimal few who aren't intimidated by figuring out how to manipulate the frames themselves.

Anyways, moving along, my next complaint is a bit more minor. Simply the fact that any new frames that are created (Client-side or server-initiated) seem to for some reason come with a standard 60 second tick timer with the 'display tick message' option set. This was never an issue in ZMud. and to disable these tick timers, I have to right click in that frame, choose to show the status bar, right click the tick timer and uncheck enable. For each and every frame. It's very tedious work and something I would have to explain to my players how to disable for themselves if they can't figure it out. Perhaps a simple 'notick' flag could be added to the <frame> entity. My first thought was to go into general preferences and find the tick timer settings, turn off the tick message and set that as the default option for all windows, but alas the tick timer settings are no longer even IN general preferences.

That's pretty much the end of my MXP ranting. Other than the fact that -animated- gifs are unsupported, but that's not exactly a huge issue either. It'd be nice, but it's something I can live without.

All the complaints aside, there are alot of things I really love about CMud as well. Time stamps, docking frames, Column number display (Yeah, it's a little thing, but I love it.), improved/easier to use color support to break the typical '16 color' ansi mold, SSH, independent settings for each frame.. It all just makes for an improved experience, but all in all, CMud just still doesn't feel anywhere near as user-friendly or comfortable as ZMud.

I really feel that a few basic options at the very least to make it behave more like ZMud will help hook more customers onto it that are currently leary of paying 30$ when ZMud already does everything they need. CMud just doesn't have alot to offer to the average MUDder that their already paid-for version of ZMud can't do. The primary sales focus of CMud as it stands doesn't seem to be users upgrading from ZMud so much as users who need more power than ZMud can offer and new users who don't already have ZMud and therefor any comfort level with it.

There are a few general suggestions I'd like to chime in as well. An 'images' section similar to the 'MSP sounds' section for handling the currently downloaded images for MXP. the ability to have images overlap text or other images without 'pushing' them out of the way. (I.e. One image as a map perhaps and another image as a character avatar to move along it.) Animated gif support for more realistic character avatars, Classic, Simple and Advanced modes to help prevent the level of intimidation for new and migrating users. (I.e. Advanced mode being as it is now, Classic mode closely resembling Zmud in behavior/feel and Simple mode simply lacking some of the more intimidating options, such as the nameless menu in general preferences, the add buttons options, the 'Customize' menu and various other such things. Not only would it be less intimidating, but even advanced users may prefer to turn on advanced mode, make the changes they need, then turn it back off just to keep the program looking cleaner and less cluttered. I know I would liove it that way.) The ability to have non-connection based frames send their commands to the MUD itself as opposed to that frame where nothing happens. At all. Ever.. Since there is no real connection there.

A little more advanced suggestion that is practically just wishful thinking at this point would be a built-in FTP viewer for coders that takes the Username and password sent from the MUD itself, preventing the need for clumsy external FTP programs. Someone who needs to modify some code can simply type 'ftp start' into the mud or some such and have an inline frame open up with a traditional windows-style view for manipulating their work within the internal ZMud editor.

I've not yet actually messed with the gauges in CMud, but I've not seen anything in the changelog related to this next suggestion. A more fluid filling of the gauges. Every time I used them in ZMud, it was percentage based and blocky. When A 25% gauge would be 1/4 full. Then when the next tick from the MUD showed your hp to be at 50% instead, it would immediately jump to half full. It would look much smoother if the gauge filled from 25% to 50% when the change was registered, even if it happened within a very short time span. (As it would typically have to in order to properly represent where the gauge is actually at before the next tick from the MUD). Perhaps even the ability average out the interval between ticks to make it even more smooth and realistic.

So, I think I've typed long enough now.. I'm going to go ahead and wrap this up by trying to emphasize on the fact that this was not just a complaint rant.. I know it may seem that way, but it's really more intended to be a constructive post. I didn't make this post 'expecting' any of my ideas to be taken into consideration but more just with the hope that they wouldn't fall on deaf ears. I have used ZMud for a very long time and would really love to see CMud head in a general direction that more people would consider upgrading to it, if not just for the fact that my MUD is going to have some fairly heavy MXP implementation that ZMud just can't handle. I hear from so many of my friends that they just don't have any reason to move up from ZMud because it does everything they need it to. And for many people, it will always be that way, but I really feel that if CMud was a little more user-friendly and alot of it's power was more manageable and less intimidating, more people would make the switch. Not every player is looking for the biggest, baddest MUD client around, but alot of them wouldn't mind having that power at their disposal if they weren't just flat out overwhelmed with the new interface and extra options they couldn't ever even fathom to understand thrown in their face right from the start. A more comfortable approach with the ability to bring out these options as needed would likely pull a few extra customers Zuggsoft's way.

Now then. I believe I'm going to go get myself checked out for carpal tunnel. I hope that this post isn't just immediately disregarded as I currently fear it will be.. I spent a good 3 hours on it.. >.< I know I was a bit repetetive, especially on a few key points, but I suppose that's what you get for typing when you're braindead at midnight.

Posted: Thu Jun 26, 2008 9:32 am

Blimey, that's quite an essay. I don't have time to talk about all of it for now (I'm at work) but there're a couple of points that bear consideration:

1) Zugg's looking into better ways to display graphical, tile-based maps. See also this thread.
2) I think a simple-advanced mode bears thinking about. There's simply no way to add some of the things you want without adding more options (which you yourself admit), so it's only going to get more complex. Some of it's due to lack of documentation (Styles for example) but that's because we don't bug Zugg about it enough :P
3) I don't think the graphical frills you're after - chiefly, the gauge thing - are worth the effort. The improvement's pretty marginal for something that's presumably going to take a fair amount of effort.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

You make a number of very good points, and I am fairly certain Zugg will give your post a few times as he considers what should be done.

The main things that jump out at me are 2 bugs with windows created by the MXP FRAME tag.
1. The tick timer is active when the window is created.

2. The specified positions of the windows are not saved properly. I say it this way because if I configured a specific position for a window then I would not want the server to move it around on me. I think you had a very good thought in using the read-only package option. The way I can imagine making that idea useful is to actually not save the window at all when it is created by MXP. If the user moved it or added settings to it then it should be saved.

Regarding the proposed additions to the FRAME entity, I really wouldn't like the idea of an override. I do like the idea of a dock option, and hope Zugg will give it some thought. I am not too sure how many changes he is willing to make to MXP handling though. MXP was worked out as a collaborative effort between Zugg, Nick Gammon (MUSHclient), and another client devloper. It was mostly fixed as a standard many years ago. I think if Zugg considers adding more to the spec then he will also have to change the version CMud reports to the server as a reply to SUPPORT.

As you know zMud had an #FTP command. When CMud was in its earliest stages Zugg asked on the forums about whether he should continue to provide such a basic FTP support. It was nearly unamious that better FTP support was available in clients dedicated to that protocol, and with basic FTP support in web browsers there really was no need to have CMud include #FTP. Perhaps it would make sense for the command to return, and work similar to the #URL command. I am suggesting that #FTP with no parameters would take the address from the mud session and formulate it into ftp://some.mud and let Windows open whatever client the user specified as thier default FTP client.

Posted: Thu Jun 26, 2008 5:21 pm

Wow, that's quite a post. Like some of the others have already mentioned, it's going to take me a couple of readings to catch everything that you have in the post.

The MXP FRAME command in CMUD definitely still has problems, as you mentioned. The implementation in zMUD was very tied to the window docking system used in zMUD. CMUD uses a completely different (and more flexible) window docking system, and it's taken a while to get the FRAME stuff working with it. I agree that these bugs need to be worked on so that CMUD maintains your frame sizes and relationships. I've added that the bug list. I've also added the issue with the tick timer...that's a weird one but should be easy to fix.

As for additions/changes to MXP, I have to be really careful with this. As Vijilante mentioned, MXP is a standard protocol beyond just CMUD and zMUD. Even just adding the recent "c" and "%" options to the IMAGE tag were problematic since they don't work in zMUD and I didn't change the MXP version number in CMUD 2.29 like I probably should have.

Unfortunately, animated gifs are not going to happen. Handling the animation in a scrolling text window like the MUD output window is very difficult and it's just not going to benefit enough people. Because zMUD/CMUD are the only clients that even implement the IMAGE tag, most MUDs don't use images at all. It's just a case where the amount of work involved to support animated gifs is way beyond the benefit to most CMUD users. And I have a *lot* of features like that on the wish list. I'll put it on the wish list, but don't expect to see it for a long time.

There are a lot of limitations in how CMUD can handle graphics in the main MUD window. It cannot overlap text and graphics. I think the kind of stuff you are talking about with maps and avatars will be better handled by the new mapper stuff that I'm adding later this year. Keeping the graphics and the map in a separate window allows the MUD output window to keep handling scrolling text, which is what it is optimized to do.

Note that the graphical map stuff *will* probably be handled via extensions to MXP. So I think you'll get the end result that you are thinking about, but just not overlapping with your regular MUD text. Think of an MMO where the chat window is floating over the graphics.

Vijilante already covered the FTP stuff. The #FTP command will eventually be added back into CMUD. Several 3rd party components that I used for the #FTP command in zMUD are no longer available to me, so it requires more work to rewrite that module for CMUD. And I wanted to also handle the SFTP and FTPS stuff (in CMUDPro) to make it even more transparent. For example, easy local editing of server files and stuff like that. But again, I'm only one person and I have to prioritize my time to benefit the most users. And I recently decided to give the new mapper stuff the next highest priority (after bug fixing, which is still the highest priority). So the FTP stuff will have to wait.

As far as your comments about the complexity of CMUD vs zMUD, there is really no good answer to this. The problem is that CMUD is NOT zMUD. Lots of people like to think that CMUD is just an upgrade to zMUD or something, but it's not. It's a completely new program designed to be as compatible with zMUD as possible and to look as much like zMUD as possible. But it's a different program. And like any new and different program, there is always going to be a learning curve. After you use CMUD for several months you'll probably actually find that it is easier than zMUD in a lot of ways and it will be much harder to go back.

One of the problems with zMUD was that it did some low-level tricks with Windows to add certain features. For example, the ability to maximize the window and move the cursor to the top to popup the main menu window. That was a trick. The problem with tricks is that they break a lot of Windows compatibility. They prevent 3rd party software like WindowBlinds from working properly. They cause bugs on new versions of Windows, like Vista. One of the main design points in CMUD was to make it a more "standard" Windows application. So this means no more silly Windows tricks. No more adding custom icons to the window caption for rollup/stayontop/etc. No more messing with trying to move the window caption to the left side of the window instead of the top.

Back in the Windows 3.1 days (when zMUD was first written), it was very important to squeeze as much space as possible on the limited 640x320 resolution screens for the MUD output. These days that isn't important. On big monitors with high resolution you can just change your font size to get as many lines as you need on the screen. Getting every last pixel for the MUD output is no longer worth the incompatibilities that it caused in zMUD.

As far as having modes like Classic, Simple, Advanced...I really hate programs that do that (*cough* Office *cough). The problem with this is that many people *learn* how to use new software by exploring the menu system. When you start hiding menu options via a "mode", then it's hard for new people to learn the software. They look for a menu command to do something, don't find it, and complain that the software is crap because it doesn't have that feature anymore. People don't read help files. And they don't take the time to learn how to put a program into "Advanced" mode. So that isn't going to happen.

Also, if you compare the menus in zMUD and CMUD, they are already quite similar. So I can't really imagine that there is much of a learning curve there. You talked about the Preferences screen, and I agree that is different. But it's a simple case of not being able to please everyone. You complain that the tabs along the top "blend in" and you don't see them. Well, other people complain that in zMUD there is too much stuff in the tree on the left and it's too confusing to figure out what page to select. CMUD implements a page/subpage interface to try and hide some of the complex options. More advanced options are on the tabs for the subpages so that the user isn't overwhelmed with so many choices. I even specifically removed several options from zMUD that were not heavily used to try and reduce this complexity.

Regarding the "hidden menu" in the Preferences upper-left corner...that is the "Advanced" menu. In a sense, this is exactly what you were talking about before with having a Simple/Advanced mode. Most users don't need to use that menu, which is why it's hidden. The proper way to change the settings for a specific Window is to go into the Package Editor, click on the Window object that you want to change, then click the Preferences button in the lower-right part of the editor window. That opens the Preferences for the specific window.

So in a sense you are actually contradicting yourself by saying that you want a way to hide advanced options, and yet you want the advanced menu in the Preferences to not be hidden. This is a good example of the kind of stuff that I get all of the time. I get hundreds of suggestions and complaints, and they usually all contradict one another. I can't do what user "A" wants without annoying user "B" and visa versa. There is no single perfect solution that everyone would like.

What I have tried to do in CMUD is take a fresh look at some things and try not to be constrained by what zMUD did. Even the opening Sessions screen is an example...it looks a lot more like a standard Windows dialog box now. Where is the complexity that you are talking about? Run CMUD, click the New Session action on the left. Enter the hostname/port and click the Connect action. Now you are connected and playing your MUD. The defaults are already set the way most people want them. Where is the complexity?

Want an alias? Click the Aliases button to open the settings editor. Click the New button. Enter the name of the alias, press Tab and enter the value of the alias. Click Save. That's all pretty standard stuff. The settings editor already hides the more advanced options (in the More button at the bottom of the settings editor) so you don't see all of that unless you click on the More button.

The menu customization is hidden in the customize menu. It looks and works just like it does in MS Office. So once again I have tried to make a feature in CMUD as familiar as possible. Same with the window docking. Not many programs need window docking. But in CMUD I have taken the window docking system that closely resembles the one used in MS Visual Studio to provide better user feedback when dragging and docking windows.

So there are already lots and lots of areas in CMUD where I have tried to make it easier to use, or better match what users are already accustomed to. But in many cases this meant changing how it was done in zMUD. So yes, CMUD is aimed more at those people who have never used zMUD before. zMUD users are going to have a learning curve with CMUD and will need to change some things that zMUD just plain did wrong. I didn't want to migrate "bugs" and "weirdnesses" from zMUD into CMUD. CMUD was a fresh start.

Anyway, to conclude this long response, I'm NOT going to ignore anything that you said. But I hope you'll also understand that this stuff isn't simple and that it is very difficult to make everyone happy at the same time.

Adept Joined: 27 May 2008 Posts: 299

Wizard Joined: 26 Mar 2008 Posts: 1547

It would be nice with some backcompatibility upgrades to zMUD though, could make the transition process easier and help cmud users to help their zmud-stubborn friends.

Posted: Thu Jun 26, 2008 8:21 pm

Posted: Thu Jun 26, 2008 8:29 pm

I'm attempting to mind read here so could be totally wrong but I think that chamenas means for you to shove some of the new things from CMUD into zMUD as say a v7.22/v8.00 which is impossible as you can no longer compile zMUD.

Posted: Thu Jun 26, 2008 8:50 pm

Oh, if that is what chamenas was suggesting then yes, that's not going to happen. As Taz mentioned, I can no longer compile the zMUD code so zMUD is completely frozen. zMUD was written using Delphi 5 (several versions of Delphi prior to what I'm using now with Delphi 2007) and it used several 3rd party components that are no longer available. And many of the tools that I used with zMUD and Delphi 5 do not work on Vista, which is what I'm currently running on my development system.

Also, adding new stuff to zMUD isn't going to make it easier for people to switch from zMUD to CMUD...it just makes it easier for people to stay with zMUD and ignore CMUD. If people want the new features that are in CMUD, then they just need to get CMUD.

I think there is too much stuff in this thread. Nicodareus: let's create a new thread to talk about the FRAME bugs. Then people can feel free to continue to rant about other stuff in this thread. I just don't want your frame problems to get lost.

Btw, I have no plans to implement any "override" option for frames. I can appreciate your desire for this as a MUD developer, but zMUD/CMUD has always taken the position that the player has final control. The MUD is not allowed to ever "override" something that the player has set up the way they want it. For example, if the player turns off MXP in the client, there is no way for the MUD to "force" it back on again.

Edited: Discussion of FRAME issues has been moved here: http://forums.zuggsoft.com/forums/viewtopic.php?p=134023

Wanderer Joined: 24 Jun 2008 Posts: 68 Location: Texas

For the most part we just have conflicting opinions on a few things, like the whole advanced/simple mode thing.. Ehe.. You hate it and I love it.. :P So not much sense in going back and forth over what essentially boils down to a difference of opinion.

But there a couple of things I feel the need to respond to.

Wanderer Joined: 24 Jun 2008 Posts: 68 Location: Texas

Ah, another quick note that I feel is warranted in this thread that you never commented on is the change from ctrl-enter to shift-enter.. Almost everything I use uses ctrl-enter and not shift-enter. Is it possible to simply add an option that says 'Use ctrl-enter for new line instead of shift-enter'?

And something I've not brought up until now, is there a way to make it so that escape doesn't clear the command window? It's something that always got to me on ZMud as well and that I've just lived with. I tend to play on a couple of roleplaying MUSHes and nothing irritates me more than when I have a 13 line pose typed out and I accidentally drop the keyboard or a cat jumps into my lap and the 'esc' key accidentally gets hit and it's all gone permanently. Maybe just a checkable option much like the one I suggested above?

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Here is an interesting thought. Put the main menu and main toolbar in a flyout panel on the top. The default would be for them to be pinned open. A user can simply un-pin them to increase the mud window by those few lines. At the same time make it so they can be docked into any other flyout space. I think those would require that they be actual windows instead of toolbars. This would also have the benefit of having the locations the user puts them to be displayed saved as part of the layout.

Posted: Sat Jun 28, 2008 5:28 am

The change from ctrl-enter to shift-enter is just something that I had little control over. The standard way to add a newline to a multi-line edit box in Windows is to use shift-enter. In zMUD I used my own custom control for the command line, so I could program it to work however I wanted it, and I choose Ctrl-Enter because I didn't realize there was a different "standard" key for Windows. In CMUD I am using a more advanced 3rd party control (a rich text control) for the command line, and it uses the standard Windows Shift-Enter key. While I could patch the source code for this 3rd party control, I'm am trying to avoid that whenever possible to make it easier for me to keep up with upgrades of 3rd party components.

ESC does a lot more than just clear the command line. It actually causes any command line scripts the are running to be aborted. ESC is the general "get me out of trouble" key. So no, I don't plan to add an option for this. I know that everyone would like to have options for everything, but it's those kind of options that end up making CMUD look even more intimidating. It's like the other person who posted and wanted to redefine the Up/Down arrow keys. Next you'll see someone who wants to change Home/End or Pgup/PgDn, or the Backspace key or the Tab key. I just can't provide options for everything like this. If you are getting into that kind of detailed configuration, then you should probably look for a keyboard remapping utility that you can run at the same time as CMUD.

Or consider a different keyboard. On my Logitech G15 keyboard, the ESC key is much harder to press by accident, even with our 3 cats.

Posted: Sat Jun 28, 2008 5:30 am

Vijilante: Unfortunately, Menus and Toolbars cannot be placed within flyout panels using the toolbar and window docking system that is used in CMUD. The ability to have the docked toolbar within the MUD window itself is already a bit kludged (which is why it's easy to accidentally undock the command line and then not be able to get it docked back to the specific window without undocking the window first).

I'll think about some way to get the main menu to pop back to the top for the future.

Wanderer Joined: 24 Jun 2008 Posts: 68 Location: Texas

Drat. I see what you are saying. It's something I can adjust to, but it will just take some time and it kinda irritates me, because I don't like shift-enter for new lines.

As to the latter, though, would it be possible to leave the escape key as that general abort function, but also have an option for 'Do not allow ESC to delete the line' or something? I realize i've lived with it like this for years, but I really have had several times where a roleplay scene was entirely killed by that blasted occurence.. You can't just retype a 10+ line pose. At least, I can't. My memory's not that great, plus a great deal of enthusiasm for the scene is gone at that point and often-times I have to tell my scene-partner(s) that I'm just going to bed because my mood was just ruined.

I really don't want to buy a new keyboard as I like the layout of mine, nor am I fond of remapping software. If you don't feel this option is justified, I'll just continue to deal with the frustrations as I have so often in the past. I don't really think this option is nearly as intimidating to a migrating or even new user as many of the options already in general preferences.

And for that matter, it could be an option found when right-clicking the command line or something to put it even further out of the way, as that would likely better fit your style of hiding such advanced options I think.

Like I said, I can live without it if I absolutely have to, but I think if you ask any roleplayer, you'll find that they'd love this option just as much as I would..

Adept Joined: 04 Feb 2005 Posts: 246

How about storing a command line aborted with ESC in the history, as if you down-arrowed? At least that makes ESC not totally destructive.

Wanderer Joined: 24 Jun 2008 Posts: 68 Location: Texas

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I have to second that suggestion. It is clean and simple. I am sure someone won't like it, but I think it makes sense.

Posted: Sun Jun 29, 2008 1:28 am

I like that suggestion. Actually, when I am typing something long like that, I have formed a habit where I tap up/down every so often to force it into the command history as a kind of 'save'.

Posted: Tue Jul 01, 2008 5:13 pm

Great suggestion! I'll add that to the list, and maybe even do it for 2.30.