Because I want to make a function inside the PlayerAdded function I mean Player.CharcterAdded:Connect so if the character spawn he will get a tool/gui in game.
Because I want to access the UserInputService.
1 Like
You can use PlayerAdded in a localscript, but it wont detect your player joining because you join before the localscript executes, though for your usecase I don’t think you need to use any events.
If you want access to UserInputService, I think making a localscript in StarterCharacterScripts is enough, and for giving a tool/gui on Character spawn, what you can do in a regular script is when a player is added, clone the tool into their StarterGear and their Backpack, and the gui into their PlayerGui
6 Likes
Because I want to make a flatform detector that it will detect if you are in mobile or no but IDK how to do it wil replicated events
I’m not 100% sure if this works, but you can do this:
local player = game.Players.LocalPlayer
player.CharacterAdded:Connect(function(Character)
end)
1 Like
Local scripts never run before player joining, if you want to wait for character to spawn
game:GetService("Players").LocalPlayer.CharacterAdded:Wait()
1 Like
Instead of adding tools/GUIs in a LocalScript, you should make your tools/GUIs be created server-side in a server script. You can also do that with StarterGui or StarterPack, which will add GUIs or tools automatically when the player’s character spawns.
This makes sure the server also knows they exist too, so you can do server-side stuff. Otherwise, you’ll only be able to do stuff to the tool or GUI that the player can see locally and no other players will see the player hold the tool for example.
Then, since you want to use UserInputService you should have your code that needs it be in its own LocalScript, for example, inside of your tool or GUI.
You can have the LocalScript talk to the server using RemoteEvents or RemoteFunctions, which let you send messages to the server (or from the server to a player or players).
However, it’s important to mention if you do use remotes for anything, you should think about what you let your remotes do in your server code. Most exploiting (cheating) is basically like adding new, much more powerful LocalScripts to your game that you aren’t able to detect (and that’s a good way to think about it). So anything that you can do in your LocalScript a cheater can do too. You should think about it as if they can write new LocalScripts to add to your game, and that means that you don’t want your LocalScript code to be able to tell the server to do unreasonable things even if you don’t necessarily tell it to yourself
Instead, it’s good to treat remotes like simple requests to do certain things that the server will do if it decides it’s okay. For example, a remote might tell the server to “buy an upgrade” and the code to decide if the player can buy the upgrade (e.g. if they have enough money) should happen in the server code, so even if a cheater asks the server to buy an upgrade the player can’t actually buy, it won’t.
4 Likes
No need to get the player to use UserInputService.
You can find the documentation here: UserInputService.InputBegan (roblox.com)
But I don’t know how to use remote event or remote function I know a little but It’s not working Is there any way to detect a player if the player using mobile/pc? look this post
You can use
local UIS = game:GetService("UserInputService")
If UIS.TouchEnabled == true then
print("Player is on mobile")
elseif KeyboardEnabled == true then
print("Player is on pc")
else
print("player is on console")
end
You can use it. Certainly. Would you want to though? That depends on your requirements.
Generally if you use it locally, whatever callback you pass to Players.PlayerAdded.Connect would not run for connecting players themselves, but it would for players that connect to the game after this script runs for the player. Usually you want to do this on the server.
For this, you can use a normal Script under ServerScriptService, use the PlayerAdded event, and clone the LocalScript accordingly. However, you also can use use the LocalPlayer part of a LocalScript via game:GetService('Players').LocalPlayer to directly get the player.