Królik Uszasty

Będą dodane w późniejszym etapie (ale już relatywnie niedługo). Z racji tego, że są to pociągi o charakterze dekoracyjnym, będą upychane w wolne luki, które nie zostaną wykorzystane przez pociągi towarowe.

Wczoraj została wgrana aktualizacja rozkładu testowego. Zmiany obejmują: Dodane pociągi nocne 163xx (Warszawa Wschodnia) Warszawa Grochów-Sędzice (Szklarska Poręba Górna) vmax 120 613xx (Szklarska Poręba Górncza) Sędzice-Warszawa Grochów (Warszawa Wschodnia) vmax 120 831xx (Szczecin Główny) Zgierz Kontrewers-Kraków Płaszów (Kraków Główny) przez Łódź Kaliska, Włoszczowa Północ, Dąbrowa Górnicza Ząbkowice vmax 140 381xx (Kraków Główny) Sosnowiec Maczki-Zgierz Kontrewers (Szczecin Główny) przez Zawiercie, Włoszczowa Północ, Łódź Kaliska vmax 140 542xx (Gdynia Główna) Zgierz Kontrewers-Brynów (Bielsko Biała Główna) przez Łódź Kaliska, Piotrków Trybunalski vmax 120 452xx (Bielsko Biała Główna) Brynów-Zgierz Kontrewers (Gdynia Główna) przez Piotrków Trybunalski, Łódź Kaliska vmax 120 141xx (Warszawa Wschodnia) Warszawa Grochów-Katowice Tow. KTC (Gliwice) przez Piotrków Trybunalski vmax 140 411xx (Gliwice) Katowice Tow. KTC-Warszawa Grochów (Warszawa Wschodnia) przez Piotrków Trybunalski vmax 140 Dodane pociągi towarowe ZUE 6490xx (Piława Górna) Katowice Tow. KTC - Myszków przez Będzin vmax 80 co 2 godziny ZNE 6290xx (Piława Górna) Katowice Tow. KTC - Czarnca (Kielce Herbskie KHB) przez Będzin vmax 100 co 2 godziny (BETA) TKE 4432xx Katowice Muchowiec Staszic - Mysłowice co 2 godziny TKE 4431xx Katowice Muchowiec Staszic - Dąbrowa Górnicza Towarowa przez Dorota (wybrane kursy przez Sosnowiec Kazimierz) co 2 godziny vmax 100 (BETA) TME 4440xx (Częstochowa Towarowa) Myszków - Staszic (Łaziska Średnie) przez Dąbrowa Górnicza Południowa vmax 80 co godzinę TDE 2421xx Sędziszów Towarowy - Katowice Tow. KTC przez Sosnowiec Kazimierz (wybrane kursy do Sosnowiec Maczki przez Dorotę lub Sosnowiec Kazimierz) vmax 100 co 1-3 godziny TNE 2430xx (Kielce Herbskie) Sędziszów Towarowy - Sosnowiec Maczki (Jaworzno Szczakowa) przez Sosnowiec Kazimierz vmax 80 kursy nieregularne LTE 2450xx Sędziszów Towarowy - Borowa Górka kursy nieregularne TDE 4220xx (Gliwice Port) Katowice Tow. KTC - Sędziszów Towarowy (Nałęczów) przez Sosnowiec Kazimierz vmax 120 kursy nieregularne TNE 4230xx (Jaworzno Szczakowa) Sosnowiec Maczki - Sędziszów Towarowy (Kielce Herbskie) przez Sosnowiec Kazimierz vmax 80 kursy nieregularne LTE 4250xx Borowa Górka - Sędziszów Towarowy kursy nieregularne Pociągi oznaczone BETA z góry mogą mieć poważne błędy i niedociągnięcia, więc na pewno zostaną poprawione. Mogą występować kolizje na odcinku Sędziszów-Tunel, wiemy o nich i będą niebawem usuwane. Zestawienia składów są tymczasowe i będą zmieniane. Numeracja pociągów nocnych będzie jeszcze korygowana później. Zapraszam do testów na serwerach PL5, INT5 i INT9.

Have you ever considered to exchange showing speed and signal colour to the delay of a train? So in squares would be shown how much a train is late.

