Gammon Software Solutions forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

Entire forum
MUSHclient
General
MXP Spec clarification

Home \| Users \| Search \| FAQ
Username:	Register forum user name
Password:	Forgotten password?

(New message)

Subject:	MXP Spec clarification
Name:	Your forum user name. Register forum user name
Password:	Your forum password. Forgotten password?
Message:	[quote=Shadowfyr] Sigh. I am thinking in broad terms of what someone "may" do in the future. Sure, you are correct in that, in general, if all you are doing is sending a list in some format that will show it one way in the GUI and one way in the text system, its not a big deal. All I am saying is, you might want to have a means to negotiate clearer about what is and isn't allowed, so that, to use your inventory example, you don't get something as bad as: [code]<shop> <item level=1 num=inf price=20>an Aylorian Dirk</item> <item level=1 num=inf price=20>an Aylorian Sword</item> <item level=1 num=inf price=20>an Aylorian Axe</item> <item level=10 num=1 price=10>a scimitar</item> </shop> vs. <shop> <item level=1 num=inf price=20>an Aylorian Dirk image=adirk.jpg 3d=adirk.obj effects=flames.efx texture=aylorian_metal.inc</item> <item level=1 num=inf price=20>an Aylorian Sword image=asword.jpg 3d=asword.obj effects=flames.efx texture=aylorian_metal.inc</item> <item level=1 num=inf price=20>an Aylorian Axe image=aaxe.jpg 3d=aaxe.obj effects=flames.efx texture=aylorian_metal.inc</item> <item level=10 num=1 price=10>a scimitar image=scimitar 3d=scimitar texture=iron.inc</item> </shop>[/code] Which is nearly doubling the data involved, when half the stuff in the list is "not" essential at all to display in text. Mind you, no mud is currently likely to do that. But something coming from EQ2 might ask, "Well, why if you have a GUI can't you at least show some pictures of what the thing is, and provide something sort of like the "dressing room", where you can look at it in 3D? Hell, I would love to see that myself, even if I had never played EQ2. To me, it adds something to at least get a sense of how big a "huge sword" really is, just how spiky the spikes on the mace are, etc. Sure, I can imagine it, but which is seriously more stunning, the battle scene with Sauron in the movie, or the convoluted prose of Tolkien? Some people may want to former, even if the rest of the game is text. And, if you start adding that sort of data into the stream, you may want to make sure there is "at least" some concept in the protocol which allows a client to negotiate "down" to a level that won't be sending all of it, instead of relying on the server coder to implement some addon hack, which only works with their server, and which ever client they cobbled together to do it. And sure, they could set it up to simply let the person enable/disable some content on the server end, for that character, but that only works where someone bothers to do it, in which case, you are right back to getting 2-3 times the data, and throwing 1/2-2/3 (or more) of it out, instead of just requesting, "Don't send me what I can't use.", in the first place. Have thing that would require a GUI capacity, or a plugin for graphical elements, place those items in a category of "graphical features", which you can negotiate out of. At the very least, make sure that there is a clear concept of how those additional elements "must" be included in any protocol, and negotiated, so if someone does come along with something of the sort, you can extend to protocol in a way that the client can deal with effectively, not just figuratively scratch its head at and throw out. If it can't use it, then have the protocol establish it, and the protocol on the server end figure out what to send and what to not bother with, not the client, which is a bit like closing the barn door after the herd has already stampeded over you lawn. See what I am saying? We don't need to implement the features to do any of the stuff I put in my example, but we should have the "server" end firmly in the position of being responsible for determining if it should cram all those things into it in the first place, or if, perhaps, the guy with GenericClient++ shouldn't have all the extra stuff thrown at him to start with. Color markup, etc. would be handled in a style sheet system instead, so you could "override" the styles for inventory, or shops, etc., to make it fit your aesthetic, or you could use what the "mud" wants you to see instead. That is fine. Some data though, is not needed, wanted, or useful, to a text client, so it makes no sense to send it anyway, instead of negotiating with the server using something like, "Can do 3D, can't do 3D, can do images, can't do images, can do tables, will do tables, etc." That gets you your example, and tells the server, don't send me the other stuff. [/quote] Message to be posted (in English, please).
Forum codes:	Check this if your message uses 'forum codes' or templates (auto-detected for new posts). Forum codes Templates

