Lower the Rubber

[Goodygumdrops]

Whoa...so much to disagree with.

There are a lot of misconceptions about what rubber is and what it does. I'll just quote some of them mostly chronologically. But I want to preface by pointing out that rubber is not meant to be a gameplay feature or mechanic—meaning you shouldn't lament the loss of gameplay mechanics that are lost by reducing rubber, as they were an abuse and exploit in the first place.

When someone creates something, the only valid use for that creation is the creator's intention. Any other possible uses are actually irrelevant, incorrect, or abusive, even if they seem interesting or fun to people.

[Phytotron]

Copying most of my "ninja inb4 lock" post from the other thread into this one since I don't expect most of you will read the end of a locked thread, and reading Lucifer's quote of it may be kind of awkward, and in anticipation of anyone responding to it, quoting quotes is even more of a hassle. Then Lucifer will presumably delete his post preceding this one. And yes, it's quite long, but you all really should read it. It's informative! EDIT: Ah, damn, just missed the page break! This would've been an 'epic' one, too. Hmmph.


The entirety of the argument in this thread is bogus—on both sides—as it suffers from two flawed premises.

1. You're all acting as though Fortress (and Sumo and CTF) is a defined, game-wide game mode, an all-encompassing description of which includes all the physics settings. It is not. You're all suffering from a misconception. Fortress is defined by the zone behavior, period. That means a server can have any combination of physics settings—any rubber values, speed, acceleration, wall length, turn delay, walls stay up delay; as well as any sort of scoring—and still qualify as Fortress so long as it has the appropriate zone behavior. I know a lot of you don't want to accept that and would say "but it's really not Fortress," with an implied "as I know it," but thems the facts.

It's nothing more than a matter of convention (albeit, one somewhat codified in the Ladle) that has all these Fortress servers being clones of one another. Also, laziness, since all one has to do to create a "Fortress" server is use some pre-made config or map file (another negative side-effect of those damnable things). Same goes for Sumo and CTF. There's no reason whatsoever why every Sumo server should have Fortress-like physics, or why every CTF server should have high rubber and minuscule turn delay (CYCLE_DELAY).

It's similar to the way people conflate "high rubber" and "open/loose/dogfight" with an overall set of physics settings. "High rubber" describes the amount of rubber, period. There's no reason every one should have high speed and acceleration, minuscule turn delay, and usually heavy brakes. "Dogfight" is a description of (moronic) gameplay rules, not physics at all.

Or even the very fact that there is a large proportion of people in this game (and the Wiki, inconceivably) who actually refer to "rubber" as a game mode. "Do you play rubber?" "This is just another rubber server." That's just plain stupid.

Anyway, Lucifer alludes somewhat to this: Servers in this game used to be made distinct by their physics settings. Then all these "special game modes" were introduced and now there's actually less variety than there was in the old days. How's that for irony. But anyway, then he made the point about just making a Fortress server the way you want and leaving it to competition. And ordinarily I would mostly agree with this, except for the fact that what defines "Fortress" to most everyone playing these days—this all-encompassing view that includes a particular set of physics—has become so conventional. In effect, that convention has become a monopoly on Fortress; it's not a fair market environment. The default config and Ladle make putting up servers with alternative Fortress physics (whatever they may be) an even more disadvantaged position.

So, I don't have a solution (nor do I really care, since I don't even believe in Fortress's existence , but that makes me impartial, right?), but from an outside position, I'm informing you all that this premise is wrong. And you can begin to work toward a solution yourselves when you realize and accept that statements like "Lower the rubber in fortress!" or "OMG Don't change fortress!" simply don't make sense. In the first case, you can't change the rubber in every Fortress server because it's not a game-wide, all-encompassing game mode. In the second case, changing the settings—any settings besides the zone itself—in one or several Fortress servers isn't changing Fortress. It's only that server(s).

