5b4aaa8b59
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). Additional documentation and release notes are available at [Multiplayer Documentation](https://docs-multiplayer.unity3d.com). ## [1.0.0-pre.6] - 2022-03-02 ### Added - NetworkAnimator now properly synchrhonizes all animation layers as well as runtime-adjusted weighting between them (#1765) - Added first set of tests for NetworkAnimator - parameter syncing, trigger set / reset, override network animator (#1735) ### Changed ### Fixed - Fixed an issue where sometimes the first client to connect to the server could see messages from the server as coming from itself. (#1683) - Fixed an issue where clients seemed to be able to send messages to ClientId 1, but these messages would actually still go to the server (id 0) instead of that client. (#1683) - Improved clarity of error messaging when a client attempts to send a message to a destination other than the server, which isn't allowed. (#1683) - Disallowed async keyword in RPCs (#1681) - Fixed an issue where Alpha release versions of Unity (version 2022.2.0a5 and later) will not compile due to the UNet Transport no longer existing (#1678) - Fixed messages larger than 64k being written with incorrectly truncated message size in header (#1686) (credit: @kaen) - Fixed overloading RPC methods causing collisions and failing on IL2CPP targets. (#1694) - Fixed spawn flow to propagate `IsSceneObject` down to children NetworkObjects, decouple implicit relationship between object spawning & `IsSceneObject` flag (#1685) - Fixed error when serializing ConnectionApprovalMessage with scene management disabled when one or more objects is hidden via the CheckObjectVisibility delegate (#1720) - Fixed CheckObjectVisibility delegate not being properly invoked for connecting clients when Scene Management is enabled. (#1680) - Fixed NetworkList to properly call INetworkSerializable's NetworkSerialize() method (#1682) - Fixed NetworkVariables containing more than 1300 bytes of data (such as large NetworkLists) no longer cause an OverflowException (the limit on data size is now whatever limit the chosen transport imposes on fragmented NetworkDelivery mechanisms) (#1725) - Fixed ServerRpcParams and ClientRpcParams must be the last parameter of an RPC in order to function properly. Added a compile-time check to ensure this is the case and trigger an error if they're placed elsewhere (#1721) - Fixed FastBufferReader being created with a length of 1 if provided an input of length 0 (#1724) - Fixed The NetworkConfig's checksum hash includes the NetworkTick so that clients with a different tickrate than the server are identified and not allowed to connect (#1728) - Fixed OwnedObjects not being properly modified when using ChangeOwnership (#1731) - Improved performance in NetworkAnimator (#1735) - Removed the "always sync" network animator (aka "autosend") parameters (#1746)
48 lines
2.7 KiB
C#
48 lines
2.7 KiB
C#
using Unity.Collections;
|
|
|
|
namespace Unity.Netcode
|
|
{
|
|
/// <summary>
|
|
/// Base building block for creating a message. Any struct (or class) that implements INetworkMessage
|
|
/// will automatically be found by the system and all the proper mechanisms for sending and receiving
|
|
/// that message will be hooked up automatically.
|
|
///
|
|
/// It's generally recommended to implement INetworkMessage types as structs, and define your messages
|
|
/// as close as you can to the network transport format. For messages with no dynamic-length or optional
|
|
/// data, FastBufferWriter allows for serializing the entire struct at once via writer.WriteValue(this)
|
|
///
|
|
/// In addition to the specified Serialize method, all INetworkMessage types must also have a
|
|
/// static message handler for receiving messages of the following name and signature:
|
|
///
|
|
/// <code>
|
|
/// public static void Receive(FastBufferReader reader, ref NetworkContext context)
|
|
/// </code>
|
|
///
|
|
/// It is the responsibility of the Serialize and Receive methods to ensure there is enough buffer space
|
|
/// to perform the serialization/deserialization, either via <see cref="FastBufferWriter.TryBeginWrite"/> and
|
|
/// <see cref="FastBufferReader.TryBeginRead"/>, or via <see cref="FastBufferWriter.WriteValueSafe{T}(T)"/> and
|
|
/// <see cref="FastBufferReader.ReadValueSafe{T}(T)"/>. The former is more efficient when it can be used
|
|
/// for bounds checking for multiple values at once.
|
|
///
|
|
/// When bandwidth is a bigger concern than CPU usage, values can be packed with <see cref="BytePacker"/>
|
|
/// and <see cref="ByteUnpacker"/>.
|
|
///
|
|
/// Note that for messages sent using non-fragmenting delivery modes (anything other than
|
|
/// <see cref="NetworkDelivery.ReliableFragmentedSequenced"/>), there is a hard limit of 1300 bytes per message.
|
|
/// With the fragmenting delivery mode, the limit is 64000 bytes per message. If your messages exceed that limit,
|
|
/// you will have to split them into multiple smaller messages.
|
|
///
|
|
/// Messages are sent with:
|
|
/// <see cref="NetworkManager.SendMessage{T}(T, NetworkDelivery, ulong, bool)"/>
|
|
/// <see cref="NetworkManager.SendMessage{T}(T, NetworkDelivery, ulong*, int, bool)"/>
|
|
/// <see cref="NetworkManager.SendMessage{T, U}(T, NetworkDelivery, U, bool)"/>
|
|
/// <see cref="NetworkManager.SendMessage{T}(T, NetworkDelivery, NativeArray{ulong}, bool)"/>
|
|
/// </summary>
|
|
internal interface INetworkMessage
|
|
{
|
|
void Serialize(FastBufferWriter writer);
|
|
bool Deserialize(FastBufferReader reader, ref NetworkContext context);
|
|
void Handle(ref NetworkContext context);
|
|
}
|
|
}
|