New setting in b0_2_8: DOUBLEBIND_TIME

[dlh]

Ok—kinda off-topic but check out freecycle. Post a WANTED ad and browse through the offers, you will find something.

Edit: Here is Austin's group.

[Phytotron]

On topic then off topic I go.

First, after thinking I think I want to ammend my comment. It's not necessarily the db'ing in and of itself with which I have a big problem -- it can make for more fun and interesting close, one-on-one battles. It's really just one tactic with which I personally have a problem, in particular. I'm not entirely clear on what the specific jargon for it is -- when a player makes a long tail, 180s, and then 180s back onto/into it, often multiple times, for the purpose of building up a lot of speed. That's what I'd like to see rectified, but I dunno how.

Secondly, nemo, neato site. These days there are too many instances of people buying something new, keeping it for a short time, trashing it, then buying something new again to replace it. Wasteful. (Of course, some of that is due to the ol' planned obsolescence, but still.) So that site's a nice idea, especially since you can get strangers involved. Frugality is a virtue.

[Luke-Jr]

Ok—kinda off-topic but check out freecycle.

Ugh. Freecycle is so poorly setup. It would do much better with an item-based forum or such.

[Z-Man]

Oszilloscope: I'm afraid the input subsystem, where this setting resides, has no possible way of discerning "good" and "bad" uses of dbing by any definition. It's either allow all or disalow all.

awww slow down z-man! I still haven't managed to test all those other nice new rubber settings yet!

If in doubt, leave it at zero.

Ok, so what's the possibility this can be tweaked to prevent the 180ing but still allow reasonable double-binding? I'm guessing its a good possiblity and it'll work out.

I'm afraid that's not possible. This option can leave all forms of dbing enabled or it can disable them all (with the given time threshold). 180ing against walls for camping (putting yourself into a position where you cannot get (easily) killed) needs to be combatted by making consecutive 180s deadly (with RUBBER_DELAY and a sufficiently large value of CYCLE_DELAY). I80ing for speed (aka building slingshots, what Oscilloscope does not like and I admit is kind of a lame tactic) can't be combated with the current arsenal if you don't want to make 180s against walls deadly. Suggested future settings against slingshots would be
- a separate acceleration factor for your own and your teammates' walls. If your own walls don't accelerate you, a slingshot is useless. This setting would have other tactical implications, probably interesting ones.
- CYCLE_RUBBER_DELAY_BRAKE: if I hit a wall during the CYCLE_RUBBER_DELAY time, I get slowed down by this deceleration. This reeks of special case coding; why should rubber not slow you down in general?

Hmmm, what's the possibility I can get a setting to dither this from the wall, similar to how CYCLE_WALL_NEAR affects acceleration? I wouldn't object if it was CYCLE_WALL_NEAR that did it, neither.

I completely fail to understand what you mean here by "dither". What effect on cycle_delay do you propose?

[Lucifer]

Ok, so what's the possibility this can be tweaked to prevent the 180ing but still allow reasonable double-binding? I'm guessing its a good possiblity and it'll work out.

I'm afraid that's not possible. This option can leave all forms of dbing enabled or it can disable them all (with the given time threshold).

? Sometimes you db in sequence, sometimes at the same time. For example, to do a proper 180 on the wall on older servers, you have to hit the keys in sequence. Otherwise you bounce. But to turn around and make those cool little towers we like to make, you hit both keys at the same time. So it seems like there could be a setting where you could allow 180s within a certain range. Slow 180s, where db is used to aid maneuvering, might still be possible at certain settings, while the fast 180s that are used as a crutch might be disabled. It's all about how far apart you want to allow the keys to be hit.

The reason CYCLE_DELAY wasn't able to solve this problem is because it was too general. It was like dropping an atomic bomb trying to get a kidnapper.

Hmmm, what's the possibility I can get a setting to dither this from the wall, similar to how CYCLE_WALL_NEAR affects acceleration? I wouldn't object if it was CYCLE_WALL_NEAR that did it, neither.

I completely fail to understand what you mean here by "dither". What effect on cycle_delay do you propose?

So let's say I set it at a harsh 0.1, and set it to 1 meter dither. At 1 meter its effect would be multiiplied by 0.001. At 90 centimeters, 0.005, or whatever, until when I'm at 1 cm from the wall it's a full blown 0.1, just like my harsh setting.

[TiTnAsS]

Austin texas, and about 2 feet by 4 feet would do me.

The table I have is one of those big folding tables that seats 6, 3 on each side. If I put that in my bedroom, I won't be able to go to the bathroom without climbing over the bed, and in the middle of the night that bed's occupied by a woman and a small boy.

So, I have the desk the computer in there is on right now, which is the server that currently runs Breakfasts in Hell. But I need to move *that* piece of furniture into the living room where I can put the other computer I built, you know, so my kids can use it. (My two older kids are at the age when I really need to make sure there's a computer available to them) After I do that, there's no place left in my bedroom to put my server. If there's no place for my existing server, there certainly isn't a place for a second server. So that's where I'm at.

I have another table in the living room that's a perfect size that I'm considering moving in there, but I have misgivings about that. I use it to work, I put my laptop on it. And after school starts, it's a perfect place to do homework, beats the hell out of the dining room table, you know?

I will probably wind up doing that last one anyway. It's the best of the bad choices available right now.

Itll work until another small table comes your way that you can put in the tables place that your gonna move...

[Z-Man]

Sometimes you db in sequence, sometimes at the same time. For example, to do a proper 180 on the wall on older servers, you have to hit the keys in sequence. Otherwise you bounce. But to turn around and make those cool little towers we like to make, you hit both keys at the same time. So it seems like there could be a setting where you could allow 180s within a certain range. Slow 180s, where db is used to aid maneuvering, might still be possible at certain settings, while the fast 180s that are used as a crutch might be disabled. It's all about how far apart you want to allow the keys to be hit.

Ah. Setting DOUBLEBIND_TIME to a very small positive value (0.001) would eliminate exactly simultaneous (during the same frame) keypresses only. Some of them, those that don't make it to be exactly simultaneous, will make it through, though. We can't read the user's mind just yet

The reason CYCLE_DELAY wasn't able to solve this problem is because it was too general. It was like dropping an atomic bomb trying to get a kidnapper.

Then it's good there's a difference between CYCLE_DELAY and DOUBLEBIND_TIME: the doublebind detection will drop the second keypress. We can add another option so that a too-fast doublebind will work as a moderately fast normal double keypress, somehow dropping user input does not seem all too nice...

Hmmm, what's the possibility I can get a setting to dither this from the wall, similar to how CYCLE_WALL_NEAR affects acceleration? I wouldn't object if it was CYCLE_WALL_NEAR that did it, neither.

I completely fail to understand what you mean here by "dither". What effect on cycle_delay do you propose?

So let's say I set it at a harsh 0.1, and set it to 1 meter dither. At 1 meter its effect would be multiiplied by 0.001. At 90 centimeters, 0.005, or whatever, until when I'm at 1 cm from the wall it's a full blown 0.1, just like my harsh setting.

That would be possible, but it would affect close combat as well and slow down your turns unpredictably. Your client does not yet know where your enemy really is now, and if CYCLE_DELAY is affected by walls, it will matter.

[Lucifer]

Ah. Setting DOUBLEBIND_TIME to a very small positive value (0.001) would eliminate exactly simultaneous (during the same frame) keypresses only. Some of them, those that don't make it to be exactly simultaneous, will make it through, though. We can't read the user's mind just yet

No, but we're getting there.

Then it's good there's a difference between CYCLE_DELAY and DOUBLEBIND_TIME: the doublebind detection will drop the second keypress.

Yeah. I realize the first couple of responses to this were negative, but I thought it was wonderful after only reading a few words.

We can add another option so that a too-fast doublebind will work as a moderately fast normal double keypress, somehow dropping user input does not seem all too nice...

I don't know, it would be mildly entertaining to drop both keypresses. You know, randomly even. My psych teacher told us that operant conditioning works best when the reward is applied only some of the time, but regularly enough to reinforce the behavior.

That would be possible, but it would affect close combat as well and slow down your turns unpredictably. Your client does not yet know where your enemy really is now, and if CYCLE_DELAY is affected by walls, it will matter.

We could have it that way near rim walls and obstacle walls, though. We know where those are. It's not a big deal for me, I just thought it would be neat to throw on top of it.

[llaffer2]

I love it. I've always thought that DB'ing was a bug and the correct fix is to have the clients unable to map two keys to the same function to eliminate it completely.

It is still nice to know that I can shut it off DBing on my server, but the problem is that few will.

The servers of today rely on DBing, high speed, high rubber. Add high ping in there, and it's a coin flip if you win or lose.

I like the servers from last year and the year before that .. slower, more methodical, took skill to win, not dumb luck. Even at higher pings.

[Z-Man]

We can add another option so that a too-fast doublebind will work as a moderately fast normal double keypress, somehow dropping user input does not seem all too nice...

I don't know, it would be mildly entertaining to drop both keypresses. You know, randomly even. My psych teacher told us that operant conditioning works best when the reward is applied only some of the time, but regularly enough to reinforce the behavior.

Heh, yes, that would be funny. Unfortunately quite impractical as well, because at the time the double bind is detected, the first keypress has already been processed.
My main concern with ignoring user input in some cases is the false positive detection. I guess it can happen that you hit your two double bound keys at once in error when you tried to hit them in sequence. By making the reaction less draconic (but still draconic enough to make simultaneous keypresses useless as a planned action), we could get what we want without too much collateral damage.

llaffer2: Yes, high rubber on real game servers is bugging me, too. It was never meant to be set so high you actually notice it even exists.

[Lucifer]

llaffer2: Yes, high rubber on real game servers is bugging me, too. It was never meant to be set so high you actually notice it even exists.

Well, if there's anything I learned being a mechanic, it's that tools are rarely used exactly as designed. I've got a big wrench, box end on both sides, one sides 24mm and the other side's 26mm, and I've used it to beat off rotors, as a breaker bar on a smaller wrench, a few other things. I've also used it to loosen and tighten 24mm bolts and nuts. And if I ever have to warranty it and the guy says "Nope, you've used it as a hammer", I'll have his entrails on the counter.

(ok, maybe not that dramatic, but I've seen the implied threat of physical violence get a few tools warrantied that "corporate policy" said shouldn't have been)

[Jonathan]

My main concern with ignoring user input in some cases is the false positive detection. I guess it can happen that you hit your two double bound keys at once in error when you tried to hit them in sequence.

Take into account that the chance of hitting both in one frame is 1/fps.

[Phytotron]

llaffer2: Yes, high rubber on real game servers is bugging me, too. It was never meant to be set so high you actually notice it even exists.

Well, if you really wanted to piss some people off (and amuse others), you could write something into the code that doesn't allow it to be set above a certain value.

[Jonathan]

llaffer2: Yes, high rubber on real game servers is bugging me, too. It was never meant to be set so high you actually notice it even exists.

Well, if you really wanted to piss some people off (and amuse others), you could write something into the code that doesn't allow it to be set above a certain value.

Like 0xff800000 interpreted as float?

[gss]

I think it is a mistake to allow a user to configure multi-binds and then have servers 'drop' mulit-bound keypresses.

If you don't want to allow multi-binds, it shouldn't be configurable in the client. Since older clients allow it though, I don't see how you can remove it.

I would suggest a better solution is to allow single-bound keypresses to react as quickly as multi-bound ones. I've never understood why pressing one key twice causes a slower reaction than two keys pressed in sequence. If all keypresses reacted the same way, everybody could turn equally fast, single or multi-bound.

Of course... I have been looking for something to convince me to stop playing this game all the time! If servers use this new setting, I'll have found it!