Save this message ...

Subject review (reverse sequence)

Pages: 1 2 3

Posted by

Shadowfyr USA (1,774 posts)

bio

Date

Sun 16 Sep 2007 08:09 PM (UTC) [ quote ]

Message

Yeah, it shifted to "Maybe we should replace it, rather than try to fix it?", some time ago. I will still say you are not getting the issue. I talked a while back about a system for 3D that would do limited scenes, which could be changed dynamically as needed. Got sort of the same argument there, "Well, if all you want is sun position, then just code that into the stuff you download for the plugin/client, then just send the position." It missed the point that this was an "example" of what someone might do. It doesn't matter if I hard code something that is supposed to help make it look like its snowing, if the next week everyone on the mud agrees we need to have a volcano go off, and now we need "ash". Similar code? Sure. Same code? No, so it "must" update more dynamically. Same with just bugfixes. Wrong texture, etc.? Patch the text sent. But you still "send" the text.

Point being. The example given in my last post is the "minimum" I might imagine someone doing, and it ignores one key feature I think most 3D systems currently lack: The ability to update the content with the same ease as you update the "code" for a room on a mud. You are assuming static information, which one simple name, linked to a pre-downloaded definition file will handle. Ok, in that case you are 100% correct, its not a huge issue. But that **may not** be what is actually being sent.

Mind you, it may be possible, with some allowances for background tasks and such, to find ways around that still. Like updating the object via a different port. Or even, as I considered, using a torrent like system, which could slowly patch your files in the background, and where the tracker could "inform" the client that file X in directory Y has been patched, as needed, and update critical files without having to force the client to download the whole file at once. Decent bandwidth limiting could even reduce lag for dialup to a point where the game was still playable, while patching, though it would lag some still. It might not be a huge issue if the torrent system was "aware" of user commands and actions and could delay its own actions for "idle" periods, like when the player goes AFK, etc. You can't do that with an external patcher or torrent client.

The benefit is obvious to the server owner. No huge bandwidth hit to them every time someone is downloading their plugins/files.

But yeah, this has strayed from the original post, but then, I don't think we are likely to draw any more conclusions from the original than we already did: 1. Its broken. 2. It probably won't be fixed by Zugg and 3. We are unlikely to see it fixed any time soon.

main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}

top

Posted by Shaun Biggs USA (644 posts) bio

Date Sat 15 Sep 2007 03:05 AM (UTC) [ quote ]

Message

I completely see what you are saying. This is why I can say with absolute certainty that you are flat out missing the point of making protocols concise.

What you turned my example into has many completely superfluous bits of data in it, and can still be used by text clients which are creative about things. All you would need is some type of basic flagging for any of the items you mentioned.

<item level=1 num=inf price=20 obj=idnumber options="flame glow">an Aylorian Dirk</item>

If you have to download the images for 2D and 3D objects, might as well have a whole object pack that will match the images and basic affects on the items, vaguely like having CSS for web pages. It can notify the client on how to colour the text, what font it should be displayed as, what images to use, etc. Adding extra options for changed flags should be no problem at all, and should be easily modifiable by whoever is running the server. Possibly even easily modifiable by people who just want to make their own alternate graphics packs. Text based clients can use the options at least to display what extra flags are on said item, if it is wanted. That being done, the only wasted bit of code would be the object id... a far cry from the immense amount of waste that you have claimed would occur. Actually, with this example, noting the level and price may wind up being redundant for certain items if they are at the defauts, cutting back even more on the amount of data wasted, possibly even saving some bandwidth occasionally.

Also, supporting the tags should be somehow requested by the client if the mu* intends on being able to be used by even plain old telnet. Anything after that can be dealt with on a case by case basis. If a client choses not to support certain tags, then it can ignore them without having the server waste processing time trying to figure out if each individual player can deal with the tag. The server should not be burdened with trying to figure out what the client can do.

