For blocks, we now use 'block-item state' and 'block-only state', which should be much clearer for people implementing custom stuff.
'block-item state', as the name suggests, sticks to the item when the block is acquired as an item.
'block-only state' applies only to the block and is discarded when the block is acquired as an item.
'type data' for items was also renamed, since 'type' is too ambiguous to be anything but super confusing.
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 using json before, which is horribly inefficient.
This saved about 200 KB of memory on initial startup (which isn't much, but for more complex recipes, it might have been significantly worse.
this reduces bandwidth efficiency because it can't be compressed with everything else this way. If we want to cache stuff sent during the login sequence, it's better to stuff a bunch of stuff into a batch (e.g. crafting, creative, actor ids, biome defs) and pre-compress that as one big package instead.
I'd like to have this directly provided to Furnace, but I don't know how to short of making into a singleton. Since I want to have per-furnace recipe managers (e.g. for stuff like blast furnace vs regular furnace etc), a singleton isn't really an option.
the compressor used by RakLibInterface when opening a session is still
hardcoded, but that's because we have no way to select the correct
compressor at that point in the login sequence, since we aren't
propagating the protocol information up from RakLib right now.
