LamettaJoin Date: 2012-07-07
Post Count: 7975 |
Just as a note as to why I won't be using the Filtering Enabled feature, as I would like to communicate this concept with the admins and community who may wonder "why not", will be detailed below.
As for a while now, roblox has been updating its platform to give the newer users a better experience and to keep them engaged, thus making aesthetic changes, development changes for experience developers, and safety updates.
However, with with updates comes a price, sometimes it could be a large price that denies another community entirely, and sometimes it comes with the price on the platform itself, however slight.
One of the issues that came with the aesthetic chance to keep a character animation smooth, was the issues with latency (or how accurate the character model viewed from another individual, is compared to the actual individual's perspective).
Now, the issues that I have with Filtering Enabled aren't really issues, but personal preferences. Sure, exploiting is super limited, but it isn't impossible with Filtering Enabled. Filtering Enabled only protects the server and the clients from being affected by one individual, but the individual exploiting can still ruin things themselves, so it doesn't have much of an impact on gameplay standards besides perhaps preventing someone from stealing your place. Even still, there are ways to obtain places ways beyond my knowledge even with Filtering Enabled activated (as proven when a random individual managed to obtain TGI's weapons back months ago -- however this information could be outdated).
None of that is the issue I personally have with Filtering Enabled, however. Filtering Enabled requires the client to communicate with the server using game functions only, to minimize exploiting, great. However, this means that the client and all local scripts, must first communicate with the server before activating, meaning a few small issues come up (at least on my end).
The only issue regards my attempt to fix character latency issues. When using a local script, the local script -- without filtering enabled -- views and acts by the client's perspective of things, thus assuring a more accurate response than a server script or a local script that first must be read by the server. What this means is that, if I were to use a local script to re-create a humanoid and replace the roblox humanoid with a new one created by the local script, then I could drastically improve the latency issues that this platform has. I'm not saying this out of my hat either, experimentation and play testing has already been done with a replica "ghost humanoid" that I've created in order to keep the characters more accurate, but this only works if the local script runs off of the client's response time, rather than the server.
Why this won't work with Filtering Enabled? Filtering Enabled forces all scripts to communicate with the server, and the way that characters normally function is based off client and server perspective - for example:
Your character begins walking down a path, you are nearly at the end on your screen. However, where you move must first communicate with the server, which dictates how others view you. If you are nearly at the end and the server communicated too slowly, then others will see you much further from the end than you see yourself, and due to "recent" roblox updates, all calculations for damage are done on the server's version of the character, rather than the client version, thus making things less accurate -- which arguable could be VERY important when it comes to combat on roblox... however I don't know how important that is to them.
The current delay the server has to communicate with the client is not entirely clear and I can not give an exact result, however I will estimate that the delay is about half a second off from where it should be, which is a huge difference.
I just wanted to communicate this with the community and share why I will NOT be using Filtering Enabled at some of my places, but this is only because of personal reasons, but it is always good to share information like this, I believe. |