This thread has moved far, far off of any clarification of MXP though, so I'm going to drop the matter after this post.

It is much easier to fight for one's ideals than to live up to them.

top

Posted by Shadowfyr USA (1,774 posts) bio

Date

Sat 15 Sep 2007 (UTC) [ quote ]

Amended on Sat 15 Sep 2007 12:01 AM (UTC) by Shadowfyr

Message

Sigh. I am thinking in broad terms of what someone "may" do in the future. Sure, you are correct in that, in general, if all you are doing is sending a list in some format that will show it one way in the GUI and one way in the text system, its not a big deal. All I am saying is, you might want to have a means to negotiate clearer about what is and isn't allowed, so that, to use your inventory example, you don't get something as bad as:

<shop>
<item level=1 num=inf price=20>an Aylorian Dirk</item>
<item level=1 num=inf price=20>an Aylorian Sword</item>
<item level=1 num=inf price=20>an Aylorian Axe</item>
<item level=10 num=1 price=10>a scimitar</item>
</shop>

vs.

<shop>
<item level=1 num=inf price=20>an Aylorian Dirk image=adirk.jpg 3d=adirk.obj
  effects=flames.efx texture=aylorian_metal.inc</item>
<item level=1 num=inf price=20>an Aylorian Sword image=asword.jpg 3d=asword.obj
  effects=flames.efx texture=aylorian_metal.inc</item>
<item level=1 num=inf price=20>an Aylorian Axe image=aaxe.jpg 3d=aaxe.obj
  effects=flames.efx texture=aylorian_metal.inc</item>
<item level=10 num=1 price=10>a scimitar image=scimitar 3d=scimitar
  texture=iron.inc</item>
</shop>

Which is nearly doubling the data involved, when half the stuff in the list is "not" essential at all to display in text. Mind you, no mud is *currently* likely to do that. But something coming from EQ2 might ask, "Well, why if you have a GUI can't you at least show some pictures of what the thing is, and provide something sort of like the "dressing room", where you can look at it in 3D? Hell, I would love to see that myself, even if I had **never** played EQ2. To me, it adds something to at least get a sense of how big a "huge sword" really is, just how spiky the spikes on the mace are, etc. Sure, I can imagine it, but which is seriously more stunning, the battle scene with Sauron in the movie, or the convoluted prose of Tolkien? Some people may want to former, even if the rest of the game is text. And, if you start adding that sort of data into the stream, you may want to make sure there is "at least" some concept in the protocol which allows a client to negotiate "down" to a level that won't be sending all of it, instead of relying on the server coder to implement some addon hack, which only works with their server, and which ever client they cobbled together to do it.

And sure, they could set it up to simply let the person enable/disable some content on the server end, for that character, but that only works where someone bothers to do it, in which case, you are right back to getting 2-3 times the data, and throwing 1/2-2/3 (or more) of it out, instead of just requesting, "Don't send me what I can't use.", in the first place. Have thing that would require a GUI capacity, or a plugin for graphical elements, place those items in a category of "graphical features", which you can negotiate out of.

At the very least, make sure that there is a clear concept of how those additional elements "must" be included in any protocol, and negotiated, so if someone does come along with something of the sort, you can extend to protocol in a way that the client can deal with effectively, not just figuratively scratch its head at and throw out. If it can't use it, then have the protocol establish it, and the protocol on the server end figure out what to send and what to not bother with, not the client, which is a bit like closing the barn door after the herd has already stampeded over you lawn.

See what I am saying?

We don't need to implement the features to do any of the stuff I put in my example, but we should have the "server" end firmly in the position of being responsible for determining if it should cram all those things into it in the first place, or if, perhaps, the guy with GenericClient++ shouldn't have all the extra stuff thrown at him to start with. Color markup, etc. would be handled in a style sheet system instead, so you could "override" the styles for inventory, or shops, etc., to make it fit your aesthetic, or you could use what the "mud" wants you to see instead. That is fine. Some data though, is not needed, wanted, or useful, to a text client, so it makes no sense to send it anyway, instead of negotiating with the server using something like, "Can do 3D, can't do 3D, can do images, can't do images, can do tables, will do tables, etc." That gets you *your* example, and tells the server, don't send me the other stuff.

