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.
this is no longer used by the core, and as far as I can tell no plugin uses it either.
it was used in the past for chat broadcast channels, but not anymore.
this doesn't work for PRs from forks, since fork PRs don't have access to repo secrets.
we'll need some more advanced mechanism to avoid redundant reviews, but that's a job for another time.
this allows getting rid of several container window classes.
we should probably look into adding more info to the BlockInventoryWindow to make the type easier to identify, though.
now that holder is tracked by an ephemeral window, we can put whatever we like in there.
it already needs to locate the correct pair anyway to know the left/right for DoubleChestInventoryWindow, so we might as well use this logic for initializing the DoubleChestInventory itself too. The old logic in tile/Chest didn't work correctly.
this unblocks a variety of changes, such as positionless tiles, enhanced APIs on Blocks for inventories, and also eliminates a bunch of cyclic references within the core code.
linked to #5033
