Mudlet: El texto GMCP / GA se suprime al iniciar sesión

Esto es anterior a una solución que puse recientemente ( desde la versión de lanzamiento 3.16.1) para finalmente permitir que el servidor negocie la opción 1 de telnet (ECHO) y se haga cargo del eco en la pantalla de Mudlet si tienen la opción "hacer eco de lo que escribo dispuesto a descartar eso como causa sin más información.

¿Tiene alguna idea de si se trata de un cambio reciente o si Mudlet siempre ha sido así?

Para ser honesto, parece que no estamos restableciendo algo que deberíamos en nuestro método (void) cTelnet::reset() . Simplemente no sé (todavía) qué podría ser. ¿Alguna idea, alguien ...?

Lo único que diría es que si deshabilito el gancho H_PRINT_PROMPT en master.c, el problema no ocurre en los segundos intentos de inicio de sesión, sin embargo, el hecho de que muestran la primera conexión con el gancho habilitado, pero fallan solo en los siguientes conexiones, a pesar de que el texto se está enviando a Mudlet, tengo dificultades para lanzar el problema a la biblioteca de barro o al controlador. El hecho de que al agregar la n en la solicitud de nombre de usuario y contraseña haga que Mudlet muestre la solicitud me hace pensar que hay un problema en Mudlet. (es decir, esto funciona: input_to ("get_name", INPUT_PROMPT, "¿Por qué nombre desea ser conocido? n"); pero provoca un retorno de línea después del indicador y la entrada está en la siguiente línea)

Además, no vemos este mismo problema en ningún otro cliente probado (telnet, tintin ++)

¿Eso ayuda en absoluto?

También tenemos este problema en StickMUD. @mfczureal y yo pasamos muchas horas tratando de sortearlo a través del juego, pero parece que este está relacionado con Mudlet.

Confirmado con LDmud 3.5.1 y Mudlet 3.17, pero esto ha estado en Mudlet durante bastante tiempo. Estoy bastante seguro de que noté el problema en alguna parte antes, pero no puedo encontrarlo espontáneamente. ¡Gracias por informar los detalles!

Bueno, lo que he escuchado suena como si no estuviéramos restableciendo algo cuando el servidor se desconecta; todo lo que tenemos que hacer es averiguar qué es diferente la segunda vez y volver a cambiarlo a cómo era la primera vez ...: gritar:

Intenté grabar una repetición para comparar, pero es diferente al original. Primera conexión: la pantalla está bien. Siguientes conexiones: La pantalla está apagada. Reproduciendo repetición en este momento: también visualización incorrecta durante la primera conexión.

A continuación, se muestra un ejemplo del comportamiento tras el primer inicio de sesión y los inicios de sesión sucesivos. GA está siendo enviado desde el juego.

Veo que esto todavía está marcado como "necesito más información". ¿Qué puedo proporcionar para ayudarlo a avanzar con este problema? Este problema nos impide seguir adelante con la implementación de GA en nuestro MUD de producción y realmente nos gustaría trabajar con ustedes para solucionarlo. Gracias

@SlySven ?

: pensando: Humm, es posible que un archivo de reproducción no sea suficiente porque puede que no refleje el comportamiento de desconexión / reconexión, por lo que tendré que iniciar sesión en un MUD que muestre este problema y supervise algunas variables. Tengo algunas sospechas, pero vivo. las pruebas realmente ayudarán. ¿Puedo iniciar sesión en cualquiera de sus MUD @mfczureal / @mpconley ?

Bueno, has estado en mi barro recientemente solucionando el problema de Discord, así que prueba Darkwind. :)

Ah, pero no sabía que @mfczureal en GitHub era ZureaL en Discord. :guiño:

Puede probar este problema conectándose a mg.mud.de:23

Inicie sesión como invitado con un nombre como gast luego vuelva a conectarse.

¿Solo comprobando si ha habido algún seguimiento de esto? Sigo manteniendo nuestra capacidad para implementar GA en producción y realmente me gustaría poder poner esto en práctica. ¡Gracias!

Necesitamos quitar la etiqueta de necesidad de más información y devolver la de alta prioridad :)

¡Hecho! Sin embargo, no estoy seguro de cuáles @SlySven para investigar esto. Si puede, intente profundizar también en el código de Mudlet para ver dónde va mal.

Intenté investigar esto, pero no podía estar seguro de estar experimentando lo que está informando. Realmente no entiendo cómo funcionan las cosas de GA, así que no estoy seguro de cómo las cosas de IRE Bugfix y todos esos factores influyen en todo. Traté de iniciar sesión en Darkwind pero estaban sucediendo cosas realmente extrañas con la interfaz de usuario descargable (que se estaba instalando como un paquete y un módulo y tardaba una eternidad en hacerlo cada vez que comenzaba) TBH No podía decir si estaba teniendo el problema que está informando; ni siquiera estoy seguro de haber tenido todas las perillas en la posición correcta.

