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.
Support for more advanced stuff like NBT copying wasn't added in this PR, as the NBT used by PM is currently an inconsistent mess and doesn't play nice with vanilla. In the interests of avoiding this mess propagating, it's been left for another time.
Adds PlayerEntityPickEvent a la PlayerBlockPickEvent
and Entity->getPickedItem().
This was static to permit ItemFactory to register spawn eggs for all known entity types in early PM4. However, nowadays we provide a callback to the spawn egg instead, and spawn eggs must be manually implemented, so this is no longer needed.
In addition, having this static forces everyone to make a new entity class for every unique type of entity, which isn't ideal.
this produced a 40% performance improvement in a simulation with 800 item entities.
If the items were all different, then this would still be a problem. However, many of the same unstackable items occupying the same space is a problem for SkyBlock farms, so this should improve performance for SkyBlock quite a bit.
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.
closes#5645
the code for this is borrowed from ItemEntity. I didn't feel like a base class was appropriate, and we can't (yet) declare constants in traits.
since item merging is a potential hotspot, we want to know if this code section is a performance problem.
Current timers only tell us whether overall ticking of a particular entity is slow, but that includes movement and therefore isn't particularly helpful.
This allows plugins to modify the entity via setters in EntitySpawnEvent without their changes getting overwritten by setter calls directly after the 'new YourEntity' statement.
As well as benefiting plugins, this also clears a path for a BC-breaking change in PM5 (to have the programmer use addEntity() to spawn entities, instead of the constructor doing it, which will improve on a number of data handling aspects).
fixes#4973
This targets next-minor because it has some side effects on plugins that depended on the old behaviour, such as VanillaHopper, so it's not suitable for a patch release.
This commit completely revamps the way that blocks are represented in memory at runtime.
Instead of being represented by legacy Mojang block IDs and metadata, which are dated, limited and unchangeable, we now use custom PM block IDs, which are generated from VanillaBlocks.
This means we have full control of how they are assigned, which opens the doors to finally addressing inconsistencies like glazed terracotta, stripped logs handling, etc.
To represent state, BlockDataReader and BlockDataWriter have been introduced, and are used by blocks with state information to pack said information into a binary form that can be stored on a chunk at runtime.
Conceptually it's pretty similar to legacy metadata, but the actual format shares no resemblance whatsoever to legacy metadata, and is fully controlled by PM.
This means that the 'state data' may change in serialization format at any time, so it should **NOT** be stored on disk or in a config.
In the future, this will be improved using more auto-generated code and attributes, instead of hand-baked decodeState() and encodeState(). For now, this opens the gateway to a significant expansion of features.
It's not ideal, but it's a big step forwards.
this commit provides a central place where all block data can go to be upgraded to the latest version (currently 1.19), irrespective of how old it is.
Previously I had issues during debugging, because it wasn't possible to just upgrade a block without deserializing it into a Block object, which isn't currently supported for many blocks.
This commit solves that problem by separating the upgrading from the deserialization.
