I’ve been running into the same issue again and again when firing an event on the server. I always need the player parameter and I’m not sure why. The problem is that it’s not always easy to get the player object from a server script. Is there any way to avoid having to pass the player as a parameter?
1 Like
If you’re referring to remote events, the player parameter is required as that is the destination of the network call.
EDIT: If what you need is script-script communication on the server, try using Bindable Events.
1 Like
I don’t understand, are you trying to fire a remote event without using player? No i think therws no wsy, as basically Once you fire a remote event you need to do It from clientisde, which is a player
You need to fire a remote event ( i am guessing) with the player argument, there is not a way to fire the client without the player argument, otherwise how do you know which client to reference. However if your firing the from the client to server the player argument is passed automatically
Or maybe shared or _G just saying or modules
If he wants to create his own custom event handler using _G or modules, he may do so. Otherwise, I’d stick with Bindable Events.
I should have been a bit more specific. Good to know that you have to add player as a parameter. This poses a question though, if my server script is in Workspace, how would I get the player object? What I’m trying to achieve is when a part gets touched, a sound stops playing.
I present to you the magic of the Players service. Roblox thought one step ahead.
Just make sure to check for a Humanoid before calling that function.
2 Likes
If the server needs to tell a certain client something, you will need the player object. This can usually be done because you already know the player that needs to be told from previous code, or if you need to fire all clients you can use a for loop or :FireAllClients.
I’m not sure what you’re trying to do though.
I dont recommend you to use parte.Touched, might be laggy without a debounce, try Region3
For something this simple, part.Touched will work fine. A debounce isn’t hard to add and Region3’s can get complicated. However, if it’s a sound system based on ambience per location, then yes, Region3’s can be used there.
1 Like
Yes thats what i mean, but i know its easy to add a variable but region3 would be better as he me mentioned sounds
You shouldn’t have to pass the player object at all because it’s passed implicitly. The first parameter received is the firing client and all subsequent parameters are for the data sent by the client. From the client’s end, it should only be sending data that it actually needs to send.
If you’re talking about the server needing to fire an event to a client and you don’t know how, that’s heavily dependent on the kind of system you’ve created such that it is capable of fetching a player and sending data over. For example, with Touched events, you first find a character and then an associated player then that’d be your player argument determining which client receives the event.
I think you’re after something like this.
When a part is touched, it checks if it’s a character and finds the associated player object. It then fires your remote event for that particular player. On the client you can then pause the sound you’re wanting to stop.
function touched( part )
local character = part:FindFirstAncestorWhichIsA( 'Model' )
if character:FindFirstChildWhichIsA( 'Humanoid' ) then
local player = game.Players:GetPlayerFromCharacter( character )
if not player then
return
end
YOUR_REMOTE_EVENT:FireClient( player )
end
end
YOUR_TOUCH_PART.Touched:Connect( touched )
Side Note: Using a region3 could limit the freedom of “detection”, it could be pretty inaccurate in some cases as there are mostly just cuboids and if you were to have spheres and all different types of shapes it would be difficult to detect if a player Is actually touching that part