The statement "In regular fortress, I don't think it's feasible. I do, however, think there is merit for a new mode of fortress with lower rubber and other altered settings" doesn't make sense. "[J]ust make it as 'other gametype'" doesn't make sense. It wouldn't be a "new mode of Fortress." It would still be Fortress.

This is not a game like other online games you all play. Game modes, physics, and other rules are not set by the game developers or some central authority. The community, with server configurations, is supposed to do that. It's just that ever since "special game modes" were introduced, not many have.

If you change fortress' settings, then you'll have to change sumo's settings too, otherwise there is no uniformity.

Why do you need uniformity? Uniformity bad. There used to be more creativity in this game before "special game modes."


2. There are a lot of misconceptions about what rubber is and what it does. I'll just quote some of them mostly chronologically. But I want to preface by pointing out that rubber is not meant to be a gameplay feature or mechanic—meaning you shouldn't lament the loss of gameplay mechanics that are lost by reducing rubber, as they were an abuse and exploit in the first place. It is meant to compensate for lag—something Concord mentioned in his first post, but then later dismissed, which I found odd.

I also want to point out that rubber is not a single setting, despite there being that one HUD bit. Rather, there are several rubber settings, all of which work in concert to varying results, and are furthermore affected by non-rubber settings, such as speed. While a few people made posts that showed some of the other rubber settings, I'm betting most looking still don't realize or understand that. So, to commence with the quoting. Developers do correct me if I get anything grossly incorrect.

Rubber is illogical. Rubber comes into effect when you hit a wall, but if you are in contact with it, how can you get closer to it?

Because you're not actually contacting the wall at that point. To now quote myself from an earlier thread: Rubber isn't a shield. And it doesn't produce seals (like a gasket or something). In the "old days" people didn't use terms like "digging" or grinding "deeper." They referred to making a very close grind. The reason being, rubber's purpose is to stop and slow you before you actually make contact with a wall. Now, most of the time this isn't visible; it happens on an infinitesimal visual scale. You think you've touched the nose of your cycle (the model of which is entirely cosmetic, by the way; it's really just a singular point) to a wall and laid your wall up against it, but as far as the code is concerned, you haven't actually made contact. The more rubber you use, the closer you get. Once rubber runs out, you'll actually contact the wall. Contact is immediate death, just like GLTron.

If you want to see this in action, set CYCLE_RUBBER_MINDISTANCE to something like 0.5. You'll see how it stops you cold before making contact with the wall.

Then, set CYCLE_RUBBER to something ridiculous like 100, and CYCLE_RUBBER_MINDISTANCE_RESERVOIR to 2. You'll see how, after MINDISTANCE stops you, you'll slowly move toward the wall as your rubber gets used up. That's what's always happening, just on a much smaller scale.

That said, yes, this is one of those situations where what makes sense to a programmer doesn't make sense from a design standpoint. This game has programmers, not designers. You can do things with the settings to try to reduce that visual effect (as I have tried to do, which Concord has in the past shat on), but it's almost impossible to eliminate without setting rubber values to 0. Which would be a bad idea since rubber is so integrated into the code, such as how it handles latency. It causes all kinds of problems. That said...

We need lots of rubber for lag!

No, you don't. You need only enough rubber to compensate for latency, no more. That does not include being able to turn against a wall you're already grinding (e.g., "double grinding"); that's an abuse of the settings that shouldn't be allowed in the first place.

It does include a setting like CYCLE_PING_RUBBER, which will basically add a little more rubber to those who have higher pings. I don't know what it is in the typical Fortress clone. I have, however, seen it set too high in some servers to where higher-pinged players have an advantage in the closeness of their grinds.

It does include balancing rubber against speed. However, that's only if CYCLE_RUBBER_TIMEBASED is set to 0. If that's the case, then rubber usage is distance-based. This means that when you "hit" a wall, rubber usage is determined by how far you would have gone had that wall not been there. Obviously, the faster you're going, the farther you would have gone, so rubber gets used faster. That is the original and still the most common setting.

