Clamp mod-provided progress for bossbars#4203
Conversation
|
This is going to need more investigation on the rules that vanilla and mods use to render the progress and whatever there is something that Sponge can do here. The first question is whatever the mod has custom render logic to handle the display of progress? |
|
This line caused exception mentioned in the issue. It's simply 1 tick when entity is hurt below half health (meaning negative bar progress) and on the next tick bossbar is set to full again (so in this case client basically won't notice anything). Easy fix from mod side. |
|
Thank you, thats all I wanted to know. Its just a bug in the mod and not that they have special rendering. |
|
Not really a bug if it works as intended in normal circumstances I guess. |
|
Minecraft is known to have weird edge cases around values out of the vanilla bounds, so anything unusual is unexpected and could be considered a bug. I'm fairly certain sending out of bounds values for the progress used to produce weird rendering bugs. Anyways, thaths besides the point. The changes LGTM. |
|
Yeah, it surely is used. But any solution other than clamping will probably break Adventure's BossBar contract for progress which is not good |
aromaa
left a comment
There was a problem hiding this comment.
My point being that we don't usually consider values out of the vanilla bounds to (ever) be valid and try to sanitize them as mods and plugins tend to not do so themselves and lead to all sorts of weird behavior. So this is just another new place to do so, nothing unusual for us.
That being said, thank you again!
Should solve #4200
The progress restriction of [0, 1] is coming from Adventure. Minecraft doesn't have this restriction so mods don't really care about clamping the value they provide. So I think it would be better to just clamp all mod-provided progress