Unlock ServerReplicator's Filters

Feature Requests Engine Features
#1 
Callback FilterResult ServerReplicator.DeleteFilter(Instance deletingItem) [noyield] [RobloxPlaceSecurity]
Callback FilterResult ServerReplicator.EventFilter(Instance firingItem, string event) [noyield] [RobloxPlaceSecurity]
Callback FilterResult ServerReplicator.NewFilter(Instance newItem, Instance parent) [noyield] [RobloxPlaceSecurity]
Callback FilterResult ServerReplicator.PropertyFilter(Instance changingItem, string member, Variant value) [noyield] [RobloxPlaceSecurity]

Why don’t we get access to these callbacks that act like an advanced FilteringEnabled?
I know they work fine, since they got used in The Witching Hour 2013 and had no problems…

EDIT: Might’ve been 2015, not 2013… I forgot, but I think it’s 2013?

Oh, also this one might be handy for some places:

Function void ServerReplicator:PreventTerrainChanges() [RobloxPlaceSecurity]

Not sure if FilteringEnabled already does that, nor if it’s possible using the methods above.
(I assume without FE, if you want to use those custom ones, you’ll need this method)

2 Likes
#2

I think it’s because it causes a performance impact of about 30%, since c++ code was baking in Lua to get the filtering instructions. Or something like that, can’t exactly remember. But as always, there was some reason not to.

1 Like
#3

If The Witching Hour 2013 can use it and run fine, I’m pretty sure it’s not that bad.

Actually can’t find TWH’s source, it’s on my other laptop.
(Too lazy to transfer it over for now, although it means I didn’t transfer a lot of stuff I forgot about)

EDIT: Nvm it’s also on a disk on another pc, that’s currently turned on, so I can access the disk.
EDIT1: Apparently I didn’t put it on the disk (sigh)
Let this be a lesson: You better organize your stuff in a good way, makes it easier to transfer later on…

#4

Why do you want these?

#5

It allows more precise control than just flicking the FilteringEnabled checkbox.

Example:
Allow client to launch bullets clientside, but ignore all other created instances.
Inside NewFilter you can even do a quick check if the bullet can spawn where it’s spawning.

2 Likes
#6

I heard SFOTH uses the old ServerReplicator filtering API.

Anyway, I’m pretty sure it was disabled because it was far too slow. Imagine networking at 20Hz, and now imagine it being at 3Hz due to Lua.

For something as tight as networking, you really only want to have one of two things: discard everything from the client, or discard nothing from the client.

#7

Expect… FilteringEnabled really doesn’t do that. It discards MOST of everything from the client, but not all of it.

#8

It doesn’t discard physics, and that’s pretty much it.

#9

Am in great need of this.

#10

Why can’t you do it with a remoteevent?

You can accomplish the exact same thing as you could with this filter system, except it requires maybe 10 more lines of lua code.

1 Like
#11

They want a dynamic filter so that they can create a specific “bullet” construct on the client and have it replicate to the server

#12

Yeah, can’t this be done without any sort of special filter?

#13

If you send a signal to the server to create your bullet construct then there will be a delay for the client.

1 Like
#14

I’ve always used FireServer, created one locally immediately afterwards, and then manually loop through other other players and FireClient on them to render the bullet on each client after the server calculates the trajectory. Wouldn’t that work in this case?

#15

I’ve tried this method before. My problem is when the projectile should freely bounce around the arena using ROBLOX’s physics. And since every client handles the client’s own projectile physics, desync becomes an issue (at least for me).

2 Likes
#16

The internal networking isn’t magic though. It’s not like remotes have lag and internal doesn’t.
There is likely a small difference but I would imagine it’s immensely minuscule.

Shooters have methods to reduce this latency. There are plenty of articles on this, or you could ask @AxisAngle as I’m sure PF does this as well. And it works perfectly fine from what I’ve seen.

Here’s an interesting one:
https://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization

#17

Basically, anything that can be turned into an equation, we send as an equation.

Health for example is
clamp(health0,healrate*(tick()-tick0)+health0,maxhealth)
we send health0 and tick0

Look angles is
ang0+(tick-tick0)*angvel
We send ang0 and angvel
tick0 is computed on arrival

That way we don’t have to constantly send the health value, and the look angles can be more correct.

2 Likes
#18

Has there been any plans to unlock the filters?

#19

Its never going to be unlocked.
Do you need help with hiding the effects of latency?