Torque command line arguments

#1 One way you could accomplish this is to modify starter.fps/main.cs and put your commands in
onStart()

somehting like

function onStart()
{
   Parent::onStart();
   echo("\n--------- Initializing MOD: FPS ---------");

   // Load the scripts that start it all...
   exec("./client/init.cs");
   exec("./server/init.cs");
   exec("./data/init.cs");

   // Server gets loaded for all sessions, since clients
   // can host in-game servers.
   //initServer();

   writeOutFunctions();
   writeOutClasses();

   quit();

   // Start up in either client, or dedicated server mode
   if ($Server::Dedicated)
   {
      initDedicated();
   }
   else
   {
      initClient();
   }
}

Keep in mind, this is untested and is a hack job. In theory it _should_ work

-Ron

#2 Thanks Ron,

I thought about that.

See the thing is, I'm writing an editor and I want to grab all the functions and methods when the user first starts a project.

The way it is set up now, when you first create a project group you point the program to the executable and from there I want it to start Torque, pull the information and exit. Then it will scan all of the script files for any script based objects or methods and add them accordingly.

I also want to keep it as automated as possible.

Maybe what I can do as a work around is enter the lines into the script through code, run Torque then remove the lines.

#3 I would suggest you check out how things like CTAGS works--basically, it is a set of regular expressions that can search through files automatically and determine what lines meet the requirements for being a "script definition", a "script call", etc.

It's amazingly tricky to get regular expressions working properly for things like this, but as far as I can tell it's exactly what you are looking for--the ability for an editor to be aware of script function definitions within a Torque environment.

IMO, actually running TGE simply to dump out the function list is a really big kludge if what I described above is what you are trying to accomplish.

#4 Well Stephen,

The main decision factor here is that not everyone will have access to source code. There's alot of people out there learning torque through the demo before they make an investment.

I've been able to pull out the classes, functions and methods out of the source code for a couple of days now. But again that was source code.

That and the fact that it is independent of the engine itself, has made me decide to take this road.

I know it may seem to be a 'big kludge' but it will only happen one time. unless the engine is recomplied and the user wants to re-grab the defs

#5 That's a good point--for some reason I was thinking you wanted to grab all the functions that were defined in your script files, not all the ConsoleFunctions that actually implement the underlying functionality.

#6 The problem I have come across though is that if you do the writeOutClasses and writeOutfunctions with the debug it works fine. If I try to do it with a release version it doesn't show the args and it doesn't write them to the files, even though it creates them.

What's going to end up happening is that I'm going to make a stock set for the compiled versions and allow it to build its own for the debug versions.

That way if someone is using the demo it will already have a set. And since the demo doesn't include the source, there's less of a chance that it will be missing anything anyway.

#7 There's a few key defines which control this behavior; if you feel like changing it it's pretty straightforward.