Game Development Community

RESOLVED: Build Exports stops responding

by Michael Bacon · in Torsion · 10/03/2007 (6:51 am) · 13 replies

Recently the Build Exports phase of my project has caused Torsion to stop responding.

It creates a 480kb console.log with the export information but then it just sits there eating 100% CPU.

I tried removing the excess configurations and I tried creating a new project in the same base folder but the result was the same.

Finally I tried it with a copy of the Torque_demo.exe and the starter.fps and it worked as if nothing had happened.

Somehow I broke Torsion's Build Export step with my engine changes. I rewrote the AIPlayer class and added little bits and pieces all over. I have no idea how to track it down.

The only thing I can think of is that the export list in the console log is unreadable somehow and Torsion gets stuck chewing on it. I looked over the log itself but didn't see anything extraordinary.

For now I'm turning off the exports..

#1
10/03/2007 (7:20 am)
The two functions in the engine that are used while building exports are dumpConsoleFunctions() and dumpConsoleClasses(), might wanna check inside them and see if they are causing a problem.

The script that gets run for building exports is in C:\Program Files\Torsion\torsion_exports.cs
#2
10/04/2007 (5:10 am)
I didn't change any of that.

The only thing I can think is that maybe one of my function descriptions somewhere is unparsable but I really think that it is a bug with Torsion. The engine seems to run and complete just fine. Its the part after that step that hangs.
#3
10/09/2007 (3:27 am)
Anybody?

Is there any way I can debug the 'Build Exports' process to even see where its hanging?
#4
10/09/2007 (6:49 am)
Hey Brian, what version of Torque and Torsion are you using.

I notice that the torsion_exports.cs I have has a line commented out saying it crashes 1.4

// Dump all the functions, classes, and globals to the log.
dumpConsoleFunctions();
echo( "" );
dumpConsoleClasses();
//echo( "" );
//export( "*" ); // This crashes 1.4... why?
//echo( "" );
//RootGroup.save( "./rootgroup.log" );

put that block from the file in your main.cs and try debugging that block, if that block works, then its a Torsion parsing problem most likely
#5
10/09/2007 (7:49 am)
I own TGE v1.5.2 and Torsion. I am running Torsion v1.1.130.

That line is already commented out in my version.

My problem doesn't seem to be with the Torque Engine. It seems to be with Torsion.

The console log is created just fine by the engine. Then Torsion (torsion.exe in the process list NOT my engine executable) starts consuming 100% CPU. I then need to terminate Torsion manually (which is very hard because it is eating all the cycles!).

I can look at the console log and it looks okay to me but something is obviously wrong.

I'm going to run a test. I think a specific resource might have broken it... I'm going to reimplement that resource in a fresh engine and see if the problem reoccurs...
#6
10/09/2007 (8:42 am)
I'm going to double post here as I feel it is an appropriate context.....



So I just tried out my idea and I was right. A specific resource (the Namespace Mod) kills Torsion. I need this mod for my project. I only implemented it because it fixed a problem that occurred during development and telling my guys that it ain't going to work now that it has been working isn't gonna fly.

So what exactly does Torsion rely on that the Namespace Mod breaks??

I'm looking into it....
#7
10/09/2007 (9:30 am)
Yeah, I'm not sure if Torsion does anything else with the engine once it has that function/class list popped out, if any script commands are sent or not.

Torque namespacing is confounding as it is, and some of the Torsion code may be using a specific behavior that the namespace mode changes
#8
10/09/2007 (12:35 pm)
@Brian - It's very possible that the namespace mod kills the export building process. Your best bet to figure out the problem is to check the output.log after build exports runs. Torsion expects the dump format to be a particular way... if it has changed then thats the problem. If you can give me a concrete example of what that change is, i may be able to correct it for the next release.
#9
10/10/2007 (7:21 am)
@Tom - Does the build process make any assumptions on the class or className members? These are primarily what is affected. Actually all SimObjects are given both of them as well as superClass and superClassName properties. The duality seems to be for making it compatible with existing code (some objects used class and some used className). These members are also put in a group named NameSpace.

This is all I have right now but I'm working on it.
#10
10/13/2007 (7:46 pm)
@Brain - I don't remember really... it worked before, so something was changed with that mod. If you can nail down what it is i'll be glad to try to fix it.
#11
10/23/2007 (9:05 am)
I found it!

The new namespace setup was setting the global namespace name to "" instead of NULL.

This was causing the global namespace to be exported with the classes.

I found the easiest fix (and one that keeps backwards compatibility) was to modify consoleDoc.cc around line 283:
// Skip the global namespace, that gets dealt with in dumpFunctions
      if(!className) continue;
[b]      if(!className[0]) continue;[/b]
#12
10/23/2007 (9:10 am)
@Brain - Oh... so this was originally a change in the namespace resource? Please post it back to the resource thread as well for anyone else that may encounter it.
#13
10/23/2007 (9:25 am)
I have already done so. Sorry for wasting your time ;)


I just want add that since resolving this issue I am happier than ever with Torsion!

It is a wonderful piece of work.