Pavé downhill, solution. Designing/technical ?

[Robyklebt]

It's a continuation from this thread

viewtopic.php?f=5&t=9668

But really think a clearer solution than the final recommendation by Alk/Flock would be useful. And IMO is kind of urgent, real pavé season is coming soon already.

Ah, background: My guess is that something like this happened:
The old downhill bug, -3 or steeper downhill, when groups that weren't riding were stronger than groups that were riding (and it depended on what the first group did anyway, but forgot if they had to ride or not for the bug to happen) was basically the solution to what we have now? Buh or Luques when playing around with the pavé selectivity in climbs and downhill ended up adding this thing that turned out to be a bug.
And now that the bug is corrected, we have the situation that there's weird behaviour in at least downhill pavé, not sure how it affected the climbs or the flat, if at all.

Behaviour now:
-1 with pavé has become more siebable according to Flockmaster (I didn't realize it during the race). Actually IMO that's ok or even good, was always a bit weird that a -1 makes it so hard to sieb, it's not like it is harder in reality, higher speeds, those that are dropped might be dropped by less, but still dropped.
-High downhill with * just supercharged the downhill skill, which of course is completely wrong. Huge differences.

Then lots that we don't know really. What's the effect at -2? -3? -4? etc. What would be the effect of steep downhill not just with * but with ***, or *****?

That's why the advice "no downhill pavé in designs" right now to me is not that satisfactory a solution.

Job for Alk:
1) Find out what effect it has on other downhills, see above. Knowledge! Right now we know little, guess/assume a lot.

Then find a solution.
That can be: Ban all downhill pavé in designs. Ban certain downhill pavés in designs. Or even put the bug back in, then we have downhill pavé unti -2 at least. I realize that a real solution right now is not possible, other things to do for Alk, analyzing the whole pavé thing will take time. But a better solution then this unclear recommendation we have right now IMO is necessary. AND and analysis of what exactly changed after the bug correction, what did it affect?

[flockmastoR]

Ok the stuff you referenced is just concerning very steep downhill+pave.

Additionally there was this discussion: viewtopic.php?f=5&t=7990&p=118554&hilit=1+pave#p118546
which is more concerning as the bug fix shouldn't have an influence on those km (at least as I understood that part of the code)

I think what we need is a discussion about what behaviour we want there. IMO it is not that there is just a small bug that needs to be fixed such that the downhill pave stuff works as expected its more generally. We don't even know how it should work.

So my proposal always was: Go back to the pre bug fix way and allow dowhill with pave until -2.

[Alkworld]

The main problem here is that Buhmann's code for speed, siebing, fighting, etc is really not very well structured and therefore hard to understand the concept behind that. Without understanding it, fixing it properly becomes pretty impossible. My idea is to start a major redesign of the "race physics engine" at some point rather than fixing that mess we have.
And about the bug fix, see above, no idea really what's the impact of it other than no longer crashing.

[Robyklebt]

Ok the stuff you referenced is just concerning very steep downhill+pave.

Additionally there was this discussion: viewtopic.php?f=5&t=7990&p=118554&hilit=1+pave#p118546
which is more concerning as the bug fix shouldn't have an influence on those km (at least as I understood that part of the code)

I think what we need is a discussion about what behaviour we want there. IMO it is not that there is just a small bug that needs to be fixed such that the downhill pave stuff works as expected its more generally. We don't even know how it should work.

So my proposal always was: Go back to the pre bug fix way and allow dowhill with pave until -2.

Not really, I said this:

-1 with pavé has become more siebable according to Flockmaster (I didn't realize it during the race). Actually IMO that's ok or even good, was always a bit weird that a -1 makes it so hard to sieb, it's not like it is harder in reality, higher speeds, those that are dropped might be dropped by less, but still dropped.

Just got it wrong a bit, more siebable than 0 or +1 is not what it should be, more siebable than it was ok, hardest km... no

Unlike you I'm not influenced by any understanding of the code Seeing it wouldn't help either, I still wouldn't understand anything. BUT! To me it seems highly likely that it's the bugfix that influenced that. When did it change? After the bugfix, so seems likely that it's connected to that.
My guess is that the code that produced the bug was some kind of balance thing, balance climb/pavé/downhill. Weakening the influence of downhill. Decreasing the speed in downhills. Decreasing it so much if it was -3 or more not riding was faster than riding. Which then created the bug (so it must have been that it only appeared when the first group was riding, check yourselves, I'm slighly drunk. With that balance thing gone, the balance is off. At least in downhill. Might it have influenced + km as well? Worth checking IMO. Not sure if the Andes were a good laboratory for that, have my doubts. I sort of remember a sieb by Matisse that was much weaker than I expected on a + km. Magnificent 7 it was, checked.. expected the 5**** 4**** combination to be much more selective, Gurruwiwi only dropped at the 4, others ah, JongHun Kim with 48-86 and 73.1 pavé at the time (if I read the training thing correctly) the same, dropped at 4**** after surviving 5****. Maybe can be explained with form? But maybe it's an effect of the bug? We don't really know.

And IMO that's not a good idea without first checking how it works exactly now. See above, the last sentence in green, we don't really know. We need to know (or at least the programmers) what changed, that's why IMO the first step is Alk or Gipfel or you testing. Ideally test with the pre bug fix code as well, if you still have it or can re create it. What changed is only the bug fix and later the too weak-game crashes fix.
Do tests, see how it changed. or just see how it is. Run tests with a bunch of different riders on different terrain. To see the effect of downhill/climb, try with 50/60/70 mountain, same skills otherwise, same with downhill, compare with the old code, if that is gone, go from memory.

THEN decide how to deal with it. Just until -2 is ok, then we somewhat realize during Het Nieuwsblad, or even later, STrade Bianche, that really something like 3*** or 6** seems to behave clearly differently than it did a year ago... too late then. Or -2***** during Paris Roubaix. (Not sure there is that, but there are some +/- in PR too, and with high pavé obviously.)

So research now. I know Alk is working a lot on the game, Gipfel and you too, but IMO this one is pretty important, we don't want the pavé to blow up in our faces next spring. So give it some priority, first with checks, then think what to do. (if the behaviour is very different and clearly not good, then re-introducing the bug might actually be the best solution until Alk has time for a full solution)

Ok, done for now, need to write a bug report, wanted to write more here, but time for a bug report now.

[Robyklebt]

The main problem here is that Buhmann's code for speed, siebing, fighting, etc is really not very well structured and therefore hard to understand the concept behind that. Without understanding it, fixing it properly becomes pretty impossible. My idea is to start a major redesign of the "race physics engine" at some point rather than fixing that mess we have.
And about the bug fix, see above, no idea really what's the impact of it other than no longer crashing.

Oh, before the bug report short answer here.

Yes, understand that now is not the time to redo the whole thing, no pressure on that. Complete redesign sometime in the future, even far future, no problem. In general it works all mostly ok right now from a user point of view. Programmer a mess it seems, ok ok.

But, the effect of the bugfix still should be understood now. Talking about both, but mainly about the first fix, the one that took out the -3 pavé bug, then the second one you did a bit later, the one that made the game crash. (IMO likely that the first fix created the second bug, it's the first fix that probably somewhat disturbed Buhmann's cosmic balance)

[Bear]

Too tired to read everything. But maybe we can use a fantasy offseason race to test the current physics for downhill pave. maybe just a random race with different pave sections and min tact. but short in general. and maybe not pay prize money in this kind of race.

[Robyklebt]

After my very sensible proposal to have the admins do some checks, tests on how pavé works after the pavé fix was rejected , I did my own test in the horribly named pavé race last week. Focus on my riders since I know their settings, energy etc. All had fighting on the whole time.

Result:
On a 0 **** km 50 Magritte siebing 82.7, 4 of my riders in the group, Fortuny, Henri and Blake. Lowest rider in the group, fighting too I suppose, and helped, 75,4. Highest pavé dropped, 80.2, presumably not fighting.

0*** 3 of mine, Blake this time is gone. Fighting the first time around I guess. The 80.2 this time stays, still without fighting.

1***** km 58 Here then Matisse had 26 less energy than the other guy with the same amount of helpers, 1, then 2. The sieb: Stringfellow, 76 pavé stays. He was riding without helper, without being helped in the beginning, then started helping Fortuny or Matisse or maybe Henri, forgot whom. He had less energy than Magritte at this point. 6.7 less pavé, less mountain (+1), but more flat. (Ok, better form) The 2 km non-fighting while others did can't explain why he suddenly manages to stay with Magritte on the hardest km, while he was dropped on softer ones earlier. How much smaller did the energy gap between Matisse and him get in those 8 km? Rather minimal I'd suppose, not the full 26 between Fortuny and Matisse, since Stringfellow was helping for 5 or 6 of those kms.

Analysis: The group at the 1***** was rather huge anyway, some of it might be explained by fighting off/on etc, but still it felt wrong. As did the siebs in my race at Paris-Roubaix on the *****. Something just seems off.

Recommendation:
1) Put the bug back in. There really isn't any advantage of the current system over the old bug-system. No -3 or steeper downhill with pavé. Same rule as then. Disadvantage is that pavé behaviour is weird. I suppose Alk remembers what exactly he changed. Might have changed something further for the race stop thing?
2) If you want to work, then do the offline tests now, test with different riders, different pavé, different altitude gain/loss, bug-system, system now, to see how it differs. That's basically what I proposed when I created this thread... so I'd say go with recommendation 1

