This question is pretty vague, because it has a simple answer (I hope).
Can a local script be placed inside of StarterGui (not PlayerGui), and be able to run?
I couldn’t manage to make it work, so I thought it could be an issue on my side, with how I implemented it in my script. I want to know if I should continue to try and make it work, or if I’m just wasting my time.
Nope. They don’t. When you create things in StarterGui they get cloned into PlayerGui. But could you explain your use case for wanting a script to run in there? I think use cases help out a lot when wanting to find a solution.
StarterGui is basically a container, whatever you put under that will be replicated separately for every player into another container called “PlayerGui”.
LocalScripts run under PlayerGui, server-scripts do not.
It’s a bit of a longer story, so bare with me please.
As my first ever attempt to make a player list gui, I came upon the issue of how I can give the data of what players are already inside the game to a player that just joined, so I thought of making a copy of an updated list instead of the original, blank one in StarterGui with all the players on it.
There are plenty of ways I can think of to go around this issue, but if this were to be possible, it would have made this much more easier.
To be more exact, upon a new player entering, a RemoteEvent was fired for all clients, which started a function of adding another player to the list.
Upon a new player entering, their list would not contain any of the players that joined the game previously, so to go around this, I wanted to make direct changes to StarterGui, in order for new players to get an updated version of the Leaderboard.
I already found some ways around this. The question I put up was pretty simple, and not regarding other ways of me to be able to achieve this, just if a localscript can do changes directly into startergui, not playergui.
Then your answer is: No, it cannot change anything under game.StarterGui, StarterGui is a service - Player.PlayerGui is not.
On another note, addressing this:
A very simple workaround would be to loop through existing players via Players:GetPlayers() and add them to the list.
Also firing a remote each time a player joins is pointless, Players.PlayerAdded can be called locally so players who join in the future would also be added to the list.