think that i set up the alternate plugin.ini correctly - but it doesn’t work.
the main problem i can currently face is: i can wrote in stupid things in the pathes defined in the plugin.ini loaceted in the repository-plugin-3dsmax-folder but there won’t be generated errors in deadline monitor. so i guess deadline doesn’t really use it.
the only plugin.ini that works is the one in the locale 3ds max folder. if i change there in the pathes before starting the deadline-job the hoped-for changes happen.
has the alternate-plugin.ini-folder in the repository to be mapped as a drive on my submission workstation?
Can you post the log from the first task for a job that didn’t respect your custom plugin.ini file? Hopefully there is something there that can explain what’s going on. You can find the log by right-clicking on the job and selecting Job Reports -> View Log Reports.
Thanks!
In the meantime, many days are gone. Today I found time for the problem which still exist. Attached is the report file.
What I noticed is that Deadline opened the plugin_alternate.ini from drive C. Is that correct? And if so, which drive C? Is it the drive on the machine that is rendering (a blade)? The plugin_alternate.ini is definitely not on the workstation, from where I submitted the job.
pluginIniSwitching.20120606.01.logReport (23 KB)
Ah, that explains things. The alternate plugin.ini needs to be put into the 3dsmax plugin folder, which can be found in \your\repository\plugins\3dsmax. The contents of this folder are copied locally to the slaves at render time. That’s why it’s pointing to a path on C.
I’m sure you’ve found this documentation already, but in case you haven’t, this is covered here:
thinkboxsoftware.com/deadlin … e_Creation
Hope this helps!
I put the alternate plugin.ini file (in my case named plugin_alternat.ini) in the repository - plugins - 3dsmax - folder and check it (Edit Plugin.ini File - Button) and activate it (dropdown list) also inner the submission dialog from 3ds max submission script (Render-Tab).
In my last network rendering test today I limited the job to my local workstation “Bark06”. I changed my plugin_alternat.ini. Then it was automaticaly copied like you explained to the local thinkbox folder. But neither the “X:…” nor the “C:…” entry in line 3 (which both are pointing to the needed 3ds max plugin directory - first the original directory in network, second a local copy) caused something.
I attach the two corresponding versions of my plugin_alternat.ini. and again an error report which shows that the plugin_alternat.ini is called from Deadline from local C-Drive.
plugin_alternat______pointing.to.network.directory.ini (385 Bytes)
plugin_alternat_pointing.to.local.directory.ini (408 Bytes)
Bark06_00000_20120607124641.logReport (23.2 KB)
Out of curiosity, how did you confirm that plugins weren’t loaded from X: in the second test? The log report isn’t complaining about any missing DLLs.
Do the C: and X: folders have different plugins in them, or are they the same?
C: and X: are the same. it was only a try, if my local workstation would load from it’s loacal directory.
In the alternative 3ds max plugins directory there is a different kind of a special camera dll which is as an older version in the normal plugins directory. all the time only the old one is working. I can confirm this by the kind of displacement shading. only the new dll produces smooth shaded faces. the old one is tessallating the mesh (smoothing doesn’t work in conjunction with vray displacement modifier).
currently we changed the plugin.ini on 8 blades. this plugin.ini is pointing to the alternative 3ds max plugin directory in X:\ …and it is working. better would be the job/ task based switching from one plgin.ini to another via submission dialog. so we had more flexebility for old jobs which are still in the queue and which needs the old dll.
I just noticed this:
I wonder if this is the problem. Deadline is using both the alternate plugin.ini and the user plugin.ini. If the user plugin.ini references the old dll on C:, it’s possible that that’s the one that gets loaded first. That would explain why the new one doesn’t get loaded.
We fixed this problem in 5.1, and I noticed you are still on 5.0. In 5.1, if there is an alternate plugin.ini, that’s the only one that is used. The user plugin.ini would be ignored.
Cheers,
Talked to my team leader. We will eventual try the update to 5.1.
In the meantime I will take a closer look to the user.plugin.ini. But my first look lets not really face the problem: its only pointing to “Additional…” plugins. This only defined path is pointing to a folder in the local Max installation where in the camera dll isn’t.