Player list not working?

I’m trying to make a voting system, where people can vote a player as a king. There is a problem though. My player list doesn’t seem to be working. It’s in a local script, but i tried it with a server script and it didn’t work!
Here is the code to it.

---Wait for game to load
wait(2)
---Variables
local frame = script.Parent.ScrollingFrame
local pos = UDim2.new(0, 0,0.059, 0)
local playerservice = game:GetService("Players")
local players = playerservice:GetPlayers()
local player_table = {}
---Functions
function ButtonForPlayer()
	for i = 1,#players do
		if players[i] then
			local button = Instance.new("TextButton",frame)
			button.BackgroundColor3 = Color3.new(255,255,255)
			button.TextColor3 = Color3.new(0,0,0)
			button.Text = players[i].Name	
			button.Position = pos
			table.insert(player_table,players[i])
			return button
		end
	end
end
---
function Wipe(player)
	local button = ButtonForPlayer()
	if button then
		button:Destroy()
		table.remove(player_table,player)
	end
end
---Events trigger functions
playerservice.ChildAdded:Connect(function(c)
	if c then
		print("Player added!")
		if c.Name then
			print("Player has name!")
			local button = ButtonForPlayer()
			if button then
				print("Got button!")
				if button.Text == c.Name then
					print("Text = players name, calling function!")
					ButtonForPlayer()
				end
			end
		end
	end
end)
---
playerservice.ChildRemoved:Connect(function(c)
	if c then
		print("Player removed!")
		if c.Name then
			print("Player had a name!")
			local button = ButtonForPlayer()
			if button.Text == c.Name then
				print("Button text = players name, wiping button from list!")
				Wipe(c)
			end
		end
	end
end)
2 Likes

I’d recommend re-writing this so that you use a LocalScript to call a RemoteFunction that returns game:GetService(“Players”):GetPlayers(), and also use a script on the server to listen for a PlayerAdded event, which would in turn fire a RemoteEvent to all clients which would in turn prompt the client to call the RemoteFunction to update the player list. You could also just use solely a RemoteEvent, so that when a player joins the server fires all clients with the list of players passed to each client using the event.

Why in the world would you need to get networking involved here… game:GetService("Players"):GetPlayers() can be called on the client and so can PlayersService.OnPlayerAdded. You are just over complicating the matter.

yeah, but calling Players.PlayerAdded won’t work for the local player, because technically local scripts replicate after the event fires, so doing it on the client you’ll need to use the event to get newly added players and get the current player through Players.LocalPlayer as well; this does prove simpler then involving multiple remotes though.

1 Like

I dont know where you heard Players.PlayerAdded doesnt replicate. Try it in roblox studio to see for yourself before disregarding someones idea :slight_smile:

What?
Where in my post does it say it doesn’t replicate?

I think you misunderstood, what I’m saying is that a function bound to the Players.PlayerAdded event will not fire for the specific LocalPlayer, as the event would fire before local scripts replicate.

I went ahead and tried this in Studio, just to inform other developers that it does in fact not work this way for the Local Player.

image

	game:GetService("Players").PlayerAdded:Connect(function(player)
	     print(player.Name)
	end)

as expected, this did not print

Oh, that is what you meant. Yeah you’re right but the localplayer still shows up inside of :GetPlayers()

of course it does, :GetPlayers() returns an array of all player objects in the server.

PlayerAdded fires almost right after a player joins, but local scripts take time to replicate.

1 Like

This is why OP’s code should run through all players when they join and add/remove players at runtime

If you find the clean and simple solution I offered over-complex then it sounds like you need to revisit that topic. That’s not my issue if a simple concept is not fully understood by somebody else.

It is more secure, simple, ensures an order to the events that need to occur, and allows for easy and secure expantion if you desire more functionality.

1 Like

The problem is though, you dont need a purely ease of life feature to be secure.

1 Like

Yes, I realize that, but it’s really not complicated to implement, and if a feature that does need to be secure is ever added down the road, then it would be much easier to expand than rewriting all the code.

It’s just a difference in opinion really. Both work. I don’t see any major reason to use one over the other. Personally I feel that my solution is simpler but if you disagree that’s fine. I just don’t appreciate you trashing my solution as incorrect when it is totally valid and does have some advantages.

But yes, you are correct in this particular instance it does not need to be secure.

1 Like