[Alkworld]

Recommendation:
1) Put the bug back in. There really isn't any advantage of the current system over the old bug-system. No -3 or steeper downhill with pavé. Same rule as then. Disadvantage is that pavé behaviour is weird. I suppose Alk remembers what exactly he changed. Might have changed something further for the race stop thing?

Putting the bug back has the major disadvantage of the game crashing surprisingly and requiring somebody to fix it.
My suggestion: I continue doing the technical redesign of that stuff in the background, then rewrite the whole unreadable pavé code of Buhmann (will take a while however)

[Robyklebt]

Not the original bug if I remember correctly.

It was a secondary bug after the original bug-fix that created that one. Again, if I remember correctly. Talking about the race stops if some riders are too weak thing, right? Wasn't that fixable by putting tempo in or out anyway? But again, that wasn't part of the original bug

[Alkworld]

Not the original bug if I remember correctly.

It was a secondary bug after the original bug-fix that created that one. Again, if I remember correctly. Talking about the race stops if some riders are too weak thing, right? Wasn't that fixable by putting tempo in or out anyway? But again, that wasn't part of the original bug

Yes, two separate bugs, but with a similar outcome, game calculation stopping. Taking out tempo helped there (I think it was riders with very low energy?), but if the player in question is off, that also still doesn't stop the crash unless an admin does something.

[Quick]

Not the original bug if I remember correctly.

It was a secondary bug after the original bug-fix that created that one. Again, if I remember correctly. Talking about the race stops if some riders are too weak thing, right? Wasn't that fixable by putting tempo in or out anyway? But again, that wasn't part of the original bug

This is still happening btw

[Robyklebt]

My suggestion: I continue doing the technical redesign of that stuff in the background, then rewrite the whole unreadable pavé code of Buhmann (will take a while however)

Well, I think my suggestion is better! See the bolded part. Recreating the old bug should be pretty fast. And then use that until you find the time to rewrite the whole code. As it now just doesn't seem to be like it should be, the ***** pavé aren't working properly IMO. So as provisional solution, the old pavé-downhill bug version better.

That version didn't have game stopping bugs. Those appeared after the debugging. The only bug it had was: On -3 or steeper downhill with pavé, IF the riders in the front were in tempo, riders NOT riding gained time on riders riding. How much depended on energy. But since we have a directive NOT to design races with -3 or steeper pavé with the debug system as well, mostly it should pose 0 problems. And if one slips through once, ok, then we have a buggy race, that's it.

