Any way to make a 'chat' plugin?

Is there any way that you could make a PlugIn that would allow a person to 'chat' with MudMaster or ZMud? I still feel that MUSH is the best client, but that is the biggest feature it lacks. I think a /LOT/ of people would switch to MUSH if it supported chat, or if someone could write a plugin for chat. Anyone?

A chat plugin would be fairly hard because it would need to do stuff that is not in MUSHclient anyway (most plugins will utilise existing capability).

Particularly, the need to handle incoming asynchronous messages would be hard in a plugin.

If a lot of people think a chat feature would be handy, perhaps that should be the next major development. Comments, anyone?

The thing that I like best about Mushclient is that it isn't bloated. IMHO, let things like AIM be good at the chat thing and Mush just keep spitting out the mud output.

I'd much rather see things like macros being able to be bound to all keys or other improvements to the core functionality than a tangent like a chat client.

Dub.

Yes. More functional design implimentations would be better.

I posted something about Zuggs chat client a while back. Anyone actually look into seeing if it is COM complient? Mushclient still wouldn't be able to 'recieve' chat from it, since there is no way to make a threaded plugin or script that runs continuously right now, but it might be able to 'send' to that chat client through the interface with a plugin designed to let you use all the needed commands.

Exactly what Dubthach said.

Not precisely Magnum. I don't agree with his assumption that AIM or other chat clients are viable solutions. They cater to too many different groups of people and in some case like ICQ, even if you hide yourself from people, the mere fact that you are a member of the service means any idiot can try to talk to you (usually some ass pedaling a porn site). mud chat is far more select, has a much smaller number of users and you can gag people a lot easier. Also.. Unless I am wrong there is no central registry, so you needn't worry about idiots dropping in to spam you anyway.

"If" Zugg's program can be linked to mushclient, either directly (prefered) or through a plugin it is viable solution. If not, then building it into the client is the only useful option at this point. However.. That doesn't mean the feature can't be made to be a seperate COM, just latching on to mushclient through commands to support it and some minimal interaction the other direct (like an alert to show new text, etc.). As a scripted plugin such an alert can't really be done.

Its one thing to have AIM or ICQ open in the backround and chatting with people thru that..But it is entirely different to have a direct 'peer to peer' chat going on with multiple ppl at once on a MUD. Its like having your own private, unloggable/unsnoopable channel for you and your friends, clan. It makes staking out PKs a lot easier as well! :) Personally i might have to offer Nick my firstborn child if he were to code that into the next version of MUSH. :)

Personally, I would still prefer such an application be written outside MUSHclient, perhaps as Shadowfyr suggests.

For example, a 3rd party program could interact with MUSHclient by sending incoming text to the MUSHclient, and MUSHclient could send outgoing text to that program.

This might be as simple as setting up another "World" that connects to a local port. If you wanted to, you could use scripting to route the communications to your world of choice.

You would then run a seperate "IM server" that could format the incoming strings in whatever form you want, which could be triggered upon and echoed to another world:

You could set up script here to Trigger on the incoming lines and echo them to another connection/world output screen. You could also write aliases in those worlds to take a line and send it out via this connection. All of this without bloating MUSHclient! :)

Perhaps Nick would be willing to write the separate "IM Server"?

Well Magnum.. Currently the problem with is is that scripts are not 'threaded' If there was an option to thread a plugin, so that one of its scripts to continually watch for messages, then maybe if would work. However, probably not, since in general you don't poll such programs to ask it if new data is available. Instead the most servers (which in this case it would be acting like) usually send a message that they 'expect' to be caught by the client program shortly after it is sent. Providing a means to run some scripts in a seperate thread, may not necessarilly solve that problem. The script itsself is more like a document displayed by a COM program (the script engine). There is no way to really talked directly to it.

The only way I could see a plugin working would be if the text arrived in a seperate program and you used the plugin to mearly send from in mushclient. You might be able to write a chat client that could buffer the incoming text and wait for the plugin to request it, but imho you would need to thread the plugin then, because otherwise you need to use a timer and a 1 second delay in actually seeing the new text could be really annoying (especially if you have a lot of fast typers and lots of chat traffic).

So... The options are:

1. Existing form. No threaded requests, all text out and in displays in the seperate chat client. Plugin only sends commands and text from the mud.
2. A threaded plugin that can loop a 'give me new data' request. Plugin handles commands and display of the text in
mushclient. Advantage is being able to use colourtell, etc.
3. Partial integration. Where mushclient tells you if new text has arrived, but uses the external program for the chat and a plugin to talk to it. Probably requires writing
a new chat client.
4. Full integration. Mushclient sends and recieves text from the chat through the external program. No plugin needed. May work with existing Zugg chat program (maybe).
5. Built in. Same as 3, but with no external program. Can use existing triggers to do matching and coloring, etc.

Personally I have enough space on my own desktop that I would prefer something between option 3 and 4, but with the ability to have the reception and display of the chat within mushclient turned off, so that the chat client itself would handle that part. Having everything jammed into a single window in mushclient, even if you would prefer is was someplace else, is one thing that kind of bugs me. However, this would mean building a custom chat client that included similar trigger coloring and such in it to what mushclient uses, since otherwise you are forced to have 'display in mushclient' turned on to get that functionality and you are right back to having it all stuffed in one window. :p

Well, what I am talking about, Shadowfyr, is an independant IM program running on your computer. The IM program handles communications out to the internet, and also handles communications with MUSHclient. Essentially, the IM program acts as a local proxy server.

As soon as I disconnected after writing my previous message, I thought of a better enhancement:

Allow a world to have 2 connections open at once!
The rules for the second connection would be:

• All incoming text is sent to the world's output window.
• Text is only sent the the second connection if a custom character prefixes the string.
• Optional: The second IP must be 127.0.0.1, with configurable port number

How it would work:

Optionally, string could be formatted with preable, etc at local port, BEFORE being sent out. (Instead of on remote recieving IM program)

This isn't that much of an extension to your "Phantom" program, Shadowfyr... Except that you would need to build the internet communications. :)

The nice thing, is it doesn't bloat MUSHclient. Listening to a second ip:port per world would likely just require additional calls to existing routines within MUSHclient. The world never sends anything to second port except when explicity instructed via a user configurable 'alias' (character).

Yes, you need a third party IM program. Isn't that the best option though? Gives the user the option of bogging down their system with more running programs, instead of building into client, which makes those of us who don't care about IM'ing suffer with extra bloat.

Well, also with scripting, like 'World.SendtoIM "Magnum wuz here."

The author of the IM program would be responsible for secure communications, etc... (NOT MUSHclient). :)

Hmm. Interesting Magnum.. That would work, though it fails to cover the 'what if the user doesn't want IM messages to appear in the muds output window' problem. As I said. I would prefer them to go to a seperate window. For that matter I wouldn't mind routing the existing channel traffic there as well, but that is a seperate issue. However, it does solve the biggest problem of how to get the two to talk to each other.

I haven't read every word in this thread (yet) but I have a couple of comments.

First, how important is compability with zMUD or MudMaster to you? It is easier and quicker for me to do something that lets MUSHclient users chat to each other, without digging up the MudMaster chat spec, working out how to implement it, and testing to make sure it does work (with both of them).

Second, I am toying with the idea of using UDP for a chatting system. I think zChat uses TCP, but am not absolutely certain. The difference is that UDP is connectionless, which means that you don't have to establish a connection, nor worry about what happens if it drops out (eg. if one member of the chatting party crashes). It is also easier to program.

This is how it would work...

Say you have a 4-member party, let's call them A, B, C and D (just to be boring). Each of them has a UDP port open in listening mode (receive mode) - the port number being by convention or agreement (eg. 4999). When MUSHclient receives a message on that port it simply displays it (like a world.note in concept). Similarly when you *send* a message (eg. :message) it sends a UDP packet to each member of the part (A, B, C, D) except itself of course.

The only problem would be to filter out spam arriving on that port, but probably you would do this by having the list of IP addresses (eg. "add chat member"), something like this:

add "A" ip "1.2.3.4"
add "B" ip "4.5.4.6" .. and so on

If a packet arrives from an address that is not in the list it is discarded. Thus you could "block" someone by simply not putting them in your list.

I don't know how much more complex than that it needs to get, maybe "emote" or "say", maybe the provision to send to "all in party" or "selected party member".

The good thing about this is:

1. It is simple
2. Being connectionless it just keeps on going as people drop in/out of the group.

There might be a danger, where people share IP addresses at an ISP, that you might send the message to the wrong person. Maybe a "I am joining the group" message needs to be sent first to initiate the connection, perhaps with an identifying name and password.

Having said all that there is one problem with UDP, it is not guaranteed delivery. I don't know how unreliable it would be in practice, but there is certainly a possibility of discarded packets, ie. messages going astray.

We could work around that to a certain extent by numbering packets, then MUSHclient could warn you if the packets arrived out of sequence (eg. "warning, 2 messages lost"). Then at least, you could ask for that person to resend.

What do you think?

Hmm. I don't think anyone wants to have messages get lost. lol

