lore-length readded + Ability to set some GUI default colors

[YellowZaki]

I think lore-length was a great addition. I know it was removed because of problems with some languages. That's why I've made it to be disabled if the user changes it to -1.

I've also added the ability to use default colors for challenge description text and rewards text. When you have a lot of challenges it is very tedious to start every text with the same color.

Tested and working.

 challenge:
# The main part that generates description text.
# [description] comes from challenge.description
lore: |-
[description]
[status]
[cooldown]
[requirements]
[rewards]
description:
# Formatting applied to description text ([description])
color: '&b'

rewards:
# [text] comes from challenge.rewardText and challenge.repeatRewardText
lore: |-
&7&l Rewards:
[text]
[items]
[experience]
[money]
[commands]
# Formatting applied to reward text ([text])
text-color: '&b'

[BONNe]

hmm, but you can do it with description itself.
the reason it was removed was because it is not necessary....

The description of challenge:

&7line 1
&7Line 2
&7 line 3 with any length you want

This only makes sense, if users create description like:

&7 I will put everything in single line and hope it will be ok. Not sure why tho...

What I would suggest is to split the description text on saving/loading instead of parsing time.
The only I issue what I see is that it is not obvious that text will be split in that case.

[YellowZaki]

hmm, but you can do it with description itself. the reason it was removed was because it is not necessary....

The description of challenge:

&7line 1
&7Line 2
&7 line 3 with any length you want

This only makes sense, if users create description like:

&7 I will put everything in single line and hope it will be ok. Not sure why tho...

What I would suggest is to split the description text on saving/loading instead of parsing time. The only I issue what I see is that it is not obvious that text will be split in that case.

I know that you can create multiline descriptions by manually splitting the text. But it is not convenient. You have to manually split it which takes time. By automatically adjusting it, it saves lot of time.

[tastybento]

Thanks for this, @YellowZaki, and apologies it sat so long.

Since this was opened, Challenges migrated its locales and panels to MiniMessage, and that unfortunately breaks the approach here:

• The lore wrapping (WordUtils.wrap + ChatColor.getLastColors) treats MiniMessage tags like <gray> as visible characters, so it wraps in the wrong place and can split a tag across two lines. getLastColors also only understands legacy § codes, so it can't carry a MiniMessage colour to the next line.
• The &b colour prefix is a legacy code; it won't render through the MiniMessage pipeline (it needs a <...> tag or a hex code that Util.translateColorCodes understands). BentoBox now also preserves per-line colour for legacy codes itself, so that part is largely handled upstream already.
• lore-length: 25 as a default reintroduces the wrapping problems in space-less languages (CJK) that got it removed originally — the -1 opt-out doesn't help anyone who leaves the default.

On top of that it now conflicts across CommonPanel/Settings/config.yml/en-US.yml, so it'd need a rewrite rather than a rebase.

The default text colour idea is genuinely useful though — it's tedious to prefix every challenge's text with the same colour — so I'm going to re-add just that part, implemented to work with the current pipeline, and I'll link the new PR here. Closing this one; thanks again for the idea and the original work.

[tastybento]

Follow-up: the default text-colour feature is re-added, MiniMessage-native, in #418 (description-color / reward-text-color under gui-settings). Thanks again @YellowZaki.

[YellowZaki]

I think lore-length was a great addition. I know it was removed because of problems with some languages. That's why I've made it to be disabled if the user changes it to -1.

I've also added the ability to use default colors for challenge description text and rewards text. When you have a lot of challenges it is very tedious to start every text with the same color.

Tested and working.

 challenge:
# The main part that generates description text.
# [description] comes from challenge.description
lore: |-
[description]
[status]
[cooldown]
[requirements]
[rewards]
description:
# Formatting applied to description text ([description])
color: '&b'

rewards:
# [text] comes from challenge.rewardText and challenge.repeatRewardText
lore: |-
&7&l Rewards:
[text]
[items]
[experience]
[money]
[commands]
# Formatting applied to reward text ([text])
text-color: '&b'

[BONNe]

hmm, but you can do it with description itself.
the reason it was removed was because it is not necessary....

The description of challenge:

&7line 1
&7Line 2
&7 line 3 with any length you want

This only makes sense, if users create description like:

&7 I will put everything in single line and hope it will be ok. Not sure why tho...

