Mudlet: Texte GMCP/GA supprimé lors de la connexion

Ce antidate le fix je mets récemment (depuis la version 3.16.1) pour permettre enfin pour le serveur de négocier telnet option 1 (ECHO) et reprendre en écho à l'écran Mudlet du texte qui Mudlet envoie à l'arrière du serveur à Mudlet - de sorte que, s'il est fait correctement, les mots de passe que l'utilisateur tape dans la ligne de commande Mudlet ne s'affichent pas sur l'écran de profil principal par la suite s'ils ont l'option "faire écho à ce que je tape sur mon écran" - donc je suis disposé à l'ignorer comme cause sans plus d'informations.

Savez-vous s'il s'agit d'un changement récent ou si Mudlet a toujours été comme ça ?

Pour être honnête, il semble que nous ne réinitialisons pas quelque chose que nous devrions dans notre méthode (void) cTelnet::reset() - je ne sais pas (encore) ce que cela pourrait être - des idées, quelqu'un...?

La seule chose que je dirais est que si je désactive le hook H_PRINT_PROMPT dans master.c, le problème ne se produit pas lors des 2èmes tentatives de connexion, cependant, le fait qu'ils affichent la première connexion avec le hook activé, mais n'échoue que lors des suivantes connexions, malgré le fait que le texte est envoyé à Mudlet, j'ai du mal à lancer le problème à la mud lib ou au pilote. Le fait que l'ajout du n dans l'invite du nom d'utilisateur et du mot de passe amène Mudlet à afficher l'invite me fait penser qu'il y a un problème dans Mudlet. (c'est-à-dire que cela fonctionne : input_to("get_name", INPUT_PROMPT, "Par quel nom souhaitez-vous être connu ? n" ); mais provoque un retour de ligne après l'invite et l'entrée est alors sur la ligne suivante)

De plus, nous ne voyons ce même problème sur aucun autre client testé (telnet, tintin++)

Est-ce que cela vous aide?

Nous avons également ce problème sur StickMUD. @mfczureal et moi avons passé de nombreuses heures à essayer de le contourner tout au long du jeu, mais j'ai l'impression que celui-ci est lié à Mudlet.

Confirmé avec LDmud 3.5.1 et Mudlet 3.17 - mais cela est dans Mudlet depuis un certain temps. Je suis presque sûr d'avoir noté le problème quelque part auparavant, mais je ne peux pas le trouver spontanément. Merci d'avoir signalé les détails !

Eh bien, ce que j'ai entendu donne l'impression que nous ne réinitialisons pas quelque chose lorsque le serveur se déconnecte - tout ce que nous avons à faire est de déterminer ce qui est différent la deuxième fois et de revenir à ce qu'il était la première fois... :scream:

J'ai essayé d'enregistrer une rediffusion pour comparaison, mais c'est différent de l'original. Première connexion : l'affichage est correct. Connexions suivantes : L'affichage est éteint. Lecture en relecture à ce moment : affichage également erroné lors de la première connexion.

Voici un exemple du comportement lors de la première connexion et des connexions successives. GA est envoyé depuis le jeu.

Je vois que cela est toujours marqué comme "besoin de plus d'informations". Que puis-je fournir pour vous aider à faire avancer ce problème ? Ce problème nous empêche d'avancer dans le déploiement de GA dans notre MUD de production et nous aimerions vraiment travailler avec vous pour résoudre ce problème. Merci

@SlySven ?

:pensant: Humm, un fichier de relecture pourrait ne pas suffire car il peut ne pas refléter le comportement de déconnexion/reconnexion - je vais donc devoir me connecter à un MUD qui affiche ce problème et surveille quelques variables - j'ai quelques soupçons mais je vis les tests vont vraiment aider. Puis-je me connecter à l'un de vos MUD @mfczureal / @mpconley ?

Eh bien, vous avez récemment essayé de résoudre le problème de Discord, alors essayez Darkwind ? :)

Ah, mais je ne savais pas que @mfczureal sur GitHub était ZureaL sur Discord. :clin d'œil:

Vous pouvez essayer ce problème en vous connectant à mg.mud.de:23

Connectez-vous en tant qu'invité avec un nom comme gast puis reconnectez-vous.

Juste vérifier s'il y a eu un suivi à ce sujet ? Nous retardons toujours notre capacité à implémenter GA en prod et j'aimerais vraiment pouvoir mettre cela au lit. Merci!

Nous devons retirer l'étiquette de besoin de plus d'informations et celle de haute priorité :)

Terminé! Cependant, je ne sais pas quels @SlySven pour enquêter à ce sujet. Si vous le pouvez, essayez également de creuser dans le code de Mudlet pour voir où cela ne va pas.

J'ai essayé d'examiner cela, mais je ne pouvais pas vraiment être sûr d'avoir vécu ce que vous rapportez. Je ne comprends pas vraiment comment fonctionnent les trucs de GA, donc je ne sais pas comment les trucs de correction de bogues IRE et tout cela entre en ligne de compte. J'ai essayé de me connecter à Darkwind, mais il se passait des choses vraiment étranges avec l'interface utilisateur téléchargeable (qui était installée à la fois en tant que package et en tant que module et prenait du temps à le faire à chaque fois que je commençais) TBH Je ne pouvais pas dire si je avait le problème que vous signalez - je ne suis même pas sûr d'avoir tous les boutons dans la bonne position.

