Looks like there is some bug while dragging an object with one of the 3 Gumball arrow handles and setting a 0 to the used direction. Every time I do this, Rhino 7 will move the object in a different, totally random location that’s not the exact zero of the active CPlane. Тhat bug should be fixed as it leads to unwanted inaccuracy. Typing zero while dragging with the Gumball’s arrow should always move the selection to the zero of the CPlane in the chosen direction.
Hi Bobi,
I’m probably missing something basic here, but typing a number whilst dragging surely sets the distance to move, not the location to move to. Typing 0 is effectively saying “go back to where you started dragging from”, isn’t it?
Regards
Jeremy
Hi @jeremy5 , I think that in this case it’s more logical to drag the selection to the CPlane 0, because resetting is already done either via the Esc key or pressing the RMB while dragging with the LMB, so there are already two ways to cancel the dragging.
The current implementation is wrong in my opinion, because typing 0 in the Command line while dragging with the Gumball actually moves the selected object(s) to some totally random distance which is different every time. 
Well, I’ve learnt something. Typing a number while dragging does set position, not distance. Never knew that (wish I had done, long ago). Seems on a quick test, to work ok in the orthogonal views - it’s only incorrect if done when dragging in the perspective view. Is that what you found?
Yes, 99% of the time I work in Perspective view, so that bug with moving the objects at random distance while typing 0 is really a big issue to me as I use Gumball as my main moving tool.
Hi Bobi- this should work - if you wait long enough for an OSnap to light up on dragging - is that what you mean? I find the lad just a micron too long for easy OSnap dragging - you can set this with
testDragOsnapDelay (in miliseconds, default is 250, I like 150) This should probably be an ‘Advanced’ setting but I do not think it is so it needs to be in your startup commands. If I find it in Advanced, I’ll shout.
Is that it, or is there more to this?
-Pascal
Hi @pascal, the problem is that each time I try to move the selected object with the Gumball writing 0 in the Command line, Rhino moves it at some random distance that will not correspond to the number I entered. If you try do to the same with the “Move” tool while Ortho is active and then lock the direction with the Tab key, you will notice that Rhino will conveniently set the object at the active CPlane’s 0. Gumball should be able to do that, as well.
Here is a comparison between both input methods. While recording the video, I also found another bug that causes the text objects to always appear with visible surface isocurves even though I opted those to be hidden from the General settings.
P.S. The processing of the video will take a while before it becomes visible.
Hi Bobi - Snappy dragging needs to be on in the Gumball settings for that to work but it should work, in the axis you chose, that is, not necessarily to the origin in all axes of course.
-Pascal
Hi @pascal , I’m aware of the Snappy dragging, but I think that the Smooth dragging also should be able to move the selected object to the CPlane 0 in the same way after typing 0 in the Command line. Is there any chance to fix that behaviour in the coming weeks or months?
Honestly, I see no benefit in moving the object by a random distance each time, which is totally unpredictable (kind of a 3d Russian roulette 
) and destroys the accuracy expected by Rhino.
Hi Bobi - what would go to the origin, the Gumball origin? (basically make it snappy for that one operation?) I think what is happening now is the grab point on the gumball goes to zero.
-Pascal
Yes, the Gumball origin. It should act exactly like:
a) the Snappy dragging while typing 0 in the Command line. Basically moving the selected object to the active CPlane’s 0 coordinate in the desired direction (depending which one of the 3 arrow handles is being used). This particular approach is very useful for convenient moving of symmetrical objects, flat surfaces (or blueprints), curves, points etc to the center of the CPlane only in one direction, eliminating the need to lock the latter with the Tab key since the 3 arrow handles already lock the direction along x, y or z;
b) the manual dragging with the “Move” tool while the direction is being locked with the Tab key (as I showed at the 4:50 minute in my video above).
OK - well I guess the difference is the ‘from’ point… without snappy gumball, the from point is the mouse location on the gumball handle. It could be that in this special case ‘0’ can be interpreted as acting in snappy mode, since it does not have any utility in a distance constraint. I don’t know - I would not expect a lot of traction on this idea among developers but it is always possible. I’ll ask…
-Pascal
Trust me, making this act like the Snappy dragging while 0 is entered in the Command line is both, very useful during technical modeling, and much better than ending up with an object moved by a totally random distance which basically has only disadvantages and leads to loss of precision. The center point of the Gumball should be considered as the zero point that will be moved along the x-, y- or z-axis depending which arrow handle is used. Snappy dragging with Gumball already does that, so this should be easy to implement into the Smooth dragging, too.
Given that it already seems to work in the orthogonal views and only fails in perspective, we can hope that most of the code is already there… This is just about bringing consistency to the behaviour.
Exactly! It’s proven to work perfectly fine with the “Snappy dragging” setting where typing 0 in the Command line moves the selected object to the 0 of the CPlane in the same direction as the arrow handle, so the code is already there and just needs to be implemented in the “Smooth dragging” setting as well.
Also, grabbing the center point of the Gumball, pressing the Tab key to lock the direction, typing 0 in the Command line and hitting Enter does exactly what’s expected, so it seems like it’s a matter of minutes to add that same code to the arrow handle. However, it’s far less convenient to use the center point of Gumball, because of 4 main reasons:
Corrected
0 typed in response to a request for a location usually means the Cplane origin, the same as typing 0,0,0. For the world origin type w0. 0 is fundamentally different than typing 1 or other non-zero number which is usually interpreted as a distance constraint.
Thanks David, but I believe you will find that typing 0 on the command line in response to a location request will place the item at the CPlane origin, which may well not be the the World origin.
Hi Jeremy- as far as I can see the system as it is now works the same in all views. The pointer location is used as the from point to move to zero in that axis - the difference may be that that point’s location in 3d is more precise in an ortho view.
-Pascal
Jeremy is correct. I made a mistake which I’ll correct.
Type w0 for the world origin.
If you click on an object and start dragging it, then type 0 and enter will continuing to hold down the mouse button, the object will move so that the location on the object where you clicked is at the Cplane origin.
If you click on an object and start dragging it, then type a number other than zero and enter will continuing to hold down the mouse button, the object will be constrained so that the location on the object where you clicked is at typed distance from its original position.
As I mentioned above, I see two main issues here:
Also, clicking on the arrow handle and typing 0 in the pop-up numerical field does nothing. It would be nice if typing 0 there would move the center of the object to CPlane 0.