Mudlet: Texto GMCP / GA suprimido no login

Isso antecede uma correção que coloquei recentemente ( desde a versão 3.16.1) para finalmente permitir que o servidor negocie a opção 1 do telnet (ECHO) e assuma o eco na tela do Mudlet se eles tiverem a opção "ecoar o que eu digito na minha tela" definida - então, estou disposto a descontar isso como uma causa sem mais informações.

Você tem ideia se essa é uma mudança recente ou Mudlet sempre foi assim?

Para ser honesto, parece que não estamos redefinindo algo que deveríamos em nosso método (void) cTelnet::reset() - eu só não sei (ainda) o que pode ser - alguém tem alguma ideia ...?

A única coisa que direi é que se eu desabilitar o gancho H_PRINT_PROMPT no master.c, o problema não ocorre nas 2ª tentativas de login, porém, o fato de aparecerem a primeira conexão com o gancho habilitado, mas falham apenas nas subsequentes conexões, apesar do fato de que o texto está sendo enviado para Mudlet, tenho dificuldade em jogar o problema para o lama lib ou driver. O fato de adicionar n no prompt de nome de usuário e senha faz com que Mudlet exiba o prompt me faz pensar que há um problema no Mudlet. (ou seja, isso funciona: input_to ("get_name", INPUT_PROMPT, "Por qual nome você deseja ser conhecido? n"); mas causa um retorno de linha após o prompt e a entrada é então na próxima linha)

Além disso, não vemos esse mesmo problema em nenhum outro cliente testado (telnet, tintin ++)

Isso ajuda em tudo?

Também temos esse problema no StickMUD. @mfczureal e eu passamos muitas horas tentando contornar isso durante o jogo, mas parece que este é relacionado a Mudlet.

Confirmado com LDmud 3.5.1 e Mudlet 3.17 - mas isso está em Mudlet há algum tempo. Tenho certeza de que observei o problema em algum lugar antes, mas não consigo localizá-lo espontaneamente. Obrigado por relatar os detalhes!

Bem, o que ouvi parece que não estamos reiniciando algo quando o servidor se desconecta - tudo o que temos que fazer é descobrir o que está diferente na segunda vez e voltar a como era da primeira vez ...: grito:

Tentei gravar um replay para comparação, mas é diferente do original. Primeira conexão: a tela está boa. Seguintes conexões: Display está desligado. Reproduzindo o replay neste momento: Também é exibido errado durante a primeira conexão.

Aqui está um exemplo do comportamento no primeiro login e logins sucessivos. GA está sendo enviado do jogo.

Vejo que ainda está marcado como "preciso de mais informações". O que posso fornecer para ajudá-lo a resolver esse problema? Esse problema está nos impedindo de prosseguir com a implantação do GA em nosso MUD de produção e realmente gostaríamos de trabalhar com vocês para consertar isso. Obrigado

@SlySven ?

: pensando: Humm, um arquivo de repetição pode não ser suficiente porque pode não refletir o comportamento de desconexão / reconexão - então, vou precisar fazer login em um MUD que exibe esse problema e monitora algumas variáveis ​​- Tenho algumas suspeitas, mas vivo o teste vai realmente ajudar. Posso obter um login em qualquer um dos seus MUDs @mfczureal / @mpconley ?

Bem, você esteve na minha lama recentemente solucionando o problema do Discord, então tente Darkwind? :)

Ah, mas eu não sabia que @mfczureal no GitHub era ZureaL no Discord. :piscadela:

Você pode tentar esse problema conectando-se a mg.mud.de:23

Faça login como um convidado com o nome gast e reconecte.

Apenas verificando se houve algum acompanhamento sobre isso? Ainda mantendo nossa capacidade de implementar o GA em produção e eu realmente gostaria de poder colocar isso para dormir. Obrigado!

Precisamos remover o rótulo de necessidade de mais informações e o de alta prioridade de volta :)

Feito! Não tenho certeza de quais são os planos de

Eu tentei investigar isso, mas não tinha certeza se estava experimentando o que você está relatando. Eu realmente não entendo como as coisas do GA funcionam, então não tenho certeza de como as coisas do Bugfix do IRE e todos os fatores que influenciam isso tudo. Eu tentei entrar no Darkwind, mas estava tendo coisas muito estranhas acontecendo com a interface do usuário para download (que estava sendo instalada como um pacote e um módulo e demorava muito para fazer isso cada vez que eu iniciava) TBH Eu não sabia se eu estava tendo o problema que você está relatando - nem tenho certeza se coloquei todos os botões na posição certa.

