03-24-2014, 11:54 PM
<div>I'd generally be in favor of keeping repels. I would be in favor of self kills being brought back though, pb thor should only be usable if willing to sacrifice self or have enough energy to take it.</div>
<div> </div>
<div>The biggest annoyance to me with repels is player latency. </div>
<div> </div>
<div>When a player gets repelled, the continuum client appears to try to do some kind of interpolation of the location on the enemies screen where they saw themselves repel you, and the location you are on your screen when you receive the repel packet and actually see the repel on your screen. This leaves the exact vector a player is actually going to take after being repelled as not quite determinate. It can be estimated accurately enough for the game mechanic to not be considered broken. The continuum client also likes to do a split second hop between these potential paths when this happens. </div>
<div> </div>
<div>While there are also latency issues with bullet/bomb timing to appear on a players screen, once it has, the damage you take is determinate. There are other issues here, it isn't particularly hard to exploit latency to make bullets/bombs that don't hit you on your screen, appear to hit you on other players screens to misrepresent your energy to those players.</div>
<div> </div>
<div>On the defensive side, my main annoyance, would be having to compensate for the opposing players latency when figuring the latest timing you have to repel safely. The last safe time to repel is consistently earlier against higher latency players (and goes up with your own latency as well). This aspect would be fine if we all had < 10ms connections, but that is not feasible.</div>
<div> </div>
<div>The biggest annoyance to me with repels is player latency. </div>
<div> </div>
<div>When a player gets repelled, the continuum client appears to try to do some kind of interpolation of the location on the enemies screen where they saw themselves repel you, and the location you are on your screen when you receive the repel packet and actually see the repel on your screen. This leaves the exact vector a player is actually going to take after being repelled as not quite determinate. It can be estimated accurately enough for the game mechanic to not be considered broken. The continuum client also likes to do a split second hop between these potential paths when this happens. </div>
<div> </div>
<div>While there are also latency issues with bullet/bomb timing to appear on a players screen, once it has, the damage you take is determinate. There are other issues here, it isn't particularly hard to exploit latency to make bullets/bombs that don't hit you on your screen, appear to hit you on other players screens to misrepresent your energy to those players.</div>
<div> </div>
<div>On the defensive side, my main annoyance, would be having to compensate for the opposing players latency when figuring the latest timing you have to repel safely. The last safe time to repel is consistently earlier against higher latency players (and goes up with your own latency as well). This aspect would be fine if we all had < 10ms connections, but that is not feasible.</div>