Skip to content

InventoryTransaction ​

class · pocketmine\inventory\transaction\InventoryTransaction · source

This is the basic type for an inventory transaction. This is used for moving items between inventories, dropping items and more. It allows transactions with multiple inputs and outputs.

Validation does not depend on ordering. This means that the actions can appear in any order and still be valid. The only validity requirement for this transaction type is that the balance of items must add up to zero. This means:

  • No new outputs without matching input amounts
  • No inputs without matching output amounts
  • No userdata changes (item state, NBT, etc)

A transaction is composed of "actions", which are pairs of inputs and outputs which target a specific itemstack in a specific location. There are multiple types of inventory actions which might be involved in a transaction.

Properties ​

$actions protected ​

php
protected array $actions

$hasExecuted protected ​

php
protected bool $hasExecuted

$inventories protected ​

php
protected array $inventories

$source ​

php
public \pocketmine\player\Player $source

Methods ​

__construct() ​

php
public function __construct(\pocketmine\player\Player $source, array $actions = [])

addAction() ​

php
public function addAction(\pocketmine\inventory\transaction\action\InventoryAction $action) : void

callExecuteEvent() protected ​

php
protected function callExecuteEvent() : bool

execute() ​

php
public function execute() : void

Executes the group of actions, returning whether the transaction executed successfully or not.

findResultItem() protected ​

php
protected function findResultItem(\pocketmine\item\Item $needOrigin, array $possibleActions) : ?\pocketmine\item\Item

getActions() ​

php
public function getActions() : array

Returns a set of actions involved in this transaction.

Note: This system is designed to care only about item balances. While you can usually assume that the actions are provided in the correct order, it will still successfully complete transactions whose actions are provided in the "wrong" order, as long as the transaction balances. For example, you may see that an action setting a slot to a particular item may appear before the action that removes that item from its original slot. While unintuitive, this is still valid.

getInventories() ​

php
public function getInventories() : array

getSource() ​

php
public function getSource() : \pocketmine\player\Player

hasExecuted() ​

php
public function hasExecuted() : bool

matchItems() protected ​

php
protected function matchItems(array &$needItems, array &$haveItems) : void

squashDuplicateSlotChanges() protected ​

php
protected function 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.

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.

validate() ​

php
public function validate() : void

Verifies that the transaction can execute.

VanillaMine is a fork of PocketMine-MP, maintained by Luxury Nodes. Not affiliated with the PMMP team or Mojang.