Zugg Software :: View topic

Wizard Joined: 17 Jun 2006 Posts: 1201

I logged in and had the debugger running.

When I sent movement commands they are aliases which then reset a variable that I have if I move from a room and they also send the command to move that direction. Well here is the difference between what I actually did in the MUD and what the debugger shows.

Copied from the screen.

Posted: Sat Nov 10, 2007 6:12 am

It almost looks like you have multiple windows with the same name (Achaea). Check the Windows menu...is there more than one window listed with the name "Achaea"? I obviously need to do something to the debugger so that it shows a different label for windows that have the same name.

Also, it looks like you are using some sort of event called "se". Can you post the script for this event?

How long had you been logged in before you captured this dump? I'm a bit worried about the [40] which means you have used 40 background threads already.

Btw, the lines with the = instead of the | means that the debugger is showing the result of a #CW, or #SUB, or #PSUB or #PCOL. The debugger shows each step starting with the original MUD text and ending with what you see on the screen.

The lines with > instead of | show the text that is sent to the MUD. So according to the dump shown above, "southeast" *was* sent to the MUD 6 times. Also, the --- separators are automatically inserted each time you press a macro key or enter a command on the command line. In this case, it looks like your "se" event ran 6 times somehow. So you need to look to see how this event is being fired.

Hmm, actually, maybe "se" is a macro and it's just reusing the original thread called "Achaea Event". If that thread was originally created to run an event, then when it is reused, the name isn't changed. I can see where this will make the debugger a bit confusing, so I should probably fix this.

So if that is the case, then it looks like you pressed your "se" macro key 6 times.

Wizard Joined: 17 Jun 2006 Posts: 1201

Well SE is an alias.

Alias SE:

Wizard Joined: 17 Jun 2006 Posts: 1201

What the hell. I just got my ass kicked in the game because all the direction aliases are firing like 4 or 5 times each. All they consist of is the above.

Wizard Joined: 17 Jun 2006 Posts: 1201

It does the same thing if I type a direction manually.

Apprentice Joined: 26 Apr 2007 Posts: 113

I guess if [40] is cause for concern then [81] is even bigger cause for concern..?

I've been logged on for little over an hour.

Wizard Joined: 17 Jun 2006 Posts: 1201

That's nothing. Mine went up to [271]!

I also cannot type #THREAD on the command line. I reopened the debugger and it is back down to [58].

Apprentice Joined: 26 Apr 2007 Posts: 113

Since I restarted Cmud, despite my best efforts, it's remaining pretty resolutely at [1].

I'll keep trying to break it.

Apprentice Joined: 03 Nov 2007 Posts: 132

So far I am finding that every time an alarm fires, a new background thread is being created. I've no idea if they're being reused or not. Showing in my test window the debugger looks like this:

0.0014 | testwind | [1] testwindow Comline : start : #T+ TestAlarm
0.0026 | testwind | Trigger "TestAlarm" compiled (Pattern) : *1
0.0007 | testwind | [1] testwindow Comline : stopped
1.0051 | testwind | Trigger "TestAlarm" changed from "" to "#say 1.0054 | firing;#T- TestAlarm"
0.0009 | testwind | Alarm: *1
0.0011 | testwind | Trigger "TestAlarm" compiled (Normal) : #say 0.0013 | firing;#T- TestAlarm
0.0008 | testwind | [2] testwindow Trigger : start : Alarm "TestAlarm" 0.0011 | : #say firing;#T- TestAlarm
0.0008 | testwind | [2] testwindow Trigger : running
0.0021 | testwind | [2] testwindow Trigger : terminated
6.7087 | ---
0.0006 | testwind | [1] testwindow Comline : start : #T+ TestAlarm
0.0014 | testwind | [1] testwindow Comline : stopped
1.0031 | testwind | Alarm: *1
0.0011 | testwind | [3] testwindow Trigger : start : Alarm "TestAlarm" 0.0014 | : #say firing;#T- TestAlarm
0.0008 | testwind | [3] testwindow Trigger : running
0.0019 | testwind | [3] testwindow Trigger : terminated
18.974 | ---
0.0007 | testwind | [1] testwindow Comline : start : #T+ TestAlarm
0.0016 | testwind | [1] testwindow Comline : stopped
1.0030 | testwind | Alarm: *1
0.0011 | testwind | [4] testwindow Trigger : start : Alarm "TestAlarm" 0.0014 | : #say firing;#T- TestAlarm
0.0008 | testwind | [4] testwindow Trigger : running
3.9690 | ---
0.0006 | testwind | [1] testwindow Comline : start : #T+ TestAlarm
0.0016 | testwind | [1] testwindow Comline : stopped
1.0028 | testwind | Alarm: *1
0.0012 | testwind | [5] testwindow Trigger : start : Alarm 0.0014 | "TestAlarm" : #say firing;#T- TestAlarm
0.0008 | testwind | [5] testwindow Trigger : running
0.0021 | testwind | [5] testwindow Trigger : terminated

