For some reason just selecting a part with the scale tool and moving the camera or scaling an object with it causes a huge amount of lag. It has something to do with the rendering as shown by the micro profiler below.
The render bars are ~65 - 70 ms long
It does not occur with any of the other new tools.
I am not sure if this belongs here or in #platform-feedback:studio-bugs
Possibly this issue:
As for your other issues, I havenât seen anyone report them yet, but they are clearly some quite serious ones!
It belongs here because this is still in beta so isnât really considered part of studio yet, and this post will be monitored by the team who are working on it instead of all studio engineers.
EDIT: didnât mean for this to be a reply for the post it appears to reply to, mobile isnât the easiest to post on.
Switching tools with your mouse down crashes the drag tool and causes weird, inconsistent state, which permanently screws up whatever you were dragging and never removes the handles.
The new default cursor makes everything seem selectable. The original pointer provides more context since it doesnât change whenever hovering over locked parts or the skybox.
Found something interesting. Attempting to move a model that is inside of a ViewportFrame appears to break the entire dragger. Iâm not sure if this is just a fluke though. Turns out, if you try to drag anything that is outside of the Workspace and not visible, it will throw this error.
After this error occurred, I was not able to re-select the Move button, and had to restart Studio to get the Move dragger to work again. Before I restarted, I tried to change the current dragger then re-select the Move button, but got a separate error.
Does anyone else feel uncomfortable with the new mouse icon always being the hand âgrabâ icon whenever the mouse is in 3D space? It feels really weird/uncomfortable for the mouse to be the âgrabâ even when your mouse is hovering over the skybox. Maybe itâs just because Iâm used to the old way the icon used to work, but it seems like itâd make more sense for there to only be a âgrabâ icon when thereâs actually something to grab. Was this change intentional?
If the cursor is always going to stay the same regardless of whether youâre hovering over something selectable, then it should just be the regular cursor at all times, because in that case having a hand icon doesnât really serve a purpose but to remind me that I can grab things (I already knew that). This is similar to other software Iâve used, such as Blender, so it seems like users would be more used to something like that, rather than a constant and distracting hand waving around!
Seems like updating the position of the selected object in Explorer/Properties doesnât update the position of the handles for attachments
i donât know if anyone else is having this issue, but the new lua dragger acts weirdly with rotated parts while trying to scale them
Hallelujah!!!
Itâs in beta so theyâll probably fix it
I donât like that parts go through other parts when Collisions enabled. Thatâs going to drive me crazier. lol Please fix that part.
Unintentional, weâll look into a better behavior.
Unintentional, weâll restore the old behavior for this.
I changed my mind on this.
The old behavior is really weird, where box selection and dragging act differently. The new behavior will be that Tools will act exactly the same as Models for both box selection and dragging.
Mentioned elsewhere in the thread, I forgot to force local space mode when scaling a single part. If you manually switch to local space mode as a workaround scaling will work.
Thatâs somewhat expected because our code precalculates and frontloads most of the hard work on mouse down. Iâll look at whether adding a debounce so that you donât accidentally run into this makes sense.
Oops, I forgot to force a mouse-up when the tools get deselected. Will fix.
Unintended, it should not let you do anything to stuff in a ViewportFrame. (It would actually kind of work anyways for stuff in a ViewportFrame if you added some support code, but thereâs no good way to draw handles for stuff in a ViewportFrame)
Unintended, I actually know exactly what line of code I messed up thatâs breaking this.
Not sure whatâs going on here either, could you DM me a copy of the model youâre testing it on there / let me know the settings used (collisions / joints / constraints)?
Dragging a Script from the Toolbox into the viewport (dragging instead of clicking so that Studio doesnât screw up my camera) causes this error.
Iâm curious, whatâs the point of the âTemp Movement Weldâ?
Pretty sure itâs from this, and I have join surfaces off.
Sorry for the size of these screen grabsâŚThe part in question in the image in my other post is not anchored but welded to the model via borntoweld (lol). In this image, the part is not anchored or welded. It seems the rotation of blocks causes the handles to bug out, but ctrl + L corrected it, soo maybe Iâm just doing it wrong! I will send the model in a few. lol. I dunno. Moving handles. Keeps things interesting!
Confirmed, will be fixed.
In order to move the parts around efficiently while dragging, the draggers donât simply set .CFrame = ... on all of the parts. Instead, when you pick up a selection to move it via freeform dragging or via a handle, they weld the selection together with temporary welds (the âTemp Movement Weldsâ), which are removed again when you put it down (Theyâre also Archivable = false, so donât worry, they wonât accidentally be saved into your place file). That way, the draggers only need to move a single one of the parts in the selection, and the entire selection will be moved at once as a welded assembly.
This will be fixed in next weekâs release.
Could DM me the model? Iâm not sure how thatâs happening. It seems like thereâs a joint in the model thatâs being physically simulated but is somehow missing an Attachment0 / Attachment1, I donât know how that could happen.
Maybe it has to do with the PrimaryPart being in a child model?
Models are only used to determine what the user is trying to select. As far as the actual drag operations are concerned the selection is just one big bag of parts and attachments.
Nice updates, but a feature Iâd really like (if it doesnât already exist) is that if Iâm working with a model or part within a model, stop the tools from thinking I want to drag the entire root model, especially if I have the part or sub-model selected in Explorer anyways. I know that you can lock, but thatâs a hassle, and holding alt only affects single parts.
