Physically, your draft benefit (in absolute watts) should depend both on your speed and the speed of the rider(s) you are drafting. However if you’re riding in a pack I can’t think of a plausible reason why it should be less towards the rear of the pack than towards the front, as everyone is moving at much the same speeds (it won’t be hugely sensitive to small variations). Draft should only drop off when you are off the back of a pack (or part of a very stretched out tail) or right up at the front with only a couple of riders or so to shelter behind.
It’s hard to debug possible problems in secret algorithms based on little more than rider feel though.
Any normal (unavoidable) variation in effort level means that this criterion is frequently achieved for all riders in normal riding. I don’t believe it is a useful criterion to use.
I’ll admit I haven’t focused on this, but if there were progressive acceleration, wouldn’t pace partner speeds get faster and faster as the day went on? Does that happen? I understand there is a complaint about unrealistic pack speeds, but I wonder whether it isn’t just the result of people being willing to put out more effort than would be required just to draft a leader. (About to start a long ride, so maybe I’ll pay more attention this time.)
No this won’t happen the PP ride at prescribed wattage, the only thing that the group can influence is the amount of draft saving by the PP, if they go to fast they will just open a gap and ride on their own. The size of the group will give the PP less draft but only until the maximum draft savings is achieved, I think it is about 20 riders in front of the PP .
Thanks. I was responding to some else’s suggestion that the problem was “progressive acceleration.” My sense is that if everyone in a group holds constant output, then the speed might be faster than IRL because there will be more “churn” than IRL, but that’s not a flaw in Zwift’s basics physics—the problem is either that it is easier to move to the front (since you can just pass through other riders), or that people do not draft like in IRL (perhaps because the don’t want to or they lack the ability or the cues or breaks provided when you ride IRL or Zwift let’s you stay closer to others than most of us would be able to do IRL!). In short, I’m not sure the issue of a fast pack can be addressed without messing with other factors that make Zwift physics realistic (or enjoyable when people aren’t racing).
This is one of Zwift’s biggest flaws and what causes the problem. IRL if you hold the same cadence in the same gear you hold the same speed whether drafting or taking a pull. In Zwift you just go faster. Similarly on gravel in Zwift it’s not any harder to pedal, you just go slower.
Fixing this fixes the pack dynamics problem. Everything else being attempted is a bodge.
But IRL, isn’t it the rider making the decision to draft/reduce power? It isn’t something special about the physics of riding IRL. If you want to stay in the draft in Zwift, you do the same thing, I think.
No. Resistance in real life reduces when you’re in the draft, just like it should increase when you go on a gravel road surface. Neither of these things happen in Zwift. In Zwift to maintain speed in the draft you have to reduce your cadence assuming the same gearing.
Eric just posted his race and I saw something interesting I wanted to point out
at exactly 9:35 his watts flash red when trying to catch back onto the pack
He wasn’t even close to the wheel in front of him
He then has to resurge for it to only happen again after another 10-15 seconds of fighting
because of how he outputs power, it thinks that the autobreaking feature thinks he is “easing” when in reality he just drops his power for 1-2 seconds.
(thinking out loud here)
Power reporting can vary from power source to power source and some have more naturally spiky graphs than others. I wonder how this can be considered when building this autobreak feature. Maybe instead of current power compared to last 10s it could be last 3 second power avg compared to previous Xs power avg.
Also
Maybe included to the conditionals should be some “distance to next closest rider ahead” where the distance has to be less than 2 meters or something
I wouldn’t break IRL if I was 10m behind the last person in a pack I’m desperately trying to grab onto…
Maybe comparing to your most recent X seconds of power output is a bad metric for this sort of thing.
It’s becoming clear that the Zwift guys don’t actually care about user input for this. They’ve decided that braking is their solution and your most recent ten seconds of power is one of the metrics and are going to fiddle with the details indefinitely until it doesn’t feel totally broken.
Zwift lag can be anywhere from almost-zero to three seconds and it often has nothing to do with an individual user’s connection. This is yet another reason why PD4 is doomed to failure in its current form.
I would also say it’s possible that what you see on your screen is not a full and perfect representation of the underlying calculations. Displays are updated periodically, there’s no real way of knowing what is going on under the hood without access to the code.
However we can say for sure that every rider regularly drops their power below the average of their last 10s as a matter of simple logic. So if that is a trigger for autobraking, it’s a rather unhelpful one. Likewise they will intermittently go faster than and slower than the rider immediately in front.
Have we done any tests where the riders are 100% solid? What happens when you cant easily roll through the pack and you bump into the back of other people until you apply enough watts to push them out of the way? would this slow the “churn” or just box in the back?
So with network latency, and slow client machines, one user’s representation of where other riders are located could be different from what another user sees. The rider in the video is pushing to get back on, and then eases off a bit. He seems to be auto-braked by a rider he sees many meters ahead. So it looks like there is a disjoint between what the user sees and the game state that the braking mechanism is using. This could e.g. happen if some calculations/logic are done server-side and others client-side. It seems unlikely, but who knows?
It would be bad if PD4 will work differently depending on how far from the Zwift servers the users are located (network latency).
David can probably explain what happens in the video.
I think that would reduce the churn but also think you are right about it causing boxing. Maybe blocking front and back but allowing sideways pass-through movement would work. Riders who are doing enough power to go faster then those in front first move quickly sideways to the edge of the group to a lane that is kept free for overtaking and so into the draft, think this was James’ idea. Riders who ease-off would have to move quickly to the (other) outside to drop back too or somehow push people behind them sideways before dropping back if in the middle, the latter would mean allowing even more lateral rider overlap which would look worse.
