Match on tag...

How about a feature in triggers that would let you 'match on tag' so you can match on lines containing MXP information? It could prove useful and also provides a back door for people who for whatever reason are on a mud that does not directly support it, but want to use it for messaged, etc. And before you say once more that it was not intended for that... Then why have a default mode supporting basic color manipulation if they didn'e expect people to use it.

Zmud should be able to use it this way as well in a a future version, since Zugg says he is working on the bugs in it and unlike MUSHclient it currently does ignore invalid tags, sending them to output instead. This would allow you to continue to use it the same way it works now, while allowing more versitility in triggers and a back way around the problem that currently makes using it on non-mxp specific muds a bit problimatic. Not to mention a way to support tags that may be added to the implimentation of MXP yet and thus not directly supported. (Say a streaming media ActiveX component for instance.) ;)

Only a thought. ;)

On the scripts configuration screen there is an "MXP" button. If you click on that you will see there are script routines that MXP tags can call (there are examples in the supplied script file).

Thus, you can get a script triggered on a tag, and do whatever you want when that happens.

I don't agree with the way that zMUD displays unknown tags, as it makes it difficult for a MUD to be forwards compatible. In other words, if the MXP spec adds a new tag, and a MUD starts using it, everyone would have to immediately upgrade their client or else see <blah>some text here</blah> on their screens. MUSHclient silently discards those (or reports on them in the warning log, if you are interested), so you can use older versions of MUSHclient even after new tags are implemented.

This behaviour is exactly like HTML, so that you don't have to constantly upgrade your web browser, which given how each new version seems to be bigger and (at times) have more bugs, is probably a good thing.

Thanks. And I see your point about added MXP tags that are not supported. The odds of a mud immediately upgrading when a new tag is added is not likely though, since for most muds that would require serious changes to the core code and a recompile. Unless the feature was truly unique, it is not likely. Also, there is no major difference in having to upgrade to an MXP client if you suddenly find you need it. Anyone that cares about such features is probably not using a free client and will be upgrading fairly often anyway. But as I say, that is mearly my opinion and the way zmud does it may even be one of the bugs currently in its MXP support.

My only complaint about the do this on MXP event thing is that if you trigger on every opening tag event for instance, you waste a lot of time looking at tags and things that you do not actually need to. Not good to lag a client that way, but it is nice to know it is there.

All sorts of things hidden in MUSHclient that I keep overlooking. lol

Hmm. Well my MXP ghosting almost worked... Lines that contain only a false tag such as a room name work correctly, but if I get a line like this:

xyz tells you: consider <mob>, then consider <self>.

The script I made registers an MXP error and returns the result, but when it tries to display it I get:

xyz tells you: consider
<mob>
, then consider
<self>
.

I am using world.tell, but it seems like the MXP error routines or something is adding a line feed in there some place. This really shouldn't happen if all the matches are on the same line, since world.tell should only auto-terminate a line if new information is recieved, not every time it gets a bad tag. Otherwise I can now side step Mushclients design and display tag like info that is not recognized by MXP. Just wish I knew why it breaks the line up that way, but since I can't make it ignore tags that are not at the start of a line... This is the best possible solution for getting around the limitations of MXP on non-MXP complient muds that I could come up with.

For anyone interested the code is:



And the addition of this script name to the error script setting for MXP on the script configuration. This allows you to (save for the minor glitch above) to use MXP color in tells, says, mudmail, etc. on a mud that doesn't use MXP and uses < and > in places that would normally cause MUSHclient to eat the contents. Though it should be noted that this also assumes that the lines contain <<Words>>, instead of <Words>. If it is the later you will end up with an extra > at the end. ;)

The error code is called 3 or more times for each failed tag and you have to use the 'A' line to retrieve the contents of the false tag, because the 'E' message only returns the first word, not everything between the brackets.

EX - <The Plaza> would produce something like:

1st.> E ### ### Error message.
2nd.> A ### ### MXP Element: <The Plaza>
3rd.> E ### ### Unknown MXP tag: <the>
(As near as I remember, it has been 1-2 days since I wrote this script.)


