Describe the bug
The current implementation of spectrums the hud element hook causes incompatibilities (the hud element of spectrum not rendering) with multiple mods that overhaul/replace the ingame hud (ex. Armorpoints++).

To Reproduce

1. install spectrum and Armorpoints++
2. observe the hud element of specrum not rendering

Expected behavior
The hud element of spectrum should render.

How to fix
Implement the render callback using HudRenderCallback.EVENT.register(<callback>) of the fabric-rendering-v1 api instead of mixins.
This callback is usually supported by all hud altering mods to keep compatibility with most mods.
Using the callback should pose no problems to this mod's hud render implementation as:

1. the callback is executed at the tail of the core render method, which is later than the current mixin injects, but will not make a difference in result
2. all required parameter values can be obtained from the InGameHud instance within the Minecraft client singleton.

Mod version
1.5.7

Screenshots
Without mods like Armorpoints++:

With Armorpoints++:

Additional context
This issue is related to and was originally posted at Cheos137/ArmorpointsPlusplus#49.
Dedicated compatibility for spectrum will be added to Armorpoints++, however, switching to a more compatible implementation within spectrum - especially when it's easily possible - is recommended nonetheless.

Didn't know there was weirdness with chat rendering.
If that is still the case it's understandable you're not using it.. and then, dedicated compatibility from my side will do the trick :)

I tried using HudRenderCallback.EVENT in the past, but at that time it rendered after rendering the chat window, obscuring the text. I will have to see if that is still the case. In that case moving it to the event would be no issue whatsoever

Sorry I am only getting back to you now.
It's definitely still a thing. As soon as there is a separate event that renders that get's called before the chat rendering I will switch to that one, of course. Thank you for adding compat!

(not centered, because of quick test)

One last thing comes to mind: The newest update ships with a new status effect, that basically set's the player into hardcore mode as long as it is active, switching from default hearts to hardcore hearts as long as it is applied. Since the mixin is in the same method (renderHealthBar), that mixin might fail, too. (

that mixin will probably get ignored, too
ap++ only checks whether the client level is set to hardcore mode, so depending on how you implemented this, it might even work - otherwise i could check for it, too.. you'd just have to tell me where i can find what i need to check for :)

The client level does not get modified - though that would be a great improvement, agreed and noted!
For now, the check for an effect with identifier "spectrum:divinity" will suffice - checking purely for an effects identifier should result in no need for a safe access, even.

Added support for this now, too: Cheos137/ArmorpointsPlusplus@6e804e5

gonna close this issue now as i feel it's no longer needed :)