KOLEJ Polish PKP Set v2.0
a nie prościej dograć newgrfa z niewidzialną lokomotywą?
Newgrf z niewidzialną kolejką? A można prosić o nazwę?
invisible lead engine czy jakos tak Wink
(17-02-2014, 10:35)TadeuszD napisał(a): BTW: Czy w okresie międzywojennym nie było żadnej polskiej konstrukcji, odpowiadającej donner'om?
Bo tak sobie właśnie przypomniałem założenia, jakimi kierowałem się u zarania PKP setu. Starałem się wtedy unikać nadmiaru "niemiecczyzny", żeby nie biło tak po oczach, że większość taboru, jeżdżącego po Polsce do lat 50-tych, to graty po kolejnych zaborcach.
Myślę że nie ma co zaklinać rzeczywistości, było jak było.
W 1938 na PKP było około 10 tys. wagonów osobowych, z czego 4-osiowych przejściowych ~1700, ~1600 wagonów osobowych było produkcji polskiej - zapewne właśnie te lilpopy itp - wątpię by budowali inne, skoro brak było dalekobieżnych a dużo było właśnie starych gratów dobrych na lokalne linie.

Donnery prawie skończone, musze tylko poprawić Bi bo jest jakiś przesunięty (to te dwa za pocztowym).
Zastanawiam się, czy w celu lepszego rozróżnienia nie dać żółtego paska - w końcu w latach 50tych przemianowali Bi na Ai.

[Obrazek: bici2.jpg]


PS. z innej beczki - proponuję uniwersalnym wagonom krytym, węglarkom i platformom dołożyć:
Kod:
misc_flags:    bitmask(TRAIN_FLAG_AUTOREFIT);
Dzieki temu będzie można na danej stacji od razu zmieniać zastosowanie wagonu do towaru, bez tego irytującego zjeżdżania do "zajezdni".
Słuzy do tego guzik "autorefit" na liście rozkazów - oczywiście można sobie wybrać, na której konkretnie stacji to ma być.
Ale musi być wsparcie GRFa.
Zaraz, zaraz... Z jednego wagonu zrobiły się już dwa... Nie chcę "zaśmiecać" listy taboru wagonami o identycznych parametrach.
Zrobiłby z tego jeden typ (BCi) i co najwyżej losowo podstawiał grafiki albo wagonu z zabudowanym albo niezabudowanym pomostem...
Od początku proponowałem dwa, i nie mają identycznych parametrów:
Cytat:
Proponuję dwa typy: trzeciej klasy Ci, 58 pasażerów, szybsza wymiana (otwarte pomosty), mniejszy komfort, oraz Bi, 40 pasażerów, wolniejsza wymiana (przedsionki zabudowane), lepszy komfort.

Nawiasem mówiąc, w abhxz brakuje tego fiuczeru z cargo_age_period, który jest w abdnu, 1 klasa ma jedynie mniej miejsc.
(25-02-2014, 10:59)McZapkie napisał(a): ...i nie mają identycznych parametrów:

Nikt w takiej sytuacji nie będzie zwracał uwagi na bzdety, jak komfort. Wszyscy będą kupowali Ci. Wink
W grze przydałby się następca "boczniaka" - szybszy, trochę pojemniejszy, może o większej przepustowości. I od tego bym wyszedł; tzn. albo znalazł idealnego przedstawiciela z danego okresu, spełniającego te warunki, albo "uśrednił" w tym celu parametry kilku modeli - wygląd nabiera wtedy drugorzędnego znaczenia. Ale nie mnożyłbym niepotrzebnie bytów.
Zamiast drugiego donner'a wolałbym już dodać jakiegoś dalekobieżnego 4-osiowego boczniaka pruskiej lub włoskiej konstrukcji, który byłby poprzednikiem dla lilpopów, pojawiających się dopiero w latach 30-tych.
OK, to niech będzie jeden ale losowo wybierany z pomostami i bez, np. w proporcji 3:1.
Co do wagonów, to też myślałem o czymś szybszym niż boczniak, ale niekoniecznie bardziej przepustowym,
tylko właśnie dalekobieżnym.
Może dla odmiany jakiegoś austriaka?
[Obrazek: 05423BHXZ.jpg]
http://www.parowozy.pl

