Calculation of selling price

[Robyklebt]

Seems to be a widespread problem.

Quite a few in my team as well.

Interestingly enough, the one rider that should be a reduced purchase, Camille Roy, isn't categorized as one. I get the full prize for him, while in reality I bought him for 74% according to my press center.

[Robyklebt]

Donks has a few more comments:

1) In the "Anleitung" there is no description of the cheapened riders. Or I didn't find it.

2) The calculation seems weird. I'm pretty sure I bought most of my riders at 95%. But none of the ones showing a reduced purchase thing show that at 95%, all much much closer to 100. Oh, not all, Novelli is at 85%. Almirall too. Haven't checked all, but so far found none that is at actually 95%, which is where all of them (or most at the very least) should be (Well shouldn't, but would be if the bug calculated the "reduced purchase" right.

3)Also it seems that the calculation for the sale of the cheapened riders has changed. Can't guarantee that 100%. But at least in 2014 it was like described in this link

http://www.radsportfreaks.de/RSFForum/v ... gte#p80101

Meaning, the value (regarding a sale) can't get over the price you paid for the rider.

The same is written by Manghi in 2022, but I suspect that text was written earlier, just posted in 2022?

Kann ich mit verbilligten Fahrern durch kaufen/verkaufen Geld verdienen?
Grundsätzlich nein. Verbilligte Fahrer (die mehr als 5 % verbilligt sind) steigen nicht mehr im Wert. Man erhält bei einem Verkauf den Einkaufspreis abzüglich der persönlichen Geldsperre. Sollte der Marktwert des Fahrers unter den Einkaufspreis fallen wird der Marktwert genommen.

Now as I mentioned in the Allagen thread, I would have preferred the way it is now... Although it has disadvantages too, now if the rider goes under the value for which you bought him you can basically sell him at his real value, "new" system not, somebody like Longbottom (now checked him too)

Reduced purchase, 69% (of course he was bought at 95%...)
So I get 242'751
Old system (official system?)I'd get the 348'221

I think the system where it's always a percentage simply makes more sense, even with the less money you then get for very old riders.


But this again is a case where something somehow changed, wanted or unwanted doesn't matter, but it should be either corrected (would mean old system back) or officially changed. Unless somebody like Hansa can find a place where it was officially changed.

And the reason it should be made official, or corrected is exactly that. By writing stuff down you get people like Hansa and also me finding stuff, finding how things were at one point in time supposed to be. By just letting stuff be the way it somehow turns out to be, your future selves or your successors won't get that kind of info, simply because it isn't available.

[Rockstar Inc]

Some more data to check for the admins - i got a tax of 26,26%
Every rider in my team seems to be noted as reduced purchase - i bought every rider from the ytm or the regular market as "name geben"

---
Also at least for me interesting my rider Karafiat

Price at the auction: $1,570,519
My Offer: $1,623,567
Value according team-page: $1,595,154
Reduced purchase according rider-page: $1,570,519

[Alkworld]

I know there are some inconsistencies in the prices right now, but there are a few problems why it's so hard to just simply fix it:
- Time: The topic is too complex to just work on it half an hour per day. It would need a developer / data expert to do a real deep dive here. I could give you the relevant data and the old and new code for calculating, but it's a real pain to read and understand.
- Code: In the new code there's one central place for calculation (which is good), in the old code, there have been maybe 20 places, most of them identical, but some definitely not.
- Different calculations: in the old code, there was one for newly created riders, mostly making young riders more expensive, month change was considering current points (included that now in the new code), not sure if there were more. I think I shared the code in some thread a while ago.
- Reduced purchase: The difficulty here is that the data was stored in the same field as market price, and was only updated when it was equal to the market value. As the market value slightly changed, this got out of sync. But at least the original purchase should still be available and for all riders bought the first time (unnamed), it cannot have been a reduced purchase. So it should be possible to mostly fix that.
- Going back to the old system: There is no old system to go back to (old system was PHP5, Flash and lots of old code for a different DB structure), only to imitate the old system. To get there 100% is not always easy.

[flockmastoR]

I know there are some inconsistencies in the prices right now, but there are a few problems why it's so hard to just simply fix it:
- Time: The topic is too complex to just work on it half an hour per day. It would need a developer / data expert to do a real deep dive here. I could give you the relevant data and the old and new code for calculating, but it's a real pain to read and understand.
- Code: In the new code there's one central place for calculation (which is good), in the old code, there have been maybe 20 places, most of them identical, but some definitely not.
- Different calculations: in the old code, there was one for newly created riders, mostly making young riders more expensive, month change was considering current points (included that now in the new code), not sure if there were more. I think I shared the code in some thread a while ago.
- Reduced purchase: The difficulty here is that the data was stored in the same field as market price, and was only updated when it was not equal to the market value. As the market value slightly changed, this got out of sync. But at least the original purchase should still be available and for all riders bought the first time (unnamed), it cannot have been a reduced purchase. So it should be possible to mostly fix that.
- Going back to the old system: There is no old system to go back to (old system was PHP5, Flash and lots of old code for a different DB structure), only to imitate the old system. To get there 100% is not always easy.

Absolutely agree, I did take a look at it after you posted the different code snippets, but it is not really understandable. For me still the greatest issue is the "update" of the price for so many reasons. Couldn't reproduce the market value based on skills/age/points as the value itself is in the calculation. So for my understanding it can be just reproduced when you account for all previous market values?!

You think there is a way for a one function calculation (similar to the training %) that is just triggered once per month but that doesn't rely on the historic market value of the rider? I mean like a "close enough" approximation?

PS: isn't the salary calculated in such a way? Or is the salary also depending on the previous salary + update at month change?

[Alkworld]