But what it also means is that the 5 rubber in the typical Fortress clone is not the same as 5 rubber in a server with different speed. In a slower server it would feel like more, and in a faster server it would feel like less. Rubber is not a universal value when _TIMEBASED is set to 0, and in most cases it is.

On the other hand, if that value is set to 1, then rubber consumption is determined solely by how long you're "contacting" that wall, regardless of your speed. The value for CYCLE_RUBBER becomes a timer, in essence. In this case, there's really no reason to increase rubber to match speed. Indeed, with that set to 1, I would never set basic _RUBBER above 1.

Then there's CYCLE_RUBBER_TIME, which determines the speed at which rubber recovers after a grind. This operates independently of _TIMEBASED.

A typical Fortress server uses a base CYCLE_RUBBER of 5, with _TIMEBASED set to 0, and _TIME set to 10. That means that rubber has to be balanced against speed, which has a base of 30. Personally, with that combination, I'm not awfully bothered by it being 5, although I would enact CYCLE_RUBBER_DELAY to prevent 180's and adjusts against walls. Also, brakes for weaks.

But the other major point is the speed. Fortress servers are set to what I consider a rather high speed. Higher speed is going to cause more problems with lag (so does higher rubber, but in a different, buggier way, like "instas"). Speed is relative to distance and time. What would be more effective than raising rubber in reducing problems with overseas lag would be to scale down the speed, and along with it the size of the arena, zones, and wall length—and rubber. You might also want to experiment with slightly increasing CYCLE_PING_RUBBER and slightly decreasing _RUBBER_TIME to satisfy overseas complaints.


