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.
Added Floodgate 2.0 as a requirement
Removed warning about linking accounts with "allowFloodgateNameConflict:
'false'" as it's no longer a problem with Global Linking API enabled
Knwon Bug: Profile.isSaved() is 'false' when logging in from Bedrock
after auto registering through Bedrock so FastLogin will try to register
for a second time, insted of logging in
Affected systems: BungeeCord after name change
Effects: Carry on items, permissions, etc. from the old user account without access to the new one
After a name change it could happen that the client still only
knows the old username and will send it to the server. Mojang will provide us with an up-to-date username that we should use instead.
The username is also sent to Mojang, so that they could verify the use. Therefore exploiting this behavior extensively for arbitrary usernames is not possible.
Related #344
Fixes#306
There seems to be some capability problems
that it doesn't correctly load ProtocolLib before
this plugin. Furthermore if we use
events for our hooks they print out a warning.
