Bug: Copy Objects with Keyboard Alt

i am wondering how i did not reach out before since this is getting in the way extremely regularly…

the problem is that when i press alt in a swift normal move in 90 Percent of the time alt does not trigger a copy but it simply moves the object making me repeat the action. yes when i take myself time focus on pressing alt long enough it works, though the plus sign often flickers not knowing if it should initiate or not and sometimes it indeed does not. my keyboard is all good i have the same issue with 3 tested keyboards,1 macbook internal and 2 external wired apple keyboards.

please guys have a look and make alt more reliable before my keyboard ends as a pankcake because it is giving me a mood…

since we are at it maybe just make copy work holding the button like in every other application out there, rhino is the only one which forces me to awkwardly tap alt making me feel like i am some sort of ballerina.

edit: i must add, once i start drag copying it seems to work better the amount of successful attempts increas, i think the problem is more when i do other work in between and then suddenly drag copy, the function sleeps in some way. which is getting in the way obviously… i can not warm up the function each time i use it.

I’m on a PC but when dragging an object, this is in the command line:

Drag objects, tap Alt to make a duplicate, press and hold Alt to temporarily toggle osnaps

If you really mean ‘press’ then I think moving the object is the expected behaviour.

well yes that wording, tapping is here used as a synonym for press and let go it is not in my muscle memory to use this word in a prima ballerina sense of way… :slight_smile: i mean tapping of course as i have written further below.

talking about it when you drag copy an object, the snaps are not working anyway unless you have snappy dragging activated for the gumball. so keeping this function makes zero sense making way for a normal alt drag copy style. or do you know of some other applications which lets you hammer the button that copy works?

I’m using the gumball for a lot of things but in some situations I prefer dragging without it. I currently have my object snaps disabled so whenever I press ALT, the snaps are temporarily enabled. It works fine for me.

I don’t understand?

which other application needs a press - release method to drag copy like in rhino? usually (meaning in other apps) it works on press without having to release.

I’d say that’s because we’re having more options while executing a command in Rhino.

Got it.

The problem is the multiplicity of actions attributed to Alt, and in this case two that are both valid in the same procedure (making a copy and toggling osnaps). So they had to choose a way to distinguish between the two. I agree, Rhino does not always pick up the Alt-Tap right away, this is something that has been around for a long time. I don’t know if this depends on how your keyboard to computer communication is hooked up and if that affects the transmission/recognition of a tap as opposed to a continuous hold down. I.e how long does it have to be to get the first signal over there, and how long after that will it be interpreted as a hold down and not a tap.

1 Like

i am relieved that its not just me neurotically hitting into the keys simply expecting too much…

osnaps when dragging work only during a gumball drag, an object drag clicking anywhere else on the object does not yield snaps functionality, making any extra alt function during drag copy in this case not applicable and obsolete. or is there anything i have forgotten in a rush?

That is true for curves, surfaces or breps however dragging a selected mesh snaps to the nearest vertice.

well… only when you click on a vertex point. when you click somewhere between the vertices then the same happens meaning all snaps are ignored. which makes that a rare to never case with revealing inconsistency and questionable necessity. in rhino clicking somewhere on geometry without using the command move to pick an exact point dragging geometry is not a precise endeavour to begin with.

Yes you forgot dragging points and or control points.

is that something you often do needing snaps?

Yes.

can you explain that briefly?

What? The necessity of snap when dragging control points?

well, lets say your need, since i personally would not simply drag something like that. i use the command move or other tools to align, definitely not connecting a vertex point control point or any other point onto some random geometry with click drag, so i am wondering what your user case is.

For example when building a symmetrical closed curve I’m often using lines or plylines which are mirrored to snap control points. The points on the right side need to be dragged to the end points of the purple line.

why dont you draw the control point curve directly onto the lines? creating a random curve just to ping pong the cp´s does not sound like it makes a whole lot of sense. besides that in all honesty i can not believe that this happens so often :face_with_peeking_eye: but ok i dont know what you are building there.

any cases for multiple points which you have to move to some geometry? i am pretty sure that is the most negligible user case… under the line i dont think somebody would miss much. not having snaps in these cases :man_shrugging:

The situation I described is not using a random curve but a mirrored line.

Of course that would be the ideal situation but more often than not I have to edit things where I do not have full control over the source of the data.

:wink:

Maybe. Non-Gumball object dragging with object snaps works fine for both from and to points. Some people work with osnaps disabled and just turn them on when needed by holding down the Alt key (not me however). This already causes a major problem which has never been resolved - as Alt is also used for yet another function - to enforce window selection and thereby disable point picking - if you want to try to drag from a osnap point and you hold down Alt in order enable osnaps, you cannot pick an osnap point anyway.

Clearly the Alt key is just super overloaded in Rhino and somehow I think we’re lucky to get the functionality out of it that we do… But it’s not a very clean situation.