No disrespect or anything… but I’m truly convinced that there is a team at ROBLOX that just sits down and says, hm, what can we mess up today? What can we break that isn’t already broken? What can we smear that is already broken? For these past few weeks there has been a-lot of annoying stuff that has been newly broken/glitchy. For example, selecting with CTRL is glitchy, random studio closing/crashes, etc. But THIS one…
For YEARS I have been using studio with many various features/things that were just the way that they were made to be that I cannot live without. THIS is one of them.
Whenever pasting something into the Lighting specifically because you want it to keep the position and orientation of it (or even ServerStorage now), NOW it acts as if you pasted it into Workspace. It aligns it to whatever the Workspace paste behavior does. Not just that, but the inconvenient camera zoom-to-object when it happens. WHY
Expected behavior
What is supposed to happen is that the objects/model you paste into anything OTHER than Workspace, it’s supposed to keep that position that it is being pasted from. So pasting into Lighting, ServerStorage, ServerScriptService, etc. It’s not supposed to re-align or make a new position, THEN ZOOM TO IT. It never used to zoom. It should NOT zoom to the object.
I was also frustrated from running into the same sudden change in behavior.
Problem
Pasting PVInstances (Parts, Models) stored in ServerStorage/Lighting into the Workspace via the Explorer “Paste Into” command (Ctrl+Shift+V) used to have the benefits of 1 maintaining original positions, regardless of current camera position, and 2 not getting your camera forced zoom to the pasted object.
For me, this was an important because models are often stored in an organized manner or are positionally critical (e.g. map markers and position nodes) and pasting into workspace was a safe way to edit them. Additionally, the old behavior better replicates the clone and parent to workspace behavior that is common in code.
The new “Paste Into” command now just acts with the same behavior as pasting in the game window as opposed to via the Explorer, repositioning the pasted object relative to the current camera, with the added benefit of parenting to whatever is selected.
Workaround
It seems that the old functionality is preserved in the paste variant called “Paste Into At Original Location”. If you right click your desired container in the Explorer window (e.g. Workspace), the option should appear.
This option allows you to the paste with seemingly identical functionality as the old “Paste Into” command.
“Paste Into At Original Location” pastes into the selected container while not disrupting the position of the pasted object. It also does not force zoom-to-object. This new command does not have a shortcut by default.
If you are facing the same frustration, I would suggest rebinding Shift+Ctrl+V to the “Paste Into At Original Location” command. You can do this under the File > Advanced > Customize Shortcuts menu.
Hey, sorry for the issues. This should not come up again.
Context:
I’m currently working on migrating all of the old crash / hang-prone insertion paths (Paste / Duplicate / Insert from File / etc) to a new piece of significantly more performant insertion code.
The benefit of doing this is that you should no longer experience any hangs when inserting content once the migration is finished. Also the insert behavior will be much more consistent between different ways of inserting something (insert from file works completely differently than paste currently )
The cost is there will be some teething problems like this because there’s a ton of little behaviors baked into the various insert paths. Bare with me and report again if you see anything off with the insert paths. I’ve intentionally changed some small things to increase consistency but something like focusing the camera on stuff that isn’t even in the workspace is a clear mistake.
)