Nowy model płatności za transport

[TadeuszD]

Ale to przecież nie jest patch, tylko standard...
Dziwię się że w ogóle bronisz tego kuriozum...

Nie bronię "kuriozum" - wręcz przeciwnie - uważam, że ta dziwna stała = 31 powinna zniknąć!
Bronię jednak ogólnej idei, wg której wożenie towarów klasycznymi środkami transportu na coraz większe odległości staje się całkiem nieopłacalne, a nie tylko trochę mniej opłacalne. Wymusza to inwestowanie w coraz lepsze (i droższe) technologie - samoloty, pociągi MagLev, vacuum-tube, itp. OTTD zdecydowanie NIE JEST grą realistyczną, więc nie ma tu sensu skupiać się na rzeczywistych stawkach przewozowych, np. PKP...

Natomiast kombinowanie w newgrf aby wydłużyć czas, to nie jest dobry pomysł.

A to się chyba źle zrozumieliśmy. Nie chodziło mi, że trzeba coś zmieniać w GRF-ach. Chodziło mi o to, że OTTD mógłby sztucznie "spowalniać czas" na dużych mapach, aby uzyskać na nich model przychodu zbliżony do uzyskiwanego na małych mapach. Efekt byłby identyczny z tym, jakby wszystkim pojazdom jednocześnie przemnożyć cargo_age_period o współczynnik, wynikający z wielkości mapy.

EDIT
I jeszcze jedna sprawa, która przyszła mi do głowy już w łóżku... W swoim wzorze wykorzystujesz dwa razy funkcję exp(). Przy włączonym CargoDist i wielu pojazdach na mapie wywołanie tej funkcji może następować nawet kilkaset razy na sekundę - każdy przeładunek/wyładunek dla każdej partii towarów podróżujących inną trasą jest wyliczany osobno.
Nie wiem, ile trwa wyliczenie exp() na nowych procesorach - ostatnio zajmowałem się tymi kwestiami jak królowały procesory 486 - ale na pewno dłużej niż kilka prostych operacji na integerach. OTTD jest programem jednowątkowym, więc wydłużenie choć jednego bloku operacji wpłynie negatywnie na całkowitą wydajność aplikacji. Nie jestem więc pewny, czy pójście w zaawansowany model zmiennoprzecinkowy to najlepszy pomysł. Może lepiej popracować nad jakimś uproszczonym algorytmem, operującym na integer'ach?