Jump to content
Hexerin

Why is player movement still client-side?

Recommended Posts

Specifically talking about movement on foot, not while in vehicles. There is nothing more frustrating than trying to shoot someone, only for them to teleport around because the server is simply accepting their obviously corrupted movement data. Whether it be them having a bad connection to the server, intentional lagswitching, or just outright speedhacking, the problem is the same.

  • Like 2

Share this post


Link to post
Share on other sites

what i find the most frustrating is when people just out of high speed cars and they are suddenly well back from the position they should be at.. Seems like an obvious exploit.

  • Thanks 1

Share this post


Link to post
Share on other sites

It is must related to low tick rate, anyone did reseach what is actual responce???

Share this post


Link to post
Share on other sites

i don't know enough facts about this topic to discuss about it. anything not from LO would be speculation.

Share this post


Link to post
Share on other sites

You know how cars currently work?
Protip: theyre server sided.

Do you really want server sided player movement?
Really?
 

Edited by UubeNubeh DaWog
  • Like 5
  • Thanks 2

Share this post


Link to post
Share on other sites

Have  you seen how bad the servers perform already? If everything was server sided rather than client sided, we would be in such a bad situation now...

BTW I remember some exploit with getting your character stuck under a car so that the server still shows you there while on the client you are running around and shooting.

  • Like 1

Share this post


Link to post
Share on other sites

Yeah. I sure would love to have a half a second delay before seeing my character move, that sounds really fun.

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, Todesklinge said:

Exit vehicle on full speed, without taking damage... thats a bug.

Imagine if you took damage proportional to the speed you were going when you exit a vehicle over a certain speed.

It could interact with Valzipram tablets letting a player ignore the damage so then it would have something more to offer over other blue mods.
  • Like 4

Share this post


Link to post
Share on other sites
43 minutes ago, Karyon said:
Imagine if you took damage proportional to the speed you were going when you exit a vehicle over a certain speed.

It could interact with Valzipram tablets letting a player ignore the damage so then it would have something more to offer over other blue mods.
That is a good suggestion. I know the quality of gameplay in PUBG (? - Some battle royale game) was improved when a change like this was implemented. 

Share this post


Link to post
Share on other sites

bro the servers are already sh*t...cars are already serverside and its not always that great...leave the playermovement alone .-.

Share this post


Link to post
Share on other sites

as soon as we get 0ms i’m sure client side movement will be deleted 

  • Like 1

Share this post


Link to post
Share on other sites
15 minutes ago, BXNNXD said:

as soon as we get 0ms i’m sure client side movement will be deleted 

i get 600ms from the middle east. does that mean we can do this already

i wanna see my character moving with 6 second delays. 😄

Share this post


Link to post
Share on other sites

What I like the most is being hit by a car not next to me, getting shot over my hat and checking to see if my bullet went pass the player ^.^

Share this post


Link to post
Share on other sites
33 minutes ago, Obvious Lesbian said:
i get 600ms from the middle east. does that mean we can do this already

i wanna see my character moving with 6 second delays. 😄
shouldnt you be playing on citadel then?

Share this post


Link to post
Share on other sites

totaly why most ppl quit this game, its fighting lag and bad serverprediction instead of a game, rip apb 

Share this post


Link to post
Share on other sites

Yeah, great Idea, let's make the game unplayable for anyone with more than 60ms
I'm totally in for removing 65% of the current playerbase

Edited by Pachi3080

Share this post


Link to post
Share on other sites

Everyone here is wrong. Movement is not clientside, it has never been clientside, it is server authoritative and clientside predicted.

