This change closes the plugin via the plugin manager, which disables
the plugin, as intended, but also cleans up after the plugin, preventing
any further errors or issues caused by tasks scheduled by the plugin before
it failed.
Backport of 1.13 cf772531f4
The base64 encoding method for server favicons in 1.12 puts newlines in
the encoded string. The 1.13 client and server pair fixed this issue and
no longer consider it valid. Luckily the 1.12.2 client will parse the
correct encoding just fine as well.
This fixes the encoding so that the server icon will display properly on
both 1.12.2 clients as well as newer clients.
Shout out to ViaVersion whose contributors noticed this some time ago.
If the server attempts to load a chunk generated by a newer version of
the game, immediately stop the server to prevent data corruption.
You can override this functionality at your own peril.
Improves doors to better handle unloaded state so they need 1200 LOADED ticks
in order to not be dismissed.
Also improves the villages to not even tick when the center of the village + 1
is not loaded, improving server performance (and helping door issue)
This should keep Iron Titans back working
Vanilla has risk of losing entities by causing them to be
removed from all chunks if they try to move into an unloaded chunk.
This pretty much means high chance this entity will be lost in this scenario.
There is another case that adding an enttiy to the world can fail if
the chunk isn't loaded.
Lots of the server is designed around addEntity never expecting to fail for these reasons,
nor is it really logical.
This change ensures the chunks are always loaded when entities are
added to the world, or a valid entity moves between chunks.
Hopefully will fix issues #1496 and #1434
there is apparently bugs with relighting, so turning toggle back on
also bumped the max time threshold to reduce risk of starving the queue
allows it to violate TPS some, but at cost of better light data
also fixed some chunk neighbor checks
Apparently a zero max health attribute is perfectly fine in vanilla and
our own revive handling code appears to handle the case fine, even when
EntityDeathEvent is cancelled. So we should allow it to avoid issues
when these mobs are killed.
CraftBukkit added synchronization to read and write methods. This adds
much more contention on this object for accessing region files, as
the entire read and write of NBT data is now a blocking operation.
This causes issues when something then simply needs to check if a chunk exists
on the main thread, causing a block...
However, this synchronization was unnecessary, because there is already
enough synchronization done to keep things safe
1) Obtaining a Region File: Those methods are still static synchronized.
Meaning we can safely obtain a Region File concurrently.
2) RegionFile data access: Methods reading and manipulating data from
a region file are also marked synchronized, ensuring that no 2 processes
are reading or writing data at the same time.
3) Checking a region file for chunkExists: getOffset is also synchronized
ensuring that even if a chunk is currently being written, it will be safe.
By removing these synchronizations, we reduce the locking to only
when data is being write or read.
GZIP compression and NBT Buffer creation will no longer be part of the
synchronized context, reducing lock times.
Ultimately: This brings us back to Vanilla, which has had no indication of region file loss.
Modifying of permissions was only half protected, enabling concurrency
issues to occur if permissions were modified async.
While no plugin really should be doing that, modifying operations
are not heavily called, so they are safe to add synchronization to.
Now, all modification API's will be synchronized ensuring safety.
Additionally, hasPermission was victim to a common java newbie mistake
of calling if (containsKey(k)) return get(k), resulting in 2 map lookups.
Optimized it to simply be a single get call cutting permission map
lookups in half.
The PluginManager incorrectly used synchronization on firing any event
that was marked as synchronous.
This synchronized did not even protect any concurrency risk as
handlers were already thread safe in terms of mutations during event
dispatch.
The way it was used, has commonly led to deadlocks on the server,
which results in a hard crash.
This change removes the synchronize and adds some protection around enable/disable
Fixes issue #1177
`MapMaker#weakKeys()` makes the `Map` use identity comparison for the keys, while also enabling the automatical removal of dropped classes from the cache.
The changes are the same as in #1399, except now the original patch is modified instead of a new one being created.
