Skip to content

Conversation

@TheArtyrian
Copy link

This PR adds a small change/addition to how ItemRarityTicker.getItemNameColors() locates colors on an ItemStack's name, which then determines the particle color output.


For context as to why I made this PR, I recently wrote loader-agnostic Rarity code for a mod called Appledog, and soon planned to integrate it into a library project I contribute to, RunicLib. This code "simulated" rarities by mixing into ItemStack's getDisplayName() and getTooltipLines() functions; this allows it to render with a unique color instead of a ChatFormatting preset.

As a stress test, I ran Appledog alongside several mods, including Subtle Effects. However, when dropping an Appledog-related item with the unique rarity, the particles rendered using ChatFormatting.RED, which was the fallback color for the custom Rarity. This can be seen in the image below alongside several other modded rarities:

image

The fix to this was a lazy, but simple one that should (likely) catch any edge case like this: if baseColor is null, the code will then read the display name of the stack instead, and see if it can apply the color from there. Unfortunately, this fix will only work when particleColorType = "NAME_COLOR" in the config file, but it at the very least still allows it to render the proper color in some form.

Below is what the Appledog-related items look like with the fix applied (tested on both NF and Fabric):
(NOTE: All other items in the previous screenshot were checked seperately - no changes to their color or any weird issues were found.)

BEFORE (brighter, incorrect red):
image

AFTER (darker, proper red):
image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant