Mudlet: GMCP/GA-Text wird bei der Anmeldung unterdrückt

Dies ist älter als ein Fix, den ich kürzlich ( seit der Release- Version 3.16.1) eingefügt des Textes übernehmen kann, den Mudlet an den Server zurück an Mudlet sendet - damit, wenn es richtig gemacht wird, Passwörter, die der Benutzer in die Mudlet-Befehlszeile eingibt, danach nicht auf dem Hauptprofilbildschirm angezeigt werden, wenn er die Option "Echo was ich auf meinem Bildschirm tippe" aktiviert hat - also möchte ich das ignorieren als Ursache ohne weitere Informationen.

Haben Sie eine Ahnung, ob dies eine kürzliche Änderung ist oder Mudlet schon immer so war?

Um ehrlich zu sein, es hört sich so an, als würden wir nichts zurücksetzen, was wir in unserer (void) cTelnet::reset() -Methode tun sollten - ich weiß nur (noch) nicht, was es sein könnte - hat jemand eine Idee ...?

Das einzige, was ich sagen würde, ist, dass wenn ich den H_PRINT_PROMPT-Hook in master.c deaktiviere, das Problem beim 2. trotz der Tatsache, dass der Text an Mudlet gesendet wird, habe ich Schwierigkeiten, das Problem an die Mud-Lib oder den Treiber zu werfen. Die Tatsache, dass das Hinzufügen des n in der Eingabeaufforderung für Benutzername und Kennwort dazu führt, dass Mudlet die Eingabeaufforderung anzeigt, lässt mich vermuten, dass in Mudlet ein Problem vorliegt. (dh das funktioniert: input_to("get_name", INPUT_PROMPT, "Unter welchem ​​Namen möchten Sie bekannt sein?n" ); bewirkt aber einen Zeilenrücksprung nach dem Prompt und input steht dann in der nächsten Zeile)

Außerdem sehen wir dasselbe Problem bei keinem anderen getesteten Client (Telnet, Tintin++).

Hilft das überhaupt?

Wir haben dieses Problem auch bei StickMUD. @mfczureal und ich haben viele Stunden damit verbracht, das Spiel zu umgehen, aber es fühlt sich so an, als ob dieses mit Mudlet zu tun hat.

Bestätigt mit LDmud 3.5.1 und Mudlet 3.17 - aber das ist schon länger in Mudlet. Ich bin mir ziemlich sicher, dass ich das Problem schon einmal irgendwo bemerkt habe, kann es aber nicht spontan finden. Danke, dass du die Details gemeldet hast!

Nun, was ich gehört habe, hört sich so an, als würden wir nichts zurücksetzen, wenn der Server die Verbindung trennt - alles , was wir tun müssen, ist herauszufinden, was beim zweiten Mal anders ist und es wieder so zu ändern, wie es beim ersten Mal war... :scream:

Ich habe versucht, zum Vergleich eine Wiederholung aufzunehmen, aber sie unterscheidet sich vom Original. Erste Verbindung: Display ist in Ordnung. Folgende Anschlüsse: Display ist aus. Wiedergabe der Wiedergabe zu diesem Zeitpunkt: Auch falsche Anzeige bei der ersten Verbindung.

Hier ist ein Beispiel für das Verhalten bei der ersten Anmeldung und nachfolgenden Anmeldungen. GA wird vom Spiel gesendet.

Ich sehe, dass dies immer noch als "Weitere Informationen erforderlich" markiert ist. Was kann ich Ihnen zur Verfügung stellen, um dieses Problem zu lösen? Dieses Problem hindert uns daran, die Bereitstellung von GA in unserem Produktions-MUD voranzutreiben, und wir würden gerne mit euch daran arbeiten, dieses Problem zu beheben. Vielen Dank

@SlySven ?

:denken: Hmm, eine Wiedergabedatei reicht möglicherweise nicht aus, da sie möglicherweise nicht das Verhalten beim Trennen / erneuten Verbinden widerspiegelt - also muss ich mich bei einem MUD anmelden, das dieses Problem anzeigt und ein paar Variablen überwacht - ich habe einen Verdacht, aber live Testen wird wirklich helfen. Kann ich mich bei einem Ihrer MUDs @mfczureal / @mpconley anmelden ?

