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
➜ 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 page
Pages: 1
2
3
4
5
6
7
8
9
| Posted by
| Nick Gammon
Australia (23,133 posts) Bio
Forum Administrator |
| Date
| Reply #120 on Fri 30 Jul 2010 09:14 PM (UTC) |
| Message
| If you are going to make a design criteria "don't send duplicated data" then you are going to tie your hands somewhat. Or "minimize the bandwith" likewise.
Surely, if a new protocol doubles your player base, you won't mind if the bandwidth, per player, increases by maybe 50%?
After all, if your primary goal is to reduce bandwidth you could remove colour codes and send everything in monochrome (that saves something like 5 bytes per colour change). But then you might *lose* players if you do that.
My other comment is, if you just want to "mark up" existing text, without duplicating it, then that is what MXP can do quite well. For example:
<chat> <channel> General </channel> <player>Nick</player> <message> says, "Hi there!" </message> </chat>
That lets you pull out various parts of the message without sending the whole chat message again in another format.
However you will note that the marking up itself takes quite a bit of bandwith (eg. you need <player> ... </player> ) and this method makes it harder to decide to display the chat message in another window. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Larkin
(278 posts) Bio
|
| Date
| Reply #121 on Mon 02 Aug 2010 06:31 PM (UTC) |
| Message
| I was just postulating that the logic behind the start/text/end method may have been to reduce the duplication of data, even though there are other things already being duplicated. I have no idea what they were thinking when they made this whole GMCP thing, and it is a bit of a mess now.
I have avoided MXP like the plague because MUSHclient doesn't seem to like when you get non-MXP tags that seem to match the MXP format, such as our "guild secret" channels that are surrounded with angle brackets (i.e., <<Channel>> Person says, "Blah."). The codes being inline with the text means you then have to escape the text that appears code-like, just as HTML uses < and > to display < and >, but MXP doesn't account for that, or at least the implementations I've seen so far don't do it. | | Top |
|
| Posted by
| David Haley
USA (3,881 posts) Bio
|
| Date
| Reply #122 on Mon 02 Aug 2010 08:56 PM (UTC) |
| Message
|
Quote:
I have avoided MXP like the plague because MUSHclient doesn't seem to like when you get non-MXP tags that seem to match the MXP format, such as our "guild secret" channels that are surrounded with angle brackets (i.e., <<Channel>> Person says, "Blah."). The codes being inline with the text means you then have to escape the text that appears code-like, just as HTML uses < and > to display < and >, but MXP doesn't account for that, or at least the implementations I've seen so far don't do it.
MUSHclient enforces tag escaping whereas Zugg's software does not, and it tries to guess at what was meant. This means that many MUD developers have been lax -- and have been allowed to be lax by zMud -- in escaping angle brackets. This is not really MXP's fault as a protocol except insofar as it does not, strictly speaking, demand that all non-tag angle brackets be escaped (even though this is really the only reasonable behavior). |
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | | Top |
|
| Posted by
| Nick Gammon
Australia (23,133 posts) Bio
Forum Administrator |
| Date
| Reply #123 on Mon 02 Aug 2010 09:13 PM (UTC) Amended on Mon 02 Aug 2010 09:14 PM (UTC) by Nick Gammon
|
| Message
| It does demand it:
http://www.zuggsoft.com/zmud/mxp.htm
MXP Spec said:
Since a normal < symbol is interpreted as the start of an element tag, you must use < to refer to a less-than symbol directly.
(My emphasis).
The problem actually is that zMud and cMud (as far as I know anyway) don't follow the spec (in this respect).
Since they don't follow the spec, lazy MUD developers have got away with not sending < as < and say "it works in zMUD so there must be a bug in MUSHclient".
|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| David Haley
USA (3,881 posts) Bio
|
| Date
| Reply #124 on Mon 02 Aug 2010 09:17 PM (UTC) |
| Message
| | My bad -- what the spec doesn't specify is what to do when the bracket is not escaped but not meant to be a tag. It doesn't say if it should be rendered, or discarded, or if an error should be thrown, ... |
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | | Top |
|
| Posted by
| Nick Gammon
Australia (23,133 posts) Bio
Forum Administrator |
| Date
| Reply #125 on Mon 02 Aug 2010 09:17 PM (UTC) |
| Message
|
Larkin said:
... but MXP doesn't account for that, or at least the implementations I've seen so far don't do it.
MXP does account for it, as I said above. And my implementation at the server end accounts for it as well:
http://www.gammon.com.au/mushclient/addingservermxp.htm
It is possible to make it work, but when an implementation gets into the wild which doesn't enforce the spec in this rather critical area, confusion has unfortunately reigned. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Nick Gammon
Australia (23,133 posts) Bio
Forum Administrator |
| Date
| Reply #126 on Mon 02 Aug 2010 09:19 PM (UTC) |
| Message
|
David Haley said:
My bad -- what the spec doesn't specify is what to do when the bracket is not escaped but not meant to be a tag. It doesn't say if it should be rendered, or discarded, or if an error should be thrown, ...
My interpretation of "you must use" is that choosing not to use a demanded representation should not be allowed. Otherwise it would be worded as "you may use". |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Nick Gammon
Australia (23,133 posts) Bio
Forum Administrator |
| Date
| Reply #127 on Mon 02 Aug 2010 09:26 PM (UTC) |
| Message
| You are right though that the spec basically describes how to handle the "success" situation rather than the failure situation. For example it is silent (as I recall) on what do to with:
MUSHclient reports an error, but the spec doesn't say whether or not to do that.
Just as an aside the GMCP spec is somewhat similar ...
http://www.ironrealms.com/gmcp-doc
It describes what to do if you get, say, Core.Hello, but not what to do if you get Core.Foo (which isn't defined).
Similarly the telnet subnegotiation says that a subnegotiation sequence should look like:
Putting aside the case of imbedded IAC IAC, it is silent on what to do if the final IAC is not followed by SE. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Twisol
USA (2,257 posts) Bio
|
| Date
| Reply #128 on Mon 02 Aug 2010 09:29 PM (UTC) |
| Message
| | Seems to be a pretty common mistake. Shame on us MUD people for being so optimistic! XD |
'Soludra' on Achaea
Blog: http://jonathan.com/
GitHub: http://github.com/Twisol | | Top |
|
| Posted by
| David Haley
USA (3,881 posts) Bio
|
| Date
| Reply #129 on Mon 02 Aug 2010 09:48 PM (UTC) |
| Message
|
Nick Gammon said:
My interpretation of "you must use" is that choosing not to use a demanded representation should not be allowed. Otherwise it would be worded as "you may use".
I agree with your interpretation.
And yes, many standards are unfortunately lax in specifying precise behavior. I think it has to do with people treating any detail-oriented discussion as "annoying nitpicking". (Of course, the devil is often in the details, as you find out later after pushing through a protocol that ignores them...) |
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | | Top |
|
| Posted by
| Nick Gammon
Australia (23,133 posts) Bio
Forum Administrator |
| Date
| Reply #130 on Mon 02 Aug 2010 10:04 PM (UTC) Amended on Mon 02 Aug 2010 10:05 PM (UTC) by Nick Gammon
|
| Message
| I know that MXP is not defined in a RFC (at least I don't think it is) but per RFC 2119:
http://www.faqs.org/rfcs/rfc2119.html
This is the definition of "must":
RFC 2119 said:
1. MUST
This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.
|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Larkin
(278 posts) Bio
|
| Date
| Reply #131 on Mon 02 Aug 2010 11:07 PM (UTC) |
| Message
| | Thanks for the details on the MXP spec. I did try to qualify my statement by saying that the implementations I've seen to this point have just been less than trustworthy, primarily IRE, and so now I'm not surprised to see the same sort of thing happening with GMCP. | | 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.
305,985 views.
This is page 9, subject is 9 pages long: ![[Previous page]](/images/thin_prev.gif)
1
2
3
4
5
6
7
8
9
It is now over 60 days since the last post. This thread is closed.
Refresh page
![[Go to top]](/images/gototop.gif)
top