Added missing UIDs to manual pages

Author: unitALG

Packages/com.unity.inputsystem/Documentation~/QuickStartGuide.md

@@ -1,4 +1,6 @@
-
+---
+uid: input-system-quickstart
+---
 # Quickstart Guide
 
 This page has a brief description of how to quickly start using the Input System. The Input System has [multiple workflows](Workflows.md) which you might prefer that offer different benefits. This quickstart guide shows a workflow which suits most common scenarios.

Packages/com.unity.inputsystem/Documentation~/RespondingToActions.md

@@ -1,4 +1,6 @@
-
+---
+uid: input-system-responding
+---
 # Responding to Actions
 
 There are two main techniques you can use to respond to Actions in your project. These are to either use **polling** or an **event-driven** approach.

Packages/com.unity.inputsystem/Documentation~/timing-input-events-queue.md

@@ -1,3 +1,6 @@
+---
+uid: input-system-timing-queue
+---
 # The input events queue
 
 The Input System receives information from hardware input devices as a stream of events. These events represent either system events received from the input device, or snapshots in time based on frequent samples from the device.

Packages/com.unity.inputsystem/Documentation~/timing-missed-duplicate-events.md

@@ -1,3 +1,6 @@
+---
+uid: input-system-timing-missed
+---
 # Avoid missed or duplicate discrete events
 
 Discrete events are simple on/off events that occur when a user presses or releases a control such as a gamepad button, key, mouse, or touch press. This is in contrast to continuously changing values like those from gamepad stick movement. You can poll for these types of discrete event by using [`WasPressedThisFrame`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_WasPressedThisFrame_) or [`WasReleasedThisFrame`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_WasReleasedThisFrame_). However, you can get incorrect results such as missing an event or appearing to receive multiple, if you check for them at the wrong time.

Packages/com.unity.inputsystem/Documentation~/timing-mixed-scenarios.md

@@ -1,3 +1,6 @@
+---
+uid: input-system-timing-mixed
+---
 # Mixed timing scenarios with fixed and dynamic input
 
 There are some situations where you might set the Update Mode **process in Dynamic Update** even when using input code in `FixedUpdate`, to minimize input latency, as described in the [previous section](./timing-optimize-fixed-update.md).

Packages/com.unity.inputsystem/Documentation~/timing-optimize-dynamic-update.md

@@ -1,3 +1,6 @@
+---
+uid: input-system-timing-optimize-dynamic
+---
 # Optimize for dynamic update (non-physics) scenarios
 
 If you're not working with the physics system or using `FixedUpdate`, always set the input system to process input in sync with the frame rate and `Update()` calls. This is the default setting, but to check or set this, go to  **Project Settings** \> **Input System Package** \> **Input Settings**, and set **Update Mode** to **Process Events in Dynamic Update**.

Packages/com.unity.inputsystem/Documentation~/timing-optimize-fixed-update.md

@@ -1,3 +1,6 @@
+---
+uid: input-system-timing-optimize-fixed
+---
 # Optimize for fixed-timestep or physics-based scenarios
 
 If you are working with the physics system or using `FixedUpdate` to control your game in a scenario where a small amount of input latency is acceptable (for example, a few frames), the simplest approach is to set the [input system update mode](./timing-select-mode.md) to **Process Events in Fixed Update**. This means your input code in `FixedUpdate` will operate as expected.

Packages/com.unity.inputsystem/Documentation~/timing-select-mode.md

@@ -1,3 +1,6 @@
+---
+uid: input-system-timing-select
+---
 # Select an appropriate input processing mode
 
 The Input System **Update Mode** controls when the input system processes queued input events.