Tylko trzeba by odszukać, jaką miał pierwotnie vmax.
Obstawiam 100km/h, bo takie wtedy były parowozy pospieszne robione.
Wtedy można by lepiej wykorzystać Ok1, a datę lilpopów przesunąć trochę do 1935 (tak naprawdę te wózki na 140 to były tuż przed wojną i eksperymentalnie tylko).

A do boczniaków brakuje jakiegoś lekkiego taniego tendrzaka, zwłaszcza na rozpoczęcie gry w 1920 - myślałem nad zrobieniem OKi1, vmax 80km/h, moc 2x mniejsza niż Ok1.
Boczniaki świetnie się nadają do lokalnych pociągów, bo szybsza jest wymiana pasażerów nawet bez modyfikacji load_speed, bo po prostu są krótsze, jest ich więcej na tę samą ilość pasażerów.

I jeszcze jedno - loading_speed dla pasażerów wydaje mi się generalnie za małe, w porównaniu z innymi setami, a także ładowaniem towarów
- co najmniej 2x za małe.
Zrobiłem taką kalkulację, jak ilość drzwi, budowa wagonu i typ wpływają na szybkość wymiany pasażerów oraz komfort podróży.
Zrobiłem to z myślą o secie radzieckich wagonów, gdzie klas jest całe multum,
ale może by to wykorzystać do zbalansowania tego setu?
https://docs.google.com/spreadsheet/ccc?...sp=sharing
Np. obecnie WLAB ma 8x cargo_age_period niż 2kl, to trochę nie fair patrząc na cenę i ilość pasażerów.
Tak czytam i czytam te nazwy wagonów i czuję się jak bym chiński czytał^^ nic z tego nie rozumiem^^
(25-02-2014, 19:41)McZapkie napisał(a): Obstawiam 100km/h, bo takie wtedy były parowozy pospieszne robione.
Wtedy można by lepiej wykorzystać Ok1, a datę lilpopów przesunąć trochę do 1935...
Brzmi sensownie.

Co do load_speed, to dla wybranego taboru podmiejskiego (Bh, Bipa, EN57) już podwyższyłem nieco ten parametr (choć 18 to przesada. Smile ). Wagony dalekobieżne mają load_speed celowo zaniżony - to cena za ich Vmax i wyższy komfort po przebudowie na 1-kę.

Co do WLABd, to jest OK. Powyżej 500 kratek zaczyna przynosić zysk większy niż zwykły dalekobieżny. I taka była moja intencja. Zerknij na 43 stronę tego wątku.
Mnożniki bardziej "dyskretne" niż 2, 4 i 8 po prostu nie dają odczuwalnej różnicy dla przeciętnego gracza.
Mnie jedynie co najbardziej irytuje w tej grze to zbyt szybko upływający czas. Te dni wolniej by mogły mijaćWink A co do szybkości ładowania wagonów i ceny to hmmm czy już jest tak, że wagon pierwszej klasy przynosi większy zysk niż 2? Bo pamiętam, że kiedyś była mowa o tym.
Všichni se tu zaobíráte pasažerskýma vagonama, ale pro grf Firs je třeba chladící či mrazící /frigo/ vagon na přepravu ryb. Doufám, že SOJITA mi rozumí.
Wprowadzam powoli różne drobne poprawki do wersji 2.0.9 PKP Setu.
Przy okazji, opierając się na dyskusjach prowadzonych z McZapkie, postanowiłem dopracować model kosztów dla wagonów 1, 2 klasy oraz sypialnych. Pierwotny model był chyba jednak zbyt ostry. Po serii prób postanowiłem urealnić pojemność WLAB-a (30 pasażerów + 2 osoby obsługi) raz podnieść współczynnik dla cargo_age_period dla 1 klasy z 2 do 2,82. Wykres przychodów w zalezności od odległości, na którą dokonywany jest przewóz, wygląda teraz następująco:

[Obrazek: 680Income.png]

Wykres jest bezskalowy - w wiekszości przypadków używałem współczynników 0..1 - chodziło mi tylko o ustalenie właściwych proporcji między uzyskanymi wartościami.
Ale widać wyraźnie, że na małych odległościach wygrywa 2 klasa (ze względu na największą pojemność), a na większe odległości kolejno 1 klasa oraz sypialny, pomimo znacznie mniejszych pojemności. Preferencyjności stosowania poszczególnych wagonów nie zakłóca nawet aż tak bardzo "ogon", stanowiący temat dyskusji w innym watku...

