Mudlet: O servidor IRE não negocia para MXP

Isso pode explicar o código original - mas eles podem não ser os únicos, e não podemos quebrar as coisas por padrão e adicionar soluções alternativas para cada jogo lá fora.

Verdadeiro; entretanto, o problema recairá sobre Evennia e outros jogos de MUD que negociam por isso também, @ vadi2 : rindo: então você pode estar brincando com a batata quente. : man_shrugging:

De acordo com Evennia, o mushclient funciona para eles! Pode não ser uma escolha.

Interessante. então nós apenas assumimos o padrão MXP para continuar? (e para colocar um comentário em algum lugar para fazer referência a este problema ...)

Bem, não, temos que encontrar uma solução que funcione para Evennia e IRE. Para Evennia não escapar de <> antes que o MXP seja negociado e para IRE de alguma forma fazer o MXP funcionar sem que eles o negociem.

Esta é a coisa mais difícil que temos que fazer. Os usuários não se importam se funciona em um ou outro, eles querem que Mudlet apenas funcione: man_shrugging:

talvez crie uma função Lua que possa habilitar o mxp on para o usuário. Percebi que não temos a funcionalidade Lua (lazy) que nos permite desligar ou ligar o mxp diretamente. com essa ideia, poderíamos juntá-los em um perfil.

ao mesmo tempo, é útil ter essa funcionalidade para que codificadores de lama e usuários de mudlet possam criar um alias para desligar e ligar para observá-lo facilmente.

Isso ainda é uma solução alternativa para usuários IRE. Como o MUSHclient faz isso - e realmente funciona para Evennia / ChatMUD e IREs fora da caixa?

Devo observar que era 'no comando' por padrão no cliente mush.

Ok, então o IRE saiu da caixa.

Estou pensando em tentar implementar algo semelhante em mushclient na forma de:

1) 'sim / não / sob comando'
2) também deve fornecer uma dica de ferramenta útil que explica qual opção é adequada para qual servidor. por exemplo, para 'sim':
"Recomenda-se selecionar esta opção se você estiver jogando jogos IRE (achaea, aetolia, starmourn, etc).

3) implemente isso na opção XML (não abandone a opçãoforce_mxp_negotiation) em vez disso, use-a para importar a opção para a nova variável. isso está convertendo o perfil antigo em um novo perfil em uma atualização.
4) cada perfil padrão terá a opção XML que pode ser qualquer uma das opções ativada / desativada / comando personalizado para cada respectivo jogo.

Isso não vai funcionar, não podemos ter um cliente complicado que requer mais botões e fobs à medida que cresce apenas para manter as coisas funcionando (e não adicionar novos recursos).

Que tal detectarmos automaticamente o MXP e ativá-lo?

Portanto, queremos detectar mxp na forma de [#z e também detectar a negociação?

Sim. Basicamente, adicione uma solução alternativa para IRE (até que eles consigam).

Estou surpreso que eles não negociem, dada a extensão de sua implementação MXP - você tem certeza absoluta de que é esse o caso?

Mushclient ou IRE?

IRA

pelo que eu reuni, pode ser ativado por sua configuração. embora, eles não implementem negociação para mxp ainda. como eu comuniquei diretamente com Tecton sobre isso, ele disse que pode ser implementado na próxima atualização do motor do rapture. (no qual não sei quando será a próxima atualização).

Ok - vamos adicionar uma opção de detecção automática para os casos em que um motor começa a forçá-lo (como tínhamos antes ... ha)

tivemos essa detecção automática antes deste ou daquele mesmo código antes de modificá-los?

Nah, lembre-se de que assumimos que o MXP estava ligado sem o servidor negociar por ele - e é por isso que o IRE funcionou.

então
1) por padrão, deixamos mxp ativado (com mMxp como falso no init) obviamente IRE pode ativá-lo por (esc) [4z
2) se e se algum servidor de lama for negociado, o mMXP será alterado para verdadeiro. (AKA código 0 linha aberta)

Boa?

Acho que sim - você está dizendo que o MXP pode ser ativado por meio de negociação adequada ou por nós verificando a string mágica. Caso contrário, está desligado e < , > aparece OK. Soa bem.

detecção automática mágica. : p farei um patch mágico de RP amanhã.

Lembre-se de que existem MUDs por aí que nem mesmo sabem / se preocupam com MXP, então distorcem sua saída se acontecerem de usar < > para, digamos, alguma forma de destaque de um valor em uma lista de modo que, do ponto de vista HTML / XML, parece que uma tag não está ativada. O que oh! Ou, pelo menos, NÃO deve estar LIGADO por padrão ...! : see_no_evil:

Você deve ser capaz de disparar a magia de detecção automática colocando algo em TBuffer::translateToPlainText(std::string& data, const bool isFromServer) após a linha:

                case static_cast<quint8>('z'):

que interceptará TODAS as sequências de código de controle MXP, mas somente atuará sobre elas se as condições forem adequadas. Você deve, talvez, interromper o disparo com isFromServer modo que apenas os dados do servidor (e replays correspondentes) agradem seu código - fazer isso evitará falsos positivos de feedTriggers( ... ) chamadas pelos scripts do usuário / empacotador ...: smiling_imp:

@SlySven obrigado. Vou dar uma olhada.