As an aside, my personal favored rubber combo is _RUBBER 1, _TIMEBASED 1, and _TIME being something like 0.3 (which is as low as I can make it without it doing broken things, like never 'sploding), as Gene noted. That takes speed out of the rubber equation, and minimizes rubber as a gameplay mechanic. Also, CYCLE_RUBBER_DELAY 1 and _DELAY_BONUS [something, I forget] to eliminate adjusts and 180 grinds. I've also found that overseas players don't have abnormally disadvantageous rubber-related lag issues in my servers with those settings, despite a low CYCLE_PING_RUBBER (may even be 1).

5 rubber means I can try to outdig someone, or dig harder to get out of something

Putting aside my disdain for the word "dig" and the misconception about rubber that it creates, you can do those things whatever the rubber value is. It's always relative. Where I quoted myself above—that was in response to my answering someone who said "what do you mean there's no such thing as closed?" If there's a wall there, you can get behind it. Whether the rubber value is 1 or 50, if the player who laid down the grind got 80% closeness on his grind, you can always go to 85%, or 95%. Closeness is a proportion relative to a given rubber value; it's not a constant, universal value that stands irrespective of the rubber value. Dig?

Plus, [lowering rubber] might upvalue "open play", if it's misinterpreted.

That has some truth to it, but in a twisted sort of way. It's true that you hear "open" players in their spitting bile say, "if you want to seal go to a high rubber server, noob." Trouble is, they're almost always in high rubber servers when they say that (shit, high rubber is pretty much all that's left). That Dogfight server is high rubber. Way high, especially when you consider the other physics settings. So, there's really nothing you can do about that so long as the general Arma population has this completely out-of-whack concept of what constitutes "high rubber."

low-rubber servers like Mud Puddle (5 rubber)

Perfect example of a few points I've made. First of all, it shows that rubber isn't universal because there are several settings that factor into its behavior. Typical Fortress has a value of 5 as well, but is the rubber behavior the same? You know it's not even close. Why? Because Mud Puddle also has _TIMEBASED 1. That means you use the same amount of rubber on a grind no matter how fast you're going. And it has _TIME 5, meaning rubber recovers twice as fast as on a typical Fortress server. Moreover, it has a much smaller CYCLE_DELAY, meaning adjusts or doublebind turns are faster and tighter, meaning adjusts or 180s against a wall consume much, much less rubber. There's also the matter of its short walls, which in combination with all that, make surviving smaller boxes imminently easier, especially with crutches.

So, that server is totally a high rubber server in its behavior. It's not even close. For another comparison, Yellow Submarine has 15 rubber, but because _TIMEBASED is 0 and _SPEED is 35, despite _TIME being a little lower at 4, rubber is, on average, consumed much more quickly on that server. In effect, Yellow Sub actually has effectively lower rubber than Mud Puddle. It's still totally a high rubber server, though.

Which is the other point that comment is an example of: The utterly twisted concept people these days have of what constitutes high or low rubber.

The distance you get closer to a wall depends NOT on how much rubber you use but rather on the amount of time you spend digging into the wall. This is not well-known among the community, because it goes against intuition.

Doh! Wrong on two levels. One, rubber usage is exactly what determines your closeness to the wall. (So does _MINDISTANCE and a couple others, but that's the initial slowdown.) Secondly, what I said about _TIMEBASED. In a typical Fortress server it has nothing to do with time. I hope you're not spreading this around.

a brand new player is more likely to stick with a game if the game mechanics are intuitive. Therefore, we should reduce the presence of rubber in the game.

With this I totally agree. That's what I've tried to do in my servers. There's nothing at all intuitive about being able to sit on a wall for any amount of time, or 180 against it. Sadly, rubber and the abusive/exploitative gameplay it produces has only increased over time. The community isn't going to go reverse course on that, only the developers have the power to do so, and they ain't gonna—despite their, and Z-Man's specifically, position against high rubber. "Open source" philosophy, I guess. And after all, also because of that, even if they did do something about it, the bulk of the "community" would leave and make a fork or branch or whatever with all the rubber. It's a lost cause.

Change sumo rubber to the same settings then please. I want it to be equal.

I refer to section one. Your comment doesn't make any sense.

And cycle_turn_delay half of what it is in current fortress config.

No such setting. It's CYCLE_DELAY. I don't know what you think that would accomplish, though. It would make for tighter multibind turns (something I totally oppose), and would make adjusts and 180s more effective by using less rubber, as I described above.

Also, I believe there is a setting (cycle_rubber_timebased or something?) that dictates whether the distance you are from the wall is determined by rubber used or the time spent grinding against it.

To reiterate:

1) _TIMEBASED decides whether rubber usage is determined by speed (and would-be distance traveled) or time. A value of 0 in the first case (default, old way), or 1 in the latter.
2) Rubber usage equals closeness to a wall, regardless of the value of _TIMEBASED.

I don't know what you mean by the grinding bit. Rubber isn't used when grinding against a wall, if you mean when you're running parallel to it.

Ok, I put up a server, hosted in Virginia, USA for you guys to test this in. It is called "Low Rubber Fortress". Currently it is running current Ladle settings with only the following 2 changes.

Code: Select all

CYCLE_RUBBER_SPEED 60

What do you believe you're accomplishing with that one? Some people assume that has something to do with cycle speed; it doesn't.

I'd opt for slightly stronger/more brakes and acceleration and less base speed instead, I actually tried that and it works and it makes it more tense than no rubber.

More brakes and less speed, with the same rubber value, means more effective rubber. Also, no one has suggested no rubber.

actually, driving parallel to walls is what creates acceleration. rubber does get you slightly closer to walls, but this creates very very minimal increased acceleration.

Eh, kinda sorta, but not really. You're right on the first sentence (despite its lack of capitalization, you rebel, you), of course.* But on the second, it's CYCLE_WALL_NEAR that determines at what distance to a wall acceleration kicks in. Surely you've all noticed that you can catch acceleration off a wall without actually grinding it. Now, once you make a grind, sure, if you use 80% of your rubber instead of 30% you might get a little more acceleration, especially if _WALL_NEAR is set to something really low (which in a typical Fortress server, it isn't), but it's negligible.

* I don't think vov was claiming that there was claiming that acceleration was derived from rubber, however. I think he was making the point I made earlier: Higher speed usually requires higher rubber to compensate.

