If AuthType == ONLINE, players will be treated as if they were Java
players
If AuthType == OFFLINE, name conflicts will be checked the same way it's
done with Floodgate
Updated config.yml to infrom about the changes.
Floodgate and Geyser specific checks can now be modified without
changing JoinManagement.
Added the ability to resume Java specific checks for Bedrock players.
This will be neccessary for Geyser `auth-type=online` players
Since the code only needs to interact with Geyser, if Floodgate is not
installed, and perform similar things with both, it's reasonable, to
merge their code.
This commit breaks premium checking with `auth-type=online` in Geyser
It is possible to use Geyser without Floodgate by configuring Geyser to
use auth-type= 'online' or 'offline'. In that scenario, floodgateService
will be either unavailable or empty.
The FloodgateService and GeyserService classes are not merged,
because Geyser can work without Floodgate.
Added Geyser as 'softdepends' in plugin.yml and bungee.yml
to make it load before FastLogin.
Also made Floodgate a soft dependency in bungee.yml.
If the pluign is running on Bukkit, and it's connected to Bungee
then core.getStorage() will be null.
If that's the case, players will be logged in via a plugin messages.
Technically speaking, one player can own both the Java and the Bedrock
account with the same name, so it's more appropriate to say account
instead of player.
Referencing 'FloodgatePlayer' in JoinManagement.java and it's subclasses
has cause ProtocolLib to fail to register an event when Floodgate was not
installed.
If I ever tried to either cast or use FloodgatePlayer as a return type
when Floodgate was not installed in the server, I got this error:
[19:37:46 ERROR]: [FastLogin] Plugin FastLogin v1.11-SNAPSHOT-744264d has failed to
register events for class
com.github.games647.fastlogin.bukkit.listener.protocolsupport.ProtocolSupportListener
because org/geysermc/floodgate/api/player/FloodgatePlayer does not exist.
ProtocolLib doen't have this problem.
The FloodgateApi is the same for Bukkit and Bungee, so the Floodgate
related code could be used in a future Bungee implementation too.
Currently, Bungee will report Floodgate disabled to core, so the
upstream Floodgate implementation will be used there.
If enough code will be moved to core, I might consider enabling these
features to BungeeCord too.
