Zugg Software :: View topic

Posted: Sat Aug 15, 2009 12:39 am

Alright... so I've been looking over this once more... trying to get the handshaking going down right..
But it seems it just doesn't respond to normal MXP triggers as i had hoped.

Posted: Tue Aug 18, 2009 4:51 pm

I have eyeballed and figured out some of the tags:

pushStream = reroutes text to the window in its id (effectively #C+ id) [seems to always miss the first value]
popStream = reroutes text back to the main window (#C-)
clearStream = clear the given window id (#CLR id)
a = any manipulative object or mob, not sure how i can use the number field given
dialogData = seems to be a button/panel
progressBar = gauges
component = arrays for room contents

Posted: Tue Aug 18, 2009 5:07 pm

I'll copy a response from another post here in case someone else reads this and tries to figure it out:
-----
You'll need to set up a bunch of <!ELEMENT> MXP statements to define the XML tags that you want to recognize from the MUD. Remember that the MUD isn't actually supporting MXP...they are just sending raw XML data. So usually in a onLoad or onConnect event, you need to use the #MXP command to send <!ELEMENT> commands to CMUD to define each tag. See the MXP Spec for documentation on the <!ELEMENT> tag.

Posted: Wed Aug 19, 2009 10:29 am

Okay... I'm not exactly sure how to define them, I have tried entering

Posted: Wed Aug 19, 2009 11:20 am

The following to bits of code seem to give me a crash after the tag appears when used together:

Posted: Wed Aug 19, 2009 8:58 pm

I'm not getting any crashes, so post your crash dump for me to see it.

I'll look into this more next week when I can spend time looking at the MXP code. Your example of

#MXP <!EL prompt ''>

should be fine. But technically you are supposed to also give the allowed attribute list, like this:

#MXP <!EL prompt att="time">

But I can't get your trigger to fire here either, so I'm not sure what is wrong. I'll have to get into the code to find out...it's been a *long* time since I played with this, so maybe something has gotten broken. Sorry the !ELEMENT syntax is a bit odd...it's not something we invented ourselves for MXP, it's something that comes from XML DTD definition files.

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

I believe you need to include the OPEN keyword on account that MXP is put into some default secure mode that essentially prevents user tags from working. Since Simutronics isn't communicating with CMud about MXP, all the tags have to be specified as okay for the user to use.

Another thing I noticed (but this was way back in ZMud) was that the element definitions weren't resulting in recognizable tags in the data stream until I included TAG info.

Posted: Thu Aug 20, 2009 1:32 am

So would i be correct to assume that multiple attributes would be:

#MXP <!EL a att="exist|coord|noun"> //coord is not always used

Also, this command seems not to work, and i see now that is because this is already a system element.
Is there a way to augment the system version to catch these as well?

Posted: Thu Aug 20, 2009 4:15 pm

You cannot redefine system elements. Elements such as A for tags should automatically be handled if you just enable MXP secure mode (you can use the #PUEBLO command to enable MXP-secure all-the-time mode). No MUD should be stupid enough to try and use a well-known HTML tag such as A for a different purpose.

The OPEN tag shouldn't be needed if you use the command:

#MXP 1 <prompt time="123"></prompt>

to send the MXP command. The argument 1 tells the #MXP command to send it to the screen in secure mode. But this doesn't work, which is why I think there is a bug somewhere. The MXP trigger still doesn't fire (although the MXP command is no longer echoed to the screen).

As far as specifying multiple attributes, see the <!ATTLIST> MXP command for the syntax on this. You use spaces between the attributes, not | characters. Remember that these commands come from XML, and the use of | for lists is more of a zScript syntax and not an XML syntax.

Posted: Fri Aug 21, 2009 9:35 am

I don't suppose you could add an option to ignore/override system elements like you can with other predefined aliases and keys?
Or perhaps you could augment it at the build level to include this abnormality?

I will try and talk to the admins, but I doubt Simu will be willing to budge.
I would hate to have to give this project up just because of the 'a' tag.

Posted: Fri Aug 21, 2009 3:49 pm

I doubt they will change anything. In fact, they probably did it to make it harder for MXP clients to emulate to force you into using their client. They stopped caring about clients such as CMUD and zMUD several years ago when certain people left. To change it would require that they change their own client and do it in a backwards compatible way with their users. Chance of that happening is probably zero.

MXP elements are not saved as "settings" in CMUD, so there is no mechanism for doing overrides like with aliases and keys. The MXP/HTML parsing is done at a very low level and allowing override of the A tag is not a simple fix. I'll add this to the to-do list, but you probably won't see it happening for a long time. I just can't put that much work into a MUD-specific fix when that MUD isn't even helping to support Zuggsoft anymore.

Posted: Fri Aug 21, 2009 6:50 pm

Understood. Why did they stop anyhow?
I've heard you mention your trail account got revoked, buts that about it.

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

The stated reason from Simu was that there was not enough of an advertisement improvement to justify the cost. They've used this reason on pretty much all the mudlist sites like mudconnector.