prompt under mudlet is strange

[陈圣麒]

under mudlet when use unicode the prompt: > turns into ; use ascii is just fine

[Zesstra]

Good morning,

On 26.01.20 07:07, 陈圣麒 wrote:
> under mudlet when use unicode the prompt: > turns into ; use ascii is just fine

It may be cause by the specific implementation of your prompt hook and since
we don't know it, it difficult to come to any conclusions.

However, I assume it is more likely to be a client issue, because Mudlet has a
somewhat spotty track record when it comes to prompt handling and its
implementation of the two relevant pseudo-standards for marking something as a
prompt (either using the EOR telnet option (end-of-record) or using GA when
negotiation the SGA (suppress-go-ahead) telnet option).
Also, it may stumble when you don't use either method and mudlet tries to
detect the prompt itself.
Another possibily would be client-side triggers and alike which do not handle
utf8 correctly (e.g. it has string.len() vs. utf8.len()).

BTW: Mudlet does not support any of the relevant telnet options to negotiate
binary transport or telnet charset. As far as I understand it, it is a client
setting telling it to assume utf8 - do you set that?

TL;dr: check mudlet and/or try a different client, e.g. MushClient oder tintin++.

Zesstra
--
MorgenGrauen -
1 Welt, mehr als 200 Programmierer , mehr als 16000 Raeume,
viel mehr als 7000 unterschiedliche Figuren, 90 Quests, 13 Gilden,
ueber 5000 Waffen und Ruestungen, keine Umlaute und ein Haufen Verrueckter.
Existenz: mehr als 25 Jahre
http://mg.mud.de/

[陈圣麒]

in mushclient it's ok so I think it probably mudlet's problem.

[Tamarindo]

Zesstra, could you dig into the guidance a bit more?

At the beginning of the session, game should/should not send to Mudlet WILL SGA?

When presenting a prompt, if the client has already returned a DO SGA, the game will/will not send a GA?

The prompt will always send an EOR?

Thank you,

-Tamarindo@StickMUD

[陈圣麒]

I use the aoe mudlib and it has this problem.

[Tamarindo]

Re: aoe - Yes, I once I get information from Zesstra and the Mudlet crew I will resolve this in aoe mudlib and perhaps I will also resolve it somehow in Mudlet - I have done a lot of telnet negotiation work in Mudlet this past year.

[Zesstra]

Hi Tamarindo,

I think, Gnomi and me both commented already on an issue on github, one of
those about prompt handling, you may find more information there.

First of all: I strongly prefer the EOR method because it is simpler and does
not interfer as much with other parts of the telnet protocol.

With EOR, you can negotiate sending EOR on the mud side. Once the mud sent a
WILL TELOPT_EOR and received a DO TELOPT_EOR from the client, you just send an
EOR after every prompt. It historically just marks a logically continuous
portion of data and arguably that is finished with a prompt in mud contexts.
In any case a mud must only send EORs if negotiated for the mud-side. (The
client side usually does not send them and should reject a request to use
them, i.e. it should answer a DO TELOPT_EOR from the mud with a WONT TELOPT_EOR.)

SGA on the other hand is a complicated issue, because historically it is a
means of flow control on half-duplex networks. Go-Ahead is like a token. A
telnet partner is only allowed to send, after it received a Go-Ahead from the
other side. After it finishes, it sends a GA and the other side can send until
it finishes with a GA and the circle is complete. Since this not needed on
modern the telnet option exists to *disable* this sending of Go-Aheads. So
strictly speaking: telnet partner are *required* to send GA as flow-control
tokens unless the negotiate the telnet option Supress-Go-Ahead. Once
negotiated, the telnet partners should not send any GAs.

I guess you see the dilemma. In any case, GA as prompt mark is only allowed
when Suppress-Go-Ahead is in effect which is kind off counter intuitive. And
disregards the "should" requirement of the corresponding RfC making it
doubtful that there is a correct way of using them.

Also SGA is used by some clients to enable char mode. This is motivated by a
comment in the RfC:
" As the SUPRESS-GO-AHEAD option is sort of the opposite of a line at a
time mode, the sender of data which is suppressing GO AHEADs should
attempt to actually transmit characters as soon as possible (i.e.,
with minimal buffering) consistent with any other agreements which
are in effect.
"

