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.
When timings was disabled, internalStopTiming is not called, and timer depth is not decremented.
If timings is later reenabled, the next call to internalStartTiming will think the timer is already running, and won't generate any new records for the timer.
This has led to broken timings reports with missing Full Server Tick entries, amongst other things.
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
due to direct repeated usage of registerEvent() with closures, we've seen some libraries like muqsit/SimplePacketHandler generate very large timings reports, because a new timings handler gets created every time a plugin registers or unregisters a new packet handler callback.
This change fixes the problem by ensuring that any handlers derived from the same function, handling the same event class, will share the same timer.
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.
I don't plan to make wood-like blocks have a dynamic wood/leaves/sapling type, as it's entirely possible their type properties will continue to diverge in future versions.
TreeType includes a bunch of stuff that don't have regular saplings associated with them, such as mangrove and azalea trees.
Mangrove has a dedicated propagule block with different behaviour than the others, and azalea trees are grown from azalea blocks, which are solid and have different behaviour to saplings.
We may also want to account for crimson and warped 'trees' in TreeType too, although I'm not sure if those belong there or not.
TreeType really belongs in the generator package. Not all types of tree may have their own boat type (e.g. azalea).
We can't use WoodType for this either, because some types of wood also don't have associated boat types (crimson, warped).
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.
