Can you use PlayerAdded from the client?

Help and Feedback Scripting Support
#1

Hi, I’ll get straight to the point. I am making a administrative panel just out of fun and to extend my knowledge on LUA, and I was wondering if it was possible to use player added to detect when a player joins locally.

I want to add a new player image label when a new player has joined automatically to allow the administrator to do actions to the player. Current code:

local players = script.Parent
local playerService = game:GetService("Players")

playerService.PlayerAdded:Connect(function(player)
	
	local playerUi = Instance.new("ImageButton")
	playerUi.Parent = players
	playerUi.Image = "rbxassetid://2790390993"
	
	playerUi.ImageColor3 = Color3.new(49, 49, 49)
	playerUi.ImageTransparency = 1
	playerUi.Name = player.Name
	
	local playerName = Instance.new("TextLabel")
	playerName.Parent = playerUi
	playerName.Name = player.Name
	playerName.TextTransparency = 1
	playerName.BackgroundTransparency = 1
	playerName.TextSize = 16
	playerName.TextScaled = false
end)

As you can see, I’ve already made the function. I tested it in a real game and it didnt work, assuming that you cant call it from the client. I’m planning to do it from the server but I want to double-check because doing it from the server seems tedious.

1 Like
Player.Added event not changing player's hp
Weird issue with textlabel
#2

Expected result is this, a new player being added to the player frame.
https://gyazo.com/3dd63f42e7163f9b56819fd5317dad05

#3

Yes, PlayerAdded can be used by both the server and the client. It doesn’t fire for the LocalPlayer though because the LocalPlayer will already be connected to the server by the time PlayerAdded fires for them, if that’s what the issue here was. You need to account for that case yourself by

A) Running the function again later.
B) Explicitly handling the case of the LocalPlayer.

local function playerAdded(player)
    myCode()
end

playerService.PlayerAdded:Connect(playerAdded)
for _, player in ipairs(playerService:GetPlayers()) do
    playerAdded(player)
end
7 Likes
#4

Yes you can, but you can loop through all players when the player is added and add the player frame with a for loop.

game.Players.PlayerAdded:Connect(function()
	for _, v in pairs (game.Players:GetPlayers()) do
		-- Add player frame to each players, Player.PlayerGUI.GUI
	end
end)

Although colbert’s solution might be better.

#5

Is this guaranteed to be safe, though? Isn’t it better to have it on the server and fire a remote event to the clients telling when a player has been added? I do this when I want to send extra information associated with the player (replication), but I do not know for a case where there isn’t an associated data to be sent.

#6

This existing on the client allows for many operations to be conducted without the need for network traffic. Performing code on a single client for connecting players has zero security concerns unless the developer introduces such concerns.

You could create an event for when a player joins and perform an action locally that uses that players information however you see fit. From adding the player name to a list of nearby players to having your local player ask the server to do something like “teleport me to the player who just joined because he’s my friend.”

1 Like
#7

Yes this is guaranteed to be safe. Depending on the kind of system you’re making though, you may want to consider using a RemoteFunction so that the client can request data from the server as in when its LocalScripts start executing rather than the server eagerly sending data when a player joins. LocalScripts would not be able to work with the data that the server sends unless the receiving data is queued in the remote, though I’m not sure if this is the case.

1 Like
#8

How about to the point of using CharacterAdded for other players on the client to?

Should I change my code to have PlayerAdded on the client? Right now it’s all on the server and sending a remote event. Or is it negligible?

#9

Yes, CharacterAdded will also work on other players.

Typically my preference when it comes to the server wanting to send the client data, especially join data, is to follow a lazy approach rather than an eager one. That is, that the client requests the data when it’s ready as opposed to having the server shove the data on the player. Pretty sure that is the normal pattern for this kind of work.

If your current system works then you don’t need to change it. The main bottleneck I can see here is simply being the network traffic because a RemoteFunction performs a round trip whereas a RemoteEvent is a single trip. Ultimately you aren’t looking at a whole lot of significant changes if you change the structuring, just practice problems. What may change:

  • When the client receives the data, which would be when LocalScripts start as opposed to when the client joins. The only LocalScripts that start immediately on join are those in ReplicatedFirst, the rest start after game.Loaded fires (or game:IsLoaded() returns true).

    • Helps with code predictability. You know exactly when the client receives data - when InvokeServer returns - over making guesses. I also don’t know if RemoteEvents queue for OnClientEvent. If they do, then my whole point is moot and you can ignore this post.

  • Round trip as mentioned earlier. Practice-wise a RemoteFunction is better but network wise a RemoteEvent is better. Round trip versus single trip. For servers in regions further from client machines, it can take long for data to be sent and/or received.

I wouldn’t say it’s negligible, but it’s not significant.

1 Like