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

[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.

[MetaProx]

Yes, I already said that it should be well avoided.

[colbert2677 (ImagineerColbert)]

Decent tutorial. It, of course, does not cover all of what is needed to know about FilteringEnabled/non-experimental mode, but it hits the primitives just as it should. Nicely done

Some things that haven’t been mentioned (or have been, but I just never noticed):

• Environment trust. Remember that you can’t trust the client. The client should be handling things only they can see and asking the server for permission to run global effects (i.e. client asks to change to x team, server checks if they are allowed to be on it and changes their team if they pass permissions).
• Be wary of where you put your variables. It makes all the difference where you put just one variable. You don’t want to have a remote where the client requests to damage someone and supplies, say, damage values - an exploiter could pass a higher-than-expected damage count.
• Determine which remote you require. Remote events act like spawn() or separate threads in the sense that they don’t yield the script. Remote functions are for when you wish to have callback functions and want the script to yield until the function returns a result. Always check over your code and make sure you have that return in there.
• Organization is your friend. You ideally want to keep all remotes in folders within ReplicatedStorage unless there is a reason you need it elsewhere.

[MetaProx]

yep, I should change the title to tips.

[Beartikal]

Another inportant feature I would add on: don’t trust the client with anything important such as data stats or important values.

[Zeumus]

I think you should add something from what Echo has said. It is very important when it comes to Remotes.

@EchoReaper

You should set up your remote events in a way that they can be verified. For instance, instead of having a RemoteEvent “GiveMoney(amount)”, you’d have “RequestSellItem(item)”. The server would be able to verify that you had the item in your inventory and determine whether the request is legitimate or not.

[Simply_Benny (Simply)]

Filtering Enabled, is the best and only way to program games. I completely agree with the ideas expressed in this post!

[LuckyTux]

I’m going to share this with newer devs! Thanks for the info