How is my Humanoid.Died:Connect() giving my server script the player name/object?

  1. What do you want to achieve? Keep it simple and clear!
    I am trying to create a particle death effect. When someone dies in-game, red particles will explode out of their head.

  2. What is the issue? Include screenshots / videos if possible!
    My issue is after looking around in the internet I have managed to be able to make a death script that’s inside StarterCharacterScripts that waits until the player dies, calls a remote event, and in a server script does something.

Local Script

script.Parent:WaitForChild("Humanoid").Died:Connect(function()
	game.ReplicatedStorage.DiedRE:FireServer()
end)

Server Script

game.ReplicatedStorage.DiedRE.OnServerEvent:Connect(function(player)
	print(player)
end)

I am confused on how the server script knows which player the RemoteEvent received the FireEvent from? How is it possible it’s getting the player?
Knowing this would allow me to then spawn particles on the HumandoidRootPart.Position, but before I do any of that, I am seriously confused on what these two scripts are doing/giving eachother and how/why.

The first parameter passed through in FireServer() is ALWAYS the player object. If you want to send over something something else, it will be the second parameter.

Example:

--Client
game.ReplicatedStorage.RemoteEvent:FireServer("Hello!")

--Server
game.ReplicatedStorage.RemoteEvent.OnServerEvent:Connect(function(player, message)
	print(player, message) -- Output: (player), "Hello!"
end)
2 Likes

Makes perfect sense, thank you so much!!

Remote Events ~ FilteringEnabled Part One - YouTube You could watch this video to help you, it’s slightly outdated though. The “player” argument is automatically passed by Roblox to the remote event.

And btw, you cannot print a player, because a player is an Instance (object) not a string which the print function use, you could do that by saying print(player.Name).

You actually can print an instance, it will just print its name automatically.

1 Like

That is true, printing an instance will return the instance’s name.

I’d recommend combining server scripts together to save storage.

If you test run the game, by looking in your character model, you will see the default Character “Health” script.

Copy that health script and paste it in StarterCharacterScripts.

From there you can copy your remote event script inside the health script. Humanoid is already identified in that script.

Seems unnecessary and sloppy to me, wouldn’t do it. It’s more organized to just have 1 script for multiple remote events.

1 Like

All preference with the scripter. I respect opinion.

I guess I didn’t here about that update :slight_smile: .

Actually what I do is loop all Connections in a while loop.

Instead of having individual :Connect() things. For Example

Instead of Humanoid.Died:Connect()

while CustomWait(.1) do

if Humanoid.Health <= 0 then

end

end

That seems like extra work for less, well, everything. There can be up to a .1 second delay, and some things are better handled by Roblox. Also, connections don’t use a significant amount of performance to the point where you need to do this.

1 Like

Yea its unnecessary. But .1 can’t really be problematic ye? Ima stick to a loop for memory and less listeners. I’d go complicated for a small tip in memory.

.1 is 100% definitely noticeable. Can I ask who told you this? Or did you come up with it by yourself.

You should be more worried about that .1 difference instead of miniscule performance bonus, if that’s even true.

1 Like

.1 hm ok buddy :joy:. Actually i might be clowning but ima stick to the .1 reliance time.

This is a .1 difference of setting health (not humanoid related, you can make a gui disappear and appear in a .1 wait and you’ll see it):

character.Humanoid.Health = 50
    wait(.1) 
character.Humanoid.Health = 0

Like I said before:

1 Like

Ah it may make, like for example, a ragdoll have a .1 delay when Humanoid.Health <= 0. What if i made it .05.

That’ll probably be unnoticable ye? I mean catching something from a microdecimal delay shouldn’t be noticable to the naked eye.