Additional Item Rarity Color Check #193
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds a small change/addition to how
ItemRarityTicker.getItemNameColors()locates colors on anItemStack'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'sgetDisplayName()andgetTooltipLines()functions; this allows it to render with a unique color instead of aChatFormattingpreset.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:The fix to this was a lazy, but simple one that should (likely) catch any edge case like this: if
baseColorisnull, 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 whenparticleColorType = "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):

AFTER (darker, proper red):
