Problem on Render Blades

Just doing a rebuild of our master image and I’m getting an issue, the same installer was used on my machine and works fine. But installed on the network it’s throwing a maxscript error when I send a job via Deadline.

3ds Max 2014
Krakatoa - 2.3.1.56082_x64
Deadline 6.2.0.32 R

The main error here appers to be that the MAXScripts have not been loaded for some reason.

Normally, the way Krakatoa MX loads is:
*The plugin.ini entry to the DLL causes the DLR C++ plugin to load.
*The same entry in plugin.ini also causes the MAXScript Auto-Load pass to run the KrakatoaStartup.ms file located in the same folder as the DLR.
*The various fileIn() lines in that startup script should load the scripted components including KrakatoaGUI.ms which contains the FranticParticleRenderMXS struct definition.

So for some reason, one of these steps (most likely the last one) is not executed on the slave machine.
If the plugin.ini does not contain an entry to the DLR, then no C++ plugin and no scripts would be loaded. But the fact that initRenderer() is being called shows that the C++ plugin has been loaded. So most probably the KrakatoaStartup.ms has also been run.

A possible reason for the 3rd step above to not perform correctly would be if the \Scripts folder was not located in the same relative path to the DLR folder as expected. Normally, the Plugin.ini path is C:\Program Files\Thinkbox\Krakatoa MX\3dsMax2015. To find the Scripts folder, the Startup script goes one level up to C:\Program Files\Thinkbox\Krakatoa MX, then looks for a \Scripts sub-folder. If for some reason the DLR path is two folders deep instead of one, it won’t be able to resolve the \Scripts folder. But if you used the regular installer, or copied a pre-installed Krakatoa MX folder structure to other machines, I would expect the relative structure to remain the same. In short, while the actual root of the \Krakatoa MX\ folder can be anything, its sub-folders cannot be moved around…

If none of the above explanation points at a possible problem in your setup, we could add some debug prints in the KrakatoaStartup.ms file that print to the Deadline Log and see what happens…

Hi Bobo,

Which Plugin.ini file should I be looking at?

I’ve done some things with our max plugin.ini to load some scripts and plugins from our custom repository, perhaps that might have broken it.

Dave

If you are running with the US English locales, then the file is by default under
C:\Program Files\Autodesk\3ds Max 2015\en-US\plugin.ini

We try to inject a line into all plugin.ini files for all languages we find, but I don’t think that is relevant in your case. I don’t know if there is a dedicated en-UK setting. Typically the content should be something like

[Directories]
Krakatoa=C:\Program Files\Thinkbox\Krakatoa MX\3dsMax2015\

It’s in the en-US plugin.ini

I think it quite possibly has something to do with User Accounts, it’s logged on as the rendering account, but when I launch 3dsmax in workstation mode it’s trying to pull user macros from the admin account (where 3dsmax was probably installed from)… Krakatoa was missing all the menu items, I’ve copied over the appdata from the rendering user to the admin user and that’s made Krakatoa work in workstation mode at least, but still not in the net render mode.

Sigh… typically the last plugin I need to get working before the rollout!

It should not depend on the User settings.

Open the file KrakatoaStartup.ms and see what it is doing.

After defining a few globals including FranticParticleRenderMXS, it gets the Home directory from the Plugin itself:

local theKRoot = try(FranticParticles.KrakatoaHome)catch(undefined)

This value is taken from the folder where the DLR was found, minus one sub-directory. So it would be typically C:\Program Files\Thinkbox\Krakatoa MX\

Then if that is not undefined, it checks to see if Max is running in Slave (network) mode.
If that is the case, it skips all the UI stuff like Macros and Icons copying.

Then it does a bunch of fileIns() of the necessary scripts, incl. KrakatoaGUI.ms…
All these calls use the Home folder resolved by the DLR when it was loaded, e.g. C:\Program Files\Thinkbox\Krakatoa MX, plus Scripts\ and the name of the MS file. You could modify the script on your network blade by injecting some print calls where instead of printing to the Krakatoa Log, you print to the DeadlineUtil log:

try(DeadlineUtil.LogMessage "Blah")catch()

In fact, you could do a search and replace for “FranticParticles.LogProgress” and replace it with “DeadlineUtil.LogMessage”. As result, all steps of loading Krakatoa will be logged by the Slave!

