I noticed after setting the path of my caching for Stoke, that for some reason Stoke randomly creates and intermediate sub folder? Is there any way to disable this from happening. It’s posing a problem when we try to develop internal pipeline tools for Stoke specifically into our currently pipeline folder structure. This sub folder that automatically creates itself is a problem.
[attachment=0]folder.jpg[/attachment]
Any help would be great
As the docs mention:
Each Stoke object will generate a unique random ID upon creation. This ID will be used to create a sub-folder called Stoke_XXXX_YYYY within the Base folder.
How can we disable this from happening upon caching?
The Stoke UI enforces that ID, so anything the user does with the version, path etc. controls ends up creating that sub-folder.
While we could consider adding an option to turn this off, it is probably too late with all the previous Stoke versions that exist out there.
The sub-folder name depends on a property of the Stoke object, which is stored in its paramblock as randomID.
So if you want to know what the path will be, you can build it by using
$.getCachePath() + "Stoke_" +$.randomID+"\\" + $.outputVersion + "\\" + $.outputPrefix+"_####.prt"
-->"C:\Users\Borislav\AppData\Local\Thinkbox\Stoke\Cache\Stoke_663921_651078\v001\Stoke_####.prt"
Or you can ask the delegate what the output path is, and it will tell you
So the folder is not really random, the randomID is generated randomly once on object creation, and stays with the object for its whole life as part of the paramblock. Thus, if you merge a Stoke object into another scene, it will come over with its own ID and will resolve the same way. I don’t see why your pipeline tools cannot query the ID or the actual path to make the right decisions (assuming they have access to the Max scene content, of course…)
It’s not that our tools cant query that subfolder. It’s more of a problem where all of our other fx tools we use like, Phoenix, fumefx, tp…etc. we have a cache manager and publishing system that expects the caches to be in a specific folder just based on the shotgun entry name.
We can resolve this and find the latest cache outside of max or wherever. But in this case we have no ability to do this. We would have to add another column in shotgun jusy to store this random it per stoke object published. Granted our assembly tools would then require a one off conditional statement to handle just stoke whereas all the other setups can use the same exact method.
Just saying it would be easier to have the ability to turn it off if possible. It would be a nice feature without hurting any existing systems.
I’m not by any means saying that the random subfolder is a bad thing, i can certainly see it’s use. However in our case it just causes unexpected results and more importantly is not necessary, or work with the pipeline folder structure.
Again, there is a UI level paramBlock that holds the various components of the path as implemented by the Stoke scripted plugin.
And then there is the C++ plugin (the delegate), which has no concept of versions, base paths, random IDs etc. In theory, setting the $.delegate.SequencePath would be enough, but as soon as the UI is accessed to set any of those components, or run the simulation, the path will be rebuilt from the components and overwritten.
Here is a quick and dirty attempt to make the RandomID folder optional. Still Work In Progress, but promising…
Currently a new Stoke object is still created with a default RandomID folder behavior, but
the actual sub-folder is now listed in the UI and
there is a button with a menu to turn it off for the current object
Once the RandomID folder usage is turned off, the path will be just the Base + Version + Prefix.
The lack of RandomID in the file name leads to a new behavior: If you simulate v001 of some base path with a Stoke object, then later create a fresh new Stoke object that uses the same path and version, it will automatically load the previously simulated PRT data. This is probably desirable, as you can easily create new Stoke objects that take over the folders of older simulators to act as mere loaders, or to create new iterations with new settings.
What is left is to add a global switch to turn off the RandomID folder option for any newly created Stoke objects. It would be accessed via the same new menu, and once set, it will be recorded in an INI file and cause newly created Stoke simulators to use the same behavior.
And then I will have to implement this for the Field Simulator’s VDB output which currently uses the same RandomID mechanism.
Yeah this is great to hear and is more along the lines of what we wanted. Will these changes then be added to the official release of stoke once you finish it’s development?
The new behavior is and expected one as fumefx and phoenix both work that same way as well.
