|
ArjenJ Wanderer
Joined: 30 Jan 2006 Posts: 66
|
Posted: Sun May 21, 2006 9:24 pm
word wrapping |
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. |
|
|
|
shalimar GURU
Joined: 04 Aug 2002 Posts: 4689 Location: Pensacola, FL, USA
|
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 |
|
_________________ Discord: Shalimarwildcat |
|
|
|
ArjenJ Wanderer
Joined: 30 Jan 2006 Posts: 66
|
Posted: Mon May 22, 2006 8:04 am |
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.
|
|
|
|
Ulfy Newbie
Joined: 07 Oct 2003 Posts: 7
|
Posted: Mon May 22, 2006 10:50 am |
|
|
|
|
Ulfy Newbie
Joined: 07 Oct 2003 Posts: 7
|
Posted: Mon May 22, 2006 10:50 am |
Posted in the wrong thread, apologies.
|
|
|
|
shalimar GURU
Joined: 04 Aug 2002 Posts: 4689 Location: Pensacola, FL, USA
|
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} |
|
_________________ Discord: Shalimarwildcat |
|
|
|
Vijilante SubAdmin
Joined: 18 Nov 2001 Posts: 5182
|
Posted: Mon May 22, 2006 10:53 pm |
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. |
|
_________________ The only good questions are the ones we have never answered before.
Search the Forums |
|
|
|
Seb Wizard
Joined: 14 Aug 2004 Posts: 1269
|
Posted: Tue May 23, 2006 10:57 pm |
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.
|
|
|
|
|
|