Hi Bobi - I think we’ve got the move to zero problem, and how you would prefer it, pinned down. (The distance it moves is not random, it may not be very useful, but it us not random as far as I can see: it uses the ponter location as the From point and I can see that there may be arguments for not changing this, but as I said, I’ll ask)
RH-68316 SetPt: Make zero always be snappy
Perhaps.
-Pascal
Hi @pascal , based on my observations on that bug, when I set 0 in the Command line, it moves the object to at least 5 different distances each time. 
What’s interesting, though, is that no matter where I press the arrow handle, those few random distances repeat after several trials. It’s especially noticeable when I turn off the Grid snap. One random distance may be 12,41 mm, the next one may be 9,93, the next may be 11,04, then the first one repeats again at 12,41 mm, then 11,04 again, and so on. No matter if I drag the object to the positive or negative direction of the arrow handle, or if I click on the tip or 5 pixels away from it, those few numbers repeat over the time and I still fail to understand what’s the logic behind this particular behaviour since the 0 in the Command line is an exact number which is typically used to set the movement to the center of the CPlane.
I didn’t know that before. Thanks for mentioning.Very useful.
It’s those “hidden” gems that make working effictively so much easier.
I still think the idea I posted a while ago about implementing percentage of the current selection would make a lot of sense in some cases. But as with many (good ?) ideas that suggestion drowned in the sea of too many other requests.
Thank you for taking this improvement into consideration, @pascal ! Being able to center the geometry with the Gumball’s arrow handle in a consistent and predictable way is a real game changer.
Wow, that was quick! Is there any chance to add the fix to Rhino 7’s Gumball, as well? I guess it’s just a matter of copying a portion of the code that’ already available to the Snappy dragging. Thanks!
Hi -
Nope. At this point, only crash bugs are ported to Rhino 7.
-wim
Is not that considered a bug? It’s literally an inconsistent moving of objects at totally random distances each time that lead to inaccuracy. Entering 0 as a distance moves an object by 3,96 mm, then entering 0 again moves it by 1,04 mm, then entering 0 again moves it by 12,07 mm. Looks extremely buggy to me.
It’s not an issue that is crashing Rhino.
-wim
But it surely crashes the workflow and accuracy of the Rhino users. Not trying to argue, just saying facts. I often see many other bugs being fixed every couple of weeks with the new service releases of Rhino 7, even though they do not crash it.
No… it was working as designed as far as I can see . As I mentioned, the movement is dependent on the pointer location on the gumball handles. The change is an enhancement, to be sure, but back porting is avoided at this stage of V7 development, as there may be unintended consequences.
-Pascal
What are those unintended consequences? I see that Rhino 8 WIP already have it fixed quickly, since that was already in the code of Rhino 7’s Snappy dragging. It’s a matter of minutes or hours to transfer it to the Smooth dragging, as your programmers already did with Rhino 8’s Gumball a day ago. I was surprised that the fix for Rhino 8 was so quick. Good job! It’s pity that you don’t want to fix Rhino 7’s Gumball the same way…
I will repeat myself, that there is nothing accurate or predictable in moving objects at totally random distances every time a 0 is being set as a coordinate. This is clearly a huge bug directly causing unwanted inaccuracy and could lead to issues with important projects. I write that as someone who actually works on these and see the issues first hand.
Over the years I have been very impressed with the bug fixes and the willingness of the developers to make Rhino better. However, this particular bug is really annoying, because it literally leads to errors and wrong distances that are not relative to the exact numerical input. For the first time ever I see the developers refuse to fix a bug of such a giant caliber. It was officially reported as a bug and is already fixed for Rhino 8 WIP, yet it’s still present in Rhino 7 and continues to destroy the modeling precision.
Wait, if I select an object and click on a gumball axis arrow then type a number it moves that distance.
For what it’s worth if you select an object, click and drag the gumball from the center point and type 0 it moves the object to 0,0,0.
If I drag an object via the arrow habdle of Gumball and type 0, Rhino 7 will move the former by some random inaccurate distance that does not make any sense and will lead to errors. That random distance is different each time and compromises the accuracy Rhino is known for. The bug is already fixed in Rhino 8 WIP but unfortunately at this very moment is still present in Rhino 7.
What happens if you type a number other than 0?
If “Smooth dragging” is active, typing any number other than 0 will move the object at the exact numerical distance. The bug with inaccurate moving of the object at random location only happens if you type 0. However, if “Snappy dragging” is active, typing 0 will move the object at the CPlane 0, which is the correct way. That also applies while moving with the “Move” tool and the direction is locked via tapping the Tab key before typing 0. Only the “Smooth dragging” mode produces that inconsistency.
What Bobi is pointing is correct.
I don’t use the Gumball that way so I have no opinion about the frustration involved with this scenario.
But after reading the up comments, I find not very logical to end up with two different behaviors when using the same tool to do the same operation but in another fashion ( smooth or snappy dragging here ).
Regards
R.Santos
Exactly! The bug literally causes crucial errors related to the positioning of objects, which is the worst bug a NURBS modeling and engineering program could have.
