[Home] [Downloads] [Search] [Help/forum]


Register forum user name Search FAQ

Gammon Forum

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  General
. . -> [Subject]  MXP Spec clarification

MXP Spec clarification

It is now over 60 days since the last post. This thread is closed.     [Refresh] Refresh page


Pages: 1  2  3 

Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #30 on Sat 15 Sep 2007 (UTC)

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.
[Go to top] top

Posted by Shaun Biggs   USA  (644 posts)  [Biography] bio
Date Reply #31 on Sat 15 Sep 2007 03:05 AM (UTC)
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.
[Go to top] top

Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #32 on Sun 16 Sep 2007 08:09 PM (UTC)
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.
[Go to top] 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.


83,542 views.

This is page 3, subject is 3 pages long:  [Previous page]  1  2  3 

It is now over 60 days since the last post. This thread is closed.     [Refresh] Refresh page

Go to topic:           Search the forum


[Go to top] top

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

[Home]


Written by Nick Gammon - 5K   profile for Nick Gammon on Stack Exchange, a network of free, community-driven Q&A sites   Marriage equality

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( https://gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Hosted at HostDash]