0.4-armagetronad-work Rubber / Wall glitch

[LittleSteps]

While playing sumo I have seen people box themselves and start to endlessly turn regardless of their rubber being 5/5, it was very persistent, so I just assumed it was a macro or some kind of bot.
Although when I decided to download the latest version of 0.4-armagetronad-work and work on a project of mine, I noticed that I am able to reproduce the same persistence as a couple of other players who I have seen do this.
Although it does not seem natural, I feel as if I have ample amount of time to turn even when my rubber hits 5 out of 5, and even when I do it looks buggy as if I am teleporting off the wall.

Here is a video of myself doing what was mentioned and what I believe is a bug / glitch.
https://www.youtube.com/watch?v=tUL4XiWEy1Q

In this video I enter the server "Wild West =Saloon SumoBar= Texas," which is "0.2.9-sty+ct_alpha_r793 unix dedicated." This bug / glitch is reproducible in any server I have tested it in.

[Light]

There's a LAG_RUBBER setting or something like that you might wanna toy with. Couldn't watch your video at the moment, but I'm assuming that's what it would appear to be?

[aP|Nelg]

There's a LAG_RUBBER setting or something like that you might wanna toy with. Couldn't watch your video at the moment, but I'm assuming that's what it would appear to be?

CYCLE_PING_RUBBER

[LittleSteps]

There's a LAG_RUBBER setting or something like that you might wanna toy with. Couldn't watch your video at the moment, but I'm assuming that's what it would appear to be?

CYCLE_PING_RUBBER

Which is still a server side function that differs from server to server (most of the time is set to 3 though), but this is reproducible in any server while using the latest version of '0.4-armagetronad-work'. Also in the video, in the bottom left hand corner you can see my ping ends up normalizing at around 70. But, regardless of my ping low or high, this is still reproducible in any server.

[aP|Nelg]

There's a LAG_RUBBER setting or something like that you might wanna toy with. Couldn't watch your video at the moment, but I'm assuming that's what it would appear to be?

CYCLE_PING_RUBBER

Which is still a server side function that differs from server to server (most of the time is set to 3 though), but this is reproducible in any server while using the latest version of '0.4-armagetronad-work'. Also in the video, in the bottom left hand corner you can see my ping ends up normalizing at around 70. But, regardless of my ping low or high, this is still reproducible in any server.

And you cannot reproduce this in older versions of 0.4, 0.3, or 0.2?

[ConVicT]

Yes, it works on 0.2.8; I was doing it for a while yesterday.
Does this mean that when I see people mazing, they're actually exploiting a bug because their rubber is always between 4.5 and 5?

[LittleSteps]

And you cannot reproduce this in older versions of 0.4, 0.3, or 0.2?

Good thought, It actually can be reproduced while using 0.2.3.X but in my short experience while using the client, not nearly as easy. Hard to find a server hosted on something other than sty-ct-ap, but the server 'Ladle 106 CT'S STO' was hosted on '0.2.8_alpha20110403 unix dedicated' and while using the latest available 2.3.3.X client, I was able to reproduce the 'glitch' a couple times, but no where close to as easy and natural as I did while using 0.4. So much harder that it took me a couple tries, normally I would join the server and do it immediately, but it took me a couple times to be able to do it as shown in the video below, where I skip to when I finally did it.
For 0.3, I am unsure, I have not tried and I do not have the time to compile it right now, but I am sure it does occur in that client, I do not know how easily though.

https://www.youtube.com/watch?v=E86vUn4j5JE - Link to me trying to reproduce the glitch using the latest 2.8.3.X client available from armagetronad.net, and playing on a 2.8_alpha server unix hosted server. Like I said, took a couple tries, but it was reproduced.

Yes, it works on 0.2.8; I was doing it for a while yesterday.
Does this mean that when I see people mazing, they're actually exploiting a bug because their rubber is always between 4.5 and 5?

I am not sure, very possible though. This bug has certainly saved me from dying in a couple servers for sure. Rubber has always been pretty buggy to begin with, I am not sure if there will be any motivation to fix this issue even if we did find the root cause. The only odd thing is that in my older 0.4 client, I do not remember experiencing this bug, but while looking at the changes / revisions in 0.4-armagetronad-work I do not see anything that could have caused this since then.

[vov]

This definitely is nothing new. It's (probably, what I've always thought) part of the anti-lag measures. They're quite generous sometimes. Depends on the server settings and your connection though.
That said, I'd still be doubtful of anything being shown to me on "swag's hacked armagetron client" (first video) .

[Z-Man]

Oh, it looks like it's this bit in gCycle.cpp:

Code: Select all

    // cheat. If rubber ran out, backdate the time.                                                                                            
    if ( other.RubberDepleteTime() > 0 )
    {
        gameTime = other.RubberDepleteTime();
    }

My philosophy for open source clients is that the official client should already cheat as much as possible, so that there is the least possible fertile ground for hacked cheat clients.
This bit exploits the new-in-0.2.8-bzr lag credit system that makes the server accept messages from clients even if they're delayed. The cheat kicks in if a client turns the cycle too late in front of a wall and the rubber is way depleted and if it's honest, the cycle is certainly going to crash. So it pretends it already sent the turn message just as the rubber ran out.
It's in 0.2.8-bzr and of course 0.4. Dunno about 0.3, but I guess not.