Gammon Forum : MUSHclient : Plugins : Any way to make a 'chat' plugin?

Register forum user name Search FAQ

Gammon Forum

Entire forum

MUSHclient

Plugins

Any way to make a 'chat' plugin?

Any way to make a 'chat' plugin?

It is now over 60 days since the last post. This thread is closed. Refresh page

Pages: 1 2 3 4 5 6 7

Posted by Shadowfyr USA (1,786 posts) bio

Date

Reply #15 on Thu 22 Aug 2002 06:16 PM (UTC)

Amended on Thu 22 Aug 2002 06:19 PM (UTC) by Shadowfyr

Message

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:


Connect me!
wait....
connected.
'You chat'-
  send to IP of server.

While zChat does this:

Connect me!
wait....
connected.
Request IPs.
'You chat' -
  if connected to original IP
    send to IP you connected to.
  else
    send/connect back to all IPs the client requested??

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. ;)

Posted by

NC99 USA (17 posts)

Date

Reply #16 on Fri 23 Aug 2002 09:40 PM (UTC)

Message

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

Im a minster of death...Praying for war!

NC

Posted by

Shadowfyr USA (1,786 posts)

Date

Reply #17 on Fri 23 Aug 2002 10:52 PM (UTC)

Message

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.

Posted by

Nick Gammon Australia (22,988 posts)

bio Forum Administrator

Date

Reply #18 on Wed 28 Aug 2002 01:18 AM (UTC)

Message

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.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Shadowfyr USA (1,786 posts)

Date

Reply #19 on Wed 28 Aug 2002 02:29 AM (UTC)

Message

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.

Posted by

Skarsnik (11 posts)

Date

Reply #20 on Mon 31 Mar 2003 01:32 PM (UTC)

Message

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...

Posted by

Shadowfyr USA (1,786 posts)

Date

Reply #21 on Mon 31 Mar 2003 07:16 PM (UTC)

Message

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. :(

Posted by

Skarsnik (11 posts)

Date

Reply #22 on Wed 02 Apr 2003 11:08 AM (UTC)

Message

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

Posted by

Nick Gammon Australia (22,988 posts)

bio Forum Administrator

Date

Reply #23 on Wed 02 Apr 2003 11:17 PM (UTC)

Message

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

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Nick Gammon Australia (22,988 posts)

bio Forum Administrator

Date

Reply #24 on Wed 02 Apr 2003 11:19 PM (UTC)

Message

Quote:

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*.

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

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Nick Gammon Australia (22,988 posts)

bio Forum Administrator

Date

Reply #25 on Wed 02 Apr 2003 11:53 PM (UTC)

Message

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* :)

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Shadowfyr USA (1,786 posts)

Date

Reply #26 on Thu 03 Apr 2003 01:16 AM (UTC)

Amended on Thu 03 Apr 2003 01:22 AM (UTC) by Shadowfyr

Message

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.

Posted by

Shadowfyr USA (1,786 posts)

Date

Reply #27 on Thu 03 Apr 2003 02:18 AM (UTC)

Message

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. ;)

Posted by

Nick Gammon Australia (22,988 posts)

bio Forum Administrator

Date

Reply #28 on Thu 03 Apr 2003 02:37 AM (UTC)

Message

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?

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Shadowfyr USA (1,786 posts)

Date

Reply #29 on Thu 03 Apr 2003 07:09 PM (UTC)

Amended on Thu 03 Apr 2003 07:11 PM (UTC) by Shadowfyr

Message

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.

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

192,302 views.

This is page 2, subject is 7 pages long: 1 2 3 4 5 6 7

It is now over 60 days since the last post. This thread is closed. Refresh page

Go to topic: Search the forum

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Comments to: Gammon Software support
Forum RSS feed ( https://gammon.com.au/rss/forum.xml )