The Basics of adjusting your game to the removal of Experimental Mode with FilteringEnabled

[MetaProx]

After the latest update…

After the latest update, you’re probably wondering, what is this FilteringEnabled thing? What does it have to do with the removal of Experimental mode? This post, though a little old, will kind of set you on the right path for now. I hope to make updates to this post in the future when I’m not as busy.

First things first though, before you get reading this, Experimental mode was a mode that did not require your game to be FilteringEnabled, now with the removal of it, it goes without saying that your game must be FilteringEnabled. As such if you aren’t a programmer, this might not at all make sense to you, in fact I suggest to you to find a programmer who knows how to do this, or share this post with programmers who don’t. If you are, welcome! Sit back, relax grab something to drink, and hopefully try to understand everything below.

One last thing, this tutorial isn’t final and I hope to eventually release a video explaining everything in detail when I find the time to actually create and upload something like that. My internet isn’t all to great so here’s hoping for the future.

Introduction

So, I noticed many people on the Devforum(and elsewhere) have issues with FilteringEnabled and I’d like to offer some advice on how to use it to the best of your ability. There are often times people look at the Wiki for this kinda stuff, but as I’ve already discovered with metatables, sometimes the wiki doesn’t quite explain things as they are. And sometimes things can appear to be much more confusing than they actually are!

How does it work?

So how does FilteringEnabled work? Well, this is rather simple, the way your game works is the Server and the Client, without FilteringEnabled, both can interact with eachother just fine, things replicate from Client to Server. This changes when you apply FilteringEnabled; while almost everything on the server is replicated back to the client, everything on the client is now not replicated back to the server. This is namely what confuses many who have just started learning FilteringEnabled, they do things through LocalScripts expecting it to replicate back to the server as it did before FilteringEnabled. This is where a majority of the problem lies.

What are the benefits of using FilteringEnabled?

There are actually a ton of benefits to using FilteringEnabled, not only in just the security department. This can work for many things, like the following:

1. Security: This should be fairly obvious, but now that the client can only interact with itself, most exploits will be stopped, and often times will have to use what you’ve already programmed in.
2. Your choice in replication: Seeing that now everything done on the client isn’t replicated to the server, this allows for more freedom in what you want users to experience locally. For example, you can change the time of day on the client, and not have it affect the server, there are a few exceptions to this, but nothing important to note.
3. Optimization: When done correctly, using FilteringEnabled can actually improve the performance of both the server and the client, or either or. Seeing as you can control what is replicated on the client and on the server, you can take stress off one or the other, either by sending it to the client, sending it to the server to then send to all the other clients, or just simply having the server handle it. The improvement in performance that you can gain from this is one of the biggest reasons why I would suggest you use FilteringEnabled. You can also allow for the user to choose what they want replicated, to improve their own experience(Sorta like settings in games you see off of roblox).

And that’s just to list a few uses of FilteringEnabled that I can think of off the top of my head.

How do I use this?

So you’ve decided to truly figure out the deep-hidden secrets of using FilteringEnabled, I knew you could do it!(If you have already, good on you!). So there are some things you should probably know,I lied, there is actually a few really good ways for the Client to communicate with the Server, and those are…

[Insert drumroll here]

Remotes!

RemoteEvents and RemoteFunctions, these are your best friends when it comes to FilteringEnabled, they allow you to pass information from the client to the server, or vice versa. These are almost mandatory in a FilteringEnabled environment, as they allow you to fire functions either from client or from server. When connection(for the most part) is cut off between the two, this is your best bet to still have the client interact with the server. So then, let’s get down to how you use it.

RemoteEvents:
So let’s say you want to fire off a function but have no intention of getting the result back(unless you want to fire another RemoteEvent back at the client). Then you’d use RemoteEvents, these allow you to fire off a physical RemoteEvent class with some parameters.

Some Examples:

--Your non-Local Script.
RE = script.RemoteEvent
RE.OnServerEvent:connect(function(plr,arg1,arg2) --When your localscript fires the RemoteEvent,
--Also the Player is always the first Argument.
print(plr.." says: "..arg1.." "..arg2)
end)

--Your localScript.
RE = game.Workspace.Script.RemoteEvent
RE:FireServer("Hello","world") -- Wow that was really simple, wasn't it?

In the end these should return something like, “Player1 says: Hello World” on the server, neat isn’t it?

RemoteFunctions:
Okay, now before I even say a word, do not use this a lot, because this is a callback function, something that yields until it can return, I would only use this if you find that you really need to return something from the server and don’t want to use two RemoteEvents.

--Your non-Local script
script.RemoteFunction.OnServerInvoke = function(plr,arg1,arg2)
print(plr.." says: "..arg1.." "..arg2)
return "Successfully printed to server."
end

--Your LocalScript
ret = game.Workspace.Script.RemoteFunction:InvokeServer("Hello","world")
print(ret)

Now you should have printed something like, “Player1 says: Hello world” to the server, but you also printed, “Successfully printed to server.” on the client. This is namely what RemoteFunctions are used for.

Also, these work both ways!
You can use either of these both ways! You can fire specific clients from the server as well, in this case, we will use the FireClient function, but FireAllClients works too if you’re trying to fire the RemoteEvent for all Clients.