: thought_balloon: Lo que creo que sería útil en el lado de Mudlet sería tener un conjunto temporal de métodos en Host y cTelnet y posiblemente principal TConsole y es TBuffer instancia que recopila y devuelve el estado de todos los miembros de la bandera bool posiblemente relevantes en esas clases y haga que informen justo después de que se haya completado el inicio de sesión (o cuando se muestre ese comportamiento diferente con las indicaciones). Esto sería para ver qué banderas están en un estado diferente después del primer inicio de sesión (donde las cosas son correctas) y las segundas y repetidas (donde no lo están). Sospecho firmemente que una de esas banderas (al menos) debe estar reset / set in cTelnet::reset() - como encontré que era necesario con el Host::mIsRemoteEchoingActive que agregué recientemente ...

¡Gracias por mirar! Ok, lo intentaré entonces.

No verlo con mg

Tampoco lo veo en Darkwind (tuve que _realmente_ excavar para encontrar la información de conexión; ¡proporciónalo en el informe la próxima vez!)

Nada en Stickmud:

Agregue los pasos exactos para reproducir el problema (preferiblemente sin tener que rastrear la creación de personajes) y veremos esto nuevamente. ¡Gracias chicos!

En este momento tenemos GA deshabilitado en nuestras instancias de producción y desarrollo debido a estos problemas. Uno de nuestros administradores va a crear una nueva instancia del dev MUD para que pueda volver a habilitar GA y pueda ser un campo de juego absoluto para probar cómo funciona GA en LDMud. Debería estar despierto más tarde esta noche y proporcionaré una actualización cuando esté listo

@ vadi2 @SlySven Utilice stickmud.com 7680 o el enlace StickMUD en Mudlet. Conéctese como jugador O para iniciar sesión como invitado escriba 'visita' en el inicio de sesión y pase el captcha. Después de conectarse, puede desconectar () y repetir el proceso anterior. En la segunda conexión y a partir de entonces, no verá el mensaje 'Dar su nombre' como estaba en la primera conexión hasta que ingrese un nombre de jugador o 'visita'.

El ejemplo que probó con mg muestra el defecto muy bien. Dejame explicar:

Observe cómo en el primer intento de conexión Wie heisst Du denn ("neu" fuer neuen Spieler)? se envía ANTES de responder gast y solo después de responder esa pregunta se le pregunta Bist Du maennlich oder weiblich: - El resto del procedimiento de inicio de sesión es irrelevante para este problema .

Ahora, en todos los intentos siguientes, no verá la línea Wie heisst Du denn antes de responder gast . En su lugar, debe responder antes de ver la pregunta y luego verá ambas preguntas en la misma línea.

¡Gracias!

: pensando:: confundido:: encogimiento de hombros:

Ah, tengo la sospecha furtiva de que el estado siempre que GA está habilitado o no no se restablece al volver a conectarse ... por lo que Mudlet todavía piensa que está habilitado, cuando el juego aún no lo ha habilitado (como mg.mud.de no habilítelo hasta que escriba gast ).

Cuando GA no está habilitado, Mudlet espera un poco antes de darse por vencido y mostrar el texto, pero cuando está activado, solo muestra el texto cuando llega un GA. Así que aquí, GA nunca llega, Mudlet espera una eternidad para mostrar el texto.

Avísame si esto soluciona el problema:

• linux: https://transfer.sh/guark/Mudlet-3.17.1-testing-PR2366-5f62ffd-linux-x64.AppImage.tar
• osx: https://transfer.sh/olHMX/Mudlet-3.17.1-testing-PR2366-5f62ffd.dmg
• ventanas: https://ci.appveyor.com/api/buildjobs/6adm501x5iimk8bn/artifacts/src%2Fmudlet.zip

hola @ vadi2 esto me funciona en OSX con StickMUD. ¡Gracias!

Bonito. Esto lo arregla en el lado de Mudlets. Una mejor solución sería habilitar GA en la conexión de inmediato (para que no vea No GA como en mg. No he probado stickmud)

Hasta ahora, habilitaremos GA tan pronto como confirmemos que son los clientes de Mudlet o Grapevine; de ​​lo contrario, los jugadores podrían activarlo si lo necesitan. GA no debe manejarse bien en algunos clientes.

Técnicamente, GA es parte del modelo NVT ( Network Virtual Terminal ), es decir, algo que se supone que proporciona un terminal predeterminado como parte del modelo semidúplex que implica Telnet. Reprimir Go Ahead no es una opción que siempre está de acuerdo con Mudlet, por lo que en realidad el otro extremo se requiere para proporcionar señales de GA. No me había dado cuenta completamente de esto antes ...

