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.
Closes#1260
* master:
Add some debug for entity slices
Mark chunk dirty on entity changes
Reduce and improve dupe uuid resolve message
Add more entity debug info
Bring some 1.13 authors to master
Fixed more stuff
Remove unsed method
Extend player profile API to support skin changes
Extend player profile API to support skin changes
Cleaned up some implementation notes to use existing Vanilla method for some things.
merged into parent patch
7dd5837d Fixed more stuff (NickAcPT)
09f01353 Remove unsed method (NickAcPT)
e5ea4656 Extend player profile API to support skin changes (NickAcPT)
e67d55d0 Extend player profile API to support skin changes (NickAcPT)
* pull/1250/head:
Fixed more stuff
Remove unsed method
Extend player profile API to support skin changes
Extend player profile API to support skin changes
0069113b Put the decompile fixes into MC Dev Fixes patch (Andrew Steinborn)
608b5e52 Optimize RegistryID.c() (Andrew Steinborn)
* pull/1257/head:
Put the decompile fixes into MC Dev Fixes patch
Optimize RegistryID.c()
It's possible we won't hit this on the servers current state since nothing is async,
but we are working towards that.
I experienced a crash due to this code during my work.
Our changes for the spawn radius have the potential to throw an ArithmeticException
should the server be stopped before we've loaded worlds, we check if the server is
running earlier to check if we should even consider attempting to load chunks, which
would cause us to, 1) not load chunks anyways, as we're disabled; 2) throw an
ArithmeticException due to us expecting that we're going to be loading more than 0 chunks.
These chunks are unfinished, and waste cpu time saving these unfinished chunks.
the loadChunk method refuses to acknoledge they exists, and will restart
a new chunk generation process to begin with, so saving them serves no benefit.
* master:
Duplicate UUID Resolve Option
Add more information to Entity.toString
change LAST_EDIT to PAPER_LAST_EDIT for edit commands
Add more information to Entity.toString()
Add Debug Entities option to debug dupe uuid issues
Guard the Entity.SHARED_RANDOM from seed changes
Create a symlink on not-windows to current minecraft decompile dir
Due to a bug in 2e29af3df0
which was added all the way back in March of 2016, it was unknown (potentially not at the time)
that an entity might actually change the seed of the random object.
At some point, EntitySquid did start setting the seed. Due to this shared random, this caused
every entity to use a Random object with a predictable seed.
This has caused entities to potentially generate with the same UUID....
Over the years, servers have had entities disappear, but no sign of trouble
because CraftBukkit removed the log lines indicating that something was wrong.
We have fixed the root issue causing duplicate UUID's, however we now have chunk
files full of entities that have the same UUID as another entity!
When these chunks load, the 2nd entity will not be added to the world correctly.
If that chunk loads in a different order in the future, then it will reverse and the
missing one is now the one added to the world and not the other. This results in very
inconsistent entity behavior.
This change allows you to recover any duplicate entity by generating a new UUID for it.
This also lets you delete them instead if you don't want to risk having new entities added to
the world that you previously did not see.
But for those who are ok with leaving this inconsistent behavior, you may use WARN or NOTHING options.
It is recommended you regenerate the entities, as these were legit entities, and deserve your love.
Added code that refreshes the player's skin by sending packets with a special order, telling the client to respawn the player and re-apply the game profile
Added code that refreshes the player's skin by sending packets with a special order, telling the client to respawn the player and re-apply the game profile
The removal of `ServerConnection.this.h.add(networkmanager);` got
lost in the 1.13 update, causing network managers to be registered
twice.
Fixes "handleDisconnection() called twice" warning spam in console.
Some of the fields in the anonymous class are named the same as the
surrounding method's parameters, which caused the fields to be
initialized incorrectly.
That way it keeps returning the same block position, resulting
in an infinite loop during chunk generation.
* master:
Don't process despawn if entity is in a chunk scheduled for unload
Fix Squids corrupting the entire servers entity randomness....
Fix placement of chunk tracking - Fixes#1199
This won't happen anyways if the user has
"skip ticking for entities in chunks scheduled for unload" turned on,
but if they don't, protect from this instant killing the entity to
keep it vanilla in behavior
a player may teleport away, and trigger instant despawn
Spigot had code that returned early in chunk add/remove methods.
This was causing our code added to set current chunks and counts to
be skipped over if the entity was default not persistent but made persistent.
This was the source of many issues
Fixes#1208
When interacting with entities with an item, the client will assume
the interaction is successful, and update the held item on the
client. However, if the interaction is cancelled on the server side,
the client will still mistakenly remove/replace the item in hand.
Examples for this are milking cows with a bucket or dyeing sheep.
The bucket is replaced with milk and the dye removed from inventory.
Refresh the player inventory when PlayerInteractEntityEvent is
cancelled to avoid this problem.
The adjacent blocks of doors, double plants, pistons and beds need
to be updated manually from the server when cancelling a block break
from a player, as it otherwise causes the other parts to disappear
on the client.
This is already done for doors but only for the BlockBreakEvent,
not for PlayerInteractEvent. Move the code to a common method
and also handle the other blocks in similar ways.
The extra buffer used to decode the strings sent by the client
in the legacy ping protocol was never released. However, creating
an extra copy of the buffer just to decode it to a string isn't
actually necessary: We can just call toString() directly on the
original buffer.
Additionally, free the buffer in handlerRemoved() to handle cases
where the client never sends enough bytes to form a valid legacy
ping request.
Closes#1197
While this really undoes a lot of the desired performance gains avoiding chunk lookups,
we sadly have to accept this because we are seeing lots of bugs with entities.
