Interpretation of Chat flag letters

[SlySven]

I've been running a comparison of MUD clients that implement the MMCP chat protocol (as part of adding it to Mudlet).

One oddity that caught my eye was a difference in the meaning of the 'F' character. According to the MudMaster documentation, 'F' means something about a Firewall (maybe the detected incoming connection is on a different IP address to the one it advertises) whereas 'T' is used to show that this client instance will accept file transfers from that peer:

However, I noted that MUSHClient uses 'F' to indicate file transfers will be accepted instead of the 'T' that MM uses - is this intentional or accidental?

BTW Is there a method to set the IP address that MUSHClient advertises when it tries to make a connection to another peer? I could not see a way to set this but it'll be needed if it is behind a ISP's NATing modem/router and a central server is not being used...

[nickgammon]

Sorry for the delay in responding. It has been quite some time since I wrote that stuff (14 years ago maybe?) and I simply don't remember exactly how it works, or indeed how it works in general.

The code here seems to indicate how flags are set:

static CString MakeFlags (CChatSocket * pChat)
  {
  CString strFlags;

  if (pChat->m_bCanSendCommands)
     strFlags += "A";

  if (pChat->m_bIgnore)
     strFlags += "I";

  if (pChat->m_bPrivate)
     strFlags += "P";

  if (pChat->m_bCanSnoop)
     strFlags += "n";

  if (pChat->m_bHeIsSnooping)
     strFlags += "N";

  if (pChat->m_bIncoming)
     strFlags += "S";

  if (pChat->m_bCanSendFiles)
     strFlags += "F";

  if (pChat->m_iChatConnectionType == eChatZMud)
     strFlags += "z";

  return strFlags;

  }

I can't offhand see where those flags are set. I don't think the chat system was particularly robust, and I have had practically no bug reports or questions about it which seems to indicate that either it worked perfectly (which I doubt) or no-one is using it.

Is there any particular reason you don't use a more modern peer-to-peer chatting system, such as Discord? I think the point of chats in the past was to bypass any limitations server admins might put on you (such as logging what you said), but if you use some other provider, like Discord, then they won't be able to see what you are saying either.

[nickgammon]

BTW Is there a method to set the IP address that MUSHClient advertises when it tries to make a connection to another peer? I could not see a way to set this but it'll be needed if it is behind a ISP's NATing modem/router and a central server is not being used...

I don't think so.

[SlySven]

Is there any particular reason you don't use a more modern peer-to-peer chatting system, such as Discord? I think the point of chats in the past was to bypass any limitations server admins might put on you (such as logging what you said), but if you use some other provider, like Discord, then they won't be able to see what you are saying either.

Well Mudlet does include a quite sophisticated IRC implementation, but it cannot use Discord as their "SDK" is incompatible with GPLed projects - like Mudlet is.

As it happens the Medievia MUD is keen to move away from the MudMaster client they have previously recommended - because it is even older than MUSHClient (and creaky as well!) They do make extensive use of the MMCP protocol though and I have always wanted to incorporate it into Mudlet. So when someone else contributed a largely viable wodge of code I've joined in and been filing down the sharp edges and filling in a hole or two with them.

BTW Is there a method to set the IP address that MUSHClient advertises when it tries to make a connection to another peer? I could not see a way to set this but it'll be needed if it is behind a ISP's NATing modem/router and a central server is not being used...

I don't think so.

As their (well Medievia's) usage is based around a server the details of advertising the connection details is not something they worry about - however in order to allow a peer to advertise the public connections it has, the user might need to tweak what is reported in the initial "CHAT:%s\n%s%-5u" string (the details on the second line) so that it reports the public address of their modem/router which has been set to forward incoming connections to their PC.

For comparison Scandum's TinTin++ allows/does that via it's #CHAT {IP} {www.xxx.yyy.zzz} command (where the last argument is an IPv4 quad-value address).

Edit A cursory look at your code suggests that void CChatSocket::OnConnect(int nErrorCode) would need revising to accept a user provided address instead of the first one that (void) GetHostNameAndAddresses (CString & strHostName, CString & strAddresses) populates into its second argument.