No i do tego powrót klasyków Warszawa - Katowice p. CMK, Kozłów i odwrotnie na 120 km/h. Nie do końca rozumiem, na czym polega ta nierealistyczność i nietypowe sytuacje. Żeby zagęścić ruch, pociągi muszą się poruszać ze zbliżoną prędkością, inaczej powstają ogromne dziury między pociągami. Z drugiej strony nie można dopychać pociągów z innych miejsc bez ograniczeń. Nawet jeśli przyjmiemy, że braki z Grodziska uzupełnimy pociągami z Markowa, to wciąż jesteśmy ograniczeni wyjazdem w Szeligach, gdzie przecinamy tory szlakowe. Można dopchać pociągów w Idzikowicach przez łącznice z Radzic, ale wtedy Opoczno i Olszamowice utoną, bo nie będą w stanie przerobić tego ruchu i wyprzedzań.

Całej mapy

It seems you have overcharged the brake pipe with pressure greater than 5 bar. You should not use fill position (↑↑↑) unless you know, what are you doing. The brake lever should not stay there for a long time, rather short impulse and immediately you should go back to assimilation (↑↑) - then the brake pipe overcharges in a controlled manner to only 5,4 bars and goes back to 5,0 bar gradually, when the brake lever is back in "running"/"driving" position.

Nie będę tutaj się zbytnio rozwodzić na temat decyzji biznesowych, natomiast uważam że Twoje twierdzenia są (być może tylko jako zabieg retoryczny) przejaskrawione. Fakty są takie, że: 1) na rynku istnieją podmioty gospodarcze, które używają w tym momencie do różnego rodzaju szkoleń symulatorów robionych metodami gospodarczymi w oparciu o MaSzynę (i czasem zaczynają się odbijać od jej ograniczeń) i mogą mieć pokusę dokonania niskokosztowego unowocześnienia oprogramowania, 2) przynajmniej jeden z naszych konkurentów walidował swoją symulację danego pojazdu w oparciu o moją pracę na rzecz MaSzyny. Dla mnie, na podstawie mojej, wyżej przedstawionej wiedzy o sytuacji na rynku, obawy o wykorzystanie gry SimRail w sposób niezgodny z przeznaczeniem (tj. czyli nie do grania w grę w domu a do szkolenia lub zdobywania know-how o symulacji konkretnego pojazdu) nie wydają się być wyssane z palca. Pewnie dlatego musimy wyważyć co i ile możemy przenosić do wersji "cywilnej" naszego oprogramowania, która jest przecież po wielokroć tańsza od wersji komercyjnej/szkoleniowej.

Tak jak pisałem kawałek wcześniej, to nie jest mój obszar i nie zamierzam jakoś bardziej wchodzić w powody wyboru technologii komunikacji. Jestem w stanie zrozumieć argumenty za i przeciw oraz perspektywę firmy i użytkowników. Co do liczby parametrów/zmiennych, to myślę, że zwykly wagon przelicza ich z tysiąc, a bardziej złożone pojazdy mogą iść nawet w kilkanaście tysięcy (oczywiście dla pojazdów w pociągu gracza, bo boty mają większość obliczeń wyłączoną). Większość z nich stanowi de facto wartości pomocnicze do określenia dynamiki pojazdu lub zachowań jego systemów (np. przepływy między zbiornikami i komorami w hamulcach, zeby ostatecznie napelnić cylinder hamulcowy i zaczac hamowanie). Jestem też absolutnie przekonany, że to nie to powoduje, że gra zajmuje 100 GB - wystarczy spojrzeć, ile zajmują na dysku poszczególne DLC mapowe, żeby stwierdzić, że to mapa stanowi większość danych przechowywanych na dysku.