main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}

top

Posted by Shaun Biggs USA (644 posts) bio

Date

Fri 14 Sep 2007 05:25 AM (UTC) [ quote ]

Amended on Fri 14 Sep 2007 05:27 AM (UTC) by Shaun Biggs

Message

Quote:
Wrong. Sorry, but I don't agree with you at all, some people may very clearly **want** for aesthetic reasons, or due to actual need, to send color information. How else do you send that sort of thing? Send a name, then *hope* that, despite the clear requirement for some puzzle, etc., that the word/image/button is colored blue, that the client isn't replacing that with orange?

And some people may very clearly **want** for aesthetic reasons, or due to actual need, to change the colours that come from the server to whatever they choose. Either to make things stand out, making it blend in better with a pattern of text, or to remove it completely. Putting things completely in control by the server takes out a lot of options for the users. Even with a pure text client, people can do amazing things with text libraries such as ncurses.

Quote:
You **are** missing the point when I talk about bandwidth. If any part of the data being sent is like.. GUI data, which can only be used by the GUI, but someone is intentionally using the client in text only mode (or a client that only supports it), then throwing 500k across a connection, when the client can only use like 1k of it, is just stupid. You have to be able to have the server ask at some point, "Can you even use any of this information, or should I instead send you the short version?"

I certainly hope that this is severe exaggeration here. If you can only use 0.2% of the information in text mode, then go play WoW or something. Nearly anything that could be used by the client to make a gui can just as easily be displayed as text. Inventories of shops, contents of containers, items worn, channel displays, exits, etc. Most of the tags should just be describing the data being sent, not sending graphics or whatnot. Not even graphical games do that, they just send the client information on what can and cannot be seen, and let the client figure out how to display it.

Take this shop listing as an example:


Num  Level  Price    Qty  Item
---  -----  -------  ---  -----------------------------------
  1      1       20  ---  an Aylorian Dirk
  2      1       20  ---  an Aylorian Sword
  3      1       20  ---  an Aylorian Axe
  4     10       10    1  a scimitar

A text and a graphical version could both be shown by the following:


<shop>
<item level=1 num=inf price=20>an Aylorian Dirk</item>
<item level=1 num=inf price=20>an Aylorian Sword</item>
<item level=1 num=inf price=20>an Aylorian Axe</item>
<item level=10 num=1 price=10>a scimitar</item>
</shop>

Let the client sort out how to deal with it, and you don't have to worry about if the client is text based or graphics based. Graphics could be loaded up by item type field or item name to display things in inventory.

It is much easier to fight for one's ideals than to live up to them.

top

Posted by

Shadowfyr USA (1,774 posts)

bio

Date

Fri 14 Sep 2007 03:32 AM (UTC) [ quote ]

Message

Wrong. Sorry, but I don't agree with you at all, some people may very clearly **want** for aesthetic reasons, or due to actual need, to send color information. How else do you send that sort of thing? Send a name, then *hope* that, despite the clear requirement for some puzzle, etc., that the word/image/button is colored blue, that the client isn't replacing that with orange? Either you are talking about something entirely different than I am, or you are hugely missing the point of being able to send colors and/or GUI design data.

You **are** missing the point when I talk about bandwidth. If any part of the data being sent is like.. GUI data, which can only be used by the GUI, but someone is intentionally using the client in text only mode (or a client that only supports it), then throwing 500k across a connection, when the client can only use like 1k of it, is just stupid. You have to be able to have the server ask at some point, "Can you even use any of this information, or should I instead send you the short version?" It just doesn't make any sense to send stuff the client can't use, especially if the reason for that is because its designed to run on systems with very little bandwidth.

main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}

top

Posted by

David Haley USA (3,881 posts)

bio Moderator

Date

Thu 13 Sep 2007 03:52 AM (UTC) [ quote ]

Message