What I would suggest is to split the description text on saving/loading instead of parsing time.
The only I issue what I see is that it is not obvious that text will be split in that case.

[YellowZaki]

hmm, but you can do it with description itself. the reason it was removed was because it is not necessary....

The description of challenge:

&7line 1
&7Line 2
&7 line 3 with any length you want

This only makes sense, if users create description like:

&7 I will put everything in single line and hope it will be ok. Not sure why tho...

What I would suggest is to split the description text on saving/loading instead of parsing time. The only I issue what I see is that it is not obvious that text will be split in that case.

I know that you can create multiline descriptions by manually splitting the text. But it is not convenient. You have to manually split it which takes time. By automatically adjusting it, it saves lot of time.

[tastybento]

Thanks for this, @YellowZaki, and apologies it sat so long.

Since this was opened, Challenges migrated its locales and panels to MiniMessage, and that unfortunately breaks the approach here:

• The lore wrapping (WordUtils.wrap + ChatColor.getLastColors) treats MiniMessage tags like <gray> as visible characters, so it wraps in the wrong place and can split a tag across two lines. getLastColors also only understands legacy § codes, so it can't carry a MiniMessage colour to the next line.
• The &b colour prefix is a legacy code; it won't render through the MiniMessage pipeline (it needs a <...> tag or a hex code that Util.translateColorCodes understands). BentoBox now also preserves per-line colour for legacy codes itself, so that part is largely handled upstream already.
• lore-length: 25 as a default reintroduces the wrapping problems in space-less languages (CJK) that got it removed originally — the -1 opt-out doesn't help anyone who leaves the default.

On top of that it now conflicts across CommonPanel/Settings/config.yml/en-US.yml, so it'd need a rewrite rather than a rebase.

The default text colour idea is genuinely useful though — it's tedious to prefix every challenge's text with the same colour — so I'm going to re-add just that part, implemented to work with the current pipeline, and I'll link the new PR here. Closing this one; thanks again for the idea and the original work.

[tastybento]

Follow-up: the default text-colour feature is re-added, MiniMessage-native, in #418 (description-color / reward-text-color under gui-settings). Thanks again @YellowZaki.

[YellowZaki]

I think lore-length was a great addition. I know it was removed because of problems with some languages. That's why I've made it to be disabled if the user changes it to -1.

I've also added the ability to use default colors for challenge description text and rewards text. When you have a lot of challenges it is very tedious to start every text with the same color.

Tested and working.

 challenge:
# The main part that generates description text.
# [description] comes from challenge.description
lore: |-
[description]
[status]
[cooldown]
[requirements]
[rewards]
description:
# Formatting applied to description text ([description])
color: '&b'

rewards:
# [text] comes from challenge.rewardText and challenge.repeatRewardText
lore: |-
&7&l Rewards:
[text]
[items]
[experience]
[money]
[commands]
# Formatting applied to reward text ([text])
text-color: '&b'

[BONNe]

hmm, but you can do it with description itself.
the reason it was removed was because it is not necessary....

The description of challenge:

&7line 1
&7Line 2
&7 line 3 with any length you want

This only makes sense, if users create description like:

&7 I will put everything in single line and hope it will be ok. Not sure why tho...

What I would suggest is to split the description text on saving/loading instead of parsing time.
The only I issue what I see is that it is not obvious that text will be split in that case.

[YellowZaki]

hmm, but you can do it with description itself. the reason it was removed was because it is not necessary....

The description of challenge:

&7line 1
&7Line 2
&7 line 3 with any length you want

This only makes sense, if users create description like:

&7 I will put everything in single line and hope it will be ok. Not sure why tho...

What I would suggest is to split the description text on saving/loading instead of parsing time. The only I issue what I see is that it is not obvious that text will be split in that case.

I know that you can create multiline descriptions by manually splitting the text. But it is not convenient. You have to manually split it which takes time. By automatically adjusting it, it saves lot of time.

[tastybento]

Thanks for this, @YellowZaki, and apologies it sat so long.

Since this was opened, Challenges migrated its locales and panels to MiniMessage, and that unfortunately breaks the approach here:

