Any method to #include in TorqueScript?
by Stefan Lundmark · in Torque Game Engine · 05/04/2006 (3:32 pm) · 20 replies
As the title says:
Is there any method in TorqueScript like #include in C++?
Sometimes scripts get very cluttered, especially Gui's.
Simplified example follows:
Would be much easier to read if it looked like this:
And having subControl.gui contain the same portion that was removed from the first codeblock in the example. There is push/pop Dialogs, but dialogs have certain bugs with clearing states and mouseOver that prevent them being used for certain things.
Is there any method that accomplishes this that I've overlooked? exec() does not work, and add() remove() messed up profiles etc.
Thankful for any insight you can give me.
Is there any method in TorqueScript like #include in C++?
Sometimes scripts get very cluttered, especially Gui's.
Simplified example follows:
new GuiBitmapCtrl(MainMenuGui)
{
position = "0 0";
extent = "640 480";
visible = "1";
bitmap = "~/sprites/background.png";
new GuiControl("SubControl")
{
position = "0 0";
extent = "640 480";
visible = "0";
}
}Would be much easier to read if it looked like this:
new GuiBitmapCtrl(MainMenuGui)
{
position = "0 0";
extent = "640 480";
visible = "1";
bitmap = "~/sprites/background.png";
include("subControl.gui");
}And having subControl.gui contain the same portion that was removed from the first codeblock in the example. There is push/pop Dialogs, but dialogs have certain bugs with clearing states and mouseOver that prevent them being used for certain things.
Is there any method that accomplishes this that I've overlooked? exec() does not work, and add() remove() messed up profiles etc.
Thankful for any insight you can give me.
About the author
#2
Thanks for the suggestion though.
Edit: I did just now find a way for it to read compiled code, using compileExec() instead of exec().
However, calling eval() within a Gui control defination, does not work even with the standard eval, so I guess I'm defeated.
05/04/2006 (4:37 pm)
That will not work with compiled scripts, however.Thanks for the suggestion though.
Edit: I did just now find a way for it to read compiled code, using compileExec() instead of exec().
However, calling eval() within a Gui control defination, does not work even with the standard eval, so I guess I'm defeated.
#3
subcontrol.gui :
main.gui :
05/04/2006 (6:15 pm)
Have you tried the following :subcontrol.gui :
GuiControl(SubControl)
{
position = "0 0";
extent = "640 480";
visible = "0";
}main.gui :
exec("subcontrol.gui");
new GuiBitmapCtrl(MainMenuGui)
{
position = "0 0";
extent = "640 480";
visible = "1";
bitmap = "~/sprites/background.png";
new GuiControl( : subcontrol );
} 
#4
Thus, you cannot put any other script code inside of an object instantiation.
This means that without either major changes to the compiler/interpreter or the addition of a script pre-processor, you cannot do what you want. The simplest solution would be a pre-processor, but it would still be a lot of work for very little gain. Best advice is just work with the system the way it is.
Also, Bruno's solution won't work. The : syntax just copies the fields from the "parent" control, it would not instantiate a copy of any child objects. Thus, you'd still have to have a new for every object in the "included" file and it would have to be of the same class. That would kind of defeat the purpose and be sheer hell to maintain.
T.
05/04/2006 (6:33 pm)
The only valid syntax inside an object instantiation is member definitions and other instantiations, but only for objects derived from SimGroup (I forget if the same applies for SimSet). GuiControl is derived from SimGroup.Thus, you cannot put any other script code inside of an object instantiation.
This means that without either major changes to the compiler/interpreter or the addition of a script pre-processor, you cannot do what you want. The simplest solution would be a pre-processor, but it would still be a lot of work for very little gain. Best advice is just work with the system the way it is.
Also, Bruno's solution won't work. The : syntax just copies the fields from the "parent" control, it would not instantiate a copy of any child objects. Thus, you'd still have to have a new for every object in the "included" file and it would have to be of the same class. That would kind of defeat the purpose and be sheer hell to maintain.
T.
#5
05/05/2006 (1:26 am)
I came to the same conclusion, thanks Tom and everyone for your help. 
#6
05/05/2006 (2:46 am)
@Stefan - Would there be something i could add to Torsion to possible make GUI scripts (or scripts in general) feel less cluttered? I already have code folding and i'm considering adding adding those two combo boxes (like in VC++) which allow you to quickly navigate to objects/functions in a script.
#7
But (doh) I had two quirks that lead me back to Tribal IDE again, which was:
1. Syntax options, for example making "Reserved Words" bold, which was something I wanted to replicate how Tribal IDE's syntax look, but you could only select colour. A minor quirk, but it wasn't easy on my eyes with the blue, and I wanted the black to set apart from the normal text which was also black. (My vision is lacking)
2. I didn't need the debug window or whatever that was which was at the bottom, so I resized it so it wasn't visible. Very nice, but it didn't save so next time I started Torsion it was there again.
I'm probably going to revisit Torsion again today (I love how you can collapse code!) and try to get used to the syntax though, was late yesterday. I really love all the other parts of the editor! But more options would be my wish.
05/05/2006 (5:56 am)
What a coincidence Tom, I actually downloaded Torsion yesterday as I remembered it had "function collapsing", and it sure helped alot! Looked *much* cleaner.But (doh) I had two quirks that lead me back to Tribal IDE again, which was:
1. Syntax options, for example making "Reserved Words" bold, which was something I wanted to replicate how Tribal IDE's syntax look, but you could only select colour. A minor quirk, but it wasn't easy on my eyes with the blue, and I wanted the black to set apart from the normal text which was also black. (My vision is lacking)
2. I didn't need the debug window or whatever that was which was at the bottom, so I resized it so it wasn't visible. Very nice, but it didn't save so next time I started Torsion it was there again.
I'm probably going to revisit Torsion again today (I love how you can collapse code!) and try to get used to the syntax though, was late yesterday. I really love all the other parts of the editor! But more options would be my wish.
#8
Also both panes, left and bottom, can be disabled via the 'View' menu. Still i should start to store your pane size settings. =)
Thanks for the feedback Stefan!
05/05/2006 (9:48 am)
Well i can look at adding an option to bold some of the syntax. I was avoiding it because a) i would need a much more complex interface for settings and b) bold tends to make things non monospaced. Still i'll take another look at the issue for you.Also both panes, left and bottom, can be disabled via the 'View' menu. Still i should start to store your pane size settings. =)
Thanks for the feedback Stefan!
#9
I'll keep a close eye and thanks for looking at my input.
If window saving and bold editing is in the final version of Torsion, you got my dollars (you probably do anyway :p).
Laters
05/05/2006 (1:22 pm)
Oh, yes I noticed the bolding made text larger/smaller in Tribal.. maybe make it disabled by default and let the user decide if it's worth it? I have bad vision and it makes it much easier for me to see function declarations, new's, etc - when scrolling or otherwise not focusing on a specific code-part. I'll keep a close eye and thanks for looking at my input.
If window saving and bold editing is in the final version of Torsion, you got my dollars (you probably do anyway :p).
Laters
#11
05/05/2006 (4:08 pm)
Thanks a ton Tom! 
#12
it's not totally elegant, but works for me.
playGui.gui
this is pretty primitive,
and has a few drawbacks:
* problem 1: you can no longer save PlayGui.gui from torque's gui editor, or else you'll get myPanel included in it, and next time you load you'll have two myPanels and next time three, etc.
* proposed solution: add a field to all guiControls along the lines of "doNotIncludeInParentSave", a boolean which is false by default. it's use is pretty obvious, i think. - this would require some slight engine coding.
* problem 2: playGui needs to know about the existence of what is essentially a child file.
* proposed solution: reverse this dependency so that the child file needs to know about its parent. do this by putting the playGui.add() call inside myPanelGui.gui. This introduces a sub-problem which is the requirement that myPanelGui.gui must be exec'd after playGui.gui. And yet another proposed solution: wrap the playGui.add() call inside a schedule(0).
.. and that's most of the problems i see.
we'll probably take a while before implementing & testing the proposals, but i'm posting now in case anyone wants to give them a shot. the basic stuff i posted first is working fine for us tho.
ps,
the motivation here is that our PlayGui.gui has become a very dynamically-constructed object, and basically gets all screwed up if you save it out again from the torque gui editor. However, at the same time, our playGui also contains a very non-dynamic control with lots and lots of buttons, and it's really, really convenient to edit that part in the gui editor. So with this method we seperated out the static-but-detailed part from the main dynamic part.
07/18/2006 (1:08 pm)
I found a way to do what the OP was looking for.it's not totally elegant, but works for me.
playGui.gui
new GameTSCtrl(PlayGui) {
// yadda yadda
}
//--- OBJECT WRITE END ---
[b]
exec("./myPanelGui.gui");
PlayGui.add(myPanel);
[/b]this is pretty primitive,
and has a few drawbacks:
* problem 1: you can no longer save PlayGui.gui from torque's gui editor, or else you'll get myPanel included in it, and next time you load you'll have two myPanels and next time three, etc.
* proposed solution: add a field to all guiControls along the lines of "doNotIncludeInParentSave", a boolean which is false by default. it's use is pretty obvious, i think. - this would require some slight engine coding.
* problem 2: playGui needs to know about the existence of what is essentially a child file.
* proposed solution: reverse this dependency so that the child file needs to know about its parent. do this by putting the playGui.add() call inside myPanelGui.gui. This introduces a sub-problem which is the requirement that myPanelGui.gui must be exec'd after playGui.gui. And yet another proposed solution: wrap the playGui.add() call inside a schedule(0).
.. and that's most of the problems i see.
we'll probably take a while before implementing & testing the proposals, but i'm posting now in case anyone wants to give them a shot. the basic stuff i posted first is working fine for us tho.
ps,
the motivation here is that our PlayGui.gui has become a very dynamically-constructed object, and basically gets all screwed up if you save it out again from the torque gui editor. However, at the same time, our playGui also contains a very non-dynamic control with lots and lots of buttons, and it's really, really convenient to edit that part in the gui editor. So with this method we seperated out the static-but-detailed part from the main dynamic part.
#13
- versus "save gui".
07/18/2006 (1:46 pm)
Arg - realized that another part of the basic method which needs to be created is a "save control" menu item.- versus "save gui".
#14
07/19/2006 (4:04 am)
I do not use the GUI editor myself so this is a welcome addition. Thank you. 
#15
07/27/2006 (10:32 am)
Is there a reverse of PlayGui.add? if so then we could enter that in the console before editing the gui, then it would be available by itself yes?
#16
so simGroup::remove() should work as far as reversing it..
i'm not sure how the gui editor would then find it tho.
07/27/2006 (10:39 am)
PlayGui.add() is just a use of SimGroup::add(),so simGroup::remove() should work as far as reversing it..
i'm not sure how the gui editor would then find it tho.
#17
07/27/2006 (11:19 am)
Maybe RootGroup.add() or wherever guis normally add themselves when they have no other gui as a parent?
#18
gimme an hour or so.
07/27/2006 (11:23 am)
I'm currently implementing "File | Save Current Control"..gimme an hour or so.
#20
I too like to have certain syntax bolded. The "Bitstream Vera Mono" is one of a very few that does not expand when bolded. That and the excellent clarity at 8 pt makes it my current favorite. You can download the Bitstream Vera family here: www.gnome.org/fonts/
Hope that helps!
@Orion: Nice job with the resource.... definitely going to integrate.
08/01/2006 (3:07 pm)
Re: Using bold fonts...I too like to have certain syntax bolded. The "Bitstream Vera Mono" is one of a very few that does not expand when bolded. That and the excellent clarity at 8 pt makes it my current favorite. You can download the Bitstream Vera family here: www.gnome.org/fonts/
Hope that helps!
@Orion: Nice job with the resource.... definitely going to integrate.
Associate Orion Elenzil
Real Life Plus
i dunno if eval can handle multiple lines tho.