Ctrl+L broken on attachments

  • Select an attachment
  • Press Ctrl+L
  • It doesn’t switch out of local space

It is expected to switch out of local space.

I think this is recent.

6 Likes

Though it seems I either got local/global switched or they made it only local instead of enabling Ctrl+L.

1 Like

I can repro, but did this ever work?

2 Likes

Would Roblox ever release a feature that isn’t properly tested :stuck_out_tongue:?

In the past, perhaps. But now? Not if we can help it, we have some very good QA engineers now.

However, I’m not a part of the Studio team, so I don’t know 100% of what they’ve shipped or haven’t shipped. I do my best to keep up on it, but there’s too much to keep track of!

By the way, this issue has been logged and passed on to the right people. I was confused by Sharksie’s wording; I didn’t think this had been implemented at all. Turns out it hasn’t!

As far as I know and could tell when I was working on the IK dragger attachments specifically have always been local space only.

I believe the idea was that an Attachment is specifically representing a CFrame that is local to that part and that it might not make sense to manipulate them in world space by default (or at all).

@Sharksie any chance you could elaborate on your use case a bit? More out of curiosity than anything. I agree with you that allowing world-space manipulation probably makes sense.

1 Like

Attachments are used to store Lights, Sounds, ParticleEmitters, etc.

For some reason, it is impossible to parent an attachment to anything but a BasePart

So my hierarchy looks like this:

  • Workspace
    • “Origin” Part
      • Attachment
        • ParticleEmitter

Right now I can’t rotate an attachment relative to the world, and it’s very easy to become unaligned with the horizon when you’re doing rotations like this. So I have to edit properties in order to get my attachment to behave properly.

1 Like

We have a ticket to add support for different spaces for the attachment dragger.

2 Likes