|
| 09 Mar 2017 10:19 PM |
So, I'm trying to change my weapon system in order to work with FilteringEnabled, and I figured since I'm taking the time to switch my functions to RemoteEvents, I might as well get it right the first time.
My guns currently rely on raycast. Currently, the Sever is only responsible for drawing the rays and dealing damage to players/NPCs. Should I also make the server the one to physically call the FindPartOnRay method? Should I try to import as many functions I can onto the server?
Thanks.
|
|
|
| Report Abuse |
|
|
|
| 09 Mar 2017 10:23 PM |
*By " the Sever is only responsible for drawing the rays ", I mean creating the visualization of the ray.
|
|
|
| Report Abuse |
|
|
|
| 09 Mar 2017 10:30 PM |
| make the server do only the important work, leave things like animation and casting the ray to the client for more immediate results |
|
|
| Report Abuse |
|
|
|
| 09 Mar 2017 10:46 PM |
yeah, while that works, it's a noticeable decrease in speed when handled by the client as opposed to the server.
while slight, there is a slight delay for the server drawing a ray, whereas without FE and using the client - there's almost no delay. i guess there's no way to work around this but to optimize, yeah?
|
|
|
| Report Abuse |
|
|
|
| 09 Mar 2017 10:54 PM |
yeahhh, because having the ray come out slightly offset from the barrel is a fairly jarring visual effect.
|
|
|
| Report Abuse |
|
|
OzzyFin
|
  |