AFAIK it is also sometimes enabled/disabled in connection with the echo mode.
"
In many TELNET implementations it will be desirable to couple the
SUPPRESS-GO-AHEAD option to the echo option so that when the echo
option is in effect, the SUPPRESS-GO-AHEAD option is in effect
simultaneously: both of these options will normally have to be in
effect simultaneously to effect what is commonly understood to be
character at a time echoing by the remote computer.
"

Therefore, even if you assume that anyway nobody will care about GA as flow
control method, it is inter-related with other telnet options.
I really don't like it for marking prompts in the mud context.

[Zesstra]

On 26.01.20 11:24, Zesstra wrote:
> On 26.01.20 07:07, 陈圣麒 wrote:
>> under mudlet when use unicode the prompt: > turns into ; use ascii is
>> just fine

> However, I assume it is more likely to be a client issue,

My assumption was correct. There is a bug report for this for mudlet:
https://github.com/Mudlet/Mudlet/issues/1623

[Michael Conley]

Thanks Zesstra,  Good information and I will see what I could to (if anything) to improve things.

--
You received this message because you are subscribed to the Google Groups "LDMud Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ldmud-talk+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ldmud-talk/14cec4ed-cd33-9918-bea4-986aef984d8e%40zesstra.de.

[陈圣麒]

yes if the lib doesn't use MXP then there is no problem

[Zesstra]

On 26.01.20 19:33, Tamarindo wrote:
> I have done a lot of telnet negotiation work in Mudlet this past year.

BTW: In this case, although not related with this problem: I would like to
reiterate my dissatisfaction with the way Mudlet requires it's pseudo-GMCP
message Client.GUI to be sent outside a GMCP package context.

Bye,

[Michael Conley]

Hi Zesstra, did this resolve the issue for you? https://github.com/Mudlet/Mudlet/pull/3003

-Tamarindo

--
You received this message because you are subscribed to the Google Groups "LDMud Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ldmud-talk+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ldmud-talk/461e6eb9-b57b-47d8-e7ff-2e85ad5e1b96%40zesstra.de.

[Zesstra]

On 29.01.20 01:35, Michael Conley wrote:
> Hi Zesstra, did this resolve the issue for

> you? https://github.com/Mudlet/Mudlet/pull/3003No, it did not. I commented as such at the corresponding issue. While your
change did change the message to one conforming to the required format of a
GMCP message (thanks for that!), it is still sent outside a GMCP package
without being requested by the client.
(And yes, people are irritated by it and I received complaints.)

Also, it is a Mudlet-specific (i.e. client-specific) message no other client
can use in any way (because the package expected by mudlet is specific to
Mudlet) and it should be in some Mudlet namespace instead of a generic
"Client". E.g. Client.Mudlet.GUI which would be the GUI message within the
Client.Mudlet package. Other clients could then request a Client.<client>
package for messages concerning them.

(Both is also true for Client.Map.)

[Michael Conley]

Yes, standards introduction in our MUD community needs improvement.  I would have like to have seen the MNES standard (https://www.reddit.com/r/MUD/comments/ef40vp/mnes_mud_new_environ_standard/) introduced with more conversation, for instance.  I wish to perfect the configuration that can happen at the beginning of a connection to provide the most comfortable settings for a player with whatever client that chose to use for that connection to make it more seamless.  For example, something as simple as rows and columns, or ansi color choices, should be something that could be selected for the player at connection time unless they made an explicit choice otherwise.  One could argue the reverse of course, however my interest is in serving the common player that is not very tech savvy, otherwise they could skip our game right from the start (and right now... they are, and it needs to change). 

Regarding Client.GUI and Client.Map, some may argue that to maintain some reasonable commonality that the package names should be kept the same across much of the code on the game side, while only the values would change game side depending upon the client being used for that connection.  For example, most of the code would be the same other than a #define value for a Mudlet .mpackage file path vs. a TinTin++ .zip file path (fictional example!).  This would help us speak relatively the same language across the clients, motivating them to be more common, too.  I'm not saying this is the final, best answer or right, only another perspective.  Likely Client.GUI ad Client.Map would have benefitted from more conversation when they were originally implemented.

I worked with Eric@Grapevine Client for the Client.Media proposal, which was advertised on /r/mud.  https://wiki.mudlet.org/w/Standards:MUD_Client_Media_Protocol.  I believe the IRE games client and Mudlet have implement it so far and Eric will get to it when he can.  I do hope there will not need to be variance client to client for the pattern of values there, although there are some ideas for additions in the next rev, like fade-in and fade-out of sounds.

We also should do what we can within the LDMud community to talk more about changes.  I know there were some who were not too happy with some of the efun names disappearing, particularly the ones that are also in the C language, like strlen for instance.  People know there is a work-around, but to some I am sure there is a religious connection to some core learnings.  In fact, it sort of reminds you of when you don't go to church for a while, then they change up the ritual, and when you come back you don't quite fit in anymore.  As for me, I just continually chuck all the obsolete efuns out of the lib and keep it current ;)