lag's effect on gameplay is marginal. lag kills you when you are trying to outgrind 3.5 at the same frequency it kills you when you try to outgrind 0.5.

The following to both sides of this argument: That's not the point. It's not about outgrinding. It's about the player's client not thinking they've yet hit a wall, but the server saying they have. Rubber is meant to make up the difference between the player seeing "I'm not even close to hitting that wall, so I'm not going to turn yet" and the server saying "oh no, you already passed it, dude; die now." That was the original intention of rubber, not about beating grinds or doing fancy "tricks" or other nonsense. And it's a real, inescapable problem that has to be dealt with somehow. That's why 0 rubber (even 0.n) is unworkable with this game. People with higher pings will get the message too late that their cycle has already crossed that wall. Which, again, is further exasperated as speed goes up.

Again, to Concord, if this is a negotiation (which it probably should be if you want anyone to come to your side), you should at least offer to try increasing CYCLE_PING_RUBBER a tad, possibly decreasing _RUBBER_TIME, in compensation for lowering rubber.

Whatever settings are currently going on in the low rubber server is whack (imo). Turns feel really weird.

That makes no sense, unless someone changed settings related to turning. Rubber has nothing to do with turns.

Code: Select all

CYCLE_RUBBER_DELAY 0.0
CYCLE_RUBBER_DELAY_BONUS 0.5

There's no point setting _BONUS to anything if _RUBBER_DELAY is set to 0.

[LOVER$BOY]

After three minutes

Phytotron, bro... I have new respect for you man!

Sorry that I'm a slow reader but anyway, read through it all and your points are on the mark, mind blowing AND correct!

So far as I know, there is no rule suggesting we "stick" with the current modes. I for one disagree. We should experiment, come up with new modes and modes that give us the fun, thrills and enjoyment. After all, this is a game played by many for thrills and nothing more (except idiots who love to expose bugs in servers).

Alpha Project is all about experiments. Take a look at Happy Fun Time or the Last One Standing which is combination of CTF, High Rubber and Death Match modes in one. I like the "proper" modes which I prefer to call them but I got somewhat bored by the "normality" and started experimenting.

Action and reaction, ebb and flow, trial and error, change - this is the rhythm of living. Out of our over-confidence, fear; out of our fear, clearer vision, fresh hope. And out of hope, progress.

So, let's get our gear together and go exploring through the puzzle, crack the codes and bring out a new formula that everyone enjoys!

Edit:
Wanted to use the quote

The urge to make things better has always driven progress and then that is what brings about happiness.

but didn't know if that would be taken wrongly.

[Vogue]

I don't know why this has to be so difficult. You don't need to change the ladle settings. A test tournament? **** that, create an entire new tournament with low rubber and see how it goes. If people prefer it over ladle, the change will happen gradually and we'll abandon "ladle" for lower rubber.

Just do it.

[Z-Man]

Excelent post there, just a couple of corrections/additions:

It does include balancing rubber against speed. However, that's only if CYCLE_RUBBER_TIMEBASED is set to 0. If that's the case, then rubber usage is distance-based. This means that when you "hit" a wall, rubber usage is determined by how far you would have gone had that wall not been there. Obviously, the faster you're going, the farther you would have gone, so rubber gets used faster. That is the original and still the most common setting.

But what it also means is that the 5 rubber in the typical Fortress clone is not the same as 5 rubber in a server with different speed. In a slower server it would feel like more, and in a faster server it would feel like less. Rubber is not a universal value when _TIMEBASED is set to 0, and in most cases it is.

On the other hand, if that value is set to 1, then rubber consumption is determined solely by how long you're "contacting" that wall, regardless of your speed. The value for CYCLE_RUBBER becomes a timer, in essence. In this case, there's really no reason to increase rubber to match speed. Indeed, with that set to 1, I would never set basic _RUBBER above 1.

