adjusting in tron

[Your_mom]

when did adjusting stop being cheap? when did 180ing on the rim 5 times become part of gameplay? mabey im the only one sick of pure grinding and having a noob grind and adjust/180 so many times its impossible to beat without adjusts and 180s, mabey im just sick of pure grinding and not bieng able to beat that. Mabey i just still want armagoshdarn back ...

but i guess my main question is

when did adjusting stop being cheap?

[dlh]

I try to stay away from the rim wall, because I know to beat grinds I am going to have to adjust now that cycle_rubber_mindistance is in effect. And I don't really try to tunnel through walls anymore, because grinding has become too easy (so to beat a grind I have to adjust). Maybe the 2.7.0 servers should set the compatibilty setting so only 2.7.0 clients or less can connect (swampland is the only 2.7.0 server i play on now, but its just not the same with the new clients).

Because of all the new changes, I've had to adapt my gameplay. I usually try to catch people out in the open now, by overtaking them with speed or just capitalizing on their offensives with what I call a hook.

Bounces were actually a good way to stop adjusters. With the fix of that bug, adjusting and 180ing has become rampant.

Certain tatics are acceptable to different people. For instance some consider double-binding cheap (but only as a way to justify themselves for losing :p) If you grind on the rim wall, be prepared to adjust, there is no other way.

[Jonathan]

I think artificial instability (or whatever you want to call it) could help...

[Lucifer]

I want the return of grinding as a skill. Grinding right now is all about luck and how close the server decided you were to the wall. Tight grinds used to be like "wow, that was tight". Now they're standard fare....

[Z-Man]

Really important is probably that you set

Code: Select all

CYCLE_RUBBER_MINDISTANCE_LEGACY 1

or even 0 on a new server. The default value of 10 is absolute nonsense.

If you want to make grinding take real skill, try this (should work on a 0.2.7.1 server, I only tested with current CVS):

Code: Select all

CYCLE_RUBBER_MINDISTANCE -0.01
CYCLE_RUBBER_MINDISTANCE_RATIO 0

With these settings, the rubber won't stop cycles before a wall, it will only slow them down. Independently of the setting of CYCLE_RUBBER, players will only have a limited time window to make their turn before a wall. Best thing about this is that it will affect users of 0.2.7.1 more than those of earlier versions, so it evens the playing field again.
If you want to hack a 0.2.7.0 server to send 0.2.7.1 clients these settings, it's easily possible: just add the lines

Code: Select all

// minimal distance to a wall rubber will allow
static REAL sg_rubberCycleMinDistance=-.01;
static nSettingItem<REAL> c_rmd("CYCLE_RUBBER_MINDISTANCE", sg_rubberCycleMinDistance);

// the length of the wall times this value is added to the previous value
static REAL sg_rubberCycleMinDistanceRatio=0;
static nSettingItem<REAL> c_rmdr("CYCLE_RUBBER_MINDISTANCE_RATIO", sg_rubberCycleMinDistanceRatio);

anywhere in src/tron/gCycle.cpp. This will have no influence on your server itself or on 0.2.7.0 clients, but the 0.2.7.1 clients will get their rubber code "sabotaged".

In current CVS, there's an extra option that makes 180s and adjusts take more rubber or even be deadly. Right after a turn, rubber can be weakened or disabled. This code was originally in 0.2.7.1, but nobody liked it to have it on his own machine. But I guess people will like it to be on other players' machines

I'm afraid there is no such thing as an option to expel users of a new client from an old server. You can use the new feature delay setting to make the server pretend that it uses an older network protocol, but the client knows it's compatible with all older servers down to 0.2.0, so this won't be of use here.

Sorry about the apparent randomness of grinds now. The changes from 0.2.7.0 to 0.2.7.1 were supposed to do exactly the opposite. I really have no explanation currently.

Jonathan: What is artificial instability supposed to be?

[Lucifer]

Well, you know how to push my buttons, z-man. I added those two lines to Swampland in 0.2.7.1's everytime.cfg. Hope swampy doesn't mind the test....

[Jonathan]

I just tried that server. Much better. Could have been harder though.

Jonathan: What is artificial instability supposed to be?

My idea was to put in some randomness based on how much you stress rubber etc.