We appreciate everything the LDMud Team has done to keep the driver progressing.  It's inspired me to do more, I know that, and I am hoping in the near future with all of the people who are asking for what they should use to start a new game that more people will again choose LDMud and LPC!  I can't wait to figure out the Python websockets so I could link up with the Grapevine (Gossip) chat network (https://grapevine.haus/docs) which I believe will grow a lot over time.  They are doing a ton of marketing and we're seeing many varieties of games linking up to Gossip and listing in the Grapevine portal.

-Tamarindo@StickMUD 

--
You received this message because you are subscribed to the Google Groups "LDMud Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ldmud-talk+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ldmud-talk/392da6e4-d8ce-70c1-96e1-9190c6c53ff2%40zesstra.de.

[Zesstra]

On 29.01.20 04:16, Michael Conley wrote:

> Yes, standards introduction in our MUD community needs improvement.

My objective was not to start a discussion about the general process of this,
although I agree that there is no decent way.

> I would have like to have seen the MNES standard
> (https://www.reddit.com/r/MUD/comments/ef40vp/mnes_mud_new_environ_standard/)
> introduced with more conversation, for instance.

Dear jof. That one... And MSDP... MSDP-over-GMCP... *sigh*
BTW: this transmission of data by cycling through TTYPE SEND/IS is obnoxious
(unless for cycling through different fallbacks).

Seriously: MSDP (Mud Server Data Protocol), GMCP (general
Mud communication protocol), MSDP-over-GMCP, EXOP (Telnet Extended Options
Standard), MCCP (Mud Client Compression Protocol, Version 1-3), MMCP (Mud
Master Chat protocol), MNES (Mud New-Environ Standard), MSSP (Mud Server
Status Protocol) und MTTS (Mud Terminal Type Standard)...?

> For example, something as simple as rows and columns, or ansi color
> choices, should be something that could be selected for the player at
> connection time unless they made an explicit choice otherwise.

I have to mention, that there is for a long long time support for exchanging
information about rows+columns of the terminal in telnet and it does work...
IMHO there is no need whatsover to duplicate that in yet another new protocol.

> Regarding Client.GUI and Client.Map, some may argue that to maintain some
> reasonable commonality that the package names should be kept the same
> across much of the code on the game side, while only the values would
> change game side depending upon the client being used for that connection.

Oh, no, no, no... IMHO: Someone who assumes using prior knowledge of the
server about the specifics of the client when answering questions from the
client is a sane design, likely thinks bathing in acid is a joyful experience...
Changing the response of the server for the same request depending on the
assumed (capabilities of) client is just mindbogglingly insane and crazy.
(Forgive me to use plain language, but I am really horrified that someone
would deliberately design a GMCP package like that, although it is not even a
real GMCP package in this case...)

If one implement GMCP (which one obviously does), one has a perfectly working
way for the client to request a specific capability, i.e. the correct one for
the client and the client decides what it wants.
There might even be a client who could interpret two different client packages
- why should the server know and decide what to send? Why should it maintain a
table of client names and versions?

> This would help us speak relatively the same language across the clients,
> motivating them to be more common, too.

The language is defined by the GMCP transport layer and it is always the same.
If different clients request to enable the GMCP package
"Client.<clientname>", they can perfectly share the same codebase. The spec
could also include additional data to be requested, e.g. different UI and map
formats for different versions if available.

> I worked with Eric@Grapevine Client for the Client.Media proposal, which
> was advertised on /r/mud.
> https://wiki.mudlet.org/w/Standards:MUD_Client_Media_Protocol.

Well, it is not client-specific and gets enabled by client request, thank you
for that.
Although I do not like the use of an empty message name making the message
basically the same as the package name in case of the Client.Media message.
This breaks the intended scheme in GMCP of organizing messages and packages
hierarchically (messages are always the leaves of the tree). The message
Client.Media would be the message "Media" in the package Client, whereas you
obviously intend it to be as message in the Client.Media package.

[Zesstra]

I forgot to mention, that we (Morgengrauen) will likely remove support for the
Client.GUI message if it were to remain without alternative in the current
form for the foreseeable future.

(Reasons are the bad design (it forces servers to behave rude and the feedback
I got from non-Mudlet people.)

[Zesstra]

Hi Tamarindo and everybody else,

I think, a new thread might be good to add some general thoughts... They are
purely my personal view.

I would like to see a little coordination between client programmers and muds.
Currently, some client programmers devise something and muds can follow or
not. But there is no discussion in advance.

We have an awful lot of mud-client protocols nowadays and most of them are
supported by very few clients and muds. Some of them contradict each other or
are rather badly designed (e.g. contradict existing, traditional telnet
options). Some duplicate tasks and it is not clear, which one should have
precedence (e.g. several ways to indicate supported charsets).

Many unnecessarily reinvented the transport layers, increasing the necessary
work to support them, e.g. GMCP and MSDP and MSDP-over-GMCP.

GMCP defines a rather nice "transport layer" by using JSON and a reasonable
Core module to control basic behaviour (like requesting packages/features).
However with the exception of Core, it defines no packages by itself. In the
beginning, they tried to define Char, Comm and Room, but did not finish before
mudstandards.org ceased operation. (Maybe it was even one reason for it.)

The "well-known" packages Char, Comm and Room are now implemented differently
by different muds, which destroys inter-operability.
Additional packages are defined on-the-fly by muds and clients, but mostly
without adhering to any coherent namespace, making the problem worse.
(Client.GUI is an example of this.)
(BTW:one idea in the spec was to use an initial _ to mark packages as
server-specific ones, but nobody uses it.)

That means, the "application layer" (the packages) of GMCP is mud-specific and
requires mud-specific interpretation by the clients. This is very difficult,
when identically named packages have different data for different muds,
clients and even mud-client combinations!

From my perspective we should stop defining any more transport layers and
"just" use GMCP for transport, but improve the situation by
a) adhering to a common behaviour of all muds and clients for
"well-known" packages. It is likely, that these will encompass a minimum,
basic feature set. (but who defines them...? I don't see that coming.)
b) using consistent namespaces for everything else, e.g.
<Mud>.<Subpackage>.<Message> for mud-specific packages and
<Clientname>.<Subpackage>.<Message> for client-specific packages.

My approach now would clearly be centered around b).

[Gnomi]

I would glady see some definition of standardized packages for GMCP.

But many clients lack support for even some basic telnet options, that
are important nevertheless. For example there are NAWS, CHARSET, EOR and
STARTTLS. We're talking about maps and sound support in GMCP, but are
still missing encoding negotation or automatic encryption.
So for me when talking about MUD standards many MUD clients are still
too focused on shiny features without having done the necessary homework.

Regards,
Gnomi.

[Zesstra]

On 30.01.20 23:47, Gnomi wrote:
> But many clients lack support for even some basic telnet options, that
> are important nevertheless. For example there are NAWS, CHARSET, EOR and
> STARTTLS. We're talking about maps and sound support in GMCP, but are
> still missing encoding negotation or automatic encryption.
> So for me when talking about MUD standards many MUD clients are still
> too focused on shiny features without having done the necessary homework.

I completely agree with that. All those options - defined long ago and used in
standard telnet - are missing from to many clients. These are a kind of
low-hanging fruits. Where functionality is in existing specifications outside
the MUD world, we should not duplicate them in a new high-level protocols
(like charset in MNES) without having a very good reason for that.

CHARSET and BINARY (!) are definitely two which should receive a higher
priority, because they also define what data you can transport in any
higher-level protocol. e.g. with BINARY everything is limited to NVT ASCII.
(However, the optional translation table of CHARSET is IMHO not really necessary.)

[Michael Conley]

Could we drag you two into participating in a Discord server?  Why not create one for LDMud, integrate the Github feed to a channel, and create some channels for each of the protocols we are interested in?  And Intermud, Python, etc. so we could get on the same page.  Whatever your opinions on Discord, theres a lot of games with them, and its simple to flip between them and the Mud and Mudlet Discords to keep up with what's going on.

PS.  I will see what I could do to remedy the Client.Media spec per the comment in this thread.  I understand the request and it shouldn't be a problem.

Tamarindo from StickMUD & Age Of Elements

--
You received this message because you are subscribed to the Google Groups "LDMud Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ldmud-talk+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ldmud-talk/4cab3978-ac3b-ac32-cfab-63744163e470%40zesstra.de.

[Travis Everett]

This isn't exactly on topic, but related. I mean it more as something (a pipe-dream) to think about than as a real request.

Spending a regrettable amount of time on various attempts to improve, optimize, and debug aspects of how we format (align & color) text made me greatly envy server-client relationships that delegate rendering/presentation work to the client (and separate content/style/layout concerns to some extent; modern Web stacks are one example). 

Some of this is intrinsic to writing the text stream at all; some is related to user-specific customizations. I assume this is a shared experience, but I can give examples if anyone needs. Players like and request these, but rendering user-specific customizations server side limits our ability to cache, slows down string rendering, and either entails more complex/conditional code everywhere, or the complexity of inventing and adopting new messaging abstractions (making it cover all cases, making sure it's used everywhere, and making sure we don't backslide as wizards used to doing it the old way add new content...)

This is roughly the desire/challenge OOB protocols are trying to address: to manage the complexity (and overcome the limitations) of providing better UI/X via a single-scrolling-text-stream. MUD clients have been trying to address the same issue ad-hoc from the user's side for decades with features like highlights and scriptable panels/windows to extract and rearrange information to make it easier to understand. They all point to some degree of dissatisfaction with the limitations of the text stream.

My pipe-dream is: game code doesn't know about the text stream (or any other interface), nor what protocols are involved. It focuses on the logic and content of the game. Modules at a separate layer use profiles to map/filter game state/events into the appropriate structure, optionally format per stylesheet (or let the client do this when it is capable), and push through the relevant protocol(s). A game might just use one, or it might support several profiles simultaneously.

T

[Karl Tiedt]

Travis, 

I am curious, how would you go from game context, "A pair of ruby slippers" -> user friendly output of "A pair of ruby slippers" -- where would the context exist that says "make this red if needed" in your example?

-Karl Tiedt

To view this discussion on the web visit https://groups.google.com/d/msgid/ldmud-talk/CAC%3DjSUUTG%3D1y5KoKU7A--dfa8zxbPVc7F%3D5xW1YJQ2zrayYj6w%40mail.gmail.com.

[Travis Everett]

Karl,

Shooting from the hip here in pipedreamland, but: tag them as "red" (with an api, or with markup) and have stylesheets that specify how to translate "red" into the supported formats. 

With the caveat that color is a slippery concept in the first place (many players may have colors remapped in their terminal emulator or telnet/mud client, and many items with some color can't be represented), you can tag an intrinsic color like you would tag any semantic.

If the slippers are intrinsically red, tagging them as red is just as valid as tagging them as items or shoes. 

T

To view this discussion on the web visit https://groups.google.com/d/msgid/ldmud-talk/CADNgbTEKpCu_PGb6npn-5hwYPJVBycH0CzQGWztpvvRu5AzZNg%40mail.gmail.com.

[陈圣麒]

chinese muds use an Android app as client. it has it's own protocols it displays like this.

[Karl Tiedt]

Travis, that sounds like not just text then and violating the first part of your pipedream, at least from how I understood your first post...

On Sat, Feb 1, 2020, 19:38 陈圣麒 <seik...@gmail.com> wrote:

chinese muds use an Android app as client. it has it's own protocols it displays like this.

--
You received this message because you are subscribed to the Google Groups "LDMud Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ldmud-talk+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ldmud-talk/8d372e48-511f-4231-a54c-72307902c671%40googlegroups.com.

[Zesstra]

On 31.01.20 17:18, Michael Conley wrote:
> Could we drag you two into participating in a Discord server?

Ich would be willing to join a discussion on Discord, but I am not to thrilled
of having another client/service that a I have to run/look at on a regular
basis. But we can arrange discussion for specific topics...
And to be honest: I really appreciate the property of email, to be not
real-time. ;-)

> PS.  I will see what I could do to remedy the Client.Media spec per the

> comment in this thread.  I understand the request and it shouldn't be a problem.That is great news, thank you very much! :-)

Bye,

[Doug Warren]

This is rather timely, as we just added an X-Real-IP style header to our telnet opt to get query_ip_number() to be correct when coming in through a node.js client.  I'd love for things to be standard.

--
You received this message because you are subscribed to the Google Groups "LDMud Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ldmud-talk+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ldmud-talk/48c0e58e-26f6-3a7e-3cfd-8eefafa6105c%40zesstra.de.

[Zesstra]

On 04.02.20 20:34, Doug Warren wrote:
> This is rather timely, as we just added an X-Real-IP style header to our
> telnet opt to get query_ip_number() to be correct when coming in through a
> node.js client. 

We have something like that at Morgengrauen for many years, which is of course
only used for the local websocket-proxy. (incidentally, the first proxy also
used node.js)
We simply use a special "username", "REMOTE_HOST=...", so it is not really
OOB. ;-) What is your approach?

