DAZ Studio quality - pet peeves
Olo_Ordinaire
Posts: 742
I can't understand why in 2023 we're still seeing these:
- long-running processes in user-facing software that ignore the "Stop/Cancel/Abort" button, as we see in dForce simulation
- when loading a scene with a missing texture or DUF file, we see not one, not two, but THREE "missing file!" modal dialog boxes! Checking "Stop asking" does nothing
My personal opinion is that modal dialog boxes should die, but that's not always possible or appropriate. But when loading a scene in DS, just make a list somewhere or set an error indication OR give me the option to STOP LOADING THE DANG THING, instead of continuring.
Thank you.
Comments
No, it's the warnings about too-short springs that do not scan the main event loop - and those ar trouble generally. On a well-configured item they will be a short list, and checking the event loop would be unproductive.
I'm not sure of the logic involved for the multiple alerts for the same error, but Stop Asking will apply to future dialogues in that position in the sequence (at least in my experience).
Thanks, Richard, but it doesn't matter *why* the errors are being reported -- it matters that I can't stop the endless operation. I've also had badly-made garments report a short string of spring errors, then simulation starts and DS never returns control. I have to kill the process, in that case.
The "Stop Asking" dialog option does not stop anything, in my experience.
I'm sure these are the results of old, old design decisions, but it's 2023. Why are we still dealing with this stuff ?
Yeah, I remember the time my scenes took an hour+ to load, often I started the process and went to do something else, came back an hour later to see the stupid dialog for duplicate formulas on the screen which has no other option but to click "Ok"... If I was given an option to cancel loading the scene, I would understand, but stopping the process just to show that dialog - That's just stupid (imho)
It may be because the texture path is wrong in multiple places and so the "stop asking" only refers to one of them.
If recent experience is to be believed this might be due to the "//Runtime" bug that several products suffer from. From what I have seen the duf files with this bug have it referenced 2 or 3 times within the file and so that may be why the box comes up 2/3 times. Or it could be because Daz is choking on those paths and so when you hit "Stop Asking" it links that against the badly-parsed path but it keeps re-triggering it with the raw path.
I've encountered issues where textures are mapped to a specific drive letter and path, not just the folder (e.g. F:/texture.jpg), this can be problematic when your assets are stored outside of the boot drive and the device you had them on is no longer available, and in this case the missing image dialog opens. In some cases a texture was mapped to a temp folder, not the path where the texture came from, when that image is not found the missing image dialog is shown. In these instances walking away while a file loads stops the file and will not continue until you relink an image or dismiss the dialog. if you walk away again the file will stop loading to display a 2nd dialog telling you what was missing and wait for the user to confirm.
I have reported this behavior on more than one instance, however it has not been addressed by Daz at this time
It's telling you that there is an actual, outright error in there. That isn't soemthing that it should just slide over and leave people to find if they dig.
But, when it's not giving the user any other options than "Ok", especially when the warning comes up the second time after the scene has loaded, interrupting the loading process and requiring the user to push "Ok", is more like showing the user certain well known international hand signals.
Well, it can't fix the issue - just flag it up as something that needs fixing. It will stop things from working as they should, though, so can't be igmored.
Maybe the Duplicate Formulas warnings should also include a built in way to fix the problem.
I'm nearly certain most Studio users wouldn't even know how to start fixing that problem on their own and will just continue to click OK and ignore the problem if they can.
Reporting the duplicate formulas via support ticket just makes more work if the fix can be scripted.
Sounds like an great idea for a new product.
A script that scans your library looking for and fixing duplicate formulas.
I am hoping that Daz Studio 5 will make some improvements in this area - adding in more robust namespacing to avoid unexpected clashes and proper caching to stop figures taking ages to load when many morphs are available.
I think an auto-fix is properly unlikely given that there are a few pitfalls when fixing the issue. I have fixed one or two myself due to the PA using stupid values for the unique ID values but those were just for simple expressions, I think it gets more messy when you have morphs that are linked to by other morphs.
That certainly would cause problems when one PA links to another PAs morphs that duplicated a morph name/ID from another product.
Obviously, the earlier you can catch this sort of thing the better.
A tool that PAs can use during product build time would be ideal as the issues would be caught before the product was even finished.
Once customers are seeing the warnings while loading a character it's a bit late.
One could have that warning also trigger a message to the PAs that cause the mess.
They can fix it and submit an update before being allowed to submit any more products.
Taking time off current projects to be forced to fix the broken ones that are already in the store should be incentive to be more careful.
A user level tool for 3rd party sites like rendo would be nice to have.
Clicking OK is the only choice given, and the warning is repeated when the scene has loaded, so there is no need and/or use to stop loading the scene until the user clicks OK.
I know, I've had this problem many times myself.
I'm trying to suggest solutions. The context in which I wrote that should have made that little more clear.
I would also like to see something like that added to the QA process - it would be quite simple to set up an automated validation process on submission where it does some of the simple checks such as:
That's far from perfect but would be so very easy to automate and sort out some of the more obvious product bugs I have seen recently.
Unfortunately, I am not sure that is likely to happen :(
I would add to this script checking for:
All this stuff should be caught when a PA submits to DAZ, and summarily rejected on day one of acceptance testing. Perhaps the script could be made available to PAs, as well, so they wouldn't submit cr** like this.
http://docs.daz3d.com/doku.php/public/software/dazstudio/4/change_log#4_21_1_27
So, once 4.21.1.27 or greater becomes the minimum version PAs are required to use when submitting assets this issue should eventually go away? That's a relief but we still could use a tool that scans a library and flags existing products since I doubt Daz is going to employ someone to go through all the products in the store and rebuild them on that version.
Yes, that is a very good start :)