CharacterAutoLoads: Why should you disable it

CharacterAutoLoads: Why should you disable it:

Game developers using Main Menus, this topic is mainly for you !

Hello everyone reading this. My name is Illusion (@christianluma), and I have been scripting on Roblox Studio since 2022. This is my first post on the devforum and today I will be talking about something I see a lot on multiple games and I will explain why is it a bad practice, as well as proposing my own method, its pros and cons.

As you can see in the title, I will be talking about CharacterAutoLoads. Now, to give some context, I see very often games (mostly with Main Menus) where the developers would allow the player to load his character, and set the character’s position inside a sort of closed box out of the bounds of their game map, with their Humanoid having a forcefield to avoid getting killed by potential exploiters. I then asked myself “Why would you create something specific for a character that is not used at the moment ?”

I then opened up Roblox Studio and did some researches until I found a magic button under Players, CharacterAutoLoads !!!

This button prevents any players joining the game to be able to control a character, and thus, it requires a ServerScript to load itself a Player.Character.

Now here’s the twist: Disabling CharacterAutoLoads also prevents any GUI inside StarterGui to be cloned inside the Player.PlayerGui. This seems problematic, as you would generally allow the Player to click on some buttons to atleast spawn on the map.

This is why I am also proposing a great way to get GUIs without CharacterAutoLoads enabled:

To achieve this, you will need these 3 things:

  • A server script, located in ServerScriptService
  • CharacterAutoLoads = false (You might not want to disable it in a script but rather generally in the studio)
  • A folder set inside ServerStorage (ReplicatedStorage also works, but less secured if you own Admin GUIs for example)

After these steps done, put your GUIs inside the folder, they are now stored and needs a ServerScript to be sent to the player.

To do so, here is basically the ServerScript I make:

game.Players.PlayerAdded:Connect(function(Player)
	for _, GUI in game.ServerStorage.User:GetChildren() do
		GUI:Clone().Parent = Player.PlayerGui
	end
end)

Explanation of the Code:

-- Player Added is an Event triggered whenever a player has joined the game: we store the player Instance inside a variable named Player.
game.Players.PlayerAdded:Connect(function(Player) 
	-- for loops are used to iterate: _ means no indexes, GUI is the current object at the iteration.
	-- We iterate through a folder in ServerStorage named User. 
	-- GetChildren() is a method storing every children of an Instance inside a table. We don't need to use pairs() and ipairs() (Some would say it's a bad practice to use them)
	for _, GUI in game.ServerStorage.User:GetChildren() do
	    -- Clone() creates a copy of an Instance, here we clone the current GUI and we move it to the PlayerGui of the player.
		GUI:Clone().Parent = Player.PlayerGui
	end
end)

This code is a reallly basic code to give GUI to any player without their character loading.
But this code alone will still not allow you to load a character. You have to use Player:LoadCharacter().
Example: You have a Main Menu. Your point is to make the player spawn in. LoadCharacter() will not work in LocalScripts. If you want the player to spawn itself (example: the Player clicks a button), you will have to set a RemoteEvent firing from a LocalScript to a ServerScript, which will use LoadCharacter().

Finally, CharacterAutoLoads means the character will not load, and so, the death of the Player’s Character will result in not being able to spawn in back automatically.
You will need a script from the server detecting someone’s death, and apply LoadCharacter() (or maybe make them return to the MainMenu, etc…)
Be careful: The Character never gets removed from workspace, unless you call Player.Character = nil or use the LoadCharacter() method (which will replace the previous character, not delete then create)

This seems like I explained how could you implement such a system, allowing you to have much more control on your Players and their Characters. Thank you for reading me and have a nice coding session !

(P.S: I didn’t talk about performances gain/loss nor security features, you might find your own way aswell, that’s where the word creativity takes place :wink: )

14 Likes

I would like to add that maybe cloning all the UI on the server is not a good idea. 90% of the time there is no need for the server to control the UIs inside a player, and players dont really need to know the contents of other players’ UI either. Reparenting them on the client might be a better idea, unless you use ResetOnSpawn (which, in this case, you probably shouldnt be using either) It would help save a bit of memory too.

1 Like

I always manually parent my UI over to PlayerGui with an external script and control it with a reference. That way, UI always loads, and you don’t have to go through a bunch of WaitForChild chains.

I really wish there was some sort of immutable singleton to put UI in, cough cough.

1 Like

Thank you for your answer. However, the problem with what you are saying is that if i directly set the Parent, the object will cease to exist in the server storage, which means new players will not be able to get the UI. Also, players can not know the playerGUI of other players, only self and server can access to it.

I was talking about parenting the UI on the client side, which means other clients and the server would still see all the UI in its previous place.

Here is how I do it:

  • In studio, all UI is in StarterGui for easy editing
  • On the server, all UI gets reparented to a folder in ReplicatedStorage to prevent the default behavior
  • On each client, all the UI gets reparented to their PlayerGui
1 Like

I got your point now. I think it really depends on your situation: in my case, I usually have special UI like administrations one, and instead of giving them to everyone and limit access with the server’s help, i would let the server gives it itself to specified players. And I also like centralizing everything so I only use one script that chose what to give to who. It may be a bit slower, but will do the work asked

1 Like

I don’t think this is necessary anymore. New Player and Character Destroy Behavior

1 Like