Previously: If allowFloodgateNameConflict = false or linked and either autoLoginFloodgate or
autoRegisterFloodgate is set to no-conflict and a player with a non-conflicting name
connects then there will be a double check.
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.
Added a shared class for Floodgate name conflict checking that can be used by both ProtocolLib and ProtocolSupport
Rebased on Sat May 22 11:42:08 2021 +0200
Added access modifier to "FastLoginBukkit plugin;" in FloodgateHook.java
Rebased on Sat May 22 11:42:08 2021 +0200
Initialize FloogateHook in ProtocolLib's class
Floodgate 1.0 does not work with the current Bukkit implementation.
ProtocolLib and Floodgate don' play along nicely when used with FastLogin
Related issue: #493
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.
previously if autoRegisterFloodgate was set to false and the player was
not registered, the plugin tried to auto-login the user, which has led
to misleading "Failed to login" messages
Smart123s
games647
墨水瓶Official
InkerBot