The client is allowed to move on their own screen only before the server receives information that they have moved, their movement data is not "corrupt", warping occurs for 2 reasons (maybe 3 because it's APB and their reliable stream is fucked from what I've understood from Matt's post about why the lag is happening, as apparently commands can be received and processed out of order which should never happen with a reliable stream), the first being packet loss, and the second occurring when a client lags. Packet loss occurs when one end has an unstable connection and packets are failing to reach their destination, and packet jitter which occurs when packets are arriving at their destination late, when they arrive late, the server has to process all of the commands it received late in a single server frame, when a client lags or stops sending packets for a period of time, they'll continue creating movement commands until they either disconnect or stop lagging, when they're lagging, all of the commands are batched up so that they can be sent next client update, when the client stops lagging, the client sends all of the batched movements to the server in a single update, where the server processes them from front to back in the next server frame, when all of these commands are processed, the server accepts the various movements the client has made since they last sent an update and voila, they move, albeit not very smoothly.

And would you believe this? Speedhacking works the same way, when you speedhack, you create multiple commands per server tick, they're all batched up and sent to the server at once, the server processes them from front to back, and you move...just a lot faster than expected.

Movement is not clientside, what you see is nothing more than a side effect of proper input prediction, which you should be thankful for. Most games to this day are still utilizing networking code from the Quake engine, and for good reason, it can't be done much better than it already has been.

What's the fix? Only allow the server to process a certain amount of user commands per server frame, this is what the Source Engine does and it works very well, just remember that you have to account for high FPS or you'll get clients with good PCs stuttering all over on their screen.

  • Like 3
  • Thanks 3

Share this post


Link to post
Share on other sites
14 hours ago, Seedy said:

what i find the most frustrating is when people just out of high speed cars and they are suddenly well back from the position they should be at.. Seems like an obvious exploit.

What I find the most frustrating is whenever people link their Twitch channel in bright red

Share this post


Link to post
Share on other sites

Would you rather have the illusion of responsiveness (and sometimes get teleported when syncing with the server)
or experience the truth of lag affecting every of your inputs?

Edited by Talla

Share this post


Link to post
Share on other sites

Hello everyone,

I have removed few posts unrelated to the topic of this thread. Please stick to a certain line of discussion and discuss respecfully.

Ritual

Share this post


Link to post
Share on other sites
12 hours ago, Similarities said:

Everyone here is wrong. Movement is not clientside, it has never been clientside, it is server authoritative and clientside predicted.

The client is allowed to move on their own screen only before the server receives information that they have moved, their movement data is not "corrupt", warping occurs for 2 reasons (maybe 3 because it's APB and their reliable stream is fucked from what I've understood from Matt's post about why the lag is happening, as apparently commands can be received and processed out of order which should never happen with a reliable stream), the first being packet loss, and the second occurring when a client lags. Packet loss occurs when one end has an unstable connection and packets are failing to reach their destination, and packet jitter which occurs when packets are arriving at their destination late, when they arrive late, the server has to process all of the commands it received late in a single server frame, when a client lags or stops sending packets for a period of time, they'll continue creating movement commands until they either disconnect or stop lagging, when they're lagging, all of the commands are batched up so that they can be sent next client update, when the client stops lagging, the client sends all of the batched movements to the server in a single update, where the server processes them from front to back in the next server frame, when all of these commands are processed, the server accepts the various movements the client has made since they last sent an update and voila, they move, albeit not very smoothly.

And would you believe this? Speedhacking works the same way, when you speedhack, you create multiple commands per server tick, they're all batched up and sent to the server at once, the server processes them from front to back, and you move...just a lot faster than expected.

Movement is not clientside, what you see is nothing more than a side effect of proper input prediction, which you should be thankful for. Most games to this day are still utilizing networking code from the Quake engine, and for good reason, it can't be done much better than it already has been.

What's the fix? Only allow the server to process a certain amount of user commands per server frame, this is what the Source Engine does and it works very well, just remember that you have to account for high FPS or you'll get clients with good PCs stuttering all over on their screen.


pretty sure this is not the case for APB. The server just predicts with the current movement where a character goes, And the client even executes this, (remember when you get a dc and chars keep walkign into the air?) but the movement itself is not serversided (which would mena movement happens after server cofirms it) All the server does is forwarding the clients movement input. thats why we see lags, because the sudden change of a players movement gets forwarded with a bit of dely (especially when servers are laggy and then the servers information to you needs to correct the inaccurate position. thats why the stupid WASD dancing exists and creates what it does. if the game were truly serversided WASD dancing would be rather worthless.

Share this post


Link to post
Share on other sites
20 hours ago, Obvious Lesbian said:
i get 600ms from the middle east. does that mean we can do this already

i wanna see my character moving with 6 second delays. 😄
Technically speaking it is a 0.6 delay per input you've given - 6 seconds is (6000ms).

As for the topic at hand, server-based movement would be extremely unreliable at it's current state due to performance from the server's hardware and networking ports they maybe using. Guaranteed it will push the servers to it's limits and will worsen the performance in the long-run.

Share this post


Link to post
Share on other sites
3 hours ago, LilyV3 said:

pretty sure this is not the case for APB. The server just predicts with the current movement where a character goes, And the client even executes this, (remember when you get a dc and chars keep walkign into the air?) but the movement itself is not serversided (which would mena movement happens after server cofirms it) All the server does is forwarding the clients movement input. thats why we see lags, because the sudden change of a players movement gets forwarded with a bit of dely (especially when servers are laggy and then the servers information to you needs to correct the inaccurate position. thats why the stupid WASD dancing exists and creates what it does. if the game were truly serversided WASD dancing would be rather worthless.

Close.

Movement is server authorative, meaning you send a "move me" signal to the server but your client will start moving your character on your screen without awaiting the response.
The server will keep track of your location/speed to make sure that your movements are "legal", and thus tries "predicting" your movement, even though it's more like "keeping your movement going in the direction of your last input".

If the position of the character on your client is too far from what the server thinks it should be (aka an "illegal move") it'll move you to the "correct" location. BOOM, there's your teleporting and rubberbanding.

The same goes for enemies. The server sends your client information about things like position, orientation, movement, ... for your client to render.
The thing is that your client will keep simulating the last "movement update" it received from the server even if the enemy has already changed direction.

That's why enemies teleport when the server is having a shit day,  your client is still using the information from the last update from the server which said the enemy was moving left. Now you get a new position and movement package and it seems the enemy has long since started moving in another direction, AKA the enemy teleports.

This is explains things like:

- why you can keep moving freely even after you get the "disconnect" countdown timer
- why you can't enter a car, change weapons, throw a nade, change the shoulder the camera looks over,... while "disconnected"
- why cars and players might start flying or running into walls when you're disconnecting

...

 

Share this post


Link to post
Share on other sites

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...