MAXScript execution order

Deadline
1

After starting using the integrated SMTD script (by the way, very nicely done!) in 3ds Max, I’d like to ask whether it’d be possible for you to consider a different PostLoad maxscript execution order.

The thing is, I’m using PostLoad scripts to alter render paths (among other things), which in return then get altered once again.

It’s not a big deal, though, but, when I submit a scene file for caching purposes (mainly global illumination caching) I really don’t need the rendered output, so I disable it in the PostLoad script and have the scenes cached.

The thing is, this way Deadline alters my pipeline behavior a little and re-enables the beauty output no matter what my PostLoad script says, so it saves out the rendere file anyways - which is an unnecessary hit on the network and mainly, it alters the render file name slightly so that the extension is in all capital letters, which isn’t what I put in in the first place and might cause issues with Python scripts (haven’t happened to me, yet, just assuming).

So, my suggestion would be:

  1. either alter the script execution order, so that the PostLoad scripts get executed after Deadline does its job of altering the paths
  2. or, if that wouldn’t be ideal (for whatever other reasons), at least, please, keep the names completely intact, no case changes, no character additions/subtractions etc…

Thank you, cheers,

2

The settings that tell Deadline render output is enabled is pulled from the plugin info file that gets submitted with the job. Specifically, these 2 settings:

RenderOutput=…
SaveFile=true/false

These are exposed so that they can be changed from the 3dsmax job properties in the Monitor. That’s probably why your post-load script tweaks are ignored, because these settings will override whatever is set in the scene file. If they didn’t, then we couldn’t support changing them from the Monitor.

I can’t seem to reproduce the issue with the extension being capitalized. Does this only happen when your post-load script is applied?

Cheers,

  • Ryan
3

Thanks for the explanation.

I’ll have to test this, but it never happened before when I was submitting the jobs via the Monitor Submission Scripts.

4

AH!!

Now it occured to me! It might have something to do with this script of Bobo’s :wink:

global SMTD_RemapLocalToNetworkPath fn SMTD_RemapLocalToNetworkPath thepath = ( substituteString (toUpper thePath) "D:\\" "\\\\RAMMSTEIN\\__UNMANAGED_PROJECTS__\\" )

I’ll remove the “toUpper” method, hopefully MAXScript shouldn’t have problems with it (as it doesn’t care about casing).

Sorry to bother you here with this, I didn’t realize it at first.

5

I don’t think that’s the case with string replacement. Maybe it would work to split the path into the folder and file name parts, do the string replacement on an upper case folder part, and then append the file name part to the end. That way, the output file name casing doesn’t change.

6

String operations DO care for casing.
For example,

a = "c:\\temp\\test" --> "c:\temp\test" substituteString a "C:" "D:" --does not work because search string is capital C --> "c:\temp\test"

That’s why I proposed to use toLower, to ensure that a path containing C: or c: would still work…
If your paths have consistent casing, you don’t need to convert the case before replacing.

7

Ah, of course they are, I forgot. :slight_smile:

In that case I propose:

regex = dotNetClass "System.Text.RegularExpressions.Regex" regex.Replace @"D:\testProject\projFolder\something.exr" @"^([D|d][:])" @"\\MyServer\__myProjects__"