In InventoryTransactionEvent I scheduled a Task via TaskScheduler::scheduleTask(). For what I can observed from the Server::tick() function, the events are triggered from the network (hence the line $this->network->processInterfaces(); in Server::tick()) , which is processed before it (the tick()) calls the tickSchedulers($this->tickCounter). Therefore it should process my task in the same tick. Yet it is delayed to the next tick (I var_dump($currentTick) in my task and var_dump(Server::getTick()) in the Event to verify.). Why is that delayed for 1 tick?
If you schedule the task on the event, it will be queued, but the previous queue was fired on that tick already. Therefore, your task will be updated only on the next tick. If you want to execute code on the same tick, why bother with tasks? I can't offer much help, I would need to know the expected behaviour and perhaps your previous attempts.
InventoryTransactionEvent has no setItem on the actions. I need the event to be complete to modify my target item. It should not have ticked. As far as I can see, the Event is ran before the task ticks. Here's what I'm refering to: Server.php PHP: private function tick() : void{ $tickTime = microtime(true); if(($tickTime - $this->nextTick) < -0.025){ //Allow half a tick of diff return; } Timings::$serverTickTimer->startTiming(); ++$this->tickCounter; Timings::$connectionTimer->startTiming(); $this->network->processInterfaces(); // <---- Where the event should fired from. It did, I traced. Timings::$connectionTimer->stopTiming(); Timings::$schedulerTimer->startTiming(); $this->pluginManager->tickSchedulers($this->tickCounter); // <---- Here's the task ticks. Timings::$schedulerTimer->stopTiming();
Additional note: The reason behind this is if it's delayed to the next tick, it's executed after a series of new events, which can change the Inventory slot that I'm planning to modify. By making sure it runs on the same tick, no more events can creep into my "workaround".
From the Discord chat (thanks to Javier Leon9966), it might be that there’s a task in the queue that’s scheduled for the future, and so the task queue will stop until the next tick, hence the effect. I might make another thread for the InventoryTransactionEvent’s modifying the target item, which I might use the Inventory Processor to do so.