TCP/IP would work better imo. As for what to support... Several programs support both Mudmaster and zChat, but short of asking the creator of mudmaster for specs, there doesn't seem to be any available. However.. Looking at a copy of mcl to get a clear idea as to what is going on, it seems that mud master's chat protocal has some complications. The least of which being that is uses a termination character, rather than a 'length of data' field, but if it is supportable.... I do think zChat is the better one though. Basically it would be nice to not have a mushclient specific chat. Doing so kind of defeats the whole point of what the person who started this thread was intending to do, which is to chat with MudMaster or zChat clients.

Interestingly it could 'almost' be implimented using a second world and scripting. 'Almost' because one thing it needs is to keep track of all the IPs to send data to, so a script based one would only work to talk to one other person, who's 'full' client would have the burden of passing on any traffic from you to everyone else. Assuming of course that the full clients even try to echo packets to others. There is nothing in the spec suggested that they do, should, can or will.

My only major gripe with zChat is the same as with FTP in most browsers, the file transfer they support.. What is it with people designing things and leaving out simple and necessary stuff? In the old days you had ANSI and it was good, until someone remapped F1 to be FORMAT C:.
Nothing changed (i.e. no one bothered to provide a subset of ANSI or limit such remappings to the user end). Someone built file tranfer protocals and they where good. Until you had to restart a six hour download from the beginning for the 14th time. Eventually someone came up with YModem (pretty good, if you could stay on the full 6 hours, but..) and then finally ZModem. Then TCP/IP and the net is introduced and... we are right back to having no 'resend last packet' support. It bugs the hell out of me.

If you did impliment file tranfer support through the connection, I would suggest using something a bit like ZModem did. I.e. ignore the existing file commands in the spec, and add a new set of commands (like 512,513,514, etc.) that do the following:
This is the only thing about the zChat spec I thought was bad. Though apparently there is also a flaw in the initialization, where security data isn't terminated correctly. Why Zugg didn't provide a 'length' field for that, like everything else, I have to wonder.

Well.. i dont know all the technical jargon and stuff, but i do know some things.. I downloaded ZChat the other day and it seems to have some compatibilty issues between MM chat. If you use a custom color scheme in MM it doesnt seem to want to pick up the chats. You see that someone is trying to chat to you, but you dont see what they say. Another thing is MM has the ability to 'Chat Serve' people. Where there is a host IP and everyone connects to it, and all the messages are routed thru it and to everyone else. So theres only 1 IP to call, etc. Some people i play with use it, and others just have certain ppl they want to chat with. But being compatible with ZMud and MM i think is a must. Having chat, but only being able to chat with other MUSH ppl kinda limits what you can do. Yes, im a huge advocate of MUSH and i try to get people to switch..but they are going to want their chat with all the fixings that the other chats have.

Well NC99, zChat does say quite clearly that it doesn't support 'all' mudmaster features. As for the difference in them.. From what you say mudmaster uses a central server, so a client does this:
I am not sure if zChat always sends to all linked IPs or if it does use some way of reestablishing the connection if the 'server' drops it, but the above is a reasonable (though probably wrong) assumption of how it works. In theory this is far more stable, since each client can act as a server and knows the IP of every other server/client in the chat. There is no need to worry about the main server that handles all the traffic crashing. This is however less secure, since all chatting IP addresses can be grabbed, if you have the right tools. However all true P2P networks have this flaw, so...

As for you color problem and such.. It is likely those a features of MM that are not implimented in zChat. Some such features may even be redundant between the chat protocals or interfer with each other, so where intentionally left out. Since I don't have the MM spec, I can't really say for sure.

However.. The irony here is that if it does work as you say, then MM could be implimented through a plugin and scripts, there being no need to keep track of or talk too all the other connected IPs directly. ;)

Shadow: MM doesnt use a central server..but the option is there for someone to 'act' as the central server.

Ah.. Well without the specs it is a little hard to know. lol Especially since the version used in zChat and zMud are apparently broken implimentations, at least according to some posts on the MM forums.

Using a "chat server" seems to me to defeat the idea of peer-to-peer chatting. If you are worried about someone eavesdropping your chats, then the chat server could do that, unless you operated it yourself.

One fairly simple approach to implement chatting, is to make a small server of your own (eg. download PennMUSH server from this site), tweak the configuration a bit to maybe not allow guest logins, add a room or two, and then advise your friends of its IP address and port. Then everyone (in the group) just connects to this server and uses it for chatting. You could then make an alias in your "main" world to capture chats and send them to the other world, and a trigger in the world to capture replies.

If you don't want to do that, then you could even just find a quiet MUSH somewhere and connect to that, find a quiet corner, and use that as your chat medium. I suggest a MUSH because you don't need to muck around eating and drinking to stay alive on them.

Alternatively again, you could write your own chat program (eg. in VB) and using COM interface it with MUSHclient.

Well.. I wasn't sure about the specification. Some peer-to-peer systems use a single server to provide a list of place you can connect to, then true peer-to-peer once connected. That could have been the way it worked, since there is one or two instances where muds talk about people using MM on then, thus implying that the mud itself provides such a service.

As for writing out own.. Without the 'correct' specs we wouldn't be able to write one compatible with the existing implimentations and not supporting them would, as has been said before, not really be what we want.

Now if zChat can reconnect to others automatically if the clients own 'server' goes offline is a definite issue, but a seperate one from the main point of this discussion, which is, 'should mushclient support it as a built in feature and if not, do we even have another viable option?' I am not sure we do have such an option.

I realise this post is a bit late, but if anyone is still reading this.. Out of interest I wrote a prototype zMud, MudMaster chat plugin for MUSHClient back in 2001. It works fine except at the time v3.17 sending colored text to a MUSH window was slow as all hell (so as soon as someone spammed a page or more of chat the speed is unacceptable).

All that MUSH needs to do is provide a way to send ANSI color codes to the world for it to parse that is not a total dog.


It really *almost* highlights the power of the scripting engine.

Skars...

My own approach I 'was' considering would have been a seperate chat window. It is faster to send text to the mud or recieve it from the mud and drop it in an external app through the script, thus letting you use it to talk on mud channels as well as the normal chat, than to try to feed all the information from an Mudmaster chat connection through your world window. I.e. the idea is to 'reduce' spam in the main window while supporting chat, not increase it. ;) lol

I really didn't feel that implimenting a chat program that could be talked too by mushclient was really worth the time though. A more programmable multi-use window was what I planned, but implimenting it proved way more complex than my current knowledge allowed or the time I was willing to spend on it would require. What 'should' have been simple to do in VB turned out to be a snake pit full of exceptions, limitations and work arounds that quickly pissed me off. lol

I would like to take a look at what you managed to put together. Though if it used the only implimentation spec that I could find (i.e. zChat's) then it is probably still broken with respect to some things in MM. Unfortunately I was never able to find a spec for MM's implementation itself. :(

I based the script/dll on MudMasters chat by reverse engineering what mm does, there is no specification. From what I can gather there was once, but its gone.

The zChat's specification has alot of bloated useless junk in it that is not compatible with mm's implementation, which annoys me no end as zChat was *based* of mm's chat. (I'm sure someone mentioned standards before).

If Nick ever manages to implement a method to send ansi formatted strings to the world window that isnt horribly slow It would be worthwhile finishing the prototype *hint hint*.

Skars

After seaching my old backups I have found the original MudMaster chat spec, or what looks like it anyway. It was a Word document, so to make it more generic I have reformatted it as an HTML page, which you can find here at MudMaster Chat Spec

I hadn't realised that world.colourtell was so slow - there is something wrong there. I'll look into fixing that.

I have achieved a reasonable speed improvement by changing the way it refreshes the window after doing a world.tell - now it only refreshes when the line changes. This makes it flicker a lot less, and work a lot faster, particularly if you have lots of colour changes on one line, however the only drawback is that a partial line (ie. one without a final newline, caused by a world.note, or output from the MUD) will not be drawn (yet).

Now, armed with the proper spec, and faster colour updating, it should be possible for someone to release a nice chat plugin *hint hint* :)

Nice to have a speed up like that. It did tend to be slow. For instance on a 300mhz machine a line like:

[Ww-Hb-Mb-Bc-Sp-Sh-Ar-In-Sg-Sl-Pn-)(]

Would literally lag so much you could watch the client build the line with every Ww, -, Hb, -, etc. one at a time. ;) It generally took about 1-2 seconds 'per' line.

Needless to say, thanks for the speed inprovement.

Hmm.. Looking at the specs for ZChat and Mudmaster the difference seems to be:

1. zChat uses a 'stamp' to ID where the message comes from and avoid message loops.
2. zChat uses a 'length' field, in order to avoid the use of ASCII 255 as a terminator.
3. Uses 1024 byte blocks, instead of 500 for file transfers.
4. Adds the commands Icon, Status, Email address, request PGP key, PGP Key, Send command and Stamp.

My thoughts on the differences... Zugg was right. Beign able to specify a length is safer than using a terminator in some cases. Also a 500 byte block is silly for file transfers and just doubles the overhead. A better method would have been to add a new option:

IDs 200->205 - Bandwith Limited File Transfer.