I think there's really a fundamental disconnect here. I am talking about a protocol that sends computer-parseable data that the client is free to interpret however they want. The point is not at all whether or not a text client would do anything interesting with the message "item 1234 added to inventory". The point is that the server is informing the client of the events that happen around the character, and the client is free to do whatever it wants to display that data. In a sense, the whole 'text vs. GUI' discussion is irrelevant, since the data being sent is the complete data set.

In other words, the 'text client' is not going to literally display the data sent by the server. The client will instead read the data, interpret the events in some meaningful way, and decide to print out the message in some text form.

Part of the point is that you would never be sending color information, because that is a decision for the client in the first place, not the server. The server shouldn't be deciding what color the client wants to see the game in. Maybe the client wants room names to be in yellow, not green... etc.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

top

Posted by

Shadowfyr USA (1,774 posts)

bio

Date

Thu 13 Sep 2007 01:26 AM (UTC) [ quote ]

Message

Umm. No, I think you are the one confusing the data with the description, to some extent. Ok, true, if you allow for something like, "Add this item to the inventory", to somehow effect the text system, then sure. Realistically, unless that is being displayed in a separate window, you don't even want the text system to handle adding/removing items from such a thing. It does make sense for a GUI though. But, yeah, I see you point, for most data. There are however situations where it might not make much sense to send the same data. If you know the client doesn't support GUI, you can do any of the following:

1. Only send the text data in your data block.
2. Send a special text block, which can't contain graphical info.
3. Send the image name/location for the item, color information, text, and what ever else is needed for it, then have the client throw out the stuff it doesn't need.

The first option could be part of the spec, based on negotiation. You do not want the third option though, since that would waste bandwidth you don't need to, in order to send information the client can't use anyway. You may be correct however in assuming that option #1, based on what is negotiated, is the best choice. I was looking more at the larger view of what data "would be" needed in both cases, rather than if the same transport method could be used in all cases.

main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}

top

Posted by

David Haley USA (3,881 posts)

bio Moderator

Date

Wed 12 Sep 2007 06:10 AM (UTC) [ quote ]

Message

Quote:
The reason you may want to have a "GUI" and a "text" system is that there are things a GUI can do that ***is not possible*** in a text system.

That's not the point if the underlying data is the same. Obviously the GUI interface can manipulate data in ways not really feasible for text (drag and drop, for instance) but the data is the same. So I don't understand why you need to split in two the data being sent if you're already in the context of a descriptive protocol.

I think that you are confusing the description of the data with the server saying what it should look like. So, if the server is sending the data, then the client has everything in hand, and everything else is how to display that data. When you say that the GUI is necessarily handicapped, you are assuming that somehow there is data that is not being sent, and that is what makes no sense to me. As a server your role is not to decide how the client is going to format the semantically rich data you are sending: your role is to send the data in some descriptive, parseable form, and let the client figure out what to do with it.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

top

Posted by

Shadowfyr USA (1,774 posts)

bio

Date

Wed 12 Sep 2007 03:18 AM (UTC) [ quote ]

Amended on Wed 12 Sep 2007 03:19 AM (UTC) by Shadowfyr

Message

The reason you may want to have a "GUI" and a "text" system is that there are things a GUI can do that ***is not possible*** in a text system. For example, you may want to have a window that shows a shop include a "buy", "sell", etc. button, or even tabs, like in EQ2, where if you go to a mender you get three tabs - Repair, Buy and Sell. Each also has a button/button(s), like "buy 1", "buy amount" and maybe "restock", as in if items stack in 100s, but you only have 48, you can "restock" the other 52, instead of entering a number or buying them one at a time. Same with sales. You have "sell" and "sell stack", and now, for items you have previously sold, you can also "buy back" for the same original value (the last 10 items or something).

Point being.. If you try to force the "text" version and GUI both conform to *one* set of definitions for what is "allowed", you invariably handicap the GUI. The only way I could see around that would be to not allow such functions to be used at all *unless* it supported either "links" or "GUI". And, that still presents a problem. How do you put links for such buttons into the text version, without it looking lame. Obviously, it not as simple as just dropping them into the same place as the GUI would have them. It a) wouldn't look right in most cases, and b) it might work better if formatted in a completely different way. Graphics and text markup are simply **not** interchangeable in that respect, without *creating* compromises that limit what the client can do, and what the developer can expect it to look like. I just don't think you can make one single markup design work in "both" modes, which means you kind of, by default, need on for the GUI that looks good, and one that looks good in the text mode. There are bound to be cases where the two designs have no analogous translation, so why force the system to try to make them analogous in the first place?