Esto parece mejorar la experiencia al conectarse a mg.mud.de 👍

Los comentarios sobre la necesidad (o no necesidad) de GA se discutieron en el # 1252 un poco más en profundidad, y MG parece funcionar bien con Mudlet simplemente enviando EOR en lugar de GA, que parece obsoleto.

Kebab señaló mi atención sobre este tema y me gustaría comentar un poco sobre GA / SGA. No estoy seguro, en qué otro lugar, así sea aquí ...

Tienes toda la razón. GA es un medio (histórico) de control de flujo. Y a menos que se negocie SGA, los socios de comunicación que cumplen con los estándares deben enviar GA cuando el otro socio puede enviarlo (es decir, hoy en día probablemente después de cada salida). Pero por el mismo argumento, los socios solo deben enviar una vez que recibieron un GA ... (que nadie piensa)

Desde mi punto de vista, la única forma razonable de lidiar con esto y cumplir con los estándares es negociar siempre SGA y deshacerse de los GA superfluos.

Esta es la razón por la que no soy amigo del uso de GA como un medio para la detección rápida (marcado de mensajes). Para hacer esto, debe habilitar Suppress-go-ahead para deshabilitar GA como un medio de control de flujo en telnet. Solo entonces podría usarlo con algún otro significado en la capa sobre telnet (marcando las indicaciones en la salida de MUD). Incluso si ignora los estándares de telnet aquí, de lo contrario, podría obtener GA para las solicitudes y, finalmente, para muchas otras salidas que no son de solicitud).
Un problema es que no hay una buena manera de negociar si un MUD usa GA para la detección rápida.

Además, SGA está AFAIR entrelazado con otras opciones de telnet como el modo NOECHO y CHARMODE / LINEMODE. Esta interdependencia complica aún más las cosas.

Morgengrauen usa EOR para marcar las solicitudes si se negocia TELOPT_EOR (de lo contrario, no marca las solicitudes) y no juega con SGA (porque eso haría que el comportamiento de negociación de telnet del mudlib sea significativamente más complicado; en este caso, el Mudlib tiene que cuidar de TELOPT_ECHO, TELOPT_SGA, TELOPT_COMPRESS y TELOPT_COMPRESS2 que no quiero hacer, esto es cosa del conductor) y deja todos los problemas de control de flujo a la máquina telnet de LDMud. Eso significa que Morgengrauen tiene el comportamiento predeterminado de los MUD que usan LDMud para GA / SGA.

Con respecto al comportamiento predeterminado de LDMud, actualmente no estoy muy seguro, pero @amotzkau ciertamente podría

La implementación predeterminada de LDMud es no dar ninguna indicación sobre un indicador (que puede tener razones históricas, anteriormente el indicador se escribió antes de llamar a input_to, por lo que el controlador tampoco tenía ninguna indicación de qué es un indicador).

Y LDMud usa SGA para indicar el modo char, que también tiene razones históricas. Sin SGA, se insta a los socios de comunicación a hablar solo cuando hayan recibido la AG de la contraparte y señalar con GA cuando hayan terminado de hablar. Entonces, esta secuencia de 'comando, GA - respuesta, GA' constituye efectivamente un estilo de modo de línea. Y muchos clientes consideran que aceptar la SGA es un modo char, porque ahora el cliente es libre de enviar los caracteres a medida que se ingresan. Y es por eso que SGA no se negocia al principio. Existe una opción de telnet LINEMODE que podría hacer lo mismo, pero que no es tan ampliamente adoptada por los clientes como SGA.

En respuesta a @SlySven, se requiere que todos los servidores envíen GA si no se acuerda SGA, eso es técnicamente correcto, pero eso también significa que el cliente no puede enviar nada nuevamente, después de haber enviado GA y no haber recibido GA. Y el servidor solo podría enviar una única respuesta antes de tener que esperar nuevamente un comando de usuario. Cualquier mensaje fuera de banda (eventos, acciones de otros usuarios) debe almacenarse en búfer hasta que el usuario ejecute otro comando. Ningún cliente o servidor de MUD se adhiere a eso, hasta donde yo sé.

El uso de GA para una indicación rápida seguiría ese proceso antiguo (el servidor finaliza su respuesta con GA, lo último en la respuesta es la indicación), pero ya nadie hace el resto de este proceso, por lo que eso no sirve como una buena justificación. Y siempre que se acuerde SGA (por lo que esto no concierne a Mudlet) GA no se enviará ni se ignorará cuando se reciba. Por lo tanto, otros clientes pueden ignorar la indicación de solicitud en modo char.