Zastanawiam się, czy podobnych właściwości nie nadać niektórym wagonom towarowym? Można by założyć, że nowoczesne wagony towarowe, jak Tadds, Habbins czy platformy kontenerowe gwarantują lepsze warunki przewozu towarów, a więc powinny pozwalać na transportowanie ich na większe odległości bez żadnych kar.
Dobra robota.
Pamiętaj też o zwiększeniu running_cost dla WLAB, pensja kuszetkowego i pranie pościeli kosztuje,
że nie wspomnę o balansie gry.
Jak chcesz sprawdzić przychody i koszty, to tutaj mam arkusz:
https://docs.google.com/spreadsheet/ccc?...sp=sharing
W czerwone pola wpisuje się parametry (są już podane dla pasażerów),
w komórce D2 ilość, w B4 cargo_age_period.
Natomiast parametry kosztów są w kolumnie V, podaje się koszty roczne, koszt zakupu i czas życia.
Czerwona linia to suma running_cost i kosztów amortyzacji.

A właśnie, w secie 2cc jest takie coś, że jak pojazd stoi, to ma o wiele mniejsze running_cost,
niż jak jedzie:
http://149.156.194.203/~mczapkie/Train/t...stoprc.jpg
Ostatnio grałem na serwerze z 2cc+ECS i jak się skończył węgiel w kopalniach a nie byłem zalogowany,
to mi ten fiuczer uratował firmę - mnóstwo pociągów stało bezczynnie, bo w ECS jak braknie węgla,
to huty rudy też nie przyjmują i cały łańcuszek leży.
Chyba przez start/stop da się to zdefiniować?
I przy okazji zastanów się, czy running_cost nie powinny być proporcjonalne do kwadratu prędkości?
Teraz są chyba liniowo zależne.
Nie chodzi tylko o prostą fizykę mv^2/2, ale 2x większa prędkość to co najmniej 4x większe dochody.
(19-03-2014, 18:20)McZapkie napisał(a): Pamiętaj też o zwiększeniu running_cost dla WLAB, pensja kuszetkowego i pranie pościeli kosztuje...

Moge nieco zwiększyć running_cost, choć w rzeczywistości te koszty są pokrywane z niebagatelnej ceny miejscówki, których nie ma jak zasymulowac w OTTD.

McZapkie napisał(a):A właśnie, w secie 2cc jest takie coś, że jak pojazd stoi, to ma o wiele mniejsze running_cost...
Chyba przez start/stop da się to zdefiniować?

Najłatwiej zasymulować taki efekt korzystając z callback'a running_cost_factor oraz parametru current_speed. Nie wiem tylko jak często jest to wyliczane, bo na pewno nie co 1 tick zegara...
Przy jakiejś okazji mogę to sprawdzić. W sumie myk, że gdy V < 1km/h to running_cost spada powiedzmy o 75%, nie byłby taki głupi. W końcu stojący pociąg nie zużywa paliwa. Liczą się tylko koszty stałe. Nie pamiętam teraz dokładnie, ale w OTTD jest chyba tak, że pociąg przebywający w depocie w ogóle nie generuje żadych kosztów utrzymania.

McZapkie napisał(a):I przy okazji zastanów się, czy running_cost nie powinny być proporcjonalne do kwadratu prędkości?

O ile pamiętam, to running_cost dla lokomotyw w PKP Secie jest proporcjonalny do iloczynu mocy i Vmax. A ponieważ bez mocy nie ma prędkości - słabe przyspieszenie nie pozwala rozpędzić się do Vmax - to zależność running_cost od prędkości wychodzi pośrednio jako nieliniowa. Ale sprawdze to jeszcze...

No i wracając do wczesniejszego pytania - bawić się w zwiększanie cargo_age_period dla wagonów towarowych, czy nie?
Zgadza się, w depocie nic nie kosztuje, ale tu chodzi o pociąg stojący pod załadunkiem.
W sumie jest to pomysł na rozgraniczenie lokomotyw pasażerskich i towarowych.
Pospieszne mogłyby mieć koszty stałe - bo głównie jeżdżą a nie stoją.
Osobowe mogą mieć trochę obniżone przy postoju, a towarowe znacznie obniżone przy postoju, ale zwiększone przy jeździe, bo mają ciężkie składy.
W NML można stosować funkcje, popatrz do setu xUSSR, tam mają niektóre przeliczenia wygodnie podefiniowane.

