All Activity

W moim przypadku, wygląda na to, że wyjątkowo, update ten i rozwiązanie strumieniowania tekstur, rzeczywiście zadziałało. Wcześniej przejazd przez Warszawę (w szczególności Centralną), to były ścinki i spadek FPS'ów do 10-20. Ogólnie, to pamięć VRAM wiecznie pełna, a nawet ponad limit (według nakładki Steam). Teraz? Z włączonym strumieniowaniem na średnim poziomie przejechałem całą Warszawę bez ani jednego zauważalnego dłuższego przycięcia (było jedno, ale bardzo króciutkie). Liczba klatek też była całkiem niezła, bo poniżej 35 nie spadła, a nawet większość czasu utrzymywała się na poziomie ponad 55. Generalnie, dla mnie to rozwiązanie się sprawdziło. Dodam jeszcze specyfikację kompa i ustawienia, jeśli by to kogoś interesowało: AMD Ryzen 7 7800X3D RAM 32 GB Nvidia RTX 3060Ti Ustawienia wrzucam w postaci screen shotów.

Dziś postanowiłem sobie pojechać ten scenariusz Smokiem (ET25). I ja miałem dokładnie taki sam przypadek. Podłączyłem się w Bukownie pod zdefektowany skład, ręczny w EU07 zwolniony. Ruszyłem, wyjechałem kawałek z Bukowna, zdążyłem się rozpędzić do 40 km/h. Pociąg nagle zniknął, a ja spadłem na tory w szczerym polu 😂 Pociąg się nie wykoleił, scenariusz trwał dalej. Ale nie wiedziałem w którą stronę pójść i wyszedłem... do głównego menu. W podsumowaniu był komunikat "Przerwałeś scenariusz". SimRail_log_2026-04-25_18-15-57.txt

No nie jednak muszę się poprawić... Mój Intel 8gen i7 (proc laptopowy z roku 2018/19) 12M RAM + GTX1050 mob., 2GB VRAM - z aktywnym mimpap (ustawionym na minimum) nie ładuje Skierniewic w trybie dyżurnego. (znaczy zaczyna, ładuje, trwa to 4 minuty, a potem się zawiesza, trzeba ubijać żeby wyjść). Z tradycyjnym ustawieniem 1/2 rozdz. tekstur, na tych samych ust. odległości i jakości (1920x1080, najlepszy antyaliasing jaki się da ustawić, 500m odl. rysowania wszystkiego, 160m ludzi, 0 samochodów i zero trawy) - ładuje Skierniewice dyż. w 1.5 minuty (oba testy na tym samym serwerze INT3 jakieś pół godziny temu). Nie aktywowałem LS w żadnym powyższym przypadku i nie sprawdzałem FPSów. Konfiguracja działająca wydawała mi się dość płynna w animacji poruszania (spoglądanie w różne strony za pomocą myszy) i dość responsywna/szybka (nie 'spóźnialska') w przełączaniu się na widok rozkładu jazdy-widok dyżurki-widok ekran(ów) urz. komputerowych. Obie opcje 'nabijają' VRAM do pełna jak się patrzy na Task Manager. (rozdzielczość 1920x1080 bo mam podłączony do wyjścia HDMI dość duży telewizor i z dowolną inną nie-natywną rozdzielczością wygląda jeszcze gorzej)

Cześć, na wstępie gratuluję świetnych scenariuszy - podziwiam i doceniam Twoją robotę. Dwa razy próbowałem przejechać scenariusz i dwa razy nie dostaję wyjazdu z Zawiercia. Przesyłam logi do sprawdzenia w wolnej chwili. Tym razem wybrałem wersję bez zdarzeń losowych i bez dodatkowych manewrów. SimRail_log_2026-04-25_07-38-45.txt

Oświetlenie pulpitu nawet po maksymalnym ściemnieniu pozostaje bardzo jasne i w warunkach nocnej jazdy męczy. Czy nie dałoby się zejść z minimalną jasnością w dół?

Rozruch jak rozruch, ale brzęczyk! Tak czy inaczej, byłoby miło gdyby deweloperzy ustosunkowali się tutaj, czy można liczyć w temacie na coś czy nie.

It looks great! It would be great if there were an option to select station X and display only your own node – centred on the screen – along with the neighbouring nodes on either side in that view 🙂

