Anything that come with snippet example in C will be included :p
The only reason my mud support msdp is because of KaVir Snippet. It is easy to plug in, works without a headache, and is very easy to expand/modify for its own need.
Like any good API should be.
This being an external communication channel, the only thing you should have to do to use it is a libray import and use some methods to identify/push/get the text. Nothing else is needed (from the Mud coder point of view). You could even link it to a IRC channel and use the same protocol as well.

Were it only that simple.

What about channel management? Are you tying in with your command system? How are your users dealing with multiple channels, turning them on/off, etc. Where are you saving state… how does your MUD admin configure all of this… are you integrating this with your MUD's internal chat system in terms of channels? what about color codes? etc.

What about channel management?:
-like any other channels, (already have like 10 of them, 1 more 1 less aint making any differences)

Are you tying in with your command system?
-like the other channel, specific command

How are your users dealing with multiple channels, turning them on/off, etc.
-Like the others channel that can be turne on and off

Where are you saving state
-Like the other channels

' what about color codes? '
-That 'could' be tricky but as a matter of fact is only a string substitution problem.

I think 'any' even remotely modern muds have multiple channels, if only for clan. And a 'channel' is basiclaly the easiest thing to add even for beginners, as you basically only have toduplicate the main channel code for it.

Yes I think it is that simple. As a matter of fact, I think any competent C programmer ( I am not) could use the irc protocol. No need to invent something specific for mud when something specifically made for text communication already exist.

The point is not that this is an incredibly difficult problem. The point is that it's difficult to have something that can be just dropped in to any MUD – you need to make changes to tie things together.

My understanding is that the IRC protocol isn't used because a lot of hosts forbid IRC-like servers.

I disagree: every point you made had nothing to do with the new channel itself but only how the mud will handle it for himself. The communication API should be as easy as import <string.h>
Then is your problem how you will use it in your context.


Well mud themselves wont be servers but clients, you only need one server that will host one channel (or more) for all the muds. So it should be easy to get one up. You dont even need to control the server, there are enough IRC servers around. Just need to control one channel, and that can be quite easily done.
It may not achieve 100% reliability, but is that the goal for something that is just an 'added bonus' in the first place ?

I'm sorry, that makes no sense.

If you're talking about something being simple, then "your problem" is exactly how you'll use it in your context.

And no, it's silly to say that communicating with the API is as simple as importing some header file. In all honesty I would suggest you work with this kind of stuff a bit – you describe yourself as not a competent C programmer who hasn't worked with this a lot and yet you're making pretty grand proclamations about how easy all this is.


No. The MUD does not act as a client, it acts as a node on the IRC network. Simple example for why this is: the MUD is not sending messages for one person to one network, but for many people to the network. Again, you need to do your homework. :smile:

Sorry but the only thing a protocol need for communication is identification, and push/pull text.


Be it for one person or a hundred person it is the exact same thing, the mud is only a client that is used by many people at once. Like if you used multiple client in your own computer. And connecting from different account. Exact same thing, and you are still only a client.

Sorry, but really, do you actually know what you're talking about when it comes to how people want intermud protocols to work?

And even if you do want just this, how exactly are you going to tie it into your MUD with a single import statement? It's a little mind-boggling to me that I'm even having to ask this question. :sad:

As for your other bit, you are most certainly not solving the MUD hosts' problem if you're proposing that the MUD open an outgoing connection per user, with the MUD acting as one client per user. The whole point of this discussion, remember, is that MUD hosts don't like people doing stuff with IRC to begin with.

Well you started IRC was a problem as a server, now that is even as a client. May be true, but then why another unknown protocol would be more accepted and not blocked by default.

And for the first thing…what is the problem with stating you only need an import to access an API and that if the API is good enough then identification should not be more than identify(charactername,password) then pushtext(charactername, text, channel/private, (whatever fancy parameter you want)) and every xxx time foreach(charactername, gettext())……..
Really tell me why this should be more complicated to implement in any mud.

A whole protocol like MSDP only takes an hour to implement with Kavir snippet.

I thot this bill was about the climate.

Rarva: yes, intermud connectivity is super easy.

DH: yes, Rarva is missing the point.

Is it can be hugs tiem now?

MSDP isn't a feature-rich, real-world-usable intermud chat network. QED


I've given you any number of reasons, you just wave your hands around by saying it's the same thing as everything, all you need is an #include statement, and that it's the MUD's problem anyhow.

That little thing you say about "whatever fancy parameter you want"? That's more hand-waving – you might find that to be harder than you think.

Well I read from the beginning of the thread and IRC was not reallly mentioned as a 'no way' solution.

The goal for me would be simplicity. I don't see how implementing a functional IRC interface would be simple, not to mention the MUD would have to add support for outgoing connections rather than building on top of MSDP. Using the spider approach someone can in fact create a spider that links MUDs to an IRC network, or an MMCP network which would allow TinTin++, zMud and Mushclient users to connect directly, and someone could set up an MSDP enabled MUD that is also connected to an existing Intermud network and function as a bridge.


