The image backed by the client buffer which will change on the next
frame, however the screenshot plugin uses both executor thread and EDT
thread to paint the full screenshot, and so it requires the image will
not change. Note the gpu plugin already returns a new image because it
has to pull it out of the GL.
After the introduction of the new ABOVE_MAP layer, the dev tools overlay
was no longer able to draw above the map, which is needed for the widget
inspector.
Prior to this commit, hitpoints exp drops (and combined exp drops
containing hitpoints) would be highlighted for any combat prayer. This
commit corrects this behavior so combined drops will only be highlighted
when containing the proper combat style prayer, and split exp drops will
only highlight hitpoints when the correct prayer type was active for the
experience drops which precede it.
Fixesrunelite/runelite#1697
This adds a test which exposes an edge case where the needed prayer
levels to next combat level had been calculated to be 3 instead of 1,
and fixes that calculation.
Fixesrunelite/runelite#7103
This commit moves constants from the test to the overlay, and replaces
instances of magic numbers with them. It additionally fixes the odd
check in `correctPrayer()` and fixes some minor whitespace issues.
This commit fixes the occasional issue of xp drops not being highlighted
while flicking prayer from the prayer menu; that is, before this commit
it was possible to select or deselect a prayer between xp drop widgets
being spawned, causing different highlighting for them. This commit
saves the active prayer at the beginning of each tick and uses that
tick's prayer for all widgets unhidden during that tick.
Fixesrunelite/runelite#1280Closesrunelite/runelite#6679
Currently we have this implemented inverse. Training should be "details"
as it is more detailed description of what player is currently doing,
and "state" should be "In Game", "In Menu", "Exploring", "Raiding" etc,
as that describes best what is player currently doing (also, e.g for
discord party integration, it is appended after state, so there always
MUST be some state, and this PR ensures that).
Signed-off-by: Tomas Slusny <slusnucky@gmail.com>
