* 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>
these are actually two separate concerns: one for dodgy PHPStan type suppression on implicit keys, and the other for arrays being casted to strings by PHP.
it never occurred to me that this was misleading until I read some Devin documentation,
noticed that Devin misunderstood was the class was for, and then realized actually
Devin understood correctly, and it was the name of the class that was wrong. Funny
how that happens...
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.
instead of skipping queues and forcing sync compression as previously seen.
this maintains proper packet order and allows immediate-flush to be used to reduce latency in-game.
Small servers won't notice any difference, but for larger ones it may make a difference, since the buffer time effectively depends on the amount of load RakLib is under.
closes#3325
if not, this will cause random crashes in core code, which assumes that state IDs found on runtime chunk memory are valid and registered.
this problem exists in other places too, and probably requires a rethink of how we're dealing with this, but for now, this will do as a band-aid.
this has such a big impact on performance that I think this is warranted. Should also make it more obvious what the GC is doing without needing to enable ALL debug info.
these are noisy and cause conflicts. Since they also usually cause new errors to be reported, we often can't directly update it anyway. Better to test & update this locally.