• The lore wrapping (WordUtils.wrap + ChatColor.getLastColors) treats MiniMessage tags like <gray> as visible characters, so it wraps in the wrong place and can split a tag across two lines. getLastColors also only understands legacy § codes, so it can't carry a MiniMessage colour to the next line.
• The &b colour prefix is a legacy code; it won't render through the MiniMessage pipeline (it needs a <...> tag or a hex code that Util.translateColorCodes understands). BentoBox now also preserves per-line colour for legacy codes itself, so that part is largely handled upstream already.
• lore-length: 25 as a default reintroduces the wrapping problems in space-less languages (CJK) that got it removed originally — the -1 opt-out doesn't help anyone who leaves the default.

On top of that it now conflicts across CommonPanel/Settings/config.yml/en-US.yml, so it'd need a rewrite rather than a rebase.

The default text colour idea is genuinely useful though — it's tedious to prefix every challenge's text with the same colour — so I'm going to re-add just that part, implemented to work with the current pipeline, and I'll link the new PR here. Closing this one; thanks again for the idea and the original work.

[tastybento]

Follow-up: the default text-colour feature is re-added, MiniMessage-native, in #418 (description-color / reward-text-color under gui-settings). Thanks again @YellowZaki.

[YellowZaki]

I think lore-length was a great addition. I know it was removed because of problems with some languages. That's why I've made it to be disabled if the user changes it to -1.

I've also added the ability to use default colors for challenge description text and rewards text. When you have a lot of challenges it is very tedious to start every text with the same color.

Tested and working.

 challenge:
# The main part that generates description text.
# [description] comes from challenge.description
lore: |-
[description]
[status]
[cooldown]
[requirements]
[rewards]
description:
# Formatting applied to description text ([description])
color: '&b'

rewards:
# [text] comes from challenge.rewardText and challenge.repeatRewardText
lore: |-
&7&l Rewards:
[text]
[items]
[experience]
[money]
[commands]
# Formatting applied to reward text ([text])
text-color: '&b'

[BONNe]

hmm, but you can do it with description itself.
the reason it was removed was because it is not necessary....

The description of challenge:

&7line 1
&7Line 2
&7 line 3 with any length you want

This only makes sense, if users create description like:

&7 I will put everything in single line and hope it will be ok. Not sure why tho...

What I would suggest is to split the description text on saving/loading instead of parsing time.
The only I issue what I see is that it is not obvious that text will be split in that case.

[YellowZaki]

hmm, but you can do it with description itself. the reason it was removed was because it is not necessary....

The description of challenge:

&7line 1
&7Line 2
&7 line 3 with any length you want

This only makes sense, if users create description like:

&7 I will put everything in single line and hope it will be ok. Not sure why tho...

What I would suggest is to split the description text on saving/loading instead of parsing time. The only I issue what I see is that it is not obvious that text will be split in that case.

I know that you can create multiline descriptions by manually splitting the text. But it is not convenient. You have to manually split it which takes time. By automatically adjusting it, it saves lot of time.

[tastybento]

Thanks for this, @YellowZaki, and apologies it sat so long.

Since this was opened, Challenges migrated its locales and panels to MiniMessage, and that unfortunately breaks the approach here:

• The lore wrapping (WordUtils.wrap + ChatColor.getLastColors) treats MiniMessage tags like <gray> as visible characters, so it wraps in the wrong place and can split a tag across two lines. getLastColors also only understands legacy § codes, so it can't carry a MiniMessage colour to the next line.
• The &b colour prefix is a legacy code; it won't render through the MiniMessage pipeline (it needs a <...> tag or a hex code that Util.translateColorCodes understands). BentoBox now also preserves per-line colour for legacy codes itself, so that part is largely handled upstream already.
• lore-length: 25 as a default reintroduces the wrapping problems in space-less languages (CJK) that got it removed originally — the -1 opt-out doesn't help anyone who leaves the default.

On top of that it now conflicts across CommonPanel/Settings/config.yml/en-US.yml, so it'd need a rewrite rather than a rebase.

The default text colour idea is genuinely useful though — it's tedious to prefix every challenge's text with the same colour — so I'm going to re-add just that part, implemented to work with the current pipeline, and I'll link the new PR here. Closing this one; thanks again for the idea and the original work.

[tastybento]

Follow-up: the default text-colour feature is re-added, MiniMessage-native, in #418 (description-color / reward-text-color under gui-settings). Thanks again @YellowZaki.

