16 May, 2011, KaVir wrote in the 1st comment:
Votes: 0
I've noticed this on a few muds now:

RCVD IAC WILL MCCP1
SENT IAC DONT MCCP1
RCVD IAC WILL MCCP2
SENT IAC DO MCCP2
RCVD IAC SB MCCP1
MCCP INITIALIZED.

Translation:

Server: Do you support MCCP1?
Client: No, I don't.
Server: Okay, what about MCCP2?
Client: Yeah, okay.
Server: Great! Activating MCCP1.
Client: *choke*

This causes BlowTorch to crash (because it doesn't support MCCP1), and causes Mudlet to freeze (because it doesn't properly handle MCCP1). TinTin seems to accept it, presumably for legacy reasons, but I can't see many new clients bothering to add MCCP1.

Does anyone know where this comes from? Is it some snippet that several muds are using, or just a common mistake?
17 May, 2011, Scandum wrote in the 2nd comment:
Votes: 0
I've seen it happen on some MUDs as well, TinTin++ accepts MCCP1 initiations purely for that reason, though it doesn't negotiate it.
17 May, 2011, Twisol wrote in the 3rd comment:
Votes: 0
That's absolutely ridiculous. The only difference (AFAIK) is the malformed IAC SE, so if you're negotiating MCCP2 you're explicitly trying to avoid broken subnegotiations.
17 May, 2011, Twisol wrote in the 4th comment:
Votes: 0
Incidentally, I just thought of something. If the actual protocol is the same, why was a new telopt needed?
17 May, 2011, KaVir wrote in the 5th comment:
Votes: 0
A new telopt was needed for backward compatibility reasons. A good example of this is Mudlet, which incorrectly implements MCCP1 without the malformed IAC SE. This means that if you send Mudlet IAC SB MCCP1 it then waits until it receives IAC SE - so if activating MCCP1 is your final subnegotiation sequence, Mudlet freezes (but if there's another subnegotiation sequence afterwards, it gets eaten, then Mudlet carries on).

Activating MCCP1 after negotiating MCCP2 is clearly unintentional, I was just wondering if anyone knew why multiple muds do it. If it's caused by a certain snippet, perhaps that snippet could be fixed. I've tried talking to the staff of muds that do it, but nobody seems to remember where their MCCP code came from. If it's an old snippet, the problem wouldn't have shown up until relatively recently, as the older clients support both MCCP2 and MCCP1.
17 May, 2011, Twisol wrote in the 6th comment:
Votes: 0
Hmm. I really want to say that Mudlet's right and MCCP should have just been updated to use IAC SE, but I guess if it broken and you have lots of people using it, it would be easier to start from scratch. Kind of bothersome though.

Sorry for hijacking the thread.
18 May, 2011, Tijer wrote in the 7th comment:
Votes: 0
KaVir said:
A new telopt was needed for backward compatibility reasons. A good example of this is Mudlet, which incorrectly implements MCCP1 without the malformed IAC SE. This means that if you send Mudlet IAC SB MCCP1 it then waits until it receives IAC SE - so if activating MCCP1 is your final subnegotiation sequence, Mudlet freezes (but if there's another subnegotiation sequence afterwards, it gets eaten, then Mudlet carries on).

Activating MCCP1 after negotiating MCCP2 is clearly unintentional, I was just wondering if anyone knew why multiple muds do it. If it's caused by a certain snippet, perhaps that snippet could be fixed. I've tried talking to the staff of muds that do it, but nobody seems to remember where their MCCP code came from. If it's an old snippet, the problem wouldn't have shown up until relatively recently, as the older clients support both MCCP2 and MCCP1.


Well alot of the God Wars MCCP stuff originated from Jobo of Dystopia, his "snippet" supported both mccp1 and mccp2
18 May, 2011, Scandum wrote in the 8th comment:
Votes: 0
While on the MCCP subject, are you planning to add MCCP support to your protocol handler KaVir?
19 May, 2011, KaVir wrote in the 9th comment:
Votes: 0
Tijer said:
Well alot of the God Wars MCCP stuff originated from Jobo of Dystopia, his "snippet" supported both mccp1 and mccp2

I just checked it - Jobo's snippet negotiates MCCP2 first, so it shouldn't have this problem.

Scandum said:
While on the MCCP subject, are you planning to add MCCP support to your protocol handler KaVir?

No, there are already snippets for that, and I think it's better off decoupled from my code. I might elaborate on the instructions for adding MCCP though.
30 Nov, 2011, Rarva.Riendf wrote in the 10th comment:
Votes: 0
Heh just added the snippet MXP_MCCP.zip using yours , is there a 'better' snippet out there btw ? (was very easy btw, your protocol.c just rocks)
30 Nov, 2011, Scandum wrote in the 11th comment:
Votes: 0
My MTH MCCP implementation uses 75% less memory and has less redundancy than other snippets I've seen.
01 Dec, 2011, David Haley wrote in the 12th comment:
Votes: 0
Data please?
01 Dec, 2011, Rarva.Riendf wrote in the 13th comment:
Votes: 0
Any of the client coder made unit tests to test the various protocol they say they support with all test cases (logging quitting normally, breaking connection reconnecting etc etc ?)
Would be handy so you can test a server for compliance.
As I am not interested in the protocol themselves (and dont want to be) and just add the snippets I find, I have no idea if I am implementing them right.
I mean I test through Valgrind for memory leaks, the usual test cases with pure telnet and stuff lie tintin zmud and mush, but having a 'general' tool would be the best way for the mud community to test their server.
I am quite surprised I have seen nothing about it, but maybe I used the wrong keyword while searching.
01 Dec, 2011, David Haley wrote in the 14th comment:
Votes: 0
Quote
As I am not interested in the protocol themselves (and dont want to be) and just add the snippets I find, I have no idea if I am implementing them right.

Out of curiosity, why would you implement and support protocols in which you have no interest?
01 Dec, 2011, Rarva.Riendf wrote in the 15th comment:
Votes: 0
David Haley said:
Out of curiosity, why would you implement and support protocols in which you have no interest?

Easy to implement, no actual drawbacks I would consider matter.
It is like adding a feature in game that can be very easily done by trigger or with simple already ingame aliases. Most cost hardly nothing to do it, so why not.
Relieves from the boredom of coding something else you are stuck with as well. Sometimes I a am stuck with an idea, but cannot find a 'good way' to design it. So while I am thinking about it, I just plug in something that is purely technical, like a protocol, or a snippet I just have to adapt so it works, but not having to 'think' about it.
Some people would go read a book or watch a movie, I just go code mindless stuff.
03 Dec, 2011, Rarva.Riendf wrote in the 16th comment:
Votes: 0
hmm, realized MXP_MCCP.zip was mccp1 so replaced it by mth-1.4 that is mccp2…
and wich is indeed better as is(the one in mxp_mccp use one outbuf buffer per player, I see no reason why…)
03 Dec, 2011, Scandum wrote in the 17th comment:
Votes: 0
mth-1.4 also allocates 32K of memory per player of internal zlib memory, while MXP_MCCP.zip allocates 128K per player. Based on my own tests the compression ratios are pretty much identical.
03 Dec, 2011, Rarva.Riendf wrote in the 18th comment:
Votes: 0
Scandum said:
mth-1.4 also allocates 32K of memory per player of internal zlib memory, while MXP_MCCP.zip allocates 128K per player. Based on my own tests the compression ratios are pretty much identical.

NM, was just one of this writing when thinking of something else… had in mind the siteban structure buffer, and dunno why I thought there was one in player as well..
Considering how MXP_MCCP is version 1, it should be deleted and replaced by the one in mth-1.4.
I guess the compression ratio does not change that much because the buffer to compress is already very small to begin with.
03 Dec, 2011, Kober wrote in the 19th comment:
Votes: 0
There are also 2 mccp patches here.
0.0/19