This is a re-run of my large conjoined thread - https://rocket.unrealengine.com/questions/1841/feedback-my-next-round-of-contenteditor-feedbac- broken up in different threads as per request of Alexander.
Since the very start of Unreal you were able to first click a mouse button, and then ctrl/shift/ctrl+shift to move the object you had selected. Now however since the latest build you need to rigidly first press the keyboard key, and then use the mouse, or you cannot move anything. Since you are going to be working at high speed and changing back and forth rapidly between navigating the viewport and moving objects, the need for having it follow this rigid order is causing slow downs in my workflow and make for a frustrating experience.
I understand that features may need updating and so on after so many years, but this is a change that does not seem like it could possibly improve anything and is fundamentally slower? Can the original UE1/2/3 system return, or at the very least an option for it? The way it has been for the past 15 years was nice and fluent, requiring minimal breaks in the continuous move camera-move object rhythm. That rhythm is absolutely vital and essential IMO.
Ah I see now,
“ctrl and/or shift (depends per build and engine generation, forgot what UE4 is at now) + left click and drag anywhere = move/rotate/scale X ctrl and/or shift + right click and drag anywhere = move/rotate/scale Y ctrl and/or shift + both mouse buttons and drag anywhere = move z”
Yes, right now, that is the planned setup for the next build. I agree completely and am excited to see this come out!
-Alexander
Bump.
I just got the latest build, and this problem is still very much so still there.
Again I don’t see what the possible benefit could have been from changing this, thus I assume this was an overlooked change that slipped in. I find this frustrating to work with and not just because I am not used to it. This is fundamentally slower compared to the old system because it relies on pausing your actions for a brief moment.
Hi Sjoerd,
I apologize for any confusion, it was changed slightly, it is not both shift and/or ctrl. It is just ctrl + click (left, right or both). Please let me know if this is behaving differently for you, I am on Beta 3 now and I can verify this is functional.
Thanks,
Alexander
It is also CTRL + SHIFT. That is fine and as it should be.
My point is that for the past 15 years the order in which to press the various buttons involved has been free to decide.
Now only since beta 2 it is rigidly set to first pressing CTRL or CTRL+SHIFT and then the mouse. This causes you to let go of the mouse first. This brief delay slows down my workflow while it looks like this was not an intended change on your behalf. The fact that no one seems to understand what I mean seems to confirm even more to me that this was not a planned change but an accidental one?
Hi Sjoerd,
That is my fault, I understand what you are saying, I had reproduced this incorrectly. First clicking the mouse and then pressing ctrl does not move static meshes like it did in UE3. Thank you for letting me know this was not added, I have created a new request to the programmers letting them know this it is now available.
Thank you,
Alexander
Hi Sjoerd,
I was testing this on the latest build here and you can anticipate the editor movement being changed. Make sure to update your build once it becomes available.
-Alexander
Hi, thanks.
Changed as in fixed or changed into something else? I would hate to see the original navigation being changed or removed, The original UE1 system is still the best and fastest viewport navigation I’ve ever worked with in any 3D program, but it is not something that is easy to get into for new people. I fear that one day you will remove it because too few use it, which would be sad.
Currently, I am able to move objects without hitting ctrl or shift. Holding shift while moving an object moves the camera with the object.
Unless you’re talking about moving node objects in subeditors like Materials, in which case I can hold ctrl before or after clicking and selecting to move a node.
This is subject to change, but this is most likely the way we’ll be going with object/camera movement.
Are you using the X Y Z move gizmo/the three arrows when you move an object or are you clicking and dragging anywhere (so not on the gizmo) in the viewport to move something? Because the latter would be a major change, which could work speed wise, but would be highly confusing at first. I don’t think you meant that though?
Using the widget. Is that what you are requesting? Faster widget movement/workflow for object placement?
No, I rarely use the widget. I meant the original way of navigating/moving things as found in UE1/2 and also UE3 (alongside the widget method).
-left click drag anywhere = move forward and backward
-right click drag anywhere = rotate view
-both mouse buttons click drag anywhere = pan view
Which then hooks into object translations →
ctrl and/or shift (depends per build and engine generation, forgot what UE4 is at now) + left click and drag anywhere = move/rotate/scale X
ctrl and/or shift + right click and drag anywhere = move/rotate/scale Y
ctrl and/or shift + both mouse buttons and drag anywhere = move z
The order of these has been changed after 15 years, which is very annoying and seems to be for no reason (what is the benefit?).
The great plus of this feature is that it is way faster to move and navigate. The problem with the widget is that you need to move your mouse to it. Moving the mouse, from possibly one monitor all the way to the other, and then trying to hit a specific part of a small widget → 1 second before you are able to begin moving. With shortcuts that is reduced to near 0.
Considering you move things about 40 000 times say (based on 4000 to 8 000 objects that have ever been in one level and been moved several times) per level, and say you got 5 levels in your game, that is 200 000 times a moving operation. At a loss of 1 second per operation that is 200 000 seconds lost. Now lets say you do this faster after all, at 100 000 seconds lost that still amounts to 27 hours of lost time in moving your mouse to a widget.
In other words, no matter how nice any feature found in the editor, it is the most boring and standard thing that you will end up doing the most and that has the greatest impact on your work. Hence my post.