[Suggestion] Add option for gradient to text component

[Andre601]

This is posted here, as I believe it can/should be implemented for both BungeeTabListPlus and AdvancedTabOverlay.

The idea is to have an option for displaying a Text as a Gradient in the tab list, since this requires you to use [color=#<code>] for every separate letter of a text, which can become even more annoying when you have constantly changing text for slots or the Header/footer.

An idea could be a color option that would either accept a ChatColor name (i.e. WHITE) or a hex color value and then have some specific syntax to have a gradient.

For example:

components:
- '{text: "White Color", icon: "colors/white.png", ping: 0, color: "WHITE"}'
- '{text: "Custom HEX color", icon: "colors/gray.png", ping: 0, color: "#aabbcc"}'
- '{text: "Gradient HEX color", icon: "colors/gray.png", ping: 0, color: "#aabbcc-#ddeeff"}'

[CodeCrafter47]

We have already briefly talked about this on discord, but I'd like to present my thoughts on this here in greater detail.

With the 3.4.0 update of BTLP we have the !color_animation custom placeholder which allows creating color gradients. However it is rather cumbersome to use, so I'm still looking for better options.

The solution you proposing is straightforward and easy to use, however the issue I see with it is that it would allow only one color/ color gradient per slot. Also one would need to give some though to how this can be used in the header/ footer, and what happens when legacy color codes are used in the same slot.

It has been suggested to me to use the Adventure library and the MiniMessage format it provides. See https://docs.adventure.kyori.net/minimessage.html. This would be a big change to how text formatting works in the plugin. However I think the advantages we gain, especially when it comes to rainbow effects and color gradients would be worth it. The biggest concern I have with this option is how it can be implemented without breaking any of the existing formatting options.

[Andre601]

The solution you proposing is straightforward and easy to use, however the issue I see with it is that it would allow only one color/ color gradient per slot. Also one would need to give some though to how this can be used in the header/ footer, and what happens when legacy color codes are used in the same slot.

The header/footer thing could be fixed (in some way) by having it similar to like the [color='<color>'] option for text. And if people would want to use multiple gradients in one text then they can just utilize a custom color_animation placeholder for it, so I personally see no big deal in this.

In addition would I like to give some more ideas here on how colors could be applied.

components:
- {text: "Single Color", color: "#00FF00"}
- {text: "Single Color, &fexcept this white", color: "#00FF00"}
- {text: "Single Gradient", color: "#00FF00-#0000FF"}
- {text: "Single Gradient with multiple colors", color: "#00FF00,#000011,#0000FF"}
- {}
- {text: "[color=#FF0000-#00FF00]Multiple [color=#00FF00-#0000FF]Gradients"}
- {text: "Gradient, &fbut this stays white", color: "#00FF00-#0000FF"}
- {text: "Gradient, &fthis stays white &rand this is gradient again", color: "#00FF00-#0000FF"}

I quickly break each option down to what I had imagined it to do:

• {text: "Single Color", color: "#00FF00"} Single HEX color is applied accross the entire text
• {text: "Single Color, &fexcept this white", color: "#00FF00"} Same as before but &f would break this up (Count as the end of the other color) and override the used color
• {text: "Single Gradient", color: "#00FF00-#0000FF"} A simple gradient using two colors.
• {text: "Single Gradient with multiple colors", color: "#00FF00,#000011,#0000FF"} Gradient that uses multiple target colors. Similar to !color_animation
• {text: "[color=#FF0000-#00FF00]Multiple [color=#00FF00-#0000FF]Gradients"} Uses the [color] option to define multiple gradients here. Could be applied for footer/header text.
• {text: "Gradient, &fbut this stays white", color: "#00FF00-#0000FF"} Same as with the single color example. &f would override the set gradient. Maybe the gradient would also end there?
• {text: "Gradient, &fthis stays white &rand this is gradient again", color: "#00FF00-#0000FF"} &r would tell ATO/BTLP to re-apply the set color value (in this case the gradient)

I want to be clear about one thing as I believe this may have been missunderstood. My suggestion isn't about having the same feature such as !color_animation (as in having it animated) but to have a static color/gradient applied to the text without the requirement of having to create a custom placeholder that would by default be animated.

On an additional note should it perhaps be considered to have a own textComponent for header and footer (without the skin and ping option of course) to have a unified formatting across all parts that offer text customisation.

My idea of a header and footer setup:

showHeaderFooter: true

headerAnimationUpdateInterval: 1
header:
- {text: "First frame"}
- {text: "Second frame"}

footerAnimationUpdateInterval: 1
footer:
- |-
  {text: "&eLine 1"}
  {text: "&6Line 2"}
- |-
  {text: "&6Line 1"}
  {text: "&eLine 2"}

It has been suggested to me to use the Adventure library and the MiniMessage format it provides. See https://docs.adventure.kyori.net/minimessage.html. This would be a big change to how text formatting works in the plugin. However I think the advantages we gain, especially when it comes to rainbow effects and color gradients would be worth it. The biggest concern I have with this option is how it can be implemented without breaking any of the existing formatting options.

Idk about this. While it would help in establishing a somewhat common color-format would I personally see some minor issues with it.

• You would depend on another library. If something in MC changes/breaks can you not just update but have to wait for the lib to reflect this change.
• More formats = more confusion. I believe that ATO and BTLP should keep their own, consistent formatting for things.

[CodeCrafter47]

Thank you for the extensive explanations.

Let me summarize your proposal from my perspective. It comes down to the following points.

1. Extending the functionality of the [color=...] format code to allow for static color gradients, potentially with more than two colors.
2. Adding a color: option to set the default color/ color gradient for a slot which is used if there are no other formatting codes and following the reset &r.
3. Potentially extending the header so that the color: option can also be used there.

I think this would be a good option, though I'm not yet 100% convinced whether we need the color: option, when extending the [color=...] format code already gives access to the same features.

When comparing your suggestion to the Adventure library, I think both options will provide similar features and realizing them will require a similar amount of work. I'm currently leaning a bit towards using the Adventure library, but I think both options are good choices.

That being said, though, I don't plan on working on this myself for the next update (probably not for the next few updates). It would be nice if someone was to contribute this as a pull request. In that case they could choose which approach to take. Anyone thinking of doing this, you can contact me here or on discord for some info on how to get started or to exchange some ideas.

[Andre601]

I'm not sure if this issue is still relevant. The color_animation component as of now seems like a good working thing and if any of the other suggestions (i.e. change of the header and footer syntax) are still relevant would I better create a new issue for them for better tracking as the main topic about this issue, gradients, seems to be more or less solved.

Also, after I also spend my fair share with the MiniMessage library do I no longer stay with what I said in the past. The library does have its big advantages but I also agree that it could become difficult to implement it without breaking current colour formatting behaviour. Additionally, would the biggest problem be to inform people about it. It's rather unlikely that people would read the update/patch notes (At most would people already using it and therefore getting an update notification read it, but that's not guaranteed.

Anyway, I close this issue now. If it is still relevant for you, let me know and I reopen it.

[CodeCrafter47]

I think it is still relevant. Though I don't think anything will be happening soon. Using adventure/ minimessage would be nice. I think using some high level text formatting library would benefit the plugin, as it would make handling text a lot easier internally.

[Andre601]

I agree. Though the biggest problem is obvious: MiniMessage adds a completely different syntax system that most people aren't used with and probably won't bother to work with in the first place since alternatives are a thing.

So worst case here is a new feature support nobody or barely anyone uses. Obviously you could force them into using it by blocking/removing the old color format but that would only cause hate from most people.

[CodeCrafter47]

Forcing people to use a new format would be a bad idea. Did that once many years ago.

[Andre601]

Forcing people to use a new format would be a bad idea. Did that once many years ago.

Agree. People who are curious or knowing MM will try using it while others will stick to the currently used format. There isn't really anything in-between those two options sadly...

[Andre601]

Looking back at this issue, I think MiniMessage support is a good idea. From what I gathered have a lot of people adopted this format (including me) for plugins, so people could already be used to it by now.

In terms of "encouraging" people to use it could you add it, while supporting the current formats for the time being, but announce their deprecation and future removal from BTLP and ATO, so that they know they have to switch over...

[Andre601]

I've decided to close this issue in favour of a new, more clear issue with better ideas to have here.

New issue: #9