calling CraftWorld.save() currently does not call WorldSaveEvent, and WorldSaveEvent could fire on worlds that have saving disabled.
New location will always fire during a world save and only during an actual save.
This change improves the quality of life for plugin developers using
iterator iteration with side-effects. In the specified Guava patch, the
internal iterator no longer relies on the AbstractList iterator which
iterates by index, and will instead wrap the provided iterator in a
transformer given the Function.
With the current API it is possible to create an inventory with a specific
type, but it is not possible to give such an inventory a title other than
the default.
The commit changes that by adding a method to optionally supply the title
for the given inventory type and holder, creating the functionality to
display any supported inventory type with a 32 character length String.
If the inventory title supplied is larger than 32 characters then an
IllegalArgumentException is thrown stating so.
Bans require a name and UUID but our API only allows for a single string
identifier for a ban entry. Until this is sorted out go back to the old
name based setup since we can always get a UUID given a name.
The getEntries methods on these return player names instead of UUIDs.
As we need the UUIDs for our API we add a getValues method to get at
the data we need. To further ensure we get the most data possible we
also add a way to get at the stored GameProfile to ensure we always
have both the UUID and the name from the list.
When getting an OfflinePlayer by name we lookup their UUID and then
use that to fetch the OfflinePlayer. If the player has not played on
this server before the resulting OfflinePlayer will return null for
getName(). As this is unintuitive we now create the OfflinePlayer directly
using the profile we looked up and make OfflinePlayer prefer that data.
Previously the alias system would pass all arguments from the alias
to its command(s) implicitly. The new system requires arguments to be
explicitly passed so server owners can have more control over where and
how they are passed. To ensure this isn't a breaking change during the
migration from bukkit.yml to commands.yml we now add the $1- argument
to the alias commands to match the previous behavior.
Previously no implementation existed to access various additional
information fields regarding bans. This implementation expands on the
information outlined in the sister Bukkit commit to provide access to
the Minecraft implementation of the ban system.
This implementation of the banning API contains 2 new classes which
provide access to the internal workings of the built-in banning
system within Minecraft.
The CraftBanEntry class simply supports the representation of an internal
Minecraft BanEntry object. The data that may be modified within this new
object must be manually saved to the list contained within the
CraftBanEntry using it's save() method.
The CraftBanList class supports the representation of an internal
Minecraft BanList object through proxy methods. These methods do
validation on the passed objects where needed to ensure safe input to the
backed Minecraft objects.
These changes additionally re-route the existing banning API to the newer,
more detailed, system. Functionality prior to this change still behaves
as documented by the contract defined by the methods changed.
Previously, if an error occurred during CraftServer initialization before the
logger was instantiated, it would cause an NPE and the server would never
finish loading properly. By instantiating the logger before attempting to
load anything else in CraftServer, we ensure that a logger will always be
available in the case of any errors.
Due to vanilla blanket comparing data values, and the unspecified
order of hashmap iterators, we need to run through custom recipes
first, and therefore separately, to ensure that they are actually
used. By not adding the custom results to the experience table, we do
not override the experience gains from vanilla smelting recipes.
