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.
Added over 500 new locations.
Some locations were merged together, or split further into finer segments.
Removed few locations.
Spelling corrections
Renamed and organised fields.
Renamed few field display labels to give a more intuitive description of the intended world point.
Limited margin of "distance to area" to 128 squares(region length*2) to prevent mislabeling areas. Particularly in instances.
Fixed error which caused each world area to be placed on wrong coordinates along y-axis.
Added Math.abs() to get absolute value when calculating polygon dimensions from coordinates.
The value cannot be more than MAX_VALUE so the previous condition was
never met. Additionally use MAX_QUANTITY constant instead of abusing
char max value which is completely unrelated.