[YellowZaki]

I think lore-length was a great addition. I know it was removed because of problems with some languages. That's why I've made it to be disabled if the user changes it to -1.

I've also added the ability to use default colors for challenge description text and rewards text. When you have a lot of challenges it is very tedious to start every text with the same color.

Tested and working.

 challenge:
# The main part that generates description text.
# [description] comes from challenge.description
lore: |-
[description]
[status]
[cooldown]
[requirements]
[rewards]
description:
# Formatting applied to description text ([description])
color: '&b'

rewards:
# [text] comes from challenge.rewardText and challenge.repeatRewardText
lore: |-
&7&l Rewards:
[text]
[items]
[experience]
[money]
[commands]
# Formatting applied to reward text ([text])
text-color: '&b'

[BONNe]

hmm, but you can do it with description itself.
the reason it was removed was because it is not necessary....

The description of challenge:

&7line 1
&7Line 2
&7 line 3 with any length you want

This only makes sense, if users create description like:

&7 I will put everything in single line and hope it will be ok. Not sure why tho...

What I would suggest is to split the description text on saving/loading instead of parsing time.
The only I issue what I see is that it is not obvious that text will be split in that case.

[YellowZaki]

hmm, but you can do it with description itself. the reason it was removed was because it is not necessary....

The description of challenge:

&7line 1
&7Line 2
&7 line 3 with any length you want

This only makes sense, if users create description like:

&7 I will put everything in single line and hope it will be ok. Not sure why tho...

What I would suggest is to split the description text on saving/loading instead of parsing time. The only I issue what I see is that it is not obvious that text will be split in that case.

I know that you can create multiline descriptions by manually splitting the text. But it is not convenient. You have to manually split it which takes time. By automatically adjusting it, it saves lot of time.

[tastybento]

Thanks for this, @YellowZaki, and apologies it sat so long.

Since this was opened, Challenges migrated its locales and panels to MiniMessage, and that unfortunately breaks the approach here:

• The lore wrapping (WordUtils.wrap + ChatColor.getLastColors) treats MiniMessage tags like <gray> as visible characters, so it wraps in the wrong place and can split a tag across two lines. getLastColors also only understands legacy § codes, so it can't carry a MiniMessage colour to the next line.
• The &b colour prefix is a legacy code; it won't render through the MiniMessage pipeline (it needs a <...> tag or a hex code that Util.translateColorCodes understands). BentoBox now also preserves per-line colour for legacy codes itself, so that part is largely handled upstream already.
• lore-length: 25 as a default reintroduces the wrapping problems in space-less languages (CJK) that got it removed originally — the -1 opt-out doesn't help anyone who leaves the default.

On top of that it now conflicts across CommonPanel/Settings/config.yml/en-US.yml, so it'd need a rewrite rather than a rebase.

The default text colour idea is genuinely useful though — it's tedious to prefix every challenge's text with the same colour — so I'm going to re-add just that part, implemented to work with the current pipeline, and I'll link the new PR here. Closing this one; thanks again for the idea and the original work.

[tastybento]

Follow-up: the default text-colour feature is re-added, MiniMessage-native, in #418 (description-color / reward-text-color under gui-settings). Thanks again @YellowZaki.

[YellowZaki]

I think lore-length was a great addition. I know it was removed because of problems with some languages. That's why I've made it to be disabled if the user changes it to -1.

I've also added the ability to use default colors for challenge description text and rewards text. When you have a lot of challenges it is very tedious to start every text with the same color.

Tested and working.

 challenge:
# The main part that generates description text.
# [description] comes from challenge.description
lore: |-
[description]
[status]
[cooldown]
[requirements]
[rewards]
description:
# Formatting applied to description text ([description])
color: '&b'

rewards:
# [text] comes from challenge.rewardText and challenge.repeatRewardText
lore: |-
&7&l Rewards:
[text]
[items]
[experience]
[money]
[commands]
# Formatting applied to reward text ([text])
text-color: '&b'

[BONNe]

hmm, but you can do it with description itself.
the reason it was removed was because it is not necessary....

The description of challenge:

&7line 1
&7Line 2
&7 line 3 with any length you want

This only makes sense, if users create description like:

&7 I will put everything in single line and hope it will be ok. Not sure why tho...