Zasięgnąłem dzisiaj języka, jak to ma działać. Broker/serwer MQTT będzie stawiany przez grę i dostępny podstawowo przez Ethernet/TCP/IP (oprócz tego rozważane są też inne opcje, ale to wyjdzie w praniu). W takiej sytuacji można będzie użyć albo jakiegoś mikrokontrolera z ethernetem (połączenie kablem RJ45, WiFi), albo we własny sposób z własnym interfejsem/protokołem - wtedy odbieramy dane programowo i do kontrolera wysyłamy dowolnie. Dane z symulatora będą odświeżane kilka razy na sekundę. Jednocześnie MQTT od ręki daje nam możliwość komunikacji z wieloma sterownikami zewnętrznymi, przez co można będzie podzielić sterowanie pulpitem na kilka mniejszych kontrolerów. Pytanie jest dosyć niekonkretne. Jeśli ruszysz natychmiast z -100% na +100% to wystarczy jedna. Jeśli ruszasz powoli (a to sugeruje Twoja wypowiedź o odczuciu liniowości), to 5 do 10 komunikatów na sekundę powinno wystarczyć, w szczególności że przekształtniki (falownik czy czoper) mają i tak swoje wygładzanie wartości zadanej i wyjściowej, więc to się wygładzi w stopniu wystarczającym. Czy możemy przyjąć, że takie rozwiązanie spowoduje pomijalne różnice w przebiegu rozruchu i hamowania, czy chcesz to przeliczać? Powiem może trochę szerzej - że wszystkie z pojazdu to już wiadomo, że nie. Dla Dragona mamy potencjalnie 300, a dla Impulsa 900 wartości wejść/wyjść. Część z nich jest w grze nieużyteczna, część zaś nie będzie dostępna, żeby przypadkiem ktoś sobie jednak nie zaczął robić z gry symulatora. Natomiast z zasady raczej wszystko to co da się zbindować do klawiatury i to co widać na miernikach i lampkach powinno być. Wedle mojej wiedzy dozwolony ma być float 32 bit. Ależ proszę bardzo... W ciągu kilku dni już drugi raz używasz tej samej nieszlachetnej części ciała, aby wyrazić swoje głębokie niezadowolenie, że coś nie jest robione po Twojemu. Smacznego. Ja bym w wątku o kontrolerach gier w pierwszej kolejności spodziewał się jakichś informacji w temacie, opinii, rozważań. Śmieszność raczej nie jest podstawowym jego celem i bym jej tutaj jakoś na siłę nie szukał.

@Mywasher Nie uważasz, że jednak Twoje wypowiedzi trochę zbyt emocjonalnie podchodzą do tematu, a niektóre porównania wręcz niesmaczne? Wydaje mi się, że jest już bliżej jak dalej do ukończenia prac i z jakiegoś powodu taki standard został wybrany - nie wiem, nie znam się i nie będę tłumaczył powodów wyboru i całego toku myślowego, jaki za tym stał. Nie sądzę, żeby na tym etapie ktoś zaorał wszystko tylko dlatego, że jeden użytkownik forsuje inny standard. Natomiast porównywanie pulpitu w domu do rozwiązań przemysłowych (a już co gorsza - pojazdów kolejowych) nie jest chyba na miejscu. Ja wiem, że nawet wyolbrzymione pół sekundy opóźnienia przy włączaniu hamowania przy prędkości 200 km/h to prawie 30 metrów różnicy w miejscu zatrzymania, ale bądźmy szczerzy - jeśli komuś naprawdę takie coś uniemożliwiałoby za każdym razem zatrzymanie się w miejscu, to jednak chyba trzeba zmienić technikę jazdy. Inna sprawa, że ja nie spodziewałbym się jakichś dużych i zauważalnych opóźnień w transmisji, zwłaszcza że te istotnie responsywne to muszą być w większości wypadków ze... 4(?) manipulatory (nastawnik, bocznik/tempomat, hamulec zespolony, hamulec pomocniczy). Myślę, że prawdziwe pojazdy w niektórych sytuacjach serwują większe opóźnienia (typu zawieszający się na kilka sekund monitor diagnostyczny przy włączaniu hamowania nagłego, bo musi przetworzyć na raz kilkanaście komunikatów o błędach). Sam do MaSzyny skonfigurowałem swój pulpit do komunikacji co 100 ms i jeździło mi się dobrze. Głównie dlatego, że wystarczyło ruszyć ręką zamiast korzystać z klawiatury. Co do samych magistral komunikacyjnych, no to cóż... no mamy na przykładowoym pojeździe (EZT) magistralę CAN, nawet 5-6 niezależnych linii, żeby te dane przesłać, ale wciąż hamowanie nagłe to otwarcie dziury pod grzybem lub zadajnikiem hamulca oraz równolegle poprowadzony przewód wzdłuż całego pojazdu (tzw. "pętla bezpieczeństwa"), który w tradycyjny sposób odcina zasilanie zaworów bezpieczeństwa. No i na tyle, na ile liznąłem TMCSów (systemów sterowania pojazdami), to tam komunikacja jest raczej dosyć surowa z odczytywaniem bitów i bajtów po adresach/pozycjach w ramce. MQTT wraz z bibliotekami pozwoli to opakować w trochę bardziej przyjazną formę odczytu. Na pewno nie będzie to ciągnięcie danych z internetu - dane będą przetwarzane i wystawiane lokalnie, szczegółów podłączenia nie znam, ale na pewno będą podane.

