Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Due to spam on this forum, all posts now need moderator approval.

 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 Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #30 on Thu 03 Apr 2003 08:57 PM (UTC)
Message
Quote:

However, yes they can 'all come in on the same port'. Otherwise the programs would never work.


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?
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Shadowfyr   USA  (1,792 posts)  Bio
Date Reply #31 on Thu 03 Apr 2003 09:57 PM (UTC)

Amended on Thu 03 Apr 2003 09:58 PM (UTC) by Shadowfyr

Message
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.
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #32 on Thu 03 Apr 2003 10:24 PM (UTC)
Message
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. :)
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Shadowfyr   USA  (1,792 posts)  Bio
Date Reply #33 on Thu 03 Apr 2003 10:34 PM (UTC)

Amended on Thu 03 Apr 2003 10:37 PM (UTC) by Shadowfyr

Message
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.
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #34 on Thu 03 Apr 2003 10:49 PM (UTC)
Message
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?
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #35 on Thu 03 Apr 2003 10:59 PM (UTC)
Message
MudMaster seems to default to port 4050.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Skarsnik2   (1 post)  Bio
Date Reply #36 on Thu 03 Apr 2003 11:43 PM (UTC)
Message
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...


Top
Posted by Skarsnik   (11 posts)  Bio
Date Reply #37 on Sat 05 Apr 2003 05:11 AM (UTC)
Message
(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

Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #38 on Sat 05 Apr 2003 06:04 AM (UTC)
Message
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. :)
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Shadowfyr   USA  (1,792 posts)  Bio
Date Reply #39 on Sat 05 Apr 2003 07:56 AM (UTC)

Amended on Sat 05 Apr 2003 07:57 AM (UTC) by Shadowfyr

Message
>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.
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #40 on Sat 05 Apr 2003 08:33 AM (UTC)
Message
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.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by NightCrawler   Canada  (16 posts)  Bio
Date Reply #41 on Sat 05 Apr 2003 04:57 PM (UTC)
Message
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

A computer once beat me at chess, but it was no match for me at kick-boxing...
Top
Posted by Shadowfyr   USA  (1,792 posts)  Bio
Date Reply #42 on Sat 05 Apr 2003 08:51 PM (UTC)
Message
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.
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #43 on Sat 05 Apr 2003 09:01 PM (UTC)
Message
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.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by NightCrawler   Canada  (16 posts)  Bio
Date Reply #44 on Sun 06 Apr 2003 03:19 AM (UTC)
Message
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
A computer once beat me at chess, but it was no match for me at kick-boxing...
Top

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.

301,416 views.

This is page 3, subject is 7 pages long:  [Previous page]  1  2  3 4  5  6  7  [Next page]

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

Go to topic:           Search the forum

[Go to top] top

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

Home