Once you have a log like that, we might understand where it is failing…

Swapped out the Logging message… no clues…

It is possible that the Lightning DLX was loaded after the scripts have already run. :frowning:
Or the scripts do not run at all…

Out of curiosity, what happens if you submit the same Krakatoa job in Force Workstation mode? Does it render or does it fail (assuming the blade can see a workstation license of Krakatoa, of course).

Basically we want to know whether the installation of Krakatoa is totally broken, or only the Slave (network rendering) mode.
If you can VNC into the blade and run Max and Krakatoa, it would be a good test too.

Also, can you confirm that all other renderers (Scanline, VRay) work on that blade (in other words, this is in fact a Krakatoa MX problem and not a Deadline Slave problem)…

So it doesn’t work in Force Workstation mode, throws the same error, did 3 times, then decided to successfully render… not sure why… I’ve re-queued the job and I’m getting errors again. The same error message appears, if I click it manually there’s another message “Unknown property: “PostLoadEvent” in undefined”

No idea why it rendered successfully once… job completed and rendered file was as expected, but not again since, 8 times and counting…

In answer to other questions, yes Vray, Fume, Afterburn all rendering fine.

I’m going to sleep on it and see what fresh eyes does in the morning/afternoon…

Successful Render Log

krak.jpg

One last look at it before I turn off the lights…

So it’s looking like a permissions/user issue, I just started up max on that machine in workstation mode manually and there were a few message boxes, checked the maxscript listener and spotted this…

The currently logged on user is called ‘Remote’ so it looks like it’s being denied access to the ‘Local Administrator’ folder…

I ran the KrakatoaStartup.ms and got the following error, same again, to do with permissions, and running as administrator… I’ll look into it tomorrow morning!

Ok, you are right about the permissions.

These temp* files are the result of the multi-threaded MacroScript evaluation of 3ds Max that was introduced a few years ago. Once they are written to disk, they would be renamed to the final MCR name.
In some of the Krakatoa .MS files we are loading (including KrakatoaGUI.ms) there are also MacroScript definitions, so when fileIn() is called, Max is trying (and failing) to create its MCR copies in the current user macros folder.

The result seems to be failed filein() calls for any MS file that contains MacroScript definitions. Since the KrakatoaGUI.ms has MacroScripts, and is the place where the struct is defined that shows up as ‘undefined’, I guess we now know the cause for the trouble.

I hope you can figure out the permissions tomorrow…

Couple of things I noticed, which can do no harm in resolving here.

I would make sure all machines including submission workstations are running Max 2014 with SP5. I’m not entirely sure what version: “16.3.207.0” is for Max 2014? Is it a non-public/beta version or perhaps it’s just SP3 but without the subs extension? Either way, bringing it in-line with your slave running SP5 can only help here :slight_smile:

Finally, Deadline v6.2.1.50 is available and uses your existing v6.2 license, so it’s just a simple repository install that is required for 80+ fixes/tweaks/back-ported code from Deadline v7.0. If your currently configuring/updating your production setup, I would highly recommend this minor point update.

C:\Users\remote\AppData\Local\Autodesk\3dsMax\2014 - 64bit\ENU\3dsmax.ini

Had the entry: Additional Macros
pointing to the Local Admin folder for some reason, I’ve changed this to the remote account and it worked first time!

All good, thanks for the help!

@Mike, yep I’m missing SP’s on my machine, will be re-installing mine next week anyway, and I’ll update Deadline once I have everything up and running.

Is Nuke 9 support coming to Deadline 6.2?

Rgds

Dave

Deadline v6.2.1 added support for Nuke v9.0 :slight_smile:
thinkboxsoftware.com/deadlin … -2014.html

Great now I just need to figure out why Max 2013 has stopped working on my blade…

Any ideas??

Basic max job, no plugins, just scanline as renderer… fails to load…

Max2013 PU6 needs to be installed on the slave machine. Max 2013 was initially broken in their shipping version at release. You need at least PU2.
thinkboxsoftware.com/news/20 … -2013.html

The log is your friend :slight_smile:

Thinkbox Support is my friend :slight_smile:

And of course that was the issue, I’d be told 3dsmax had been installed with all updates…