 |
ReedN
Wizard
Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon
|
 Posted: Fri Feb 06, 2009 1:52 am
[3.03a] CMud becomes unresponsive under a large amount of received text
|
Issue:
I find that when in combat and there is a large amount of text coming in from the Mud, Cmud becomes unresponsive and it becomes difficult or impossible to type something into the command line. I have a non-combat routine which bears a very good resemblance to these symptoms and so I created a small example based on it.
Instructions to Reproduce:
| Code: |
1) Enter Cmud, press Escape to enter a blank session.
2) Copy the xml code below and right click and paste it into 'untitled' in the settings editor.
In the xml code is my routine for counting shards. I have a bunch of shards in my inventory and I send out commands to inspect each one of them. As the descriptions come back I add up their weight which is to be printed when everything has been counted. To simulate the effects of being connected to a Mud I've created a 'MudResponse' folder which will mimic the responses of the Mud, sending back exactly what it would send back.
3) Type: 'shards'. While it is executing, try to type something into the command line.
You should find the command line unresponsive until the code completes. This actually completes fairly rapidly without actually being connected to a Mud. If I'm connected to a Mud, the responses from the Mud take longer to arrive and it locks up the command line for a much greater length than what you will experience in this example.
This isn't an infinite loop and if you look at your CPU utilization during this test you won't see it spike or do anything to terribly interesting. It just denies you access to your command line.
Additionally, it is gagging the line "#say "It weighs about 4 pounds and 15 ounce(s)."" and I can't figure out why it is gagging it. There are no triggers that should be gagging this line. However this weird behavior seems to only happen in my toy example. I don't see this erroneous gagging occurring in practice while connected to the Mud.
|
XML Code:
| Code: |
<class name="Shards" id="1">
<class name="shardActive" initdisable="true" enabled="false" id="2">
<trigger priority="23390" case="true" regex="true" id="3">
<pattern>^This strange-looking shard</pattern>
<value>#gagspace
#T+ shardCountAlarm</value>
</trigger>
<trigger priority="23400" case="true" regex="true" id="4">
<pattern>^Type MORE to continue reading</pattern>
<value>#gagspace
more</value>
</trigger>
<trigger priority="23410" case="true" regex="true" id="5">
<pattern>^\s{6}shard(\d+)</pattern>
<value>#gagspace
pr %1
#gagspace</value>
</trigger>
<trigger priority="23430" case="true" regex="true" id="6">
<pattern>^It weighs(?: about)? (?:(\d+) pounds?)?(?: and )?(?:(\d+) ounce\(s\))?\.$</pattern>
<value>$weight = 0
#if (!%null( %1)) {$weight = %1}
#if (!%null( %2)) {$weight = %float( $weight) + (%float( %2) / %float( 16))}
#add pounds $weight</value>
</trigger>
<trigger priority="43210" case="true" regex="true" id="7">
<pattern>^(?:It has about|An unseen presence|You are|\d+h|\s)</pattern>
<value>#gag</value>
</trigger>
</class>
<alias name="shards" autoappend="true" id="8">
<value>#var pounds 0
#T+ shardActive
#T+ shardCountAlarm
ii shard
#gag
#repeat 3 {
more
#gag
}</value>
</alias>
<var name="pounds" id="9">7406.25</var>
<trigger name="shardCountAlarm" type="Alarm" priority="95920" enabled="false" id="10">
<pattern>*4</pattern>
<value><![CDATA[#if (@pounds <> 0) {
$cost = %round( @pounds * 0.075)
$cost = $cost * 100
#print %format( "Shards: &d lbs, Cost: &d gold", @pounds, $cost)
} {
//
#print "No Shards to Count!"
}
#T- shardActive
#T- shardCountAlarm]]></value>
</trigger>
<class name="MudResponse" id="11">
<trigger type="Command Input" priority="120" regex="true" id="12">
<pattern>^ii shard</pattern>
<value>#repeat 300 {#say " shard237252 a chipped iconic shard"}
#say "Type MORE to continue reading"</value>
</trigger>
<trigger type="Command Input" priority="130" regex="true" id="13">
<pattern>^more</pattern>
<value>#repeat 300 {#say " shard237252 a chipped iconic shard"}</value>
</trigger>
<alias name="pr" id="14">
<value>#say "This strange-looking shard is made of a stone-like material and sports sharp, jagged edges as if it had been cloven from a larger source. Faint power pulses from it, giving off a soft white glow like an illuminated crystal. Inscribed upon the shard's smooth surface are many exotic, alloy-filled glyphs that glitter strangely with a light of their own."
#say "It has about a month of usefulness left."
#say "It weighs about 4 pounds and 15 ounce(s)."</value>
</alias>
</class>
</class>
|
|
|
|
|
|
Rahab
Wizard
Joined: 22 Mar 2007
Posts: 2320
|
Posted: Fri Feb 06, 2009 5:54 pm
|
Perhaps I am confused, but it sounds like you are saying that if triggers are processing a line from the mud, you cannot execute a command from the command line and the mud does not display the next line from the mud, until the current line is processed by all triggers. If that's what you are saying, then yes, that is what happens. Cmud will not display the next line until it finishes processing the current line. It is unlike Zmud in that respect. Am I misunderstanding you?
|
|
|
|
|
charneus
Wizard
Joined: 19 Jun 2005
Posts: 1876
Location: California
|
Posted: Fri Feb 06, 2009 7:49 pm
|
I think what he's saying (and I experience it too) that you can't type a single thing in the command line upon receiving huge blocks of text or spam. I notice it quite a bit when I'm using my mapper aliases to run to various rooms, as well. The command line is unresponsive, and you have to wait until the screen stops scrolling to type anything in.
The problem with this is that we no longer can be in battle with huge spam and expect oue commands to go in. Things like this can be the difference between victor and loser. :p
Charneus |
|
|
|
|
ReedN
Wizard
Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon
|
Posted: Fri Feb 06, 2009 8:19 pm
|
Yes, Charneus has it right. That's exactly what I was trying to say. Also, although the example I used may seem like some contrived case, I believe the mechanism is the same for when in battle and you can't type because of the spam.
|
|
|
|
|
Rahab
Wizard
Joined: 22 Mar 2007
Posts: 2320
|
Posted: Fri Feb 06, 2009 9:48 pm
|
Have you tested whether the problem is that your triggers are still processing the huge block of text? That would be my first guess. The command line won't respond while a line is being processed by triggers.
|
|
|
|
|
ReedN
Wizard
Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon
|
Posted: Fri Feb 06, 2009 9:57 pm
|
The way it is implemented above processes it all at once, but in practice, the Mud inserts some waiting in there that isn't present in the code above. The effect is the same either way. You can't type in the command line.
I could try again to adjust it to mimic more closely how the Mud sends data. I figured it was rather irrelevant since the symptoms were equivalent either way. Processing large amounts of text causes the command line to become unresponsive. |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Sat Feb 07, 2009 1:14 am
|
Please follow Rahab's advice and play around with disabling various triggers to determine which triggers are causing the problem. CMUD *does* block command line input when it is in the middle of executing another thread to prevent thread loops (or the equivalent message queue loops that zMUD had). You can get around this "blocking" by adding a simple #WAIT command to a trigger to tell CMUD to continue processing the script in the background to see if that helps.
Your test script is also going to be a problem. CMUD blocks command line input in the middle of a loop, so when you do something like #REPEAT 300, you won't be able to type in the command line until that is completely done. This is completely different than how text is processing from the MUD where the command line is not blocked at all by the incoming MUD text. So this makes your particular script a lot less responsive than normal MUD input. Again, putting a #WAIT before your #REPEAT 300 should help with this by placing the scripting doing the #SAY into the background.
The reason I say all of this is that when I play on my MUD and get large amounts of text, I never have any problem with the command line becoming unresponsive. Again, it's all up to what trigger processing you are doing on this text. So in your "real life" MUD example, try disabling your triggers to determine which one is causing the command line to get blocked. If you don't have any triggers running, then CMUD will never block the command line input. You can easily test this in a blank session by connecting to your MUD and then displaying a lot of text from the MUD. |
|
|
|
|
|
|
|
