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
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.
The darker() is originally from the npc indicators minimap overlay, but other plugins now using this such as impling plugin do not expect this.
If we require the minimap colors to be different later we should add a separate property specifically for it.
This allows the other plugins which depend on the npc overaly to work
when npc highlight plugin is off, while still letting them use the
consistent highlight style of the central overlay.
Lightweight components do not render correctly over AWT canvases on
MacOS. The popup factory API to override this is not available on 8, so
add an 11-specific popup factory to override it by using a multi-release
jar.
With the new steam client updates, the client tries to aggressively
move around several of the widget overlay components, including xp
tracker, and several hp bars. This tends to fight with the layouting we
already do with the widgets.
This changes the widgets to only be layouted if the overlay has a
preferred location or position set. Otherwise, it will offset the snap
corner bounds by where the client has positione the widget.
It is still possible to get the client ui to fight the widget overlay by
moving the overlays around manually, but it should no longer happen in
the default positioning of the widgets.
After changing the slayer plugin to use npc indicators for the outline
style, some users request being able to set the color of slayer
highlights to be unique in order to identify marked npcs such as
superiors while slaying. This readds the previous target color config
and adds new highlight style options to the slayer plugin.
The ChatPlayers do not implement equals or hashCode, making them
unsuitable as a hashmap key. Instead just use a linked list and compare
the members using the comparable interface.
Closing and opening the sidebar when the side panel is collapsed
currently expands the side panel to the most recently opened panel,
even if it was collapsed at the time the sidebar was closed, and also
incorrectly doesn't set the nav button as selected.
This changes the behavior of expanding the sidebar to not open the side
panel if it was not opened at the time the sidebar was closed.
The client attempts to force these to always be below the xp tracker,
and having them at an equal priority can cause our overlay renderer to
fight it by laying out them above the xp tracker
This adds support for moving the wilderness icon layer, which is not in
an area near a snap corner. With no preferred location set the overlay
adjusts its bounds to the widget bounds and will not adjust the widget
position.
The object spawn event happens after the lighting animation, which was
causing it to create a new burner with the default timers applied
instead of the one applied via the fm level.
Also fix computing upper limit on the random timer which is not
inclusive of the fm level
Setting the start time to null isn't necessary, since IN_MENU is marked
shouldRestart, it always resets the start time when the status is changed to
menu. This was clearing it, forcing a presence update, and then erroring when
trying to compute the original start time. It also would have never really unset,
even if it wasn't erroring later, due to IN_MENU also being unclearable, and
so would have never been removed in the first place.
Additionally the status reset test is also wrong since it is testing the end
timestamp which has never been used by us, making the test useless.
The non-items examine info has been broken for years, and the wiki already has item examines anyway, so we can use those in the future if we need them.
