move force-close crafting grid hack to InGamePacketHandler

the crafting transaction implementation has no business caring about this
This commit is contained in:
Dylan K. Taylor 2020-04-29 16:54:23 +01:00
parent 4ce6525065
commit adadd5423d
2 changed files with 9 additions and 14 deletions

View File

@ -26,8 +26,6 @@ namespace pocketmine\inventory\transaction;
use pocketmine\crafting\CraftingRecipe;
use pocketmine\event\inventory\CraftItemEvent;
use pocketmine\item\Item;
use pocketmine\network\mcpe\protocol\ContainerClosePacket;
use pocketmine\network\mcpe\protocol\types\inventory\ContainerIds;
use function array_pop;
use function count;
use function intdiv;
@ -154,16 +152,4 @@ class CraftingTransaction extends InventoryTransaction{
$ev->call();
return !$ev->isCancelled();
}
protected function sendInventories() : void{
parent::sendInventories();
/*
* TODO: HACK!
* we can't resend the contents of the crafting window, so we force the client to close it instead.
* So people don't whine about messy desync issues when someone cancels CraftItemEvent, or when a crafting
* transaction goes wrong.
*/
$this->source->getNetworkSession()->sendDataPacket(ContainerClosePacket::create(ContainerIds::NONE));
}
}

View File

@ -257,6 +257,15 @@ class InGamePacketHandler extends PacketHandler{
$this->craftingTransaction->execute();
}catch(TransactionValidationException $e){
$this->session->getLogger()->debug("Failed to execute crafting transaction: " . $e->getMessage());
/*
* TODO: HACK!
* we can't resend the contents of the crafting window, so we force the client to close it instead.
* So people don't whine about messy desync issues when someone cancels CraftItemEvent, or when a crafting
* transaction goes wrong.
*/
$this->session->sendDataPacket(ContainerClosePacket::create(ContainerIds::NONE));
return false;
}finally{
$this->craftingTransaction = null;