Zugg Software :: View topic

Newbie Joined: 29 Mar 2003 Posts: 3

Hi.

Normally I do not complain, since normally
I use freeware soft :-), but in this case...

There seem to be some sort of escalation in
load times of Zmud, I am a programmer, and
such an application really shouldnt take so
much resources, unless its built in haste.

Myself, when I still used zmud, didnt need
about 60% of its features, especially I didnt
need the two windows it were taking :-)

Actually a good example of how mud client
should look like one can see in FireClient
design, sad it doesnt support key binding
thought.

Why I post it? I still hope to use zmud in
the near future, and really hope it will be
faster instead being outnumbered in features.

Wanderer Joined: 08 Jan 2003 Posts: 60

I'd have no problem if it took 90% of my system resources and took three minutes to load if it would just handle ANSI sequences better. As it is, it's very hackish.

GURU Joined: 10 Oct 2000 Posts: 4379 Location: USA

araven:
What exactly do you find slow? zMUD's text scrolling speed and trigger parsing speed is really fast as it is right now.

virtuous:
How does it not handle ANSI sequences correctly? What is it doing wrong that it shouldn't?

Kjata

Newbie Joined: 29 Mar 2003 Posts: 3

Hi, again.

I did not mean regexp parsing capabilities
of the client :-) Normally zmud is not the only application running on my machine, its rather one of 5-7 running at the same time.

What I, as user, want from each of those
applications?

1. Low memory occupation, a lot of memory
taken by client, means constant swapping
and unswapping by the OS. Example of such
a flawed application most of you could see
in the latest releases of Easy CD Creator.
Me as a user, dont need easiness or beauty
in the application, I need speedy and
bugfree software. This is the only sofware
I am ready to pay for.

2. Good inbetween application navigation,
if each program I run would start making
numerous windows I would be lost. Both
useful and easy solution is tabs. Fireclient
and Editplus give a good examples of these.

Araven

Novice Joined: 24 Mar 2003 Posts: 44 Location: USA

Sound like a UNIX user

. Most people do need an easy and pretty programs, though. The load times have increased in the recent versions because they have to load JET/OLEDB.

--loves EditPlus, BTW

Wanderer Joined: 08 Jan 2003 Posts: 60

There is a bug where using #substitute in an Ansi trigger messes up. There is no way to trigger on the color of the text as displayed rather than the actual color codes sent to the client. Working with Ansi codes in variables is almost as difficult as working with special characters in variables. A lot of functions provide no means of using, or even of detecting, Ansi codes. There is no way to instruct a wildcard to match everything it usually matches except for Ansi codes. Setting up Ansi codes in triggers is cumbersome--Do regex triggers even support them?--and it is very annoying that pasting into an Ansi trigger's pattern obliterates everything already there. There is no convenient way to alter the color of a string that is not already stored in a variable, such as if I want to change the default color for a yell but allow player-specified color codes to remain unaltered. The color-specification keywords are not precise, such as brown/yellow instead of yellow/bold,yellow. The %ansi function is too literal, such that %ansi(white) after %ansi(bold,green) usually produces bold white instead of regular white, and the hack %ansi(def,white) is not even supported. The handling of the color syntax when copying from the mud output to the command line is buggy as well.

That's what I can think of, off the top of my head. I understand Zugg is trying to avoid featuritis, and I understand the difficulties involved in a program this size. I simply think it would be better to stop development for a while and stabilize the entire system before adding anything new. That's not feasible, though, because that would cripple the shareware system because a seemingly-halted program garners few investors.

Still, some alterations and additions would be nice, especially if there is a way to do it *now* instead of waiting for a future version, beta or not. I have considered plugin development, but Ansi codes are not available in the processed form, and I do not care to fumble my way through Telnet and MCCP to deal with it. And the inability to receive newline/prompt text *without* duplication is--when last I checked--not supported. The system doesn't need to send me the text a second time; all it needs to do is send me the new text. I think I can write code that remembers if it was or was not a newline.

GURU Joined: 10 Oct 2000 Posts: 4379 Location: USA

araven:
1. So the issue is not speed but memory? Although zMUD's memory usage has gone down dramatically recently, I understand how it may be a bit big for some computers. Especially if you run a lot of apps alongside zMUD. However, if your computer does not need to be constantly switching programs between the page file and memory, you will find that zMUD is really quite fast. This is only when loading and switching apps, once you have switched to ti and the computer is done with what it has to do, it will be as fast as it normally is.

