66 replies to this topic

[Caratinoid]

By rubber banding I mean a situation when your character starts to teleport left and right or gets teleported backwards multiple times after your run around a corner. The glitch is caused by a game bug diep inside network code which doesn't handle network packets that arrive out of order properly. It is likely to happen when the client who is playing at a high frame rate connects to a host with big network latency.

When you are playing off host, the amount of data you send to the server will be proportional to your framerate. So, reducing your framerate will also reduce the amount of network traffic and decrease the chance of rubber banding issue. Until now that was the only known workaround but ...

I have found a different workaround that will help reduce the amount of network traffic without having to decrease you frame rate. Before you proceed however please note that this fix is meant for people playing at a high frame (60+ FPS) or those who often play at night from australia and experience this glitch very often. If you don't have these problems then please stay away from it.

Anyway here is the fix:

There is a varible inside Coalesced.bin called MOVEREP_DELAY_FRAME. It controls how many frames the game will skip before sending client position information to the host. It's default value is 1 which means that the game will send 1 update each second frame.

You should set it to an iteger value which will give you an acceptable number of position updates sent per second. This is how you calculate how many updates you'll get based on your framerate:

Position updates per second = FPS / (MOVEREP_DELAY_FRAME + 1)

A good value to be at is in range 20-30 position updates per second. If that still gives you problems you can go lower but I would not go lower than 15. I personaly play at 120 FPS, so for me I have set it to 5, which gives me 20 position updates per second.

Oh yeah, this will not affect how fast you deal damage or how fast your powers get transmitted to the host so it will not add any aditional lag time or anything like that. It will in fact reduce your lag a bit because network packets will be smaller because there is less data to send.

Edited by Caratinoid, 29 July 2013 - 02:08 PM.

[capn233]

Caratinoid wrote...

If you don't have these problems then please stay away from it.

Is that because you can use this fix for evil instead of good?

[Caratinoid]

capn233 wrote...

Caratinoid wrote...

If you don't have these problems then please stay away from it.

Is that because you can use this fix for evil instead of good?

No, but you can mess things up.

[capn233]

Caratinoid wrote...

No, but you can mess things up.

You were starting to make me think that if the host had more error in a client's location that the AI might not be able to hit them as easily.

[tetsutsuru]

I've had that happen. A rare occurrence, but man, is it annoying. It's like in Wayne's World when he was doing, "Camera 1. Camera 2. Camera 1. Camera 2." I just get into hard cover and camp there for about 20 seconds, which usually alleviates the de-sync.

[capn233]

tetsutsuru wrote...

I've had that happen. A rare occurrence, but man, is it annoying. It's like in Wayne's World when he was doing, "Camera 1. Camera 2. Camera 1. Camera 2." I just get into hard cover and camp there for about 20 seconds, which usually alleviates the de-sync.

I get rubber banding every now and then.  Not really common for me, unless I get connected to a host on the other side of the globe.

Or Windows Update decides to run.

[Zjarcal]

For some reason I thought you made a thread about this already.

Great info, already knew you could fix it in coalsced but didn't know exactly how.

[Heldarion]

tetsutsuru wrote...

I've had that happen. A rare occurrence, but man, is it annoying. It's like in Wayne's World when he was doing, "Camera 1. Camera 2. Camera 1. Camera 2." I just get into hard cover and camp there for about 20 seconds, which usually alleviates the de-sync.

I did that stuff too, only I didn't stay in hard cover for 20 seconds, only 2 or 3 then repeated when rubber banding reappared. As good a fix as I could get at the time

[Fixx21]

Caratinoid

Why have some powers / weapons that do not work off host?
has a solution?

[Caratinoid]

Zjarcal wrote...

For some reason I thought you made a thread about this already.

Great info, already knew you could fix it in coalsced but didn't know exactly how.

Yeah this had already been discussed before, but aside from decreasing your framerate no real solution was given. Accidentally stumbled on this variable today while looking through the code base.

Edited by Caratinoid, 25 July 2013 - 05:11 PM.

[megawug]

Oh wow... Caratinoid, I hope this works! I'll report back later.

[Thrasher91604]

Has this been tested on a rubberbanding game or is it only theory? How would you know if you already changed Coalesced.bin? Is this on the host side or client side?

Edited by Thrasher91604, 25 July 2013 - 06:06 PM.

[capn233]

Caratinoid wrote...

Yeah this had already been discussed before, but aside from decreasing your framerate no real solution was given. Accidentally stumbled on this variable today while looking through the code base.

Please figure out how to add more enemy units to SP.

[Caratinoid]

Thrasher91604 wrote...