[Doug Warren]

Ours is literally part of the telopt negotiation, specifically IAC-SB-TELOPT_ENVIRON.  

--
You received this message because you are subscribed to the Google Groups "LDMud Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ldmud-talk+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ldmud-talk/66e41049-06d1-2603-1faf-255da380eaef%40zesstra.de.

[陈圣麒]

maybe the problem is the lib it self not the driver or mudlet. I test Unitopia lib it supports mxp too when under utf-8 the prompt ">" is just ok won't become ";". when use age-of-elements lib ">" will become ";" maybe the aoe lib's mxp part doesn't handled properly

[Tamarindo]

Could you confirm if this is still a problem on AoE?  I don't get the issue on Mudlet with ageofelements.org 7680.  Thanks!

[陈圣麒]

在 2020年5月1日星期五 UTC+8上午6:41:36，Tamarindo写道：

[Tamarindo]

Hi Zesstra or Gnomi - How could I make my game server encode default as UTF-8 with the 3.6 drivers?  I did look through the unicode document and attempted to set a configurable option in the master's inaugurate, but that did not work.

Thank you,

-Tamarindo

[Tamarindo]

Replying to my own email, I am now reviewing the 3.5vs.3.6 document, thanks.

[Zesstra]

Hi Tamarindo,

On 02.05.20 13:05, Tamarindo wrote:
> Hi Zesstra or Gnomi - How could I make my game server encode default as
> UTF-8 with the 3.6 drivers? I did look through the unicode document and
> attempted to set a configurable option in the master's inaugurate, but that
> did not work.