Edit: like if you grind for too long in THPS (if you ever downloaded the demo ) you get very unstable. The longer you grind the bigger the chance that you fall (in Armagetron: the more you abuse rubber the bigger the chance that you die).

[Lucifer]

Didn't work, actually, Jonathan, so I just multiplied the mindistance by -1.

Try Breakfast of Champions, it was up a few minutes ago, and compare it. I guess we're asking for the old grind feel back but without the bounce. It might be impossible, I might add.... If I re-enable the bounce will I get the old grind back?

[Z-Man]

Seems to be working. I dropped in quickly and saw a lot more explosions than usual

I forgot to add how to tune the negative MINDISTANCE: the value affects the difficulty of grinding logarithmically. That means to turn the difficulty up/down one notch, you have to double/cut in half the value of CYCLE_RUBBER_MINDISTANCE. A change from -.01 to -0.02 shrinks the length of the time window by the same amount as a change from -0.02 to -.04. Values closer to zero than -0.001 will probably get lost in the land of floating point inaccuracies.

[Z-Man]

Unfortunately, I still don't know how the bounce bug really was caused. It was an odd interference between at least three effects, one of them being simulation steps backwards in time. I would have added a BUG_BOUNCE setting if I knew how

[Lucifer]

Seems to be working. I dropped in quickly and saw a lot more explosions than usual

I forgot to add how to tune the negative MINDISTANCE: the value affects the difficulty of grinding logarithmically. That means to turn the difficulty up/down one notch, you have to double/cut in half the value of CYCLE_RUBBER_MINDISTANCE. A change from -.01 to -0.02 shrinks the length of the time window by the same amount as a change from -0.02 to -.04. Values closer to zero than -0.001 will probably get lost in the land of floating point inaccuracies.

So we're talking base 10, then, right? So -0.01 is really 10^-0.01, or 1/10^0.01, which is 0.97724, about. 10^-0.02 is 0.954993, about. What does that number represent specifically? Is it milliseconds before you crash? Or what?

Mind you I switched swampland back to mindistance = 0.01 because it was unplayable.

[Jonathan]

I don't know anything about the internals of the bounce, but was it platform-dependent?

[Lucifer]

I don't know anything about the internals of the bounce, but was it platform-dependent?

No. Here's what it *looked* like:

(this is just one scenario)You'd be driving in a straight line next to a wall. So you double-bind to turn around, turning towards the wall.

The cycle would make it's first turn and the server would compute its position, right? Then a combination of rubber and proximity would actually shift the cycle back a little bit so his tail is actually on the outside of the two walls. Then the server would make the second turn on the cycle and compute its new position, and instead of being in the tunnel you made, you're outside the tunnel. It would then take an update or two (and a slide) to get your client to show your cycle in the right place, usually resulting in death because you make moves based on where you thought you'd be.

The situation's a bit more complex than that. The wall would have a break in it, and the break corresponded to the place you bounced. So let's say you're grinding the grid wall and someone has beaten your grind, so you adjust against the grid wall to get him. You bounce instead, and you're farther from the wall, and your wall has a break in it.

Now, the bounce varied in size, it wasn't always "the length of the cycle", although it usually was. But it would vary, sometimes you'd have a small bounce, sometimes a large bounce. Your actual speed affected the size of the bounce a great deal, so on ish where the cycles are painfully slow, bounces were small and it was an effective way to build a tunnel that you'd use as a slingshot, whereas on Breakfast of Champions bounces tended to be big and had mean consequences.

Due to the bounce, 180s were extremely dangerous. Sometimes you'd 180 and be ok, sometimes you'd 180 and bounce, but most of the time you'd 180 and bounce but think you're ok, which caused you to make the wrong decisions and crash.

