It appears that many users are upset with FilteringEnabled due to latency with client-side input, especially with vehicles and tools. I believe it is the case that most online video games utilize “extrapolation” and “interpolation” to make gameplay experience as smooth as possible. I propose that a compromise be made specifically for client-linked objects like tools and vehicles, such that the user can manipulate server- and client-side Parts independently. This would perhaps give game devs more control over user experience and client-server communication.
This is what filtering enabled is. You create a part (or any other object) on the client and it doesn’t go to the server or any other clients. It stays right there and you can do whatever you want with it.
Well in that case, I may or may not have conceived a potential solution to other game devs’ complaints about latency with FilteringEnabled. Has anyone tried this yet?
Well in that case, I may or may not have conceived a potential solution to other game devs’ complaints about latency with FilteringEnabled. Has anyone tried this yet?[/quote]
I’m doing it in my 100-Player BrickBattle. Currently only the characters do it. I want to do it with the projectiles as well but I seem to have run into something of an obstacle…
Anyway, doing it this way is like hiring a janitor to clean up the incoming data for free. The incoming data for 100 imaginary players is below double that of 50 real players (as tested in trade hangout) and I’m sending data for each character at 5 times per second, which is must faster than I was observing at trade hangout. Even if I can’t get the projectiles to simulate properly it’s going to be far faster than any other 100 player brickbattle, possibly even fast enough to have a somewhat serious game.
The problem with FilteringEnabled is that it forces the developer to deal with all that prediction/interpolation/extrapolation that ‘real’ developers spend a lot of time with, and they have more control than us.
The problem why we have trouble doing those things properly is that roblox only gives us partial control over networking.
Primarily, we cant easily make server-local parts. FilteringEnabled is just a hacky all-or-nothing way to make client stuff local, and it even throws a warning if you use it to do localparts, and the parts stop being local if you turn the feature off.
A ‘Replicates’ checkbox would be more flexible. Using one, EVERY machine could have its own representation of a particular object (lets say a tool). The local player can have a local, smooth version of the tool. The server can have a simplified single block version. The other clients can render the tool if you are close enough.
Lets take another example, a car. The only way to make it smooth to the client, is to have the client car be 100% local. But we also need a server car. We cant have both currently because server overrides client. The client then would tell the server ‘I drove here’ and if it doesnt seem too crazy, the server agrees and directs the car to drive there the same route.
Even better would be selective replication. So only the local player would have a local version of the tool. The local player would tell the server about the tool, and the server makes it own version, and replicates it to all but the local player. Less work.
So:
-A ‘Replicates’ checkbox
-A ‘IgnoreNetworkChanges’ checkbox that allows you to prevent the server from affecting some object locally? (eg the tool you are holding so the server side tool affects all other clients but not you.)?
While it isn’t a good way to do things, since it is unofficial and a bit hacky, you CAN make server-local parts by sticking them in Workspace.CurrentCamera on the server-side. If you have any projects that need server-local parts then that could be a good temporary workaround. An official feature would be much better though.
This doesn’t solve the major problem of when you want to replicate parts to everyone except the client. If I’m reading what you said correctly, that might as well just be the most pointless thing ever hahah.
This doesn’t solve the major problem of when you want to replicate parts to everyone except the client. If I’m reading what you said correctly, that might as well just be the most pointless thing ever hahah.[/quote]
A ‘OverrideReplication’ checkbox or something could be added to make it so that the local version of an object ignores all changes to it from network.
