Hi so I’ve seen RemoteEvents (I know how to use them) but there’s Bindable Functions… what are they for? Are they any different from RemoteEvents, bye.
3 Likes
Bindable functions are used for script to script communication (same type). For example, if you need one server script to connect with another server script, instead of using RemoteEvents (firing to client, back to server), you can easily use a Bindable event and fire straight to that script. To use is simple, create the event where both scripts are able to access, then just run
Bindable:Fire()
And to receive the event, simply do
Bindable.Event:Connect(function()
9 Likes
They can be used for script to script communication.
For example, Sharing data between scripts or activating an event to happen.
They can’t be used for client to server, that’s why RemoteEvents exist.
Here’s the API on it:
Event:
Function:
Bindable Functions are basically functions you can invoke from anywhere and only work script to script, you can’t use it for client to server communication, that’s what Remotes are for.
Here’s an example
--Script 1 in the BindableFunction
local func = script.Parent
func.OnInvoke = function(a,b)
return a + b
end
--Script 2 in workspace/anywhere that a script can be ran
local func = workspace.BindableFunction
print(func:Invoke(5,10)) -- returns 15
Someone please correct me if I’m wrong on something
9 Likes
RemoteEvents & RemoteFunctions are for server to client communication, while BindeableEvents & BindeableFunctions are for server to server communication or client to SAME client communication.
The difference between Events and Functions is that Events will send data over event connections making them one way method of communication. Useful for if the thread sending the event is not expecting a response.
Functions on the other hand will use callbacks and are expecting a response back. Allowing you to separate code between scripts.
Would I recommend them? No, ModuleScripts are a much better option if you want to split up your workflow between multiple scripts.
Thats actully kinda nice! But one question… do you have to pass the player inside the braquets like this:
Bindable:Fire(player, Arg1, Arg2, Arg3)
No, as communication using BindeableEvents or Functions doesn’t pass between parts of the client - server model. But I would recommend just using ModuleScripts instead.
If you want to then yes, if you do not then no, the player argument isn’t set as default in Bindable Events.
The only time that is required if you’re firing a RemoteEvent, BindableEvents do not explicitly require you to give it a player parameter, as others have said
Okay, now I know what BindableFunctions are for. They can sometimes be useful if you don’t want to use ModuleScript. Thanks for the help
Yeah, but what are the “…” for? I’ve seen them alot of times and don’t know the meaning.
People use those to represent all the arguments that was carried over by the :Fire() event.
function hi(...)
print(...)
end
hi(22, 22, 22, "hello")
--prints all the arguments like 22 and "hello"
2 Likes
The … is a placeholder for a table of values. When a function has … as an argument it has no limit to the number of arguments. Basically treat it like an array. It’s not the most useful thing for the application Lua is being used for but it exists still.
https://www.lua.org/pil/5.2.html
The three dots (
...) in the parameter list indicate that the function has a variable number of arguments. When this function is called, all its arguments are collected in a single table, which the function accesses as a hidden parameter namedarg. Besides those arguments, theargtable has an extra field,n, with the actual number of arguments collected.
4 Likes
What about Bindable Events? They dont require going to client and back to server again. What are the other uses for Bindable Functions? I heard :Invoke() but I dont know how to use that