Due to JDK-4737788, maximizing an undecorated frame incorrectly covers the
taskbar. Substance attempts to correct this by computing its own maximized
bounds, but it does not account for DPI scaling. Since Substance automatically
calls setMaximizedBounds when the frame is resized to do this we simply
override it and replace the bounds with our own which includes the scaling of
the display.
This also fixes the frame maximizing to the incorrect display on 11.0.8 due to
JDK-8231564, which changes the coordinates setMaximizedBounds() expects to be
relative to the primary display instead of the current display. Previously,
Substance was always setting the bounds x/y to 0 due to this.
Co-authored-by: Runemoro <runemoro1@gmail.com>
Not sure where these original arguments come from, but it was
incorrectly noting the items and then attempting to adjust zoom to
account for that, which makes most item outlines slightly off
Two infernal max cape items exist: one being the item which players can
use, and another presumably being the item displayed in the dialog shown
when combining a max cape and an infernal cape. `INFERNAL_MAX_CAPE` is
the definition for the latter cape, and `INFERNAL_MAX_CAPE_21285` is the
real item players would have.
Mining dense essense doesn't have a chat message so this starts the mining session based on animation instead.
Co-authored-by: chasertw123 <henderson.chase@gmail.com>
Added Math.min() & Math.max() when passing point coordinates.
This makes it easier to add new locations without having to worry about entering the specific coordinates to the respective parameter.
I.e. no need to follow the previously addressed convention.
...Just in case.
• Adjusted a few locations tiny bit.
• Removed Wilderness Obelisk 27 Portal as I felt Wilderness GWD is so close and is a more descriptive location.
Update PlayerManager to work with the latest changes made to high risk worlds.
Protect item prayer is completely disabled on high risk worlds.
Also changed the ternary operator to only apply if the prayer level is less than 25, since players can use the prayer if they are 25 prayer.
After some testing I found that a niche issue arises from the combination of the alphabetical sorting and the for loop. This aims to band-aid the issue as best possible until proper rework is done.
Renamed fields
Appended main areas (BB) which house other locations with `_ZONE` .
Example
Old → `HOSIDIUS("Hosidius", new Location(1737, 3627, 1789, 3582), 0),`
New → `HOSIDIUS_ZONE("Hosidius", new Location(1737, 3627, 1789, 3582), 0),`
Reason for this is to solve a problem with the `for loop` responsible for iterating over all locations to find which one the player is located in.
Since they are sorted alphabetically, `HOSIDIUS` comes before `HOSIDIUS_BANK` or any other location prefixed with "hosidius".
Disregarding if `worldArea ∈ BB`.
So, coincidentally, appending BB areas with `_ZONE` is just a lucky "solution" as a result of the alphabetical sorting to push the area down in the hierarchy.
To be clear; This is a hack, not a proper solution.
Ideally, in a perfect world the entire thing would be replaced by a proper R-Tree or other spatial access method.
However, for now, this is as good as it gets seeing as it'd be a pretty big task.
