Attachments are being increasingly used for organizing things, and now with the recent update, they can be used for even more stuff. At this point, you might have several Attachment instances for a single object in your game (46 for a standard R15 character for example) and identifying them and what they do is sort of difficult unless you venture into the explorer jungle.
Being able to set a color for an Attachment would solve this problem.
Here’s a mockup where attachments in a character used for joints are green, and ones used for accessories are blue:
I don’t think this is a good solution considering there are cases where tons of attachments are used, and this would increase memory consumption on the live game. Maybe it should display the attachment’s name next to its colored dot in studio.
I would prefer if attachments remain as light-weight as possible, they are (sort of) replacements to using BaseParts in the first place. Probably this would work better as a plugin or built into an animation editor? (that uses spherical parts to represent the attachments instead, so you can color them)
I don’t think the issue is that we need to differentiate attachments, but that we have to toggle every attachment in the place if we want to work with just a few select attachments. There should be a better way of controlling which attachments are visible.
These are all valid points. I too would like attachments to remain as light weight as possible, but with the number of use cases for them increasing (when they were only used for constraints, organization was not a problem) there needs to be some way to differentiate them from one another. In terms of usability, colors are the best solution because they provide the most clarity with the least amount of toggling values/settings and without increasing visual clutter in the same way text would.
I also think the storage issue can be solved; Color3 or even BrickColor both seem sort of superfluous, but a smaller selection (8/16) colors would help immensely and not increase memory usage noticeably. Even 8 colors is enough to fit the 3 primary colors, 3 secondary colors, as well as black and white. If anyone wanted more colors, sphere parts could be used instead. This is also more of a feature request for studio, not so much for actual games.
I cannot stress enough how important this is for me. As constraints are now used for effects, lights, and physics attachments, it has become a hassle to distinguish which does what.
Take for example a connection corridor. Attachments are used to properly organize lights, to create a steam effect off a broken pipe, to add ambient noise, with ropes that are used to run wires across the room, and to move fans in the ceiling using PGS. How can I edit all the light-emitting attachments if I can’t see which one is which?
I really hope this sheds some light in the importance of this feature. I believe BrickColor would be more than sufficient to solve this issue.
Attachments purpose isn’t meant to replace parts. While it does work, that’s not the intended use for them. I feel like they should create another Attachments type object so that Attachments can strictly be used for constraints.
Attachments now have more support than ever for effects, sounds, and lighting.
Clearly, Roblox intends for this to be a more lightweight replacement for parts when it comes to placing visual and audio effects in-game. The more use we give to the Attachment class, the more this topic becomes a serious issue.
I’ve attached an image below, which hopefully demonstrates the number of attachments which can be present in a small area, and how difficult it was become to discern them and their purpose. In the image below, the attachments are being used for multiple purposes, such as constraints for the doors, light placement, object placement (objects are replaced at runtime) and for welding purposes, as used by the Roblox character.
If this is going to happen, I would request that attachment colors use the attribute system internally, to keep the instance lightweight. It seems like a practical choice to store specific legacy or development-only properties in this extendable structure that already exists for all instances. This would use reserved or “invalid” attribute names.
Also, it’s silly that attributes don’t let you start them with “RBX”. For internal use they should just use invalid attribute names like “.Example”, or even just “/1” for fast engine access. It’s guaranteed to be unused and the newfound simplicity could very slightly improve the performance of “GetAttribute”/“SetAttribute” for everyone.
I would also request this is used for things like BasePart.Locked and maybe the legacy surface properties. (BaseParts are too bloated IMO.) This just needs to be documented for people who rely on serialization formats.
