Looking for an example
by Chase Webb · in Torque 2D Beginner · 06/16/2014 (6:54 am) · 16 replies
Hello World!
So this is probably going to seem like an odd request, but could someone make (or find) a quick example of creating a GUI button without using a taml file? It looks like the Sandbox makes its buttons for each toy via a combination of functions, but I've not had success in duplicating the feat in a single script yet.
You might be wondering why I want to try to do something like this without the awesome taml system. Honestly, it's because I want to try some fancy IF statement combinations for the little editor I'm making for my game, and it appears that it would be easier to do it that way than through multiple separate taml files.
If it turns out I'm wrong, I'll post my findings here :P
So this is probably going to seem like an odd request, but could someone make (or find) a quick example of creating a GUI button without using a taml file? It looks like the Sandbox makes its buttons for each toy via a combination of functions, but I've not had success in duplicating the feat in a single script yet.
You might be wondering why I want to try to do something like this without the awesome taml system. Honestly, it's because I want to try some fancy IF statement combinations for the little editor I'm making for my game, and it appears that it would be easier to do it that way than through multiple separate taml files.
If it turns out I'm wrong, I'll post my findings here :P
#2
Then add it to a parent GuiControl. That can be a GuiWindow, a SceneWindow, or the Canvas itself
That's all there is to it!
Shameless plug
You can check outthe Particle Editor for an example as almost all the GuiControls are created programatically.
The base containers are loaded from taml and are given unique names. They are then populated by the scripts based on the values in the Particle Effect.
06/16/2014 (1:00 pm)
In script, simply create your new Gui Control as you would any other object%ImageButton = new GuiButtonCtrl()
{
Profile = "BlueButtonProfile";
Extent = "64 64";
HorizSizing = "right";
Position = "0 0";
};Then add it to a parent GuiControl. That can be a GuiWindow, a SceneWindow, or the Canvas itself
MySceneWindow.add(%ImageButton);
That's all there is to it!
Shameless plug
You can check outthe Particle Editor for an example as almost all the GuiControls are created programatically.
The base containers are loaded from taml and are given unique names. They are then populated by the scripts based on the values in the Particle Effect.
#3
Learn something new everyday ;D
06/16/2014 (3:14 pm)
Was unaware you could still do the legacy TGE GUI creation. Thought it had to be all TAML based in Torque2D (still hate TAML [sorry Mich!] :P)Learn something new everyday ;D
#4
Just out of curiosity, what parts of TAML do you hate?
06/16/2014 (3:54 pm)
@Jeff : Legacy Gui works as before but not all controls have been ported, some being only partially ported over. There are also a bunch of hard-coded paths and bitmaps which require C++ source code modification to use properly.Just out of curiosity, what parts of TAML do you hate?
#5
06/18/2014 (7:05 am)
Woo, got the first button to show up! Now to polish and then experiment :) 
#6
I don't really get the taml hate though - it's just like torquescript without the semi-colons and braces. It takes very little time to manually translate between the two (thought it is tedious).
06/18/2014 (6:34 pm)
Even better, Jeff - you can save the GUI object out to taml after creating it procedurally in script.I don't really get the taml hate though - it's just like torquescript without the semi-colons and braces. It takes very little time to manually translate between the two (thought it is tedious).
#7
06/18/2014 (9:12 pm)
If that's true, Richard, then what's the point to using taml files in the first place?
#8
A - Richard never lies.
B - taml files were initially intended (from what I know) for editors. An editor would let you create your asset, save it to .taml and then load it up later in your actual project.
In the context of script-generated GUI which see immediate use, saving them to .taml isn't really useful unless you later strip out the gui-generating scripts and just load the .taml.
06/18/2014 (9:30 pm)
@Mike :A - Richard never lies.
B - taml files were initially intended (from what I know) for editors. An editor would let you create your asset, save it to .taml and then load it up later in your actual project.
In the context of script-generated GUI which see immediate use, saving them to .taml isn't really useful unless you later strip out the gui-generating scripts and just load the .taml.
#9
1. In general, TAML will load faster than TorqueScript can execute
2. Sweet, sweet serialization
3. Easy to edit format(s) + XML schema support
4. Data driven and more artist/designer friendly than TS
5. Proper asset/module management
It wasn't just due to editor support. TAML was born out of many feature requests and it solved several in one swing.
06/18/2014 (9:38 pm)
Reasons:1. In general, TAML will load faster than TorqueScript can execute
2. Sweet, sweet serialization
3. Easy to edit format(s) + XML schema support
4. Data driven and more artist/designer friendly than TS
5. Proper asset/module management
It wasn't just due to editor support. TAML was born out of many feature requests and it solved several in one swing.
#10
This should all be put into a document somewhere....
06/20/2014 (6:33 pm)
TAML is not a replacement for torquescript - it's a replacement for serialization of engine objects like GUI controls and levels. These things used to be emitted as script that would then load and execute to recreate these objects - as Mich says, TAML loads differently - bypassing the normal script execution pipeline and speeding things up a little.This should all be put into a document somewhere....
#11
In all seriousness, there are still a few Torque veterans who don't get TAML or dislike it compared to legacy TorqueScript serialization...which was actually literally TorqueScript in a file. TAML isn't a format. It's a proper and functional serialization system that kicks ass against what was previously offered. It's even better than some of what the uber popular (commercial) engines offer. I still don't get the holdout.
06/20/2014 (6:59 pm)
Quote:This should all be put into a document somewhere....Someone should document?!? BLASPHEMY!
In all seriousness, there are still a few Torque veterans who don't get TAML or dislike it compared to legacy TorqueScript serialization...which was actually literally TorqueScript in a file. TAML isn't a format. It's a proper and functional serialization system that kicks ass against what was previously offered. It's even better than some of what the uber popular (commercial) engines offer. I still don't get the holdout.
#12
06/20/2014 (7:29 pm)
Only drawback I see to TAML is that you can't define several assets per definition file. And even that's easily circumvented with a little elbow grease.
#13
06/20/2014 (9:13 pm)
While it's true that is a limitation, since I've broken away from the old Torque ways I don't see that being an actual problem. Photoshop doesn't do that. Unity doesn't do that. Unreal doesn't do that. I just don't get the point of having a massive file of multiple asset definitions anymore. From both a tool and game perspective, a giant file collection (aside from a level) makes me cringe now.
#14
06/21/2014 (12:22 am)
So in my case, while I'm sure there's a different way to do it, I wanted to know how to use the functions to create my menus because the game I'm making has a dynamic set of menus, that unlock more and more buttons and options as you progress through the game. It appears that to accomplish this with the taml system I'd have to make a huge number of files to accommodate all of the buttons which may or may not be accessible depending on when you look at it.
#15
I'm just also defending TAML as being better for serialization than the older serialization method.
06/21/2014 (5:54 am)
And that makes sense Chase. There's different ways to solve the same problem, so pick what works best for your game and is in your comfort zone. Plenty of good reasons to dynamically create GUIs from code, like the Sandbox menus.I'm just also defending TAML as being better for serialization than the older serialization method.
#16
I can see the benefits of using TAML. I'm just too used to old torque ways and dislike change haha. I see your points for the TAML system.
Well that sounds fine by me that its in there.
I really need to just get used to TAML :P
06/21/2014 (9:47 am)
sorry if im jumping topic, but wanted to chime in since i said something and forgot about this thread! :PI can see the benefits of using TAML. I'm just too used to old torque ways and dislike change haha. I see your points for the TAML system.
Quote:Even better, Jeff - you can save the GUI object out to taml after creating it procedurally in script.
Well that sounds fine by me that its in there.
I really need to just get used to TAML :P
Torque Owner Eero Karvonen
%guiContent = new GuiWindowCtrl(GlobalWindowName) { canSaveDynamicFields = "0"; isContainer = "1"; Profile = "GuiWindowProfile"; HorizSizing = "right"; VertSizing = "bottom"; Position = "0 0"; Extent = "220 80"; MinExtent = "220 60"; canSave = "1"; Visible = "1"; tooltipprofile = "GuiDefaultProfile"; hovertime = "1000"; text = ""; maxLength = "1024"; resizeWidth = "0"; resizeHeight = "0"; canMove = "0"; canClose = "0"; canMinimize = "0"; canMaximize = "0"; minSize = "50 50"; new GuiButtonCtrl(GlobalButtonName) { canSaveDynamicFields = "0"; isContainer = "0"; Profile = "GuiButtonProfile"; HorizSizing = "right"; VertSizing = "bottom"; Position = "8 48"; Extent = "200 24"; MinExtent = "8 2"; canSave = "1"; Visible = "1"; hovertime = "1000"; text = "Button"; groupNum = "-1"; buttonType = "PushButton"; UseMouseEvents = "0"; }; };I'm currently building my editor GUI with the legacy TGB GUI editor which outputs this kind of Torquescript code. I've read that you can accomplish the task in the GUI editor included in T3D MIT as well (but atm, I have no idea if it exports TS or TAML).Regarding the GUI classes, T3D reference has been a closer friend to me than its T2D counterpart. Have a look to see what functionality is available (not everything is the same as in T2D, of course),
docs.garagegames.com/torque-3d/reference/annotated.html