Feature: 1.16 colors with fallback to closest pre 1.16 colors

[TekExplorer]

basically the title, i would like to have rgb for clients that support it and fallback to regular & codes for anything older, preferably with support for viaversion clients.

plus a gui that allows you to select a color from an rgb creation system of sorts within the gui or use regular codes [ie regular codes and then a rainbow wool that allow you to do rgb] preferably with rgb presets (or that could just be the regular color codes) and with permission nodes allowing access for, say, a donor to be able to do rgb. maybe a way to have rainbow text that every character is a color slightly different than the last [rgb rainbow?] this should also be an option and permission.

[BrainStone]

GUIs aren't possible (with reasonable means) on the bungee. And neither is detecting then client version and transforming the message. If you want to support multiple client versions you need to use ViaVersion.

[TekExplorer]

So there is no way to add hex color?

[BrainStone]

There certainly will be a way to do so. But I won't add any code that takes care of making it backwards compatible. That's the job of other plugins like ViaVersion.

[TekExplorer]

Oh, yeah that's what I was asking for. Mainly though, what if you set a hex code but log in to a 1.15 server? What do you see? It IS a bungee plugin after all.

That's what I was referring to.

[BrainStone]

You probably don't see any color at all. It depends on how the client handles it.
Maaaaaybe Bungee itself does some color correcting. Not sure though.

[TekExplorer]

If you don't see any color, than couldn't you add the option to set 1.16 color codes AND legacy color codes for a given format? This should make any issues related to it obsolete, and just have the plugin detect the client version, which afaik is pretty easy. This would, interestingly, make viabackwards color correcting unnecessary with this plugin, and account for all color related questions

Something like
Legacy-format: &6 [rank]
Hex-format: &#123456 [rank]
Maybe?

Edit: or just allow for version specific formatting, which would do the same thing but add more options.

[BrainStone]

and just have the plugin detect the client version, which afaik is pretty easy
Nope. At least not in the current code base.

In short I will add proper color support in time but I will not add handling for different versions. Simply because slightly more colorful chats are not worth the time I'd need to sink into that kind of stuff. If you're running multi version servers not having all features of the most recent versions at your disposal is something that you need to be aware of.

If you want that kind of backwards compatability use ViaVersion. That's exactly what it was made for.

[TekExplorer]

The reason I mention it is that I thought it would be cool to have 1.16 clients have rgb regardless if they are on a 1.16 server or a 1.8 server. Viabackwards takes care of older clients on newer servers, ie a 1.15 client would see the closest color to the rgb that's available but it doesn't work the other way around. I realize that maybe the code for this particular plugin may not be suited for it, despite how simple the solution seems (all else the same set <1.16 to use & and 1.16+ to use &#) that perhaps it doesn't work that way.

If you ever rewrite the plugin, I highly recommend you build in this functionality, give more control over what can be done, thereby giving you more room for various features as they come up. (This should also make updating easier)

Besides, as a bungeecord plugin, you should expect to support various versions from way down to 1.8 to the future 1.17+, so in the future, perhaps a priority is to cater to that idea.

[AwesomestCode]

If you so wish for this functionality to be added, have a go at contributing to the source code. However, given the limited time to develop this plugin that BrainStone and the contributors, including me, have, not all feature requests will be implemented. The one writing the code decides which ones to implement. While I can’t speak for BrainStone on what he plans to do, rewrite wise, I can say from working with the codebase that it is already very flexible for what it does; however, many utility methods don’t account for different versions having different chat formats. It may also be a limit of the BungeeCord API; as far as I'm aware, short of listening to packets there's no way of getting a user's version. no forget about that there is a way.

As I said, feel free to contribute code that does this in a clean way and doesn't break the rest of the plugin, but, while I can't speak for BrainStone, I dislike how you're instructing us on what to prioritize.

[TekExplorer]

I'm sorry if I appear to be telling you what to do, that was not my intention. All I ask is that you take these ideas into consideration so that if you ever get the chance to, you may implement. I cannot know, as I am not a programmer, how or what should be prioritized, and I can only, as a user, tell you what i believe would make your software better.

Thank you for at least responding to my request. Once again, all I ask is you keep this feature request in mind if ever the opportunity presents itself. No expectations from me, work at your own pace.

Also, there are plugins for bungee that can send different versions to different servers. Maybe they listen to packets, I don't know, but it is possible(to do things based on client version), which is why I mentioned it.

Edit: clarity

[AwesomestCode]

The feature to send different versions to different servers is in stock BungeeCord.

[TekExplorer]

Well, this plugin does it (spigot filters ftw). So there's that 🤔. I need to do more research anyway to see if the viabackwards translation is a thing on bungee or not, if there is, then hey, problem solved.

My guess is, if bungee doesn't just supply client versions in the API, which if it doesn't then I'mma slap someone cuz that sounds like a feature that a proxy supporting multiple versions should have, then packet sniffing is (probably) used... Ofc it's not like I checked the code, but you could do that if you felt so inclined.

Again, I can only share my opinion based on what I know from what I've seen. For all I know it could be super difficult.

Imo if it is too difficult with the current code, then making a list of features to add whenever, if ever, you decide to rewrite the code might not be a bad idea.

[AwesomestCode]

Sorry if my previous post sounded rude or angry. I was dealing with a person spam pinging me to make a bug fix for my Aphelia Discord bot. I believe it’s possible to get the protocol number from a connection object. However, the main issue is that the current utility methods don’t allow for different users to be send different messages; this is the same reason #52 has been on hold for a while. Thank you for understanding.

[AwesomestCode]

Yes, turns out I was wrong on not being able to get user versions. My mistake. Sorry.

[TekExplorer]

Sorry if my previous post sounded rude or angry.

That's perfectly alright 😉

However, the main issue is that the current utility methods don’t allow for different users to be send different messages; this is the same reason #52 has been on hold for a while. Thank you for understanding.

What do you mean by that? 🤔

Yes, turns out I was wrong on not being able to get user versions. My mistake. Sorry.

It happens, glad I could clear that up 😉

• if the formatting looks weird that because I'm using mobile (edit: didn't know that "-" is a bullet. Learn something new everyday)