The bounce could be exploited to move you across walls, but that was hard to do. Nevertheless, I managed it a couple of times, and there are others (whose names we won't mention 'cause I"m still pissed about it) who used the bounce bug to go through walls pretty much anytime they wanted.

So to wander for a moment, the reason I suggested that nemo's broken wall bug and the current going through walls might be a new incarnation of the old bounce bug is because the symptoms during gameplay appear to be the same, and it's all about tracking the cycle's position and the effects rubber has on it near walls. Nemo's broken wall looked like it happened near some intense turns (which the server/client relationship renders ambiguous by the nature of the relationship). Well, the going through walls bug also usually happens during intense turning and around walls (obviously, you can't go throuh a wall unless you're near one).

In any case, we're happy the bounce is gone, but in the process of losing the bounce, we've also lost a lot of the old grind. It used to be that when you hit a wall you could watch your rubber gauge, turn at the last minute, and make a really tight grind. Grinding was a skill that you had to master, and beating someone's grind was a competitive accomplishment. Now grinding is different. I suspect the time-travel code has something to do with it too, because I can see how the server making timing corrections based on the timestamp could affect grinding. Also in losing the bounce we've got all these 180s. So what your_mom and I (and misery and eggcozy based on some BoC play we had a few minutes ago) are all wanting is the old grinding behavior back, 180s reduced, AND no bounce. As misery put it, "play a CLEAN game".

For reference, since I don't know how much game lingo you know z-man (you did take that hiatus, and I don't know how much of it is new language created during that time), grinding refers to getting close to a wall and driving parallel to it. I.e. to gain speed you grind a player's wall.

[Z-Man]

Ok, long rubber mechanics explanation follows. negative and positive MINDISTANCE settings have racically different effects. Warning, Math is involved:

For the sake of simplicity, let's say you're approaching a wall at x=0 from the positive side, we'll ignore the y coordinate. When rubber is in effect and MINDISTANCE is set to 0, your cycle will follow the trajectory
x(t)=C*exp(-CYCLE_RUBBER_SPEED*t)
where C is some positive constant determined by the initial conditions. Rubber gets activated at the moment the speed of this movement ( differentiating shows it's always CYCLE_RUBBER_SPEED * x(t) ) gets lower than your cycle's natural speed.

Now, with MINDISTANCE different from 0, the trajectory gets changed to
x(t)=MINDISTANCE + C*exp(-CYCLE_RUBBER_SPEED*t).

That means that for MINDISTANCE >= 0, rubber does its job and you never reach x(t)==0, because exp is always positive. For MINDISTANCE < 0 however, you do reach x(t) = 0 at the time
t_0 = -ln(-MINDISTANCE/C) / CYCLE_RUBBER_SPEED
and crash. Here, ln is the natural logarithm, the inverse function of exp(x) = e^x. Let's assume in the following that C will be constant when we play with the settings (it is not really, but it varies only slightly).
Since ln(x*e) = ln(x) + 1, multiplying MINDISTANCE with e has the effect of pulling forward t_0, the time of the crash, by 1/CYCLE_RUBBER_SPEED (which is 1/40 of a second at default settings). At default CYCLE_RUBBER_SPEED, multiplying MINDISTANCE with 2 has about the effect of decreasing t_0 by 1/60 of a second.

All in all, at negative CYCLE_RUBBER_MINDISTANCE, the time you have to turn should be given by
T=-ln(-CYCLE_RUBBER_MINDISTANCE/SOME_CONSTANT)/CYCLE_RUBBER_SPEED..
Or, if you want to tune CYCLE_RUBBER_MINDISTANCE, to reach a certain T, you have to set it to
CYCLE_RUBBER_MINDISTANCE=-SOME_CONSTANT*exp(-T*CYCLE_RUBBER_SPEED)

CYCLE_RUBBER_SPEED enters as a tunable parameter, too, but it has the other side effect of making rubber feel really sluggish when it is increased too far.

Well, that's the theory, at least. Some bits of code in 0.2.7.1 may actually interfere by sanitizing values. After all, negative MINDISTANCE settings were not planned.

Thanks for the bounce explanation.

[Z-Man]

I set up "0.2.7.1 test server" with the following config:

Code: Select all

CYCLE_RUBBER_MINDISTANCE -.001
CYCLE_RUBBER_MINDISTANCE_RATIO 0
CYCLE_RUBBER 5

With the 0.2.7.1 release code.

As Lucifer probably tried to point out, a drawback of the negative mindistance settings is that you can't rely on the gauge to judge when you have to turn. You'll need to use "The Force" or something. This is the prime reason I advertised this as "making it take skill again". It's a slightly different skill than required in 0.2.7.0, I'll have to admit that.

I also have to admit that the rubber gauge became less useful in 0.2.7.1 because it does not seem to handle overflows correctly; after heavy rubber abuse, it's stuck at the maximum reading for a while. Sorry about that. I'll try to make it more reliable for the next release.