Zugg Software :: View topic

Wizard Joined: 17 Jun 2006 Posts: 1201

Well for Achaea I was still having problems with commands screwing up my display. Like it would cut room descriptions in half or the prompt in half on the display once in awhile.

Example:

3500h, 3800m, 16400e, 16400w cexdkick rat
b-

Stuff like that. This is annoying. It will also sometimes put the direction I send from command line inside of a room description on the display which cuts the line in half. I posted on this awhile back and no one ever responded after Zugg's post.

However, another thing I am curious about is the speed. It just seems slow to me, especially during large battles or when tons of text is coming in. What are some times you all get?

For instance, running a small test like:

Magician Joined: 28 Jan 2007 Posts: 430

Well, I personally haven't had display issues like those you're explaining at all.

I did your test under my package, though it isn't by any means very large yet, and got an approximate 350 ms.

Somehow doing CTRL Q doesn't work for me in a non-untitled session, worked otherwise though but that number wouldn't
show anything concerning matters at hand.

I'm sure you've heard that before but maybe you should piece by piece look over your battle code. As you say
that's when the huge speed pumps usually happen.

Just my .002, heh.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Your test

Posted: Mon Dec 22, 2008 3:13 am

The display problem, if I recall, is caused by CMUD's tolerance for MUDs that don't comply with the telnet standard. The problem occurs when your command is sent just as a packet boundary appears inside your prompt - the packet boundardy isn't terminated with any text, which isn't part of the telnet standard - prompts should be terminated with GA or EOR, and IRE muds do this properly.

Trouble is that many MUDs don't do this correctly - they just end the packet with no terminating sequence, and leave the client to work it out. So CMUD isn't going to wait around for a GA or EOR that may or may not be coming; instead, it assumes that the packet boundary is the end of a prompt and puts your command between the end of the first packet and the start of the second. Hence the display issue.

If I recall, a possible fix was suggested in that CMUD might detect or be told if the MUD is propery terminating its prompts with GA or EOR. If it is, then packet boundaries wouldn't be treated as prompts any more, and the problem should disappear. I can't remember if that suggestion was responded to as feasible or not, nor if it's on the wishlist. Zugg will know more.

As for speed, a short expansion on Viji's "speed of rejection" and "speed of match". These two aren't normally both achievable with the same pattern - rejection means that a line that doesn't match is rejected as quickly as possible, but may slow down a match on a line that fits the pattern; speed of match is the opposite, matching lines that fit the pattern as quickly as possible but rejecting lines that don't fit slightly slower. Which you're going to optimise for depends on how often the trigger fires compared to the volume of text and isn't something we can really help you with - you're going to have to use your own judgement.

Regexes have lots of features to help you adjust these two speeds - the two you'll probably use most frequently are non-greedy quantifiers (.+? versus .+) and atomic grouping and quantifiers (which are quite complex and should probably be read about on their own). But the short answer is that triggers take a lot of tweaking to get them running as quickly as they can.

The regex engine isn't the only factor in chug you might get during combat, either. Some script operations are slower than others and you can often write scripts slightly differently to improve speed, usually at a cost to readability or at an increase in headaches when trying to understand exactly what the code's doing. It's up to you whether or not you think it's worth it, and only you know your scripts well enough to find the problem areas - it takes some difficult debugging to find them sometimes, too.

My advice would be to use as few variables as you possibly can, and rely on local variables and events as much as possible. If you're going to be doing a lot of operations on a variable (like sorting it), it'll probably be more economical to put the value into a local variable and do your operations on that, putting the value back into the "real" variable at the end if you need to. This advice is so general that it's almost useless, I know, but it's the best I can offer :(

Wizard Joined: 17 Jun 2006 Posts: 1201

Wizard Joined: 17 Jun 2006 Posts: 1201

Well I think most of the slow issue was simply due to some coloring triggers based off of a string list of names. One of those had 800 names in it. Another one had 300. So every single word was checking through those lists, which really was quite fast I guess.

Posted: Mon Jan 05, 2009 6:46 pm

To answer the original question, which I'm pretty sure I answered in your other post as well, CMUD can insert text on the screen anytime there is a packet break from the MUD. So in your example:

3500h, 3800m, 16400e, 16400w cexdkick rat
b-

the MUD had a packet break between the "cexd" and the "b-" text. Whenever there is a packet break from the MUD, CMUD is allowed to add any text that your triggers might generate.

Packet breaks can be very network dependent. The Internet is allowed to break network packets at any point. This can also be caused by TCP/IP packet properties in Windows, your network router, or your ISP.

It is not something I can change or fix in CMUD. Most MUDs do not mark the end of a MUD prompt in any way...just with a packet boundary. That is why CMUD is allowed to insert text to the screen after any packet boundary...because CMUD thinks it's at the end of a MUD prompt.

Posted: Mon Jan 05, 2009 8:02 pm

Is there really no way to add a preference for those playing MUDs that do properly terminate their prompts, though, to turn that off? I understand that you can't just ignore packet boundaries without breaking a lot of MUDs, but being able to selectively turn it off would fix this problem.

Posted: Mon Jan 05, 2009 10:34 pm

That is already on my to-do list for the future.

Magician Joined: 17 Apr 2005 Posts: 496

I'm guessing that you're colouring city/order/etc. members/enemies based on a string list of names (I've fooled around with it myself, and yes, it is really bloody slow). You might want to look at this old thread about Patricia trees. Implementing something like that for those specific string lists would vastly improve your match time on names. Before you ask, I've fooled around with implementing it myself in a general way, and it's not for the faint of heart, CMud (understandably) doesn't have the best interface for implementing custom data structures... but it's certainly an interesting problem to while away the hours (days/months/years) with...