Well those are just MSDP variables, you can define whatever you want for those - you just add or remove them from the table. When adding the snippet to muds that lack certain variables, I usually just comment them out in the update function (described in the installation instructions) and leave it for other people to decide what they want to use instead.

I thought you were talking about modifying the actual functionality of the snippet.

Heck no. I'm just looking at commenting ones out. Why mess with goodness otherwise?

Considering I do not intend to send data that will not/can not be rendered as text for people who cannot use it, it is good enough.

And my point is plugin it in/out takes less than an hour in a ROM code even when not knowing at all what you are doing, add 256 color support for free, so why not.
It is not like plugin it off takes less than 5minutes.
This plugin really makes MSDP free, it does not force you to make anything of it anyway. The users can ask me for any variable he can have with a '0 lag command', like exits stats score his eq etc. Does not mean I have to create the gui for them as well.

Sending platform dependent data is a bad idea regardless of the situation. If you want to go that route it'd probably be best to use HTML5 instead, and in the long run the lack of competition (because the server has a monopoly) will (typically) result in an inferior product compared to servers that allow competition.


Seconded. It's probably a good idea to provide a document that lists all the unusual variables, and a description of the data they hold. All in all the amount of work involved is minimal, though given the small size of the MUD community it is likely to take several years for a new generation of GUIs to fully evolve.

Then MSDP is just as irrelevant for you. It's not like getting an MSDP state dump is particularly useful to a human. It's not entirely clear to me why you're talking about human reading as an issue here considering that MSDP (and any other protocol of the sort) is not intended for direct human consumption.

At the very least, MSDP is no more readable than a standard format like JSON, and is ill-suited for structured data, unlike JSON.


Who said anything about platform dependent data? Who are you talking to?

Let me rephrase:hp mana etc are ,human readable and directly usable on a screen.
a link consisting on two room vnum,or a path between the consisting in id on the server, not so much.
I use MSDP only as a way for the player to have data he can look at without typing the associated command. I use MSDP as a 'super prompt'.

That has nothing to do with MSDP. The protocol itself is for delivering data. It's agnostic as to what is done with the data. So the same thing can be said for any number of data transport or serialization libraries. What's your point?

My point was exactly that: it is agnostic, so you can do pretty much what you want with it (performance issue aside)
Does not mean you have to. Comes for free, allows many stuff without having to pour much work in it, and is perfectly transparent to the user who does/can not use it.

Correction: It would come for free, if the protocol itself didn't change in ways that it make it NOT backwards compatible with previous versions. I would, instead, say it comes with a randomly recurring maintenance cost.

Also, the transparency directly depends on the client correctly handling the TELNET protocol, and we all know that isn't the case for everyone.

Rarva, I have no idea what you're trying to say with respect to the points I made.

I said that you might not want to use MSDP if you're interested in sending structured data. What do your comments have to do with that?

Why isn't MSDP good for structured data?

Because the conversation is not 'I want to use structured data and I already use 'whatever', is MSDP a good solution ?' but 'I do not send anything at all for now, does MSDP bring anything.'
Having MSDP is better than nothing at all, no ?

It has no provisions for nested data structures, the best you can hope for is an array.


No.

If you aren't using any fasteners at all, and someone gives you a hammer, when you decide you need them, you might be tempted to buy nails instead of screws, just because you don't want to bother getting a screwdriver.

The best tool for a job is not always the best tool especially when you do not have it anyway.

Nesting support was added a year ago, and array support half a year ago. No further changes are planned.

The question I was replying to was, "why shouldn't I use MSDP" not "what does MSDP do". I dunno what question you're talking about, but if you're replying to me, please keep in mind what I was replying to.


For the curious as to why I made my statement, MSDP nesting and arrays are rather fragile. They rely on special bytecodes to indicate when to open and close structures, but there is no provision for escaping data. Therefore, it is quite unclear how you would send binary data (for example) using MSDP because you could end up sending MSDP bytecodes which will result in completely incorrect interpretation of the data.

There's really no reason at all to be creating yet another data format. This should be obvious by considering how Scandum started very simple, too simple in fact, and realized he had to jury-rig additional features like nesting and arrays into his format. If this ever gets serious, you will see that he will have to start adding even more features, like escaping, until eventually he will have reengineered a whole data format. It's a waste of time, it's confusing, it creates standard hell, and it's short-sighted.

Do people commonly send binary data over Telnet? Is this even an issue?

Well, if you're trying to send rich data to a client for rendering, then yes, it is quite likely that you would want to send binary data, such as sound, images, compressed data for maps, etc.

The point isn't that MSDP is terrible for everything (although there are certainly issues using a standard that changes on one person's whim). The point is that if you have certain needs, it simply doesn't work well. The question was "why shouldn't I" – it was not "why shouldn't anybody ever". So, the answer is "if you have these needs, it's not great". I did not say "no matter what your needs, don't use it".

He does not have any need actually, so the question is still why should he not…only reason would be it is hard to remove (it is not) or it is not transparent enough( main concern) or it really takes too much time for what its worth (adding support for 256 colors come for free with the plugin as well) considerig it really takes little more than 15mins to plugin , and no more than an hour to add your main variables in it, the main reason would be: it does not what i wish to do…
I think that if you had to start sending binairies for a text mud, I would consider to drop telnet alltogther, or just make it the 'fallback soon to be dropped option once everyone /enough people migrated to the client that use the binaries'

Good point, and this reminds me that some muds now auto-update their client plugin resources – but I can't remember if they use MSDP for this or even which muds. Anyone know what I'm trying to remember here?