Was there a need in general to implement this fix? Or then decide not to roll it back once the issue become apperant?
There was an exploit (read, broken code) that allowed users to do a U-Turn and pick up a badge they potentially have not earned - Was that a big enough issue to cause this amount of problems for the rest of zwift users?
Its a virtual badge, there is no benefit from it - Why not just make a process to remove a badge at the request of the user.
Seems an awful lot of work and fall out, for an issue that wasnt a ‘major’ issue to start with.
I was wondering in other topic is it possible to fix 1.18 bugs with older 1.17 version file. If Zwift is taken backup for that file, is it possible to take copy for that and rename it for example version 1.18.2 and release that as a repair update. Could it be work that way and fix 1.18 bugs ?.
It’s been a week and “you are still working on it”…very poor, makes me question if you are really working on it, or just one junior developer looking at it. Until it affects a big voice or a boss like Eric… we have to live with it…?
Forget working on it, remove what you did and push out an update with it gone, simple… yes I work in IT and we’d never get away with our users waiting a week for fixing something we introduced, we’d rip it out asap…or rollback…we’d have a plan in the Change Board for rollback…it would take matter of hours not a week and counting…
I don’t do many group rides or routes for badges, ride with mates, so for me I can pick a route I have no intention of riding and go off in another direction and forget about it… but there are plenty of others it is impacting now and the many thousands that don’t even know yet about it yet, but will at some time experience this and get really annoyed when it happens to them… any probably post here.
Nothing I’ve seen suggests this is feasible, let alone simple. Which isn’t intended as a defence of Zwift, more a realistic observation based on issues like this that have been repeatedly seen in the past.
I do assume it’s feasible - the release notes talk about something they have done on the U-turn logic to prevent an exploit that grants reverse courses badges in certain conditions. Simply restoring the U-turn logic to its pre-change version would remove the new bug, albeit by re-enabling the exploit (which potentially exists since years).
It’s more that the very reason things like this happen so regularly (‘fix’ or change something = break something else) seems to be that the code in the background is a total mess. So whilst it may seem simple to just undo the changes and assume it’ll go back to how it was before, the overwhelming evidence is that working with the code just isn’t that straightforward.
Hey Zwift -
I’ve noticed quite a lot of in-game riders going 24 kph. This bug affects a lot of your users. The point is that these kinds of bugs are not preventable but a thoughtful change to the game will go a long way to not causing so much stress.
Here is a suggestion :
Consider a notice at logon that tells users about known issues they should be aware of ?
Zwift Weather ( or whatever )
This would have a before-and-while-game-playing-visible popup with the ability to send the text to your email and copy it and also is a must click to remove lifespan
In this case it would say something close to this :
If you complete any route you will be not be able to do a U-turn. After you complete any route and try to perform a U-Turn you will limited to 24kph and will only be able to make turns randomly for the rest of your Zwift session until you quit Zwift and logon again.
If users like to use u-turn i wouldn’t mind if Zwift release a update where u-turn is disabled/removed until Zwift find how to make it work again and release that on a next update where is more bug fixes.
All this talk about spaghetti code and code in general has nothing to do with this , why are we making up reasons on behalf of zwift to not address the problem we want addressing .
If anything the reason they could not easily rollback this feature is if they are not using a fit for purpose code version control methodology that supports release branching and feature branching . It is just not feaisible for a product as big as zwift to not be at least doing something like this as we would get a ■■■■ of a lot more issues like the ones we get each month trust me .
If they are , then rolling back a single feature ( which it was) is trivial.
The only reason therefore to not do it is because they are not listening to users who are asking for it , and realising how much back blood this is creating …
I guess the reason why many talk about spaghetti code is the nature of the bugs and the way fixes are done. Let’s take this case with what is known. There’s an exploit by which one can do a U-turn after passing the finish banner of a route and collect the banner for the reverse route with minimal riding. Zwift developers get the task to close the loophole.
The obvious solution: modify the badge recognition function so there are no conditions where not riding the route awards the badge.
The Zwift solution: disable U-turns under conditions that appear to be those of the exploit.
The actual solution: Suspend the U-turn under conditions that appear to be those of the exploit.
What do you think will now happen? Modifications to the U-turn suspend modifications.
Net result: the root of the exploit remains, the bad solution gets even more complicated. In 3 months, someone will need to do some modifications on anything that’s underneath the growing list of conditions under which U-turns will be disabled and/or suspended, and watch it all fall apart again.
That’s collateral damage. As Zwift have confirmed, if a U-turn is suspended, the speed limit sets in, and turn controls are disabled - this explains the behavior seen by many users. Once you terminate a ride and start a new one, clearly the suspend terminates, and the suspended U-turn then gets performed. Not stellar coding either mind you - whoever coded a reset of the U-turn suspension didn’t realize that this reset may happen at the beginning of a new ride, and thus trigger an out-of-nowhere U-turn.
All this for nothing - the actual initial bug is not that the user performs a U-turn under certain conditions, it’s that performing that U-turn confuses the route completion logic. Fix the route completion logic and leave the U-turns alone…
This really sucks. I know y’all did this on purpose to keep people honest on route badges, but you’ve really screwed it up. Today was a horrible ride for 3 hours. Tried to ride the flats w/Cadence and then tried to U turn and of course couldn’t. Then your speed is limited to 24 kph and you have to End ride and get back end. This needs to be fixed quickly as it’s effecting Group rides, Meetups and individual rides.
Patience, my butt. That’s way too long. This really effects the enjoyment of rides very negatively. So you mean we get to do this for another month? That’s not reacting the way you should be on such a huge issue.