Dealing with instances that use attachments (Attachment0 and Attachment1 properties) can be difficult to clean up programmatically, especially when you don’t know where the source instance is, like for instance a beam.
Say you have a part with an attachment in it, you only know of that one part, and you want to destroy the instance that has it set as an attachment for, such as a beam. But doing this can be difficult because you have to implement a custom method for keeping track of what attachment is associated with what instance, in order to destroy the beam and both of its attachments.
You could, for example, instance an ObjectValue inside both attachments which reference the beam, but this creates unnecessary instance clutter.
Proposed Solution
There should be a function for attachments that returns an array of instances that have that specific attachment set as an Attachment0/Attachment1. Or better yet (that addresses this particular problem), a function to destroy the source instance, and both of its attachments all at once.
I support 100%, attachments should’ve had a property that specifies what object they’re currently connected to (ie. a beam, a rope constraint, etc) to begin with. I imagine it would be easy to implement and it only gives more control to the developer, and that’s always a good thing.
Attachments can be used for any number of things. If this is for usability in studio, is it possible that you could just name and organize attachments so that it becomes more clear?
Using multiple attachments is just a convention used by constraints/effects. There may be an effect in the future that uses four attachments, for instance, and this mapping falls apart.
Why can’t you start at the beam/etc which has both attachment references instead of at the part?
This is not usability for studio, this is usability for code.
I don’t understand how this mapping falls apart.
If there is a function to retrieve an array of instances that have that attachment set as an Attachment0/1/2/3/4- or however many Attachment properties there are, it shouldn’t matter. The point is, you can ultimately figure out where the source instance is, and do what you want with it.
Alternatively, if there is a function to destroy the source instance and all of its attachments (aka easy clean up), I also don’t see how it matters how many attachments an instance may have and/or why this mapping falls apart.
Because in this scenario, I don’t know where the beam is. I only know where the one part is, and that particular part has a single seemingly stray attachment in it. I can’t associate that attachment with anything because we don’t have any properties or functions that can indicate this.
Let’s say you have a beam between two parts, and one of those parts (the one without the beam) is destroyed. Now you have a beam and an attachment that doesn’t do anything anymore and you don’t know where they are. You can create a custom and potentially tedious way of tracking this, but I don’t think you should have to.
I will pose a frame challenge. If you can’t associate two of your own related objects that you personally created, and need the engine to figure it out for you, it sounds like a problem with your game & not the engine. If you want all related parts to be destroyed when one is, why are you not parenting them to the same model and destroying the model instead of the part? Models were specifically designed to group related objects. You shouldn’t be trying to be re-purpose attachments to do the same thing. And why is whatever is destroying the part told to destroy the part instead of being passed the beam and finding the two attachments+parts associated with it just be looking at its own properties?
Okay, your proposed method now returns an array of instances that have the specified attachment set as any property. Are you sure these parts are all actually linked now? If you have some spline effect that has the ability to work with different numbers of attachments and you get rid of one of them, should all of these parts be destroyed? Actually, we already have this problem with the 2-attachment physics constraints where some of them can optionally be set to use 1.
Even if, for some reason, you decide that you will manually decide which removed attachments constitute removing all related ones on an effect-by-effect basis, you should just be using a Model. Models were specifically created for grouping related objects. Attachments were not. Use the right tool for the job, or of course you’ll run into problems.
