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

NC99 USA (17 posts)

Date

Mon 19 Aug 2002 03:31 AM (UTC)

Message

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?

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

NC

Posted by

Nick Gammon Australia (22,975 posts)

bio Forum Administrator

Date

Reply #1 on Mon 19 Aug 2002 06:21 AM (UTC)

Message

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?

- Nick Gammon

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

Posted by

Dubthach (47 posts)

Date

Reply #2 on Mon 19 Aug 2002 01:47 PM (UTC)

Message

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.

Posted by

Shadowfyr USA (1,786 posts)

Date

Reply #3 on Mon 19 Aug 2002 08:52 PM (UTC)

Message

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.

Posted by

Magnum Canada (580 posts)

Date

Reply #4 on Mon 19 Aug 2002 10:39 PM (UTC)

Message

Exactly what Dubthach said.

Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.

Posted by

Shadowfyr USA (1,786 posts)

Date

Reply #5 on Mon 19 Aug 2002 11:47 PM (UTC)

Message

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.

Posted by

NC99 USA (17 posts)

Date

Reply #6 on Tue 20 Aug 2002 12:20 AM (UTC)

Message

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

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

NC

Posted by Magnum Canada (580 posts) bio

Date Reply #7 on Tue 20 Aug 2002 12:26 PM (UTC)

Message

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.


Name: MU Instant Messanger
IP  : 127.0.0.1
Port: 9001

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:


[AOD PK Clan] Magnum: Where is Kagehi? He's bountied and I want to kill him!
[AOD PK Clan] Sparhawk: Forget it, he's hiding in his house.
[MARENTHA Rogue] Magnum: Anyone know where to find a healing potion?

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"?

Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.

Posted by

Shadowfyr USA (1,786 posts)

Date

Reply #8 on Tue 20 Aug 2002 08:34 PM (UTC)

Amended on Tue 20 Aug 2002 08:36 PM (UTC) by Shadowfyr

Message

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

Posted by Magnum Canada (580 posts) bio

Date Reply #9 on Wed 21 Aug 2002 01:25 AM (UTC)

Message

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:


- IM Program recieves text message from the internet.
- IM Formats line preamble, postamble. (Eg: "AOD Clan: ")
- IM sends line to local port.
- MUSHclient recieves line on local port (just like it would from a mud)
- MUSHclient outputs line to output screen of world who is configured to that local port.
- MUSHclient user, who has configured "~" for IM messages, types "~Who needs blade poison?"
- MUSHclient sends that string (minus the prefix 'alias' of "~") to local port.
- IM recieves string on local port.
- IM Sends string to internet.

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.

Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.

Posted by

Magnum Canada (580 posts)

Date

Reply #10 on Wed 21 Aug 2002 01:33 AM (UTC)

Message

Quote:

The world never sends anything to second port except when explicity instructed via a user configurable 'alias' (character).

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

Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.

Posted by

Shadowfyr USA (1,786 posts)

Date

Reply #11 on Wed 21 Aug 2002 01:56 AM (UTC)

Message

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.

Posted by

Nick Gammon Australia (22,975 posts)

bio Forum Administrator

Date

Reply #12 on Wed 21 Aug 2002 02:33 AM (UTC)

Message

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?

- Nick Gammon

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

Posted by Shadowfyr USA (1,786 posts) bio

Date

Reply #13 on Wed 21 Aug 2002 06:09 PM (UTC)

Amended on Wed 21 Aug 2002 06:26 PM (UTC) by Shadowfyr

Message

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:


512 File send request:
  Same as existing spec.
513 File Deny:
  Same as existing spec.
514 File Block Request:
  Same as existing spec.
515 File Block:
  Sends an incremental CRC as the first 2 bytes, which
  is checked by the CRC computed in mushclient, from the
  previous CRC and the data in this 1024 byte (1026
  counting the CRC) packet.
515 File Cancel:
  Same as existing.
516 File Resend From:
  Sends a block number to restart from, when a CRC fails.
  This also provides (in theory) the means to store the
  file name, current CRC and block number, so one can
  continue downloading later, but that is probably not
  needed.

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.

Posted by

NC99 USA (17 posts)

Date

Reply #14 on Thu 22 Aug 2002 01:18 PM (UTC)

Message

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.

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

NC

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.

191,134 views.

This is page 1, 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 )