Similar to a folder except the things inside of it don’t render, have physics, etc. Think of it like a ReplicatedStorage that you can put wherever you want. I want this for gear so I can just have a model of all the assets the gear is going to use without either creating them in the script or inserting them from the site. I imagine it would also be useful for model maker models.
1 Like
What type of needs make it not optimal for it to be held in Lighting/ServerStroage/ReplicatedStorage? I do not think making something that does not render or have physics might be hard in Workspace…
I am not sure it is easy to allow something in a model that renders and has physics to have a model inside not to have physics or render. At all know how easy/hard a feature like this would be? Seems a little difficult to me because a part can be in anything and still work.
Doesn’t seem like a big deal to me. Certainly they have a list of objects to render and calculate physics for, and they can just not add objects inside a StorageContainer to that list.
Folder.Visible or something of the sort?
I like this idea. It would be useful on a number of applications, such as distribution or dynamic expansion of models from within themselves.
Also gear. I make gear and it’d be cool to use thIs.
Couldn’t you just put it in the tool and then parent the stuff to nil as soon as the tool script ran?
While this would be extremely useful for tools specifically, it’s kind of inelegant everywhere else.
IMO “fixing” tools somehow to be less annoying is really what you want here, not a StorageContainer object.
Actually, wouldn’t it make sense to just turn scripts into “StorageContainers”? I can’t think of one use case for having parts parented to a script being rendered in the world.
Yeah, but somewhere, out there, someone’s doing it.
Out there, someone’s sticking potatoes up their rectum
Just because one or two people are using something for some random, odd use case doesn’t mean we should not update it – their fault for not using it correctly.
[quote] Out there, someone’s sticking potatoes up their rectum
Just because one or two people are using something for some random, odd use case doesn’t mean we should not update it – their fault for not using it correctly. [/quote]
But up until the change is made they were using it correctly.
Yep, that’s what I want. Not sure how to do that other than the StorageContainer though.
Dfjdjsjgksjgijdjkejjjjgjkxks
Not sure if whacked in head with lead pipe or positively biased towards own idea. You’re going to create a whole new instance because one or two people are using something other that what it was intended for? Parts are meant to be in the workspace or models – not other parts, scripts, joints, etc. This is something scripts should have done to begin with.
[quote] Dfjdjsjgksjgijdjkejjjjgjkxks
Not sure if whacked in head with lead pipe or positively biased towards own idea. You’re going to create a whole new instance because one or two people are using something other that what it was intended for? Parts are meant to be in the workspace or models – not other parts, scripts, joints, etc. This is something scripts should have done to begin with. [/quote]
There is no reason why Scripts specifically should have this behavior. That is, if you want it to be applied to Scripts, then it should also be applied to the variety of other classes that would be considered applicable, whatever that criteria might be. Or, we could figure out that the behavior does not apply to any single existing class or group of classes, and just make a new class specifically for the new behavior, which is generally why new classes are created in the first place.
[quote] Dfjdjsjgksjgijdjkejjjjgjkxks
Not sure if whacked in head with lead pipe or positively biased towards own idea. You’re going to create a whole new instance because one or two people are using something other that what it was intended for? Parts are meant to be in the workspace or models – not other parts, scripts, joints, etc. This is something scripts should have done to begin with. [/quote]
There is no reason why Scripts specifically should have this behavior. That is, if you want it to be applied to Scripts, then it should also be applied to the variety of other classes that would be considered applicable, whatever that criteria might be. Or, we could figure out that the behavior does not apply to any single existing class or group of classes, and just make a new class specifically for the new behavior, which is generally why new classes are created in the first place.[/quote]
I doubt a new instance would be an optimal solution for the same reason Stravant thought so. Creating an whole new instance just to prevent them from entering the world seems inelegant and would just create API bloat for something that doesn’t have many use cases and can technically already be accomplished anyway. However, giving scripts (and their cousins LocalScripts and ModuleScripts) this behavior would not only cover those few use cases and make sense, but the amount of people it would affect would be negligible.
[quote] While this would be extremely useful for tools specifically, it’s kind of inelegant everywhere else.
IMO “fixing” tools somehow to be less annoying is really what you want here, not a StorageContainer object. [/quote]
Nah. Could definitely use in RPG’s for chests and stuff. Could be used for custom particles. Could be used for a bit actually.
One word: Whitelist
I agree that it’s inelegant, but only because I think the whole idea is unnecessary to begin with. What I’m saying is that it makes no sense to add the feature to Scripts, because it’s outside of the scope of what Scripts do. It would be like a coffee maker that also does your taxes.
I would compare it to a coffee maker that traded off space on the top for you to place decorations for space to store your coffee beans. Who even places decorations on the top of their coffee maker in the first place (assuming it’s not fed from the top), so I’d love a coffee maker that stored my beans in it so I didn’t have to walk over to the pantry to get them. Taxes + coffeemaker is a poor analogy.
Then say that it’s like a coffee maker that [performs action completely unrelated to making coffee]. The point is that it’s out of scope; it’s outside the idea of what scripts are expected to do and how they’re expected to behave. The only reason I can think of doing it this way is because the feature is not worth adding a new class for. And if that’s the case, then why even implement it?