There are 2 animations for each pearl rod (except Oily). Usually it
seems that only one is used when actually fishing, which were the ones
present before this commit. However, it seems that Jagex is not
consistent about what animations are used, as Anglerfish fishing uses
the other animation of the normal pearl rod. Given that the other two
exist, and they're technically usable (and can be used as the starting
animation), it's only a matter of time before Jagex accidentally gets
them the wrong way round again, so this is a pre-emptive measure. It
also means that the UI won't show "Not Fishing" for a split second when
casting out.
Splits the RUNELITE menu action into two actions:
RUNELITE - general menu items.
RUNELITE_PLAYER - menu items which target a player and have its identifier set to a player index.
Then the player indicators plugin is changed to only decorate RUNELITE_PLAYER menu items.
If you left a raid while a raid was currently being
scouted/held in the same world then there was a chance the
plugin would not reset and the scout overlay and timer
would break. This was due to the plugin thinking that the
player was in a raid party when he left and did not reset.
This was fixed by reseting whenever the raid party varp
changed while the player is outside of the raid.
steps to reproduce:
start a raid on account 1
scout another raid in the same world on account 2
leave the raid on account 1 and it will not reset correctly
Each of the pearl rods have 2 animation IDs, with one of them showing
the casting of the rod. This casting animation is used by the normal and
oily rods. However, for whatever reason, the Fly fishing and Barbarian
rods both use the non-casting animation whilst active.
this reverts commit abaf45092b
We need to run this every frame because the client can update the widget
bounds cache without calling [proc,toplevel_resize]. This is easily
reproducible by resizing the client in fixed mode, which causes the
the tli to be revalidated, but because its in fixed mode it doesn't run
the resize listener because the bounds don't actually change.
We use BeforeRender instead of ClientTick because ClientTick is posted
before cs2s are evaluated each tick, so if [proc,toplevel_resize] (or
any other cs2 that can touch these widgets) is called the widget would
be in the vanilla position for the next frame.
Max Weber