docs: switch to docfx for documentation (#1026)
* Moved doc files to docfx folder * load csproj * doc generation * Run docfx * Add docfx * Deploy docs to mirror-networking.com * use deploy phase * deploy whole generated site * Fixed the semantic release command * Is last \ required? * show debug log * using lftp for site deploy * Testing lftp * Show current folder * try -e command option * Show me the files * use plain ftp * use choco install instead of cinst * fix ssl certificate validation * fix username * Upload site to xmldocs folder * no need to archive docs * No need for debug output * Fix file permissions * show me .htaccess * Show me contents * Wipe out folder to fix permissions * Set file permissions * Fix file permissions * complete toc list * Migrated intro page * Remove old docs * Update link to docs * Add link to github * Only update docs for stuff in master * This is a powershell command * Update doc/articles/Concepts/Communications/RemoteActions.md * Update doc/articles/Concepts/VisibilityCustom.md * Update doc/articles/Concepts/Authority.md * Update doc/articles/Concepts/GameObjects/SpawnObjectCustom.md * Update doc/articles/Concepts/Authority.md * Update doc/articles/Classes/SyncVars.md * No need to run semver twice
11
Assets/Mirror/Runtime/doc.csproj
Normal file
@ -0,0 +1,11 @@
|
||||
<Project Sdk="Microsoft.NET.Sdk.Web">
|
||||
<PropertyGroup>
|
||||
<TargetFramework>netstandard2.0</TargetFramework>
|
||||
</PropertyGroup>
|
||||
|
||||
<ItemGroup>
|
||||
<!-- your static content you like to publish -->
|
||||
<Content Include="Assets\Mirror\**\*.*" />
|
||||
</ItemGroup>
|
||||
|
||||
</Project>
|
@ -1,7 +1,7 @@
|
||||
![Mirror Logo](https://i.imgur.com/aZRKBeh.png)
|
||||
|
||||
[![Download](https://img.shields.io/badge/asset_store-brightgreen.svg)](https://www.assetstore.unity3d.com/#!/content/129321)
|
||||
[![Documentation](https://img.shields.io/badge/documentation-brightgreen.svg)](https://vis2k.github.io/Mirror/)
|
||||
[![Documentation](https://img.shields.io/badge/documentation-brightgreen.svg)](https://mirror-networking.com/xmldocs)
|
||||
[![Forum](https://img.shields.io/badge/forum-brightgreen.svg)](https://forum.unity.com/threads/mirror-networking-for-unity-aka-hlapi-community-edition.425437/)
|
||||
[![donate](https://img.shields.io/badge/donations-brightgreen.svg)](https://www.patreon.com/MirrorNetworking)
|
||||
[![Build status](https://img.shields.io/appveyor/ci/vis2k73562/hlapi-community-edition/Mirror.svg)](https://ci.appveyor.com/project/vis2k73562/hlapi-community-edition/branch/mirror)
|
||||
|
24
appveyor.yml
@ -7,14 +7,11 @@ version: '{branch}-{build}'
|
||||
# - ps: $blockRdp = $true; iex ((new-object net.webclient).DownloadString('https://raw.githubusercontent.com/appveyor/ci/master/scripts/enable-rdp.ps1'))
|
||||
|
||||
install:
|
||||
- set PATH=C:\Ruby25-x64\bin;%PATH%
|
||||
- cd docs
|
||||
- gem install bundler -v 1.17.3
|
||||
- bundle install
|
||||
- cd ..
|
||||
- cp c:\Tools\curl\bin\libcurl.dll C:\Ruby25-x64\bin
|
||||
- choco install unitypackager
|
||||
|
||||
- choco install docfx
|
||||
- choco install lftp
|
||||
- npm install -g semantic-release@15
|
||||
|
||||
#build:
|
||||
# project: Mirror/Networking.sln
|
||||
# verbosity: minimal
|
||||
@ -23,10 +20,8 @@ install:
|
||||
skip_tags: true
|
||||
|
||||
build_script:
|
||||
- cd docs
|
||||
- bundle exec jekyll build
|
||||
- ruby checksite.rb
|
||||
- cd ..
|
||||
- docfx metadata doc\docfx.json
|
||||
- docfx build doc\docfx.json
|
||||
|
||||
after_build:
|
||||
- RMDIR /Q /S Assets\Mirror\Tests
|
||||
@ -40,8 +35,11 @@ artifacts:
|
||||
|
||||
image: Visual Studio 2017
|
||||
|
||||
before_deploy:
|
||||
- npm install -g semantic-release@15
|
||||
environment:
|
||||
LFTP_PASSWORD:
|
||||
secure: sH23IC4a98S5uTtgYNHNvg==
|
||||
|
||||
deploy_script:
|
||||
- semantic-release
|
||||
- ps: IF ($env:APPVEYOR_REPO_BRANCH -eq "master") { lftp -e 'set ftp:ssl-allow no ; mirror -R -c -e -p doc/_site public_html/xmldocs; chmod -R a+X public_html/xmldocs ; ls -l public_html/xmldocs/ ; ls -l public_html/xmldocs/styles/ ; bye' -u mirreofx --env-password ftp://mirror-networking.com }
|
||||
|
||||
|
9
doc/.gitignore
vendored
Normal file
@ -0,0 +1,9 @@
|
||||
###############
|
||||
# folder #
|
||||
###############
|
||||
/**/DROP/
|
||||
/**/TEMP/
|
||||
/**/packages/
|
||||
/**/bin/
|
||||
/**/obj/
|
||||
_site
|
5
doc/api/.gitignore
vendored
Normal file
@ -0,0 +1,5 @@
|
||||
###############
|
||||
# temp file #
|
||||
###############
|
||||
*.yml
|
||||
.manifest
|
2
doc/api/index.md
Normal file
@ -0,0 +1,2 @@
|
||||
# PLACEHOLDER
|
||||
TODO: Add .NET projects to the *src* folder and run `docfx` to generate **REAL** *API Documentation*!
|
@ -20,13 +20,13 @@ These attributes can be used for Unity game loop methods like Start or Update, a
|
||||
A Custom Attribute that can be added to member functions of NetworkBehaviour scripts, to make them only run on clients, but not generate warnings.
|
||||
|
||||
- **ClientRpc**
|
||||
The server uses a Remote Procedure Call (RPC) to run that function on clients. See also: [Remote Actions](../Concepts/Communications/RemoteActions)
|
||||
The server uses a Remote Procedure Call (RPC) to run that function on clients. See also: [Remote Actions](../Concepts/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](../Concepts/Communications/RemoteActions)
|
||||
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](../Concepts/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](../Concepts/Communications/RemoteActions)
|
||||
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](../Concepts/Communications/RemoteActions.md)
|
||||
The allowed argument types are:
|
||||
|
||||
- Basic type (byte, int, float, string, UInt64, etc)
|
||||
@ -42,7 +42,7 @@ These attributes can be used for Unity game loop methods like Start or Update, a
|
||||
- Game object with a NetworkIdentity component attached.
|
||||
|
||||
- **SyncVar**
|
||||
[SyncVars](SyncVars) 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](SyncVarHook).
|
||||
[SyncVars](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](SyncVarHook.md).
|
||||
|
||||
- **SyncEvent**
|
||||
[SyncEvents](SyncEvents) are networked events like ClientRpc's, but instead of calling a function on the game object, they trigger Events instead.
|
||||
[SyncEvent](SyncEvent.md) are networked events like ClientRpc's, but instead of calling a function on the game object, they trigger Events instead.
|
@ -100,7 +100,7 @@ The `Server` and `Client` attributes are for your own custom callback functions.
|
||||
|
||||
The `ServerCallback` and `ClientCallback` attributes are for built-in callback functions that are called automatically by Mirror. These attributes do not cause a warning to be generated.
|
||||
|
||||
For more information, see [Attributes](Attributes).
|
||||
For more information, see [Attributes](Attributes.md).
|
||||
|
||||
## Commands
|
||||
|
||||
@ -120,7 +120,7 @@ Commands are called just by invoking the function normally on the client. Instea
|
||||
|
||||
Commands are type-safe, have built-in security and routing to the player, and use an efficient serialization mechanism for the arguments to make calling them fast.
|
||||
|
||||
See [Communications](../Concepts/Communications) and related sections for more information.
|
||||
See [Communications](../Concepts/Communications/index.md) and related sections for more information.
|
||||
|
||||
## Client RPC Calls
|
||||
|
||||
@ -134,7 +134,7 @@ To define a Client RPC call in your code, you must write a function which:
|
||||
|
||||
- Has the `ClientRPC` attribute
|
||||
|
||||
See [Communications](../Concepts/Communications) and related sections for more information.
|
||||
See [Communications](../Concepts/Communications/index.md) and related sections for more information.
|
||||
|
||||
## Networked Events
|
||||
|
||||
@ -152,6 +152,6 @@ You can use events to build powerful networked game systems that can be extended
|
||||
|
||||
SyncEvent is the base class that Commands and ClientRpc calls are derived from. You can use the SyncEvent attribute on your own functions to make your own event-driven networked game play code. Using SyncEvent, you can extend Mirror’s Multiplayer features to better fit your own programming patterns.
|
||||
|
||||
See [SyncEvents](SyncEvent) for more details.
|
||||
See [SyncEvents](SyncEvent.md) for more details.
|
||||
|
||||
|
@ -26,7 +26,7 @@
|
||||
The IP address of the server this client is connected to.
|
||||
|
||||
- **serverPort**
|
||||
Deprecated. Port was moved to the [Transports](../Transports) that support it.
|
||||
Deprecated. Port was moved to the [Transports](../Transports/index.md) that support it.
|
||||
|
||||
## Methods
|
||||
|
@ -22,7 +22,7 @@ Network Connection is a high-level API class that encapsulates a network connect
|
||||
The incremented connectionId for this connection.
|
||||
|
||||
- **hostId**
|
||||
Deprecated. Use `connection.GetType() == typeof(NetworkConnection)` to check if it's a regular or local connection.
|
||||
Deprecated. Use `connection.GetType() == typeof(NetworkConnection.md)` to check if it's a regular or local connection.
|
||||
|
||||
- **isReady**
|
||||
Flag to control whether state updates are sent to this connection
|
||||
@ -31,7 +31,7 @@ Network Connection is a high-level API class that encapsulates a network connect
|
||||
The last time that a message was received on this connection.
|
||||
|
||||
- **playerController**
|
||||
A reference to the [NetworkIdentity](../Components/NetworkIdentity) playerController.
|
||||
A reference to the [NetworkIdentity](../Components/NetworkIdentity.md) playerController.
|
||||
|
||||
## Methods
|
||||
|
@ -12,7 +12,7 @@ A SyncDictionary is an associative array containing an unordered list of key, va
|
||||
|
||||
- Struct with any of the above
|
||||
|
||||
SyncDictionary works much like [SyncLists](SyncLists): when you make a change on the server the change is propagated to all clients and the Callback is called.
|
||||
SyncDictionary works much like [SyncLists](SyncLists.md): when you make a change on the server the change is propagated to all clients and the Callback is called.
|
||||
|
||||
|
||||
To use it, create a class that derives from SyncDictionary for your specific type. This is necessary because the Weaver will add methods to that class. Then add a field to your NetworkBehaviour class.
|
@ -26,4 +26,4 @@ The server automatically sends SyncVar updates when the value of a SyncVar chang
|
||||
|
||||
## SyncVar Hooks
|
||||
|
||||
The [SyncVar hook](SyncVarHook) attribute can be used to specify a method to be called when the SyncVar changes value on the client.
|
||||
The [SyncVar hook](SyncVarHook.md) attribute can be used to specify a method to be called when the SyncVar changes value on the client.
|
Before Width: | Height: | Size: 45 KiB After Width: | Height: | Size: 45 KiB |
@ -2,35 +2,35 @@
|
||||
|
||||
Mirror includes the following classes:
|
||||
|
||||
- [NetworkServer](NetworkServer)
|
||||
- [NetworkServer](NetworkServer.md)
|
||||
Network Server is a High-Level-API class that manages connections from multiple clients.
|
||||
|
||||
- [NetworkClient](NetworkClient)
|
||||
- [NetworkClient](NetworkClient.md)
|
||||
Network Client is a high-level API class that manages a network connection from a client to a server, and can send and receive messages between the client and the server.
|
||||
|
||||
- [NetworkConnection](NetworkConnection)
|
||||
- [NetworkConnection](NetworkConnection.md)
|
||||
Network Connection is a high-level API class that encapsulates a network connection.
|
||||
|
||||
- [NetworkBehavior](NetworkBehavior)
|
||||
- [NetworkBehaviour](NetworkBehaviour.md)
|
||||
Network Behaviour scripts work with game objects that have a NetworkIdentity component. These scripts can perform high-level API functions such as Commands, ClientRpc’s, SyncEvents and SyncVars.
|
||||
|
||||
- [Attributes](Attributes)
|
||||
- [Attributes](Attributes.md)
|
||||
Networking attributes are added to member functions of NetworkBehaviour scripts, to make them run on either the client or server.
|
||||
|
||||
- [SyncVars](SyncVars)
|
||||
- [SyncVars](SyncVars.md)
|
||||
SyncVars are variables of scripts that inherit from NetworkBehaviour, which are synchronized from the server to clients.
|
||||
|
||||
- [SyncEvents](SyncEvent)
|
||||
- [SyncEvents](SyncEvent.md)
|
||||
SyncEvents are networked events like ClientRpc’s, but instead of calling a function on the game object, they trigger Events instead.
|
||||
|
||||
- [SyncLists](SyncLists)
|
||||
- [SyncLists](SyncLists.md)
|
||||
SyncLists contain lists of values and synchronize data from servers to clients.
|
||||
|
||||
- [SyncDictionary](SyncDictionary)
|
||||
- [SyncDictionary](SyncDictionary.md)
|
||||
A SyncDictionary is an associative array containing an unordered list of key, value pairs.
|
||||
|
||||
- [SyncHashSet](SyncHashSet)
|
||||
- [SyncHashSet](SyncHashSet.md)
|
||||
An unordered set of values that do not repeat.
|
||||
|
||||
- [SyncSortedSet](SyncSortedSet)
|
||||
- [SyncSortedSet](SyncSortedSet.md)
|
||||
A sorted set of values tha do not repeat.
|
24
doc/articles/Classes/toc.yml
Normal file
@ -0,0 +1,24 @@
|
||||
- name: NetworkServer
|
||||
href: NetworkServer.md
|
||||
- name: NetworkConnection
|
||||
href: NetworkConnection.md
|
||||
- name: NetworkClient
|
||||
href: NetworkClient.md
|
||||
- name: NetworkBehaviour
|
||||
href: NetworkBehaviour.md
|
||||
- name: Attributes
|
||||
href: Attributes.md
|
||||
- name: SyncVars
|
||||
href: SyncVars.md
|
||||
- name: SyncVar Hooks
|
||||
href: SyncVarHook.md
|
||||
- name: SyncEvents
|
||||
href: SyncEvent.md
|
||||
- name: SyncLists
|
||||
href: SyncLists.md
|
||||
- name: SyncDictionary
|
||||
href: SyncDictionary.md
|
||||
- name: SyncHashSet
|
||||
href: SyncHashSet.md
|
||||
- name: SyncSortedSet
|
||||
href: SyncSortedSet.md
|
Before Width: | Height: | Size: 38 KiB After Width: | Height: | Size: 38 KiB |
Before Width: | Height: | Size: 34 KiB After Width: | Height: | Size: 34 KiB |
Before Width: | Height: | Size: 218 KiB After Width: | Height: | Size: 218 KiB |
Before Width: | Height: | Size: 20 KiB After Width: | Height: | Size: 20 KiB |
@ -15,13 +15,13 @@ If none of these options is checked, the server will have authority over the obj
|
||||
|
||||
With the Unity’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](../Concepts/GameObjects/SpawnObject) for more information.
|
||||
You must put a Network Identity component on any Prefabs that spawn at runtime for the network system to use them. See [Object Spawning](../Concepts/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](../Concepts/GameObjects/SceneObjects) for more information.
|
||||
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](../Concepts/GameObjects/SceneObjects.md) for more information.
|
||||
|
||||
## Preview Pane Information
|
||||
|
Before Width: | Height: | Size: 5.3 KiB After Width: | Height: | Size: 5.3 KiB |
Before Width: | Height: | Size: 16 KiB After Width: | Height: | Size: 16 KiB |
Before Width: | Height: | Size: 43 KiB After Width: | Height: | Size: 43 KiB |
@ -2,7 +2,7 @@
|
||||
|
||||
\*\*Please see the Lobby example in the Examples folder in your Mirror folder
|
||||
|
||||
The Network Lobby Manager is a specialized type of [Network Manager](NetworkManager) that provides a multiplayer lobby before entering the main play scene of the game. It allows you to set up a network with:
|
||||
The Network Lobby Manager is a specialized type of [Network Manager](NetworkManager.md) that provides a multiplayer lobby before entering the main play scene of the game. It allows you to set up a network with:
|
||||
|
||||
- A maximum player limit
|
||||
|
||||
@ -26,7 +26,7 @@ There are two types of player objects with the Network Lobby Manager:
|
||||
|
||||
- Handles commands in the lobby
|
||||
|
||||
- Must use the [Network Lobby Player](NetworkLobbyPlayer) component
|
||||
- Must use the [Network Lobby Player](NetworkLobbyPlayer.md) component
|
||||
|
||||
**Player Prefab**
|
||||
|
Before Width: | Height: | Size: 22 KiB After Width: | Height: | Size: 22 KiB |
@ -1,6 +1,6 @@
|
||||
# NetworkLobbyPlayer
|
||||
|
||||
The Network Lobby Player stores per-player state for the [Network Lobby Manager](NetworkLobbyManager) while in the lobby. 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.
|
||||
The Network Lobby Player stores per-player state for the [Network Lobby Manager](NetworkLobbyManager.md) while in the lobby. 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 Lobby Player component must also have a Network Identity component. When you create a Network Lobby Player component on a game object, Unity also creates a Network Identity component on that game object if it does not already have one.
|
||||
|
@ -30,7 +30,7 @@ If you are already familiar with multiplayer game development, you might find it
|
||||
|
||||
Mirror's 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) for more information.
|
||||
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
|
||||
|
||||
@ -70,7 +70,7 @@ If you have one Network Manager that is persisted through scenes via Don't Destr
|
||||
|
||||
## 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) components.
|
||||
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.
|
||||
|
||||
@ -100,7 +100,7 @@ You should normally make sure the Network Manager persists between Scenes, other
|
||||
|
||||
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.
|
||||
|
||||
See [Application](../Events/Application), [Server](../Events/Server), [Client](../Events/Client), and [Other](../Events/Other) events for more information.
|
||||
See [Application](../Events/Application.md), [Server](../Events/Server.md), [Client](../Events/Client.md), and [Other](../Events/Other.md) events for more information.
|
||||
|
||||
## Properties
|
||||
|
Before Width: | Height: | Size: 7.1 KiB After Width: | Height: | Size: 7.1 KiB |
Before Width: | Height: | Size: 5.7 KiB After Width: | Height: | Size: 5.7 KiB |
Before Width: | Height: | Size: 3.6 KiB After Width: | Height: | Size: 3.6 KiB |
Before Width: | Height: | Size: 11 KiB After Width: | Height: | Size: 11 KiB |
Before Width: | Height: | Size: 4.6 KiB After Width: | Height: | Size: 4.6 KiB |
Before Width: | Height: | Size: 38 KiB After Width: | Height: | Size: 38 KiB |
Before Width: | Height: | Size: 7.9 KiB After Width: | Height: | Size: 7.9 KiB |
Before Width: | Height: | Size: 10 KiB After Width: | Height: | Size: 10 KiB |
Before Width: | Height: | Size: 56 KiB After Width: | Height: | Size: 56 KiB |
Before Width: | Height: | Size: 24 KiB After Width: | Height: | Size: 24 KiB |
Before Width: | Height: | Size: 28 KiB After Width: | Height: | Size: 28 KiB |
@ -2,31 +2,31 @@
|
||||
|
||||
General description of Components
|
||||
|
||||
- [NetworkManager](NetworkManager)
|
||||
- [NetworkManager](NetworkManager.md)
|
||||
The Network Manager is a component for managing the networking aspects of a multiplayer game.
|
||||
- [NetworkLobbyManager](NetworkLobbyManager)
|
||||
- [NetworkLobbyManager](NetworkLobbyManager.md)
|
||||
The Network Lobby Manager is an extension component of Network Manager that provides a basic functional lobby.
|
||||
- [NetworkLobbyPlayer](NetworkLobbyPlayer)
|
||||
- [NetworkLobbyPlayer](NetworkLobbyPlayer.md)
|
||||
The Network Lobby Player is a component that's required on Player prefabs used in the Lobby Scene with the Network Lobby Manager above.
|
||||
- [NetworkManagerHUD](NetworkManagerHUD)
|
||||
- [NetworkManagerHUD](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.
|
||||
- [NetworkIdentity](NetworkIdentity)
|
||||
- [NetworkIdentity](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.
|
||||
- [NetworkStartPosition](NetworkStartPosition)
|
||||
- [NetworkStartPosition](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.
|
||||
- [NetworkProximityChecker](NetworkProximityChecker)
|
||||
- [NetworkProximityChecker](NetworkProximityChecker.md)
|
||||
The Network Proximity Checker component controls the visibility of game objects for network clients, based on proximity to players.
|
||||
- [NetworkTransform](NetworkTransform)
|
||||
- [NetworkTransform](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.
|
||||
- [NetworkTransformChild](NetworkTransformChild)
|
||||
- [NetworkTransformChild](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.
|
||||
- [NetworkAnimator](NetworkAnimator)
|
||||
- [NetworkAnimator](NetworkAnimator.md)
|
||||
The Network Animator component allows you to synchronize animation states for networked objects. It synchronizes state and parameters from an Animator Controller.
|
||||
- [NetworkNavMeshAgent](NetworkNavMeshAgent)
|
||||
- [NetworkNavMeshAgent](NetworkNavMeshAgent.md)
|
||||
Coming Soon
|
||||
- [NetworkController](NetworkController)
|
||||
- [NetworkController](NetworkController.md)
|
||||
Coming Soon
|
||||
- [NetworkRigidbody](NetworkRigidbody)
|
||||
- [NetworkRigidbody](NetworkRigidbody.md)
|
||||
Coming Soon
|
||||
|
||||
|
26
doc/articles/Components/toc.yml
Normal file
@ -0,0 +1,26 @@
|
||||
- name: NetworkManager
|
||||
href: NetworkManager.md
|
||||
- name: NetworkLobbyManager
|
||||
href: NetworkLobbyManager.md
|
||||
- name: NetworkLobbyPlayer
|
||||
href: NetworkLobbyPlayer.md
|
||||
- name: NetworkManagerHUD
|
||||
href: NetworkManagerHUD.md
|
||||
- name: NetworkIdentity
|
||||
href: NetworkIdentity.md
|
||||
- name: NetworkStartPosition
|
||||
href: NetworkStartPosition.md
|
||||
- name: NetworkProximityChecker
|
||||
href: NetworkProximityChecker.md
|
||||
- name: NetworkTransform
|
||||
href: NetworkTransform.md
|
||||
- name: NetworkTransformChild
|
||||
href: NetworkTransformChild.md
|
||||
- name: NetworkAnimator
|
||||
href: NetworkAnimator.md
|
||||
- name: NetworkNavMeshAgent
|
||||
href: NetworkNavMeshAgent.md
|
||||
- name: NetworkController
|
||||
href: NetworkController.md
|
||||
- name: NetworkRigidbody
|
||||
href: NetworkRigidbody.md
|
Before Width: | Height: | Size: 45 KiB After Width: | Height: | Size: 45 KiB |
8
doc/articles/Concepts/Communications/toc.yml
Normal file
@ -0,0 +1,8 @@
|
||||
- name: Remote Actions
|
||||
href: RemoteActions.md
|
||||
- name: Network Manager Callbacks
|
||||
href: NetworkManager.md
|
||||
- name: Network Behavior Callbacks
|
||||
href: NetworkBehavior.md
|
||||
- name: Network Messages
|
||||
href: NetworkMessages.md
|
Before Width: | Height: | Size: 44 KiB After Width: | Height: | Size: 44 KiB |
Before Width: | Height: | Size: 35 KiB After Width: | Height: | Size: 35 KiB |
@ -45,7 +45,7 @@ You don’t need to use `playerPrefab` on the `NetworkManager` to create player
|
||||
|
||||
In addition to players, client connections also have a “ready” state. The host sends clients that are ready information about spawned game objects and state synchronization updates; clients which are not ready are not sent these updates. When a client initially connects to a server, it is not ready. While in this non-ready state, the client can do things that don’t require real-time interactions with the game state on the server, such as loading Scenes, allowing the player to choose an avatar, or fill in log-in boxes. Once a client has completed all its pre-game work, and all its Assets are loaded, it can call `ClientScene.Ready` to enter the “ready” state. The simple example above demonstrates implementation of ready states; because adding a player with `NetworkServer.AddPlayerForConnection` also puts the client into the ready state if it is not already in that state.
|
||||
|
||||
Clients can send and receive network messages without being ready, which also means they can do so without having an active player game object. So a client at a menu or selection screen can connect to the game and interact with it, even though they have no player game object. See documentation on [Network Messages](../../Communications/NetworkMessages) for more details about sending messages without using commands and RPC calls.
|
||||
Clients can send and receive network messages without being ready, which also means they can do so without having an active player game object. So a client at a menu or selection screen can connect to the game and interact with it, even though they have no player game object. See documentation on [Network Messages](../Communications/NetworkMessages.md) for more details about sending messages without using commands and RPC calls.
|
||||
|
||||
## Switching Players
|
||||
|
10
doc/articles/Concepts/GameObjects/toc.yml
Normal file
@ -0,0 +1,10 @@
|
||||
- name: Spawn Player
|
||||
href: SpawnPlayer.md
|
||||
- name: Spawn Player - Custom
|
||||
href: SpawnPlayerCustom.md
|
||||
- name: Spawn Object
|
||||
href: SpawnObject.md
|
||||
- name: Spawn Object - Custom
|
||||
href: SpawnObjectCustom.md
|
||||
- name: Scene Objects
|
||||
href: SceneObjects.md
|
Before Width: | Height: | Size: 8.0 KiB After Width: | Height: | Size: 8.0 KiB |
@ -6,17 +6,17 @@ State synchronization is done from the Server to remote clients. The local clien
|
||||
|
||||
Data is not synchronized in the opposite direction - from remote clients to the server. To do this, you need to use Commands.
|
||||
|
||||
- [SyncVars](../Classes/SyncVars)
|
||||
- [SyncVars](../Classes/SyncVars.md)
|
||||
SyncVars are variables of scripts that inherit from NetworkBehaviour, which are synchronized from the server to clients.
|
||||
- [SyncEvents](../Classes/SyncEvent)
|
||||
- [SyncEvents](../Classes/SyncEvent.md)
|
||||
SyncEvents are networked events like ClientRpc’s, but instead of calling a function on the game object, they trigger Events instead.
|
||||
- [SyncLists](../Classes/SyncLists)
|
||||
- [SyncLists](../Classes/SyncLists.md)
|
||||
SyncLists contain lists of values and synchronize data from servers to clients.
|
||||
- [SyncDictionary](../Classes/SyncDictionary)
|
||||
- [SyncDictionary](../Classes/SyncDictionary.md)
|
||||
A SyncDictionary is an associative array containing an unordered list of key, value pairs.
|
||||
- [SyncHashSet](../Classes/SyncHashSet)
|
||||
- [SyncHashSet](../Classes/SyncHashSet.md)
|
||||
An unordered set of values that do not repeat.
|
||||
- [SyncSortedSet](../Classes/SyncSortedSet)
|
||||
- [SyncSortedSet](../Classes/SyncSortedSet.md)
|
||||
A sorted set of values tha do not repeat.
|
||||
|
||||
## Advanced State Synchronization
|
@ -16,7 +16,7 @@ However, it can be also be resource intensive or complex to determine accurately
|
||||
|
||||
## Network Proximity Checker Component
|
||||
|
||||
Mirror’s [Network Proximity Checker](../Components/NetworkProximityChecker) component is simplest way to implement network visibility for players. It works in conjunction with the physics system to determine whether game objects are close enough (that is, “visible” for the purposes of sending network messages in your multiplayer game).
|
||||
Mirror’s [Network Proximity Checker](../Components/NetworkProximityChecker.md) component is simplest way to implement network visibility for players. It works in conjunction with the physics system to determine whether game objects are close enough (that is, “visible” for the purposes of sending network messages in your multiplayer game).
|
||||
|
||||
## Network Visibility on Remote Clients
|
||||
|
@ -1,6 +1,6 @@
|
||||
# Customizing Network Visibility
|
||||
|
||||
The built-in [Network Proximity Checker](../Components/NetworkProximityChecker) component is the built-in default component for determining a game object’s network visibility. However, this only provides you with a distance-based check. Sometimes you might want to use other kinds of visibility check, such as grid-based rules, line-of-sight tests, navigation path tests, or any other type of test that suits your game.
|
||||
The built-in [Network Proximity Checker](../Components/NetworkProximityChecker.md) component is the built-in default component for determining a game object’s network visibility. However, this only provides you with a distance-based check. Sometimes you might want to use other kinds of visibility check, such as grid-based rules, line-of-sight tests, navigation path tests, or any other type of test that suits your game.
|
||||
|
||||
To do this, you can implement your own custom equivalent of the Network Proximity Checker. To do that, you need to understand how the Network Proximity Checker works. See documentation on the Network Proximity Checker component.
|
||||
|
24
doc/articles/Concepts/toc.yml
Normal file
@ -0,0 +1,24 @@
|
||||
- name: Authority
|
||||
href: Authority.md
|
||||
- name: About IDs
|
||||
href: IDs.md
|
||||
- name: Clients and Servers
|
||||
href: ClientsServers.md
|
||||
- name: Authentication
|
||||
href: Authentication.md
|
||||
- name: Conversion
|
||||
href: Conversion.md
|
||||
- name: Clock Synchronization
|
||||
href: ClockSync.md
|
||||
- name: State Syncronization
|
||||
href: StateSync.md
|
||||
- name: Visibility
|
||||
href: Visibility.md
|
||||
- name: Custom Visibility
|
||||
href: VisibilityCustom.md
|
||||
- name: Communications
|
||||
href: Communications/toc.yml
|
||||
topicHref: Communications/index.md
|
||||
- name: GameObjects
|
||||
href: GameObjects/toc.yml
|
||||
topicHref: GameObjects/index.md
|
8
doc/articles/Events/toc.yml
Normal file
@ -0,0 +1,8 @@
|
||||
- name: Application Events
|
||||
href: Application.md
|
||||
- name: Server Events
|
||||
href: Server.md
|
||||
- name: Client Events
|
||||
href: Client.md
|
||||
- name: Other Events
|
||||
href: Other.md
|
Before Width: | Height: | Size: 16 KiB After Width: | Height: | Size: 16 KiB |
Before Width: | Height: | Size: 229 KiB After Width: | Height: | Size: 229 KiB |
Before Width: | Height: | Size: 162 KiB After Width: | Height: | Size: 162 KiB |
Before Width: | Height: | Size: 9.7 KiB After Width: | Height: | Size: 9.7 KiB |
@ -2,17 +2,17 @@
|
||||
|
||||
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)
|
||||
- [Basic](Basic.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)
|
||||
- [Tanks](Tanks.md)
|
||||
This is a simple scene with animated tanks, networked rigidbody projectiles, and NavMesh movement
|
||||
|
||||
- [Pong](Pong)
|
||||
- [Pong](Pong.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)
|
||||
- [Additive Scenes](AdditiveScenes.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.
|
||||
|
||||
- [Lobby System](Lobby)
|
||||
- [Lobby System](Lobby.md)
|
||||
The Lobby 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.
|
6
doc/articles/Examples/toc.yml
Normal file
@ -0,0 +1,6 @@
|
||||
- name: Basic
|
||||
href: Basic.md
|
||||
- name: Pong
|
||||
href: Pong.md
|
||||
- name: Lobby
|
||||
href: Lobby.md
|
@ -81,12 +81,12 @@
|
||||
## Version 3.4.9 -- 2019-Apr-6
|
||||
|
||||
- Added: Semantic Versioning (which is why we jumped from 1.6 to 3.4.9)
|
||||
- Added: [SyncDictionary](../Classes/SyncDictionary)
|
||||
- Added: [SyncHashSet](../Classes/SyncHashSet)
|
||||
- Added: [SyncSortedSet](../Classes/SyncSortedSet)
|
||||
- Added: [SyncDictionary](../Classes/SyncDictionary.md)
|
||||
- Added: [SyncHashSet](../Classes/SyncHashSet.md)
|
||||
- Added: [SyncSortedSet](../Classes/SyncSortedSet.md)
|
||||
- Added: SyncList and SyncDictionary support all IList and IDictionary derived types, respectively
|
||||
- Added: Documentation for [SyncVars](../Classes/SyncVars)
|
||||
- Added: Documentation for [SyncEvents](../Classes/SyncEvent)
|
||||
- Added: Documentation for [SyncVars](../Classes/SyncVars.md)
|
||||
- Added: Documentation for [SyncEvents](../Classes/SyncEvent.md)
|
||||
- Added: NoRotation to NetworkTransform
|
||||
- Added: Scale is now included in spawn payload along with position and rotation
|
||||
- Added: Generic `IMessageBase` to allow struct message types
|
||||
@ -121,12 +121,12 @@
|
||||
- Fixed: NetworkAnimator bandwidth abuse
|
||||
- Fixed: NetworkAnimator float sync bug
|
||||
- Fixed: Persistent SceneID's for Networked objects
|
||||
- Changed: Documentation for [Transports](../Transports)
|
||||
- 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](../Concepts/Authentication) to see how to update your code.
|
||||
- Please refer to the code sample [here](../Concepts/Authentication.md) to see how to update your code.
|
||||
- Changed: NetworkManager -- Headless Auto-Start moved to `Start()` from `Awake()`
|
||||
- Changed: Removed Message ID's for all messages - See [Network Messages](../Concepts/Communications/NetworkMessages) for details
|
||||
- Changed: Removed Message ID's for all messages - See [Network Messages](../Concepts/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
|