I need an uninstaller for DS 4.16

FrankTheTank

I have been trying to upgrade from DS 4.16 to DS 4.23. But I am facing some weird issues. The installer that I have for 4.16 is a standalone installer .exe not a DIM. There is no uninstaller for it. There is only an option under the start menu to uninstall CMS. So I went and tried to just install DS 4.23 via DIM without first uninstalling 4.16, overtop of my DS 4.16 installation, and it looked like the installation was a success.

But when I run 4.23 I have some weird issues as soon as I try to open content. Opening some files I get messages "missing texture file etc.". So I thought maybe some files got corrupted, but they didn't. The files are there, exactly where they should be, its just that DS 4.23 won't always find them on its own. So then I go and reinstall 4.16 and sure enough, the files load properly. The install paths are all default, but for whatever reason, DS 4.23 will not see all the files, only some. So I think that 4.16 is not getting uninstalled cleanly and is causing some kind of problem. Since I cannot run any version of DS right now but 4.16. I even tried to install 4.21.0.5 as well. I face the same problem wth that. NO idea how to fix this. Luckily everything is backed up.  

Richard Haseltine

I can't think of a way for that to happen - and as far as I recall the standalone and DIM install paths for applications are different anyway (though they should use the same settings). Is there any pattern to the things that load and that don't load?

One difference that dos occur to me - though I can't recall which side of the change 4.16.x.x lies (Edited to add 4.16.1.x, so yes your non-beta 4.16 would be before the change) - is the updated URI handling, where older DS was happy with an excess / in a path (e.g. "//runtime/textures/somefolder/something.jpg") while the new handler would skip the //Runtime and start looking for a textures folder in the root content directory, without sucess of course. Do the missing file messages seem to be missing the opening, or other, folder from the path?

FrankTheTank

Richard Haseltine said:

I can't think of a way for that to happen - and as far as I recall the standalone and DIM install paths for applications are different anyway (though they should use the same settings). Is there any pattern to the things that load and that don't load?

One difference that dos occur to me - though I can't recall which side of the change 4.16.x.x lies (Edited to add 4.16.1.x, so yes your non-beta 4.16 would be before the change) - is the updated URI handling, where older DS was happy with an excess / in a path (e.g. "//runtime/textures/somefolder/something.jpg") while the new handler would skip the //Runtime and start looking for a textures folder in the root content directory, without sucess of course. Do the missing file messages seem to be missing the opening, or other, folder from the path?

yes, I think that is exactly what is happening. one example here, the vendor put the path as "/textures/SASE/Sharon/SASESharonEyesB_1007.jpg" instead of the correct path of "/runtime/textures/SASE/Sharon/SASESharonEyesB_1007.jpg"

In 4.16, Daz was able to find the texure. In 4.21 and 4.23 Daz is no longer able to find it. Why did they change this? I can only imagine how much content is now going to be broken because of sloppy Renderosity vendors. 

So what is my recourse? I guess I need to manually move vendor files around to the correct places? Or is there an easier solution?

Richard Haseltine

If you open the .duf file in a text editor (you may need to uncompress it first, either using the Batch Convert  pane or an archive tool like 7Zip) I am pretty sure you will find the path is entered as "//runtime/textures/SASE/Sharon/SASESharonEyesB_1007.jpg" (and in fact that error with *.EyesB_007.jpg is the most common as it was like that ina  template file, and many PAs are careful to name their maps systematically so that they can just generate the materials files by searching and replacing the character name). The fix would be to remove the extra / at the beginning of the path - if there isn't an update for the product that has already done that.

FrankTheTank

ok. i opened one of the dufs in question with notepad++, so maybe this won't be too bad. Hopefully there aren't that many.

jjoyner

FrankTheTank said:

ok. i opened one of the dufs in question with notepad++, so maybe this won't be too bad. Hopefully there aren't that many.

As you likely know, in Notepad++ you can replace character strings one at a time in the current file, for all occurrences in the current file, or in all occurrences in all files open in Notepad++. 

Richard Haseltine

As for why the change was made, as I understand it the original handling was restrictive on what characters can be used (see the issues there have been with content using accented characters) and leaving "innocent" errors alone (such as the double /) is justr storing up  trouble for the future. Almost all the cases that have come to light have been like this, and have affected products from both stores - most affected products were updated, once the PAs became aware of the issue; it is not soemthing that is at all likely to affect files saved from DS, just cases where a file is manually edited like this (which means, in general, busy PAs streamlining their workflow rather than something individual users or PAs with low production levels are likely to do).