Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD Beta Forum
Anaristos
Sorcerer


Joined: 17 Jul 2007
Posts: 821
Location: California

PostPosted: Fri Sep 03, 2010 4:45 am   

[3XXB] Strange #MXP and/or #LOOP behavior
 
I believe I posted this way back in 2.34 or so, but I had no concrete proof.
Insert the following in an untitled session:
Code:

// in an alias (call it test1) insert the following line which won't display in this forum due to special characters in the XML text:
#MXP <FRAME NAME="TEST" ACTION="OPEN" FLOATING TOP="-100C" LEFT="-200C" WIDTH="200" HEIGHT="200" SCROLLING="NO"></FRAME>

then:
Code:

  <alias name="test2" id="2">
    <value><![CDATA[#LOOP 2000 {
  #MXP <DEST "TEST" X=9 Y=2><color "0x5EFB6E">%i</color></DEST>
  #MXP <DEST "TEST" X=9 Y=4><color magenta>%i</color></DEST>
  #MXP <DEST "TEST" X=9 Y=6><color white>%i</color></DEST>
  #MXP <DEST "TEST" X=9 Y=8><color cyan>%i</color></DEST>
  }]]></value>
  </alias>
  <trigger priority="30" id="3">
    <pattern>^go$</pattern>
    <value>test2</value>
  </trigger>
  <alias name="test1a" id="6">
    <value><![CDATA[#MXP <DEST "TEST" X=2 Y=2><color yellow>LINE1: </color></DEST>
#MXP <DEST "TEST" X=2 Y=4><color yellow>LINE2: </color></DEST>
#MXP <DEST "TEST" X=2 Y=6><color yellow>LINE3: </color></DEST>
#MXP <DEST "TEST" X=2 Y=8><color yellow>LINE4: </color></DEST>]]></value>
  </alias>

Then at the command line enter:
Code:

test1
test1a
#SHOW go

You will see the MXP window update as expected. What it is not expected is the partial results that are being sent to the main window. As you can see from the posted code there is nothing being sent to the main window except what the #SHOW command displays.
The main window will display this:
Code:

go
65
129
193
257
322
386
450
514
579
643
707
771
836
900
964
1028
1093
1157
1221
1285
1350
1414
1478
1542
1607
1671
1735
1799
1864
1928
1992

This appears to be a series related to some function of the type (16x + y). Changing the loop range just shortens or lengthens the ouput to the main window.
The reason I am not sure which of the two commands is doing this is that this only happens to me when I use both together.
If you are wondering why I am running this off a trigger, it is because I am searching for the root of another problem related to MXP and in doing so I (re)discovered this (You can consolidate everything into 1 alias and run it). I will post on that shortly.
_________________
Sic itur ad astra.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Fri Sep 03, 2010 5:08 pm   
 
Wow, that's really strange. I was definitely able to reproduce it...thanks for the clear instructions and scripts. I'll add this to the bug list and look into it. I have no idea what's causing it.
Reply with quote
DemonLlama
Beginner


Joined: 03 Nov 2002
Posts: 27
Location: USA

PostPosted: Wed Sep 08, 2010 1:04 am   
 
I'll edit this to add more info when I have more, but I use MXP color codes (e.g., #SAY <color red>You're getting slaughtered!</color>) in some other #SAY statements. After running this alias (combining it all into one), I noticed three things:

1) The "failure" numbers are different depending on the number of #MXP statements you have in the #LOOP.
2) At some point during the loop, the displayed number flashes the color yellow and then goes back to what is designed in.
3) If you re-run the alias, each entire "LINE#: nnn" line is the color of the "nnn" (so, instead of a yellow LINE: and cyan 1000, you end up with a cyan "LINE: 1000").

Later, I noticed that after running this alias, my #SAY statements with MXP color codes were broken (from within triggers). I used a manual #SAY statement with those same color codes, and it worked... and "reset" my color codes, so now the trigger-based MXP colors are working as well.

