When the varrock armour effect triggers it will smelt two bars at once,
using two charges, unless there is only one ore remaining where it will
use only one charge.
Co-authored-by: Jason Barr <58792686+JBarr2710@users.noreply.github.com>
The ground marker minimap overlay gets a local point for the tile to mark from fromWorld()
and passes it to localToMinimap() - but because the adjustment of -1, when the player position
is subtracted from it to compute the minimap location it causes the computed position to be off
by a full tile.
Additionally, drawRect() width and height is inclusive so the width/height must be subtracted by 1
This interface allows for drastically simplified skill actions, allowing
us to eschew their name entries in favor of looking up the item name
using the items' compositions (fetched from their IDs) at runtime.
As the number of bonus types increases, the existing system of allowing
only a single type of bonus to be applied, and only allowing actions to
entirely opt out of having bonuses applied rather than more fine-grained
control, is showing its age. This commit redefines all bonus and action
entries in Java enums so that such systems can be better-defined.
Additionally, it comes with the benefit of easier change validation via
testing and enabling item and sprite ID referencing via runelite-api.
GPU uses an alternative projection to avoid vertex snapping. Usually
this doesn't matter much, and in the worst case causes the discrepancy
to be only a few pixels, but with the model outline feature it causes
the outlines to be noticibly off when GPU is enabled.
This adds a second model-to-canvas method using the alternative
projection and uses it when GPU is enabled.
If the xptracker is shown, but both counter and progress bar set to off, the xp tracker layer is not actually hidden but only has hidden children. This causes the overlay renderer to layout things around the invisible xptracker. Avoid this by checking the vars for the xptracker to see if it is hidden or not.
Due to an apparent typo, the wrong value was being referenced for the
left bar's Y offset specifically for the resizable viewport with bottom
line interfaces. This commit fixes this reference and the associated
value.
When interacting with another player's cannon, a completely different
message is returned. Using this, if we ever get a normal cannon message
after clicking on a cannon, we can be 100% certain that it is ours.
