12-03-2014, 11:45
Niestety to spowolnienie czasu poprzez rzadsze naliczanie cargo days dawałoby nieproporcjonalnie wielkie przychody na dużych odległościach:
[Obrazek: Pt31comp.png]
na niebiesko zaznaczyłem 6x rzadsze naliczanie tak, aby prawie nie było tej "hopki" - jak widać, w porównaniu z pomarańczową krzywą oryginalnej płatności, jest o wiele za dużo, np. w porównaniu z running cost (czerwona prosta).
Oczywiście można by obniżyć mnożnik bazowy, ale wtedy z kolei byłoby za mało przychodu na małych odległościach (zbyt płaski wykres).
Nie tędy droga.
Głównym problemem jest to, że jest jeden mechanizm służący do dwóch rzeczy:
1. spłaszczania krzywej przychodu z odległością
2. kary za opóźnione transporty.
I na większych mapach to nie działa właściwie.
Najlepszym rozwiązaniem jest rozdzielenie tych rzeczy, właśnie pracuję nad nowym modelem.
Płatność w zależności od odległości wyglądała by tak jak ta zielona krzywa
(jej początkowy charakter identyczny ze starym openttd dla każdej prędkości i towaru, potem mniej lub bardziej płaska zależnie od towaru).
Ale ponadto odejmowane byłyby punkty karne za zbyt późny dowóz,
a kryterium spóźnienia byłaby różnica między czasem transportu a spodziewanym czasem transportu liczonym z prędkości maksymalnej i odległości (plus jakiś mały offset na czas potrzebny na ładowanie/rozładunek i przyspieszanie/hamowanie).
Punkty karne naliczane byłyby, tak jak teraz, czyli w mniejszej ilości, jeśli różnica
jest większa niż cargo.days1 ale mniejsza niz cargo.days2, w większej ilości gdy różnica jest większa niż cargo.days2.
Czyli transport pasażerów byłby znacznie bardziej uczulony na spóźnienia niż np. węgla.
To dawałoby możliwość ciekawych strategii, które są obecne również teraz, ale nie tak wyraźnie.
Np. mało opłacalne byłoby czekanie na pełny załadunek pasażerów, ale w przypadku węgla mogłoby być już opłacalne (zależnie od długości składu),
trzeba by też, w przypadku wspólnej linii, pomyśleć o takim ustawianiu semaforów, aby pasażerskie miały priorytet - jak towarowy poczeka, to nie straci nic lub mało.
[Obrazek: Pt31comp.png]
na niebiesko zaznaczyłem 6x rzadsze naliczanie tak, aby prawie nie było tej "hopki" - jak widać, w porównaniu z pomarańczową krzywą oryginalnej płatności, jest o wiele za dużo, np. w porównaniu z running cost (czerwona prosta).
Oczywiście można by obniżyć mnożnik bazowy, ale wtedy z kolei byłoby za mało przychodu na małych odległościach (zbyt płaski wykres).
Nie tędy droga.
Głównym problemem jest to, że jest jeden mechanizm służący do dwóch rzeczy:
1. spłaszczania krzywej przychodu z odległością
2. kary za opóźnione transporty.
I na większych mapach to nie działa właściwie.
Najlepszym rozwiązaniem jest rozdzielenie tych rzeczy, właśnie pracuję nad nowym modelem.
Płatność w zależności od odległości wyglądała by tak jak ta zielona krzywa
(jej początkowy charakter identyczny ze starym openttd dla każdej prędkości i towaru, potem mniej lub bardziej płaska zależnie od towaru).
Ale ponadto odejmowane byłyby punkty karne za zbyt późny dowóz,
a kryterium spóźnienia byłaby różnica między czasem transportu a spodziewanym czasem transportu liczonym z prędkości maksymalnej i odległości (plus jakiś mały offset na czas potrzebny na ładowanie/rozładunek i przyspieszanie/hamowanie).
Punkty karne naliczane byłyby, tak jak teraz, czyli w mniejszej ilości, jeśli różnica
jest większa niż cargo.days1 ale mniejsza niz cargo.days2, w większej ilości gdy różnica jest większa niż cargo.days2.
Czyli transport pasażerów byłby znacznie bardziej uczulony na spóźnienia niż np. węgla.
To dawałoby możliwość ciekawych strategii, które są obecne również teraz, ale nie tak wyraźnie.
Np. mało opłacalne byłoby czekanie na pełny załadunek pasażerów, ale w przypadku węgla mogłoby być już opłacalne (zależnie od długości składu),
trzeba by też, w przypadku wspólnej linii, pomyśleć o takim ustawianiu semaforów, aby pasażerskie miały priorytet - jak towarowy poczeka, to nie straci nic lub mało.
![OpenTTD #Polska - Polskie forum gry OpenTTD [ARCHIWUM] OpenTTD #Polska - Polskie forum gry OpenTTD [ARCHIWUM]](https://forum.openttd.pl/images/logo.png)
