it was due to the null value possibly returned by the LocalesManager#get(user, reference) method when nothing has been found, leading the variables replacement to cause a NPE.
User#getTranslation(reference, ...variables) now does the check and return the reference if the translation found equals null BEFORE trying to replace variables.
User#getTranslationOrNothing(reference, ...variables) works the same as before, it just checks if the returned translation is the same than the reference (therefore it returns the blank String), otherwise it sends the translation.
Renamed island multihome to start with "Custom" to make it clearer. This
class is as much an example as anything of how to override the default
help.
Renamed my author tag to be tastybento. :-)
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.
This is a first working version and can probably be improved.
Firstly, the plugin will save any BSkyBlock language files to the locale
folder from the BSkyBlock jar if and only if the locale folder does not
exist. It will then do the same for any addons as they are loaded. Addon
language files are prefixed with their addon name to keep them separate
and recongnizable.
Then the plugin loads the language files and merges common languages
together into a YAMLConfiguration that is held in memory. The combined
config is never saved out to the file system.
If a request is made for a particular reference to a language that does
not exist or if the reference does not exist, then the default language
is tried.
The original code did not allow addons to talk to each other in any way.
After trying loads of things with class path I studied the bukkit code
and saw that they override the findClass method in URLClassLoader. This
enables addons to find classes in other addons. All that was then needed
was a map in the AddonsManager of classes that this manager knows about
and a getter and setter method for them. After all that (3 hours) it
works.
I'm working on addons and realized it would be a better approach to be
able to register the listener for a panel explicitly for each panel.
This is optional. Also, added the ability to open the panel immediately
for a player.
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.
Removed the old localization system
Started implementation of the new one
For build reasons, removed protection listeners - they were requiring too much work to update them, and they need to be reworked due to the boilerplate code.
Implemented a recursive composite command that can be extended with
subcommands to infinity (and beyond!).
Composite command also tries to create help text and a list of help
commands. These are not current used and need more work.
This has not been tested yet completely.
Removed current config "API"
Removed a few unused or duplicate settings
Removed OfflineHistoryMessages
Removed visitor blocked commands (should be an addon)
This is a bit of a hack. The AbstractCommand class had to be pulled
apart to enable the ArgumentHandler to be imported by another plugin
without the other plugin having to extend AbstractCommand, which is
something it does not want to do because it is not defining a new
command, but just adding arguments.
There's too much passing of arguments in this implementation, but it
works. I'll see if I can simplify it.
This follows the proper builder approach, where all variables are
defined in a builder with a final build at the end to make the object.
The variables in the object are final so cannot be changed afterwards.
TeamEvent is used for all team events. Removed the extra classes that
are not needed anymore.
See this for a good summary on builder patterns:
http://minborgsjavapot.blogspot.com/2014/08/creating-objects-using-builder-pattern.html
Plan is to replace the island events with builder pattern too, so that
we only need one class for typical island events.
