This reverts commit 397a71a602.
Apparently this doesn't actually fix the issue. Some things
just straight up happen without sending events to plugins and there's
nothing we can do about it.
By the time this code is called, the performance hit happened already.
There's a separate way to whitelist these that still allows keeping
the protections active.
When worlds first load, events start happening before plugins normally
(POSTWORLD) enable. This means that regions and other protections won't
be active when these events are called.
This shouldn't break anything that depends on us, e.g. custom flags,
since our API contract already states that should be done on load,
and all plugins are loaded on startup (just not enabled).
This functionally reverts e5b76a5, though individual classes can change
this behavior on an individual basis by overriding the method.
Also, make time-lock and weather-lock restore only initial values,
which should be more intuitive behavior when multiple regions overlap
with different flag values.
Enderchests are not modified on use. In fact, they don't even
have inventories, so they are not modified at all. To deny usage,
the interact flag must be denied, since they most closely fit in
a category with other interact-covered blocks (and not use-covered
blocks, since using them does not change the region in any way).
This commit reverts f7d36b and ea4f4c0.
When set to allow, allows players to rotate item in item frames even if
they wouldn't normally have permissions to modify the item frame.
Fixes WORLDGUARD-3588.
* Send/receive chat and allowed/blocked cmd flags now respect deny-message flag.
* Added `regions.cancel-chat-without-recipients` option to disable the default behavior.
It is possible, for example when teleporting between two worlds, that
regions in two different managers are compared. If the regions in each
world have the same name, they would return equal. Removing the equals
override will prevent two different regions from seeming equal even if
they are not.
Apparently the spigot server stores time-lock between logout and login,
but not weather-lock. This should work around any such issues by
re-applying handlers on login.
