I’m very new to scripting and I believe I have most of the basics covered, so I tried to follow along with a script and I noticed that I’m not sure when to use “.” or “:” Here is an example below. Why was . used after Players and not : also why was : used after PlayersAdded and not .?
I’m not the best at explaining things, but here I go…
We generally use a . whenever we are trying to navigate through a certain instance, basically its children. PlayerAdded is an event which is bundled with the Player instance whenever a Player joins your game.
As for using a :, it’s used for functions, such as :Connect(), which connects when a certain event gets triggered, such as your case, or when playing a sound (e.g. :Play())
So from what I understand I believe you’re trying to explain is that PlayerAdded is a child of Players? Since you said that’s when a . is used? Also I may be confused between a Service and an Event. Maybe that’s where the . and : are set apart? Also, I like to think that whatever has a () at then end is a function, is that correct?
And when we say “children” or “child” what do we mean? Lets say I open the properties of a part, are all the things such as colour and transparency children of that part?
Okay, let’s just take it as if Events are objects which can’t be seen in the Explorer, but they are still usable in games.
A service is just like the main folders which are at the top level of your game’s Explorer. An event is something that is part of the Service. Let’s say you want to make a function such that something happens when a part is touched. You wouldn’t say…
Touched.game.ReplicatedStorage.Part:Connect(function(Player) -- Touched is not a service?
Instead, you will say…
game.ReplicatedStorage.Part.Touched:Connect(function(Player) -- ReplicatedStorage is a valid service in the game.
Yes, I suppose you could say that. You can search up certain functions for how to use them/their parameters on the Roblox Doc.
No, those are called properties. They all can be called with a . though. Let me show you an example:
Say, you wanted to change whether a script is enabled inside of a brick, and its transparency
local brick = game.Workspace.Part -- Navigating to the Part in the Workspace.
local brickScript = brick.Script
local brickTransparency = brick.Transparency
brickScript.Enabled = false
brickTransparency = 1
Normally, you can see whether something is a property by opening the game’s Explorer and clicking on a certain part, then toggle over to the “Properties” tab. Any value that appears there is pretty much a property of that part.
I also am confused about parameters. I don’t understand why I need a parameter in this script. (playerPart). I also don’t understand how the script knows how PlayerPart is a part of a player that touches the block, I mean it could mean anything??
local fireBlock = script.Parent
local function fire(playerPart)
local player = playerPart.Parent
local human = player:FindFirstChild(“Humanoid”)
if human then
human.Health = 0
end
It’s a parameter that returns what exactly makes contact with the Part. See the Touched event Document on my previous reply for more information.
You can name “plr” to anything you want, but it’s there so we have something to specify to studio on what exactly touched the Part. Let’s say…
Whenever a Player touches a brick, what makes it a… Player? Its humanoid!
Therefore, we need to check whether the part which touched the part is part of an actual Player, which we will then find for their Humanoid.
local part = game.Workspace.Part
part.Touched:Connect(function(PartTouched)
local player = PartTouched.Parent -- For example, if your legs touch the part, the script will check for the parent of your legs, which will be your character!
local humanoid = player:FindFirstChild(“Humanoid”) -- Here, we are checking whether there is a Instance in this part’s parent for instance named “Humanoid”.
if humanoid then -- here, we are checking if the variable humanoid returns anything. If it does, then there’s a Player! Otherwise, the script will ignore this part of the code, since it does not meet the condition.
humanoid.Health = 0 -- We are setting a property of a Humanoid! In this case, Health is a property for Humanoid (self-explanatory on what the Health property is)
end
end)
So basically playerPart returns what touched is…then we set that value in a variable called player? Then it looks inside for whatever was touched to look for a thing called Humanoid. When it’s true it will set the health to 0? I’m still quite confused but I may have a very tiny idea about what’s happening.
Let’s break it down here on what the variables/parameters in the script means:
PartTouched - Returns the part which touched the specified part. player - Searches for the Parent of the PartTouched humanoid - Searches for a Instance named “Humanoid” in the variable player.
How do I know what events I need for whatever I am trying to make. I don’t have an example but if I wanted to make something there’s no way id know what events to use. There’s so many and what if that specific thing I’m trying to make doesn’t have an example to look at? Sorry for spamming you with so many questions. This is very new to me. Thanks for your help so far! I really appreciate it!!!
First, I’d like to explain the period. Periods are typically used for indexing objects, properties of objects, or events of objects. For example, a child of the workspace, such as a part could be indexed using workspace.Part. (This does not mean properties or events are children of workspace, according to roblox, they are members of a certain class, whether it’d be a part’s Transparency, a Button’s click event, etc) This is not it’s only usage, however. For instance, if you were using built-in roblox events, or even creating you own objects later on with modules, you could detect them using events such as MouseButton1Click, PlayerAdded, etc all using the period. (Indexing can also be done using brackets workspace["Part"] but is more widely seen used in tables, dictionaries, and loops.
Next, I understand that the colon, “:” can be confusing. The “:” is used to call methods. In the example in the image, the :Connect method connects an event to code, making it useful. Also, for now, you could view methods as calling a function on an object and events as detecting certain changes. This does not mean all things with parenthesis are functions, although all functions contain parenthesis to pass arguments, making it similar to methods which do the same. Arguments can be visualized as data being sent from where certain code is being called, and requires extra information on how the code should be ran. Server to client communication is a good example. RemoteEvents sent from the server are requires to provide the first argument of Player, which determines which player’s client will run the code, along with additional optional information that may be needed depending on the situatioon.