:thought_balloon: Ce que je pense serait utile du côté de Mudlet, ce serait d'avoir un ensemble temporaire de méthodes dans les Host et cTelnet et éventuellement le principal TConsole et c'est TBuffer instance qui rassemble et renvoie l'état de tous les membres drapeaux bool éventuellement pertinents dans ces classes et les fait rapporter juste après la fin de la connexion (ou lorsque ce comportement différent est affiché avec les invites). Ce serait de voir quels drapeaux sont dans un état différent après la première connexion (où les choses sont correctes) et les seconds et répétés (où ils ne le sont pas) - je soupçonne fortement qu'un de ces drapeaux (au moins) doit être réinitialiser/définir dans cTelnet::reset() - comme je l'ai trouvé était nécessaire avec le Host::mIsRemoteEchoingActive que j'ai récemment ajouté...

Merci d'avoir cherché ! Ok, je vais essayer alors.

Ne pas le voir avec mg

Ne pas le voir non plus dans Darkwind (il a fallu _vraiment_ creuser pour trouver les informations de connexion - veuillez les fournir dans le rapport la prochaine fois !)

Rien dans Stickmud :

Ajoutez les étapes exactes pour reproduire le problème (de préférence sans avoir à parcourir la création de personnage) et nous y reviendrons. Merci les gars!

À l'heure actuelle, nous avons désactivé GA dans nos instances de production et de développement en raison de ces problèmes. L'un de nos administrateurs va créer une nouvelle instance du dev MUD afin que je puisse réactiver GA et puisse être un terrain de jeu absolu pour tester le fonctionnement de GA dans LDMud. Devrait être levé plus tard ce soir et je fournirai une mise à jour quand ce sera prêt

@vadi2 @SlySven Veuillez utiliser stickmud.com 7680 ou le lien StickMUD dans Mudlet. Connectez-vous en tant que joueur OU pour vous connecter en tant qu'invité, tapez « visite » sur la connexion et passez le captcha. Après vous être connecté, vous pouvez lua disconnect() et répéter le processus ci-dessus. Lors de la deuxième connexion et par la suite, vous ne verrez pas l'invite « Donnez votre nom » comme c'était le cas lors de la première connexion jusqu'à ce que vous ayez entré un nom de joueur ou « visite ».

L'exemple que vous avez essayé à partir de mg affiche en effet très bien le défaut. Laissez-moi expliquer:

Remarquez comment, lors de la première tentative de connexion, Wie heisst Du denn ("neu" fuer neuen Spieler)? est envoyé AVANT de répondre gast et seulement après avoir répondu à cette question, on vous demande Bist Du maennlich oder weiblich: - Le reste de la procédure de connexion n'est pas pertinent pour ce problème .

Maintenant, dans toutes les tentatives suivantes, vous ne voyez pas la ligne Wie heisst Du denn avant de répondre gast . Au lieu de cela, vous devez répondre avant de voir la question, et vous verrez alors les deux questions sur la même ligne.

Je l'ai Merci!

:pensant: :confondu: :man_shruging:

Ah, je soupçonne que le statut lorsque GA est activé ou non n'est pas réinitialisé lors de la reconnexion ... donc Mudlet pense toujours qu'il est activé, alors que le jeu ne l'a pas encore activé (comme mg.mud.de ne le fait pas activez-le jusqu'à ce que vous tapiez gast ).

Lorsque GA n'est pas activé, Mudlet attend un peu avant d'abandonner et d'afficher le texte, mais lorsqu'il est activé, il n'affiche le texte que lorsqu'un GA arrive. Alors ici - GA ne vient jamais - Mudlet attend une éternité pour montrer le texte.

Faites-moi savoir si cela résout le problème :

• 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
• fenêtres : https://ci.appveyor.com/api/buildjobs/6adm501x5iimk8bn/artifacts/src%2Fmudlet.zip

salut @ vadi2 cela fonctionne pour moi sur OSX avec StickMUD. Merci!

Joli. Cela le corrige du côté des Mudlets. Une meilleure solution serait d'activer GA sur la connexion tout de suite (donc vous ne voyez pas Pas de GA comme dans mg. Je n'ai pas testé stickmud)

Jusqu'à présent, nous activons GA dès que nous confirmons qu'il s'agit des clients Mudlet ou Grapevine - sinon, les joueurs pourraient l'activer s'ils en ont besoin. L'AG ne doit pas être bien gérée chez certains clients.

Techniquement, GA fait partie du modèle NVT ( Network Virtual Terminal ), c'est-à-dire quelque chose qu'un terminal par défaut est censé fournir dans le cadre du modèle semi-duplex qu'implique Telnet. Supprimer Go Ahead n'est pas une option que Mudlet accepte jamais , donc en fait, l'autre extrémité est nécessaire pour fournir des signaux GA. Je ne m'en étais pas pleinement rendu compte avant...

