added folia-support as param

[MaksyKun]

The problem is solved by adding this into plugin.yml. folia-supported: true

However, I couldn't test the plugin ingame by now since Vault seems not to support Folia atm. With this change I only managed to accept BSP on Folia Servers to be loaded. Further improvements might be neccessary once Folia is really a thing.

[Travja]

True folia support will likely require a lot of code changes to make things thread safe. There will be a lot of trial and error along the way to make sure that everything works properly. I'm fine merging this in and calling it experimental folia support, but Vault being a dependency that doesn't work on folia definitely makes that hard.

[goflishMC]

@Travja @MaksyKun Here's a list of all folia supported plugins. There are 2 vault forks that support folia

https://github.com/BlockhostOfficial/folia-plugins

If we decide to use one of the forks we can fork one and then keep the jar available for download on our discord and our website to use with our plugins.

I know there's a long road ahead if we decide to add folia support to any of our plugins.

[MaksyKun]

I'll take a look in the next days to look how compatible it actually is. Thanks for the information!

[MaksyKun]

@goflishMC @Travja It seems like we are forced to use paper-api in order to give full compatibility since it comes with a native way to run the Bukkit.getGlobalRegionScheduler() method.

Is there any reason why we shall keep the spigot-api? After all, from my knowledge Paper shall also support Spigot servers.

[MaksyKun]

I just uploaded one attempt into this branch how I learned about Folia so far. It works with my testing server for folia properly.

[Travja]

@goflishMC @Travja It seems like we are forced to use paper-api in order to give full compatibility since it comes with a native way to run the Bukkit.getGlobalRegionScheduler() method.

Is there any reason why we shall keep the spigot-api? After all, from my knowledge Paper shall also support Spigot servers.

Paper is a fork of the Spigot API. If we move to the Paper API and build off that, we will lose compatibility with plain Spigot servers.

[MaksyKun]

Right, that could be problematic. Just from my interest, I tested to run the Folia supported BSP on a spigot server.

Surprisingly, it works. But we would have to high risk developing with paper-api without realizing that something might not be contained in spigot.

[MaksyKun]

@Travja How about making it this way (updated the branch again): I created an external utility jar with paper called "ProFoliaBridge" that contains the following code:

public final class ProFoliaBridge {

   public static void execute(Plugin plugin, Runnable runnable) {
       plugin.getServer().getGlobalRegionScheduler().execute(plugin, runnable);
   }

    public static void runDelayed(Plugin plugin, Runnable runnable, long delay) {
        plugin.getServer().getGlobalRegionScheduler().runDelayed(plugin, t -> runnable.run(), delay);
    }

    public static void runAtFixedRate(Plugin plugin, Runnable runnable, long delay, long period) {
        plugin.getServer().getGlobalRegionScheduler().runAtFixedRate(plugin, t -> runnable.run(), delay < 1 ? 1 : delay, period);
    }

    public static void cancelTasks(Plugin plugin, Plugin cancelReference) {
        plugin.getServer().getGlobalRegionScheduler().cancelTasks(cancelReference);
    }
}

This way, we can extend this api on anything new that occurs in Folia so that we just access it through the Plugin class as below:

public static void run(Runnable runnable) {
        if(isFolia) {
            ProFoliaBridge.execute(plugin, runnable);
        } else {
            Bukkit.getScheduler().runTask(plugin, runnable);
        }
    }

We wont even need to use paper-api in BossShopPro then.

[Travja]

I was thinking about this and decided to come give it a look again. I'm thinking that if we make the bridge utility a sub-module of Genesis, that would probably be the better option here. That way it can have its own separate dependencies without conflicting or adding an explicit dependency on paper while still being easily maintainable. Do you know much about multi-module projects in order to take that on @MaksyKun?

[MaksyKun]

I was thinking about this and decided to come give it a look again. I'm thinking that if we make the bridge utility a sub-module of Genesis, that would probably be the better option here. That way it can have its own separate dependencies without conflicting or adding an explicit dependency on paper while still being easily maintainable. Do you know much about multi-module projects in order to take that on @MaksyKun?

I have done some plugins with sub-modules years before so I think that should be no big deal. I can try to set it up 👍

[MaksyKun]

Well, I took a look and its a bit more scuffed than I remember. Are you more familiar with sub-modules?

[Travja]

Folia compat module now lives here: https://github.com/magemonkeystudio/folia-bridge

On my setup, I have all of our plugins in one giant multi-module setup with a parent genesis-parent project that houses all the genesis-related things. For now, (at least before we want to experiment with adding folia support for other plugins) the folia-bridge file lives there. Find more info here: https://github.com/magemonkeystudio/magemonkey-parent/tree/dev/genesis-parent