I updated from 4.11 to 4.20 through DIM and now cannot launch a second instance of the program

handel_035c4ce6

Well, as the topic says - I updated from 4.11 to 4.20 (with Win 10) through DIM and now cannot launch a second instance of the program (can have only one launch of the program working).

Please advice how to circumvent this problem (I hope this is not a feature).

Or at least how to downgrade to 4.11 again.

Thanks in advance.

markusmatern

The default behaviour was changed with 4.12

This is the documentation about it: https://www.daz3d.com/forums/discussion/comment/5112696/#Comment_5112696

It is still possible to start multiple instances. However the default behaviour is to only start a single instance. The documentation is explaining the command line options you need to use to start a second or third instance. I sometimes even start four instances together.

Basically you start it like this: dazstudio.exe -instanceName DAZ#

You can make this also with a link in Windows as a handy shortcut.

You also may want to take a look in this thread: https://www.daz3d.com/forums/discussion/359146/does-4-12-1-16-allow-multiple-instances-of-studio/p9

handel_035c4ce6

So basicly instead of making the working better for another highly secretive reasons they make it harder.

PS. Copied the command line one guy posted on this thread and it works. Thanks.

Richard Haseltine

handel_035c4ce6 said:

So basicly instead of making the working better for another highly secretive reasons they make it harder.

There was nothing secret about the reasons - running multiple non-unique instances carried the risk of corruption of data and other kinds of conflict.

PS. Copied the command lien one guy posted on this thread and it works. Thanks.

jbowler

handel_035c4ce6 said:

So basicly instead of making the working better for another highly secretive reasons they make it harder.

It's protecting the shared configuration files; with -instanceName # they are loaded once at start-up but they are not updated.  If they were each instance would overwrite the configuration files with the local changes.  As it is if you want to change the configuration you must either run a non-instanced version (which is what I do) or mess with more of the command line options to give separate sets of config files.

Instances do write the "recent files" list but they basically add to it on every save so it rapidly gets populated with the same file name.  CMS directory changes, current working directory, current scene directory... are all lost.

handel_035c4ce6

The next problem I met - when I close the program it doesn't get closed but moves to the background processes (Win 10) and to start the program at new I have either to manually close the background process or to wait untill it dissappears.

 

jbowler said:

handel_035c4ce6 said:

So basicly instead of making the working better for another highly secretive reasons they make it harder.

It's protecting the shared configuration files; with -instanceName # they are loaded once at start-up but they are not updated.  If they were each instance...

You mean it's to prevent problems when opening two instances of the same or similar scene (using same assets) from interfering with each other?

jbowler

handel_035c4ce6 said:

The next problem I met - when I close the program it doesn't get closed but moves to the background processes (Win 10) and to start the program at new I have either to manually close the background process or to wait untill it dissappears.

That's another reason for running with -instanceName