Tylko trzeba by w menu zakupu wyraźnie zaznaczyć, że są zmienne koszty.
W 2cc nic o tym nie pisze i odkryłem to przypadkiem.

Co do towarowych wagonów, to raczej bym zwiększył loading_speed dla kontenerów.
Natomiast cargo_age bym zmodyfikował dla chłodni - ktoś ostatnio narzekał, że są zbyt wolne i mu ryby zgniły Smile
(20-03-2014, 19:20)McZapkie napisał(a): W sumie jest to pomysł na rozgraniczenie lokomotyw pasażerskich i towarowych.

Jeśli kiedykolwiek zastosuję ten mechanizm, to raczej będzie on powiązany z typem lokomotywy. W parowozie trzeba szuflować węgiel i utrzymywać parę nawet wtedy gdy stoi, więc redukcja kosztów utrzymania nie powinna być większa niż 50%. Natomiast elektryki są znacznie oszczędniejsze w trakcie postoju, więc tu możnaby redukować koszt nawet o 80%.

Spojrzałem na wzór do wyliczania cen zakupu i utrzymania w PKP Secie. Koszty utrzymania są jednak liniowo zależne od mocy i prędkości. W dodatku moc ma znacznie większą wagę w tym wzorze aniżeli prędkość. Jak się cofam wspomnieniami, to coś kołacze mi się po głowie, że koszty utrzymania miały odzwierciedlać w głównej mierze koszty zużycia paliwa, a te są dość mocno związane z mocą.
Za to koszty zakupu są zależne głównie od prędkości max. lokomotywy. To na odmianę miała być cena za nowszą i lepszą technologię.
Ze strony https://dev.openttdcoop.org/projects/pkpset/files można pobrać kolejną wersję PKP Setu do testów. Oprócz błędów i poprawek uwzględniłem też parę nowych postulatów. Od siebie dodałem ograniczenie dla bipy i kibla, żeby nie nadawały się do transportu pasażerów na zbyt duże odległości.
Zapraszam do testów. Smile