there are three configurables for encodings:
// Standard-Encoding fuer Dateien
set_driver_hook(H_FILE_ENCODING, "UTF-8");
// Und Encoding fuer Dateinamen im Filesystem
configure_driver(DC_FILESYSTEM_ENCODING, "UTF-8");
// Standard-Encoding fuer Interactives
configure_interactive(0, IC_ENCODING, "ASCII//TRANSLIT");

As you see, we use UTF8 for file names and file contents, but ASCII//TRANSLIT
as default encoding for interactives. But each interactive can change that
setting for itself.

Bye,

[Vadim Peretokin]

I had no idea this thread existed until I stumbled upon it in a google search today.

Regarding earlier Client.GUI talk - coincidentally, Mudlet had a request just yesterday to enable Client.GUI module from client-side to better adhere with the GMCP spec, and given that it's a simple one-liner this improvement, expect to see it future update: https://github.com/Mudlet/Mudlet/pull/5562.

Big thanks to Tamarindo for his earlier work on implementing Client.GUI to use proper GMCP. For anyone else interested, these are the GMCP extensions under discussion: https://wiki.mudlet.org/w/Manual:GMCP_Extensions

Best,

V.

[Zesstra]

Hello Vadim,

On 31.10.21 09:59, Vadim Peretokin wrote:
> I had no idea this thread existed until I stumbled upon it in a google search
> today.

