In prison, the only way to get a new file is if someone sends it baked in a cake.
I need a similar stroke of ingenuity to get a New File to my maxscript, which is suffering in an entirely different sort of lockup.

The problem is this:
I am trying to do a batch animation export script for a game pipeline.
Each export is broken into two phases:
1) the animation is opened, cleaned, and exported to FBX (this flattens all of the controllers, etc)
1.5) File New
2) the FBX is imported, cleaned some more, and exported to game format

This works flawlessly when I test the script in max. BUT, for batch operations, I’m running max in render mode (3dsMaxcmd.exe). This makes the export faster, more efficient, and (one would think) more stable and robust. But when the script is run in render mode, I have problems with step 1.5 (File New).

I’ve tried doing it a couple of different ways.
1) resetMaxFile #noprompt
This works in normal mode. In render mode it _almost always_ works, but on some rare occasions it fails and causes max to hang indefinitely without ever actually terminating, which is VERY VERY BAD for a batch operation.
2) max file new
This presents an annoying dialog box, which would make it useless for batch operations, but luckily the dialog is suppressed in batch mode.
Dialog notwithstanding, this command works flawlessly in standard mode. But in render mode it sometimes leaves crap in the scene, fouling step 2. When I attempt to delete the remaining objects, I get an Unknown System Exception.

This leaves me with 2 remaining options, neither appealing:
use a full GUI copy of max for each export (YUCK)
or
launch a separate render for each stage of the export (also yuck)

That is, of course, unless anyone here can send me a cake.

I’ve got some other ideas, but i’ll throw this (hopefully) cake-like one out:

Could you create a “blank” file for importing into. (C:\myAnimExport_template.max)
So instead of “new file” you’d open a blank “template file”.

Perhaps the open command will work better than reset or new.

thedour.net
Render 3D @ ScriptSpot.com

Good thinking! But, actually, I forgot to mention, that was the first thing I tried (before I knew about resetMaxFile). Unfortunately I had some stability problems with that as well.

For the time being, I’ve gone back to resetMaxFile, which at least produces clean output.
At the start of each export operation, I’m having max pass its window-handle to an autoIt script, which kills the process if it doesn’t finish within a reasonable time limit. This should guard my batch against hangups, although it still remains an unsolved mystery why the command is failing in a few cases.

Thing is, 3dsmaxcmd is designed for rendering only. Many of the command line switches recognised by 3dsmax.exe are not recognised by 3dsmaxcmd (and, it has to be said, vice-versa).

Slower it may be, but you’d be better off using the full one - use “-q -mi -silent” to stop most, if not all, of the displays. Better something which works reliably, if slowly, than something which is quicker, but randomly fails (IMO anyway).

Max 4.2 through 2012 (SP2+SAP).
XP-64 (SP2)
NVidia 9800GTX-512 (Driver 266.58).
Core 2 Quad Q6600 2.4GHz, 8Gb Ram, DX9.0c.

Sounds good.

With either method, maybe you can look to do some garbage collection in key places, and maybe reset any locals/globals, and “use with undo off” etc.

My initial thinking was that method #2 should work, and that Unknown System Exception on delete might be easier to overcome than the other problems. 
How are you going about deleting everything?
• delete $objects
• unhide all, unfreeze all, select all, delete
• Another way?

Steve has a great point on reliability though. You could go with full and use things to speed it up like disable scene redraw, undo off, don’t have the modify panel open, etc.

thedour.net
Render 3D @ ScriptSpot.com

Hum. Good flags… I hadn’t seen those before; it appears they’re in a separate section of the help.
It appears there’s also a -mip flag, that sets Max permanently minimized. I wonder if that results in performance gains over -mi (maybe by avoiding initializing things) or if it’s just a convenience flag…

Performance does matter to me; with hundreds of files to process, 16 hour batches are not uncommon. An extra few seconds per animation adds up… and in GUI mode, I know that some operations take 10x as long if (for example) the Scene Explorer is left open. Render mode ensures those sorts of problems are avoided—and it appears to have all of the functionality I need; if it didn’t, my process wouldn’t be working 99% of the time. But… if -mi or -mip mode can give me approximately the same performance in a closer-to-nominal script environment, then it’s worth changing.

I’m call it wraps for today, but next time I pop the hood I’ll experiment with this suggestion.
Thanks!