Cela semble améliorer l'expérience de connexion à mg.mud.de 👍

Les commentaires sur le besoin (ou pas besoin) de GA ont été discutés un peu plus en profondeur dans le n° 1252, et MG semble bien fonctionner avec Mudlet en envoyant simplement EOR au lieu de GA, ce qui semble obsolète.

Kebab a attiré mon attention sur ce problème et j'aimerais commenter un peu GA/SGA. Je ne sais pas où d'autre, alors que ce soit ici...

Vous avez entièrement raison. GA est un moyen (historique) de contrôle de flux. Et à moins que SGA ne soit négocié, les partenaires de communication conformes aux normes doivent envoyer GA lorsque l'autre partenaire est autorisé à envoyer (c'est-à-dire de nos jours probablement après chaque sortie). Mais par le même argument, les partenaires ne doivent envoyer qu'une fois qu'ils ont reçu un AG... (ce que personne ne pense je pense)

De mon point de vue, la seule façon raisonnable de gérer cela et d'être conforme aux normes est de toujours négocier le SGA et de se débarrasser du GA superflu.

C'est la raison pour laquelle je ne suis pas un ami de l'utilisation de GA comme moyen de détection rapide (marquage des invites). Pour ce faire, vous devez activer Suppress-go-ahead pour désactiver le GA comme moyen de contrôle de flux dans telnet. Ce n'est qu'alors que vous pourrez l'utiliser avec une autre signification dans la couche au-dessus de telnet (marquage des invites dans la sortie MUD). Même si vous ignorez les normes telnet ici, vous pourriez autrement obtenir GA pour les invites et éventuellement pour de nombreuses autres sorties sans invite).
Un problème est qu'il n'y a pas de bonne façon de négocier si un MUD utilise GA pour une détection rapide.

De plus, SGA est AFAIR entrelacé avec d'autres options telnet comme le mode NOECHO et CHARMODE/LINEMODE. Cette interdépendance complique encore plus les choses.

Morgengrauen utilise EOR pour marquer les invites si TELOPT_EOR est négocié (il ne marque pas les invites autrement) et ne bricole pas avec SGA (car cela rendrait le comportement de négociation telnet de la mudlib considérablement plus compliqué - dans ce cas, la Mudlib doit m'occuper de TELOPT_ECHO, TELOPT_SGA, TELOPT_COMPRESS et TELOPT_COMPRESS2 que je ne veux pas faire, c'est du truc pour le pilote) et laisse toutes les questions de contrôle de flux à la machine telnet de LDMud. Cela signifie que Morgengrauen a le comportement par défaut des MUD utilisant LDMud pour GA/SGA.

Concernant le comportement par défaut du LDMud, je ne suis pas vraiment sûr actuellement, mais @amotzkau pourrait certainement

L'implémentation par défaut de LDMud ne donne aucune indication sur une invite (cela peut avoir des raisons historiques, auparavant l'invite était écrite avant d'appeler input_to, donc le pilote n'avait aucune indication non plus de ce qu'est une invite).

Et LDMud utilise SGA pour indiquer le mode char, qui a également des raisons d'historique. Sans SGA, les partenaires de communication sont priés de ne parler que lorsqu'ils ont reçu l'AG de l'homologue et de signaler à l'AG lorsqu'ils ont fini de parler. Ainsi, cette séquence de "commande, GA - réponse, GA" constitue effectivement un style en mode ligne. Et l'acceptation de SGA est alors considérée par de nombreux clients comme un mode char, car le client est désormais libre d'envoyer les caractères au fur et à mesure qu'ils sont saisis. Et c'est pourquoi SGA n'est pas négocié au début. Il existe une option telnet LINEMODE qui pourrait faire la même chose, mais qui n'est pas aussi largement adoptée par les clients que SGA.

En réponse à @SlySven que chaque serveur est tenu d'envoyer GA si SGA n'est pas accepté, c'est techniquement correct, mais cela signifie également que le client n'est pas autorisé à envoyer quoi que ce soit à nouveau, après avoir envoyé GA et non reçu GA. Et le serveur ne serait autorisé à envoyer qu'une seule réponse avant de devoir à nouveau attendre une commande utilisateur. Tous les messages hors bande (événements, actions d'autres utilisateurs) doivent être mis en mémoire tampon jusqu'à ce que l'utilisateur effectue une autre commande. Aucun client ou serveur MUD n'adhère à cela, pour autant que je sache.

L'utilisation de GA pour l'indication d'invite suivrait cet ancien processus (le serveur termine sa réponse avec GA, la dernière chose dans la réponse est l'invite), mais plus personne ne fait le reste de ce processus, donc cela ne constitue pas une bonne justification. Et chaque fois que SGA est convenu (donc cela ne concerne pas Mudlet), GA ne doit pas être envoyé et ignoré lors de sa réception. Par conséquent, d'autres clients peuvent ignorer l'indication d'invite en mode char.