My suggestion would be to try switching the SMTDFunctions.CreateJobInfoFile() function’s code from
--Store Current Scene Selection
local theSelectionArray = for o in selection collect o.inode.handle
with PrintAllElements on format "SceneSelection=%\n" theSelectionArray to:JobInfoFile
to
--Store Current Scene Selection
local theSelectionArray = for o in selection collect o.inode.handle
with PrintAllElements on format "SceneSelection=%\n" (theSelectionArray as bitarray) to:JobInfoFile
In cases of lots of consecutive indices, the bitArray signature will express the ranges as M…N instead of listing all coma-separated indices, thus making the string A LOT shorter. Instead of containing 12753 integers, it would look like
#{275228..277926, 277928..278928, 278931..280933, 280935..282936, 282938..285238, 285240..287986}
Then the customize.ms code would loop over the bitarray (I don’t think we even have to convert to an array in memory), so it will use significantly less memory (one bit per object, instead of 4 bytes).
I have not tested this yet, but I am pretty sure you (Laszlo) could add the “as bitarray” to the existing code and see if it helps with newly submitted jobs… If it does, we can make the change on our side, too.
I don’t think we can do anything on the reading side for already submitted jobs, assuming the issue is in the MAXScript parser.
That being said, reading that file into MAXScript does not seem to cause any problems on my 10+ years old workstation. However, loading the text you sent in the MAXScript Editor surely messes it up (it hangs a lot). Opening in a stand-alone SciTE does not cause any problems.
