The following API constants have been added:
- tile\BrewingStand::BREW_TIME_TICKS
The following public API methods have been added:
- utils\BrewingStandSlot->getSlotNumber() : int
- CraftingManager->getPotionTypeRecipes() : array<string, array<string, PotionTypeRecipe>>
- CraftingManager->getPotionContainerChangeRecipes() : array<int, array<string, PotionContainerChangeRecipe>>
- CraftingManager->registerPotionTypeRecipe(PotionTypeRecipe $recipe) : void
- CraftingManager->registerPotionContainerChangeRecipe(PotionContainerChangeRecipe $recipe) : void
The following classes have been added:
- BrewingRecipe
- PotionTypeRecipe
- PotionContainerChangeRecipe
- BrewItemEvent
- BrewingFuelUseEvent
- PotionFinishBrewingSound
this was caused by 083a1e1ff6.
This was discovered by a new PHPStan rule I'm working on, which disallows overwriting the values of parameter variables. During the refactor of this function to correct the error, another error appeared: Variable might not be defined.
This is yet another excellent example of why mutability is bad.
I've stuck to only doing this in the places where I'm sure we should never get false back. Other places I'm less sure of (and I found more bugs along the way).
we don't usually add VanillaItems entries for blocks since they already exist in VanillaBlocks, but air has a special use case specifically as an itemstack, so we make an exception for this case.
this fixes many cases of corruption during disk-full situations - file_put_contents() would write an empty file, destroying the original data.
fixes#3152
this fixes a wide range of blocks with invalid blockstates becoming update! blocks on the client.
The most common occurrence of this was air with nonzero metadata left behind by world editors which set blockIDs but not block metadata. This caused large ghost structures of update! blocks to appear from nowhere.
The performance impact of this is very minimal (20 microseconds per chunk load in timings, compared to average 660 microseconds to load tiles).
this is not as good as phpstan/phpstan-src#769 (e.g. array_key_first()/array_key_last() aren't covered by this, nor is array_rand()) but it does eliminate the most infuriating cases where this usually crops up.
if the worker selected previously had a generator registered, but has since been shutdown, the workerStartHook that cleans up generatorRegisteredWorkers won't yet have been called.
This results in the worker being started by the submission of PopulationTask, and the generator doesn't get preemptively registered.
if this happened, the index would stay set in activeChunkPopulationTasks, eventually causing the generation queue to jam up completely and non-forced generation to come to a standstill.
When profiling this, I noticed that we spend a stupidly large amount of time creating useless Position objects in the case of update=true, because Vector3->sides() calls Position->getSide(), which calls Position::fromObject(parent::getSide()). This is stupid because the update logic doesn't require Positions anywhere (as evidenced by this change needing no other alterations.
A rough profile shows that this improves setBlock() performance by about 25% in the update=true case, which is a pretty big margin.
As an added bonus, it gets rid of some unrealized cyclic dependencies in World->changedBlocks.