EDIT: Existing MXP color codes continued to work (e.g., in a statusbar/window), just nothing coming as a statement from within a trigger/alias until after I manually typed one in.
_________________
~DemonLlama~
Reply with quote
Anaristos
Sorcerer


Joined: 17 Jul 2007
Posts: 821
Location: California

PostPosted: Wed Sep 08, 2010 1:20 am   
 
Yes, I am aware of this behavior. That was the reason I had the test set up the way I did (the odd loop behavior was collateral). I am also trying to find the root of the behavior you describe with no success. I find that for no apparent reason #MXP statements executed with aliases that are invoked whtin a #TRIGGER scope have no effect on the window. However, if you run the same aliases from the command line or invoke them from another alias which is not invoked from within a #TRIGGER scope, the windows will display the data. What is more frustrating is that on occasion things will work, then after I quit the session and come back, they have stopped working again. Another odd behavior is that the color of one entry will migrate to other parts of the window. I thought this was related to the number of writes being done which is why I instituted such a large loop, but as you can see if you run the test, the colors are displayed correctly. If I enable the "notrig" option (disable trigger on trigger), the mis-coloring seems to go away. Also, there is no failure from running in a #TRIGGER scope if done from a untitled session (as the above test shows), only in a live session this problem arises. What's more, this affects all scripts that write using #MXP, though this behavior only appeared when I started using #MXP from within GMCP triggers. That there is a relationship, this is apparent, that the relationship is linear, it is not. I am still looking, but frankly, at the moment I have run out of options.
EDIT Running the scripts in 3.23a, with the package which was current at the time, works. Running 3.23a with the package in the 3.24 or 3.25 state, fails. The failure is also applicable to 3.24
_________________
Sic itur ad astra.
Reply with quote
oldguy2
Wizard


Joined: 17 Jun 2006
Posts: 1201

PostPosted: Wed Sep 08, 2010 1:40 am   
 
Want to see something else weird? Use your exact same test above just like you have it except after entering #show go and letting it run to completion enter test2 on the command line. Then keep entering test2 and watch what happens.
Reply with quote
Anaristos
Sorcerer


Joined: 17 Jul 2007
Posts: 821
Location: California

PostPosted: Wed Sep 08, 2010 7:27 am   
 
Yes, it is weird. What's really interesting is that whatever is going on affects how the data is being displayed. I got it to the point where it was writing the stuff in italic font with reversed background, and all the colors washed out. However, once it cycles through and starts back so the first entry is in the 60 - 65 range, the colors come back. Note that white is the MXP default color.
_________________
Sic itur ad astra.
Reply with quote
oldguy2
Wizard


Joined: 17 Jun 2006
Posts: 1201

PostPosted: Wed Sep 08, 2010 9:21 am   
 
Each #mxp line causes 8 numbers to be displayed too. It loops through and then displays 7 and so on. With the 4 mxp statements it displays 32 (8 x 4) numbers and counts down as you continue entering test2. Then displays 31 lines and so on. It's like it is looping through all the coloring codes and mxp tags. It does underline and italics and strikethrough and so on. It displays a new number on the main window every 64th iteration. Then once you complete the cycle it starts over again.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Fri Sep 10, 2010 4:17 pm   
 
