Mudlet: L'enregistrement de l'événement sysIrcMessage n'appelle parfois pas la fonction associée

Il existe un numéro antérieur à ce sujet sur https://github.com/Mudlet/Mudlet/issues/1469, mais il a été fermé après que l'affiche originale a cessé de participer et que certaines modifications connexes ont été apportées.

Résumé de la vidéo :

• Vous avez un script qui est déclenché par une chaîne de texte sur l'écran de connexion du jeu, de sorte que lorsque vous vous connectez au jeu, votre client est censé se connecter à IRC et rejoindre un canal et envoyer un message sortant, les messages entrants d'IRC sont censé être répercuté sur votre écran de jeu. Les messages de bienvenue sur IRC et les messages d'un canal passent tous par cette même fonction.
• Vous vous connectez au jeu, il ouvre la fenêtre IRC, vous montrant dans le canal. Vous avez un client IRC régulier sur le côté qui vous observe rejoindre.
• La fenêtre de jeu peut ou non avoir des échos. Vous pouvez discuter depuis l'autre client IRC et il sera même vu dans la fenêtre IRC de mudlet mais n'exécute pas le code lua pour l'écho dans la fenêtre du jeu. Cela dure toute la session, le redémarrage de mudlet peut ou non aider.

J'ai essayé moi-même et j'ai immédiatement pu recréer le problème, pas de manière fiable, mais il est d'environ 50%. Il n'y a pas de schéma que je puisse dire, alternant d'abord, puis une séquence de bien et une séquence de mal. Je n'ai pas eu à fermer et redémarrer mudlet pour voir un changement, à la place j'ai laissé un autre profil ouvert, ce qui signifie que je pouvais fermer ce profil et le rouvrir, et cela peut ou non le réparer comme le redémarrage l'a fait.

Ce message "Bonjour de mudlet" n'atteint en aucun cas la chaîne. Je suppose que c'est parce qu'il se trouve dans le même bloc de code que les éléments de connexion et qu'il doit probablement terminer la connexion avant d'envoyer des messages, il est probablement ignoré au lieu d'être mis en file d'attente pour l'envoi lors de l'adhésion. Je ne sais pas si ce code pourrait être scindé et déclenché par une jointure de serveur réussie ou une acceptation de jointure de canal du serveur ou quelque chose du genre. J'oublierai cette partie pour l'instant car je pense que c'est un comportement attendu.

Dans la vidéo, entre 1:00 et 1:02, votre fenêtre de jeu n'affiche aucun message de "bienvenue sur IRC" lors de la connexion à IRC même si votre fenêtre IRC est ouverte et a déjà rejoint le canal. Mais ensuite, vous ouvrez la fenêtre des déclencheurs et elle affiche soudainement tous les messages de bienvenue et ainsi de suite que vous avez reçus plus tôt. Je pense donc que ces messages entrants ont été correctement intégrés à un événement et ajoutés à une file d'attente d'événements, puis la file d'attente d'événements a été arrêtée et l'ouverture de la fenêtre des déclencheurs l'a redémarrée.

Lorsque j'ai tapé la commande 'lua', les choses ont parfois démarré de la même manière pour moi. Parfois, j'ai reçu les premiers messages de bienvenue, puis ils se sont arrêtés, et j'ai pu taper « lua » et lui faire afficher le reste des éléments de bienvenue et le chat entrant qui n'ont pas encore été traités.

Dans la fonction /src/Host.cpp#L1397 Host::postIrcMessage(a,b,c), l'événement sysIrcMessage est créé, puis raiseEvent est appelé.
Cela me semble assez logique... créez un événement, mettez 4 chaînes avec l'une disant "sysIrcMessage" et les autres avec les autres données, étiquetez-les comme 4 chaînes, alimentez-le à raiseEvent().

Cette fonction Host::postIrcMessage est appelée par la boîte de dialogue IRC qui formate une version texte et html du message et envoie du texte à lua et html à la fenêtre de discussion IRC.
C'est dans /src/dlgIRC.cpp#L613
Donc, puisque la fenêtre de discussion IRC est correctement mise à jour et affiche la discussion entrante, cela devrait signifier que la chose lua se produit en même temps, car la mise à jour de la fenêtre de discussion IRC vient à la ligne 618, après la partie lua à la ligne 606. Donc il dépasse ce code lorsqu'il y parvient, mais est ensuite bloqué quelque part plus tard. Étant donné qu'il peut être redémarré et géré correctement, je suppose que l'événement est construit correctement, mais qu'il n'est tout simplement pas appelé quand il devrait l'être. Parfois, vous le pouvez, mais vous ne pourrez peut-être pas le redémarrer.

Pour tenter d'enregistrer une rediffusion à l'instant (je ne sais pas si les rediffusions incluent des données extérieures comme celle-ci), j'ai essayé d'ouvrir le profil hors ligne, puis de cliquer sur se reconnecter, et de cette façon, je ne vois aucun écho. J'ai suffisamment essayé pour ne pas penser que ce n'est qu'une séquence de malchance.

Dans tous les cas cependant, la fenêtre de discussion IRC s'affiche correctement et a reçu toutes les discussions que j'ai envoyées de mon autre client IRC pour autant que je sache.

Dans la vidéo, entre 1:00 et 1:02, votre fenêtre de jeu n'affiche aucun message de "bienvenue sur IRC" lors de la connexion à IRC même si votre fenêtre IRC est ouverte et a déjà rejoint le canal. Mais ensuite, vous ouvrez la fenêtre des déclencheurs et elle affiche soudainement tous les messages de bienvenue et ainsi de suite que vous avez reçus plus tôt. Je pense donc que ces messages entrants ont été correctement intégrés à un événement et ajoutés à une file d'attente d'événements, puis la file d'attente d'événements a été arrêtée et l'ouverture de la fenêtre des déclencheurs l'a redémarrée.

