My VSCode explorer is becoming a mess, should I parent all GUI scripts to starter GUI instead of leaving them inside frames, buttons, etc.?
I’ve searched a bit in the forum but the topics I found didn’t mention Rojo.
My VSCode explorer is becoming a mess, should I parent all GUI scripts to starter GUI instead of leaving them inside frames, buttons, etc.?
I’ve searched a bit in the forum but the topics I found didn’t mention Rojo.
StarterPlayerScripts should be where your client modules live.
Well, it depends, but I usually put my script parented to Screengui , and I place the module either in ReplicatedStorage/SPS or inside a local script, depending on the situation.
Client scripts too? I use this text from Rojo’s documentation as a general rule:
“Most software projects outside Roblox have a single location, like a folder named src, that all code goes into. By moving most of your code into services like ReplicatedStorage, ServerScriptService, and StarterPlayer, it becomes easier to find what you’re looking for.”
(Porting an Existing Game | Rojo 5th paragraph)
So I just try to keep scripts not nested too deeply, like in starter player, replicated storage, etc.
The only exception I had was with GUI scripts which I put inside frames, GUI buttons, etc. But I guess I should stop with that, right?
Yeah, I do the same for modules, I’m in doubt about the local scripts’ parent.
Idk if I should parent mine to start GUI or the screen GUI they act on as you do, what do you think?
I will definitely use a parent-to-screen GUI. Let’s say the script has a variable for the player folder. What happens if the script runs before the folder exists? That would cause an error. So, it’s better to include it inside the screen GUI and ensure that all data and folders are loaded before cloning to the player GUI. This is how I did it, but perhaps there are other ways to approach it.
I often use single script architecture with one local and one server script, the rest being modules. The are several frameworks that can help with this.
To backpack off of this, UI is ideally programmed in component based modules, with the MVC (model view controller) model.
Lets say you have a button, you create a module for the handling of that button, now instead of needing a script in every instance of that button, you just require that module.
Modules are infinitely more useful than an abundance of scripts.
Damn you went full OOP with Luau?
So your project is fully Rojo-managed? Like, you created all the GUI with code? I’m only managing my code with Rojo right now, I don’t want to change my approach since I started this project like that.
Yeah, I avoid cloning scripts too, but I only create a module when I repeat a script more than once. Like, I won’t ever have two pause buttons, does that make sense?
edit:
With my architecture, parenting GUI local scripts to starter GUI or a screen GUI is still better than parenting to GUI objects like frames, right?
That makes sense, but I just changed all my GUI scripts’ parent to starter GUI and I don’t know why I didn’t run into any errors.
This is the framework I use, I find it much simpler than knit or nevermore as requiring a module requires no effort, just:
local Maid = shared(“Maid”)
As for UI, Its created on runtime by cloning templates in ReplicatedStorage, those are then converted into their own classes with their own show and hide methods.
BasicPane is what I used to use, but now I have a more custom solution.
Oh so it’s done automatically, that’s cool, maybe I’ll change to this in future projects, but I don’t want to re-structure my current project, so
what would you do?
I mean, I already changed them to starter Gui so I guess I’ll keep that.
I’ll leave this topic open if anyone else wants to share their opinions.