If you use BlockFace in any way, to compensate the directionals being incorrect, you can still have backwards compatibility if you add in the handling in your plugin:
boolean legacyBlockFace = BlockFace.NORTH().getModX() == -1; (and then handle it accordingly)
If you didn't special case your directions to fix what's being fixed here... Hurray! Your plugin should now work.
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.
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.
This also allows, for instance, to parse complex numbers with imaginary part=0, if the according toString method omits zero components.
This also saves some unboxing (Foo.valueOf returns a wrapper, while Foo.parseFoo returns a primitive)
Any files placed in the new (optional) update folder are automatically copied into the plugins directory the next time a reload happens. This allows safe updating of the plugin .jar files.
