[Home] [Downloads] [Search] [Help/forum]


Register forum user name Search FAQ

Gammon Forum

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  Plugins
. . -> [Subject]  trying to make atcp2 plugin to work

trying to make atcp2 plugin to work

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


Pages: 1  2  3  4  5  6  7 8  9  

Posted by Twisol   USA  (2,257 posts)  [Biography] bio
Date Reply #90 on Thu 29 Jul 2010 05:33 AM (UTC)
Message
WillFa said:
how to actually implement [...] a plugin that conforms to the spec?


Well, it's in the spec IRE's using, and I explained how to implement it for said spec, so...

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] bio
Date Reply #91 on Thu 29 Jul 2010 06:20 AM (UTC)
Message
WillFa said:

Can I point out that you guys have been arguing for 2.5 pages about something that should/shouldn't be in the spec, and not how to actually implement the spec or a plugin that conforms to the spec?

Nick, I see why you got disgusted with the mudstandards forum discussion.

While I can sympathize with your frustration, it is somewhat bizarre to be surprised that part of designing standards is discussing, um, what goes into those standards.

As far as I'm concerned these are all still open issues for some spec; whatever IRE/Zugg decide to do with ATCP2 is their affair.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top

Posted by Twisol   USA  (2,257 posts)  [Biography] bio
Date Reply #92 on Thu 29 Jul 2010 06:25 AM (UTC)
Message
Well, this is a topic for ATCP2 (see title), and the "community effort" protocol is supposedly named GMCP, so...

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] bio
Date Reply #93 on Thu 29 Jul 2010 06:30 AM (UTC)
Message
Woe be unto you the next time you stray from a topic to discuss an issue that interests you, Twisol. ;)

PS let's not perpetuate the idea that it's actually a "community effort"; it's not.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top

Posted by Twisol   USA  (2,257 posts)  [Biography] bio
Date Reply #94 on Thu 29 Jul 2010 06:52 AM (UTC)
Message
David Haley said:
Woe be unto you the next time you stray from a topic to discuss an issue that interests you, Twisol. ;)

Hah, I'm just pointing out that this topic is mainly relevant to IRE's brand of the protocol, so it's not as much arguing for a feature as it is arguing against its removal.


David Haley said:
PS let's not perpetuate the idea that it's actually a "community effort"; it's not.

Yes, as I said, the ATCP2 thing is IRE's, and you've reserved the name GMCP for a community effort.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top

Posted by Bast   (78 posts)  [Biography] bio
Date Reply #95 on Thu 29 Jul 2010 02:44 PM (UTC)
Message
Nick Gammon said:

David Haley said:

Unless you meant this figuratively somehow, hosting packages that charge per byte sent are rather unusual.


I think David is right here. Generally you pay (say) $30 per month and get a cap of how many gigabytes you can use up. They don't charge, like, a cent per megabyte.



Every byte costs against that cap. Once someone goes over the cap, then they are going to pay extra. I know with MCCP, there is a savings when sending the same data multiple times, but I still think it is a valid issue. I don't know why people think that bandwidth is unlimited even for a text mud. The MMO games cache, or include in their client, as much data as they can and send as little data over the wire as possible. I admit, I have never run a mud where I had to pay for bandwidth, so maybe I am over thinking this.

David Haley said:

So... you're saying that all this work should be done only because people don't want to restart the client once after disabling a plugin because it uses a relatively small amount of extra bandwidth? I'm sorry, but doesn't that sound just a little bit silly? Fine, they want to stay logged in 24/7 once they get running. OK, but is it so unacceptable that the first time they start up and disable some clients, they need to reconnect?


I am saying exactly that, this is users we are talking about. They are capable of anything and frequently do things or ask for things I never thought of. Some users are knowledgeable, some are not, some are silly, some are serious, but I never take for granted what a use case will be for anything I create.

All this work? It takes some extra code that surely would be tested, but once implemented, would likely be able to be used forever. You talk about race conditions, but really, they would happen about as often as my user scenario. And if it did happen, you reload whatever plugin isn't getting its data and boom, back in business. My scenario, the user has to restart the client. Of course, the next argument will be that if you don't do refcounting and don't care that extra data is being sent, then neither of these will ever happen. Saving bandwidth is always valid imo.

If I don't want the extra data, then don't send it to me.

Bast

Bast

Scripts: http://github.com/endavis
[Go to top] top

Posted by Worstje   Netherlands  (899 posts)  [Biography] bio
Date Reply #96 on Thu 29 Jul 2010 04:05 PM (UTC)
Message
TL;LT. (Too long, lost track.)

My opinion on things like this is simple: there has to be symmetry. If you can opt-in, you need to be able to opt-out afterwards in a manner that mirrors the way you opted in. Disconnecting to opt out, or having to reconnect to opt in, or whatever, that's all the pillars of a crappy design.

With a good design, opting in and opting out would be possible whenever. Assuming that IRE has their ATCP2 protocol designed and implemented without the involvement of hallucanogenic substances and with the presence of sanity, they should have said symmetry.

