while I could implement server-side ability to disable entity movement, I don't think that's particularly useful. However, the intended function of this (disabling client sided AI) is useful, so it makes more sense to rename it to match its functionality, rather than changing its functionality to match the name.
closes#3130
this was previously part of the abandoned package pocketmine/spl. It had to be separated in the PM3 days, because RakLib depended on it.
Since RakLib 0.13, RakLib stopped being dependent on or aware of pthreads, so it no longer depends on any thread-related packages.
It's also possible to absorb pocketmine/snooze and pocketmine/classloader back into the core with this in mind.
Due to the high cost of Item::serializeCompoundTag(), it's very costly to rebuild this every time we need it. This is sent during the pre-spawn step, where we need to minimize costs as much as possible.
we rely on phpstan for validation of this internally, and plugins shouldn't be calling these methods anyway.
this significantly reduces the overhead of CompressBatchPromise.
For blocks, we now use 'block-item state' and 'block-only state', which should be much clearer for people implementing custom stuff.
'block-item state', as the name suggests, sticks to the item when the block is acquired as an item.
'block-only state' applies only to the block and is discarded when the block is acquired as an item.
'type data' for items was also renamed, since 'type' is too ambiguous to be anything but super confusing.
moral of the story: do not trust that mojang things do what they say they do - the spectator ability layer always applies, regardless of whether the player is actually in spectator mode or not ...
there's a bunch of places we can't reach with this right now:
- particles
- sounds
- tile NBT
- entity metadata
- crafting data cache
- chunk encoding
- world block update encoding
this is a work in progress, but ultimately we want to get rid of these singletons entirely.
fixes#5722
I'm not very clear why this works. PM doesn't use real spectator mode yet (we're still using the faux spectator mode PM has had for years, because I haven't yet assessed how real spectator mode will affect stuff like block interactions), so this ability layer shouldn't have any effect.
thank you @Alemiz112
this saves a considerable amount of memory.
we don't actually need this state array in PM4 anyway, since we don't support the client-side chunk cache yet.
when the time comes to support it, it'll be much more practical to cache binary states and copy bytes anyway, instead of doing it the current way, which is both slow and memory-intensive.
Measured footprint change: 9 MB -> 400 KB.
the aim of the game here is to avoid allocating lots of tiny arrays, which have a terrible overhead:useful-data ratio.
This reduces the footprint of the mapping from 1.6 MB to 600 KB.
this allows saving about 4 MB of memory, because there are many blocks which have identical states, although they have different IDs.
this relies on a potentially risky assumption that the tags in knownStates won't be modified. If they are modified, the changes will influence all blockstates which share the tag.
However, I don't expect this to happen, and the 4 MB memory saving is substantial enough to be worth the risk.
this was achieved by storing binary representations of the blockstates, rather than the original BlockStateData.
Due to the insane object:data ratio of Tag objects (40:1 for ByteTag for example), modestly sized NBT can explode in memory footprint. This has been previously seen with the absurd 25 MB footprint on file load.
Previously, I attempted to mitigate this by deduplicating tag objects, but this was mitigating a symptom rather than addressing the cause.
We don't actually need to keep the NBT around in memory, since we don't actually use it for anything other than matching blockstates. In this case, we can allow the code to be possibly a little slower, since the lookup is anyway slow and the result will be cached.
In fact, using encoded ordered states as hash keys significantly improves the speed of lookups for stuff like walls, which have many thousands of states.
We keep around generateStateData(), since it's still possible we may need the BlockStateData associated, and it can be easily reconstructed from the binary-encoded representation in BlockStateDictionaryEntry.
since this is contextless (there's no way to know the version of the client requesting the MOTD), we can safely assume that this is not going to vary between protocol versions.
closes#5724
this uses a (potentially bogus) assumption that the lowest mapped meta value associated with an ID is valid. I don't want to break this during a patch release, and this works for now.
In the future it would probably make more sense to bypass ItemTranslator entirely, and rely solely on the blockstate returned by RuntimeBlockMapping to fetch the correct ID. This is similar to how we serialize items for saving on disk in PM5.
this doesn't support editing the rear side of a sign, since the 1.12 format doesn't allow us to represent the rear text, and it would necessitate API breaks to support anyway.
However, we can quite trivially support APIs for the sign GUI, which plugins can use to enable editing signs. PocketMine-MP doesn't currently permit this, since it's currently an experimental feature in 1.20, but plugins can simply use Player->openSignEditor() to mimic it.
This is, however, a byproduct of the fact that APIs needed to be added in order to facilitate the use of OpenSignPacket in 1.19.80.
this uses the same dodgy hack used by CraftingTransaction, which assumes that getResultsFor() does not care about the crafting inputs.
While this is currently OK, since none of the currently-implemented recipes care about inputs anyway, it will become a problem when we implement shulker box recipes, so this needs to be addressed.
However, it can't be addressed without BC breaks, so this will have to be dealt with in PM5.
closes#5715