This would allow you to do what you can do in many P2P systems, including WinMX and specifically limit the transfer rate by ignoring requests when the total bytes per second exceeds some limit. This should reduce lag for those of us with dial-ups to a managable level. Though the guy downloading from you may grumble, it would let you keep playing and using the chat, while a full on download would kill you (sometimes literally).

zChat must check the client ID and use the MM character 255 terminator when talking to MM clients and the length info for other zChat clients.

In the same style as ZChat's changes... I would consider adding the option of supporting the ability of the users to tell the other client what color to use for 'their' text and allowing HTML color tag support. You would send an ID request like 206 - 'MuChat?' and get back 207 - 'Yes' and then talk to any such clients using the extended set of features, like the extended color support. This could mean that someone connect to a zChat or MM client, and not directly to you, would not be able to send/recieve such, but that is the way things go and you probably have the same issues dealing with zChat, unless it always does a connections list request when it links to another client.

For the plugin to not just be another buggy client that people complain about being 'broken' though, you need it to be able to talk to MM and zChat, support zChats quirks and nicer additions, like the user icons, and hopefully perform the Name Change thing that is one of those 'broken' in zChat when trying to use it with MM. That is assuming Zugg hasn't fixed that yet.

Anyway.. Just some thoughts on what would be needed or would be just nice to see. ;)

I don't want to change the spec and make a third chat system right now. :)

It would be good to work with zChat and MM. Can you clarify how this works for me? The spec talks about "making a connection" - I gather a peer-to-peer connection?