Nie wiem czy ten błąd występuje tylko u mnie ale kiedy robiłem ten scenariusz to żadna stacja nie podawała wjazdów, więc gdy byłem podpięty z wagonami GWARKA to musiałem zakończyć scenariusz bo bot wysyłał mnie na tor niby wolny ale stał tam już inny skład. Później to i ja już stanąłem, ponieważ jakiś manewrujący skład stał na wprost mnie i nie podawało mi przebiegów

Incredible!

Przecież takie sytuacje zawsze weryfikuje rynek, więc nie widzę powodów do zmartwień. Przyszłość symulatorów, kolejny poziom, to AR z hardwarem (mixed reality) https://fb.watch/GG1UeANw5O/ Na razie tak bawi się wojsko oraz komercyjne projekty wysokobudżetowe , a może za parę lat my konsumenci.

Bloody hell, Mate, that looks great!

Dziękuję za tę szczerość po raz kolejny – w końcu wiemy, że ograniczenia nie są techniczne, lecz wynikają z paranoi biznesowej. To fascynujące, że SimKol traktuje każdego hobbystę budującego pulpit jako potencjalnego szpiega przemysłowego. W świecie cywilizowanego biznesu istnieje coś takiego jak ochrona prawna własności intelektualnej. Istnieją mechanizmy licencyjne, patenty i sądy, które potrafią skutecznie dyscyplinować podmioty wykorzystujące czyjąś pracę niezgodnie z przeznaczeniem. To, co Pan opisuje, to skrajnie posunięta asekuracja, która świadczy o głębokim braku zaufania do polskiego systemu prawnego oraz własnych możliwości egzekwowania swoich praw. Zamiast korzystać z narzędzi prawnych, nakłada się kaganiec wszystkim użytkownikom. P.S. Pan wybaczy, ale uwaga o "walidowaniu symulacji konkurenta w oparciu o Pana pracę na rzecz MaSzyny" – brzmi bardziej jak chęć pochwalenia się osobistymi osiągnięciami niż merytoryczny argument w tej dyskusji.

Wow, that looks absolutely amazing!!!!! 😗

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.

To zdanie powinno być drukowane na każdym "pudełku" i ekranie ładowania. To rzadki przypadek, gdy producent oficjalnie przyznaje: naszą największą obawą jest to, że nasz produkt mógłby być za dobry. To nie jest kwestia techniczna, to czysta arogancja i strach przed pasją własnych klientów. Nie mieści mi się to w głowie, jak można tak podchodzić do klienta. Przykro więc patrzeć, jak społeczność zamiast żądać odblokowania potencjału, za który zapłaciła, zajmuje się polerowaniem łańcucha, na którym ją uwiązano. No ale "volenti non fit iniuria" (chcącemu nie dzieje się krzywda).

Szanowny kolego, jeśli nie życzysz sobie udziału osób trzecich w ogólnej dyskusji, to dam Ci prostą, acz bardzo skuteczną radę - skorzystaj z wiadomości prywatnej. Stwierdzenie, że SimRail ma prawo decydować o tym, jak dysponuje prawami do produktu jest stwierdzeniem faktu, a nie reprezentowaniem interesów firmy -> jeśli uważasz, że firma nie ma prawa dysponować swoim produktem wedle uznania, to uzasadnij, a nie imputuj mi kolejne bzdury. Co do kwestii samej wypowiedzi,, Twojego pouczania, całe szczęście, że Szanowny Kolega jest jeno zwykłym użytkownikiem 🙂 Chcesz powielać kłamstwa, półprawdy - Twoja sprawa, ja w tym zakresie będę to weryfikować i podkreślać, że ignorancja nie zwalnia od śmieszności wypowiadającego.

Szanowny kolego @error723, oczywiście masz się prawo wypowiadać, tak jak ja napisać swoją opinię, ale ewentualnej odpowiedzi oczekiwałem od osoby, do której wyraźnie zwróciłem się w swoim wpisie. Nie widzę aby Twoje konto forumowe miało opis jako członka zespołu SimRail. Nie wiem więc dlaczego wypowiadasz się w takim tonie, jakbyś reprezentował interesy firmy. Jeśli SimKol, na który się powolujesz udzielił Ci takich pełnomocnictw, to nic mi o tym nie wiadomo, więc proszę się nie wypowiadać w kwestiach prawnych dotyczących tego symulatora.

