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:
935f75de SPIGOT-4242: Treat cave / void air as transparent
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 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:
97d31e64 Add merging and matching of parsed BlockData
CraftBukkit Changes:
cfc67965 Add merging and matching of parsed BlockData
Paper team can do paper upcommit when manual upstream updates are needed
this will generate a changelog of everything that has changed between then and now.
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.
Spigot Changes:
1503de9c Update default spawn-range
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.
