Island lock is combined with island ban in terms of the Listener. It is
LockAndBanListener. It is a flag because after thinking about it, it
made sense to be just like any other island setting. Also, island owners
can now (in theory) lock out others by rank.
Although the test class says everything works, the Settings GUI needs to
enable toggling so that players can lock the island.
Enjoy banning players!
It currently just displays a panel with all the flags in it. And throws exception when clicking on an item :P
Flag no longer have a PanelItem but Material instead as the icon.
Added a toPanelItem() method in Flag
Made the Panel(Builder) not using the Optional as fields anymore
Cleared up the description settings methods. Using these will add to the
description of the item.
Temporarily removed JavaDoc and Source jar creation from the POM to save
time when compiling. Will put it back when we need it.
Also, I worked out how to run the Bukkit server setup for tests. See the
setUp method in the tests. This works (at last).
This approach simulates an enum, but one that can be extended by others
to add custom flags. I added a handy values() method that uses
reflection to provide a list of all the flags in the class.
See TestBSkyBlock.java test classes for the tests of the default flag
registration and the custom flag registration.
Added serializer adapter for the Flags hashmap in Island.
Teams don't work. Need to work out why.
PVP doesn't work correctly. It allows members to hit visitors anytime,
but visitors can only hit others if PVP is off. This isn't how it is
supposed to work!
Made getIslandsAt() Optional to enable better code structures in the
listeners.
Created an abstract class to simplify flag protection listeners.
Added default setting for flags that will be able to be set by config.
This default is used for any space in the worlds not occupied by an
island.
a lot of unused/useless Settings has been removed
Settings class has been moved to the main package, because the config package would then only contain it
I need feedback about it
This is a more flexible and natural way to provide the display for the help, especially for the colors.
I had to remove the "/" from the usage though. If you think it should be there, re-add it but remove it from the locale then.
Used reflection to get the command map from the server instead of using
the NMS call.
Also, more importantly, this commit enables CompositeCommands to
auto-register their top-level command in the constructor. No need to
separately obtain the command manager object. Yes, easy API. :-)
Moved PremadeEvent to api/events
Made use of PremadeEvent for all existing events
Renamed TeamReason to Reason in TeamEvent
Made the addon events follow the used builder pattern
Renamed #loadAddons() to #enableAddons() in AddonsManager
Added #disableAddons() in AddonsManager
Commands now require a setup to define their permission, player/console
status, description and any parameters they have. This is also where any
subcommands are created if they exist.
Each command automatically has a help subcommand. This is used to
display help. This will also recursively go to any other sub commands
and get help from them.
Note that getUsage() now *only* shows the command and any sub commands.
It turns out that Bukkit requires this to start with a / because it
actually uses this in its own help system and the server will not start
if it is not in the right format. Therefore I split off parameters into
their own string. This also enables them to be translatable.
Everything should work at this point. It's just waiting on the locale
system to work to display the strings in the locale files.
Sub commands work, tab complete works. See the TestIslandCommand.java
test command for how to use the API and unit tests.
Still need to do the auto-help.
Commands work and tab complete works somewhat.
Help still needs to be done. Added in NotSetup And PluginConfig to just
make the plugin work. It's fine to remove them when there is a working
alternative.