Nun, du warst kürzlich auf meinem Schlamm, um das Discord-Ding zu beheben, also versuch es mit Darkwind? :)

Ah, aber ich wusste nicht , dass @mfczureal auf GitHub ZureaL auf Discord war. :zwinkern:

Sie können dieses Problem beheben, indem Sie eine Verbindung zu mg.mud.de:23

Melden Sie sich als Gast mit einem Namen wie gast und verbinden Sie sich dann erneut.

Nur um zu sehen, ob es dazu eine Nachverfolgung gegeben hat? Wir haben immer noch unsere Fähigkeit, GA in Prod zu implementieren, und ich würde das wirklich gerne ins Bett bringen. Vielen Dank!

Wir müssen das Etikett "Mehr Informationen benötigen" von diesem und das mit hoher Priorität zurückbekommen :)

Fertig! Ich bin mir jedoch nicht sicher, was @SlySven plant, dies zu untersuchen. Wenn Sie können, versuchen Sie auch, in Mudlet-Code zu graben, um zu sehen, wo er schief läuft.

Ich habe versucht, dies zu untersuchen, aber ich konnte nicht wirklich sicher sein, ob ich das erlebt habe, was Sie berichten. Ich verstehe nicht wirklich, wie das GA-Zeug funktioniert, also bin ich mir nicht sicher, wie das IRE-Bugfix-Zeug und all diese Faktoren in das Ganze einfließen. Ich habe versucht, mich bei Darkwind anzumelden, aber mit der herunterladbaren Benutzeroberfläche (die sowohl als Paket als auch als Modul installiert wurde und jedes Mal eine Ewigkeit brauchte, um dies zu tun) passierten wirklich seltsame Dinge. TBH Ich konnte nicht sagen, ob ich hatte das Problem, von dem Sie berichten - ich bin mir nicht einmal sicher, ob ich alle Knöpfe in der richtigen Position hatte.

:thought_balloon: Was meiner Meinung nach auf der Mudlet-Seite hilfreich wäre, wäre, einen temporären Satz von Methoden in den Host und cTelnet und möglicherweise im Haupt TConsole und es ist TBuffer Instanz, die den Status aller möglicherweise relevanten bool Flag- Mitglieder in diesen Klassen sammelt und zurückgibt und sie direkt nach Abschluss der Anmeldung melden lässt (oder wenn dieses unterschiedliche Verhalten mit den Eingabeaufforderungen angezeigt wird). Dies wäre, um zu sehen, welche Flags sich nach dem ersten Login in einem anderen Zustand befinden (wo die Dinge richtig sind) und dem zweiten und wiederholten (wo sie nicht sind) - ich vermute stark, dass eines dieser Flags (zumindest) sein muss zurücksetzen/einstellen in cTelnet::reset() - wie ich fand, war es mit dem Host::mIsRemoteEchoingActive notwendig, das ich kürzlich hinzugefügt habe ...

Danke fürs Suchen! Okay, dann probiere ich es mal.

Nicht sehen mit mg

Auch in Darkwind nicht zu sehen (musste _wirklich_ graben, um die Verbindungsinformationen zu finden - bitte beim nächsten Mal im Bericht angeben!)

Nichts in Stickmud:

Fügen Sie die genauen Schritte hinzu, um das Problem zu reproduzieren (vorzugsweise ohne die Charaktererstellung durchsuchen zu müssen) und wir werden uns das noch einmal ansehen. Danke Leute!

Derzeit haben wir aufgrund dieser Probleme GA in unseren Produkt- und Entwicklungsinstanzen deaktiviert. Einer unserer Admins wird eine neue Instanz des Dev MUD erstellen, damit ich GA wieder aktivieren und ein absoluter Spielplatz zum Testen der Funktionsweise von GA in LDMud sein kann. Sollte später am Abend aufstehen und ich werde ein Update bereitstellen, wenn es fertig ist

@vadi2 @SlySven Bitte benutzen Sie stickmud.com 7680 oder den StickMUD-Link in Mudlet. Verbinden Sie sich als Spieler ODER um sich als Gast anzumelden, geben Sie beim Login "Besuch" ein und übergeben Sie das Captcha. Nachdem Sie eine Verbindung hergestellt haben, können Sie lua Disconnect() und den obigen Vorgang wiederholen. Bei der zweiten Verbindung und danach sehen Sie die Aufforderung „Give your name“ wie bei der ersten Verbindung erst, nachdem Sie einen Spielernamen oder „visit“ eingegeben haben.