main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}

top

Posted by

David Haley USA (3,881 posts)

bio Moderator

Date

Tue 11 Sep 2007 05:55 AM (UTC) [ quote ]

Message

Quote:
Now.. One issue I can see is GUI vs. text. It may be necessary, as part of any such protocol, to define two styles for every such item. For example, <style_gui>name="inventory" blah...</style_GUI> and <style_text>name="inventory" blah...</style_text>. That way, if a client doesn't support the GUI elements at all, then trigger based systems could "still" parse the style and generate changes to the inventory list, in the text only display.

I don't understand the problem. Send the client the data with descriptive markups describing (as it were) what the data is, and let the client decide all its own whether to format it using a GUI or text or whatever.

It also solves this problem:

Quote:
And, we need to consider allowing someone to "override" what the server wants, by intercepting style sheets, markup and commands to add/delete/sort, etc. anything in them.

The whole point of style sheets, incidentally, was for the HTML to describe the data, and leave the formatting up to somebody else. That is to say, the HTML would define the structure of the data, and the CSS is applied to that data to generate a webpage. Kind of like XML and XSLT. (Except that, naturally, that's not how CSS is actually used in practice a lot of the time.)

Anyhow, if you leave such formatting up to the client, which is where it belongs in the first place, then there is no longer any need to be intercepting and overriding stuff in over-complicated ways.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

top

Posted by

Shadowfyr USA (1,774 posts)

bio

Date

Tue 11 Sep 2007 03:20 AM (UTC) [ quote ]

Message

I still think markup is useful, but what may be needed is something closer to the style sheets that they eventually added to HTML. Mind you, there are some issues with those, not the least being that they where tacked on as an after thought, to extend functions like , etc. and no two browsers **currently** support both names for "all" of those elements, or a clear and easy way to attach the styles to any of those things.

Now.. One issue I can see is GUI vs. text. It may be necessary, as part of any such protocol, to define two styles for every such item. For example, <style_gui>name="inventory" blah...</style_GUI> and <style_text>name="inventory" blah...</style_text>. That way, if a client doesn't support the GUI elements at all, then trigger based systems could "still" parse the style and generate changes to the inventory list, in the text only display. Someone could instead make a client that has no support of text mode inventories, etc. and instead only supports the GUI version. The client would still handle insertion/deletion of items to both the same way, but it only accepts/responds to changes in the style data for the method(s) it handles. Such a style sheet system could mean that, for things like inventories, you could change the color or the item in a "hands" slot to designate that it was damaged, for example. Mind you, the question them becomes "how" the color should change. Is it an overlay, the background or the outline? Do those need to be named to, or do you provide, as part of the basic GUI, some way to designate which one to do. Or, do you, as I have suggested, only fire an event for a plugin, which will handle how to display the inventory, and thus what to do if you change a color element.

The later is less flexible than having the server define "all" elements, but would require less bandwidth to "define" the interface, since you could instead just provide an interface plugin, which had all the handling in it. And, we need to consider allowing someone to "override" what the server wants, by intercepting style sheets, markup and commands to add/delete/sort, etc. anything in them. This would allow the design to remain flexible from the user standpoint, instead of locking them into the interface of the server, if they opt to do something entirely different, kind of like how EQ2 can have UI patches added, to alter the look and feel of its GUI, even though the data remains the same. And that is done by altering the markup, etc. in the XML files used to define how it should look. Though, theirs doesn't let you alter behavior, just display.

main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}

top

Posted by

David Haley USA (3,881 posts)

bio Moderator

Date

Sun 09 Sep 2007 10:02 PM (UTC) [ quote ]

Message

For what it's worth, I fully agree that the way to go is to have a protocol that lets the server describe what is happening such that the client can do what it wants with that information.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

