Daz 3D is part of 
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.Daz 3D is part of
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
Yes, I've had these problems again, as with every version of DS4 and 4.5 I've installed, and now also the DSON importer and the one plugin installer from the DS4.5 beta I installed (the Dynamic clothing control). It really has become very tiresome.
There were some slight differences this time, making a slight improvement.
As always before, the DS installer, the DSON importer installer and the Dynamic Clothing control installer, when the uninstaller for the previous version ran, the uninstaller errored out with a 'segmentation fault'. On return to the installer after the acknowledging the uninstaller error, the installer promptly crashed. It really should not be beyond the wit of man to design things so that the installer doesn't crash in cases when the uninstall fails.
In all three cases, the errored uninstall DID uninstall the existing uninstall .dat file.
In the case of the Dynamic Clothing Control installer and the DSON importer, the lack of the uninstall .dat file meant further install attempts with the uninstall trying to run then errored due to the absence of the uninstall .dat file, the installer then crashing again after the uninstall fail. As the Dynamic Clothing control importer has no option to choose to install without uninstalling, I had to go into the Program files to manually delete the uninstall .exe to then finally get the installer to run. The DSON Importer installer thankfully DOES have an option not to uninstall, so that could be run picking that option without having to manually delve and delete the uninstall .exe.
The marginal positive change with the actual DS installer was that on the initial uninstaller segmentation error followed by the installer crash, this time, for the first time, it had deleted the uninstall .exe AS WELL AS the uninstall .dat file it's always deleted. So this time the installer did run on the second attempt without trying to uninstall and therefore failing, and therefore not needing me to manually find and delete the uninstall .exe to get the installer to run.
But then, as previous times and as with you, the CMS installer ended saying there'd been an unspecified error (but I don't use the CMS ... but still ....)
And at the end of the installs of all three - DS, DSON Importer and Dynamic Clothing control - there was a message about an error in creating the new uninstallers, citing an inability to access the uninstall file, even though it did create (non-empty) uninstall .exe and .dat files for each.
Very tiresome. These DAZ programs are the only programs I have any trouble installing. I can't even remember the last time I got error messages, let alone crashes and needs to manually delete files, on any other program install, whether fresh installs or upgrades to new versions. Yet I've had this with every DS 4 and 4.5.
Currently a follower can hide facets on one target mesh. You can make the socks hide genesis facets. You can make boots hide sock facets if it is following the socks. However you can't make boots hide facets on Genesis and on the Socks.
It is the database.Correct. The Valentina 5 Client, fixes all sorts of nastiness, especially on the Mac.
nvinit*.dll is part of the NVIDIA driver installation; it is NOT provided by any of the installers that DAZ 3D distributes. It [presumably] listens for processes to start (in this case, a BitRock uninstaller) and attaches itself to them. Its purpose appears to be to export functions that allow configuration of the desktop and display(s); it provides the ability to control display functionality, such as gamma and PowerMizer settings, obtain display information such as multi-monitor modes and a list of the displays that are connected to the system. The problem is, IT is crashing and thereby causing the process it is attached to (i.e. the BitRock uninstaller) to crash. Renaming the dll causes it to not be found, which causes it to not attach to the process when it starts, which then doesn't cause it to crash, which ultimately allows the process (i.e. the BitRock uninstaller) to operate in the way it was designed.
The thing is, BitRock is the ONLY thing that ever trips the crash in nvinit on my system. So even if it is an Nvidia bug, it seems like BitRock is doing something to trigger it where most apps do not. Other installer systems don't seem to have this problem, either.
What is the reason for using BitRock instead of standard .msi files? Is it cross-platform, so supports your Mac install as well in a single project?
Of course: I'm still using the last? 4.5 beta, and fitting clothes to each other (or as I more usually do, setting them to collide with layers below) works just fine even in my build (4.5.2.40 Pro 64-bit)
Content DB Maintenance > Re-Import metadata
Thanks. Took a bit more than that to get it done. Uninstall DS and the Content Management Service module, clear out the old Meta Data and then reinstall and it was all there. Weird way to do it but it worked. Found that info at the ZEN desk. Actually good documentation on this and other issues pertaining to Meta Data there at the ZEN desk. Just wish DAZ would figure out a more automated way around all this. That was really my main request. lol
Thanks. Took a bit more than that to get it done. Uninstall DS and the Content Management Service module, clear out the old Meta Data and then reinstall and it was all there. Weird way to do it but it worked. Found that info at the ZEN desk. Actually good documentation on this and other issues pertaining to Meta Data there at the ZEN desk. Just wish DAZ would figure out a more automated way around all this. That was really my main request. lol Once we get the Valentina 5 server deployed, that should come up much less often.
Hope so. I have to admit, I really like Smart Content. It is smart but when one has this sort of thing happen trying to get it all back after a reinstall is just a bit overwhelming. By the by, is there a way to tell DIM to reinstall all downloaded content? I couldn't find a way to do that since I was considering this as an option if I couldn't find a solution to the meta data issue.
Be nice if there was a reinstall button on the DIM rather than unistalling and reinstalling. Yea, I do have it all saved to my L drive for safe keeping. :-)
On your system. It is at fault for crashes in plenty of other applications, just none that you use. BitRock cannot be expected to know that a third party may or may not attach to one of its processes and inject flawed code/logic that results in a crash. Again, it is nvinit that is causing the crash; the uninstaller is only crashing because nvinit attached to it and crashed. It is interesting, however, that NVIDIA is among those prominently listed as BitRock InstallBuilder customers.
To answer your question... Yes, BitRock building for multiple platforms (without forcing customers to deal with JVM issues) from a single project certainly played a significant part in choosing it; particularly because of the number of installers that had to be built. It cut the amount of work required to produce the installers, literally in half (actually more when you consider the amount of extra effort that went into building the VISE installers on Mac). Obviously, with our move toward Install Manager and zips with manifests, we're reducing our need for it. But, that need doesn't entirely go away... at least not yet. The change log for Install Manager provides some insight into the direction we are heading. Once we reach a certain point, MSI/DMG become much more feasible solutions... though it does require a bit of work and does not happen overnight.
In any event, there are several tangents here and I don't mean to derail this thread. Apologies to the folks visiting this thread for information specifically regarding the Release Candidate.
http://www.daz3d.com/media/catalog/product/cache/1/small_image/350x455/17f82f742ffe127f42dca9de82fb58b1/_/p/_product-page_daz-studio-4.6beta_.jpg
This horrendous zombie picture isn't gonna pop up every time I open the program, is it?
It looks better than the zombies in The Walking Dead :)
...urgh that is ugly.
I still miss the lovely "smiling Vicky" on the Studio2.3 startup.
This one?
http://screenshots.en.sftcdn.net/en/scrn/72000/72764/daz-studio-17.jpg
....yep.
If its the geometry shell bug at render time it is fixed, its just not in this build. It will be there be there before 4.6 ships.
No disrespect as I'm sure you're all working very hard to get these bugs fixed but I am very disappointed that this issue did not make this build, considering it was reported so quickly after the previous beta was released and is a major feature with a lot of potential. Hopefully it won't be long before the next beta is released as its the one thing I've been waiting for!
No disrespect as I'm sure you're all working very hard to get these bugs fixed but I am very disappointed that this issue did not make this build, considering it was reported so quickly after the previous beta was released and is a major feature with a lot of potential. Hopefully it won't be long before the next beta is released as its the one thing I've been waiting for!
And I'm confused as to how this build qualifies as a release candidate if it doesn't have everything in it that's gonna be in the actual release. :-/ Maybe I've misunderstood, but I was always under the impression that "release candidate" meant that if there were no fix-needed issues reported then that build got released as-is. No?
I have not noticed any problems with Reality 2.5. Seems to be all good.
Well it wretched well should be! This is a beta version so we have to sacrifice our previously stable version to use it - and why? Just to maintain support to the single most naff aspect of the post DAZ 4.0 build; the supposed content management system.
The last place I want my content is in the documents folder. It eats up space on my main drive and is nowhere near as elegant a storage solution as the old Runtime set up. I'd submit this idiotic idea as a bug report if I thought anyone would listen.
Well it wretched well should be! This is a beta version so we have to sacrifice our previously stable version to use it - and why? Just to maintain support to the single most naff aspect of the post DAZ 4.0 build; the supposed content management system.
The last place I want my content is in the documents folder. It eats up space on my main drive and is nowhere near as elegant a storage solution as the old Runtime set up. I'd submit this idiotic idea as a bug report if I thought anyone would listen.Reversion is simple and clean, if the Beta doesn't work for you.
There is not, nor has there ever been a requirement to put your content libraries anyplace you don't want them. Windows standards say that is where user content goes so that is the default for Windows. It is not a required location, simply a place to go if you don't specify somewhere else.
Well it wretched well should be! This is a beta version so we have to sacrifice our previously stable version to use it - and why? Just to maintain support to the single most naff aspect of the post DAZ 4.0 build; the supposed content management system.
The last place I want my content is in the documents folder. It eats up space on my main drive and is nowhere near as elegant a storage solution as the old Runtime set up. I'd submit this idiotic idea as a bug report if I thought anyone would listen.
What is not recommended or supported is 2 different versions of the same DAZ Studio branch installed at the same time. See first post:
Can I have the General Release and the BETA installed at the same time?
The simple answer is… Not within the same major version (4.x).
The more complicated answer is yes, but only if you are running a 64-bit operating system and you install the 32-bit version of one and the 64-bit version of the other.
Well it wretched well should be! This is a beta version so we have to sacrifice our previously stable version to use it - and why? Just to maintain support to the single most naff aspect of the post DAZ 4.0 build; the supposed content management system.
The last place I want my content is in the documents folder. It eats up space on my main drive and is nowhere near as elegant a storage solution as the old Runtime set up. I'd submit this idiotic idea as a bug report if I thought anyone would listen.
What is not recommended or supported is 2 different versions of the same DAZ Studio branch installed at the same time. See first post:
Can I have the General Release and the BETA installed at the same time?
The simple answer is… Not within the same major version (4.x).
The more complicated answer is yes, but only if you are running a 64-bit operating system and you install the 32-bit version of one and the 64-bit version of the other.
Yes, I saw this - but this is the first time that I've come across a beta version that can't be run alongside the existing stable version from a different drive in order to maintain functionality.
Well it wretched well should be! This is a beta version so we have to sacrifice our previously stable version to use it - and why? Just to maintain support to the single most naff aspect of the post DAZ 4.0 build; the supposed content management system.
The last place I want my content is in the documents folder. It eats up space on my main drive and is nowhere near as elegant a storage solution as the old Runtime set up. I'd submit this idiotic idea as a bug report if I thought anyone would listen.Reversion is simple and clean, if the Beta doesn't work for you.
There is not, nor has there ever been a requirement to put your content libraries anyplace you don't want them. Windows standards say that is where user content goes so that is the default for Windows. It is not a required location, simply a place to go if you don't specify somewhere else.
...not necessarily if one wants an absolutely clean rollback. As I understand one has to clear the registry (a potentially dangerous thing to do) to eradicate everything that the previous install squirreled away in various places as the uninstaller doesn't catch everything.
Another issue is that from experience, any scene that as created or saved under a newer version of the application will not open in the previous one since there is no backwards compatibility.
...and I agree with urdwolf about the Documents folder. I have all my runtimes/libraries on a separate (larger) drive than the boot drive.
...and another thing while I'm here, why, when I installed 4.5 (on Win7) to the C:Root, did it place some items (like all the Omnifreaker stuff) in the Programme Files Folder? As I understand with Win7, this is a big "no no" and thus is partly responsible for some of the instability I am experiencing using the Surfaces tab and the built in Ubersurface/HSS plugins.
I personally rolled back to do some testing on 4.5.1.56 and it worked fine.
The only no no in regards to Program Files is that you cannot count on being able to write to the folder(its usually write protected). Omnifreaker stuff does not need to write over itself, so this is certainly not a problem.
One of the benefits of duf/dsf is that a file saved in 4.6 will open in 4.5
For those wishing to understand more about OpenSubdiv and vertex/edge weights I recommend this video:
OpenSubdiv Video
Studio doesn't have the real-time stuff at the moment, it uses the uniform cpu type, but its a great demonstration of the potential of these features.