the same answer applies: All three exits on the west side of Łódź are low capacity lines: double track line no. 14 without ABS towards Zduńska Wola, Sieradz, Sędzice, two single track lines no. 15 and 16 from Zgierz towards Łowicz and Kutno combined with some limitations of our engine: (1) a train needs to go from point outside the map and to another point outside the map, (2) no reversing of trains (even EMUs). It means that there is no possibility to increase the traffic by adding trains going only to Zgierz or going the sequence of Retkinia <-> Kaliska (rev.) <-> Chojny as in reality. I think we have about 10 (pairs of) slots per hour and all of them have to be divided between Marysin (to Zgierz), Kaliska (to Zgierz) and Retkinia (to Zduńska Wola via Pabianice, Łask). Maybe it may be a bit artificially optimised for one or two trains more, but it may cause som trains to have excessive long stops. Well, is it a proper one? On the main lines there are missing only three big stations in Warszawa (and all three seem to not be very exciting, although busy) and three - mechanical ones: Sosnowiec Dańdówka (62+171), Piotrków Trybunalski (1) and Sieradz (14). Of course there are also Charsznica, Wolbrom, Jaroszowiec Olkuski, Olkusz - but they are affected by line no. 62 low capacity layout - and signalboxes in side freight lines in Silesia (Staszic, KMB, Stawiska, Kozioł, DTA R5, Przemiarki) - also not exciting, low capacity and remarkably not mixed traffic. Also - I don't get it. How adding signalboxes in one part of the map resolve a problem of too low traffic not being entertaining enough? Does it change a lot if you replace 100 km/h freight train with 120 km/h (or even 140 km/h) passenger train from Knapówka and then you have to go full section from Psary to Góra Włodowska (the longest one!) with reduced speed? Or if you wait in Psary for couple of minutes (if you have good luck, but if you have bad luck you can be stuck in Starzyny at entry signal forever)) when someone sent any train (even 140 km/h 531xx TLK) just before you? To be not distrupted at all we would need to wipe out everything but pendolinos from CMK and create a big time window on the other lines just in case something goes wrong. In the upcoming timetable there might be a bit less of freights during day-time on CMK as we see more details and we can apply some timetable rules more strictly now. In consequence we have already heard that this makes some signalboxes, which are very responsible now like Szeligi, not interesting at all.

Dear Mywasher Still, I think we see the case differently. Real life dispatching can be really boring as hell without all the other activities. Real life driving can also be boring and you can pass only 2-3 trains during an hour-long drive and have no contact with any dispatcher. And this is the fact that affects the gameplay on the entire map. I see that you see only CMK as a problem, which very limited approach. Redirecting all freights from CMK to LK1 is not a complex solution, it is just moving the problem into other parts of a map and creating a clean playground for some drivers. We can get rid of freights there, but when argument of "realism" kicks in, there come also questions about the limit of it and why this thing is more "real" than the others. Maybe we should cancel most of 16xx/61xx pendolinos, as in reality there are only two or three of them per day? Maybe we should cancel all 161xx/611xx as there are no TLK's to Wrocław via CMK? Maybe we should cancel a half of pendolinos and EuroCity trains to Katowice as in reality they are mixed and pendolinos mostly fill the gaps between international trains? As you can see, all of them make more room on the line to drive trains without delays. AFAIK in normal operations there should be no or very, very low number of overtakes on CMK. No overtakes = always green. Nope, sorry. LK1 is not a proper environment for mixed traffic. The line is not prepared for traffic required by online multiplayer game (as most of our Polish lines). It has a lot of "interesting" solutions in station tracks layouts which significantly decrease capacity. It doesn't matter if it is big station like Skierniewice, Koluszki or it is a small station like Rogów, Płyćwia, Rokiciny, Baby... I hit the wall many times preparing the current timetable and we hit the same wall preparing the next timetable - fundamental design philosophy for those stations and their layouts. Well, but average 50 km/h EN57 or even 70 km/h EN76 put just before 140 km/h Intercity or 160 km/h Sprinter does not ruin the experience for drivers? Maybe in absolute values it sound as less distruptive, but it is even less than 50% of desired speed of a fast train. Then you cannot just set cruise control to 90-100 km/h and go with constant speeed - you have to brake every three blocks as the regional train approaches passenger stop and then you have to accelerate as there are other trains behind you. On the other hand - what about being held in side track in a heavy freight train for too long and falling out of "slot"? I heard complaints about getting stuck in Pruszków or Grodzisk in freight train because dispatcher misjudged necessary time or feared not to delay passenger train instead of letting a freight train go when it was already at full speed and it should reach the planned overtaking spot. I believe that with current tool we will be able to prepare a proper timetable for night time with more freight trains, however with a minimal amount of priority passenger trains it may not set enough pressure on dispatchers.

