ssgbryan posted at 5:41PM Mon, 31 October 2016 - #4288413

Have you spent 1 - 4 hours a day for 6 months trying to figure the best way to use the golum and associated products in Poser? I have.

And I spent 5 years developing with it. And you're still incorrect with your assessments.

It isn't a software debate Boni. It is an accurate statement of what happens when you have more than a handful of native DS items. Do you think I liked having to come up with the setup I mentioned above? The DIM is why I ended up reworking all of the subfolders.

Let's go with your Mad Nurse example that you said is so bad. I have it as well. The texture files are stored in /Runtime/Textures/RD/MadNurse... No subfolder there; where is yours installed? The files for the product itself is in /People/Genesis 2 Female/Clothing/G2FMadNurse... no subfolders there either. I think it's more of user error. That's why you've struggled for hours, so let's not spread misinformation about how bad the set is. You can also see the docs of where the files are supposed to be installed in the online docs as well as in DIM (by clicking the 'i' on the item you want to install) so you can verify if you've installed it in a different place.

As of today, I have 1,042 packages (according to the very appropriately named DIM) installed in DAZ's default layout (99% are genesis 1 & 2 - a couple of V4 products may have slipped thu ). It is breathtaking how many subfolders have only another subfolder in it, along with how many products are unhelpfully hidden away inside of an ego subfolder. Unless the enduser takes active steps to bring order, they will spend most of their time blindly drilling through subfolder after subfolder, looking for a product they know they have purchased.

Once again, I'm going to assert that you probably have a bad install due to user error rather than products installed poorly. Chances are I have the same products if not more than you do.

Every genesis product install is a snowflake, Male_M3dia's poor attempts a deflection won't change that - every single install is different, and unless the enduser memorizes what every single product goes with, they are going to have to do cleanup to actually find the products they purchased.

I'm going to assert that this is incorrect as well. Give me another example and i'm sure I'll check my install and verify it as well. If you decided to play with your install settings that's more likely the issue.

One other piece of advice - Poser Companion Files - I have over 1000 DS packages installed - Not 1 product has all of the PCF files in the correct folder. Not 1.

What do you deem incorrect? QA has locations of where each file is supposed to be located. If you are stating an opinion, then that's far different than it being wrong. What's an example?

I'd also recommend resaving those out as Poser native files.

The DAZ vendors could do it (and a couple do provide native Poser files for their Companion Files), but for the most part they don't. It only takes a couple of seconds, and once you have done it, you have even less need to use DSON while in creative mode.

Making companion files doesn't automatically make a product poser compatible; it does require planning beforehand to make products work in both programs. Keep in mind that clothing does not have to be grouped in DS for genesis figures. So if it's not grouped, it's dead in the water for poser, so a companion file will not be needed. Some vendors that make poser items may still group their items so it may work, but if the companion file isn't there, there is a risk it won't work in Poser. So your assertion on that is incorrect as well.

The add-on framework in Poser isn't really designed to do the kind of heavy lifting that DSON requires. This is an issue with Python, not Poser (or DAZ, for that matter) - Python is 32-bit (with the 2GB per process limit - this is why Poser slows to a crawl when using DSON - EVERYTHING has to go through that 2Gb, unless you save stuff out as Poser native) and the folks that maintain the Python language aren't doing very much to migrate it to 64-bits. Not surprising, Python is designed to be a light weight scripting language.

Not sure about the 32-bit, as HD requires 64-bit to work in Poser; but the way the framework issue (and other issues as well) is the reason why Genesis 3 does not use DSON and I think no more development will happen with the importer.