: Thought_balloon: O que eu acho que seria útil no lado do Mudlet seria ter um conjunto temporário de métodos em Host e cTelnet e possivelmente TConsole e é TBuffer instância que reúne e retorna o estado de todos os membros da sinalização bool possivelmente relevantes nessas classes e os faz relatar logo após o login ser concluído (ou quando esse comportamento diferente é mostrado com os prompts). Isso seria para ver quais sinalizadores estão em um estado diferente após o primeiro login (onde as coisas estão corretas) e os segundos e repetidos (onde não estão) - eu suspeito fortemente que um desses sinalizadores (pelo menos) precisa estar redefinir / definir em cTelnet::reset() - como eu achei necessário com o Host::mIsRemoteEchoingActive que eu adicionei recentemente ...

Obrigado por olhar! Ok, vou tentar então.

Não vejo com mg

Também não o vi no Darkwind (tive que _realmente_ cavar para encontrar as informações de conexão - forneça no relatório da próxima vez!)

Nada no Stickmud:

Adicione as etapas exatas para reproduzir o problema (de preferência sem ter que se arrastar pela criação do personagem) e veremos isso novamente. Obrigado rapazes!

No momento, desativamos o GA em nossas instâncias prod e dev devido a esses problemas. Um de nossos administradores vai ativar uma nova instância do dev MUD para que eu possa reativar o GA e ser um playground absoluto para testar como o GA funciona no LDMud. Deve ser mais tarde esta noite e eu farei uma atualização quando estiver pronto

@ vadi2 @SlySven Use stickmud.com 7680 ou o link StickMUD em Mudlet. Conecte-se como jogador OU para fazer o login como Visitante digite 'visita' no login e passe o captcha. Depois de conectar, você pode se conectar () e repetir o processo acima. Na segunda conexão e depois disso, você não verá o prompt 'Dê seu nome' como era na primeira conexão até que você insira um nome de jogador ou 'visita'.

O exemplo que você experimentou em mg realmente mostra o defeito perfeitamente. Deixe-me explicar:

Observe como na primeira tentativa de conexão Wie heisst Du denn ("neu" fuer neuen Spieler)? é enviado ANTES de você responder gast e somente após responder a essa pergunta Bist Du maennlich oder weiblich: - O resto do procedimento de login é irrelevante para este problema .

Agora, em todas as tentativas seguintes, você não vê a linha Wie heisst Du denn antes de responder gast . Em vez disso, você precisa responder antes de ver a pergunta e, então, verá as duas perguntas na mesma linha.

Ok, obrigado!

: pensando:: confundido:: man_shrugging:

Ah, tenho uma leve suspeita de que o status sempre que o GA está habilitado ou não é redefinido ao se reconectar ... então Mudlet ainda pensa que está habilitado, quando o jogo ainda não o habilitou (como mg.mud.de não habilite-o até digitar gast ).

Quando o GA não está habilitado, Mudlet espera um pouco antes de desistir e mostrar o texto, mas com ele ativado, ele só mostra o texto quando um GA vem. Então aqui - GA nunca vem - Mudlet espera uma eternidade para mostrar o texto.

Informe se isso corrige o 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
• windows: https://ci.appveyor.com/api/buildjobs/6adm501x5iimk8bn/artifacts/src%2Fmudlet.zip

oi @ vadi2 isso funciona para mim no OSX com StickMUD. Obrigado!

Agradável. Isso corrige no lado dos Mudlets. Uma solução melhor seria habilitar o GA na conexão imediatamente (para que você não veja Nenhum GA como no mg. Não testei o stickmud)

Até agora, estamos habilitando o GA assim que confirmarmos que são os clientes Mudlet ou Grapevine - caso contrário, os jogadores podem ativá-lo se precisarem. O GA não deve ser bem tratado em alguns clientes.

Tecnicamente, o GA faz parte do modelo NVT ( Network Virtual Terminal ), ou seja, algo que um terminal padrão deve fornecer como parte do modelo half-duplex que o Telnet implica. Suprimir o avanço não é uma opção com a qual Mudlet jamais concorde, então, na verdade, a outra extremidade é necessária para fornecer sinais de GA. Eu não tinha percebido isso completamente antes ...

Isso parece melhorar a experiência de conexão com mg.mud.de 👍