Ah, yes, that simple issue developed into quite a long and interesting thread.

> Regarding earlier Client.GUI talk - coincidentally, Mudlet had a request just
> yesterday to enable Client.GUI module from client-side to better adhere with
> the GMCP spec, and given that it's a simple one-liner this improvement, expect
> to see it future update: https://github.com/Mudlet/Mudlet/pull/5562.

Oh, that is very good to know, that you are changing this. :-) Thanks!
In the meantime MG changed to not send it automatically, but we added an
in-game command to send the package announcement to the client. I will then
add proper handling for enablement via Core.Set soon.

Bye,
Zesstra@MG

[Nils Schimmelmann]

Hello Zesstra, Vadi, and all,

I'm glad that we're bringing this up. I would like to caution that while we are not following the GMCP protocol and historically sent "Client.GUI" and "Client.Map" messages without the Client module being enabled we should not further break the GMCP specification. I propose that we bring the Client GMCP module into backwards compatible compliance by (re)sending the "Client.GUI" and "Client.Map" GMCP messages when the "Client" GMCP module is enabled. This allows broken clients to continue working but also empowers more pedantic MUDs to only send "Client.GUI" and "Client.Map" if the Client module is enabled and thus following the GMCP specification.

The also means sending Core.Supports.Add [ "Client 1" ] rather than Core.Supports.Add [ "Client.GUI 1" ] which is incorrect since Client.GUI represents a GMCP message rather than a GMCP module.

