I have been amazed many times by the way the Move command works. What I mean is that Move always requires that one defines the starting point, even for points (!). Shouldn’t moving a point assume that the starting point is… well, the point itself?
I think so. I think the Move command should have a default starting point as the default behavior, and optionally one would specify the starting point using a commandline parameter “(define start point)”.
For non-points the current need for defining a starting point makes some sort of sense, but even with solids or lines Rhino could be a bit smarter (“intelli-sensitive”) in order to significantly speed up moving objects. For example like so:
Default Start Position: Make the (default) starting point the (gumball) center of the first selected object, or if it’s a point, make the point’s location the starting point (mimicing SetPt in that the starting point is “given”).
Commandline option: When activating the Move command and selecting object(s), the commandline option “Define start point” as an alternative means to complete the selection (on Enter §1 applies).
Default for non-Points & groups: When selecting the Move command, and if the gumball position of the first object is relocated (whether a point or not), then a default starting point would be given ((from the first object), while still providing the option to explicitly relocate the starting point according to §2.
In short, no matter how and what objects you select after activating the Move command, you can directly go to a target point - given that the default starting point is OK. If the default starting point is not OK, the option is there to (re)define it before selecting the target point. This would be a great improvement when making many moves to different positions.
Did I overlook some aspect here here?