It works, but it is more like a DIY patch thing. It has a few problems with the current implementation :
1. It doesn't suit our "code style" : it uses an Handler instead of a Manager, eg.
2. It is a bit laggy (I've got the feeling that it could be improved)
3. It doesn't hook to other Placeholder APIs for now
And a few other things.
I think this is more like a Proof of Concept : it will have to be improved in the next weeks.
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 the adapter annotation to MySQL and fixed issues with empty
hashmaps causing null errors.
Added a flag serializer adapter for the protection flags so that flags
are saved and loaded correctly.
Renamed the Adapter notation class to be clearer about what it is doing.
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!
This is required for automated testing (can't use static getInstance). I
really need automated testing of the protection classes, so even though
this adds a parameter to the classes, it's important to have it right
now.
Generally these are very easy to understand. They use an abstract class
for common code.
I have not tested these in-game. I would like to see if I can create
some test classes but it may not be possible because of the static
BSkyBlock calls.
There's a lot more that needs to be checked in these listeners! I moved
some common methods into the abstract class because they will be used
again and again by other listeners.
Added an anvil listener.
Added the flags. They were from ASkyBlock so may have name changes.
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.
While writing the admin tp command, I realized that subcommand aliases
were not working. Also, it was not possible to tell what alias had been
used for a command. I added that capability. i.e., if the alias is used,
then the label of that command is set to the alias.
Saves a backup of the config after validation in the database so it can
be checked.
To Be Done: Validation of the config when it is loaded against the
database version.
These methods are used specifically for loading and saving settings
classes (those use the ISettings interface). The saving saves a copy of
any settings class in the database for future reference. The loading
loads a copy from the database if it exists and checks if any fields are
different from the config file. If they are different and some action
needs to be taken, the action is taken. This is still be to be coded.
In other news, the saving of arrays is unsupported and currently should
be avoided. Use Lists or Sets instead.
Reworked locales so they use a nice and pretty folder structure.
Added the ability to define adapters to serialize certain data
structures. Added the PotionType list adapter.
Saving and loading of configs basically works. Known issues:
1. The config.yml is saved and loaded to/from the database folder
2. More error handling is required for the config loading. e.g., a list
value with only one value in it is not read as a list. This could get
tricky.
3. Comments are not saved (yet)
Currently it handles the @ConfigEntry path and specificTo fields.
Experimental: There is a class called Setting2.java. It has an
annotation that defines its filename as config.yml. Currently, it is
using the database folder as its location, but it could be the plugin's
datafolder in the future. By placing the config.yml file in the database
folder, it will be read. See the code in BSkyBlock onEnable() for how
that is done.
The main differences between Settings2.java and Settings.java are that
all fields are NOT static and therefore it is an object and uses getters
and setters. This is because it is a JavaBean. In other code, settings
should be queried using this config object.
Added the concept of an adapter class that would convert the YAML input
to the setting type and value.
I included an example adapter class for Enum.
I fixed a number of the settings to match the config/yml or the other
way around.
After compiling and running, do /bsb reload to see the result.
This is a WIP and obviously not finished.
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
