Corrects poor wording and obvious mistakes in Beta_Test_Guide.md

docs/Beta_Test_Guide.md

@@ -10,7 +10,7 @@ You are interrested in testing the bleeding edge functionnalities and features a
 
 This might be a bit daunting at first, but the rewards in term of simplified workflow and direct access to new features is well worth the effort! If you have any problem during the setup or at any other point, don't hesitate to ask the [community](Communities) for help!
 
-This guide assumes that you already setup your development environment, lust like a "normal" mission designer. Which means Lua Development Tools (LDT) is installed on your computer, and you already know how to create a mission using MOOSE. If it is not the case, please follow the instructions [here](http://flightcontrol-master.github.io/MOOSE/Usage_Guide.html).
+This guide assumes that you already setup your development environment, like a "normal" mission designer. Which means Lua Development Tools (LDT) is installed on your computer, and you already know how to create a mission using MOOSE. If it is not the case, please follow the instructions [here](http://flightcontrol-master.github.io/MOOSE/Usage_Guide.html) before proceeding.
 
 # 1) Installation
 
@@ -38,7 +38,7 @@ Install [7-Zip](http://www.7-zip.org/) if you don't already have it. It is a fre
 ### 1.3) Run the Install script
 
 Because DCS is going to load Moose dynamically (more on that later), we need to do some (slightly) advanced stuff to finish the setup of your own development enviroment. Thankfully we wrote a program to do all of it automatically for you !
-Browse to your local MOOSE repository and run `Moose Development Environment Setup\MooseDevelopmentEnvironmentSetup.exe` **as an administrator** (Select the file > Left Click > Run as administrator). 
+Browse to your local MOOSE repository and run `Moose Development Environment Setup\MooseDevelopmentEnvironmentSetup.exe` **as an administrator** (Select the file > Right Click > Run as administrator). 
 * The Splash screen opens, click ok
 * Enter (or browse for) the 3 paths asked and click ok. Don't worry about the trailing backslashs.
 * Let the program do it's magic ! 
@@ -53,7 +53,7 @@ The software will do the following:
 * Add 7-Zip to your PATH environment variable (this explains the restart requirement)
 * Copy a precompiled version of Lua 5.1 to your `Program Files` (this explains the administrator priviledge requirement)
 
-The script is made in AutoIt, it is available near the executable if you want to know what it does. If you are still reluctant, the whole process can be done manually by experienced users, get in touch with the [community](Communities)!
+The script is made in AutoIt, it is available near the executable if you want to know what it does. If you are still reluctant to do this, the whole process can be done manually by experienced users, get in touch with the [community](Communities)!
 
 # 2) MOOSE Directory Structure
 
@@ -70,11 +70,11 @@ The MOOSE framework is devided into a couple of directories:
 
 Moose static loading is what the "normal" mission designer uses. Simply put, there is a tool which concatenates every .lua file which constitutes Moose into just one: Moose.lua. This is the file which is loaded in Mission Editorr by the mission designer.
 This process is very useful when you are using a stable Release of Moose which don't change often, because it is really easy to set up for the mission designer. It also allows him to release missions which are contained in their entirety in the .miz file.
-But in a context in wich Moose changes sometimes multiple times a day, static loading would require the generation of a new Moose.lua each time, replace the old Moose.lua in the .miz file you are using to test your changes, and play the mission. Add to this process the fact that the Mission Editor doesn't like changes to the .miz file while the mission is open, so you would need to close and reopen the ME everytime, and this process becomes unworkable for both the tester and the developper.
+But in a context in wich Moose changes often, static loading would require the generation of a new Moose.lua for every change and the replacement the old Moose.lua in the .miz file you are using to test the changes. Add to this cumbersome process the fact that the Mission Editor doesn't like changes to the .miz file while it is open, so you would need to close and reopen the Mission Editor for every change, and this process becomes unworkable for both the tester and the developper.
 
 ## 3.2) Dynamic Loading
 
-Enter Moose Dynamic loading. In this process, the Moose.lua you insert in your .miz file looks for every .lua which constitute Moose in `DCSWorld\Scripts`, and asks DCS to load them. This way, the latest changes to Moose's .lua files in `DCSWorld\Scripts` are automatically taken into account when you restart the mission, no need to fiddle around with the .miz file or to close the mission editor!
+Enter Moose Dynamic loading. In this process, the Moose.lua you insert in your .miz file looks for every .lua which constitute Moose in `DCSWorld\Scripts`, and asks DCS to load them during the mission startup. This way, the latest changes to Moose's .lua files in `DCSWorld\Scripts` are automatically taken into account when you restart the mission, no need to fiddle around with the .miz file or to close the mission editor!
 Now, there is still a problem left : you wouldn't want to have to copy the Moose's .lua files from your local repository to `DCSWorld\Scripts` everytime you retrieve a new version of Moose. The solution to this problem is a dynamic link! It is created by the Install Scipt (see above), and, simply put, makes sure that the folder `DCSWorld\Scripts\Moose` is always in sync with your local repository. That way, everytime you want to update to the next Moose, you simply sync your local repository with the remote with GitHub, and restart your mission !
 Note that if you want to release your missions to end users, you will need to make it use the static loading process. There is a tool to automate this task, read below.