Loading...
> >

Daz Studio 4.12 Pro, General Release! (*UPDATED*)

1…222324252628»

Comments

  • fixmypcmikefixmypcmike Posts: 19,565

    Window > Workspace > Save Layout, keyboard shortcut is F4

  • mindsongmindsong Posts: 1,693

    so it can be assumed that entering no name at the 'enter name' pop-up dialog does 'the right thing'? (not at a DS computer)

    (i have many a 'named' workspace using this, but simply want a basic 'save current', as occurs with a normal DS shutdown)

    this may qualify for 'tip of the day' award

    tnx

  • dramenondramenon Posts: 52
    Richard Haseltine said:
    pkinnane_44e978d933 said:

    I'm going to post this straight:

    Obviously we cannot see what is happening within the Octane plugin code, only what is happening around it when attached to the debugger.
    --
    There is a task/runnable that the Octane plugin is starting in the global thread pool that is not completing. Since Daz Studio (4.12+) is waiting for threads in the global thread pool to cleanup before it closes (to prevent crashes and/or potential data loss during shutdown), the application is not closing until cleanup of the global thread pool times out. This used to default to a very long time (i.e. many hours), but a pending release reduces this to 3 minutes max. This wait occurs after plugins are shut down [virtual void DzPlugin::shutdown()], but before the pane is deleted or the plugin is unloaded.
    --
    If this is a task/runnable that is truly intended to run for the duration of the plugin's lifetime, it should not use the global thread pool, rather it should use its own QThread instance.
    --
    N    ote, use of API such as QtConcurrent make use of the global thread pool

    So if I am reading this right, It's up to Octane folks to fix the plugin because of a change made to how Daz Studio (4.12+) works with ALL PLUGINS. Seems like the right thing to do here per the explanation.

    I assume other plugins have to do the same?
    Is there a way to know what other Plugins might have the same issue.

    Joys of software! Thanks for the info.
     

  • jayjarrettjayjarrett Posts: 27

    Hey guys. I am new to the beta thing, so please give me a break while I settle, in. I have been using DAZ for about a year and I am totally addicted. Well, I love doing beta testing and I am aware of the risks I take. I am well versed in the file system and have had to uninstall and install many times. So this brings me to my question. I installed the public beta the other day and it, I thought, was working fine. Well, it seems the PostgreSQL Valentia conversion cannot be read and get this error and then the programs go back to the downloadable folder. The Dim will not install anything, but my manifest file is intact. I removed all "system" files with dim and tried the reinstall and still got the error. I might just Nuke it and start over. I am going to give that content wizard a whirl and start fresh. But if there is a simple fix let me know. Thanks again, and I will do my best to keep up.

    Jay

    Screenshot 2020-10-31 004210.png
    721 x 439 - 28K
    Screenshot 2020-10-31 003014.png
    2664 x 159 - 51K
  • Richard HaseltineRichard Haseltine Posts: 96,696
    mindsong said:

    so it can be assumed that entering no name at the 'enter name' pop-up dialog does 'the right thing'? (not at a DS computer)

    (i have many a 'named' workspace using this, but simply want a basic 'save current', as occurs with a normal DS shutdown)

    this may qualify for 'tip of the day' award

    tnx

    No, you have to give it a name if you want to keep it. DS loads the previous session layout on load, and saves on exit unless told otherwise by the command line switches - even if there was an option to "save session layout now" it would still be overwritten on exit, or potentially damaged on a failed exit (e.g. crash or forced exit) so the situations in which it was useful would be limited to the occasions on which DS exited without touching the session files, and on which you wanted to recover the chnaged layout (but didn't want to save it as a named layout).

  • Richard HaseltineRichard Haseltine Posts: 96,696
    dramenon said:
    Richard Haseltine said:
    pkinnane_44e978d933 said:

    I'm going to post this straight:

    Obviously we cannot see what is happening within the Octane plugin code, only what is happening around it when attached to the debugger.
    --
    There is a task/runnable that the Octane plugin is starting in the global thread pool that is not completing. Since Daz Studio (4.12+) is waiting for threads in the global thread pool to cleanup before it closes (to prevent crashes and/or potential data loss during shutdown), the application is not closing until cleanup of the global thread pool times out. This used to default to a very long time (i.e. many hours), but a pending release reduces this to 3 minutes max. This wait occurs after plugins are shut down [virtual void DzPlugin::shutdown()], but before the pane is deleted or the plugin is unloaded.
    --
    If this is a task/runnable that is truly intended to run for the duration of the plugin's lifetime, it should not use the global thread pool, rather it should use its own QThread instance.
    --
    N    ote, use of API such as QtConcurrent make use of the global thread pool

    So if I am reading this right, It's up to Octane folks to fix the plugin because of a change made to how Daz Studio (4.12+) works with ALL PLUGINS. Seems like the right thing to do here per the explanation.

    I assume other plugins have to do the same?
    Is there a way to know what other Plugins might have the same issue.

    Joys of software! Thanks for the info.

    I would think if there were others they'd have been found by now, given that (at least until the free licenses were available) a relatively small proportion of the userbase would seem likely to have an Octane license. I'm not sure to what extent all this is new - it's possible that it has been happening for a long time, but because of the lack of instance management it was not immediately apparent to users.

  • DoctorJellybeanDoctorJellybean Posts: 7,889
    jayjarrett said:

    Hey guys. I am new to the beta thing, so please give me a break while I settle, in. I have been using DAZ for about a year and I am totally addicted. Well, I love doing beta testing and I am aware of the risks I take. I am well versed in the file system and have had to uninstall and install many times. So this brings me to my question. I installed the public beta the other day and it, I thought, was working fine. Well, it seems the PostgreSQL Valentia conversion cannot be read and get this error and then the programs go back to the downloadable folder. The Dim will not install anything, but my manifest file is intact. I removed all "system" files with dim and tried the reinstall and still got the error. I might just Nuke it and start over. I am going to give that content wizard a whirl and start fresh. But if there is a simple fix let me know. Thanks again, and I will do my best to keep up.

    Jay

    Why are you trying to install the Valentina conversion? Valentina hasn't been used for some time now.

  • mindsongmindsong Posts: 1,693
    Richard Haseltine said:
    mindsong said:

    so it can be assumed that entering no name at the 'enter name' pop-up dialog does 'the right thing'? (not at a DS computer)

    (i have many a 'named' workspace using this, but simply want a basic 'save current', as occurs with a normal DS shutdown)

    this may qualify for 'tip of the day' award

    tnx

    No, you have to give it a name if you want to keep it. DS loads the previous session layout on load, and saves on exit unless told otherwise by the command line switches - even if there was an option to "save session layout now" it would still be overwritten on exit, or potentially damaged on a failed exit (e.g. crash or forced exit) so the situations in which it was useful would be limited to the occasions on which DS exited without touching the session files, and on which you wanted to recover the chnaged layout (but didn't want to save it as a named layout).

    tnx for the detailed response.

    so the request stands - while using DS and before running any action that is likely to crash DS, can we do something to save the current *default* environment settings (as is, unnamed), so if DS does crash, that the next load will honor the current state of the environment?

    As mentioned, I can and do save named settings (f4), but way-too-often assume that DS won't crash, and don't think to exit DS just to save the current default load settings until I realize the damage is done.

    Am I missing something, or is the 'save default settings now' suggestion meaningful?

  • Richard HaseltineRichard Haseltine Posts: 96,696
    mindsong said:
    Richard Haseltine said:
    mindsong said:

    so it can be assumed that entering no name at the 'enter name' pop-up dialog does 'the right thing'? (not at a DS computer)

    (i have many a 'named' workspace using this, but simply want a basic 'save current', as occurs with a normal DS shutdown)

    this may qualify for 'tip of the day' award

    tnx

    No, you have to give it a name if you want to keep it. DS loads the previous session layout on load, and saves on exit unless told otherwise by the command line switches - even if there was an option to "save session layout now" it would still be overwritten on exit, or potentially damaged on a failed exit (e.g. crash or forced exit) so the situations in which it was useful would be limited to the occasions on which DS exited without touching the session files, and on which you wanted to recover the chnaged layout (but didn't want to save it as a named layout).

    tnx for the detailed response.

    so the request stands - while using DS and before running any action that is likely to crash DS, can we do something to save the current *default* environment settings (as is, unnamed), so if DS does crash, that the next load will honor the current state of the environment?

    As mentioned, I can and do save named settings (f4), but way-too-often assume that DS won't crash, and don't think to exit DS just to save the current default load settings until I realize the damage is done.

    Am I missing something, or is the 'save default settings now' suggestion meaningful?

    You can certainly make a feature request, I'm just not sure how likely it would be to get picked up.

  • StormyrainStormyrain Posts: 10

    Hi,

    I was having an issue where Daz was suddenly crashing immediately upon start up. I spoke with Tech Support and Amy walked me through a fix that required me to delete "dzdynamics.dll" which worked. However, now Dforce is not usable which is a pretty big issue. Amy said it was a known issue and that I should watch the forums for updates, I'm just not sure WHICH topic to watch? I have to say this is a pretty big deal and I'm anxious for a fix to be rolled out..

    (The error was this one: DAZStudio.exe caused INT_DIVIDE_BY_ZERO in module "C:\WINDOWS\System32\DriverStore\FileRepository\igdlh64.inf_amd64_bdd37d808cfdf045\igdrcl64.dll" at 0033:00000000C46AFB99, GTPin_Init()+1057113 byte(s)")

    Thank you!

  • DoctorJellybeanDoctorJellybean Posts: 7,889
    Stormyrain said:

    Hi,

    I was having an issue where Daz was suddenly crashing immediately upon start up. I spoke with Tech Support and Amy walked me through a fix that required me to delete "dzdynamics.dll" which worked. However, now Dforce is not usable which is a pretty big issue. Amy said it was a known issue and that I should watch the forums for updates, I'm just not sure WHICH topic to watch? I have to say this is a pretty big deal and I'm anxious for a fix to be rolled out..

    (The error was this one: DAZStudio.exe caused INT_DIVIDE_BY_ZERO in module "C:\WINDOWS\System32\DriverStore\FileRepository\igdlh64.inf_amd64_bdd37d808cfdf045\igdrcl64.dll" at 0033:00000000C46AFB99, GTPin_Init()+1057113 byte(s)")

    Thank you!

    What video card and drivers do you have? And did the drivers have an update?

  • StormyrainStormyrain Posts: 10
    DoctorJellybean said:
    Stormyrain said:

    Hi,

    I was having an issue where Daz was suddenly crashing immediately upon start up. I spoke with Tech Support and Amy walked me through a fix that required me to delete "dzdynamics.dll" which worked. However, now Dforce is not usable which is a pretty big issue. Amy said it was a known issue and that I should watch the forums for updates, I'm just not sure WHICH topic to watch? I have to say this is a pretty big deal and I'm anxious for a fix to be rolled out..

    (The error was this one: DAZStudio.exe caused INT_DIVIDE_BY_ZERO in module "C:\WINDOWS\System32\DriverStore\FileRepository\igdlh64.inf_amd64_bdd37d808cfdf045\igdrcl64.dll" at 0033:00000000C46AFB99, GTPin_Init()+1057113 byte(s)")

    Thank you!

    What video card and drivers do you have? And did the drivers have an update?

    According to Tech Support my drivers are not an issue; but this is a known problem. From Tech Support "The dzdynamics plugin is for dForce.  This causing crashing is a known issue, and our developers are currently working on resolving this.  In the meantime, you will not be able to use dForce."


    I have an Nvidia Gforce GTX 1060. No updates since 9/30. Daz and Dforce worked fine after that update.

    Thank you!

  • DoctorJellybeanDoctorJellybean Posts: 7,889
    edited November 2020
    Stormyrain said:
    DoctorJellybean said:
    Stormyrain said:

    Hi,

    I was having an issue where Daz was suddenly crashing immediately upon start up. I spoke with Tech Support and Amy walked me through a fix that required me to delete "dzdynamics.dll" which worked. However, now Dforce is not usable which is a pretty big issue. Amy said it was a known issue and that I should watch the forums for updates, I'm just not sure WHICH topic to watch? I have to say this is a pretty big deal and I'm anxious for a fix to be rolled out..

    (The error was this one: DAZStudio.exe caused INT_DIVIDE_BY_ZERO in module "C:\WINDOWS\System32\DriverStore\FileRepository\igdlh64.inf_amd64_bdd37d808cfdf045\igdrcl64.dll" at 0033:00000000C46AFB99, GTPin_Init()+1057113 byte(s)")

    Thank you!

    What video card and drivers do you have? And did the drivers have an update?

    According to Tech Support my drivers are not an issue; but this is a known problem. From Tech Support "The dzdynamics plugin is for dForce.  This causing crashing is a known issue, and our developers are currently working on resolving this.  In the meantime, you will not be able to use dForce."


    I have an Nvidia Gforce GTX 1060. No updates since 9/30. Daz and Dforce worked fine after that update.

    Thank you!

    Which version are your drivers? Thank you.

    Post edited by DoctorJellybean on
  • StormyrainStormyrain Posts: 10
    DoctorJellybean said:

    Which version are your drivers? Thank you.

    26.21.14.3650

     

  • jbowlerjbowler Posts: 742
    Richard Haseltine said:

    I'm going to post this straight:

    Obviously we cannot see what is happening within the Octane plugin code, only what is happening around it when attached to the debugger.
    --
    There is a task/runnable that the Octane plugin is starting in the global thread pool that is not completing. Since Daz Studio (4.12+) is waiting for threads in the global thread pool to cleanup before it closes (to prevent crashes and/or potential data loss during shutdown), the application is not closing until cleanup of the global thread pool times out. This used to default to a very long time (i.e. many hours), but a pending release reduces this to 3 minutes max. This wait occurs after plugins are shut down [virtual void DzPlugin::shutdown()], but before the pane is deleted or the plugin is unloaded.
    --
    If this is a task/runnable that is truly intended to run for the duration of the plugin's lifetime, it should not use the global thread pool, rather it should use its own QThread instance.
    --
    Note, use of API such as QtConcurrent make use of the global thread pool.

    So far as I know I'm not using Octane but the identical problem started happening for me in 4.12.2.51, see bug #349543.  My limited investigation with VS definitely suggested to me a Qt main loop which was not exiting (I've done a moderate amount of Qt app programming) and, yes, Daz did not exit after at least 12 hours.

    Can you reveal what version the global thread queue wait was introduced in and what version the 3 minute tlmeout was introduced in?  I'm prepared to wait 3 minutes, but not 3 days and I would rather not have to keep killing the thing.

    I have added products to my Daz installation that might be causing the problem; this is why I want to know the version at which the wait was introduced, then I might be able to track the problem to a specific product.  I do know that the 4.12 general release doesn't have this problem; it exits fine whereas the beta does not, ever.

    My personal experience with Qt is that I wouldn't ever use anything global.  I always use QThread and it isn't that hard and it is good programming practice to never use anything global, even inside libraries like Qt...  Maybe in a future version (6.0?) they could remove all of that stuff :-)

  • ChoholeChohole Posts: 33,604

    http://docs.daz3d.com/doku.php/public/software/dazstudio/4/change_log_4_14_0_8#4_14_0_4

     

Sign In or Register to comment.