As a Roblox developer, it is too hard to easily mark positions in my world to use in scripts. Attachments exist, but they must have a parent. A workaround is parenting attachments to Terrain, but that isn’t enough: I might want my nodes’ hierarchy to matter, and this feels like a hack.
This would be especially useful while working on my map: maybe I want a bunch of nodes for places where my AI can travel, nodes to determine where cars can spawn, etc. These “nodes” don’t need any size or rendering capability, but they would benefit from having a parent, and even children.
Right now, I have to use invisible parts with collisions off which is annoying at best, and possibly expensive at worst (I might want tens of thousands of them!)
So, I’m suggesting a “Node” instance. This instance would have a CFrame property, perhaps a color and size for Studio visualization purposes (like physics constraints do), and they’d be movable with transform gizmos.
Another alternative is this feature request regarding parenting attachments anywhere:
I feel like “node” is not a great instance name suggestion as in computer programming a “node” is an abstract data structure that contains a value and a reference (sometimes).
I don’t have any problem with Roblox introducing a generic node object that you can then set to reference a CFrame, but MaximumADHD’s feature request is a bit better as it is specific to the use case you want and there wouldn’t be any name-overlap with existing concepts.
If it’s any consolation, I seem to recall a Roblox staff member saying that if it’s got canquery off (as well as things like cancollide+cantouch off, and completely invisible) the memory usage on server + client are both incredibly tiny (of course it all adds up but if you’ve set them up right it won’t be that much)
I absolutely agree with this post though. Specifically requiring various attachment based instances to have something existing to attach to can be limiting, it would be nice to have the ability to say “put this end at these coordinates” and have it function the same as “put the end at this object that’s at these coordinates”
(implementing this might be a bit funky though, depending how it’s done it might break a lot of things)
For the record, if you parent these parts to somewhere other than the workspace (either from the start or through a script during runtime) then you can make use of the positional data without replicating the part to the client, saving resources and stuff.
I saw another post about wanting specific no-physics parts for such cases.
I agree it would be useful for nodes to exist. Perhaps in the meantime a plugin can be made which treats parts with a specific tag as nodes, stores the positional data in a modulescript or something accessible by scripts, and has archivable off on the parts so they don’t get published. It would then use the positional data to recreate the visual nodes in studio when you need to see/adjust them. This could be configured with a hierarchical structure.
Wdym “hierarchy to matter”? You can use tags for this kinda stuff, or have attachments that act like folders underneath terrain. Anywho I don’t think a new instance is needed here but attachments should just be allowed to be parented to anything.
Typically I just use attachments that are parented to the terrain if I really needed that functionality. I see how it could be useful in some cases, but the difference with engines like Godot and Unity is that they don’t really have scripts like Roblox does. Everything needs to be attached to an object to work while a script is an object. Attachments do their role pretty well in replicating the other features GameObjects have in unity. Also I’m like 99% sure you can parent attachments to attachments.