As for the trustworthiness of MS and the freedom of C#/Mono, it's not something I'm at all worried about. Thing is, if MS tomorrow suddenly decided to take off their mask and unveil themselves as a Scooby-Doo villain, then that just means that people willing to accept the terms of that will use C#, while others won't. Same as now.
They already unmasked themselves as the villain.
My point is that the main advantage with Torque3D is that it is open source, if you now keep implementing shady stuff you eventually flush the main advantage down the toilet.
Sure if someone cannot help himself and wants to implement C# he can do that, since it is open source, but please keep it out of the main repo.
Implementing support for C# has no negative impacts on the open-source-ness of the engine. You would be free to not utilize that plugin in your builds.
Hey @ JeffR
Have a few questions / Suggestions for the clean core, Terrain, other bits of T3D and beyond.
1. Will Torque 3.11 include the new PBR lighting system and E/C work you have been doing? I am waiting for the PBR and EC system to make it into a binary version of T3D.
2. Are there any plans to upgrade to physx 3.4? From what I understand we are on 3.3 and the origin rebasing feature in 3.4 would be beneficial for much larger worlds.
3. As for terrain - What is the plan in regards to that?
1) E/C yes, PBR no.
With the E/C stuff, it's much easier to leave the existing game classes in place(just flagged as deprecated) while pushing for the E/C stuff and various premade GameObjects to act as replacements for the old game classes like Player. for PBR though, you either use PBR or not, so it's definitely a larger, breaking change.
2) Yep. There was some compaitibilty issues with VS2017 and 3.4, but it sounds like recent updates to both have resolved that. I'll be testing on that tonight or tomorrow so we can get that PR rolled in.
3) Quite a number of things have been discussed, but we haven't fully pegged on anything concrete yet. Major topics involve it being easier to stitch terrain together so you can make larger worlds without having to do a lot of weird juggling of terrain blocks. It should just be a natural thing to expand the terrain's scope. Likewise being able to go back and adjust texture and terrain mesh densities, so you can tweak stuff without having to start all over, because duh
The other future considerations would be either small tweaks to the current means of texturing so it's a bit easier to comprehend(adjusting names of texture maps in the editor, etc) but we've also been mulling on just jumping straight to full Virtual Textures. Using VTs means an overhaul on the toolset, but it'd work far better for artists(since you'd just paint down the material into the map, blending would happen as part of the paint action, not a blit-at-runtime bit of render voodoo), and would be WAY more efficient to render.