This supersedes addChunkPacket() in most cases, and has a more clear name. It broadcasts the given packet to every player who has the target position within their chunk load radius.
This has the triple bonus effect of a) making a lot of code easier to read, b) reducing Server::getInstance() usages, and c) removing a whole bunch of Server dependencies.
The network and block namespaces are untouched by this commit due to potential for merge conflicts. These should be dealt with separately on master.
Async compression and broadcasts are now reliable and don't have race condition bugs.
This features improved performance and significantly reduced bandwidth wastage.
Reduce Level broadcast latency by ticking network after levels. This ensures that session buffers get flushed as soon as possible after level tick, if level broadcasts were done.
I considered renaming sendDataPacket() to dataPacket() to reduce the BC breaks, but the parameter set has changed, which might cause astonishing behaviour, so it's better to break it in a loud way. Also, this has a clearer name.
DataPacketSendEvent and DataPacketReceiveEvent will no longer capture BatchPackets
In most places strings are now used instead of DataPackets, to remove limitations on what data can be sent to a network interface
Removed CraftingManager's cyclic dependency on Server
There is a lot more work to do aside from this, but this commit is intended to clean up what is necessary to fix the handling of BatchPacket.
* Implemented InventoryEventProcessor, fixes#1986
Event processors can now be registered and unregistered at will. Entity inventory/armor change events are now handled by event processors instead of the inventories themselves, which allows enabling/disabling the calling of these events at will.
This now avoids stupid things happening when initializing inventory contents, since the callers for those events are now registered _after_ the contents are initialized.
As of 1.2.13 release, the client now skips the crafting grid step when it crafts with right-click on the recipe book. This means that we can't validate crafting based on the crafting grid contents anymore. The only way to do it now is to use the inputs and outputs calculated by the transaction balance.
Returning false all the time could mean any one of a range of things. Throwing exceptions is better in that it allows us to catch them and see what actually broke.
This allows deleting lots of code, and additionally provides a huge reduction in the compressed size of CraftingDataPacket. Since we don't care about these UUIDs (they are only used in CraftingEventPacket, which is broken and unused in PM) we fill them with zeros instead.
This commit brings in a much-needed rewrite of crafting transaction handling.
The following classes have been removed:
- CraftingTransferMaterialAction
- CraftingTakeResultAction
The following classes have significant changes:
- CraftingTransaction
- All API methods have been removed and are now handled in CraftItemEvent
- CraftItemEvent
- added the following:
- getInputs()
- getOutputs()
- getRepetitions() (tells how many times a recipe was crafted in this event)
- Recipe interface:
- Removed getResult() (individual recipes may handle this differently)
- CraftingRecipe interface
- removed the following:
- matchItems()
- getExtraResults()
- getAllResults()
- added the following
- getResults()
- getIngredientList() : Item[], which must return a 1D array of items that should be consumed (wildcards accepted).
- matchesCraftingGrid(CraftingGrid)
- ShapedRecipe
- constructor now accepts string[], Item[], Item[]
- ShapelessRecipe
- constructor now accepts Item[], Item[]
the requirement for a crafting table is determined by the number of ingredients can fit on the grid (shapeless) or the max height and width (shaped). It's impossible to craft a big recipe with a small crafting table simply because you're not able to put the required resources into the grid.
