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.
Used to determine ACTUAL Living NPC's. Spigot mistakenly inversed the conditions for LivingEntity, and
used LivingEntity for Insentient Entities, and named the actual EntityLiving class EntityInsentient.
This should of all been inversed on the implementation side. To make matters worse, Spigot never
exposed the differentiator that there are entities with AI that are not sentient/alive such as
Armor stands and Players are the only things that do not implement the REAL EntityLiving class (named Insentient internally)
This interface lets you identify NPC entities capable of sentience, and able to move about and react to the world.
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.
Instead of checking whether it was set previously, setting it to false,
then setting it back to true if it was true before, just use the
command-line argument in git to override the config for that command.
Using a variable makes it pretty painless to do.
GitHub still just dumps people into an editor. It's not quite the forms
we hoped for. Better to add newlines and hope it makes things even a
tiny bit clearer for people reporting issues.
Redirects are in place (or will be shortly). This is mostly
housekeeping.
Maven repo URLs already redirect however we can't deploy through them.
Jenkins URLs do not currently redirect but will within 24 hours.
Also adds a Discord link to the README, because apparently that's what
people want.
Documentation will be updated and announcements made once all redirects
are in place, until then, consider this advanced notice.