Argument, by ktoś samodzielnie nie zrobił symulatora na podstawie gry nie jest kuriozalny - jeśli chcesz pełny symulator, zgłaszasz się do Sim-Kol jako właściciela projektu oraz posiadacza praw do tegoż projektu, zawierasz umowę i płacisz za wykonanie usługi. Jeśli nie rozumiesz tego, że SimKol ma prawo do decydowania o formie zarabiania na własnym produkcie, to nie wiem jak Ci to wytłumaczyć. Nie ma kagańca na MQTT, jest udostępnienie tego co masz w grze, tylko zamiast korzystać z klawiatury, będziesz mógł sterować pojazdem przy pomocy własnych modułów. Mało znalazłeś, wystarczyło zajrzeć na strony mqtt i sprawdzić tworząc prosty broker oraz subskrybenta -> rabbitmq pokazuje w jaki sposób to stworzyć, krok po kroku. Możesz obciążyć kolejkę wedle uznania (daj 5 subskrybentów) i sprawdź zanim napiszesz coś podobnego, powtarzając po przedmówcy, który ciągle szuka właściwego "kalkulatora" do przeliczenia ileż to taktów zejdzie procesorowi na obrobienie ramek. Mało tego, nie zweryfikowałeś jaka jest architektura tegoż protokołu, ale piszesz o łatwiźnie i "kroplówce" danych. Po co? To, że interfejs MQTT pozwala na znacznie prostszą (dla człowieka) prezentację danych jest bezsprzeczne. Piszesz o zaawansowanym protokole, a jakie masz z nimi doświadczenie na co dzień? I powiedz mi, posty na forum piszesz binarnie i komunikujesz się po jakimś ukrytym API czy używasz zaawansowanego protokołu, który pozwala bez problemu nie tylko tworzyć, ale i odczytywać wiadomości? I może bardziej dosadnie -> łapiesz konie na łące i jeździsz na oklep, czy używasz tej zaawansowanej technologi jaką jest motoryzacja? Wybór protokołu komunikacyjnego i forma wystawionego API została podjęta po uzgodnieniach z społecznością na kanale discord - w dyskusji wzięło udział wielu konstruktorów o mniejszym lub większym zrozumieniu tematu, ale zdecydowana większość uznała to za najlepszy pomysł (nawet w tym temacie jest mój post, który zaprasza do dyskusji - było to ponad pół roku temu). Bicie piany dzisiaj i manipulowanie niesprawdzonymi lub błędnymi danymi ma służyć chaosowi? Czy może jak napisał Królik, jeden "pasjonata" ma wywrócić wszystko do góry nogami bo takie ma widzimisię? MQTT jest znacznie bardziej zaawansowanym protokołem bo jest nowszy, a obecnie pozwala już na stosowanie w warstwie 1- https://www.bevywise.com/mqtt-usecases/manufacturing-solutions.html . Te rozwiązania oparte są nie tylko o szereg badań, ale także wdrożenia. Ponownie, zweryfikuj swoją wiedzę, zanim będziesz pisać o brokerach MQTT jako "zasobożernych silnikach" - postaw serwer w dockerze i zmierz ile faktycznie wymaga zasobów... Naprawdę, warto najpierw poczytać, zweryfikować i samodzielnie sprawdzić bo czasem może się okazać, że piszemy o czymś o czym nie mamy pojęcia z pełnym przeświadczeniem swoich racji - nikt nie jest od tego, by Ci wyjaśniać zasady działania i jeśli chcesz rzucać półprawdy, niedomówienia czy niesprawdzone "mity" i opierać o to twierdzenia o "wykastrowanie", "zasobożerność" czy pozostałe, to z pewnością, nikt nie będzie także chętny by pomagać Ci w zrozumieniu czym to jest. Zdobywanie wiedzy polega na weryfikacji i pytaniu, a nie oskarżaniu i rzucaniu nieprawdziwych tez by inni je weryfikowali.

Nowa wersja 1.6.18 (link do ręcznego pobrania: 44_patwrobel.7z) -drobne poprawki w Misji 5 i 6 @Masterczulki zawiera poprawkę błędu, który znalazłeś w Zgierzu

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.

