Zugg Software :: View topic

Posted: Sat Jun 02, 2007 5:12 pm

I've started this thread as a continuation to the ATCP discussion from the LUA in CMUD topic (wow, that topic has spawned two other discussions already!)

As I mentioned in that thread, I have gotten the official go-ahead from IronRealms to implement ATCP support in CMUD.

I am in the process of getting some documentation on some of their modules, but it looks like the basic idea of ATCP is to send messages via the telnet suboption protocol. This is also how some other MUD protocols (ZMP is one that I have seen) work. So CMUD is going to have a generic way to respond to non-standard telnet options and suboptions. I'll then let you set up triggers on the suboption text, allowing you to parse the messages yourself.

In the case of ATCP, I might be able to build in specific support for specific modules to make things even easier (like getting the character vitals).

But I wanted to find out what other kind of "support" for ATCP you wanted. Do you just want to trigger on the messages and handle them yourself, or is there something else that needs to be handled in CMUD?

Posted: Sat Jun 02, 2007 5:30 pm

Triggering on the messages is probably the most versatile way to handle it. The most common operation that people will probably want to do is populating variables with the ATCP values, much like the MXP Set option. You might want to include a way for CMUD to do that automatically, but making triggers for it will allow people to do that as well, if they choose to. Different games also supply different values (Lusternia sends a Power value that none of the other games do, for example) and triggers are a nice way for people to only capture the values that they want.

One thing I know that ATCP does that you might want to emulate as well, though, is controlling the game's internal editor. Normally, the game's editor lets you edit long files line-by-line - you enter each line on as a separate command to build up your news post or whatever. But when you use an ATCP-enabled client (either MudBot or the game's Java client) then an editor window much like the CMUD editor appears. Objects such as journals and letters that you can edit with the in-game editor can contain text when you first edit them, which will appear in the in-game editor, and ATCP somehow sends this data to the client so that it can print it in its editor window as well. It'd be nice (but not necessary) if you could use CMUD's editor for this as well.

Magician Joined: 25 Oct 2000 Posts: 461 Location: USA

I agree just opening it up so folks can trigger off what they want to is the best - there are something like 4(?) different IRE games out there alone, each I'm sure with tweaks to make them unique. It'll save you some headache if you're just able to expose the messages, rather than dealing with the specifics of each. This way as other protocols come out of the woodwork, CMUD will be able to handle them all. Very cool stuff!

Posted: Sat Jun 02, 2007 7:57 pm

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

My ideal handling of ATCP would be something where we can specify what fields go to which variables and/or maybe fire ATCP events but the ATCP line (just text) doesn't go to the display and then we have to gag it there.

Posted: Fri Jun 08, 2007 3:17 pm

Seems to me like the text wouldn't be displayed anyway since it's received surrounded by IAC SB/SE. It'll probably end up being something like adding protocols to some kind of list based on their identifying number, which adds them to a drop-down you can choose for triggers. Then you just create triggers for the body of the ATCP message - this way you could just make an ATCP trigger of (*) to print the whole message, or whatever you like. You could raise events or run scripts or whatever from within the ATCP trigger. With it being a trigger option as well, it'd hopefully work in multistate triggers too :)

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Actually, I would like the idea of putting some way to allow triggerring based on low level inputs. Such as IAC, or a raw switch. I know you really don't want to use that, but it would allow those of us that really know what is going on to build responses to protocols that would be nearly as good as direct support for that protocol.

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

ATCP is basically just a plain text line sent on a timer. It's prefaced by telnet codes, but if you ignore the codes (as many clients do when it's a code they don't understand), the text will just be displayed in the output window.

I agree with Vijilante that setting up some way we can trigger on protocol-level messages would be ideal, though probably difficult to implement.

Posted: Fri Jun 08, 2007 11:48 pm

Vijilante: That's similar to what I have in mind. Since we are in the world of the "telnet" protocol, I want to let you trigger on telnet options. You'll be able to decide what to return (WILL or WONT) when a telnet option is queried, and you'll be able to set up triggers that respond to the telnet suboption data requests (which is what ATCP uses). What you'll see are some new functions that allow lower-level communication, so you'll be able to send responses back to the server via the suboption channel instead of just sending plain text.

So, it's not as low level as triggering on IAC, but it's pretty close.

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

Oooooo.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I have to agree. Oooooo. Cool

Wanderer Joined: 11 Mar 2002 Posts: 93

oooo ATCP! Just for curiosities sake, any ideas of when ATCP support will be available? *hopes the next big version release*

Posted: Thu Jun 28, 2007 2:47 pm

Yes, the next big version, hopefully in the latter half of next month. See the thread in Zugg's blog :)

Posted: Thu Jun 28, 2007 5:00 pm

I can't wait for this, it sounds amazing.