Das Beispiel, das Sie von mg versucht haben, zeigt den Fehler tatsächlich gut an. Lassen Sie mich erklären:

Beachten Sie, wie beim ersten Verbindungsversuch Wie heisst Du denn ("neu" fuer neuen Spieler)? gesendet wird, BEVOR Sie gast beantworten und erst nach Beantwortung dieser Frage werden Bist Du maennlich oder weiblich: gefragt .

Jetzt sehen Sie bei allen folgenden Versuchen die Zeile Wie heisst Du denn bevor Sie gast antworten. Stattdessen müssen Sie antworten, bevor Sie die Frage sehen, und sehen dann beide Fragen in derselben Zeile.

Danke, verstanden!

:denken: :verwirrt: :man_shrugging:

Ah, ich habe den leisen Verdacht, dass der Status, wenn GA aktiviert ist oder nicht, beim erneuten Verbinden nicht zurückgesetzt wird ... also denkt Mudlet immer noch, dass er aktiviert ist, wenn das Spiel es noch nicht aktiviert hat (wie mg.mud.de nicht aktivieren Sie es, bis Sie gast ).

Wenn GA nicht aktiviert ist, wartet Mudlet etwas, bevor es aufgibt und den Text anzeigt, aber wenn es eingeschaltet ist, zeigt es den Text nur an, wenn ein GA kommt. Also hier - GA kommt nie - Mudlet wartet ewig, um den Text zu zeigen.

Lassen Sie mich wissen, ob das Problem damit behoben ist:

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

Hallo @vadi2 das funktioniert bei mir auf OSX mit StickMUD. Vielen Dank!

Schön. Dies behebt es auf der Mudlets-Seite. Eine bessere Lösung wäre, GA sofort bei der Verbindung zu aktivieren (damit Sie kein GA wie in mg sehen. Stickmud nicht getestet)

Bisher aktivieren wir GA, sobald wir bestätigen, dass es sich um die Mudlet- oder Grapevine-Clients handelt – andernfalls könnten Spieler sie bei Bedarf aktivieren. GA muss in einigen Clients nicht gut gehandhabt werden.

Technisch GA ist ein Teil des NVT ( Network Virtual Terminal ) -Modell , dh etwas , dass ein Standard - Terminal soll als Teil des Halbduplex - Modell schaffen , dass Telnet impliziert. Suppress Go Ahead ist keine Option, der Mudlet jemals zustimmt, daher ist das andere Ende tatsächlich erforderlich , um GA-Signale bereitzustellen. Das war mir vorher nicht ganz klar...

Dies scheint die Erfahrung beim Verbinden mit mg.mud.de zu verbessern 👍

Kommentare über die Notwendigkeit (oder keine Notwendigkeit) von GA wurden in Nr. 1252 etwas ausführlicher diskutiert, und MG scheint mit Mudlet gut zu funktionieren, indem es einfach EOR anstelle von GA sendet, was veraltet erscheint.

Kebab hat mich auf dieses Thema aufmerksam gemacht und ich möchte etwas zu GA/SGA kommentieren. Ich bin mir nicht sicher, wo sonst, also sei es hier...

Du hast völlig recht. GA ist ein (historisches) Mittel zur Flusskontrolle. Und wenn SGA nicht ausgehandelt wird, müssen standardkonforme Kommunikationspartner GA senden, wenn der andere Partner senden darf (dh heutzutage wahrscheinlich nach jeder Ausgabe). Aber nach dem gleichen Argument müssen die Partner nur senden, wenn sie eine GA erhalten haben ... (was niemand glaube ich)

Aus meiner Sicht ist der einzig vernünftige Weg, damit umzugehen und standardkonform zu sein, immer SGA zu verhandeln und die überflüssige GA loszuwerden.