I noticed mention of a bridge in the future. Would this be on both bukkit-based and sponge? And would there be a consideration for situations where it's not possible to install this bridge? (Eg. "Other" server software such as cuberite or even just flat out vanilla [patched with vanillacord])

[AwesomestCode]

The utility methods are functions the plugin calls that do stuff like “add the user’s prefix to this chat message” (actually, I believe that’s integrated in the preprocessor, but you get my point) or “send everyone this message”. They exist to make the plugin easier to work on so we don’t have to write a loop that sends messages to each player individually every time we want to send a message to everyone. However, they don’t account for stuff like certain players being sent different messages. As for the bridge, that’s for BungeeChat 3, a rewrite planned to happen “anywhere from the next minute to the end of the millennium” according to BrainStone. I’m not sure which platforms it’ll support.

[TekExplorer]

 “anywhere from the next minute to the end of the millennium”

Ooooof course.

You made these methods yourselves for the plugin I assume? How difficult would it be to rewrite it to add or interrupt with an if then statement so that
if ("rgb" = true) then call rbgFormatProcessorOrWhatever

Else [whatever you have now]
?

Obviously I don't think it's THAT simple, but I feel like you could just add a function that sets rgb to true for a client if the client is rgb compatible (1.16+) and calls for the rgb format assuming the config is along the lines of
defaultFormat: &6[yourformat]
rbgFormat: &#ffffff[your format]

Would that work? Might add code that could otherwise be simplified, but keeping it separate should theoretically make it easier to implement initially.

[AwesomestCode]

I can’t say for certain since BrainStone wrote those methods before I knew this plugin even existed, but I could take a look at the source code later and possibly make an attempt at implementing it.

[BrainStone]

I need to do more research anyway to see if the viabackwards translation is a thing on bungee or not, if there is, then hey, problem solved.

That's why I kept mentioning to use ViaVersion. You can install it on the bungee and it'll take care of downgrading the colors.

I’m not sure which platforms it’ll support.

All. At least all I know of: Bungeecord, Velocity for proxies and Spigot, Sponge and Nukkit directly. Maybe even Forge directly if there's enough demand, but I'm not a huge fan of that. Forge is always so much work for such little payoff. (I mean plugin style mods that need to be able to support a vast version range. Hard to implement and hardly used anyways).

---

And the issue that arises from the current architecture is that the message is fully processed before it is determined who it gets send to. Meaning there's no good way to generate an individual message for each player.

---

And lastly I want to point out that it's literally just colors. It's nothing but a cosmetic thing. We've been fine without it for 10+ years and we'll be fine without it until I get around implementing support for it.
And to reiterate: It's a tiny cosmentic feature. I won't be jumping through ridiculous hoops just to give it backwards compatibility, especially when there's a perfectly fine working plugin that does just that. Now additionally I could imagine even Bungee itself taking care of that already. I'll get back to you on that.

[TekExplorer]

And the issue that arises from the current architecture is that the message is fully processed before it is determined who it gets send to. Meaning there's no good way to generate an individual message for each player.

Couldn't you process it twice? I can't imagine, unless it's hardcoded, that you couldn't just send the original to everyone under 1.16 and the second one to any newer client 🤔. It doesn't have to be individual I don't think, and no backwards compatibility hoops need jumping if there is an option for both, rgb being optional.

Is it cosmetic? Sure. Should server owners have access to it? Yes. Should you go through rediculus hoops to implement it? Hell no. I am operating on the assumption that it should be rather simple, or that there is a simple solution, correct me if I'm wrong, as I very well could be.

(Sure you could have viaversion or bungee translate, but what if server owners want to control that directly?)

Whatever works the best, for the most reasonable effort, is imo the best solution. Anything else will come with time, should a better method arise.

[BrainStone]

Couldn't you process it twice?

Not really. The message is already fully processed at the time it gets decided who to send it to. There's really nothing to be processed anymore.

It doesn't have to be individual I don't think

Essentially yes. I have to determine which version of the message to send per player. Which makes it individual. There's no "send message X to 1.15 players and Y to 1.16 players" method

and no backwards compatibility hoops need jumping if there is an option for both, rgb being optional.

Asking me to handle the message differently based on the player's version is making me jump through backwards compatibility hoops.

I am operating on the assumption that it should be rather simple, or that there is a simple solution, correct me if I'm wrong, as I very well could be.

Yes you are very wrong. As explained multiple times already.
Let me be clear: It's not too hard to implement in a new system. One that's not integrated throughout the plugin. But as it stands right now the current BungeeChat architecture doesn't allow any kind of post processing without rewriting a majority of the message code.

[TekExplorer]

Ah, welp, in that case, all I ask is that the feature be added to the v3 list of features for the rewrite that may happen whenever.

Or that if it works well with bungeecord/viaversion that it gets added sometime soon

Thank you again for taking the time to respond to my questions/suggestions, and I hope you have a good (insert any amount of time here)