Say you and I are on some MUD, do I ask you for your IP address, and then (somehow) chat <ip> which makes the connection to your PC? What port do I use? Do you just choose one? What if another person wants to chat? Do you specify a different port (after all, they can't all come in on the same one)?

Does it go like this, for instance:

Nick: Let's chat
Shadowfyr: Good idea. I am IP 1.2.3.4, use port 5678
Nick: OK, doing that
Shadowfyr: Listening on 5678
(Shadowfyr tells client to listen on 5678)
(Nick tells client to call 1.2.3.4 port 5678)
(Chat established)

Or is the system somewhat different, and if so, in what way?

Umm.. Not 100% sure. about the port. My guess is that the connection request is sent on a 'known' port. However, you can have multiple port 80 requests from HTTP, so I don't see why you can't have multiple connections on any other port. It looks like Skarsnik's attempt uses port 2050 by default. In other words you can specify a different port, but the initial request 'provides' the correct IP and port to use and 'must' come in on a default port number. Most servers use this method, or alternatively use something like MS does and uses a port redirect. In this case it is like this:

Nick: Let's chat
Shadowfyr: Good idea. My IP is 1.2.3.4
(Shadowfyr starts the chat client.)
Nick: OK, doing that
(Shadowfyr's client listens on 2050)
(Nick tells client to call 1.2.3.4 and use port 5678)
(Nick's app sends a request to 1.2.3.4 port 2050)
(Shadowfyr's client recieves request and sets an outgoing connection to Nick's on <Nick's IP>:5678)
(Chat established, both clients now communicate to each other using port 5678)
(Nick's client sends a CHAT_REQUEST_CONNECTIONS command to get other connected client IPs and ports)
(Shadowfyr's does the same, so both know everyone that the other is currently talking to)

However, yes they can 'all come in on the same port'. Otherwise the programs would never work. Choosing a different port is generally only needed to avoid collisions with other applications or specify an accessable port under a firewall. You may want to talk to Skarsnik about how the negotiation actually works, since I haven't seen the actually negotiation process take place or which end actually makes the final connection. I do know however, that it "can't" work unless you start with a known port.

Alternatively, it may be like you suggest and you do have to have both clients on the same port to connect, but then that would be a seriously stupid design imho.


As to changing the spec.. ZChat already did that and broke several things in the process. You can't even support basic MM commands without knowing 'if' the one you are talking to is MM, since the basic syntax of zChat and MM are different. The fact that one uses CHAT, and the other uses ZCHAT as the connection request command is 'key' to knowing which one to use. Adding the commands I suggested doesn't break either one. I assume they simply ignore anything sent to them that has a command ID they don't recognize and since one of the additions is a seperate ID method to say 'yes this client does use these commands', you could pick either MM or zChat as the 'default' protocal and no client would care, except other MuChat users. The others would simply never be sent them, so would never need know they existed.

The only possible problem would be if the 200 range is already being used by someone else for something and since zChat adds its commands in the 100 range, that is not likely. It extends the protocal, not completely replaces it. I would suggest to anyone that coded one to use the zChat implimentation though as the 'base' that the plugin would use, since it does add some of those additional features like the icons.

NOTE to anyone doing this (and Skarsnik specifically): While your 'plugin' makes for a nice 'chat' plugin, it doesn't appear to support the ability to post other things to the chat window. Some of us have been trying to find a way to redirect existing channels and the like to a seperate 'and color supporting' window. Providing some sort of method to allow a 'chat.note' command or the like would be helpful to handle this.

Also... Having the script unable to reconnect to an existing chat window is an issue.. It would likely be a good idea to find a way to fix this somehow, since I can just see me chatting with someone about something 'in' one of those scripts and losing them when I reload it to check something. Not a good thing imho and kind of make it a lot less useful.

Yes, of course they can. I don't know what I was thinking of when I wrote that. :)

OK, your next sentence touches on my next query, what does a third person (eg. Magnum) do? Does he connect to Nick or Shadowfyr's PC? I presume from what you said that you make an informal in-game arrangement that one of you is the host, so that the host listens for connections and the others establish them?

Then, when each player joins, s/he uses the chat protocol to find *existing* connections. For a new connection the new player would need to enquire which player is the host and which IP to use.

Is there a well-known port for zChat, MM chat?

I think they are all supposed to work as server or client. They generally only care about who they specifically host. i.e.>

Client 1>
Hosts 2, 3, 4
Connected to 5

Client 5>
Hosts 1, 6, 7

Basically any message that gets sent is echoed down the line, so that each person echoes that message to the ones they host. I am not 100% sure how it handles directed messages if the guy you are trying to talk to is on say client #12, which is hosted by 7 and sent by 1. You could get loops, so some sort of method probably needs to exist to ID what messages have already arrived at 'your' client, However, since you can 'host' multiple others, but only 'connect' to one, this probably fixes itself, since you will never get two clients hosting the same third party.

Basically all clients are also hosts and it only matter who you connect to if one of them might drop the ball and disconnect a mess of them. It is probably a good idea for clients that see a new user that they don't have a connection for to ask the client that sent them the message, but then whos client make the request to connect to ones that are still available? I don't know how or even if they handle that.

As for the well-known port?? I have no idea.

If someone connected to client 5 in your example, and requested connections, wouldn't s/he only see 1, 6 and 7, not 2, 3 and 4 which are indirect connections? Surely "request connections" wouldn't cascade? All client 5 would know is it is hosting 1, not that 1 is re-hosting other clients.

Thus I would imagine, but have never used it so I couldn't say for sure, that you would agree on one player as the host, not randomly connect to each other.

Or, if you did connect to each other, each connection is considered a separate chat session.

In your example, client 1 might be one chat session on one MUD, whlist client 5 is another chat session for another MUD, and inter-session messages are not only technically difficult but not desired as players from different MUDs see irrelevant messages for each other.

Just guessing. :)

No. They all share 'one' chat session. Basically in my example, a message sent by 6 to 5 would be passed to one and one would be responsible for passing the message to any it hosts. Same if a message came from 3, then 1 would pass it on to 5, which would in turn pass it on to only those it is connected to and so on. There doesn't need to be any central one serving the rest, but if one that acts as an intermediary dies, then you lose groups of people, but only those 'hosted' by the one that was lost.

OK, I see that now from the spec. :)

Now, what is all this talk about needing colour for making a chat plugin? Is that just so chat lines can be in a different colour, or are ANSI codes imbedded in chat messages?

MudMaster seems to default to port 4050.

Hiya,
MudMaster's default listen port is 4050. If that port is taken it then jumps to 4100, 4150 ect..

Ansi codes are imbedded in the chat messages. So the chat client I wrote was parsing the ANSI text and converting it to MUSH. Which might be an issue in visual basic as its string handling is quite limited. So porting it to c++ looks like a good option (porting it would also reduce installation bloat). C# is out as the installation would bloat.

As for the plugin being able to post the messages to another window. I think this will be limited by MUSH, as creating a MDI window and attempting to plug it into an running application is asking for a world of hurt.

The chat serving in MudMaster is very simple, basically if you (A) server some one (B) you echo all of their messages. But if someone else (C) is serving you, then they only echo your messages, not (B)'s messages.



Skars


N.B. I'm going to play with this over the weekend...

(Quoting Nick Going back about 10 posts)
> I have achieved a reasonable speed improvement by changing the way it refreshes the window after doing a world.tell - now it only refreshes when the line changes. This makes it flicker a lot less, and work a lot faster, particularly if you have lots of colour changes on one line, however the only drawback is that a partial line (ie. one without a final newline, caused by a world.note, or output from the MUD) will not be drawn (yet).

Correct me if im wrong and I guess you have realised this; but all Diku based muds send the last prompt without a new line. Won't this cause serious issues?

As for not printing .tells until you send a new line. There will be occasions when you wish to tack on a bit of information at the end of the last line without feeding a hard return. Perhaps a .tellRefresh or something similar could solve the problem...
(The reason i mention this is because one of the first scripts I will write when I port my stuff to MUSH is a script that 'tacks' on something to the end of a prompt telling me whats changed).

N.B. Chat comming along, any one wana beta test it?

Skars

First, the new technique only applies to world.tell, not MUD output. Thus the Diku prompts will still be OK. I am well aware of that problem, that was one of the problems in the original (version 1) of MUSHclient where it didn't draw the line until it got a newline.

As for the tell which tacks onto the end, potentially this will be a problem, however I think recent versions don't allow mixed lines anyway, so the problem goes away (or gets worse, depending on your point of view). Maybe a "refresh" might be called for, perhaps you can test for me. :)

>The chat serving in MudMaster is very simple, basically if you (A) server some one (B) you echo all of their messages.
>But if someone else (C) is serving you, then they only echo your messages, not (B)'s messages.

Except that B's messages 'are' you messages. lol So it makes no sense for C to echo B's messages, it has no idea that B originated them. However, message traffic 'must' go both directions and be echoed to 'all' connections that have been established, except the one the message came from. Otherwise all messages would go down the pipeline, but never the other direction. In other words, if you only echo to those 'you' serve, then C can talk to B through A:

C ==> A ==> B

but C would never recieve anything from B.

C /\/ A <== B

The point being that even if B is sending a special message to the user at C, C's client has no idea that it did orignate with B, unless it looked up the IP and port info for 'that' user. Since it does have this info though, it could concievably make a second connection for FTP or directly chatting 'only' to B.

Ironically, this may be a bad thing in some cases, because the direct connection to the other user to transfer a file could be slow, but the one through an intermediary, like 'A', may be much faster. :p The fun of using the internet... lol I think that it is likely that file request do perform a direct link though, since otherwise you would lag everyone in between, unless the guy in between had broadband. Anyway, the point is that saying C doesn't echo messages from B is both technically accurate, but on a deeper level incorrect, since the data is echoed to C, just not directly by B.

I am trying to get my head around how this all works still.

For one thing, CHAT_REQUEST_CONNECTIONS requests the list of connections from another client and then "try to connect to all of those yourself" - does that potentially mean that A asks B for its connections, gets C, and then connects, so now we have:

A => B => C
A => C

Then when C sends a message to A (and B) A also sends it to B, so B gets it twice?

Another issue is that you might try to remove double-dealing by using IP addresses. Now there are 2 IP addresses that might apply (and that assumes the client isn't lying), the "local" IP address, and the "real" IP address.

In my case, with a client behind NAT (network address translation) the local IP address (which the client knows) will be 10.0.0.3 (say), which is a private IP address, but the "real" IP address will be a different one, which is the address of the firewall.

However with multiple sessions going there are potentially multiple instances of 10.0.0.3 (from me, and other people doing the same thing), and multiple instances of my firewall address too. It is hard to say how you would end up with a unique address. Perhaps the real address/port combination might work.

Hi,

I've just spent the last 30 mins reading this thread and I think you folks are onto something. I'm a MudMaster (2000) user and have been for years. The one feature I've always preferred in MM was it's chat capabilities and I was happy to see Zmud pick up on it and implement it. Likewise here.

While I can't help too much as far as the specifics of the implementation go (I'm not a programmer), I may be able to help out with some info on how the chat feature works from a user's perspective.

First, MudMaster (and Zchat as far as I know) default to using TCP port 4050 as previously indicated. However, this is user-configurable and can be set to any TCP port the user wants to use. Most people just use the default, however.

As far as connections go, it's strictly peer-to-peer unless someone chooses to act as a chat server. Connections are limited only by the number of available sockets.

So, my client "A" can connect to "B", "C", "D", etc. If connection B happens to be connected to Z, I don't see anything from "Z" at all. However, I will see B chatting to Z unless he does so privately.

If B chatserves Z, then I can see Z as well. I have no direct connection to Z, however, so I cannot chat directly to him, transfer files, etc. I can attempt to peek at B's connections and obtain his list of connections and call them directly, but B can mark his connections as private which will prevent me from peeking at them.

Assuming, for the sake of argument, that B hasn't hidden his connections and I connect directly to Z, I'm going to get an echo...that is, whatever Z says will appear twice to me. Once from my direct connection to him, and again because B is serving him to me. The only workaround for this is to drop my direct connection to Z or have B stop serving him.

The same holds true if the situation is reversed (B serving me to Z, Z calling me directly).

IP Addressing is different animal. Because ICS, NAT and routers are so commonplace now, it's not uncommon to look at my connections and see private IP addresses in the list. I'm not clear on how MM routes these, but it does. I've seen 192.168.x.x addresses, 169.254.x.x and, strangely, even 127.0.0.1 addresses in my list. Yet, MM seems to have no trouble routing packets to these clients.

Other features available in MM:

Allow Commands: Not as spooky as it sounds, this is used for sending scripts to/from other connections. I have to toggle this on for a specific connection if I want them to send me a script file via chat.

Ignore: Do not disturb, talk to the hand, etc. Allows me to ignore all messages from any connection I sic this flag on.

Allow Snooping: Allows another connection to see the output of "My" client window.

Being snooped: The opposite of above, it just lets me know that someone is actively looking at my client window.

Private: Let's me hide a specific connection from all other connections.

Serving: Allows me to serve a specified connection to all other connections. Useful for individuals behind firewalls who can't accept incoming connections.

Allow File Transfers: Allows a specific connection to send you files. This feature is deliberately capped with a low transfer rate so it doesn't lag you to Hell and back.

I think that will about cover it for now. I'm sure I missed something, but I won't worry about it for now. I'll bookmark this thread and check it over the next day or two. If there's anything else you need to know just ask, I'll do my best to answer.

Mentally yours,
NightCrawler

So.. Back traffic is broken if you have someone that is 'in' the network of connections, but not served by them..

Sounds to me like a serious glitch. It would have made more sense to use something like TCP/IP tracking uses, so that each packet got a unique stamp, allowing echoes to be ignored. By doing it the way MM does, you don't prevent accidental echos, just break something that imho 'should' work. :p Nice to know that it works this way though, even if it is a little less functional than I was assuming.

Not as serious as an infinite loop. I see from the zChat spec that messages have a unique ID, so that you can tell if your own message has come back to you, otherwise I can easily imagine that (via an indirect server) one message sets up a loop that keeps getting echoed until everyone closes their client.

Thanks for the description, NightCrawler, that clears things up a bit. I presume from my preliminary tests with MM Gui, that the chats actually appear in the main client output window, and are entered in the normal command window? eg.

/chat Magnum Hi there Magnum
/chatall Hello everyone

As for the IP addresses, from the MM spec, I gather that clients announce their IP address/port when they connect, which may well be local addresses like 192.168.x.x, however they would have to have a non-local address on the actual connection (eg. the NAT server address) and this is what MM would reply to. I presume the local address is just for displaying purposes, can't see how useful that is personally. One thing to note is that, unless configured, an incoming connection may not work through NAT, as NAT doesn't know which private PC to route an incoming connection to, unless specifically told to.

Hello again,

MM's chat feature displays all chat communications in the main window and commands are entered in the input bar at the bottom as per your example. There isn't a built-in way to send the chat to another window aside from scripting. I've seen a few people ask for a "chat window", but it was never implemented.

Personally, I prefer the chat in the same window as the rest of the MUD output, but that could be me...I don't like having to switch windows to follow a conversation, and I'm still running on a fairly small monitor, so screen real estate is a precious commodity.

I should touch on a few thing: I missed in my original post:

MM supports full color chat. This allows you to write small (or large, if you're bored) scripts to define the color of your chat text and it appears on the other end exactly as you intended. By default, chat text is a light gray color (forgive me, I don't know the code for it), but through scripting I can change the color to, say, bright yellow and anyone I chat to will see it that way. As far as I'm aware, Zchat will see the result of my script through some translation process to interpret it in the Zmud/Zchat equivalent.

MM Chat also supports "emotes" or actions. Similar to the IRC /me command, except it's /emoteall or /emote <connection>. I find a lot of people tend to use this command in their chat scripts because it allows for greater customization. By default, MM displays, "You chat to everyone, 'hello'" or "Nightcrawler chats to everyone, 'hello'", depending on whether you're sending or receiving.

Regarding Zmud/Zchat: Zchat is considered an "add-on" for Zmud. It will function as a stand-alone client, but for those users who own a registered version of Zmud, Zchat will integrate in similar fashion to MM. That is, the chat content will display in the main Zmud window and you can type your chat message in the Zmud input bar. Precisely as indicated in your reply above, except that Zmud uses #chat instead of /chat. This integration isn't provided in the non-registered shareware version, however.

I'm not sure if this will help at all (or perhaps you already know), but the MM console source code is freely available on the MudMaster site. I believe it's written in C++ but don't hold me to that. You may be able to find more information on implementation there. http://www.mud-master.com

Regarding Shadowfyr's comment concerning "Back Traffic", let me clarify the chatserver echo thing a little more. Using my previous example, if I'm connected to B (who is chatserving Z) and I call Z directly, I do not see my own chat text echoed back at me. I will, however, see everything Z says twice. Once from the direct connection to Z, and a second time from B (who is serving Z). My apologies if I wasn't clear in my original post or if I've misinterpreted the comment.

Regards,
NightCrawler

And what happens if three players all claiming to be named Magnum join the chat? Does it stop them? And if you type:

/chat Magnum hi there

Do all three get the message?

There's nothing to prevent duplicate names from connecting to a chat session. Likewise, there's nothing to prevent someone from changing their name to the same as another connection's name. MudMaster stores the connections in the order they connect, so if there are two people named "NightCrawler", it just sends the message to the first one it finds. To be honest, tho, this isn't something that you'd run into alot unless people are trying to be comedians. I've heard of someone writing a script to prevent this sort of thing, but it's not built-in to MM.

As a side note, this problem does occasionally occur if someone loses their existing connection for some reason (network problems, etc) and they reconnect. I run a full-time chat server for some folks I play with and one of them has a notoriously unstable dial-up connection. I haven't seen it cause any problems, other than breaking my chat-serving script.

There is a MM native ping command that can be used for checking latency and I've occasionally used it as a "keepalive" for unstable connections. It will drop a connection if it doesn't receive a response after awhile...not sure how long, tho, since I've never really timed it.

NightCrawler

That is probably one of the reasons why zChat implements a randomly generated ID for each user. There are definitely problems with the implimentation, since it seems to me that neither chat client deals with situtions that are nearly 100% certain to happen on occation or even to properly deal with those that are rare, but can happen. Compatibility is essential, but I wouldn't mind seeing the protocal it extended to handle stuff that the existing one fails on. The improvements might only work between MushChat clients, but I find it odd that it can't do something as relatively simple as TCP/IP like packet handling, so 'everyone' that is not set as private will see all messages. I would hope that it is smart enough to tack a number onto the second, third or fourth Magnum to connect, but the specs say nothing about it and odds are it doesn't have a decent method to handle that either. :p

All in all, I am becoming less and less impressed by the design, but then I tend to consider something as 'working' only after I have found a way to deal with unexpected problems, not just when it performs the basic task. ;) lol

One more question - say you are hosting chats (ie. listening on port 4050 or whatever). Is this done per world (MUD) or per client?

In other words, if you are connected to 10 different MUDs do you potentially host 10 chat sessions, or one chat session?

Shadowfyr: For example, say you have 5 connections in your list and they all think they're funny guys, so they set their names to "NightCrawler". If you use the /chatall command, your message will be sent to everyone. MM doesn't care how many NightCrawlers are in the list. However, if you try to private chat NightCrawler, your message will go to the first NightCrawler in the list, but not the other 4. At least as far as I've tested it. There may very well be some kind of random UID. When some of my friends come online later (lazy slobs), I'll run a few tests and let you know the result. Again, my apologies if I misunderstood your post.

Nick: That's a good question and one that's never occurred to me, so I ran a quick test on both the console version and MM2k. Both versions returned the same result...

On a second workstation, I launched MM and started two sessions (MM's equivalent of Worlds as far as I understand them) and set the both to listen on port 4050 (which they do by default). I then attempted to connect to those sessions from another workstation...only one session accepts the incoming call. So, it looks like the first client to listen on the port will grab the call before the other one even knows it's there. My workaround for this in MM would be to set one session as a "server only" to which everyone connected to, including myself (from all other sessions).

As a note, MM2k will let you open as many sessions as you like (probably limited only by available system memory) in the same instance of MM2k. However, MM Console doesn't have "sessions", so it requires you to open multiple instances for each "session" you wish to use.

In all fairness, I have to agree with Shadowfyr. There are definitely bugs in MM that should be worked out. The application isn't foolproof. However, I have to consider that MM is a "hobby" that the author does in his spare-time. Both MM and MM2k are coded by different individuals and the original console version is no longer in development at all by the original author (hence the release of the source code).

The random UID is an extension added to zChat. MM does this:

CHAT:<name>\n<ip><port>

while zChat does this when talking to other zChat clients:

ZCHAT:<name><tab><ID>\n<ip><port>

However, from the info I can see in the zChat spec, this <ID> is a randomly generated ID created by the connecting client, so each person being hosted by someone would have their own ID. This means you 'could' tell one user appart from another, but only those people that are connected as zChat users. How exactly this works for displaying the users name in the client or sending private messages, I haven't a clue.

Of course this is based on the specs I got from Nick, so who knows what MM2k may have changed or extended.

I am not really surprised that two instances of MM can't both listen on 4050, but what I mean is, that if you are connected to two MUDs (ie. two sessions) can you host two chat sessions (say using ports 4050 and 4051) or is the chatting session-independent? If so, which session window does it appear in (if that question has any meaning in MM)?

Sorry, I misunderstood the original question. The answer would be yes. You could run multiple sessions and have chat connections in each one, all running on different ports.

So, if I'm connected to MUD A, I can start a chat session on port 4050 and chat with all my MUD A buddies. If I start a second session and connect to MUD B, I can start a second chat session on port 4051 and invite people in. Each chat session would appear in its respective session window, they wouldn't know the other was there unless I chose to serve one session to the other.

You'd just have to be careful to specify the port number for people to call because MM defaults to 4050. If someone from MUD B calls my IP but forgets (or doesn't know) to specify the port, they'll end up in chat session A.

Another question - apparently zChat supports two styles of chat sessions, MM chat and zChat chat, which are completely different because zChat uses a length field whilst MM uses a special terminator of \xFF.

How does zChat know which one to use? I can imagine how on an incoming connection because it will either receive "CHAT:" or "ZCHAT:" directly after the connection is established, but how about for an outgoing connection? Which one does it send?

Is it user-configurable?
Does it send "CHAT:" and if that is rejected follow up by "ZCHAT:"?
Or, some other technique?

I'm afraid I can't help you too much where Zchat is concerned. I don't use it, so I'm not all that familiar with it. From what I understand, Zchat attempts to establish the connection using the "Zchat Protocol" (whatever that is). If that fails because the client is MM, it immediately attempts to reestablish the connection using the MM protocol. I believe there is a setting in the connection properties in Zchat that allows you to designate a connection as "MudMaster User" if you want to skip the Zchat-based connection attempt.

When this happens, I can see it on my chat server as an attempted connection that fails to fully negotiate. It is immediately followed by a second connection that succeeds.

You'll have to consult the documentation for the Zchat protocol (assuming there is any) for the answers. Sorry.

The zChat specs say nothing about how to correctly connect to an MM service, but I think you answered the question anyway. lol The original V1.0 or zChat probably didn't actually support MM, so since no one ever seems to update the original documentation on these things (sort of like Nick and the help file that comes with Mushclient.... lol), the spec for zChat only covers the zChat protocal itself.

Can anyone who is a MM chat expert comment on this?

I am examining the messages generated by MM GUI - when you do a /chatall, and this is what I see:

MM_Nick chats to everybody, 'hi there'

Note the final quote in red. Now in MM, the entire message is in red, because the chat configuration specifies that chats are in red on black. However the generated message is this:

MM_Nick chats to everybody, 'ESC [0mhi there ESC [1m ESC [31m'

Note how MM specifies red for the final quote (ESC [ 31 m) but not for the initial part of the message. Is this not a bit strange? If you are going to colour some of the message shouldn't you colour all of it? Otherwise the first quote is in the receiver's chat colour, and the final quote is in the sender's chat colour, which are not necessarily the same. Am I missing something here?

Another question about chat...

Would you expect that if someone tried to connect to my chat port the client would automatically accept it (as MM 2000 seems to) or that you would be queried, or have the option to do either?

eg. A message box: "Magnum is trying to connect for a chat from 192.3.4.5 - Accept?" Yes/No

> Note the final quote in red. Now in MM, the entire message is in red, because the chat configuration specifies that chats are in red on black.

This is a bug of mud master (and its spec). I can't really see a way around it if your implementing the spec. To get around it my chat alias sends an emote like below.
/EMOTEALL chats to everybody, @AnsiReset()@ForeWhite()'@AnsiBold()@ForeWhite()$ChatText@AnsiReset()@ForeWhite()'



> Would you expect that if someone tried to connect to my chat port the client would automatically accept it (as MM 2000 seems to) or that you would be queried, or have the option to do either? eg. A message box: "Magnum is trying to connect for a chat from 192.3.4.5 - Accept?" Yes/No

State Issues in a telnet application :), thats a new one.


Nick are you adding chat to the next ver of MUSH?
E.G. Can/should I abandon the dll/plugin...

Skars

Hello again,

Both MMC and MM2k allow users to define the chat text background and foreground colors (/chatback <0-7> and /chatfore <0-15>) but these changes will only affect the local client. By default, the color scheme is red on black and I suspect that most leave the default scheme as is. If, however, you changed the forecolor to, say, light cyan (/chatfore 11) the change would only be apparent to you. I would still see red on black.

You can change the color of the actual message you send using a script similar to this:

/alias {ch %0} {/chatall @AnsiBold()@ForeCyan()$0@AnsiReset()} {Optional Group Name}

This would still cause your name and the "chats to everybody" parts to appear in the default /chatfore color, but your actual message content would appear in Bright Cyan. The @AnsiReset() at the end of the line returns the color to the default, so the closing quotation mark would again appear in the default color.

This is the most basic example of a colored chat alias, since as I mentioned previously, some people like to be creative and use /emoteall instead.

As for accepting connections, both MMC and MM2k default to autoaccepting incoming calls but this can be toggled off using /autoaccept <on/off>.

Useless tip of the day: If you want to use multiple words in your chat name, simply enclose them in { }. ie /chatn {MM Nick}.

Edit I: I should mention that MM is case-sensitive, so if you attempt to use the sample code above, make sure you type it as I did. @AnsiBold() is not the same as @ansibold() or @ANSIBOLD().

Edit II: If you need a test environment, I can probably set up a temporary chat server here for you to play around on and run a few tests. Might give you an opportunity to concentrate on the client end of things for awhile. Just let me know. I have the luxury of working from my own home, so I'm almost always here (except when I'm not). I don't want to make a public server, tho, so I don't wanna post my IP to the board. But I'm sure Nick can dig up my email address if he needs it :)

I have read the entire thread. Being a programmer, i have a very important question to ask. What's zChat?

Zchat is an optional plugin for Zmud. It functions as a stand-alone chat client or, with the registered version of Zmud, will fully integrate. It adds chat functionality to Zmud and allows communication with MudMaster's native chat client.

So the chat text goes in the MUD window?

Zchat text only appears in the MUD window if you have a registered version of Zmud. Otherwise, Zchat functions independantly as a stand-alone chat client and chat text appears in the Zchat window.

Yes I am working on that, your earlier posts prompted me to get on with it, as a chat system is obviously wanted by at least some users. :)

Because I haven't used chat in the past myself I am unsure exactly how their implementations work, as I obviously want to be compatible with zChat/MM chat, so that you can play in a mixed client environment.

NightCrawler, I will probably take up your offer of testing shortly, at least you can tell me if my system doesn't work the way you are used to.

Can someone explain how groups work in chatting? There is a CHAT_TEXT_GROUP command which seems to indicate you send a message to a named group. But how do you get into groups?

Is it the sender's responsibility to put people into groups, and then only send to the group, or the receiver's responsibility to know if they are in that group or not?

> Yes I am working on that, your earlier posts prompted me to get on with it, as a chat system is obviously wanted by at least some users. :)

