Carrara 8.5 Is there a bugs list anymore like we had in mantis?

3dOutlaw3dOutlaw Posts: 2,471
edited September 2013 in Carrara Discussion

Now that we are Zendesk bound...

Has anyone gotten any feedback that we will be able to see a "known issues" list? That way we can look before posting the same problems again and again? It would really save time knowing that a problem I see is a bug, and not trying to get help, make it work, wait for an answer, etc...

If not, and people know of "new" confirmed issues, should we catalog them in a common thread?

Post edited by 3dOutlaw on
«1

Comments

  • frank0314frank0314 Posts: 14,030
    edited December 1969

    Bugs still need to be reported through Zendesk otherwise that can't be looked into.

  • 3dOutlaw3dOutlaw Posts: 2,471
    edited December 1969

    Yes, that is correct...but do you have any idea about my original questions?

  • frank0314frank0314 Posts: 14,030
    edited December 1969

    I don't know if you get feedback or not. I haven't actually filed a bug report yet.

  • thoromyrthoromyr Posts: 452
    edited December 1969

    3doutlaw said:
    Now that we are Zendesk bound...

    Has anyone gotten any feedback that we will be able to see a "known issues" list? That way we can look before posting the same problems again and again? It would really save time knowing that a problem I see is a bug, and not trying to get help, make it work, wait for an answer, etc...

    If not, and people know of confirmed issues, should we catalog them in a common thread?

    Have you gone to report a bug? Unless things changed suddenly you can review reported bugs. Regrettably, being user submitted they often don't have meaningful titles (and some people report bugs in the forums, others have usage questions reported as bugs). You could, I think, filter based on ones that have been acknowledged -- that would make it a "known issue".

    You could also peruse the bug list just because if that's your case. I don't make a habit of it, but just like I try to read some of the front page threads before starting a new one, I sometimes read bug reports before reporting one. And, once, I was able to help someone.

  • 3dOutlaw3dOutlaw Posts: 2,471
    edited September 2013

    Yes, I have submitted 3 possible bugs. One was closed, due to the implementation of Fast Mip-Map causing a 3rd party plugin to fail, and the "solved" reason was that the 3rd party plugin needed to fix it.

    One was submitted 2 or so days ago, the other yesterday. Still processing.

    There is no way to review reported bugs anymore that I am aware of. You now submit possible bugs via a support ticket.

    Post edited by 3dOutlaw on
  • DAZ_SpookyDAZ_Spooky Posts: 3,100
    edited December 1969

    3doutlaw said:
    Now that we are Zendesk bound...

    Has anyone gotten any feedback that we will be able to see a "known issues" list? That way we can look before posting the same problems again and again? It would really save time knowing that a problem I see is a bug, and not trying to get help, make it work, wait for an answer, etc...

    If not, and people know of confirmed issues, should we catalog them in a common thread?

    The known issues list is in the Product readme.
  • 3dOutlaw3dOutlaw Posts: 2,471
    edited December 1969

    Sorry, I meant issues that are found since release. (or are you adding to that product readme?)

    Is that list linked on site, or only delivered with the product?

  • DAZ_SpookyDAZ_Spooky Posts: 3,100
    edited December 1969

    3doutlaw said:
    Sorry, I meant issues that are found since release. (or are you adding to that product readme?)

    Is that list linked on site, or only delivered with the product?

    Linked on the site. There haven't been any major issues discovered since release. At least not yet. :)
  • thoromyrthoromyr Posts: 452
    edited December 1969

    3doutlaw said:
    Now that we are Zendesk bound...

    Has anyone gotten any feedback that we will be able to see a "known issues" list? That way we can look before posting the same problems again and again? It would really save time knowing that a problem I see is a bug, and not trying to get help, make it work, wait for an answer, etc...
    ack! I didn't think it'd been that long since i was in the bug tracker.

    If not, and people know of confirmed issues, should we catalog them in a common thread?
    The known issues list is in the Product readme.

    Unless the product readme is continuously updated it doesn't do much good for checking to see if an issue exists. Further, it doesn't help in the event that a bug report hasn't been evaluated yet where a reporter might add additional information.

    Instead of being collaborative, it is a one way entrance to a black box. Ugh. I can understand wanting to filter through the help desk because of the usage issues being reported as bugs, but this seems like throwing the baby out with the bath water.

  • thoromyrthoromyr Posts: 452
    edited December 1969

    3doutlaw said:
    Sorry, I meant issues that are found since release. (or are you adding to that product readme?)

    Is that list linked on site, or only delivered with the product?

    Linked on the site. There haven't been any major issues discovered since release. At least not yet. :)

    What about minor issues? Or should those just get reported repeatedly? Or are they not fixed? Release notes tend to focus on major issues and that is fine, but minor issues are still issues.

  • DAZ_SpookyDAZ_Spooky Posts: 3,100
    edited December 1969

    thoromyr said:
    3doutlaw said:
    Now that we are Zendesk bound...

    Has anyone gotten any feedback that we will be able to see a "known issues" list? That way we can look before posting the same problems again and again? It would really save time knowing that a problem I see is a bug, and not trying to get help, make it work, wait for an answer, etc...
    ack! I didn't think it'd been that long since i was in the bug tracker.

    If not, and people know of confirmed issues, should we catalog them in a common thread?
    The known issues list is in the Product readme.

    Unless the product readme is continuously updated it doesn't do much good for checking to see if an issue exists. Further, it doesn't help in the event that a bug report hasn't been evaluated yet where a reporter might add additional information.

    Instead of being collaborative, it is a one way entrance to a black box. Ugh. I can understand wanting to filter through the help desk because of the usage issues being reported as bugs, but this seems like throwing the baby out with the bath water.It is coming. We are waiting on a Zendesk update, so I can't give you a time frame but it is high on our priority list, and you will see the change ASAP after their update is done.

  • DAZ_SpookyDAZ_Spooky Posts: 3,100
    edited December 1969

    thoromyr said:
    3doutlaw said:
    Sorry, I meant issues that are found since release. (or are you adding to that product readme?)

    Is that list linked on site, or only delivered with the product?

    Linked on the site. There haven't been any major issues discovered since release. At least not yet. :)

    What about minor issues? Or should those just get reported repeatedly? Or are they not fixed? Release notes tend to focus on major issues and that is fine, but minor issues are still issues.Haven't seen more than a couple of those either. One about the difference between Carrara and Poser Point at, and something else I don't remember off hand.

  • 3dOutlaw3dOutlaw Posts: 2,471
    edited December 1969

    In case anyone is looking, I found the product readme online: http://docs.daz3d.com/doku.php/public/read_me/index/16777/start

    :)

  • DartanbeckDartanbeck Posts: 21,522
    edited December 1969

    3doutlaw said:
    In case anyone is looking, I found the product readme online: http://docs.daz3d.com/doku.php/public/read_me/index/16777/start

    :)

    Thanks! It also has a link to the 8.5 documentation wiki, which has installation instructions whether using DIM or not. Very cool. This DAZ_jared sure is great at this stuff. Hey, thanks for the heads up and the link, 3doutlaw!
    btw, is it rude to say: "I like your avatar graphic"? I hope not. If not... that's what I'm saying. If so, forget I was ever here! LOL
  • thoromyrthoromyr Posts: 452
    edited December 1969

    It is coming. We are waiting on a Zendesk update, so I can't give you a time frame but it is high on our priority list, and you will see the change ASAP after their update is done.

    Glad to hear it is viewed as an issue, sounds good to me!

  • olafolaf Posts: 4
    edited December 1969

    how to get presets and landscapes to not be greyed out?

  • thoromyrthoromyr Posts: 452
    edited December 1969

    olaf said:
    how to get presets and landscapes to not be greyed out?

    see this thread, but the short of it is that Presets and Scenes folders were erroneously created in the application directory rather than in the application bundle. The DAZ recommended fix is to use symlinks to correct this so that later content updates via DIM will correct it.

  • stem_athomestem_athome Posts: 518
    edited December 1969

    thoromyr said:
    What about minor issues? Or should those just get reported repeatedly? Or are they not fixed? Release notes tend to focus on major issues and that is fine, but minor issues are still issues.Haven't seen more than a couple of those either. One about the difference between Carrara and Poser Point at, and something else I don't remember off hand.

    So all previously reported bugs for all version prior to 8.5 over the last several years have now been fixed in 8.5? That is great to hear if correct.
    So anyone who ever reported a bug can now try 8.5 and find that reported bug fixed, that is amazing.

    OR,

    Is it more a case that all previously reported bugs have now been dismissed with old bug tracker, and the bugs will have to be re-submitted?

  • DAZ_SpookyDAZ_Spooky Posts: 3,100
    edited September 2013

    thoromyr said:
    What about minor issues? Or should those just get reported repeatedly? Or are they not fixed? Release notes tend to focus on major issues and that is fine, but minor issues are still issues.
    Haven't seen more than a couple of those either. One about the difference between Carrara and Poser Point at, and something else I don't remember off hand.

    So all previously reported bugs for all version prior to 8.5 over the last several years have now been fixed in 8.5? That is great to hear if correct.
    So anyone who ever reported a bug can now try 8.5 and find that reported bug fixed, that is amazing.

    OR,

    Is it more a case that all previously reported bugs have now been dismissed with old bug tracker, and the bugs will have to be re-submitted?

    Neither. We still have access to Mantis, even though you don't. You will not get feedback from Mantis any longer as it is no longer connected to an E-Mail system. If you want direct feedback on a bug, instead of just watching the change log for a particular bug, then please resubmit the bug using the new system.

    Post edited by DAZ_Spooky on
  • DAZ_SpookyDAZ_Spooky Posts: 3,100
    edited December 1969

    thoromyr said:
    olaf said:
    how to get presets and landscapes to not be greyed out?

    see this thread, but the short of it is that Presets and Scenes folders were erroneously created in the application directory rather than in the application bundle. The DAZ recommended fix is to use symlinks to correct this so that later content updates via DIM will correct it.Also note that there are three, for Pro, two for Standard, products that are called Native Content. If you don't have "Carrara Native Content for Carrara 8.0" installed you will get the same results.

  • stem_athomestem_athome Posts: 518
    edited September 2013

    So all previously reported bugs for all version prior to 8.5 over the last several years have now been fixed in 8.5? That is great to hear if correct.
    So anyone who ever reported a bug can now try 8.5 and find that reported bug fixed, that is amazing.

    OR,

    Is it more a case that all previously reported bugs have now been dismissed with old bug tracker, and the bugs will have to be re-submitted?

    Neither. We still have access to Mantis, even though you don't. You will not get feedback from Mantis any longer as it is no longer connected to an E-Mail system. If you want direct feedback on a bug, instead of just watching the change log for a particular bug, then please resubmit the bug using the new system.

    So, there are still outstanding bugs/ issues from previous versions, and DAZ knows what they are. So why are they not listed as "Known Issues" on the docs page?

    Post edited by stem_athome on
  • TerritanTerritan Posts: 76
    edited December 1969

    thoromyr said:
    see this thread, but the short of it is that Presets and Scenes folders were erroneously created in the application directory rather than in the application bundle. The DAZ recommended fix is to use symlinks to correct this so that later content updates via DIM will correct it.
    Also note that there are three, for Pro, two for Standard, products that are called Native Content. If you don't have "Carrara Native Content for Carrara 8.0" installed you will get the same results.

    I got Carrara 8.5 Pro, and I have "Carrara 8 Native Content" and "Carrara 8.5 Native Content" showing in DIM. Does this mean I should also be seeing a "Carrara Native Content for Carrara 8.0" as well? Because this might go to explain some of the other problems I'm seeing too.

    Also, there are cases where it's very bad to install content within the application bundle, like when the application needs the user to point at it (Mimic is the most recent case in point). It's impossible for the open file dialog (by itself) to open files within bundles. It's also impossible to save files within bundles by themselves, so the "User Scenes" folder might not see much use. This was an issue I reported back in the days of C7.

    And come to that, there are certain other packages I know I've purchased over the years that I'm not seeing within DIM. Is this something I should ask about through Zendesk too?

    (On a lighter note, I just checked for an old bug that I had reported long ago involving resizing of objects and modifiers. It's been fixed. :) )

  • evilproducerevilproducer Posts: 9,050
    edited December 1969

    Territan said:

    Also, there are cases where it's very bad to install content within the application bundle, like when the application needs the user to point at it (Mimic is the most recent case in point). It's impossible for the open file dialog (by itself) to open files within bundles. It's also impossible to save files within bundles by themselves, so the "User Scenes" folder might not see much use. This was an issue I reported back in the days of C7.

    I could be wrong here, but I seem to recall the issue of putting all the presets and such goes back at least as far as C5, which would mean it would predate DAZ as that's the version Carrara was at when DAZ bought them. Not that it shouldn't get fixed.

    To get around the issue, I made an alias (shortcut).

  • DAZ_SpookyDAZ_Spooky Posts: 3,100
    edited December 1969

    So all previously reported bugs for all version prior to 8.5 over the last several years have now been fixed in 8.5? That is great to hear if correct.
    So anyone who ever reported a bug can now try 8.5 and find that reported bug fixed, that is amazing.

    OR,

    Is it more a case that all previously reported bugs have now been dismissed with old bug tracker, and the bugs will have to be re-submitted?

    Neither. We still have access to Mantis, even though you don't. You will not get feedback from Mantis any longer as it is no longer connected to an E-Mail system. If you want direct feedback on a bug, instead of just watching the change log for a particular bug, then please resubmit the bug using the new system.

    So, there are still outstanding bugs/ issues from previous versions, and DAZ knows what they are. So why are they not listed as "Known Issues" on the docs page?That would be a Marketing decision. The ones deemed important, that would impact most users in a major way, are the ones that were listed.

  • DAZ_SpookyDAZ_Spooky Posts: 3,100
    edited December 1969

    Territan said:

    Also, there are cases where it's very bad to install content within the application bundle, like when the application needs the user to point at it (Mimic is the most recent case in point). It's impossible for the open file dialog (by itself) to open files within bundles. It's also impossible to save files within bundles by themselves, so the "User Scenes" folder might not see much use. This was an issue I reported back in the days of C7.

    I could be wrong here, but I seem to recall the issue of putting all the presets and such goes back at least as far as C5, which would mean it would predate DAZ as that's the version Carrara was at when DAZ bought them. Not that it shouldn't get fixed.

    To get around the issue, I made an alias (shortcut).On a Mac, that is, technically, where it belongs. On Windows that is not where it belongs, anymore. Yes, it needs to move, or at least the location for User files needs to move. Yes, we know it needs to move. Unfortunately it is much more complex than it appears to be on the surface. We have been trying to figure out how to free up the dev time to get this done since Carrara 7.1.

  • TerritanTerritan Posts: 76
    edited December 1969

    On a Mac, that is, technically, where it belongs. On Windows that is not where it belongs, anymore. Yes, it needs to move, or at least the location for User files needs to move. Yes, we know it needs to move. Unfortunately it is much more complex than it appears to be on the surface. We have been trying to figure out how to free up the dev time to get this done since Carrara 7.1.

    [citation needed]

    I'm looking for chapter and verse in the docs right now, but what I gather so far is that as a rule of thumb, the application bundle should only contain those files that the application either (a) can't run without, like actual program resources, or (b) has to get frightfully cozy with, like plug-ins and extensions.

    The extensions folder belongs in there, but the object library data does not. There are other places, like the /Library/Application Support folder, the user-specific ~/Library/Application Support folder, or the /Users/Shared/ folder, where shared optional user-accessible resources can be placed. And interestingly, Daz already tries to put some stuff in the shared folder. Daz even has files in the /Library/Application Support folder, albeit only for a thing called the Content Management System. (Ironic, if you think about it.)

    And it's not written anywhere that I can find, but there's another rule of thumb at work here: If you're going to ask the user to find a specific file, using a file dialog that can't possibly access that file without strictly counter-intuitive outside help, that is what's known in the industry as a "dick move." I'm not trying to be vulgar here; I believe that is the actual scientific term. It could almost be the textbook definition. At the very least, it's "setting them up for failure."

  • DAZ_SpookyDAZ_Spooky Posts: 3,100
    edited December 1969

    Territan said:
    On a Mac, that is, technically, where it belongs. On Windows that is not where it belongs, anymore. Yes, it needs to move, or at least the location for User files needs to move. Yes, we know it needs to move. Unfortunately it is much more complex than it appears to be on the surface. We have been trying to figure out how to free up the dev time to get this done since Carrara 7.1.

    [citation needed]

    I'm looking for chapter and verse in the docs right now, but what I gather so far is that as a rule of thumb, the application bundle should only contain those files that the application either (a) can't run without, like actual program resources, or (b) has to get frightfully cozy with, like plug-ins and extensions.

    The extensions folder belongs in there, but the object library data does not. There are other places, like the /Library/Application Support folder, the user-specific ~/Library/Application Support folder, or the /Users/Shared/ folder, where shared optional user-accessible resources can be placed. And interestingly, Daz already tries to put some stuff in the shared folder. Daz even has files in the /Library/Application Support folder, albeit only for a thing called the Content Management System. (Ironic, if you think about it.)

    And it's not written anywhere that I can find, but there's another rule of thumb at work here: If you're going to ask the user to find a specific file, using a file dialog that can't possibly access that file without strictly counter-intuitive outside help, that is what's known in the industry as a "dick move." I'm not trying to be vulgar here; I believe that is the actual scientific term. It could almost be the textbook definition. At the very least, it's "setting them up for failure."Requirement for submission to the Mac Store. Everything shipped with the App belongs in the .app.

  • TerritanTerritan Posts: 76
    edited December 1969

    Requirement for submission to the Mac Store. Everything shipped with the App belongs in the .app.

    It's most likely a requirement that the app ship as a single bundle when it's first downloaded, but when first opened, it can run its own installer which moves files and writes information from within the bundle to other locations where the user might need to get to it. Here's what I found in relation to that:

    Your application may write to the following directories:
    ~/Library/Application Support/
    ~/Library/
    ~/Library/Caches/

    where is your application's bundle identifier, its name, or your company’s name. This must exactly match what is in iTunes Connect for the application.

    Always use Apple programming interfaces such as the URLsForDirectory:inDomains: function to locate these paths rather than hardcoding them. For more information, see File System Programming Guide.


    (Reference: OS X 10.7 Core Library > General > Submitting to the Mac App Store > File-System Usage Requirements for the Mac App Store)

    On the other hand, you've opened a fascinating new can of worms with that reference. Please, tell me more about Daz's pending submission of Carrara to the Mac App Store.

  • DAZ_SpookyDAZ_Spooky Posts: 3,100
    edited December 1969

    Territan said:
    Requirement for submission to the Mac Store. Everything shipped with the App belongs in the .app.

    It's most likely a requirement that the app ship as a single bundle when it's first downloaded, but when first opened, it can run its own installer which moves files and writes information from within the bundle to other locations where the user might need to get to it. Here's what I found in relation to that:

    Your application may write to the following directories:
    ~/Library/Application Support/
    ~/Library/
    ~/Library/Caches/

    where is your application's bundle identifier, its name, or your company’s name. This must exactly match what is in iTunes Connect for the application.

    Always use Apple programming interfaces such as the URLsForDirectory:inDomains: function to locate these paths rather than hardcoding them. For more information, see File System Programming Guide.


    (Reference: OS X 10.7 Core Library > General > Submitting to the Mac App Store > File-System Usage Requirements for the Mac App Store)

    On the other hand, you've opened a fascinating new can of worms with that reference. Please, tell me more about Daz's pending submission of Carrara to the Mac App Store.Their QA made us do it when we put Bryce in the App Store. It isn't pending, it has been there for a while.

  • TerritanTerritan Posts: 76
    edited December 1969

    Their QA made us do it when we put Bryce in the App Store. It isn't pending, it has been there for a while.

    For the reason cited above—it needs to download as a single bundle if it's coming from the Mac App Store, but once it's down and running it can run its own installer and move files out of the bundle and to other approved locations within the system.

    And in those cases where the user may need to point the program somewhere with the open file dialog, it absolutely should.

    Additionally, you have your own CMS. You're not using the Mac App Store to distribute Carrara. You probably ought to follow more of their guidelines for the whole user experience thing, but Carrara would be much more comfortable with those libraries in the folder with the app.

    At times like this, I like to point to Reason. Wildly successful, doesn't distribute through the Mac App store, uses an application bundle, and still stores the user accessible data in a folder with the application (outside the bundle). Also, it has a pretty darned vibrant "Rack Extension" architecture (essentially plug-ins which add devices to the virtual rack) introduced officially in Reason 6.5... and those are all stored in ~/Library/Application Support/Propellerhead Software/Rack Extensions.

    It's a different branch of the creative arts, but you could learn a few things studying that program. Oh, and the demo is a free download. Does everything except save.

Sign In or Register to comment.