P.S.:
I did however notice another more serious problem while doing this. The color for room names in the area that was causing me problems is Dark Green. Having failed to remember how to set this using predefined color names (green gave me the hi-color rather than the dark one) I instead used the color code - &h008000. Only problem is that world.notecolourRGB seems to ignore this and displays notes in the current note color. This is supposed to be a valid color, but wouldn't display. Instead I had to use &h118011, though &h118000 may work (I didn't test it). Looks like it is ignoring anything that starts with 00 except black. This makes setting colors for notes a little troublesome. :p

world.tell is designed to trigger a new line on a change of line type.

In other words, consecutive "tell" lines will stay on the same line, but once output from the MUD arrives, (or a command echo) it assumes that it should be on a new line.



The server shouldn't be serving up descriptions like this. I seem to remember going over this before. A proper MXP-enabled MUD will change those to &lt; and &gt;

If you are trying to use MXP tags on a MUD that isn't designed for it you are falling outside the design parameters of the MUSHclient implementation.

Ok. First item... There is no 'new' information coming in or commands being echoed, but if you have an MXP error it seems to be treating things as though one of these two possibilities is happening, so...

Though I think I see the reason I don't agree with it. I am guessing that tags are processed as soon as they arrive, so even if more than one is on the same line it treats each one as seperate input from the mud. So world.tell in scripts for tag effects would instead of imbedding new text 'within' a line inadvertantly breaks the line when the next bit of text arrives, even if it would have been on the same line. :p There are bound to be 'valid' reasons why this will mess some people up, since it will cause problems if people want to add something to the output every time a certain valid tag arrives, without completely disrupting the existing text.

2nd. Item - True it is not within the limits of what MUSHclient was designed to do. The fact that I am in this case trying to get around a minor glitch that prevents me from using MXP and not recieving &lt and &rt from the mud is just an interesting quirk. Also you pointed out before that using tags in tells and such was probably not intended, but the specification implies that it is to some extent. Even ANSI codes can be sent through mud communications, but most muds strip out the escape characters and disable the codes (a hold over from the days when you could get your hard drive erased by some idiot remapping F1 to be 'format c:'). It may not actually be intended, but if people only did what designers intended a lot of stuff we use today wouldn't exist. lol

In any case other than the odd added line feeds most of the post was mearly for consumption of people who are like me a bit crazy and want to find a way around this minor quirk without harassing game admins to change every <> to their html version. If something can be done someone is almost certainly going to try it. ;) And will likey try even if they can't do it. lol

---------

What about the world.notecolorRGB problem though. This has nothing to do with 'unintended' uses. It just does not seem to work right when the color code is anything like &h00####. This is something that needs to be corrected (unless I am just missing something). :p

Yes indeed, you have spotted a bug that was lurking there for a while. I suspect that what is happening is that the high-order bits are "spilling over" into the blue byte.

eg.

&h007F00 <- works
&h008000 <- doesn't work ( 80 could be considered negative)
&h018000 <- works for some reason

I have added that as bug/suggestion #452.

As a work-around, either add a small amount of blue (last example above) or use a slighly smaller amount of green (first example above).

Yes, each tag is processed as it arrives "on the fly".

All goes well unless you try to do tells in the middle. My examples in the script file don't do that, for that very reason. You are confusing MUSHclient by changing the line it is processing underneath it (by adding tells).

This seems to be a bug in VBscript, it is actually passing in the number:


&hFF8000


to MUSHclient.

In JScript the problem goes away, so it is not an internal MUSHclient problem.

As a workaround, in VBscript, add an extra "1" to the 4th byte, like this:


/ world.NotecolourRGB &h01008000, &h00


That additional "01" causes the correct colour to be displayed, but is ignored by MUSHclient.

Alternatively, this will work:


/ world.NoteColourName "green", "black"


Or, even this, which works around the VB problem, but still lets you use hex:


/ world.NoteColourName "#008000", "#0"


Well. At least the work around is easy to manage. Thanks.