Ad @Królik Uszasty "Dziękuję za szczerość – to, co Pan napisał, rzuca bardzo ciekawe światło na architekturę SimRail, ale buduje też niepokojący paradoks. Z jednej strony słyszymy o 900 parametrach które gra musi przeliczać. Z perspektywy gracza to ogromna „nadmiarówka”. Skoro te parametry obciążają nasze procesory, a gra zajmuje już ponad 100 GB, to dlaczego nakłada się na nas sztuczne ograniczenia? To sytuacja typu lose-lose: płacimy zasobami naszego sprzętu za niezwykle złożoną symulację, z której potencjału nie możemy w pełni skorzystać przez kagańce nakładane na MQTT. Argument, że ogranicza się dane, by „ktoś nie zrobił sobie z gry symulatora”, jest kuriozalny w produkcie sprzedawanym pod szyldem „The Railway Simulator”. W świecie symulatorów lotniczych (MSFS, X-Plane) otwartość na skomplikowane systemy buduje rynek. U Was widać lęk przed tym, by gra nie stała się zbyt dobrą konkurencją dla Waszych własnych rozwiązań B2B. Co do wyboru MQTT – na podstawie informacji które znalazłem w necie, ale także tych pochodzących z dyskusji w tym wątku, argument o „optymalności” MQTT brzmi mało przekonująco, a wręcz jak wykręt. Wybór tak zaawansowanego protokołu przy jednoczesnym dawkowaniu danych „kroplówką” wygląda na technologiczne pójście na łatwiznę. Odnosi się wrażenie, że po prostu przenieśliście gotowy moduł z wersji profesjonalnej do gry, bo tak było najtaniej, a teraz sztucznie go blokujecie, by chronić swoje interesy biznesowe. Narzucacie nam ciężkie rozwiązanie sieciowe, jednocześnie odcinając nas od parametrów, które nasz sprzęt i tak musi w tle przeliczać. Wygląda na to, że dostajemy zasobożerny silnik z profesjonalnego trenażera, który został celowo „wykastrowany”, zamiast wspierać pasję społeczności. Szkoda, bo to właśnie tacy „hardkorowi” hobbyści budujący pulpity są najlepszą reklamą każdego szanującego się symulatora."

You probaly need to adjest the code, that sets the exit signal for the removed platform stops. Could you indicade, what scenario you are editing and what stops you want to taje out? Then I can give you an example on what to do.

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ł.

Jak dla mnie (niech mnie ktoś poprawi jeśli się mylę) - chodzi o to, że tradycyjnie, interfejsy sprzętowe (dla ułatwienia zawęźmy że w pecetach) rzadko mają wsparcie dla warstwy 3-4-5 modelu OSI (jak mają buforowanie jak RS232 to jest dobrze, jak mają adresowalne endpointy jak USB na urządzenie (wiedza z 'generycznej' implementacji USB na PIC18xxx), a np. z tego co pamiętam o MIDI to po prostu jest specyficznie skonfigurowany port szeregowy. Czyli wszystko to działa jak 1-2 warstwa OSI (fiz i MAC dla porównania). Jak się chce mieć wsparcie dla czegoś bardziej skomplikowanego, kolejkowanie (...yyy...), zarządzanie przepustowością, zarządzanie opóźnieniem, zarządzanie kolejnością, to każda aplikacja implementuje to po swojemu i w zamknięty, nieprzejrzysty, 'czarna skrzynka' sposób (od 'prostego' podjeścia typu wyślij ramkę jak nacisnę klawisz na klawiaturze muzycznej albo sequencerem MIDI, do 'wyślij tę ramkę do tego endpointu na tym urządzeniu USB ) (a jak są do tego biblioteki, to każdy twórca robi je po swojemu, niekoniecznie optymalnie) Ale (i znów, jak się mylę to proszę mnie poprawić) nie można _standardowo_ wydać polecenia 'wysyłaj te konkretne dane do tego urządzenia cyklicznie jak się będą zmieniać, a ja nie chcę tego co chwila sprawdzać, co najwyżej jakby "byly blady" ' albo 'wyślij to i obudź mnie jak będzie odpowiedź' itp. Czyli można porównać MQTT do IP, TCP/IP, UDP dla sieci bardzo lokalnej dla 'małych urządzeń'. (wyobrazić również można by sobie np. masz manipulator typu 'joystick' do kranu hamulca na gameporcie analogowym, manipulator typu 'kierownica' (xD) do przepustnicy 4E/303E po USB, przerobiony keyboard MIDI albo coś własnego łączącego się po MIDI, do przycisków, hebelków światełek i wskaźników zegarowych i teraz chcesz to razem spiąć tak, żeby nie musieć pisać obsługi tego wszystkiego w samej grze...)

Just as a curious question: Why is that? I'm especially looking forward to the DLC Zgorzelec - Dresden, where it is common for trains in reality to end in Bischofswerda or Görlitz and continue in reverse onto the next journey or into the yard. I guess you'll just don't implement this and let every train run the full line between Dresden and Zgorzelec, but ending trains would be way more realistic and fun. E.G. it could be possible that the job ends a few seconds after opening the doors at the final stop, and the retour journey becomes playable five minutes before departure.