Using console in builds
by Ricardo Vladimiro · in Torque Game Builder · 04/02/2007 (1:34 am) · 9 replies
Hi everyone
Sorry I'm starting a new thread, but I can't seem to find the one I was going to answer in.
I have a problem. On a built game, the console is running. In the thread I mentioned, it is said that using enableWinConsole (false) would disable it. Well, I've put down enableWinConsole (false) in game.cs and the console is still there.
How can I change this behaviour?
Sorry I'm starting a new thread, but I can't seem to find the one I was going to answer in.
I have a problem. On a built game, the console is running. In the thread I mentioned, it is said that using enableWinConsole (false) would disable it. Well, I've put down enableWinConsole (false) in game.cs and the console is still there.
How can I change this behaviour?
#2
04/03/2007 (12:23 am)
Thank you Don. It's a workaround but for now it will do.
#3
Make sure to make a backup of your project, then go to the common/gui folder and delete the console.gui and console.gui.dso
I haven't tested this, but it may be a more permanent solution.
04/04/2007 (7:12 am)
Why don't you try this Ricardo:Make sure to make a backup of your project, then go to the common/gui folder and delete the console.gui and console.gui.dso
I haven't tested this, but it may be a more permanent solution.
#4
04/04/2007 (9:54 am)
I can try this directly on the build. I'll check it and return here.
#5
Thanks for the help.
04/05/2007 (5:19 am)
Renaming or deleting the console.gui.dso from the common/gui folder does the trick. It leaves an error in console.log, but I can handle that later.Thanks for the help.
#6
this is not a hack, and is the intended way to do things ...
TGB makes building games quite easy, the packaging part is where lots of tedious work comes into play ... :)
04/05/2007 (7:50 am)
The proper thing to do is both update the common.cs like Don suggested, then remove the console gui files from the common/gui folder ... this eliminates both the key-binding, and the existance of the console ... so that the keybinding doesn't show errors in the console log as well ... also, you want to comment out the line in common.cs that execs the console gui files ...this is not a hack, and is the intended way to do things ...
TGB makes building games quite easy, the packaging part is where lots of tedious work comes into play ... :)
#7
This makes any build-related work easier. Not bullet proof since as the engine evolves, some has to be redone, but it's a more elegant approach I think.
04/05/2007 (8:40 am)
Yeah David. I'm starting to write down the steps needed in the builds. Another thing I've been doing is to include some bits of script like this:if ($runWithEditors).......
This makes any build-related work easier. Not bullet proof since as the engine evolves, some has to be redone, but it's a more elegant approach I think.
#8
I'm not even sure, but I think you could build a completely separate 'build' install ... that has lots of stuff stripped out ... develop with your 'dev' install ... and reference the same project in both ... since the projects can be stored outside of the editors path now ... so with 1.5 ... the build process might get a lot cleaner and simpler to do ...
to try to clarify a bit more ...
Install TGB Twice, install it once as a "Developer Copy" and the second install, codename it "Build Copy" or whatever ... in the "Build Copy" edit all the Common/ scripts, and any other scripts that are 'auto-included' in Build Packages ... and remove anything that you commonly don't want in a 'production release' or even a 'beta' release ... such as the Console Dialog, and all the other dialogs ... if you don't use them, strip them out ... add them back into the game project itself if a specific game project uses it ... ie; copy the MessageBox dialog from the Common folder in your "Developer Copy" to your "Game Project" folder and exec it as if it were part of your game project and not the "common" folder ... this way, your "Build Copy" has a "clean" common folder, only including what you absolutely need ... or commonly use in your projects ...
Then ... create a new project from the "Developer Copy" store it in a general location, "My Documents/MyGames" for example ... setup Torsion or whatever to point to this location, and use your "Developer Copy" information for the debug stuff ...
Now, when your ready to make a quick test build ... to ship a beta to a client, or a few friends ... close the "Developer Copy" and launch the "Build Copy" ... then run the Package Utility ...
All the common scripts, etc, etc ... are relative to the Install of TGB ... not the Game Project ... so your "Build Copy" should generate a nice clean "build" for you ...
Simplifying things quite a bit more then the old method ... although, this logic still applies to the 1.1.3 build ... you would just have to copy your Game Project folder into the "Build Copy" games directory ... deleting it first, if it's been built previously...
This should allow you to create a fairly simple "method" ... and reduce the amount of tedious work you have to perform with each of your game projects ... allowing you to simply add to projects the items you need ...
Also, note ... that wrapping exec() statements in the common folder around logical statements (IF) ... will still include the information in your build (making your build larger) .. but would prevent the items from loading into memory and being accessible ... it's best to just not have them ship with your product at all ... and why go through the trouble of removing them after a build ...
In your Game Project, if you use the "common/gui/MessageBox.gui" for example ... just exec("common/gui/MessageBox.gui") from inside one of your game project scripts ... and it will be added to your build ... since it's referenced from one of the scripts that is parsed during the build process ... no need to copy the MessageBox.gui to your gameProject/gui folder ... (though, you could do this too, if you wanted too)
04/05/2007 (12:47 pm)
Ricardo, I'm pretty sure the 'withEditors' option is deprecated with the 1.5 Beta ... as the 'player' and the 'editor' are now separated ... I'm not even sure, but I think you could build a completely separate 'build' install ... that has lots of stuff stripped out ... develop with your 'dev' install ... and reference the same project in both ... since the projects can be stored outside of the editors path now ... so with 1.5 ... the build process might get a lot cleaner and simpler to do ...
to try to clarify a bit more ...
Install TGB Twice, install it once as a "Developer Copy" and the second install, codename it "Build Copy" or whatever ... in the "Build Copy" edit all the Common/ scripts, and any other scripts that are 'auto-included' in Build Packages ... and remove anything that you commonly don't want in a 'production release' or even a 'beta' release ... such as the Console Dialog, and all the other dialogs ... if you don't use them, strip them out ... add them back into the game project itself if a specific game project uses it ... ie; copy the MessageBox dialog from the Common folder in your "Developer Copy" to your "Game Project" folder and exec it as if it were part of your game project and not the "common" folder ... this way, your "Build Copy" has a "clean" common folder, only including what you absolutely need ... or commonly use in your projects ...
Then ... create a new project from the "Developer Copy" store it in a general location, "My Documents/MyGames" for example ... setup Torsion or whatever to point to this location, and use your "Developer Copy" information for the debug stuff ...
Now, when your ready to make a quick test build ... to ship a beta to a client, or a few friends ... close the "Developer Copy" and launch the "Build Copy" ... then run the Package Utility ...
All the common scripts, etc, etc ... are relative to the Install of TGB ... not the Game Project ... so your "Build Copy" should generate a nice clean "build" for you ...
Simplifying things quite a bit more then the old method ... although, this logic still applies to the 1.1.3 build ... you would just have to copy your Game Project folder into the "Build Copy" games directory ... deleting it first, if it's been built previously...
This should allow you to create a fairly simple "method" ... and reduce the amount of tedious work you have to perform with each of your game projects ... allowing you to simply add to projects the items you need ...
Also, note ... that wrapping exec() statements in the common folder around logical statements (IF) ... will still include the information in your build (making your build larger) .. but would prevent the items from loading into memory and being accessible ... it's best to just not have them ship with your product at all ... and why go through the trouble of removing them after a build ...
In your Game Project, if you use the "common/gui/MessageBox.gui" for example ... just exec("common/gui/MessageBox.gui") from inside one of your game project scripts ... and it will be added to your build ... since it's referenced from one of the scripts that is parsed during the build process ... no need to copy the MessageBox.gui to your gameProject/gui folder ... (though, you could do this too, if you wanted too)
#9
When I read the editor separation of 1.5 beta I imagined I could do a lot of things separatelly, but we are in production so trying 1.5 beta now is out of the question. I'll have to try it out probably around June or July, hopefully it will be RC or even gold already.
04/05/2007 (3:54 pm)
I considered doing something like that with the current version, but I'm so overwelmed with design, business, scritp, production (small team mate, you know the drill) that I simply discarded it and started putting the if statements where I found necessary.When I read the editor separation of 1.5 beta I imagined I could do a lot of things separatelly, but we are in production so trying 1.5 beta now is out of the question. I'll have to try it out probably around June or July, hopefully it will be RC or even gold already.
Torque Owner Don Schaper
XIX Software
common/gamescripts/common.cs
function initializeCommon()
edit (or comment out) GlobalActionMap keybinding for "tilde"