The modified patch prevents entity loading off the main thread when
entities are initially loaded.
However, the initial loading of an entity is not the only time the
Entity#readAdditionalSaveData method is called. Commands like /data also
invoke the method (through Entity#load) to update an entities data
without completely re-creating it.
This however breaks with the current patch, as the patch moves parts of
the entity lookup for persistent anger deserialisation into the first
tick of an entity (which obviously is only called once and hence not
re-run when an already ticking entity is modified as laid out above).
This change actively runs the now split logic for deserialisation again
if the entity has already ticked its first tick. This way, initial
deserialisation is still split into one off thread and the first tick
parts, but following main thread deserialisations can happen completely
inside Entity#readAdditionalSaveData is called.
Due to the weakly consistent of ConcurrentLinkedQueue iterator, at some points, packet will be resent twice times or more, causing some weird behaviors (e.g. kicked for illegal movement since the same ClientboundPlayerPositionPacket was sent two times). This changes for the patch add a flag for marking if the packet was consumed to prevent such issue and ensure consistently of the packet queue.
The max search distance used to get the closest Poi data on X/Z axis is cubed
instead of squared (one time in the parameter and another time in the function)
for almost all search.
Generally this has been hidden by another check that already does a pre
distance check between the poi pos and the source pos for individual
component but the issue still happens for diagonal distance search.
Discovered by Samsuik
This moves the setHealth call to below the recordDamage call to prevent
recordDamage from clearing the CombatTracker, since recordDamage will
clear the CombatTracker if the entity is dead. This fixes death messages
such as the "doomed to fall" messages.
Bjarne Koll