Next experiment: different turn delays for 180s and adjusts
Moderator: Z-Man
Next experiment: different turn delays for 180s and adjusts
From the next restart on for about 24 hours, another experiment will be running. The cycle turn delay for quick left-right or right-left combos has been reduced to 0.05 seconds, while the turn delay for left-left and right-right combos is still at 0.1 seconds.
Your client thinks the delay for both is 0.05 seconds; so if you execute a left-left turn with a double bind, expect a misprediction and a lag slide. To protect you against that, doublebinding has been restricted for those clients that support it.
Since the delay time has been decreased and is still the same for 180s, double grinding should still work as usual.
This feature is brought to you by Wrtlprnft
One question about it: While looking at the code, I noticed that if you do a left-right-left combination, the time of the first left turn also influences the time of the second left turn if _DOBULEBIND_BONUS is bigger than 2. Is that intended that way?
Your client thinks the delay for both is 0.05 seconds; so if you execute a left-left turn with a double bind, expect a misprediction and a lag slide. To protect you against that, doublebinding has been restricted for those clients that support it.
Since the delay time has been decreased and is still the same for 180s, double grinding should still work as usual.
This feature is brought to you by Wrtlprnft
One question about it: While looking at the code, I noticed that if you do a left-right-left combination, the time of the first left turn also influences the time of the second left turn if _DOBULEBIND_BONUS is bigger than 2. Is that intended that way?
- Jonathan
- A Brave Victim
- Posts: 3391
- Joined: Thu Feb 03, 2005 12:50 am
- Location: Not really lurking anymore
Re: Next experiment: different turn delays for 180s and adju
Is just pressing the same key twice within 0.1 s so extraordinary?
Some content that was edited out: Attached an example of what I can easily do without practice.
No problem, people make mistakes sometimes. But what did you want to say?'Collaborator' wrote:Z-Man apologizes for accidentallty editing instead of quoting. Darn, darn, it's bad enough if it happens with my own posts.
Some content that was edited out: Attached an example of what I can easily do without practice.
- Attachments
-
- singlebind.mp4.gz
- Grid lines are 0.1 s apart with the settings I used.
- (1.68 MiB) Downloaded 430 times
Last edited by Jonathan on Tue Jun 13, 2006 4:28 pm, edited 2 times in total.
- wrtlprnft
- Reverse Outside Corner Grinder
- Posts: 1679
- Joined: Wed Jan 04, 2006 4:42 am
- Location: 0x08048000
- Contact:
Next experiment: different turn delays for 180s and adjusts
Yeah, that's exactly what I intend. After all, if you manage to press left-right-left the two left turns are still only really possible with doublebinding. I think that's the logical solutionz-man wrote:One question about it: While looking at the code, I noticed that if you do a left-right-left combination, the time of the first left turn also influences the time of the second left turn if _DOBULEBIND_BONUS is bigger than 2. Is that intended that way?
(The old code stored the time of the last turn, and I had two choices: Either store the time of the last turn right and the time of the last turn left (which I'm doing right now) or store the time of the last turn and its direction. This would mean left-right-left wouldn't be affected by _DB_BONUS at all.)
There's no place like ::1
-
- Posts: 5
- Joined: Tue Dec 27, 2005 5:55 pm
God. How I hate that change with all my nicotine-craving body. My offense and defense depends on having the left-right/right-left turns at 0.1 seconds. When you have the possibility to be between that and 0.05, I just die. DIE. And I hate dying nearly as much as I hate Vanhayes. Please turn this back as quick as you can so I won't bite my fingers off...................
i only played with the bot for about 2 minutes and i hated it. this change would really only be of any help to the noob's because i think most of the people that play fortress double bind, especially those that do def. and unless you press the left-left with perfect timing, it sometimes wont work and could make you kill teammates........on another note......i think the speed boost of the enemy wall was a good change, sometimes it helped, sometimes it didnt...
i PM you what it is if there isnt a topic for suggestions
i PM you what it is if there isnt a topic for suggestions
- wrtlprnft
- Reverse Outside Corner Grinder
- Posts: 1679
- Joined: Wed Jan 04, 2006 4:42 am
- Location: 0x08048000
- Contact:
Uh, some clearing up for those that don't even bother to read the first post:
This change is NOT about disabling doublebinding. The idea is that while double binding is a bad practice it should still be allowed, but CYCLE_DELAY is there to decrease the advantage double binders get.
But this also affects left-right turns: Those are always different buttons, so there's nothing wrong with pressing them at almost the same time. CYCLE_DELAY applies to both those things with the same impact, making it hard to exactly hit a hole, for example.
That's why I introduced this new setting, it allows you to have different delays for both cases, so you can set the delay for left-right low while giving left-left a higher delay (in this case it was the same as the old setting).
So why did double binding get disabled as a whole? Simple, all released clients don't know about the new setting, so if you were to doublebind without it the client would think it could turn earlier than it actually can, giving you huge lag jumps.
I'd like to declare the outcome of this experiment as void for exactly that reason: barely anyone can make two turns in the same direction within 100ms without doublebinding, therefore the setting wasn't really tested. CYCLE_DELAY 0.05 and DOUBLEBIND_TIME 0.1 would have archieved exactly the same thing, except that it could have been cheated (I bet noone did for a 24-hour test).
Z-man: can you repeat the test a few weeks after 0.2.8.3 is out, then without the DOUBLEBIND_TIME setting, please?
This change is NOT about disabling doublebinding. The idea is that while double binding is a bad practice it should still be allowed, but CYCLE_DELAY is there to decrease the advantage double binders get.
But this also affects left-right turns: Those are always different buttons, so there's nothing wrong with pressing them at almost the same time. CYCLE_DELAY applies to both those things with the same impact, making it hard to exactly hit a hole, for example.
That's why I introduced this new setting, it allows you to have different delays for both cases, so you can set the delay for left-right low while giving left-left a higher delay (in this case it was the same as the old setting).
So why did double binding get disabled as a whole? Simple, all released clients don't know about the new setting, so if you were to doublebind without it the client would think it could turn earlier than it actually can, giving you huge lag jumps.
I'd like to declare the outcome of this experiment as void for exactly that reason: barely anyone can make two turns in the same direction within 100ms without doublebinding, therefore the setting wasn't really tested. CYCLE_DELAY 0.05 and DOUBLEBIND_TIME 0.1 would have archieved exactly the same thing, except that it could have been cheated (I bet noone did for a 24-hour test).
Z-man: can you repeat the test a few weeks after 0.2.8.3 is out, then without the DOUBLEBIND_TIME setting, please?
There's no place like ::1
Yes, this test wasn't about doublebinding. But it also wasn't about anyone liking the change It was a purely technical test, and it worked. Didn't like the change because you lagged more? Sorry, yes, that was because your client doesn't know about it. Didn't like the change because you rely on DBing? Well, now would be a good time to reevaluate the need of DBing on a .1 delay server. And I really can't hear the "This change helps noobs" argument any more.
Anyway, as planned, the experiment will end with the next restart.
Anyway, as planned, the experiment will end with the next restart.