## **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>
TimedRegisteredListener uses a reference to the first event fired. This
causes a memory leak in the server for any references that event has. This
changes TimedRegisteredListener to only store a reference to the class of
the event.
This change is intentionally a breaking change, as it is an obscure part
of the API. A non-breaking change would require the leak to be maintained
or an immediate update for any plugins using the method, as it would be an
indirect break.
A unit test is also included to check behavior of shared superclass
functionality.
By: Score_Under <seejay.11@gmail.com>
Static methods are death to testability. However, irrelevant static
methods can be negotiated with until a later time in which they can be
removed. When instantiating a new Permission object, static calls are
made to the Bukkit class during a recalculatePermissibles logic path.
This recalculatePermissibles call should probably be moved
appropriately, but until the time such testing can be accomplished
itself, these tests work around that situation by simply verifying the
static Bukkit server references are satisfied since what is called as
a result is irrelevant currently.
This commit also updates a few other tests for PluginManagerTest to
work towards the standard of using the Hamcrest unit testing library.
By: EdGruberman <ed@rjump.com>
CommandMap contains a method that will auto-complete commands
appropriately. Before the first space, it searches for commands of which
the sender has permission. After the first space, it delegates to the
individual command.
Vanilla commands contain implementations to mimic vanilla
implementation. Exception would be give, that allows for name matching;
a feature we already allowed as part of the command is now supported for
auto-complete as well.
Plugin commands can get a tab completer set to delegate the completion
for. If no tab completer is set, it can check the executor to see if it
implements the tab completion interface. It will also attempt to chain
calls if null gets returned from these interfaces. Plugins also
implement the new TabCompleter interface, to add ease-of-use for plugin
developers, similar to the onCommand() method.
The default command implementation simply searches for player names.
To help facilitate command completion, a utility class was added with
two functions. One checks two strings, to see if the specified string
starts with (ignoring case) the second. The other method uses the first
to selectively copy elements from one collection to another.
By: Score_Under <seejay.11@gmail.com>
New events:
- InventoryOpenEvent
- InventoryClickEvent - detects any clicks on a slot or outside the window
- In the creative inventory view, only clicks on the quickbar are detected
- InventoryCloseEvent
- BrewEvent - when a potion finishes brewing
- CraftItemEvent (a subevent of InventoryClickEvent) - fired when taking the crafted item
- PrepareItemCraftEvent - fired just before updating the result slot
Changes to existing events:
- EnchantItemEvent extends InventoryEvent and also has a new whichButton() method
- PrepareItemEnchantEvent also extends InventoryEvent
- FurnaceBurnEvent and FurnaceSmeltEvent now extend BlockEvent (as does BrewEvent)
- PlayerInventoryEvent is deprecated (though it never did anything anyway)
New subclasses of Inventory:
- BrewerInventory
- CraftingInventory
- DoubleChestInventory
- EnchantingInventory
- FurnaceInventory
New methods in Inventory:
- getViewers()
- getTitle()
- getType()
- getHolder()
- iterator() - Yes, inventories are now iterable!
- The iterator is a ListIterator that does not support add or remove
New methods in Player:
- getOpenInventory()
- openInventory()
- openWorkbench()
- openEnchanting()
- closeInventory()
- setWindowProperty()
- getItemOnCursor()
- setItemOnCursor()
Other changes:
- createInventory() methods in Server to make inventories not linked to an object
- ContainerBlock is deprecated in favour of InventoryHolder
- New InventoryView class gives direct access to an inventory window!
- Removed the Slot class which did nothing and was used nowhere
Some small credit goes to Afforess (initial conception of openInventory() methods) and Drakia (initial conception of InventoryOpenEvent and InventoryCloseEvent).
By: Celtic Minstrel <celtic.minstrel.ca@some.place>
This metadata implementation has the following features:
- All metadata is lazy. Metadata values are not actually computed until another plugin requests them. Memory and CPU are conserved by not computing and storing unnecessary metadata values.
- All metadata is cached. Once a metadata value is computed its value is cached in the metadata store to prevent further unnecessary computation. An invalidation mechanism is provided to flush the cache and force recompilation of metadata values.
- All metadata is stored in basic data types. Convenience methods in the MetadataValue class allow for the conversion of metadata data types when possible. Restricting metadata to basic data types prevents the accidental linking of large object graphs into metadata. Metadata is persistent across the lifetime of the application and adding large object graphs would damage garbage collector performance.
- Metadata access is thread safe. Care has been taken to protect the internal data structures and access them in a thread safe manner.
- Metadata is exposed for all objects that descend from Entity, Block, and World. All Entity and World metadata is stored at the Server level and all Block metadata is stored at the World level.
- Metadata is NOT keyed on references to original objects - instead metadata is keyed off of unique fields within those objects. Doing this allows metadata to exist for blocks that are in chunks not currently in memory. Additionally, Player objects are keyed off of player name so that Player metadata remains consistent between logins.
- Metadata convenience methods have been added to all Entities, Players, Blocks, BlockStates, and World allowing direct access to an individual instance's metadata.
- Players and OfflinePlayers share a single metadata store, allowing player metadata to be manipulated regardless of the player's current online status.
By: rmichela <deltahat@gmail.com>
Adds Player.hidePlayer, Player.showPlayer, and Player.canSee for managing
what players are hidden from a player. When someone is hidden from a player
the player cannot see them in the user list or /list and they cannot /tell
them so they appear to be completely gone from the server.
By: Travis Watkins <amaranth@ubuntu.com>
