Is it possible to add a switch for the deadline check?
ie I check it, so that it doesn’t check for deadline every time I switch to particle save mode or I fat finger the close button when I am in particle save mode on the GUI dialog.
How would this be different from “Do Not Detect Deadline” in the drop-down list?
Also, in the latest builds, if the Deadline Functions have been already loaded, it shouldn’t take time to switch to Save / Partition mode.
Oddly enough, I have it set to Do Not Detect Deadline and it still seems to be searching for it, it even spits it out to the Log window.
Ahh, figured it out, since the Partition rollout was open it always searches for deadline regardless of the state of the drop down.
So the fact of the matter still remains, so even though I have Do Not Detect enabled, shouldn’t this disable the Deadline search when I open the partitioning rollout?
I read through the code and it sounds like it should NOT search for Deadline if detection is disabled.
When the rollout opens, the event handler on Krakatoa_GUI_Partition rolledUp val do() is called and if the argument is true (opening), the function FranticParticleRenderMXS.DetectDeadline forceloading:false is called. This function has the code to check the INI file for the settings of the drop-down list and if it is “1” (disable), it returns early and logs the warning " -Deadline Support is Explicitly DISABLED. Use the drop-down list under Partitioning to change…".
The only way this would not work is if the INI file is not written to correctly, for example because the file is somehow locked.
Once you have set the list to “Do Not Detect Deadline”, try running the following in the MAXScript Listener and see what value it is returning:
getIniSetting (GetDir #plugcfg + "\\Krakatoa\\KrakatoaPreferences.ini") "Deadline" "DetectDeadline"On my machine, it returns “1” when Deadline detection is disabled, and “2” when it is enabled. See what you get.
Ah Hah, the value is null “” Indicating that the drop-down has never been initialized/used. I would have thought it would have had a value when the ini was written.
but to the point, actually invoking the drop down and selecting the Do Not Detect writes the value “1” and all is wonderful and worky worky.
Since the Do Not Detect is by default the first in the list, it fools the silly user (myself) into thinking that it is set, when it actually has no value at all.
Jees I forget some of this s*#t working across a couple different machines, what is set on one is not set on another 
Anyway thanks
Now I would consider this a bug, not a case of a silly user. If the list defaults to “Do Not Detect”, it should store the value of “1” the first time it fails to detect Deadline, so it would not continue trying, especially if Deadline is not even installed. I will try to fix it tomorrow. Thanks for looking.