With that as a given, you people could have implemented the few lines necessary for reasonably foolproof support of said symmetrical doodah at least five times in the time you've spent arguing the merits and necessities. Just my EUR 0.02. :)

(I haven't got a clue who 'you people' might be. As I said: TL;LT.)
[Go to top] top

Posted by Twisol   USA  (2,257 posts)  [Biography] bio
Date Reply #97 on Thu 29 Jul 2010 05:27 PM (UTC)

Amended on Thu 29 Jul 2010 05:28 PM (UTC) by Twisol

Message
Worstje said:
Assuming that IRE has their ATCP2 protocol designed and implemented without the involvement of hallucanogenic substances and with the presence of sanity


They certainly took leave of their senses in one instance:

Quote:
- Comm.Channel.Start
* informs the client that text that follows is something said over a communication channel
* message body is a text containing the channel name
* for tells from/to another player, the channel name is "tell Name"
* Example: Comm.Channel.Start "ct"
* Example: Comm.Channel.Start "tell Player1"
- Comm.Channel.End
* ends a channel text started by Comm.Channel.Start
* message body is a text containing the channel name


I.e. it sends an ATCP2 message, followed by regular text, followed by an ATCP2 message, and they expect you to treate that regular text differently. They're using this like it's MXP. I can't even begin to figure out how to implement this in MUSHclient, because we're handling all ATCP2 messages before we start handling the data. Interleaving the handling would practically require core client support.

I e-mailed Jeremy and told him and Tomas about this, and suggested an alternative that sends the content inside the message. Response:

Quote:
I will look into the possibility of adding a message like this, which would be sent along with the existing Start/End ones.

Well, okay... I guess that works. :S

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top

Posted by Worstje   Netherlands  (899 posts)  [Biography] bio
Date Reply #98 on Thu 29 Jul 2010 06:32 PM (UTC)
Message
And I tried so hard to be nice in my previous post. Ugh. Well, at least they are trying for a change.

Arguably, one might say MUSHclient does it wrong. Think of protocols like MCCP which also start affecting the output at a specific position.

Then again, I'm quite sure it is considered OOB data. Meaning that the position of the OOB data in the primary stream is not meaningfully bound to other information in said primary stream.
[Go to top] top

Posted by Twisol   USA  (2,257 posts)  [Biography] bio
Date Reply #99 on Thu 29 Jul 2010 06:38 PM (UTC)
Message
Worstje said:
Then again, I'm quite sure it is considered OOB data. Meaning that the position of the OOB data in the primary stream is not meaningfully bound to other information in said primary stream.


Yes, exactly. It has no reliable context with the normal output and shouldn't be used that way. =/

MCCP's whole purpose is to change the data being received, and it operates at a lower level than telnet. Plus, it's such a common protocol that you don't really need to worry about writing it as a client plugin. It's not a limited-domain protocol.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top

Posted by Lasher   USA  (22 posts)  [Biography] bio
Date Reply #100 on Thu 29 Jul 2010 07:05 PM (UTC)
Message
Twisol said:

I.e. it sends an ATCP2 message, followed by regular text, followed by an ATCP2 message, and they expect you to treate that regular text differently. They're using this like it's MXP. I can't even begin to figure out how to implement this in MUSHclient, because we're handling all ATCP2 messages before we start handling the data. Interleaving the handling would practically require core client support.

I e-mailed Jeremy and told him and Tomas about this, and suggested an alternative that sends the content inside the message.


Set a flag that the next line of text received is really ATCP channel data and hope you don't lose connection in the meantime?

Mind if I ask what the suggestion you emailed is? I haven't implemented comm.* for Aardwolf yet, so in the interest of considering as many options as possible before hitting the code it could be interesting to see.

I don't see why this needs to be more complex than something like:

To turn channels on/off - from client:
comm.channel { "channel": "chat", "status": "on" }

From Server:
comm.channel { "channel": "chat", "player": "Lasher", "msg": "This is a test message" }

Now this is the 50,000 foot view and I haven't taken a closer look (which usually reveals more complexity), but isn't that basically it?

Note that Aardwolf doesn't have the ability to see everyone else on a channel so we don't have to deal with that. The IRE way of doing the channels list seems fine so if everything else is equal, might as well be consistent on that part.

I'll leave on-the-fly IRC type channels out of this for now, main reason being they don't exist yet :)
[Go to top] top

Posted by Worstje   Netherlands  (899 posts)  [Biography] bio
Date Reply #101 on Thu 29 Jul 2010 07:54 PM (UTC)

Amended on Thu 29 Jul 2010 07:56 PM (UTC) by Worstje

Message
I think you missed the point, Aylorian.

Telnet subnegotiation is Out-Of-Band. It cannot say anything about the things following or preceding it, since it is part of a different layer of processing.

ATCP(2)/GMCP are supposed to be used for information that does not affect the surrounding text. It is supplemental information, fully for scripted interpretation that is not seen by the user in that form. It is NOT a markup language.