Even with CYCLE_RUBBER_TIMEBASED set to 1, you still need to adapt the rubber value to the basic speed to maintain the gameplay feel. The reason for that is that with TIMEBASED 0, rubber obviously has the same unit of measure as lengths. If rubber usage really just depended on time with TIMEBASED 1, it would have the unit of measure of, well, time. And since arbitrary in-between (and, in fact, out of bounds) values of TIMEBASED are allowed, that would give CYCLE_RUBBER a floating dimension, which is something one should usually avoid. Hence, with TIMEBASED 1, rubber usage is determined by the time, multiplied by the cycle's base, default speed. Same with the corresponding setting for CYCLE_DELAY.

The distance you get closer to a wall depends NOT on how much rubber you use but rather on the amount of time you spend digging into the wall. This is not well-known among the community, because it goes against intuition.

Doh! Wrong on two levels. One, rubber usage is exactly what determines your closeness to the wall. (So does _MINDISTANCE and a couple others, but that's the initial slowdown.) Secondly, what I said about _TIMEBASED. In a typical Fortress server it has nothing to do with time. I hope you're not spreading this around.

Nope, the inner quote is entirely correct. When rubber is doing its thing, your distance to the wall goes as WARNING MATH exp(-CYLCE_RUBBER_SPEED*(t-t_0)), END MATH with t being the current time, t_0 some offset depending on initial conditions (which weakly depend on a lot of things, but for the most part are just the time you would have hit the wall at plus some fixed offset). Purely depends on the timing. That's why you can dig deeper if you hit the brake or don't go as fast to begin with (when CYCLE_RUBBER_TIMEBASED is < 1): you have more time then before your rubber is used up.

It's about the player's client not thinking they've yet hit a wall, but the server saying they have. Rubber is meant to make up the difference between the player seeing "I'm not even close to hitting that wall, so I'm not going to turn yet" and the server saying "oh no, you already passed it, dude; die now."

No, that is what local prediction is for. The client always shows your cycle in the position you would turn at if you hit that key right now, no matter what your ping is. Only very early versions did not have that. The lag-compensating part of rubber is aimed at latency variations, at the cases where the predictions just turn out to be wrong for some reason. You are right insofar as rubber precedes prediction, IIRC, though back then the player was supposed to compensate for the constant bit of latency in his head, just like in Quake 1 (not Quake World).
And by now, we even have the LAG_CREDIT family of settings dealing with latency variations. Crank them up if you want to avoid slides. That adds cheating potential because it essentially makes the server believe the client if it says "dude, like, I know it's late, but I totally turned there two seconds ago. k, bro?". I probably should increase the default values for those.

Note: Regardless of original intent, I have accepted Rubber as Gameplay. If it is kept in sensible bounds.

Note 2: On diversity vs. uniformity: Surprisingly, both are important. We have all those settings so a diverse landscape of servers can develop (and so we don't have to spend ages ourselves balancing the bloody things), but for competetive play, you want uniform, standard settings. That is why the shooter e-sport people still play Counterstrike, the old one, instead of COD. COD changes every year, CS stayed the same. That makes it possible to train very specifically. It can be very hard to get used to new settings, especially considering everything rubber-related happens on this essentially invisible scale. There is value in going to a server, not knowing what will expect you there, but there is also value in going to a server, knowing exactly what will expect you there.
(Thinking this further, of course there could be a "random settings" tournament where there is a rotation of different variations; being able to adapt to new settings quicky is a skill you can compete on as well. Wasn't there a CTWF tournament?)

Note 3: I resent the notion that any game setting is "easy" or "for wusses". All settings apply for all players. If you have a bajillion rubbers and it is night impossible to die, that also means your enemies are night impossible to kill. After adjusting to the settings, you're not fighting them, you're fighting the other players.

Note 4: I do not resent the notion that there are stupid game settings.

Final note, on the original topic of this thread: I VEHEMENTLY DON'T CARE. I run my tournament server with whatever you guys like. Nothing holy about the original settings.

[ppotter]

Also, I believe there is a setting (cycle_rubber_timebased or something?) that dictates whether the distance you are from the wall is determined by rubber used or the time spent grinding against it.

To reiterate:

1) _TIMEBASED decides whether rubber usage is determined by speed (and would-be distance traveled) or time. A value of 0 in the first case (default, old way), or 1 in the latter.
2) Rubber usage equals closeness to a wall, regardless of the value of _TIMEBASED.

I don't know what you mean by the grinding bit. Rubber isn't used when grinding against a wall, if you mean when you're running parallel to it.

Grinding, digging, whatever you want to call it. The time spent with your nose pointing into the wall.

[Jonathan]

Even with CYCLE_RUBBER_TIMEBASED set to 1, you still need to adapt the rubber value to the basic speed to maintain the gameplay feel. The reason for that is that with TIMEBASED 0, rubber obviously has the same unit of measure as lengths. If rubber usage really just depended on time with TIMEBASED 1, it would have the unit of measure of, well, time. And since arbitrary in-between (and, in fact, out of bounds) values of TIMEBASED are allowed, that would give CYCLE_RUBBER a floating dimension, which is something one should usually avoid. Hence, with TIMEBASED 1, rubber usage is determined by the time, multiplied by the cycle's base, default speed. Same with the corresponding setting for CYCLE_DELAY.

It wouldn't be as bad if it were expressed differently. If you recompose the settings into time cost and distance cost — their more physical constituents — they are more intuitive and seemingly more robust. Or so I think. It would definitely teach people to keep TIMEBASED in [0, 1] (i.e. to keep the time and distance costs non-negative).

Edit: Z-Man said something below that shows TIMEBASED is not what I think it is. The correct procedure for me is: shut up, look at the code, and only then contemplate saying anything.

It's about the player's client not thinking they've yet hit a wall, but the server saying they have. Rubber is meant to make up the difference between the player seeing "I'm not even close to hitting that wall, so I'm not going to turn yet" and the server saying "oh no, you already passed it, dude; die now."

No, that is what local prediction is for. The client always shows your cycle in the position you would turn at if you hit that key right now, no matter what your ping is. Only very early versions did not have that. The lag-compensating part of rubber is aimed at latency variations, at the cases where the predictions just turn out to be wrong for some reason. You are right insofar as rubber precedes prediction, IIRC, though back then the player was supposed to compensate for the constant bit of latency in his head, just like in Quake 1 (not Quake World).

Depends on where that wall came from. If there is a wall because your opponent turned in front of you, (ping) rubber can compensate for the lag somewhat by allowing more time to dodge. Not that you will be in good shape in that case, but it's a lot better than instant death. It allows HPBs to play more aggressively without having to take unacceptable risks. Conversely, the HPB can seem immortal from the LPB's perspective, and can get deeper grinds. It isn't perfect, but you can tweak it so the game is fairly balanced overall, perhaps biased depending on whom you want to accommodate.

Note 3: I resent the notion that any game setting is "easy" or "for wusses". All settings apply for all players. If you have a bajillion rubbers and it is night impossible to die, that also means your enemies are night impossible to kill. After adjusting to the settings, you're not fighting them, you're fighting the other players.

In other words, it's a pillow fight to the death!

[Phytotron]

Eh, I could'a swore I was basically repeating (paraphrasing) Z-Man's own description from long ago with the "the wall's up there; no, it already passed" bit. Hrm.


Something else I forgot to mention/ask. I noticed that most, if not all, the objections that cited lag seemed to be coming from Europeans. But, aren't there Fortress servers on both side of the Atlantic? It goes without saying that when Americans play in a Euro server, the lag roles are reversed. So it's not exactly an unleveled playing field. In fact, haven't the Euro Fortress servers been some of the most active?

Then, with respect to the Ladle, assuming teams are often of mixed continents, do you guys nonetheless try to sort the maximum number of players onto servers on their own continents? Or, something I'm sure you don't do but possibly should: Alternate all US, all Euro servers from one month to the next. Like "home and home" sports scheduling. But I guess that also depend on availability.

That has the potential to digress slightly, but still related to that line of objection.

[sinewav]

Then, with respect to the Ladle, assuming teams are often of mixed continents, do you guys nonetheless try to sort the maximum number of players onto servers on their own continents?

Yes, that is a consideration many teams think about.

But I guess that also depend on availability.

That, and it's nearly impossible to field a team with 6 equally good EU players are US to substitute.

[Titanoboa]

Or, something I'm sure you don't do but possibly should: Alternate all US, all Euro servers from one month to the next. Like "home and home" sports scheduling. But I guess that also depend on availability.

We alternate the final's server between US and EU every month. For all the other rounds, half the servers are US and half are EU. In addition, the backup servers are always opposite of the main server's location, so if both teams prefer the other, they can agree to switch.

[Phytotron]

So, basically, you all do whatever you can to level the playing field with respect to overseas lag. That being the case, there's no particular reason that Europeans should get special consideration when talking about rubber vs. lag, right? That is, of course, unless Americans find that they have equivalent unreasonable lag hurdles in a Euro server. When I say "unreasonable" I mean "rubber isn't sufficient to compensate for latency; and you can't even do a basic grind." It doesn't mean "OMG i cant do my trix!"

Hence, with TIMEBASED 1, rubber usage is determined by the time, multiplied by the cycle's base, default speed.

Are you referring here to the static value of CYCLE_SPEED, or the varying value of a given cycle's speed at a given moment (as in, after acceleration has been applied)?

[ppotter]

Whatever the settings are in "Low Rubber TronZero Sumobar", they don't really change the gameplay, much less benefit it. The refill means it's much easier to tunnel, and rubber in general is more forgiving (as long as your connection/game is stable), however it does prevent you from 180ing in a tunnel, so +1 for that, since that was one of your objectives. However it does make rubber more redundant, it's purpose is a safety net against latency, yet any small slide, get too near someone with a larger ping and it's just instant death if they happen you turn towards you. At the moment it feels like the settings have the opposite effect they were intended to have.

That's not to say they couldn't be an improvement on the current settings without some tweaks. Perhaps a higher value for your rubber, 3 perhaps, but a reduce the rate of refill quite a lot.

[Z-Man]

Hence, with TIMEBASED 1, rubber usage is determined by the time, multiplied by the cycle's base, default speed.

Are you referring here to the static value of CYCLE_SPEED, or the varying value of a given cycle's speed at a given moment (as in, after acceleration has been applied)?

The static setting value. Warning, math again: the forula for rubber usage speed when you are really close to the wall* is ((actual cycle speed)^(1-CYCLE_RUBBER_TIMEBASED)) * (CYCLE_SPEED^CYCLE_RUBBER_TIMEBASED), ^ denoting exponetiation.

*: it's slightly reduced proportionally while you are getting slowed down by rubber before you hit the wall. Not really a relevant amout.

[LOVER$BOY]

Hence, with TIMEBASED 1, rubber usage is determined by the time, multiplied by the cycle's base, default speed.

Are you referring here to the static value of CYCLE_SPEED, or the varying value of a given cycle's speed at a given moment (as in, after acceleration has been applied)?

The static setting value. Warning, math again: the forula for rubber usage speed when you are really close to the wall* is ((actual cycle speed)^(1-CYCLE_RUBBER_TIMEBASED)) * (CYCLE_SPEED^CYCLE_RUBBER_TIMEBASED), ^ denoting exponetiation.

*: it's slightly reduced proportionally while you are getting slowed down by rubber before you hit the wall. Not really a relevant amout.

Yes, I noticed that function within the code. Drove me insane for a few days before I consulted my textbook and understood it.

[Z-Man]

It and many other things rubber-related would have been a lot easier to implement and understand if rubber worked like the brake: values between 0 and 1, settings influence the rates of change. And of course if hitting a wall would decrease the numeric value.