Sentence casing docs

Author: jabbacakes

docs/advanced-topics/client-anticipation.md

@@ -19,15 +19,15 @@ Client anticipation uses `AnticipatedNetworkVariable<T>` and `AnticipatedNetwork
 Games with a server-authoritative architecture often face the problem of making the game feel responsive despite [latency](../learn/ladandpacketloss.md). For example, when a user wants to change the color of an object from green to blue they click a button in the UI, an RPC is sent to the server, and the server changes the object to blue. From the client's perspective, the object doesn't change to blue until the server responds to that message, resulting in a perceived delay for the user.
 
 <figure>
-<ImageSwitcher 
+<ImageSwitcher
 lightImageSrc="/sequence_diagrams/Anticipation/ServerAuthoritative.png?text=LightMode"
 darkImageSrc="/sequence_diagrams/Anticipation/ServerAuthoritative_Dark.png?text=DarkMode"/>
 </figure>
 
 Client anticipation solves this problem by allowing a separation between the visual value and the authoritative value of an object. In this example, with anticipation, when the button is pressed to change the color from green to blue, the client *anticipates* the result of the command by visually changing the object to green while it waits for an update from the server:
 
 <figure>
-<ImageSwitcher 
+<ImageSwitcher
 lightImageSrc="/sequence_diagrams/Anticipation/ClientAnticipation.png?text=LightMode"
 darkImageSrc="/sequence_diagrams/Anticipation/ClientAnticipation_Dark.png?text=DarkMode"/>
 </figure>
@@ -48,15 +48,15 @@ Anticipation systems need to be able to handle stale data. Stale data refers to
 Expanding the example above to include a second client that's also trying to change the color of the same object highlights this problem. If client A tries to change the object to blue, and then client B tries to change it to red, client A sees a delayed switch to blue, followed by a switch to red (which is fine because this is actually what happened). Client B, however, clicks the button to change it to red, then sees it change to blue, followed by a change to red.
 
 <figure>
-<ImageSwitcher 
+<ImageSwitcher
 lightImageSrc="/sequence_diagrams/Anticipation/ServerAuthoritativeMultiClient.png?text=LightMode"
 darkImageSrc="/sequence_diagrams/Anticipation/ServerAuthoritativeMultiClient_Dark.png?text=DarkMode"/>
 </figure>
 
 With client anticipation, this scenario plays out differently: client A anticipates the change to blue, so it happens immediately, and then later sees the object change to red (which, again, is fine). Client B also sees the object change to red immediately, but because a change to blue is already in progress, that overwrites client B's anticipated value, causing it to flicker briefly to blue from client A's request before changing back to red again from client B's request.
 
 <figure>
-<ImageSwitcher 
+<ImageSwitcher
 lightImageSrc="/sequence_diagrams/Anticipation/StaleDataNoPolicy.png?text=LightMode"
 darkImageSrc="/sequence_diagrams/Anticipation/StaleDataNoPolicy_Dark.png?text=DarkMode"/>
 </figure>
@@ -68,20 +68,22 @@ There are two ways you can respond to stale data, which are determined by the `S
 - StaleDataHandling.Ignore
 - StaleDataHandling.Reanticipate
 
