I know that many bugs reported are either not really critical, or a simple workaround can be found, or it’s a video card problem or something like that. But there are also still some more critical issues
As you said yourself: there are still many bugs reported. Like this one.from Holo. PDF draw order bug still O.k. we maybe found a workaround.
I’m just saying, that I think it is wrong to say we are at R15, we completely stop repairing bugs, and let the people wait for V7 to be released. If something is affecting pdf communication or data exchange it needs a bit higher priority I believe.
Otherwise Rhino can get a reputation of not beiing suitable for “real” production. That could hurt Mc Neel as a company as well as many users that are producing data for production.
Every bug I’ve reported here is a regression from R5. Every single thing is working in R5 as intended and not in R6. I’m only going to post these 3 that are critical to our workflows:
Obviously this one RH-52539 as we’re branching into using blocks more and more. Including 3D geometry.
This RH-52277 is just a productivity & habit issue. It feels wrong to force 26 people here relearn to use Ctrl+“other than V” to paste and move.
And this one has been logged and I guess deleted? RH-52583
Thank you for considering!
I completely gave up on text masking. There’s too many issues with it in R6 and non existent command/method support.
The issue here is - we don’t want to come to work one day and R7 WIP license is expired and we have to scramble to either make things work for buggy R6 or shell out for TWENTY SIX seats of R7 just to fix the bugs. If you’re saying that we can use R7 WIP 'till the end of days, this talk shouldn’t even be happening and I should be installing 26 seats of R7 WIP right now.
These are your words “As you might have noticed, there’s no shortage of bug reports on this forum. Prioritization is hard”.
If that is the case why was Rhino 6 even released then. About the only things that that comes to mind that 6 does way better then 5 is rendering and video. Granted I don’t use 6 that much because I need to get work done and don’t have time to fool around with annoying little problems, nor do the 4 members of my group who have Rhino 5.
Thank you for helping us prioritize. This is very helpful.
We’re investigating this one now. It’s likely to be fixed by @stevebaer, as it’s already fixed in V7. He’s also on vacation at the moment.
This isn’t a regression from V5 - it worked that way in V5, too, at least according to comments in that bug. I understand that it’s annoying.
It’s not deleted, it was just visible to our developers only. It appears that there is already a fix in 6.15 for it? I’m having a hard time interpreting @lowell’s comments - can you please try with a 6.15 build?
No, but by the same token, we are willing to make much more significant changes in the WIP than we are in service releases. So if you report bugs in the WIP, and ask for big changes, they’re more likely to happen here. If you wait until 7.15 to start logging bugs, we’ll be back where we are today - stuck in a pretty stable product that we’re not willing to do major surgery on. Of course it’s up to you how much you want to engage.
Can you send a V5 3dm file that reads incorrectly into V6 with the detail marker justification problem? If possible, please send a small file that only reproduces that problem.
Because the features we did add, and the fixes we did make, were worthwhile to other customers to buy. Again, if Rhino 6 doesn’t work for you, please don’t upgrade. We don’t want your money for something that doesn’t make your life better. We also offer a 100% money-back guarantee - if you’re dissatisfied with your purchase of Rhino 6, please return it to your reseller - no questions asked.
And, we’ve tried to make Rhino affordable enough that you can upgrade for a few things and still feel like you got some value. In this case, maybe that’s not true - only you can decide whether it was worth buying. Careful: if you bought at a discount when Rhino 6 first came out, that offer is now gone. If you return today and upgrade later, you’ll pay full price.
RH-52583 is not fixed in 6.15. It’s marked Awaiting Dependency. It is fixed in an unmerged branch of 7.x to the point of being testable internally via a test command, but requires an interface change in the DimStyle and Leader properties dialogs to be completely done. That’s why it’s in 7.x instead of 6.x.
The dependency is that there was a change needed in v6 file reading of DimStyles that didn’t show up until the fix for RH-52583 that would have caused some leaders to not be editable in 6.x. That bug is fixed in 6.15 and when a SR containing that fix is out, I’ll either fix the dialog stuff or ask Alain to do it and commit the fix for RH-52583 in 7.x
We don’t want our money back, We really only want Rhino 6 to work as well as Rhino 5. There is a Rhino loyalty factor here.
When Rhino 6 went on sale I knew there was some issues as I had been using WIP on and off for a year or so before it became Rhino 6, and would update version as they were published. There were at times updates almost daily.
I knew there were issues when I bought the new version. I am sure I am not alone in that. I believed that they would be addressed in time and life would go one. But at this date I should be able to open any step file in Rhino 6 especially if it opens in Rhino 5 (RH-52486) as well as do other expected things that I can do in Rhino 5
During the WIP phase of Rhino 6, several of our most active and vocal users (not necessarily ones on this forum) suggested that the implementation of leader text alignment in Rhino 3, 4, and 5 was bad because it didn’t map well to the way AutoCAD works. They wanted to be able to transfer files between Rhino and AutoCAD with 100% fidelity using both DXF and DWG file formats.
Rhino 3, 4, and 5 only auto-aligned leader text to the tail. AutoCAD only explicitly aligns leader text left, right or center.
The change we’re making in V7 is to add back the auto-alignment functionality for leader text. There’s some significant work to make this work right, including:
Figuring out default values
Testing compatibility with Rhino 3, 4, 5, 6 (both reading old files and saving to old files)
Testing compatibility with AutoCAD and other CAD products
Making sure the UI makes sense
Because the possibility of breaking this for other customers (who requested the change in the first place) is high, and because these features have existed in Rhino 6 for several years, we’re not comfortable making the change in Rhino 6.
Admittedly, this change is a regression for you. Had you been involved during the Rhino 6 WIP phase, you might have noticed and given us some additional feedback to get it right. I strongly encourage you to be involved in the Rhino 7 WIP development. Without your voice, we’ll continue to make Rhino work for the people who are involved - and it might not be to your liking.
You’re only half right. Ctrl+Shift+C was that way. Ctrl+V in R5 was doing _Paste Zoom S Pause Pause Move for us since the time immemorial.
Look, we love Rhino and passionate about it. With all its bugs and shortcomings we’d still choose it over the monstrosity that shall not be named here. We’ve been so swamped for the past year, that only now we are able to make a window to finally shift to R6. R6 WIP was so buggy at the time we had the opportunity to explore it (a year and a half ago) I could spend days just logging and testing all kinds of bugs. And before you blame us for not being involved in WIP development again, I’m just gonna post this here: V5 vs V6 text justification
I will be helping with R7 WIP as soon everyone (26 + potentially another 4 by the end of the year) here is not “suffering” working in R6. I want to help, 'cause Rhino is the lifeblood of our engineering department, but we’d like you to help us a little in return too.
Re: Leader horizontal justification.
RIP hopes and dreams. Is there at least a way to access leader horizontal justification in python? We already use script to plop our leaders, I can make it adjust justification. Otherwise we’d probably have to have all our leaders justified by center. It’s gonna look like ass, but oh well…
Correct. Don’t worry about backwards compatibility. We don’t care for it. We’re only prepared to move forward and onward as bequeathed by great Lenin. /s
We just want surface in blocks and not print the same.
I’m just catching up on this thread as I’m supposed to be on vacation It seems like some information may have been mis-interpreted. If there is a regression in functionality in V6 for any sort of printed output, we will seriously investigate and attempt to fix the bug in a V6 service release. If the bug is easy to reproduce with a simple model, then chances are we can fix this pretty quick. Holo’s draw order bug is very hard to figure out and I doubt this even worked well in V5. That doesn’t mean I’m giving up on it as I have made some tweaks to improve his situation over time, but haven’t completely fixed the issue.
We are releasing V6 for Mac “soon” which means we will have a round of service releases for Mac. Windows users will benefit from this in that some Mac fixes will also be fixes on Windows.
We are not adding new features for V6, but we are still fixing regression bugs.