- Reduced purchase: The difficulty here is that the data was stored in the same field as market price, and was only updated when it was equal to the market value. As the market value slightly changed, this got out of sync. But at least the original purchase should still be available and for all riders bought the first time (unnamed), it cannot have been a reduced purchase. So it should be possible to mostly fix that.

I think I fixed that now, please check your riders. The regularly bought ones should no longer be shown as reduced riders. It was a consequence of incomplete data cleanup after the wrong calculation in month change (the aforementioned complexity ...)

[Alkworld]

PS: isn't the salary calculated in such a way? Or is the salary also depending on the previous salary + update at month change?

I think not, but it's still pretty weird indeed. It's calculating something, then it does the same calculation again, but uses the first result somehow (that part: ( ((28-25)*100000-((pow((28-21),2.28))))/(3000000/$gehalt)), but the original salary is not used. It seems a bit like the previous salary was used at some point, but I'm not sure either what Buhmann thought here. And

Code: Select all

((28-25)*100000-((pow((28-21),2.28))))

is a very weird way instead of simply writing "299915.5", which is the result of that line.

Full calculation of salary:

Code: Select all

$gehalt = (pow((45 + ($zeit-45) * pow ($berg,2.96)/550000+max($berg,40)+$regeneration/2),3.9) * 200 +
            pow(max($flach,40),4.62)*20 + 
            max(0,pow(max(0, ($pave*0.3+$flach*0.7)-70), 2.1))*60*29000*40 - 
            max(0, (70-($pave*0.3+$flach*0.7))*100*29000*40)  + 
            pow(max($berg,40),5.75)/4 + 
            pow(max($zeit,40),7.28)/3436 + 
            pow(max($sprint,40),6.21)/35 + 
            max(0, ($sprint-45)*100*29000*40) + 
            pow($regeneration,2.3)*300 + 
            pow(max($abfahrt,40),3)*8000)/29000 ;
            
        $gehalt = (pow((45+($zeit-45)*pow($berg,2.96)/550000 + max($berg,40) + $regeneration/2),3.9)*200 + 
            pow(max($flach,40),4.62)*20 + 
            max(0,pow(max(0, ($pave*0.3+$flach*0.7)-70), 2.1))*60*29000*40 - 
            max(0, (70-($pave*0.3+$flach*0.7))*100*29000*40)  + 
            pow(max($berg,40),5.75)/4 + 
            pow(max($zeit,40),7.28)/3436 + 
            pow(max($sprint,40),6.21)/35  + 
            max(0, ($sprint-45)*100*29000*40) +
            pow($regeneration,2.3)*300 + 
            pow(max($abfahrt,40),3)*8000)/29000 -
            ( ((28-25)*100000-((pow((28-21),2.28))))/(3000000/$gehalt) );
            
        return max(round($gehalt / 40), 25000);

[flockmastoR]

PS: isn't the salary calculated in such a way? Or is the salary also depending on the previous salary + update at month change?

I think not, but it's still pretty weird indeed. It's calculating something, then it does the same calculation again, but uses the first result somehow (that part: ( ((28-25)*100000-((pow((28-21),2.28))))/(3000000/$gehalt)), but the original salary is not used. It seems a bit like the previous salary was used at some point, but I'm not sure either what Buhmann thought here. And

Code: Select all

((28-25)*100000-((pow((28-21),2.28))))

is a very weird way instead of simply writing "299915.5", which is the result of that line.

Full calculation of salary:

Code: Select all

$gehalt = (pow((45 + ($zeit-45) * pow ($berg,2.96)/550000+max($berg,40)+$regeneration/2),3.9) * 200 +
            pow(max($flach,40),4.62)*20 + 
            max(0,pow(max(0, ($pave*0.3+$flach*0.7)-70), 2.1))*60*29000*40 - 
            max(0, (70-($pave*0.3+$flach*0.7))*100*29000*40)  + 
            pow(max($berg,40),5.75)/4 + 
            pow(max($zeit,40),7.28)/3436 + 
            pow(max($sprint,40),6.21)/35 + 
            max(0, ($sprint-45)*100*29000*40) + 
            pow($regeneration,2.3)*300 + 
            pow(max($abfahrt,40),3)*8000)/29000 ;
            
        $gehalt = (pow((45+($zeit-45)*pow($berg,2.96)/550000 + max($berg,40) + $regeneration/2),3.9)*200 + 
            pow(max($flach,40),4.62)*20 + 
            max(0,pow(max(0, ($pave*0.3+$flach*0.7)-70), 2.1))*60*29000*40 - 
            max(0, (70-($pave*0.3+$flach*0.7))*100*29000*40)  + 
            pow(max($berg,40),5.75)/4 + 
            pow(max($zeit,40),7.28)/3436 + 
            pow(max($sprint,40),6.21)/35  + 
            max(0, ($sprint-45)*100*29000*40) +
            pow($regeneration,2.3)*300 + 
            pow(max($abfahrt,40),3)*8000)/29000 -
            ( ((28-25)*100000-((pow((28-21),2.28))))/(3000000/$gehalt) );
            
        return max(round($gehalt / 40), 25000);

Well I don't find it that crazy to wright down the calculation you did. It gives at least some background of it, whereas 299915.5 doesn't tell you anything (but yeah most of the exponents and factors come from nowhere, they are just used to squeeze the formula until something results from it that you have in mind

[Schnuggeritos]

I think I fixed that now, please check your riders. The regularly bought ones should no longer be shown as reduced riders. It was a consequence of incomplete data cleanup after the wrong calculation in month change (the aforementioned complexity ...)

This fixed the issue for my existing team but my new guy Adam Rehberg is shown as reduced purchase. Bought him on 08.02.2025 in an auction (youth market).