Poniżej changelog:
Kod:
2.0.9
New wagons added: Eamos, Tadns, WLABd and Bh("bonanza"),
End of service for Tp4 and Ok1 changed to year 1956,
New purchase costs for engines - prices more dependent on vehicle speed,
Loading_speed property changed for Eaos, Res, Sgs, Fals, Falns, Gags, SN61,
EN57 and EN71,
Running cost increased for wagon s with brakeman's hut (BCyh, Wddoh, Kdth, Rh),
Model_life property changed for Kddet,
Running_cost_factor property changed for Bipa,
Cargo_age_period for A/Bhxz, A/Bdnu and A/Bdhmnu differs for 1st and 2nd class,
Cargo_age_period decreased for Bipa, EN57 nad EN71,
TRAIN_FLAG_AUTOREFIT flag added to ordinary open and covered wagons,
Refit to MAIZ or CERE allowed for normal covered wagons (Kdt, Kdth, Kddet,
Gags and Gbs),
Refit to MAIZ disallowed for normal self-discharging wagons (Fals, Falns),
Refit to FICR disallowed for normal open wagons (Wddo, Wddoh, Eaos)(#6706),
Visual glitches fixed in Habbins, SU45 and SU46,
Bug fixed for EN76 (#6708),
New ZOOM_LEVEL_IN_2X graphics for wagon Slr,
Capacity increased for SN61, Bipa and Bh("ryflak"),
Implementation of A/Bdhmnu changed - number of parts optimized,
New Wddo, Wddoh and Eaos graphics for WDPR cargo (#6741),
Palette recolouring for rear lights implemented for A/Bhxz, A/Bdnu and Bipa,
New translations added: Croatian and Spanish.
Super. A czy ta wersja będzie na bananas? Chętnie bym ją wrzucił na serwer do przetestowania, ale tak aby klient dał rady uzupełniać online.
Co do poprawek, to jednak będę się upierał przy większych szybkościach przeładunku dla pasażerów.
Poszedłeś w złym kierunku. Zamiast zmniejszać dla dalekobieżnych, trzeba było zwiększyć dla lokalnych/podmiejskich.
Popatrz jak to jest w 2cc:
http://wiki.openttd.org/2cc_TrainSet#Loa...enger_cars
a chciałbym zauważyć że tam się mieści 40-50 pasażerów i są krótkie, w PKP jest pasażerów więcej a loading_speed tylko 5 - w efekcie ślamazarzy się znacznie wolniej niż rozładunek węgla łopatą z węglarki.
10 powinno być OK dla dalekobieżnych, 15 dla bezprzedziałowych z pojedynczymi drzwiami, 20...30 dla bezprzedziałowych z podwójnymi drzwiami (zależnie ile skrzydeł drzwi na 10mb wagonu).

Cytat:Jeśli kiedykolwiek zastosuję ten mechanizm, to raczej będzie on powiązany z typem lokomotywy. W parowozie trzeba szuflować węgiel i utrzymywać parę nawet wtedy gdy stoi, więc redukcja kosztów utrzymania nie powinna być większa niż 50%. Natomiast elektryki są znacznie oszczędniejsze w trakcie postoju, więc tu można by redukować koszt nawet o 80%.
W elektrowozie trzeba i tak płacić maszyniście czy stoi czy leży, więc takich głębokich różnic bym nie robił, i tak parowozy są bite Smile
Natomiast mi chodziło o co innego.
Otóż w openttd koszty są naliczane bez przerwy i nie ma żadnego odzwierciedlenia, co naprawdę robi lokomotywa,
czy stoi, czy przyspiesza, czy jedzie ze stałą prędkością.
Lokomotywy pasażerskie na ogół często przyspieszają do vmax i hamują, rzadko kiedy stoją.
Więc running_cost mogą zostać takie jakie są, proporcjonalne (z jakąś wagą) i do mocy, i do kwadratu prędkości.
Natomiast lokomotywy towarowe często stoją, natomiast jak jadą, to często z mniejszą prędkością ale maksymalną mocą,
bo mają ciężkie brutto na haku.
I tu by się przydał modyfikator tak jak w 2cc - jak stoi to koszty zredukowane,
ale jak jedzie to duże (większe niż teraz są), proporcjonalne głównie do mocy.
(25-03-2014, 18:13)McZapkie napisał(a): Co do poprawek, to jednak będę się upierał przy większych szybkościach przeładunku dla pasażerów.
Poszedłeś w złym kierunku. Zamiast zmniejszać dla dalekobieżnych, trzeba było zwiększyć dla lokalnych/podmiejskich.

I tak jest. Domyślnie w OTTD loading_speed wynosi 5. I tyle mają wagony dalekobieżne. Natomiast resztę wyliczałem tak, aby otrzymać odpowiednio krótsze czasy załadunku. I tak: dalekobieżny rozładowuje się w 16 ticków, boczniak w 10 ticków, ryflak i bonanza w 9 ticków, bipa w 10 ticków, a EN57 w 6 ticków.
Faktycznie, bipę można by trochę poprawić, żeby nie była gorsza od ryflaka i bonanzy. Ale całą resztę uważam za poprawną. W końcu dalekobieżne, jak sama nazwa wskazuje, nie służą do ruchu podmiejskiego, więc długi czas załadunku eliminuje je z tego zastosowania. Wink

Edit:
Poeksperymentowałem dziś z tym running_cost_factor. Odkryłem, że parametr ten jest wyznaczany co 1 dzień lub w momencie zmiany kierunku jazdy pociągu.
Do testów wyliczyłem running_cost_factor dla stojącej lokomotywy z tego samego wzoru, co normalny running_cost_factor, lecz przy podstawieniu power=0. Największy spadek kosztów byłby więc widoczny w przypadku lokomotyw ciężkich, o dużej mocy.
To, co najbardziej mnie razi w tym mechanizmie, to zero-jedynkowy charakter zmian tego kosztu. Eksperymentalnie zrobiłem więc trzeci stan pośredni - gdy pociąg jedzie całkiem pusty, to zużywa "połowę" swej mocy, tzn. koszty użytkowania przyjmują wartość pośrednią. W sumie niezły bonus dla pociągów towarowych, które praktycznie połowę czasu jeżdżą puste...


Skocz do:

[-]
Zamknięcie forum OpenTTD Polska
Forum OpenTTD Polska zostało wyłączone. Obecnie znajduje się tu archiwum dyskusji o dodatkach tworzonych przez naszą społeczność.
Po aktualne treści i dyskusje zapraszamy na nasz discord! :)

[-]
Discord