2. Normally the only window that you would have when using zMUD is the MUD output window docked to the main toolbar. It's just one window. zMUD onyl creates more windows when you specifically tell it to create another window and when you open the Settings Editor, the Mapper, Database, etc. Even so, these windows can all be docked alongside the main MUD window or in some other configuration.

Kjata

GURU Joined: 10 Oct 2000 Posts: 4379 Location: USA

virtuous:

quote:
There is a bug where using #substitute in an Ansi trigger messes up.

Please post an example of the problem as well as the script that is beign executed and some sample MUD output that causes the problem.

quote:
There is no way to trigger on the color of the text as displayed rather than the actual color codes sent to the client.

I don't know what you mean by this. What is different from the color displayed to the one the MUD sends?

quote:
Working with Ansi codes in variables is almost as difficult as working with special characters in variables.

Try using %expand to control the expansion of variables. For example, you can tell to expand the variable only one level, which would be getting it's contents and not trying to parse special characters within it.

quote:
A lot of functions provide no means of using, or even of detecting, Ansi codes.

Most functions don't deal with ANSI codes and they don't need to since they perform what they do no matter if the text has ANSI codes or not. You may detect ANSI codes by looking for the presence of ASCII character 27.

quote:
There is no way to instruct a wildcard to match everything it usually matches except for Ansi codes.

Use ranges to avoid matching ANSI codes. Example: [A-Za-z0-9 ]

quote:
Setting up Ansi codes in triggers is cumbersome--Do regex triggers even support them?--and it is very annoying that pasting into an Ansi trigger's pattern obliterates everything already there.

Maybe I'm not understanding correctly, but you can use the %ansi function to include ANSI codes in whatever your trigger does.

quote:
There is no convenient way to alter the color of a string that is not already stored in a variable, such as if I want to change the default color for a yell but allow player-specified color codes to remain unaltered.

I don't understand what you mean. Example?

quote:
The color-specification keywords are not precise, such as brown/yellow instead of yellow/bold,yellow.

You may also use the numbers instead. Look at the help entry for %ansi(I believe) which has the numbers that can be used.

quote:
The %ansi function is too literal, such that %ansi(white) after %ansi(bold,green) usually produces bold white instead of regular white, and the hack %ansi(def,white) is not even supported.

That's because white is already the "bold" form. What you want is grey instead. %ansi(def, white) does not work because you should do" %ansi(default)%ansi(white)

quote:
The handling of the color syntax when copying from the mud output to the command line is buggy as well.

Example?

Kjata

Wanderer Joined: 08 Jan 2003 Posts: 60

quote:
Please post an example of the problem as well as the script that is beign executed and some sample MUD output that causes the problem.

I've mentioned it several times in the past. I think it's already on the bugs list.

quote:
I don't know what you mean by this. What is different from the color displayed to the one the MUD sends?

