Handling IRC channel messages

[Helianthella]

I recently added a buildin for reading messages from channels (#1719). However there's a problem: it cannot handle the #irc channel fully. This is because the way I set it up the event triggers when a player sends a message to a channel and not when a channel receives a message. When the player sends something, an event is dispatched with the player attached and the @channelmes$ variable is set.

For IRC this works when sending messages from Hercules to IRC but not the other way around, because it only triggers when sending. This means if a user in the IRC channel says something the server has no way to read the message, unless it was sent through Hercules.

There's two ways I could solve this:

• Make the addchannelhandler() command also call the event when a message is received, only in the #irc channel, without an attached player and making it register $@channelmes$ instead of @channelmes$
  • 👍 no need for an extra global event or config flag
  • 👎 adds an extra layer of complexity for one single edge case

• Make the server call ::OnIRCEvent globally when an incoming event occurs in the IRC channel. This could be triggered on/off via a config flag
  • 👍 keeps addchannelhandler() simple
  • 👍 could be used to retrieve not only messages but also other events (join, part, quit, ...)
  • 👎 adds an extra global event (affects performance)

Thoughts? Any other idea?

[MishimaHaruna]

Having the server call the event handler globally might indeed be a performance hit (assuming you'd run it through npc->event_do("::OnIRCEvent"), please correct me if I'm wrong), and would also affect those that don't have any handler configured, since we don't have a cache for the global, detached, events (like we do in npc->script_event() for the RID-specific events).

Having such an event fire on any activity from IRC might be a problem. From personal experience (I run a copy of Hercules connected to the Rizon IRC network, and I have some additional debug code that prints any event originating from IRC), the IRC servers can be very chatty, especially on (re)connection, due to the very long MOTD messages used. Occasionally, IRCops also send global notices, which might also be a bit verbose. I'm not sure what performance impact this might have, especially on reconnections or after a netsplit (when a large amount of channel join notifications are delivered).

While I like the possibilities of customization that the second approach would give, I'd advise some analysis on how it might affect the performance (unless we implement some caching for the global event handlers, like we do for the player events - in that case, it'd only affect the performance if a script with the event label is actually loaded)

[Helianthella]

@MishimaHaruna Actually some global events are cached because they are called very often (pc login, logout, die, kill, ...) so I could just add OnIRCEvent as one of them and then use npc->script_event() to invoke it. I would just add a copy of it named npc->script_event_detached(). Since IRC is very chatty I could make it relay only messages by default and add a config options for those that also want join/quit/part/...

[MishimaHaruna]

Yes, the ones you mention are the kind of global events that require a RID attached. Having a similar function for the events that run detached would work. This is what I meant wen I mentioned not having a cache for the global, detached, events.

FWIW, that the same mechanism can be extended to handle the OnAgitStart, OnAgitEnd, OnAgitStart2, OnAgitEnd2 events as well (the other ones, such as OnInit, OnInterIfInit, etc, are irrelevant and don't need to be cached).

I agree about having a configuration to filter some kind of messages that might be undesired.

[Helianthella]

Ok so to recap,

• we add a new script_event cache for detached events, and cache the following events:
  • OnIRCEvent
  • OnAgitStart
  • OnAgitStart2
  • OnAgitEnd
  • OnAgitEnd2

• we add new configuration options to the chsys channel config file:

  irc_event_triggers: {
  message: false /* turn to true to enable the event */
  private: false
  notice: false
  join: false
  part: false
  quit: false
  nick: false
  mode: false
  topic: false
  }

• if anything in irc_event_triggers is true, it will call OnIRCEvent when an event occur and set those variables:
  • $@IRC_EVENT_TYPE the type of event (message, notice, join, ...)
  • $@IRC_EVENT_NICK$ the nick of the person triggering the event
  • $@IRC_EVENT_MSG$ the message (from message, notice, part, ...)

@MishimaHaruna is this correct?

[MishimaHaruna]

That looks correct @mekolat

In the list of triggers, where would CTCP 'ACTION' (i.e. /me) fall? Same trigger as message? kick could also be added, and perhaps other, although I'm not sure it can be of much use.