When the BlockState's block type was changed, #update may have removed
the TileEntity, causing #isApplicable to fail with a NPE.
By: blablubbabc <lukas@wirsindwir.de>
* CraftBlockState#getWorldHandle() would previously run into a NPE when being invoked for a non-placed BlockState. It now returns null in this case.
* CraftChest#getInventory() would previously encounter this NPE when being called for a non-placed BlockState. It will now automatically forward the call to #getBlockInventory() when it is being called for either a non-placed BlockState, or during world generation.
* CraftStructureBlock#applyTo was able to run into a NPE when being called for non-placed BlockStates (this is for example called by #getSnapshotNBT()).
* Replaced all no-world-generation preconditions with a general 'ensureNoWorldGeneration' method.
* Removed a few superfluous #isPlaced() calls. If getWorldHandle() reutrns a World, this already implies that the BlockState is placed.
By: blablubbabc <lukas@wirsindwir.de>
During block destruction, the type of the block may already have been set to AIR while the TileEntity has not yet been removed.
Also, TileEntity#getOwner() skips the whole BlockState construction now if the block is of type AIR.
This removes the previous workaround again of returning a dummy CraftBlockEntityState in this case.
By: blablubbabc <lukas@wirsindwir.de>
- SPIGOT-5732: Fix issue with spawning leash hitches and painting, by using the right block faces
- SPIGOT-6387: Allow hanging entities to be spawned mid air
- Use randomize parameter to determine if a random painting should be chosen or not
- Return BlockFace self by leash hitches entity
- Throw a standardised exception when trying to set a BlockFace to a hanging entity which the entity does not support, instead of using BlockFace south or throwing a null pointer
By: DerFrZocker <derrieple@gmail.com>
The current implementation of World#spawn or World#spawnEntity
respectively, always prepares/finalizes the spawn of every entity
spawned through the API. While this is great to simulate natural
spawning of entities in the world through the API, it fails at
reliably creating default entities for purposes other than vanilla
gameplay.
While the caller of the API could attempt to undo all of the
customization that is applied in the prepare/finalization step, they are
numerous (reaching from sheep colour to equipment) and in some cases,
such as the chicken jockey, even spawn in other entities.
Hence this commit introduces a new overload to the World#spawn and
World#spawnEntity methods that accepts the 'randomizeData' parameter
that, when set to false, skips the prior mentioned
preparation/finalization step.
By: Bjarne Koll <lynxplay101@gmail.com>
## **Current API**
The current world generation API is very old and limited when you want to make more complex world generation. Resulting in some hard to fix bugs such as that you cannot modify blocks outside the chunk in the BlockPopulator (which should and was per the docs possible), or strange behavior such as SPIGOT-5880.
## **New API**
With the new API, the generation is more separate in multiple methods and is more in line with Vanilla chunk generation. The new API is designed to as future proof as possible. If for example a new generation step is added it can easily also be added as a step in API by simply creating the method for it. On the other side if a generation step gets removed, the method can easily be called after another, which is the case with surface and bedrock. The new API and changes are also fully backwards compatible with old chunk generators.
### **Changes in the new api**
**Extra generation steps:**
Noise, surface, bedrock and caves are added as steps. With those generation steps three extra methods for Vanilla generation are also added. Those new methods provide the ChunkData instead of returning one. The reason for this is, that the ChunkData is now backed by a ChunkAccess. With this, each step has the information of the step before and the Vanilla information (if chosen by setting a 'should' method to true). The old method is deprecated.
**New class BiomeProvider**
The BiomeProvider acts as Biome source and wrapper for the NMS class WorldChunkManager. With this the underlying Vanilla ChunkGeneration knows which Biome to use for the structure and decoration generation. (Fixes: SPIGOT-5880). Although the List of Biomes which is required in BiomeProvider, is currently not much in use in Vanilla, I decided to add it to future proof the API when it may be required in later versions of Minecraft.
The BiomeProvider is also separated from the ChunkGenerator for plugins which only want to change the biome map, such as single Biome worlds or if some biomes should be more present than others.
**Deprecated isParallelCapable**
Mojang has and is pushing to a more multi threaded chunk generation. This should also be the case for custom chunk generators. This is why the new API only supports multi threaded generation. This does not affect the old API, which is still checking this.
**Base height method added**
This method was added to also bring the Minecraft generator and Bukkit generator more in line. With this it is possible to return the max height of a location (before decorations). This is useful to let most structures know were to place them. This fixes SPIGOT-5567. (This fixes not all structures placement, desert pyramids for example are still way up at y-level 64, This however is more a vanilla bug and should be fixed at Mojangs end).
**WorldInfo Class**
The World object was swapped for a WorldInfo object. This is because many methods of the World object won't work during world generation and would mostly likely result in a deadlock. It contains any information a plugin should need to identify the world.
**BlockPopulator Changes**
Instead of directly manipulating a chunk, changes are now made to a new class LimitedRegion, this class provides methods to populated the chunk and its surrounding area. The wrapping is done so that the population can be moved into the place where Minecraft generates decorations. Where there is no chunk to access yet. By moving it into this place the generation is now async and the surrounding area of the chunk can also be used.
For common methods between the World and LimitedRegion a RegionAccessor was added.
By: DerFrZocker <derrieple@gmail.com>
The previous layout and class hierarchy of the skeleton API defined
variances of the skeleton, such as the wither skeleton or the stray, as
child types of the normal skeleton variance, which is technically
incorrect, yet did not produce any specific issue as the normal skeleton
variance did not have any unique logic.
With the introduction of powdered snow in the 1.17 update, the normal
skeleton variance now has unique logic, specifically the conversion to
a stay when stuck inside powdered snow, which cannot be represented in
the current API layout due to the prior mentioned hierarchy.
This commit implements the hierarchy changes made in the bukkit
repository by representing the new hierarchy on the craftbukkit side
through the CraftAbstractSkeleton and the respective additions to the
skeleton implementation in regards to the stray conversion.
This commit does not break ABI yet breaks backwards compatibility due to
the mentioned hierarchy changes. Plugins that previously used the
Skelton interface to compute whether or not an entity is skeleton-like
through instanceOf checks will now only match the normal skeleton variance
instead of any skeleton-like entity.
By: Bjarne Koll <lynxplay101@gmail.com>
* Calls the LightningStrikeEvent for summoned lightning
* Uses the new COMMAND SpawnReason for other entities
By: Julian van den Berkmortel <julianvdberkmortel@outlook.com>
Apparently there are items and plugins out there that still use legacy
color codes within text components, and which thereby break this
heuristic.
Our remaining approach to differentiate between legacy (plain) and
modern (JSON-based) text is to check if a particular text can be parsed
as JSON-based text. This approach is not perfect either as there are
ambiguous cases that it cannot resolve correctly. However, these cases
are hopefully rare enough in practice that this approach remains
suitable.
By: blablubbabc <lukas@wirsindwir.de>
For example, this affects empty Strings, and Strings that consist only
of whitespace. In lenient mode this would also affect text that contains
comments, but that is not the case currently.
Minecraft's component parser (i.e. Gson) produces null for these texts
instead of throwing a parse exception. By interpreting this text as
legacy text we correctly create text components for them that contain
their contents.
By: blablubbabc <lukas@wirsindwir.de>
Issues resolved by this:
* SPIGOT-5063: Internal text representation of ItemStacks changes during ItemStack serialization. This issue was initially primarily concerned with the conversion between color text attributes to legacy color codes.
* SPIGOT-5304: Internal text representation of ItemStacks changes when opening the inventory (in creative mode). In particularly, this issue is also concerned with the conversion between plain text representations to non-plain ones.
* SPIGOT-5656: Internal text representation of ItemStacks changes during ItemStack serialization. This issue is particularly concerned with reordering of text attributes in the text's Json representation.
* SPIGOT-3206: Internal text representation of book pages changes during ItemStack serialization.
* SPIGOT-5350: Any non-plain text features are stripped from books during ItemStack serialization.
* SPIGOT-5980: Written books are marked as 'resolved' during ItemStack serialization and on various inventory interactions, even though they aren't, and thereby breaking any non-resolved page contents.
* SPIGOT-4672: Since item display names are serialized in their internal Json representation, any translatable components get properly persisted as well now.
---------
Minecraft uses text components to represent text. Internally Minecraft stores these components as Json formatted Strings and dynamically parses the text components from this Json representation whenever required.
In some cases Minecraft will create the text components and then convert them to Json itself for the internal storage. In other cases the Json representation is specified by users (eg. in Minecraft give commands, loot tables, mob equipment specified via Minecraft's summon commands, etc.).
There are many different ways in which the same text components can be represented in Json. When Minecraft compares objects which store this textual information, it takes the exact Json representation into account to determine whether the objects are considered equal. For example, ItemStacks will not match (and therefore not stack) if there is a difference in this internal Json representation for at least one if the item's text attributes (such as display name, lore, book pages, etc.). And when specifying nbt data in command selectors (eg. to only match entities/players which hold an item with specific name), the selector compares the raw Json representation as well.
As long as the Json representation is valid and can be parsed, Minecraft will not modify or normalize it.
However, under various circumstances Spigot converts this text information from the internal Json representation to text components (and in some cases even to plain text with legacy color codes) and then later tries to convert the text from these representations back to text components in the Json representation. Because this backwards conversion is in many cases not able to reproduce the original Json representation, the internal data of some affected Minecraft objects (ItemStacks, TileEntities, Entities, etc.) will in some cases get modified.
One especially notable situation in which this issue can come up is Bukkit's configuration serialization of ItemStacks: When a plugin serializes and later deserializes ItemStacks with display name, localized name, lore, or book pages of signed books, Spigot would convert these textual ItemStack attributes to plain text with legacy color codes and later try to convert those back to chat components in the Json representation. If the reconstructed Json representation does not match the original representation, the deserialized ItemStacks would no longer match nor stack with any original ItemStacks.
This case is particularly common if the original ItemStacks are created by users via some vanilla Minecraft mechanism (eg. Minecraft's give command, loot tables, mob equipment specified via Minecraft's summon command, etc.) and the used internal text representation for the created ItemStacks does not match the text representation produced by Spigot. This is also quite likely to be case, because the internal text representation produced by Spigot can sometimes be slightly verbose and, until recently, contained legacy color codes which cannot be used in Minecraft commands in-game.
However, this issue is not limited to items created by users, but affects items created by Minecraft itself as well.
Other cases in which Spigot itself (without any plugins involved) will convert between these text representations include dragging items around inside the inventory or opening the inventory while in creative mode. In these cases Spigot creates Bukkit representations of the affected items for use in Bukkit events and then, after the events have been handled, converts these Bukkit representations back to Minecraft items. See for example SPIGOT-5656 and SPIGOT-5304.
The idea of these changes is to avoid this back and forth conversion between the internal Json representation and the text component or plain text representations in various situations in which it is not actually required:
* CraftMetaItem stores the raw original Json representation for the display name, localized name, lore and pages of signed books now. As long as no plugin modifies these text attributes via the API, they can be reapplied in their original form to an ItemStack.
* The configuration serialization will serialize the original Json representation for these text attributes now so that it can also be restored during deserialization.
* However, in order to still be able to deserialize previously serialized items, and in order to allow users to specify text in the more simple plain representation in configuration files, we also still accept plain text during deserialization. Our approach is to check if the serialized text contains legacy color codes, in which case we convert it to chat components using our own converter and then to Json. Otherwise we try to parse it via Minecraft's Json parser. If the parsing fails due to the text not being valid Json, we interpret the text as plain text and convert it via our own converter as well.
* Various duplicated code has been removed from CraftMetaBookSigned and instead the base CraftMetaBook class allows sub classes to override the relevant aspects of how pages are parsed, serialized and deserialized.
* The BlockStates for command blocks and signs preemptively retrieved the custom name and sign line components, converted them to plain text and later converted them back to text components when applying the BlockState. We now only perform this conversion if a plugin has explicitly modified these texts.
Other changes:
* Minor: We also retrieve, convert and update a few other BlockState attributes directly from the underlying snapshot and only when requested by plugins now.
* SPIGOT-5980: Written books did not properly persist their 'resolved' attribute, resulting in unresolved book pages not getting resolved.
* There are methods to get and set the resolved value for books. However, these are not yet exposed in Bukkit.
* Minor fix: CraftMetaBook#isBookEmpty did not check some of the book attributes. This is probably a minor issue, but for consistency reasons there are checks for the missing attribute(s) now.
----
Covered cases
---
* By remembering the raw original String data, we can persist the exact text representation (eg. the ordering of elements within the Json text object (SPIGOT-5656), used style of escaping quotes (single quotes, escaped double quotes, etc.), use of plain texts (SPIGOT-5304), used boolean style, modern text component features such as translatable texts (SPIGOT-4672), etc.). All of these differences would otherwise cause the ItemStack to no longer be considered equal to its original.
* An empty String in the serialized config data results in no display name rather than an empty display name, like before. An item with explicitly empty display name (`{display: {Name: '""'}}`) is saved as `'""'` and can also be loaded from that representation again.
* Any plain texts, with or without color codes, which don't parse as Json (eg. `display-name: 'Bla'`) are still getting run through Spigot's text to components converter, like before.
* We can now also persist empty but explicitly present lore (`{display:{Lore:[]}}`). Previously this would get removed when the ItemMeta gets reapplied to the item. And ItemMeta#equals would return true for items with and without this empty lore data, even though Minecraft considers them to be different. For plugins using the API there should be no change: #hasLore still checks whether the lore is both present and not empty, and #getLore returns an empty list instead of null in this case (however, it previously already returned an empty list in this case). And setting the lore to an empty list via #setLore will still result in an item with no lore.
* Similarly, we can also persist explicitly specified but empty lists of book pages now.
----
Cases that are not covered (i.e. which may lead to changes in items), but were already not covered previously:
----
* NBT data for text that is not actually of type String.
* Empty or unexpected entries within the display compound.
* Variations in the NBT data representation in item features other than the above mentioned ones.
* Texts containing color codes. During deserialization these texts get interpreted as plain text and converted to a text component representation. This will break the serialization of any ItemStacks which actually use a text component representation with embedded color codes for some reason. Usually the likelihood for encountering such items in practice would probably be small. However, in the past (pre MC 1.16) Spigot would actually produce such items during ItemStack deserialization or when plugins created ItemStack via the Bukkit API. However, Spigot has changed the text representation it produces in MC 1.16, so any previously created and still existing items with this text representation are already problematic anyways now. See SPIGOT-5964. A fix for this linked issue (eg. the automatic conversion of these items) would probably resolve this deficit here as well.
* Spigot's String to text components converter produces quite verbose components since 1.16. See SPIGOT-5964 as well. However, this applies regardless of the changes of this PR.
* Book ItemStacks with more pages than 100 pages or oversized pages are truncated (like before) and may therefore change.
hange.
By: blablubbabc <lukas@wirsindwir.de>
This was the behaviour before the 1.16 update and made it so that any
message sent by a plugin was treated as a system message allowing the
player to disable chat messages while keeping access to commands.
After 1.16 disabling the chat also disabled any plugin output, this
restores the original behaviour.
By: Phoenix616 <max@themoep.de>
The methods would otherwise cache wrong enum types for specific enums.
This would result in a `ClassCastException` at the caller location,
which obviously is no fun. This broke API with `Switch#getFace` and
`FaceAttachable#getAttachedFace`.
The existing implementation was also stupid.
By: Mariell Hoversholm <proximyst@proximyst.com>
Previously spigots chunk pdc loading logic would read the entire chunk
nbt compound into the persistent data container of the chunk instead of
just reading the "BukkitValues".
Furthermore this commit also now correctly checks if the nbt compounds
of entities, tile entities and chunks actually have a value for the
"BukkitValues" key, as the previous 'getCompound' call would always
return an instance, the null check was useless. This commit now uses
'get', which returns null if no key exists and then runs an instanceof
check to both validate a non-null instance and an NBTTagCompound
instance.
By: Bjarne Koll <lynxplay101@gmail.com>
The underlying issue is a change by Mojang how UUID are stored in NBT.
This patch will have CraftBukkit convert the format during
deserialization.
By: SydMontague <sydmontague@web.de>
This is a fairly hacky way to do this - primarily because the Ansi library doesnt support RGB - however the VT100 codes here are the standard for RGB terminals.
By: Narimm <benjicharlton@gmail.com>
This also fixes that the nether/end portals would be created even if the
event was cancelled as well as that the EntityPortalEvent would be
called for player portal usage which is not according to its API
specification
By: Phoenix616 <max@themoep.de>
CraftFurnace is the base class for all concrete types of furnaces (this
mimics Minecraft's underlying type hierarchy). It is marked as abstract
now to avoid accidental instantiation.
Also, the various furnace sub types were missing type parameters.
By: blablubbabc <lukas@wirsindwir.de>
The flag for getChunkAt(int, int, ChunkStatus, boolean)
is actually a flag for whether to bring the underlying
PlayerChunk up to the required ticket level to load the
chunk. So, if the chunk is already at the required level,
but has not yet loaded, the call will actually either
start the load if it has not already been started and
block until completion.
This behaviour is not suitable for just
checking if the chunk is loaded.
By: Spottedleaf <Spottedleaf@users.noreply.github.com>
While 9862a0135d might of semi helped being able to save black text
lore, it actually took a fundamental problem with the legacy serialization
code and expanded it to break even more aspects of the server when dealing
with Component to Legacy conversion.
This is causing data loss in Spigot with cases such as setting an item name
to white gets stripped resulting in it being italic.
Additionally, things such as book pages have been returning black formatting
codes for the end of the line even when the user doesn't have colors in the book.
The root issue is that the "Default Color" system is fundamentally wrong.
Components do not and should not care about what element of the game they
are being used by, and that's what the default color system did.
It results in components that if obtained from 1 source such as a Book
where the default / rendered color is black, is then copied to another
source such as an Entity name, the black is carried forward and shown
in the Entity name, when in reality it should have been white.
This commit reverts 9862a0135d and fixes the underlying serialization
issues when it comes to Legacy to and From conversions.
There was quite a number of issues with this code overall, in how
it handles inserting color codes, new line parsing and such.
Books was using mojangs own "getLegacyString" which doesn't match behavior.
We also do not want to use Mojangs method as there is no guarantee they don't
remove that in future.
Plus, everything about books uses the CB implementation anyways, and it should
be consistent (this was mandatory to avoid serialization format changes on old vs new)
These changes as is results in Item Stacks already serialized will not
change contents when they go to component and back, so this won't impact
any existing data.
Newly created books though for example will change behavior in that they
will no longer insert black color codes in the serialized data and will
only represent intentional color changes by the creator of the book.
This will result in cleaner data on them, and books are the only thing
I'm aware of that has a behavioral shift due to the likelyhood of the
default color system kicking in on other parts of the string.
A unit test has been added to verify integrity of serialization to
ensure that any legacy string that is converted into Components will
always re-encode back in the same way when going back to Legacy.
By: Aikar <aikar@aikar.co>
After this commit, spigot now creates a deep copy of the
itemmeta's persistent data container when the itemmeta
instance is cloned.
This change fixes the bug that, after cloning itemmeta, the container
instance the cloned meta would point to was equal to the original one.
This resulted in two itemmeta instances sharing a single persistent
container.
By: Bjarne Koll <LynxPlay101@gmail.com>
