If the request has its own UA set, don't overwrite it with the default
RuneLite one. This has to be an interceptor and not a network
interceptor so that it runs prior to the okhttp BridgeInteceptor, which
is what sets the default okhttp ua.
When in a party, "Only boss damage" would work only if everyone in the party
had it setup the same. Members who had it enabled would not send their hit to
those who had it disabled. Members who had it enabled would receive and count
hits from those who had it disabled.
This adds an issue form geared specifically toward bug reports, and
links to GitHub discussions for feature requests and enhancements
instead, with the mindset of improving intake triage.
After using 8ad5977ad5 for a while, I
noticed that the plugin would lose calibration seemingly at random.
Given I was sitting at Redwoods, this didn't make sense. I want to give
some context as to what was happening and why, baked permanently into
the commit history:
The plugin requires that a few things exist when it saves data, or else
it assumes that something went wrong and it resets the config. One of
these things is that the infobox object exists.
Usually, this is fine, as one is created on login with the stored
duration, as long as said duration is not negative.
However, if the user stood in the same area for 10 minutes and then
logged out somehow (either manually or through AFK), upon logging back
in the config would not create a new infobox as the stored duration is
negative.
Either toggling the plugin or restarting the client at this point would
clear the reference to the old Infobox, and a new one would not be
created on login due to the aforementioned negative duration.
If the plugin was toggled, the calibration is instantly lost, and the
user now sees the tutorial overlay.
If the client was restarted, it would appear as if the plugin is working
fine, and it would fix itself if the player moved far enough. If they
just logged out, however, it would clear its config.
Either way, in most situations, the user is now forced to recalibrate
the plugin when they've done nothing wrong, only commited the heinous
crime of XP wasting.
Most of this was due to how the plugin tracked the aggro time, which was
through its infobox. This really shouldn't be how it does it, and so now
it keeps track of the time separately, and doesn't rely on the creation
of the infobox to block the saving of data.
While this can be null, in the vast majority of events and also in every overlay it cannot be, and just triggers unncessary warnings from IDE inspections
Remove support for examining npcs/objects which has been unused for a long time. All examines I see go through this examine_item script, so we can assume the ITEM_EXAMINE chat message type is used for all examines.
Since the client does menu sorting after our tick event but before
rendering, it currently renders the wrong menu action. This prevents the
sorting when doing item swaps.
