Królik Uszasty

Could you provide more details, please? I cannot reply without knowing more about what happened.

Wykaz ostrzeżeń stałych został przygotowany przez użytkownika P.Wiśnia i jest udostępniony na jego stronie https://simrail.pl/ w zakładce Baza danych -> Lista PDF.

Wstępnie poprawione, czekamy na aktualizację API.

Cześć, od strony technicznej (kolejowej) sprawa wygląda tak, że wyłączone lokomotywy mają otwarte zawory czuwakowe (zawory bezpieczeństwa). Powoduje to, że po dezaktywacji kabiny/wyłączeniu baterii tracą one zasilanie i się otwierają, opróżniając przewód główny. Powoduje to, że nie ma możliwości napełnienia przewodu głównego takiej lokomotywy, bo powietrze od razu ucieka do atmosfery. Żeby temu zaradzić stosuje się dwojakie rozwiązania: albo przełącza lokomotywę w tryb holowania przy włączonych bateriach - zasila się zawory, żeby były zamknięte, albo przełącza się ją w tryb holowania bez zasilania - zawory wtedy odcina się mechanicznie, żeby powietrze nie uciekało. Na chwilę obecną w SimRail możesz ciągnąć na zimno wyłącznie dwie lokomotywy: 1) EU07 w trybie włączonych baterii - po załączeniu baterii należy w kabinie A przestawić przełącznik jazda pociągowa-jazda ciągniona (za maszynistą) na pozycję jazda ciągniona, 2a) ET22 w trybie włączonych baterii - po załączeniu baterii należy przestawić w szafie elektrycznej (chyba za kabiną A) ten sam przełącznik na jazdę ciągnioną, 2b) ET22 w trybie na zimno - bez załączania baterii należy znaleźć zawory kulowe czuwaka, które należy zamknąć. Dragon i TRAXX nie mają w tym momencie maszynowni, w której można by dokonać stosownych przełączeń. CD163 czeka na aktualizację, która również umożliwi ciągnięcie jej na zimno. Być może udałoby się to już teraz, gdyby przestawić przełącznik jazda pociągowa-jazda ciągniona na pulpicie kabiny A w pozycję jazda ciągniona, co wyłączy czuwak i SHP. Oczywiście w każdym przypadku hamulec maszynisty przestawiamy w odcięcie. Kwestia włączenia/wyłączenia samego hamulca lokomotywy jest kwestią odrębną, aczkolwiek obecne przepisy wymagają, aby pierwszy i ostatni pojazd w składzie miał czynny hamulec.

Dla pociągu 17017 założona prędkość rozkładowa wynosi 120 km/h, stąd dobór lokomotywy EP07 jest poprawny. Pociąg ten nie ma kolizji z innymi na całej swojej drodze, stąd zarzut brak należytej staranności w ramach możliwości symulatora jest bezzasadny.

Dziś wieczorem pociągi powinny się już pojawić na PL3 i pozostałych serwerach.

Pociągi powinny usunąć się samoczynnie po restarcie API w nocy. Zmiana rozkladu w ciągu dnia (rano przed resetem) niestety nie usuwa pociągów z EDR. Postaram się kolejnym razem na podegranie rozkładu bliżej północy.

Rozkładowo pociąg 3108 powinien przyjechać na tor 2 przy peronie VI, najprawdopodobniej sytuacja ruchowa musiała wymusić zmianę peronu - wjazd pociągu 4506 i zajęte odcinki izolowane w przebiegu na tor 2, co na etapie podawania wjazdu spowodowało wybór wolnego toru, na który dało się podać przebieg szybciej.

Rozkłady jazdy zostały wygenerowane i są dostępne w grze.

Wiemy, pracujemy nad rozwiązaniem.

W poprzednim paczu została zmieniona metoda wyliczania HDR i ekspozycji - ustawiono większą wagę na środek ekranu.

Problem fixed with realeas of the new timetable.

This is by design. The dialogues between dispatcher and driver are static, always mentioning intended train parameters and locomotive. Number of possible combinations is constatly growing with each locomotive or wagon. It might be rather simple to make interactive chat messages, but the problem occurs with sounds. We will not classify this as a bug, but we will talk this over.

Dokładnie, jedno i drugie wygląda na skyboxy - modele z nałożonymi statycznymi obrazkami chmur, ewentualnie z możliwością przechodzenia między obrazkami. Na pewno wyglądają genialnie, bo odtwarzają idealnie 1:1 kształt chmur określonego typu na podstawie zdjęć, natomiast to nie jest system dynamicznego i animowanego nieba, jaki mamy teraz w SimRailu.

@RWag64 what about https://api.simrail.eu:8082/api/getAllTimetables?serverCode=fr1&train=4516?

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.