AuthMe / AuthMeReloaded

The best authentication plugin for the Bukkit/Spigot API!
https://www.spigotmc.org/resources/authmereloaded.6269/
GNU General Public License v3.0
634 stars 514 forks source link

[Dev-API] LoadCompleteEvent and PreLoadEvent #799

Open games647 opened 8 years ago

games647 commented 8 years ago

Some plugins want to make interactions with AuthMe player after login. The problem is that AuthMe is handling a lot of stuff async in the background in the meanwhile. This could be the cause for flying, inventory issues as in #789 described.

I'm thinking of a event to notify other plugins when we finished initializing the player. (i.e. inventory protection, location protecting, saving online state to database). The event should be called before sending a login message to the player in the case a plugin want to modify or remove this message (i.e. force login)

Moreover there plugins which makes the player to skip authentication. For these case in might make sense if we make an PreLoadEvent too. This event could be cancellable. If a plugin cancels this even, we only perform necessary actions like saving the online state to the database.

What your opinion about that? Another solution is to lock operations to specific players.

My thoughts about the AutoIn issues AutoIn calls the forcelogin method directly on the join event while AuthMe is initializing the player (async). There could be race conditions while the protecting effects (i.e. flying) will be applied after AuthMe wants to restore it. I think @GotoFinal does this in order to remove the login message. My above suggestion would remove the need to do that on the joinevent.

A lot of the stuff here, is a guess by me. Sorry if I'm wrong somewhere.

GotoFinal commented 8 years ago

It's good idea, but much simpler (seems to be simpler) may be change authme code to delay forceLogin method, and invoke it after async task. And move login message if needed, so it will be executed after join event, and after async tasks, and message will be not displayed if player is already logged in.

Or add both ;)

EbonJaeger commented 8 years ago

Given I also write the PerWorldInventory plugin, and have had people come to me with inventory weirdness on logging in, I wonder if doing this would allow the two plugins to integrate better together.

games647 commented 8 years ago

@GotoFinal

It's good idea, but much simpler (seems to be simpler) may be change authme code to delay forceLogin method, and invoke it after async task.

It might be really be easier. Just locking and queue all player operations until the initialization is finished. And this wouldn't force plugin developers to use the new API. So it's backwards compatible.

And move login message if needed, so it will be executed after join event, and after async tasks, and message will be not displayed if player is already logged in.

I think kind of waiting for the end of the queue, isn't it?

@Gnat008

Given I also write the PerWorldInventory plugin, and have had people come to me with inventory weirdness on logging in, I wonder if doing this would allow the two plugins to integrate better together.

Shouldn't it work better with the packet inventory hider?

EbonJaeger commented 8 years ago

@games647

Shouldn't it work better with the packet inventory hider?

That was the theory, but I'm not sure how well that worked. In any case, events + API would likely be a cleaner way to handle it regardless.

sgdc3 commented 8 years ago

@games647 your event would be only a workaround, in my opinion we should try to reduce the ammount of async stuff first.

Azfaloth commented 8 years ago

any progress on this?