-### StaleDataHandling.Ignore
+### `StaleDataHandling.Ignore`
+
 If `StaleDataHandling` is set to `StaleDataHandling.Ignore`, stale data doesn't roll back the value of the variable or transform to the server value and doesn't trigger the [`OnReanticipate` event](#onreanticipate-event). `ShouldReanticipate` remains false in the event something else triggers the callback. The authoritative value is still updated, however, and for `AnticipatedNetworkVariable`, the `OnAuthoritativeValueUpdated` callback is still called. The result for our example is that, for client B, the change to blue is recognized as being sequenced before its change to red, and is thus ignored, eliminating the flickering. This is the default behavior for `AnticipatedNetworkVariable<T>`.
 
 <figure>
-<ImageSwitcher 
+<ImageSwitcher
 lightImageSrc="/sequence_diagrams/Anticipation/StaleDataIgnore.png?text=LightMode"
 darkImageSrc="/sequence_diagrams/Anticipation/StaleDataIgnore_Dark.png?text=DarkMode"/>
 </figure>
 
-### StaleDataHandling.Reanticipate
+### `StaleDataHandling.Reanticipate`
+
 If `StaleDataHandling` is set to `StaleDataHandling.Reanticipate`, stale data is treated the same way as any other server data updates. The value is rolled back, `ShouldReanticipate` is set to true, and the [`OnReanticipate` event](#onreanticipate-event) fires. In typical client prediction systems, this generally involves replaying the player's input from the time of the incoming data to now, which results in re-performing the switch to red.
 
 <figure>
-<ImageSwitcher 
+<ImageSwitcher
 lightImageSrc="/sequence_diagrams/Anticipation/StaleDataReanticipate.png?text=LightMode"
 darkImageSrc="/sequence_diagrams/Anticipation/StaleDataReanticipate_Dark.png?text=DarkMode"/>
 </figure>

docs/advanced-topics/custom-serialization.md

@@ -62,7 +62,7 @@ public static class SerializationExtensions
 
 Additionally, you can also add extensions for `FastBufferReader.ReadValue()`, `FastBufferWriter.WriteValue()`, and `BufferSerializer<TReaderWriter>.SerializeValuePreChecked()` to provide more optimal implementations for manual serialization using `FastBufferReader.TryBeginRead()`, `FastBufferWriter.TryBeginWrite()`, and `BufferSerializer<TReaderWriter>.PreCheck()`, respectively. However, none of these will be used for serializing RPCs - only `ReadValueSafe` and `WriteValueSafe` are used.
 
-### For NetworkVariable
+### For `NetworkVariable`
 
 `NetworkVariable` goes through a slightly different pipeline than `RPC`s and relies on a different process for determining how to serialize its types. As a result, making a custom type available to the `RPC` pipeline doesn't automatically make it available to the `NetworkVariable` pipeline, and vice-versa. The same method can be used for both, but currently, `NetworkVariable` requires an additional runtime step to make it aware of the methods.
 

docs/advanced-topics/fastbufferwriter-fastbufferreader.md

@@ -3,7 +3,7 @@ id: fastbufferwriter-fastbufferreader
 title: FastBufferWriter and FastBufferReader
 sidebar_label: FastBufferWriter and FastBufferReader
 ---
-The serialization and deserialization is done via `FastBufferWriter` and `FastBufferReader`. These have methods for serializing individual types and methods for serializing packed numbers, but in particular provide a high-performance method called `WriteValue()/ReadValue()` (for Writers and Readers, respectively) that can extremely quickly write an entire unmanaged struct to a buffer. 
+The serialization and deserialization is done via `FastBufferWriter` and `FastBufferReader`. These have methods for serializing individual types and methods for serializing packed numbers, but in particular provide a high-performance method called `WriteValue()/ReadValue()` (for Writers and Readers, respectively) that can extremely quickly write an entire unmanaged struct to a buffer.
 
 There's a trade-off of CPU usage vs bandwidth in using this: Writing individual fields is slower (especially when it includes operations on unaligned memory), but allows the buffer to be filled more efficiently, both because it avoids padding for alignment in structs, and because it allows you to use `BytePacker.WriteValuePacked()`/`ByteUnpacker.ReadValuePacked()` and `BytePacker.WriteValueBitPacked()`/`ByteUnpacker.ReadValueBitPacked()`. The difference between these two is that the BitPacked variants pack more efficiently, but they reduce the valid range of values. See the section below for details on packing.
 
@@ -47,7 +47,7 @@ void Serialize(FastBufferWriter writer)
 }
 ```
 This creates efficiently packed data in the message, and can be further optimized by using `BytePacker.WriteValuePacked()` and `BytePacker.WriteValueBitPacked()`, but it has two downsides:
-- First, it involves more method calls and more instructions, making it slower. 
+- First, it involves more method calls and more instructions, making it slower.
 - Second, that it creates a greater opportunity for the serialize and deserialize code to become misaligned, since they must contain the same operations in the same order.
 
 You can also use a hybrid approach if you have a few values that will need to be packed and several that won't:
@@ -78,7 +78,7 @@ struct ExampleStruct
 This allows the four bytes of the embedded struct to be rapidly serialized as a single action, then adds the compacted data at the end, resulting in better bandwidth usage than serializing the whole struct as-is, but better performance than serializing it one byte at a time.
 
 
-## FastBufferWriter and FastBufferReader
+## `FastBufferWriter` and `FastBufferReader`
 
 `FastBufferWriter` and `FastBufferReader` are replacements for the old `NetworkWriter` and `NetworkReader`. For those familiar with the old classes, there are some key differences:
 
@@ -96,9 +96,9 @@ This allows the four bytes of the embedded struct to be rapidly serialized as a
 
 A core benefit of `NativeArray<byte>` is that it offers access to the allocation scheme of `Allocator.TempJob`. This uses a special type of allocation that is nearly as fast as stack allocation and involves no GC overhead, while being able to persist for a few frames. In general they're rarely if ever needed for more than a frame, but this does provide a efficient option for creating buffers as needed, which avoids the need to use a pool for them. The only downside is that buffers created this way must be manually disposed after use, as they're not garbage collected.
 
-## Creating and Disposing FastBufferWriters and FastBufferReaders
+## Creating and disposing `FastBufferWriters` and `FastBufferReaders`
 
-To create your own `FastBufferWriter`s and `FastBufferReader`s, it's important to note that struct default/parameterless constructors can't be removed or overridden, but `FastBufferWriter` and `FastBufferReader` require constructor behavior to be functional. 
+To create your own `FastBufferWriter`s and `FastBufferReader`s, it's important to note that struct default/parameterless constructors can't be removed or overridden, but `FastBufferWriter` and `FastBufferReader` require constructor behavior to be functional.
 
 `FastBufferWriter` always owns its internal buffer and must be constructed with an initial size, an allocator, and a maximum size. If the maximum size isn't provided or is less than or equal to the initial size, the `FastBufferWriter` can't expand.
 
@@ -116,7 +116,7 @@ It's important to note with `Allocator.None` that the `FastBufferReader` will be
 
 Regardless which allocator you use (including `Allocator.None`), `FastBufferWriter` and `FastBufferReader` must always have `Dispose()` called on them when you're done with them. The best practice is to use them within `using` blocks.
 
-## Bounds Checking
+## Bounds checking
 
 For performance reasons, by default, `FastBufferReader` and `FastBufferWriter` **don't do bounds checking** on each write. Rather, they require the use of specific bounds checking functions - `TryBeginRead(int amount)` and `TryBeginWrite(int amount)`, respectively. This improves performance by allowing you to verify the space exists for the multiple values in a single call, rather than doing that check on every single operation.
 
@@ -126,9 +126,9 @@ For performance reasons, by default, `FastBufferReader` and `FastBufferWriter` *
 
 For convenience, every `WriteValue()` and `ReadValue()` method has an equivalent `WriteValueSafe()` and `ReadValueSafe()` that does bounds checking for you, throwing `OverflowException` if the boundary is exceeded. Additionally, some methods, such as arrays (where the amount of data being read can't be known until the size value is read) and [`INetworkSerializable`](inetworkserializable.md) values (where the size can't be predicted outside the implementation) will always do bounds checking internally.
 
-## Bitwise Reading and Writing
+## Bitwise reading and writing
 
-Writing values in sizes measured in bits rather than bytes comes with a cost 
+Writing values in sizes measured in bits rather than bytes comes with a cost
 - First, it comes with a cost of having to track bitwise lengths and convert them to bytewise lenghts.
 - Second, it comes with a cost of having to remember to add padding after your bitwise writes and reads to ensure the next bytewise write or read functions correctly, and to make sure the buffer length includes any trailing bits.
 
@@ -159,5 +159,3 @@ Packing values is done using the utility classes `BytePacker` and `ByteUnpacker`
   | uint   | 30 bits (0 to 1,073,741,824)                                 |
   | long   | 60 bits + sign bit (-1,152,921,504,606,846,976 to 1,152,921,504,606,846,975) |
   | ulong  | 61 bits (0 to 2,305,843,009,213,693,952)                     |
-
-  

docs/advanced-topics/inscene_parenting_player.md

@@ -4,10 +4,7 @@ title:   Real world In-scene NetworkObject parenting of players solution
 description: In-scene NetworkObject parenting of players Solution
 ---
 
-
-We received the following issue in Github.
-
-## Issue:
+## Issue
 
 When a player Prefab has a script that dynamically adds a parent to its transform, the client can't join a game hosted by another client. [You can see orignal issue here](https://github.com/Unity-Technologies/com.unity.netcode.gameobjects/issues/1211)
 
@@ -18,8 +15,7 @@ Steps to reproduce the behavior:
 1. Launch one instance of the game as Host.
 1. Launch another instance and try to join as Client.
 
-## Solution:
-
+## Solution
 
 If you want to do this when a player has first connected and all `NetworkObjects` (in-scene placed and already dynamically spawned by the server-host) have been fully synchronized with the client then we would recommend using the `NetworkManager.SceneManager.OnSceneEvent` to trap for the `SynchronizeComplete` event.
 

docs/advanced-topics/message-system/clientrpc.md

@@ -5,32 +5,32 @@ title: ClientRpc
 import ImageSwitcher from '@site/src/ImageSwitcher.js';
 
 :::warning
-ClientRpc and ServerRpc are legacy features of Netcode for GameObjects and have been replaced with the universal RPC attribute. This documentation is for legacy use. For current projects, use [Rpc](rpc.md) instead.
+`ClientRpc` and `ServerRpc` are legacy features of Netcode for GameObjects and have been replaced with the universal RPC attribute. This documentation is for legacy use. For current projects, use [RPCs](rpc.md) instead.
 :::
 
 
-Servers can invoke a ClientRpc to execute on all clients.
+Servers can invoke a `ClientRpc` to execute on all clients.
 
 <figure>
-<ImageSwitcher 
+<ImageSwitcher
 lightImageSrc="/sequence_diagrams/RPCs/ClientRPCs.png?text=LightMode"
 darkImageSrc="/sequence_diagrams/RPCs/ClientRPCs_Dark.png?text=DarkMode"/>
 </figure>
 
 
 
-## Declaring a ClientRpc
+## Declaring a `ClientRpc`
 
-You can declare a ClientRpc by marking a method with the `[ClientRpc]` attribute and including the `ClientRpc` suffix in the method name.
+You can declare a `ClientRpc` by marking a method with the `[ClientRpc]` attribute and including the `ClientRpc` suffix in the method name.
 
 ```csharp
 [ClientRpc]
 void PongClientRpc(int somenumber, string sometext) { /* ... */ }
 ```
 
-## Invoking a ClientRpc
+## Invoking a `ClientRpc`
 
-You can invoke a ClientRpc by invoking the function directly with parameters:
+You can invoke a `ClientRpc` by invoking the function directly with parameters:
 
 ```csharp
 void Update()
@@ -63,9 +63,9 @@ PongRpc(somenumber, sometext); // Is this a ServerRpc call or ClientRpc call?
 PongClientRpc(somenumber, sometext); // This is clearly a ClientRpc call
 ```
 
-## To send to one client, use ClientRpcSendParameters
+## To send to one client, use `ClientRpcSendParameters`
 
-The following code provides an example of using ClientRpcSendParameters, which sends a ClientRpc to a specific client connection. The default Netcode for GameObjects behavior is to broadcast to every single client.
+The following code provides an example of using `ClientRpcSendParameters`, which sends a `ClientRpc` to a specific client connection. The default Netcode for GameObjects behavior is to broadcast to every single client.
 
 ```csharp
 private void DoSomethingServerSide(int clientId)
@@ -101,7 +101,7 @@ private void DoSomethingClientRpc(int randomInteger, ClientRpcParams clientRpcPa
 ```
 
 <figure>
-<ImageSwitcher 
+<ImageSwitcher
 lightImageSrc="/sequence_diagrams/RPCs/ClientRPCs_CertainClients.png?text=LightMode"
 darkImageSrc="/sequence_diagrams/RPCs/ClientRPCs_CertainClients_Dark.png?text=DarkMode"/>
  <figcaption>Server can invoke a client RPC on a Network Object. The RPC will be placed in the local queue and then sent to a selection of clients (by default this selection is "all clients"). When received by a client, RPC will be executed on the client's version of the same Network Object.</figcaption>
@@ -113,20 +113,20 @@ The host is both a client and a server. If a host invokes a client RPC, it trigg
 
 
 <figure>
-<ImageSwitcher 
+<ImageSwitcher
 lightImageSrc="/sequence_diagrams/RPCs/ClientRPCs_ClientHosts_CalledByClientHost.png?text=LightMode"
 darkImageSrc="/sequence_diagrams/RPCs/ClientRPCs_ClientHosts_CalledByClientHost_Dark.png?text=DarkMode"/>
  <figcaption>Hosts can invoke client RPCs on `NetworkObjects`. If broadcasting to all clients, the RPC will be immediately invoked on the host and placed in the local queue. At the end of the frame, the client RPC will be sent to the remote clients. When a remote client receives the client RPC it's executed on the client's local cloned instance of the same NetworkObject.</figcaption>
 </figure>
 
 :::warning
-When running as a host, Netcode for GameObjects invokes RPCs immediately within the same stack as the method invoking the RPC. Since a host is both considered a server and a client, you should avoid design patterns where a ClientRpc invokes a ServerRpc that invokes the same ClientRpc as this can end up in a stack overflow (infinite recursion).
+When running as a host, Netcode for GameObjects invokes RPCs immediately within the same stack as the method invoking the RPC. Since a host is both considered a server and a client, you should avoid design patterns where a `ClientRpc` invokes a `ServerRpc` that invokes the same `ClientRpc` as this can end up in a stack overflow (infinite recursion).
 :::
 
 See the [Boss Room RPC Examples](../../learn/bossroom/bossroom-actions.md).
 
 
-## Also see
+## Additional resources
 
-* [ServerRpc](serverrpc.md)
+* [`ServerRpc`](serverrpc.md)
 * [RPC parameters](rpc-params.md)