Keeping packages as one container is a very reasonable use case, actually. It’s not realistic or even possible when you have to split your client and server code into different containers entirely. So no, the advise is not reasonable, nor is it even usable advice. It’s just obvious coding practices that work most of the time. Watch your attitude when you don’t know what you’re talking about.
“…for certain modules”, does not really present itself as a significant argument for a feature request like this.
Unless you give out a very interesting reason (which you haven’t given thus far), your feature request has no likelihood of happening.
That’s the fun part. Notice how this is a completely separate feature request thread, posted by a different person entirely!
Also, if you read my replies, you’d see that yes, I already said my reason since apparently it was necessary to do so here. Splitting client and server scripts into different containers means we cannot keep packages together under one container. This is a huge hindrance.
Even should you make an independent feature request detached from this, you don’t make a very compelling argument into its favor.
Why is this a necessity?[1]
(it’s not) ↩︎
Why would I waste time going into more detail or tryitto prove the worth of it to random people in a coloured folders thread? The feature request already exists, with many desiring the feature. It’s very weird how you seem to believe this is some wild request I’ve come up with on my own. Even without the packages use case, having systems isolated to one container is just far cleaner than how we have to organize our projects currently. That’s why it was relevant to mentioned here, because this is another (already resolved) request about organization.
If you don’t understand the benefits of having a single system under one package, then you may have never had a need for such a thing to begin with. But constantly bothering others who do desire such a system because you don’t personally see the use of it is just strange. Nobody needs to prove the importance or quality of their requests to random members of the developer forum. I’m not going to continue polluting this thread with more after this, because this is already more than enough. A short sideline is fine, but it’s derailed completely off topic now.
Let’s gooo! Roblox heard us! For everyone who wants to learn more about: GeneratedFolder | Documentation - Roblox Creator Hub
Not the same thing, that’s been around longer than colored folders.
Seriously man??? I don’t know how I never found this!
Also, just realized we can create rainbow tween effect! LOL
Use this code in Command Bar to get this effect:
local a = Instance.new("Folder", workspace)
a.IconTint = Color3.fromRGB(0, 0, 255)
game:GetService("TweenService"):Create(a, TweenInfo.new(2, Enum.EasingStyle.Sine, Enum.EasingDirection.InOut, -1, true), {IconTint = Color3.fromRGB(255, 0, 0)}):Play()
4 Likes
Dear god i can only now imagine toolbox viruses that either flash your folder colors really fast or scramble them around.
1 Like
you mean studio v iruses
This goes against the architectural philosophy implied by Script’s RunContext property. According to your own logic, RunContext is not warranted because you could “already achieve it by changing its parent” for a Script and LocalScript but they still implemented it.
ModuleScripts are the only thing that are lacking a meaningful way to fit into this architecture where both Scripts and Client Scripts can be securely placed in the same container and easily transported across games.