Loading...
> >

Scene Optimizer [Commercial]

1…789101113»

Comments

  • V3DigitimesV3Digitimes Posts: 3,494

    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_3dgarrett_3d Posts: 1,038

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

  • Richard HaseltineRichard Haseltine Posts: 111,777

    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?

  • V3DigitimesV3Digitimes Posts: 3,494

    garrett_3d said:

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

    Well... not really... 

  • V3DigitimesV3Digitimes Posts: 3,494

    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 HaseltineRichard Haseltine Posts: 111,777

    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.

  • V3DigitimesV3Digitimes Posts: 3,494

    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.

  • garrett_3dgarrett_3d Posts: 1,038

    You think it may be because I shared my DS4 libraries with DS6? Do you think that if I use DS6 in the future, independent libraries would be a better option?

  • DoctorJellybeanDoctorJellybean Posts: 10,182

    garrett_3d said:

    You think it may be because I shared my DS4 libraries with DS6? Do you think that if I use DS6 in the future, independent libraries would be a better option?

    That shouldn't make a difference. I have one library, and use it for both DS 4 and 6. 

  • V3DigitimesV3Digitimes Posts: 3,494

    DoctorJellybean said:

    garrett_3d said:

    You think it may be because I shared my DS4 libraries with DS6? Do you think that if I use DS6 in the future, independent libraries would be a better option?

    That shouldn't make a difference. I have one library, and use it for both DS 4 and 6. 

    No, I would not recommend separating your DS4 and DS6 content libraries just because of what I described.

    The situation I mentioned is only one hypothetical mechanism that could explain this kind of issue, and it may have absolutely nothing to do with what you actually experienced.

    For this to happen, a product would have to write persistent data into the shared content library, both DS4 and DS6 would have to read that same data, and the product would also have to lack sufficient validation or fallback if that data became invalid or corrupted.

    That probably applies to far less than 0.0001% of the content people use, so splitting entire content libraries to avoid such a tiny theoretical risk would not be reasonable in my opinion.

    I also use shared content libraries between DS4 and DS6.

    The important thing is simply to make sure that, if a particular product or one of its files ever becomes corrupted, you have a way to reinstall or restore it.

     

  • jmucchiellojmucchiello Posts: 2,398

    garrett_3d said:

    You think it may be because I shared my DS4 libraries with DS6? Do you think that if I use DS6 in the future, independent libraries would be a better option?

    I think it would drive you to madness because there's only one DIM. You would have to constantly tell it which library to install into. When I had drive space issues I tried splitting my library onto two drives. It drove me batty. (Not saying I'm not batty now)

    Share the content library.

  • Richard HaseltineRichard Haseltine Posts: 111,777

    You could as a test save the current content directory set in DS 4 up (via Edit>Preferences>Content>Content Directory Manager, highlight Curent and then click the Copy button on the left) then set up a temportary content directory set under curent, install the script and some content to that, and see if the script now works. Then switch back to your regular content directories by checking them, instead of Curent, in Content Directory Manager

  • garrett_3dgarrett_3d Posts: 1,038

    jmucchiello said:

    garrett_3d said:

    You think it may be because I shared my DS4 libraries with DS6? Do you think that if I use DS6 in the future, independent libraries would be a better option?

    I think it would drive you to madness because there's only one DIM. You would have to constantly tell it which library to install into. When I had drive space issues I tried splitting my library onto two drives. It drove me batty. (Not saying I'm not batty now)

    Share the content library.

    As it stands, if I use DS6 again, it will be on a different PC so that shouldn't be an issue yes

Sign In or Register to comment.