with the thread count going up by one every time the alarm is enabled. Should this be something of concern? It's pretty easy to see a situation where several alarms are enabled and disabled in a very short time during a fight.

Wizard Joined: 17 Jun 2006 Posts: 1201

Thats what mine is doing too and probably how I got up to [271] during a battle.

Posted: Sat Nov 10, 2007 6:32 pm

That's true...I don't think alarms are reusing the threads because alarms fire asynchronously in the background and the chance of your current thread being available for reuse when the alarm fires is pretty small. So that explains the high thread numbers.

oldguy2: It might help if you told us what messages you have enabled in the debugger window. The line that has the > instead of the | is the line that shows what is sent to the MUD, and in your example above, the "n" command was only sent to the MUD *once*

The MUD prompt lines:

Achaea |3580h, 3923m, 16800e, 16800w cexkdb-n

that are displaying more than once can be explained depending upon what messages you have enabled in the debugger.

First, the "Show session text" message causes a line to be written to the debugger whenever the routine that checks for trigger matches is called. And this routine is called twice for "prompt" text...once for the prompt (which fires any Trigger on Prompt triggers), and once again when you get a newline (which fires any Trigger on Newline triggers). I need to add some information to the debugger so that you can tell these two cases apart, but right now it will cause two identical lines in the debugger window.

If the "Show raw session input" message is enabled, then you will also see the text from the MUD displayed in the debugger when it is actually received from the network socket. Although on Achaea, this should be indicated with * instead of | since you probably have MCCP enabled.

In addition, if the "Show ANSI codes" message is enabled, then it might also display the line again to show the ANSI control codes in the line. Although it's not *supposed* to show that line if it's the same as the normal text.

Anyway, in the next version I'll try to add a better indicator of which message is causing which line to be displayed to make it easier to understand.

OldGuy2: So, I need you to try something for me. Create a New Session icon in your main CMUD session window and connect to your Achaea MUD from there. Before connecting, go to the Edit Session and then the Files tab and make sure to enter a different package filename so that it doesn't load your main settings. Then, log into your character and type the "n" command manually again and capture what happens. Make sure the "Show raw session input" message is ON so that I can see the raw text sent from the MUD.

If this looks normal, then you can connect back to your normal session icon. Then, turn OFF triggers using the gun icon in the command line, and then enter your "n" command manually again. You might also try playing with turning MCCP off, and also turning the ATCP support off. It's possible that Achaea is somehow sending the prompt more than once, which is what we need to find out.

I'd also be interested in hearing from other people that play Achaea to see if they also see the multiple MUD prompts in the debugger.

Certainly if you have a complex MUD prompt trigger, then having it process the MUD prompt several times is definitely going to cause the slowdown that you were getting in the past. We just need to figure out why the prompt is being processed more than once.

Wizard Joined: 14 Aug 2004 Posts: 1269

Wizard Joined: 17 Jun 2006 Posts: 1201

Alright I will get back to you on that. Also to let you know I still keep getting MCCP errors while logged into Achaea.

Wizard Joined: 17 Jun 2006 Posts: 1201

Wizard Joined: 17 Jun 2006 Posts: 1201

Triggers off shows...

Wizard Joined: 14 Aug 2004 Posts: 1269

The reason you are getting multiple room descriptions I think is partly because you have several triggers that match the same paragraph of text (which is sent to you as a single line). Notice that two of them start: "Achaea =The stars twinkle ". There is an "=" instead of a "|". That means the text was changed by a trigger. The other reason Zugg may have already explained in another thread.

Wizard Joined: 17 Jun 2006 Posts: 1201

