Summary
When users copy+paste actors, the editor fails to preserve their z-rotation or their location (x y or z). This is a fundamental failure than is seen all the main places where where transform is used, including in animation sequencer where the editor for examples moves the body of the LAAT back to it’s ORIGIN (without any of the other parts eg turrets, it just moves the body) because (without instruction or permission or notification) it changes the body (only) from static to movable, and so the user must reset back to static after EACH scene graph plot. Massive time wasting dysfunction.
Please select what you are reporting on:
Creative
What Type of Bug are you experiencing?
UI/Tools
Steps to Reproduce
Copy+paste, transform (by dragging arrows in editor, including while working in sequencer), duplicate. All risk screwing up transformation. The effect is immediately apparent when copy+pasting or duplicating 4 curved parts that are arranged into a ring before duplication/copying.
None of these are grouped. They and every part of the structure (many more parts than selected/than are being manipulated in the test) are children of an actor–That should not break any of these functions.
Expected Result
Things should obviously paste and duplicate where users paste them, with the same location and rotation as the originals. If users wanted the original location and/or rotations copied, they obviously would have copied THAT.
In sequencer nothing should return to origin when being transformed. Obviously nobody wants that, it’s totally dysfunctional and wastes users time sequencing by making 2 clicks and hitting enter into literally 5x as much time wasted on this.
Observed Result
With copy+paste or duplicate, the editor fails to preserve z-rotation or location coordinates, consistently. It seems to only screw these up during transforming in viewport when it’s snapping, not when it lets you smoothly transform.
This is another issue. The editor loses track of where things should actually be snapped to. They should obviously be snapped relative to where they are/start.
Notably, rotation is NOT screwed up when users use the slide bar under the detail panel to accomplish transform, but unfortunately that’s no kind of fix because that’s programmed wrong too: Whereas currently not even axes that DO share exact same values can be transformed together via slider, EVERYTHING selected should be simultaneously transformable by the detail-panel slider bars (same axis value/s or not) a. because there’s no reason the editor shouldn’t be able to transform all it’s simple math that the editor needs to be performing correctly, and b. because it’s needed when transforming in viewport with the arrows screws up rotation. It’s so often that something doesn’t work and neither do the next and often only 1 or 2 fallbacks. This is the kind of totally dysfunctional stuff that’s why people aren’t making games with this and what’s messed up is a lot of them mistake dysfunction for a learning curve.
Not sure if there’s a coherence to the incoherence or if it’s doing it wrong in a consistent way (notwithstanding the fact it should not happen at all) but maybe some insight into what exactly is going on can be gained from experimenting with 4 identical “curved trim” or “railing curved” or similar pieces. Arranged in a perfect circle and then copy+pasted, transformed, or etc. it will skew each piece by 5 degrees, making a sort of gammadion/whirling log or spiral shape. But, 5 degrees may only be unique to this specific test / the conditions in my editor / difference between origin and now or something.
What is consistent is that the ring segments will be skewed to the same direction and degree. This WOULD be a reasonable fix (although again theses little things add up when that fix makes the task tax 3x as long every time) if users could simply skew each part back (even easier if multi-select transform worked correctly/at all), but–notice that skewing these merely 5 degrees will NOT form a circle, because it doesn’t just skew rotation, it also skews location (so now it’s gone from a few times to a an asinine amount of work to fix these things with how messed up 4 different coordinates over 2 different transform types are for no reason).
This rotation thing is the type of difficulty I’d expect when trying to rotate 4 curved parts together–they rotate relative to themselves rather than relative to their shared center. Is there a way to toggle between those two relative-bases for multi-selects? If not there needs to be. Obviously this should never happen when simply pasting, duplicating, or transforming (rotation was literally not instructed or permitted at all, nor was location change). I’m aware I can turn snap on/off, which btw constantly randomly toggles itself.
Note that there is not a right-click option with “set” or “pivot” in it that fixes any of this though that would seem to be more or less the desired use for these options. Making the items children of an actor is not a coherent fix; that obviously should not need to be done. It also has little to do with this in the end because the same bug happens when duplicating or copy+pasting only only one object by itself, too.
Platform(s)
PC; Windows 11 Pro
Upload an image
Additional Notes
Discussion
This is just math please just preserve and apply relative and world changes to the math correctly, that’s literally all. There are tons of issues with basic function like that and these issues are severely substandard outliers among software in general. Dysfunctions like these mistaken for learning curves are why users aren’t making games with this and I can prove that mathematically.
Silver lining: Sometimes this can be used to make cool spiral/shuriken ish designs and do way crazier stuff if combined with interesting mesh+texture combos lol. This is the type of thing that should be a fun/advanced extra tool, but obviously this is not how THESE tools should work.
It is literally like the engineers do not use this software. This type of stuff is: 1. Impossible to miss over the course of any significant use, and 2. Impossible for a sane and informed decisionmaker (“Master of Priorities and Coin”) to ignore.
