I’m trying to stop StarterGui from cloning its contents into a players GUI.
I have a custom spawning system which clones anything that would be in StarterGui into the PlayerGui.
the reason I am doing this is because I need GUIs to be in playergui before the player’s character spawns. from what I understand StarterGui will only clone its contents when the character is added and I couldn’t find a way to change this behavior. this prompted me to make my own GUI cloning system which works perfectly except for one problem.
startergui keeps cloning its contents even when there is nothing inside. when my character loading script clones all the GUIs I want from another location over to Playergui, StarterGui just removes it all and clones its contents instead.
after looking into it I found this nice piece of code which solved this whole issue: game:GetService("StarterGui").ResetPlayerGuiOnSpawn = false
this pretty much solved all of my problems but…its depreciated.
why is this the case? I pretty much need this property but I dont like using depreciated code.
I did some looking around before making this post and the related posts I came across recommended to just stop individual Screenguis from resetting on spawn.
this brings me back to the problem of cloning GUIs when the player joins and not the character being added as simply changing how each GUI spawn doesn’t seem to be the solution. if I could just change when and how everything gets cloned then I wouldn’t need to disable StarterGui.
any thoughts on what I should do?
You might just have to spawn the player in a box outside your map bounds, kill them instantly and then only respawn them when they’re intended to spawn. If you don’t want to use the deprecated property, then there’s probably nothing more you can do.
would it be wise to try to use a repeat loop to force contents to be loaded?
for example if I put a bool value named “StarterLoaded” inside starter gui, and then whenever this value is detected by my custom spawn script, proceed to clear playergui and reload the intended GUI objects?
Yes, you should be able to do that with the ChildRemoved event. Only problem is that would force the GUI to reset each time the character respawns, which might not even be an issue if you aren’t too concerned with that behaviour.
ResetPlayerGuiOnSpawn Was deprecated in favour of each Layer having its own option called ResetOnSpawn
You could iterate through each Layer and set these instead of setting the Deprecated one, or, heres an idea for you, why dont you clone the GUI into the players’ GUI from a different folder? Such as a folder located in ReplicatedStorage or ServerStorage and leave StarterGui permanently empty with no content?
if you have nothing in startergui the empty space is still unfortunately gonna be forced into playergui.
I already have made a seperate folder for my GUIs in replicatedstorage, I still had to “disable” startergui because it is quite literally cloning nothing.
its been a long time since ive had this problem and the game I was doing this to has gotten too big to sift through, but if I had to guess I think I probably stored stuff elsewhere and didn’t rely on startergui initially. I don’t think I managed to actually disable startergui only make it seem like I did.
Yeah!
I mean honestly who had the idea at Roblox to even make such an idea?
I feel like cloning everything from ServerStorage in a serverscript and seeing if it gets deleted. Do you think this might work?
There’s nothing wrong with StarterGui. Most experiences expect to have a basic set of Guis that they want cloned to the player each time they spawn, with later years fine tuning this via the ResetOnSpawn property (there was a global setting for StarterGui before it was made granular; it is deprecated and only remains for backwards compatibility). StarterGui is a tool to make the replication process easier, you do not have to use it if it doesn’t suit your needs.
If you need to explicitly control Gui replication, it was always the expectation that you stored them outside of StarterGui and cloned them as needed to the players.