Daz 3D is part of 
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.Daz 3D is part of
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
@jbowler, Am about 100% certain the Iray messages are a compiler flag not set properly. And I just checked, those mi_plugin_factory messages are in the 4.20.0.2 log also. And I just checked my windows server, I thought it was on 4.16, but it is actually 4.15.0.2, It's logs shows the same missing directory in TEMP, I think 4.15 Iray implementation must either be completely different or maybe it's because I have to use a remote desktop connection as there is no monitor on that Windows server.
libiray.dll is version:
334300.6349 in DAZ 4.15
349500.7063 in DAZ 4.20.0.2 and 4.20.0.3
I also know they recompiled the dll's between the release and public beta, because if you try to move any of those iray files from the beta back to the release the log will tell you that the iray plugin was built for a newer version of DAZ and fail to load even though it is the same version.
What's really weird about this toolbar issue is that both of my installs 4.20.0.2 and 4.0.20.3 do not contain the files toolbars.dsx but the 0.2 install has the toolbars loaded and the beta does not. I do not modify my tool bars in any way, just use the defaults, that is why it is so strange.
One last odd piece of information, I copied the toolbars.dsx from 4.15, restarted the beta and the message was gone, but alas no toolbars either, then exited the beta and it rewrote the toolbars.dsx file. I don't actually have time to see what the differences are between the 4.15 toolbars.dsx and the one rewritten by the beta toolbars.dsx. Maybe a job for tomorrow.
That is the General Release, which does not have the putative fix, not the Public Build, which does.
That's my point - toolbars.dsx disappeared so it can't be copied. The putative fix is just that if it requires doing something that can't be done. Anyway, what is the fix? DAZ Studio doesn't create toolbars.dsx if it isn't required (I just tested 4.20.0.3), so a from-scratch installation of the Public build won't have it. I tried deleting the layout .dsx files to see what would happen:
"C:\Users\jbowl\AppData\Roaming\DAZ 3D\Studio4 Public Build\actions.dsx"
"C:\Users\jbowl\AppData\Roaming\DAZ 3D\Studio4 Public Build\customactions.dsx"
"C:\Users\jbowl\AppData\Roaming\DAZ 3D\Studio4 Public Build\layout.dsx"
I got a default set of things (none of my custom toobar entries). I loaded my saved layout (saved just a few minutes ago) but I didn't get any of the pose architecture buttons I expect to see. I restored my saved "Studio4 Public Build" directory and now all my pose architect buttons are back in place.
I did have to recreate them once before as well, in 4.16, so maybe something has been going wrong for some time.
Copy the whole %AppData%\Roaming\DAZ 3D\Studio4 Public Build directory, indeed, do what I just did and make a backup of it. I also often copy the Studio4 Public Build directory to Studio4 to make my General and Public interfaces identical to the Public. If you use the syntax Studio4 [something] to name the directory there is meant to be a way of passing something on the command line to get DAZStudio to use that as the root, but I haven't really tested that out.
Can't be copied where? The Public Build does not copy the files from the General Release, as has already been pointed out.
In any event, some issues have been found and a new build is in progress.
You always refer us to the change log, but there is no change log entry beyond 4.20.0.3.
4.20.0.3 is the current release, the change log won't show any new entries until the next release\build is out.
Apologies, my mistake. When I went to recreate it, I realized that my original procudure was erroneous. As Richard posted, some issues were found by the devs in the meantime.
Then I'll explain it better.
I loaded a scene, a pretty big one with about two hundreds props, chars and stuff in there. I then move the camera (A camera, not the perspective one). Since the camera angle wasn't what I wanted, I pressed the undo button twice instead of once (it happens some times), DAZ Studio froze for a second and suddenly the WHOLE scene was empty. No props, no chars, nothing... Like a fresh, just starrted new scene.
The only hint it was a loaded scene is the name of it in the title bar.
Can I suppose it's a bug and will it get fixed? Don't tell me someone asked to a total scene wipe using the Undo button. It litterally undoes the scene load.
You can press CTRL+Y to redo.
Which will reload your scene just as it was.
If you are using the main menu, it's the next one down under undo.
I like the feature.
I use it alot to cycle though wardrobe items like shoes when I putting outfits together.
I can load one , if I don't like it I press CTRL-Z to unload and move to the next one I want to try.
If I decide I liked a combination a few tries back, I can press CTRL+Y to roll back to it.
Very convenient.
Yes, undoing content load is a feature - it allows dealing with cases where the load has undesired effects, such as changing otion node values ot completely resetting a pose instead of just adjusting the feet for the heels or the hand pose to grip a prop, and as IceCrMn says if you didn't mean to undo you can redo.
As there is mention of a new beta this piece of info is probably useless, but what I found is that if you copy toolbars.dsx from an old intall, while the error does go away and the toolbars.dsx is rewritten on exit of DAZ, the actual change in content between the old version and the newly rewritten version is that all the lines between <Application Toolbar> and </Application Toolbar> are deleted. At least in my install.
I can understand unloading a single prop, not the WHOLE scene! It's atrocious! I have to make "fake" undo steps to avoid the first one to totally wipe the scene!
I know I can hit the "redo" button to have back all the elements of the scene...but it means lose all the puppeteer dots and tabs and some of the timeline keyframes!
Perhaps it is nice for stills but with animations it's pure madness!
Instead of clicking on an undo button or typing Ctrl Z, you could use the Edit menu, which will tell you what will be undone. You can't accidently hit it twice. If it says Undo Load and the name of your scene, you can just not click on the menu selection.
Well, that sounds like a bug or bugs with the undo feature - please report it with steps to reproduce, if you haven't.
You can clear the undo queue manually. In earlier versions of DAZStudio it was necessary to do this to fix a damaged undo queue. Look in Scripts/Utilities and use "Purge Memory". The change happened along with the change that fixed the bug that individual property loads could not be undone - this bug made it impossible to undo the side effects of the load (I think that is what Richard was referring to). E.g. loading footwear would permanently alter the character foot pose.
That said it is completely clear and unambiguous that allowing a scene "open" to be undone is a bug, because the first thing a scene open does is to, effectively, purge the memory and that deletes the undo stack! Memory should be purged after an open too.
Clearly doens't, since it creates an undo step for the scene load.
Anyway, the Undo Stack is bugged since years, the scene unoad is something new.
I'll send a bug report, hoping doen't have same fate as the timeline.
The selection bugs in the timeline might have been fixed in 4.20, or maybe earlier; it seems I can now select and deselect a key at the end of the (displayed) timeline. There may have also been some attempt to fix the click-select bugs, although not the fundamental problem that neither click select nor drag seem to work if "A" is turned on when the key-group (triangle) clicked/dragged contains both a property and its alias.
The fundamental timeline undo bug that I know about is that setting a parameter "locked" property is not recorded on the undo stack, so, for example:
It's also a PITA that the undo stack records some but not all movement between frames in the timeline. This frequently results in rapid flushing of the undo stack simply because of the large number of "skip to filtered key" operations that get recorded. Direct frame selection is not recorded, but an undo of the previous operation after direct frame selection results in the frame going back to the place where the previous operation happened, so what's the point of recording "random" skipping around the timeline?
Other obvious things haven't been fixed; the only things being keyframed in an "Environment Options" node are the transforms (who cares where the darned thing is?) Visible in render (eh?) and cast shadows (++eh?) The Matte Fog and Atmospheric Ground Fog settings cannot be animated!
Curiously the Camera DOF display properties can be animated! Yep, I can make the DOF Overlay Color blend from red to green. Why, when I can't animate important things like Lens shift; so I can move where my plate camera is, but I can't shift the lens to take account of the movement.
The bug that making a change to a Linear key value converts the key to TCB is still there too.
Loading (merging) a scene into an existing scene is undoable; opening a scene is not. Which are you talking about? The stack is purged, but the load (into an empty scene) is undoable back to the empty scene.
The new beta is, by the way, now in DIM
http://docs.daz3d.com/doku.php/public/software/dazstudio/4/change_log_4_14_0_10#4_12_2_50
I use Beta 4.20.0.4 , still can not detect HDR light in textures folder .
It looks like \runtime\ is missing. What set is it?
or has a double // or other invalid characters in fron tot he Runtime - the Sabby characters behaved in exactly the same way
why it work on Version 4.15 not 4.20 ??.
Correct. I had a look at the file, the line is
//Runtime/textures/Laticis%20Imagery/LI%20Incandenscent%20-%20Portait%20Lighting/Incandescent_001.hdr
i edit the file from :
//Runtime/textures/Laticis%20Imagery/LI%20Incandenscent%20-%20Portait%20Lighting/Incandescent_001.hdr
to :
/Runtime/textures/Laticis%20Imagery/LI%20Incandenscent%20-%20Portait%20Lighting/Incandescent_001.hdr
and it work .
I was going to suggest that. You may have to edit the other presets if they also have the //runtime entries.