Attachment WorldPosition should *not* be [readonly]

Feature Requests Studio Features
,
#1

1333×750 376 KB

Why is Attachment property WorldPosition set to [readonly] ?
I know that Attachment.Position works relative to their parent and that Attachment.WorldPosition is absolute.
Thing is I want to calculate stuff using the WorldPosition, if I use .Position calculations won’t work.

Changing the Attachment.Position value to a bunch of large numbers also doesn’t break the attachment, so why keep us from using WorldPosition? If Attachment.Position were to be changed Attachment.WorldPosition would automatically change. Allowing this feature to be used would make scripting Attachment behavior a bit easier and would save users some unnecessary work. At the time of this discovery I had to improvise and it required me to do extra work for really no reason at all.

1079×698 670 KB

The goal is to make Roblox Studio as user friendly as possible after all.

Some would say this would be “not user friendly” , but this has been happening with UI instances for a while already. Example: Offset and Scaling
I don’t see why this property should be kept readonly.

Btw adding an adornee property for attachments would be nice, instead of making the Parent property take over Adornee’s role. It would make for some easier Attachment organization. For this to be not as frustrating as it may sound a toggle would be required.

SetAdorneeToParent = True

5 Likes
#2

local to world coordinates
parent basepart’s cframe * cframe.new(local attachment offset)
world to local coordinates
world cframe * parent basepart’s cframe:inverse()

They probably didn’t bother to add this in because it would be redundant. Kind of like how raycasts return the hit part’s material. Very redundant, since you can just do hit.Material.

#3

Was trying to use this just the other day for a similar purpose. Seems like it’s read-only because it’s not actually stored, just calculated using the other Attachment properties.

Can’t do that when you’re using terrain or multi-material CSG :wink:

2 Likes
#4

I would like this, yes, but until we get that, using the stuff CFrame offers is the best option.

Here’s something I wrote up, just to be of at least some assistance.

function SetAttachmentWorldCFrame(Attachment, CF)
	local ParentCF = Attachment.Parent.CFrame
		
	local NewCF = ParentCF:toObjectSpace(CF)
	local NewPosition = NewCF.p
	local RX, RY, RZ = NewCF:toOrientation()
	local NewOrientation = Vector3.new(math.deg(RX), math.deg(RY), math.deg(RZ))
	
	Attachment.Position = NewPosition
	Attachment.Orientation = NewOrientation
end

And of course, those last two lines on the function that set Position and Orientation can be commented out if you don’t need either one of them (i.e. you wanted only position)

2 Likes
#5 
local function setAttachmentWorldCFrame(attachment, cf)
	attachment.CFrame = attachment.Parent.CFrame:toObjectSpace(cf)
end

local function getAttachmentWorldCFrame(attachment)
	return attachment.Parent.CFrame:toWorldSpace(attachment.CFrame)
end
10 Likes
#6

I know it is only a few lines, but I used this all too often. I’d prefer if this were just a method or property on the attachment.

Edit: I don’t care about setting. But reading worldCFrame pleasee.

1 Like
#7

isn’t worldCFrame just part.CFrame*attachment.CFrame?

EDIT: I just tested it, and the CFrame of the PrimaryAxis corresponds to the rightVector of a CFrame. So if you plan on setting CFrames of attachments, be prepared to work with the rightVector instead of the lookVector.

1 Like
#8

Doesn’t really matter, as long as you’re consistent.

#9

If you’re only working with Attachments via script, sure. Fortunately the ROBLOX team have given us many properties to avoid that headache.

#10

Yeah uh… About my little function:
Most of it was trial-error testing to see what also worked and I seem to have left a LOT of my previous code in.

Am I OK? No.

#11

Yes it can be implemented by users, but I’m not sure why it needs to be read-only to begin with. Position/Rotation of BaseParts are writable despite them being able to be set through CFrame, for instance.

Unless there’s a good reason for it being read-only, it’d be great to make it writable so developers don’t need to re-implement an already a existing feature over and over in their projects.

#12

It’s in my opinion bound to cause a lot of confusion by having it writable. If you can set WorldPosition, some people may be confused by the fact that the WorldPosition changes by transforming the “parent” part. The (relative) Position/Axis/CFrame, however, stays constant.

A method probably eliminates much of this confusion, but I’m undecided on that myself :stuck_out_tongue: .

#13

Isn’t that already possible? E.g. “Oh I can just do attachment.WorldPosition to get the part’s CFrame” I haven’t seen anyone confuse the property, but if it’s an issue it’s something that should be tackles with the property itself and not its write access.

#14

attachment wpos.rbxmx (3.3 KB)

Here’s a messy plugin that moves attachmenta to attachmentb.WorldPosition using the functions above. I’m not publishing it becasue it’s not publish worthy in it’s current state, but it’s opensource so anyone who wants to make it better and publish it has my blessing.

Instructions: enable the plugin, select an attachment you want to move, then select another attachment and it moves selection1 to selection2 worldposition.
The ‘reset selection’ button just resets both selections to nil, it doesn’t return the selection to its’ original position.

The plugin can be so much better I just don’t care to spend another second on it.

1 Like
#15