Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Due to spam on this forum, all posts now need moderator approval.

 Entire forum ➜ MUSHclient ➜ MXP and Pueblo ➜ Behavior of MXP Errors

Behavior of MXP Errors

It is now over 60 days since the last post. This thread is closed.     Refresh page


Posted by Shadowfyr   USA  (1,792 posts)  Bio
Date Tue 23 Sep 2003 08:30 PM (UTC)

Amended on Tue 23 Sep 2003 09:04 PM (UTC) by Shadowfyr

Message
Ok.. I know I have gone over this before and you have said that Mushclient was never intended to allow this sort of thing. However, I recently realized that it would be convenient to add a real hyperlink to something for those that have MXP, but to use it with Mushclient requires 'faking' the way other client mishandle other 'bad' tags. So here is what I came up with this time:

function MXP_Error (level, number, line, message)
  dim StyleF, StyleB
  if level = "E" and number = 1001 then
    Inf = GetLineInfo(line, 11)
    StyleF = GetStyleInfo(line, 1, 14)
    StyleB = GetStyleInfo(line, 1, 15)
    colourtell RGBColourToName(StyleF), RGBColourToName(StyleB), "<"
  end if
  if level = "A" and number = 20000 then
    setvariable "LastElement", message
    dim Inf, t
    Inf = GetLineInfo(line, 11)
    StyleF = GetStyleInfo(line, 1, 14)
    StyleB = GetStyleInfo(line, 1, 15)
    setvariable "LEFore",StyleF
    setvariable "LEBack",StyleB
  end if
  if level = "E" and number = 1023 then
    StyleF = getvariable("LEFore")
    StyleB = getvariable("LEBack")
    colourtell RGBColourToName(StyleF), RGBColourToName(StyleB), replace(getvariable("LastElement"),"MXP element: ","")
  end if
  MXP_Error = 1
end function

It works like a charm, save for two issues. Example: if I send these lines>

<color purple>Loriah << East Road - Bladesman Avenue >>
<color gold>Loriah << East Road - Bladesman Avenue >>

You get:
-purple-Loriah
-previous color-<< East Road - Bladesman Avenue >>
-gold-Loriah
-purple-<< East Road - Bladesman Avenue >>

So.. Problem one - When an MXP error happens, it automatically adds a life feed. This only happens if you are using the Error callback. Why?? It makes no sense for this to happen, especially since the rest of the line appears 'after' anything you do in the function. I.e.

With MXP Error:
Loriah
>

Without it:
Loriah >

Second issue, the line number that the error 'supposedly' happened on is either wrong or something is not being processed right, because the line styles for that line do not match what exists there. Instead it seems to be retrieving line styles from the 'previous' line. However the actually line contents when returned using GetlineInfo(line,1) is correct. Worse, Inf in the above shows 3 styles on the line, but style 2 is invalid (NULL strings) and causes the colourtell in the if-then with 1023 to generate an error.

Neither of these problems make sense imho. Though the later 'could' be the result of the line not yet completing, since the last ">" has yet to be displayed, but then why would it be returning a style at all, even if inherited from the prior line?

NOTE: While in my case I am trying to cheat my way around the way Mushclient handles things, there have been cases in the past where something like this would have been helpful for those who just plain happened to play on a mud where MXP isn't implimented properly. Due to these two quirks, there is simply way around the problem, especially since there is also no option for colourtell that will make it default to the 'current color', but instead it seems to default to the note color. :p This could be a nice addition:

colournote "current_color","current_background","Blah.."
colourtell "current_color","current_background","Blah.."

It would at least solve one problem and could be fairly useful, since it would let you insert lines into something that match the color, without relying on Styles, which often prove to be a major pain when all you want to do is get the current colors being displayed.
Top

Posted by Shadowfyr   USA  (1,792 posts)  Bio
Date Reply #1 on Thu 25 Sep 2003 05:32 PM (UTC)
Message
Are you looking into these quirks Nick or just ignoring them, since I am trying to do something not intended?

BTW: The documentation is a bit vague on colournote and colourtell, both say that if you leave off a color attribute, using "", they default to the current color. While it is obvious that this is the current 'note' color when you use them this way, the help file could be read as using the last 'outputed' color. And in most programming languages this is the sort of thing you would expect to see. The fact that you can't actually retrieve and use the last output color in some cases, like this one specifically, doesn't help much if you want the later result.
Top

Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #2 on Fri 26 Sep 2003 10:50 PM (UTC)
Message
Sorry for not replying sooner, I have been distracted by other things.

For one thing, the transition between world output and a tell or note is considered a different "type" of line, and thus MUSHclient automatically starts a new line.

As for the current colour, couldn't you look at the style run for the current line and find what the RGB colour was for the most recent style?

I know what you are trying to do, but can't you contact the MUD admins and suggest they fix up their outputting routines for < and > if they are using MXP?


- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Shadowfyr   USA  (1,792 posts)  Bio
Date Reply #3 on Sat 27 Sep 2003 04:07 AM (UTC)

Amended on Sat 27 Sep 2003 04:59 AM (UTC) by Shadowfyr

Message
Hmm. I see, so it is the execution of the tell that is triggering a newline? That still seems a tad odd.

As for reading the style, I was trying to do that, but something about the error routine executing short circuits this or something, if you check the styles it tells you that there are 3 on the line, but only the first one returns a valid (and wrong) value. The value it returns is the last color used 'prior' to the color actually being displayed on that line. So if the part of the line that is visible is green, but the prior one ended with red, then you get red. The other two styles when requested return NULL, not empty strings, but actual NULLs or something.

As for telling them to fix the < and >. Two problems, in my case they don't actually use MXP on the mud. What I wanted it for won't work anyway, so for me even fixing it won't help, the tag I wanted to use only works in secure mode, so even if I could have fixed everything else, it wouldn't have shown what I wanted. However, even if it was an MXP mud, I seem to remember at least one person who tried to tell their muds admin that they needed to change those things and they refused. That doesn't leave you with a lot of options to get around the problem.
Top

Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #4 on Tue 30 Sep 2003 06:07 AM (UTC)
Message
Hmm - you are trying to fix MXP tag processing for a non-MXP MUD?

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Shadowfyr   USA  (1,792 posts)  Bio
Date Reply #5 on Tue 30 Sep 2003 05:31 PM (UTC)
Message
Not anymore. I was trying to stick a <a></a> that into a character bio I am making on the mud, but after some testing that tag is a secure mode only tag, so won't work anyway. I have once in a while had some clever admin throw MXP color imbedded tags at us as a joke, but in general the mud isn't MXP and what I was trying to accomplish wouldn't work anyway.

What I did come up with isn't too bad though. It would have helped if I could have at least gotten the colors to match and line in which the <> appear someplace in the middle of everything still get messed up, but it's no big deal for me. Now for those few people in the past whos own muds do use MXP but screw up the implimentation and then refuse to fix it, this solution only half fixes the problem. But that isn't your or my problem, however annoying it may be.
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.


15,762 views.

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum


[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.