Tour des paves 22h bug

[Pokemon Club]

Hello, the race stop km 88

[flockmastoR]

Hello, the race stop km 88

Any more details is welcome. I think there were experienced managers around but I didn't see any hint on how it was resolved.

The trigger of this bug is low energy riders being in tempo on (high?) Pave km. Please spread this when the game is stuck on pave.

[Hansa]

Hello, the race stop km 88

Any more details is welcome. I think there were experienced managers around but I didn't see any hint on how it was resolved.

The trigger of this bug is low energy riders being in tempo on (high?) Pave km. Please spread this when the game is stuck on pave.

On 19h same bug on same km we fixed it with taking both guys in tempo out of tempo both had pretty low power.

[flockmastoR]

Hello, the race stop km 88

Any more details is welcome. I think there were experienced managers around but I didn't see any hint on how it was resolved.

The trigger of this bug is low energy riders being in tempo on (high?) Pave km. Please spread this when the game is stuck on pave.

On 19h same bug on same km we fixed it with taking both guys in tempo out of tempo both had pretty low power.

Yes I am aware of it. I think I found the spot that triggered it and also a similar one where Alk already did a "fix" (I write "fix" because the general logic of the tempo on pave is not explainable and Alks fix is just avoiding that crash without really understanding how the logic should be). As long as the reimplementation of the engine is not done, I will try to upload that second fix spot tomorrow before the last stages of pave.

issue#29

[Hansa]

Hello, the race stop km 88

Any more details is welcome. I think there were experienced managers around but I didn't see any hint on how it was resolved.

The trigger of this bug is low energy riders being in tempo on (high?) Pave km. Please spread this when the game is stuck on pave.

On 19h same bug on same km we fixed it with taking both guys in tempo out of tempo both had pretty low power.

Yes I am aware of it. I think I found the spot that triggered it and also a similar one where Alk already did a "fix" (I write "fix" because the general logic of the tempo on pave is not explainable and Alks fix is just avoiding that crash without really understanding how the logic should be). As long as the reimplementation of the engine is not done, I will try to upload that second fix spot tomorrow before the last stages of pave.

issue#29

Maybe better to load it in after pave tour and then test it in a couple one day races? Just for the chance your fix breaks something else?

[flockmastoR]

You might be right. But I guess then we will have to wait for 2027 for a real test of it

[Radunion]

You might be right. But I guess then we will have to wait for 2027 for a real test of it

You probably get a real test at Andes.

[NBeullens]

You might be right. But I guess then we will have to wait for 2027 for a real test of it

You probably get a real test at Andes.

There are not that many high cobble kilometres in Andes, 1km of 4 stars, some of 3 stars (stage 3 and more importantly the top of Pico Campanario) and the others are 2 and 1 star

[Radunion]

If I remember correctly, the super-steep pave kms were a risk as well. Plus, with autotempo there may be no quick fix if it happens.

[Pokemon Club]

Maybe we can put a very hard cobblestone fantasy just to test it

[NBeullens]

If I remember correctly, the super-steep pave kms were a risk as well. Plus, with autotempo there may be no quick fix if it happens.

Today could be a potential chance then? 18% 4 star is way more than anything in andes, most i think was 17 3 star in andes but ofcourse i don't know if riders on that km will be low energy, i doubt it for today

[Robyklebt]

(I write "fix" because the general logic of the tempo on pave is not explainable and Alks fix is just avoiding that crash without really understanding how the logic should be)

It's maybe not explainable from a programming point of view. From a logic one yes, it has to do with the 'minimum tempo', the tempo riders have when they are rolling. And bugs occur when the tempo a rider does is slower than this 'rolling minimum'.

[flockmastoR]

(I write "fix" because the general logic of the tempo on pave is not explainable and Alks fix is just avoiding that crash without really understanding how the logic should be)

It's maybe not explainable from a programming point of view. From a logic one yes, it has to do with the 'minimum tempo', the tempo riders have when they are rolling. And bugs occur when the tempo a rider does is slower than this 'rolling minimum'.

sure it is, but in special cases it leads to negative values which from a logic point of view make no sense. Thats why in combinations it can sum up to 0 which causes the crash (at least my local reproduction of the stage tells me exactly that). It makes it even harder, as those paramters are set and changed at a lot of different places (and Alk fixed one, I think I found the condition with heavy rain that leads to a different section to set this parameter).

From a numerical point of view the calculation is not stable by design. Even if the logic behind SHOULD not allow it to happen (I mean the thinking behind it)

[Robyklebt]

Makes no sense talking to me about programming, it's like talking to BW about the sprint mechanics... won't penetrate the thick skull.

Negative value means slower than rolling I guess? Which in the game is slower than you can ride? Blah, forget it.

