[Released] Turbo Loader for Genesis 9 [Commercial]
RiverSoft Art
Posts: 6,570
[Sorry. No images. I cannot seem to upload them right now]
Do you have a large content library? Have you started to dread loading a Genesis 9 figure because it can take so long? Then the Turbo Loader for Genesis 9 is for you! Turbo Loader turbocharges Daz Studio for users with large content libraries. By disabling unneeded morphs for your Genesis 9 figures, see dramatic speed increases in loading scenes and figures, and even clearing scenes.
The first time that Daz Studio loads a Genesis 9 character in a scene, Daz Studio searches your content directories for all the morphs used by that figure and creates properties to control them. With a large content library with lots of morphs, this operation can take a long time. However, for most scenes, you don't need all of those morphs.
The Turbo Loader scripts detect ALL morphs in your system for Genesis 9 and organize them by product. Turbo Loader will work with morphs installed manually, by Daz Install Manager, or even by Daz Connect!
Disable all the morphs for a figure type (except some important products such as Genesis 9 Starter Essentials). Then, quickly enable select morphs for the scene you want to create. You will be amazed at how much more responsive Daz Studio is!
- Turbocharge the loading of figures* and scenes.
- Finds morphs, properties, and aliases wherever they are located, even in multiple locations such as products installed with Daz Connect.
- Organizes morphs by product, allowing you to easily enable and disable morphs to suit your current needs.
- Create configurations to quickly and easily enable or disable sets of morphs before loading figures.
Products installed manually or with products like Content Wizard do not have morphs recognized by the Daz Studio database. They will be organized as unknown products with a name from their parent directory.
*This is very dependent on the number of morphs you have for a figure generation. In tests, we have seen speed increases from 6-17x faster!
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
I have resolved to limit severely my G9 character library (43 atm) so that I won't have to experience the nightmare that made the G8 Turbo Loader a necessity. Thanks for getting us ready for the lag that could come with males and females using the same base.
You're welcome. Between sharing males and females AND my new Character Converter making tons of morphs, all of a sudden I needed it
...and here it is.
It's released
Hello RiverSoftArt,
thank you for this fantastic product! I have purchased Turbo Loader for all generations as well as the Booster product and I'm now in the process of adjusting my workflow accordingly.
Your product not just speeds things up considerably, it also helps to "clean up all the clutter" when searching for the relevant adjustments.
I did notice some "unwanted behaviour", which might need to be addressed at least in the G9 version. (I'm using DAZ connect as you will see below):
- Morphs located in Drive Letter > DAZ 3D > Content > My Daz Connect Library > data > cloud > 1_9xxxx > data > daz 3d > genesis 9 > base _get_ renamed correctly.
- Morphs located in the same path but in >> 1_9xxxx > data > daz 3d > genesis 9 > [genesis 9 eyelashes | genesis 9 eyes | genesis 9 mouth | genesis 9 tear ] do seem to be "overlooked".
This way they still show up in the parameter pane. I suppose this requires a simple fix in the scripts to include the additional directories [genesis 9 eyelashes | genesis 9 eyes | genesis 9 mouth | genesis 9 tear ] on top of "base" in the search paths?
Apart from that everything seems to be working properly.
Best regards,
Guido
You're welcome! I am glad you like it.
I will have to think carefully about this one. I have a feeling there will be unwanted side effects in my code if I do that. But thank you for the suggestion.
Heya RiverSoftArt,
Came across a problem that's going to make me (at least for now) stop using the G9 loader:
The above error pops off every time I try to use Merge into Scene on any G9 character. And by "pops," I mean that same bit of code runs until I force close Daz Studio, or it crashes (around 5 minutes or so).
I think I fixed this once before, but it always reoccurs. That morph (and all the basic FACs ones) are enabled, executed, saved in the configuration, etc. It can't find the .tlOff... because it's on. And Turbo Loader, by every method I have to see what it knows... knows that it's on/active.
If I disable it manually, it will load one character, and if I forget (like I always do because it's a thing I always want... which is why I turned it on...), I am harshly reminded by the impending crash/force-close. I have way fewer G9 morphs, so it's not a huge inconvenience to just turn them all on and stop using TL for now, but I figured this time... I'd actually say something since it kinda broke my flow state, and I remembered to come say something about it, lol. Can't fix what we don't know is broken I guess. Somehow, only that loader has this error, though G3 and G8 are both running fine, and I set them all up the same way (and G3 and G8 each have exponentially more morphs to go through compared to G9 for me at the moment).
Hopefully, this gets fixed or whatever I'm doing wrong comes out before my G9 library catches up :)
Edit: Oh! DIM install, According to DIM I have the latest version (13 October 2023). No Connect anything anywhere (because I dislike it personally). And as I mentioned, it's just this loader, G3 and G8 from the same date work just fine (and a lot!).
I will have to investigate.
No worries, bugs are weird. Especially when they do things counterintuitive to their co-programs that work fine, lol.
If it helps in the investigation (I got bored/stubborn a bit), a couple of points:
It's guaranteed to throw that on the facs_cbs_* morphs specifically. All of them, and only them.
I can go in and manually disable one at a time, and it will hang on the next. If I start the process, and manually disable them in the folder while it's running; sometimes, it'll catch it before it's stuck in its cycle and reactivate them as normal, sometimes not, that part seemed random.
Those morphs will specifically freak out on any/all of the *9 base characters (or any character that uses them specifically, i.e. any that use V9/M9 morphs directly). If I use a vendor morph that does not use a Daz G9 base specifically, it never has an issue and works like normal (very few I have do not do that, took a while to find one).
It seems like when I disable them with TL (via configuration or manually executing), TL doesn't seem to recognize I did so, and the error will reoccur on the next load attempt since it says it can't find them, even with me having the folder open staring at them all as tlOff files. I have to manually turn them off (turning them on with TL also functions on the files themselves in real-time, but it's like TL just can't read them, or their state at least, for... reasons?)
Crucially, if I do the manual disable, and then use TL, it turns them on (as it should). If I try to load a second character without re-disabling them (and for me at least, that means manually), it will throw the error (even though, obviously at that point, TL has to know they're on; it just turned them on!) <-- This was the one that had/has me most baffled.
It's really weird that it's just those Facs morphs, and only when called by a base *9 character. I'm still open to somehow I may have borked something, but re-install (of all the *9 files and TL)/re-scan/re-setup fails to fix it, and like I said, the other TLs (G3* and G8*) all work fine, so.... yeah, lol.
And maybe one day the forums will notify me of replies again, lol. I'll try to remember to check back in a bit more often in case maybe I can offer more things I tried later.
Checking back in since DIM prompted me for the newest update.
At least in my case, disabling through TL now functions correctly, which is nice!
Still crashes with the same error if I don't disable the facs again (which is faster now at least, since the script works correctly!) before loading a second character that uses those facs.
Out of curiosity, is there a particular method to get the ignore section to actually ignore say... these problematic FACS morphs? I want them on all the time, so in my case, I would be fine if the script would just ignore them entirely, which my attempts to do have failed to make happen :/
One other thing that I just noticed/remembered: I have to manually refresh the status for this, and only this G9 loader. the others all update themselves. No idea how that could be related, but figured I'd mention it, since it's the only behavior that seems limited to this one aside from the crashing problem.
Since detailed and specific steps may also be useful for error checking, I can quickly get this error/crash repeatably by
This is with the newest update through DIM from July 19th.
On the plus side, this is now faster than file hunting, so I'll take the script disabling correctly and reliably, since G9 is slowly creeping up in load time!
I am not seeing any crashes with the facs stuff. By chance, can YOU in file explorer rename them? Are they set to read-only? (shouldn't matter but am wondering) What does the file path look like? Do you use a link?
What does your Filtered Products Options look like? Here is mine:
What does Product List look like? Are there lots of *** UNKNOWN PRODUCT ***?
The crashing is probably keeping it from saving the configuration. That is why you have to manually refresh the status.
Unfortunately, I do not have Amala or Fabrice.
Amala and Fabrice are included with the Genesis 9 Starter Essentials, hence they were easy and fast to test with eliminating other variables.
On reviewing my Filtered Products list, yours includes "Genesis 9 Essentials" while mine by default does not. Reset also removes it, so I may have done that and not noticed it. I have tried adding it and saving settings, will test again once I post this.
Path to the problem morphs is "R:\My Library\data\DAZ 3D\Genesis 9\Base\Morphs\Daz 3D\FACS", got rid of all symlinks/redirects about a year ago I think, because that caused issues across all loaders and some other plugins.
I can manually do all kinds of stuff, no they aren't read-only, and as I said with the latest update, TL does enable/disable them if I explicitly do so with it (i.e. Execute Selected or Execute). The morph list just does not update their state. Like if I disable them, load a model that enables them, and reopen TL, the G3 and G8 TLs will have the list of enabled disabled updated. Only the G9 one does not. Crashing is not required, the list does not update unless I manually tell it to with Refresh Status, and is the only one that requires me to do so.
Also, apparently every single morph in my product list shows as UNKNOWN PRODUCT, including the Daz native ones. Again, though, I never noticed it as a possible problem, because that is across all of the TLs. None of the others have issues.
For the record, I appreciate your patience. I genuinely love the Turbo Loader system, and really just want this one to work like the rest do, cuz I kinda use them all the time, and it feels weird to do it different for just this one.
Gonna give it another shot with the added G9 Expressions filter, and see if that little thing is the whole problem... will update with an edit shortly.
Update: My filter list matches yours exactly, did a re-scan and clean restart to make sure I wasn't missing something somewhere. No dice. I am kinda at a loss as to what, where could be causing this behavior, honestly. It feels like there's a config file hidden somewhere that's storing errant data or something, and that is reading instead of what should be. Can't find anything like that though. It's honestly only vexing because it's only happening to one script out of 5. I would think that if my whole setup was wrong, and they're all in the same place, accessing the same data, the same way, from the same place, they'd all have the same, similar, or even any issues. But it's just the one. Although, G9 has now surpassed G3 in number of morphs finally, so at least it isn't still the one with the least morphs having all the problems. :)
I suppose for clarity's sake, was your question about renaming the facs files as a means of eliminating them from the morph list? Because yes, I can, but again my issue is I just want them on. If I wanted them off, I'd just zip them and be done with it, since I know that works. My whole issue is that only Genesis 9 seems to force this request to find a missing .tlOff it shouldn't be looking for, and that nothing I can seem to do will stop it from doing so. Every other Genesis will, at worst, just pop a list saying some morph or other couldn't be loaded/found. So why does this one lock itself in a hard loop retrying a task it shouldn't even be running?
Since I'm out of other ideas, and I can't dig through encrypted scripts to compare, I'll just have to adapt, at least I can manually toggle with the loader now, which is still markedly faster than doing it by hand.
Ah! That was my problem. I was looking for products in Smart Content! I can load both no problem.
If you mean, using TurboLoader Booster Utilities and its merge script, you expect the morph list in the Turbo Loader Manager to update, this is NOT a feature I have added to any of the Turbo Loader products. If you mean when you click Execute Selected in the Turbo Loader Manager, you expect the settings to be automatically saved, this is again NOT a feature done by any of the scripts. You have to click Save Settings or Execute.
This means the filtered products list is not working for you. The script goes through the morphs and removes products whose NAME is in the filtered products list. Since all of yours have *** UNKNOWN PRODUCT *** in the name (as well as being slightly different names), nothing will get filters. For example, if YOU added "FACS *** UNKNOWN PRODUCT ***" (I think), this product and all of its morphs would never be in the list anymore so you could never accidentally turn them off. ONLY DO THIS AFTER ENABLING ALL MORPHS FIRST.
Glad you found them (I had to go to my downloads to figure out what came with the essentials myself, lol).
I mean that whether you intended it as a function or not, i.e. opening a turbo loader script (i.e. TL for G8F) scans the morphs list, and tells me what's enabled/disabled for that character base. Always has. Genesis 9 does the same scan, but does not correctly display what is enabled/disabled after doing that opening scan, and nothing except explicitly refreshing will cause it to do so. The scan on open is not reading the current morphs, nor is the one when you double-click to load a configuration from within the script. This functionally changes nothing, I was just informing you of a behavior that does not match with every other TL script in case that helps narrow down what my core issue is.
I shall give this a try. Will let you know if that fixes it for me. I am becoming increasingly aware this seems to be a "me" problem, but I do very much appreciate all the tips and help :)
In case my actual problem is getting lost in the details: As of right now, I HAVE to turn them off for the script not to crash Daz Studio. Every character that tries to turn them on when they are not off is what causes the error. As far as I can tell, this should not happen, as it should not try to enable a morph that is already enabled. It is trying to, and that is the problem. As a reminder, this is the offending error:
It is looking for a .tlOff file (disabled morph) that does not exist because it is enabled because the script just enabled it. This is the entire issue I have. Anything that leaves these morphs on/enabled causes this error. It doesn't matter if they were never off, it doesn't matter if I or the script itself enabled them. If they are enabled, and I attempt to use scripts to merge/open a character/actor that enables the FACS while they are already on/enabled, this is the error I get. I need the script to stop insisting on looking for a file that does not exist... Like it does for any/every other circumstance.
As I mentioned previously, despite all of the other supposed errors I have, every other Turbo Loader script functions just fine.
If my Unknown Products thing is an issue, it's not affecting anything else in any other script. Only Turbo Loader Manager Genesis 9 behaves slightly differently, and merging using the same method I do across every other TL script generation does not have this issue with any other script/combination. It is just G9, so as far as troubleshooting as an end user goes, something seems to be wrong here, or every script should have a similar (or indeed any) issue. They don't. It's just this one. If it stops looking for file(s) it has to know don't exist and stops crashing Daz Studio insisting it/they must exist, I would have no functional problem. If it would just skip missing files (like every other script is happy to), I would have no functional problem, and would gladly chalk the listup to QT UI being buggy. It locks me in the above loop instead. That is the issue I need resolved/bypassed. Enabling the files is the problem, not a solution.
If you wrote anything after your end quote, it was cut off in your post, just fyi.
Tried adding the unknown product to filters. Does nothing, but even removing the morphs entirely/re-scanning the directory so they aren't ever in the script's list, then re-adding them after does not solve the problem.
Steps I took:
I cleared the morphs list, removed the FACS folder entirely, scanned for morphs, and saved a new morph list manually. Turbo Loader Manager does not show the FACs morphs now. Unchecked all morphs and executed. While the folder was entirely missing, no issues. Loaded multiple characters with merge, and only got one shared facs file missing error across each.
Replaced FACs folder with all in .dsf form. Turbo Loader Manager still does not show them. Merging a character immediately throws the error.
This script/generation alone insists it has to enable the FACS morphs by changing .tlOff(s) to .dsf(s), if those .dsf(s) exist at all. And it has to do so each time a character references them. If it can't find the required .tlOff file(s) when triggered (again for no reason, as far as I can tell, if the folder/facs morphs exist at all, this script insists it has to go through this process), regardless of how or why they aren't there, it goes into that forced loop. Even if as far as I can tell, there's no reason the script should even be aware of/attempting to locate them at all.
So, like, I'm open to the idea that, somehow, something is borked on my end, but if I go through all the means available to me to never have these morphs recognized by the script, and they are still causing an issue that works unlike every other script... that feels like a not "me" problem... For example, I typically realize I forgot to re-scan/add a new G3/8F morph because it just loads up with any new character merged if it's not in the managed list... this one does not do that, which I gather is what it should do, at least, it does not do that with very specifically the facs_cbs morphs. If these G9 FACs morphs exist in any way and are not in .tlOff form, the merge script fixates on them incorrectly and fatally.
If that's in the merge script itself, then it's weird it only does it for G9 FACs morphs. If it's reading some table/function parameter somewhere in an encrypted script in the G9 stuff, that makes more sense, but I am equally unable to do anything to solve the problem. If there's some super-secret hidden config somewhere that is/is not correctly being read/written, cool, but I can't find it to remove/edit/fix it myself.
As a simple end-user request issue: I just need the script (whichever of the two it has to be, or both, I suppose) to stop hard locking to perform a function it can't do, shouldn't even by trying to do, and most importantly doesn't need to do in a way that loops until crashing studio. If it can't find a tlOff file, it should never lock Studio up until it crashes. It should skip it, like it does in every other script combination for any other missing thing. It doesn't. Please make it do that. That would fix my issue.
This is NOT a feature in any of the Turbo Loader Manager scripts. The FIRST time the Turbo Loader Manager script is run (or the morph list is empty), it will ask to scan. After that though, when you start the script, it just loads the morph list (which can take a long time and so has a progress bar).
The Merge script has determined that facs_cbs_BIUL_BDL.dsf is one that is needed by this character. The "Enabling" message is letting you know that it is going to look for the morph. It does this by looking for OFF morphs because there can be multiple locations for the morph (with Daz Connect). The next messages mean that the off morph was not found so everything is good. This is normal.
Yeah, it is getting hard to parse everything so I was ruthless here.
You are misunderstanding the log messages. It HAS to look for the morphs to make sure they are on. It prints out a message that the looking is started. And then looks for the off morphs. If it cannot find the off morphs, great, it just goes on. After that is done, it opens the morph file to find out if this morph needs any other morphs to work (as it doesn't help to turn on a morph if all of its morphs aren't on). I will look to see if facs_cbs_buil_bdl.dsf contains something that causes an infinite loop.
I'm sure it's supposed to. It doesn't, which was the problem originally reported almost three months ago. Quite frankly, if it got difficult to parse because you enjoy arguing the semantics of the terms I used to describe processes, that's on you. And if it's taken this long for you to get around to doing any actual investigation, I suppose don't bother. I paid for a thing because I assumed I would receive support. I won't make either mistake again. Apologies for disturbing you, and good luck with whatever you do moving forward.
Peace.
I need to understand what you are saying in order to understand the issue. If we cannot communicate, I cannot figure out if the problem is in the product. I could not reproduce your error so it was a little difficult to do anything. And your Daz Content database is corrupted (all those unknown products) so it could easily have been something in your system. I now have a small test case where I can confirm I see the issue, so I can work towards fixing it.
Writing "Peace" after what you wrote above doesn't work (that's all I will say).
HI
After Turbo Loader disables the morphs, I click on the character thumbnail to load the character and I get the message "The files listed below could not be found" which is expected.
But If I type in the name of the same character in Parameters, that character`s morph sliders show up and are enabled.
In previous versions, the character`s morph sliders down even show up when disabled by Turbo Loader.
Are the morphs actually disabled and Is there a fix for this?
Thank you
I am unable to reproduce this behavior. Are you sure the morphs are truly disabled. Did you perhaps disable the morphs AFTER the character has been loaded into the scene? (In that case, the morphs stick around until a new scene is loaded)
Thank you for your reply.
It does not seem like the morphs are disabled since I can still access working sliders. It just seems like it only disabled access to the morphs when clicking on the thumbnails in the content library. (I don`t use smart content)
When I disabled the morphs through Turbo Loader, I had no characters loaded.
I went through the process of disabling the morphs three times
I am using DS 4.22 on Windows 11, 8GB Ram, Nvidia RTX 3090
There would be no sliders if the morphs are disabled. You can try using the parameters on the slider to find where the morph it controls is located.
I just ended up reinstalling and it seems to be working fine now.
Thank you again for your replies
Well, I am glad you got it working.