Mudlet: El registro del evento sysIrcMessage a veces no llama a la función asociada

Hay un problema anterior sobre esto en https://github.com/Mudlet/Mudlet/issues/1469 pero se cerró después de que el póster original dejó de participar y se realizaron algunas ediciones relacionadas.

Resumen del video:

• Tiene una secuencia de comandos que se activa mediante una cadena de texto en la pantalla de inicio de sesión del juego, de modo que cuando se conecta al juego, su cliente debe conectarse a IRC y unirse a un canal y enviar un mensaje saliente, los mensajes entrantes de IRC son se supone que se repetirá en la pantalla de tu juego. El material de 'bienvenida a IRC' y los mensajes de un canal pasan por esta misma función.
• Te conectas al juego, aparece la ventana de IRC, mostrándote en el canal. Usted tiene un cliente de IRC regular en el lado que lo observa unirse.
• La ventana del juego puede tener o no un eco de las cosas. Puede chatear desde el otro cliente de IRC e incluso se verá en la ventana de IRC de mudlet, pero no ejecuta el código lua para hacer eco en la ventana del juego. Esto dura toda la sesión, reiniciar el mudlet puede ayudar o no.

Probé esto por mí mismo e inmediatamente pude recrear el problema, no de manera confiable, pero es aproximadamente el 50%. No puedo decir ningún patrón, alternando al principio y luego una racha de bueno y una racha de malo. No tuve que cerrar y reiniciar Mudlet para ver un cambio, en su lugar, dejé otro perfil abierto, lo que significa que podría cerrar este perfil y volver a abrirlo, y eso puede o no solucionarlo de la misma manera que lo hizo al reiniciar.

Ese mensaje de "Hola desde mudlet" nunca llega al canal en ningún caso. Supongo que esto se debe a que está en el mismo bloque de código que el material de conexión y es probable que tenga que terminar de conectarse antes de enviar mensajes, probablemente no se tenga en cuenta en lugar de estar en la cola para enviarlo al unirse. No estoy seguro de si tal vez ese código podría dividirse y activarse mediante una unión exitosa al servidor o la aceptación de la unión al canal desde el servidor o algo así. Olvidaré esa parte por ahora porque creo que es un comportamiento esperado.

En el video, entre la 1:00 y la 1:02, la ventana de su juego no muestra ningún mensaje de 'bienvenida a IRC' por conectarse a IRC aunque su ventana de IRC esté abierta y ya se haya unido al canal. Pero luego abres la ventana de desencadenadores, y de repente muestra todos los mensajes de bienvenida y todo eso que habías recibido antes. Entonces, creo que esos mensajes entrantes se integraron correctamente en un evento y se agregaron a una cola de eventos y luego la cola de eventos se detuvo, y al abrir la ventana de desencadenadores, se inició de nuevo.

Cuando escribí el comando 'lua', a veces comenzaba las cosas de la misma manera para mí. Algunas veces, recibí los primeros mensajes de bienvenida y luego se detuvieron, y pude escribir 'lua' y hacer que mostrara el resto de las cosas de bienvenida y el chat entrante que aún no se había manejado.

En la función /src/Host.cpp#L1397 Host :: postIrcMessage (a, b, c), se crea el evento sysIrcMessage y luego se llama a raiseEvent.
Me parece bastante lógico ... crear un evento, poner 4 cadenas con una que diga "sysIrcMessage" y las otras con los otros datos, etiquetarlas como 4 cadenas, alimentarlo para raiseEvent ().

Esa función Host :: postIrcMessage es llamada por el cuadro de diálogo IRC que formatea una versión de texto y html del mensaje y envía texto a lua y html a la ventana de chat de IRC.
Eso está en /src/dlgIRC.cpp#L613
Entonces, dado que la ventana de chat de IRC se actualiza correctamente y muestra el chat entrante, eso tendría que significar que lo lua ocurre al mismo tiempo, porque la actualización de la ventana de chat de IRC viene en la línea 618, después de la parte de lua en la línea 606. Entonces está superando ese código cuando llega a él, pero luego se retiene en algún lugar más tarde. Dado que se puede reiniciar y manejar correctamente, me imagino que el evento se está construyendo correctamente, simplemente no se está llamando cuando debería ser. A veces puede, pero es posible que no pueda reiniciarlo.

En un intento de grabar una repetición en este momento (no estoy seguro de si las repeticiones incluyen datos externos como ese), intenté abrir el perfil sin conexión y luego hacer clic en volver a conectar, y al hacerlo de esta manera, nunca veo ninguno de los ecos. Lo intenté lo suficiente como para que no crea que esto sea solo una mala racha.

Sin embargo, en todos los casos, la ventana de chat de IRC aparece correctamente y ha recibido cada chat que he enviado desde mi otro cliente de IRC hasta donde yo sé.

En el video, entre la 1:00 y la 1:02, la ventana de su juego no muestra ningún mensaje de 'bienvenida a IRC' por conectarse a IRC aunque su ventana de IRC esté abierta y ya se haya unido al canal. Pero luego abres la ventana de desencadenadores, y de repente muestra todos los mensajes de bienvenida y todo eso que habías recibido antes. Entonces, creo que esos mensajes entrantes se integraron correctamente en un evento y se agregaron a una cola de eventos y luego la cola de eventos se detuvo, y al abrir la ventana de desencadenadores, se inició de nuevo.

