- Fixed console warnings raised when receiving Sandbox manipulation events occur in an unexpected order (this can happen but  we don't need to see it spamming the console).
- Stopped the MultiWindowToy from mounting using "angle" to stop the view from spinning like crazy.
- Created README.md. Still needs filling out.
- TAML now supports writing and reading JSON.  By default it will use a schema that is strictly compatible with JSON RFC4627 (specifically the part about member names must be unique) however TAML does not care about this and it can be turned off with the console variable "$pref::T2D::JSONStrict" (set it to false).
- TAML adheres to unique member names by adding a suffix.  The member names that do this are the ones that represent children types or custom node names.  The JSON writer has a unique serial number which is increments during writing however you are free to configure the actual format by changing the following in the "tamlJSONWriter.cc" file (at the top): StringTableEntry JSON_RFC4627_NAME_MANGLING_FORMAT = StringTable->insert( "%s[%d]" );
- Taml also allows you to configure which characters are used to separate the type/node-name from the index again using an entry in the "tamlJSONWriter.cc": StringTableEntry JSON_RFC4627_NAME_MANGLING_CHARACTERS = StringTable->insert(" !$%^&*()-+{}[]@:~#|\\/?<>,.\n\r\t");

- TAML already will auto-detects the file type by extension (the defaults are XML is ".taml", BINARY is ".baml") and JSON now has a default of ".json".  As always, you are free to changes these defaults in the C++ code or on a TAML per-instance basis.
tutorial subtle improvement: change old style getWord(%this.upKey, 0) to %this.upKey._0 .
- Removed obsolete file from projects.
- Fixed console warning from CollisionToy (zero-sized dimension was being specified).
- Fixed console warning from CompundObjectsToy (bad layout mode was being specified).
- Completely rewritten the Taml visitor/parser set-up this morning.  Now TAML can perform parsing requests for visitors for potentially any format i.e. you can write a visitor without having knowledge of the format being read.  Only an XML parser is currently present but I'm now writing JSON and BINARY parsers.  With a JSON and BINARY parser in place you will be able to define things like asset-definitions and module-definitions in any TAML format (any that has a parser).
- Added JSON parser.  You can now write module and assets using JSON because there's a parser available (it can even update so it works with renaming assets etc).
tutorial tweaks that are not necessary but will make the tutorial a bit easier:
removed unnecessary calls in ShooterControls::onRemoveBehavior
fixed a bad reference to caustics particle effect
Merge remote-tracking branch 'remotes/upstream/development' into development

Conflicts:
	modules/TropicalAssets/1/assets/particles/caustics.asset.taml
- Fixed issue reported on garagegames.com/community/forums/viewthread/133647.
- Batch renderer now works exclusively with triangles making the quads as special-case of two triangles.  The changes remove the single/multiple strict batching therefore this metric has been removed from the DebugStats which causes the changes outside of the BatchRender type.
Merge pull request #50 from WildTurkeyUK/triangle_batching

- Batch renderer now works exclusively with triangles making the quads a...
Merge branch 'development' of https://github.com/GarageGames/Torque2D into development
Merge pull request #51 from doodaddy64/development

Development
update the creation of torqueScript html documentation via doxygen.
* updates to consoleDoc.cc
  *  output global script functions as "groups" instead of a "namespace".
  * this helps create an organization that isn't hacking the "namespace" C++ concept
* a new doxygen "layout" file
  * uses "groups" instead of "namespace" to get global functions organized well
  * for classes, uses the term "methods" and "fields" in place of "public attributes" and other default C++ what-not
* a new css files.
  * based on doxygen default but with much less bold text. :)
  * keeps all the unnecessary configuration in tact.  it doesn't hurt and it will be easier to diff with future doxygen defaults
in the docs, all parameters should be on one line like so:
   string Vector2Direction ( F32 angle, F32 magnitude )
documentation upgrade and cleanup
 * support torque2D doxygen
 * support for torqueScript doxygen on the code base (not by dumping symbols with a script)

moved support files (css, menu layout, footer/header) to a config dir
moved config files (run doxygen for engine or script) into config dir
some updates to doxygen config files.  getting closer to a system that documents torque2D with tags.  Then documents TorqueScript as a separate doc with links into the torque2D docs.  Before there was a concept for ConsoleFunctions and now there is a decent concept for ConsoleMethods as well.  Note that doxygen is unhappy with this idea as it was not designed for this.   So I'm trying to keep it as simple as possible while still working (frankly tricking Doxygen).