Will TAML and the module system from Torque2D be ported to Torque3D?
by Peter C · in Torque 3D Professional · 03/01/2013 (12:32 pm) · 12 replies
I was wondering if the TAML and module systems were planned on being ported from Torque2D to Torque3D. Those systems look like they would become very useful down the line, and I would like to know if there are already plans to port it.
Thanks,
Peter
Thanks,
Peter
#2
Modules: What? Where? Are you talking the component system?
Please explain what you mean by modules. I have been working in the engine pretty deep and don't have a clue what you are saying. Perhaps I have been too deep to notice...
03/01/2013 (1:19 pm)
@Michael,Modules: What? Where? Are you talking the component system?
Please explain what you mean by modules. I have been working in the engine pretty deep and don't have a clue what you are saying. Perhaps I have been too deep to notice...
#3
Script modules as demonstrated within T2D are inherently allowed through the script package system. This is how mods worked for Tribes. This is what allowed the common + game paradigm to work in the legacy engines. Think of having a basic minimal functionality template that you start with. It allows tools usage, but there is no game there. You then activate a module containing x/y functionality/assets... add a few more and you have a sort-of game. This is the path taken in T2D with it's sandbox and toys approach. This is the path I/we have discussed for T3D. I've always said that even though most people don't grasp it, packages are your friend!
03/01/2013 (1:26 pm)
@Frank:Script modules as demonstrated within T2D are inherently allowed through the script package system. This is how mods worked for Tribes. This is what allowed the common + game paradigm to work in the legacy engines. Think of having a basic minimal functionality template that you start with. It allows tools usage, but there is no game there. You then activate a module containing x/y functionality/assets... add a few more and you have a sort-of game. This is the path taken in T2D with it's sandbox and toys approach. This is the path I/we have discussed for T3D. I've always said that even though most people don't grasp it, packages are your friend!
#4
@Michael Alright, in that case, is there any documentation or examples on how the script plugins work in T3D? Furthermore, do you have any information on how TAML was implemented with the differences between T2D and T2D MIT? I have no background in T2D, and am still getting used to T3D, and I am trying to evaluate what will need to be done to implement that functionality. Also, I fully agree on the modularity part, however I would suggest going one further and making each module a plugin/DLL. The problem with the current system is that it is highly monolithic in nature, which is a pain to work with when trying to add new functionality. That also leads me to the concern of the lack of using a namespace for the majority of Torque's code, but that's something I'll save for another day.
03/01/2013 (1:35 pm)
@Frank See here for examples: https://github.com/GarageGames/Torque2D/tree/master/modules@Michael Alright, in that case, is there any documentation or examples on how the script plugins work in T3D? Furthermore, do you have any information on how TAML was implemented with the differences between T2D and T2D MIT? I have no background in T2D, and am still getting used to T3D, and I am trying to evaluate what will need to be done to implement that functionality. Also, I fully agree on the modularity part, however I would suggest going one further and making each module a plugin/DLL. The problem with the current system is that it is highly monolithic in nature, which is a pain to work with when trying to add new functionality. That also leads me to the concern of the lack of using a namespace for the majority of Torque's code, but that's something I'll save for another day.
#5
Okay, you are talking script. I was thinking C++ code components and possibly modular objects built from gamebase. Although, the ability to assemble components into objects via script would be very nice.
Thanks for the clarification.
03/01/2013 (1:36 pm)
@Michael,Okay, you are talking script. I was thinking C++ code components and possibly modular objects built from gamebase. Although, the ability to assemble components into objects via script would be very nice.
Thanks for the clarification.
#6
An example would be how when the game is executed the core script package gets loaded and executed. The game script package is then loaded and executed to extend or override the functionality of the core. Essentially the game is a "mod" of the core. This can quite easily be broken down into smaller and discrete packages for specific functionality (the gametype system does this) and/or assets. I hinted at doing this in my open discussions of the template refactor, but the general feedback received indicated a lack of interest in such from the community. So no immediate work was done in this direction. But now that the new and improved T2D is on the scene such modularity is seen as more attractive -- but hey, it's a constantly evolving environment!
As for TAML, I'm only familiar with the term due to it being touted as the new data persistence format for T2D. I don't use T2D though, so don't know how it used or even what it would take to get it working within T3D.
03/01/2013 (2:03 pm)
Documentation of how to use packages (for mods/modules/extensions/plugins/whatever) in Torque through the package system? I have no idea, I've never looked at the documentation. Someone more informed about the documentation will have to step up to answer that.An example would be how when the game is executed the core script package gets loaded and executed. The game script package is then loaded and executed to extend or override the functionality of the core. Essentially the game is a "mod" of the core. This can quite easily be broken down into smaller and discrete packages for specific functionality (the gametype system does this) and/or assets. I hinted at doing this in my open discussions of the template refactor, but the general feedback received indicated a lack of interest in such from the community. So no immediate work was done in this direction. But now that the new and improved T2D is on the scene such modularity is seen as more attractive -- but hey, it's a constantly evolving environment!
As for TAML, I'm only familiar with the term due to it being touted as the new data persistence format for T2D. I don't use T2D though, so don't know how it used or even what it would take to get it working within T3D.
#7
I am sorry as I think I may have been one of the ignorant people that jumped on the "I hate packages" train. If you know a better way to do things I am all ears.
03/01/2013 (3:31 pm)
@Michael,I am sorry as I think I may have been one of the ignorant people that jumped on the "I hate packages" train. If you know a better way to do things I am all ears.
#8
03/01/2013 (4:32 pm)
I personally think that packages would be a really good idea. That would allow for much easier asset and resource reuse. It would also be really good for things such as mod support. 
#9
That is not accurate. The T2D module system has nothing to do with the script package system. It's a completely new and custom solution. Some of the toys do make use of packages though. We use them to override touch reaction on a SceneWindow. The Sandbox has its own touch/mouse reaction, but my DeathBallToy has a custom one. I activate the DeathBallToy package when the toy is loaded so I can have unique input.
The Module system has a completely different implementation and functionality. You can read the documentation on that here: Module Manager.
The TAML system resulted in a complete change in the class hierarchy for Torque 2D. You can read more about that system here.
03/02/2013 (7:27 am)
Just wanted to chime in to make a correction:Quote:Script modules as demonstrated within T2D are inherently allowed through the script package system. This is how mods worked for Tribes.
That is not accurate. The T2D module system has nothing to do with the script package system. It's a completely new and custom solution. Some of the toys do make use of packages though. We use them to override touch reaction on a SceneWindow. The Sandbox has its own touch/mouse reaction, but my DeathBallToy has a custom one. I activate the DeathBallToy package when the toy is loaded so I can have unique input.
The Module system has a completely different implementation and functionality. You can read the documentation on that here: Module Manager.
The TAML system resulted in a complete change in the class hierarchy for Torque 2D. You can read more about that system here.
#10
03/02/2013 (12:36 pm)
I can't imaging hating packages. They're very handy if used correctly - just be sure to know what package is active when debugging. 
#11
The TAML stuff however didn't force any major changes to the engine types, it only required a few changes to support field-prefixes which are used indirectly by the asset system for things like "@asset=" etc. Apart from that, integrating TAML into T3D would be pretty easy. Obviously you would need to modify the includes (etc) as those are all in different locations.
03/03/2013 (10:19 am)
Indeed, the T2D module system doesn't utilize the packages stuff at all. The TAML stuff however didn't force any major changes to the engine types, it only required a few changes to support field-prefixes which are used indirectly by the asset system for things like "@asset=" etc. Apart from that, integrating TAML into T3D would be pretty easy. Obviously you would need to modify the includes (etc) as those are all in different locations.
#12
03/03/2013 (10:30 am)
Just to be clear: my comment was intended to say that similar, although not exact, "modular" functionality is (and has always been) easily (in my opinion) achievable using existing features/functionality (packages) for T3D, and was not meant to imply any technical insight into how it was enabled/designed/setup for T2D. 
Associate Michael Hall
Distracted...
If there was a demand for it, then sure it could happen. It would probably happen quicker if someone were to present a working pull request demonstrating the application of the feature.
MODULES
We have talked about modularity in our Steering Committee meetings. The current template restructuring and cleanup we've talked about can be seen as a transition towards a more modular template build system allowing more modular functionality -- although we will not call them "toys"! It should be known however that there already is a means of using so-called modules (mods, extensions, plugins, whatever you want to call them) within Torque -- it's had that from day one (even the legacy engines) and that functionality has not been lost, only under-utilized.
Personally, I find myself more and more wanting to rewrite the entirety of the (basic) template from scratch. Eight lines of script is all it takes to get a Torque 3D window open that doesn't do anything. Everything on top of that could then be assembled from modules...