There’s been a lot of chatter in the past two days as Zwifters have hopped into the Pace Partner groups only to discover the bots’ paces are different than usual.
We initially covered this topic yesterday, explaining that the bots had stopped drafting. At that time, based on a message we had seen from Zwift support, we assumed the lack of drafting was done on purpose. But that wasn’t actually the case! On top of all that, more updates have come in since yesterday’s changes, with some Pace Partners reverting back to their old drafting paces, while others remain slow (non-drafting).
Not long after I was alerted to this forum post, I received the following from Kristy Fulwider, Director of Marketing Communications at Zwift:
Hi Eric –
Hope you’re having a lovely Friday.
I wanted to follow up on something you noted in ZwiftInsider this week re: Pace Partners. We’re also putting a forum post up for the community, and wanted to make sure we shared some of the more technical elements with you at the same time.
As you noticed, Pace Partner paces were slower than usual for roughly a day. We were in the process of transitioning Pace Partners from client emulation to server entity emulation, a move that would eventually transition Pace Partners out of our experimental FutureWorks program. This change created unforeseen inconsistencies in drafting which impacted pace, and as parity was the goal, we reverted them back.
We’ll continue to work on this transition with an eye on consistency. We remain excited about what this change means: a path towards Pace Partners in worlds other than Watopia and equally important, a reduction in Pace Partner downtime.
Have a fantastic weekend.
Kristy
Client to Server Emulation
The most interesting part of Kristy’s message is her statement about moving Pace Partners from “client emulation to server entity emulation”. For the less nerdy among us, here’s what those terms mean in Zwiftland:
- Client emulation: Zwift is running on a device just like you or I use for Zwift (the “client”), but the power and cadence data is being “faked” by software instead of created by someone’s legs. This is how Zwift Insider’s speed testing bots work – and how every bot on Zwift works. A normal Zwift install, reading in computer-generated data. This is how Zwift’s Pace Partners currently work – somewhere (we assume in a Zwift developer’s house, since Zwift’s offices are essentially closed), there are four PCs running Zwift reading in emulated cadence+power data. If one of those machines crashes, so does the Pace Partner. You get the idea.
- Server entity emulation: the Pacer Bots are no longer running on separate Zwift devices – rather, they are “generated” by Zwift’s servers and controlled entirely by code. (Think the blue ghosts of early Zwift days, which rode around on course with behavior automatically controlled by server code.)
Moving to server-based Pace Partners makes it much easier to spin up additional bots, with little increase in maintenance or other costs. Instead of requiring a developer to set up an entirely new computer (which could crash at any time), a new server-side Pace Partner would simply require another entry into a database table. And since Zwift’s servers are redundant and cloud-based, reliability should be rock-solid, provided the code behind everything is stable.
Next-Level Opportunities
Moving Pace Partners to the server-side is an essential step in order for Zwift to implement many of the cooler features which we’ve talked about for months. These ideas are listed and discussed on our main Pace Partners page, but here’s a quick list:
- Roll Your Own: being able to spin up a Pace Partner with whatever specs you desire
- Change of Pace: having Pace Partners change their pace in smart ways – like bumping it up on climbs, and decreasing it on descents
- Smart Messaging: sending smarter messages to nearby riders, instead of just reading through the script like they do currently
- More Options: having more Pace Partners available at various paces
All four of these ideas are much more doable using server-side emulation. In fact, I would say #1 is impossible unless the Pace Partners are server-side, and numbers 2-4 are made much much easier when implemented server-side.
A Good Sign
At the time of this posting, C. Cadence was still rolling without a draft, meaning her group was around 5kph slower than normal. Hopefully Zwift will get her fixed up soon.
But those are just growing pains. In the bigger picture, it’s clear Zwift is investing some work into taking Pace Partners to the next level – and that’s exciting! I’m looking forward to the server-side rollout happening soon, so Zwift can begin to grant Pace Partners more magical powers.
Your Thoughts
Share your thoughts below!
Hooray~ – looks like they are taking the user feedback and scaling this up to make it a practical long-term feature.
Yay! Sanity prevails…
However,let’s PLEASE not vary the bots pace on climbs and descents. This would make it harder for heavier riders, who suffer on climbs but don’t get much benefit on flats and descents.
Let’s keep them at a steady w/kg pace regardless of the percent grade.
Yep, and importantly, this is why I love pace partners. I want a steady wkg requirement so that I don’t go too hard on my ride. This is why I do my rides with pace partners over “group rides” where you join a ride and then the rider leader throws in power increases on the hills, totally ruining your expected workout.
Except that increasing power on hills is more realistic. When riding alone in Zwift, I always find i increase power on hills. Same on hills in real life.
The other side being that it feels very unnatural to push the same watts uphill and downhill. But there could be bots who react to the gradient and bots who don’t 😉
This is very exciting! I’m looking forward to this change. I can see some major drawbacks with user spawned Pace Partners – form server load issues to ‘cluttering’ and dehumanization of the Zwift world.
I look forward to the future when the Pace Partners are in the worlds that have the UCI courses (Innsbruck, Richmond, Yorkshire). I hope they will also add mountain courses also for the climbers using a Pace Partner (Innsbruck mountain climb CCW, France, Watopia Mountain 8). Its nice to see development.
Yeah I can definitely see the attraction of having a Pace Bot for say Alpe or Ven Top climbs since judging pace for new riders in particular can be really tough
getting to pick your own watts/kg will be best solution!
“You own w/kg”. Once of the attractive things about pace partners are riding in a large group, where you can focus on staying in someone’s draft and let the distance fly. For your very own w/kg you can just use the ERG mode. I also regularly do that if i want a very steady ride. But i like to keep my mind busy with the hustle of a group, even trough the effort will vary a bit more.
Ref “somewhere (we assume in a Zwift developer’s house, since Zwift’s offices are essentially closed), there are four PCs running Zwift reading in emulated cadence+power data.” Really? I thought Zwift was hosted in a cloud (AWS?) That doesn’t sound very “DevSecOps” if it’s in some gal’s garage. Am I misunderstanding what your wrote?.
Yes, you’re misunderstanding what I wrote. 😀
The Pace Partners were (are) running on client emulators (presumably in someone’s house as a FutureWorks project, thanks to Covid). That’s a completely different thing than Zwift’s servers, which run on Amazon’s cloud.
Why wouldn’t Zwift just spin up 4 (or more) ‘desktop machines” on AWS for testing? That would be more reliable than running something in someone’s house.
That may be what Zwift is doing. Eric is guessing at what might be happening.
great news and i like the variation of pace on the climbs. I found that when rolling with D that Dan got dropped and then it was a case of everyone sitting up. Naturally you push more watts going up a climb so this makes total sense and should even out the pace and create a smoother ride experience.
“reliability should be rock-solid, provided the code behind everything is stable” Hahahahah. Are you new around here?
This is a major improvement – it should limit or stop the many times the bots (notably C. Cadence) just disappears and reappears out of nowhere. Code-based should solve this. Looking forward to pace partners in other worlds, too. They should have a bot (that only you can see) that starts at every KOM and represents your PR, so you can pace with it.
Agree! Having a bot setting pace using your KOM PR would be a great addition.
A personal route PR bot would be great to race against your previous best each lap. Been asking for this for for years not convinced that it will come
The question I would have on that is … what would the PR bot do? I love the idea, but if it was implemented as a steady pace or wkg to match the time of your PR that would also be unrealistic and probably useless on some routes. Ideally you would want it to match your own personal changes in watts and pace as you progressed through the PR ride.
We should throw a party for the Pace Partners! Looks like they are finally graduating from FutureWorks!
It would be nice to have your own personal train of bots, Imagine 5 personalized locomotives dragging you around Watopia, yum.
Is it just me, or would it not have been a far better approach to leave the existing 4 Pace Bots running as they are and add in a new additional Server Side Pace Bot so that if it works properly then woohoo, but if it doesn’t you don’t muck up what’s already running and working (at the admittedly limited way it currently is)
…especially given Zwift’s track record of, well, pretty much not ever getting things coded properly first time!
Is it possible that behind this lies also a subtle shift of (some of the) power and draft processing for all riders to the server? That might also explain why a number of people are reporting slightly greater lags or different feels in response when they change pedalling power or move in or out of a bunch recently. I noticed a number of comments over last week, starting around the same time, in the TTT and ZRL teams about the recovery in the pack after a pull at the front not being as much as normal.
From what Zwift has told me, no. That’s all staying client-side.
This might be a way to provide people with the ability to race against their own best time for a course. That’s something people have been requesting for ages.
Why does it matter how fast you go? Unless the goal is to ride an unrealistic speed on an unrealistically smooth road. Power is power, intensity is intensity, speed is conditional.
Being able to create a pace partner to my specs is something I’m definitely looking forward to. I can see it being the next step in interval training, if you can program the bot to to an interval session. that way you could turn the bot loose on the workout and you just follow it, adjusting power to keep pace with the bot rather than Erg mode keeping you at the specified power. Much more realistic in that you’re having to adjust your effort, shifting, etc. on the fly.
This explains everything — bots have been a user-level hack, without even access to some sort of API to determine course details or proximity to other bots or even distance traveled. They’re completely blind (“blind as a bot?”), simply generating a dumb power stream and generating a repeating series of clever witticisms.
Seems like they are back up to speed this week. Coco about 24.6 to 25 mph average every day this week
The sooner they have something between 1.5 (D) and 2.5 (C) the better. Amazed that they may really care what customers are saying, what a novel idea.