...in the opposite needs of drivers (who want rather smooth ride according to the timetable, especially when driving fast passenger trains) and dispatchers (who want to have some fun of dispatching by making decisions and creating overtake opportunities). To make dispatching a bit less boring we need to have speed difference and overtakes, but every overtake is a risk of missing it and then the faster train gets blocked by a slower one. The CMK is a bit different from other lines as it is the only one designed for driving 200 kph but the situation is very similar on the line no. 1 when a fast train going 140 kph can be blocked by an EN57 going with average speed of 50 kph. Please remember that we still get complaints about too long breaks between trains on signalboxes on the main lines - up to 15 minutes - although we run about 30% of train count (~1500 of 5000) daily from whole Poland on 6% of its railway grid. This might seem as paradox, but it is effect of mixed traffic - here is my quickly made drawing about 1 year ago for discord discussion and example of 25 km long section between Włoszczowa Północ and Olszamowice with Pendolino driving time 11 minutes and freight driving time 20 minutes: We can get rid of freights on CMK (especially northert part), but it does not mean there will be more trains (lack of capacity from Warszawa Zachodnia towards Warszawa Włochy so we have fixed slot count for Grodzisk Mazowiecki spread between Łódź and CMK) so the signalboxes will become more boring and it will be more common to be signalled by bots than humans.

No. We have about gradients up to 10-12 ‰, what is about equivalent of 20-25% of Pendolino acceleration. It is not a problem even in wet conditions when all inverters and motors are working, but it might be useful when the drive is broken and the available tractive effort is considerably lower. Some locomotives has a similar hidden feature as they can increase the tractive effort of a single motor from 75 to 85 kN when the other ones are slipping.