Dies ist der Grund, warum ich kein Freund davon bin, GA als Mittel zur Prompt-Erkennung (Markierung von Prompts) zu verwenden. Um dies zu tun, müssen Sie Suppress-grünes Licht ermöglichen , die GA als Mittel zur Flusskontrolle in Telnet zu deaktivieren. Erst dann könnten Sie es mit einer anderen Bedeutung in der Schicht über telnet verwenden (Markieren von Eingabeaufforderungen in der MUD-Ausgabe). Selbst wenn Sie die Telnet-Standards hier ignorieren, könnten Sie ansonsten GA für Eingabeaufforderungen und schließlich für viele andere, nicht-aufforderungsbezogene Ausgaben erhalten).
Ein Problem ist, dass es keine gute Möglichkeit gibt, zu verhandeln, wenn ein MUD GA zur sofortigen Erkennung verwendet.

Darüber hinaus ist SGA AFAIR mit anderen Telnet-Optionen wie dem NOECHO-Modus und dem CHARMODE/LINE-MODE verknüpft. Diese gegenseitige Abhängigkeit verkompliziert die Sache noch mehr.

Morgengrauen verwendet EOR zum Markieren von Prompts, wenn TELOPT_EOR ausgehandelt ist (es markiert sonst keine Prompts) und bastelt nicht an SGA herum (denn das würde das Telnet-Aushandlungsverhalten der Mudlib deutlich komplizierter machen - in diesem Fall muss die Mudlib kümmere mich um TELOPT_ECHO, TELOPT_SGA, TELOPT_COMPRESS und TELOPT_COMPRESS2, was ich nicht möchte, das ist Sache für den Treiber) und überlässt alle Fragen der Flusskontrolle der Telnet-Maschine von LDMud. Das heißt, Morgengrauen hat das Standardverhalten von MUDs, die LDMud für GA/SGA verwenden.

Bezüglich des Default-Verhaltens des LDMud bin ich mir derzeit nicht wirklich sicher, aber @amotzkau könnte sicherlich mehr Details dazu sagen.

Die Standardimplementierung von LDMud besteht darin, keinen Hinweis auf eine Eingabeaufforderung zu geben (das kann historische Gründe haben, früher wurde die Eingabeaufforderung vor dem Aufrufen von input_to geschrieben, sodass der Treiber auch keinen Hinweis darauf hatte, was eine Eingabeaufforderung ist).

Und LDMud verwendet SGA, um den Zeichenmodus anzuzeigen, was auch historische Gründe hat. Ohne SGA werden die Kommunikationspartner angehalten, erst zu sprechen, wenn sie die GA vom Gegenüber erhalten haben und mit GA zu signalisieren, wenn sie fertig gesprochen haben. Diese Sequenz von 'Befehl, GA - Antwort, GA' bildet also effektiv einen Zeilenmodus-Stil. Und die Zustimmung zu SGA wird dann von vielen Clients als Zeichenmodus angesehen, da der Client jetzt die Zeichen so senden kann, wie sie eingegeben werden. Aus diesem Grund wird SGA nicht am Anfang verhandelt. Es gibt eine LINEMODE-Telnet-Option, die das gleiche tun könnte, die jedoch von den Kunden nicht so weit verbreitet ist wie SGA.

Als Antwort auf @SlySven, dass jeder Server verpflichtet ist, GA zu senden, wenn SGA nicht zugestimmt wird, ist das technisch korrekt, bedeutet aber auch, dass der Client nichts mehr senden darf, nachdem er GA gesendet und keine GA erhalten hat. Und der Server darf nur eine einzige Antwort senden, bevor er erneut auf einen Benutzerbefehl warten muss. Alle Out-of-Band-Nachrichten (Ereignisse, Aktionen anderer Benutzer) müssen gepuffert werden, bis der Benutzer einen anderen Befehl ausführt. Kein MUD-Client oder -Server hält sich daran, soweit ich weiß.

Die Verwendung von GA für die Aufforderungsanzeige würde diesem alten Prozess folgen (der Server beendet seine Antwort mit GA, das letzte in der Antwort ist die Aufforderung), aber niemand führt den Rest dieses Prozesses mehr aus, so dass dies keine gute Begründung ist. Und wann immer SGA vereinbart wird (also Mudlet nicht betrifft), werden GA nicht gesendet und bei Erhalt ignoriert. Daher können andere Clients die Eingabeaufforderung im Zeichenmodus ignorieren.