How do Remote Events & Functions play out, how do they work and what do they do?

Remote Events and Remote Functions can be communicated with or activated using a local script on the client side, and that's the only way for clients to communicate with the server. I know I'm bad at explaining. So let's say you want to increase a value, you can use a local script make the a value in leaderstats increase, but it'll only increase locally. Other players in the same server won't be able to see the increment because you're using a local script. The only way you can change anything of the server is to request using events, and to do that you'll have to have a local script which would fire the event then a script in SeverScriptService would check and perform something in return. Local scripts should only be on the client side, like in StarterGui, Backpack, etc.. If you put a script (local script won't work in workspace) in workspace, you don't need to fire any event because it's directly connected to the server, so if you have a pad or a part that give values to a player, you just insert a script into a part that states whenever a player touch this part, their certain stat will increase.

And btw, PeasFactory is really helpful. Happy scripting. https://www.youtube.com/channel/UCUC3i1csDpG4Xqg8KBnraEQ You're probably still be confused, so ask away if you have any more questions.

A remote event is a 1 way connection with your target of choice. If fired from a local script, a remote can only send to the server. if fired from the server, it may only send to every client or an individual one.

e.g say you had a remote event in replicatedstorage

Local script:

--lets say I wanted to change the color of a part with FE enabled.
script.Parent.ClickDetector.MouseClick:connect(function()
    local variable == 'urfatmum'
    game.ReplicatedStorage.remote:FireServer(variable)

end)

arguments are the hardest part of remotes, by far. Arguments are optional, however whatever you're trying to send put it on the fire server part.

Server script: (the reciever in this case.)

game.ReplicatedStorage.remote.OnServerEvent:connect(function(player, newnameforvariable)
    print(newnameforvariable)
    workspace.Part.BrickColor = BrickColor.new("Black")

end)

Now let's talk about those arguments. We fired a variable from the client, but we have a player now?? Whether a remote event or remote function, you must ALWAYS have a player argument on the receiving end.You don't need to send over a player value, it'll do it for you. Make sure the player is the first argument on the reciever, so you don't accidentally name something wrong.

On the receiving end you may name the arguments whatever you want if it helps.

Let's talk remote functions, my personal favorite. Say we wanted to do the same thing as last time, but if everything went okay we'd send over a gui saying all went well.

Same setup as last time, local script:

script.Parent.ClickDetector.MouseClick:connect(function()
    local variable2 == 'urfatmum2'
    local diditwork = game.ReplicatedStorage.remotefunc:InvokeServer(variable2)

    if diditwork == 'shutup' then
        game.ServerStorage.Gui = game.Players.LocalPlayer.PlayerGui

    else
        warn("oh frickkkk")
    end
    end
end)

Notice how we named the invokeserver part something? You can go without naming it, but if you want to send Data back via a 2 way connection, assign your function to a variable.

Server script:

game.ReplicatedStorage.remotefunc.OnServerInvoke = function(player, variable2)

    local yes,no = pcall(function()
        workspace.misspelledpart.poop = fart
    end)

    if yes then
        return 'shutup'

    else
        print("somethn went wrong chief: "..no)
        return false
    end
    end

end

What we just did is recieve an invoke, and pcall an incorrect operation thus not actually doing the function correctly, by making use of return we can return something to our if statement back on the local script. If our function ran okay we'll send that it worked and on the local script give us a gui. If it didn't work, we'll return false.

I didn't cover a lot, but that's a general idea?