Zugg Software :: View topic

Wanderer Joined: 30 Jan 2006 Posts: 66

I've tried switching of the server side word wrapping of the MUD I'm playing at the moment to simplify a lot of my triggers. But zMud seems to be terribly slow in doing the word wrapping...... Is this a known problem and is there maybe a way to solve this problem client side, besides hardware upgrades?

Thanks in advance.

Posted: Sun May 21, 2006 9:38 pm

It is in the works for CMUD I heard.

some muds have a 'cols' command to set the number of colums wide the screen is... if they dont have it already, suggest they impliment it

Wanderer Joined: 30 Jan 2006 Posts: 66

My mud has such an option but that makes triggering certain things difficult... that's why I'd like zMud to do the wrapping instead of the MUD. But right now that makes zMud to slow to handle.... so lets wait for CMUD.

Newbie Joined: 07 Oct 2003 Posts: 7

Newbie Joined: 07 Oct 2003 Posts: 7

Posted in the wrong thread, apologies.

Posted: Mon May 22, 2006 3:32 pm

i know if i set cols to 999+ then zMUD can handle the wordwrapping options fine
when i need to see somethat that that column width makes it ugly and unreadable, i make an alias

#ALIAS command {cols 120;%-1;cols 999}

SubAdmin Joined: 18 Nov 2001 Posts: 5182

ArjenJ is talking about speed. This is from a topic brought up over at the Achaea forums when they finally added an option to disable MUD side wrapping. It seems that the overall speed of zMud degrades when it has to both wrap lines and put the full line through trigger testing. This became an issue because Achaea has some text outputs from command that are around 600 characters, by changing the wrapping to zMud, now triggers are testing against that whole 600 characters all the time. Hopefully the 'exclusivity' flag that cMud is adding will correct this problem, by allowing large texts to quickly be elminated from further testing, this will cut the overhead costs involved in memory copies drastically. The problem lies less in the actual wrapping of lines then it does in having to copy the entire text of the line, and sometimes the previous line(s) where multiline triggers are concerned, to the stack for each trigger that has to be tested. The larger line sizes, for just a few lines, is enough to cause speed reductions that carry over during high spam periods, such as when zMud is most critical, combat.

Best I can say, is that there is no real way for Zugg to fix how this works, without recoding the 3rd party component used for regular expression testing. From my experience with such components they are harder to understand than a manual on implimenting string theory on the creation of matter from energy, meaning they are completely impossible. So I think we will just have to wait for that 'exclusivity' flag in CMud and talk Zugg into whatever levels of implimentation are required to make it useful.

Wizard Joined: 14 Aug 2004 Posts: 1269

Just an idea, but you may also see some speed improvements by trying as much as possible to match the beginning and/or end of lines with your triggers - I expect particularly the beginning of the line. In other words, make sure that as many of your triggers as possible start with a ^ to match the beginning of the line. This way the trigger parser does not have to parse the whole line looking for the string. I think in earlier versions of zMUD this increased speed somewhat - I'm not sure if it is still a factor.