Mudlet: El servidor IRE no negocia MXP

Eso podría explicar el código original, pero podrían no ser los únicos, y no podemos romper las cosas de forma predeterminada y agregar soluciones para todos los juegos que existen.

Cierto; sin embargo, entonces el problema recaerá en Evennia y otros juegos de MUD que también lo negocian, @ vadi2 : riendo: así que podrías estar jugando con la papa caliente. : hombre_encogiéndose de hombros:

Según Evennia, ¡mushclient funciona para ellos! Puede que no tenga que ser una elección.

Interesante. ¿Así que simplemente usamos MXP por defecto para continuar? (y poner un comentario en algún lugar para hacer referencia a este problema ...)

Bueno, no, tenemos que encontrar una solución que funcione tanto para Evennia como para IRE. Para que Evennia no escape <> antes de que se negocie MXP y para que IRE haga que MXP funcione de alguna manera sin que ellos lo negocien.

Esto es lo difícil que tenemos que hacer. A los usuarios no les importa si funciona en uno u otro, quieren que Mudlet simplemente funcione: man_shrugging:

tal vez cree una función Lua que pueda habilitar mxp para el usuario. He notado que no tenemos la funcionalidad Lua (lazy) que nos permite apagar o encender mxp directamente. con esa idea, podríamos acoplarlos en un perfil.

al mismo tiempo, es útil tener esa funcionalidad para que los codificadores de barro y los usuarios de los mudlets puedan crear un alias para apagarlo y encenderlo para observarlo fácilmente.

Esa sigue siendo una solución alternativa para los usuarios de IRE. ¿Cómo lo hace MUSHclient? ¿Funciona realmente tanto para Evennia / ChatMUD como para IRE?

Debo señalar que estaba 'bajo comando' de forma predeterminada en el cliente mush.

Ah, está bien, entonces IRE salió de la caja.

Estoy pensando en intentar implementar algo similar en mushclient en forma de:

1) 'sí / no / al comando'
2) también debe proporcionar información sobre herramientas útil que explique qué opción es adecuada para qué servidor. por ejemplo, para 'sí':
"Se recomienda seleccionar esta opción si está jugando juegos IRE (achaea, aetolia, starmourn, etc.).

3) implemente esto en la opción XML (no abandone la opción force_mxp_negotiation) en su lugar utilícelo para importar la opción a una nueva variable. esto es convertir el perfil antiguo en un perfil nuevo en una actualización.
4) cada perfil predeterminado tendrá una opción XML que puede ser cualquiera de esas opciones habilitadas / deshabilitadas / comando adaptado a cada juego respectivo.

Esto no funcionará, no podemos tener un cliente complicado que requiera más botones y controles a medida que crece solo para mantener las cosas funcionando (y no agregar nuevas características).

¿Y si detectamos automáticamente MXP y lo habilitamos?

Entonces queremos detectar mxp en forma de [#z y también detectar la negociación?

Si. Básicamente, agregue una solución para IRE (hasta que lo solucionen).

Me sorprende que no lo negocien dado lo extensa que es su implementación de MXP, ¿estás muy seguro de que ese es el caso?

mushclient o IRE?

IRA

por lo que reuní, se puede habilitar mediante su configuración. aunque todavía no implementan la negociación para mxp. como me comuniqué directamente con Tecton sobre esto, dice que podría implementarse en la próxima actualización del motor de rapto. (en el que no sé cuándo será la próxima actualización).

De acuerdo, agreguemos una opción de detección automática para los casos en que un motor comienza a forzarlo (como lo hicimos antes ... ja)

¿Tuvimos esta detección automática antes de este o ese mismo código antes de modificarlos?

No, recuerda que asumimos que MXP estaba encendido sin que el servidor lo negociara, y por eso IRE funcionó.

luego
1) de forma predeterminada, dejamos mxp activado (con mMxp en falso en init) obviamente IRE puede activarlo mediante (esc) [4z
2) si se negocia algún servidor de lodo, entonces mMXP cambiará a verdadero. (AKA código 0 línea abierta)

¿bien?

Creo que sí, estás diciendo que MXP se puede activar mediante una negociación adecuada o si buscamos la cadena mágica. De lo contrario, está desactivado y < , > aparecen bien. Suena bien.

detección automática mágica. : p haré un parche mágico de relaciones públicas mañana.

Recuerde que hay MUD por ahí que ni siquiera saben / se preocupan por MXP, así que alteran su salida si usan < > por ejemplo, alguna forma de resaltado de un valor en una lista de modo que desde un punto de vista HTML / XML parece que una etiqueta no está activada. ¡Oh! O, al menos, ¡NO debería estar ENCENDIDO por defecto ...! :no ver el mal:

Debería poder disparar la magia de detección automática poniendo algo en TBuffer::translateToPlainText(std::string& data, const bool isFromServer) después de la línea:

                case static_cast<quint8>('z'):

que interceptará TODAS las secuencias de códigos de control MXP, pero solo actuará sobre ellas si las condiciones son las adecuadas. Debería, tal vez cerrar el disparo con isFromServer para que solo los datos del servidor (y las reproducciones correspondientes) hagan cosquillas en su código; hacerlo evitará falsos positivos de feedTriggers( ... ) llamadas por los scripts del usuario / empaquetador ...: smiling_imp:

@SlySven gracias. Lo investigaré.