This looks fantastic so far for learning Torquescript, but applying Torquescript knowledge into making add-ons is another huge step.
I've worked with numerous proprietary languages, from Torquescript, to Salesforce's Apex language, as well as numerous game's implementations of existing languages, like C# in Space Engineers. In every case, even if you have the language down very solidly, you still have to learn the softwares's API; how you interface with it. What classes are available to you to use, what function should your script call to make the software do X, what should your script hook into to detect when the software does Y, etc. And that's something Blockland/Torque doesn't do a good job explaining, and if you could find a way to do that, it would be great.
For example, it's not immediately apparent that in order to make a slash command, you make a function prefixed with "serverCmd". But rather than expecting people to know that, Gytyyhgfffff gave the idea of encapsulating that into a discrete "slash command" block.
As another example, say we want a scratch script to do something when a player talks. Maybe instead of having to create a "package" block, and then a "packaged function" block, then have to know the name of the function you need to package (serverCmdMessagesent), perhaps you could have this encapsulated into a "when a player talks" block?
The more things can be encapsulated, the better. Then, if you can provide a way of seeing in real-time what the raw code is, instead of exporting to a file and opening it, you could more easily see what the game is actually doing