Sweet, abandoning chat dll :). For the record I did have the basics (chat/emote/peek/request) working compiled and wrapped in an install kit ready to be shipped to testers...

> Because I haven't used chat in the past myself I am unsure exactly how their implementations work, as I obviously want to be compatible with zChat/MM chat, so that you can play in a mixed client environment.

I would personally be inclined to make it MudMaster compatible (and therefore zChat compatible). But thats mostly because I dislike zChat(zMud) in all its bloated glory...

Skars

Can you tell me what you did for "request connections"?

It seems to me there are 2 IP addresses - the "reported" one from the client, which might be a private address, eg. 10.0.0.1, and the "actual" address which the client connected from, which might actually be the NAT router or somesuch.

Which one did you use? According to the zChat spec (and also the MM spec) you might not know the IP address. Why not? You must have if you made a connection. That tends to imply that it wants the reported IP address and not the actual one.

Groups:

When you have a list of connections MM, you can assign them group names using the /chatgroupset <connection> <group> command. You can then chat to a specific group using the /chatgroup <group> <message> command (which MM will let you abbreviate by typing /cg <group> <message>).

So, I can have two groups of people like Cool People and Uncool People. I can send messages to one group without the other group seeing the message (ie. /cg Cool People The other group sucks!)

The people I have placed it groups won't know that I've placed them into groups. It's simply something I set in my client to help sort my connections into sub-categories.