También me di cuenta de esto hace unas semanas, por lo que he estado probando varias cosas para "reactivarlo" cada vez que me encuentro en un mal estado. Como el resto del problema, parece bastante aleatorio. A veces, abrir ventanas de configuración o disparar un comando lua activará la cola de eventos, pero solo alrededor del 50% del tiempo en mi experiencia.

Ahora que lo probé usando la ventana de depuración, veo que muestra los mensajes que aparecen en vivo en la ventana de depuración. Así que el script se ejecutó y construyó la "X dice Y" como se muestra en la ventana de depuración, simplemente no actualiza la ventana principal para reflejar que está ahí hasta más tarde. Aparentemente, no se está aferrando al evento de IRC entrante y ejecutando el evento más tarde como había sospechado originalmente ... ahí es cuando el resultado se vuelve visible. Está realizando el evento, pero se interrumpe en algún lugar antes de actualizar la pantalla.

Entonces supongo que hay dos problemas:

• Aparentemente, puede ejecutar feedTriggers (cadena) desde este código y hacer que no aparezca en la ventana principal hasta más tarde. La primera pareja estará bien y luego el resto no actualiza la pantalla por su cuenta.
• La mitad de las sesiones no ejecuta ese evento sysIrcMessage (aunque la ventana de IRC está funcionando). Probablemente sea un problema registrar ese evento, porque si funciona una vez, funciona para toda la sesión.

Vi una nota en el manual sobre feedTriggers que dice que se supone que feedTriggers hace que la cadena aparezca junto con el siguiente mensaje si no usa una nueva línea. Pero este script tiene una nueva línea allí, por lo que no debería estar esperando la salida del juego o un visto bueno, etc. Por ahora agregué send ("\ n"), lo que significa que mi mensaje del juego al menos actualiza mi pantalla por ahora.

En Ubuntu, compilé mudlet y lo ejecuté y parece estar haciendo el script como se esperaba. Me refiero a que la visualización sigue retrasada hasta el tráfico del juego, pero al menos activa el script con los mensajes de IRC entrantes. Lo probé unas 20 veces seguidas y funcionó bien. Luego descargué y ejecuté la versión 4.8.2 de Linux, y eso es mitad y mitad como lo había estado haciendo Windows.

Bueno, tal vez la compilación de desarrollo tenga algunas correcciones con respecto a este problema.

Así que probé algunos con Windows 10 nuevamente. Había estado usando 4.8.2 todo el tiempo, así que descargué el archivo zip para probar el PR 3872 reciente creado por el bot del compilador. Tiene el mismo problema, ~ 50% de las veces no registra el controlador.

Esto puede estar relacionado con la forma en que funciona feedTriggers() . Según el manual de feedTriggers () , esta función requiere que Mudlet "reciba" datos del juego antes de que se procesen los tiggers.

Para citar una nota de la página:

Nota: El sistema de procesamiento de disparadores también requiere que se reciban (o aparezcan) algunos datos del juego para procesar el feedTriggers (), así que use un envío ("\ n") para obtener un nuevo mensaje (por lo tanto, nuevos datos) correctamente después o asegúrese de que el texto incluya un carácter de nueva línea "\ n" para simular una línea de datos del servidor de juegos.

Entonces, intente agregar send("\n") a la función onIRCMessage o envuelva la línea IRC entrante con caracteres de nueva línea y vea si eso ayuda.

• La mitad de las sesiones no ejecuta ese evento sysIrcMessage (aunque la ventana de IRC está funcionando). Probablemente sea un problema registrar ese evento, porque si funciona una vez, funciona para toda la sesión.

Ya no creo que sea un problema para registrar el evento, sino más bien un problema con la llamada. Parece detenerse en esta declaración if donde verifica si es el cliente 'host predeterminado'.

https://github.com/Mudlet/Mudlet/blob/development/src/dlgIRC.cpp#L612 -L614

Esta parte está desactualizada desde que solía poder ejecutar el IRC sin abrir un perfil. Ahora tiene que estar asociado con un perfil y no hay un 'host predeterminado' a partir de agosto de 2019. https://github.com/Mudlet/Mudlet/pull/2950

Sin embargo, ese código desactualizado debería ser solo una pequeña hinchazón para un camino que ya no se toma. Todavía no he mirado para ver por qué isDefaultHostClient () a veces se vuelve verdadero cuando el cliente de IRC está asociado con un perfil abierto.

He eliminado el código anterior, por lo que puede probar este PR en Windows:

https://make.mudlet.org/snapshots/ccfee3/Mudlet-4.9.1-testing-pr3927-24eab7a5-windows.zip

¡Esto parece haber resuelto el problema! Intenté unas 20 repeticiones y no pude reproducir el problema.

Parece que el cliente todavía requiere algún tipo de entrada para impulsar el primer evento, pero un clic en cualquier lugar lo hará, incluido un clic para minimizar la ventana de IRC, que es necesario para volver a enfocar la ventana principal de todos modos.

¡Gracias a los dos! Muy buen trabajo. :)