Fix typos in README.md

README.md

@@ -166,7 +166,7 @@ Each module, whether an Engine module or Plugin module, when built for Windows,
 
 Replacing 'Win64' with 'Win32' if you are building the editor for 32-bit Windows.
 
-For Unreal Engine version 4.26, when I build the UE4 project there are 395 Engine modules (in the <tt>Engine/Binaries/Win64</tt> folder) and 591 Plugin modules (under the <tt>Engine/Plugins</tt> folder).  If you create an "empty" C++ project (like when using the "First Person' or 'Third Person' template), clean the solution and then build the editor just for the game project, there are 352 Engine modules and only 181 Plugin modules.
+For Unreal Engine version 4.26, when I build the UE4 project there are 395 Engine modules (in the <tt>Engine/Binaries/Win64</tt> folder) and 591 Plugin modules (under the <tt>Engine/Plugins</tt> folder).  If you create an "empty" C++ project (like when using the 'First Person' or 'Third Person' template), clean the solution and then build the editor just for the game project, there are 352 Engine modules and only 181 Plugin modules.
 
 Keeping that in mind, you can use "RunUAT.bat BuildEditor" without specifying a project to build the editor for the UE4 editor project and then use "RunUAT.bat BuildEditor -project=\<your_project_here\>" to build the editor for your game project to build everything, or you can just use "RunUAT.bat BuildEditor -project=\<your_project_here\>" to only build the modules required by your project.
 
@@ -434,7 +434,7 @@ You don't need to understand what all of these arguments do, and some of them, l
 
 <tt>"-platform="</tt> - This is the platform that you want to package for.  For Windows this would typically be "Win64" for 64-bit Windows operating systems.
 
-<tt>"-configuration="</tt> - This indicates which "build configuration" you want to use, which identifies which game executable will be included in the packaged build.  This can be "Development" to include the executable that has more log output and has the in-game console command window enabled.  It can be "Shipping" to include the shipping executable which has more optimized code and runs faster, but has no output and has the in-game console command window disabled (which makes debugging packaged game issues more difficult).  For people building from source code, you can also use the "Test" configuration which has less output than the "Development" configuration and makes it a little closer in performance to the "Shipping" configuration (but it still has the in-game console window enabled).  The "Test" configuration also has some 'stats' disabled so if you use any of the 'stat' commands in the console to help with profiling performance, you may be limited by some things not be available (like "stat fps" for example, but "stat unit" still works).
+<tt>"-configuration="</tt> - This indicates which "build configuration" you want to use, which identifies which game executable will be included in the packaged build.  This can be "Development" to include the executable that has more log output and has the in-game console command window enabled.  It can be "Shipping" to include the shipping executable which has more optimized code and runs faster, but has no output and has the in-game console command window disabled (which makes debugging packaged game issues more difficult).  For people building from source code, you can also use the "Test" configuration which has less output than the "Development" configuration and makes it a little closer in performance to the "Shipping" configuration (but it still has the in-game console window enabled).  The "Test" configuration also has some 'stats' disabled so if you use any of the 'stat' commands in the console to help with profiling performance, you may be limited by some things not being available (like "stat fps" for example, but "stat unit" still works).
 
 <tt>"-pak"</tt> - This tells the packaging tool to put all of the cooked content into Unreal Engine .pak files, which can be compressed.  Pak files can also be encrypted to make it more difficult for people to tamper with your game or extract assets from your game.  Putting all your content into .pak files also makes it much harder to see which asets are getting packaged and which are not.  If you don't include the "-pak" argument, the packaged game will have asset files as "loose" files with the same folder structure as your game's Content folder, so temporarily disabling the .pak file format can help you identify when assets aren't getting cooked or staged.
 
@@ -481,7 +481,7 @@ I then used UnrealFrontend to create a profile that only cooked the 'ThirdPerson
     Staged folder:        236 MB, 23 Files (.pak file size was 107 MB)
     PackagedGame folder:  236 MB, 23 Files (.pak file size was 107 MB)
 
-The game still runs the same.  You load into the 'ThirdPersonExampleMap' and it has the same content as when no maps were specified, but I eliminated all the Starter Content that was not actually used by the game.  This make the packaged game **about one third** the size of the "Package Project" defaults!!!
+The game still runs the same.  You load into the 'ThirdPersonExampleMap' and it has the same content as when no maps were specified, but I eliminated all the Starter Content that was not actually used by the game.  This makes the packaged game **about one third** the size of the "Package Project" defaults!!!
 
 So, specifying specific maps to cook can make the packaged game smaller, but there is a "down side" to this.  If you are dynamically loading content at run-time (like loading custom skins for a character), if that content does not have a "hard" reference in a map or in your user interface, then that content will not get cooked (since it's not referenced by any other content).  To prevent this problem, there is an .ini setting you can use to add specific folders to a list to indicate that ALL the content in those folders (and sub-folders) should ALWAYS be cooked even if they aren't referenced by anything.