This reverts commit 1d2b52732e3c475ddc2bab4e45726d22850e3d5c.
I hadn't considered that the likes of plugins and hoppers need to be
able to interact with double chest inventories as well as players.
If we were to move this logic to the Block side, we'd have to expose
APIs on the Chest block to get the correct inventory lazily. I'm not
sure I want to commit to having getInventory() on the block right now,
as we can't guarantee it's available (see problems around Campfire
inventory on the block).
Short term, it'll probably be better to just expose the logic in
block\Chest for deciding which side the inventories should be on.
having this created by the block was unreliable anyway. If items were set into the block's created inventory before setting the block in the world, the campfire contents would get overridden when the block was next run through readStateFromWorld() anyway.
There needs to be a deeper exploration of how to handle blocks with inventories without requiring plugins to interact with tiles. For now, this isn't the worst solution, but it's not the best either.
turns out relying on scheduled updates for this was a bad idea, since it causes a lot of unnecessary code to run every tick, as well as being problematic for campfire, which doesn't have any blockstates to compare against.
this is intended to replace PluginCommand and CommandExecutor, both of which are overengineered and unfit for purpose.
Allowing a closure allows much greater flexibility.
We can't use this within the core yet, as plugins will expect PluginBase->getCommand() to return PluginCommand (with its associated setExecutor() and similar APIs).
However, I think this is useful enough to add by itself.
The following callbacks can now be registered in timings, to allow threads to be notified of these events:
- Turning on/off (`TimingsHandler::getToggleCallbacks()->add(...)`)
- Reset (`TimingsHandler::getReloadCallbacks()->add(...)`)
- Collect (`TimingsHandler::getCollectCallbacks()->add(...)`)
Collect callbacks must return `list<Promise>`. The promises must be `resolve()`d with `list<string>` of printed timings records, as returned by `TimingsHandler::printCurrentThreadRecords()`. It's recommended to use 1 promise per thread.
A timings report will be produced once all promises have been resolved.
This system is used internally to collect timings for async tasks (closes#6166).
For timings viewer developers:
Timings format version has been bumped to 3 to accommodate this change. Timings groups should now include a `ThreadId` at the end of timings group names to ensure that their record IDs are segregated correctly, as they could otherwise conflict between threads. The main thread is not required to specify a thread ID. See pmmp/timings@13cefa6279 for implementation examples.
New PHPStan error is caused by phpstan/phpstan#10924
This binds internal sneaking to whether or not the player is currently pressing the shift key, which fixes#5792 and fixes#5903.
However, it does introduce visual issues with sneaking, as explained in #6548. This needs to be worked on separately. For now, it's better we trade 2 functional bugs for 1 visual bug.
