Merged PR 629: Minor Userguide changes (Charlie)

## Summary
Minor userguide changes, working from the "bottom" of the comments from 3110

## Test process
User Guide continues to successfully render.

## Checklist
- [X] PR is linked to a **work item**
- [ ] **acceptance criteria** of linked ticket are met
- [ ] performed **self-review** of the code
- [ ] written **tests** for any new functionality added with this PR
- [X] updated the **documentation** if this PR changes or adds functionality
- [ ] written/updated **design docs** if this PR implements new functionality
- [ ] updated the **change log**
- [X] ran **pre-commit** checks for code style
- [ ] attended to any **TO-DOs** left in the code

Related work items: #3110

docs/source/configuration/agents.rst

@@ -96,8 +96,7 @@ Similar to action space, this is defined as a list of components from the :py:mo
 
 ``reward_components``
 ^^^^^^^^^^^^^^^^^^^^^
-TODO: update description
+A list of available reward types from :py:mod:`primaite.game.agent.rewards.RewardFunction.rew_class_identifiers`
-A list of reward types from :py:mod:`primaite.game.agent.rewards.RewardFunction.rew_class_identifiers`
 
 e.g.
 
@@ -105,7 +104,13 @@ e.g.
 
     reward_components:
         - type: dummy
+          weight: 1.0
         - type: database-file-integrity
+          weight: 0.40
+          options:
+            node_hostname: database_server
+            folder_name: database
+            file_name: database.db
 
 
 ``agent_settings``
@@ -118,10 +123,9 @@ e.g.
 .. code-block:: yaml
 
     agent_settings:
-        start_settings:
+        start_step: 25
-            start_step: 25
+        frequency: 20
-            frequency: 20
+        variance: 5
-            variance: 5
 
 ``start_step``
 ^^^^^^^^^^^^^^
@@ -153,4 +157,4 @@ If ``True``, gymnasium flattening will be performed on the observation space bef
 -----------------
 
 Agents will record their action log for each step. This is a summary of what the agent did, along with response information from requests within the simulation.
-A summary of the actions taken by the agent can be viewed using the `show_history()` function. By default, this will display all actions taken apart from ``DONOTHING``.
+A summary of the actions taken by the agent can be viewed using the `show_history()` function. By default, this will display all actions taken apart from ``do-nothing``.

docs/source/configuration/game.rst

@@ -59,4 +59,4 @@ These are used to determine the thresholds of high, medium and low categories fo
 ``seed``
 --------
 
-Used to configure the random seeds used within PrimAITE, ensuring determinism within episode/session runs. If empty or set to -1, no seed is set.
+Used to configure the random seeds used within PrimAITE, ensuring determinism within episode/session runs. If empty or set to -1, no seed is set. The given seed value is logged (by default) in ``primaite/<VERSION>/sessions/<DATE>/<TIME>/simulation_output``.

docs/source/configuration/io_settings.rst

@@ -14,7 +14,6 @@ This section configures how PrimAITE saves data during simulation and training.
 .. code-block:: yaml
 
     io_settings:
-        # save_logs: True
         save_agent_actions: True
         save_step_metadata: False
         save_pcap_logs: False
@@ -26,11 +25,6 @@ This section configures how PrimAITE saves data during simulation and training.
         agent_log_level: INFO
 
 
-``save_logs``
--------------
-
-*currently unused*.
-
 ``save_agent_actions``
 ----------------------
 

docs/source/configuration/simulation.rst

@@ -5,8 +5,7 @@
 
 ``simulation``
 ==============
-In this section the network layout is defined. This part of the config follows a hierarchical structure. Almost every component defines a ``ref`` field which acts as a human-readable unique identifier, used by other parts of the config, such as agents.
+In this section the network layout is defined. This part of the config follows a hierarchical structure.
-# TODO: ref field is no longer real
 At the top level of the network are ``nodes``, ``links`` and ``airspace``.
 
 e.g.
@@ -26,7 +25,7 @@ e.g.
 ``nodes``
 ---------
 
-This is where the list of nodes are defined. Some items will differ according to the node type, however, there will be common items such as a node's reference (which is used by the agent), the node's ``type`` and ``hostname``
+This is where the list of nodes are defined. Some items will differ according to the node type, however, there will be common items such as a node's hostname (which is used by the agent) and the node's ``type``.
 
 To see the configuration for these nodes, refer to the following:
 
@@ -74,10 +73,6 @@ this results in:
         endpoint_b_port: 2 # port 2 on switch
         bandwidth: 100
 
-``ref``
-^^^^^^^
-
-The human readable name for the link. Not used in code, however is useful for a human to understand what the link is for.
 
 ``endpoint_a_hostname``
 ^^^^^^^^^^^^^^^^^^^^^^^

docs/source/configuration/simulation/nodes/common/common_node_attributes.rst

@@ -4,11 +4,6 @@
 
 .. _common_node_attributes:
 
-``ref``
--------
-
-Human readable name used as reference for the |NODE|. Not used in code.
-
 ``hostname``
 ------------
 

docs/source/configuration/simulation/nodes/common/node_type_list.rst

@@ -12,6 +12,7 @@ Available options are:
 - ``computer``
 - ``firewall``
 - ``router``
+- ``wireless_router``
 - ``server``
 - ``switch``
 

docs/source/configuration/simulation/software/applications.rst

@@ -14,12 +14,10 @@ Applications takes a list of applications as shown in the example below.
 
 .. code-block:: yaml
 
-    - ref: client_1
+    - hostname: client_1
-    hostname: client_1
+      type: computer
-    type: computer
     ...
     applications:
-        - ref: example_application
         type: example_application_type
         options:
             # this section is different for each application

docs/source/configuration/simulation/software/services.rst

@@ -14,12 +14,10 @@ Services takes a list of services as shown in the example below.
 
 .. code-block:: yaml
 
-    - ref: client_1
     hostname: client_1
     type: computer
     ...
     applications:
-        - ref: example_service
         type: example_service_type
         options:
             # this section is different for each service