Has this been tested on a rubberbanding game or is it only theory? How would you know if you already changed Coalesced.bin? Is this on the host side or client side?

I tested it with wireshark to see how many packets will get sent per second, it does appear to do what I think it should.
And it's on client side obviously, if you get rubber banding on host then something is seriously wrong.

[Qui-Gon Glenn]

Very interesting, will test.

[Thrasher91604]

Let me be more clear, are the coalesced settings only followed when changed on the host? Also, the question is whether or not rubberbanding is tested; is it an unproven jump in logic that fewer packets leads to less rubberbanding?

[Caratinoid]

Thrasher91604 wrote...

Let me be more clear, are the coalesced settings only followed when changed on the host? Also, the question is whether or not rubberbanding is tested; is it an unproven jump in logic that fewer packets leads to less rubberbanding?

You need to change it on the client side, it will only affect your game. Changing it on the host does nothing when hosting.

Artificially decreasing internet bandwidth while increasing frame rate does result in certain rubber banding without a fix. The glitch does not occur however after applying the fix under the same circumstances. Haven't seen any other problems so far.

[Caratinoid]

capn233 wrote...

Caratinoid wrote...

Yeah this had already been discussed before, but aside from decreasing your framerate no real solution was given. Accidentally stumbled on this variable today while looking through the code base.

Please figure out how to add more enemy units to SP.

I'm looking at MP part since I got code compiler working. I will try to fix some small MP bugs first, though if anyone has any good  ideas of some mod requiring code access I may get interested in that as well.

[BridgeBurner]

Thrasher91604 wrote...

Let me be more clear, are the coalesced settings only followed when changed on the host? Also, the question is whether or not rubberbanding is tested; is it an unproven jump in logic that fewer packets leads to less rubberbanding?

The unreal engine's netcode is heavily dependent on "tick rate". This is basically the smoothed FPS rate of the server, in the case of ME3, this is whatever the host is playing at.

Lower frame rate in Unreal Engine games = fewer resources alocated for processing the logic of the game you are running. This is the same thing with AI difficulty; higher frame rate expands the available resources to carry out AI processes, thus enemies tend to be a bit more ferocious at higher frame rates, and will dumbly shoot past players who are standing still at 30 or lower.

The same problem exists for tick rate. Low server side tick rate leads to the host being unable to process all the information being received. This problem is exacerbated, when you factor in pre-calculations. Clients / hosts will always pre-calculate your movement / actions to some degree, and high latency causes this to become erratic, as the host is receiving data packets telling you you are at location X, when you are actually at location Y, or A or B or C, hence rubberbanding.

Remember, reducing your net-work packets per second transmitted will lead to lost damage from high-fire rate weapons, as your game simply will not transmit all the shots you are firing properly.

Using this kind of edit will 100% work off host, just like editting your files to uncap frame rate works off host too.

[Dr. hoovsbin]

Where do I find the Coalesced.bin file?

When I'm at home I play on a high end desktop PC over a satellite ISP and this is a constant problem that can make an easy game tough.

[capn233]

Caratinoid wrote...

I'm looking at MP part since I got code compiler working. I will try to fix some small MP bugs first, though if anyone has any good  ideas of some mod requiring code access I may get interested in that as well.

I was sort of kidding.  I don't know what would be required for that sort of SP mod.

[Thrasher91604]

Not seeing why sending fewer packets will cause less rubberbanding.

EDIT: OK matching the data rate available to the host would make more sense.

Edited by Thrasher91604, 25 July 2013 - 07:20 PM.

[BridgeBurner]

Thrasher91604 wrote...

Not seeing why sending fewer packets will cause less rubberbanding.

At high latencies, the packets begin to queue up instead of being processed, leading to a disparity between where the host thinks you are, and where you think you are. In ME3, the host is authoritative in almost every regard, bar cooldowns and rate of fire. The host (except when you're dead) is 100% in control of where you are, causing rubberbanding, as the host "forces" your character into the position that it believes you should be in.

Edited by Annomander, 25 July 2013 - 07:19 PM.

[Caratinoid]

Thrasher91604 wrote...

Not seeing why sending fewer packets will cause less rubberbanding.

High ping + many packets = higher chance for a few packets to get delayed and be received out of order, making you jump to your previous position.

[Caratinoid]

Annomander wrote...

Thrasher91604 wrote...

Remember, reducing your net-work packets per second transmitted will lead to lost damage from high-fire rate weapons, as your game simply will not transmit all the shots you are firing properly.

This only applies for lost packets. This fix will not affect weapon damage. I know because I see where this variable is used in the code, it will only affect how fast your position gets updated, nothing else.

Edited by Caratinoid, 25 July 2013 - 07:23 PM.