TAML Reference?
by Demolishun · in Torque 2D Beginner · 08/02/2013 (12:06 pm) · 8 replies
Okay, I am not working with T2D right now, but I am serializing T3D missions (possibly datablocks) into an XML format for use with a database. I know TAML is a replacement for datablocks in T2D, but I am wondering if it would work for converting mission scripts to XML.
I already have a simple XML format that I can convert to and from. It basically looks like this:
So basically I just create a tag like SimGroup based upon the class of the object. Then I assign any attributes as attributes of the object. I do filter out stuff that does not need to be saved like "parentGroup". I am not analyzing script either. I am parsing the live objects after loading a mission in memory to do the conversion.
So is there a spec for TAML? Would TAML be relatively close to this to be worth getting them into a similar format in case TAML comes over to T3D?
I already have a simple XML format that I can convert to and from. It basically looks like this:
<<object type> [<attribute>=<data>,...]>
<<object type> [<attribute>=<data>,...] />
</<object type>>
<!-- real data would look like this -->
<SimGroup name="MissionGroup">
<SimObject name="blah" />
<SimGroup name="SpawnSpheres">
<SpawnSphere position="0 0 0" />
</SimGroup>
</SimGroup>So basically I just create a tag like SimGroup based upon the class of the object. Then I assign any attributes as attributes of the object. I do filter out stuff that does not need to be saved like "parentGroup". I am not analyzing script either. I am parsing the live objects after loading a mission in memory to do the conversion.
So is there a spec for TAML? Would TAML be relatively close to this to be worth getting them into a similar format in case TAML comes over to T3D?
About the author
I love programming, I love programming things that go click, whirr, boom. For organized T3D Links visit: http://demolishun.com/?page_id=67
#3
1. TAML is a full persistence system. It was not a replacement for datablocks, rather a solution to many larger problems like asset management.
2. TAML is not a format. It can save and load XML, JSON, and binary. Those are formats.
3. Pay close attention to how collections are persisted. The approach TAML takes was reworked a couple of times by Melv.
08/02/2013 (12:56 pm)
Things worth noting:1. TAML is a full persistence system. It was not a replacement for datablocks, rather a solution to many larger problems like asset management.
2. TAML is not a format. It can save and load XML, JSON, and binary. Those are formats.
3. Pay close attention to how collections are persisted. The approach TAML takes was reworked a couple of times by Melv.
#4
I guess I misunderstood the purpose of TAML. So comparing TAML to a format is apples and oranges. I think the name ending with ML kind of suggests it is an XML format.
My goal with serialization was to allow me to manipulate the objects with XSLT. I find it interesting that TAML defines every possibly tag. I took a completely different approach in my XSLT. I pretty much allow the tags to be anything and can recreate the original TS by using things like "name(.)" and "@*" to match against tags and attributes. So I am not doing any scheme verification at all. However, because TAML defines tags that are basically SimObject names then it might be somewhat compatible.
Here is my XSLT to get back to TS:
github.com/Demolishun/Torque3D/blob/T3DProto90/My%20Projects/Proto90Days/game/py...
So maybe just doing what I am doing is fine. If TAML comes to T3D then I will look at this again.
08/02/2013 (2:25 pm)
@Michael,I guess I misunderstood the purpose of TAML. So comparing TAML to a format is apples and oranges. I think the name ending with ML kind of suggests it is an XML format.
My goal with serialization was to allow me to manipulate the objects with XSLT. I find it interesting that TAML defines every possibly tag. I took a completely different approach in my XSLT. I pretty much allow the tags to be anything and can recreate the original TS by using things like "name(.)" and "@*" to match against tags and attributes. So I am not doing any scheme verification at all. However, because TAML defines tags that are basically SimObject names then it might be somewhat compatible.
Here is my XSLT to get back to TS:
github.com/Demolishun/Torque3D/blob/T3DProto90/My%20Projects/Proto90Days/game/py...
So maybe just doing what I am doing is fine. If TAML comes to T3D then I will look at this again.
#5
I hope TAML makes it to T3D. My opinion is that it will greatly advance the "user-friendliness" of the engine and dramatically improve the asset pipeline. But what do I know? I'm the 2D guy =)
08/02/2013 (2:42 pm)
Quote:So comparing TAML to a format is apples and oranges.Basically. I know it's confusing now when you consider things like XML and XAML. I just want to make sure folks understand the truth behind TAML as it is now represented in T2D.
I hope TAML makes it to T3D. My opinion is that it will greatly advance the "user-friendliness" of the engine and dramatically improve the asset pipeline. But what do I know? I'm the 2D guy =)
#6
You are one of the enduring reasons I am interested in T2D. It is excellent technology and I would love to see a lot more cross pollination between the code bases. You are doing a great job of explaining this tech, thank you.
In fact I wish they shared the same render pipelines. T3D and T2D together would be an amazing engine. I think down the road as the community grows we will see a lot more "internal" engine work. I know I love getting into the pipes and valves, but that is not getting my game done. I guess it is a matter of balance and need.
08/02/2013 (2:51 pm)
@Michael,You are one of the enduring reasons I am interested in T2D. It is excellent technology and I would love to see a lot more cross pollination between the code bases. You are doing a great job of explaining this tech, thank you.
In fact I wish they shared the same render pipelines. T3D and T2D together would be an amazing engine. I think down the road as the community grows we will see a lot more "internal" engine work. I know I love getting into the pipes and valves, but that is not getting my game done. I guess it is a matter of balance and need.
#7
08/02/2013 (2:53 pm)
Many, many people desire the same thing. You can count me among them, provided stability and features are not sacrificed from the two. At two very specific points, the 2D and 3D engines were unified into a kickass codebase. Quote:All this has happened before, and all of it will happen again.
#8
08/02/2013 (4:29 pm)
Also confusing that the XML format files are named .taml ;). 
Employee Michael Perry
ZombieShortbus