What I would suggest is to split the description text on saving/loading instead of parsing time.
The only I issue what I see is that it is not obvious that text will be split in that case.

[YellowZaki]

hmm, but you can do it with description itself. the reason it was removed was because it is not necessary....

The description of challenge:

&7line 1
&7Line 2
&7 line 3 with any length you want

This only makes sense, if users create description like:

&7 I will put everything in single line and hope it will be ok. Not sure why tho...

What I would suggest is to split the description text on saving/loading instead of parsing time. The only I issue what I see is that it is not obvious that text will be split in that case.

I know that you can create multiline descriptions by manually splitting the text. But it is not convenient. You have to manually split it which takes time. By automatically adjusting it, it saves lot of time.

[tastybento]

Thanks for this, @YellowZaki, and apologies it sat so long.

Since this was opened, Challenges migrated its locales and panels to MiniMessage, and that unfortunately breaks the approach here:

• The lore wrapping (WordUtils.wrap + ChatColor.getLastColors) treats MiniMessage tags like <gray> as visible characters, so it wraps in the wrong place and can split a tag across two lines. getLastColors also only understands legacy § codes, so it can't carry a MiniMessage colour to the next line.
• The &b colour prefix is a legacy code; it won't render through the MiniMessage pipeline (it needs a <...> tag or a hex code that Util.translateColorCodes understands). BentoBox now also preserves per-line colour for legacy codes itself, so that part is largely handled upstream already.
• lore-length: 25 as a default reintroduces the wrapping problems in space-less languages (CJK) that got it removed originally — the -1 opt-out doesn't help anyone who leaves the default.

On top of that it now conflicts across CommonPanel/Settings/config.yml/en-US.yml, so it'd need a rewrite rather than a rebase.

The default text colour idea is genuinely useful though — it's tedious to prefix every challenge's text with the same colour — so I'm going to re-add just that part, implemented to work with the current pipeline, and I'll link the new PR here. Closing this one; thanks again for the idea and the original work.

[tastybento]

Follow-up: the default text-colour feature is re-added, MiniMessage-native, in #418 (description-color / reward-text-color under gui-settings). Thanks again @YellowZaki.

[YellowZaki]

I think lore-length was a great addition. I know it was removed because of problems with some languages. That's why I've made it to be disabled if the user changes it to -1.

I've also added the ability to use default colors for challenge description text and rewards text. When you have a lot of challenges it is very tedious to start every text with the same color.

Tested and working.

 challenge:
# The main part that generates description text.
# [description] comes from challenge.description
lore: |-
[description]
[status]
[cooldown]
[requirements]
[rewards]
description:
# Formatting applied to description text ([description])
color: '&b'

rewards:
# [text] comes from challenge.rewardText and challenge.repeatRewardText
lore: |-
&7&l Rewards:
[text]
[items]
[experience]
[money]
[commands]
# Formatting applied to reward text ([text])
text-color: '&b'

[BONNe]

hmm, but you can do it with description itself.
the reason it was removed was because it is not necessary....

The description of challenge:

&7line 1
&7Line 2
&7 line 3 with any length you want

This only makes sense, if users create description like:

&7 I will put everything in single line and hope it will be ok. Not sure why tho...

What I would suggest is to split the description text on saving/loading instead of parsing time.
The only I issue what I see is that it is not obvious that text will be split in that case.

[YellowZaki]

hmm, but you can do it with description itself. the reason it was removed was because it is not necessary....

The description of challenge:

&7line 1
&7Line 2
&7 line 3 with any length you want

This only makes sense, if users create description like:

&7 I will put everything in single line and hope it will be ok. Not sure why tho...

What I would suggest is to split the description text on saving/loading instead of parsing time. The only I issue what I see is that it is not obvious that text will be split in that case.

I know that you can create multiline descriptions by manually splitting the text. But it is not convenient. You have to manually split it which takes time. By automatically adjusting it, it saves lot of time.

[tastybento]

Thanks for this, @YellowZaki, and apologies it sat so long.

Since this was opened, Challenges migrated its locales and panels to MiniMessage, and that unfortunately breaks the approach here:

