Further simulation bugfixes, allow subclassing

[prime31]

That all looks awesome. The only thing that might cause issues is moving it out if Plugins. Boo and UnityScript users won't be able to access it but I suppose if they are foolish enough to use those languages they can deal with the consequences ;)

[fresswolf]

You are right. I don't know if anyone is using the library together with on of those languages. I've looked a bit further into the issue and I think the default Unity way would be to put the library into the "Standard Assets" folder. That folder is compiled before other scripts, thus can be accessed by the Boo users. One drawback is that the editor scripts can't be in the TouchKit subfolder, as all editor scripts in "Standard Assets" must be placed in the "Standard Assets/Editor" folder (strange and ugly Unity rules..). Now that won't solve the issues mentioned in commit 6c9d9c8. I can't speak for others but at our company, we include such open source libraries as git submodules. Now when I want to create a custom gesture recognizer (which I don't want or am not allowed to publish as open source), I can't subclass the awesome TKAbstractGestureRecognizer, as some of it's virtual methods are declared as internal and can't be overridden. The reason for that is that Unity throws the scripts in "Plugins" or "Standard Assets" into a separate assembly.

So my suggestions are:

• Put TouchKit into the "Standard Assets" folder
• Edit the gesture recognizers and replace the "internal" keyword by "protected"

If you agree with that, I will create another pull request with those changes

[prime31]

I think the TouchKit folder is fine. Anyone still using Boo or UnityScript can move stuff around themselves as a penalty for using them.