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.
Allows you to increase how far to check for a safe place to respawn
a player near their bed, allowing a better chance to respawn the
player at their bed should it of became obstructed.
Defaults to vanilla 1.
In many places where we simply want the current chunk the entity
is in, instead of doing a hashmap lookup for it, we now have access
to the object directly on the Entity/TileEntity object we can directly grab.
Use that local value instead to reduce lookups in many hot places.
This enables us a fast reference to the entities current chunk instead
of having to look it up by hashmap lookups.
We also store counts by type to further enable other performance optimizations in later patches.
This is the best way to get an entity when the world and its UUID are known.
It is faster than Server.getEntity(UUID) because it does not have to iterate all worlds
This fixes a CRITICAL missing part of the Bukkit API due to mistakes on upstream
refusing to implement the Sentient NPC baseclass of all NPC's.
Until now, the Bukkit API has not provided a way for accessing and setting
a non creature entities target.
Although Flying, Slime, Ambient, and Water mobs all supported targets internally,
you were unable to get/set it.
Now with the SentientNPC API and these API's moved down, every sentient NPC has
access to target data.
This only impacted people who used our useSnapshots new API in a plugin,
which obviously was no one as the data result was completely broken.
Merged the NPE check patch into mine since it has to handle it too.
This event is called when an entity receives knockback by another entity. The knockback can be modified in the event. If the event is cancelled the entity is not knocked back.
Also renames patch file to better express what it's doing.
It is presumed that those using this config option intend for
suffocation checks to be disabled in all instances. In doing so, they
inherently assume the advantages and issues associated with removing
said safety check.
If the community expresses a desire for more specific options regarding
the handling of this safety feature, we can investigate providing them.
Fixes GH-1149
Called when a player is firing a bow and the server is choosing an arrow to use.
Plugins can skip selection of certain arrows and control which is used.
Rewrites the Vanilla luck application formula so that luck can be
applied to items that do not have any quality defined.
See: https://luckformula.emc.gs for data and details
-----------
The rough summary is:
My goal was that in a pool, when luck was applied, the pool
rebalances so the percentages for bigger items is
lowered and smaller items is boosted.
Do this by boosting and then reducing the weight value,
so that larger numbers are penalized more than smaller numbers.
resulting in a larger reduction of entries for more common
items than the reduction on small weights,
giving smaller weights more of a chance
-----------
This work kind of obsoletes quality, but quality would be useful
for 2 items with same weight that you want luck to impact
in varying directions.
Fishing still falls into that as the weights are closer, so luck
will invalidate junk more.
This change will result in some major changes to fishing formulas.
-----------
I would love to see this change in Vanilla, so Mojang please pull :)
hashCodes are not allowed to change, however bukkit used a value
that does change, the entityId.
When an entity is teleported dimensions, the entity reference is
replaced with a new one with a new entity ID.
For hashCode, we can simply use the UUID's hashCode to keep
the hashCode from changing.
equals() is ok to use getEntityId() because equals() should only
be true if both the left and right are the same reference.
Since entity ids can not duplicate during runtime, this
check is essentially the same as this.getHandle() == other.getHandle()
However, replaced it too to make it clearer of intent.
To teleport an entity between dimensions, the server makes a copy
and puts the copy in the new location, and marks the old one dead.
If this method got called for the same world in the same tick,
the entity would not have been removed from the UUID map, and the
world readd would fail.
This can be triggered even with a plugin if the entity is teleported
twice in the same tick, from world A to B, then back from B to A.
The re-add to A will fail to add the entity to the world. It will
actually be there, but it will not be visible on the client until
the server is restarted to re-try the add to world process again.
This bug was unlikely to be seen by many due to the double teleport
requirement, but plugins (such as my own) use this method to
trigger a "reload" of the entity on the client.
