AWS Thinkbox Discussion Forums

Possible bug in 3dsmax plugin

Currently using Deadline 10.0.13.6

Looking at the code of DeadlineRepository/plugins/3dsmax/3dsmax.py
on line 1264 there is a mistake in the check for whether the version is set:

    if self.Plugin.GetPluginInfoEntryWithDefault("SceneFile", "") == "":
        # Scene file submitted with job, so maxscript will be the first auxiliary file
        ...

The condition directly contradicts the comment and everything that comes after it.
The comparison operator should be “!=” instead of “==”

Please confirm whether this is undesired behavior.

If the scene file is submitted with the job, we know where it is and as such do not populate “SceneFile”. Normally that would point to the path to the “.max” file.

The logic here is good.

What problems are you seeing?

Thank you for the response.

I guess I misunderstood the comment in the code to mean that the scene file was submitted with the job as defined in the SceneFile field.

What we are seeing are jobs that try to execute the .max file instead of the maxscript. They mistakenly take the .max file as the script to run.

This means that some submitter is misbehaving and writing both “SceneFile” and copying to the auxiliary files directory.
Most suspect is the Krakatoa submitter, which I understand is not maintained by the Deadline team.

This is partially true. Both the SMTD that ships with Deadline and the Krakatoa submitter were written by the same person (yours truly), and looking at the KrakatoaGUI code I can clearly see how it could get messed up. :blush:

Basically Krakatoa MX uses the same SMTDFunctions and SMTDSettings struct defined by the integrated Deadline submitter for 3ds Max. In general, any settings set in the SMTD UI (or in the case of Deadline 10 stored and restored with the .MAX scene file) will also apply to the Krakatoa Jobs. Only the settings that are absolutely required by Krakatoa are being overwritten. So for example if you set up some Limits or White Lists in the SMTD UI and submit a Krakatoa job, these settings would persist.

The command line built by the Krakatoa MX UI always adds the 3dsMax scene file to the list. But if you have set your SMTD to any of the alternatives to the “Save and Submit Scene file with the Job to the Repository” option (e.g. global or custom path, or original file path), then the SceneFile= property would be written, but the MAX file would still be in the command line, leading to the issue you reported.

I will have to go sit in a corner and thing about what I did there :cry:
Krakatoa should either override the MAX scene file saving option to always save and submit the file with the job, or it should respect the setting and include the file in the command line OR in the SceneFile= property accordingly.

A temporary solution would be to edit the file KrakatoaGUI.ms in your Krakatoa MX\Scripts\ folder.
You will have to edit its security settings to allow editing. Open in a text editor.
Locate the fn SubmitJob function and edit it:

	fn SubmitJob partitionStart partitionEnd partCount partitionMode:#tasks PartitionRange:true timeout:3600 =
	(
		local initialArgs = ""
		local oldJobName = SMTDSettings.JobName 
		local oldComment = SMTDSettings.Comment 
		SMTDSettings.Comment = edt_comment.text
		SMTDSettings.JobName = edt_jobname.text
		local oldSubmitSceneMode = SMTDSettings.SubmitSceneMode --> NEW LINE, store the old scene submission value
		SMTDSettings.SubmitSceneMode = #reposave --> NEW LINE, enforces scene save and submission


...
		
		SMTDSettings.JobName  = oldJobName 
		SMTDSettings.Comment = oldComment 
		SMTDSettings.SubmitSceneMode = oldSubmitSceneMode --> NEW LINE, restore the old value

		SMTD_LastMessage = SMTDFunctions.getRenderMessage()
		if retCode == #success then
		(
			SMTDSettings.DeadlineSubmissionSuccessful = true
			SMTDFunctions.getJobIDFromMessage SMTD_LastMessage
			try(FF_AssetTracker_Functions.TrackDeadlineRender SMTDSettings.DeadlineSubmissionLastJobID)catch()
		)	
		retCode 
	)

Sorry about the inconvenience!

Thanks, that makes sense! I worked under the wrong assumption for a while.

I’m pretty new to this software, but did go through the SMTD functions, so I think I understand what you are saying :slight_smile: .
I suppose the correct solution would be to respect the settings.

In the meanwhile, we’ll use the workaround you suggested.

On a side note, any chance the Krakatoa submitter could be distributed with the Deadline repo, like other submitters?

I can confirm the workaround fixed the problem.

Thanks again! I hope an official fix will make it soon :wink:

Privacy | Site terms | Cookie preferences