Fixed create system plugins tutorial

tutorials/create_system_plugins.md

@@ -16,31 +16,31 @@ steps below. The fully working example is available [here](https://github.com/ga
 
 The first step of implementing a system plugin is to determine the subset of
 available interfaces to implement. Aside from the base `System` object,
-there are currently four additional available interfaces:
+there are currently five additional available interfaces:
 
 1. ISystemConfigure
-  1. Has read-write access to world entities and components.
-  2. Executed once the moment the plugin is loaded.
-  3. Can be used to get custom configuration from the SDF file, register events
+   1. Has read-write access to world entities and components.
+   2. Executed once the moment the plugin is loaded.
+   3. Can be used to get custom configuration from the SDF file, register events
      with the event manager, as well as modifying entities and components.
 2. ISystemPreUpdate
-  1. Has read-write access to world entities and components.
-  2. This is where systems say what they'd like to happen at time gz::sim::UpdateInfo::simTime.
-  3. Can be used to modify state before physics runs, for example for applying control signals or performing network synchronization.
+   1. Has read-write access to world entities and components.
+   2. This is where systems say what they'd like to happen at time gz::sim::UpdateInfo::simTime.
+   3. Can be used to modify state before physics runs, for example for applying control signals or performing network synchronization.
 3. ISystemUpdate
-  1. Has read-write access to world entities and components.
-  2. Used for physics simulation step (i.e., simulates what happens at time gz::sim::UpdateInfo::simTime).
+   1. Has read-write access to world entities and components.
+   2. Used for physics simulation step (i.e., simulates what happens at time gz::sim::UpdateInfo::simTime).
 4. ISystemPostUpdate
-  1. Has read-only access to world entities and components.
-  2. Captures everything that happened at time gz::sim::UpdateInfo::simTime.
-  3. Used to read out results at the end of a simulation step to be used for sensor or controller updates.
+   1. Has read-only access to world entities and components.
+   2. Captures everything that happened at time gz::sim::UpdateInfo::simTime.
+   3. Used to read out results at the end of a simulation step to be used for sensor or controller updates.
 5. ISystemReset
-  1. Has read-write access to world entities and components.
-  2. Executed once the moment the plugin is reset.
+   1. Has read-write access to world entities and components.
+   2. Executed once the moment the plugin is reset.
 
-It's important to note that gz::sim::UpdateInfo::simTime does not refer to the current time, but the time reached after the `PreUpdate` and `Update` calls have finished.
+It's important to note that `gz::sim::UpdateInfo::simTime` does not refer to the current time, but the time reached after the `PreUpdate` and `Update` calls have finished.
 So, if any of the `*Update` functions are called with simulation paused, time does not advance, which means the time reached after `PreUpdate` and `Update` is the same as the starting time.
-This explains why gz::sim::UpdateInfo::simTime is initially 0 if simulation is started paused, while gz::sim::UpdateInfo::simTime is initially gz::sim::UpdateInfo::dt if simulation is started un-paused.
+This explains why `gz::sim::UpdateInfo::simTime` is initially 0 if simulation is started paused, while `gz::sim::UpdateInfo::simTime` is initially `gz::sim::UpdateInfo::dt` if simulation is started un-paused.
 
 Systems that are only used to read the current state of the world (sensors,
 graphics, and rendering) should implement `ISystemPostUpdate`.