mathchamp
|
  |
| Joined: 22 Oct 2007 |
| Total Posts: 320 |
|
|
| 10 Jul 2014 06:00 PM |
Humanoid.TargetPoint does not replicate from client to server, which basically breaks every gun and rocket launcher in existence. Even the Quadshooter (released recently) breaks.
Technically I can rescript a gun to work with FilteringEnabled rather easily (local script receives mouse click and passes TargetPoint as an argument to RemoteEvent), so that's not really the issue (but doing this with 20 guns would be rather tedious).
The real issue is WHY FilteringEnabled stops TargetPoint from replicating. There are a whole load of things that replicate to the server even with FilteringEnabled turned on that permit exploitation much more so than TargetPoint.
Take for example the position of a character. At the moment, the client determines a character's position and this is replicated to the server regardless of FilteringEnabled. Obviously this is to make characters feel less laggy, but at the same time can lead to exploitation. A client can assign an arbitrary CFrame to their Torso in order to teleport and it will replicate. A client can change the WalkSpeed, and while the WalkSpeed itself does not replicate, it is the CLIENTSIDE WalkSpeed that determines how fast the character moves and thus that is also potentially exploitable.
On the other hand, what can an exploiter accomplish if they were to hack Humanoid.TargetPoint? At most they would be able to set the target point somewhere not in their line of sight, which makes no difference if the tool only uses the direction and not the point itself. Even with FilteringEnabled, an exploiter could still potentially set an arbitrary TargetPoint and any tools that pass this TargetPoint to the server would be "affected" despite FilteringEnabled. The solution to TargetPoint exploitation would be to use raycasting to check if the point is actually in line of sight (only would work in first person as otherwise the Camera gets involved), and this is independent of FilteringEnabled.
Thus, I feel that FilteringEnabled should not be filtering Humanoid.TargetPoint as there is little security risk of allowing this property to be replicated (only the client's own Humanoid, though, attempted changes by a client to other humanoids should still be filtered), while filtering it forces script edits on many tools and gear. |
|
|
| Report Abuse |
|
|
|
| 10 Jul 2014 06:52 PM |
| I agree with this but sadly roblox most likely does not care. |
|
|
| Report Abuse |
|
|
|
| 10 Jul 2014 07:19 PM |
| mathchamp you should directly contact roblox about this, maybe through RBXDev or info@roblox.com |
|
|
| Report Abuse |
|
|
|
| 10 Jul 2014 08:50 PM |
| What is this, someone making a serious post? |
|
|
| Report Abuse |
|
|
|
| 11 Jul 2014 03:45 AM |
U stupid?
FilteringEnabled broke pretty much everything
It's definitely not for people who want to use a bunch of free models and gear....
and it's optional so don't bug ROBLOX to fix like every single gear |
|
|
| Report Abuse |
|
|
|
| 11 Jul 2014 03:55 AM |
| onetruegodtheholycow, do you have any idea who you're speaking to? seriously insulting mathchamp? this guy is one of the most famed 2008 developers, he made that game plane wars. hes good. |
|
|
| Report Abuse |
|
|
|
| 11 Jul 2014 04:00 AM |
| Irrelevant, FilteringEnabled clearly wasn't made for those old games and it'd take a huge amount of effort to get them working, so just don't bother |
|
|
| Report Abuse |
|
|
|
| 11 Jul 2014 07:17 AM |
| zzz u are no champing of math that is me ! jaja اصهعنضاضهعصا |
|
|
| Report Abuse |
|
|
|
| 11 Jul 2014 07:42 AM |
"A client can assign an arbitrary CFrame to their Torso in order to teleport and it will replicate."
cOLD mOLD. Totally didn't already do this. |
|
|
| Report Abuse |
|
|
mathchamp
|
  |
| Joined: 22 Oct 2007 |
| Total Posts: 320 |
|
|
| 11 Jul 2014 10:43 AM |
@OneTrueGodTheHolyCow this has nothing to do with old games, and I can fairly easily go ahead and work around Humanoid.TargetPoint not being replicated.
The reason for my proposal is that basically every use case of Humanoid.TargetPoint will directly pass its value to a server script, whether directly (FilteringEnabled = false) or through RemoteEvent (FilteringEnabled = true). Thus there isn't any real reason to filter it as all filtering does is break gear and legacy tools for no benefit.
It's kind of like VehicleSeat.Throttle and VehicleSeat.Steer, except that those two properties are not filtered. |
|
|
| Report Abuse |
|
|
HUBHUB13
|
  |
| Joined: 15 Oct 2010 |
| Total Posts: 36 |
|
|
| 11 Jul 2014 10:45 AM |
"for no benefit."
Clearly it has nooo benefit at all. |
|
|
| Report Abuse |
|
|
mathchamp
|
  |
| Joined: 22 Oct 2007 |
| Total Posts: 320 |
|
|
| 11 Jul 2014 10:59 AM |
There is "no benefit" in filtering the property if the client changing the property is the client of the player to whose character the Humanoid belongs to.
That being said, I have written a once-per-place workaround script. |
|
|
| Report Abuse |
|
|
|
| 11 Jul 2014 12:32 PM |
My point was more that ROBLOX clearly broke many things and so it'd be hard to fix some of these. For example this Humanoid.TargetPoint...not used very often any more.
They also made Scripts no longer act local inside of Hopperbins, which broke so much old crap it's unbelievable that they actually haven't reverted it yet
So why should it be different for TargetPoint? This isn't really a filtering problem, it's a humanoid problem, I don't know why they would put TargetPoint as a property of Humanoid but, yeah
It'd be nice if they fixed it, but I doubt they will. They tend not to care about old stuff that much. |
|
|
| Report Abuse |
|
|
j1my3p1x
|
  |
| Joined: 16 Jan 2010 |
| Total Posts: 978 |
|
|
| 11 Jul 2014 02:32 PM |
"It'd be nice if they fixed it, but I doubt they will. They tend not to care about old stuff that much."
It'd be nice if they fixed it, but I doubt they will. They tend not to care at about anything that much.
FTFY.
|
|
|
| Report Abuse |
|
|
| |
|
|
| 11 Jul 2014 06:14 PM |
| You guys need to have a bit more respect. They've been doing really well lately. Yes, they used to be bad about it, but they've done a really good job this year. |
|
|
| Report Abuse |
|
|
| |
|
|
| 12 Jul 2014 09:52 AM |
"really good"
Yeah-no, they've been doing extremely well in my opinion.
Most every update this year has had at least some form of good, and it's still going, we're getting mouse updates and pathfinding soon, not to mention that we will hopefully have our new materials online soon too! (Apple: work faster) |
|
|
| Report Abuse |
|
|
| |
|