They both seem to be the ‘Client Script Service,’ for client side scripts that run once. But when should I use one or the other?
1 Like
ReplicatedStorage scripts will always run first; This can be used for asset loading and loading screens. StarterPlayerScripts is useful for input behavior, StarterCharacters, and stuff relating to the player.
1 Like
ReplicatedFirst would run scripts first, (due to the name?) + also where custom loading gui screens are located, you have got them mixed up
If you want scripts to run before anything else, place them in ReplicatedFirst, note that you will need to use :WaitForChild().
2 Likes
What? You didnt read my post clearly, it is for preloading assets and loading screens.
Im confused, dont you place your loading screens in replicatedfirst?
Bro, you place the loading screens in StarterGui, and then if the loading screen is for asset purposes, you use ReplicatedFirst, and then preload the assets and display the count of assets in the loading screen.
use replicatedfirst’s function called RemoveDefaultLoadingScreen, it’s something like that
local Players = game:GetService("Players")
local ReplicatedFirst = game:GetService("ReplicatedFirst")
local player = Players.LocalPlayer
local playerGui = player:WaitForChild("PlayerGui")
-- Create a basic loading screen
local screenGui = Instance.new("ScreenGui")
screenGui.IgnoreGuiInset = true
local textLabel = Instance.new("TextLabel")
textLabel.Size = UDim2.new(1, 0, 1, 0)
textLabel.BackgroundColor3 = Color3.fromRGB(0, 20, 40)
textLabel.Font = Enum.Font.GothamSemibold
textLabel.TextColor3 = Color3.new(0.8, 0.8, 0.8)
textLabel.Text = "Loading"
textLabel.TextSize = 28
textLabel.Parent = screenGui
-- Parent entire screen GUI to player GUI
screenGui.Parent = playerGui
-- Remove the default loading screen
ReplicatedFirst:RemoveDefaultLoadingScreen()
--wait(3) -- Optionally force screen to appear for a minimum number of seconds
if not game:IsLoaded() then
game.Loaded:Wait()
end
screenGui:Destroy()
---I stole this from the devpage
3 Likes
Bro no, you remove roblox’s loading screen, then add yours, havent you seen devpage? There is a function for thay
Yeah thats what im talking about
I was talkin about that…This text will be blurred
And so was i ||weeeeeeeeeeeeeee||
Better yet, I could use ReplicatedStorage with scripts where RunContext is set to Client.
Sounds gross. I would never endorse running scripts in storage services even if you can just use RunContext. Sounds like an organisational nightmare for one and for two, it’s probably better that you put them in their canonical locations anyway.
It’s not exactly wrong to put your game code in ReplicatedFirst but canonically you only want to use ReplicatedFirst for things that need to be ran or shown to the player as soon as possible upon connecting to the server (e.g. loading screens). StarterPlayerScripts populates PlayerScripts in the Player object, the canonical replacement for the archaic method of using StarterGui as a container for client-sides. It’s the dedicated client equivalent of ServerScriptService (and, to boot, ServerScriptService being the canonical replacement for putting server-side code in the Workspace).
2 Likes
local GUI = script:WaitForChild("Intro"):Clone()
GUI.Parent = game:GetService("Players").LocalPlayer:WaitForChild("PlayerGui")
Are you talking about this? Because it’s quite simply to load an intro gui on replicatedfirst.
The problem with both ReplicatedFirst and StarterPlayerScripts is if I add a client script there from the server after a player joins, it is not copied and/or replicated and executed by the player. ReplicatedStorage, however, solves this problem.
I mean… yeah, that’s how they work? The contents of ReplicatedFirst are only replicated once during the initial snapshot. PlayerScripts is a non-resetting container that’s only populated when the client initially connects. ReplicatedStorage is part of general replication that happens during the initial snapshot as well as throughout the session’s lifetime.
Adding contents to starter containers doesn’t reflect the changes to the player until there’s a need to reset the container that they will eventually populate (Backpack for StarterGear and StarterPack, PlayerGui for StarterGui, PlayerScripts for StarterPlayerScripts). You have to copy them to the runtime containers yourself or, in the case of client code for example, signal to the client to execute that code (e.g. via remotes), which is the preferable method to dynamically adding scripts.
You haven’t supplied a use case anywhere throughout the thread so it’s hard to figure out what you’re trying to accomplish here overall and the alternatives that could be provided but using RunContext to sidestep those misunderstandings of replication across a session’s lifetime rather than resolving your actual root problem doesn’t sound like a good solution to commit to. Nothing wrong with running code on-site now with RunContext but sounds like you have an XY problem on your hands if the site in question is ReplicatedStorage.
4 Likes
nah you have a gui located under your script that is in replicatedfirst
why is bro responding to a 1 year post
shouldnt this thread be closed by now