Question about healthbar rendering [1.12.2]

[theishiopian]

I am trying to make an overlay of the vanilla health bar that changes the color of the first two hearts on the bar. The render works fine, and renders my hearts over the vanilla ones no problem. The trouble is that vanilla hearts tend to shake up and down under various conditions, and these movements are hardcoded and can't be accessed. The solution taken by tinkers construct appears to be to render their own health bar, which is something I'd like to avoid. Is there some way of masking out shapes underneath my render, IE erasing anything on the HUD behind my icons? Or perhaps some way of getting the shake that I don't see? I really REALLY don't want to cancel the vanilla render and make my own health bar if it can be at all avoided, as that would be a compatibility nightmare for other mods that do the same. Is there a decently efficient way to use reflection to get a reference to the field in GUIIngame that stores the y offset for each heart? I hesitate to do that since reflection tends to be rather intensive.

 

 

[Animefan8888]

  On 8/8/2019 at 9:16 PM, theishiopian said:

Is there a decently efficient way to use reflection to get a reference to the field in GUIIngame that stores the y offset for each heart? I hesitate to do that since reflection tends to be rather intensive. 

Expand  

No but it doesn't seem like their motion is random. There are no calls to rand.next... You can replicate the math it all seems to be focused on the updateCounter field which is accessible

Minecraft.getInstance().ingameGUI.getUpdateCounter()

 

[theishiopian]

I did see a call to rand.nextInt(), Ill find it when I get home. It may turn out to be extraneous though, in which case I'll use the update counter.

[Animefan8888]

  On 8/8/2019 at 11:20 PM, theishiopian said:

I did see a call to rand.nextInt(), Ill find it when I get home. It may turn out to be extraneous though, in which case I'll use the update counter.

Expand  

There is a single one unfortunately but it only happens when the health is less than or equal to 4(2 hearts). Which I assume you won't influence you too much and they also apply a seed to the random before rendering the health so it should always result in the same value.

[theishiopian]

Since by default my effect really kicks in at 4 hearts, it unfortunately does influence me. However, the seed does help, where does it come from? I'm not at my dev environment currently so I can't find it myself.

[Animefan8888]

  On 8/8/2019 at 11:44 PM, theishiopian said:

Since by default my effect really kicks in at 4 hearts, it unfortunately does influence me. However, the seed does help, where does it come from? I'm not at my dev environment currently so I can't find it myself.

Expand  

It's based on the update counter multiplied by 312871.

[theishiopian]

Ah, perfect. so If i get the update counter and multiply, the seed should give me the same number? or will the update counter have updated by the time my code calls?

[Animefan8888]

  On 8/9/2019 at 12:24 AM, theishiopian said:

Ah, perfect. so If i get the update counter and multiply, the seed should give me the same number? or will the update counter have updated by the time my code calls?

Expand  

Should all work fine.

[theishiopian]

kk, excellent. 

[theishiopian]

@Animefan8888 I tried setting the seed, but it doesn't seem to work at all. I think I'm going to rethink my effect, the health rendering section is a mess of obfuscated fields that make no sense.

[Animefan8888]

  On 8/9/2019 at 3:44 AM, theishiopian said:

@Animefan8888 I tried setting the seed, but it doesn't seem to work at all. I think I'm going to rethink my effect, the health rendering section is a mess of obfuscated fields that make no sense.

Expand  

Did you copy all of the positioning code?

[theishiopian]

There's about a dozen fields with names like j6 or k4. I could spend a few hours picking apart all that junk, or make a much more reliable indicator that gets the same idea across without jiggling.