Must have started around when he stopped beating his protocols.
But I have to say, I was rather amused to note that the exact same posters who are criticising "old" protocols on this thread are also slamming and mocking UDP on that thread :P
Is there something in the water these days? People have been remarkably prone to misreading posts or entire threads. I don't believe that anybody was, at least in this reality that we actually operate in, "slamming and mocking" UDP.
But I have to say, I was rather amused to note that the exact same posters who are unable to read and reply to what people actually say are also insulting and mocking posters on that thread :P
I'm right, because I said I am, neiner neiner, so there, I win. (Is that how this game works? +1 for victory? I guess I need to insult ya'all, too, and throw out that you're responsible for the downfall of all things holy in MUD-land. That will make my position impregnable!)
I don't really understand why you say this. If a server happens to be talking to a client over telnet, it doesn't have to format/track anything beyond what it actually wants to send. It can send all of its data using OOB protocols and nothing over the main channel. This would require the same amount of work (gather data, package data, send data) as using AwesomeNewProtocol. It's still telnet, technically, although clearly it will be useless to a plain old telnet client.
When you say "telnet" here, do you really mean something that sends data such that a plain telnet client will be able to render it?
I mean "a MUD which supports TELNET in the traditional and common sense." If you support TELNET, you expect people to be connecting with *ANY* client that supports TELNET. If that's the case, the server MUST maintain anything which it may need to resend for whatever reason, and it must make all data available via the primary non-OOB connection. If you make assumptions, you are in the land of custom clients, and if that's the case, there are much simpler ways to manage your data stream.
The server doesn't need to format anything, the plugin does that. The server still needs to track data, but that would be exactly the same for a custom client. Having actually spent several months developing a custom plugin, I'm just not seeing where this extra effort comes in.
So, you don't allow people to play with anything but your plugin? How is that not a custom client? What's the point of bothering with TELNET if people can't use an arbitrary TELNET client? Or do you mean people connecting with a plain client don't get any formatting and have to suffer with raw text and no line breaks?
Interesting stuff. But I have to say, I was rather amused to note that the exact same posters who are criticising "old" protocols on this thread are also slamming and mocking UDP on that thread :P
Yeah. Well I just ignore the muffers.
BTW that post was shortly before mudstandards.org. After I found out what Nick Gammon was doing with Mushclient, I started exploring the whole idea of client/server event-based messaging. This is sort of at angles to what MDSP is.
I should mention that I've got an integrated client that does reliable messaging, so I've also integrated what I call the mud's main teletype window and data mapper into it's own client. It can transfer files in the background, currently just one file at a time. It can also do peer to peer encrypted chat, which I've talked about elsewhere as a player-driven replacement for this IMC2 thingy.
And I would be remiss if I didn't mention it was faster.
I mean "a MUD which supports TELNET in the traditional and common sense." If you support TELNET, you expect people to be connecting with *ANY* client that supports TELNET.
OK, thanks for clarifying. Your earlier statement makes sense to me with this in mind.
So, you don't allow people to play with anything but your plugin? How is that not a custom client?
He still allows standard telnet; they just don't get the new features. I'm surprised that this isn't considered a competitive advantage – after all, readily available information is often power – but there you go.
What's the point of bothering with TELNET if people can't use an arbitrary TELNET client?
I think he means telnet in the strictly-speaking-uses-telnet-protocol sense. When he talks about using telnet even for a fully custom client, he just means the protocol. He would still be layering other stuff on top of it (like MDSP or whatever) so I don't see the point of using telnet under that layer if the real information is all in the data protocol (might as well just use TCP or UDP or whatever) but there you have it.