AntiFiter
|
  |
| Joined: 14 May 2009 |
| Total Posts: 12290 |
|
|
| 19 Jul 2016 09:32 PM |
I was wondering what the best replication method there is with Filtering and an FPS game. Here's 2 setups:
1. The standard setup - Local script in gun that tells the server to replicate whatever you do on the server, using remote events. Pros: + Client doesn't have to manually replicate everything
2. My custom setup (and one phantom forces uses I think) - Server creates arm welds - From there you send info to the Server, which then does FireAllClients to send a remote event to all clients. clients individually replicate what your client did. Server doesn't see anything, it just acts as a traffic controller. Pros: + Less lag for server (replicating wise), but potential lag dealing with twice as many remote events (to have to FireAllClients). Cons: - replicating can cause lag if it involves cloning etc
Which setup should I use? or a different one |
|
|
| Report Abuse |
|
|
GGGGG14
|
  |
| Joined: 29 Jan 2012 |
| Total Posts: 25344 |
|
|
| 19 Jul 2016 09:36 PM |
It's actually somewhat difficult to have 1 client replicate the events that all of the other clients fired...
I suggest using your "standard setup"
However, I don't have experience with making one of these gun replication systems yet, so I couldn't tell you which way is superior. |
|
|
| Report Abuse |
|
|
AntiFiter
|
  |
| Joined: 14 May 2009 |
| Total Posts: 12290 |
|
|
| 19 Jul 2016 09:37 PM |
| For lower end PC's it's really difficult to to the 2nd setup, but if everyone was playing on a Console it would be easy. But I know Phantom Forces uses the 2nd one |
|
|
| Report Abuse |
|
|
|
| 19 Jul 2016 09:37 PM |
much less exploitable if it's created standard way
Add 13,000 posts |
|
|
| Report Abuse |
|
|
bohdan77
|
  |
| Joined: 10 Aug 2008 |
| Total Posts: 7944 |
|
|
| 19 Jul 2016 09:40 PM |
@Lord_Narwhal
how so
And i've made the 2nd setup before, and it works nicely. |
|
|
| Report Abuse |
|
|
|
| 19 Jul 2016 09:41 PM |
i heard it from someone else
they say with the 2nd system you can teleport all players to yourself and just shoot them all since the server won't have a problem with what you're doing
Add 13,000 posts |
|
|
| Report Abuse |
|
|
AntiFiter
|
  |
| Joined: 14 May 2009 |
| Total Posts: 12290 |
|
|
| 19 Jul 2016 09:44 PM |
| The setups I described wouldn't allow teleporting, unless you have something weird set up for that |
|
|
| Report Abuse |
|
|
|
| 19 Jul 2016 09:45 PM |
there are hacks that can teleport everyone to you even if you have FE
Add 13,000 posts |
|
|
| Report Abuse |
|
|
AntiFiter
|
  |
| Joined: 14 May 2009 |
| Total Posts: 12290 |
|
|
| 19 Jul 2016 09:46 PM |
| With FE on you can still teleport yourself. Just is how client works. |
|
|
| Report Abuse |
|
|
GGGGG14
|
  |
| Joined: 29 Jan 2012 |
| Total Posts: 25344 |
|
|
| 19 Jul 2016 09:51 PM |
@bohdan the "custom" replication system would make it easier to exploit because an exploiter could edit his client-side code to use FireServer rapidly to the server (which in turn uses FireAllClients). He could cause the event to fire to the server like 100 times per second or even cause the game to crash by making other clients replicate hundreds of things locally in a short period of time.
@AntiFiter I would suggest using some sort of querying function in your server to monitor the pace at which the event is firing to the server and run each reqeust individually using thread schedulers. (Of course this is only if you use "custom") |
|
|
| Report Abuse |
|
|
AntiFiter
|
  |
| Joined: 14 May 2009 |
| Total Posts: 12290 |
|
|
| 19 Jul 2016 09:59 PM |
| I wasn't really thinking about the server being forced to crash. My main concern was how much each system lags |
|
|
| Report Abuse |
|
|
AntiFiter
|
  |
| Joined: 14 May 2009 |
| Total Posts: 12290 |
|
| |
|
AntiFiter
|
  |
