Its too soon from the history realise to be so confident. The iceberg effect maybe enacting. i.e. <1% of the iceberg is showing above water.
I’ll continue to use the workaround and wait eagerly for the fix, then test the fix on a dumming project. Thank you for the more precise and less threatening dialog.
Without the intent of convincing anyone about anything, just for the sake of record, we have a very sophisticated data infrastructure, and we are tracking the crash rate, error rate and many other quality metrics religiously. This makes it possible for us to ship a dramatically higher quality product than other CAD vendors, despite releasing new versions every 2 weeks and not just once or twice a year. We do make mistakes, and release bugs, but we fix them very quickly. That being said, I can confidently say that a small fraction of our user base has been impacted - which doesn’t make it less bad. Data corruption is unacceptable, and we had very very few issues similar to this since 2018 when Shapr3D on Parasolid was released.
My bet is the Boolean operation when stacked compounding the potential for error.
The application is not crashing. It is failing to load the history tree correctly, but not failing to load. I don’t know how that would show up in your metrics.
No, the issue that we are aware of is not related to booleans. It’s related to some of the esoteric constellations of direct modeling operations. If you have an example where a similar error occurs due to boolean operations, please let us know.
Number of feature tree errors before load, number of feature tree errors after load. Also we can compare the topology between the two states, but the details of these go a bit beyond the scope of this forum.
Do these telematics happen with cloud disabled?
Some of it does, but nothing that would tell us anything about the content or geometry or anything that we could use to tell anything about what’s actually going on in the app.
broadly whats the user % of cloud disablers?
I’m afraid I can’t share this information but fairly small. Some of our larger enterprise customers, particularly in defense, aerospace and automotive OEMs prefer to use Shapr3D without the cloud, but on average it’s a low percentage.
Understood. I am from a defense and aerospace background; I’d recommend you reach out to your non-cloud customers (without the private enterprise server) to tell them about the risks of loss without localised backup given this bug. I know how angry they will be if they suffer what I have. This would give you good kudos. Its always hard to admit a bug but boy is it worse if you tell them after the event.
Our enterprise customers always have backups. Very unfortunate that we have this issue now, but with legacy CAD it’s very common, and their infrastructure is prepared for that.
Fair enough.
Please provide a compressive written statement of what the bug-fix aims to do, relating to this common problem in loading complex large history models, planned to be released in v5.660 around July 15th. This will restore some confidence for me and inform @WeBasic , @Jon1, @mattcasper78, @HOPELESSKING, and now @Raygun, who are experiencing similar issues.
@Istvan I’ll assume you are ignoring my request for information, otherwise please advise when you can answer my request.
I don’t understand what you want to know. I shared more detail about the related bug fix that we are working on, and you responded to that. What else would you like to know?