Previous preset awareness/cache?
Silas3D
Posts: 565
Hi everyone
Through a custom script, is it possible to recall the last preset applied? Would it be cached in DS some way?
For example:
- I apply a material preset to my figure/object
- Run my script which does some stuff
- After `some stuff`, script re-runs the material preset
I can do a before and after script, but it would be far more efficient and user-friendly if this could be handled in the script.
Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
I don't believe it is kept in memory, so your only option would be to scrape the log file.
How would one do that? Presumably there would need to be a path to the preset if something like that was possible?
Well, bear in mind that log entries are not set in stone - they have chnaged and may well do so in future. But, currently, each file opened is entered into the log - but it doesn't tell you what kind of file it was, or what the target was for a preset.
Ok I guess I'll just have to split into two scripts :(
Since they could possible be written to the undo stack, that may prsent an unconventional way of getting the data.
@Tugpsx Novel idea, but in this case I'd need a redo function as well as the undo - do you know if such a thing exists? I know there's a redo within the UI, but don't know if there's a script equivalent.
@Silas3D :
Have you looked through all the samples available on the scripts samples page?
What about using a Sub Script in your script for #3 to execute after your script finishes #2?
* Sub Script : http://docs.daz3d.com/doku.php/public/software/dazstudio/4/referenceguide/scripting/api_reference/samples/remote_operation/sub_script/start
Just my 'hacky' script writing thinking process to your problem, and how I would pursue it based on what I did for my slider parameter colors function. I could be way off, and my first iteration of my script used Sub Script methods for dynamic dialog switching (which I had to abandon due to stack override errors I couldn't solve if a user was to go back/forth several times between dialogs [broke at around seventh call] from first script activation).
But, for my color parameter function, I could change 'live' within the script execution before auto-script completion, or user cancellation.
The way it works is with saves/retrievals to Windows Registry (only tested on Windows) based on how mCasual utilized push/pop context for permanent data saves for script parameters. I set all data saves to record for both execution completion and user cancellations, but set independence for the color parameter function to allow to retrieve live saves/calls while script is open (with final save pusing to regular script exec/cancel parameters).
So, my thinking for your issue is something along those lines -- Maybe an auto-save to registry your #1 (after completion), then after #2 completes, #3 calls another script (not user facing) that retrieves the saved registry data for doing #1 again with these parameters. Then script execution completes.
What do you think?
* EDIT : To add link...
* EDIT 1 : Just remembered after rereading my last paragraph -- The auto-save to registry won't work until after script execution/cancellation, so you will have to add a user save button (I have 3 buttons; Save/Load/Default [which loads Daz Studio default color A/B]) to save the preset data to the registry while the script is open, before #2, where #3 will retrieve and execute.
I agree reading the logfile is too fragile.
Can I ask why you need to apply the material preset before AND after?
I don't think you can access this information through the undo stack, but using DzUndoStack you might be able to lock() the undo stack, undo() applying the preset (use getCaption() to verify it is what you want to undo first), do whatever you need to do, call redo(), and then unlock().
I haven't tried this, so not sure if it will work or not...
It's a commercial product idea so I'm sure you'll understand that I can't say too much - let's just say that my script will be doing some preparation on a model so that a material preset will work entirely, rather than approx 75%.
Presently I would have to have two scripts to run - a prep script, apply the mat preset and then a cleanup script. From a UX POV it would be much easier if a customer didn't need to do this but for robustness' sake I may just have to do this anyway.
@DaremoK3 the script samples are honestly very intimidating due to verboseness and lack of documentation. Obviously to the trained eye this is not an issue hehe!
As per response to Omniflux, the issue is with regard to the Material Preset. I can't call a specific preset in the script as that is an unknown (hence the cache/log etc awareness requirement). So as it stands I would need to run a prep script, apply mat preset, then run another cleanup script.
I just wanted to make this as easy to use as possible, but if it has to be separate scripts so be it.
Zev0's Fit Control product has a similar work flow. Run script to add morphs, user adjusts morphs, run script to remove unused morphs.
If the reason to run the material preset the first time is so that you know which material preset to apply afterword, than I can only think of two ways to do this with the current script API besides monitoring the logfile or messing with the undo stack, of which neither option is robust enough I would feel comfortable using in a commercial project.
The first is the workflow you are currently looking at.
The second is build the whole UI to allow the user to choose the preset from within your script - and I don't think that's worth the effort it would take to get something that would feel like a natural extension of the existing UI.
I suggest submitting a feature request to expose the last (or list of the last) files loaded/merged. It probably won't help you with your current project, but may in the future. I feel the developers are pretty responsive to such things, especially when they are simple to implement and obvious holes in the current API. Sometimes they even appear in the upcoming changelog a day or two after being discussed in this forum.
@Omniflux thank you, where would one go about raising such a request?
https://helpdaz.zendesk.com/ - it uses the same login as the main DAZ site, but you have to click on "Sign In" first.
Choose "Submit a Request"
then, choose "Technical Support Questions"
down at the bottom under "Tech Ticket Tracker" choose "Feature Request"
fill out the rest as makes sense.
Well, they are surely "verbose" because they include a lot of comments, and make a lot of steps very explicit, so as to function as education examples.
You might be able to use callbacks (DzCallBackMgr, DzCallBack) and to respond to signals from DzAssetIOMgr to do what you want, at least to an extent (I'm not entirely clear on the aim, and this isn't an area I have dived into).
No disrepect Richard but this comment is quite ignorant. Whilst there may be a lot of script comments, this doesn't mean that they are always easy to understand or provide enough detail. Frankly I think it's quite appalling that DAZ rely on the community to provide technical support for the script engine that THEY wrote - I know this because I have raised a number of tickets asking for assistance only be shown to the script samples, meaning that only people who understand Qt Script/C++/JS will be able to make sense of it. Very rarely has there been additional context for HOW to use these scripts. I'll go back to a previous comment I made about scripting being very intimidating for a lot of people. Nothing ever really seems to be done by DAZ to try and break down this barrier to entry. Am I missing something?
It's one thing to point someone to a general script that may help, its another thing to point someone to a specific part of a script and actually explain how it works or why it is needed. The script samples are nothing more than a glossary, unless you're lucky enough to find a sample that does everything you need it to do (and nothing else).
Thank you for the suggestion Richard, but looking at these pages gets me no closer to finding a solution, they just don't make any sense to me. That may well be frustrating for you as someone that may have a more trained eye for these things, but it honestly makes my head hurt trying to make sense of what is essentially a foreign language to me. All I have gleaned from the callback pages is that you can dynamically load a script, there's no mention of presets.
I'm not sure what you expect in the way of explanation - how much understanding of scripting, or more specifically Javascript and the like scripting, do you have as a starting point? This is a field where to a certain extent you need to have at least a tenuous grasp of several other things (basic scripting, how DS works in its data handling, how processes can relate to each other) to build on.