Right now, we have ServerScriptService. This. Is. Awesome! It’s EXTREMELY helpful for organization, and gives our server scripts a dedicated place to be. With FilteringEnabled, this service has become even more helpful. A place for server scripts to go and to do their thing is beyond awesome. But what about Local Scripts?
Would it not be nice to have a dedicated place to put our Local Scripts? As of now, I’m putting all of my localscripts into the StarterGui. I’m not sure if that’s the proper practice, but that’s because, honestly, there is no proper practice as of right now.
Including a ClientScriptService (or LocalScriptService, I’m for either) would be a small but helpful tool for developers. Having my StarterGui service chock-full of Local Scripts that have nothing to do with GUIs is quite tiresome and annoying.
To conclude, however, I’d like to ask both for your comments on this suggestion as well as where you put all of your LocalScripts. Perhaps we developers could learn a thing or two from each other on this thread, as well! :]
Perhaps I didn’t make myself clear? I don’t want a place for GUIs, I don’t want a place for things to replicate first. I just want a place to put Local Scripts. It’d be essentially EXACTLY what ServerScriptService is, but, for the client.
He doesn’t want to use StarterGui because StarterGui is for GUIs. He wants a place to store his Localscripts that have absolutely nothing to do GUIs. He specifically said he is putting them in StarterGui right now, but he doesn’t want to do it, because it isn’t really a proper practice. With that, he’s forced to do it because there is no proper practice implemented. We have no dedicated place to store our localscripts while regular scripts do. He basically wants ServerScriptService but for localscripts.
He doesn’t want to use StarterGui because StarterGui is for GUIs. He wants a place to store his Localscripts that have absolutely nothing to do GUIs. He specifically said he is putting them in StarterGui right now, but he doesn’t want to do it, because it isn’t really a proper practice. With that, he’s forced to do it because there is no proper practice implemented. We have no dedicated place to store our localscripts while regular scripts do. He basically wants ServerScriptService but for localscripts.[/quote]
I personally like this idea. Though using ScreenGui works, it can ruin the puropse of guis, if you don’t want your guis to reset, while the scripts still run un-reset.
The thing is, I would definately use this for admin scripts, where, the script from the admin script on the server will parent itself to backpack, (To work with filtering enabled), then to ClientScriptService afterwards.
If I keep it in backpack like I always do, scripts are going to start to break in certain games, such as a training place I went to once, where if it stayed in backpack for too long, it would get deleted because of a silly “remove tools” script.
I want my admin scripts to work in all situations, filtering enabled or disabled, loadstring enabled or disabled (Using LuLu)
[quote] The problem with ReplicatedFirst, though, is that LocalScripts can’t RUN from there. [/quote]That’s because ReplicatedFirst isn’t working yet. “Consistent” LocalScripts will be able to run from there once it’s fully functional (it isn’t yet because, like the CSG modeler, it’s waiting for iOS).
