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

[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

[buildthomas]

I would probably refrain from doing so until it is updated, since FilteringEnabled is no longer a thing they need to take into account anymore (there’s no experimental mode anymore, everything is effectively FilteringEnabled), so it might unnecessarily confuse them as it is right now.

[LuckyTux]

Thanks Build. You’re the man.

[STR4T]

Thank you for this Thomas! Will share this with a few friends struggling as I was.

[MetaProx]

Alright, I made some slight updates, the post is still relatively old, but I do hope to upload a video soon, sorry for the inactivity on this post.

[iRexBot]

Lots of my friends sadly are too “lazy” or too “ignorant” to learn Remote Events and resort to using putting a server script and using script.parent.parent.parent.parent.etc… So I pretty much use your post to teach them remote events. The non-ignorant ones learned with some help from me but the ignorant ones are still using the bad method.

[12mrcool (NorthernCanuck)]

ok but what if its just a building showcase etc…

[MetaProx]

Then you don’t need to change anything, it’s only a script thing.