Virtual3D
|
  |
| Joined: 15 Jan 2009 |
| Total Posts: 634 |
|
|
| 31 Aug 2014 09:49 AM |
| How do I permit a local script to edit the workspace without having to call on a script to edit the workspace. I don't mind a local script asking for confirmation from a script to run the local script's content. I hope you guys understand what I'm saying. |
|
|
| Report Abuse |
|
|
|
| 31 Aug 2014 09:51 AM |
Put these things in the Workspace called RemoteFunctions.
In the remote function, write code similar to this:
RemoteFunction.OnServerInvoke = function(player)
end
On the client (localscript) do
Workspace.RemoteFunctionName:InvokeServer();
Notice how the code in the actual remotefunction has the 'player' parameter, but you did send the player to the RF in the client. The RemoteFunction :InvokeServer automatically sends which player invoked the server. |
|
|
| Report Abuse |
|
|
Virtual3D
|
  |
| Joined: 15 Jan 2009 |
| Total Posts: 634 |
|
|
| 31 Aug 2014 10:03 AM |
| I'm not familiar with RemoveFunctions and I'm going to read up on it. Anyway, so can I still permit a localscript to edit the workspace after I invoke the removefunction? I know it works with a script. |
|
|
| Report Abuse |
|
|
|
| 31 Aug 2014 04:24 PM |
| Yes. RemoteFunctions are how you use FilteringEnabled correctly. |
|
|
| Report Abuse |
|
|
|
| 31 Aug 2014 04:28 PM |
| dont use filtering it crashed my system32 and gave me a virus i warned u |
|
|
| Report Abuse |
|
|
|
| 31 Aug 2014 04:31 PM |
| LocalScripts can't edit the Workspace if FilteringEnabled is true? Is this correct? |
|
|
| Report Abuse |
|
|
| |
|
| |
|
|
| 01 Sep 2014 10:48 PM |
OK so you have servers and you have clients Regardless of FilteringEnabled, the server is going to send (i.e. replicate) information to the client - this includes anything created server-side, so parts, other players, etc.
With FilteringEnabled set to false, the client can send any info it wants to the server - this includes Instancing Parts in Workspace, which is then replicated from the server to all the other clients.
However, the client doesn't get to send information to the server if FilteringEnabled is set to true - unless you communicate via RemoteEvents and RemoteFunctions, which can cross the boundary. This is super useful for preventing exploits/hacks.
RemoteFunctions work by: 1) Putting a RemoteFunction somewhere that both the server and client can see them - Adding them into Workspace in Studio works just fine
2) Having a Script (non-local) listen for calls from the client like this: Workspace.RemoteFunction.OnServerInvoke:connect(function(player, msg) print(player.Name .. " says '" .. msg .. "' from their client!") end)
3) Having a LocalScript on the client activate that event like this:
Workspace.RemoteFunction:InvokeServer("Hello world!")
If you wanted it to be ambiguous what you can do, you might be able to do this
Server-side: Workspace.RemoteFunction.OnServerInvoke:connect(function(player, func) func() end)
Client-side: Workspace.RemoteFunction:InvokeServer(function() print("Hello world!") end) |
|
|
| Report Abuse |
|
|
|
| 01 Sep 2014 10:51 PM |
Oops, you have to do
Workspace.RemoteFunction.OnServerInvoke = function() end
, not
Workspace.RemoteFunction.OnServerInvoke:connect(function() end) |
|
|
| Report Abuse |
|
|
| |
|
Krypticon
|
  |
| Joined: 12 Feb 2014 |
| Total Posts: 680 |
|
|
| 02 Sep 2014 03:37 AM |
| Ignore everything BothAngles says. He's a troll. |
|
|
| Report Abuse |
|
|