Using the MXP snippet on this site..
I belive this problem has todo with the secure mode sent at the beggining..
(MXP starts off as off)
[prompt] eq
You are using:
<held> a comlink
[prompt] config +mxp
Ok.
[prompt] eq
You are using:
<held> a comlink
[prompt] config -mxp
Ok.
[prompt] eq
You are using:
a comlink
[prompt]
I turn off mxp support, but it doesn't actually let mushclient know that we are no longer actually not doing MXP stuff.
If you turn on mushclient's debugging of MXP tags, it will do something like:
unknown element <held>
How do i do this? Turn it off i mean.
IAC DONT MXP \0
?
(forgive any information i've miseed, i'm on the tired side)
Your config -mxp thing may not be working correctly. If you're using Nick's very fine MXP code, it automatically takes care of changing < and > into non-MXP codes for you in case you're not running in MXP. I know, because I implemented it and it works perfectly for me. :)
ps, send_mxp_stylesheet is EXACTLY the same as the example's void turn_on_mxp (DESCRIPTOR_DATA *d), except i liked this function name better.
As I said, It works perfectly for when MXP is turned on. But in mushclient, when MXP is turned off, normal text like <held> does not get displayed, as mushCLIENT things its actually an MXP tag.
Unless this is something very specific to how you configured your mud, the problem with the "invisible" tags is server side, not MC. Considering I code, build and play a Dawn of Time mud, I can say for fact that if the server side info is properly configured, the inventory fields will indeed show up with mxp disabled. Everything else thats riddled with mxp in DoT shows up just fine too but some of the functionality is lost without mxp. I'm fairly certain Khalin wouldn't mind if you looked at the mxp implementation in DoT for comparison (and possibly inspiration with some credit mentions perhaps) to see where you might have something misflagged for nonmxp users.
Hell, you may even decide you like DoT enough to just use it instead of trying to patch mxp into another codebase.
Actually, it's a little odd, because I use Nick's MXP code basically straight out of the box, and I have no trouble at all with MXP disabled. All the "tags-which-aren't-tags" (such as <held>) properly come out as "<held>" and aren't eaten up. So I'd say that this is server-side as well, and doesn't have to do with MUSHclient.
What we're trying to say is that our implementations work just fine; I for one do use MUSHclient and when I turn off MXP it all works perfectly.
So if it's not an issue with MUSHclient - which it probably is not, given that it works for other people - it is most likely an issue with something on your server. Perhaps MXP isn't actually being fully turned off or something.
Perhaps, what you can try doing is making sure MXP is off client-side as well. It would surprise me if that were the issue, but, well, you never know. When you turn MXP off, you might not actually be sending the "switch off" commands (if those exist?) I believe Nick's code is meant to handle auto-detection, not on-the-fly switching between MXP-on and MXP-off.
There is no sub negotiation to turn it off once you've turned it on.
You can turn it off server side, like you've been doing, but that causes your server to stop sending the HTML equivalents of symbols, while the client itself is still parsing HTML.
This is why your text vanishes when enclosed in anchors.
You may have to add to your MUD a means of identifying players who were using MXP, but no longer are, so the MUD knows not to continuing converting characters, but cease sending actual MXP.
Indeed. After dissecting DoT it appears that's what they've done. It looks like they detect whether or not MXP is in use by the client, then use the players settings to determine whether or not they actually make use of the MXP or not.
Well, the only problem would be that its not exactly spec. and if i send it out to other clients, who knows what might happen.
I do like the idea of telling the client exactly what is happening.
But wouldn't it be just some trivial lines in convert_mxp_tags and count_mxp_tags?
my guess would be here abouts:
default:
if (bMXP)
{
switch (c)
{
case '<': /* < becomes < */
case '>': /* > becomes > */
count += 3;
break;
case '&':
count += 4; /* & becomes & *
break;
case '"': /* " becomes " */
count += 5;
break;
} /* end of inner switch */
} /* end of MXP enabled */
If MXP is detected escape.
For the rest, its if its detected and the player flag is turned on?
I must be missing something about this code though, because when i tried to simply do that, i had my output buffer corrupted (probably due to count being off, or the memcpy not being done in the right position, or something.
Any hints as to what todo to deal with this in the mean time?
I believe its a good idea to add it.
Though not specifically included in the spec, there is precedent for it.
Sub-negotiation is not a detail handled by the specification anyhow, it merely suggests using the guidelines for MCP, and MCP *can* be turned off after being activated, if the client is written to support it.
http://www.zuggsoft.com/zmud/mxp.htm
Bottom portion under "Implementation Details"
"If you want to get more sophisticated, you can use the Telnet Option negotiation to determine if the client supports MXP"
http://www.zuggsoft.com/zmud/mcp.htm
"Compression can only be terminated by the server - a normal end to the compression stream is assumed to mean "revert to uncompressed mode". It may be desirable for the server to automatically terminate compression when an IAC DONT COMPRESS sequence is received from the client."
So again, based on precedent, and apparent interest, I would encourage it to be added. Those who use Zuggs stuff can deal with him on the subject of him supporting it, right now people are trying this anyway with neither client supporting it fully. One might as well.
I have added the telnet negotiation thing as suggestion #503.
I'm not sure about the idea of doing it at the server end. Either they can turn off MXP or they can't. If they can then the server should stop sending it and the client should stop expecting it. As no known client supports turning it off at the client end, it seems a bit problematic to implement it at the server end.
In the case of MUSHclient, disconnecting should do it, so you could accompany the "mxp -off" command with a suggestion to the player that they immediately disconnect and reconnect.
Or, say that will take effect next time they connect, and keep sending MXP for now.
Ages later I stumbled on the answer while looking for something else.
else if (!str_cmp(argument, "on"))
{
send_to_char("Initalizing MXP.\n\r", ch);
SET_BIT(ch->act,PLR_MXP);
send_mxp_stylesheet( ch->desc);
}
else if (!str_cmp(argument, "off"))
{
send_to_char("Terminating MXP.\n\r", ch);
REMOVE_BIT(ch->act,PLR_MXP);
ch->desc->mxp = FALSE;
}
Right after:
send_to_char("Terminating MXP.\n\r", ch);
Should be:
send_to_char( MXPTAG("MXP OFF"), ch);
And that tells the client to stop processing what the server sends as MXP. I thought I saw that in there somewhere, just wasn't a telnet negotiation, was an MXP tag.