yurisuika / Raised

Raises the hotbar so the selector is not cut off!
GNU Lesser General Public License v3.0
17 stars 5 forks source link

Blacklist specific HUD Elements from being affected by Raised #82

Closed Wimblerrr closed 7 months ago

Wimblerrr commented 7 months ago

Hi, I was wondering if it would be possible to get an option/ config to blacklist specific HUD elements. In my example here: 2024-01-27_20 20 54 I have simple voice chat installed (bottom left corner), as well es GUI Compass (top middle). Instead of just raising the HUD elements, it seems to raise a copy of them behind the element itself. This is why it's rendered overlaying.

Using raised-forge-1.19.2-3.1.1.jar

yurisuika commented 7 months ago

This is a telling sign that the mod is repeatedly rendering itself. #78 and #64 both are the same issue, in which both had faulty rendering logic that caused them to render multiple times.

This is Forge specific because of how Forge events work. Unfortunately, adding a blacklist is not a solution, because even if you only had 1 element enabled to move (say the food bar), it would still look like that because these mods are likely rendering on every element type event call. Then when that mod rendered off of the food bar rendering, that would be offset while everything else it rendered on would be in the stock position.

If you change the chat offset, you will likely notice a third visual rendering of these items. And if you go out of creative mode, with all the other status bars, record overlay, etc rendering, then they are probably going to be rendering many more times. You will not notice this because they are all synced up, but it is what they have been doing the entire time.

Wimblerrr commented 7 months ago

This is a telling sign that the mod is repeatedly rendering itself. #78 and #64 both are the same issue, in which both had faulty rendering logic that caused them to render multiple times.

This is Forge specific because of how Forge events work. Unfortunately, adding a blacklist is not a solution, because even if you only had 1 element enabled to move (say the food bar), it would still look like that because these mods are likely rendering on every element type event call. Then when that mod rendered off of the food bar rendering, that would be offset while everything else it rendered on would be in the stock position.

If you change the chat offset, you will likely notice a third visual rendering of these items. And if you go out of creative mode, with all the other status bars, record overlay, etc rendering, then they are probably going to be rendering many more times. You will not notice this because they are all synced up, but it is what they have been doing the entire time.

I see. Seems like there isn't any real way to prevent this, other than not using forge. Thank you very much for your explanation though. Gonna close the issue then.

yurisuika commented 7 months ago

Well these issues can be fixed, but the changes would have to come from these mods. It would be a very simple fix for them; they just need to choose which overlay element they want to associate their mod overlay elements with and only run their rendering when the overlay rendering event is of that element type. Why I say this is Forge specific is because on Fabric there are no such events, so people just inject their overlay rendering into the vanilla code they want theirs associated with.

image

For example, on 1.16 these are the Forge overlay element types. When playing in survival, you will often have 10-15 of these being called at any one time. If a mod does not specify what element type to run its rendering on, it will be rendered 10-15 times instead of once. This is what you are seeing.