Scene Optimizer [Commercial]

V3Digitimes

Richard Haseltine said:

garrett_3d said:

When I tried out DS6 the other week, I absently tried using some older stuff in my library with scripts. When I realised they wouldn't work, I went back to DS4. They no longer worked in DS4. Something in the process of trying to use them in DS6 rendered them inoperable. I ended up manually deleting the products and reinstalling them to make them work in DS4 again. I should probably note that they are external PA products, not from Daz store.

 I can only assume therefore, that something under the hood of DS6 overwrites any DS4 related commands in older scripts, making them no longer operational in DS4.

I am pretty certain that isn't the case, it is much more likely that there is a pathing error or possibly that soemthing else has overwritten a file.

I was also very astonished this is why I did not answer immediately (I wanted to be able to think a bit about that).
Of course encrypting a script un DS6 makes it fail in DS4, whatever the compatible version mentionned top of the script. But... How exactly a failure in DS6 could trigger a failure in DS4 is not obvious except if it writes some corrupted information in the registry before it crashes or some stuff like that (and the DS4 script does not recover from those previous data because no check or fallback)... 

garrett_3d

I have no evidence of what actually happened, but it was a Kaluma product if that helps?

Richard Haseltine

V3Digitimes said:

Richard Haseltine said:

garrett_3d said:

When I tried out DS6 the other week, I absently tried using some older stuff in my library with scripts. When I realised they wouldn't work, I went back to DS4. They no longer worked in DS4. Something in the process of trying to use them in DS6 rendered them inoperable. I ended up manually deleting the products and reinstalling them to make them work in DS4 again. I should probably note that they are external PA products, not from Daz store.

 I can only assume therefore, that something under the hood of DS6 overwrites any DS4 related commands in older scripts, making them no longer operational in DS4.

I am pretty certain that isn't the case, it is much more likely that there is a pathing error or possibly that soemthing else has overwritten a file.

I was also very astonished this is why I did not answer immediately (I wanted to be able to think a bit about that).
Of course encrypting a script un DS6 makes it fail in DS4, whatever the compatible version mentionned top of the script. But... How exactly a failure in DS6 could trigger a failure in DS4 is not obvious except if it writes some corrupted information in the registry before it crashes or some stuff like that (and the DS4 script does not recover from those previous data because no check or fallback)... 

Wouldn't Registry entries be in the DS 4 or DS 6 tree, and so not avaialble to the other version?

V3Digitimes

garrett_3d said:

I have no evidence of what actually happened, but it was a Kaluma product if that helps?

Well... not really... 

V3Digitimes

Richard Haseltine said:

V3Digitimes said:

Richard Haseltine said:

garrett_3d said:

When I tried out DS6 the other week, I absently tried using some older stuff in my library with scripts. When I realised they wouldn't work, I went back to DS4. They no longer worked in DS4. Something in the process of trying to use them in DS6 rendered them inoperable. I ended up manually deleting the products and reinstalling them to make them work in DS4 again. I should probably note that they are external PA products, not from Daz store.

 I can only assume therefore, that something under the hood of DS6 overwrites any DS4 related commands in older scripts, making them no longer operational in DS4.

I am pretty certain that isn't the case, it is much more likely that there is a pathing error or possibly that soemthing else has overwritten a file.

I was also very astonished this is why I did not answer immediately (I wanted to be able to think a bit about that).
Of course encrypting a script un DS6 makes it fail in DS4, whatever the compatible version mentionned top of the script. But... How exactly a failure in DS6 could trigger a failure in DS4 is not obvious except if it writes some corrupted information in the registry before it crashes or some stuff like that (and the DS4 script does not recover from those previous data because no check or fallback)... 

Wouldn't Registry entries be in the DS 4 or DS 6 tree, and so not avaialble to the other version?

100% right!
I wanted to simplify for the users, because "registry" is pretty well known and I was pretty sure more people would understand the principle.
In practice I thought about: some files, json or txt or else, written somewhere on you computer, and likely in your data folder, containing values required by the interface (size, location, dial values, etc), which were set "undefined" because DS6 failed (but wrote thefile) and re-read as undefined by DS4, without any fallback of any kind in the script (because never supposed to be undefined). So... "registry" was more simple but indeed basically "false"... and the ... long sentence to explain the idea is more correct but less simple for everybody. 

Richard Haseltine

V3Digitimes said:

Richard Haseltine said:

V3Digitimes said:

Richard Haseltine said:

garrett_3d said:

When I tried out DS6 the other week, I absently tried using some older stuff in my library with scripts. When I realised they wouldn't work, I went back to DS4. They no longer worked in DS4. Something in the process of trying to use them in DS6 rendered them inoperable. I ended up manually deleting the products and reinstalling them to make them work in DS4 again. I should probably note that they are external PA products, not from Daz store.

 I can only assume therefore, that something under the hood of DS6 overwrites any DS4 related commands in older scripts, making them no longer operational in DS4.

I am pretty certain that isn't the case, it is much more likely that there is a pathing error or possibly that soemthing else has overwritten a file.

I was also very astonished this is why I did not answer immediately (I wanted to be able to think a bit about that).
Of course encrypting a script un DS6 makes it fail in DS4, whatever the compatible version mentionned top of the script. But... How exactly a failure in DS6 could trigger a failure in DS4 is not obvious except if it writes some corrupted information in the registry before it crashes or some stuff like that (and the DS4 script does not recover from those previous data because no check or fallback)... 

Wouldn't Registry entries be in the DS 4 or DS 6 tree, and so not avaialble to the other version?

100% right!
I wanted to simplify for the users, because "registry" is pretty well known and I was pretty sure more people would understand the principle.
In practice I thought about: some files, json or txt or else, written somewhere on you computer, and likely in your data folder, containing values required by the interface (size, location, dial values, etc), which were set "undefined" because DS6 failed (but wrote thefile) and re-read as undefined by DS4, without any fallback of any kind in the script (because never supposed to be undefined). So... "registry" was more simple but indeed basically "false"... and the ... long sentence to explain the idea is more correct but less simple for everybody. 

It would need to be a file written to a content library, or soemthing like the Documents folder, as they also have separate AppData folders.

One test might be to lauch a new instance of DS4 with its own name and settings, which would be yet another distinct set of settings.

V3Digitimes

Yes, exactly.

When I mentioned the registry, I was really oversimplifying the idea for users. What I actually had in mind was persistent data written somewhere accessible to both DS4 and DS6, for example in a shared content library.

In particular, I was thinking of something under the usual data/Vendor/Product/... structure. I have at least one product myself that writes editable text files there, which users can modify or back up.

So, as a purely hypothetical example: a script running in DS6 could acquire an invalid value, write that value into a text/JSON/etc. file, and then fail or crash. Later, DS4 could run the same script, read that same shared file, encounter the invalid value and fail as well if the script has no validation or fallback for it.

That would create an apparent “DS6 broke the DS4 version” situation, even though DS6 had not modified DS4 itself at all. The connection would simply be the shared file in the content library. Anything stored in a regular content library does not care whether DS4 or DS6 is the application opening it.

So yes, separate AppData/settings trees would rule out a lot of possibilities, but shared content data could still provide a bridge between the two versions.

Of course, that is only one possible explanation for what garrett_3d observed, not a claim that this is what actually happened.