TGEA 1.7 - How to setup folders for release
by Trent · in Torque Game Engine Advanced · 04/05/2008 (3:47 pm) · 8 replies
Ok well I'm not at the stage of releasing a real game or anything, I just need to show a remote friend a build with the new art work we're making, but of course, the stronghold folder is full of .cs and .max files and other files irrelevant to a final user, so I need to package up a runtime version to send to him.
Is there an automated way to compile the .cs into .dso and say, extract only the necessary files to another runtime folder?
Is there an automated way to compile the .cs into .dso and say, extract only the necessary files to another runtime folder?
About the author
#4
Answer:
04/11/2008 (11:59 pm)
What's your problem? David answered your question :)Quote:Is there an automated way to compile the .cs into .dso and say, extract only the necessary files to another runtime folder?
Answer:
Quote:There's nothing automated to do it.
#5
04/12/2008 (11:57 pm)
I am simply asking if there might be a guide somewhere to what I should and shouldn't remove from the folder structure, such as /editor and /common and all of the max files, and how to get my .cs files to compile into .dso 
#6
To release, you will want to remove the following folders:
Tools
Editor
Profile
To get TGEA to compile the cs files to dso will require changing something in the engine. You'll want to search thru the docs folder to find out how to do that.
04/13/2008 (7:23 am)
David must have been having a bad day to give a sarcastic answer like that.To release, you will want to remove the following folders:
Tools
Editor
Profile
To get TGEA to compile the cs files to dso will require changing something in the engine. You'll want to search thru the docs folder to find out how to do that.
#7
The only way that one could automate removal reliably would be to understand what belongs to your project's organization and what does not. And that is a developer-specific operation.
For example, we could include a shell/cmd script that would remove .max assets, perhaps use perl or php to scan the .map/.csx files to get texture names and remove all the rest of the textures that are not included in any .gui, .cs, or .ms files; ignore .ml files so that we don't remove any mission lighting resources...but that would only work on an untouched copy of a specific starter kit.
I would be loathe to automate a file that removes functionality from scripts and assets from the mod directory of projects that we did not create in an automated fashion simply because of the liability of a team perhaps losing their original assets that they were loading and exporting into the shapes directory while testing. Run the script, boom. Original assets gone. We can hope for best practices, but was can in no way account that all developers will use our best practices, or (and this is important) that our best practices are their best practices.
It would be much more intuitive to a team to package their game for release, removing files that they know are not part of the final game (say, .max or .map files) than it is to try to support an automated removal package that could completely destroy months of work on accident. One cannot assume that all teams work in a prescribed manner with source and asset control with a strong backup system in place to ensure integrity of their data.
As another example, if you're looking at mod-ability for your game, you might want to keep the editor in there (or at least a modified version of the editor to allow for mod placement and mission development of new levels for the game.
Now, I could have said all that in the first post, but my answer was simply "There's nothing automated to do it" because, and this is important, there is nothing automated to do it. It is project-dependent and best left to the team/developer's way of working and organization. Hence the post answering that portion of the query.
@Trent
I'm not sure where the DSO generation code has moved in 1.7. It was in the torqueConfig.h file in previous versions, but doesn't seem to be there in this one.
04/14/2008 (9:16 am)
The question was on an automated removal formula (and DSO generation on TGEA 1.7).The only way that one could automate removal reliably would be to understand what belongs to your project's organization and what does not. And that is a developer-specific operation.
For example, we could include a shell/cmd script that would remove .max assets, perhaps use perl or php to scan the .map/.csx files to get texture names and remove all the rest of the textures that are not included in any .gui, .cs, or .ms files; ignore .ml files so that we don't remove any mission lighting resources...but that would only work on an untouched copy of a specific starter kit.
I would be loathe to automate a file that removes functionality from scripts and assets from the mod directory of projects that we did not create in an automated fashion simply because of the liability of a team perhaps losing their original assets that they were loading and exporting into the shapes directory while testing. Run the script, boom. Original assets gone. We can hope for best practices, but was can in no way account that all developers will use our best practices, or (and this is important) that our best practices are their best practices.
It would be much more intuitive to a team to package their game for release, removing files that they know are not part of the final game (say, .max or .map files) than it is to try to support an automated removal package that could completely destroy months of work on accident. One cannot assume that all teams work in a prescribed manner with source and asset control with a strong backup system in place to ensure integrity of their data.
As another example, if you're looking at mod-ability for your game, you might want to keep the editor in there (or at least a modified version of the editor to allow for mod placement and mission development of new levels for the game.
Now, I could have said all that in the first post, but my answer was simply "There's nothing automated to do it" because, and this is important, there is nothing automated to do it. It is project-dependent and best left to the team/developer's way of working and organization. Hence the post answering that portion of the query.
@Trent
I'm not sure where the DSO generation code has moved in 1.7. It was in the torqueConfig.h file in previous versions, but doesn't seem to be there in this one.
#8
I'd like to clarify that I first asked for an automated way to _extract_ the necessary files to another folder, leaving the source project untouched. My third post I regretfully slipped into the "remove" terminology, where my intent was never to delete anything (bad, bad!!), but simply to have an "output" folder where only redistributable items would be copied. If I knew at the time what was needed for a game to be distributed I probably wouldn't have been asking about an automated tool with a very vague feature list :)
Having said that, David answered my question quite simply and satisfactorily. Having got my answer I then asked about manual instructions for the same process which Mike ended up giving me.
Some other clown complained about GG support, not me.
04/15/2008 (2:53 pm)
Thanks guys.I'd like to clarify that I first asked for an automated way to _extract_ the necessary files to another folder, leaving the source project untouched. My third post I regretfully slipped into the "remove" terminology, where my intent was never to delete anything (bad, bad!!), but simply to have an "output" folder where only redistributable items would be copied. If I knew at the time what was needed for a game to be distributed I probably wouldn't have been asking about an automated tool with a very vague feature list :)
Having said that, David answered my question quite simply and satisfactorily. Having got my answer I then asked about manual instructions for the same process which Mike ended up giving me.
Some other clown complained about GG support, not me.
Associate David Montgomery-Blake
David MontgomeryBlake