66 réponses à ce sujet

[Thrasher91604]

OK, yeah, thanks, I see that now. The way I see it, long queues cause the rubberbanding if the client does some freewheeling while waiting to hear from the host. The client jumps ahead, then the host sends it back...

[Thrasher91604]

Won't it delay your damage being registered on the host? Also, less responsive powers, etc..?

[Caratinoid]

Thrasher91604 wrote...

Won't it delay your damage being registered on the host? Also, less responsive powers, etc..?

I specifically said few times already ... no!

[Thrasher91604]

Right, it just affects position data rates. Interesting.

[megawug]

Took the cabal out for a spin... no rubberbanding with poison strike so far! Woot!

It seems the fact that the Unreal engine assumes 30 FPS is probably what causes of most of the problems. 60 FPS... what a foreign concept!

Modifié par megawug, 25 juillet 2013 - 07:55 .

[Thrasher91604]

Wouldn't games on low latency hosts with good data rates (no queues) become less responsive in position control? Might actually make enemies miss you, unless hits are registered on the host rather than the client.

Modifié par Thrasher91604, 25 juillet 2013 - 08:04 .

[megawug]

Thrasher91604 wrote...

Wouldn't games on low latency hosts with good data rates (no queues) become less responsive in position control? Might actually make enemies miss you, unless hits are registered on the host rather than the client.

The problem is lost packets.  That 1/30 of a second difference under normal circumstances isn't going to be noticed.  A person certainly can't click that fast.

[Caratinoid]

Thrasher91604 wrote...

Wouldn't games on low latency hosts with good data rates (no queues) become less responsive in position control? Might actually make enemies miss you, unless hits are registered on the host rather than the client.

Hit detection for enemy bullets is performed on host, so the enemies will not magically miss you if your position is lagging a bit. Hit dection for your own bullets (for hitscan weapons) is performed on client.
 
Since it only affects your position and camera rotation on the server you will not see much diffirence if you go higher than 30 updates per second. The host will be able to see your every little mouse movement if both you and the host run the game at 100 FPS and live not far from one another but does anyone really need that kind of precision? It's not like it's a PvP mode where this may become important. Besides keep in mind that joning the game with very high frame rate while the host plays at very low frame rate may even cause problems for other players, because you'll be sending  more data than the host can process.

Modifié par Caratinoid, 25 juillet 2013 - 08:54 .

[BridgeBurner]

Caratinoid wrote...

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.

Mass Effect 3 hit detection is client side. Fewer packets being sent = fewer shots recorded in each packet. The game doesn't save up all your hits and jam them into one packet, it has to timestamp them to some degree, meaning sending fewer packets adversely affects high RoF weapons.

Experiencing the original UT on a 30 FPS server is markedly different from a 20 FPS server. losing 10 frames reduces the number of shots registering / RoF by almost 25% due to rounding, the same applies here with the packets. Fewer packets received = less data available, invariably leading to damage loss at low frame rates with weapons which have a high RoF. The packets aren't any "larger" there's still the same amount of recorded data, ergo, you lose more by communicating less often.

Has been this way since the UE, and is still the same now we're approaching UE4.

Modifié par Annomander, 25 juillet 2013 - 09:01 .

[Thrasher91604]

I think what he's saying is that this parameter only affects the rate of position data being sent, not recorded shots, which are still sent at the same rate?

[BridgeBurner]

Thrasher91604 wrote...

I think what he's saying is that this parameter only affects the rate of position data being sent, not recorded shots, which are still sent at the same rate?

Packets are packets, you can't choose what's in them, and reducing the number of packets sent will have the effect that I have mentioned.

You might not notice it, but in PVP games it is a huge deal.

[Thrasher91604]

I know what you are saying, but if the low level packet rates are not being affected, but just the rate (or quantity) of position data being put into them, then there would be no affect on recorded shots.

EDIT: Or it could just repeat position data, until the time period had exprired, and then send updated position data. In this case too, hit rates wouldn't be affected. Seems odd but if it fixes rubberbanding then maybe not...

Modifié par Thrasher91604, 25 juillet 2013 - 09:17 .

[megawug]

Annomander wrote...

Thrasher91604 wrote...

I think what he's saying is that this parameter only affects the rate of position data being sent, not recorded shots, which are still sent at the same rate?

Packets are packets, you can't choose what's in them, and reducing the number of packets sent will have the effect that I have mentioned.

You might not notice it, but in PVP games it is a huge deal.

In this case, that might not be true.  If the client side has calculated the damage, it should pass the last known state to the packet, even if it's less often.  Also, this assumes the parameter affects damage, which we're not sure of.

[Caratinoid]

Annomander wrote...

Caratinoid wrote...

Annomander 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.

Mass Effect 3 hit detection is client side. Fewer packets being sent = fewer shots recorded in each packet. The game doesn't save up all your hits and jam them into one packet, it has to timestamp them to some degree, meaning sending fewer packets adversely affects high RoF weapons.

Experiencing the original UT on a 30 FPS server is markedly different from a 20 FPS server. losing 10 frames reduces the number of shots registering / RoF by almost 25% due to rounding, the same applies here with the packets. Fewer packets received = less data available, invariably leading to damage loss at low frame rates with weapons which have a high RoF. The packets aren't any "larger" there's still the same amount of recorded data, ergo, you lose more by communicating less often.

