- Cashed out players were treated as combat-logged players
- Player inventories were not cleared before returning items, resulting
in duplicated items
- Players would be given the "locked slot" item
- Allow multiple stacks of the same type and amount
Communities will only be refreshed if:
- We know (via redis message) that the community has been changed (e.g.,
if a member joins/leaves, if an invite is sent, ...).
- Five minutes have passed since a full refresh
This is to fix a troublesome race condition occurring between Mineplexer
and Core. Simply put, the following steps occur normally:
1) Player logs in via Bungee
2) If there is no PlayerInfo entry, PlayerStats inserts a PlayerInfo entry
into Redis
3) CoreClientManager looks for the PlayerInfo entry and finds it
4) If the PlayerInfo entry was just inserted, it will have accountId=0.
CoreClientManager sees this and updates it to a valid accountId, then
reinserts into Redis
5) All is good
However, sometimes Step 3 occurs before Step 2 (perhaps latency to Redis
is a factor), and so CoreClientManager
sees a null entry and ignores it. Then, an invalid PlayerInfo entry is
inserted with accountId=0, which then breaks any SQL queries relying on an
valid accountId
Negative yaw values are considered valid in minecraft.
UtilShapes doesn't correctly handle negative yaw values
(throws an ArrayIndexOutOfBoundsException) so whenever
a player is facing east they're unable to activate Frost
Barrier.
This commit fixes the issue by allowing UtilShapes to take
negative values.