| Joined: 14 May 2009 |
| Total Posts: 12290 |
|
|
| 20 Jul 2016 07:31 PM |
Bump again
I really need to know which I should use; and how to correctly implement it |
|
|
| Report Abuse |
|
|
|
| 20 Jul 2016 08:29 PM |
second method is more exploitable but has 0 lag
first method is laggy for players other than the client but the client sees smooth bullets
it's preference
Add 13,000 posts |
|
|
| Report Abuse |
|
|
|
| 20 Jul 2016 08:37 PM |
Thing that you're forgetting is that if the client MUST create a bullet client-side, the delay looks terrible and is very noticeable.
Now, this leaves two potential solutions. Create the bullet client-side, fire the server, and have the server create another bullet (which will replicate to all clients), and destroy it on the guy who fired the gun's client.
The second solution is to create it client-side, fire the server, and have the server tell all the other clients to create the bullet. This is the far superior solution.
What we have to remember is that there is never a change in the client-server model, something people get confused when working with FE.
|
|
|
| Report Abuse |
|
|
|
| 20 Jul 2016 08:39 PM |
i use the first method because laggy projectiles in my game is fine since it's 100% PvE so people seeing laggy bullets besides their own is ok
Add 13,000 posts |
|
|
| Report Abuse |
|
|
AntiFiter
|
  |
| Joined: 14 May 2009 |
| Total Posts: 12290 |
|
|
| 02 Aug 2016 11:55 AM |
Sorry for bumping this again, but I still have some input
"second method is more exploitable but has 0 lag" I think you've got it wrong. The second method requires all players to replicate all things gun, that includes performance effecting functions like Cloning. With the first method the server is the only one doing work.
"first method is laggy for players other than the client but the client sees smooth bullets" My guns don't draw the bullets btw
Ultimately I think I'll have to keep with the second method, just because you can have the firing effects happen instantly, like the muzzle flash, and then have the server replicate it to everyone except you. With the standard method, the server would overwrite whatever your doing, so if you did the muzzle flash locally, it would end, and then the server would do it again and you'd still see the muzzle flash. |
|
|
| Report Abuse |
|
|
booing
|
  |
| Joined: 04 May 2009 |
| Total Posts: 6594 |
|
|
| 02 Aug 2016 12:02 PM |
puu.sh/qm98R/73b325bba8.jpg
No method, with or without FE, stops all exploits. |
|
|
| Report Abuse |
|
|
AntiFiter
|
  |
| Joined: 14 May 2009 |
| Total Posts: 12290 |
|
|
| 02 Aug 2016 12:09 PM |
| I'm only focused on lag atm. I can easily patch exploits like that. |
|
|
| Report Abuse |
|
|
|
| 02 Aug 2016 01:12 PM |
"I think you've got it wrong"
""custom" replication system would make it easier to exploit because an exploiter could edit his client-side code to use FireServer rapidly to the server (which in turn uses FireAllClients). He could cause the event to fire to the server like 100 times per second or even cause the game to crash by making other clients replicate hundreds of things locally in a short period of time."
Add 13,000 posts |
|
|
| Report Abuse |
|
|
AntiFiter
|
  |
| Joined: 14 May 2009 |
| Total Posts: 12290 |
|
|
| 02 Aug 2016 01:17 PM |
Oh, that's what you meant.
Still, someone could spam the server with remote event in the original setup anyway, causing extreme lag. |
|
|
| Report Abuse |
|
|
|
| 02 Aug 2016 01:18 PM |
custom rep is much worse with that issue because it's being made locally instead of server-side
Add 13,000 posts |
|
|
| Report Abuse |
|
|
kiansjet
|
  |
| Joined: 16 Nov 2012 |
| Total Posts: 233 |
|
|
| 02 Aug 2016 01:52 PM |
if you teleport (Even in a Non-FE) game, you can have the sever do some simple math with player magnitude and detect a teleport. Apocalypse Rising is a great example. In phantom forces the server compares serverside and clientside position and kicks you (Client out of sync) if they are ridiculously far apart.
|
|
|
| Report Abuse |
|
|