Rename page, formatting

Converting-Game-Commands-to-Game-Actions.md

@@ -4,7 +4,6 @@ For this tutorial we will convert `GAME_COMMAND_CHANGE_SURFACE_STYLE` to `Surfac
 # Analysis
 ## Calling
 Start by working out how the game command is called. This can be done for looking for all references to `GAME_COMMAND_CHANGE_SURFACE_STYLE`. From this search we find there are 3 places where it is called from. They are all from tools. All of the calls are the last call of a function and no state from the output of the action are used. This makes things very easy as there is no requirement to use callbacks or complex return values.
-
 ```
                 gGameCommandErrorTitle = STR_CANT_CHANGE_LAND_TYPE;
                 game_do_command(
@@ -15,12 +14,10 @@ Start by working out how the game command is called. This can be done for lookin
 Notice that the error title is `STR_CANT_CHANGE_LAND_TYPE` this will be used for failure returning within the game action function. Setting the toolId at the end does not depend on the output of this function and should be safe to do even with network delay. If it isn't it may need wrapped in a callback.
 
 ## Game Command Function
-
 Refer to [[Game Commands]] for notes on the function.
 
 # Create New Class
 ## Create New Header
-
 For ever game action there is a header created in the src/openrct2/actions/ folder. The header should have the same name as the class. We will call it `SurfaceSetStyleAction.hpp` to be consistent with the naming convention. Create a stub class for SurfaceSetStyleAction.
 ```
 #pragma once
@@ -58,12 +55,12 @@ Register<SurfaceSetStyleAction>();
 ## Work out the Parameters
 Have a look at the game command and make a list of all of the parameters.
 1. int32_t x0, 
-1. int32_t y0, 
-1. int32_t x1, 
-1. int32_t y1, 
-1. uint8_t surfaceStyle, 
-1. uint8_t edgeStyle, 
-1. uint8_t flags
+2. int32_t y0, 
+3. int32_t x1, 
+4. int32_t y1, 
+5. uint8_t surfaceStyle, 
+6. uint8_t edgeStyle, 
+7. uint8_t flags
 
 Parameter 1-4 is a map range and should use `struct MapRange`. Parameter 5-6 are the styles that are set, both are required in our action. Parameter 7 is the flags, this is no longer passed directly into the function and is therefore not required.
 
@@ -95,6 +92,7 @@ Game Actions need a serialise function to send the parameters over the network.
         stream << DS_TAG(_range) << DS_TAG(_surfaceStyle) << DS_TAG(_edgeStyle);
     }
 ```
+
 # Query Function
 I like to create the query function by copying and pasting the game command directly into the game action and massaging until it fits.
 
@@ -355,11 +353,9 @@ New code
 
         return res;
 ```
-
 At this point the Query is now complete. Further refactoring could look at splitting it up into separate functions.
 
 ## Execute Function
-
 Within the execute function we do not need to check for validity of parameters. But we do need to do the parts that were guarded by GAME_COMMAND_FLAG_APPLY.
 
 The start of the function is pretty similar:
@@ -444,11 +440,9 @@ We can then go into the main for loop.
 
         return res;
 ```
-
 The execute function has now been completed. There is a lot of overlap between the two functions and it may make more sense to combine the function into one again. We are now ready to start moving the three calls to the game command into three calls to the GameAction.
 
 # Modify Callers
-
 Now that the game action is setup we can modify the callers to use the new class. Start with just one and test it before rolling it out to all of the others.
 ```
                 gGameCommandErrorTitle = STR_CANT_CHANGE_LAND_TYPE; // This is no longer used.