[liquid]

Players.getLocal().getHealthGauge().getPercent() throws a NPE if the over-head adrenaline bar (example) is not visible. If it is visible, it'll return the player's adrenaline percent.

Likely caused by the recent game-updates surrounding combat (legacy mode, graphical changes, etc.)

 

[cloud]

Players.getLocal().getHealthGauge().getPercent() throws a NPE if the over-head adrenaline bar (example) is not visible. If it is visible, it'll return the player's adrenaline percent.

Likely caused by the recent game-updates surrounding combat (legacy mode, graphical changes, etc.)

Not a bug actually, if the health/adrenaline gauge isn't visible then the data related to it isn't available, so the gauge returns null.

 

[liquid]

Not a bug actually, if the health/adrenaline gauge isn't visible then the data related to it isn't available, so the gauge returns null.

getHealthGauge()#getPercent() is returns the value of getAdrenalineGauge()#getPercent(), and getAdrenalineGauge()#getPercent() returns null even if it is visible.

It is a bug.

Also, I would much rather it was implemented from the gathering of data of the actionbar. Why one should only be able to return the player's health percent whilst they are in combat, I do not know.

 

[cloud]

getHealthGauge()#getPercent() is returns the value of getAdrenalineGauge()#getPercent(), and getAdrenalineGauge()#getPercent() returns null even if it is visible.

It is a bug.

Also, I would much rather it was implemented from the gathering of data of the actionbar. Why one should only be able to return the player's health percent whilst they are in combat, I do not know.

Oh I'm sorry originally I misunderstood you. I'll check into it.

In response to your other question, if you'd like to get the data from the actionbar then you can. The rs3 package contains an ActionBar class that contains methods such as getHealth and getMaximumHealth. Those are more appropriate for when you're just looking for the local players health, but when it comes to other npcs the only way you can check their health is through the combat gauges

 

[liquid]

Oh I'm sorry originally I misunderstood you. I'll check into it.

In response to your other question, if you'd like to get the data from the actionbar then you can. The rs3 package contains an ActionBar class that contains methods such as getHealth and getMaximumHealth. Those are more appropriate for when you're just looking for the local players health, but when it comes to other npcs the only way you can check their health is through the combat gauges

I see it now, thanks (-:

Spoiler

Ended up re-coding it myself, using the text from the action-bar

private static final InterfaceComponent HEALTH_COMPONENT = Interfaces.getAt(1430, 4, 7);

private static String healthTextAb() {
  return HEALTH_COMPONENT.getText();
}

private static double getMaximumHealthAb() {
  String h = healthTextAb();
  return Double.parseDouble(h.substring(h.indexOf("/") + 1, h.length()));
}

private static double getHealthAb() {
  String h = healthTextAb();
  return Double.parseDouble(h.substring(0, h.indexOf("/")));
}

public static int getHealthPercentAb() {
  return (int) Math.round(getHealthAb() / getMaximumHealthAb() * 100);
}

 

[cloud]

May I ask why you did that (Unless it was before you knew in which case I completely understand)?

 

[liquid]

May I ask why you did that (Unless it was before you knew in which case I completely understand)?

Already started before you posted the reply

Spoiler

By the way, this pretty much sums up the problem

As you see, health is reported to be at 100%.

 

[cloud]

Already started before you posted the reply

Spoiler

By the way, this pretty much sums up the problem

As you see, health is reported to be at 100%.

Yeah I found the problem in the code, I'm writing a better framework for the data structure the game uses so I don't have any similar problems in the future

 

[wyn]

Yeah I found the problem in the code, I'm writing a better framework for the data structure the game uses so I don't have any similar problems in the future

Use settings/varps for getting actionbar you nub. You shouldn't be using widgets with almost all of the bars accessible through them.

 

[cloud]

Use settings/varps you nub. You shouldn't be using widgets with them accessible.

What? We're talking about the combat gauges that appear above players heads?

 

[wyn]

What? We're talking about the combat gauges that appear above players heads?

Players.getLocal().getHealthGauge().getPercent()
Players.getLocal().getAdrenalineGauge()#getPercent()

There are settings/varps for those, same for maximum health. No reason to check widgets.

 

[cloud]

Yeah I found the problem in the code, I'm writing a better framework for the data structure the game uses so I don't have any similar problems in the future

As a followup, I've gone ahead and written a nice wrapper around a LinkedList implementation in the game engine to help me better manage when things related to their linked lists. The hooks were also updated, and because of that until the next release both gauges will return the health gauges value (instead of the adrenaline gauges, but everything is fixed in the next release).

 

[cloud]

Players.getLocal().getHealthGauge().getPercent()
Players.getLocal().getAdrenalineGauge()#getPercent()

There are settings/varps for those, same for maximum health. No reason to check widgets.

Mate, that's only for the local player, you're forgetting that other Actors also have combat gauges lol. Using the CombatBar class to just get the local players data works fine and does use varps, but for other Actors you need to rely on their CombatGauges

 

[wyn]

Mate, that's only for the local player, you're forgetting that other Actors also have combat gauges lol. Using the CombatBar class to just get the local players data works fine and does use varps, but for other Actors you need to rely on their CombatGauges

I assumed you used settings automatically for the localplayer for any methods that can easily be checked with settings. .

 

[cloud]

I guessed you used settings automatically for the localplayer for any methods that can easily be checked with settings. .

Yeah no problem mate, but when somethings local player specific I tend to put it in separate classes to not cause any confusion.