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>
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.
- 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>
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>
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
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>
HashMapPalette uses an instance of CrudeIncrementalIntIdentityHashBiMap
internally. A Palette has a preset maximum size = 1 << bits.
CrudeIncrementalIntIdentityHashBiMap has an initial size but is
automatically resized. The CrudeIncrementalIntIdentityHashBiMap is created
with the maximum size in the constructor of HashMapPalette, with the aim
that it doesn't need to be resized anymore. However, there are two things
that I think Mojang hasn't considered here:
1) The CrudeIncrementalIntIdentityHashBiMap is resized, when its initial
size is reached and not the next time, when a further object is added.
2) HashMapPalette adds objects (unnecessarily) before checking if the
initial size of CrudeIncrementalIntIdentityHashBiMap is reached.
This means to actually avoid resize operations in
CrudeIncrementalIntIdentityHashBiMap, one has to add 2 to the initial size
or add 1 and check the size before adding objects. This commit implements
the second approach. Note that this isn't only an optimization but also
makes async reads of Palettes fail-safe. An async read while the
CrudeIncrementalIntIdentityHashBiMap is resized is fatal and can even lead
to corrupted data. This is also something that Anti-Xray is currently
relying on.