Zugg Software :: View topic

Apprentice Joined: 13 Aug 2007 Posts: 166

I voted for Mapper bug fixes, because I use the mapper constantly in zMUD, but I can't do it in CMUD as it is now. Speed improvements and general stability are also important because it's impossible to use a client that crashes easilly or runs to slow, and right now, 1.34 is quite stable for me, but runs way to slowly for me to be able to play with it.

And an Athlon 64 3000+ with 1GB RAM & Win XP should be more than enough to run a MUD program fast. So I would rather have it use more processor power and run fast enough, than have low CPU usage and be unplayable with.

D

Magician Joined: 25 Oct 2000 Posts: 461 Location: USA

I'm curious what you mean by slow and what mapper issues you are having? I'm running with the same system specs, and don't have any issues with either 1.34 in terms of speed or the mapper...

Apprentice Joined: 13 Aug 2007 Posts: 166

With the same settings, CMUD runs alot slower than zMUD. How? The text I receive from the mud scrolls alot slower, lags kind of... triggers are processed slower... When it comes to the mapper, I in zmud I use the #MENU {AutoMapper|File|Map Off} etc command, which doesn't work in CMUD. I mean, I have purchased CMUD, I'm just not using it to play yet.

D

Posted: Fri Aug 17, 2007 4:44 pm

For speed issues, please create another topic and post about it. Speed issues are usually the result of a bad script that you have running. So my guess is that something from zMUD didn't translate properly. If you post more details, we should be able to help with it. Normally CMUD is *much* faster than zMUD. But if your scripts do not compile properly, then it's going to be slower.

Magician Joined: 25 Oct 2000 Posts: 461 Location: USA

And I believe Zugg mentioned in another thread that #MENU is fixed with the automapper for 2.0 (or at least on the bug list _to_ be fixed).

Wizard Joined: 14 Aug 2004 Posts: 1269

Is it not possible to use #CMD {AutoMapper|File|Map Off}?

[Edit: No it's not on the version of CMUD that I tried - with various combinations of #CMDs. That's annoying - I currently use #File {AutoMapper|File|Map Off} too.]

Posted: Fri Aug 17, 2007 9:25 pm

Nope. The #CMD command is for executing internal commands by name. See the #CMD help topic for the list of names. The #MENU command, on the other hand, executes commands based upon their caption name in the menu system. This can be less reliable because in v2.0 people can customize their menu to move stuff around and rename it. That's why #CMD was added. But #CMD only handles normal CMUD commands and doesn't know anything about other windows, like the mapper.

Posted: Fri Aug 17, 2007 9:30 pm

Yet, at least. Or that's my hope anyway :)

Posted: Sat Aug 18, 2007 1:26 pm

I voted for 'other' though I am already using cmud. I voted anyway though, because a few people from my mud have mentioned a specific problem to me as the main reason they are waiting.

The problem being buttons. I have no idea what their issue with buttons is (I no longer use any buttons other than toggle switches and a handful of menu buttons for pathing locations), but they have mentioned some problem with buttons which is causing them to wait.

They have also mentioned general stability, but with the exception of non-docked windows and multiplaying situations, I've found cmud (at least the last few releases) to be really stable. However, I was turned off several times in the past by the unstability when using floating windows, so I can see how people might find this an issue.

In IRE muds especially, there is a third party proxy client available (mudbot/whyte's mapper/imapper) with a nice mapper. Its very popular with zmud users as well, as the mapper makes good use of MXP to create a small floating window with an auto-updating ansi map. In some ways this already works better in CMUD as the mxp display part is somehow smoother and easier to visualise; but the window itself works best if floating, yet undocked windows make for an unstable CMUD, and that in turn is a turnoff, especially since "map window" might be one of the first things a user does when logging into their mud to try CMUD out.

So I guess my vote goes toward multiplaying (and floating windows) stability, along with whatever (if any exist) problems there may still be with buttons.

Posted: Sat Aug 18, 2007 1:36 pm

There're some problems with multistate buttons (that should be fixed now) but other than that, I can't think of any outstanding button problems. There's the caption/id thing, but that's easily solved. Get some more info out of them :P

Posted: Sat Aug 18, 2007 1:46 pm

I will, though its probably fixed to be honest. I think its been a quite few versions since anyone from Aetolia except myself has tried cmud out.

Posted: Sat Aug 18, 2007 8:05 pm

The only problem i have with buttons is that the button toolbar is expanded in all windows in the session where the buttons should be (still only one instance of the buttons, which is good).

This is from my having the buttons in a different package I believe.

Posted: Mon Aug 20, 2007 2:38 am

The reason for this is tht all modules all modules and windows have a list of other modules that they have access to. If these modules have buttons (and toolbars) defined, even if they are not displayed, the window still allocates to the tool bar space.

The way to fix this is go to the properties for each (child) window and disable all the packages it does not need access to (presumably the ones with buttons at the very least.

Officially (technically) speaking, buttons outside of windows aren't supported, but as you are obviously aware a great many of them do. They are some hiccups however. For example, multi-state buttons can be displayed but not clicked if they are defined outside of a window. For more information on this discussion see this topic