Inconsistent and unpredictable - Hard to debug about runelite-watchdog

[CreativeTechGuy]

Good to know! I cannot wait to get some easy ways to test this to create more actionable bug reports in the future. 😛 Thanks for your hard work!

[adamk33n3r]

I cannot seem to setup Watchdog notifications for Guardians of the Rift "A portal to the huge guardian fragment mine *" but I can setup a notification for the message "A portal has spawned *" from the Guardians of the Rift Helper plugin.

The Guardians of the Rift message "The rift will become active in 5 seconds." isn't matched with a pattern of that exact string. Nor is it matched if I add a * after it. Similarly with The rift becomes active!.

Did you try adding a * at the start? If it is related to #9, that should fix the issue. I've never played Guardians of the Rift, but I imagine it could be colored and that's why it's failing similar to #9.

Cannot match the vanilla notification of Valuable drop: with "drop"

That seems to be similar to what #9 was experiencing but having a wildcard * before the text seemed to fix it for them. I'm a little stumped why it's not working for you. I've revamped the glob pattern matching in v2 and I have created a unit test for this example that passes so hopefully it is fixed for you soon.

Possibly deduped notifications (From RuneLite's Chat Filter plugin's Collapse Chat setting)

Can you elaborate here? I'm not entirely sure what you're talking about.

All in all, v2 will be released soon and I think it will probably fix most if not all of your issues. Stay tuned! If you're eager to try it out, you can try out my newest release candidate here https://github.com/adamk33n3r/runelite-watchdog/releases/tag/v2.0.0-rc2

[adamk33n3r]

Oh, and I forgot to mention that I really like your "debug mode" idea. I'll have to think about that some more and design something. I do think that's valuable. Probably won't make it into v2 but it's a good idea!

[CreativeTechGuy]

I'll happily test when the new version is out! Currently it's a bit hard to reproduce some of these messages since they aren't easily triggered. I'm excited to try it out! Thanks for your work.

Can you elaborate here? I'm not entirely sure what you're talking about.

I don't know if there's any adverse effects due to this runelite feature. I'm not sure if the number appended to the end of the message needs to be considered in our glob or not. Maybe it's not an issue since this plugin runs on the raw message, but I'm not sure.

[adamk33n3r]

Oh ok, I didn't know that was a thing! I'll definitely test it out :)

[adamk33n3r]

Just tested it and it works as expected!

[adamk33n3r]

After rereading your original issue, are you using Notification alerts or Chat alerts? Cause you are saying "notification" when referring to getting chat game messages, so I'm wondering if you were accidentally using Notification alerts when you should be using a Chat alert.

[CreativeTechGuy]

Notification alerts. I assumed that default Runescape notifications (eg: not ones that are created by RuneLite) are still categorized as notifications, right? Since no player said them?

[adamk33n3r]

Ah ok, I see. So that's probably just bad naming on my part. I may look into fixing that, but it's a little hard because of serialization.

Chat alerts are just "things that are in your chat box". They actually DON'T trigger on player messages at all, and it does say this but you wouldn't see it unless you create one.

Notification Fired alerts are used to hook into the notification event bus that plugins use. So for example the Tempoross plugin has some notifications. Or the Idle Notifier plugin. It fires a Notification to RuneLite with the text "You are now out of combat!". That text can be displayed in your chat if you have game messages setting on in your RuneLite settings (or screen flash, sound, etc). But it's technically coming from a Notification, so (and this is the cool bit), you can disable all of RuneLite's notification settings and just have a notification fired alert in Watchdog and still fire a text to speech alert on it without it showing up anywhere else.

Chat alerts are for game messages in your chat. So things built-in to RuneScape are these. Like if you examine something. Or if your inventory is full. Or if you die. Etc.

I hope this helps. Let me know if I can explain it any better for you.

[CreativeTechGuy]

Ooh that's a gotcha. I'm not sure why that distinction is valuable. Since from a player's perspective, it's unclear if RuneScape is sending the message or if RuneLite. Often they look identical.

Is there a reason those aren't consolidated? Just have one type of alert that does both of those things so the user doesn't need to know the distinction?

[adamk33n3r]

Well one way to tell if it's a RuneLite notification vs a RuneScape game message is if you turn off Game message notifications in RuneLite

and the message still shows up in your chat, then it's a RuneScape message.

To be clear, Chat alerts will still work for plugin notifications if they show up in your chat. So if you have Game message notifications turned on, using a Chat alert will still work because that plugin notification is being sent to your chat. So Chat alerts are like the "default" that works generally and you would use Notification Fired really only if you have Game message notifications turned off.

To answer your last questions, I think what I just explained hopefully explains why it doesn't make perfect sense to consolidate them, since Notification Fired is doing a very specific job. "Notifications" in RuneLite aren't necessarily in your chat, so creating a Chat alert only works if it's actually in your chat.

If you can further argue your point though, I'm all ears. From a technical standpoint, consolidating them would be a lot of work because I'd have to make sure I don't break everyone's existing alerts.

I can definitely see where you're coming from, they are similar in function though I think they are distinct enough. But let me know!

[CreativeTechGuy]

