/// Wraps the invocation of NetworkingManager.StartClient, including our GUID as the payload.
/// </summary>
/// <param name="ipaddress">the IP address of the host to connect to.</param>
/// <remarks>
/// This method must be static because, when it is invoked, the client still doesn't know it's a client yet, and in particular, GameNetHub hasn't
/// yet initialized its GNH_Client and GNH_Server objects yet (which it does in NetworkStart, based on the role that the current player is performing).
/// </remarks>
/// <param name="ipaddress">the IP address of the host to connect to. (currently IPV4 only)</param>
/// <param name="port">The port of the host to connect to. </param>
EMATCHSTARTED,//can't join, match is already in progress.
EUNKNOWN//can't join, reason unknown.
EUNKNOWN,//can't join, reason unknown.
}
/// <summary>
/// </summary>
///
/// <remarks
/// Why is there a RequestConnect call-and-response here? How is that different from the "ApprovalCheck" logic that MLAPI optionally runs
/// Why is there a C2S_ConnectFinished event here? How is that different from the "ApprovalCheck" logic that MLAPI optionally runs
/// In short, the connection flow in this class happens second after the logic embodied by StartClient runs (and after the client has seen
/// NetworkStart fire). We need to provide an initial dump of info when a client logs in, specifically what scene to transition to. We would need
/// this message even if we used ConnectionData to send up our client GUID--because of that, it makes more sense to keep the two RPCs here, as
/// a 2nd step in the login flow.
/// MLAPI's ApprovalCheck logic doesn't offer a way to return rich data. We need to know certain things directly upon logging in, such as
/// whether the game-layer even wants us to join (we could fail because the server is full, or some other non network related reason), and also
/// what BossRoomState to transition to. We do this with a Custom Named Message, which fires on the server immediately after the approval check delegate
/// has run.
///
/// Why do we need to send a client GUID? What is it? Don't we already have a clientID?
/// ClientIDs are assigned on login. If you connect to a server, then your connection drops, and you reconnect, you get a new ClientID. This
/// </remarks>
///
publicclassGameNetHub:MLAPI.NetworkedBehaviour
publicclassGameNetHub:MonoBehaviour
{
publicGameObjectNetworkingManagerGO;
voidStart()
{
Object.DontDestroyOnLoad(this.gameObject);
Object.DontDestroyOnLoad(NetworkingManagerGO);
//FIXME_DMW: would like to remove this. I have added it because at the moment I can't stop MLAPI from destroying the
//GameHub object I created (that I intended to live for the entire lifetime of the game), and replacing it with its
//own copy (which naturally doesn't have this editor-configured value set). I have tried setting "UsePrefabSync" to false,
/// This method runs when NetworkingManager has started up (following a succesful connect on the client, or directly after StartHost is invoked
/// on the host). It is named to match NetworkedBehaviour.NetworkStart, and serves the same role, even though GameNetHub itself isn't a NetworkedBehaviour.
David Woodruff
4 年前