Remove docs
9
doc/.gitignore
vendored
@ -1,9 +0,0 @@
|
||||
###############
|
||||
# folder #
|
||||
###############
|
||||
/**/DROP/
|
||||
/**/TEMP/
|
||||
/**/packages/
|
||||
/**/bin/
|
||||
/**/obj/
|
||||
_site
|
@ -1,11 +0,0 @@
|
||||
# Basic Authenticator
|
||||
|
||||
Mirror includes a Basic Authenticator in the Mirror / Authenticators folder which just uses a simple username and password.
|
||||
- Drag the Basic Authenticator script to the inspector of the object in your scene that has Network Manager
|
||||
- The Basic Authenticator component will automatically be assigned to the Authenticator field in Network Manager
|
||||
|
||||
When you're done, it should look like this:
|
||||
|
||||
![Inspector showing Basic Authenticator component](Basic.png)
|
||||
|
||||
> **Note:** You don't need to assign anything to the event lists unless you want to subscribe to the events in your own code for your own purposes. Mirror has internal listeners for both events.
|
Before Width: | Height: | Size: 57 KiB |
@ -1,61 +0,0 @@
|
||||
# Authentication
|
||||
|
||||
When you have a multiplayer game, often you need to store information about your player for later games, keep game stats or communicate with your friends. For all these use cases, you often need a way to uniquely identify a user. Being able to tell users apart is called authentication. There are several methods available, some examples include:
|
||||
- Ask the user for username and password
|
||||
- Use a third party OAuth2 or OpenID identity provider, such as Facebook, Twitter, Google
|
||||
- Use a third party service such as PlayFab, GameLift or Steam
|
||||
- Use the device id, very popular method in mobile
|
||||
- Use Google Play in Android
|
||||
- Use Game Center in IOS
|
||||
- Use a web service in your website
|
||||
|
||||
## Encryption Notice
|
||||
|
||||
By default Mirror uses Telepathy, which is not encrypted, so if you want to do authentication through Mirror, we highly recommend you use a transport that supports encryption.
|
||||
|
||||
## Basic Authenticator
|
||||
|
||||
- [Basic Authenticator](Basic.md)
|
||||
Mirror includes a Basic Authenticator in the Mirror / Authenticators folder which just uses a simple username and password.
|
||||
|
||||
## Custom Authenticators
|
||||
|
||||
Authenticators are derived from an `Authenticator` abstract class that allows you to implement any authentication scheme you need.
|
||||
|
||||
From the Assets menu, click Create > Mirror > Network Authenticator to make your own custom Authenticator from our [Script Templates](../../General/ScriptTemplates.md), and just fill in the messages and validation code to suit your needs. When a client is successfully authenticated, call `base.OnServerAuthenticated.Invoke(conn)` on the server and `base.OnClientAuthenticated.Invoke(conn)` on the client. Mirror is listening for these events to proceed with the connection sequence. Subscribe to OnServerAuthenticated and OnClientAuthenticated events if you wish to perform additional steps after authentication.
|
||||
|
||||
## Message Registration
|
||||
|
||||
By default all messages registered to `NetworkServer` and `NetworkClient` require authentication unless explicitly indicated otherwise. To register messages to bypass authentication, you need to specify `false` for a bool parameter to the `RegisterMessage` method:
|
||||
|
||||
```
|
||||
NetworkServer.RegisterHandler<AuthenticationRequest>(OnAuthRequestMessage, false);
|
||||
```
|
||||
|
||||
Certain internal messages already have been set to bypass authentication:
|
||||
|
||||
- Server
|
||||
- `ConnectMessage`
|
||||
- `DisconnectMessage`
|
||||
- `ErrorMessage`
|
||||
- `NetworkPingMessage`
|
||||
- Client
|
||||
- `ConnectMessage`
|
||||
- `DisconnectMessage`
|
||||
- `ErrorMessage`
|
||||
- `SceneMessage`
|
||||
- `NetworkPongMessage`
|
||||
|
||||
### Tips
|
||||
|
||||
- Register handlers for messages in `OnStartServer` and `OnStartClient`. They're called from StartServer/StartHost, and StartClient, respectively.
|
||||
- Send a message to the client if authentication fails, especially if there's some issue they can resolve.
|
||||
- Call the `Disconnect()` method of the `NetworkConnection` on the server and client when authentication fails. If you want to give the user a few tries to get their credentials right, you certainly can, but Mirror will not do the disconnect for you.
|
||||
- Remember to put a small delay on the Disconnect call on the server if you send a failure message so that it has a chance to be delivered before the connection is dropped.
|
||||
- `NetworkConnection` has an `authenticationData` object where you can drop any data you need to persist on the server related to the authentication, such as account id's, tokens, character selection, etc.
|
||||
|
||||
Now that you have the foundation of a custom Authenticator component, the rest is up to you. You can exchange any number of custom messages between the server and client as necessary to complete your authentication process before approving the client.
|
||||
|
||||
Authentication can also be extended to character selection and customization, just by crafting additional messages and exchanging them with the client before completing the authentication process. This means this process takes place before the client player actually enters the game or changes to the Online scene.
|
||||
|
||||
If you write a good authenticator, consider sharing it with other users or donating it to the Mirror project.
|
@ -1,4 +0,0 @@
|
||||
- name: Overview
|
||||
href: index.md
|
||||
- name: Basic Authenticator
|
||||
href: Basic.md
|
Before Width: | Height: | Size: 8.6 KiB |
Before Width: | Height: | Size: 38 KiB |
@ -1,26 +0,0 @@
|
||||
# Network Animator
|
||||
|
||||
The Network Animator component allows you to synchronize animation states for networked objects. It synchronizes state and parameters from an Animator Controller.
|
||||
|
||||
Note that if you create a Network Animator component on an empty game object, Mirror also creates a Network Identity component and an Animator component on that game object.
|
||||
|
||||
![The Network Animator component in the Inspector window](NetworkAnimatorComponent.png)
|
||||
|
||||
- **Client Authority**
|
||||
Enable this to have changes to animation parameters sent from client to server.
|
||||
|
||||
- **Animator**
|
||||
Use this field to define the Animator component you want the Network Animator to synchronize with.
|
||||
|
||||
Normally, changes are sent to all observers of the object this component is on. Setting **Sync Mode** to Owner Only makes the changes private between the server and the client owner of the object.
|
||||
|
||||
You can use the **Sync Interval** to specify how often it syncs (in seconds).
|
||||
|
||||
## Details
|
||||
|
||||
The Network Animator ensures the synchronization of game object animation across the network, meaning that all players see the animation happen at the same. There are two kinds of authority for networked animation (see documentation on [network authority](../Guides/Authority.md)):
|
||||
|
||||
> **NOTE:** Animator Triggers are not synced directly. Call `NetworkAnimator.SetTrigger` instead. A game object with authority can use the SetTrigger function to fire an animation trigger on other clients.
|
||||
|
||||
- If the game object has authority on the client, you should animate it locally on the client that owns the game object. That client sends the animation state information to the server, which broadcasts it to all the other clients. For example, this may be suitable for player characters with client authority.
|
||||
- If the game object has authority on the server, then you should animate it on the server. The server then sends state information to all clients. This is common for animated game objects that are not related to a specific client, such as scene objects and non-player characters, or server-authoritative clients.
|
Before Width: | Height: | Size: 40 KiB |
@ -1,119 +0,0 @@
|
||||
# Network Discovery
|
||||
|
||||
Suppose your are next to a friend. He starts a game in host mode and you want to join him. How will your phone locate his? Finding out his IP address is not exactly intuitive or something kids can do.
|
||||
|
||||
To solve this problem you can use Network Discovery. When your game starts, it sends a message in your current network asking "Is there any server available?". Any server within the same network will reply and provide information about how to connect to it.
|
||||
|
||||
Mirror comes with a simple implementation of Network Discovery you can simply use in your game. It also provides a way for you to extend it so that you can pass additional data during the discovery phase.
|
||||
|
||||
![Inspector](NetworkDiscovery.png)
|
||||
|
||||
NetworkDiscovery and NetworkDiscoveryHUD components are included, or you can make your own from a [ScriptTemplate](../General/ScriptTemplates.md).
|
||||
|
||||
Network Discovery uses a UDP broadcast on the LAN enabling clients to find the running server and connect to it.
|
||||
|
||||
When a server is started, it listens on the UDP Broadcast Listen Port for requests from clients and returns a connection URI that clients apply to their transport.
|
||||
|
||||
You can adjust how often the clients send their requests out to find a server in seconds with the Active Discovery Interval.
|
||||
|
||||
The Server Found event must be assigned to a handler method, e.g. the OnDiscoveredServer method of NetworkDiscoveryHUD.
|
||||
|
||||
In the NetworkDiscoveryHUD, the NetworkDiscovery component should be assigned automatically.
|
||||
|
||||
## Quick Start
|
||||
|
||||
To use Network Discovery follow these steps:
|
||||
|
||||
1. Create a gameobject with a NetworkManager if you have not done so already
|
||||
2. Do not add a NetworkManagerHUD. Discovery has a different UI component.
|
||||
3. Add a NetworkDiscoveryHUD component to the NetworkManager gameobject.
|
||||
A NetworkDiscovery component will be automatically added and wired up to your HUD.
|
||||
4. Add a player to the NetworkManager if you have not done so.
|
||||
5. Build and run a standalone version
|
||||
6. Click on Start Host
|
||||
7. Start play mode in the editor and click on Find Servers
|
||||
8. The editor should find the standalone version and display a button
|
||||
9. Click on the button to connect to it.
|
||||
|
||||
The NetworkDiscoveryHUD is provided as a simple and quick way to get started, but you will probably want to replace it with your own user interface.
|
||||
|
||||
## Custom Network Discovery
|
||||
|
||||
You can completely replace the user interface by adding your own interface (typically Unity UI based) instead of the default NetworkDiscoveryHUD. You do still need the NetworkDiscovery component to do the heavy lifting.
|
||||
|
||||
Sometimes you want to provide more information in the discovery messages. Some use cases could include:
|
||||
|
||||
- The client can show if the server is in PvP or PvE mode
|
||||
- The client can show how full the servers are.
|
||||
- The client can show the ping to each server so the player can chose the fastest server
|
||||
- The client can show the language
|
||||
- The client can show if the server is password protected
|
||||
|
||||
To do this, we've provided a [Template](../General/ScriptTemplates.md), so from the Assets menu, click Create > Mirror > Network Discovery.
|
||||
|
||||
This will create a script in your project with 2 empty message classes and a custom NetworkDiscovery class that inherits from NetworkDiscoveryBase and has all the override methods included and documented for you.
|
||||
|
||||
The message classes define what is sent between the client and server. As long as you keep your messages simple using the [data types](../Guides/DataTypes.md) that Mirror can serialize, you won't need to write custom serializers for them.
|
||||
|
||||
```cs
|
||||
public class DiscoveryRequest : MessageBase
|
||||
{
|
||||
public string language="en";
|
||||
|
||||
// Add properties for whatever information you want sent by clients
|
||||
// in their broadcast messages that servers will consume.
|
||||
}
|
||||
|
||||
public class DiscoveryResponse : MessageBase
|
||||
{
|
||||
enum GameMode {PvP, PvE};
|
||||
|
||||
// you probably want uri so clients know how to connect to the server
|
||||
public Uri uri;
|
||||
|
||||
public GameMode GameMode;
|
||||
public int TotalPlayers;
|
||||
public int HostPlayerName;
|
||||
|
||||
// Add properties for whatever information you want the server to return to
|
||||
// clients for them to display or consume for establishing a connection.
|
||||
}
|
||||
```
|
||||
|
||||
The custom NetworkDiscovery class contains the overrides for handling the messages above.
|
||||
|
||||
You may want to refer to the NetworkDiscovery.cs script in the Components/Discovery folder to see how these should be implemented.
|
||||
|
||||
```cs
|
||||
public class NewNetworkDiscovery: NetworkDiscoveryBase<DiscoveryRequest, DiscoveryResponse>
|
||||
{
|
||||
#region Server
|
||||
|
||||
protected override void ProcessClientRequest(DiscoveryRequest request, IPEndPoint endpoint)
|
||||
{
|
||||
base.ProcessClientRequest(request, endpoint);
|
||||
}
|
||||
|
||||
protected override DiscoveryResponse ProcessRequest(DiscoveryRequest request, IPEndPoint endpoint)
|
||||
{
|
||||
// TODO: Create your response and return it
|
||||
return new DiscoveryResponse();
|
||||
}
|
||||
|
||||
#endregion
|
||||
|
||||
#region Client
|
||||
|
||||
protected override DiscoveryRequest GetRequest()
|
||||
{
|
||||
return new DiscoveryRequest();
|
||||
}
|
||||
|
||||
protected override void ProcessResponse(DiscoveryResponse response, IPEndPoint endpoint)
|
||||
{
|
||||
// TODO: a server replied, do something with the response such as invoking a unityevent
|
||||
}
|
||||
|
||||
#endregion
|
||||
}
|
||||
```
|
Before Width: | Height: | Size: 46 KiB |
Before Width: | Height: | Size: 218 KiB |
@ -1,9 +0,0 @@
|
||||
# Network Headless Logger
|
||||
|
||||
Network Headless Logger replaces the the default log handler with one that set `Console.ForegroundColor`.
|
||||
|
||||
Only replaces the handler when running in headless mode.
|
||||
|
||||
![Inspector](NetworkHeadlessLogger.png)
|
||||
|
||||
`showExceptionStackTrace` will log the stack trace of any exceptions sent to the handler.
|
Before Width: | Height: | Size: 6.5 KiB |
Before Width: | Height: | Size: 12 KiB |
@ -1,31 +0,0 @@
|
||||
# Network Identity
|
||||
|
||||
**See also <xref:Mirror.NetworkIdentity> in the API Reference.**
|
||||
|
||||
The Network Identity component is at the heart of the Unity networking high-level API. It controls a game object’s unique identity on the network, and it uses that identity to make the networking system aware of the game object. It offers two different options for configuration and they are mutually exclusive, which means either one of the options or none can be checked.
|
||||
- **Server Only**
|
||||
Tick this checkbox to ensure that Unity only spawns the game object on the server, and not on clients.
|
||||
|
||||
![Inspector](NetworkIdentity.PNG)
|
||||
|
||||
## Instantiated Network Game Objects
|
||||
|
||||
With the Mirror’s server-authoritative networking system, the server must spawn networked game objects with network identities, using `NetworkServer.Spawn`. This automatically creates them on clients that are connected to the server, and assigns them a `netId`.
|
||||
|
||||
You must put a Network Identity component on any Prefabs that spawn at runtime for the network system to use them. See [Object Spawning](../Guides/GameObjects/SpawnObject.md) for more information.
|
||||
|
||||
## Scene-based Network Game Objects
|
||||
|
||||
You can also network game objects that are saved as part of your Scene (for example, environmental props). Networking game objects makes them behave slightly differently, because you need to have them spawn across the network.
|
||||
|
||||
When building your game, Unity disables all Scene-based game objects with Network Identity components. When a client connects to the server, the server sends spawn messages to tell the client which Scene game objects to enable and what their most up-to-date state information is. This ensures the client’s game does not contain game objects at incorrect locations when they start playing, or that Unity does not spawn and immediately destroy game objects on connection (for example, if an event removed the game object before that client connected). See [Networked Scene Game Objects](../Guides/GameObjects/SceneObjects.md) for more information.
|
||||
|
||||
## Preview Pane Information
|
||||
|
||||
This component contains network tracking information, and displays that information in the preview pane. For example, the scene ID, network ID and asset ID the object has been assigned. This allows you to inspect the information which can be useful for investigation and debugging.
|
||||
|
||||
![Preview](NetworkIdentityPreview.png)
|
||||
|
||||
At runtime there is more information to display here (a disabled NetworkBehaviour is displayed non-bold):
|
||||
|
||||
![Runtime Preview](NetworkIdentityPreviewRuntime.png)
|
Before Width: | Height: | Size: 5.3 KiB |
Before Width: | Height: | Size: 16 KiB |
@ -1,15 +0,0 @@
|
||||
# Network Lerp Rigidbody
|
||||
|
||||
> The Network Lerp Rigidbody classed as "Experimental" for now so please share any problems or bugs you find with it and use at your own risk if production builds.
|
||||
|
||||
The Network Lerp Rigidbody component synchronizes position and velocity of a rigidbody across the network. This component is useful when you have a non-kinematic rigidbody that have constant forces applied to them, like gravity, but also want to apply forces or change velocity to that rigidbody or server or client with authority. For example, objects that move and jump using rigidbody using gravity.
|
||||
|
||||
A game object with a Network Rigidbody component must also have a Network Identity component. When you add a Network Rigidbody component to a game object, Mirror also adds a Network Identity component on that game object if it does not already have one.
|
||||
|
||||
When using the Network Lerp Rigidbody you should have NetworkTransform on the same object as the Network Lerp Rigidbody will handle syncing the position
|
||||
|
||||
By default, Network Lerp Rigidbody is server-authoritative unless you check the box for **Client Authority**. Client Authority applies to player objects as well as non-player objects that have been specifically assigned to a client, but only for this component. With this enabled, value changes are send from the client to the server.
|
||||
|
||||
Normally, changes are sent to all observers of the object this component is on. Setting **Sync Mode** to Owner Only makes the changes private between the server and the client owner of the object.
|
||||
|
||||
You can use the **Sync Interval** to specify how often it syncs (in seconds). This applies both to Client Authority and Server Authority.
|
@ -1,29 +0,0 @@
|
||||
# Network Log Settings
|
||||
|
||||
**See also <xref:Mirror.LogFactory> in the API Reference.**
|
||||
|
||||
## Network Log Settings component
|
||||
|
||||
The Network Log Settings component allows you to configure logging levels and load the settings in a build.
|
||||
|
||||
When you first add NetworkLogSettings you will have to Create a new LogSettings asset that will store the settings.
|
||||
|
||||
![Inspector With No Settings](NetworkLogSettingsNoSettings.png)
|
||||
|
||||
> **Note:** If a LogSettings asset already exists the NetworkLogSettings component will set the Settings field when it is added to a game object.
|
||||
|
||||
## Log Settings
|
||||
|
||||
When you first set up LogSettings the list of components may be empty or incomplete. Running the game will cause Mirror scripts to add their respective loggers to the list so their logging levels can be changed.
|
||||
|
||||
![Inspector](NetworkLogSettings.png)
|
||||
|
||||
Log settings can also be changed using the "Mirror Log Level" window, which can be opened from the editor menu: Window > Analysis > Mirror Log Levels.
|
||||
|
||||
![Window](LogLevelWindow.png)
|
||||
|
||||
To change settings at runtime please see <xref:Mirror.LogFactory>.
|
||||
|
||||
## Issues
|
||||
|
||||
Mirrors Logging api is currently work in progress. If there is a bug or a feature you want added please make an issue [here](https://github.com/vis2k/Mirror/issues).
|
Before Width: | Height: | Size: 27 KiB |
Before Width: | Height: | Size: 23 KiB |
@ -1,246 +0,0 @@
|
||||
# Network Manager
|
||||
|
||||
The Network Manager is a component for managing the networking aspects of a multiplayer game.
|
||||
|
||||
The Network Manager features include:
|
||||
- Game state management
|
||||
- Spawn management
|
||||
- Scene management
|
||||
- Debugging information
|
||||
- Customization
|
||||
|
||||
## Getting Started with the Network Manager
|
||||
|
||||
The Network Manager is the core controlling component of a multiplayer game. To get started, create an empty game object in your starting Scene, and add the Network Manager component. The newly added Network Manager component looks like this:
|
||||
|
||||
![The Network Manager as seen in the inspector window](NetworkManagerInspector.png)
|
||||
|
||||
The Inspector for the Network Manager in the Editor allows you to configure and control many things related to networking.
|
||||
|
||||
**Note**: You can only ever have one active Network Manager in each scene because it's a singleton. Do not place the Network Manager component on a networked game object (one which has a Network Identity component), because Mirror disables these when the Scene loads.
|
||||
|
||||
If you are already familiar with multiplayer game development, you might find it useful to know that the Network Manager component is implemented entirely using the API, so everything it does is also available to you through scripting. For advanced users, if you find that you need to expand on the Network Manager component’s features, you can use scripting to derive your own class from Network Manager and customize its behavior by overriding any of the virtual function hooks that it provides. However, the Network Manager component wraps up a lot of useful functionality into a single place, and makes creating, running and debugging multiplayer games as simple as possible.
|
||||
|
||||
## Transports
|
||||
|
||||
Mirror uses a separate component (derived from the Transport class) to connect across the network. By default, it is Telepathy Transport. This design choice of separating the transport into its own component allows game developers to choose the transport that best fits their game needs. Changing transports is as simple as swapping out the component on the Network Manager object and assigning it to the Transport field.
|
||||
|
||||
Transports are available for TCP, UDP, WebGL, and Steam. Additionally, there's a Multiplex transport that allows for using two transports together on the server, e.g. Telepathy and WebSockets, so that desktop and browser players can play together on the same server seamlessly. See [Transports](../Transports/index.md) for more information.
|
||||
|
||||
## Game State Management
|
||||
|
||||
A Networking multiplayer game can run in three modes - as a client, as a dedicated server, or as a host which is both a client and a server at the same time.
|
||||
|
||||
If you’re using the Network Manager HUD, it automatically tells the Network Manager which mode to start in, based on which button the player clicks. If you’re writing your own UI that allows the player to start the game, you’ll need to call these from your own code. These methods are:
|
||||
- NetworkManager.StartClient
|
||||
- NetworkManager.StartServer
|
||||
- NetworkManager.StartHost
|
||||
|
||||
![The network address and port settings in the Network Manager and Telepathy components](NetworkAddressAndPortSettings.png)
|
||||
|
||||
Whichever mode the game starts in (client, server, or host), the Network Address and Transport Port properties are used.
|
||||
- In client mode, the game attempts to connect to the address and port specified. A fully-qualified domain name (FQDN) can also be used for the Network Address, e.g. "game.example.com".
|
||||
- In server or host mode, the game listens for incoming connections on the port specified, but does not bind to any specific IP address (it listens on all available).
|
||||
|
||||
## Spawn Management
|
||||
|
||||
Use the Network Manager to manage the spawning (networked instantiation) of networked game objects from Prefabs.
|
||||
|
||||
![The “Spawn Info” section of the Network Manager component](NetworkManagerSpawnInfo.png)
|
||||
|
||||
Most games have a Prefab which represents the player, so the Network Manager has a Player Prefab slot. You should assign this slot with your player Prefab. When you have a player Prefab set, a player game object is automatically spawned from that Prefab for each user in the game. This applies to the local player on a hosted server, and remote players on remote clients. You must attach a Network Identity component to the Player Prefab before assigning it to this field.
|
||||
|
||||
Once you have assigned a Player Prefab, you can start the game as a host and see the player game object spawn. Stopping the game destroys the player game object . If you build and run another copy of the game and connect it as a client to *localhost*, the Network Manager makes another player game object appear. When you stop that client, it destroys that player’s game object.
|
||||
|
||||
In addition to the Player Prefab, you must also register other prefabs that you want to dynamically spawn during game play with the Network Manager.
|
||||
|
||||
You can add prefabs to the list shown in the inspector labelled Registered Spawnable Prefabs. You can also register prefabs via code, with the `ClientScene.RegisterPrefab` method.
|
||||
|
||||
If you have one Network Manager that is persisted through scenes via Don't Destroy On Load (DDOL), you need to register all prefabs to it which might be spawned in any scene. If you have a separate Network Manager in each scene, you only need to register the prefabs relevant for that scene.
|
||||
|
||||
## Start Positions
|
||||
|
||||
The Network Manager will spawn Player Prefab at their defined transform position and rotation by default, however the Player Spawn Method property allows you to control how start positions are chosen in conjunction with [Network Start Position](NetworkStartPosition.md) components.
|
||||
- Choose Random to spawn players at randomly chosen startPosition options.
|
||||
- Choose Round Robin to cycle through startPosition options in a set list.
|
||||
|
||||
If the Random or Round Robin modes don’t suit your game, you can customize how the start positions are selected by using code. You can access the available Network Start Position components by the list `NetworkManager.startPositions`, and you can use the helper method `GetStartPosition` on the Network Manager that can be used in an implementation of `OnServerAddPlayer` to find a start position.
|
||||
|
||||
## Scene Management
|
||||
|
||||
Most games have more than one scene. At the very least, there is usually a title screen or starting menu scene in addition to the scene where the game is actually played. The Network Manager is designed to automatically manage scene state and scene transitions in a way that works for a multiplayer game.
|
||||
|
||||
There are two slots on the Network Manager inspector for scenes: the Offline Scene and the Online Scene. Dragging scene assets into these slots activates networked Scene Management.
|
||||
|
||||
When a server or host is started, the Online Scene is loaded. This then becomes the current network scene. Any clients that connect to that server are instructed to also load that scene. The name of this scene is stored in the `networkSceneName` property.
|
||||
|
||||
When the network is stopped, by stopping the server or host or by a client disconnecting, the offline Scene is loaded. This allows the game to automatically return to a menu scene when disconnected from a multiplayer game.
|
||||
|
||||
You can also change scenes while the game is active by calling `ServerChangeScene`. This makes all the currently connected clients change Scene too, and updates `networkSceneName` so that new clients also load the new Scene.
|
||||
|
||||
While networked Scene management is active, any calls to game state management functions such as `StartHost` or `StopClient` can cause scene changes. This applies to the runtime control UI. By setting up scenes and calling these methods, you can control the flow of your multiplayer game.
|
||||
|
||||
Note that scene change causes all the game objects in the previous scene to be destroyed.
|
||||
|
||||
You should normally make sure the Network Manager persists between Scenes, otherwise the network connection is broken upon a scene change. To do this, ensure the Don’t Destroy On Load checkbox is ticked in the inspector. However it is also possible to have a separate Network Manager in each scene with different settings, which may be helpful if you wish to control incremental prefab loading, or different scene transitions.
|
||||
|
||||
## Customization
|
||||
|
||||
There are virtual functions on the `NetworkManager` class that you can customize by creating your own derived class that inherits from `NetworkManager`. When implementing these functions, be sure to take care of the functionality that the default implementations provide. For example, in `OnServerAddPlayer`, the function `NetworkServer.AddPlayer` must be called to activate the player game object for the connection.
|
||||
|
||||
## Properties
|
||||
- **dontDestroyOnLoad**
|
||||
Use this property to control whether or not Mirror should destroy the game object with the Network Manager when the Scene changes. Tick this checkbox to ensure Mirror does not destroy your Network Manager game object when the Scene changes in your game. Untick the checkbox if you want Mirror to destroy the game object when the Scene it exists in is no longer the active Scene. This is useful if you want to manage multiple, separate Network Manager game objects in each of your Scenes. This checkbox is ticked by default.
|
||||
- **runInBackground**
|
||||
Use this property to control whether the networked game runs when the window it is running in is not focused. Tick the checkbox if you want it to run; untick it if you want the game to stop running when the window is not focused. This checkbox is ticked by default. You need to enable this property if you want to run multiple instances of a program on the same machine, such as when testing using localhost. You should disable it when deploying to mobile platforms. When enabled, it sets Application.runInBackground to true when the Network Manager starts up. You can also set this property from the Unity menu: Edit \> Project Settings, then select the Player category, and navigate to the Resolution and Presentation panel.
|
||||
- **startOnHeadless**
|
||||
If this box is checked (property is true) *and* computer that runs the program has no graphic device, program will start in server mode.
|
||||
- **serverTickRate**
|
||||
Sets the target frame rate for the server. Default is 30.
|
||||
- **showDebugMessages**
|
||||
Use this property to control the amount of information Mirror outputs to the console window.
|
||||
- **offlineScene**
|
||||
If you assign a Scene to this field, the Network Manager automatically switches to the specified Scene when a network session stops - for example, when the client disconnects, or when the server shuts down.
|
||||
- **onlineScene**
|
||||
If you assign a Scene to this field, the Network Manager automatically switches to the specified Scene when a network session starts - for example, when the client connects to a server, or when the server starts listening for connections.
|
||||
- **Network Info**
|
||||
|
||||
- **transport**
|
||||
A link to a Component derived from `Transport` class. TelepathyTransport is created and linked there by default.
|
||||
|
||||
- **networkAddress**
|
||||
The network address currently in use. For clients, this is the address of the server that is connected to. For servers, this is the local address. This is set to ‘localhost’ by default. A Fully Qualified Domain Name (FQDN) can be used by clients in this field.
|
||||
|
||||
- **maxConnections**
|
||||
Maximum number of clients connected to a server. Note that host is a server and one client. Transports may also have their own setting for this, otherwise they either copy this value or leave it to Mirror to manage the limit.
|
||||
- **SpawnInfo**
|
||||
You can expand this section of the inspector to access spawn-related settings, listed below
|
||||
|
||||
- **playerPrefab**
|
||||
Define the default prefab Mirror should use to create player game objects on the server. Mirror creates Player game objects in the default handler for AddPlayer on the server. Implement OnServerAddPlayer to override this behavior.
|
||||
|
||||
- **autoCreatePlayer**
|
||||
Tick this checkbox if you want Mirror to automatically create player game objects on connect, and when the Scene changes. This checkbox is ticked by default.
|
||||
|
||||
- **playerSpawnMethod**
|
||||
Define how Mirror should decide where to spawn new player game objects. This is set to Random by default.
|
||||
|
||||
- **random**
|
||||
Choose Random to spawn players at randomly chosen `startPositions`.
|
||||
|
||||
- **roundRobin**
|
||||
Choose Round Robin to cycle through startPositions in a set list.
|
||||
|
||||
- **spawnPrefabs**
|
||||
List of prefabs registered in the Network Manager
|
||||
|
||||
- **startPositions**
|
||||
List of Transforms built from all game objects in the scene with a Network Start Position component.
|
||||
|
||||
- **clientLoadedScene**
|
||||
Bool that indicates that the client has loaded the current scene
|
||||
|
||||
- **numPlayers**
|
||||
Returns the number of active connections from `NetworkServer`. Only valid on the server.
|
||||
|
||||
- **networkSceneName**
|
||||
Name of currently loaded and active scene.
|
||||
|
||||
- **isNetworkActive**
|
||||
Bool indicating that the server is online or the client is connected.
|
||||
|
||||
- **client**
|
||||
Returns the `NetworkClient.singleton`.
|
||||
|
||||
- **isHeadless**
|
||||
Bool that indicates if the application was started in headless mode.
|
||||
|
||||
## Methods
|
||||
|
||||
### Unity Virtual Callbacks
|
||||
|
||||
```cs
|
||||
public virtual void Awake() {}
|
||||
|
||||
public virtual void Start() {}
|
||||
```
|
||||
|
||||
### Server Methods
|
||||
|
||||
```cs
|
||||
public bool StartServer() {}
|
||||
|
||||
public void StartClient() {}
|
||||
|
||||
public void StopHost() {}
|
||||
|
||||
public void StopServer() {}
|
||||
|
||||
public void StopClient() {}
|
||||
|
||||
public Transform GetStartPosition() {}
|
||||
```
|
||||
|
||||
### Server Static Methods
|
||||
|
||||
```cs
|
||||
public static void RegisterStartPosition(Transform start) {}
|
||||
|
||||
public static void UnRegisterStartPosition(Transform start) {}
|
||||
|
||||
public static void Shutdown() {}
|
||||
```
|
||||
|
||||
### Server Virtual Methods
|
||||
|
||||
```cs
|
||||
public virtual void ConfigureServerFrameRate() {}
|
||||
|
||||
public virtual void StartHost() {}
|
||||
|
||||
public virtual void ServerChangeScene(string newSceneName, LoadSceneMode sceneMode, LocalPhysicsMode physicsMode) {}
|
||||
|
||||
public virtual void OnServerConnect(NetworkConnection conn) {}
|
||||
|
||||
public virtual void OnServerDisconnect(NetworkConnection conn) {}
|
||||
|
||||
public virtual void OnServerReady(NetworkConnection conn) {}
|
||||
|
||||
public virtual void OnServerAddPlayer(NetworkConnection conn, AddPlayerMessage extraMessage) {}
|
||||
|
||||
public virtual void OnServerRemovePlayer(NetworkConnection conn, NetworkIdentity player) {}
|
||||
|
||||
public virtual void OnServerError(NetworkConnection conn, int errorCode) {}
|
||||
|
||||
public virtual void OnServerSceneChanged(string sceneName) {}
|
||||
|
||||
public virtual void OnStartHost() {}
|
||||
|
||||
public virtual void OnStartServer() {}
|
||||
|
||||
public virtual void OnStopServer() {}
|
||||
|
||||
public virtual void OnStopHost() {}
|
||||
|
||||
public virtual void OnDestroy() {}
|
||||
```
|
||||
|
||||
### Client Virtual Methods
|
||||
|
||||
```cs
|
||||
public virtual void OnStartClient() {}
|
||||
|
||||
public virtual void OnStopClient() {}
|
||||
|
||||
public virtual void OnClientConnect(NetworkConnection conn) {}
|
||||
|
||||
public virtual void OnClientDisconnect(NetworkConnection conn) {}
|
||||
|
||||
public virtual void OnClientError(NetworkConnection conn, int errorCode) {}
|
||||
|
||||
public virtual void OnClientNotReady(NetworkConnection conn) {}
|
||||
|
||||
public virtual void OnClientChangeScene(string newSceneName, LoadSceneMode sceneMode) {}
|
||||
|
||||
public virtual void OnClientSceneChanged(NetworkConnection conn) {}
|
||||
```
|
@ -1,65 +0,0 @@
|
||||
# Network Manager HUD
|
||||
|
||||
The Network Manager HUD (“heads-up display”) is a quick-start tool to help you start building your multiplayer game straight away, without first having to build a user interface for game creation/connection/joining. It allows you to jump straight into your game play programming, and means you can build your own version of these controls later in your development schedule.
|
||||
|
||||
It is not, however, intended to be included in finished games. The idea is that these controls are useful to get you started, but you should create your own UI later on, to allow your players to find and join games in a way that suits your game. For example, you might want to stylize the design of the screens, buttons and list of available games to match the overall style of your game.
|
||||
|
||||
To start using the Network Manager HUD, either add the component to the same scene object that has the Network Manager component, or create an empty game object in your scene (menu: game object \> Create Empty) and add the Network Manager HUD component to the new game object.
|
||||
|
||||
![The Network Manager HUD component, as viewed in the inspector](NetworkManagerHUDComponent.png)
|
||||
- **Show GUI**
|
||||
Tick this checkbox to show the HUD GUI at run time. This allows you to reveal or hide it for quick debugging.
|
||||
- **Offset X**
|
||||
Set the horizontal **pixel** offset of the HUD GUI, measured from the left edge of the screen.
|
||||
- **Offset Y**
|
||||
Set the vertical pixel offset of the HUD GUI, measured from the top edge of the screen.
|
||||
|
||||
The Network Manager HUD provides the basic functions so that people playing your game can start hosting a networked game, or find and join an existing networked game. Unity displays the Network Manager HUD as a collection of simple UI buttons in the Game view.
|
||||
|
||||
![The Network Manager HUD GUI, as viewed in the Game view](NetworkManagerHUDUI.png)
|
||||
|
||||
## Using the HUD
|
||||
|
||||
The Network Manager HUD starts in Server + Client mode, and displays buttons relating to hosting and joining a multiplayer game.
|
||||
|
||||
### Host (Server + Client)
|
||||
|
||||
Click the Host (Server + Client) button to start a game as a host on the local network. This client is both the host *and* one of the players in the game. It uses the information from the Network Info section in the inspector to host the game.
|
||||
|
||||
When you click this button, the HUD switches to a simple display of network details, and a Stop button which allows you to stop hosting the game and return to the main HUD menu.
|
||||
|
||||
![The Network Manager HUD GUI when hosting a game.](NetworkManagerHUDHostingLAN.png)
|
||||
|
||||
When you have started a game as a host, other players of the game can then connect to the host to join the game.
|
||||
|
||||
Click the Stop button to disconnect from the host. Clicking Stop also returns to the main HUD menu.
|
||||
|
||||
### Client
|
||||
|
||||
To connect to a host on the internet use the text field to the right of the Client button to specify the address of the host. The default host address is “localhost”, which means the client looks on its own computer for the game host. In addition to *localhost*, you can specify an IPv4 address, and IPv6 address, or a fully-qualified domain name (FQDN), e.g. *game.example.com*, and the transport with resolve the name using DNS. Click Client to attempt to connect to the host address you have specified.
|
||||
|
||||
Use the default “localhost” in this field if you are running multiple instances of your game on one computer, to test multiplayer interactivity. To do this, you can create a standalone build of your game, and then launch it multiple times on your computer. This is a common way to quickly test that your networked game interactions are functioning as you expect, without you needing to deploy your game to multiple computers or devices.
|
||||
|
||||
![An example of three instances of a networked game running on the same desktop PC. This is useful for quick tests to ensure networked interactions are behaving as you intended. One is running as Host, and two are running as Client.](NetworkGame3Instances.jpg)
|
||||
|
||||
When you want to test your game on multiple machines you need to put the address of the computer acting as host into the address text field.
|
||||
|
||||
The computer acting as the host needs to tell their IP address to everyone running clients, so that you can type this into the box. For local clients on a LAN, that's the local IP address. For remote clients, that's the WAN IP address of the router of the host. Firewall rules and port-forwarding are generally required for a computer to act as host and accept connections from other computers, whether they're on the LAN or the internet.
|
||||
|
||||
Enter the IP address (or leave it as “localhost” if you are testing it on your own machine), then click Client to attempt to connect to the host.
|
||||
|
||||
When the client is attempting to connect, the HUD displays a Cancel Connection Attempt button. Click this if you want to stop trying to connect to the host.
|
||||
|
||||
![The HUD GUI while attempting a connection](NetworkManagerHUDConnectionAttempt.png)
|
||||
|
||||
If the connection is successful, the HUD displays the Stop button. Click this if you want to stop the game on the client and disconnect from the host:
|
||||
|
||||
![The HUD GUI after a successful connection](NetworkManagerHUDConnected.png)
|
||||
|
||||
### Server Only
|
||||
|
||||
Click Server Only to start a game which acts as a server that other clients can connect to, but which does not act as a client to the game itself. This type of game is often called a “dedicated server”. A user cannot play the game on this particular instance of your game. All players must connect as clients, and nobody plays on the instance that is running as the server.
|
||||
|
||||
A dedicated server results in better performance for all connected players, because the server doesn’t need to process a local player’s game play in addition to acting as server.
|
||||
|
||||
You might also choose this option if you want to host a game that can be played over the internet (rather than just within a local network), but want to maintain control of the server yourself - for example, to prevent cheating by one of the clients, because only the server has authority over the game. To do this, you would need to run the game in Server Only mode on a computer with a public IP address.
|
Before Width: | Height: | Size: 7.1 KiB |
Before Width: | Height: | Size: 5.7 KiB |
Before Width: | Height: | Size: 3.6 KiB |
Before Width: | Height: | Size: 11 KiB |
Before Width: | Height: | Size: 4.8 KiB |
Before Width: | Height: | Size: 59 KiB |
Before Width: | Height: | Size: 7.9 KiB |
@ -1,13 +0,0 @@
|
||||
# Network Match Checker
|
||||
|
||||
The Network Match Checker component controls visibility of networked objects based on match id.
|
||||
|
||||
![Network Scene Checker component](NetworkMatchChecker.png)
|
||||
|
||||
Any object with this component on it will only be visible to other objects in the same match.
|
||||
|
||||
This would be used to isolate players to their respective matches within a single game server instance.
|
||||
|
||||
When you create a match, generate and store, in a List for example, a new match id with `System.Guid.NewGuid();` and assign the same match id to the Network Match Checker via `GetComponent<NetworkMatchChecker>().matchId`.
|
||||
|
||||
Mirror's built-in Observers system will isolate SyncVar's and ClientRpc's on networked objects to only send updates to clients with the same match id.
|
Before Width: | Height: | Size: 12 KiB |
@ -1,9 +0,0 @@
|
||||
# Network Ping Display
|
||||
|
||||
Network Ping Display shows the Ping time for clients using OnGUI.
|
||||
|
||||
The Ping time is the moving average of the (RTT) Round-trip delay time. RTT is calculated by the PingMessage/PongMessage between the client and server.
|
||||
|
||||
![Inspector](NetworkPingDisplay.png)
|
||||
|
||||
See [Clock Synchronization](../Guides/ClockSync.md) for more info.
|
Before Width: | Height: | Size: 9.0 KiB |
Before Width: | Height: | Size: 10 KiB |
@ -1,21 +0,0 @@
|
||||
# Network Proximity Checker
|
||||
|
||||
The Network Proximity Checker component controls the visibility of game objects for network clients, based on proximity to players.
|
||||
|
||||
![Network Proximity Checker component](NetworkProximityCheck.png)
|
||||
- **Vis Range**
|
||||
Define the range that the game object should be visible to observers.
|
||||
- **Vis Update Interval**
|
||||
Define how often (in seconds) the game object should check for observers entering its visible range.
|
||||
- **Check Method**
|
||||
Define which type of physics (2D or 3D) to use for proximity checking.
|
||||
- **Force Hidden**
|
||||
Tick this checkbox to hide this object from all players.
|
||||
|
||||
With the Network Proximity Checker, a game running on a client doesn’t have information about game objects that are not visible. This has two main benefits: it reduces the amount of data sent across the network, and it makes your game more secure against hacking.
|
||||
|
||||
This component relies on physics to calculate visibility, so observer game objects must also have a collider component on it.
|
||||
|
||||
A game object with a Network Proximity Checker component must also have a Network Identity component. When you create a Network Proximity Checker component on a game object, Mirror also creates a Network Identity component on that game object if it does not already have one.
|
||||
|
||||
Scene objects with a Network Proximity Checker component are disabled when they're out of range, and spawned objects are destroyed when they're out of range.
|
@ -1,21 +0,0 @@
|
||||
# Network Rigidbody
|
||||
|
||||
> The Network Rigidbody classed as "Experimental" for now so please share any problems or bugs you find with it and use at your own risk if production builds.
|
||||
|
||||
The Network Rigidbody component synchronizes velocity and other properties of a rigidbody across the network. This component is useful when you have a non-kinematic rigidbody that have constant forces applied to them, like gravity, but also want to apply forces or change velocity to that rigidbody or server or client with authority. For example, objects that move and jump using rigidbody using gravity.
|
||||
|
||||
A game object with a Network Rigidbody component must also have a Network Identity component. When you add a Network Rigidbody component to a game object, Mirror also adds a Network Identity component on that game object if it does not already have one.
|
||||
|
||||
Network Rigidbody works best when there is also a NetworkTransform for the object to keep position as well as velocity in sync.
|
||||
|
||||
![Network Rigidbody inspector](NetworkRigidbody.png)
|
||||
|
||||
By default, Network Rigidbody is server-authoritative unless you check the box for **Client Authority**. Client Authority applies to player objects as well as non-player objects that have been specifically assigned to a client, but only for this component. With this enabled, value changes are send from the client to the server.
|
||||
|
||||
The **Sensitivity** options allow you to set a minimum thresholds before values are send over network. This helps minimize network traffic for very small changes.
|
||||
|
||||
For some object you may not want them to rotate but don't need to sync the Angular Velocity. The **Clear Angular Velocity** will set the Angular Velocity to zero each frame causing the minimizing when objects rotation. If **Sync Angular Velocity** is enabled then clear is ignored. The same can apply to **Clear Velocity**.
|
||||
|
||||
Normally, changes are sent to all observers of the object this component is on. Setting **Sync Mode** to Owner Only makes the changes private between the server and the client owner of the object.
|
||||
|
||||
You can use the **Sync Interval** to specify how often it syncs (in seconds). This applies both to Client Authority and Server Authority.
|
Before Width: | Height: | Size: 37 KiB |
@ -1,103 +0,0 @@
|
||||
# Network Room Manager
|
||||
|
||||
\*\*Please see the Room example in the Examples folder in your Mirror folder
|
||||
|
||||
The Network Room Manager is a specialized type of [Network Manager](NetworkManager.md) that provides a multiplayer room before entering the main play scene of the game. It allows you to set up a network with:
|
||||
- A maximum player limit
|
||||
- Automatic start when all players are ready
|
||||
- Option to prevent players from joining a game in progress
|
||||
- Customizable ways for players to choose options while in room
|
||||
|
||||
There are two types of player objects with the Network Room Manager:
|
||||
|
||||
**Room Player Prefab**
|
||||
- One for each player
|
||||
- Created when client connects, or player is added
|
||||
- Persists until client disconnects
|
||||
- Holds ready flag and configuration data
|
||||
- Handles commands in the room
|
||||
- Must use the [Network Room Player](NetworkRoomPlayer.md) component
|
||||
|
||||
**Player Prefab**
|
||||
- One for each player
|
||||
- Created when game scene is started
|
||||
- Destroyed when leaving game scene
|
||||
- Handles commands in the game
|
||||
|
||||
![Network Room Manager](NetworkRoomManager.png)
|
||||
|
||||
## Properties
|
||||
- **Show Room GUI**
|
||||
Show the default OnGUI controls for the room.
|
||||
- **Min Players**
|
||||
Minimum number of players needed to start a game.
|
||||
- **Room Player Prefab**
|
||||
The prefab to create for players when they enter the room (requires Network Room Player component).
|
||||
- **Room Scene**
|
||||
The scene to use for the room.
|
||||
- **Gameplay Scene**
|
||||
The scene to use for main game play.
|
||||
- **pendingPlayers**
|
||||
List\<PendingPlayer\> that holds players that are ready to start playing.
|
||||
- **roomSlots**
|
||||
List\<NetworkRoomPlayer\> that manages the slots for connected clients in the room.
|
||||
- **allPlayersReady**
|
||||
Bool indicating if all players are ready to start playing. This value changes as players invoke `CmdChangeReadyState` indicating true or false, and will be set false when a new client connects.
|
||||
|
||||
## Methods
|
||||
|
||||
### Server Virtual Methods
|
||||
|
||||
```cs
|
||||
public virtual void OnRoomStartHost() {}
|
||||
|
||||
public virtual void OnRoomStopHost() {}
|
||||
|
||||
public virtual void OnRoomStartServer() {}
|
||||
|
||||
public virtual void OnRoomServerConnect(NetworkConnection conn) {}
|
||||
|
||||
public virtual void OnRoomServerDisconnect(NetworkConnection conn) {}
|
||||
|
||||
public virtual void OnRoomServerSceneChanged(string sceneName) {}
|
||||
|
||||
public virtual GameObject OnRoomServerCreateRoomPlayer(NetworkConnection conn)
|
||||
{
|
||||
return null;
|
||||
}
|
||||
|
||||
public virtual GameObject OnRoomServerCreateGamePlayer(NetworkConnection conn)
|
||||
{
|
||||
return null;
|
||||
}
|
||||
|
||||
public virtual bool OnRoomServerSceneLoadedForPlayer(GameObject roomPlayer, GameObject gamePlayer)
|
||||
{
|
||||
return true;
|
||||
}
|
||||
|
||||
public virtual void OnRoomServerPlayersReady()
|
||||
{
|
||||
ServerChangeScene(GameplayScene);
|
||||
}
|
||||
```
|
||||
|
||||
### Client Virtual Methods
|
||||
|
||||
```cs
|
||||
public virtual void OnRoomClientEnter() {}
|
||||
|
||||
public virtual void OnRoomClientExit() {}
|
||||
|
||||
public virtual void OnRoomClientConnect(NetworkConnection conn) {}
|
||||
|
||||
public virtual void OnRoomClientDisconnect(NetworkConnection conn) {}
|
||||
|
||||
public virtual void OnRoomStartClient() {}
|
||||
|
||||
public virtual void OnRoomStopClient() {}
|
||||
|
||||
public virtual void OnRoomClientSceneChanged(NetworkConnection conn) {}
|
||||
|
||||
public virtual void OnRoomClientAddPlayerFailed() {}
|
||||
```
|
Before Width: | Height: | Size: 71 KiB |
@ -1,27 +0,0 @@
|
||||
# Network Room Player
|
||||
|
||||
The Network Room Player stores per-player state for the [Network Room Manager](NetworkRoomManager.md) while in the room. When using this component, you need to write a script which allows players to indicate they are ready to begin playing, which sets the ReadyToBegin property.
|
||||
|
||||
A game object with a Network Room Player component must also have a Network Identity component. When you create a Network Room Player component on a game object, Unity also creates a Network Identity component on that game object if it does not already have one.
|
||||
|
||||
![Network Room Player](NetworkRoomPlayer.png)
|
||||
- **Show Room GUI**
|
||||
Enable this to show the developer GUI for players in the room. This UI is only intended to be used for ease of development. This is enabled by default.
|
||||
- **Ready To Begin**
|
||||
Diagnostic indicator that a player is Ready.
|
||||
- **Index**
|
||||
Diagnostic index of the player, e.g. Player 1, Player 2, etc.
|
||||
- **Network Sync Interval**
|
||||
The rate at which information is sent from the Network Room Player to the server.
|
||||
|
||||
## Methods
|
||||
|
||||
### Client Virtual Methods
|
||||
|
||||
```cs
|
||||
public virtual void OnClientEnterRoom() {}
|
||||
|
||||
public virtual void OnClientExitRoom() {}
|
||||
|
||||
public virtual void OnClientReady(bool readyState) {}
|
||||
```
|
Before Width: | Height: | Size: 24 KiB |
@ -1,55 +0,0 @@
|
||||
# Network Scene Checker
|
||||
|
||||
The Network Scene Checker component controls the visibility of game objects for network clients, based on which scene they're in.
|
||||
|
||||
![Network Scene Checker component](NetworkSceneChecker.png)
|
||||
|
||||
- **Force Hidden**
|
||||
Tick this checkbox to hide this object from all players.
|
||||
|
||||
With the Network Scene Checker, a game running on a client doesn’t have information about game objects that are not visible. This has two main benefits: it reduces the amount of data sent across the network, and it makes your game more secure against hacking.
|
||||
|
||||
This component would typically be used when the server has several subscenes loaded and needs to isolate networked objects to the subscene they're in.
|
||||
|
||||
A game object with a Network Scene Checker component must also have a Network Identity component. When you create a Network Scene Checker component on a game object, Mirror also creates a Network Identity component on that game object if it does not already have one.
|
||||
|
||||
Scene objects with a Network Scene Checker component are disabled when they're not in the same scene, and spawned objects are destroyed when they're not in the same scene.
|
||||
|
||||
## Use with Additive Scenes
|
||||
|
||||
In Mirror, the Server and connected Clients are always on the same main scene, however the server and clients can have various combinations of smaller subscenes loaded additively. The server may load all subscenes at start, or it may dynamically load and unload subscenes where players or other activity is going on as needed.
|
||||
|
||||
All player objects are always first spawned in the main scene, which may or may not have visual content, networked objects, etc. With this component attached to all networked objects, whenever the player object is moved to a subscene (from the main or from another subscene), the observers lists for objects in both the new scene and the prior scene are updated accordingly.
|
||||
|
||||
Loading the subscene(s) on the server is through the normal process with `SceneManager`:
|
||||
|
||||
```cs
|
||||
SceneManager.LoadSceneAsync(subScene, LoadSceneMode.Additive);
|
||||
```
|
||||
|
||||
Next, you will send a `SceneMessage` to the client telling it to load a subscene additively:
|
||||
|
||||
```cs
|
||||
SceneMessage msg = new SceneMessage
|
||||
{
|
||||
sceneName = subScene,
|
||||
sceneOperation = SceneOperation.LoadAdditive
|
||||
};
|
||||
|
||||
connectionToClient.Send(msg);
|
||||
```
|
||||
|
||||
Then, on the server only, you just move the player object to the subscene:
|
||||
|
||||
```cs
|
||||
// Position the player object in world space first
|
||||
// This assumes it has a NetworkTransform component that will update clients
|
||||
player.transform.position = new Vector3(100, 1, 100);
|
||||
|
||||
// Then move the player object to the subscene
|
||||
SceneManager.MoveGameObjectToScene(player, subScene);
|
||||
```
|
||||
|
||||
Optionally you can send another `SceneMessage` to the client with `SceneOperation.UnloadAdditive` to remove any previous additive scene the client no longer needs. This would apply to a game that has levels after a level change. A short delay may be necessary before removal to allow the client to get fully synced.
|
||||
|
||||
Depending on the complexity of your game, you may find it helpful when switching a player between subscenes to move the player object to the main scene first, yield 100 ms, re-position it, and finally move it to the new subscene.
|
Before Width: | Height: | Size: 5.7 KiB |
Before Width: | Height: | Size: 50 KiB |
@ -1,11 +0,0 @@
|
||||
# Network Start Position
|
||||
|
||||
To control where players are spawned, you can use the Network Start Position component.
|
||||
|
||||
To use these, attach a Network Start Position component to a game object in the scene, and position the game object where you would like one of the players to start. You can add as many start positions to your Scene as you like. The Network Manager detects all start positions in your Scene, and when it spawns each player instance, it uses the position and orientation of one of them.
|
||||
|
||||
The Network Manager will spawn players at (0, 0, 0) by default. Adding this component to a game object will automatically register/unregister its game object's transform to the Network Manager as an available spawning position.
|
||||
|
||||
Depending on the Network Manager Player Spawn Method setting the spawning is either Random (possible that the same spawn position will be used by two or more players) or Round Robin (use every available position, until there are more clients than spawn points).
|
||||
|
||||
![Inspector](NetworkStartPosition.PNG)
|
@ -1,15 +0,0 @@
|
||||
# Network Transform
|
||||
|
||||
The Network Transform component synchronizes the position, rotation, and scale of networked game objects across the network.
|
||||
|
||||
A game object with a Network Transform component must also have a Network Identity component. When you add a Network Transform component to a game object, Mirror also adds a Network Identity component on that game object if it does not already have one.
|
||||
|
||||
![The Network Transform component](NetworkTransform.png)
|
||||
|
||||
By default, Network Transform is server-authoritative unless you check the box for **Client Authority**. Client Authority applies to player objects as well as non-player objects that have been specifically assigned to a client, but only for this component. With this enabled, position changes are send from the client to the server.
|
||||
|
||||
Under **Sensitivity**, you can set the minimum thresholds of change to the transform values in order for network messages to be generated. This helps minimize network "noise" for minor twitch and jitter.
|
||||
|
||||
Normally, changes are sent to all observers of the object this component is on. Setting **Sync Mode** to Owner Only makes the changes private between the server and the client owner of the object.
|
||||
|
||||
You can use the **Sync Interval** to specify how often it syncs (in seconds).
|
Before Width: | Height: | Size: 45 KiB |
@ -1,11 +0,0 @@
|
||||
# Network Transform Child
|
||||
|
||||
The Network Transform Child component synchronizes the position and rotation of the child game object of a game object with a Network Transform component. You should use this component in situations where you need to synchronize an independently-moving child object of a Networked game object.
|
||||
|
||||
To use the Network Transform Child component, attach it to the same parent game object as the Network Transform, and use the Target field to define which child game object to apply the component settings to. You can have multiple Network Transform Child components on one parent game object .
|
||||
|
||||
![The Network Transform Child component](NetworkTransform.png)
|
||||
|
||||
You can modify **Compress Rotation** to save some bandwidth when synchronizing the rotation. You can use the **Network Sync Interval** to specify how often it syncs (in seconds).
|
||||
|
||||
This component takes authority into account, so local player game objects (which have local authority) synchronize their position from the client to server, then out to other clients. Other game objects (with server authority) synchronize their position from the server to clients.
|
@ -1,40 +0,0 @@
|
||||
# Components Overview
|
||||
|
||||
These core components are included in Mirror:
|
||||
|
||||
- [Network Animator](NetworkAnimator.md)
|
||||
The Network Animator component allows you to synchronize animation states for networked objects. It synchronizes state and parameters from an Animator Controller.
|
||||
- [Network Authenticator](Authenticators/index.md)
|
||||
Network Authenticators facilitate integration of user accounts and credentials into your application.
|
||||
- [Network Discovery](NetworkDiscovery.md)
|
||||
Network Discovery uses a UDP broadcast on the LAN enabling clients to find the running server and connect to it.
|
||||
- [Network Identity](NetworkIdentity.md)
|
||||
The Network Identity component is at the heart of the Mirror networking high-level API. It controls a game object’s unique identity on the network, and it uses that identity to make the networking system aware of the game object. It offers two different options for configuration and they are mutually exclusive, which means either one of the options or none can be checked.
|
||||
- [Network Headless Logger](NetworkHeadlessLogger.md)
|
||||
Network Headless Logger adds color to log when running in headless mode
|
||||
- [Network Log Settings](NetworkLogSettings.md)
|
||||
The Network Log Settings component allows you to configure logging levels and load the settings in a build.
|
||||
- [Network Manager](NetworkManager.md)
|
||||
The Network Manager is a component for managing the networking aspects of a multiplayer game.
|
||||
- [Network Manager HUD](NetworkManagerHUD.md)
|
||||
The Network Manager HUD is a quick-start tool to help you start building your multiplayer game straight away, without first having to build a user interface for game creation/connection/joining. It allows you to jump straight into your gameplay programming, and means you can build your own version of these controls later in your development schedule.
|
||||
- [Network Match Checker](NetworkMatchChecker.md)
|
||||
The Network Match Checker component controls visibility of networked objects based on match id.
|
||||
- [Network Ping Display](NetworkPingDisplay.md)
|
||||
Network Ping Display shows the Ping time for clients using OnGUI
|
||||
- [Network Proximity Checker](NetworkProximityChecker.md)
|
||||
The Network Proximity Checker component controls the visibility of game objects for network clients, based on proximity to players.
|
||||
- [Network Rigidbody](NetworkRigidbody.md)
|
||||
The Network Rigidbody synchronizes velocity and other properties of a rigidbody across the network.
|
||||
- [Network Room Manager](NetworkRoomManager.md)
|
||||
The Network Room Manager is an extension component of Network Manager that provides a basic functional room.
|
||||
- [Network Room Player](NetworkRoomPlayer.md)
|
||||
The Network Room Player is a component that's required on Player prefabs used in the Room Scene with the Network Room Manager above.
|
||||
- [Network Scene Checker](NetworkSceneChecker.md)
|
||||
The Network Scene Checker component controls visibility of networked objects between scenes.
|
||||
- [Network Start Position](NetworkStartPosition.md)
|
||||
Network Start Position is used by the Network Manager when creating player objects. The position and rotation of the Network Start Position are used to place the newly created player object.
|
||||
- [Network Transform](NetworkTransform.md)
|
||||
The Network Transform component synchronizes the movement and rotation of game objects across the network. Note that the network Transform component only synchronizes spawned networked game objects.
|
||||
- [Network Transform Child](NetworkTransformChild.md)
|
||||
The Network Transform Child component synchronizes the position and rotation of the child game object of a game object with a Network Transform component.
|
@ -1,39 +0,0 @@
|
||||
- name: Overview
|
||||
href: index.md
|
||||
- name: Network Animator
|
||||
href: NetworkAnimator.md
|
||||
- name: Network Authenticators
|
||||
href: Authenticators/toc.yml
|
||||
topicHref: Authenticators/index.md
|
||||
- name: Network Discovery
|
||||
href: NetworkDiscovery.md
|
||||
- name: Network Identity
|
||||
href: NetworkIdentity.md
|
||||
- name: Network Headless Logger
|
||||
href: NetworkHeadlessLogger.md
|
||||
- name: Network Log Settings
|
||||
href: NetworkLogSettings.md
|
||||
- name: Network Manager
|
||||
href: NetworkManager.md
|
||||
- name: Network Manager HUD
|
||||
href: NetworkManagerHUD.md
|
||||
- name: Network Match Checker
|
||||
href: NetworkMatchChecker.md
|
||||
- name: Network Ping Display
|
||||
href: NetworkPingDisplay.md
|
||||
- name: Network Proximity Checker
|
||||
href: NetworkProximityChecker.md
|
||||
- name: Network Rigidbody
|
||||
href: NetworkRigidbody.md
|
||||
- name: Network Room Manager
|
||||
href: NetworkRoomManager.md
|
||||
- name: Network Room Player
|
||||
href: NetworkRoomPlayer.md
|
||||
- name: Network Scene Checker
|
||||
href: NetworkSceneChecker.md
|
||||
- name: Network StartPosition
|
||||
href: NetworkStartPosition.md
|
||||
- name: Network Transform
|
||||
href: NetworkTransform.md
|
||||
- name: Network Transform Child
|
||||
href: NetworkTransformChild.md
|
@ -1,24 +0,0 @@
|
||||
# Additive Scenes Example
|
||||
|
||||
IMPORTANT: Make sure you have a layer in project settings called Player for this example to work well.
|
||||
|
||||
In Build Settings, remove all scenes and add all of the scenes from the Scenes folder in the following order:
|
||||
- MainScene
|
||||
- SubScene
|
||||
|
||||
Open the MainScene in the Editor and make sure the Sub Scenes list in the Network Manager component on the Network scene object contains the SubScene scene. This is already setup by default, but if the MainScene was opened and saved before putting the scenes in the Build Settings list, the Sub Scenes list may be cleared accidentally.
|
||||
|
||||
File -> Build and Run
|
||||
|
||||
Start up to 3 built instances: These will all be client players.
|
||||
|
||||
Press Play in the Editor and click Host (Server + Client) in the HUD
|
||||
- This will be the host and the 1st player of up to 4. You can also use Server Only if you prefer.
|
||||
|
||||
Click Client in the built instances.
|
||||
- WASDQE keys to move & turn your player capsule.
|
||||
- There are objects in the corners of the scene hidden by Proximity Checkers.
|
||||
- The big area in the middle is where the subscene will be loaded when you get near the shelter.
|
||||
- There are also networked objects inside the subscene, also with Proximity Checkers.
|
||||
- Since subscenes are only loaded for individual clients, other clients that are outside the middle Zone won't see what those in the subscene can see.
|
||||
- If you play a built instance as Host or Server and play as client in the editor, you'll see the subscene content load and unload in the hierarchy as you move in and out of the middle Zone.
|
Before Width: | Height: | Size: 14 KiB |
Before Width: | Height: | Size: 52 KiB |
@ -1,7 +0,0 @@
|
||||
# Basic
|
||||
|
||||
General description of Basic example.
|
||||
|
||||
![Basic Example](Basic.PNG)
|
||||
|
||||
![Basic Player](BasicPlayer.PNG)
|
Before Width: | Height: | Size: 40 KiB |
@ -1,36 +0,0 @@
|
||||
# Multiple Additive Scenes Example
|
||||
|
||||
In Build Settings, remove all scenes and add both of the scenes from the Scenes folder in the following order:
|
||||
|
||||
- Main
|
||||
- Game
|
||||
|
||||
Open the Main scene in the Editor and make sure the Game Scene field in the MultiScene Network Manager on the Network scene object contains the Game scene. This is already setup by default, but if the Main scene was opened and saved before putting the scenes in the Build Settings list, the Game Scene field may be cleared accidentally.
|
||||
|
||||
## MultiScene Network Manager
|
||||
|
||||
The MultiScene Network Manager is derived from the base Network Manager and is responsible for additively loading the subscene instances and placing the players in their respective subscene instances and initializing player SyncVars. It has a Game Scene field where the Game subscene is assigned, and an Instances field to set how many instances are loaded on the server.
|
||||
|
||||
In this example, the subscene instances are additively loaded on the server with `localPhysicsMode = LocalPhysicsMode.Physics3D`. Physics subscenes do not auto-simulate, so each scene has a game object with a generic `PhysicsSimulator` script on it. This script does nothing on the client, only on the server.
|
||||
|
||||
Clients only ever have one instance of the subscene additively loaded (without `localPhysicsMode`), while server has them all. All networked objects have a `NetworkSceneChecker` component which is what isolates them to their specific subscene.
|
||||
|
||||
## Playing in the Instances
|
||||
|
||||
File -\> Build and Run
|
||||
|
||||
Start at least 3 built instances: These will all be client players.
|
||||
|
||||
Press Play in the Editor and click Host (Server + Client) in the HUD - This will be the host and the 1st player. You can also use Server Only if you prefer.
|
||||
|
||||
Click Client in the built instances.
|
||||
|
||||
- WASDQE keys to move & turn your player capsule, Space to jump.
|
||||
|
||||
- Colliding with the small colored spheres scores points base on their color.
|
||||
|
||||
- Colliding with the larger tumblers sends them rolling around...they're server-side non-kinematic rigidbodies.
|
||||
|
||||
- Only scores for the players in the same subscene are shown at the top of the game window.
|
||||
|
||||
![MultiScene Network Manager](MultiSceneNetworkManager.PNG)
|
Before Width: | Height: | Size: 16 KiB |
Before Width: | Height: | Size: 229 KiB |
Before Width: | Height: | Size: 162 KiB |
Before Width: | Height: | Size: 9.7 KiB |
@ -1,59 +0,0 @@
|
||||
# Pong
|
||||
|
||||
A simple example for "How to built a multiplayer game with Mirror" is Pong,
|
||||
which is included in the AssetStore package of Mirror. It illustrates the usage
|
||||
of NetworkManager, NetworkManagerHUD, NetworkBehaviour, NetworkIdentity,
|
||||
NetworkTransform, NetworkStartPosition and NetworkingAttributes.
|
||||
|
||||
![Pong](Pong1.jpg)
|
||||
|
||||
## Setting the number of players
|
||||
|
||||
First of all, let's have a look at the NetworkManager object in the main scene.
|
||||
When adding the NetworkManager component to a gameobject, a few default settings
|
||||
are already set (**Don't destroy on Load**, **Run in Background**, ...) For
|
||||
playing Pong the maximum number of players is 2, so the setting **Network
|
||||
Info/Max connections** will also be 2. As there are no other scenes (room,
|
||||
online or offline scene) in this sample the properties for **Offline Scene** and
|
||||
**Online Scene** will stay empty.
|
||||
|
||||
## Creating the player
|
||||
|
||||
Furthermore every player needs a racket to play with. Each player who joins the
|
||||
game will have his own controllable object, which represents him within the
|
||||
game. This gameobject is called *PlayerObject*. For spawning the *PlayerObject*
|
||||
a prefab has to be created, containing at least a NetworkIdentity component with
|
||||
**Local Player Authority** checked. The **Local Player Authority** allows the
|
||||
player to control and modify the gameobjects properties (e.g. for movement). The
|
||||
NetworkManager needs a reference to this prefab, which is located in **Spawn
|
||||
Info/Player Prefab**. To have the player movement synchronized over the network,
|
||||
the player prefab also contains a NetworkTransform.
|
||||
|
||||
![NetworkManagerSettings](Pong2.jpg)
|
||||
|
||||
## Player start position
|
||||
|
||||
The main scene contains 2 gameobjects with only a NetworkStartPosition component
|
||||
(gameobjects RacketSpawnLeft, RacketSpawnRight in the scene). These transforms
|
||||
will be automatically registered by the NetworkManager as spawning positions.
|
||||
|
||||
![NetworkStartPositions](Pong3.jpg)
|
||||
|
||||
## Setting up the network
|
||||
|
||||
A very convenient component for establish/testing connections is the
|
||||
NetworkManagerHUD. It provides basic functionality for start a game as
|
||||
Client, Server, or Host (Client and Server at the same time). It
|
||||
requires the NetworkManager component.
|
||||
|
||||
![NetworkManagerHUD](Pong4.jpg)
|
||||
|
||||
## The ball of Pong
|
||||
|
||||
The ball is the main focus of Pong, as this is the object needed to score
|
||||
points. Its NetworkIdentity component has neither **Server Only** nor **Local
|
||||
Player Authority** checked, as it's moved by the server physics engine and can
|
||||
be influenced by the players. As with the *PlayerObject* the position is
|
||||
synchronized via NetworkTransform. When having multiple scenes, the ball can be
|
||||
spawned by the NetworkManager, but to keep this sample simple, it's placed
|
||||
directly within the main scene.
|
Before Width: | Height: | Size: 32 KiB |
Before Width: | Height: | Size: 8.7 KiB |
Before Width: | Height: | Size: 49 KiB |
Before Width: | Height: | Size: 29 KiB |
@ -1,17 +0,0 @@
|
||||
# Room
|
||||
|
||||
General description of Room example.
|
||||
|
||||
![Host's Room View](Room1.PNG)
|
||||
|
||||
|
||||
|
||||
![Player's Room View](Room2.PNG)
|
||||
|
||||
|
||||
|
||||
![Network Room Manager](RoomManager.PNG)
|
||||
|
||||
|
||||
|
||||
![Network Room Player](RoomPlayer.PNG)
|
@ -1,3 +0,0 @@
|
||||
# Tanks
|
||||
|
||||
General description of Tanks example.
|
@ -1,15 +0,0 @@
|
||||
# Samples Overview
|
||||
|
||||
Mirror includes several small examples to help you learn how to use various features and how to set things up so they work together.
|
||||
- [Basic](Basic/index.md)
|
||||
Basic is what it sounds like...the most rudimentary baseline of a networked game. Features SyncVars updating random UI data for each player.
|
||||
- [Tanks](Tanks/index.md)
|
||||
This is a simple scene with animated tanks, networked rigidbody projectiles, and NavMesh movement
|
||||
- [Pong](Pong/index.md)
|
||||
A simple example for "How to build a multiplayer game with Mirror" is Pong. It illustrates the usage of `NetworkManager`, `NetworkManagerHUD`, NetworkBehaviour, NetworkIdentity, `NetworkTransform`, `NetworkStartPosition`and various Attributes.
|
||||
- [Additive Scenes](AdditiveScenes/index.md)
|
||||
The Additive Scenes example demonstrates a server additively loading a sub-scene into a main scene at startup, and having a server-only trigger that generates a message to any client whose player enters the trigger zone to also load the sub-scene, and subsequently unload it when they leave the trigger zone. Only players inside the trigger zone can see the objects in the sub-scene. Network Proximity Checker components are key to making this scenario work.
|
||||
- [Multiple Concurrent Additive Scenes](MultipleAdditiveScenes/index.md)
|
||||
The Multiple Concurrent Additive Scenes example demonstrates a server additively loading multiple instances of a sub-scene into a main scene at startup, with physics separation, and assigning players to the instances to play matches independently. [NetworkSceneChecker](../Components/NetworkSceneChecker.md) is the key component that makes this example work.
|
||||
- [Room System](Room/index.md)
|
||||
The Room System example demonstrates how to set up a "staging" scene where players assemble before starting a match. When all players are ready, the server sends them all a message to change scenes (along with the server itself) to the actual game play scene so they all come in at once. Includes fully playable game with a character controller where players collect server-spawned prizes for score.
|
@ -1,14 +0,0 @@
|
||||
- name: Overview
|
||||
href: index.md
|
||||
- name: Basic
|
||||
href: Basic/index.md
|
||||
- name: Tanks
|
||||
href: Tanks/index.md
|
||||
- name: Pong
|
||||
href: Pong/index.md
|
||||
- name: Additive Scenes
|
||||
href: AdditiveScenes/index.md
|
||||
- name: Multiple Additive Scenes
|
||||
href: MultipleAdditiveScenes/index.md
|
||||
- name: Room
|
||||
href: Room/index.md
|
@ -1,405 +0,0 @@
|
||||
# Change Log
|
||||
|
||||
**Mirror is published to the [Asset Store](https://assetstore.unity.com/packages/tools/network/mirror-129321) at the start of every month, unless some critical issue causes a delay.**
|
||||
|
||||
Mirror uses semantic versioning, and the versions shown here are those that were published to the Asset Store, and occasionally major version bumps happen mid-month between store submissions and are therefore not individually shown here.
|
||||
|
||||
## Version 17.3.0 -- 2020-Sep-04
|
||||
- Added: NetworkAnimator now syncs Layer Weight
|
||||
- Added: Lists can now be sent in Command/Rpc/Message/etc
|
||||
- Added: `[Server]`/`[Client]` can now be used outside of NetworkBehaviour
|
||||
- Added: Experimental [NetworkLerpRigidbody](../Components/NetworkLerpRigidbody.md) component that syncs position and velocity and applies them using Lerp.
|
||||
- Fixed: NetworkAnimator now fires triggers immediately on owner
|
||||
- Fixed: `isServer` will now keep its value after calling `NetworkServer.Destroy`
|
||||
- Fixed: `[Client]` error message now correctly logs the name of the method
|
||||
- Fixed: Messages can now be nested within other Message types
|
||||
- Fixed: `[Server]`/`[Client]` now correctly give error when used on abstract method
|
||||
- Fixed: Abstract classes can now implement IMessageBase
|
||||
- Fixed: Weaver now correctly gives error when generating a reader methods for abstract classes
|
||||
- Changed: NetworkServer no longer runs update if there are no connections
|
||||
- Changed: NetworkBehaviour.IsDirty is now a public
|
||||
- Changed: SyncEvent are now Obsolete and will be removed in the next version
|
||||
- Removed: isHeadless is now Obsolete, Use preprocessor directive `#if UNITY_SERVER` instead
|
||||
|
||||
|
||||
## Version 16.9.0 -- 2020-Aug-01
|
||||
|
||||
- Added: [NetworkHeadlessLogger](../Components/NetworkHeadlessLogger.md) log handler that sets console color
|
||||
- Added: New Mirror List Server, see [Cloud folder](https://github.com/vis2k/Mirror/tree/master/Assets/Mirror/Cloud)
|
||||
- Added: Experimental [NetworkRigidbody](../Components/NetworkRigidbody.md) component that syncs velocity and other rigidbody settings
|
||||
- Fixed: base method called inside Command/RPC now work if the first base class does not have an override
|
||||
- Fixed: NetworkRoomPlayer now cleans up roomSlots on disable
|
||||
- Fixed: Fallback and Multiplex now disable their transports when they are disabled
|
||||
- Fixed: Websockets transport SocketState now returns false if socket is `undefined`
|
||||
- Fixed: SyncEvents can now have the same name if they are in different classes
|
||||
- Fixed: You can now have multiple SyncEvents per class
|
||||
- Fixed: Message base classes are now processed even if they are declared later in the file
|
||||
- Fixed: Registering a prefab with and same GUID no longer gives an error
|
||||
- Fixed: Weaver now generates Serialize methods for classes that implement IMessageBase
|
||||
- Changed: NetworkProximityChecker now has slightly better performance
|
||||
- Changed: ClientRpc no longer need Rpc prefix
|
||||
- Changed: Commands no longer need Cmd prefix
|
||||
- Changed: TargetRpc no longer need Target prefix
|
||||
- Changed: NetworkManager.networkSceneName is now protected set as it should not be set directly
|
||||
|
||||
## Version 16.1.1 -- 2020-Jun-13
|
||||
- Added: [Command] now has an `ignoreAuthority` option for invoking Commands on objects the client doesn't have authority over, and Command methods can have an optional `NetworkConnectionToClient sender` parameter.
|
||||
- Added: [ClientRpc] now has an `excludeOwner` option to prevent messages from going to the client that owns the object.
|
||||
- Added: Commands and Rpc's can now be declared as virtual and overridden in derived classes.
|
||||
- Added: [NetworkLogSettings](../Components/NetworkLogSettings.md) component and Log Settings Window.
|
||||
- Added: SyncLists now support `AddRange`, `InsertRange`, and `RemoveAll`.
|
||||
- Added: Network Room Manager now has a virtual `OnRoomServerPlayersNotReady` that fires on server from `CheckReadyToBegin`.
|
||||
- Added: Network Room Player template now includes base Network Behaviour overrides.
|
||||
- Added: Network Room Player now has a virtual hook for the index SyncVar, and the override is in the template.
|
||||
- Added: Experimental Network Transform with more control settings and features.
|
||||
- Fixed: Network Room Manager.minPlayers is now protected so it's available for derived classes.
|
||||
- Fixed: Network Room Manager no longer does redundant player prefab registration in `OnStartClient`.
|
||||
- Fixed: Network Room Player `OnClientEnterRoom` now correctly only fires on clients.
|
||||
- Fixed: `RegisterClientMessages` was being incorrectly invoked for every scene change.
|
||||
- Fixed: Network Behaviour `SyncMode` and `SyncInterval` was not showing in the inspector in some cases (regression).
|
||||
- Fixed: Network Manager now cleans up network objects better when server stops.
|
||||
- Fixed: Network Manager no longer tries to change to offline scene redundantly in `StopClient`.
|
||||
- Fixed: Network Connection's `lastMessageTime` wasn't being properly initialized, causing incorrect idle timeout disconnects.
|
||||
- Fixed: Websockets transport now correctly pauses and queues messages during scene changes and should otherwise be more stable with SSL
|
||||
- Changed: **Breaking** Websockets Transport now requires full path to PFX Certificate file.
|
||||
- Changed: Improvements were made to the Tanks example.
|
||||
- Changed: Network Room Player now uses virtual SyncVar hook for ReadyStateChanged.
|
||||
- Changed: Network Proximity Checker now uses direct distance check against player objects instead of Physics.SphereCastNonAlloc for better performance.
|
||||
- Removed: Discord Transport
|
||||
|
||||
## Version 13.0.1 -- 2020-May-06
|
||||
- Added: [Multiple Concurrent Additive Scenes Example](../Examples/MultipleAdditiveScenes/index.md).
|
||||
- Added: [Network Match Checker](../Components/NetworkMatchChecker.md) component. Use this component to create many concurrent isolated matches within a single game server.
|
||||
- Added: [SyncLists](../Guides/Sync/SyncLists.md) now have Find and FindAll functions.
|
||||
- Added: Network Behaviour now has OnStopServer and OnStopClient virtual methods.
|
||||
- Added: Weaver now supports custom Reader & Writer for types in other assemblies.
|
||||
- Added: Network Manager now has an optional setting to check for and disconnect remote connections that have gone silent for a specified interval.
|
||||
- Added: Network Manager now has a ReplaceHandler method to avoid warnings when attempting to double register message handlers.
|
||||
- Added: `NetworkServer.SendToAll` now has an optional bool to only send to ready clients, and a `SendToReady` method that doesn't require a Network Identity.
|
||||
- Fixed: Network Animator no longer double-fires SetTrigger / ResetTrigger on the host client.
|
||||
- Fixed: Network Animator is no longer limited to one component per object.
|
||||
- Fixed: Destroy is no longer invoked twice on the server for the player object.
|
||||
- Fixed: `RegisterClientMessages` is no longer invoked twice on the client.
|
||||
- Fixed: Network Behaviour `SyncMode` and `SyncInterval` was not showing in the inspector in some cases.
|
||||
- Fixed: Telepathy Transport - `LateUpdate` now processes a limited amount of messages per tick to avoid deadlocks.
|
||||
- Changed: Network Behaviour: `OnNetworkDestroy` was renamed to `OnStopClient`.
|
||||
- Changed: **Breaking** RemovePlayerMessage has been removed as a potential security risk. Use `NetworkServer.RemovePlayerForConnection` instead.
|
||||
- Changed: **Breaking** Network Behaviour: `OnRebuildObservers`, `OnCheckObserver`, and `OnSetHostVisibility` were moved to a separate class called `NetworkVisibility`.
|
||||
|
||||
## Version 11.4.2 - 2020-Apr-03
|
||||
- Added: SyncVar hooks can be virtual now, and overriden in a derived class.
|
||||
- Added: Virtual `OnRoomStopServer` added to Network Room Manager and Script Template.
|
||||
- Added: 10K Networked Objects Benchmark Example.
|
||||
- Fixed: Setting breakpoints in an IDE for Command's and Rpc's work correctly now.
|
||||
- Fixed: `NetworkServer.SendToObservers` now reports correct channel to Mirror Profiler.
|
||||
- Fixed: Network Room Manager's `roomPlayerPrefab` is now `protected` so it can be accessed in derived classes.
|
||||
- Fixed: Network Room Player inspector and documentation updated to be less confusing.
|
||||
- Fixed: Network Identity no longer double calls `NetworkServer.Destroy`.
|
||||
- Fixed: Network Animator now correctly excludes parameters controlled by curves.
|
||||
- Fixed: Network Behaviour now uses a property drawer for the SyncVar label so it displays better.
|
||||
- Fixed: `NetworkServer.SendToReady` overloads are no longer ambiguous.
|
||||
- Fixed: Network Room Manager no longer incorrectly destroys the game player object. It's left in the game scene to be cleaned up by Unity when the scene changes.
|
||||
- Fixed: `StopHost` correctly raises `OnServerDisconnect` in Network Manager, and correctly unwinds before shutting down the server.
|
||||
- Fixed: `isServer` is no longer incorrectly false on server in Network Identity's `OnDestroy`.
|
||||
- Changed: Network Manager `offlineScene` and `onlineScene` store full paths now, so use SceneManager.GetActiveScene().path instead.
|
||||
- Changed: Network Manager HUD now calls `StopHost` / `StopServer` / `StopClient` more appropriately.
|
||||
- Changed: Network Manager HUD labels no longer say LAN. Associated docs also cleaned up to eliminate the misconception of Mirror being LAN only solution.
|
||||
- Changed: Network Transform compression removed and message handling is much simpler now.
|
||||
- Changed: Network Scene Checker initializes in Awake again because `OnEnable` proved to be unreliable in some cases.
|
||||
- Changed: Network Manager will no longer lose references to scenes if they aren't in the Build Settings scene list, however moving or renaming scenes may cause references to be lost.
|
||||
- Changed: **Breaking** Many obsolete methods and properties removed. Use [version 10](https://github.com/vis2k/Mirror/releases/tag/v10.4.7) first if upgrading from UNet or older Mirror. See [Deprecations](Deprecations.md) for complete list.
|
||||
|
||||
## Version 10.4.7 - 2020-Mar-03
|
||||
- Added: Weaver will now block play mode and builds if there are weaver errors and show them in the console again.
|
||||
- Added: `PooledNetworkReader` and `PooledNetworkWriter`, both Disposable.
|
||||
- Added: `NetworkReader.ReadMessage<T>`.
|
||||
- Added: Network Discovery now handles headless server mode.
|
||||
- Added: SyncVar, Cmd's and Rpc's now support Scriptable Objects via CreateInstance on the receiving side.
|
||||
- Added: Discord Transport *Removed in v16.1.1*
|
||||
- Fixed: `isClient` now returns true on clients in OnDestroy for networked objects.
|
||||
- Fixed: Host Player race condition for Ready message.
|
||||
- Fixed: Network Animator and Network Transform now correctly check for client authority in their respective Command methods.
|
||||
- Fixed: Network Room Manager Script Template had a virtual method instead of an override.
|
||||
- Fixed: Network Server's calls to NetworkConnectionToClient.Send now includes the channelId parameter that was missing.
|
||||
- Fixed: Network Server's calls to SendToAll, SendToReady, and SendToObservers send to the exact connection if it is detected as local connection, instead of falling back to the .localConnection.
|
||||
- Fixed: Network Server.SpawnObjects returns false if server isn't running.
|
||||
- Fixed: Network Transform rotation detection improved.
|
||||
- Fixed: Weaver generated code now builds properly for IL2CPP (again).
|
||||
- Changed: StartHost in Network Manager is no longer a virtual method (and shoudn't have been). Override OnStartHost instead.
|
||||
- Changed: Network Room Manager's OnRoomServerSceneLoadedForPlayer now includes NetworkConnection parameter.
|
||||
- Changed: Network Scene Checker now works from OnEnable instead of Awake, and uses Scene instead of scene name.
|
||||
- Changed: Renamed NeworkWriter.Write to WriteMessage for consistency.
|
||||
|
||||
## Version 9.0.2 - 2020-Feb-04
|
||||
- Added: Network Animator now has a ResetTrigger function and server / client authority warnings.
|
||||
- Added: Network Transform now has 3 new floats for Sensitivity to quiet down message traffic from micro changes.
|
||||
- Added: Network Observer added to [Script Templates](ScriptTemplates.md) -- See the new Mirror section in the Assets > Create menu.
|
||||
- Added: [Network Discovery](../Components/NetworkDiscovery.md) has been reimplemented including an example and script template -- thanks to all those who contributed!
|
||||
- Added: [Network Scene Checker Component](../Components/NetworkSceneChecker.md).
|
||||
- Added: Mirror Icon for all components.
|
||||
- Added: Inspector Headers to Network Behaviour, Network Transform, and Network Animator.
|
||||
- Added: URI added to supported data types.
|
||||
- Added: `NetworkReaderPool` has been implemented in place of `new NetworkReader` everywhere, significantly reducing garbage allocation.
|
||||
- Fixed: Network Transform and Network Animator now uses NetworkWriterPool.
|
||||
- Fixed: Network Transform and Network Animator now respect `hasAuthority` for client owned objects.
|
||||
- Fixed: Network Transform will now correctly teleport if time / distance are too large.
|
||||
- Fixed: Network Animator now correctly syncs when clientAuthority is false.
|
||||
- Fixed: Client owned objects are now destroyed when client disconnects (regression).
|
||||
- Fixed: Client authority is now preserved for networked objects carried through scene change in DontDestroyOnLoad (DDOL).
|
||||
- Fixed: Starting server immediately after cancelling client connection attempt no longer throws a NRE.
|
||||
- Fixed: IL2CPP builds no longer trigger an assert when stopping server.
|
||||
- Fixed: SyncVars are now set for Host player before hook is invoked.
|
||||
- Fixed: SyncDictionary now correctly updates the value before invoking callbacks.
|
||||
- Fixed: StopHost no longer tries to change to the Offline scene twice.
|
||||
- Fixed: Network Room Manager roomSlots are now correctly managed on both server and clients.
|
||||
- Fixed: Network Room Manager now correctly supports multiple GamePlay scenes and adds a virtual `OnRoomServerAddPlayer`.
|
||||
- Fixed: Additive scene operations no longer incorrectly lead to extraneous AddPlayer messages from clients.
|
||||
- Fixed: `NetworkWriterPool` is now used everywhere instead of `new NetworkWriter` (we missed a couple when the pool was implemented).
|
||||
- Fixed: Patch for Unity 2019.3.x `RequestScriptReload` was moved to EditorUtility from UnityEditorInternal.InternalEditorUtility.
|
||||
- Fixed: Arrays of custom types are now correctly supported.
|
||||
- Changed: Shutdown logic has been streamlined.
|
||||
- Changed: `NetworkIdentity.GetSceneIdenity` method renamed to `GetSceneIdentity` (name typo).
|
||||
- Changed: OnApplicationQuit virtual method added to Transport class and `Transport.activeTransport.Shutdown()` is no longer called from Network Manager.
|
||||
- Changed: **Breaking** SyncVar Hooks now require **two** parameters, one each for the old and new value, and the property value is now set **before** the hook is called.
|
||||
|
||||
## Version 6.7.7 - 2020-Jan-01
|
||||
- Added: [Script Templates](ScriptTemplates.md) -- See the new Mirror section in the Assets > Create menu.
|
||||
- Added: Full Text Search added to docs.
|
||||
- Added: Basic Chat example.
|
||||
- Added: Some youtube videos have been created and linked from various doc pages where appropriate.
|
||||
- Added: Transports can now support using a URI for connection including port.
|
||||
- Added: version.txt file is now included with the release version in it.
|
||||
- Added: Structs that inherit from IMessageBase now generate serializers.
|
||||
- Fixed: Components now appear in docs under API Reference.
|
||||
- Fixed: Delayed disconnect in Basic Authenticator.
|
||||
- Fixed: Multiplexer now handles OnClientConnect and GetMaxMessageSize correctly.
|
||||
- Fixed: Network Room Manager OnRoomServerCreateGamePlayer now includes the Room Player Object as parameter.
|
||||
- Changed: Room example now has Network Room Manager in the Offline scene and correctly switches to the Room scene when server / client is started.
|
||||
- Changed: Network Manager startPositionIndex and loadingSceneAsync are now public.
|
||||
- Changed: SceneMessage now has an optional customHandling flag so devs can handle their own custom scene loading, e.g. using Addressables.
|
||||
- Changed: **Breaking** Network Transform now defaults to server authority and has a Client Authority checkbox.
|
||||
|
||||
## Version 6.3.0 - 2019-Dec-09
|
||||
- Added: SyncMode selector now works for components on any scene objects owned by a client in addition to the player object, e.g. pets.
|
||||
- Added: MessageBase now fully supports inheritance.
|
||||
- Added: Room example now has UI button for host to return all clients to the Room scene and other improvements.
|
||||
- Fixed: ReplacePlayerForConnection now works for existing scene objects as long as another player doesn't own the targetted object.
|
||||
- Fixed: isClient and isServer are now true for networked objects in Start and OnStartClient / OnStartServer, respectively.
|
||||
- Fixed: hasAuthority is now set before OnStartClient and OnStartLocalPlayer are invoked.
|
||||
- Changed: connectionToClient is now used to assign client authority.
|
||||
- Changed: In many respects, the Host player acts a lot more like a client and will reveal bugs better.
|
||||
- Changed: ReplacePlayerForConnection now has an optional bool to retain authority of the previous object (default = false).
|
||||
- Removed: `NetworkServer.SpawnWithClientAuthority` is deprecated in favor of overloads of `NetworkServer.Spawn`.
|
||||
|
||||
## Version 5.0.2 - 2019-Nov-03
|
||||
- Added: SyncList and SyncSet custom Equality Comparer support.
|
||||
- Added: Custom serializers may be implemented for any type in Cmd's and Rpc's.
|
||||
- Added: [Fallback Transport](../Transports/Fallback.md).
|
||||
- Fixed: SyncVar hooks are no longer called in Host if no change.
|
||||
- Fixed: Network Identity no longer throws a null reference exception in RemoveClientAuthority.
|
||||
- Fixed: Server transport now suspended during scene change to prevent erroneous messages.
|
||||
- Fixed: SyncList, SyncDictionary and SyncSet now use a custom IEnumerator to avoid memory allocation.
|
||||
- Fixed: sceneID is no longer reset in certain cases when editing a prefab.
|
||||
- Changed: PreprocessorDefine code moved to CompilerSymbols folder to avoid paradox of missing symbols preventing the symbols being added to the project.
|
||||
- Changed: Host player no longer gets authority assigned to all objects by default.
|
||||
- Changed: Commands no longer bypass serialization for Host player, making debugging easier.
|
||||
- Changed: Local connections now maintain their own message queue.
|
||||
- Changed: Transport.Available is now abstract.
|
||||
- Removed: Network Identity: Local Player Authority has been removed as no longer necessary.
|
||||
|
||||
## Version 4.0.7 - 2019-Oct-03
|
||||
- Added: [Authenticators](../Components/Authenticators/index.md) support to authenticate clients in the Connect phase.
|
||||
- Added: Profiler events. These events can be subscribed to by the [Network Profiler](../Guides/Profiler.md) to provide visual information.
|
||||
- Added: Transports now include channel in profiler events.
|
||||
- Added: Transport abstract class now supports sending a message to a list of connection id's.
|
||||
- Fixed: SceneMessage now has sceneOperation enum so clients can properly handle additive scenes.
|
||||
- Fixed: NetworkClient handlers are now cleared in Shutdown.
|
||||
- Fixed: Offline scene is no longer reloaded when client fails to connect or is rejected.
|
||||
- Fixed: Start Position Index is now reset to zero when server is stopped.
|
||||
- Fixed: Network Room Players are now all in DontDestroyOnLoad so they don't respawn in the game scene.
|
||||
- Fixed: Network Room example player controller restores main camera on disable.
|
||||
- Fixed: Components with different sync intervals were not sending updates to clients.
|
||||
- Fixed: In certain cases, weaver wouldn't weave some external assemblies.
|
||||
- Fixed: Network Animator now does a full sync for new clients.
|
||||
- Fixed: Network Behaviour inspector now shows SyncMode for private SyncVars.
|
||||
- Fixed: Calling Commands and Rpcs of parent classes from inherited classes works as it should.
|
||||
- Fixed: Telepathy no longer hangs when attempting to connect to a nonexistent host.
|
||||
- Fixed: Websockets Transport now properly returns the client endpoint information via `ServerGetClientAddress`.
|
||||
- Fixed: WebGL build now works with ArraySegment.
|
||||
- Changed: Mirror is now free of garbage memory allocation on the sending side.
|
||||
- Some transports may still have a little garbage allocation yet.
|
||||
- Changed: Deprecated the AddPlayerMessage extraMessage byte\[\] in favor of an easier approach to [Custom Players](../Guides/GameObjects/SpawnPlayerCustom.md).
|
||||
- This is a breaking change: The virtual method OnServerAddPlayer loses the AddPlayerMessage parameter.
|
||||
- Changed: `NetworkIdentity.RemoveAuthorityForConnection` is now easier to use: no need to supply the current "owner" anymore.
|
||||
- Changed: Renamed `NetworkConnection.playerController` to `identity` ... see [Deprecations](Deprecations.md) for details.
|
||||
- Changed: Lobby system renamed to Room to better align the name for what it is and make way for a future Lobby framework.
|
||||
|
||||
## Version 3.17.4 - 2019-Sep-04
|
||||
- Added: Custom Network Readers & Writers via extension methods.
|
||||
- Added: Network Sync Mode selector on components to sync to observers (default) or just the owner.
|
||||
- Added: SyncVars now support structs and enums in other assemblies.
|
||||
- Added: Support for reading and writing array segments.
|
||||
- Added: Network Animator now has layers support.
|
||||
- Added: New virtual method OnServerChangeScene to Network Manager.
|
||||
- Added: XML summary comments for intellisense and future generated class docs.
|
||||
- Updated Examples and Documentation.
|
||||
- Fixed: SceneID was not set to 0 for prefab variants.
|
||||
- Fixed: Observers were not properly rebuilt on scene changes.
|
||||
- Fixed: SyncVar hooks were not able to change other SyncVars in Host mode.
|
||||
- Fixed: Telepathy not setting socket options on accepted clients.
|
||||
- Fixed: Catch IL2CPP bug.
|
||||
- Fixed: Telepathy and Websockets now start connections ID's at 1 instead of 2.
|
||||
- Fixed: Websockets support for SSL restored.
|
||||
- Fixed: Network Manager no longer complains about missing player prefab if auto-create is disabled.
|
||||
- Fixed: Removed a garbage allocation in Network Transform.
|
||||
- Fixed: NetworkClient.Ready was being called unncessarily in certain cases, e.g. SceneMessages.
|
||||
- Changed: Documentation moved to website and API generated docs implemented.
|
||||
- Changed: AddPlayerForConnection handler is now internal to keep safety checks intact.
|
||||
- Changed: A bunch of messages converted to value types for performance.
|
||||
|
||||
## Version 3.11.6 - 2019-Jul-10
|
||||
- Fixed: Telepathy IPv4, IPv6, and FQDN should all work now.
|
||||
- Fixed: TelepathyTransport error in UWP builds.
|
||||
- Fixed: OnApplicationQuit is handled better now.
|
||||
- Fixed: Performance and memory allocation improvements.
|
||||
- Changed: Telepathy Source is now included instead of a DLL.
|
||||
|
||||
## Version 3.10.10 - 2019-Jun-19
|
||||
- Added: Scene Message now supports params for SceneMode (Normal / Additive) and PhysicsMode (2D / 3D).
|
||||
- Added: ClientScene.Send now has an optional ChannelId parameter.
|
||||
- Added: ASMDEF to Examples folder.
|
||||
- Added: Support for sending and receiving ArraySegment\<byte\>
|
||||
- Added: IReadOnlyList\<T\> in SyncLists.
|
||||
- Fixed: Network Manager not switching to correct scene in some cases.
|
||||
- Fixed: ListServer Ping not found in WebGL.
|
||||
- Fixed: TelepathyTransport.GetMaxPacketSize uses the new configurable max size.
|
||||
- Fixed: Significant reduction in memory allocation and garbage collection.
|
||||
- Changed: Use transform.localPosition and transform.localRotation for better VR support.
|
||||
- Removed: Websockets send queues (they never worked) and SSL (temporarily because it didn't work).
|
||||
|
||||
## Version 3.6.7 -- 2019-Apr-28
|
||||
- Changed: NetworkReader now uses ArraySegment\<byte\> to minimize allocations.
|
||||
|
||||
## Version 3.6.6 -- 2019-Apr-24
|
||||
- Fixed: Reverted two internal refactor commits that had unintended consequences.
|
||||
|
||||
## Version 3.6.5 -- 2019-Apr-23
|
||||
- Fixed: Unity 2019.1 compatibility.
|
||||
- Fixed: Erroneous error indicating prefabs were missing Scene ID's.
|
||||
- Fixed: OnDeserializeSafely now works without allocations.
|
||||
- Fixed: Weaver not writing symbol files, preventing breakpoints from working in Visual Studio.
|
||||
- Fixed: Network Identity SceneID generation now uses RNG Crypto Service Provider.
|
||||
- Fixed: Scene lighting in Additive example.
|
||||
- Fixed: Player Prefab transform details now respected when instantiated in the absence of NetworkStartPosition.
|
||||
- Removed: Tests folder from Unity package generation (no end-user value).
|
||||
|
||||
## Version 3.5.9 -- 2019-Apr-12
|
||||
- Fixed: Network Manager round-robin mode using NetworkStartPosition objects now uses hierarchy sibling order.
|
||||
- Fixed: IsLocalPlayer is now reliably accurate in `Start()` by combining OwnerMessage and SpawnPrefabMessage.
|
||||
- Fixed: Stack overflow issues with Weaver and Cecil.
|
||||
- Fixed: Corrected assembly paths passed to weaver.
|
||||
- Fixed: Enum bandwdith reduced in SyncVars, Commands, and Rpcs.
|
||||
- Fixed: Placeholder files added for removed code files so updating works better.
|
||||
- Changed: Network Manager `isHeadless` is a static property now, changed from `IsHeadless()`.
|
||||
|
||||
## Version 3.5.3 -- 2019-Apr-10
|
||||
- Fixed: Exceptions in overrides of Network Manager and other components incorrectly silenced.
|
||||
- Fixed: Lobby system sometimes would not spawn and swap game player prefabs into the game scene.
|
||||
- Fixed: Application.targetFrameRate no longer set in host mode.
|
||||
- Changed: Telepathy: Split MaxMessageSize to allow setting a different value for client and server.
|
||||
|
||||
## Version 3.4.9 -- 2019-Apr-6
|
||||
- Added: Semantic Versioning (which is why we jumped from 1.6 to 3.4.9).
|
||||
- Added: [SyncDictionary](../Guides/Sync/SyncDictionary.md).
|
||||
- Added: [SyncHashSet](../Guides/Sync/SyncHashSet.md).
|
||||
- Added: [SyncSortedSet](../Guides/Sync/SyncSortedSet.md).
|
||||
- Added: SyncList and SyncDictionary support all IList and IDictionary derived types, respectively.
|
||||
- Added: Documentation for [SyncVars](../Guides/Sync/SyncVars.md).
|
||||
- Added: Documentation for [SyncEvents](../Guides/Sync/SyncEvent.md).
|
||||
- Added: NoRotation to Network Transform.
|
||||
- Added: Scale is now included in spawn payload along with position and rotation.
|
||||
- Added: Generic `IMessageBase` to allow struct message types.
|
||||
- Added: Weaver now supports Vector2Int and Vector3Int.
|
||||
- Added: List Server example.
|
||||
- Added: Additive Scenes example.
|
||||
- Fixed: SyncLists now work correctly for primitives and structs.
|
||||
- Fixed: SyncVar Hooks now will update the local property value after the hook is called.
|
||||
- You no longer need to have a line of code in your hook method to manualy update the local property.
|
||||
- Fixed: Host should not call Disconnect on transports.
|
||||
- Fixed: NetworkAnimimator now supports up to 64 animator parameters.
|
||||
- Fixed: Network Manager `StartServer` no longer assumes scene zero is the default scene...uses `GetActiveScene` now.
|
||||
- Fixed: `NetworkServer.Shutdown` now resets `netId` to zero.
|
||||
- Fixed: Observers are now properly rebuilt when client joins and `OnRebuildObservers` / `OnCheckObserver` is overridden.
|
||||
- Fixed: NetworkProximityChecker: On rare occasion, player could be excluded from observers rebuild.
|
||||
- Fixed: NetworkLobbyPlayer `OnClientReady` works now.
|
||||
- Fixed: NetworkLobbyPlayer Remove button not showing for P1 when Server Only.
|
||||
- Fixed: NetworkLobbyManager `pendingPlayers` and `lobbySlots` lists are now public for inheritors.
|
||||
- Fixed: Offline scene switching now works via `StopClient()`.
|
||||
- Fixed: Pong example updated.
|
||||
- Fixed: Source Weaver was deleting PDB files, preventing breakpoints and debugging from working.
|
||||
- Changed: TargetRpc NetworkConnection paramater is now optional...the calling client's NetworkConnection is default.
|
||||
- Changed: Movement example replaced with Tank example.
|
||||
- Changed: NetworkClient functions are all static now, so the singleton is gone. Use NetworkClient directly.
|
||||
- Changed: SyncList now supports structs directly, making SyncListSTRUCT obsolete.
|
||||
- Removed: SyncListSTRUCT - Use SyncList instead.
|
||||
- Removed: NetworkClient.ShutdownAll is obsolete -- Use NetworkClient.Shutdown instead.
|
||||
|
||||
## Version 1.6 -- 2019-Mar-14
|
||||
- Fixed: Websockets transport moved to Mirror.Websocket namespace.
|
||||
- Fixed: Network Animator bandwidth abuse.
|
||||
- Fixed: Network Animator float sync bug.
|
||||
- Fixed: Persistent SceneID's for Networked objects.
|
||||
- Changed: Documentation for [Transports](../Transports/index.md).
|
||||
- Changed: Weaver is now full source...FINALLY!
|
||||
- Changed: ClientScene.AddPlayer 2nd parameter is now `byte[] extraData` instead of `MessageBase extraMessage`.
|
||||
- Please refer to the code sample [here](../Guides/GameObjects/SpawnPlayerCustom.md) to see how to update your code.
|
||||
- Changed: Network Manager -- Headless Auto-Start moved to `Start()` from `Awake()`.
|
||||
- Changed: Removed Message ID's for all messages - See [Network Messages](../Guides/Communications/NetworkMessages.md) for details.
|
||||
- Message IDs are now generated automatically based on the message name.
|
||||
- Previously you would call Send(MyMessage.MsgId, message), now you call Send(message).
|
||||
- Removed: Documentation for Groove Transport - use Websockets Transport instead.
|
||||
|
||||
## Version 1.5 -- 2019-Mar-01
|
||||
- Added: **Migration Tool** to (mostly) automate conversion from UNet.
|
||||
- Added: Full support for WebSockets and WebSocketsSecure to replace UNet LLAPI.
|
||||
- Added: Transport Multiplexer - allows the use of multiple concurrent transports.
|
||||
- Added: NetworkLobbyManager and NetworkLobbyPlayer with example game.
|
||||
- Added: Configurable Server Tickrate in Network Manager.
|
||||
- Added: New virtual OnClientChangeScene fires right before SceneManager.LoadSceneAsync is executed.
|
||||
- Added: Unit tests for Weaver.
|
||||
- Fixed: Garbage allocations removed from a lot of things (more work to do, we know).
|
||||
- Fixed: NetworkProximityChecker now uses `OverlapSphereNonAlloc` and `OverlapCircleNonAlloc`.
|
||||
- Fixed: SyncVar hook not firing when clients joined.
|
||||
- Fixed: Network Manager no longer assumes it's on Scene(0) in Build Settings.
|
||||
- Fixed: Network Animator no longer lmited to 6 variables.
|
||||
- Fixed: TelepathyTransport delivering messages when disabled.
|
||||
- Changed: Minimum Unity version: **2018.3.6**
|
||||
- Removed: SceneAttribute.cs (merged to CustomAttributes.cs).
|
||||
- Removed: `NetworkClient.allClients` (Use `NetworkClient.singleton` instead).
|
||||
- Removed: `NetworkServer.hostId` and `NetworkConnection.hostId` (holdovers from LLAPI).
|
||||
- Removed: `NetworkConnection.isConnected` (Network Connection is always connected).
|
||||
- Removed: `Transport.GetConnectionInfo` (Use `ServerGetClientAddress` instead).
|
||||
|
||||
## Version 1.4 -- 2019-Feb-01
|
||||
- Added: HelpURL attirbutes to components.
|
||||
- Added: Automatic targetFramerate for headless builds.
|
||||
- Added: ByteMessage to Messages class.
|
||||
- Fixed: Connectiing state can be cancelled properly.
|
||||
- Fixed: Network Transform interpolation applied to client's own object.
|
||||
- Fixed: Objects are spawned with correct rotation.
|
||||
- Fixed: SceneId assignment.
|
||||
- Fixed: Changed syncInterval wasn't saved...it is now.
|
||||
- Fixed: Additive Scene loading.
|
||||
- Changed: **Mirror is now full source** -- no more DLL's.
|
||||
- Changed: **Transports are now components** -- TCP, UDP, WebGL, Steam.
|
||||
- Changed: Transport class now dispatches Unity Events.
|
||||
- Changed: `NetworkServer.SendToClientOfPlayer` uses `NetworkIdentity` now.
|
||||
- Changed: `NetworkServer.SendToObservers` uses `NetworkIdentity` parameter now.
|
||||
- Changed: `NetworkServer.SendToReady` uses `NetworkIdentity` now.
|
||||
- Changed: `NetworkServer.DestroyPlayerForConnection` uses `NetworkIdentity.spawned` now.
|
||||
- Changed: `NetworkConnection.Dispose` uses `NetworkIdentity.spawned` now.
|
||||
- Changed: `NetworkReader.ReadTransform` uses `NetworkIdentity.spawned` now.
|
||||
- Changed: Network Transform reimplemented -- physics removed, code simplified.
|
||||
- Removed: `NetworkClient.hostPort` (port is handled at Transport level).
|
||||
- Removed: `NetworkServer.FindLocalObject` (Use `NetworkIdentity.spawned[netId]` instead).
|
||||
- Removed: `ClientScene.FindLocalObject` (Use `NetworkIdentity.spawned[netId]` instead).
|
@ -1,342 +0,0 @@
|
||||
# Deprecations
|
||||
|
||||
Certain features of Unity Networking (UNet) were removed from Mirror or modified for various reasons. This page will identify all changed and removed features, properties, and methods, the reason for change or removal, and possible alternatives.
|
||||
|
||||
> Note: Some changes in this document may apply to an upcoming release to the Asset Store.
|
||||
|
||||
## Match Namespace & Host Migration
|
||||
|
||||
As part of the Unity Services, this entire namespace was removed. It didn't work well to begin with, and was incredibly complex to be part of the core networking package. We expect this, along with other back-end services, will be provided through standalone apps that have integration to Mirror.
|
||||
|
||||
## Network Server Simple
|
||||
|
||||
This was too complex and impractical to maintain for what little it did, and was removed. There are much easier ways to make a basic listen server, with or without one of our transports.
|
||||
|
||||
## Couch Co-Op
|
||||
|
||||
The core networking was greatly simplified by removing this low-hanging fruit. It was buggy, and too convoluted to be worth fixing. For those that need something like this, consider defining a non-visible player prefab as a message conduit that spawns actual player prefabs with client authority. All inputs would route through the conduit prefab to control the player objects.
|
||||
|
||||
## Message Types
|
||||
|
||||
The `MsgType` enumeration was removed. All message types are generated dynamically. Use `Send<T>` instead.
|
||||
|
||||
## Network Transform
|
||||
|
||||
[Network Transform](../Components/NetworkTransform.md) was significantly simplified so that it only syncs position, rotation and scale. Rigidbody support was removed. We may create a new NetworkRigidbody component that will be server authoritative with physics simulation and interpolation.
|
||||
|
||||
## Network Animator
|
||||
|
||||
[Network Animator](../Components/NetworkAnimator.md) was also simplified, as it batches all Animator parameters into a single update message.
|
||||
|
||||
## SyncVar Hook Parameters
|
||||
|
||||
[SyncVar](../Guides/Sync/SyncVars.md) property values are now updated before the hook is called, and hooks now require two parameters of the same type as the property: `oldValue` and `newValue`
|
||||
|
||||
## SyncListSTRUCT
|
||||
|
||||
Use `SyncList<YourSpecialStruct>` instead.
|
||||
|
||||
## SyncList Operations
|
||||
|
||||
- `OP_REMOVE` was replaced by `OP_REMOVEAT`
|
||||
- `OP_DIRTY` was replaced by `OP_SET`
|
||||
|
||||
## SyncIDictionary Operations
|
||||
|
||||
- `OP_DIRTY` was replaced by `OP_SET`
|
||||
|
||||
## Quality of Service Flags
|
||||
|
||||
In classic UNet, QoS Flags were used to determine how packets got to the remote end. For example, if you needed a packet to be prioritized in the queue, you would specify a high priority flag which the Unity LLAPI would then receive and deal with appropriately. Unfortunately, this caused a lot of extra work for the transport layer and some of the QoS flags did not work as intended due to buggy code that relied on too much magic.
|
||||
|
||||
In Mirror, QoS flags were replaced with a "Channels" system. While the default transport, [Telepathy](../Transports/Telepathy.md), does not use channels at all because it's TCP-based, other transports, such as [Ignorance](../Transports/Ignorance.md) and [LiteNetLib4Mirror](../Transports/LiteNetLib4Mirror.md), do support them.
|
||||
|
||||
The currently defined channels are:
|
||||
- `Channels.DefaultReliable = 0`
|
||||
- `Channels.DefaultUnreliable = 1`
|
||||
|
||||
## Changes by Class
|
||||
|
||||
### NetworkManager
|
||||
|
||||
- `networkPort`
|
||||
Removed as part of separating Transports to components. Not all transports use ports, but those that do have a field for it. See [Transports](../Transports/index.md) for more info.
|
||||
|
||||
- `IsHeadless()`
|
||||
Use `isHeadless` instead, as it's a property now.
|
||||
|
||||
- `client`
|
||||
Use NetworkClient directly, it will be made static soon. For example, use `NetworkClient.Send(message)` instead of `NetworkManager.client.Send(message)`.
|
||||
|
||||
- `IsClientConnected()`
|
||||
Use static property `NetworkClient.isConnected` instead.
|
||||
|
||||
- `onlineScene` and `offlineScene`
|
||||
These store full paths now, so use SceneManager.GetActiveScene().path instead.
|
||||
|
||||
- `OnStartClient(NetworkClient client)`
|
||||
Override OnStartClient() instead since all `NetworkClient` methods are static now.
|
||||
|
||||
- `OnClientChangeScene(string newSceneName)`
|
||||
Override `OnClientChangeScene(string newSceneName, SceneOperation sceneOperation, bool customHandling)` instead.
|
||||
|
||||
- `OnClientChangeScene(string newSceneName, SceneOperation sceneOperation)`
|
||||
Override `OnClientChangeScene(string newSceneName, SceneOperation sceneOperation, bool customHandling)` instead.
|
||||
|
||||
- `OnServerAddPlayer(NetworkConnection conn, AddPlayerMessage extraMessage)`
|
||||
Override `OnServerAddPlayer(NetworkConnection conn)` instead. See [Custom Player Spawn Guide](../Guides/GameObjects/SpawnPlayerCustom.md) for details.
|
||||
|
||||
- `OnServerRemovePlayer(NetworkConnection conn, NetworkIdentity player)`
|
||||
Use `NetworkServer.RemovePlayerForConnection(NetworkConnection conn, GameObject player, bool keepAuthority = false)` instead.
|
||||
|
||||
### NetworkRoomManager
|
||||
|
||||
- `OnRoomServerCreateGamePlayer(NetworkConnection conn)`
|
||||
Use `OnRoomServerCreateGamePlayer(NetworkConnection conn, GameObject roomPlayer)` instead.
|
||||
|
||||
- `OnRoomServerSceneLoadedForPlayer(GameObject roomPlayer, GameObject gamePlayer)`
|
||||
Use `OnRoomServerSceneLoadedForPlayer(NetworkConnection conn, GameObject roomPlayer, GameObject gamePlayer)` instead.
|
||||
|
||||
### NetworkIdentity
|
||||
|
||||
- `clientAuthorityOwner`
|
||||
Use connectionToClient instead
|
||||
|
||||
- `GetSceneIdenity`
|
||||
Use `GetSceneIdentity` instead (typo in original name)
|
||||
|
||||
- `RemoveClientAuthority(NetworkConnection conn)`
|
||||
NetworkConnection parameter is no longer needed and nothing is returned
|
||||
|
||||
- Local Player Authority checkbox
|
||||
This checkbox is no longer needed, and we simplified how [Authority](../Guides/Authority.md) works in Mirror.
|
||||
|
||||
### NetworkBehaviour
|
||||
|
||||
- `sendInterval` attribute
|
||||
Use `NetworkBehaviour.syncInterval` field instead. Can be modified in the Inspector too.
|
||||
|
||||
- `List<SyncObject> m_SyncObjects`
|
||||
Use `List<SyncObject> syncObjects` instead.
|
||||
|
||||
- `OnSetLocalVisibility(bool visible)`
|
||||
Override `OnSetHostVisibility(bool visible)` instead.
|
||||
|
||||
- `OnRebuildObservers`, `OnCheckObserver`, and `OnSetHostVisibility` were moved to a separate class called `NetworkVisibility`
|
||||
|
||||
- `NetworkBehaviour.OnNetworkDestroy` was renamed to `NetworkBehaviour.OnStopClient`.
|
||||
|
||||
### NetworkConnection
|
||||
|
||||
- `hostId`
|
||||
Removed because it's not needed ever since we removed LLAPI as default. It's always 0 for regular connections and -1 for local connections. Use `connection.GetType() == typeof(NetworkConnection)` to check if it's a regular or local connection.
|
||||
|
||||
- `isConnected`
|
||||
Removed because it's pointless. A NetworkConnection is always connected.
|
||||
|
||||
- `InvokeHandlerNoData(int msgType)`
|
||||
Use `InvokeHandler<T>` instead.
|
||||
|
||||
- `playerController`
|
||||
renamed to `identity` since that's what it is: the `NetworkIdentity` for the connection. If you need to convert a project after this change, Visual Studio / VS Code can help...read more [here](PlayerControllerToIdentity.md).
|
||||
|
||||
- `RegisterHandler(short msgType, NetworkMessageDelegate handler)`
|
||||
Use `NetworkServer.RegisterHandler<T>()` or `NetworkClient.RegisterHandler<T>()` instead.
|
||||
|
||||
- `UnregisterHandler(short msgType)`
|
||||
Use `NetworkServer.UnregisterHandler<T>()` or `NetworkClient.UnregisterHandler<T>()` instead.
|
||||
|
||||
- `Send(int msgType, MessageBase msg, int channelId = Channels.DefaultReliable)`
|
||||
Use `Send<T>(msg, channelId)` instead.
|
||||
|
||||
### NetworkServer
|
||||
|
||||
- `FindLocalObject(uint netId)`
|
||||
Use `NetworkIdentity.spawned[netId].gameObject` instead.
|
||||
|
||||
- `RegisterHandler(int msgType, NetworkMessageDelegate handler)`
|
||||
Use `RegisterHandler<T>(T msg)` instead.
|
||||
|
||||
- `RegisterHandler(MsgType msgType, NetworkMessageDelegate handler)`
|
||||
Use `RegisterHandler<T>(T msg)` instead.
|
||||
|
||||
- `UnregisterHandler(int msgType)`
|
||||
Use `UnregisterHandler<T>(T msg)` instead.
|
||||
|
||||
- `UnregisterHandler(MsgType msgType)`
|
||||
Use `UnregisterHandler<T>(T msg)` instead.
|
||||
|
||||
- `SendToAll(int msgType, MessageBase msg, int channelId = Channels.DefaultReliable)`
|
||||
Use `SendToAll<T>(T msg, int channelId = Channels.DefaultReliable)` instead.
|
||||
|
||||
- `SendToClient(int connectionId, int msgType, MessageBase msg)`
|
||||
Use `NetworkConnection.Send<T>(T msg, int channelId = Channels.DefaultReliable)` instead.
|
||||
|
||||
- `SendToClient<T>(int connectionId, T msg)`
|
||||
Use `NetworkConnection.Send<T>(T msg, int channelId = Channels.DefaultReliable)` instead.
|
||||
|
||||
- `SendToClientOfPlayer(NetworkIdentity identity, int msgType, MessageBase msg)`
|
||||
Use `SendToClientOfPlayer<T>(NetworkIdentity identity, T msg, int channelId = Channels.DefaultReliable)` instead.
|
||||
|
||||
- `SendToReady(NetworkIdentity identity, short msgType, MessageBase msg, int channelId = Channels.DefaultReliable)`
|
||||
Use `SendToReady<T>(NetworkIdentity identity, T msg, int channelId = Channels.DefaultReliable)` instead.
|
||||
|
||||
- `SpawnWithClientAuthority(GameObject obj, GameObject player)`
|
||||
Use `Spawn(GameObject obj, GameObject player)` instead.
|
||||
|
||||
- `SpawnWithClientAuthority(GameObject obj, NetworkConnection ownerConnection)`
|
||||
Use `Spawn(GameObject obj, NetworkConnection ownerConnection)` instead.
|
||||
|
||||
- `SpawnWithClientAuthority(GameObject obj, Guid assetId, NetworkConnection ownerConnection)`
|
||||
Use `Spawn(GameObject obj, Guid assetId, NetworkConnection ownerConnection)` instead
|
||||
|
||||
### NetworkClient
|
||||
|
||||
- `NetworkClient singleton`
|
||||
Use `NetworkClient` directly. Singleton isn't needed anymore as all functions are static now.
|
||||
Example: `NetworkClient.Send(message)` instead of `NetworkClient.singleton.Send(message)`.
|
||||
|
||||
- `allClients`
|
||||
Use `NetworkClient` directly instead. There is always exactly one client.
|
||||
|
||||
- `GetRTT()`
|
||||
Use `NetworkTime.rtt` instead.
|
||||
|
||||
- `RegisterHandler(int msgType, NetworkMessageDelegate handler)`
|
||||
Use `RegisterHandler<T>(T msg)` instead.
|
||||
|
||||
- `RegisterHandler(MsgType msgType, NetworkMessageDelegate handler)`
|
||||
Use `RegisterHandler<T>(T msg)` instead.
|
||||
|
||||
- `UnregisterHandler(int msgType)`
|
||||
Use `UnregisterHandler<T>(T msg)` instead.
|
||||
|
||||
- `UnregisterHandler(MsgType msgType)`
|
||||
Use `UnregisterHandler<T>(T msg)` instead.
|
||||
|
||||
- `Send(short msgType, MessageBase msg)`
|
||||
Use `Send<T>(T msg, int channelId = Channels.DefaultReliable)` with no message id instead
|
||||
|
||||
- `ShutdownAll()`
|
||||
Use `Shutdown()` instead. There is only one client.
|
||||
|
||||
### ClientScene
|
||||
|
||||
- `FindLocalObject(uint netId)`
|
||||
Use `NetworkIdentity.spawned[netId]` instead.
|
||||
|
||||
### Messages
|
||||
|
||||
Basic messages of simple types were all removed as unnecessary bloat. You can create your own message classes instead.
|
||||
|
||||
- `StringMessage`
|
||||
- `ByteMessage`
|
||||
- `BytesMessage`
|
||||
- `IntegerMessage`
|
||||
- `DoubleMessage`
|
||||
- `EmptyMessage`
|
||||
|
||||
### NetworkWriter
|
||||
|
||||
- `Write(bool value)`
|
||||
Use `WriteBoolean` instead.
|
||||
|
||||
- `Write(byte value)`
|
||||
Use `WriteByte` instead.
|
||||
|
||||
- `Write(sbyte value)`
|
||||
Use `WriteSByte` instead.
|
||||
|
||||
- `Write(short value)`
|
||||
Use `WriteInt16` instead.
|
||||
|
||||
- `Write(ushort value)`
|
||||
Use `WriteUInt16` instead.
|
||||
|
||||
- `Write(int value)`
|
||||
Use `WriteInt32` instead.
|
||||
|
||||
- `Write(uint value)`
|
||||
Use `WriteUInt32` instead.
|
||||
|
||||
- `Write(long value)`
|
||||
Use `WriteInt64` instead.
|
||||
|
||||
- `Write(ulong value)`
|
||||
Use `WriteUInt64` instead.
|
||||
|
||||
- `Write(float value)`
|
||||
Use `WriteSingle` instead.
|
||||
|
||||
- `Write(double value)`
|
||||
Use `WriteDouble` instead.
|
||||
|
||||
- `Write(decimal value)`
|
||||
Use `WriteDecimal` instead.
|
||||
|
||||
- `Write(string value)`
|
||||
Use `WriteString` instead.
|
||||
|
||||
- `Write(char value)`
|
||||
Use `WriteChar` instead.
|
||||
|
||||
- `Write(Vector2 value)`
|
||||
Use `WriteVector2` instead.
|
||||
|
||||
- `Write(Vector2Int value)`
|
||||
Use `WriteVector2Int` instead.
|
||||
|
||||
- `Write(Vector3 value)`
|
||||
Use `WriteVector3` instead.
|
||||
|
||||
- `Write(Vector3Int value)`
|
||||
Use `WriteVector3Int` instead.
|
||||
|
||||
- `Write(Vector4 value)`
|
||||
Use `WriteVector4` instead.
|
||||
|
||||
- `Write(Color value)`
|
||||
Use `WriteColor` instead.
|
||||
|
||||
- `Write(Color32 value)`
|
||||
Use `WriteColor32` instead.
|
||||
|
||||
- `Write(Guid value)`
|
||||
Use `WriteGuid` instead.
|
||||
|
||||
- `Write(Transform value)`
|
||||
Use `WriteTransform` instead.
|
||||
|
||||
- `Write(Quaternion value)`
|
||||
Use `WriteQuaternion` instead.
|
||||
|
||||
- `Write(Rect value)`
|
||||
Use `WriteRect` instead.
|
||||
|
||||
- `Write(Plane value)`
|
||||
Use `WritePlane` instead.
|
||||
|
||||
- `Write(Ray value)`
|
||||
Use `WriteRay` instead.
|
||||
|
||||
- `Write(Matrix4x4 value)`
|
||||
Use `WriteMatrix4x4` instead.
|
||||
|
||||
- `Write(NetworkIdentity value)`
|
||||
Use `WriteNetworkIdentity` instead.
|
||||
|
||||
- `Write(GameObject value)`
|
||||
Use `WriteGameObject` instead.
|
||||
|
||||
- `Write(byte[] buffer, int offset, int count)`
|
||||
Use `WriteBytes` instead.
|
||||
|
||||
### Transport
|
||||
|
||||
- `GetConnectionInfo(int connectionId, out string address)`
|
||||
Use `ServerGetClientAddress(int connectionId)` instead.
|
||||
|
||||
### TelepathyTransport
|
||||
|
||||
- `MaxMessageSize`
|
||||
Use `MaxMessageSizeFromClient` or `MaxMessageSizeFromServer` instead.
|
Before Width: | Height: | Size: 40 KiB |
Before Width: | Height: | Size: 25 KiB |
Before Width: | Height: | Size: 27 KiB |
Before Width: | Height: | Size: 95 KiB |
Before Width: | Height: | Size: 27 KiB |
Before Width: | Height: | Size: 48 KiB |
Before Width: | Height: | Size: 53 KiB |
@ -1,35 +0,0 @@
|
||||
# Integrations
|
||||
|
||||
Here we will maintain a list of assets known to be compatible with Mirror. If you know of others, please have the publisher contact us directly in our [Discord](https://discord.gg/2BvnM4R).
|
||||
|
||||
## [SmoothSync](https://assetstore.unity.com/packages/tools/network/smooth-sync-96925)
|
||||
|
||||
![SmoothSync](SmoothSync.jpg)
|
||||
|
||||
## [Weather Maker](https://assetstore.unity.com/packages/tools/particles-effects/weather-maker-unity-weather-system-sky-water-volumetric-clouds-a-60955)
|
||||
|
||||
![Weather Maker](WeatherMaker.jpg)
|
||||
|
||||
## [Noble Connect Free](https://assetstore.unity.com/packages/tools/network/noble-connect-free-141599)
|
||||
|
||||
![Noble Connect Free](NobleConnectFree.jpg)
|
||||
|
||||
## [Dissonance Voice Chat](https://assetstore.unity.com/packages/tools/audio/dissonance-voice-chat-70078)
|
||||
|
||||
![Dissonance](Dissonance.jpg)
|
||||
|
||||
## [RTS Engine](https://assetstore.unity.com/packages/templates/packs/rts-engine-79732)
|
||||
|
||||
![RTS Engine](rts-engine.png)
|
||||
|
||||
## [Rucksack](https://assetstore.unity.com/packages/templates/systems/rucksack-multiplayer-inventory-system-114921)
|
||||
|
||||
![Rucksack](Rucksack.jpg)
|
||||
|
||||
## [Steamworks Networking](https://assetstore.unity.com/packages/tools/integration/steamworks-networking-151300)
|
||||
|
||||
![Steamworks Networking](SteamworksNetworking.jpg)
|
||||
|
||||
## [Master Audio Multiplayer](https://assetstore.unity.com/packages/tools/audio/master-audio-multiplayer-69547)
|
||||
|
||||
![Master Audio Multiplayer](MasterAudioMultiplayer.jpg)
|
Before Width: | Height: | Size: 36 KiB |
@ -1,234 +0,0 @@
|
||||
# Migration Guide
|
||||
|
||||
## Migrating a project from UNet (HLAPI)
|
||||
|
||||
This guide gives you a step by step instruction for migrating your project from HLAP to Mirror. Mirror is a fork of UNet. As such the migration is straight forward for most projects.
|
||||
|
||||
You should review the information on the [Deprecations](Deprecations.md) page to see if your project will be impacted.
|
||||
|
||||
There's also a Migration Tool you can try:
|
||||
<https://github.com/Lymdun/MirrorConverter/>
|
||||
|
||||
### 1. BACKUP
|
||||
|
||||
You have been warned.
|
||||
|
||||
### 2. Install Mirror and Restart Unity
|
||||
|
||||
Get Mirror from the [asset store](https://assetstore.unity.com/packages/tools/network/mirror-129321) and import it in your project.
|
||||
|
||||
Alternatively you can grab the latest [release](https://github.com/vis2k/Mirror/releases) from GitHub if you're feeling adventurous, but be aware that bleeding edge dev releases are not necessarily stable.
|
||||
|
||||
**NOTE:** You must restart Unity after adding Mirror to the project for the components menu to update correctly.
|
||||
|
||||
### 3. Replace namespace
|
||||
|
||||
Replace `UnityEngine.Networking` for `Mirror` everywhere in your project. For example, if you have this:
|
||||
|
||||
```cs
|
||||
using UnityEngine.Networking;
|
||||
|
||||
public class Player : NetworkBehaviour
|
||||
{
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
replace it with:
|
||||
|
||||
```cs
|
||||
using Mirror;
|
||||
|
||||
public class Player : NetworkBehaviour
|
||||
{
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
At this point, you might get some compilation errors. Don't panic, these are easy to fix. Keep going...
|
||||
|
||||
### 4. Replace playerController with identity
|
||||
|
||||
Replace references to `NetworkConnection.playerController` with `NetworkConnection.identity`. Click [here](PlayerControllerToIdentity.md) for guidance.
|
||||
|
||||
### 5. Remove NetworkSettings
|
||||
|
||||
NetworkSettings in UNet have channels, but this is flat out broken. Rather than ignoring your settings we removed channels from NetworkSettings completely. `sendInterval` is now set in code and / or the inspector too.
|
||||
|
||||
For example, if you have this code:
|
||||
|
||||
```cs
|
||||
[NetworkSettings(channel=1,sendInterval=0.05f)]
|
||||
public class NetStreamer : NetworkBehaviour
|
||||
{
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
replace it with:
|
||||
|
||||
```cs
|
||||
public class NetStreamer : NetworkBehaviour
|
||||
{
|
||||
void Start()
|
||||
{
|
||||
syncInterval = 0.05f;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Please note that the default transport [Telpathy](../Transports/Telepathy.md), completely ignores channels, all messages are reliable, sequenced and fragmented. They just work with no fuss. If you want to take advantage of unreliable channels use LLAPITransport instead.
|
||||
|
||||
### 6. Change SyncListStruct to SyncList
|
||||
|
||||
There is a bug in the original UNet Weaver that makes it mess with our `Mirror.SyncListStruct` without checking the namespace. In Mirror, we fixed SyncLists so that they work with structs by default.
|
||||
|
||||
For example, if you have definitions like:
|
||||
|
||||
```cs
|
||||
public class SyncListQuest : SyncListStruct<Quest> { }
|
||||
```
|
||||
|
||||
replace them with:
|
||||
|
||||
```cs
|
||||
public class SyncListQuest : SyncList<Quest> { }
|
||||
```
|
||||
|
||||
### 7. Replace NetworkHash128 and NetworkInstanceId
|
||||
|
||||
These have been changed to System.Guid and uint, respectively.
|
||||
|
||||
For example, if you have something like this:
|
||||
|
||||
```cs
|
||||
public sealed class SpawnItemMessage : MessageBase
|
||||
{
|
||||
public NetworkHash128 assetID;
|
||||
public NetworkInstanceId networkInstanceID;
|
||||
public Vector3 position;
|
||||
public Quaternion rotation;
|
||||
}
|
||||
```
|
||||
|
||||
replace with:
|
||||
|
||||
```cs
|
||||
public sealed class SpawnItemMessage : MessageBase
|
||||
{
|
||||
public System.Guid assetID;
|
||||
public uint networkInstanceID;
|
||||
public Vector3 position;
|
||||
public Quaternion rotation;
|
||||
}
|
||||
```
|
||||
|
||||
### 8. Update your synclist callbacks
|
||||
|
||||
In UNet, SyncLists have a callback delegate that gets called in the client whenever the list is updated. We have changed the callback to be a C\# event instead and we also pass the item that was updated/removed.
|
||||
|
||||
For example, if you have this code:
|
||||
|
||||
```cs
|
||||
using UnityEngine;
|
||||
using UnityEngine.Networking;
|
||||
|
||||
public class MyBehaviour : NetworkBehaviour
|
||||
{
|
||||
public SyncListInt m_ints = new SyncListInt();
|
||||
|
||||
private void OnIntChanged(SyncListInt.Operation op, int index)
|
||||
{
|
||||
Debug.Log("list changed " + op);
|
||||
}
|
||||
|
||||
public override void OnStartClient()
|
||||
{
|
||||
m_ints.Callback = OnIntChanged;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
replace it with:
|
||||
|
||||
```cs
|
||||
using UnityEngine;
|
||||
using Mirror;
|
||||
|
||||
public class MyBehaviour : NetworkBehaviour
|
||||
{
|
||||
public SyncListInt m_ints = new SyncListInt();
|
||||
|
||||
private void OnIntChanged(SyncListInt.Operation op, int index, int oldItem, int newItem)
|
||||
{
|
||||
Debug.Log("list changed " + op + " old item: " + item + " new item: " + newItem);
|
||||
}
|
||||
|
||||
public override void OnStartClient()
|
||||
{
|
||||
m_ints.Callback += OnIntChanged;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Notice the callback will also work in the server in Mirror.
|
||||
|
||||
### 9. Replace Components
|
||||
|
||||
Every networked prefab and scene object needs to be adjusted. They will be using `NetworkIdentity` from Unet, and you need to replace that component with `NetworkIdentity` from Mirror. You may be using other network components, such as `NetworkAnimator` or `NetworkTransform`. All components from Unet should be replaced with their corresponding component from Mirror.
|
||||
|
||||
Note that if you remove and add a NetworkIdentity, you will need to reassign it in any component that was referencing it.
|
||||
|
||||
### 10. Update Extended Components
|
||||
|
||||
Some commonly extended components, such as NetworkManager, have changed method parameters in Mirror. A commonly used override is OnServerAddPlayer. Using the original HLAPI, your override may have looked like this:
|
||||
|
||||
```cs
|
||||
public override void OnServerAddPlayer(NetworkConnection conn, short playerControllerId, NetworkReader extraMessageReader)
|
||||
{
|
||||
base.OnServerAddPlayer(conn, playerControllerId, extraMessageReader);
|
||||
// your code
|
||||
}
|
||||
```
|
||||
|
||||
In your newly Mirror-capable NetworkManager, if you are using the `OnServerAddPlayer` override, remove the "playerControllerId" and "extraMessageReader" parameters from your override and the base call:
|
||||
|
||||
```cs
|
||||
public override void OnServerAddPlayer(NetworkConnection conn)
|
||||
{
|
||||
base.OnServerAddPlayer(conn);
|
||||
// your code
|
||||
}
|
||||
```
|
||||
|
||||
See [Custom Player Spawn Guide](../Guides/GameObjects/SpawnPlayerCustom.md) for details on how to submit custom characters now.
|
||||
|
||||
### 11. Pick your transport
|
||||
|
||||
You can choose one of several transports in Mirror. Open your NetworkManager gameobject, in the inspector you will see a `TelepathyTransport` component by default. Drag in one of the available transports and remove `TelepathyTransport` if you wish to use a UDP based transport instead.
|
||||
|
||||
### 12. Configure address and port
|
||||
|
||||
In HLAPI, you configure the port and local address in the NetworkManager. One of our goals is to make Mirror transport independent. Not all transports need address and port. Some transports might even use more than one port at the same time, so these settings were inadequate. We removed the port and address and all other Network Info properties from NetworkManager, and we moved them to the transport components instead.
|
||||
|
||||
### 13. Update your firewall and router
|
||||
|
||||
LLAPI uses UDP. Mirror uses TCP by default. This means you may need to change your router port forwarding and firewall rules in your machine to expose the TCP port instead of UDP. This highly depends on your router and operating system.
|
||||
|
||||
## Video version
|
||||
|
||||
See for yourself how uMMORPG was migrated to Mirror
|
||||
|
||||
[![Manually upgrading uMMORPG V1.130 to V1.131 (Mirror)](MigrationVideo.jpg)](http://www.youtube.com/watch?v=LF9rTSS3rlI)
|
||||
|
||||
## Possible Error Messages
|
||||
- TypeLoadException: A type load exception has occurred. - happens if you still have SyncListStruct instead of SyncListSTRUCT in your project.
|
||||
- NullPointerException: The most likely cause is that you replaced NetworkIdentities or other components but you had them assigned somewhere. Reassign those references.
|
||||
- `error CS0246: The type or namespace name 'UnityWebRequest' could not be found. Are you missing 'UnityEngine.Networking' using directive?`
|
||||
|
||||
Add this to the top of your script:
|
||||
```cs
|
||||
using UnityWebRequest = UnityEngine.Networking.UnityWebRequest;
|
||||
```
|
||||
|
||||
`UnityWebRequest` is not part of UNet or Mirror, but it is in the same namespace as UNet. Changing the namespace to Mirror caused your script not to find UnityWebRequest. The same applies for `WWW` and all `UnityWebRequest` related classes.
|
Before Width: | Height: | Size: 20 KiB |
Before Width: | Height: | Size: 5.8 KiB |
Before Width: | Height: | Size: 163 KiB |
@ -1,43 +0,0 @@
|
||||
# Changing playerController to identity
|
||||
|
||||
If you need to fix up a project after `NetworkConnection.playerController` was changed to `identity` these instructions should be helpful.
|
||||
|
||||
1. Open your Unity project and look for Assets/Mirror/Runtime/**NetworkConnection**:
|
||||
|
||||
![Project window in Unity](pc2i-1.png)
|
||||
|
||||
|
||||
2. Open this file in Visual Studio or Visual Code from Unity and look for these lines:
|
||||
|
||||
![Code snip in NetworkConnection.cs](pc2i-2.png)
|
||||
|
||||
The line numbers could be off a bit if minor file changes happen above them after this document was written.
|
||||
|
||||
|
||||
3. Comment the last line shown:
|
||||
|
||||
```cs
|
||||
// public NetworkIdentity identity { get; internal set; }
|
||||
```
|
||||
|
||||
|
||||
4. Double-click and then right-click `playerController` and select Rename:
|
||||
|
||||
![Start of Rename process](pc2i-3.png)
|
||||
|
||||
|
||||
5. Change `playerController` to `identity` and click Apply:
|
||||
|
||||
![Finishing the Rename process](pc2i-4.png)
|
||||
|
||||
|
||||
Visual Studio will now have applied the change throughout your project, but you're not done yet!
|
||||
|
||||
Without using the replace feature this time, simply retype the name back to `playerController` and un-comment the last line in the code image that you commented out in step 3.
|
||||
|
||||
Your code should now look like the code image again.
|
||||
|
||||
![Code snip in NetworkConnection.cs](pc2i-2.png)
|
||||
|
||||
|
||||
**Save your work!**
|
@ -1,14 +0,0 @@
|
||||
# Script Templates
|
||||
|
||||
We've added Script Templates to make it easier to create derived class scripts that inherit from our base classes.
|
||||
|
||||
- All possible overrides are already made for you and organized
|
||||
- They're all fully commented as to what they all do
|
||||
- Base method calls are all in place where needed so you can see what they already do.
|
||||
- Each has links at the top to their doc page(s)
|
||||
|
||||
After importing Mirror and restarting Unity, the Mirror section will appear under the Assets > Create menu, as well as the context menu that comes up when you right-click on any folder in your project. You'll be prompted for the file name like any other asset creation.
|
||||
|
||||
Hopefully these templates will be helpful to new users of Mirror to learn what methods are available in various classes, as well as just being more convenient for everyone.
|
||||
|
||||
![Script Templates](ScriptTemplates.png)
|
Before Width: | Height: | Size: 22 KiB |
@ -1,83 +0,0 @@
|
||||
# Getting Started
|
||||
|
||||
This document describes steps to creating a multiplayer game with Mirror. The process described here is a simplified, higher level version of the actual process for a real game; it doesn’t always work exactly like this, but it provides a basic recipe for the process.
|
||||
|
||||
## Video tutorials
|
||||
|
||||
Check out these [awesome videos](https://www.youtube.com/playlist?list=PLkx8oFug638oBYF5EOwsSS-gOVBXj1dkP) showing you how to get started with mirror. Courtesy of [First Gear Games](https://www.youtube.com/channel/UCGIF1XekJqHYIafvE7l0c2A) also known as Punfish in discord.
|
||||
|
||||
## Script Templates
|
||||
- Create new Network Behaviours and other common scripts faster
|
||||
|
||||
See [Script Templates](ScriptTemplates.md).
|
||||
|
||||
## NetworkManager set-up
|
||||
- Add a new game object to the Scene and rename it “NetworkManager”.
|
||||
- Add the NetworkManager component to the “NetworkManager” game object.
|
||||
- Add the NetworkManagerHUD component to the game object. This provides the default UI for managing the network game state.
|
||||
|
||||
See [Using the NetworkManager](../Components/NetworkManager.md).
|
||||
|
||||
## Player Prefab
|
||||
- Find the Prefab for the player game object in the game, or create a Prefab from the player game object
|
||||
- Add the NetworkIdentity component to the player Prefab
|
||||
- Set the `playerPrefab` in the NetworkManager’s Spawn Info section to the player Prefab
|
||||
- Remove the player game object instance from the Scene if it exists in the Scene
|
||||
|
||||
See [Player Objects](../Guides/GameObjects/SpawnPlayer.md) for more information.
|
||||
|
||||
## Player movement
|
||||
- Add a NetworkTransform component to the player Prefab
|
||||
- Check the Client Authority checkbox on the component.
|
||||
- Update input and control scripts to respect `isLocalPlayer`
|
||||
- Override OnStartLocalPlayer to take control of the Main Camera in the scene for the player.
|
||||
|
||||
For example, this script only processes input for the local player:
|
||||
|
||||
``` cs
|
||||
using UnityEngine;
|
||||
using Mirror;
|
||||
|
||||
public class Controls : NetworkBehaviour
|
||||
{
|
||||
void Update()
|
||||
{
|
||||
if (!isLocalPlayer)
|
||||
{
|
||||
// exit from update if this is not the local player
|
||||
return;
|
||||
}
|
||||
|
||||
// handle player input for movement
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Basic player game state
|
||||
- Make scripts that contain important data into NetworkBehaviours instead of MonoBehaviours
|
||||
- Make important member variables into SyncVars
|
||||
|
||||
See [State Synchronization](../Guides/Sync/index.md).
|
||||
|
||||
## Networked actions
|
||||
- Make scripts that perform important actions into NetworkBehaviours instead of MonoBehaviours
|
||||
- Update functions that perform important player actions to be commands
|
||||
|
||||
See [Networked Actions](../Guides/Communications/index.md).
|
||||
|
||||
## Non-player game objects
|
||||
|
||||
Fix non-player prefabs such as enemies:
|
||||
- Add the NetworkIdentify component
|
||||
- Add the NetworkTransform component
|
||||
- Register spawnable Prefabs with the NetworkManager
|
||||
- Update scripts with game state and actions
|
||||
|
||||
## Spawners
|
||||
- Potentially change spawner scripts to be NetworkBehaviours
|
||||
- Modify spawners to only run on the server (use isServer property or the `OnStartServer()` function)
|
||||
- Call `NetworkServer.Spawn()` for created game objects
|
||||
|
||||
## Spawn positions for players
|
||||
- Add a new game object and place it at player’s start location
|
||||
- Add the NetworkStartPosition component to the new game object
|
@ -1,8 +0,0 @@
|
||||
# Support
|
||||
|
||||
## Discord
|
||||
- You can find us on [Discord](https://discord.gg/2BvnM4R).
|
||||
|
||||
## GitHub
|
||||
- You can create an issue in [GitHub](https://github.com/vis2k/Mirror/issues)
|
||||
- You can also contribute with Pull Requests...see [Contributing](https://github.com/vis2k/Mirror/blob/master/CONTRIBUTING.md)
|
@ -1,55 +0,0 @@
|
||||
# TCP vs UDP
|
||||
|
||||
TCP and UDP are protocol used to send information over the internet.
|
||||
|
||||
Key difference between UDP and TCP
|
||||
- TCP has higher latency, reliable
|
||||
- UDP has lower latency, unreliable
|
||||
|
||||
|
||||
## [TCP (Transmission Control Protocol)](https://en.wikipedia.org/wiki/Transmission_Control_Protocol)
|
||||
|
||||
TCP is the most popular protocol on the internet. TCP is used for HTTP, SSH, FTP, and many more.
|
||||
|
||||
TCP features make it easy for programers to work with TCP but at the cost of latency.
|
||||
|
||||
TCP is better for slower paced games where latency isn't important.
|
||||
|
||||
#### Key features include
|
||||
|
||||
* **Reliable:** Applications don't have to worry about missing packets. If a packet gets lost, TCP will resend it. All data is either transmitted successfully or you get an error and the connection is closed.
|
||||
* **Sequenced:** TCP guarantees that every message will arrive in the same order it was sent. If you send "a" then "b" you will receive "a" then "b" on the other side as well.
|
||||
* **Connection oriented:** TCP has the concept of a connection. A connection will say open until either the client or server decides to close it. Both the client and server get notified when the connection ends.
|
||||
* **Congestion control:** If a server is being overwhelmed, TCP will throttle the data to avoid congestion collapse.
|
||||
|
||||
|
||||
#### Transports
|
||||
|
||||
* [Telepathy](https://mirror-networking.com/docs/Articles/Transports/Telepathy.html)
|
||||
* [Apathy](https://mirror-networking.com/apathy/)
|
||||
* [WebGL](https://mirror-networking.com/docs/Articles/Transports/WebSockets.html)
|
||||
|
||||
## [UDP (User Datagram Protocol)](https://en.wikipedia.org/wiki/User_Datagram_Protocol)
|
||||
|
||||
UDP is used for real time applications such as fast paced action games or voice over ip, where low latency is more important than reliability.
|
||||
|
||||
UDP features allow a greater control of how data is sent allowing non-critical data to be send faster.
|
||||
|
||||
UDP is better for fast paced games where latency is important and if a few packets are lost the game can recover.
|
||||
|
||||
#### Key features include
|
||||
|
||||
* **Low Latency:** UDP is faster because it doesn't need to wait for acknowledge packets, instead it can send keep sending new pacakges one after the other.
|
||||
* **Channel support:** Channels allow for different delivery types. One channel can be used for critical data that needs to get to the destination, while a different channel can just be specified by send and forget without any reliability.
|
||||
* **Different packet types:** Reliable Ordered, Reliable Unordered, Unreliable, and more depending on the implementation
|
||||
|
||||
#### Transports
|
||||
|
||||
* [Ignorance](https://mirror-networking.com/docs/Articles/Transports/Ignorance.html)
|
||||
* [LiteNetLib](https://mirror-networking.com/docs/Articles/Transports/LiteNetLib4Mirror.html)
|
||||
|
||||
## The choice is yours
|
||||
|
||||
Mirror is transport independent, they can simply by added to your NetworkManager GameObject. Mirror comes with 2 built in transports to pick from, [Telepathy](../Transports/Telepathy.md) and [Ninja WebSockets](../Transports/WebSockets.md). See the [transports](../Transports/index.md) page for more about transports.
|
||||
|
||||
Pick whatever works best for you. We recommend you profile your game and collect real world numbers before you make a final decision.
|
@ -1,54 +0,0 @@
|
||||
# General Overview
|
||||
|
||||
Mirror’s multiplayer High Level API (HLAPI) is a system for building multiplayer capabilities for Unity games. It is built on top of the lower level transport real-time communication layer, and handles many of the common tasks that are required for multiplayer games. While the transport layer supports any kind of network topology, the HLAPI is a server authoritative system; although it allows one of the participants to be a client and the server at the same time, so no dedicated server process is required. Working in conjunction with the internet services, this allows multiplayer games to be played over the internet with little work from developers.
|
||||
|
||||
The HLAPI is focused on ease of use and iterative development and provides useful functionality for multiplayer games, such as:
|
||||
- Message handlers
|
||||
- General purpose high performance serialization
|
||||
- Distributed object management
|
||||
- State synchronization
|
||||
- Network classes: Server, Client, Connection, etc
|
||||
|
||||
The HLAPI is built from a series of layers that add functionality:
|
||||
|
||||
![Network Layers](NetworkLayers.jpg)
|
||||
|
||||
## Server and Host
|
||||
|
||||
In Mirror’s High Level API (HLAPI) system, multiplayer games include:
|
||||
- **Server**
|
||||
A server is an instance of the game which all other players connect to when they want to play together. A server often manages various aspects of the game, such as keeping score, and transmit that data back to the client.
|
||||
- **Clients**
|
||||
Clients are instances of the game that usually connect from different computers to the server. Clients can connect over a local network, or online.
|
||||
|
||||
A client is an instance of the game that connects to the server, so that the person playing it can play the game with other people, who connect on their own clients.
|
||||
|
||||
The server might be either a “dedicated server”, or a “host server”.
|
||||
- **Dedicated server**
|
||||
This is an instance of the game that only runs to act as a server.
|
||||
- **Host server**
|
||||
When there is no dedicated server, one of the clients also plays the role of the server. This client is the “host server”. The host server creates a single instance of the game (called the host), which acts as both server and client.
|
||||
|
||||
The diagram below represents three players in a multiplayer game. In this game, one client is also acting as host, which means the client itself is the “local client”. The local client connects to the host server, and both run on the same computer. The other two players are remote clients - that is, they are on different computers, connected to the host server.
|
||||
|
||||
![This diagram shows two remote clients connected to a host.](NetworkHost.png)
|
||||
|
||||
The host is a single instance of your game, acting as both server and client at the same time. The host uses a special kind of internal client for local client communication, while other clients are remote clients. The local client communicates with the server through direct function calls and message queues, because it is in the same process. It actually shares the Scene with the server. Remote clients communicate with the server over a regular network connection. When you use Mirror’s HLAPI, this is all handled automatically for you.
|
||||
|
||||
One of the aims of the multiplayer system is for the code for local clients and remote clients to be the same, so that you only have to think about one type of client most of the time when developing your game. In most cases, Mirror handles this difference automatically, so you should rarely need to think about the difference between your code running on a local client or a remote client.
|
||||
|
||||
## Instantiate and Spawn
|
||||
|
||||
When you make a single player game In Unity, you usually use the `GameObject.Instantiate` method to create new game objects at runtime. However, with a multiplayer system, the server itself must “spawn” game objects in order for them to be active within the networked game. When the server spawns game objects, it triggers the creation of game objects on connected clients. The spawning system manages the lifecycle of the game object, and synchronizes the state of the game object based on how you set the game object up.
|
||||
|
||||
For more details about networked instantiating and spawning, see documentation on Spawning [game objects](../Guides/GameObjects/index.md).
|
||||
|
||||
## Players and Local Players
|
||||
|
||||
Mirror’s multiplayer HLAPI system handles player game objects differently to non-player game objects. When a new player joins the game (when a new client connects to the server), that player’s game object becomes a “local player” game object on the client of that player, and Mirror associates the player’s connection with the player’s game object. Mirror associates one player game object for each person playing the game, and routes networking commands to that individual game object. A player cannot invoke a command on another player’s game object, only their own.
|
||||
|
||||
For more details, see documentation on Player [game objects](../Guides/GameObjects/index.md).
|
||||
|
||||
## Authority
|
||||
|
||||
Servers and clients can both manage a game object’s behavior. The concept of “authority” refers to how and where a game object is managed. Mirror’s HLAPI is based around “server authority” as the default state, where the Server has authority over all game objects. Player game objects are a special case and treated as having “local authority”. You may want to build your game using a different system of authority - for more details, see [Network Authority](../Guides/Authority.md).
|
Before Width: | Height: | Size: 18 KiB |
Before Width: | Height: | Size: 24 KiB |
Before Width: | Height: | Size: 16 KiB |
Before Width: | Height: | Size: 22 KiB |
@ -1,20 +0,0 @@
|
||||
- name: Overview
|
||||
href: index.md
|
||||
- name: Getting Started
|
||||
href: Start.md
|
||||
- name: Script Templates
|
||||
href: ScriptTemplates.md
|
||||
- name: Migration Guide
|
||||
href: Migration.md
|
||||
- name: Deprecations
|
||||
href: Deprecations.md
|
||||
- name: ChangeLog
|
||||
href: ChangeLog.md
|
||||
- name: Showcase
|
||||
href: https://mirror-networking.com/showcase/
|
||||
- name: Integrations
|
||||
href: Integrations/index.md
|
||||
- name: TCP vs UDP
|
||||
href: TCPvsUDP.md
|
||||
- name: Support
|
||||
href: Support.md
|
@ -1,42 +0,0 @@
|
||||
# Attributes Overview
|
||||
|
||||
Networking attributes are added to member functions of NetworkBehaviour scripts, to make them run on either the client or server.
|
||||
|
||||
These attributes can be used for Unity game loop methods like Start or Update, as well as other implemented methods.
|
||||
|
||||
> **NOTE**: when using abstract or virtual methods the Attributes need to be applied to the override methods too.
|
||||
|
||||
- **NetworkSettings**
|
||||
This attribute has been deprecated because `channels` were moved to transports (where applicable) and `interval` was moved to an inspector property
|
||||
- **Server**
|
||||
Only a server can call the method (throws a warning or an error when called on a client).
|
||||
- **ServerCallback**
|
||||
Same as **Server** but does not throw warning when called on client.
|
||||
- **Client**
|
||||
Only a Client can call the method (throws a warning or an error when called on the server).
|
||||
- **ClientCallback**
|
||||
Same as **Client** but does not throw warning when called on server.
|
||||
- **ClientRpc**
|
||||
The server uses a Remote Procedure Call (RPC) to run that function on clients. See also: [Remote Actions](Communications/RemoteActions.md)
|
||||
- **TargetRpc**
|
||||
This is an attribute that can be put on methods of NetworkBehaviour classes to allow them to be invoked on clients from a server. Unlike the ClientRpc attribute, these functions are invoked on one individual target client, not all of the ready clients. See also: [Remote Actions](Communications/RemoteActions.md)
|
||||
- **Command**
|
||||
Call this from a client to run this function on the server. Make sure to validate input etc. It's not possible to call this from a server. Use this as a wrapper around another function, if you want to call it from the server too. See also [Remote Actions](Communications/RemoteActions.md)
|
||||
The allowed argument types are:
|
||||
|
||||
- Basic type (byte, int, float, string, UInt64, etc)
|
||||
|
||||
- Built-in Unity math type (Vector3, Quaternion, etc),
|
||||
|
||||
- Arrays of basic types
|
||||
|
||||
- Structs containing allowable types
|
||||
|
||||
- NetworkIdentity
|
||||
|
||||
- Game object with a NetworkIdentity component attached.
|
||||
- **SyncVar**
|
||||
[SyncVars](Sync/SyncVars.md) are used to synchronize a variable from the server to all clients automatically. Don't assign them from a client, it's pointless. Don't let them be null, you will get errors. You can use int, long, float, string, Vector3 etc. (all simple types) and NetworkIdentity and game object if the game object has a NetworkIdentity attached to it. You can use [hooks](Sync/SyncVarHook.md).
|
||||
- **SyncEvent (Obsolete)**
|
||||
[SyncEvent](Sync/SyncEvent.md) are networked events like ClientRpc's, but instead of calling a function on the game object, they trigger Events instead.
|
||||
**IMPORTANT:** removed in version 18.0.0, see this [Issue](https://github.com/vis2k/Mirror/pull/2178) for more information.
|
@ -1,75 +0,0 @@
|
||||
# Network Authority
|
||||
|
||||
Authority is a way of deciding who owns an object and has control over it.
|
||||
|
||||
|
||||
## Server Authority
|
||||
|
||||
Server authority means that the server has control of an object. Server has authority over an object by default. This means the server would manage and control of all collectible items, moving platforms, NPCs, and any other networked objects that aren't the player.
|
||||
|
||||
## Client Authority
|
||||
|
||||
Client authority means that the client has control of an object.
|
||||
|
||||
When a client has authority over an object it means that they can call [Commands](Communications/RemoteActions.md) and that the object will automatically be destroyed when the client disconnects.
|
||||
|
||||
Even if a client has authority over an object the server still controls SyncVar and control other serialization features. A component will need to use a [Commands](Communications/RemoteActions.md) to update the state on the server in order for it to sync to other clients.
|
||||
|
||||
|
||||
## How to give authority
|
||||
|
||||
By default the server has Authority over all objects. The server can give authority to objects that a client needs to control, like the player object.
|
||||
|
||||
If you spawn a player object using `NetworkServer.AddPlayerForConnection` then it will automatically be given authority.
|
||||
|
||||
|
||||
### Using NetworkServer.Spawn
|
||||
|
||||
You can give authority to a client when an object is spawned. This is done by passing in the connection to the spawn message
|
||||
```cs
|
||||
GameObject go = Instantiate(prefab);
|
||||
NetworkServer.Spawn(go, connectionToClient);
|
||||
```
|
||||
|
||||
### Using identity.AssignClientAuthority
|
||||
|
||||
You can give authority to a client any time using `AssignClientAuthority`. This can be done by calling `AssignClientAuthority` on the object you want to give authority too
|
||||
```cs
|
||||
identity.AssignClientAuthority(conn);
|
||||
```
|
||||
|
||||
You may want to do this when a player picks up an item
|
||||
|
||||
```cs
|
||||
// Command on player object
|
||||
void CmdPickupItem(NetworkIdentity item)
|
||||
{
|
||||
item.AssignClientAuthority(connectionToClient);
|
||||
}
|
||||
```
|
||||
|
||||
## How to remove authority
|
||||
|
||||
You can use `identity.RemoveClientAuthority` to remove client authority from an object.
|
||||
|
||||
```cs
|
||||
identity.RemoveClientAuthority();
|
||||
```
|
||||
|
||||
Authority can't be removed from the player object. Instead you will have to replace the player object using `NetworkServer.ReplacePlayerForConnection`.
|
||||
|
||||
|
||||
## On Authority
|
||||
|
||||
When authority is given to or removed from an object a message will be sent to that client to notify them. This will cause the `OnStartAuthority` or `OnStopAuthority` functions to be called.
|
||||
|
||||
|
||||
## Check Authority
|
||||
|
||||
### Client Side
|
||||
|
||||
The `identity.hasAuthority` property can be used to check if the local player has authority over an object.
|
||||
|
||||
### Server Side
|
||||
|
||||
The `identity.connectionToClient` property can be check to see which client has authority over an object. If it is null then the server has authority.
|