top

Posted by Nick Gammon Australia (18,800 posts) bio Forum Administrator

Date Sun 09 Sep 2007 09:24 PM (UTC) [ quote ]

Message

My personal view is that MXP is never going to work fantastically well for the following reasons:

Despite having a telnet protocol for detecting whether or not the client supports MXP, zMUD has it turned on all the time.
Because of this, server writers assume they can get away with mixing MXP and non-MXP like;
```
This is the nn where you can get a hot drink & a pie.
```
zMUD parses this sort of stuff OK because it simply displays stuff that is not valid MXP tags as straight text.
The spec is silent about how to handle erroneous tag situations, leaving different authors to handle them in different ways.
zMUD is not being developed any more (instead, CMUD is), thus any problems in the way it implements the spec are unlikely to be fixed.
Any problems in the way zMUD implements the spec that Zugg himself wrote are dismissed as "the spec is wrong" and "I will fix the spec one day".
MXP is really being used as a style markup language (note the emphasis on specifying bold, underline, colour changes etc.) whereas what would be a great deal more useful would be to specify content markup.

I know you can make your own tags like <inventory> ... </inventory> but the stuff between the tags is still displayed.
The idea of having "open" tags was apparently designed to allow people to self-colour their own chats (etc.) however this is open to abuse. Things like:
```
Nick says, You are an <COLOR FORE=red> IDIOT! </color>
```
Who wants to be insulted in a 40-point font chosen by their adversary?

It also doesn't work in other environments, where the player may have chosen a different color scheme for their local use. For example, in the above case, if they had chosen a red background, the red word disappears against it.

I would rather have some sort of protocol where things like inventory are updated as changes are made (eg. if you add an item to your inventory, a small tag arrives saying something like:


 <addtoinventory>blue sword</addtoinventory>.

With this sort of thing, the client can update its internal inventory list, maybe play a "ping" to show you have got a new item, and maybe display a small message in a text box:


Received new item: blue sword

Similar things could be done with battle messages, changing rooms, learning skills, and so on.

- Nick Gammon

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

top

Posted by

Shaun Biggs USA (644 posts)

bio

Date

Sun 09 Sep 2007 02:24 AM (UTC) [ quote ]

Message

The problem with continually sending escape codes occurs when people are trying to demonstrate something about HTML, and you add in escape codes to note screw up people with MXP, and the people without MXP wind up seeing the escape codes in there.

In retrospect, the best thing that could have been done to begin with is to have had MXP initiated with an escape code. That way clients that do not support MXP would just throw out the escape code and show the tags as normal text, while the MXP enabled clients would parse the tags as they currently do. That, or have a tag set very different from HTML.

It is much easier to fight for one's ideals than to live up to them.

top

Posted by

Shadowfyr USA (1,774 posts)

bio

Date

Sun 09 Sep 2007 02:06 AM (UTC) [ quote ]

Message

Realistically, we need, on all sides, to take a clear stance on what the behaviors *should* be and why, then fix the spec first, then the clients second. Both are probably not working as needed to follow any reasonable specification. After all, if the spec is silent on some issues, then obviously its unlikely that any client can be said to be operating as intended in those case, and where the spec if not doing what the original client does, consideration needs to be taken as to **if** it even makes sense for the client to have worked that way in the first place.

In the one example, if you have something like, "nn of Valor", it makes no sense to *allow* that to be sent without escaping, not does it make sense to even allow chat channels to support tags, instead of auto-escaping them, and if you do allow it, then you need to be clear on the mud that they won't appear as normal text, *unless* they escape them. (Alternatively, a special symbol could be used to instead indicate that it *shouldn't* be escaped). But, we need a clear spec, not one which people can misinterpret, and not one that breaks in certain cases, like the example I gave above, when you think you are doing it right.

main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}

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.

9,721 views.

This is page 1, subject is 3 pages long: 1 2 3

Reply to this subject Start a new subject Refresh page

Go to topic: Search the forum

top

Comments to: Gammon Software support
Forum RSS feed ( http://www.gammon.com.au/rss/forum.xml )