Requesting Connections:

I'm assuming you were directing your question at Skarsnik, but I'll answer too, since MM has this feature as well.

Imagine that A is connected to B who is connected to C...

If A wants to know who B is connected to, he can /peek B and see a list of connections (assuming B hasn't marked them as Private). This will show A the name of the person(s) B is connected to as well as their IP addresses.

If A wants to talk to C, he now has two options: Ask B to serve either A or C so they can communicate indirectly, or A can /requestconnects B and attempt to automatically establish a connection to C. Basically, /request is the same as manually calling an IP except MM does the work for you.

You may already have this info, but I'll paste it here anyway. It reiterates some of the topics we've already discussed and may help to explain some of them further. It may also explain some of the features we haven't yet discussed. This is from the MM Help file on Chat:

=====
Part One:

Mud Master chat allows you to establish a site to site link with another MM
user. Once you have a connection you are able to talk with any or all of your
chat connections, transfers commands (actions, aliases, variables, etc...),
and transfer files. Site to site means the clients are connected directly.
Often you will experience less lag using MM to chat than you would talking to
the same person through a mud.

Before you connect to anybody you need to set your chat name. Everybody you
connect to will see this name when you talk. The command is:
/chatname {chat name}.

To start a chat with another person you use the call command and their network
address. Call will accept both IP address and named address. You can see your
IP address in MM in two ways. First, you can type /info. Second, you can use
the procedure @IP(). Example: tell arithon My address is @IP(). Once you know
another user's ip address use call to connect to them. /call 204.120.248.148

Sometimes MM will be unable to reach an IP address when you /call. This is
usually because the person you are trying to call has a firewall. A firewall
prevents remote systems from connecting to an internal network. If you cannot
connect to somebody have them try to call you instead. If you still cannot
connect to each other you may both be firewalled. You can still chat if you
can both connect to another person who is willing to be a chat server for you.

An easy way to get connected with a group of people already chatting is to use
/requestconnects {name/number}. Once you connect to a user, you can request
all of their chat connections with this command. MM will then try to connect
you with all of the other user's connections. Only public connections are
returned when somebody requests your connections. If you don't want people to
see some of your connections, flag them as private.

There are several things that can happen when a chat call comes in. You can
prevent people from connecting to you by using the DND (Do Not Disturb)
command. When a call comes in DND is checked, if it is on, the chat connection
is hung up on without interrupting you. /dnd will toggle the option on and
off. You can see the DND status by using /info. Autoaccept also affects how
incoming calls are handled. If you have autoaccept off you will be prompted to
accept the call when it comes in -- this will pause your mudding until you
press Y or N. If you leave autoaccept on chat calls get accepted without
prompting you. You can see the status of autoaccept with /info.

=====

=====
Part Two:

/Chat will show you all the chat connections you have. It also shows you some
status flags associated with the different connections. The flags and a
description of them are listed below. If you are transferring a file thru a
chat connection, the chat name color will change. If the name is blue, you are
receiving a file, if it is green, you are sending a file.

A - You are allowing that chat connection to transfer commands to you
(aliases, actions, variables, etc...). /chatcommands {name/number} will
toggle this flag.
F - Means that chat connection is behind a firewall.
I - You are ignoring that chat connection. You will not see any chats or
name changes from that person. /chatignore {name/number} will toggle
this flag.
P - Private connection. Connections marked as private are not given out
when somebody requests your chat connections. /chatprivate
{name/number} will toggle this flag.
S - You are serving this connection. When serving, /chatalls coming from
people not being served are sent to those you are serving -- text from
those being served is sent to all of your other connections.
/chatserver {name/number} will toggle this flag.
T - Allow transfers. You are allowing file transfers from this connection.
/chattransfers {name/number} will toggle this flag.

To talk with a specific connection you use /chat. /chat {chat name/chat number}
{text}. Like with the other lists you can use either the name of the
connection, or the number you see when you list your connections with /chat. To
talk with all of your connections at the same time use /chatall {text}.

You can also group chat connections and talk just to that group. Use
/chatgroupset {name/number} {group name} and /chatgroupremove {name/number} to
set and remove group names from a chat connection. Once you have people grouped
you talk to the group with /chatgroup {group name} {text}. You can also use /cg
as a shortcut for /chatgroup.

Emoting on the chat channel works very similar to the commands used for
chatting. /emote, /emoteall, and /emotegroup. When you emote you chat name and
the text you emote is sent to the chat connection. /emoteall licks you would
send "{Chat Name} licks you." to all your connections.

To hang up on a chat connection use /unchat {name/number}.

If you want to send commands to another chat connection you have to first get
them to enable the reception of commands from you with /chatcommands. Once they
have flagged you able to send commands you can use the following to send them:
/sendaction, /sendalias, /sendarray, /sendbaritem, /sendevent, /sendgag,
/sendhighlight, /sendlist, /sendmacro and /sendvariable. If you want to send a
group of commands use /sendgroup. When you send a list or array, all the items
belonging to the list or array are transfered as well.

To send files through a chat connection you have to get the chat the other
party to flag with allow transfers. Use /sendfile to transfer files. Both
users are notified when a file transfer has been started and notified again
when the transfer is complete. You can check the status of a file transfer with
/filestatus {name/number}. The {name/number} refers to the chat connection, not
the name of the file being transferred. /Filecancel {name/number} will cancel a
file transfer in progress.

/ChatBack and /ChatFore can be used to change the default colors of the chat
text.

/ChatVersions will show you the version of MM that each of the chat connections
is using.

By default when you start up MM it will listen for chat calls on port 4050. You
can tell MM to listen to an alternate port if you want. You can only change the
listen port when you first run MM, using a command line parameter.
"mudmast L:port num" will cause MM to listen to a specific port.
"mudmast L:4000" will cause MM to listen to port 4000. You can see what port MM
is listening to with /info. /call uses port 4050 by default as well. If you
change the port that MM is listening to you will have to let people know which
port number to call

=====
End of File

I should add, finally, that the above HELP file hasn't been updated since the original MM Console version. While all those commands are still available in the GUI release, much of it is also point'n'click now so users can use the input bar or a mouse. Also, extra commands have been added.

Finally, regarding the last paragraph of the file concerning changing ports: you can change ports on-the-fly in MM2k. You simply need to stop and restart the chat server to enable listening on the new port.

Enough spam for awhile...

NightCrawler

When you are asked for connections (request connections) do you supply yourself?

eg. If A is connected to B and C

B asks A: request connections

Does A reply with B and C, or just C (after all B knows he has a connection, after all, that is what he just used).

You only see the other connections (that aren't marked private), you don't see yourself. This is true whether you're just peeking at the connection or whether you request them.

I am having trouble testing zChat - for one thing I can't work out how to change the port number from 4050, and for another it keeps crashing with an access violation. Does anyone else have better luck them that with zChat?

Hmm, sounds to me like the MudMaster protocol sucks... I haven't followed the entire thread, so I'm talking out of my behind, but that's the idea I got... Would it be possible to make your own protocol, and only make it compatible with MudMaster? I.e. it would probe the client/server when it connected, and it would switch protocols accordingly... Of course, this may not be needed, if you feel that mudmaster is OK... Just an idea...

> Hmm, sounds to me like the MudMaster protocol sucks... I haven't followed the entire thread, so I'm talking out of my behind, but that's the idea I got... Would it be possible to make your own protocol, and only make it compatible with MudMaster? I.e. it would probe the client/server when it connected, and it would switch protocols accordingly... Of course, this may not be needed, if you feel that mudmaster is OK... Just an idea...

Yeah, develop your own chat, then make also add MudMaster and zChat chat protocol aswell.

And then (THIS IS THE GOOD BIT) the next person who writes a chat application will have to support all three and their new one!

Skars

> I am having trouble testing zChat - for one thing I can't work out how to change the port number from 4050, and for another it keeps crashing with an access violation. Does anyone else have better luck them that with zChat?

I have the similar issues with zChat, which is one of the reasons I wrote a mm compatible chat (and let zChat can resolve its own issues).

> It seems to me there are 2 IP addresses - the "reported" one from the client, which might be a private address, eg. 10.0.0.1, and the "actual" address which the client connected from, which might actually be the NAT router or somesuch.

MM GUI has a simple approach to this, if the machine has more than one IP it asks the user to select the appropriate IP. When you establish a connection you send your (manually selected) IP information in the handshake, (so the recieving chat application does not have to attempt to resolve the new connections IP). It does work, but I guess it could be improved.


Skars

N.B. These questions might have previously been answered, I avioded the essay messages.

> And then (THIS IS THE GOOD BIT) the next person who writes a chat application will have to support all three and their
> new one!

Except that since neither MM or zChat specifically mandates that you hold commands ID numbers open for expansion, you can simply extend the command set for the one you are using. The new clients would see and respond to the new commands, but regular MM or zChat programs would likely just ignore them. It then becomes the next guys decision as to whether to support the original MM spec, what ever extensions may have already been added to MM2k or go all the way and also support yours.

This is not imho a major problem. Most of the flaws in the existing protocal are ones that could be fixed by using such an extended command to test if it is a compatible client and use the extended commands to send text with proper coloring, etc. If the client doesn't support it, then you default to the 'existing' command set that you already support as part of your own spec. Not compatibility issues would arise, since the only thing you could break is the extended set of commands you added anyway. I believe I mentioned this already in the thread actually.

This thread, which will soon take the prize as the longest one on the forum. ;-)

I think what Poromenos was getting at was, have your own protocol, even if it was similar, and then have it figure out what kind of client it was communicating with, and then 'talk down' to that client.

That wouldnt require the next coder to make it compatible with all three, Just any one. Since this client would be able to communicate it, as if it were MM, or zChat.

Example:
User X makes a client, that is compatable with MM and zChat, then connects to a chat... bunch (web?) and eventually talks to someone on MushChat, the Mushchat will do the handshake and stuff, and see that Xclient talks like MM, so as far as MushChat is concerned, XClient is MM, and can communicate that way.

Think that made sense.

I'm still wresting with message loops. According to the MM chat spec, for a CHAT_TEXT_EVERYBODY:



Now say you have three connections:

A -> called -> B -> called -> C -> called -> A

This is certainly possible.

Now according to the spec if A does a "chat all" then the message goes to B who sends it to C. However C does exactly the same thing, and sends it to A, who then sends it to B again, and so on.

In fact, I can reproduce that in MUSHclient with only 2 connections, A and B. If A calls B and B in turn calls A, then you do a chatall, then you need to abort the client before it runs out of memory.

I notice in the zChat they have message stamps, so you can tell when a message has been around the loop, something that is not in the MM spec.

I can work around it to an extent by remembering the last message sent, and decline to send the same message twice in a row. However this then has the problem that you can't send the same message twice legitimately. For instance, you might be telling someone which way to walk, and saying "north" twice might be part of the directions.

Can anyone think of a better way, but still working within the MM chat specs?

I was just looking at the message regarding potential "loops" in the conversation. Specifically, where Nick has indicated that if A calls B and B calls A.

This doesn't actually happen in MM. If you attempt to call a connection that you've already established a session with, MM sends you a message letting you know you're already connected to that client. It won't establish a second connection to the same client.

The only exception would be on a network. I could call a client using it's public address and then call it again using it's private address and establish two connections to the same session. MM has no way of knowing that they're actually the same computer since the IPs (and MACs) are different.

Regarding Zchat, I've played with it a few times but could never find a way to change the port number either. Perhaps that feature is only available if it's used in conjunction with a registered version of Zmud.

As for the Access Violations in Zchat/Zmud, I'm going to hazard a guess that you're using it on an NT-based system (Win2k, XP). Zchat apparently tries to access a protected system file (or files) or memory address range for some reason and returns this error when the operating systems says, "Hands off!" The person who wrote Zchat is aware of the problem, but doesn't seem to be too interested in fixing it. His loss, I suppose. Perhaps he'll regret his thinking when his customers start switching to MM and MushClient :)