J'ai remarqué cela aussi il y a quelques semaines et j'ai donc essayé diverses choses pour "le relancer" chaque fois que je suis dans un mauvais état. Comme le reste du problème, cela semble assez aléatoire. Parfois, l'ouverture des fenêtres de paramètres ou le lancement d'une commande lua déclenchera la file d'attente des événements, mais seulement environ 50% du temps dans mon expérience.

Maintenant que je l'ai testé à l'aide de la fenêtre de débogage, je vois qu'il affiche les messages qui s'affichent en direct dans la fenêtre de débogage. Le script s'est donc exécuté et il a construit le "X dit Y" comme indiqué dans la fenêtre de débogage, il ne met tout simplement pas à jour la fenêtre principale pour refléter qu'il est là jusqu'à plus tard. Apparemment, il ne s'accroche pas à l'événement IRC entrant et ne l'exécute pas plus tard comme je l'avais soupçonné à l'origine ... c'est juste à ce moment-là que le résultat devient visible. Il fait l'événement mais est interrompu quelque part avant de rafraîchir l'écran.

Donc je suppose qu'il y a deux problèmes :

• Vous pouvez apparemment exécuter feedTriggers(string) à partir de ce code et le faire apparaître dans la fenêtre principale plus tard. Le premier couple ira bien, puis les autres ne mettront pas à jour l'écran par eux-mêmes.
• La moitié des sessions, il n'exécute pas cet événement sysIrcMessage (même si la fenêtre IRC fonctionne). Probablement un problème d'enregistrement de cet événement, car si cela fonctionne une fois, cela fonctionne pour toute la session.

J'ai vu une note dans le manuel concernant feedTriggers qui dit que feedTriggers est censé faire apparaître la chaîne à côté du message suivant si vous n'utilisez pas de nouvelle ligne. Mais ce script a une nouvelle ligne, il ne devrait donc pas attendre la sortie du jeu ou un feu vert, etc. Pour l'instant, j'ai ajouté send ("\n"), ce qui signifie que mon invite du jeu met au moins à jour mon écran pour le moment.

Dans Ubuntu, j'ai compilé mudlet et je l'ai exécuté et il semble faire le script comme prévu. Je veux dire que l'affichage est toujours retardé jusqu'au trafic du jeu, mais au moins, il déclenche le script lors des messages IRC entrants. Je l'ai essayé une vingtaine de fois de suite et ça marche bien. Ensuite, j'ai téléchargé et exécuté la version Linux 4.8.2, et c'est moitié-moitié comme le faisait Windows.

Eh bien, peut-être que la version de développement contient des correctifs concernant ce problème ?

J'en ai donc essayé à nouveau avec Windows 10. J'avais toujours utilisé le 4.8.2, j'ai donc téléchargé le fichier zip pour tester le récent PR 3872 construit par le bot du compilateur. Il a le même problème, environ 50% du temps, il n'enregistre pas le gestionnaire.

Cela peut être lié au fonctionnement de feedTriggers() . Selon le manuel de feedTriggers() , cette fonction nécessite que Mudlet "reçoive" les données du jeu avant que les tiggers ne soient traités.

Pour citer une note de la page :

Remarque : Le système de traitement des déclencheurs nécessite également que certaines données soient (ou semblent être) reçues du jeu pour traiter les feedTriggers(), utilisez donc un send ("\n") pour obtenir une nouvelle invite (donc de nouvelles données) correctement. après ou assurez-vous que le texte comprend un caractère de nouvelle ligne "\n" afin de simuler une ligne de données du serveur de jeu.

Alors, essayez d'ajouter send("\n") à la fonction onIRCMessage ou d'envelopper la ligne IRC entrante avec des caractères de nouvelle ligne et voyez si cela aide.

• La moitié des sessions, il n'exécute pas cet événement sysIrcMessage (même si la fenêtre IRC fonctionne). Probablement un problème d'enregistrement de cet événement, car si cela fonctionne une fois, cela fonctionne pour toute la session.

Je ne pense plus qu'il s'agisse d'un problème d'enregistrement de l'événement, mais plutôt d'un problème d'appel. Il semble s'arrêter à cette instruction if où il vérifie s'il s'agit du client "hôte par défaut".

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

Cette partie est obsolète depuis l'époque où vous pouviez exécuter l'IRC sans ouvrir de profil. Maintenant, il doit être associé à un profil et il n'y a pas d'« hôte par défaut » en août 2019. https://github.com/Mudlet/Mudlet/pull/2950

Ce code obsolète ne devrait être qu'une légère surcharge pour un chemin qui n'est plus emprunté. Je n'ai pas encore cherché à savoir pourquoi isDefaultHostClient() se vérifie parfois lorsque le client IRC est en fait associé à un profil ouvert.

J'ai supprimé l'ancien code, vous pouvez donc essayer ce PR sous Windows :

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

Cela semble avoir résolu le problème ! J'ai essayé environ 20 repros et je n'ai pas réussi à reproduire le problème.

Le client semble avoir encore besoin d'un certain type d'entrée pour pousser le premier événement, mais un clic n'importe où le fera - y compris un clic pour minimiser la fenêtre IRC, ce qui est nécessaire pour ramener le focus sur la fenêtre principale de toute façon.

Merci à vous deux! Très bon travail. :)