kangarko / ChatControl-Red

Issue tracker and documentation for the next generation ChatControl Red, the most advanced chat management plugin.
49 stars 23 forks source link

1.20.1: Still Struggling with colorblind mode. #2386

Closed HorusApl closed 1 year ago

HorusApl commented 1 year ago

Are you using MySQL?

No

Are you using BungeeCord/Velocity?

No

Question

Been working on this for far too long, and hoping someone can give me the answer. I have a variable called colorless that does a permission check if a player has hide.color, and then changes the color in my chat.yml format so that it can be per player. No matter if the permission is true or false, I just can't seem to get it correctly. debug.zip

kangarko commented 1 year ago

Can you navigate me in which format you use the variable?

HorusApl commented 1 year ago

In the chat.yml format is the {colorless} variable, and that variable is suitably named colorless.yml

HorusApl commented 1 year ago

Not sure if I'm even barking up the right tree. Just want to have so if player has X perm, that any chat messages show up as white for them.

kangarko commented 1 year ago

Oh then I would simply create a chat rule that would require a certain permission and then remove all colors in a message for a player. Can you try doing that?

HorusApl commented 1 year ago

That was my initial plan and I asked on the discord, I tried:

match (.*) require perm hide.color strip colors true then replace $0

but it wasn't doing anything at all, and then I was directed to do it via the variable/format way which also doesn't seem to do it properly.

kangarko commented 1 year ago

Try setting Rules.Strip_Colors to true in settings.yml. Make sure you place this rule in rules/chat.rs. That works for me on my end, let me know how it goes.

HorusApl commented 1 year ago

I just tried this and while this works for manually typed color codes "&bHello!" will show as white. I make active use of /chc color menu, which this does nothing for and is the primary thing that I need.

kangarko commented 1 year ago

Then just split the format part containing the two variables and apply the Sender_Permission there such as:

a

kangarko commented 1 year ago

Such that the color-and-decoration have the variables and the message part only has the message

HorusApl commented 1 year ago

Alright this is my current format: https://mclo.gs/astp1l8

If I deny the permission for hide.simplechat, all the correct variables aren't appearing Except for the colors. The colors still show through even though the permission is negated. As seen in the screenshot, denying the permission does nothing to remove the color which is what is supposed to happen. image

kangarko commented 1 year ago

Change Receiver_Permission to Sender_Permission because right now it's evaluated for each chat message received, not yo as the sender.

HorusApl commented 1 year ago

But then that won't make all messages white/unformatted for that particular player, it would only make messages that they send as white/unformatted. So while that would work for an individual to be sending white messages, the purpose is so that if someone runs a command /colorblind, they will be given a permission and all messages in chat to them will appear as white.

kangarko commented 1 year ago

So sorry, I have spent time on this but found that due to how chat components are built, this is a non-workable issue.

Specifically when a color is inserted we need to split the word into a new chat "component", since this is can have performance penalty we save performance by not running receiver_permission conditions when we built the component. Instead, those are checked later when sending the each component, but the message has already been replaced. Which works fine for any other variable but specifically for the color and decoration one this splits the component.

I would need to scrape the chat renderer which I dont have enough time for, for now. I could use modern approach but it would require MC 1.16+ and we cant do that for backward compatibility reasons. Sorry for this, right now this specific placeholder appears to be a wontfix

HorusApl commented 8 months ago

Just wanted to check on this as its been some time with some performance updates/MC updates, has this answer changed to become possible by chance?

kangarko commented 8 months ago

Thanks for checking in. I have not reworked the core yet and I am unfortunately unable to give ETA for this large-scale update.