> I was just looking at the message regarding potential "loops" in the conversation. Specifically, where Nick has
> indicated that if A calls B and B calls A.
>
> This doesn't actually happen in MM. If you attempt to call a connection that you've already established a session with,
> MM sends you a message letting you know you're already connected to that client. It won't establish a second
> connection to the same client.

Which is irrelevant, since the problem is when a third client connects to the first one. I read somewhere something about how such loops can and do happen and it represents one of the 'major' flaws in the design. A good one would pass the IP of the originator in the packet 'and' a time stamp, just like TCP/IP does and the various clients involved would simply ignore those with the same stamp. Neither MM nor zChat effectively deal with this. Extentding the protocal so that Mushclients version could identify each other and use a seperate set of commands to talk to one another that includes such an ID is imho the only way to really fix it. However, that only fixes it for the Mushclient users, but it is the best that can be managed until the MM2k people or Zugg impliments a similar 'fix' in zChat.

MM and zChat are both buggy 'period'. Extending one of the protocals with special 'working' versions of the command set of one of them would solve all these problems and still allow the basic protocal to work.

Going back a few more messages... Yes Flannel, I get what you mean, but my point is that it is a 'bad' solution to make a completely new protocal like zChat did and then 'support' the old one. Instead you allow the commands 1-31 that 'are' part of the MM protocal to work as normal, but then add commands like 100, 101, 102, etc. that implement the fixes and extended capabilities. This is how you provide real compatibility 'and' also fix the problem. When a copy of Mushclient connects to something it would start with the normal MM or zChat request, then when established it would d something like <100><Muclient?><chr 255> and the other one 'if' it was MM or zChat would ignore the command. If it was Muclient compatible, then it would return <100><Yes><chr 255>, at which point they talk to each other using the 'fixed' command set in the 201-231 range. The next guy to make a client doesn't need to worry about supporting the extended set if they are satisfied with what the normal MM set can do, but yes, to be fully compatible, they would need to add the extensions as well.

> The person who wrote Zchat is aware of the problem, but doesn't seem to be too interested in fixing it.

This seems to be a common theme with Zugg. lol