On the other hand, you have Ansi and MXP. Those are injected _directly_ into the primary textstream, modifying it in the process (which is a matter ATCP(2)/GMCP do not do as they are designed to solve a different problem). Think of the escape sequences and rather famous <font size=100 face="wingdings"> tags zmud users like to mess around with. Since they are a part of the primary text stream, they can immediately affect/involve their surroundings.

My terminology is probably a bit off, but I am sleepy and not really interested in being 100% correct. As long as the idea makes it across. :)

Edit: And your really basic overview seems to be just fine. It has the message, and does not depend on the actual textstream. So maybe I understood and you _did_ get it. Oh well, typed a lot for nothing then. :)
[Go to top] top

Posted by Twisol   USA  (2,257 posts)  [Biography] bio
Date Reply #102 on Thu 29 Jul 2010 08:13 PM (UTC)
Message
I can't speak for other clients (and, strictly speaking, I can't officially speak here), but MUSHclient parses a packet in two separate stages: first it parses and strips the IAC sequences in a packet, then it parses the rest. So the "last" IAC sequence in a packet will be parsed before the "first" line of normal output is handled by triggers. It basically treats the stream as two distinct, multiplexed data streams, and deals with one before the other. No context is shared between them.

I can see how a single-pass parser can be written that would solve this issue, but it would be a wholesale rewrite of the current implementation. Clearly, if IRE continues with their Begin/End messages, they have a single-pass parser. Multi-pass is arguably more intuitive and/or obvious to implement, though.


At any rate, here's the e-mail I sent to Jeremy and Tomas including my proposal:

Quote:
For me, the biggest issue is that the Comm.Channel.(Start|End)
messages rely on the context of the visible output stream. At least in
MUSHclient, subnegotiations in a packet are handled before the data
goes through triggers. It's effectively a context-less information
channel. Unfortunately, the Comm.Channel.(Start|End) messages enclose
visible data like an MXP tag does.

The GMCP plugin would have to intercept the packet itself and
practically implement its own telnet stack so it has all the
information available within the same context. This subverts the
client's own implementation, and is very bug-prone to boot. That's why
I'm calling it a "nightmare" to implement. It could be argued that
this is a defect in MUSHclient, but the separate-step handling of
subnegotiations seems like a fairly logical way to do it.

As an idea for an alternative approach, maybe you could have the
channel messages only sent when you enable them for a given channel,
and instead of sandwiching the output between two messages, send it
entirely within one message. I also suggest that the channel in the
visible output be toggleable separately, because I can easily imagine
someone wanting to use Comm.Channel without actually rendering the
lines elsewhere (i.e. just for data grabbing). Possible examples:

(sent by client)
Comm.Channel.Listen "clt9" (enables Comm.Channel.Message for this channel)
Comm.Channel.Gag "clt9" (removes this channel from the visible output)

(sent by server)
Comm.Channel.Message {channel="clt9", who="Soludra", message="Blah blah blah"}


Thanks for your time!
~Jonathan Castello

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top

Posted by Larkin   (278 posts)  [Biography] bio
Date Reply #103 on Thu 29 Jul 2010 08:32 PM (UTC)
Message
The part of that proposal, and I know this is nitpicking, that I dislike is the use of "clt9" for a clan. Use the clan short names instead because the numbers can change more easily.

And, while I agree that the 'channel start' 'text' 'channel end' way is less effective than just 'channel text,' it can't be that hard to receive the start, set a flag, and handle the next text in whatever way you want, clearing the flag when you get the end message...
[Go to top] top

Posted by Twisol   USA  (2,257 posts)  [Biography] bio
Date Reply #104 on Thu 29 Jul 2010 08:51 PM (UTC)

Amended on Thu 29 Jul 2010 08:53 PM (UTC) by Twisol

Message
Larkin said:
The part of that proposal, and I know this is nitpicking, that I dislike is the use of "clt9" for a clan. Use the clan short names instead because the numbers can change more easily.

Was just going based on the ATCP2 messages I was already receiving.

Larkin said:
And, while I agree that the 'channel start' 'text' 'channel end' way is less effective than just 'channel text,' it can't be that hard to receive the start, set a flag, and handle the next text in whatever way you want, clearing the flag when you get the end message...

The fact is that there's no way to do that in the current implementation of MUSHclient, and that there is also nothing inherently wrong with how it's doing it now. Since ATCP(2)/GMCP is supposedly meant to transfer OOB (not the telnet kind) data, this one exception sticks out like a sore thumb and makes it very annoying.

In other words: Considering just those two messages, yeah, it's possible. Considering the protocol as a whole, it's extremely ugly. I'm not about to special-case my way though a GMCP implementation.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] 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.


260,121 views.

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

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

Go to topic:           Search the forum


[Go to top] top

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.

[Home]


Written by Nick Gammon - 5K   profile for Nick Gammon on Stack Exchange, a network of free, community-driven Q&A sites   Marriage equality

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( https://gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Hosted at HostDash]