Confused between module and message? I'll briefly talk about it:

• Module Examples
  
  • XXXX
  • XXXX.XXXX
    
  • Char
  • Char.Items
    
  • Client
  • Client.Media
• Message Examples
  • XXXX.YYYY
  • XXXX.XXXX.YYYY
    
  • Char.Name
  • Char.Items.Inv
    
  • Client.GUI
  • Client.Media.Play
    

As you can see, modules share a similar space as messages XXXX.YYYY but messages are always prefixed by a module XXXX or submodule XXXX.XXXX. This should help explain why we want to send Core.Supports.Add [ "Client 1" ] since it's requesting a module XXXX (or Client) rather than incorrectly requesting a message XXXX.YYYY (like Client.GUI). Let's please make sure we adhere our best to the GMCP standards and not further break things!

Does anyone have a concern with us allowing the "Client" GMCP module to be enabled?

Best,

Nils

[Zesstra]

Hello Nils,

On 02.11.21 00:26, Nils Schimmelmann wrote:
> The also means sending *Core.Supports.Add [ "Client 1" ]* rather than
> *Core.Supports.Add [ "Client.GUI 1" ]* which is incorrect since Client.GUI

> represents a GMCP message rather than a GMCP module.

You are of course correct. I should have checked the proposed change in
detail. ;-) Thank you for noticing this issue.
I fully agree, that the client should currently enable the module "Client",
not "Client.GUI".[1][2]

I also mentioned earlier in the thread, GMCP modules and messages in packages
can be considered as hierarchical tree and the messages are the leaves.

[1] although IMHO an even better solution would be to use proper namespaces,
e.g. "Client.Mudlet.GUI" as module name to collect GUI-relevant and
client-specific data for the client Mudlet to avoid clashes, incompatibilities
and ambiguities.

[2] However, Mudlet also defines the message "Client.Map" (also to be sent
without request at the moment) which would be also enabled/requested by adding
"Client 1", because they are in the same module... And a mud might support
only one of them. To solve it properly, these messages should not be mixed in
the same module.

(Side remark: Although a module name could be at the same time a message name,
e.g.there might be a package "Client" that has a message "GUI" (i.e.
"Client.GUI") and a package "Client.GUI", that has messages in that namespace,
e.g. "URL", i.e. "Client.GUI.URL". However I would try to avoid that
situation, because it adds confusion.)

[Vadim Peretokin]

> To solve it properly, these messages should not be mixed in

the same module.

That is true, but we're past design time for both Client.GUI and Client.Map - and keep in mind there's also a separate Client.Media (https://wiki.mudlet.org/w/Standards:MUD_Client_Media_Protocol) which is a proper module.

Confusing, eh? Enabling 'Client' will be technically correct, it'll give a bad taste to new implementers as it'll carry little practical meaning given all these overloads. We'll need to have a lengthy discussion explaining to them the fine details with every one of them.

We're all well aware of the law of the least surprises, and this would be a clear violation of it. Seems better to make an exception here not to break it!

[Vadim Peretokin]

The situation turned out to be a mess that was confusing everyone involved at some point or other, so the Core.Supports.Set 'Client.GUI' change was cancelled. 'Client' won't be sent either, due to the aforementioned issues it has. Nils had a better idea here to freeze Client.GUI and Client.Map as we used them and to make a proper GMCP module in the future.

In terms of backwards compatibility, we go to great lengths in Mudlet not to break it so existing Client.GUI and Client.Map messages will continue working as documented. 

--
You received this message because you are subscribed to a topic in the Google Groups "LDMud Talk" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ldmud-talk/tu6C0yw_00s/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ldmud-talk+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ldmud-talk/7cca4032-96ff-4dfc-a8f1-63fa5c3ced17n%40googlegroups.com.