Messages should be sent to Dalamud's General Chat setting instead of System

[NadyaNayme]

Users who use Tidy Chat with the System filter enabled and ReadyCheckHelper cannot see this plugins messaging because it sends as a System-type message. Seeing as I don't wish to be in charge of whitelisting every plugins' messaging past, present, and future and keeping up-to-date with any changes in verbiage and localization for every plugins' messaging I've taken a firm stance that the proper way to ensure compatibility is that other plugins should be using the users' General Chat setting within Dalamud which is Dalamud's Debug channel by default (honestly this channel should just be called Dalamud not Debug... but that's a different issue). This allows users to either use Debug or basically any other non-System type channel so that plugins are compatible with using Tidy Chat's filtering.

Relevant line of code: https://github.com/PunishedPineapple/ReadyCheckHelper/blob/main/ReadyCheckHelper/Plugin.cs#L471

You should be able to get the XivChatType that the user has set in their Dalamud settings with Type = mPluginInterface.GeneralChatType.

[PunishedPineapple]

I am aware that you can get the default chat type from settings; however, the choice of the system chat channel for the ready check message was very deliberate. The plugin's not ready message is meant to directly follow, and be the same channel as the game's built in ready check message. The reasons for this are so that it ends up the proper color in chat, and ends up in the same chat tabs/windows as the game's ready check message.

I'll think about whether I want to support the user setting an arbitrary chat channel for this message, but my initial thought is that I don't, as it's only doing one specific thing, and tied directly to a message that can't occur in other channels, so why should two inextricably related messages potentially appear in separate chat windows in different colors?

If you don't want to make exceptions for specific messages, what about making exceptions for messages containing link payloads or something?

[PunishedPineapple]

Two other potential solutions, partially on your side:

1. If you had IPC to add items to your whitelist (maybe you already do; I haven't looked yet), I'd probably be willing to use that in this case to add my messages to it.
2. Realistically, chat events from Dalamud might benefit from a parameter that says whether a message is from Dalamud, a plugin, or the game. Right now, there's already an issue with the dalamud chat system that could potentially benefit from API-breaking changes, so depending on what people think about that issue, maybe such a flag could be added with the longer-term resolution to that issue.

[NadyaNayme]

I can see and agree with your reasoning for why it is and should be System. I think this is one of the first cases where there is a legitimately good UX reason to have it the way it is with a solid reason as for why it would be worse UX if changed. I'm not sure I disagree with allowing the user to change it if they wish - but it is your plugin at the end of the day and this issue is a very minor one that, so far, only one person has voiced an issue with.

1. I'm not entirely against the idea of adding an IPC but I also think it's a bit overkill for such a one-off thing. For the amount of work it'd take to add an IPC I'd rather just add the one-off plugin filter TBH or tell the user to abuse Tidy Chat's "player" whitelisting functionality and whitelist "Not Ready" for System channel messages. I have an eventual refactor planned and I wouldn't want to break my IPC API by accident during the refactor so it would have to wait until after the refactor happens to be added and I don't know how or even when that will actually happen. It would also feel a bit weird to have plugins need to register with TC for their messages to not be filtered - that becomes an annoyance for users and devs-that-aren't-me which I also want to try and not be as much as possible.

2. Would honestly be a much, much better potential fix if I could limit Tidy Chat to only being concerned with Game messages and not Dalamud/Plugin messages. It also allows us to both have our cake and eat it too. A win-win for sure and I'd never have to worry about Tidy Chat filtering a plugin's message ever again. Ideally adding that kind of flag would be the best solution even if it is API-breaking.

[PunishedPineapple]

Ya, the more that I think about it, the ideal solution would really be to add that information to the chat events. I'm honestly not sure the best time/way to approach a discussion of adding it, and I feel bad bugging Goat about new feature stuff since he seems to be pretty tired of Dalamud sometimes. I certainly don't mind doing the work to implement that in Dalamud though, since it has pretty wide benefits imo.

IPC is rough in this situation too after giving it a bit more thought because (and I think it may have been you that brought this up in the past?) there isn't a broadcast of "hey, I'm here, you can register stuff with me now!", so it would have to be constant checking, or registering with a whitelist before every time you send a message or something.

Anyway, I'll probably add a dropdown in my plugin's config to let them set a chat channel for the message. It won't add any maintenance overhead, so there's no real reason not to. There's other stuff I need to get to first, though, so won't be for several days.

[NadyaNayme]

No rush about adding it - and if you want I wouldn't even mind sending a PR for it. But I know most of us devs prefer to do it ourselves, myself included, for consistent code/quality so if you'd rather do it yourself I completely understand.

I think the process now is to write a DIP for it and get discussion happening around the change - as far as who would implement it past that 🤷 but it lets plugin devs all be on the same page with what, why, and how.

I also do want to make it clear that I don't like to play "hot potato" with the filter issues caused by Tidy Chat. I hate having to poke other devs because Tidy Chat came in and made a mess of things that were working perfectly fine before. But the reason I'm against adding filters for plugin messages is it becomes an unscoped maintenance burden. I don't want to have to push an update to Tidy Chat anytime a new plugin comes along that sends messages or an existing plugin updates the wording in its messages or adds a new localized language and finds itself being caught in Tidy Chat's very, very large net. It would also be a bad user experience having plugin messages being blocked until they can get added to Tidy Chat's filters. I feel bad asking other plugin devs to make changes or add a config for compatibility and I know at the end of the day it's an issue with Tidy Chat. I just think it's the best way to ensure compatibility without adding significant maintenance burden. That would definitely change if Dalamud added a parameter to signal message source regardless of channel.

Again - thank you for considering adding the config! I'll keep an eye on the Dalamud issue you mentioned.

[PunishedPineapple]

Nah, I can do it; thank you though! For something this small, it's the same amount of time to do it myself or to review and test a PR.

And ya, I don't blame you; everything added is more maintenance work and more points of failure. There's bound to be finger pointing and passing the buck in situations like this when it's a bunch of random stuff getting bolted onto the game without a unified vision.

[PunishedPineapple]

Version 1.0.3.0 is now merged and contains a setting for which chat channel to use for this message.