since we don't have a hard date for this, and I've already made one wrong educated guess, I'd rather not have another massive outage.
A security update will have to be made to remove the old key as soon as the new one is rolled. This is not ideal, but it's the least disruptive option.
this is now able to determine which properties were renamed and/or changed when multiple renames occurred in a single version.
This also fixes unrelated properties being considered mapped to each other when there was only one property in the old and new state (e.g. mapped_type and deprecated for hay_bale in 1.10). Now, these are properly considered as unrelated.
this is now able to determine which properties were renamed and/or changed when multiple renames occurred in a single version.
This also fixes unrelated properties being considered mapped to each other when there was only one property in the old and new state (e.g. mapped_type and deprecated for hay_bale in 1.10). Now, these are properly considered as unrelated.
this is no longer a concern with pmmpthread + PHP 8.1 and up. The behaviour that caused statics to be inherited was caused by bugs in PHP 8.0 and below, which have now been fixed.
Since task execution depends on tasks executing sequentially on a particular worker in some cases (e.g. PopulationTask must be preceded by GeneratorRegisterTask), it doesn't make sense to continue task execution if an error occurs.
Moreover, a task crashing may render the whole server unstable, as it leaves the server in an undefined state. This is the same kind of problem we fixed with scheduled tasks in PM3.
In versions past, pthreads was unreliable enough that random tasks would crash without an obvious reason, forcing us to accommodate this. I still don't know the origin or frequency of said issues, but I think it's time to rip the band-aid off and solve these problems for real.
since BlockTransaction was designed to be World-agnostic, it can't position() any blocks, since Position requires a World.
This workaround is the best we can do for now; however, it would probably be wise to deprecate getTransaction() in favour of a dedicated getBlocks() method which takes care of this, as BlockPlaceEvent is currently quite obnoxious to use.
