Closed jimkberry closed 3 years ago
It turns out that things are worse than I thought.
Currently a peer sees another peer leave a game ( GameNet.OnPeerLeft()
is called) as the result of:
goodbye
from the leaving peerP2pNet detects a ping response timeout
As a result, the surviving peer synthesizes and directly applies (doesn't brodcast) GroupMemberStatusMsg(removed)
to every local GroupMgr instance, signals the AppDriver that the peer is gone and then removes the lost peer from the local ApianGameNet known-peers list.
This local action is premature. As it turns out, the GroupMemberStatus messages are typically ignored since they didn't come from Apian itself using the normal group messaging protocol.
It's a bit of a mess.
Less of a mess than I'd thought. It's still pretty brutal, but not as bad as I'd thought- at least it does work a results in the proper bikes and markers being destroyed, as well as the player object.
Probably isn't needed for BeamDemo#1 - but still oughta be more straightforward and hopefully a little bit more elegant.
It's now a lot more straightforward - not so sure about elegant. Still needs some work - but what it really needs are client use-cases to see exactly what it really does need. At least now you can leave a game session without leaving all of them or disconnecting from the network.
This probably involves ApianNet as well.
Currently when the app leave ModePlay ( probably splash and parctice as well, but it's not important) if calls AppCode.End() and then GameNet.LeaveGame() - which is pretty brutal. It sends a "goodbye" the the main channel which results in GameNet.OnPeerLeft() on all the other nodes, which is also what happens when a peer crashes.
Before calling GN.LeaveGame() the code should at least send out messages to any Apian groups announcing that it's leaving.
Looks like the current handling of even a timeout/drop is very wrong. (More info below)