Shrnutí Nečekaně pro Vás připravujeme nový jízdní řád, jelikož ten současný není ideální. Celý text Milí strojvedoucí a výpravčí SimRailu, Mám pro Vás nějaké novinky – někteří z Vás to již uhodli – připravujeme nový „záchranný“ jízdní řád. Než se dostaneme zpátky, podívejme se na moment do minulosti. Když jsme rok a půl zpátky opustili Předběžný Přístup a vydali trať Tunel-Kraków, nový jízdní řád byl připraven a nazván jako „přechodný“. Název reflektovat fakt, že místo jednoduchého přidání vlaků do Krakówa byl jízdní řád kompletně vytvořen od nuly. V něm jsme použili rozdílné předpoklady a metody pro kalkulaci jízdních dob. Jízdní řád bylo také potřeba remodelovat pro rozšíření DLC: Łódź–Warsaw a tím tak opravit i některé nedostatky původního jízdního řádu, kde jízdní řády na CMK byly příliš natažené, a tak se běžně stávalo, že vlaky dojížděly do stanice Grodzisk s desítkami minut náskokem. Přechodný jízdní řád s námi však zůstal po delší dobu, než bylo plánováno. Při vydání DLC: Łódź–Warsaw, kde byl jediným bodem střetu stanice Grodzisk Mazowiecki. Díky tomu stačilo vložit nové vlaky směřující na Skierniewice do těchto prázdných mezer v jízdním řádu. To nám umožnilo vytvořit solidní jízdní řád se zvýšenou obtížností obsluhy stanice Grodzisk Mazowiecki a Pruszków díky přidání značného množství nových vlaků pro Skierniewice a Koluszki. Nicméně vydání DLC: Łódź Junction v kombinaci s DLC: Impuls 2 nám ukázalo, že jsme narazili do zdi. Velikost změn, úprav a požadovaných změn v jízdním řádu dosáhla maximálních limitů, kterých jsme dosahovali již dříve. Navíc, naše nástroje, které jsme využívali, dosáhli maxima a jakákoliv změna nebo paralelní práce se ukázaly jako obtížné. To samozřejmě celý proces dělalo nesmyslně komplexním. Jak jste již mohli uhodnout, to bylo hlavní příčinou, proč noční vlaky nebyly v současném jízdním řádu obnoveny: trasování nočních vlaků bylo rozdílné od denních vlaků a bylo tedy nutné i přizpůsobení tras nákladních vlaků. Což prakticky znamenalo vytvořit druhý paralelní jízdní řád pro malou část dne a následně opravit i všechny ranní vlaky. Ve stejném čase tohoto roku, @P.Wiśnia mě kontaktovala a navrhl mi, abychom společně vyvinuli aplikaci na tvorbu jízdních řádů přímo pro nás na míru. Díky tomu v průběhu měsíce vytvořila systém, který nám pomůže konstruovat celý jízdní řád mnohem rychleji s větší účinností. To nám pomohlo k rozhodnutí, že současný jízdní řád už nebude nadále vyvíjen ani upravován. Za prvé by kvůli napjatému harmonogramu vydávání obsahu bylo testování a nasazování oprav jízdního řádu podle harmonogramu nesmírně obtížné. Za druhé, tento přístup by nám jednoduše neumožnil eliminovat některé důležité chyby s existujícím jízdním řádem, které by nás i Vás neustále obtěžovaly při hraní. Aktuálně je nástroj pod intenzivním testováním, který v „nouzovém“ režimu simuluje stávající jízdní řád a jeho předpoklady. Nový nástroj poskytuje spoustu výhod, ale také dvě nevýhody. Za prvé, je to na úplně jiné bázi filozofie a kalkulace jízdních dob mezi stanicemi pomocí zvolené lokomotivy, délky vlaky, hmotnosti a kategorie vlaku. To znamená, že import současného jízdního řádu v rámci tvorby vytvoření oprav vlastně není možné. Za druhé, je velmi přesný a jasně odhaluje větší množství detailů, které vyžadují další doladění. Z tohoto důvodu musí být každý vlak znovu vytvořen od nuly, a proto jsme museli upustit od striktního hodinového intervalu a přejít k drobným posunům v rámci několika minut. Aktuálně máme připraveno cca ¾ jízdního řádu – 1 321 z celkových 1 704 jízdních řádů vlaků je nyní připraveno na serverech PL5, INT5 a INT9. Rozsah změn v jízdním řádu obsahuje: 1) Znovu vytvoření tras hlavních vlaků na CMK, které nyní obsahuje drobné časové posuny a prodloužené jízdní doby s požadovanými rozestupy; 2) Úpravu jízdních řádů tak, aby odpovídaly řazení, zejména zvýšení maximální rychlosti u spojů obsluhovaných jednotkami Impuls a zavedení spojů ŁKA Sprinter na trase Varšava–Łódź; 3) Doplnění dopravy i na spojovacích tratích, které zahrnují obě DLC 4) Přísnější dodržování předpisů o jízdních řádech, zejména správné uplatňování povinných intervalů mezi vlaky odjíždějícími stejným směrem a při konfliktních jízdách. Vedlejším efektem těchto změn je také drobná redukce kapacity v některých železničních uzlech a na některých tratích, což vyplývá z nutnosti dodržovat větší rozestupy mezi vlaky. V této chvíli zbývá přetrasovat zbývající nákladní vlaky v oblasti Katowice, Sosnowiec a Zawiercie, a také na trati LK62. Další otázkou je zavedení nočních vlaků, které by mohly operovat v rozdílně oproti denním vlakům. Aktuální stav jízdního řádu můžete vidět na serverech PL5, INT5 a INT9. Konečně, bych rád zmínil, že SimRail nejsou jen „vlaky na počítači“, ale především o všech lidech, kteří se chtějí bavit a dále rozvíjet tento projekt. V současné době na jízdním řádu pracuje 4 členný tým: 1) P.Wiśnia, který vyvíjí nástroj, a pokračuje na opravě chyb a jeho ladění v rámci tvorby a exportu, a také se podílí na vývoji databáze; 2) Mr Kura, který je odpovědný za sestavování vlaků v oblasti Krakówa a CMK, který také poskytl neocenitelnou pomoc při sestavování jízdních řádů a dbá na jeho striktní dodržování, aby vlaky skutečně jezdily na čas; 3) Marcion, který je odpovědný za sestavování jízdní řádu v oblasti Łódź – ze Żyrardów do Piotrków, Zgierz a Sieradz; 4) Królik Uszasty, který je odpovědný za osobní vlaky v oblasti Katowic a směruje vývoj aplikace praktickým a užitečným směrem. Tímto bych chtěl také poděkovat Moooritz, který pracuje na řazení vlaků u nových vlaků. Díky souběžné práci, zjednodušení přidávání nových vlaků a efektivnějšímu provádění oprav jsme nyní schopni mnohem rychleji reagovat na vznikající problémy – zejména na ty méně závažné, jejichž řešení dříve trvalo dlouho. Doufáme, že se Vám nový jízdní řád bude líbit a že bude sloužit jako pevný základ pro další budoucí rozvoj.