Has been this way since the UE, and is still the same now we're approaching UE4.

Don't compare it to standart UE model, it is not, it's custom Bioware logic here, they replaced some of the standard network code. So, again, it will only affect how fast your position and rotation gets updated. This will not affect how many packets are availible it will simply not replicate your postion to the server for a few frames all the rest will be replicated as fast as your tick rate allows it.

EDIT:
It's not that there are less packets availible, it's just that there is less data availible because position will be updated less frequently, and as a result there will be less packets. If you start shooting the number of packets will increase.

Annomander wrote...

Thrasher91604 wrote...

I think what he's saying is that this parameter only affects the rate of position data being sent, not recorded shots, which are still sent at the same rate?

Packets are packets, you can't choose what's in them, and reducing the number of packets sent will have the effect that I have mentioned.

Developers have full control of which data should be updated and how often.

Modifié par Caratinoid, 26 juillet 2013 - 08:14 .

[BridgeBurner]

megawug wrote...

Annomander wrote...

Thrasher91604 wrote...

I think what he's saying is that this parameter only affects the rate of position data being sent, not recorded shots, which are still sent at the same rate?

Packets are packets, you can't choose what's in them, and reducing the number of packets sent will have the effect that I have mentioned.

You might not notice it, but in PVP games it is a huge deal.

In this case, that might not be true.  If the client side has calculated the damage, it should pass the last known state to the packet, even if it's less often.  Also, this assumes the parameter affects damage, which we're not sure of.

All damage calculations are done on host.

If the host does not receive the notification that you hit the client (by using a packet rate that is too infrequent when compared to your frame rate) you will "lose" shots.

[Thrasher91604]

You're not following us. We are saying packet rate may not be affected. How do you know this parameter doesn't affect what data it puts in the packets rather than the underlying packet rate?

Modifié par Thrasher91604, 25 juillet 2013 - 09:29 .

[megawug]

So I've done 5 games with the Cabal (off-host, 60 FPS), and no rubberbanding. In fact, lag in general has never been so good, but sample size is still too small to be sure.

Modifié par megawug, 26 juillet 2013 - 04:29 .

[Caratinoid]

megawug wrote...

So I've done 5 games with the Cabal (off-host, 60 FPS), and no rubberbanding. In fact, lag in general has never been so good, but sample size is still too small to be sure.

What value are you using for MOVEREP_DELAY_FRAME?

And yes it should reduce your lag time too because there is less data to send network packets will also be smaller which means lower ping. You can actually see this if you try to ping another computer with different packet sizes (standard command line command 'ping' in windows can do it).

I played different classes during a night (this is when I usually get problems) and had no issues either. In my case I get 90 updates less out of possible 120 (MOVEREP_DELAY_FRAME of 3 at 120 FPS) so I guess if there would be any problems I would notice them by now.

[Caratinoid]

EntropicAngel wrote...

Rubber-banding is a term usually used for racing games, where the AI of the other racers are "rubber band-ed" to you--if you're ahead of them they'll drive like bats outta hades to catch up, and if you're behind they drive super slow.



Just thought I'd mention that. Continue.

Yeah, I didn't come up with the term, other people were refering to this as "rubber banding" (probably because the game keeps teleporting you to your previous position making it look like you are connected with a rubber band to a certain part of the map) so I just followed.

Modifié par Caratinoid, 26 juillet 2013 - 08:22 .

[the slynx]

Thanks for posting this. It'd be nice to try the game out beyond 40 FPS and not do my best Banshee imitation. Will try it out in the future.

Always been a bit worried about touching coalesced before, but I guess support's done, so they'll not be going after people for modding this stuff any longer.

[Deerber]

Yeeeee Caratinoid is back! And with very useful info!!

Now, if only I wasn't too lazy to dig into the coalesced... I'd totally give this a try!

[Caratinoid]

Did another test with a very large value, which gave me about one location update per second. In game it would take around one second for an ammo box or hack circle to register my location (which was to be expected) but powers and weapons were still working instantly with no lag, so I guess it confirms that it does not affect powers or weapons.

[megawug]

Caratinoid wrote...

What value are you using for MOVEREP_DELAY_FRAME?

And yes it should reduce your lag time too because there is less data to send network packets will also be smaller which means lower ping. You can actually see this if you try to ping another computer with different packet sizes (standard command line command 'ping' in windows can do it).

I played different classes during a night (this is when I usually get problems) and had no issues either. In my case I get 90 updates less out of possible 120 (MOVEREP_DELAY_FRAME of 3 at 120 FPS) so I guess if there would be any problems I would notice them by now.

I'm using a value of 2, which should be 30 per sec (60 FPS/2).  There's definitely still lag off-host, but I'm getting a lot less of the "get hit before I see it" kinda warping.  It's nice not to have to start dodging before the enemy fires a shot.

[12323432543]

So, I tried this and it works. No teleporting around anymore. Unfortunately, because my ISP is **** I'm still having to deal with annoying lag on all my games. In any case, good tip OP.