| Joined: 07 Jun 2011 |
| Total Posts: 3600 |
|
|
| 09 Mar 2017 11:16 PM |
The server should only be casting the ray and handling collisions. The clients should be the ones, as already mentioned, create the part to visualize the ray. You should not cast the ray on the client (because it's unnecessary) and only draw the part.
There is no way to get around the latency but the best way to minimize its effects is:
- The first client tells server that I shot and the direction - Create the bullet on the first client - Server tells other clients that the first client shot - Other clients create the bullet - Server casts ray and handles collisions
The first client is the only one who will notice the latency hence why you handle them very first.
It is a security issue to let the client decide the bullet's direction but with ROBLOX it pretty much has to go that way. Getting the direction from the character's head isn't really an option as this most likely happens: twitter.com/OzzyOnRBX/status/821767115099217920 Though, first person games may be a bit different. |
|
|
| Report Abuse |
|
|
|
| 09 Mar 2017 11:29 PM |
Your insight was really good - so thanks for that, my only issue is that visualizing the ray on the client would only result in the client seeing their own ray - which I guess is good for performance sake but yeah.
Unless I'm fundamentally misunderstanding you.
|
|
|
| Report Abuse |
|
|
|
| 09 Mar 2017 11:33 PM |
Actually, rereading what you said, I can kinda understand what you're saying, though I'm not sure how to handle it.
- The first client tells server that I shot and the direction Easy enough, pass the data through a remote event
- Create the bullet on the first client Again, easy enough, bullet function defined in the client.
It's the following two which I'm unsure about the approach, I guess:
- Server tells other clients that the first client shot - Other clients create the bullet
Would the server get the data from a FireServer method, and then pass that to the clients, where they would draw the rays? Just making sure I understand you.
|
|
|
| Report Abuse |
|
|
chimmihc
|
  |
| Joined: 01 Sep 2014 |
| Total Posts: 17143 |
|
|
| 09 Mar 2017 11:33 PM |
Yeah, that is how multiplayer games generally work.
You think people are seeing the exact same thing in AAA online shooter games? Nope. |
|
|
| Report Abuse |
|
|
|
| 09 Mar 2017 11:35 PM |
I figured, it's just the first time I've dealt with the approach on Roblox before.
Really appreciate the insight guys.
|
|
|
| Report Abuse |
|
|
|
| 10 Mar 2017 12:34 AM |
So, just to addon to this thread (which has helped me a lot):
Currently, I have a LocalScript that uses stravant's screenspace module to make it possible for the player character to simulate looking up and down with their arms. Using the information from this thread....would I accomplish it this way?
Client sends information about neck and shoulder connections to the server in a while loop
Server updates the orientation by adjusting the Torso connections.
|
|
|
| Report Abuse |
|
|
OzzyFin
|
  |
| Joined: 07 Jun 2011 |
| Total Posts: 3600 |
|
|
| 10 Mar 2017 02:04 AM |
| Yeah, just find the optimal time to yield in between sending the info to get the best performance as well as user experience. |
|
|
| Report Abuse |
|
|
Guest1751
|
  |
| Joined: 20 Sep 2009 |
| Total Posts: 12 |
|
|
| 10 Mar 2017 02:14 AM |
| Do Not Use FE As It Will Lag You're Game :o |
|
|
| Report Abuse |
|
|
galio13
|
  |
| Joined: 20 Jul 2011 |
| Total Posts: 842 |
|
|
| 10 Mar 2017 05:28 AM |
^ "It Will Lag You're Game" = It will lag you are game
1, You make/write the first letter in each word capitalized 2, You can't use the you're / your correctly. 3, I am mad, because you have bad grammar. Don't
Instead write " Enabling FE will lag your game,". You don't have to write more than that, people do understand. |
|
|
| Report Abuse |
|
|
VilgO
|
  |
| Joined: 15 Feb 2011 |
| Total Posts: 518 |
|
|
| 10 Mar 2017 05:37 AM |
| If you want both security and responsive controls, you'll have to implement either client side prediction or some king of anti-cheat. |
|
|
| Report Abuse |
|
|
|
| 10 Mar 2017 06:06 AM |
| Tell the client to cast the ray and pass through the remoteevent, the part and/or the position returned from the ray. You can then deal damage from there. |
|
|
| Report Abuse |
|
|
OzzyFin
|
  |
| Joined: 07 Jun 2011 |
| Total Posts: 3600 |
|
|
| 10 Mar 2017 06:08 AM |
"pass through the remoteevent, the part and/or the position returned from the ray"
That'd be a huge security issue. |
|
|
| Report Abuse |
|
|
|
| 10 Mar 2017 06:11 AM |
| there are very few people who are able to change the values passed through a RemoteEvent. For him, it will be fine and it pays off for not having to deal with lag. |
|
|
| Report Abuse |
|
|
OzzyFin
|
  |
| Joined: 07 Jun 2011 |
| Total Posts: 3600 |
|
|
| 10 Mar 2017 06:21 AM |
An exploiter could easily fire the remoteevent with his own arguments allowing him to damage anyone.
Raycasting wouldn't be a thing if it was inefficient or 'laggy'. Of course it takes (heavyish) calculations to cast the ray but it doesn't generate any noticeable performance issues until done wrong. It is totally fine to cast the ray on the server for each bullet, even for a server with a lot of players. |
|
|
| Report Abuse |
|
|
|
| 10 Mar 2017 06:25 AM |
"server with a lot of players"
thats the main problem
|
|
|
| Report Abuse |
|
|
|
| 10 Mar 2017 06:26 AM |
| again correct me if im wrong but this cant be done with nearly all common exploits, only someone that is able to decompile the lua code and further more using server checks should be fine in this case. There arent "many" that good of exploiters on roblox. Im pretty sure exploiters would be the least of his worries aswell with FE enabled |
|
|
| Report Abuse |
|
|
OzzyFin
|
  |
| Joined: 07 Jun 2011 |
| Total Posts: 3600 |
|
|
| 10 Mar 2017 06:31 AM |
It can be done with every exploit that is able to execute lua code but also with other exploits that can pass data through remotes.
It is impossible to stop exploiting as there will always be new methods to exploit something. That is why security should always be taken into account on all platforms. |
|
|
| Report Abuse |
|
|
|
| 10 Mar 2017 06:35 AM |
" able to execute lua code"
therefore you use checks on the server that the remoteevent was actually fired by the game. unless they are able to decompile the lua code, it they would just be firing a remoteevent that does nothing since it doesnt pass the correct argument. |
|
|
| Report Abuse |
|
|
|
| 10 Mar 2017 06:36 AM |
| by checks i mean like strings such as a hash, or a simple "firethegun" string will do |
|
|
| Report Abuse |
|
|
OzzyFin
|
  |
| Joined: 07 Jun 2011 |
| Total Posts: 3600 |
|
|
| 10 Mar 2017 06:40 AM |
They'd go and guess the arguments, someone will eventually get it. Possibly even by somehow listening to the values being passed with FireServer.
Why leave such a big hole in the security (was it abused or not) when there is a really simple fix to it? |
|
|
| Report Abuse |
|
|