--Your local script!
--We will be using a RemoteEvent
--Because we're trying to set up a function that's listening for when the client is called, we use OnClientEvent
game.Workspace.Script.RemoteEvent.OnClientEvent:connect(function(arg1,arg2) 
print("The Server says: "..arg1.." "..arg2)
end)

--Your non-local script!
script.RemoteEvent:FireClient(game.Players.Player1,"Hello",game.Players.Player1.Name)

Conclusion

So, that’s all the essentials to using FilteringEnabled as well as how it works. If you struggle with this, or know of ways to improve this, please comment down below!

[iamnoamesa]

I am a little confused.

Okay, now before I even say a word, do not use this a lot, because this fires like a regular function, this means that it can run no more than once at a time

Could you clarify this please? The way it is worded, it seems to me if I invoke a remote function, I can’t invoke it again until the function has finished. I know that is not true so I ran a test:

3 local scripts in StarterGui:

game.ReplicatedStorage.RemoteFunction:InvokeServer()

Script in ServerScriptStorage:

function game.ReplicatedStorage.RemoteFunction.OnServerInvoke(Player)
	print("Recieved")
	wait(5)
	print("Done")
end

Output:

Recieved (x3)
Done (x3)

Did you mean that the script would wait for the function to finish before continuing the thread, or am I missing something?

[MetaProx]

Oh my mistake! Yeah, it doesn’t cut the other function off, rather instead it sort of yields until it can return the value, thus causing a bit of lag! I will make the edit now.

[buildthomas]

EDIT: OP has edited thread

FilteringEnabled is not Experimental Mode. In fact, the two are mutually exclusive.

When your game is in Experimental Mode, FE will be off, while in non-Experimental mode, FE will be on. This should be rectified in title/OP.

[maplestick]

This made me think the post was going to be from someone who had no clue what FE is when i first read it ><

[BULK_BROGAN]

"FilteringEnabled(also known as Experimental mode)

Decent tutorial actually apart from the few mistakes. Everything else was factually correct and fairly well explained. I’d include links to a few key wiki articles and also explain automatic replication with characters, network ownership, or at least provide links to those too.

[unix_system]

Fun fact:

Firing a server event which then fires a client event with the returned data is faster than using a RemoteFunction.

[Kiansjet]

w-How…

[unix_system]

Poorly written backend stuff for RemoteFunctions, I guess.

[MetaProx]

I already mentioned that actually, lmao.

[MetaProx]

@buildthomas

FilteringEnabled is not Experimental Mode.

uh… Alright.

@DeepBlueNoSpace

Decent tutorial actually apart from the few mistakes. Everything else was factually correct and fairly well explained.

Well, I know how it all works, I’m just not really good at explaining it. However I noticed many people were still struggling so I wanted to provide a bit of help.

[Stelrex]

Thank you. This has helped me.

[Stelrex]

@buildthomas

FilteringEnabled is not Experimental Mode

This post ( The Future of Filtering Enabled: Experimental Mode ) says:

@JParty

Filtering Enabled games will simply be called “games.”

@JParty

Games that do not have Filtering Enabled, on the other hand, will be called “Experimental Mode games.”

Doesn’t this mean that FE and “Non-Experimental Mode” are the same, and Non-FE and Experimental Games are the same?

[SummerEquinox]

Here’s a simple guide to transferring what you should call games:

FilteringEnabled is ticked = game
FilteringEnabled not ticked = experimental

I believe the intent here was to start moving more developers along the path of using FilteringEnabled in their games as Roblox grows as a platform.

[Stelrex]

Basically what I said. thanks for clarifying this for me!

[SummerEquinox]

Sure, but this is an open thread, hoping that rule might clarify it easily for someone who is just skimming the replies.

[buildthomas]

For the record, OP has edited their thread since my post. The thread claimed that FE = experimental beforehand.

[Stelrex]

Fair enough.

[iamnoamesa]

Alright, that makes more sense.
I like the tutorial overall, as it will help new developers, but I think you can change a few things to make this tutorial more useful.

• Reword the explanation for remote functions

  The way it is currently put, it sounds like remove functions are inferior to remote events. However, on a basic level, they are simply different.
  You will normally use a remote function when you want to return a value, or when you wish for the code to wait until the function has completed.
  The fact that a remote function yields until return is a good thing, since that’s the reason why you would use a remote function over a remote event.

• Talk about what should be on the server vs client / when to use remotes

  When people just start using FE, they usually don’t understand the power the client should have. They simply try remaking everything with remotes, so that it bypasses filtering enabled. This causes games to have remote events that work like this:
  game.ReplicatedStorage.DealDamage:FireServer(Player Name, Damage)
  They do not realize that this defeats the purpose of FE, which is why I think you should include a little section talking about when to use remotes and what the client should tell the server.

• Add an example

  For most people, they are told to use remotes, but they don’t understand how to implement them. I think you should take a basic problem, such as a shop button that takes 10 tix and gives you one robux, and make it with FilteringEnabled, step by step.

[Polymorphic]

RemoteFunctions should be avoided like the plague when it comes to having the server request anything from the client. It’s a cute idea, but people should not be calling InvokeClient at all for anything practical because any client can just indefinitely yield a thread by overriding a real client’s callback and cause havoc to even an otherwise well made game.