With the system now we have sort of buggy heavy pavé, that doesn't react as it should. (That could be analyzed more precisely in offline tests by developers, but takes time, so just let's assume I'm right (which isn't 100% guaranteed))

Kwick saying the other new bug, that was created by the debugging of the first bug, not sure if that's correct and that it still exists? But if it does, another argument for "go back to the original bug"!

To bring back the former bug... if you still have the old code as it was somewhere, then just put that in. If not, you have to reverse the debugging. The debugging of the no tempo-game stop bug first. Then the debugging of the original bug. Can't find where you wrote that down... maybe was only in the main chat? But sort of remember you saying finding that was easy when you knew what to look for. Some single division by 0 or something in the end was all you undid. Redo it!

[Quick]

Nonono idk what caused what but dead riders in tempo at heavy pave = race stop.

[Gipfelstuermer]

Guys, there were two bugs related to tempo on pavé

1) low-energy-riders in tempo on heavy pavé --> game stop (very very bad)
2) tempo on downhill pavé --> riders jumping to the front of the race (also bad but mangeable not to put -3 or steeper downhill into the races)

Both were related to the same (erroneous) code section (tempo on pavé !). So you could not touch one without the other.

After the fix, we have not had game stops related to low-energy-riders in tempo on heavy pavé as far as I know. There is also no jumping around on -3 or steeper downhill pavé.

But the sieb behavior has been questioned. 1) Has it changed siebs on -1/-2 ? Probably. Have they become stronger/weaker? Community seems unsure about that, which is a sign that the change isn't too extreme. 2) Has it changed siebs on -3 and steeper sections? No clue. I can't remember the time when there was no bug with this. But users mostly did not like the sieb behavior, so designers have mostly agreed to continue not using -3 and steeper downhill. So I think it is a good solution for the moment, until someone (likely Alk) has more time to study this very complex part of the code (took years for someone to find the error).

[Robyklebt]

Guys, there were two bugs related to tempo on pavé

1) low-energy-riders in tempo on heavy pavé --> game stop (very very bad)
2) tempo on downhill pavé --> riders jumping to the front of the race (also bad but mangeable not to put -3 or steeper downhill into the races)

Unless I'm completely wrong:

1) Not before the bug fix (to correct bug 2, so sometimes in late 2023)
2) Only before the bug fix.

Chronology goes something like: Bug 2 there. Bugfix in late summer/autumn 23. Bug 1 appears. Bug 1 then a fix too, I think, although Kwick claims it's still happening. But something was done, maybe didn't eliminate it all? Plus was it for riders in tempo or riders not in tempo?

Of course they are closely related, both have something to do with the "Grundgeschwindigkeit" when not making tempo, which in the case of bug 2 is higher than the tempo by low energy riders, but only on downhills -3 or more. The bug was Buh increasing that in downhills, so that there aren't those huge time losses in downhill pavé siebs that are there now (but since we don't have -3 pavé, we don't experience it. Increase downhill basic speed, it was too fast.

Sieb behaviour: You left out the sieb behaviour on heavy pavé, which is the thing that makes the current situation unsatisfying. And would make just having bug 2 there the better option. And since it shouldn't take too much time to recreate the situation before the bugfix... that's the best option.

[Gipfelstuermer]

No no, 1) came into the game shortly after the introduction of React because the error-catching (on backend side) was made much more strict in order to detect and solve code errors before they cause major bugs. We had game stops for several reasons (one of them being the low-energy-rider-tempo on pavé).

One famous occasion was Paris Roubaix 2023 morning edition. I remember exactly because I was on vacation, Alk was away, had to solve it between morning and afternoon edition, only solved it halfway into the afternoon edition which was running at 60s tact, etc... It happened a few more times before/after that and we were never able to recreate the bug in a test environment, only in the live environment... nevertheless, it never happened again after the bugfix. So the bugfix was successful in preventing these game stops (which are a horror for admins but maybe good to improve the code in the longrun...).