Add default colour for challenge description and reward text

[tastybento]

Replaces the closed#340 (see the closing note there for why the original couldn't be merged — MiniMessage migration broke its legacy-colour wrapping and &b prefixing).

This keeps the genuinely useful idea from that PR — a default text colour so admins don't have to prefix every challenge's description/reward text with the same colour code — reimplemented to work with the current pipeline.

What it adds

Two new gui-settings, both empty by default (no behaviour change):

• description-color — colour applied to each line of a challenge's own description text.
• reward-text-color — colour applied to each line of a challenge's own first-time and repeat reward text.

Utils.applyDefaultColor(text, color) prefixes every line (so multi-line text stays coloured on each lore line) and runs beforeUtil.translateColorCodes, so it uses the same & / hex codes (e.g. &b, &#55FFFF) as the challenge text. A colour written in the text itself still overrides the default (a later code wins). Only the challenge's own data-field text is affected — per-challenge locale overrides are left alone (admins colour those directly).

Deliberately left out

The lore-length line-wrapping half of #340 is not included:

• It used WordUtils.wrap + ChatColor.getLastColors, which miscount/mangle MiniMessage tags.
• Its default (25) reintroduced the space-less-language (CJK) wrapping problems it was removed for.
• The panel already wraps reward text via wrapToWidth().

Tests

UtilsTest covers applyDefaultColor: blank/null colour → unchanged, empty/null text → unchanged, single-line and multi-line prefixing, blank-line preservation, and hex colours. Full suite green (508 tests).

Closes the loop on #340.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
60.5% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[tastybento]

Replaces the closed#340 (see the closing note there for why the original couldn't be merged — MiniMessage migration broke its legacy-colour wrapping and &b prefixing).

This keeps the genuinely useful idea from that PR — a default text colour so admins don't have to prefix every challenge's description/reward text with the same colour code — reimplemented to work with the current pipeline.

What it adds

Two new gui-settings, both empty by default (no behaviour change):

• description-color — colour applied to each line of a challenge's own description text.
• reward-text-color — colour applied to each line of a challenge's own first-time and repeat reward text.

Utils.applyDefaultColor(text, color) prefixes every line (so multi-line text stays coloured on each lore line) and runs beforeUtil.translateColorCodes, so it uses the same & / hex codes (e.g. &b, &#55FFFF) as the challenge text. A colour written in the text itself still overrides the default (a later code wins). Only the challenge's own data-field text is affected — per-challenge locale overrides are left alone (admins colour those directly).

Deliberately left out

The lore-length line-wrapping half of #340 is not included:

• It used WordUtils.wrap + ChatColor.getLastColors, which miscount/mangle MiniMessage tags.
• Its default (25) reintroduced the space-less-language (CJK) wrapping problems it was removed for.
• The panel already wraps reward text via wrapToWidth().

Tests

UtilsTest covers applyDefaultColor: blank/null colour → unchanged, empty/null text → unchanged, single-line and multi-line prefixing, blank-line preservation, and hex colours. Full suite green (508 tests).

Closes the loop on #340.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
60.5% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[tastybento]

Replaces the closed#340 (see the closing note there for why the original couldn't be merged — MiniMessage migration broke its legacy-colour wrapping and &b prefixing).

This keeps the genuinely useful idea from that PR — a default text colour so admins don't have to prefix every challenge's description/reward text with the same colour code — reimplemented to work with the current pipeline.

What it adds

Two new gui-settings, both empty by default (no behaviour change):

• description-color — colour applied to each line of a challenge's own description text.
• reward-text-color — colour applied to each line of a challenge's own first-time and repeat reward text.

Utils.applyDefaultColor(text, color) prefixes every line (so multi-line text stays coloured on each lore line) and runs beforeUtil.translateColorCodes, so it uses the same & / hex codes (e.g. &b, &#55FFFF) as the challenge text. A colour written in the text itself still overrides the default (a later code wins). Only the challenge's own data-field text is affected — per-challenge locale overrides are left alone (admins colour those directly).

Deliberately left out

The lore-length line-wrapping half of #340 is not included:

• It used WordUtils.wrap + ChatColor.getLastColors, which miscount/mangle MiniMessage tags.
• Its default (25) reintroduced the space-less-language (CJK) wrapping problems it was removed for.
• The panel already wraps reward text via wrapToWidth().

Tests

UtilsTest covers applyDefaultColor: blank/null colour → unchanged, empty/null text → unchanged, single-line and multi-line prefixing, blank-line preservation, and hex colours. Full suite green (508 tests).

Closes the loop on #340.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
60.5% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[tastybento]

Replaces the closed#340 (see the closing note there for why the original couldn't be merged — MiniMessage migration broke its legacy-colour wrapping and &b prefixing).

This keeps the genuinely useful idea from that PR — a default text colour so admins don't have to prefix every challenge's description/reward text with the same colour code — reimplemented to work with the current pipeline.

What it adds

Two new gui-settings, both empty by default (no behaviour change):

• description-color — colour applied to each line of a challenge's own description text.
• reward-text-color — colour applied to each line of a challenge's own first-time and repeat reward text.

Utils.applyDefaultColor(text, color) prefixes every line (so multi-line text stays coloured on each lore line) and runs beforeUtil.translateColorCodes, so it uses the same & / hex codes (e.g. &b, &#55FFFF) as the challenge text. A colour written in the text itself still overrides the default (a later code wins). Only the challenge's own data-field text is affected — per-challenge locale overrides are left alone (admins colour those directly).

Deliberately left out

The lore-length line-wrapping half of #340 is not included:

• It used WordUtils.wrap + ChatColor.getLastColors, which miscount/mangle MiniMessage tags.
• Its default (25) reintroduced the space-less-language (CJK) wrapping problems it was removed for.
• The panel already wraps reward text via wrapToWidth().

Tests

UtilsTest covers applyDefaultColor: blank/null colour → unchanged, empty/null text → unchanged, single-line and multi-line prefixing, blank-line preservation, and hex colours. Full suite green (508 tests).

Closes the loop on #340.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
60.5% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[tastybento]

Replaces the closed#340 (see the closing note there for why the original couldn't be merged — MiniMessage migration broke its legacy-colour wrapping and &b prefixing).

This keeps the genuinely useful idea from that PR — a default text colour so admins don't have to prefix every challenge's description/reward text with the same colour code — reimplemented to work with the current pipeline.

What it adds

Two new gui-settings, both empty by default (no behaviour change):

• description-color — colour applied to each line of a challenge's own description text.
• reward-text-color — colour applied to each line of a challenge's own first-time and repeat reward text.

Utils.applyDefaultColor(text, color) prefixes every line (so multi-line text stays coloured on each lore line) and runs beforeUtil.translateColorCodes, so it uses the same & / hex codes (e.g. &b, &#55FFFF) as the challenge text. A colour written in the text itself still overrides the default (a later code wins). Only the challenge's own data-field text is affected — per-challenge locale overrides are left alone (admins colour those directly).

Deliberately left out

The lore-length line-wrapping half of #340 is not included:

• It used WordUtils.wrap + ChatColor.getLastColors, which miscount/mangle MiniMessage tags.
• Its default (25) reintroduced the space-less-language (CJK) wrapping problems it was removed for.
• The panel already wraps reward text via wrapToWidth().

Tests

UtilsTest covers applyDefaultColor: blank/null colour → unchanged, empty/null text → unchanged, single-line and multi-line prefixing, blank-line preservation, and hex colours. Full suite green (508 tests).

Closes the loop on #340.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
60.5% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[tastybento]

Replaces the closed#340 (see the closing note there for why the original couldn't be merged — MiniMessage migration broke its legacy-colour wrapping and &b prefixing).

This keeps the genuinely useful idea from that PR — a default text colour so admins don't have to prefix every challenge's description/reward text with the same colour code — reimplemented to work with the current pipeline.

What it adds

Two new gui-settings, both empty by default (no behaviour change):

• description-color — colour applied to each line of a challenge's own description text.
• reward-text-color — colour applied to each line of a challenge's own first-time and repeat reward text.

Utils.applyDefaultColor(text, color) prefixes every line (so multi-line text stays coloured on each lore line) and runs beforeUtil.translateColorCodes, so it uses the same & / hex codes (e.g. &b, &#55FFFF) as the challenge text. A colour written in the text itself still overrides the default (a later code wins). Only the challenge's own data-field text is affected — per-challenge locale overrides are left alone (admins colour those directly).

Deliberately left out

The lore-length line-wrapping half of #340 is not included:

• It used WordUtils.wrap + ChatColor.getLastColors, which miscount/mangle MiniMessage tags.
• Its default (25) reintroduced the space-less-language (CJK) wrapping problems it was removed for.
• The panel already wraps reward text via wrapToWidth().

Tests

UtilsTest covers applyDefaultColor: blank/null colour → unchanged, empty/null text → unchanged, single-line and multi-line prefixing, blank-line preservation, and hex colours. Full suite green (508 tests).

Closes the loop on #340.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
60.5% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[tastybento]

Replaces the closed#340 (see the closing note there for why the original couldn't be merged — MiniMessage migration broke its legacy-colour wrapping and &b prefixing).

This keeps the genuinely useful idea from that PR — a default text colour so admins don't have to prefix every challenge's description/reward text with the same colour code — reimplemented to work with the current pipeline.

What it adds

Two new gui-settings, both empty by default (no behaviour change):

• description-color — colour applied to each line of a challenge's own description text.
• reward-text-color — colour applied to each line of a challenge's own first-time and repeat reward text.

Utils.applyDefaultColor(text, color) prefixes every line (so multi-line text stays coloured on each lore line) and runs beforeUtil.translateColorCodes, so it uses the same & / hex codes (e.g. &b, &#55FFFF) as the challenge text. A colour written in the text itself still overrides the default (a later code wins). Only the challenge's own data-field text is affected — per-challenge locale overrides are left alone (admins colour those directly).

Deliberately left out

The lore-length line-wrapping half of #340 is not included:

• It used WordUtils.wrap + ChatColor.getLastColors, which miscount/mangle MiniMessage tags.
• Its default (25) reintroduced the space-less-language (CJK) wrapping problems it was removed for.
• The panel already wraps reward text via wrapToWidth().

Tests

UtilsTest covers applyDefaultColor: blank/null colour → unchanged, empty/null text → unchanged, single-line and multi-line prefixing, blank-line preservation, and hex colours. Full suite green (508 tests).

Closes the loop on #340.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
60.5% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[tastybento]

Replaces the closed#340 (see the closing note there for why the original couldn't be merged — MiniMessage migration broke its legacy-colour wrapping and &b prefixing).

This keeps the genuinely useful idea from that PR — a default text colour so admins don't have to prefix every challenge's description/reward text with the same colour code — reimplemented to work with the current pipeline.

What it adds

Two new gui-settings, both empty by default (no behaviour change):

• description-color — colour applied to each line of a challenge's own description text.
• reward-text-color — colour applied to each line of a challenge's own first-time and repeat reward text.

Utils.applyDefaultColor(text, color) prefixes every line (so multi-line text stays coloured on each lore line) and runs beforeUtil.translateColorCodes, so it uses the same & / hex codes (e.g. &b, &#55FFFF) as the challenge text. A colour written in the text itself still overrides the default (a later code wins). Only the challenge's own data-field text is affected — per-challenge locale overrides are left alone (admins colour those directly).

Deliberately left out

The lore-length line-wrapping half of #340 is not included:

• It used WordUtils.wrap + ChatColor.getLastColors, which miscount/mangle MiniMessage tags.
• Its default (25) reintroduced the space-less-language (CJK) wrapping problems it was removed for.
• The panel already wraps reward text via wrapToWidth().

Tests

UtilsTest covers applyDefaultColor: blank/null colour → unchanged, empty/null text → unchanged, single-line and multi-line prefixing, blank-line preservation, and hex colours. Full suite green (508 tests).

Closes the loop on #340.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
60.5% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud