Use DIM to install twice
Granville
Posts: 696
I want to use DIM to install the same content twice - once to my poser library and once to my DAZ content. But the files disappear from the first tab after I have installed them in DAZ. Does anyone have any advice?
I love the DIM, but since I have 4000 files to install, I want to do it right.
Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
You can just download the installers in ZIP format, and install them later yourself, that is the only way I can think of. If you have already installed these somewhere, and didn't ask for the installers to be deleted, then they should still be there on your machine.
That is a good idea. I'll ask some users and see if any other options might exist.
The only way it can be done at this point in time is to use DIM to install to one location and extract the same zip to the other. I just pointed my DS library in Poser and access it that way.
Another option would be to go to "C:\Users\Public\Documents\DAZ 3D\InstallManager\ManifestFiles" and delete the .dsx file corresponding to that product. Then DIM would allow you to install it again, but no matter how you do it DIM will only be aware of one installation.
Is there a reason you want to install twice rather than have both DS and Poser look at a common external content folder?
First - Thank you everyone for the advice. You guys are awesome. I honestly didn't realized that DIM downloaded all this content in zips. But when I looked in the folder, there they were.
@fixmypcmike
I have to cop to the charge of "content meddler." I want to keep my poser library pristine by organizing the content logically via the actual folder structure. I tried to abandon the poser library structure, but Carrara still needed it. I have let DAZ organize my daz studio content for me and it is a mess - there is absolutely no logic or consistency to the way the files are laid down. It reminds me of my 6-year olds' toy closet.
That's why people like to set up categories in DS
It sounds tempting to use categories, but my Antivirus program, Webroot, will not allow CMS to run no matter how I try to white list it. Its heuristics engine finds its behavior highly suspicious and identifies it as a rootkit virus - immediately shutting it down when it tries to communcate with DAZ studio.
Never had the need to do this myself until recently. I haven't found any other discussion regarding this, so I will add to this one, if anyone is still listening.
To expand on fixmypcmike's suggestion of deleting the manifests, I suggest to not delete them, but rather store them in another folder. That way, you can retrieve them and manage any library independently. Create a manifest folder for each library, naming them "ManifestFiles Lib1", "ManifestFiles Lib2", etc. (or something easy for you to remember). Rename the one of interest (the library you want to manage) to simply "ManifestFiles". That is from where Install Manager will retrieve its information since it can only keep track of one installation.
If you want to work on the other library, rename the default "ManifestFiles" to the first's name, and rename the second to "ManifestFiles". All the manifests for the first library will be in one folder, and all the manifests for the second library will be in the second folder. You can add as many as you like that way...
What would be awesome is if Install Manager could distinguish between libraries in this way. Since we can have a set of installation locations, why not have a corresponding manifest file folder for each library instead of a global one?
I think the reason for having DIM not do multiple installations is that it adds a lot of complexity and potential for problems.
-- If a product is updated, should it update all the locations? Should it ask you which ones to update?
-- How do you indicated that content should be installed in multiple places? Do you have an extra option on the Installed tab to install to an additional location? What if the package is no longer in the Downloads folder?
-- What about content which won't work properly if it's installed in more than one location visible to an application, e.g. V4 ExP morphs? If DIM is going to keep track of those, all those products would need to be updated with a new property to tell DIM it should only be installed to one place. But it isn't a problem if it's in 2 places but each app only sees one of them, and DIM doesn't have access to that information. So it needs to warn you about it and ask if you really want to do it?
-- DIM as it currently stands is designed so you can click "Start Queue" and walk away. So DIM shouldn't be prompting you with these questions along the way, forcing you to sit and watch it.
As it is, for content which is treated like a plugin (e.g. Photoshop brushes, Bryce content, Carrara content), DIM installs to all the versions listed in the Applications tab and updates them all, which can be problematic also, but seems to me the best alternative. For DS/Poser type content, since all the applications using it can use multiple external content locations, installing in only one place is a far better general solution.
Fair enough, I understand the complexity of maintaining more than one library. Done simultaneously, I can see the exponential rise in difficulty, but what if you can do one at a time, with the ability to switch between libraries? I realize that having more than one would make the user's life more difficult, but I would have no problem maintaining one at a time. Download, install/update one library as usual (queue them up and walk away), change library, install/update as usual (queue them up and walk away again). Extra steps, for sure, but one library at a time. If a user wants to have more libraries, he should do the extra work to maintain them. If he had installations on different computers, he would have to update each one separately just the same.
Anyway, I was just rolling a couple of ideas around to see if they sounded reasonable. I used to be heavily into software standardization and configuration control, so this was an extension of that process...
Thanks for your time.