(Note: this is a different bug to that seen on some segments where the time gap to an entire group leaps between two different values, as seen on the “bridge” in france map etc)
New bug (or one I’ve not seen before today. Watopia. Group event (fondo). IpadOS latest version and Zwift latest version 1.32.0 (106182)
The time gaps between riders were impossible/inconsistent, with the time gaps to some riders who were further ahead LESS than the time gaps to riders who I was closer to catching. Just not possible unless there is a black hole. I didn’t manage to screenshot all instances but sometimes it was massively wrong by 15-30 seconds.
In the instance I did manage to screenshot, the rider time gaps were:
As I say, just not possible
(Ignore masking for anonymisation of riders, and zoom to show issue more clearly, I can provide unedited screenshots if needed)
It has always been like that (or at least since 2019 anyway). The gaps are dada anyway, but this is indeed a good way of highlighting how imprecise they are.
The problem here is that the order of the list and the individual riders’ time gaps are refreshed independently and individually, so you might have taken your screenshot at a moment where the gap to the group in front of you was changing from 22 to 28/29 seconds or vice versa and it had only updated some of the riders’ times. That is, probably everybody listed in front of you (except the one you’re drafting) was riding in the one and the same group, and even the listed order was probably correct at some point in the preceding second or three. The fact that the gaps can vary so much from one moment to another make them rather useless.
A certain competitor indicates the gaps as distances instead (and they don’t do silly things like this). Well, I guess in a sense Zwift does that as well, since the gaps are really distance gaps at a constant speed (30 km/h iirc). I would prefer actual time gaps, but at least distance gaps given as distances are less misleading.
Oh, and apparently distances for the gaps seem to be measured as the crow flies at least in some of the worlds, which together with a strange logic of deciding if someone is in front of you or behind leads to entertaining situations like riders making massive jumps from in front of you to behind you and/or vice versa when for instance navigating the sections with several hairpin turns after each other.
The other possible issue is that the concept of a time gap is not clearly defined even in principle. Distance is certain: the distance between two points at an instant in time is easily defined and measured. But what does a time gap even mean? Is it the time since the first rider passed the point that the second rider is now at, or an estimate of when the second rider might be expected to reach the position that the first rider currently is? In this case, how do you estimate the speed that the second rider might travel at? There might be a hill or a descent to come.
It’s surprising how consistent the times are on things like the TTTs. There’s often a second or two of variation (for two teams that are obviously travelling at similar pace), rarely more.
Thanks Anna, that’s really useful insight as always, you seem to really understand what goes on in the Zwift code! Its disappointing to hear yet again that not only has the bug been around forever without being fixed but its based on so many flawed concepts (distance as crow flies, constant assumed speed etc etc). Its like Zwift is just built on one bad decision after another, no wonder they can’t fix simple things, it sounds a complete mess!
I agree with both you and James too - distance rather than time would be a lot more useful and accurate, and surely simpler too since it involves one (poorly done!) calculation less. They must have the code/logic for that already, because you get distance left on route, distance left to end of event banner, etc etc
Unless you can tell the future, it’s of course the former: how long ago the first rider was at the position where the second rider is now. (In pre-GPS-tracker IRL racing, the commissaire behind the lead rider would announce some landmark at their present location on the race radio and start a stopwatch, with the time gaps determined when the other commissaires reach the same landmark.)
The good thing about actual time gaps is that they don’t change depending on the terrain unless the riders’ relative pacing changes, it’s the distance gaps that move around a lot depending on whether there is a climb or a descent between the two riders. If a time gap is decreasing, the second rider is catching up, but a distance gap decreasing might just mean the lead rider has hit a climb and the second rider is still on the flat or descent.
Hah, yeah, spend enough time with the software (and software QA in general) and somehow you can’t help but end up in a cycle that goes something like this:
- That makes no sense
- That only makes sense if [something bonkers]
- Oh well, they are never going to fix it anyway
- Move on