Use a chunk status cache to check if we could potentially overwrite
a levelchunk.
The check could be entirely elided at the risk of overwriting chunk data,
however most protochunks should have their corresponding regionfile loaded
with their chunk status.
We should only set hasBeenLoaded to false potentially after saving a chunk
other wise we will not save it. The method to do this is
PlayerChunk#l(), which we were potentially calling for chunks we were not saving.
* Fix World#isChunkGenerated calls
Optimize World#loadChunk() too
This patch also adds a chunk status cache on region files (note that
its only purpose is to cache the status on DISK)
* Ensure correct regionfile usage
This also bumps the minimum region file cache to 4 files given
readChunkData can load potentially 4 files.
* Fix closed check
* Better checks for invalid regionfile usage
* Updated Upstream (Bukkit/CraftBukkit)
Upstream has released updates that appears to apply and compile correctly.
This update has not been tested by PaperMC and as with ANY update, please do your own testing
Bukkit Changes:
45690fe9 SPIGOT-5047: Correct slot types for 1.14 inventories
CraftBukkit Changes:
4090d01f SPIGOT-5047: Correct slot types for 1.14 inventories
e8c08362 SPIGOT-5046: World#getLoadedChunks returning inaccessible cached chunks.
d445af3b SPIGOT-5067: Add item meta for 1.14 spawn eggs
* Bring Chunk load checks in-line with spigot
As of the last upstream merge spigot now checks ticket level status
when returning loaded chunks for a world from api. Now our checks
will respect that decision.
* Fix spawn ticket levels
Vanilla would keep the inner chunks of spawn available for ticking,
however my changes made all chunks non-ticking. Resolve by changing
ticket levels for spawn chunks inside the border to respect this
behavior.
* Make World#getChunkIfLoadedImmediately return only entity ticking chunks
Mojang appears to be using chunks with level > 33 (non-ticking chunks)
as cached chunks and not actually loaded chunks.
* Bring all loaded checks in line with spigot
Loaded chunks must be at least border chunks, or level <= 33
Upstream has released updates that appears to apply and compile correctly.
This update has not been tested by PaperMC and as with ANY update, please do your own testing
CraftBukkit Changes:
17543ecf SPIGOT-5035: Error Using Virtual Merchant GUI
0fc6922b SPIGOT-5028: Villager#setVillagerExperience() doesn't work
bdbdbe44 SPIGOT-5024: Fox error - Unknown target reason
Upstream has released updates that appears to apply and compile correctly.
This update has not been tested by PaperMC and as with ANY update, please do your own testing
CraftBukkit Changes:
ba575a5a SPIGOT-4992: Various villager issues due to broken mapping
Upstream has released updates that appears to apply and compile correctly.
This update has not been tested by PaperMC and as with ANY update, please do your own testing
Bukkit Changes:
e041de28 SPIGOT-4946: Add VillagerCareerChangeEvent
CraftBukkit Changes:
fcb9f90b SPIGOT-4946: Add VillagerCareerChangeEvent
a4a2f679 SPIGOT-4987: Shulkerbox does not save empty slots
We were missing a synchronize on a get if cached method, however
it appears that using a ConcurrentHashMap is a better solution
so readers can avoid locking if they just want a cached value.
Existing synchronization for writers remains untouched, the
ConcurrentHashMap is just so readers can safely read without
synchronization
md_5 changed it so he could shut down the server asynchronously
from watchdog, although we have patches that prevent that type
of behavior for this exact reason.
The lock in DataWatcher is used to prevent concurrent modifications
to the 'd' field (entries in MCP). However any modifications to
this map only occur on initialization of an Entity in its
constructor. This modification is write-locked.
Every other access is through a readlock, which allows
the threads to pass if there is no thread holding the
writelock.
Since the writelock is only obtained in the constructor
of the Entity, the further readlocks are actually
useless (which get obtained on set, get, etc calls).
The entries field ('d' currently) has also been declared as
Int2ObjectOpenHashMap to avoid autoboxing on put(), get(), etc
calls.
Testing in game verified the zombie's arms raise and fall correctly
when using the API.
Renamed the OBFHELPER since the method is placed on EntityInsentient
(since we want to conflict on changes).
Note: The entity parameter stays 'this' since we want the block the
entity is targetting. This can change based on the block the player
has in their hand (see scaffholding). With a scaffhold in hand, the
scaffhold blocks in the world become solid 1x1x1 cubes, and without they
follow their model's shape.
- Add missing isCancelled check
We don't need to worry about going out of range of int
since the value is clamped to view distance, and view
distance is clamped to 33
Tux pointed out the patch still has O(n^2) time complexity since
the sublist class in arraylist does not override clear() from
AbstractList, which uses a forward moving iterator to clear
the list.
Resolved by using a peek and poll from ArrayDeque.
This patch also removes the useless WeakHashMap which holds
the list (it mapped world->list) and replaces it with a
field on World.
Resolves#1672
This API is intended to expose useful heightmaps found in the server to API. This exposes all of the live world heightmaps currently in the server.
If a heightmap becomes impossible to implement, api spec allows the implementation to throw UnsupportedOperationException (far better than returning some weird unexpected value).
Tested via:
https://gist.github.com/Spottedleaf/5d47f67c55a9fb870251ff344bfeb6b3
The cost of a call to sync() adds up quickly and especially for
HDDs. Playing around generating chunks for a while warranted a
3 min save time on a HDD. This is unacceptable default behaviour
and now the behaviour is hidden behind a flag for server owners
who are OK with taking a hit on saves (although SSDs will not have
this issue remotely as bad, since most of the time was spent seeking).
Previously we would write to header before writing our chunk data,
which opens a window for corruption (or we would overwrite entirely).
Now the saving process has been changed to follow this chain of events:
1. We always allocate a new space to write so we do not potentially
overwrite and corrupt the current data
2. Write the chunk data first (the order of the fields in
the chunk data isn't relevant though)
3. Flush to disk
4. Write to the region header last
5. Flush to disk
6. Then we free the previous space allocated
With this chain of events it is impossible for a chunk write to corrupt
a region file, unless the operating system has lied and we have NOT flushed
to disk.
However server administrators are still recommended to continue performing
regular backups.
Note that when Mojang finally decides to change their region format
to deal with oversized chunks this patch must be changed to deal with
whatever system they decide to impose.
We also make use of two flushes to disk per chunk save (to ensure
ordering and ensure data has gone to disk), so this will negatively
affect save performance.
Plugins that rely on the async login event to fire can miss the event
if a player tries to log in before the server has loaded.
The solution is to simply block the event threads from executing until
the server has loaded. This will not have an adverse affect on logins
since the event threads are cached and are only used for executing events
asynchronously.
* Add PlayerConnectionCloseEvent
This event is invoked when a player has disconnected. It is guaranteed that,
if the server is in online-mode, that the provided uuid and username have been
validated.
The event is invoked for players who have not yet logged into the world, whereas
PlayerQuitEvent is only invoked on players who have logged into the world.
The event is invoked for players who have already logged into the world,
although whether or not the player exists in the world at the time of
firing is undefined. (That is, whether the plugin can retrieve a Player object
using the event parameters is undefined). However, it is guaranteed that this
event is invoked AFTER PlayerQuitEvent, if the player has already logged into
the world.
This event is guaranteed to never fire unless AsyncPlayerPreLoginEvent has
been invoked beforehand, and this event may not be called in parallel with
AsyncPlayerPreLoginEvent for the same connection.
Cancelling the AsyncPlayerPreLoginEvent guarantees the corresponding
PlayerConnectionCloseEvent is never called.
The event may be invoked asynchronously or synchronously. As it stands,
it is never invoked asynchronously. However, plugins should check
Event#isAsynchronous to be future-proof.
On purpose, the deprecated PlayerPreLoginEvent event is left out of the
API spec for this event. Plugins should not be using that event, and
how PlayerPreLoginEvent interacts with PlayerConnectionCloseEvent
is undefined.
The key can be retrieved via methods Location#toBlockKey() and
Block#getBlockKey()
World provides lookup for blocks by long key via method World#getBlockAtKey(long)
The formatting for the key is as follows:
10 bit y|27 bit z|27 bit x
The y value is considered unsigned while z and x are considered two's complement
Y range: [0, 1023]
X, Z range: [-67 108 864, 67 108 863]
Checked encoding and decoding via https://gist.github.com/Spottedleaf/74f4e241012ca2fa67d8f1c7e8e34722
Spottedleaf