Documentation

CraftingTransaction extends InventoryTransaction
in package

This transaction type is specialized for crafting validation. It shares most of the same semantics of the base inventory transaction type, but the requirement for validity is slightly different.

It is expected that the actions in this transaction type will produce an unbalanced result, i.e. some inputs won't have corresponding outputs, and vice versa. The reason why is because the unmatched inputs are recipe inputs, and the unmatched outputs are recipe results.

Therefore, the validity requirement is that the imbalance of the transaction should match the expected inputs and outputs of a registered crafting recipe.

This transaction allows multiple repetitions of the same recipe to be crafted in a single batch. In the case of batch crafting, the number of unmatched inputs and outputs must be exactly divisible by the expected recipe ingredients and results, with no remainder. Any leftovers are expected to be emitted back to the crafting grid.

Table of Contents

$actions  : array<string|int, InventoryAction>
$hasExecuted  : bool
$inputs  : array<string|int, Item>
$inventories  : array<string|int, Inventory>
$outputs  : array<string|int, Item>
$recipe  : CraftingRecipe|null
$repetitions  : int|null
$source  : Player
$craftingManager  : CraftingManager
__construct()  : mixed
addAction()  : void
execute()  : void
Executes the group of actions, returning whether the transaction executed successfully or not.
getActions()  : array<string|int, InventoryAction>
Returns an **unordered** set of actions involved in this transaction.
getInventories()  : array<string|int, Inventory>
getSource()  : Player
hasExecuted()  : bool
validate()  : void
Verifies that the transaction can execute.
callExecuteEvent()  : bool
findResultItem()  : Item|null
matchItems()  : void
matchRecipeItems()  : int
squashDuplicateSlotChanges()  : void
Iterates over SlotChangeActions in this transaction and compacts any which refer to the same slot in the same inventory so they can be correctly handled.
shuffleActions()  : void
Shuffles actions in the transaction to prevent external things relying on any implicit ordering.

Properties

Methods

getActions()

Returns an **unordered** set of actions involved in this transaction.

public getActions() : array<string|int, InventoryAction>

WARNING: This system is explicitly designed NOT to care about ordering. Any order seen in this set has NO significance and should not be relied on.

Return values
array<string|int, InventoryAction>

validate()

Verifies that the transaction can execute.

public validate() : void
Return values
void

matchRecipeItems()

protected matchRecipeItems(array<string|int, Item$txItems, array<string|int, Item$recipeItems, bool $wildcards[, int $iterations = 0 ]) : int
Parameters
$txItems : array<string|int, Item>
$recipeItems : array<string|int, Item>
$wildcards : bool
$iterations : int = 0
Tags
throws
TransactionValidationException
Return values
int

squashDuplicateSlotChanges()

Iterates over SlotChangeActions in this transaction and compacts any which refer to the same slot in the same inventory so they can be correctly handled.

protected squashDuplicateSlotChanges() : void

Under normal circumstances, the same slot would never be changed more than once in a single transaction. However, due to the way things like the crafting grid are "implemented" in MCPE 1.2 (a.k.a. hacked-in), we may get multiple slot changes referring to the same slot in a single transaction. These multiples are not even guaranteed to be in the correct order (slot splitting in the crafting grid for example, causes the actions to be sent in the wrong order), so this method also tries to chain them into order.

Return values
void

shuffleActions()

Shuffles actions in the transaction to prevent external things relying on any implicit ordering.

private shuffleActions() : void
Return values
void

Search results