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
© 2023 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
© 2023 Daz Productions Inc. All Rights Reserved.
Comments
No, I don't. I have used it for finding dupes too
I install via DIM only. (I followed the advice in this thread and logged in to update the metadata though.)
But I think I've come a fair bit further in investigating my issue with TL. (And yes I write my issue because only a certain workflow reveals it.)
As I already mentioned I work with instances. With every Instance DAZ Studio creates a new folder in the registry named Studio4PublicBuild[<instance>] There every setting goes and after refreshing (which I didn't do in my first test this week) I can even see the TL entries. However - if I close the instance of DS the instance folder gets emptied completely. (I'm still working with DS 4.16.1.31 - might be an issue with that particular version, because I see folders with higher instance numbers still having entries so I assume there once had been a version of DS which left the settings.) On starting an instanced run of DS the data from the non-instanced folder gets copied into the empty instance folder. This also explains why I have to do all my setting of DAZ Studio itself (layout, folder start positions etc...) in the non-instanced run.
Therefore I ran TL manager in the non-instanced DS - e voila - now TL knows that it doesn't have to scan again in no regard of how many instances I have running. I only must ensure that I do the re-scan and everything I want to have saved to the registry in the non-instanced run of DS. Might look a bit inconvenient - it is - but I'm used to this workflow anyways. I´m sorry I could have guessed that in the first place but I didn't know that DS so heavily relies on the registry. Still I'm grateful for that lesson and happy that you suggested to investigate the registry.
One not too far day in the future I will update to the current version of DS and check if handles instancing still the same. If so, I might consider writing a scrpt which helps me saving the data to the non instanced version.
Oh wow, I would not have thought of that. Makes perfect sense though. I am glad you got it working.
I purchased "Turbo Loader Booster Utilities" and "Turbo Loader for Genesis 8 and 8.1" and was very surprised to achieve a reduction in file loading time. Females work fine, but for males, the available shapings have decreased significantly. As shown in the attached image, there are almost 500 G8M assets loaded in DAZ Studio, but only six shapings can be used via dial. Is this the intended behavior?
Is there a way to resolve this issue and enable the use of all shapings via dial while reducing loading time when working in DAZ?
This is the intended behavior. It is the finding of morphs and creation of all those dials that slows DS down. Turbo Loader Booster Utilities will enable morphs (and the dials) needed for loading a character or scene on the fly. Otherwise, you need to reenable in Turbo Loader Manager for G8M the products/morphs you want always available. For example, I might always leave on Shape Shift or Easy Shape Master so I always have access to those morphs (and even add them to the Filtered Products option so they cannot be turned off)
Thank you very much for your prompt advice. Thanks to you, I have found out the reason why only G8F could be operated smoothly with the dials. "Shape Shift for Genesis 8 Female(s)" has been purchased and enabled in Turbo Loader, but "Shape Shift for Genesis 8 Male(s)" has not been purchased. I also do not have "Easy Shape Master - Age Control and Body Tuning for Genesis 8 Male", so I cannot use the dials comfortably with the method you have advised. I plan to purchase one of them when the price drops.
In addition, when I load G81M in my environment, "Khalan Head", "Mouth Realism HD", and "Khalan Body" are automatically set to 100%. Since I can turn them off manually using Dial Control, there is no actual harm, but users who do not have Dial Control are expected to have difficulties.
It can be any of your favorite morphs. I just mentioned those packages because those are the ones I use.
This does not have anything to do with Turbo Loader. Turbo Loader just disables/enables morphs. What is loaded and how much comes from your Genesis 8 character.
So I have created a new issue for myself. I'm 99% sure I'm just missing something obvious.
Having gained a new rig, I am working on accessing my library from it via network share (to save the pain of having a duplicate content library of well over a terabyte on two separate computers).
For some reason, Turbo Loader, and only Turbo Loader refuses to function correctly attempting to run any script produces some variation of this error:
They all error on the same sIncludeFileExt, and I cannot for the life of me figure out why. It's still perfectly functional on the original computer hosting the library, but refuses to be recognized on the remote computer. Any ideas/recommendations/solutions?
Nevemind, I suppose. Despite having all relevant network read/write permissions and nothing else in any of my scripts having a conflict, Turbo Loader does not like running remotely. To work around this, I added an extra library on the remote computer solely to host Turbo Loader, and it runs fine from there. I swear I post things in support forums just to look at them and almost immediately then figure out my own workarounds, lol. It is minorly annoying having to set it up twice, but I suppose for some that could be perceived as a benefit of some sort, I'm just duplicating what it already did, personally, so it feels kind of... extra.
The sIncludeExt is defined in "data/RiverSoft Art/Common/RSConstants.dsa" so it is not finding that file. Turbo Loader has to use a special FindFile function I wrote instead of the one provided by DS because DS' FindFile caches the results. While caching is great usually, TL is renaming files all the time AND dealing with possible duplicates hidden by the renamed files so I could not use it.
I went through 15 pages; I may easily have missed it but I could not find anything about a Turbo Loader for Genesis 9. Seems like a no brainer...
Are you already seeing significant slowdown? I am not yet. If there are not enough G9 characters out to make people's system slow, it just didn't seem like something people would want (yet).
I moved my libraries to a network drive also, and had the same issue with it not finding sincludefileedit. The fix is that you need to map the network drive, and use the mapping in your content library path. Scripts will not find that data folder from an unmapped network drive. It probably isn't just Turbo Loader, and there may be some DAZ program functions themselves that don't work right if that isn't fixed. In particular it also cleared up an issue I was having with Filament where adding an HDRI map turned the scene black and didn't add any lights.
Bottom line is if you use a network drive for a library, it needs to be mapped to a drive letter and you need to set that mapping in the content manager.
Thanks for sharing your tip!