A few fixes for the Upgrade Guide

documentation/01_community/11-upgrade-guide.html.md

@@ -3,37 +3,37 @@ title: "Upgrade Guide"
 ```
 ## Upgrading from HaxeFlixel 3.0.4 to 3.1.0
 
-HaxeFlixel 3.1 is a continuization of our efforts of making the API cleaner and more intuitive, keeping the amount of bugs as low as possible and adding new useful features. It is one of the biggest releases so far.
+HaxeFlixel 3.1 is a continuization of our efforts of making the API cleaner and more intuitive, keeping the amount of bugs as low as possible and adding new features. It is one of the biggest releases so far.
 
-This page is a summary of all changes - for a more in-depth list including all the changes, please refer to the [changelog](https://github.com/HaxeFlixel/flixel/blob/dev/CHANGELOG.md).
+This page is a summary of all breaking changes - for a more in-depth list of changes, please refer to the [changelog](https://github.com/HaxeFlixel/flixel/blob/dev/CHANGELOG.md).
 
 ### `FlxTypedButton` / `FlxButton` refactor
 
 `FlxTypedButton` has been completely refactored, which includes the following breaking API changes:
 
-- A new `FlxButtonEvent` class was added for the onDown, onUp, onOver and onOut events. Instead of the `setCallback()`-functions. You now set callbacks like this:
+- A new `FlxButtonEvent` class was added for the onDown, onUp, onOver and onOut events. Instead of the `setCallback()`-functions, you now set callbacks like this:
 
 		button.onDown.callback = someFunction;
 
 	This class also contains a `sound` property:
 		
 		button.onDown.sound = FlxG.sound.load("pathToASound");
 
-	You might say: *"What happened to callback arguments? The `callback` has the type `Void->Void`!"*
+	You might say: *"What happened to custom callback arguments? The `callback` has the type `Void->Void`!"*
 	While that's true, you can still *use* callback arguments by leveraging [function binding](http://haxe.org/manual/haxe3/migration#callback):
 
 		button.onDown.callback = someFunction.bind(1);
 
 	In that example, `someFunction` is of type `Int->Void` and will always be called with 1.
 
-- `labelOffset:FlxPoint` is now an array `labelOffsets:Array<FlxPoint>` which uses the button status constants as indices for more control over the button position.
+- `labelOffset:FlxPoint` is now an array (`labelOffsets:Array<FlxPoint>`) which uses the button status constants as indices for more control over the button position.
 - The highlight frame of the button spritesheet is now ignored by default on mobile devices, since it does not make much sense there - you can't hover over a button on a touchscreen.
-- It is now also possible to "swipe-press" a button, which means you can press it if the input (mouse or touch) has been moved over the button and then relased. Previously, you could only press a button if the press happened while you were already hovering over the button. This especially makes `FlxVirtualPad` more usable.
+- It is now possible to "swipe-press" a button, which means you can press it if the input (mouse or touch) has been moved over the button and then relased. Previously, you could only press a button if the press happened while you were *already* hovering over the button. This especially makes `FlxVirtualPad` more usable.
 
 
 ### FlxG.keys and FlxG.keyboard
 
-In 3.0, FlxG.keyboard has been introduced. However, we realized that this does not make for an intuitive API - you can't tell the difference between the two from their name alone. In fact, even if you have been using the two for a while, it still seems confusing.
+In 3.0.0, FlxG.keyboard has been introduced. However, we realized that this does not make for an intuitive API - you can't tell the difference between the two from their name alone. In fact, even if you have been using the two for a while, it still seems confusing.
 
 This is why me merged the two classes again. This required removing the following functions:
 
@@ -64,7 +64,7 @@ if (FlxG.keys.anyPressed(["LEFT", "RIGHT"])) {}
 The following breaking changes were made during the refactor of `FlxMouse`:
 
 
-| HaxeFlixel 3.0                          | HaxeFlixel 3.1                         |
+| HaxeFlixel 3.0.x                        | HaxeFlixel 3.1.0                         |
 | --------------------------------------- | ---------------------------------------|
 | FlxG.mouse.show();                 	  | FlxG.mouse.visible = true;             |
 |                   	                  |	FlxG.mouse.load();             |
@@ -73,13 +73,13 @@ The following breaking changes were made during the refactor of `FlxMouse`:
 
 Also, the mouse cursor is now visible by default on non-mobile devices.
 
-The middle and right click events of the mouse are now set up by default, which means `FLX_MOUSE_ADVANCED` has turned into `FLX_NO_MOUSE_ADVANCED`.
+The middle and right click event listeners are now set up by default, which means `FLX_MOUSE_ADVANCED` has turned into `FLX_NO_MOUSE_ADVANCED`.
 
 ### The recording system and `FlxRandom`
 
 To put it bluntly... `FlxRandom` was a bit of a mess in 3.0. Some of the functions were deterministic, others weren't, which as a result made it very difficult to create deterministic games suitable for the recording system.
 
-In 3.1, `FlxRandom` has been completely refactored to be completely deterministic. A new algorithm for pseudo-random-number-generation was implemented, **which makes old replays incompatible** / they will have unpredictable results.
+In 3.1.0, `FlxRandom` has been refactored to be completely deterministic. A new algorithm for pseudo-random-number-generation was implemented, **which makes old replays incompatible** / they will have unpredictable results.
 
 Additionally, the following functions have been added to `FlxRandom`:
 
@@ -91,7 +91,7 @@ Additionally, the following functions have been added to `FlxRandom`:
 
 A noteworthy amount of fields inside of `FlxSprite` have been renamed to increase the consistency with other parts of the API:
 
-| HaxeFlixel 3.0                          | HaxeFlixel 3.1                         |
+| HaxeFlixel 3.0.x                          | HaxeFlixel 3.1.0                         |
 | --------------------------------------- | ---------------------------------------|
 | loadfromSprite()                 	  | loadGraphicFromSprite()                |
 | setGraphicDimensions()                  | setGraphicSize()            	   |
@@ -103,15 +103,16 @@ A noteworthy amount of fields inside of `FlxSprite` have been renamed to increas
 
 ### Scale Modes
 
-HaxeFlixel 3.1 introduces scale modes to simplify targetting multiple resolutions. Because of this, `FlxG.autoResize` has been removed. 
-`FlxG.scaleMode` can be an instance of the following classes:
+HaxeFlixel 3.1.0 introduces scale modes to simplify targetting multiple resolutions. `FlxG.scaleMode` can be an instance of the following classes:
 
 -  `RatioScaleMode` (default!)
 -  `FillScaleMode`
 -  `FixedScaleMode`
 -  `RelativeScaleMode`
 -  `StageSizeScaleMode`
 
+This change made `FlxG.autoResize` obsolete and it has thus been removed. 
+
 You can also write a custom scale mode that extends `BaseScaleMode`.
 
 Be sure to check out the [ScaleModes demo](http://haxeflixel.com/demos/ScaleModes/).