In the TdZ makeup ride I rode today, non-event riders would show up in parts of the map and then disappear in other parts of the map. We did three laps of Greater London Flat, and it seemed that the areas where non-event riders appeared were geographically consistent lap to lap.
Also, perhaps it is the new pack dynamics, but riders in my group would frequently surge forward and back. Quite an unpleasant effect!
what is the point of the known issues section of this forum? A stuff we’re actually working on section would be better or a stuff we actually care about section.
It’s a fair comment. Ten months or so would seem ample time to fix something like this. But on the other hand there are lots of small things that aren’t addressed.
The optimist in me likes to believe it’s because Zwift are reluctant to spend time patching the current engine because behind the scenes they’re hard at work on a new platform based on Unreal engine or Unity.
Same here for my ride (1800Z, London). Non-event riders visible for the first 2–3 km, and after that the riders nearby list stopped working. I’m just getting too old for this zwift.
I’ve said it before – and we’ve no insight into Zwift’s development pipeline – but it seems… unreliable.
My pet theory (I’m full of them), is that because it’s a bespoke engine that started life as a bedroom hobby project (as far as I recall), it’s maybe hard to test reliably. If it’s not designed for unit testing, integration testing, simulation etc. it can be very hard to bolt that stuff on later.
Sometimes, a thing that has worked for years suddenly breaks. The gradient on a part of the course. Uploading images taken with F10 on a PC. Syncing weight from a Withings scale. Whatever, but something that worked. Then broke. You’d expect it to be simple enough to identify what has changed and roll back the relevant change. Even better you’d expect the integration tests etc. to find such problems before hitting production.
It’s another reason I hope that they’re working on that modern engine. Something that is designed with testing from the outset. Something that can reliably be used as a base for new features being rolled out without breaking seemingly unconnected other features.
But again, I’ve no idea. I might be doing Jon Mayfield a huge disservice, and I’m not trying to suggest he’s not a competent developer (or product/tech lead, more so these days I guess). Not at all. I’ve developed plenty of projects for my own use that would never have stood up to widespread use. And I’m not trying to say I could necessarily do better. Even with unit tests and integration tests in my day job, I still sometimes break things. But I don’t develop for a unicorn startup.
I would certainly hope that a reimplementation of the whole engine is in the works, but so far pretty much the only thing that speaks for that being the case is indeed the lack of attention to bugs new and ancient.
You can add me to the “new engine” club. I too have been pinning my hopes on the “writing a new Zwift in the background” thing, since it would explain an awful lot.
