Mudlet: Registering the sysIrcMessage event sometimes doesn't call the associated function

[jacben]

Brief summary of issue:

Sometimes registerAnonymousEventHandler("sysIrcMessage", onIrcMessage) does not call the function when an IRC message is received.

Video repro here: https://youtu.be/seLTuTSOtsk (see description for timestamps)

Steps to reproduce the issue:

1. Install oragono IRC server for Windows (https://github.com/oragono/oragono/blob/stable/docs/MANUAL.md#windows)
2. Follow the oragono instructions to set up the server and initiate it
3. Create a script in Mudlet with the following code:

function connectToIRC()
  setIrcServer("127.0.0.1", 6667)
  setIrcNick("Ditto")
  setIrcChannels({"#botchannel"})
  registerAnonymousEventHandler("sysIrcMessage", onIRCMessage)
  sendIrc("#botchannel", "Hello from Mudlet!")  
end

function onIRCMessage(_, sender, target, message)
  local myString = sender .. " says " .. message .. ".\n"
  feedTriggers(myString)
end

1. Trigger connectToIRC() when the client connects to a MUD, or trigger it manually
2. Observe that Mudlet sometimes does not echo the IRC message received upon connecting
3. Use an external IRC client such as HexChat to send a message to the channel
4. Observe that Mudlet sometimes does not echo the IRC message received from the user which can be seen in the Mudlet IRC client

Error output:

Connecting to an IRC server with sysIrcMessage registered, and an echo function, should echo all IRC messages

Extra information, such as Mudlet version, operating system and ideas for how to solve:

Mudlet 4.6.2
Windows 10 version 1909 build 18363.815
Restarting Mudlet eventually gets it to fire correctly.

[atari2600tim]

There is an earlier issue about this at https://github.com/Mudlet/Mudlet/issues/1469 but it was closed after the original poster stopped participating and some related edits were made.

Summary of the video:

• You have a script that is triggered by a string of text on the game's login screen, so that when you connect to the game then your client is meant to connect to IRC and join a channel and send an outgoing message, incoming messages from IRC are supposed to be echoed to your game screen. The 'welcome to IRC' stuff and messages from a channel all go through this same function.
• You connect to the game, it pops up the IRC window, showing you in the channel. You have a regular IRC client over on the side that observes you joining.
• The game window may or may not have the stuff echoed to it. You can chat from the other IRC client and it will even be seen in mudlet's IRC window but does not run the lua code to echo it in game window. This lasts for the session, restarting mudlet may or may not help.

I tried this out myself and was immediately able to recreate the problem, not reliably, but it is about 50%. There's no pattern I can tell, alternating at first and then a streak of good and a streak of bad. I did not have to close and restart mudlet to see a change, instead I left some other profile open meaning that I could close this profile and open it back up, and that may or may not fix it same as restarting did.

That "Hello from mudlet" message never reaches the channel in any case. I assume that this is because it is in the same block of code as the connection stuff and it likely has to finish connecting before sending messages, is probably disregarded instead of queued up to send upon joining. I'm not sure if maybe that code could be split off and triggered by a successful server join or channel join acceptance from the server or something. I'll forget that part for now because I think it is expected behavior.

In the video, between 1:00 and 1:02, your game window does not show any 'welcome to IRC' messages from connecting to IRC even though your IRC window is open and has already joined the channel. But then you open up the triggers window, and it suddenly shows all the welcome messages and whatnot that you had received earlier. So I think those incoming messages were built properly into an event and added to an event queue and then the event queue was stopped, and opening up the triggers window jump started it back.

When I typed the 'lua' command then it sometimes jump started things in the same way for me. Some times, I got the first welcome messages and then they stopped, and I was able to type 'lua' and have it show the rest of the welcome stuff and incoming chat that wasn't handled yet.

In /src/Host.cpp#L1397 function Host::postIrcMessage(a,b,c), the sysIrcMessage event is created and then raiseEvent is called.
It looks logical enough to me... create an event, put 4 strings with one saying "sysIrcMessage" and the others with the other data, label them as 4 strings, feed it to raiseEvent().

That Host::postIrcMessage function gets called by the IRC dialog thing which formats a text and html version of the message and sends text to lua and html to IRC chat window.
That's in /src/dlgIRC.cpp#L613
So since the IRC chat window is updated correctly and shows the incoming chat, that would have to mean that the lua thing happens at the same time, because updating the IRC chat window comes on line 618, after the lua part at line 606. So it is getting past that code when it gets to it, but then is being held up somewhere later. Given that it can be restarted and get handled properly, I figure that the event is getting built properly, just not being called when it should be. Sometimes you can, but you may not be able to restart it.

In an attempt to record a replay just now (not sure if replays include outside data like that), I tried opening up the profile offline and then clicking reconnect, and doing it this way, I never see any of the echoes. I tried it enough that I don't think this is just an unlucky streak.

In every case though, the IRC chat window does come up properly and has received every chat that I've sent from my other IRC client as far as I can tell.

[jacben]

In the video, between 1:00 and 1:02, your game window does not show any 'welcome to IRC' messages from connecting to IRC even though your IRC window is open and has already joined the channel. But then you open up the triggers window, and it suddenly shows all the welcome messages and whatnot that you had received earlier. So I think those incoming messages were built properly into an event and added to an event queue and then the event queue was stopped, and opening up the triggers window jump started it back.

I noticed this as well a few weeks ago and so I've been trying various things to "jumpstart it" whenever I get into a bad state. Like the rest of the issue it seems pretty random. Sometimes opening up settings windows or firing a lua command will trigger the queue of events, but only about 50% of the time in my experience.

[atari2600tim]

Now that I've tested it using the debug window, I see that it shows the messages showing up live in the debug window. So the script did run and it built the "X says Y" as shown in the debug window, it just isn't updating the main window to reflect that it is there until later. It's apparently not holding onto the incoming IRC event and running the event later like I had originally suspected... that's just when the result becomes visible. It's doing the event but is interrupted somewhere before refreshing the screen.

So I guess there are two issues:

• You can apparently run feedTriggers(string) from this code and have it not show up in the main window until later. First couple will be fine and then the rest don't update the screen on their own.
• Half the sessions it doesn't run that sysIrcMessage event (even though the IRC window is working). Likely an issue registering that event, because if it works once then it works for the whole session.

I saw a note in the manual regarding feedTriggers which says that feedTriggers is supposed to make the string show up alongside the following message if you don't use a newline. But this script does have a newline there, so it shouldn't be waiting on game output or a go-ahead etc. For now I added send("\n") which means that my prompt from the game at least updates my screen for now.

In Ubuntu, I compiled mudlet and ran it and it seems to be doing the script as expected. I mean the display is still delayed until game traffic, but at least it is triggering the script upon incoming IRC messages. Tried it around 20 times in a row with it working fine. Then I downloaded and ran the 4.8.2 linux release, and that is half and half just like Windows had been doing.

Well, maybe the dev build has some fixes regarding this issue?

So tried some with Windows 10 again. I had been using the 4.8.2 all along, so I downloaded the zip file for testing recent PR 3872 built by the compiler bot. It has the same problem, ~50% of the time it does not register the handler.

[itsTheFae]

This may be related to the way feedTriggers() works. According to the manual for feedTriggers(), this function requires that Mudlet "receives" data from the game before tiggers are processed.

To quote a note from the page:

Note: The trigger processing system also requires that some data is (or appears to be) received from the game to process the feedTriggers(), so use a send("\n") to get a new prompt (thus new data) right after or ensure that the text includes a new-line "\n" character so as to simulate a line of data from the Game Server.

So, try adding send("\n") to the onIRCMessage function or wrapping the incoming IRC line with new-line characters and see if that helps.

[atari2600tim]

• Half the sessions it doesn't run that sysIrcMessage event (even though the IRC window is working). Likely an issue registering that event, because if it works once then it works for the whole session.

I no longer think it is an issue registering the event but rather an issue with it getting called. It seems to stop at this if statement where it checks if it is the 'default host' client.

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

This part is outdated from when you used to be able to run the IRC without opening a profile. Now it has to be associated with a profile, and there is no 'default host' as of August 2019. https://github.com/Mudlet/Mudlet/pull/2950

That outdated code should be just minor bloat though for a path that no longer gets taken. I haven't yet looked to see why isDefaultHostClient() sometimes comes up true when the IRC client is in fact associated with an open profile.

[itsTheFae]

I've removed the old code, so you can give this PR a try on Windows:

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

[jacben]

This seems to have resolved the issue! I attempted about 20 repros and wasn't able to reproduce the issue.

The client seems like it still requires some type of input to push the first event, but a click anywhere will do it - including a click to minimize the IRC window, which is necessary to bring focus back to the main window anyway.

Thank you both! Very nice work. :)