The previous implementation would not cache the result for Materials without a furnace result.
So it would always check all recepies before return null.
We now just populate the whole cache instead of populating each Material<->Result combination one-by-one.
We are already iterating all the recepies anyways and EpicFurnaces should be the only plugin to use this method.
So there's actually not even a memory-consumtion trade-off right now because over time it would be
like this anyway – Just with worse performance
We should wait for the async pool to cleanly exit and finish all running tasks.
30 seconds is a lot but we don't want any data loss – If 30 seconds are exceeded there might just be something
fundamentally broken in the (plugin) implementation (or a huge bulk action?)
- Fix incompatible types when setting item name and lore.
- Fix replaceLegacy method replacing characters that should not be replaced.
- Add methods to convert shaded Adventure library to the non shaded form if the server is above 1.18.2
I am too scared on touching too much logic and breaking something as I didn't work on this class
or with that library much yet.
So I'm just refactoring it a bit not changing a lot of logic
This way whatever uses the DependencyLoader actually knows if something fails and can react to it
instead of just the JVM erroring because something is unexpectedly missing in the class path
The data directory location for plugins might be configured to another path, so instead we the
plugin's *DataFolder* as a basis for our Core's data directory
Implement own logger to prefix message with plugin name (if available) and CraftaroCore.
We prefix with both because the Core is shaded and this way it is clearly logged "which" Core is logging what.
This is also the reason why the Logger's name is now `CoreLogger.class.getCanonicalName()`
instead of CraftaroCore to uniquely identify each logger. (similar to what Bukkit's PluginLogger does).
My plans with this hook system are to make it easier to understand and maintain – Hopefully it is also more flexible
Hooks now have a dedicated activation-life-cycle – I think this allows it to contain all the logic to do what
it needs to do but also provide some helper methods like `#canBeActivated`.
The activation should be used by the hooks to reduce the memory and performancec impact when not used.
The de-activation also allows hooks to clean up themselves and not rely on the plugins used by the hook or
the plugin using the hook to clean up.
For example:
You can see that the `DecentHologramsHook` has few class variables and they are kept as
small as possible and reasonable when not activated.
In `#deactivate` I call `#removeAll` to remove all holograms that still exist and I call `ArrayList#trimToSize` to reduce it's size again.
This has a similar effect to setting the class varaible null or to a new List but with this I can make that field *final*.
The exact implementation details and capabilities vary on the third-party plugins being supported by hooks,
so it needs to be flexible and easy to understand, so we can easily add support for more plugins and especially
new plugin categories like Maps (dynmap, BlueMap, PlexMap, ...).
The interface is used/imported in two other Craftaro plugins (FabledSkyBlock and UltimateStacker).
I've worked on a new hook system which is easier to understand and maintain and hopefully also
allows for some more flexibility.
To introduce the new hooks without breaking changes (or as little as possible), this interface had to move.
The migration version -1 is already written into the new database before the old one has been converted.
This causes the migration to be run on the converted database because in addition to the migrated
version (e.g. 8) the -1 is already written to the table.
And now you just need to be kind of lucky to not retrieve that wrong version.
Just a hacky workaround (I know)
* Re-uses constructors to reduce duplicate code
* Makes sure the constructor with relocate-argument actually sets `this.relocate`
* Use `this.` for accessing class variables
Modifying the Set directory makes assumptions about the created Set.
About it's type/implementation (maybe it is immutable/read-only?) and about
it's usage/way-of-use that does not break the plugin by adding stuff a Set that might be used differently too etc.