I actually did find the cause of this bug. The issue was with the DEST command (and any other MXP command that "gags" it's text). CMUD was not releasing a line attribute record when using DEST, so each time DEST was used and text was displayed on the same line, a new attribute record (which contains color info, etc) was being added to the line. Eventually this reaches the limit of the number of attribute records on a single line and was wrapping around causing corruption of the color data and screwing up the parsing of the line, causing the line to be displayed in the main window.

Fixed for 3.26
Reply with quote
Anaristos
Sorcerer


Joined: 17 Jul 2007
Posts: 821
Location: California

PostPosted: Mon Sep 13, 2010 3:35 am   
 
The problem with the bleeding colors has not gone away. If you have two fields next to each other ( a label field and a dynamically-updated field) such as:
Quote:

WHITE: XXX

Whatever color "WHITE" might be tends to bleed into the adjacent field and color "XXX" ignoring the color tag for that field. Doesn't happen 100% of the time but often enough to be noticeable.
_________________
Sic itur ad astra.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Mon Sep 13, 2010 6:08 pm   
 
You'll need to give me the exact script you are using like you did in the first example of this thread. Using the script at the top of this thread I am not seeing any problems in 3.26 anymore.
Reply with quote
Anaristos
Sorcerer


Joined: 17 Jul 2007
Posts: 821
Location: California

PostPosted: Tue Sep 14, 2010 2:36 am   
 
Here is the initalization code:
Code:


<alias name="mbtdinit" id="765">
  <value><![CDATA[#MXP <DEST @gmcpwin X=2  Y=36 EOF><color orange>WHITE: </color></DEST>
#MXP <DEST @gmcpwin X=13 Y=36><color orange>GREY: </color></DEST>
#MXP <DEST @gmcpwin X=23 Y=36><color orange>BLACK: </color></DEST>
;;
#MXP <DEST @gmcpwin X=2 Y=38><color orange>CONJUNCTION IN: </color></DEST>
#MXP <DEST @gmcpwin X=22 Y=38><color orange>FOR: </color></DEST>
]]></value>
</alias>

Here is the display code:
Code:

<alias name="mbtmdisp" id="764">
  <value><![CDATA[#IF (%trigger( @gmcpwin) != 1) {#EXIT}
;;
$bc = "white"
$gc = "white"
$wc = "white"
;;
#IF (@mdata.black <= 0) {$bc = "red"}
#IF (@mdata.grey  <= 0) {$gc = "red"}
#IF (@mdata.white <= 0) {$wc = "red"}
;;
#MXP <DEST @gmcpwin X=9  Y=36><color $wc>%format( "&2d", %abs( @mdata.white))</color></DEST>
#MXP <DEST @gmcpwin X=19 Y=36><color $gc>%format( "&2d", %abs( @mdata.grey))</color></DEST>
#MXP <DEST @gmcpwin X=30 Y=36><color $bc>%format( "&2d", %abs( @mdata.black))</color></DEST>
;;
#IF (@ldata.tickno != -1) {
  #MXP <DEST @gmcpwin X=18 Y=38><color white>%format( "&3d", @ldata.tickno)</color></DEST>
  #MXP <DEST @gmcpwin X=27 Y=38><color white>%format( "&1d", @ldata.ticklen)</color></DEST>
  }]]></value>
</alias>

The variable:
Code:

<var name="gmcpwin" type="String" id="46">Char</var>

Some sample data:
Code:

<var name="ldata" type="Record" id="787">
  <value>tickno=189|ticklen=5</value>
  <json>{"ticklen":5,"tickno":189}</json>
</var>
<var name="mdata" type="Record" id="763">
  <value>grey=-7|black=-32|white=-45</value>
  <json>{"white":-45,"grey":-7,"black":-32}</json>
</var>

The window is the same as the one posted above.
This section of the window gets updated after every mud tick (approx. 30 seconds)
The artifical way of deciding the color is done so because I thought the problem lied wiith the %if function.

I have a screenshot of the problem but the server where it is stored is blocking this forum from getting access to the image. If you like I can mail you the url.
_________________
Sic itur ad astra.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Tue Sep 14, 2010 4:25 pm   
 
You didn't give me any test procedure for reproducing the issue. I don't know what to do with the scripts that you posted. I tried running mbtminit and mbtmdisp and they both seemed fine here, but you didn't say what I'm supposed to do or look for to see the problem.
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD Beta Forum All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

© 2009 Zugg Software. Hosted by Wolfpaw.net