Prevents an issue with clients being resizable with toolbar-less means in some environments (e.g. double clicking title bar on macos).
Honestly I'm not entirely sure why this is ignored if the window isn't visible, rather than being propagated to the window manager when the window is shown, but I guess Swing isn't that smart (like always).
I originally found the information on [this SO answer](https://stackoverflow.com/a/14884056) and it seemed to resolve the issue.
Closes#14235
This used to use the shift-click teleport spells option, but now that
there are 4 different teleport spells, a dedicated swap config is best.
Co-authored-by: Adam <Adam@sigterm.info>
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.
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.
