Zugg Software :: View topic

Posted: Wed Aug 08, 2007 11:04 pm

Is there a way to view raw XML sent by the MUD?

Supposedly that is how GemStoneIV sends the data for its point and click interface FE.

Which i plan on converting to MXP to properly emulate.

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

Yes, just set your GSL Client type to stormfront (it's listed in Simutronics preferences). Save/apply preferences, close down the character, reopen the character in offline mode, start up logging, then reconnect to the mud. Everything in the mess you now see in the main game window is exactly what's being sent by Simutronics, because CMud doesn't talk to Simutronics to do the MXP prepwork and thus has absolutely no idea what these tags mean (ergo, it's plain text that's left up on the screen for the user to see).

Posted: Thu Aug 09, 2007 5:05 am

I have no StormFront option though i do have a browser_fe, however after closing the session and reopening it, there was no added text show in the log file.

Posted: Thu Aug 09, 2007 5:02 pm

You should be able to enter stormfront into the GSL client field even if it's not in the drop-down menu.

Posted: Thu Aug 09, 2007 9:39 pm

Aha, that did it, now to make sense of the tags they are using.

Oh, and doing this seems to break all GSL triggers. Dunno if that was intentional.

Posted: Thu Aug 09, 2007 11:21 pm

Another thing.

Apparantly (according to the staff at simultronics) there are still some XML codes that i am not receiving.

The person I talked to was not entirely sure if it was, in fact, being sent.

Some commands (exp, info, cman info) that had output before i switched the GSL type to stormfront are now not giving me any output either, definately something fishy here...

More details as I get them.

Posted: Fri Aug 10, 2007 1:16 am

Keep in mind that CMUD doesn't currently handle "null" tags that look like <TAG/>. I'm expecting to add this to v2.0 if I have time.

Posted: Fri Aug 10, 2007 3:09 am

I had asked on the GemStone boardss as well about the first such tag i noticed i wasnt getting, and here is the reply i got:

Posted: Fri Aug 10, 2007 3:19 am

Just as an aside, I wish you the best of luck with this, shalimar. Many brave men have fallen before the spam demon that is the Stormfront XML stream.

I remember someone (I believe it was charneus) was tackling this same problem and having lots of difficulty. His approach was different - he'd written his own proxy program that parsed out the XML and printed out MXP for zMUD/CMUD to parse, but the sheer volume of information made it difficult. I'd love to hear if you have any more success.

Posted: Fri Aug 10, 2007 3:22 am

Another reply i got in the other thread:

Posted: Fri Aug 10, 2007 8:57 am

Since CMUD doesn't handle null tags, as Zugg mentioned earlier, you wouldn't be getting the progressBar XML. And it's possible, since dialogData now looks like an empty tag (other than it's id information) with out the progressBar tag, that it may be getting stripped as well, or at least not displayed since it provides no information.

On the upside 2.0 will be out pretty soon and Uncle Zugg may include support for it. (I'm guessing it's fairly likely since he's done all that XML work for the settings editor. Then again, they could be completely separate components.)

Posted: Fri Aug 10, 2007 9:15 am

Yea, I was hoping so too, what with all the XML inport/export stuff, it does seem a prime time to add more XML support.

Though i didn't realize those were null tags since they do have IDs.

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

Null Tags <Text here />

Normal Tags <Text here>Stuff between the tag</Text>

I'm DEFINITELY lacking on the subject but it seams to me that Normal tags look like HTML < ></ > and require an open and closing while a null does not < />. So a null doesn't require a close. Kinda like the BR in HTML did not used to have to have a close <BR> but now needs one <BR/> tells browsers that the BR is a null tag and not to look for a closing tag. Or at least for information between it and a closing tag.

Someone Please shoot me down if I am incorrect as it is morning and I didn't look up a single bit of this information.

Posted: Fri Aug 10, 2007 6:11 pm

Apprentice Joined: 12 Jul 2004 Posts: 190 Location: Canada

By strict XML definition, Arminas is correct, null tags are <tag attribute="value" ... /> while non-null tags are <tag attr="value">contents</tag>.

However, the only true expert on what CMud sees as a null or non-null tag would be Zugg... so the interpretation it uses may be different.

By the above definition:
<popBold />
<pushBold />
<resource ... />
<style ... />
are all "null" tags, while...

<compass>...</compass>
<prompt ...>...</prompt>
are non-null tags.

From your above post, I'm not sure what is or isn't displaying, but it's possible that because it's contained WITHIN a non-null XML, the null <dir /> tag is displaying.

Posted: Fri Aug 10, 2007 8:55 pm

The <resource> tag is actually closed 4 lines down from it opening, which, if your right about being contained, would explain why the <style> tags (which seem to enclose relevant mapper info) are being displayed.

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

Posted: Mon Aug 13, 2007 11:31 pm

From the Simultronics forum.

Posted: Mon Aug 13, 2007 11:38 pm

If it means a literal line "L <Character ID> STORM" it shouldn't be too hard to #send it. If they mean telnet codes, it should be possible to find out what they are, either on their forums or with some packet sniffing. Once you know which codes to send, you can use the new #sendraw in version 2.

Posted: Mon Aug 13, 2007 11:50 pm

I think that line is supposed to be part of the URL or whatever line of text it is that is sent to the mud during the connection handshake to simultronics.

Posted: Tue Aug 14, 2007 12:13 am

Posted: Tue Aug 14, 2007 1:40 am

CMUD already implemented the SGE protocol for Simutronics. See the Simutronics page in the help file for how to set up your hostname and character name for it. The "L" option in CMUD sends whatever text is in the GSL Client box in the GSL options. So just put "STORM" in this field instead of fe_browser and then it should send that to the game.

You should *not* attempt to implement SGE yourself using #SEND commands. It's very difficult, and not necessary with the built-in support for it anyway.

But let me know if this should really be "STORM" rather than "stormfront" as I've got "stormfront" added to the list of options in 2.0 and need to know if this needs to be changed to just "storm".

Posted: Tue Aug 14, 2007 1:43 am

I have already tried using "Storm" as the GSL CLient and it would not even connect.

Posted: Tue Aug 14, 2007 2:04 am

Ahh, OK, I took a look at the CMUD source code and I was wrong. Instead of "L <characterid> STORM" it is sending "L <characterid> PLAY".

Before I change this, I'd like to get some additional confirmation on this. The documentation I have from Simutronics doesn't say anything about the StormFront protocol, but the "L" command isn't where they normally handshake the type of client being used, and the Wiki entry linked above is far from "official".

If someone can get a better confirmation of the "L" command, then I might be able to make a change to this. If this is really how they implemented it, then it won't be possible to use CMUD 1.34 to connect as a stormfront client.

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

Unless I'm still sitting on some really funky auto-update bugginess issues, Stormfront mode is working perfectly in CMud 1.34 with regards to Dragonrealms. Literally no difference between what happens now and what happens in ZMud.