Loading...
> >

Does 4.12.1.16 allow multiple instances of Studio?

12467…10

Comments

  • TheKDTheKD Posts: 2,696
    lancelmartin_cf51987037 said:

    The primary reason I use two instances is to render in one and pose in the other.  If a render is going to take 30 minutes or so, a separate instance can be scaled down (remove all the unneccessary scene items and shaders), get the figures posed, and then saved as pose presets to be loaded into the original scene for the next render

    Not being able to open more than one instance would obviously wreck that workflow

    Yeah I end up using a second instance to get the next render ready to go while the first render cooks a lot too.

  • Catherine3678abCatherine3678ab Posts: 8,384
    edited October 2019

      .. 

     

    Post edited by Catherine3678ab on
  • Sven DullahSven Dullah Posts: 7,621
    sylvie1998 said:

    The problem (if it even exists) of another instance deleting temp files can be solved by creating a subfolder in temp with procesa id as its name so that each inst.ance gets its own subfolder in temp.

     So what does this mean in English, please? Procesa id?

  • RayDAntRayDAnt Posts: 1,144
    edited October 2019
    Sven Dullah said:
    sylvie1998 said:

    The problem (if it even exists) of another instance deleting temp files can be solved by creating a subfolder in temp with procesa id as its name so that each inst.ance gets its own subfolder in temp.

     So what does this mean in English, please? Procesa id?

    Process ID is a unique number every instance of every program on your computer (including background ones you never see) gets assigned at its launch so that the operating system can keep track of it. The idea being that using a program instance's ID number to determine what folder its temp files go to equals no file read/write conflicts during operation.

    If you want to see them in action, Open up Task Manager and click the Details tab. You should see a column of numbers called PID, which is short for "Process ID".

    Post edited by RayDAnt on
  • Sven DullahSven Dullah Posts: 7,621
    edited October 2019
    RayDAnt said:
    Sven Dullah said:
    sylvie1998 said:

    The problem (if it even exists) of another instance deleting temp files can be solved by creating a subfolder in temp with procesa id as its name so that each inst.ance gets its own subfolder in temp.

     So what does this mean in English, please? Procesa id?

    Process ID is a unique number every instance of every program on your computer (including background ones you never see) gets assigned at its launch so that the operating system can keep track of it. The idea being that using a program instance's ID number to determine what folder its temp files go to equals no file read/write conflicts during operation.

    If you want to see them in action, Open up Task Manager and click the Details tab. You should see a column of numbers called PID, which is short for "Process ID".

    Tks! I'm on Mac so have to do some research;) I've used DS 4.9 alongside 4.10 public beta for a long time with no issues whatsoever. But now, fo a number of reasons, I had to install 4.7 and just noticed launching 4.9 when 4.7 is running empties the tempfolder, forcing 4.7 to re-analyze all the maps etc. (and generally causing some confusion). So it would be nice to find a workaround...

    Post edited by Sven Dullah on
  • RayDAntRayDAnt Posts: 1,144
    Sven Dullah said:
    RayDAnt said:
    Sven Dullah said:
    sylvie1998 said:

    The problem (if it even exists) of another instance deleting temp files can be solved by creating a subfolder in temp with procesa id as its name so that each inst.ance gets its own subfolder in temp.

     So what does this mean in English, please? Procesa id?

    Process ID is a unique number every instance of every program on your computer (including background ones you never see) gets assigned at its launch so that the operating system can keep track of it. The idea being that using a program instance's ID number to determine what folder its temp files go to equals no file read/write conflicts during operation.

    If you want to see them in action, Open up Task Manager and click the Details tab. You should see a column of numbers called PID, which is short for "Process ID".

    Tks! I'm on Mac so have to do some research;)

    If you fire up Activity Monitor you'll see exactly the same thing (a column called PID) as a Windows user sees with Task Manager.

     

    Sven Dullah said:

    I've used DS 4.9 alongside 4.10 public beta for a long time with no issues whatsoever. But now, fo a number of reasons, I had to install 4.7 and just noticed launching 4.9 when 4.7 is running empties the tempfolder, forcing 4.7 to re-analyze all the maps etc. (and generally causing some confusion). So it would be nice to find a workaround...

    Not surprised to hear it. Daz Studio has never really had a proper mechanism for handling multi-instancing until now.

  • Sven DullahSven Dullah Posts: 7,621
    RayDAnt said:
    Sven Dullah said:
    RayDAnt said:
    Sven Dullah said:
    sylvie1998 said:

    The problem (if it even exists) of another instance deleting temp files can be solved by creating a subfolder in temp with procesa id as its name so that each inst.ance gets its own subfolder in temp.

     So what does this mean in English, please? Procesa id?

    Process ID is a unique number every instance of every program on your computer (including background ones you never see) gets assigned at its launch so that the operating system can keep track of it. The idea being that using a program instance's ID number to determine what folder its temp files go to equals no file read/write conflicts during operation.

    If you want to see them in action, Open up Task Manager and click the Details tab. You should see a column of numbers called PID, which is short for "Process ID".

    Tks! I'm on Mac so have to do some research;)

    If you fire up Activity Monitor you'll see exactly the same thing (a column called PID) as a Windows user sees with Task Manager.

     

    Sven Dullah said:

    I've used DS 4.9 alongside 4.10 public beta for a long time with no issues whatsoever. But now, fo a number of reasons, I had to install 4.7 and just noticed launching 4.9 when 4.7 is running empties the tempfolder, forcing 4.7 to re-analyze all the maps etc. (and generally causing some confusion). So it would be nice to find a workaround...

    Not surprised to hear it. Daz Studio has never really had a proper mechanism for handling multi-instancing until now.

    I'll look into ityes

  • MendomanMendoman Posts: 404

    Like many others, I use one instance for posing and another for rendering, so please Daz, consider this change before pushing it through.

  • Richard HaseltineRichard Haseltine Posts: 102,308
    Mendoman said:

    Like many others, I use one instance for posing and another for rendering, so please Daz, consider this change before pushing it through.

    It appears from the change log that Daz has already considered, and implemented, a solution for this - as it stands (and we don't know if this is the final state) you would need to create a short cut/alias to launch a second instance of DS with a different name, which would run happily alongside the default instance.

  • Hurdy3DHurdy3D Posts: 1,057
    Richard Haseltine said:
    Mendoman said:

    Like many others, I use one instance for posing and another for rendering, so please Daz, consider this change before pushing it through.

    It appears from the change log that Daz has already considered, and implemented, a solution for this - as it stands (and we don't know if this is the final state) you would need to create a short cut/alias to launch a second instance of DS with a different name, which would run happily alongside the default instance.

    which would be not a satified solution.

    lets hope that this just a step between...

  • ZaiZai Posts: 289

    Oh, thank goodness! LOL

    I already have to launch the other sessions using terminal on my Mac but I wonder if an alias might work. Either way GREAT news. Thanks, Daz!

  • RayDAntRayDAnt Posts: 1,144
    edited October 2019
    gerster said:
    Richard Haseltine said:
    Mendoman said:

    Like many others, I use one instance for posing and another for rendering, so please Daz, consider this change before pushing it through.

    It appears from the change log that Daz has already considered, and implemented, a solution for this - as it stands (and we don't know if this is the final state) you would need to create a short cut/alias to launch a second instance of DS with a different name, which would run happily alongside the default instance.

    which would be not a satified solution.

    lets hope that this just a step between...

    There's also room in what's currently published in the build log for this to be an entirely automated process. Whereby attempting to launch a second instance of Daz Studio while a first is already fully loaded and running results in an instance with "2" next to its name. And launching a third, "3" - all the way up to however many you want/your machine can handle.

    Post edited by RayDAnt on
  • MendomanMendoman Posts: 404
    Richard Haseltine said:
    Mendoman said:

    Like many others, I use one instance for posing and another for rendering, so please Daz, consider this change before pushing it through.

    It appears from the change log that Daz has already considered, and implemented, a solution for this - as it stands (and we don't know if this is the final state) you would need to create a short cut/alias to launch a second instance of DS with a different name, which would run happily alongside the default instance.

    Oh, that is a good news indeed. Can't speak for others of course, but I suppose that's enough for my workflow.

  • Hurdy3DHurdy3D Posts: 1,057

    The latest upate looks promising:

    • Added support for “-copyAppSettings” CLI option; the token/arg immediately following the option is used as the name of the release cycle (and optionally the instance) to copy AppSettings from; the token/arg must be quoted if it contains a space character; the token/arg must match the suffix of the AppSettings group name for an instance that has been launched at least once (i.e., releaseCycle[instanceName]) - return value of DzApp::releaseCycleSuffixStripped() or DzApp::releaseCycleInstanceSuffixStripped()); all spaces in the token/arg are automatically stripped in order to match the pattern used in the AppSettings group name; a single “~” (tilde) character is interpreted as the root instance of the General Release; a single “.” (period) character is interpreted as the root instance of the 'current' release cycle; a non-existent instance name or a single unsupported character effectively disables the option (as a match will not be found); all pertinent AppSettings are copied

    • Added support for “-copySessionUI” CLI option; the token/arg immediately following the option is used as the name of the release cycle (and optionally the instance) to copy the session UI files from; the token/arg must be quoted if it contains a space character (any besides the General Release will); the token/arg must match the suffix of the application data folder name for an instance that has been launched at least once (i.e., release cycle [instanceName]) - return value of DzApp::releaseCycleSuffix() optionally appending DzApp::instanceNameSuffix()); a single “~” (tilde) character is interpreted as the root instance of the General Release; a single “.” (period) character is interpreted as the root instance of the 'current' release cycle; a non-existent instance name or a single unsupported character effectively disables the option (as a match will not be found); all session UI files are copied

    • Launching a named instance of a given release cycle (using the -instanceName name CLI option) now automatically copies the AppSettings for the root instance of that release cycle on first launch unless the -copyAppSettings CLI option is also specified

    • Launching a named instance of a given release cycle (using the -instanceName name CLI option) now automatically copies the session UI for the root instance of that release cycle on first launch unless the -copySessionUI CLI option is also specified

    Now there's only an option missing which generates a new instance automatically with a random name, if you start the application.

  • Richard HaseltineRichard Haseltine Posts: 102,308
    gerster said:

    The latest upate looks promising:

    • Added support for “-copyAppSettings” CLI option; the token/arg immediately following the option is used as the name of the release cycle (and optionally the instance) to copy AppSettings from; the token/arg must be quoted if it contains a space character; the token/arg must match the suffix of the AppSettings group name for an instance that has been launched at least once (i.e., releaseCycle[instanceName]) - return value of DzApp::releaseCycleSuffixStripped() or DzApp::releaseCycleInstanceSuffixStripped()); all spaces in the token/arg are automatically stripped in order to match the pattern used in the AppSettings group name; a single “~” (tilde) character is interpreted as the root instance of the General Release; a single “.” (period) character is interpreted as the root instance of the 'current' release cycle; a non-existent instance name or a single unsupported character effectively disables the option (as a match will not be found); all pertinent AppSettings are copied

    • Added support for “-copySessionUI” CLI option; the token/arg immediately following the option is used as the name of the release cycle (and optionally the instance) to copy the session UI files from; the token/arg must be quoted if it contains a space character (any besides the General Release will); the token/arg must match the suffix of the application data folder name for an instance that has been launched at least once (i.e., release cycle [instanceName]) - return value of DzApp::releaseCycleSuffix() optionally appending DzApp::instanceNameSuffix()); a single “~” (tilde) character is interpreted as the root instance of the General Release; a single “.” (period) character is interpreted as the root instance of the 'current' release cycle; a non-existent instance name or a single unsupported character effectively disables the option (as a match will not be found); all session UI files are copied

    • Launching a named instance of a given release cycle (using the -instanceName name CLI option) now automatically copies the AppSettings for the root instance of that release cycle on first launch unless the -copyAppSettings CLI option is also specified

    • Launching a named instance of a given release cycle (using the -instanceName name CLI option) now automatically copies the session UI for the root instance of that release cycle on first launch unless the -copySessionUI CLI option is also specified

    Now there's only an option missing which generates a new instance automatically with a random name, if you start the application.

    What are you expecting that to achieve? It would have to be a random name not yet used, but then what happens if it crahses out or is otherwise terminated without a proper exit and leaves its folders behind - potentially, on a system with stability issues, there would be an ever-incrasing stack of unused instance folders. And of course if it was on-the-fly random it would lose configuration settinsg that you might want to keep. The current system seems designed to allow the user to keep track of what instances exist, and to reuse them as desired, without the risk of proliferating detritus.

  • Hurdy3DHurdy3D Posts: 1,057
    edited October 2019
    Richard Haseltine said:
    gerster said:

    The latest upate looks promising:

    • Added support for “-copyAppSettings” CLI option; the token/arg immediately following the option is used as the name of the release cycle (and optionally the instance) to copy AppSettings from; the token/arg must be quoted if it contains a space character; the token/arg must match the suffix of the AppSettings group name for an instance that has been launched at least once (i.e., releaseCycle[instanceName]) - return value of DzApp::releaseCycleSuffixStripped() or DzApp::releaseCycleInstanceSuffixStripped()); all spaces in the token/arg are automatically stripped in order to match the pattern used in the AppSettings group name; a single “~” (tilde) character is interpreted as the root instance of the General Release; a single “.” (period) character is interpreted as the root instance of the 'current' release cycle; a non-existent instance name or a single unsupported character effectively disables the option (as a match will not be found); all pertinent AppSettings are copied

    • Added support for “-copySessionUI” CLI option; the token/arg immediately following the option is used as the name of the release cycle (and optionally the instance) to copy the session UI files from; the token/arg must be quoted if it contains a space character (any besides the General Release will); the token/arg must match the suffix of the application data folder name for an instance that has been launched at least once (i.e., release cycle [instanceName]) - return value of DzApp::releaseCycleSuffix() optionally appending DzApp::instanceNameSuffix()); a single “~” (tilde) character is interpreted as the root instance of the General Release; a single “.” (period) character is interpreted as the root instance of the 'current' release cycle; a non-existent instance name or a single unsupported character effectively disables the option (as a match will not be found); all session UI files are copied

    • Launching a named instance of a given release cycle (using the -instanceName name CLI option) now automatically copies the AppSettings for the root instance of that release cycle on first launch unless the -copyAppSettings CLI option is also specified

    • Launching a named instance of a given release cycle (using the -instanceName name CLI option) now automatically copies the session UI for the root instance of that release cycle on first launch unless the -copySessionUI CLI option is also specified

    Now there's only an option missing which generates a new instance automatically with a random name, if you start the application.

    What are you expecting that to achieve? It would have to be a random name not yet used, but then what happens if it crahses out or is otherwise terminated without a proper exit and leaves its folders behind - potentially, on a system with stability issues, there would be an ever-incrasing stack of unused instance folders. And of course if it was on-the-fly random it would lose configuration settinsg that you might want to keep. The current system seems designed to allow the user to keep track of what instances exist, and to reuse them as desired, without the risk of proliferating detritus.

    Maybe not a random name, but at least an automatic generated.

    What I want to achive?

    I don't want to create 10 DAZ desktop symbols which starts each an own instance.

    I want to use one single DAZ symbol. If I click on it and the main instance is running, a new instance should be automatically generated. If the instance name is random or following a pattern does not matter to me.

    Ok, I see the point that a random name is a bad idea, after the instance files are not deleted after closing the instance.

    Than let's use a pattern.

    So, there should be an option in DAZ called "allow multiple instances". If this flag is true, the DAZ app checks if the main instance is currently running.
    If this is the case DAZ starts automatically a new instance, with the name "auto-instance-{number} ".
    Number is a varialble 0 up to infinitely.


    The first time DAZ creates auto-instance-1, then auto-instance-2 and after that auto-instance-3.
    Then that I close auto-instance-1 instance of DAZ.
     I start again DAZ and auto-instance-1 is reused, after it's the "lowest" unused automatic generated instances, while 2 and 3 are still open.

    This behavoir would be more or less the same behavoir from the enduser POV as it was pre 4.12.1 ;)

    Post edited by Hurdy3D on
  • IvyIvy Posts: 7,165
    edited October 2019

    The versions of daz I have now 4.5 up to 4.12.0.35  can all be loaded as multi instances with no issue of daz.  so until DEV team get the development done and give us a option so we can once again use more than 1 instance of daz at a time i am not upgrading my daz studio.   I suggest other user that need this multi instance function also hold off on getting daz 4.12.1.16  the improvements to me were not so noticeably great that it would make any difference on upgrading from 4.12.0.35,  which so far other than the optix prime being disabled errors, has not given me any trouble using it for my needs.  I did install and try 4.12.1.16 , So that is why I say the improvements are not all that noticeable or worth the upgrade to be limited to one instance of studio.  So I uninstalled 4.12.1.16 and did a clean reinstalled 4.12.0.35  and I still have other daz's like daz4.11 and 4.10 installed as well so I am good to go

    that is my 2 cents

    Post edited by Ivy on
  • Hurdy3DHurdy3D Posts: 1,057
    Ivy said:

    The versions of daz I have now 4.5 up to 4.12.0.35  can all be loaded as multi instances with no issue of daz.  so until DEV team get the development done and give us a option so we can once again use more than 1 instance of daz at a time i am not upgrading my daz studio.   I suggest other user that need this multi instance function also hold off on getting daz 4.12.1.16  the improvements to me were not so noticeably great that it would make any difference on upgrading from 4.12.0.35,  which so far other than the optix prime being disabled errors, has not given me any trouble using it for my needs.  I did install and try 4.12.1.16 , So that is why I say the improvements are not all that noticeable or worth the upgrade to be limited to one instance of studio.  So I uninstalled 4.12.1.16 and did a clean reinstalled 4.12.0.35  and I still have other daz's like daz4.11 and 4.10 installed as well so I am good to go

    that is my 2 cents

    With the latest private beta it's possible (according to the changelog) to create as many instances as you like. But you have to open each instance with an special cli argument containing a unique instance name.

    That means that you have to create 5 Daz desktop symbols if you want to work with 5 instances.

    I hope they add an option that these named instances will be created automatically, than the behavoir would be more or less like in 4.12.0

  • Richard HaseltineRichard Haseltine Posts: 102,308
    gerster said:
    Richard Haseltine said:
    gerster said:

    The latest upate looks promising:

    • Added support for “-copyAppSettings” CLI option; the token/arg immediately following the option is used as the name of the release cycle (and optionally the instance) to copy AppSettings from; the token/arg must be quoted if it contains a space character; the token/arg must match the suffix of the AppSettings group name for an instance that has been launched at least once (i.e., releaseCycle[instanceName]) - return value of DzApp::releaseCycleSuffixStripped() or DzApp::releaseCycleInstanceSuffixStripped()); all spaces in the token/arg are automatically stripped in order to match the pattern used in the AppSettings group name; a single “~” (tilde) character is interpreted as the root instance of the General Release; a single “.” (period) character is interpreted as the root instance of the 'current' release cycle; a non-existent instance name or a single unsupported character effectively disables the option (as a match will not be found); all pertinent AppSettings are copied

    • Added support for “-copySessionUI” CLI option; the token/arg immediately following the option is used as the name of the release cycle (and optionally the instance) to copy the session UI files from; the token/arg must be quoted if it contains a space character (any besides the General Release will); the token/arg must match the suffix of the application data folder name for an instance that has been launched at least once (i.e., release cycle [instanceName]) - return value of DzApp::releaseCycleSuffix() optionally appending DzApp::instanceNameSuffix()); a single “~” (tilde) character is interpreted as the root instance of the General Release; a single “.” (period) character is interpreted as the root instance of the 'current' release cycle; a non-existent instance name or a single unsupported character effectively disables the option (as a match will not be found); all session UI files are copied

    • Launching a named instance of a given release cycle (using the -instanceName name CLI option) now automatically copies the AppSettings for the root instance of that release cycle on first launch unless the -copyAppSettings CLI option is also specified

    • Launching a named instance of a given release cycle (using the -instanceName name CLI option) now automatically copies the session UI for the root instance of that release cycle on first launch unless the -copySessionUI CLI option is also specified

    Now there's only an option missing which generates a new instance automatically with a random name, if you start the application.

    What are you expecting that to achieve? It would have to be a random name not yet used, but then what happens if it crahses out or is otherwise terminated without a proper exit and leaves its folders behind - potentially, on a system with stability issues, there would be an ever-incrasing stack of unused instance folders. And of course if it was on-the-fly random it would lose configuration settinsg that you might want to keep. The current system seems designed to allow the user to keep track of what instances exist, and to reuse them as desired, without the risk of proliferating detritus.

    Maybe not a random name, but at least an automatic generated.

    What I want to achive?

    I don't want to create 10 DAZ desktop symbols which starts each an own instance.

    I want to use one single DAZ symbol. If I click on it and the main instance is running, a new instance should be automatically generated. If the instance name is random or following a pattern does not matter to me.

    Ok, I see the point that a random name is a bad idea, after the instance files are not deleted after closing the instance.

    Than let's use a pattern.

    So, there should be an option in DAZ called "allow multiple instances". If this flag is true, the DAZ app checks if the main instance is currently running.
    If this is the case DAZ starts automatically a new instance, with the name "auto-instance-{number} ".
    Number is a varialble 0 up to infinitely.


    The first time DAZ creates auto-instance-1, then auto-instance-2 and after that auto-instance-3.
    Then that I close auto-instance-1 instance of DAZ.
     I start again DAZ and auto-instance-1 is reused, after it's the "lowest" unused automatic generated instances, while 2 and 3 are still open.

    This behavoir would be more or less the same behavoir from the enduser POV as it was pre 4.12.1 ;)

    That still has the same potential pitfalls.

    I imagine once we have this it will be possible to have DS generate a set of shortcuts, using defined names, and even have a running version act as a launcher for them (it has script calls for launching another process - used, for example, by the scripts for opening a web page or showing a read me) - I think if it tried launching a running instance that would just bring the instance forward. Whether someone could then write a launched utility for the desktop that would allow you to pick from the list, and if they could whether it could show which versions were running already - and switch to them - and which were idle I don't know as I've not tried writing any stand-alone scripts or apps for a very, very long time.

  • Hurdy3DHurdy3D Posts: 1,057

    The only pitfall I saw was the random instance names leaves unused daz folders on the system.

    But this issue is more or less fixed with a name schema.

    I'm suggesting not to replace the cli arguments with my suggestion.

    The idea is to give addtional the option to create automatically named instaces, if nesscery.

    If you want the option to create spefific instaces with the cli argument you still can do.

    If you opti-in create them automatically DS would just execute a new DS instance with the cli parameter for a new instance with an automatic generated instance name, following a naming schema. Should be hopefully not to hard to implement.

    . And of course if it was on-the-fly random it would lose configuration settinsg that you might want to keep.

    I don't get his. Accorinding to the latest closed channel change logs, DS would copy per default all settings from the default/main instance. Which is a very good thing to keep the instances in sync. So where you you loose a configuration?

  • Catherine3678abCatherine3678ab Posts: 8,384
    edited October 2019

     .. 

    Post edited by Catherine3678ab on
  • IvyIvy Posts: 7,165
    gerster said:
    Ivy said:

    The versions of daz I have now 4.5 up to 4.12.0.35  can all be loaded as multi instances with no issue of daz.  so until DEV team get the development done and give us a option so we can once again use more than 1 instance of daz at a time i am not upgrading my daz studio.   I suggest other user that need this multi instance function also hold off on getting daz 4.12.1.16  the improvements to me were not so noticeably great that it would make any difference on upgrading from 4.12.0.35,  which so far other than the optix prime being disabled errors, has not given me any trouble using it for my needs.  I did install and try 4.12.1.16 , So that is why I say the improvements are not all that noticeable or worth the upgrade to be limited to one instance of studio.  So I uninstalled 4.12.1.16 and did a clean reinstalled 4.12.0.35  and I still have other daz's like daz4.11 and 4.10 installed as well so I am good to go

    that is my 2 cents

    With the latest private beta it's possible (according to the changelog) to create as many instances as you like. But you have to open each instance with an special cli argument containing a unique instance name.

    That means that you have to create 5 Daz desktop symbols if you want to work with 5 instances.

    I hope they add an option that these named instances will be created automatically, than the behavoir would be more or less like in 4.12.0

    I've been following the change log.  and I am glad to see they are working on a solution.  its to bad they broke it in the first place. so I'll still wait a while for the bugs to be worked out

  • Richard HaseltineRichard Haseltine Posts: 102,308
    gerster said:

    The only pitfall I saw was the random instance names leaves unused daz folders on the system.

    But this issue is more or less fixed with a name schema.

    I'm suggesting not to replace the cli arguments with my suggestion.

    The idea is to give addtional the option to create automatically named instaces, if nesscery.

    If you want the option to create spefific instaces with the cli argument you still can do.

    If you opti-in create them automatically DS would just execute a new DS instance with the cli parameter for a new instance with an automatic generated instance name, following a naming schema. Should be hopefully not to hard to implement.

    . And of course if it was on-the-fly random it would lose configuration settinsg that you might want to keep.

    I don't get his. Accorinding to the latest closed channel change logs, DS would copy per default all settings from the default/main instance. Which is a very good thing to keep the instances in sync. So where you you loose a configuration?

    I meant changes made in the auto-named instance - unless the shortcut of a deliberately named instance was edited to copy them.

    Ivy said:
    gerster said:
    Ivy said:

    The versions of daz I have now 4.5 up to 4.12.0.35  can all be loaded as multi instances with no issue of daz.  so until DEV team get the development done and give us a option so we can once again use more than 1 instance of daz at a time i am not upgrading my daz studio.   I suggest other user that need this multi instance function also hold off on getting daz 4.12.1.16  the improvements to me were not so noticeably great that it would make any difference on upgrading from 4.12.0.35,  which so far other than the optix prime being disabled errors, has not given me any trouble using it for my needs.  I did install and try 4.12.1.16 , So that is why I say the improvements are not all that noticeable or worth the upgrade to be limited to one instance of studio.  So I uninstalled 4.12.1.16 and did a clean reinstalled 4.12.0.35  and I still have other daz's like daz4.11 and 4.10 installed as well so I am good to go

    that is my 2 cents

    With the latest private beta it's possible (according to the changelog) to create as many instances as you like. But you have to open each instance with an special cli argument containing a unique instance name.

    That means that you have to create 5 Daz desktop symbols if you want to work with 5 instances.

    I hope they add an option that these named instances will be created automatically, than the behavoir would be more or less like in 4.12.0

    I've been following the change log.  and I am glad to see they are working on a solution.  its to bad they broke it in the first place. so I'll still wait a while for the bugs to be worked out

    It is, as far as Daz is concerned, fixing something that was broken - as witness the support calls from people for whom running two instances has caused issues. People who post to these threads probably are not representative of those users. The work being done will allow people who want multiple instances to have them, while protecting others from accidentally damaging things. (Of course, some of us are going to have to learn not to keep typing isntance first.)

  • HavosHavos Posts: 5,392

    Running multiple instances did cause me issues, particularly when using LIE shaders. I would notice characters faces going completely white as their temp LIE pngs where deleted by a second instance. It will be good that this new solution fixes this.

    i can’t speak for others, but the proposed solution is acceptable to me.

  • IvyIvy Posts: 7,165
    edited November 2019

    in my opinion  I believe the the issue people have with DS and the Dev team tries to accommodate for everyone usages . But the fact is every user has a different computer and directory set ups and not all PC and directories are created equal .some people have very robust machines other don't some of use have many external hard drive some of us don;t etc.   Since the day I started with DS I could always run 3 or 4 copies of studio all at the same time I have done this for years . its one of the reasons for accomplishing animation with DS and necessary for my animation work flow.  Then all of a sudden I can no longer run more than one copy of studio at a time.  That means it was broke to fix a problem some people were having but on the other hand many many other were not and were like me using multi open copies of ds

    Truly I do believe  the biggest problem lies that every DS user has a different computer & content drive set up set. &  not all users have the same hardware and OS ,   Example My dual cpu system is different from your's single cpu unit in hardware set up and I am positive my content directories are not set up like yours. t hose differences are why some folks can run more than 1 instances while others can't  , you see my point. not everyone system is the same But Daz Dev has now put a block in to stop all users from loading more than one copy of ds at a time to help a few users that can't run more than one copy seems like throwing the baby out with the bathwater.

     

    Post edited by Ivy on
  • outrider42outrider42 Posts: 3,679

    This does bring up a question, how will instances work from the different bridges to Daz from software. Like mentioned if you use the Daz to Hexagon bridge and then go back to Daz it will go back that same instance. If you open Hexagon from its exe and then send to Daz it will always open a new instance. So how will this be handled in the future?

    I'd really like to see Daz offer the option of where the bridge goes, letting the user pick a current instance or open a new one.

     

    Richard Haseltine said:
    gerster said:

    The only pitfall I saw was the random instance names leaves unused daz folders on the system.

    But this issue is more or less fixed with a name schema.

    I'm suggesting not to replace the cli arguments with my suggestion.

    The idea is to give addtional the option to create automatically named instaces, if nesscery.

    If you want the option to create spefific instaces with the cli argument you still can do.

    If you opti-in create them automatically DS would just execute a new DS instance with the cli parameter for a new instance with an automatic generated instance name, following a naming schema. Should be hopefully not to hard to implement.

    . And of course if it was on-the-fly random it would lose configuration settinsg that you might want to keep.

    I don't get his. Accorinding to the latest closed channel change logs, DS would copy per default all settings from the default/main instance. Which is a very good thing to keep the instances in sync. So where you you loose a configuration?

    I meant changes made in the auto-named instance - unless the shortcut of a deliberately named instance was edited to copy them.

    Ivy said:
    gerster said:
    Ivy said:

    The versions of daz I have now 4.5 up to 4.12.0.35  can all be loaded as multi instances with no issue of daz.  so until DEV team get the development done and give us a option so we can once again use more than 1 instance of daz at a time i am not upgrading my daz studio.   I suggest other user that need this multi instance function also hold off on getting daz 4.12.1.16  the improvements to me were not so noticeably great that it would make any difference on upgrading from 4.12.0.35,  which so far other than the optix prime being disabled errors, has not given me any trouble using it for my needs.  I did install and try 4.12.1.16 , So that is why I say the improvements are not all that noticeable or worth the upgrade to be limited to one instance of studio.  So I uninstalled 4.12.1.16 and did a clean reinstalled 4.12.0.35  and I still have other daz's like daz4.11 and 4.10 installed as well so I am good to go

    that is my 2 cents

    With the latest private beta it's possible (according to the changelog) to create as many instances as you like. But you have to open each instance with an special cli argument containing a unique instance name.

    That means that you have to create 5 Daz desktop symbols if you want to work with 5 instances.

    I hope they add an option that these named instances will be created automatically, than the behavoir would be more or less like in 4.12.0

    I've been following the change log.  and I am glad to see they are working on a solution.  its to bad they broke it in the first place. so I'll still wait a while for the bugs to be worked out

    It is, as far as Daz is concerned, fixing something that was broken - as witness the support calls from people for whom running two instances has caused issues. People who post to these threads probably are not representative of those users. The work being done will allow people who want multiple instances to have them, while protecting others from accidentally damaging things. (Of course, some of us are going to have to learn not to keep typing isntance first.)

    Is that Daz's official statement on the issue? Because earlier you stated that was supposition, making this speculation as fact. You gotta play by the rules! Whether advertised or not Studio has had instances for what, 20 years? I rather think they could have waited a little longer. Removing instances entirely is not a fix, regardless of what the intention may have been. It would make sense to have this totally worked out before giving it to the public. It should have stayed in private builds.

    Forum users may or may not be a vocal minority, but I would be willing to bet they are probably the most dedicated customers, and more likely to spend more as a result.

  • RayDAntRayDAnt Posts: 1,144
    edited October 2019

    From the most recent update:

    Extended the “-instanceName” CLI option to support gap-filling automatic incrementation; a token/arg containing the “#” (number sign) character will automatically have occurrences of the “#” character replaced by the 'next' available incremental integer value (e.g., if instances 1, 2, and 3 are running, instance 2 is closed and a new instance is launched, the new instance will be assigned 2 and the next would be assigned 4 - unless 1, 2 or 3 were closed before it launched); copying of root release cycle AppSettings and session UI files is implied by the presence of a “#” character - use the -copyAppSettings and/or -copySessionUI CLI options respectively to override default behavior

     I love it when I'm right. laugh

    For those concerned about having to jump through obscure command-line hoops to get your multiple instances back once DS is updated, don't be. Based on these logs, launching multiple instances will be IDENTICAL from the user perspective to how it was before. Just without potential temp file conflicts.

    Now if only we could convince them to not arbitrarily lock down the entire Daz Studio interface any time an Iray render Context (not found in a viewport) is taking place...

    Post edited by RayDAnt on
  • JOdelJOdel Posts: 6,288

    Al I want to do is have more than one version of Studio installed on my machine, so that if something turns out to be broken in one of them, I can step back to a version where it isn't. I don't care how much RAM I've got, I'm not going to be running two versions of Studio at the same time.

    Case in point, which I stumbled over this morning and I went into in the relevant thread. On my iMac it turns out that the release version of 4.12.0.86 is broken and cannot recognize an .obj file to import it. Neither can 4.11.0.383. I had to step back to 4.10.0.123 befoe an .obj file wasn't greyed out in the directory list.

    I'm given to understand that this may be a Catalina thing, but I haven't upgraded to Catalina. I'm being bitten by it in Mojave. 

    I'll go and file a ticket if it will accept one without an order #, since this is the program, not a bit of purchased content.

  • nonesuch00nonesuch00 Posts: 18,288
    JOdel said:

    Al I want to do is have more than one version of Studio installed on my machine, so that if something turns out to be broken in one of them, I can step back to a version where it isn't. I don't care how much RAM I've got, I'm not going to be running two versions of Studio at the same time.

    Case in point, which I stumbled over this morning and I went into in the relevant thread. On my iMac it turns out that the release version of 4.12.0.86 is broken and cannot recognize an .obj file to import it. Neither can 4.11.0.383. I had to step back to 4.10.0.123 befoe an .obj file wasn't greyed out in the directory list.

    I'm given to understand that this may be a Catalina thing, but I haven't upgraded to Catalina. I'm being bitten by it in Mojave. 

    I'll go and file a ticket if it will accept one without an order #, since this is the program, not a bit of purchased content.

    Wow! Was that osX only? I recently exported & imported obj files from DAZ after adjusting with dFormers for fit to adjust clothing for 3DU Toon Mouse with a 4.12.x 64 bit public beta series on Windows 10 . I'm relieved now that I must of been lucky and got the one 4.12.x version that works.

  • GalaxyGalaxy Posts: 562

    While render in progress I don't consider to run anothe program either another Daz studio instances or something else. I don't do multitasking like this but I like to minimize lot of apps for quick access one after another. By the way this consideration does not apply for mini super computers some people have. 

Sign In or Register to comment.