Upstream has added the equivalent of our SentientNPC API, with exception to the EnderDragon.
We've added Mob to the EnderDragon, and our SentientNPC API should behave the same.
Vex#getOwner has been deprecated and a replacement Vex#getSummoner has been added using Mob.
However, since 1.13 is not production ready, SentientNPC API is subject for removal in 1.13.1 since
1.13 API is not compatible with 1.12.
Please move to the Mob interface ASAP.
This update has not been tested by PaperMC and as with ANY update, please do your own testing
Bukkit Changes:
c5ab54d8 Expand GameRule API
ab9a606c Improve entity hierarchy by adding Mob interface.
CraftBukkit Changes:
29e75648 Expand GameRule API
50e6858b Improve entity hierarchy by adding Mob interface.
0e1d79b4 Correct error in previous patch
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:
53d3ac0a SPIGOT-4238: Sometimes buckets are leaky client side when empty event is cancelled
Upstream has released updates that appear to apply compile correctly.
This update has not been tested by PaperMC and as with ANY update, please do your own testing.
Bukkit Changes:
d2834556 SPIGOT-4219: Event for PigZombies angering.
CraftBukkit Changes:
a9c796f1 SPIGOT-4184: Fix furnaces not matching Vanilla smelt or animations
195f071e SPIGOT-4219: Event for PigZombies angering.
5e3082c7 SPIGOT-4230: Improve legacy block types
See: https://github.com/PaperMC/Paper/issues/1304
Changes the UUID sent to client to be based on either
the texture payload, or random.
This allows the client to render multiple skull textures from the same user,
for when different skins were used when skull was made.
Closes#1304
I misinterpreted some code as a risk of entity loss, but now
after deeper study, I see how that code was used more and why
it was adding entities to chunks that they shouldn't have been
in during a world transfer process.
also ensure we never process already valid entities. this shouldnt be possible as of recent
commits as we made the entity slice array safer, but doesn't hurt for this logic to be safe too
incase that patch got dropped in a future version by accident/necessarily
1) Chunk Registration might kill an entity, don't add it to the world if it did!
2) By default, entities are added to the world per slice iteration.
This opens risk of the slices being manipulated during chunk add if an
EntityAddToWorldEvent spawns an entity into this chunk.
Fix this by differing entity add to world for all entities at the same time
3) If a duplicate entity is attempted to add to the world of an entity, and
the original entity is dead, overwrite it as the logic does for unloaod queued entities.
Should hopefully finish up issues with #1223
* master:
MC-135506: Experience should save as Integers
Fix EXP orb merging causing values to go negative - Closes#1169
Add "Safe Regen" Duplicate UUID resolver and make default
After witnessing behavior of the regeneration logs, its clear that Vanilla
has had bugs with saving duplicate entities for a while....
Some entities are saved in multiple chunks, and now we are bringing those duplicates
out that use to never surface.
This mode will analyze if the entity appears to be a duplicate (near the other dupe uuid)
and delete the entity instead.
This should reduce regenerations to entities that are nowhere near each other, and
therefore more likely to be subject to real UUID collisions due to our
previous bug, and therefor should survive the chunk load.
Fixes GH-1295
Non-standard sized portals exacerbate a flaw in the vanilla
portal teleportation adjustment logic.
As a result, an entity can end up slightly inside of the surrounding
portal blocks. In vanilla, this issue is minor and you are adjusted out
as if it never happened. In CraftBukkit and derivatives, the
anti-suffocation behavior activates and players end up teleported on top
of their portals.
This improves the offset so as to keep the issue from ever occurring in
the first place.
Special thanks to CarpetMod who appears to have had this fixed for some
time, and has licensed their code such that we can use it as needed.
Due to the changes in 1.13, clients will send a tab completion request
for all bukkit commands in order to factor in the lack of support for
brigadier and provide backwards support in the API.
Craftbukkit, however; has moved the chat spam limiter to also interact
with the tab completion request, which while good for avoiding abuse,
causes 1.13 clients to easilly be kicked from a server in bukkit due
to this. Removing the spam limit could cause issues for servers, however,
there is no way for servers to manipulate this without blindly cancelling
kick events, which only causes additional complications. This also causes
issues in that the tab spam limit and chat share the same field but different
limits, meaning that a player having typed a long command may be kicked from
the server.
Splitting the field up and making it configurable allows for server owners
to take the burden of this into their own hand without having to rely on
plugins doing unsafe things.
This patch has been applied to 1.12.2 in order to allow people using
plugins which allow clients of newer versions to connect, this is
not a common practice, however is being done as a level of nicety
given the current status of 1.13
We have a result boolean for this already, and this
method was meant to be "Try from cache, if that fails, look it up"
So NPE'ing there just wasn't correct.
In 1.13 the method previously used now returns translatable keys.
`block.minecraft.cobblestone` instead of `Cobblestone`
We just need to make sure we're translating those keys.
ideally this should of never mattered, as it will only
be hit if you teleport out of an unloaded chunk...
But apparently some people are triggering this.
See #1223
No entities were lost in this bug, just we were triggering the add entities
before they were loaded due to an inconsistent order of putting chunk into chunkmap.
Any entity that appeared to be gone on the last build will now be back.
This should not ever be used in production!!
This setting is intended for testing so you can try out converting your world
without actually modifying the world files.
This will add some additional overhead to your world, but you're
just testing anyways so that's not a big deal :)
Will store in a folder named after the current version.
PlayerData and Data folders are copied on server start, so there
may be some delay there, but region files are only copied on demand.
This is highly experiemental so backup your world before relying on this to not modify it
1.13 undesirably changed behavior here that chunk load event fired
before the entities were added to the world.
This means any plugin that spawns entities in chunk load event
causes the entities to be registered to the chunk, and then
added to the world twice.
Moves Entity Add to World to be done anytime a chunk is
registered to the Chunk Map, and ignore other calls.
Fixes#1288
* master:
Always process chunk registration after moving
Always move Entity to its new Chunk even if unloaded
If Entity is added to chunk, look up the chunk if current isnt set
Ignore Dead Entities in entityList iteration
Always process chunk removal in removeEntity
Spigot 1.13 checks if any field (which are manually copied from the ItemStack's "tag" NBT tag) on the ItemMeta class of an ItemStack is set.
We could just check if the "tag" NBT tag is empty, albeit that would break some plugins. The only general tag added on 1.13 is "Damage", and we can just check if the "tag" NBT tag contains any other tag that's not "Damage" (https://minecraft.gamepedia.com/Player.dat_format#Item_structure) making the `hasItemStack` method behave as before.
Check the `ItemMetaTest#testTaggedButNotMeta` method to see how this method behaves. (I also added some extra tests).
`hasItemMeta()` will return true if `ItemStack.getDamage() != 0` or it has the `Damage` tag or any other tag is set.
Closes#1222
This will help guarantee that entities are always in the
chunk that they are currently located at.
Should hopefully also fix Citizens triggering the "Saved to wrong chunk" message
Vanilla logic here would allow us to remvoe an entity from
its current chunk, and if it was going to move into an unloaded
chunk, that entity would not be added to the unloaded chunk.
This is bad because this will result in the entity being lost!
In almost all cases, the chunk will be loaded, but in the event
it wasn't, instead of losing the entity, load the chunk to add
the entity to it.
Hopefully will (f)ix #1280...
I'm suspicious that Citizens isn't calling things in the same order and causes the current
chunk to not be set, which then bugs removals. Though this doesn't make any sense to me,
so this likely won't fix it...
But if the isAddedToChunk is true, we really should be returning a chunk anyways if its loaded.
A spigot change delays removal of entities from the entity list.
This causes a change in behavior from Vanilla where getEntities type
methods will return dead entities that they shouldn't otherwise be doing.
This will ensure that dead entities are skipped from iteration since
they shouldn't of been in the list in the first place.
Spigot might skip chunk registration changes in removeEntity
which can keep them in the chunk when they shouldnt be if done
during entity ticking.
Should fix some cases where "Entity is still in another chunk section"
Related to #1223
Vanilla logic checks unload queue and overwrites if its in it.
we're triggering this if a chunk unloads, and reloads immediately in same tick.
Added check for unload queue to not treat as duplicate
Also fixed the config setting not even loading
Should fix#1280
Citizens hijacks entity map, and im guessing under the right conditions
the result might actually be null during entity creation
Pre the cache patch, the id is looked up on save, so it was fine.
Now, if its null and the save ID is requested, we will try to look
it up again and cache it if found.
While upstream has now made this event cancellable, their changes
result in the vechicle being removed before the event is called,
thus leading cancellation to not behave as expected.
See https://github.com/PaperMC/Paper/issues/1223
Should fix Vanilla bugs
Minecraft is saving invalid entities to the chunk files.
Avoid saving bad data, and also make improvements to handle
loading these chunks. Any invalid entity will be instant killed,
so lets avoid adding it to the world...
This lets us be safer about the dupe UUID resolver too, as now
we can ignore instant killed entities and avoid risk of duplicating
an invalid entity.
This should reduce log occurrences of dupe uuid messages.
Also reduce the logging spam overall.
Setting the flag updates the spawner's delay which stops the spawner from trying to find a new spawn position each tick efter the event was cancelled/aborted which makes it usable for mob stackers/mergers and other plugins that don't actually want any mob to spawn in the spawner cycle but keep the overall behaviour close to vanilla.
This might slightly effect existing plugins that use this event but I doubt anyone really relied on this behaviour, the only possible use case that I can think of is cancelling the event until you find a suitable position in your plugin... and this should be handled by the plugin itself by cancelling and spawning at the position manually.
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.
