Fix transit stuff

[Maxopoly]

Players stay in transit until another shards sends a message indicating that the player arrived or after a 30 second time out.

[Maxopoly]

Oh and portals have a 10 second cooldown now

[ProgrammerDan]

Ok so the only thing that seems to be missing is blocking saves while intransit.

Also, will the target server know the player is intransit? Ideally we'd want to cancel events and saves on the target server until the player is fully arrived.

[Maxopoly]

Right now the target server doesn't know the difference between a normal player login and a player arriving because of Bungee. We could do something with Mercury, but it's hard to guarantee anything.

[Maxopoly]

Do you mean that we should add an inTransit equivalent for arrival that prevents anything until player data is guaranteed to be loaded?

[ProgrammerDan]

That's fine, mostly I'm just after what I described in the channel:

while intransfer prevent save, 'cept for the save which is triggered by the transfer event

similarly on join, prevent save until player is fully joined and the message releasing intransfer is sent.

[Maxopoly]

Ok, I'll refrain from making the main plugin class worse and split that and the original in transit thing out in a separate class

[ProgrammerDan]

basically Intransit should tell the target server to expect the person; then they can be intransit on both sides.

This doesn't conflict with normal first-joins as the player will simply join as normal, with no interference from intransit b/c they won't be on that list.

[Maxopoly]

Can we guarantee that the Mercury message arrives before the player arrives via Bungee?

[ProgrammerDan]

not yet but it doesn't matter; if the message arrives late we'll just be "unprotected" but it shouldn't interfere with normal login as the arriving server will assume they are a user logging straight in to them instead of a transfer. The bit we're discussing is just extra protection.

In terms of order of operations however, the intransit alert should be sent prior to anything else in the transfer sequence; rabbit delivers pretty darn fast so there's a very good chance it will happen first.

[Maxopoly]

No, that was missing. I added it.

[Maxopoly]

So when should I be removing players from arrivalTransit and send a message to the origin shard to clean up it's exitTransit as well?

Right now it's in the join listener, should it be at the end of the asyncprelogin listener?

Aside from that is there anything else that should go here before it's merged?

[Maxopoly]

Ok fixed those. Thoughts on what I asked above?

[ProgrammerDan]

So I think we should remove them from origin server's exit transit when on the target server the player has finished join (Join MONITOR would be a fine place for it). There's no issue "keeping" the player in the exit queue, only reason to not just let them time out is in case the player wants to go back shortly after 10 sec timeout.

In fact you could just spawn an event to run 1-2s after join, maybe that would be best.