Anyway more important: implementation!
Invest time!
That means do what should have been done in the previous fix. The downhill bug, where if the leaders were in tempo and when slow enough, all groups behind got faster, some sort of weird cascade when riders NOT in tempo then sometimes overtook or at the very least caught groups ahead that were in tempo. Due to the overly slow tempo in front, (calculated first?) no-tempo became faster than tempo (by stronger riders) in downhill pavé. Bug solved, problem is we still can't design -3 or more with pavé. Because now the siebing is minutes at times there. While it was fine before, just that escapers with low energy kept creating that bug. And there were suspected changes in siebing behaviour in slight - km too, -1**, -2** etc. (add as many stars as you want). Suspected but seems pretty sure it happened, too many people noticed it. And possibly also in 0 with high pavé, which possibly became less selective, but this one it might be more imaginary than real.

So this time: To make sure you know what actually changes besides the bug being gone: Do offline tests before implementing. As you say the code seems mysterious, one change here seems to affect the whole calculation, first check what changes, how it changes.
Just create a bunch of different riders and check what happens on 0* to 0*****, on 1* to 1***** 2* to 2***** etc, minus too, different riders, low energy in tempo, everybody at 1000, siebs and attacks, all that cool stuff, check on the current version and the fixed version to compare. See who the 88 and 85.5 pavé guy drops in 1 km at ***** in the current version, if it's the same in the new one, see if the influence of the flat value changes, etc. etc. And then see, if there are changes, if those changes are bearable, ok, even good possibly. if suddenly 75 pavé guys are dropped on 0** it's bad, if on the other hand they stay on at 0***** it's bad too.

[flockmastoR]

Makes no sense talking to me about programming, it's like talking to BW about the sprint mechanics... won't penetrate the thick skull.

Negative value means slower than rolling I guess? Which in the game is slower than you can ride? Blah, forget it.

Anyway more important: implementation!
Invest time!
That means do what should have been done in the previous fix. The downhill bug, where if the leaders were in tempo and when slow enough, all groups behind got faster, some sort of weird cascade when riders NOT in tempo then sometimes overtook or at the very least caught groups ahead that were in tempo. Due to the overly slow tempo in front, (calculated first?) no-tempo became faster than tempo (by stronger riders) in downhill pavé. Bug solved, problem is we still can't design -3 or more with pavé. Because now the siebing is minutes at times there. While it was fine before, just that escapers with low energy kept creating that bug. And there were suspected changes in siebing behaviour in slight - km too, -1**, -2** etc. (add as many stars as you want). Suspected but seems pretty sure it happened, too many people noticed it. And possibly also in 0 with high pavé, which possibly became less selective, but this one it might be more imaginary than real.

So this time: To make sure you know what actually changes besides the bug being gone: Do offline tests before implementing. As you say the code seems mysterious, one change here seems to affect the whole calculation, first check what changes, how it changes.
Just create a bunch of different riders and check what happens on 0* to 0*****, on 1* to 1***** 2* to 2***** etc, minus too, different riders, low energy in tempo, everybody at 1000, siebs and attacks, all that cool stuff, check on the current version and the fixed version to compare. See who the 88 and 85.5 pavé guy drops in 1 km at ***** in the current version, if it's the same in the new one, see if the influence of the flat value changes, etc. etc. And then see, if there are changes, if those changes are bearable, ok, even good possibly. if suddenly 75 pavé guys are dropped on 0** it's bad, if on the other hand they stay on at 0***** it's bad too.

I am fully in line with Alkworld here to not do cosmetic surgery on a terminally ill patient, I am just trying to stop it from crashing atm and Alk told you a while ago his pathway to reimplement the engine. Agree that this needs offline testing but the testing infrastructure for it is currently not available (alk did some calculation scripts already in game that is intended to at least see the calculation influence of different parameters). What it needs from my perspective is a way to re-run the calculation of a race/a race sequence/some km from the database or completely making up meaningfull race situations and then see the influence of certain actions during that race sequence.

I think this could help in the development of a new race engine like
1) Simulate the race situation (given the start positions, energy) and the actions of each rider (click data from the database) with the current race engine
2) Plug in the "new" race engine and rerun the simulation
3) Compare the results

The replay you can see in-game is not what I mean, but it can help to create these race situations in reverse engineering. We know now about the energy of each rider at the start and the energy of each rider at the end of each race, we know when a rider was put in tempo or out of tempo or attack etc. What we don't know is random effects like a) exact km change which makes a difference in if a rider was in tempo or not at the km change, weather conditions which affect the energy consumption and speed of riders and groups, position in final sprint, and stuff I might forget.

My intention currrently is to reproduce certain known bugs with it and just verify where it fails by simulating through the km and compare it with a planned fix. First results look promissing as I was able to reproduce the behavior of the 22h TdP stage with it. I also found another bug by looking for a thing I always thought it is a display bug but could turn out to be a logic one.
Its far from a varified tool and in order to really use it for testing it would need to run on the server itself making it available for admins and maybe even testers.

[Robyklebt]

Unnecessarily long and detailed, have you eaten Donkey meat lately?

All I'm saying, don't put something online without knowing if there are major negative unintended changes. Like with the previous one, the major negative change was that downhill was now crazy siebs, so in the end we are in the same position as before, we can't design downhill pavé but also some other things changed a bit.