> When a copy of Mushclient connects to something it would start with the normal MM or zChat request, then when established it would d something like <100><Muclient?><chr 255> and the other one 'if' it was MM or zChat would ignore the command.

Im all for extending the protocol, but...
There is already a command in the spec to identify the chat application that is sent immediatly after the handshake by both zChat and MudMaster.
e.g. <19>MUSHchat 1.1.0<255>


> I notice in the zChat they have message stamps, so you can tell when a message has been around the loop, something that is not in the MM spec.

I think this has been covered but, zChats message stamps only provide the callers unique ID, which will NOT totally solve the problem (as you can still get echos because someone is served by two people your chatting to ect...).

The only work around that I can think of that will totally solve any echo/terminal loop problems would be to provide a Unique (randomly generated) ID for each *message*. Each client would then need to store a list of reciently recieve message ID's and as soon as it gets a repeat it will not display the message or pass the message on again if its serving someone).

This wouldn't be as bad as it sounds as the client would really only need to store the UID's of the last 20 or so messages...

Once again I personally think if your commited to the basic basic protocol this should come first, and then think of how to improve it.

Skars

Yes, I am using NT, and I would think a few others are as well, as NT now embraces Windows 2000, XP etc.

I want to work within the existing protocol initially, although I see that my spec must be a bit out of date, as it doesn't mention a 4-digit number that appears at the start of peeked text.

I seem to have solved the loop problem for now, by remembering the last message *sent*, and then discarding that message if it is *received* again in the next 10 seconds.

Hopefully in many cases people won't have loops anyway, however I can certainly conceive of how they could be set up, especially if you "request connections".

Testing seems to be going well, a bit more work needed on doing a scripting interface, and then it will be ready for a user test.

Will many people here be interested in:

* snooping other connections?
* transferring files?
* sending commands?

I also see a potential problem with the colouring of messages, but perhaps will let that come out in the testing *evilgrin*.

> > When a copy of Mushclient connects to something it would start with the normal MM or zChat request, then when
> > established it would d something like <100><Muclient?><chr 255> and the other one 'if' it was MM or zChat would
> > ignore the command.

> Im all for extending the protocol, but... There is already a command in the spec to identify the chat application that
> is sent immediatly after the handshake by both zChat and MudMaster.
> e.g. <19>MUSHchat 1.1.0<255>

Only one problem... If this was a true 'extension' of an existing protocal, then the existing MM or zChat clients, that you used as a 'base' for the extended version, would be looking for a version ID that was like "<19>MudMaster 1.1<255>" or "<19><9>zChat 1.1". Existing clients would not therefore correctly recognize any version you gave them with MUSHchat in it as valid, which is why imho it would be better to use a seperate request.

The method of detecting the different protocols is AFIK the initial negotiation, where you either get CHAT: or ZCHAT: as the very first character sequence received.

The actual version is just for information and the first few characters could conceivably be used to detect which client is actually in use.

However I don't think this talk of extending the protocol really solves the problem of message loops, especially where it is likely to be in a mixed client environment. For instance, if MUSHclient has to send a message to MudMaster, then it must use the existing protocol, and conceivably a loop of MUDMaster clients might exist.

True, but not extending it doesn't fix it either. In the short term I agree that it is best to use the un-extended version, but it would be nice to make it more stable and less buggy when everyone connected is a Mushclient user later on.

> Only one problem... If this was a true 'extension' of an existing protocal, then the existing MM or zChat clients, that you used as a 'base' for the extended version, would be looking for a version ID that was like "<19>MudMaster 1.1<255>" or "<19><9>zChat 1.1". Existing clients would not therefore correctly recognize any version you gave them with MUSHchat in it as valid, which is why imho it would be better to use a seperate request.

MudMaster MudMaster2000 and zChat (at least the version I have) does not use the <19> information appart for display purposes.


> However I don't think this talk of extending the protocol really solves the problem of message loops, especially where it is likely to be in a mixed client environment. For instance, if MUSHclient has to send a message to MudMaster, then it must use the existing protocol, and conceivably a loop of MUDMaster clients might exist.

Nick they wont let you re-write zChat and MudMaster, you could ask, but im pretty sure you will be ignored :()


Skars

I've been trying to say I don't want to change the protocol, or do my own. I want to work smoothly in a mixed-client environment. So far my testing seems to show this is being achieved, bearing in mind I can't test zChat because of access violations etc.

However since it is supposed to support MM protocol that should be good enough.

I think I have the loop problem in hand, and within a day or so will be ready for some enthusiastic testers. ;)

Well, it is here at last! :)

Version 3.37 of MUSHclient is released with the initial implementation of the chat system. It is pretty comprehensive, including:

• Make calls
• Accept calls
• Validate incoming calls
• Chat to one or many
• Emote to one or many
• Snoop another user
• Send/receive files
• Send commands
• Comprehensive script interface, so you can script chat sessions to your heart's content
• Send chat messages from within scripts, triggers, aliases, timers and so on
• Use plugin callbacks to filter incoming chat messages and react to them appropriately
• Ping other users to see how fast the connection is
• Chat with MudMaster and zChat users

A detailed description of the chat system can be found at The MUSHclient Chat System.

The chat improvement was achieved with a minimal amount of bloat, by the way. The download size of the MUSHclient installer has only increased from 1.17 Mb to 1.19 Mb.

This compares somewhat favourably to other clients which I could name, but won't. However to give you the general idea ...

• Client A
  Main download: 6.93 Mb
  Chat plugin: 0.67 Mb
  Required database files:
  
  • MDAC 2.7 SP1 - 5.14 Mb
  • JET 4.0 SP3 OLEDB - 3.51 Mb
  • JET 4.0 SP6 - 2.88 Mb
  
  
  Add that all up and you need 19.13 Mb to install this client. (Of course, you don't need to re-download the database files every time you upgrade, but the main client is still 6.93 Mb).
  
• Client B
  Main download: 0.87 Mb
  Required DLLs: 1.25 Mb
  Total size: 2.12 Mb
  
• Client C
  Main download: 10.7 Mb
  
• Client D
  Main download: 3.04 Mb
  

You rock! Keep up the awsome work. Because of you I can get into "trouble" at work for Mudding, luckily my boss muds also :)

I dont know if its just me, but i cant seem to be able to send commands to anyone who is allowing it.. Has anyone else had any problems with this? Other than that everything seems to work great. Thanks Nick! If i only knew how to configure it better. :p

Something else i just noticed is the #request command doesnt work, and that it seems that everyone connects to you served.. not so sure if thats a good idea or not.. also.. when you try and call someone it seems to look for them on a chat server instead of going right to that IP address?

The command sending will probably only work if MUSHclient is at both ends. It uses a command number 105, which is a zChat command number, not a MudMaster command number.

There is a bug in IP resolution, see the other recent post about that.

Sorry, I misunderstood your post. #request should work, and they should not be marked as served. I'll have to check that. However conceivably in your case it is related to the earlier bug, which resulted in connecting to the wrong IP address.

Hi,

I'm back after some problems with my ISP (got busted running servers...oops) and I was checking the status of the MUSHclient chat plug-in. I see the beta has been released to favorable response (minus a few bugs?). Nice, congrats!

I took a few minutes to browse through the new online "user's guide" for the chat plug-in too. I'm impressed. Every feature (as a MM user) seems to have been implemented including a few "bonus" features. I like the file checksum idea...and the detailed info you can retrieve on specific users is nice too.

Unfortunately, I haven't had time to test drive the client yet, but once I get my "situation" resolved with my ISP I'll toss in my two-cents for giggles.

Now, if you can make my MM scripts compatible with MUSHclient, I may even consider a permanent switch. I'm guessing that's too much to ask for, though...hehe.

Regards,
NightCrawler

I am currently working on a GUI interface to the chat system - should be available shortly.

Nick, what exactly does GUI mean in this case?

Just another Options Tab for changing options/user stuff? or.. what?
As I dont think youre writing a zChat type thing (and dont take that as suggestion if you arent), so, whats the GUI going to be like? Just an additional toolbar? know

First, there is one more configuration tab in the main world configuration system. This is for general chat configuration, for things like:

• Your chat name, eg. "Nick"
• Whether you are accepting incoming calls, and if so, on what port
• What colour you want chat messages in
• What to prefix each chat message with, eg. "<CHAT>"
• Limits on message size
• Whether to automatically accept files
• What directory to save files in

Then there is a general "current chat sessions" screen that is used to view the current status of the chats you are currently connected to. This will list each connection, and let you:

• View or change their status (eg. allow snooping, allow file transfers)
• Do various actions to that connection (or multiple connectios), such as ping, snoop, send a file, chat, emote, peek connections, request connections
• Hang up one or more connections
• Chat or emote to all
• Make a new call

Basically the GUI interface lets you use the chat system from a user-friendly dialog-box based system, which means you don't need the chat plugin if you don't want it.

However the chat plugin will let you do chats from the command window, without having to bring up, and dismiss, dialog boxes all the time. I would expect frequent users to learn a few commands rather than use dialogs.

However the main configuration screen certainly lets you view and change the chat configuration with a minimum of fuss.