The essential trade-off you'll be weighing up is how much you rely on the current behaviour of ROBLOX vs. how much you want to be responsible for your own script and character instantiation flow. Historically, there has been very little freedom with how to organise the high-level structure of one's project, and superimposing any kind of manual script replication was a pain. Relatively new services like ReplicatedStorage, ServerScriptService, StarterPlayer, etc... have helped to remedy this a bit, though.
##StarterPlayer vs. StarterCharacter
As you may have discovered on the API page for LocalScript, they will only run in 4 specific locations:
- A player's Backpack
- A player's Character Model
- A player's PlayerGui
- A player's PlayerScripts
There are 2 differences between scripts in PlayerScripts and in Character:
- Scripts in
PlayerScripts are not visible to the server, but they are visible in Character
- Scripts in
PlayerScripts are not reset when the player dies/re-spawns, but they are reset if parented to Character because the model is usually destroyed.
##Where should I put my precious GUI elements?
Whatever you do, you don't want to put your GUIs in PlayerScripts or StarterPlayerScripts - they'll only be rendered if they're under PlayerGui. If you don't want them to be rendered, you can either make them invisible or manually control when they are copied into PlayerGui. For example, you can store them somewhere in ReplicatedStorage and use Clone() to copy them into a Player's PlayerGui when needed.
If you store them in StarterGui, ROBLOX will automatically copy them into each player's PlayerGui either when they join the game, or when they spawn (if StarterGui.ResetPlayerGuiOnSpawn is true).
##But what should I DO?
In my current project, I control the whole character and script instantiation process manually - nothing in StarterPlayer or StarterGui. I do this for 2 reasons:
- I don't know about the underlying implementation of the ROBLOX engine, so I prefer to control the order in which things happen manually so that it is easier to debug and not susceptible to unannounced changes.
- I can guarantee that server-side player data is setup before the clients are allowed to interact with it
ROBLOX doesn't make it easy to control what's going on with much fidelity. It's probably not worth it, so here are some simple rules to follow which will set you off in a healthier direction:
- If the script will reset when the player dies, put it in StarterCharacterScripts
- If you want the script to continue running whether the player is dead or alive, put it in StarterPlayerScripts
- If you want the Player to have a certain GUI (along with scripts that control it) immediately when they join/spawn, put them in StarterGui
- Any script or GUI which you don't want the player to have immediately, store in
ReplicatedStorage
Have fun experimenting. Maybe one day you'll come up with an amazing structural solution and you can come back here to answer your own question!
3 comments
Don't be confused by this TMGOR. AlphaGamer150 is assuming you were using a regular script. Using LocalPlayer for local scripts is the easiest and most effective method. Use PlayerAdded only if it's a server script instead.
So, I would use this if I wanted to, say.. create a GUI alerting all players that someone has just joined?
Yes