Comentários sobre a necessidade (ou não necessidade) de GA foram discutidos em # 1252 com um pouco mais de profundidade, e MG parece funcionar bem com Mudlet apenas enviando EOR em vez de GA, que parece obsoleto.

Kebab chamou minha atenção para esse problema e eu gostaria de comentar um pouco sobre o GA / SGA. Não tenho certeza, onde mais, que seja aqui ...

Você está totalmente certo. GA é um meio (histórico) de controle de fluxo. E, a menos que o SGA seja negociado, os parceiros de comunicação em conformidade com o padrão precisam enviar GA quando o outro parceiro tiver permissão para enviar (ou seja, hoje em dia provavelmente após cada saída). Mas, pelo mesmo argumento, os parceiros devem enviar apenas uma vez que receberam um GA ... (o que ninguém, eu acho)

Do meu ponto de vista, a única maneira razoável de lidar com isso e estar em conformidade com o padrão é sempre negociar o SGA e se livrar do GA supérfluo.

Esta é a razão pela qual não sou amigo de usar o GA como meio de detecção de prompt (marcação de prompts). Para fazer isso, você precisa habilitar Suppress-go-ahead para desabilitar o GA como meio de controle de fluxo em telnet. Só então você poderia usá-lo com algum outro significado na camada acima do telnet (marcando prompts na saída do MUD). Mesmo se você ignorar os padrões telnet aqui, você poderia obter GA para prompts e, eventualmente, para muitas outras saídas não-prompt).
Um problema é que não há uma maneira legal de negociar se um MUD usa o GA para detecção imediata.

Além disso, SGA é AFAIR entrelaçado com outras opções de telnet, como o modo NOECHO e CHARMODE / LINEMODE. Essa interdependência complica ainda mais as coisas.

Morgengrauen usa EOR para marcar prompts se TELOPT_EOR for negociado (ele não marca prompts de outra forma) e não brinca com SGA (porque isso tornaria o comportamento de negociação telnet do mudlib significativamente mais complicado - neste caso, o Mudlib tem que cuido de TELOPT_ECHO, TELOPT_SGA, TELOPT_COMPRESS e TELOPT_COMPRESS2 que não quero fazer, isso é coisa do driver) e deixa todos os problemas de controle de fluxo para a máquina telnet do LDMud. Isso significa que Morgengrauen tem o comportamento padrão de MUDs usando LDMud para GA / SGA.

Com relação ao comportamento padrão do LDMud, atualmente não tenho certeza, mas @amotzkau certamente poderia

A implementação padrão do LDMud é não dar nenhuma indicação sobre um prompt (isso pode ter razões históricas, anteriormente o prompt era escrito antes de chamar input_to, então o driver também não tinha nenhuma indicação do que é um prompt).

E o LDMud usa SGA para indicar o modo char, que também tem motivos históricos. Sem o SGA, os parceiros de comunicação são incentivados a falar apenas quando receberem o GA da contraparte e sinalizar com o GA quando tiverem terminado de falar. Portanto, esta sequência de 'comando, GA - resposta, GA' constitui efetivamente um estilo de modo de linha. E concordar com o SGA é visto por muitos clientes como o modo char, porque o cliente agora está livre para enviar os caracteres à medida que são inseridos. E é por isso que o SGA não é negociado no início. Há uma opção telnet do LINEMODE que poderia fazer o mesmo, mas não é tão amplamente adotada pelos clientes quanto o SGA.

Em resposta a @SlySven que todo servidor é obrigado a enviar GA se o SGA não for acordado, isso é tecnicamente correto, mas também significa que o cliente não tem permissão para enviar nada novamente, depois de ter enviado GA e não recebido GA. E o servidor só teria permissão para enviar uma única resposta antes de ter que esperar por um comando do usuário novamente. Quaisquer mensagens fora da banda (eventos, ações de outros usuários) devem ser armazenadas em buffer até que o usuário execute outro comando. Nenhum cliente ou servidor MUD adere a isso, até onde eu sei.

Usar o GA para indicação de prompt seguiria aquele processo antigo (o servidor termina sua resposta com GA, a última coisa na resposta é o prompt), mas ninguém faz mais o resto do processo, então isso não serve como uma boa justificativa. E sempre que o SGA for acordado (de modo que isso não diga respeito a Mudlet), o GA não deve ser enviado e ignorado quando recebido. Portanto, outros clientes podem ignorar a indicação do prompt no modo char.