Daz Studio Pro BETA - version 4.20.0.17! (*UPDATED*)

1232426282933

Comments

  • MadHammerMadHammer Posts: 34
    edited March 2022

    @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.
     

    Post edited by MadHammer on
  • MadHammerMadHammer Posts: 34
    edited March 2022

    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.

    Post edited by MadHammer on
  • jbowler said:

    DoctorJellybean said:

    MadHammer said:

    Just for giggles, what happens if you rename toolbars.dsx so DAZ Beta can't find it, can you recreate it within DAZ Beta itself? Because I can't. and I don't even have that file in my 4.20.0.2 directory so I can't just copy it from there. The toolbars work in 4.20.0.2.

    I deleted toolbars.dsx, restarted DS and selected my Saved Layout. DS recreated toolbars.dsx.

    I tried renaming the whole DAZ Studio4 directory so that it is recreated from scratch using the General release.  DAZ fails to create any of the .dsx files.  So, yes, it's not possible for anyone to copy it once it is gone.  It does look as though the General release will write the files if they exist - at least using an old directory I see the file date stamps updated.  The full list of files which seem to be causing the problem is (these are the default locations):

    2022-03-02 08:53:54.732 [ERROR] :: Open File Failed - The file could not be opened: C:/Users/jbowl/AppData/Roaming/DAZ 3D/Studio4/actions.dsx
    2022-03-02 08:53:54.733 [ERROR] :: Open File Failed - The file could not be opened: C:/Users/jbowl/AppData/Roaming/DAZ 3D/Studio4/customactions.dsx
    2022-03-02 08:53:54.733 [ERROR] :: Open File Failed - The file could not be opened: C:/Users/jbowl/AppData/Roaming/DAZ 3D/Studio4/menus.dsx
    2022-03-02 08:53:54.733 [ERROR] :: Open File Failed - The file could not be opened: C:/Users/jbowl/AppData/Roaming/DAZ 3D/Studio4/actionmgr.dsx
    2022-03-02 08:53:54.733 [ERROR] :: Open File Failed - The file could not be opened: C:/Program Files/DAZ 3D/DAZStudio4/resources/actionmgr.dsx
    2022-03-02 08:53:54.733 [ERROR] :: Open File Failed - The file could not be opened: C:/Program Files/DAZ 3D/DAZStudio4/resources/dazstudio.mnu
    2022-03-02 08:53:54.748 [ERROR] :: Open File Failed - The file could not be opened: C:/Users/jbowl/AppData/Roaming/DAZ 3D/Studio4/toolbars.dsx

    Replace C:/Users/jbowler/AppData by %AppData%.  Perhaps if one of those got deleted due to problems with 4.20.0.2 4.20.0.3 will not be able to create it?  (I can't test that yet; 4.20.0.3 works for me so I'm doing an 11 hour render ;-)

    That is the General Release, which does not have the putative fix, not the Public Build, which does.

  • jbowlerjbowler Posts: 745

    Richard Haseltine said:

    jbowler said:

    I tried renaming the whole DAZ Studio4 directory so that it is recreated from scratch using the General release.  DAZ fails to create any of the .dsx files.  So, yes, it's not possible for anyone to copy it once it is gone. 

    [* * *]

    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\menus.dsx"
    "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.

  • jbowlerjbowler Posts: 745

    MadHammer said:

    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. 

    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.

  • jbowler said:

    Richard Haseltine said:

    jbowler said:

    I tried renaming the whole DAZ Studio4 directory so that it is recreated from scratch using the General release.  DAZ fails to create any of the .dsx files.  So, yes, it's not possible for anyone to copy it once it is gone. 

    [* * *]

    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\menus.dsx"
    "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.

    Can't be copied where? The Public Build does not copy the files from the General Release, as has already been pointed out.

  • Richard Haseltine said:

    jbowler said:

    Richard Haseltine said:

    jbowler said:

    I tried renaming the whole DAZ Studio4 directory so that it is recreated from scratch using the General release.  DAZ fails to create any of the .dsx files.  So, yes, it's not possible for anyone to copy it once it is gone. 

    [* * *]

    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\menus.dsx"
    "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.

    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.

  • barbultbarbult Posts: 23,241

    Richard Haseltine said:

    Richard Haseltine said:

    jbowler said:

    Richard Haseltine said:

    jbowler said:

    I tried renaming the whole DAZ Studio4 directory so that it is recreated from scratch using the General release.  DAZ fails to create any of the .dsx files.  So, yes, it's not possible for anyone to copy it once it is gone. 

    [* * *]

    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\menus.dsx"
    "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.

    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.

  • barbult said:

    n 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.

  • DoctorJellybeanDoctorJellybean Posts: 7,990
    edited March 2022

    MadHammer said:

    Can you outline your steps, because your experience is very different than mine. Also was your install of 4.20.0.3 over the top of a previous Public Beta or was it a first time install of a Public Beta? That is the only thing I can see that might be different about our setups. 

    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. 

    Post edited by DoctorJellybean on
  • ImagoImago Posts: 4,922

    PerttiA said:

    Imago said:

    Richard Haseltine said:

    Are you sure it was a camera you adjusted, not the Perspective View (which doesn't get added to the undo stack)?

    Absolutely sure the Scene tab is completely empty and there's nothing in the viewport.

    That is not what Richard was asking.

    If you were using the perspective view (instead of 'real' camera), every click of Undo you made, was affecting the scene instead of the camera. 

    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.

  • IceCrMnIceCrMn Posts: 2,115

    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.

  • MadHammerMadHammer Posts: 34
    edited March 2022

    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.

    Post edited by MadHammer on
  • ImagoImago Posts: 4,922

    Richard Haseltine said:

    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.

    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!

  • barbultbarbult Posts: 23,241
    edited March 2022

    Imago said:

    Richard Haseltine said:

    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.

    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.

    Screenshot 2022-03-03 102730.jpg
    227 x 59 - 7K
    Screenshot 2022-03-03 102904.jpg
    277 x 74 - 9K
    Post edited by barbult on
  • Imago said:

    Richard Haseltine said:

    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.

    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!

    Well, that sounds like a bug or bugs with the undo feature - please report it with steps to reproduce, if you haven't.

  • jbowlerjbowler Posts: 745

    Imago said:

    I have to make "fake" undo steps to avoid the first one to totally wipe the scene!

    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.

  • ImagoImago Posts: 4,922

    jbowler said:

     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.

  • jbowlerjbowler Posts: 745

    Imago said:

    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:

    1. Y translate a character, observe this is undoable according to the edit menu.
    2. Lock the Y translate property.  Note there is no new entry on the edit menu - it still says "undo Y translate".
    3. Undo; the Y translate is not undone.  The property is still locked, the character doesn't move and the edit menu now says "redo Y translate".
    4. Now unlock the property... Somehow the undo stack has been damaged and undo/redo of the Y translate do nothing.  Wackiness results.

    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.

  • Richard HaseltineRichard Haseltine Posts: 97,382
    edited March 2022

    Imago said:

    jbowler said:

     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.

    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.

    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.

    Post edited by Richard Haseltine on
  • The new beta is, by the way, now in DIM

  • Richard HaseltineRichard Haseltine Posts: 97,382
    edited March 2022

    jbowler said:

    Imago said:

    I have to make "fake" undo steps to avoid the first one to totally wipe the scene!

    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.

    http://docs.daz3d.com/doku.php/public/software/dazstudio/4/change_log_4_14_0_10#4_12_2_50

    Post edited by Richard Haseltine on
  • I use Beta 4.20.0.4 , still can not detect HDR light in textures folder .

    Untitled.jpg
    448 x 536 - 43K
  • The RED Crown said:

    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?

  • DoctorJellybean said:

    The RED Crown said:

    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

  • Richard Haseltine said:

    DoctorJellybean said:

    The RED Crown said:

    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 ??.

  • Richard Haseltine said:

    DoctorJellybean said:

    The RED Crown said:

    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

    Correct. I had a look at the file, the line is

    //Runtime/textures/Laticis%20Imagery/LI%20Incandenscent%20-%20Portait%20Lighting/Incandescent_001.hdr

  • DoctorJellybean said:

    Richard Haseltine said:

    DoctorJellybean said:

    The RED Crown said:

    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

    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 .

  • The RED Crown said:

    DoctorJellybean said:

    Richard Haseltine said:

    DoctorJellybean said:

    The RED Crown said:

    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

    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.

Sign In or Register to comment.