Essentially an instance with a special feature that allows you to set its icon for organization.
The icon idea, i like that. I’m also finding that non-model objects for grouping isn’t perfect. You can’t drag items into them and I can’t drag-select parts within non-model objects. I like keeping my map in a configuration object to clear up and organize my workspace and not have the grouping behavior of models.
What is the exact behavior that you’d expect from a ‘Folder’? There seems to be a lot of conflicting ideas about what a ‘Folder’ would be. Is it just a way to organize objects in the Workspace? Does it change selection behavior?
@Adam.
We put our Scripts, ModuleScripts, etc now in a Model or inside a Backpack. (In ServerStorage, Workspace, etc). We only ask for a Object to store our Objects in. We don’t need any complicated Selection Behavoir, etc. Just the default API would do (Like :GetChildren()), etc
Perhaps, in the manner of the ServerStorage and ReplicatedStorage objects, a Storage object would be nice.
Some people just don’t like models because “omg they have methods!!!”
Others don’t like them because they automatically delete when the last object in them is deleted (can’t use for bullet storage and whatnot), and because you can’t do this with them: https://www.youtube.com/watch?v=dK7JZmHeFeY
Personally, I would like a “Structure” object that was just used for organizational purposes as seen in the video. I’ve opened up so many places where the workspace is fillllllllllllled with “Crate”, “Crate”, “Crate”, etc (like 50 of them – same with trees), and they are never grouped together into “Trees”/“Crates” because then you can’t move each one individually.
I’m not sure what the OP hopes to accomplish with icons – if he can’t figure out which items are in his models based on the name, he needs to fix the name.
"Is it just a way to organize objects in the Workspace? Does it change selection behavior? "
Luke and I have found that not impacting the 3D-selection behavior is a very good behavior for such “Folder” objects (As is the current behavior if you use a Configuration object as a “Folder”, which is what we do, but that way you can’t easily use the object with the explorer, because most things aren’t “supposed” to go under a Configuration). The point is that these “Folder” objects represent code/game logic wise organization of the project, not physical organization of the project like models do. As such they shouldn’t effect give you manipulate objects in the 3D view.
The ordering of stuff
Like how everything displays models first, then parts, then whatevers in Explorer
I have to name things “.SetupScripts” to put them all the way on top, and I don’t like that.
I would be happy if they just let us put anything into a Configuration instance without studio making a fuss about it.
Some interesting API might be nice if a new instance were to be made, too.
You should check out the Configuration object.
just use configurations
allow configurations to take anything as its children.
[quote] just use configurations
allow configurations to take anything as its children. [/quote]I’m pretty sure Configurations were only made for ROBLOX building tools to store values, anyway.
I think that there should be a new instance added to the API just for grouping objects without using models/configurations/skins/whatever people use, I’d think a name like “Container” would work fine. Make it inherit Instance, and it’s all set.
Yeah mostly what Stravant said
what I had in mind honestly was that you wouldn’t even put Folders into Workspace, because they don’t belong there.
They’re for organizing things in SSS, RS, SS, etc. and nothing else.
[quote] Yeah mostly what Stravant said
what I had in mind honestly was that you wouldn’t even put Folders into Workspace, because they don’t belong there.
They’re for organizing things in SSS, RS, SS, etc. and nothing else. [/quote]
Personally I would find a use for them in workspace for storing visible game logic that isn’t to be treated as a single item which I need to manipulate, or for organizing all my map parts into a folder so I don’t have to scroll through a mess of parts to get to other services. I’d certainly use them like you said though.
The main use is to separate the namespace out to prevent conflicts.
Sort of the same way URLs are structured.
[quote] Yeah mostly what Stravant said
what I had in mind honestly was that you wouldn’t even put Folders into Workspace, because they don’t belong there.
They’re for organizing things in SSS, RS, SS, etc. and nothing else. [/quote]
Personally I would find a use for them in workspace for storing visible game logic that isn’t to be treated as a single item which I need to manipulate, or for organizing all my map parts into a folder so I don’t have to scroll through a mess of parts to get to other services. I’d certainly use them like you said though.[/quote]
This problem would be better solved with namespace scoping.
We just need a simple container class that inherits from the instance class and does/have nothing else (I think the name ΓÇ£ContainerΓÇ¥, which I have long suggested, is better than all the other suggestions). It should be able to be put anywhere, should be able to contain anything, and should have no semantic meaning at all.
Another advantage of having a container class is that classes like “Teams” and “Backpack” could inherit from container to make their purpose explicit: