Open fuzzyweapon opened 5 years ago
Hello, I am not exactly sure what is your specific use case, I do understand and I can do easily a "Apply Transformer" button on Value transformers to bake (and become the original value) of currently computed value.
You can now use "Apply/Render All Transformers" button within any transformer Edit menu to bake/render current all value transformers into a value.
Preview video: https://cl.ly/bc5012c9c569
Will be available in 1.4.6 update.
when???
It'd be really powerful for constructing test data to be able to select /some/ smart objects and selectively commit their transform values back to being the original value.
This would allow users to use transform tools to create groups of test cases more easily. For instance, right now, if I have select this value from a list, and I duplicate out a bunch of smart object entries, it will /always/ have that value across all smart objects. What if this is a category? And I want to generate data that is running through a few test scenarios that pivot on that category?
Maybe it's not a big deal when using this directly with a running API, but when trying to produce a payload for a mockservice that runs off of json strings instead of files, this is a pain, bc right now, to do this, you'd have to generate a scenario, copy out the data...generate a new one, copy it out, etc.
This is inefficient.
If I could selectively bake back those transformations, I could commit back those values, then set a new value for the transformer, commit back on other objects in the set, and so on...then simply turn my transform off and voila, all of my cases I created to test, say, some baseline business rules are there and if I want to do some fuzzing, I can still turn back on my transform and randomize it.
It'd also be nice (for maintenance of such a dataset) to be able to select which fields are baked back upon initiating a feature like that on selected smart object nodes. That way users wouldn't have to have everything just the way they want it everywhere before committing the transformed values. Without that added value, this would easily become unsuable beyond the first use and could clobber original data that was already good and the user didn't want commits from their transforms (or have to go through and turn off all the active transforms to get it right, do the action, then re-enable them >__<).