This will prevent projectiles from using the less accurate path for updating motion when interfaced with the API. However, hasImpulse is the more proper way of marking that the entity needs its velocity updated anyways.
This seems to be fairly unused logic in vanilla
I am sure this has been reported before but I cannot search for any bugs due to Mojang's new bug tracker.
Projectiles at high velocities very obviously go off track from their original course when sent to the client. This is due to the aggressive downsizing of velocity when sent over the client, and these entities typically have large velocity and still work just fine. We workaround this by sending the velocity for these entities exactly by using a teleport packet with relative flags and zero positional data. This prevents any possible position syncing, but sends an accurate velocity.
Then, we properly send the ClientboundProjectilePowerPacket on the first tick the entity is created, as vanilla only updates this when the delta is updated typically.
These can be removed as these values can now be updated on the client through synched values, additionally remove the extra bit that triggered redstone on rotation update which is not vanilla behavior.
This issue causes the item frame to move on the client erroneously, so we force the entity to resend its position the next tick.
This utilizes a moonrise patch which has a resync flag that can be triggered for the next tick, so we just utilize this. I stub out the method to ensure that it still compiles without the feature patch.
If you are creating a click callback using e.g. ChronoUnit.FOREVER.getDuration() this code will throw an ArithmeticException because toNanos overflows. The only way toNanos throws this exception is if the nanos overflow, so we can just safely cap it here as the max value for a long.
Note: This cannot happen on the Fabric/NeoForge versions since
async ticket level processing is not allowed, but can happen on
Paper. This change is made here so that Paper can
remain in sync.
Ticket level decreases may be handled asynchronously when the
off-thread invokes processTicketUpdates() when the main thread
is running ChunkHolderManager#tick(). This is because the ticket
update is queued during tick(), but not executed (invoking
processTicketUpdates) until after releasing the ticket lock.
This creates a small window for an off-thread to invoke
processTicketUpdates() and steal the update.
When the update is stolen, the full chunk status update (if any)
will be eventually queued to execute via the chunk task queue.
If the chunk queue is processed during the server tick at any
point other than the ChunkHolderManager tick, then any ticket
level decrease will violate an important invariant in the
Moonrise chunk system: ticket level decreases only occur during
ChunkHolderManager tick. This invariant exists to make interfacing
with the chunk system easier, especially working with off-thread
contexts.
This change is specifically made to work towards fixing
https://github.com/PaperMC/Folia/issues/363
Vanilla does not increment ticket timeouts if the chunk is
progressing in generation. They made this change in 1.21.6
so that the ender pearl ticket does not expire if the chunk
fails to generate before the timeout expires. Rather than
blindly adjusting the entire system behavior to fix this
small issue, we instead add non-expirable tickets to keep
ender pearls ticking.
This option should probably be removed as its a descendant of an option that allows "old tnt cannon" behavior before ~1.9 But this improves the fix so properly update the velocity/position rather than the questionable way it was doing it before.
This more properly implement spigot's fix for teleportation area effect clouds, now however supporting many other entity types specified in this bug report.
Currently, this is not an issue for (all) hanging blocks since they have a fix identical to this inside of setPos. Note however the client does not nicely support moving these entities anyways.
* Default LibraryLoader to Google's Maven Central mirror, add MavenLibraryResolver.MAVEN_CENTRAL_DEFAULT_MIRROR, and warn on use of Maven Central with MavenLibraryResolver
* Account for both Maven Central URLs
* Update Javadoc
It's important to convert the ItemStack present inside
the text component. The ItemStack nests TEXT_COMPONENT (written
book pages, custom name, ...) which would otherwise not be walked
since we have set a breakpoint at the version and moved the walker
to the next version step.
This fixes item names for hover events inside written book pages
failing to convert to NBT. This issue is also present on DFU.
Notably, this does not bump the world data version. This will be left for when the actual Vanilla base is updated, just in case. This early bump will likely be the exception for more ironed out update previews in the future.
* Setup PR publishing
also remove the JDK matrix, it's pointless with one value and other parts of the workflow depend on a single value...
* Use PaperMC action
* Change base PR maven url
* Update action
* Update action
* Update action
* Update action
* Update action
* Re-enable javadoc...?
* Delete PR comment workflow
* Rename publish tag
* comment broken jd link
* update bot name
If an exception is thrown during decompress then the read process
would be started again, which of course would eventually throw in
the decompress process.
