Scripting Helpers is winding down operations and is now read-only. More info→

How does the script know what these are?

Asked by

emite1000 335

10 years ago

It was not until today that I finally read and understand how parameters/arguments of functions work. However, I don't understand how they work when the function is declared as it is called. For example:

`1`	`ClickDetector.MouseClick:connect(function(clicked)`

`2`	`local` `Sgui` `=` `Instance.new("ScreenGui", clicked.PlayerGui)`

The parameter "clicked" is never defined as a value since the function is called then and there. Yet this script will work to make a ScreenGui appear inside the localplayer's PlayerGui. How does it know what "clicked" is?

3 answers

Answered by

BlueTaslem 18071

10 years ago

:connect is not a straightforward use of functions -- it isn't using functions like they normally are.

This is a really good question -- this is a weird bit of code, and it's a little disappointing not many learning scripters realize how strange it looks.

I'm going to use the Touched event as in my examples, but it works the same way as the MouseClick event.

First, let's write our connection separately from the definition of the function:

1function makeRed( part )
2    part.BrickColor = BrickColor.red()
3end
4 
5workspace.Wall.Touched:connect( makeRed )

part is defined, in the scope of the makeRed function, to be the first value that makeRed is given when called.

First of all, ignoring the :connect line, we can just use makeRed ourselves:

`1`	`makeRed(workspace.Player1.Torso)`

`2`	`makeRed(workspace.BasePlate)`

The first line, part will be the player's Torso; the second line, it will be the BasePlate.

Here's something Lua lets us do. It's called first class functions or higher ordered functions (EDIT: had serious nomenclature typo)

01function makeRed( part )
02    part.BrickColor = BrickColor.red()
03end
04 
05function makeBlue( part )
06    part.BrickColor = BrickColor.blue()
07end
08 
09local changer
10if math.random(2) == 1 then
11    changer = makeRed
12else
13    changer = makeBlue
14end
15 
16-- Notice that we did not CALL either makeRed or makeBlue
17-- We just used the *function itself* as a *value* (just like
18-- I can use variables like `workspace` or `ClickDetector`)
19 
20changer( workspace.BasePlate )
21-- half the time will be red, half the time will be blue
 View all 21 lines...

What happened here? changer now stores the value of a function -- that means when we call changer, it will actually be calling the function we assigned it to, which was either makeRed or makeBlue.

:connect does a similar thing. When you say :connect( makeRed ), you aren't calling makeRed. You're giving the value of makeRed so that ROBLOX can call it later.

Here's a fake implementation of how .Touched:connect( x ) might work:

1function connect( xfun )
2    while wait() do
3        local near = getNearestPart( workspace.Wall )
4        if areTouching(near, workspace.Wall) then
5            xfun( near ) -- Here!
6        end
7    end
8end

How does it know what [the parameter's value] is?

Somewhere, :connect is calling your function with a parameter -- :connect tells your function what the parameter is, in the same way that functions normally get their parameters

Higher ordered functions are awesome. Here's an aside on the makeBlue and makeRed we had earlier:

01function makeColorChanger( str )
02    return function(part)
03        part.BrickColor = BrickColor.new(str)
04    end
05end
06 
07makeRed = makeColorChanger("Bright red")
08makeBlue = makeColorChange("Bright blue")
09makeGreen = makeColorChange("Bright green")
10-- etc!
11 
12-- Let's make the baseplate red:
13makeRed( workspace.BasePlate )
14-- OR:
15makeColorChanger("Bright red")(workspace.BasePlate)
16-- Funny looking, but awesome that it works

MouseClick Case

The parameter is the player who clicked. (It isn't the LocalPlayer -- a "Script" object (as opposed to a LocalScript) doesn't have the concept of a LocalPlayer)

ROBLOX obviously can know who clicked it, since the game has to know it was clicked at all (so it just also adds, "it was this guy"). So ROBLOX just informs the event of that information.

I understand your answer and how variables can store a function as a value, but as for how that snippit of code I posted works it seems that your answer is just "somwhere somehow it's getting the Localplayer?" (I'm not meaning this as an insult or anything, but is there anyway you can explain [if you know how] it is getting that?) emite1000 335 — 10y

It *isn't* the LocalPlayer -- it's the player who clicked. ROBLOX obviously knows who clicked it, since the server has to know it was clicked at all. So ROBLOX just informs the event of that information. BlueTaslem 18071 — 10y

(Sorry about the very late response. I didn't realize you added another comment.) So the Event is giving that information to the function? I kind of expanded on this here: https://scriptinghelpers.org/questions/15736/do-events-provide-built-in-arguments emite1000 335 — 10y

Correct. The event passes the argument to the function. BlueTaslem 18071 — 10y

Answered by

Redbullusa 1580

10 years ago

Notice in this link that the parameter is playerWhoClicked.

The MouseClick event's parameter returns the player model. This is a built-in feature of this event.

Another such example is the HealthChanged event. The example uses health as the parameter as the value "Health" is changed to.

Truth be told, I don't really know. I pretty much assumed that's how some events behave.

Answered by

emite1000 335

10 years ago

Answered in Do Events provide built-in arguments?

How does the script know what these are?

3 answers

MouseClick Case

Answer this question