• The lore wrapping (WordUtils.wrap + ChatColor.getLastColors) treats MiniMessage tags like <gray> as visible characters, so it wraps in the wrong place and can split a tag across two lines. getLastColors also only understands legacy § codes, so it can't carry a MiniMessage colour to the next line.
• The &b colour prefix is a legacy code; it won't render through the MiniMessage pipeline (it needs a <...> tag or a hex code that Util.translateColorCodes understands). BentoBox now also preserves per-line colour for legacy codes itself, so that part is largely handled upstream already.
• lore-length: 25 as a default reintroduces the wrapping problems in space-less languages (CJK) that got it removed originally — the -1 opt-out doesn't help anyone who leaves the default.

On top of that it now conflicts across CommonPanel/Settings/config.yml/en-US.yml, so it'd need a rewrite rather than a rebase.

The default text colour idea is genuinely useful though — it's tedious to prefix every challenge's text with the same colour — so I'm going to re-add just that part, implemented to work with the current pipeline, and I'll link the new PR here. Closing this one; thanks again for the idea and the original work.

[tastybento]

Follow-up: the default text-colour feature is re-added, MiniMessage-native, in #418 (description-color / reward-text-color under gui-settings). Thanks again @YellowZaki.

[YellowZaki]

I think lore-length was a great addition. I know it was removed because of problems with some languages. That's why I've made it to be disabled if the user changes it to -1.

I've also added the ability to use default colors for challenge description text and rewards text. When you have a lot of challenges it is very tedious to start every text with the same color.

Tested and working.

 challenge:
# The main part that generates description text.
# [description] comes from challenge.description
lore: |-
[description]
[status]
[cooldown]
[requirements]
[rewards]
description:
# Formatting applied to description text ([description])
color: '&b'

rewards:
# [text] comes from challenge.rewardText and challenge.repeatRewardText
lore: |-
&7&l Rewards:
[text]
[items]
[experience]
[money]
[commands]
# Formatting applied to reward text ([text])
text-color: '&b'

[BONNe]

hmm, but you can do it with description itself.
the reason it was removed was because it is not necessary....

The description of challenge:

&7line 1
&7Line 2
&7 line 3 with any length you want

This only makes sense, if users create description like:

&7 I will put everything in single line and hope it will be ok. Not sure why tho...

What I would suggest is to split the description text on saving/loading instead of parsing time.
The only I issue what I see is that it is not obvious that text will be split in that case.

[YellowZaki]

hmm, but you can do it with description itself. the reason it was removed was because it is not necessary....

The description of challenge:

&7line 1
&7Line 2
&7 line 3 with any length you want

This only makes sense, if users create description like:

&7 I will put everything in single line and hope it will be ok. Not sure why tho...

What I would suggest is to split the description text on saving/loading instead of parsing time. The only I issue what I see is that it is not obvious that text will be split in that case.

I know that you can create multiline descriptions by manually splitting the text. But it is not convenient. You have to manually split it which takes time. By automatically adjusting it, it saves lot of time.

[tastybento]

Thanks for this, @YellowZaki, and apologies it sat so long.

Since this was opened, Challenges migrated its locales and panels to MiniMessage, and that unfortunately breaks the approach here:

• The lore wrapping (WordUtils.wrap + ChatColor.getLastColors) treats MiniMessage tags like <gray> as visible characters, so it wraps in the wrong place and can split a tag across two lines. getLastColors also only understands legacy § codes, so it can't carry a MiniMessage colour to the next line.
• The &b colour prefix is a legacy code; it won't render through the MiniMessage pipeline (it needs a <...> tag or a hex code that Util.translateColorCodes understands). BentoBox now also preserves per-line colour for legacy codes itself, so that part is largely handled upstream already.
• lore-length: 25 as a default reintroduces the wrapping problems in space-less languages (CJK) that got it removed originally — the -1 opt-out doesn't help anyone who leaves the default.

On top of that it now conflicts across CommonPanel/Settings/config.yml/en-US.yml, so it'd need a rewrite rather than a rebase.

The default text colour idea is genuinely useful though — it's tedious to prefix every challenge's text with the same colour — so I'm going to re-add just that part, implemented to work with the current pipeline, and I'll link the new PR here. Closing this one; thanks again for the idea and the original work.

[tastybento]

Follow-up: the default text-colour feature is re-added, MiniMessage-native, in #418 (description-color / reward-text-color under gui-settings). Thanks again @YellowZaki.