RSF Cyclingfreaks
http://www.radsportfreaks.de/RSFForum/
http://www.radsportfreaks.de/RSFForum/viewtopic.php?f=5&t=10644
Any more details is welcome. I think there were experienced managers around but I didn't see any hint on how it was resolved.
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 wrote: ↑Thu Oct 29, 2026 9:48 amAny 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.
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.Hansa wrote: ↑Thu Oct 29, 2026 6:51 pmOn 19h same bug on same km we fixed it with taking both guys in tempo out of tempo both had pretty low power.flockmastoR wrote: ↑Thu Oct 29, 2026 9:48 amAny 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.
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 wrote: ↑Thu Oct 29, 2026 7:07 pmYes 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.Hansa wrote: ↑Thu Oct 29, 2026 6:51 pmOn 19h same bug on same km we fixed it with taking both guys in tempo out of tempo both had pretty low power.flockmastoR wrote: ↑Thu Oct 29, 2026 9:48 amAny 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.
issue#29
You probably get a real test at Andes.flockmastoR wrote: ↑Thu Oct 29, 2026 8:36 pmYou might be right. But I guess then we will have to wait for 2027 for a real test of it
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 starRadunion wrote: ↑Thu Oct 29, 2026 9:31 pmYou probably get a real test at Andes.flockmastoR wrote: ↑Thu Oct 29, 2026 8:36 pmYou might be right. But I guess then we will have to wait for 2027 for a real test of it
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
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 wrote: ↑Thu Oct 29, 2026 7:07 pm(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)
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).Robyklebt wrote: ↑Fri Oct 30, 2026 10:08 amIt'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 wrote: ↑Thu Oct 29, 2026 7:07 pm(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)
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.Robyklebt wrote: ↑Fri Oct 30, 2026 11:30 amMakes 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.