Having given this some further thought passwords won't be needed if the spider's host is part of the message as that would prevent spoofing. Downside is that the heading of messages could get quite lengthy:

[lolamud.net] Someone@yetanothermud.com chats: Hello World.

Abusive spiders (I think the technology gap would make this even rarer) would be dealt with the same way as abusive players. MUDs may have to extend their ignore capabilities to include foreign hosts.

Channels could be handled within the MSDP command set. I'd probably settle for ARACHNOS_CHAT and ARACHNOS_DEVEL for players and developers.

If the concept works and demand is there I'm sure someone will step up and try to create a cooler chat kingdom. In that regard the spider/server approach is more promiscuous than the server/client approach.

Yes, truly it is child's play. Why, it's more effort not to do it.

QFT

Even if implementing a "Telnet Intermud Network" was as simple as adding "#include <"intermud.h">" beneath "#include <"awesome_mud_features.h">" what grand purpose would it serve my MUD? I ask because I've previously used IMC2, and found the 10 minutes I took to implement it to be 10 minutes of time completely wasted. And don't get me wrong, that is nothing against IMC2, but after 30 seconds, the novelty wore off, and I was left to ponder "what purpose will this actually serve?"

As a MUD developer, I personally don't want my players in position where they are at risk of being lured to another MUD through my own MUD by other players and MUD admins. That isn't to say player's won't leave for another MUD, but it's the principle of the thing. I highly doubt McDonalds would want an "Interfast-food Network" where you can chat with people at A&W while you wait in line. Besides, no matter how awesome of an Intermud Chat feature I implement, it would be a far cry from other external programs that could offer the same thing.

And as far as for my admins, being that most of the crowd here at mudbytes are admins/mud-owners, we clearly seem to be able to juggle running a MUD and trolling the forums all at the same time.

I'm not trying to bash the idea, or any idea that might further the MUD community, but at the same time we all clearly have an abundance of time to sit and chat while pbases around the net slowly grow smaller. As such, if time is to be spent on developing new MUD protocols, I would personally think time would be better spent on offerings that may help entice new players to our games. Options like MXP, MSDP, modern clients, are allowing the more "casual" gamer the chance to enter our worlds, while another IMC would, IMO, serve little purpose.

My two cents…

IMC2 is basically defunct as a network, so it's no big surprise that it wasn't useful to you. I am assuming though that you did this after it went defunct…

As for what purpose chat serves, well, the same reason why we have email vs. forums vs. instant messaging.

Many MUDs on intermud networks don't allow players on intermud.

I do happen to agree, though, that developing another intermud protocol serves rather little purpose at this point.

The circumstances under which I've seen players on intermud in a way I approve tend to fall under one or more of the following categories:

1) The players are imms/devs too
II) The players had to complete a quest or pay large in-game sums for the privilege
c) The players are on a channel not monitored or controlled at all (more on this in a bit)
*) The players are using mail/rwho/tell rather than channels

At the risk of sounding ivory tower elite like DH, when any chump can say any thing on any channel things tend to
devolve really really really quickly. For those familiar with i3, I demonstrate for you now "Nafe" as exhibit A. The
guy means well, I personally like him (despite having had to call the cops on him), but in the end he is an
unbelievably disruptive influence that 99% of people want killed. Open up all intermud facilities to any nafe off
the street and you'll have normal, fun people whose company you enjoy start finding better things to do.

So, really, normally you don't have players on intermud, in my experience. Usually it's imm/cres/devs/admins
who like to chat with like minded folks in real time.

As to being in uncontrolled channels…this is the sort of channel that normal people don't tune into. If they
do tune into it, it's an "opt-in" situation where they are buying whatever offensive crap they get, and they don't
have recourse or ground to complain if they are offended. I'm perfectly ok with players being in such a venue
if they want to be, because who cares. If they enjoy the kind of filth that breeds there, and they leave your
mud, did you really want them anyway? Could you have kept them? It's a wash.

-Crat
http://dead-souls.net/ds-admin-faq.html#...

That would be fine as long as nobody else could connect from the same host as the spider.

The concept we're discussing here seems to be quite similar to MushLink, which also has the advantage of requiring no special support on the mud. It might be worth downloading the MushLink bot and adapting it to use MSDP instead of MUSH commands.


You implemented the IMC2 protocol in 10 minutes? Or do you mean you just installed the IMC2 Diku snippet?


I occasionally log onto other peoples muds to chat with developers, and sometimes the owners or developers of other muds log onto my game for a chat. Some of my players have even left to run their own muds, but occasionally come back to compare notes and share ideas. This would provide a more convenient way to keep in contact.

For very small muds, it can also provide a social atmosphere that would otherwise leave the game feeling very lonely. Muds are inherently social games, and it can be difficult to retain players if there's nobody else to talk to.

And of course the concept could also be applied to intermud minigames. One day I'd like to pit a team of my best War players against teams from rival muds!

This thread.

WHAT. seriously, what.

..
honestly
..
what.