Well if you say so... I don't have any triggers that match the room description. There are 4 room descriptions in a row after the room title Fish Street. I have the room titles colored only. It shows that in the beginning where the trigger fired to color the room title and then the description afterward prints to the screen 4 times in a row without the title. The only other thing that I color in the room is rat or rats so I can see them easily in the room and kill them. However, in the new session without any triggers it doesn't do that so of course it is probably something I am doing. I guess I can turn off all coloring triggers.

Posted: Sun Nov 11, 2007 5:21 am

If this is happening in a new session, is there a room in Achaea at the beginning of the game that I can get to that shows this problem? In other words, is it just happening in one area, or would it happen if I just created a new character on Achaea?

Also, as far as I know Iron Realms has *not* fixed the MCCP problems with ATCP yet in any of their games. I'll need to bug them again about this. But you should probably turn off MCCP until they fix their problems.

Wizard Joined: 17 Jun 2006 Posts: 1201

Apprentice Joined: 26 Apr 2007 Posts: 113

If you can't reproduce the same with ANY room in Achaea you can use portals to get to Shallam pretty easily. (If I remember from when Aetolia had Shallam instead of Enorian, there was a portal leading to Zanzibar street.)

Posted: Mon Nov 12, 2007 9:44 pm

OK, I found the issue with Achaea (and any other Iron Realms MUD). It was actually a red-herring. Your prompt trigger wasn't really firing more than once. The problem was that when Achaea sent an ATCP command, CMUD was calling the trigger routine to look for any Telnet triggers to override the ATCP. And I was showing Telnet triggers as normal triggers and displaying the last line from the MUD instead of the text sent to the telnet trigger.

So, I've fixed this display issue in the script debugger for 2.12. You'll still get two calls for your prompt...one with the Prompt option and one with the Newline option. But I am marking the prompt trigger call in the debugger with a ] character instead of the | character to help distinguish them.

Anyway, OldGuy you might want to turn off the ATCP option in the session preferences and see if that helps. But I still don't think we have found the original slowdown problem that you were having. You shouldn't use ATCP and MCCP at the same time anyway.

Also, please turn ON the messages for "show thread start", "show thread end". You have a line like this in your log above:

0.0006 | Achaea |Pattern: ^(\d+)h\, (\d+)m\, (\d+)e\, (\d+)w ([cexkdb@]*)\- : 0.0012 | (%1=3580, %2=3898, %3=16800, %4=16800, %5="cexkdb")
8.0030 | Achaea |3580h, 3898m, 16800e, 16800w cexkdb-

which shows that your prompt trigger is firing, but then you don't show the actual threads that are started so that we can see what it is doing. Looks like you turned this off partway through your example, because earlier there is a line:

0.0211 | Achaea |Pattern: \b(?:@cityrooms)\b
0.0004 | Achaea |[40] Achaea Trigger : start : Pattern "\b(?:@cityrooms)\b" : 0.0010 | #CW royalblue
0.0044 | Achaea |[40] Achaea Trigger : stopped

so this shows that a thread was executed for your cityrooms trigger. So either you turned the thread messages off, or there is something really weird going on with your prompt trigger that causes it not to create a thread.

I can see from the timings that your prompt trigger is executing *very* slow (8.0030 seconds in the above example), so I think that is where the problem is. I think you need to show us the full XML script for your prompt trigger so that we can help determine what is so slow about it.

Wizard Joined: 14 Aug 2004 Posts: 1269

I suggest also ticking the "Show when settings compile". I'm getting a variable recompiling due to my prompt trigger and I think it may be indicative of a bug. As the variable is supposed to just be a string and therefore should not be compiled at all (but does contain %line). That could just be a zMUD Import issue though and I may have to set the variable type to String (literal) instead of whatever it is now. Hmm, no, that doesn't help - it's still compiled. I'll post a separate thread on that - could be something else I need to change. Maybe the recompilation is not actually a problem, but try ticking it anyway.

Posted: Mon Nov 12, 2007 11:34 pm

Definitely post another thread about the string compiling issue. And yes, it's definitely useful to see the Compile messages when looking for speed issues.

Wizard Joined: 17 Jun 2006 Posts: 1201

My prompt trigger just captures my current health and mana values into variables. It then captures the defensive values at the end of the prompt into a local variable and changes the value of my defenses based upon if the letter exists or not such as

Wizard Joined: 14 Aug 2004 Posts: 1269

You haven't followed our suggestions though...