Menus don't add slots for the offhand, so on sendAllDataToRemote calls the
offhand slot isn't sent. This is not correct because you *can* put stuff into the offhand
by pressing the offhand swap item
When the server is stopping, the default execution handler method will throw a
RejectedExecutionException in order to prevent further execution, this causes
us to lose the actual kick reason. To mitigate this, we'll use a seperate marked
class in order to gracefully ignore these.
Adds methods notify clients about item breaks and
to simulate damage done to an itemstack and all
the logic associated with damaging them
== AT ==
public net.minecraft.world.entity.LivingEntity entityEventForEquipmentBreak(Lnet/minecraft/world/entity/EquipmentSlot;)B
Fixes where the user has permission for selectors but not their
suggestions, which especially matters when we force suggestions to
the server for this type
Crashes caused by the missing AWT dependency come up in the support channels fairly often.
This patch detects the missing dependency and stops the server with a clear error message,
containing a link to instructions on how to install a non-headless JRE.
Fixes double firing of the event in PiglinAi
Fixes cancelling the event for piglins still triggering the
advancement trigger
Fires the event when a Raider tries to pick up a raid banner
to become raid leader.
While Velocity supports BungeeCord-style IP forwarding, it is not secure. Users
have a lot of problems setting up firewalls or setting up plugins like IPWhitelist.
Further, the BungeeCord IP forwarding protocol still retains essentially its original
form, when there is brand new support for custom login plugin messages in 1.13.
Velocity's modern IP forwarding uses an HMAC-SHA256 code to ensure authenticity
of messages, is packed into a binary format that is smaller than BungeeCord's
forwarding, and is integrated into the Minecraft login process by using the 1.13
login plugin message packet.
Beyond calling the BlockFadeEvent in more places, this patch also aims
to pass the proper replacement state to the event, specifically for
potentially waterlogged block states fading.
Co-authored-by: Lulu13022002 <41980282+Lulu13022002@users.noreply.github.com>
Minecraft's prediction system does not handle block entities, so if we are manually sending block entities during
block breaking we need to set it after the prediction is finished. This fixes block entities not showing when cancelling the BlockBreakEvent.
Paper makes the entity random thread-safe
and constructing an entity off the main thread
should be supported. Some entities (for whatever
reason) use the level's random in some places.
These can be called while an entity is being added to the world,
and if the entity is being added from a chunk load context the
sync load will block indefinitely (because the chunk load context
is for completing the chunk to FULL).
This does raise questions about the current system for these
dynamic registrations, as it looks like there is _zero_ logic
to account for the case where the chunk is _not_ currently loaded
and then later loaded.
The previous solution caused a bunch of bandaid fixes inorder to resolve edge cases where minecraft/the api might spawn items that are air.
Just simply prevent them from being added to the world instead.
Craftbukkit attempts to translate worlds that use the
same generation as the Overworld, The Nether, or The End
to use those dimensions when checking the `changed_dimension`
criteria trigger, or whether to trigger the `NETHER_TRAVEL`
distance trigger. This adds a config option to ignore that
and use the exact dimension key of the worlds involved.
- add auto expire setting
- add setter for block data
- add accessors for block state
== AT ==
public net.minecraft.world.entity.item.FallingBlockEntity blockState
Co-authored-by: Lukas Planz <lukas.planz@web.de>
Fixes https://github.com/PaperMC/Paper/issues/7276 and https://github.com/PaperMC/Paper/issues/8118
by using a config option that, when set to false, does not add markers to the entity
tick list at all and ignores them in Spigot's activation range checks. The entity tick
list is only used in the tick and tickPassenger methods, so we can safely not add the
markers to it. When the config option is set to true, markers are ticked as normal.
By checking if the world passed into StructureTemplate's placeInWorld
is not a WorldGenRegion, we can bypass the deadlock entirely.
See https://bugs.mojang.com/browse/MC-246262
Also standardizes how to handle EntityChangeBlockEvent before a removeBlock or destroyBlock
call. Always use 'state.getFluidState().createLegacyBlock()' to get the new state instead of
just using the 'air' state.
Also fixes the new block data for EntityBreakDoorEvent (a sub-event from
EntityChangeBlockEvent)
Co-authored-by: Lulu13022002 <41980282+Lulu13022002@users.noreply.github.com>
Co-authored-by: Jake Potrebic <jake.m.potrebic@gmail.com>
lets debug mode throw a trace in order to potentially see where
such calls are cascading from easier, but, generally, if you see one setBlock
call, you're gonna see more, and this just potentially causes a flood of logs
which can cause issues for slower terminals, etc.
We can limit the flood by just allowing one for a single gen region,
we'll also only gen a trace for the first one, I see no real pressing need
to generate more, given that that would *massively* negate this patch otherwise
The worldgen thread will attempt to get structure references
via the world's getChunkAt method, which is fine if the gen is
not cancelled - but if the chunk was unloaded, the call will block
indefinitely. Instead of using the world state, we use the already
supplied ServerLevelAccessor which will always have the chunk available.
== AT ==
public net.minecraft.world.entity.projectile.FishingHook timeUntilLured
public net.minecraft.world.entity.projectile.FishingHook fishAngle
public net.minecraft.world.entity.projectile.ShulkerBullet targetDeltaX
public net.minecraft.world.entity.projectile.ShulkerBullet targetDeltaY
public net.minecraft.world.entity.projectile.ShulkerBullet targetDeltaZ
public net.minecraft.world.entity.projectile.ShulkerBullet currentMoveDirection
public net.minecraft.world.entity.projectile.ShulkerBullet flightSteps
public net.minecraft.world.entity.projectile.AbstractArrow soundEvent
public net.minecraft.world.entity.projectile.AbstractArrow setPickupItemStack(Lnet/minecraft/world/item/ItemStack;)V
public net.minecraft.world.entity.projectile.ThrownTrident dealtDamage
public net.minecraft.world.entity.projectile.Arrow NO_EFFECT_COLOR
public net.minecraft.world.entity.projectile.Projectile hasBeenShot
public net.minecraft.world.entity.projectile.Projectile leftOwner
public net.minecraft.world.entity.projectile.Projectile ownerUUID
public net.minecraft.world.entity.projectile.Projectile preOnHit(Lnet/minecraft/world/phys/HitResult;)V
public net.minecraft.world.entity.projectile.Projectile canHitEntity(Lnet/minecraft/world/entity/Entity;)Z
public net.minecraft.world.entity.projectile.FireworkRocketEntity getDefaultItem()Lnet/minecraft/world/item/ItemStack;
public net.minecraft.world.item.CrossbowItem FIREWORK_POWER
Co-authored-by: Nassim Jahnke <nassim@njahnke.dev>
Co-authored-by: SoSeDiK <mrsosedik@gmail.com>
Co-authored-by: MelnCat <melncatuwu@gmail.com>
Co-authored-by: Lulu13022002 <41980282+Lulu13022002@users.noreply.github.com>
Piercing arrows search for multiple entities inside a while
loop that is checking the projectile entity's removed state.
If the hit event is cancelled on the first entity, the event will
be called over and over again inside that while loop until the event
is not cancelled. The solution here, is to make use of an
already-existing field on AbstractArrow for tracking entities hit by
piercing arrows to avoid duplicate damage being applied.
== AT ==
protected net.minecraft.world.entity.projectile.Projectile hitCancelled
Dead players would be stuck in the world loading screen and other players may
miss messages and similar sent in the join event if chunk loading is slow.
Paper already circumvents falling through the world before chunks are loaded,
so we do not need that. The client only needs the chunk it is currently in to
be loaded to close the loading screen, so we just send an empty one.
By default, only LevelStem's that specifically match the ResourceKey for
OVERWORLD will have the 5 (currently) impls of CustomSpawner (for
phantoms, wandering traders, etc.). This adds an option to instead of
just looking at the LevelStem key, look at the DimensionType key which
is one level below that. Defaults to off to keep vanilla behavior.
The 4 missing structure set seed configs are strongholds, mineshafts,
buried treasure, and ancient cities.
Strongholds use a ring placement scheme which isn't random so they
utilize the world seed by default, this adds a config to override it
for just generating the ring positions.
Mineshafts and Buried Treasure structure sets are special cases
where the "salt" that can be defined for them via datapacks has 0
effect because the difference between the spacing and separation is 1
which is used as the upper bound in the random with salt. So the random
always returns the same int (0) so the salt has no effect. This adds
seeds/salts to the frequency reducer which has a similar effect.
Co-authored-by: William Blake Galbreath <blake.galbreath@gmail.com>
There is an explicit check in the handling code for empty pistons that
prevents sticky pistons from firing the event. However when we look back
at the history we see that this check was originally added so that ONLY
sticky pistons would fire the retract event. I'm not sure why.
1092acbddf
Over the course of several updates, the meaning of that field appears to
have changed from "is NOT sticky" to "is sticky". So now its having the
opposite effect. Only normal pistons fire the retraction event. And like
all things in CB, it's just been carried around since.
If we are to believe the history, the correct fix for this issue is to
flip it so it only fires for sticky pistons, but that puts us in a
bind. It's already firing for non-sticky pistons, changing it now would
likely result in breakage. Furthermore, there is little documentation as
to WHY that was ever intended to be the case.
Instead we opt to remove the check entirely so that the event fires for
all piston types.
Co-authored-by: Zach Brown <1254957+zachbr@users.noreply.github.com>
Co-authored-by: Madeline Miller <mnmiller1@me.com>
