PlayerRespawnAnchorUseEvent is also added with options SET_SPAWN and EXPLODE, which allows plugins to customise the outcome of using the anchor in PM, which currently doesn't support dimensions. The event is also cancellable.
- `AsyncGeneratorExecutor` class added that encapsulates the logic of generating chunks using async tasks as previously
- `GeneratorExecutor` interface added that can be implemented to provide chunks in other ways
- `SyncGeneratorExecutor` which invokes the generator directly on the main thread, useful for simple generators like `Flat` where async tasks are not needed
- Some redundant APIs were removed from `World` (these will probably come back as deprecated stubs for the remainder of 5.x, but I was having too much fun deleting code)
- Removed internal `World->registerGeneratorToWorker()` (no longer useful)
- `World` now invokes generator executor instead of posting AsyncTasks directly
- Some internal classes moved to `pocketmine\world\generator\executor` (PopulationTask excluded because plugins use it in lieu of being able to regenerate chunks
- Generators can opt into main-thread execution by setting the `$fast` parameter to `true` in `GeneratorManager::register()`
- `Item::clearCustomBlockData` previously, the instance was returned, but the return type has been changed
- `Item::setCanPlaceOn`, `Item::setCanDestroy` and `Item::setKeepOnDeath` now return `$this`
closes#6669
this happens because isTerminated returns true before the thread's shutdown handler runs,
so we join with the thread to make sure that shutdown handlers are done before returning.
... hopefully we don't get servers randomly deadlocking in shutdown handlers ???
* Bedrock 1.21.80 support
* Update bedrock-data
* Add required tags to models
* Fixed biome data loading
* Support newest world format
apparently I messed up the blockstate data version last time around... it hasn't changed since 1.21.60
* always CS has to complain...
* Sync with release versions
* Ready 5.28.0 release
* this might help...
---------
Co-authored-by: Dylan T. <dktapps@pmmp.io>
we already had this anyway, and it's already being reflected into.
Instead of DevTools checking for FolderPluginLoader instances, it
could just check if the file is a directory instead.
I want to do the same for items, but items are going to be a pain in the ass.
For items there are multiple possible entry points and all of them will need to be checked:
- dropped items
- inventory contents
- lecterns
- item frames
I don't see a good way to deal with all these. We can't check for registration in the constructor
because we need to fully construct the item in order to register it.
Blocks are also a potential issue in other areas, but setBlock() is definitely the biggest offender.
as written in the comments, it's not reasonable to propagate this limitation, since it
ultimately comes from a shortfall in the Mojang save format, not a limitation of PM's
capability. It's also not obvious how this would be propagated to the likes of setOnFire(),
as this would translate into a max time of 1638 seconds, a value no one is going to
remember.
There's a case to be made for truncating this on save rather than on initial set, but
this is at least better than having Fire Aspect level 1000 cause crashes and whatever
other gameplay logic that would have to work around this stupid limitation.