The perfect example is a problem I had recently. I have a prompt of the form <stuff in here>, and the < and > are blue. In front of the prompt can be special flags that state things like the most damaged formation member, whether I have news or mail, if I am invisible, et cetera. I had an ansi trigger set up like this.
^&%*{PromptFlags}%e[(ansiforblue)m<%e[0m&%d{HP.Curr}........
If there were no prompt flags, or if there were any prompt flags *except* for invisibility, it would work fine, and the ansi codes would stay in PromptFlags, and I even could see color in my status bar. But the invisibility indicator, [*], is blue too. So if that was there, the trigger would fail, because there was no blue change right before the < anymore, it was before the [*].
A better way to trigger this would be to say, instead of triggering on where the color changes are, trigger on the color of the text itself. So, in words, it would be like this. "Match the beginning of the line. Match and grab everything into {PromptFlags} until a blue < followed by (the rest of the stuff) until the end of line." The difference is just, instead of treating the ansi codes as characters to match just like if I wanted to match on an apostrophe, treat color as a property of each character (like it is in ncurses, if you're familiar with that).

quote:
Try using %expand to control the expansion of variables. For example, you can tell to expand the variable only one level, which would be getting it's contents and not trying to parse special characters within it.

That works perfectly. :-) Thank you, and I feel stupid for not understanding that sooner.

quote:
Most functions don't deal with ANSI codes and they don't need to since they perform what they do no matter if the text has ANSI codes or not. You may detect ANSI codes by looking for the presence of ASCII character 27.

What I mean is, the functions do not have the capability to grab the Ansi codes in the first place, like the other thread about selword and such.

quote:
Use ranges to avoid matching ANSI codes. Example: [A-Za-z0-9 ]

That works well enough for ranges, but it becomes horribly inconvenient, sometimes, like for matching more complex wildcards like %n. It's one of those things that is possible, but not preferable.

quote:
Maybe I'm not understanding correctly, but you can use the %ansi function to include ANSI codes in whatever your trigger does.

I meant in the pattern box, using the %e[1;36m syntax, which is hard to read in the pattern and in the test box too. Unless you can use %ansi in the pattern box in place of the %e syntax?

quote:
I don't understand what you mean. Example?

Like for the yell channel. "Brandark yells, 'I am a meat popsicle.'" "Josephine yells, 'JoSe ne1 spare a waterskin?'"
Now, say I want to capture this, but change the default color from blue to yellow. If it were in a variable, with a blue color code at the beginning, I could use string manipulation functions to alter that ansi code. But if not, and it's in a trigger instead, it just won't work well. If I #color yellow, it obliterates all the color codes of the message itself. And while it seems reasonable that I could capture everything in the trigger to variables and modify the codes that way, the fact is that %* has some sort of limit (I have tested) so that if the line is a certain length, or longer, the trigger will not fire. In addition, if I want to modify some of the text, changing "Brandark yells," to "[Yell] Brandark:", for example, then I would have to use even more complex string manipulation functions, because just inserting a color code using #say does not work; it has to be in the output variable itself. This one is actually the most complex and the least universal, so I set it to be something to probably be shelved, and settle with capturing the entire trigger to a single variable and using string manipulation functions to mess with, then displaying with your %expand technique.

quote:
You may also use the numbers instead. Look at the help entry for %ansi(I believe) which has the numbers that can be used.

Yes, that's true, I hadn't considered it... I could even create my own variable names containing the numbers. Very cool.

quote:
That's because white is already the "bold" form. What you want is grey instead. %ansi(def, white) does not work because you should do" %ansi(default)%ansi(white)

I see what you mean about white vs. grey. As to the default, I simply think it would be a nice syntax to have, to counter bold. Better than calling it def, call it dim. %ansi(bold,white) and %ansi(dim,white) is entirely unambiguous, and cannot be messed up by any defaults. I might create my own %ansi-like function to handle this behavior.

quote:
Example?

Frequently, when copying text that was bright white, it would show up as |F instead of as |W. (|F is what I have in my color syntax box as how to set the foreground color, and W the actual foreground character for bright white.) These errors would propogate throughout the thing, especially if the color stayed the same but it went from bright to dim. Going from yellow to brown, instead of being |Y to |y, it might be |Y to |F.

Posted: Mon Mar 31, 2003 6:54 am

virtuous, stop reporting the same bug reports over and over again in other people's topics. Post your OWN topic on bug reports and keep the comments there. We have already discussed the issues you raised in the Beta forum. Your reply had NOTHING to do with the topic the original poster asked about.

OK, back to the topic that araven asked about: araven, what version of zMUD are you using? The current public version 6.40 *does* have issues with load time and memory usage, but these have been fixed in the later beta versions. I'm not telling you to go use the beta version because a new public version will be available within a couple of weeks. But basically, the EXE file size is reduced, the memory usage is reduced by almost 50%, and the speed is increased. So, you should be happier with the next version.

Most of the features you are not using in zMUD are not taking up very much memory. Things like the mapper and database modules are only loaded when you use them. So, you shouldn't really worry about those advanced features...they are waiting for you when you want to get further into your MUD playing, but they shouldn't hinder your playing if you don't use them.

Wanderer Joined: 08 Jan 2003 Posts: 60

The first thing I said was just a comment sparked by the author's posting. After that, I was responding to Kjata. I didn't realize I had repeated myself anywhere, and I'm sorry if I did. (If you mean my comment about Ansi and #substitute, I did actually say that it had already been taken care of.)

Newbie Joined: 29 Mar 2003 Posts: 3

Hi.

Glad you answered Zugg and glad there is a
less memory consuming client on the way ;-)

I have been using 5.5 if I am not wrong,
dont remember the version number exactly.
But switching between applications was an
issue, since some werent a static ones,
like Cygwin which was performing tests on
an application.

Araven

Wanderer Joined: 13 Aug 2001 Posts: 51 Location: USA

I'm using zMUD 6.55a and it's using just under 5MB of RAM. Compared to 12.5MB for Winamp, 21.1 for IE, and 12.3 MB for AIM, I think that's pretty good.