|
|
Scandum
Wizard
Group: Members
Posts: 1,783
Joined: Aug 8, 2006
|
#2 id:20241 Posted Feb 18, 2009, 10:36 pm
|
Format wise I was thinking of the following:
Defines:
Code (text): 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26 |
MSSP 70 /* free telopt value */
MSSP_GIVE 1
MSSP_TAKE 2
MSSP_SKIP 3
MSSP_UPTIME 1
MSSP_PLAYERS 2
MSSP_AREAS 3
Client: IAC DO MSSP
Server: IAC WILL MSSP
Client: IAC SB MSSP MSSP_GIVE MSSP_UPTIME IAC SE
Server: IAC SB MSSP MSSP_TAKE MSSP_UPTIME 1235024422 IAC SE /* Current time(NULL) value */
Client: IAC SB MSSP MSSP_GIVE MSSP_PLAYERS IAC SE
Server: IAC SB MSSP MSSP_TAKE MSSP_PLAYERS 2 IAC SE /* decimal value */
Client: IAC SB MSSP MSSP_GIVE MSSP_AREAS IAC SE
Server: IAC SB MSSP MSSP_SKIP MSSP_AREAS IAC SE /* Server hasn't implemented MSSP_AREAS or refuses to answer */
|
Rules:
MSSP_GIVE should be followed by a value between 1 and 244.
MSSP_TAKE should include a string of digits representing a positive decimal number.
The 0 and 255 byte should be avoided at all cost.
I think that'd be the easiest to implement. After finding IAC SB MASSP MSSP_TAKE you grab the option, then copy digits till you run into IAC SE. Avoiding the 0 byte avoids strlen and related issues and avoiding the 255 byte avoids having to double 255 to follow the telnet protocol and all the screwyness that follows from that.
|
Last edited Feb 18, 2009, 10:37 pm by Scandum
|
|
Cratylus
Wizard
Group: Members
Posts: 1,768
Joined: May 22, 2006
|
#3 id:20242 Posted Feb 19, 2009, 3:40 am
|
I like the idea in general. i do not like the straitjacketed categories.
Some of those things just don't apply for a lot of muds.
I would like a "other" field, in the manner of a table, with locally-definable
categories and values.
-Crat
http://lpmuds.net
|
|
|
|
|
|
|
elanthis
Wizard
Group: Members
Posts: 772
Joined: Feb 26, 2008
|
#6 id:20252 Posted Feb 19, 2009, 8:08 am
|
Tyche, did you actually think most MUD programmers even know how the base TELNET protocol works, much less any kind of interesting extensions? If they did, ZMP would have actually been as easy to implement in existing MUDs as I figured it would be when I designed it. Most MUDs and clients don't even _try_ to handle TELNET properly, unfortunately.
I'm honestly (pleasantly) surprised that Scandum even knew about the sub-negotiation capabilities of TELNET. :p
|
|
.........................
Cutting corners to keep your line count down is just sad.
|
|
Cratylus
Wizard
Group: Members
Posts: 1,768
Joined: May 22, 2006
|
#7 id:20253 Posted Feb 19, 2009, 8:19 am
|
elanthis said:the sub-negotiation capabilities of TELNET. :p
Yknow I was kind of wondering about this.
It just so happens that I'm ever so slightly unignorant enough that I might be
able to implement this functionality for the network subsystem of the driver
of the lib I maintain. Assuming I understand what I'm looking at here, which
admittedly, I may not.
I think that using this sort of thing is probably cool and efficient and etc, probably
saves pandas, too, and sea kittens. But I wonder...if the idea is wide adoption of
this standard...perhaps making it higher level, though inelegant for some, might
best serve the intent?
Perhaps a known query string at the telnet connection for the mud's port that
can be string parsed and string replied to, then dropped?
-Crat
http://lpmuds.net
|
|
|
|
|
Scandum
Wizard
Group: Members
Posts: 1,783
Joined: Aug 8, 2006
|
#9 id:20255 Posted Feb 19, 2009, 8:45 am
|
Cratylus said:I like the idea in general. i do not like the straitjacketed categories.
Some of those things just don't apply for a lot of muds.
I think listing both areas and rooms solves most of the issues with roomless muds. More information, not variable information, should do the trick there.
Kline said:So reporting 0 players would be reported as a SKIP instead?
No, you'd use '0' instead of '\0' there.
Tyche said:Why not use RFC 1572 to do it?
client - IAC DO NEW-ENVIRON
host - IAC WILL NEW-ENVIRON
client - IAC SB NEW-ENVIRON SEND USERVAR IAC SE
host -IAC SB NEW-ENVIRON IS USERVAR "ROOMS" VALUE "15000" USERVAR "PLAYERS" VALUE "52" USERVAR "OBJECTS" VALUE "12345" IAC SE
Hadn't thought of that. It has the 0 byte issue, but other than that it would do the trick. I wonder if string based options ("UPTIME" instead of 1) are preferable?
elanthis said:If they did, ZMP would have actually been as easy to implement in existing MUDs as I figured it would be when I designed it.
I actually briefly considered ZMP, but it's a somewhat silly protocol and comes with too much bloat.
|
|
|
Scandum
Wizard
Group: Members
Posts: 1,783
Joined: Aug 8, 2006
|
#10 id:20256 Posted Feb 19, 2009, 8:54 am
|
Cratylus said:
Perhaps a known query string at the telnet connection for the mud's port that can be string parsed and string replied to, then dropped?
Oh joy, another !!MSP cludge?
DavidHaley said:I see no real reason to make this telnet subnegotiation instead of some kind of higher-level RPC type of protocol.
Because most muds have some kind of telnet subnegotiation support given the popularity of MCCP. This would be relatively easy to add, while an extensible negotiation protocol would be 1) too much work 2) unmanageable.
|
|
|
Cratylus
Wizard
Group: Members
Posts: 1,768
Joined: May 22, 2006
|
#11 id:20257 Posted Feb 19, 2009, 9:03 am
|
Scandum said:I think listing both areas and rooms solves most of the issues with roomless muds. More information, not variable information, should do the trick there.
I disagree. I very much support the intent, but locking in
categories like this imo is not necessary and limits extension.
Again, if wide adoption is the idea, I would suggest more
flexibility, rather than one size fits all. Fixing/mitigating
unnecessarily-limiting specs in old systems/protocols/langs
is just what we already have enough of.
I don't think "well then, let's just make sure we think of
everything and don't miss anything" is a reasonable approach.
Quote:Oh joy, another !!MSP cludge?
If the idea here is a spec that is to be widely useful and adopted, then I think
it is necessary to entertain the notion that your favorite ultra efficient method
may not actually achieve the goal of being widely used, and should be reconsidered.
-Crat
http://lpmuds.net
|
|
|
Scandum
Wizard
Group: Members
Posts: 1,783
Joined: Aug 8, 2006
|
#12 id:20258 Posted Feb 19, 2009, 9:23 am
|
Cratylus said:I don't think "well then, let's just make sure we think of everything and don't miss anything" is a reasonable approach.
Using a predefined value is mainly done for ease of implementation, then again, without a c implementation snippet it won't be adopted anyways, so I guess a more open ended option would indeed be a plus.
Cratylus said:
Scandum said:Oh joy, another !!MSP cludge?
If the idea here is a spec that is to be widely useful and adopted, then I think
it is necessary to entertain the notion that your favorite ultra efficient method
may not actually achieve the goal of being widely used, and should be reconsidered.
Don't underestimate the appeal of an elitist protocol.
|
Last edited Feb 19, 2009, 9:24 am by Scandum
|
|
|
|
David Haley
Wizard
Group: Members
Posts: 7,783
Joined: Jun 30, 2007
|
#14 id:20260 Posted Feb 19, 2009, 10:22 am
|
Scandum said:Because most muds have some kind of telnet subnegotiation support given the popularity of MCCP. This would be relatively easy to add, while an extensible negotiation protocol would be 1) too much work 2) unmanageable.
I'm not convinced it's any more work than trying to exhaustively list all categories while at the same time maintaining open-endedness. I'm also not sure what would be so unmanageable about it. It would only be a question-answer protocol, with nothing happening other than: "what is your value for X", followed by "abc" or "not-applicable".
|
|
|
Scandum
Wizard
Group: Members
Posts: 1,783
Joined: Aug 8, 2006
|
#15 id:20261 Posted Feb 19, 2009, 12:06 pm
|
Tyche said:I think the open endedness of the environment variables has the added bonus of querying or sending information that one thinks is useful.
Surely you don't think lines of script is more important than getting back USERVAR "BDSM" VALUE "Y" USERVAR "FURRY" VALUE "Y" USERVAR "LASG" VALUE "Y"? ;-)
I'm clueless what LASG stands for? And as a matter of fact, I find the number of script lines more important than the number of rooms, I like interactive worlds.
Tyche said:
As a matter of fact one could send one's entire mud listing in the form of variables.
Wouldn't that make updating one's mud listing... other than domain name/IP/port sort of an automatic process?
It would, even the IP address could be set automatically.
|
|
|