Oh I totally get why they are technically different. I'm not arguing that. I'm just wondering what is the use-case where someone would want to setup a notification for one and not the other. I'd argue that unless there's a use-case there, then they should be consolidated to avoid confusion. And not only that, it'd remove the need for redundant alerts in this plugin since one alert could cover both given the similarity.

From a technical standpoint, consolidating them would be a lot of work because I'd have to make sure I don't break everyone's existing alerts.

• I'd deprecate Chat Alerts (simply due to the name) so no new chat alerts can be created. But someone who still has it in their JSON will still work.
• Make both Chat and Notification alerts an alias for each other. This will grandfather any existing configs in to the new system so they still function as expected. This may result in the alerts being a little more broad than they were previously, but won't lose any functionality. And is probably what the user wanted in the first place.

It looks like the code would actually get a bit simpler as a result. This chunk is the same from both handlers. I'm thinking it could look like:

@Subscribe
public void onChatMessage(ChatMessage chatMessage) {
    // Don't process messages sent by this plugin
    if (chatMessage.getName().equals(this.getName())) {
        return;
    }

    // Filter out player messages
    if (
        chatMessage.getType() == ChatMessageType.PUBLICCHAT
        || chatMessage.getType() == ChatMessageType.AUTOTYPER
        || chatMessage.getType() == ChatMessageType.PRIVATECHAT
        || chatMessage.getType() == ChatMessageType.PRIVATECHATOUT
        || chatMessage.getType() == ChatMessageType.MODCHAT
        || chatMessage.getType() == ChatMessageType.MODPRIVATECHAT
        || chatMessage.getType() == ChatMessageType.MODAUTOTYPER
        || chatMessage.getType() == ChatMessageType.FRIENDSCHAT
        || chatMessage.getType() == ChatMessageType.CLAN_CHAT
        || chatMessage.getType() == ChatMessageType.CLAN_GUEST_CHAT
        || chatMessage.getType() == ChatMessageType.CLAN_GIM_CHAT
    ) {
        return;
    }

    this.fireMatchingAlerts(chatMessage.getMessage());
}

@Subscribe
public void onNotificationFired(NotificationFired notificationFired) {
    this.fireMatchingAlerts(notificationFired.getMessage());
}

public void fireMatchingAlerts(String message) {
    this.getAlerts().stream()
        .filter(alert -> alert instanceof NotificationFiredAlert || alert instanceof ChatAlert)
        .map(alert -> (NotificationFiredAlert) alert)
        .filter(alert -> {
            String regex = Util.createRegexFromGlob(alert.getMessage());
            return Pattern.matches("(?i)"+regex, message);
        })
        .forEach(this::fireAlert);
}

[adamk33n3r]

I was actually arguing for the different use cases and not technical differences 😅

"Notifications" in RuneLite aren't necessarily in your chat, so creating a Chat alert only works if it's actually in your chat.

That's a use case.

If we were to go this route, I don't like Notification Fired referring to chat messages either though. I wouldn't say that examining a barrel is "firing a notification". So, I'd have to think of a new alert type that encompasses both.

One thing I noticed about the code, I'm guessing the .map(alert -> (NotificationFiredAlert) alert) would throw a ClassCastException if it was a ChatAlert.

This might have to be something that happens after v2 if it happens at all. I'd really like to get this new stuff out. I told myself I would put it out before the year is over and I'm already running behind on that! 😝 I'm hoping to make the PR tomorrow. Just some final cleanup stuff to do. Anyway, thanks for your feedback!

[CreativeTechGuy]

Appreciate the discussion and I look forward to what you do with it!

[CreativeTechGuy]

In thinking about it more. I didn't realize that things like examines were included in "Chat alerts". I wonder if just the RuneScape built-in notifications can be separated out and categorized as Notification Fired and leave the rest as-is. That'd have to be a breaking change though since it wouldn't be clear from the config if the user wanted to match things like examines or not.

[CreativeTechGuy]

I'm hijacking this thread at this point, but I had to tell you the latest update looks amazing and solves so many problems. Great job @adamk33n3r !

[adamk33n3r]

@CreativeTechGuy thanks for the kind words! I'm really happy with it. Looks like I introduced a bug #14 when importing, oops, but at least it's a minor thing.

I really do like your idea of a debug/test mode so that might be the next big thing I'll work on. But I can remove the bug label if it's solved your issues and just leave this for an enhancement (or I can create a new issue for the enhancement and close this one. Might be cleaner)

[CreativeTechGuy]

Yeah feel free to close this or whatever works best for you.

I really do like your idea of a debug/test mode so that might be the next big thing I'll work on.

It seems like the latest release did that. Or at least partially. The "Test whole alert" button seems like the sort of thing I was looking for with a debug mode. A way to run the entire alert on-demand on past messages. (Not sure if that's what it currently does or if it runs it unconditionally.) But anyway, look forward to it. Thanks!

[adamk33n3r]

Ya the test whole alert doesn't actually run on messages, it just runs every notification. So, I do think making something that shows past messages getting picked up would be helpful. Could even just be a popup that shows every message in your chat that fits your filter.

I'll close this one and open a new one for that. Thanks!