Mywasher

Co jest niesmaczne? Wskaż mi to konkretnie palcem. Bo zaczyna robić się nieśmiesznie. Bardzo nieśmiesznie. Kto nie testował obciążeniowo MQTT na różnych platformach ten nie wie co to życie. Tak na poważnie nawet Facebook ma systematycznie kłopoty ze swoim brokerem, ale to pewnie przypadek bo mają za mało zasobów. Z całym nadmiarowym narzutem oraz zupełnie niepotrzebnym ograniczaniem przepływu danych. Z poziomu sterowania enkoderem, ile komunikatów chcesz wysłać do brokera o zmianie zadajnika z pozycji +100 do -100 aby utrzymać odczucie liniowości z tak samo liniowym feedbackiem? Bo rozumiem, że skoro ma stać MQTT to wypchniecie do niego wszystkie parametry, które są wizualizowane w kabinach, i pozwolicie pchać w broker co najmniej 8 bitowe wartości analogowe z urządzeń sterowania. CAN z definicji ma swoje ograniczenia już na warstwie fizycznej, które obijają się na jego "przepustowości" więc nie wiem jak się to ma do całkiem ciekawego sterowania przez pośrednika, a sterowaniem I/O do samego silnika. Że niby magistrala rozgłoszeniowa? MQTT nie działa deterministycznie. To jest jego uroda.

Bo idea powinna być prosta, niskolatencyjna, efektywna i wspierana natywnie przez system operacyjny. Spośród wielu gotowców, które są dostępne i łatwe do wdrożenia najlepiej wypada właśnie MIDI. Możemy sobie to potwierdzić w bardzo przystępny sposób wpisując takie coś w yT: Gwarantuję Ci, że gdyby był to protokół zawodny i obarczony co najmniej "takimi zaletami" jak MQTT to żadna normalna osoba nie próbowała by grać muzyki na żywo za pomocą komputera. Stworzenie kontrolera MIDI w oparciu o RPi/ARDU/ESP to banał w obecnych czasach. Ja trzymam się rękami i nogami tego, że to co robię musi być natychmiastowo przetwarzane - koniec i kropka. Opowiadanie o tym, że MQTT uratuje sprawę to najwyższy poziom ucierania dupy szkłem o jakim słyszałem w branży gier od dekady.

Tobie to nic nie muszę udowadniać, swoją niekompetencję już uwiarygodniłeś więc nie baw się w emocjonalne przebłyski, że ktoś tu czegoś nie zrozumiał. Jedyną osobą, która nie rozumie złożoności sytuacji jesteś Ty sam i jest to na swój sposób smutne bo nawet nie masz cienia wątpliwości, że MQTT to najgorsze możliwe rozwiązanie w tym zakresie.

Bardzo lubię teoretyków z maniakalnym zacietrzewieniem w stronę rozwiązań, które z nieoczywistych dla ludzi spoza branży automatyki przemysłowej, wyglądają ładnie w teorii. To co dla Ciebie jest namiarowością i jakimś dziwnym utrudnieniem dla mnie jest bezpieczeństwem i stabilnością. Odwróćmy więc role: ile zaawansowanych technicznie projektów o wysokim poziomie niezawodności wdrożyłeś w oparciu o MQTT? Pytam z czystej ciekawości bo jednak Modbus RTU, pętle prądowe czy magistrale szeregowe są stosowane powszechnie w automatyce, a MQTT to raczej w smart home'ach. W zakresie sterowania urządzeń/maszyn chyba nikt normalny by tego nie zastosował bo szkoda oglądać słońce przez kraty. Implikujesz nam, a w zasadzie próbujesz zrealizować incepcję, że MQTT to panaceum na całe zło świata i tylko idioci korzystają z klasyki typu DMX, Modbus RTU, MIDI, a to całkiem zabawne bo jakoś Vectrny, Gammy, Elfy, pojazdy z dwiema kabinami to idealne pole do wdrożenia brokera... a nie, wróć, hahaha 🙂 Jeszcze dla udowodnienia drobnego szczegółu bo chyba coś komuś umknęło: MIDI od zarania dziejów obsługuje komunikaty SysEx... i one mogą mieć dowolną długość... w MIDI 2.0 masz w prezencie natywność systemową, 32 bitową rozdzielczość i pełną dwukierunkowość. MIDI to protokół binarny z minimalnym narzutem, w stosunku do MQTT praktycznie zerowym. Nie dalej jak wczoraj wieczorem czytałem, że wszystko na multi laguje, że nawet na singlu są jakieś kłopoty z optymalizacją... i w ten caly średnio wydajny grajdołek, chcemy wstawić broker czekający aż silnik wypluje z siebie dane lub ewentualnie je przyjmie? Ile symulatorów w których liczy się imersja korzysta z MQTT do obsługi peryferiów? Może coś z F1? Flightsimulator? Czy sobie przepiszę wypowiedź z Geminii żeby była bardziej spójna i logiczna, czy napiszę z palca to nie ma znaczenia bo liczy się merytoryka podparta zrealizowanymi projektami. BTW, szybciej na Ardu odpalę precyzyjny kontroler midi niż Ty zapewnisz mi że ostatni payload jest w aktualnym stanem, a nie tylko ostatnim zapamiętanym stanem (retain flag).

Jeroezie, I understand your perspective as a dispatcher. For you, mixed traffic is a puzzle to solve. But you have to remember that SimRail is also a driving simulator. When a dispatcher decides to 'have fun' by putting a 100 km/h cargo train right before a 200 km/h EIP, the driver's experience is completely ruined. For the driver, the 'fun' is not just seeing green lights—it's the challenge of maintaining speed, managing the energy, and following the ETCS indications precisely. When we are forced to stare at yellow signals or stop in the middle of nowhere for 20 minutes, there is no 'gameplay' left for us. We are just sitting in a virtual cabin doing nothing. You say the Pendolino is 'boring' to look at, but for many of us, it’s the main reason we play this game. The CMK is the only place in SimRail where we can actually use the high-speed capabilities of the ED250. If every line in the game becomes a 'mixed traffic mess,' then the CMK loses its unique identity. Also, the argument that 'cargo drivers don't complain' is a bit of a stretch. Ask any freight driver how they feel about being sided for 30 minutes in Pruszków. They are frustrated too. The problem is that the current timetable tries to fit too much into a map that is still missing its vital 'relief' routes like the full LK1 (Wiedynka). We don't want a boring game, but we want a logical one. A dispatcher’s 'interesting shift' shouldn't be built on the frustration of every driver on their section

Nie wiem w jakiej branży wy siedzicie i sumie mi to lotto bo akurat ja zajmuję się automatyką przemysłową i budynkową od raptem 15 lat więc tak, MQTT ROX bo przecież Wy już wszystko widzieliście, i z całą pewną pewnością automatycy to debile dlatego w poważnych tematach NIC nie opiera się o MQTT. O sieciach komputerowych dużo więcej dowiadywać się nie musicie ale pojęcie metafory powinniście przyswoić ASAP.

Maciej, I appreciate the open dialogue and I understand the challenge you face. With a limited map and resources, you’re trying to satisfy everyone, but as we say in our country, trying to wipe your backside with broken glass – making painful, makeshift compromises – is rarely the best way forward. In my view, the 'boredom' on the CMK isn't a design flaw; it’s a realistic feature of a high-speed line. The real reason dispatchers are crowded there is that the CMK currently offers the most (or only) playable signal boxes for those who want to manage traffic [low or the lowest level of difficulty escpecially for beginers]. A better long-term solution would be to complete the network of playable signal boxes on the existing lines or, eventually, implement the full 'Wiedynka' (LK1) with all its stations. If dispatchers had a wealth of complex stations to choose from on other lines, they would naturally go there for the 'action.' Even if that meant a slightly lower overall train count in the timetable, the quality of the simulation and the realism of the traffic would be much higher. We don't need to 'mask' the lack of alternative routes by forcing a chaotic mixed-traffic during the day on the CMK. Let’s focus on providing dispatchers with the complex environments they crave on lines where that traffic actually belongs, while keeping the CMK as the high-speed corridor it’s meant to be. This way, we satisfy everyone without sacrificing the primary purpose of the EIP/EC runs. Pozdrawiam Miłosz 😉

Porównywanie MQTT do MIDI w kontekście lokalnego kontrolera do symulatora to jak próba udowodnienia, że wysłanie listu poleconego przez urząd pocztowy jest szybsze niż przekazanie komendy głosowej osobie obok, bo 'nie trzeba używać strun głosowych'. Determinizm i Latencja (Timing): W symulatorze, zwłaszcza przy obsłudze hamulca czy syreny, liczy się każda milisekunda. MIDI (szczególnie po USB/Serial) jest protokołem niemal czasu rzeczywistego, o stałym i przewidywalnym opóźnieniu. MQTT opiera się na stosie TCP/IP i Wi-Fi/LAN. Masz tu narzut nagłówków, retransmisje, mechanizmy potwierdzeń i – co najgorsze – jitter (zmienne opóźnienie). Wystarczy, że sąsiad włączy mikrofalówkę albo telefon zacznie synchronizować zdjęcia, a Twoja 'pozycja 4' hamulca dotrze do symulatora z lagiem, który wyrzuci Cię poza peron. Single Point of Failure (Broker): Sugerowanie, że MQTT pozwala 'nie zarządzać kolejką', to absurd. Zamiast bezpośredniego połączenia urządzenie-gra, wprowadzasz pośrednika (brokera), który musi działać, być stabilny i mieć niskie obciążenie procesora. Jeśli broker złapie 'czkawkę' albo padnie usługa, Twój pulpit staje się bezużytecznym meblem. MIDI/HID to połączenie punkt-punkt: proste, pancerne i bezawaryjne. Zasilanie i 'Zero Kabli' to Mit: Każdy, kto budował zaawansowany pulpit, wie, że 'bezprzewodowość' kończy się tam, gdzie zaczyna się podświetlenie przycisków, diody LED stanu pojazdu (feedback) czy serwomechanizmy wskaźników. ESP32 na baterii 18650 przy aktywnym Wi-Fi padnie po kilku/kilkunastu godzinach intensywnej jazdy. I co wtedy? Podpinasz kabel... do ładowania. Czyli wracasz do punktu wyjścia, tyle że z mniej stabilnym przesyłem danych. Kompleksowość stosu vs Prostota: MIDI to standard Class Compliant. System operacyjny widzi go natywnie. MQTT wymaga warstwy software’owej, która te dane odbierze z sieci i wstrzyknie do gry (np. przez emulację klawiatury lub API). To kolejna warstwa, która może się zawiesić. MIDI wysyła 3 bajty i sprawa załatwiona. ESP32 potrafi obsłużyć MIDI po USB równie łatwo jak MQTT, ale bez narzutu całego syfu sieciowego. Standardy branżowe: MIDI nie przetrwało 40 lat dlatego, że 'ludzie się nie rozwijają'. Przetrwało, bo jest nie do zajechania pod kątem stabilności w przesyle zdarzeń on/off i wartości analogowych. W profesjonalnych symulatorach lotniczych czy kolejowych nikt nie bawi się w brokery wiadomości do odczytu przycisku 'czuwaka', bo to proszenie się o katastrofę. MQTT to świetne rozwiązanie do podlewania kwiatków w ogrodzie albo sprawdzania temperatury w lodówce z drugiego końca miasta. W sterowaniu maszyną, gdzie liczy się responsywność 'tu i teraz', lokalny interfejs MIDI/HID bije MQTT na głowę pod każdym względem technicznym. Budowanie 'modułów' na Wi-Fi to overengineering, który rozwiązuje problemy, których kabel USB po prostu nie generuje. Nawet w profesjonalnej automatyce trzymamy się od MQTT w miarę daleko bo nigdy nie wiesz czy to co widzisz to aktualny stan, czy ostatni stan.

Maciej... Macieju... I appreciate the detailed technical insight, but I have to strongly disagree with the current design philosophy. The 'CMK trap' we are seeing in the game cannot be solved by—as we say in Poland—'trying to wipe your backside with broken glass' (ucieranie dupy szkłem). It’s a painful, makeshift solution to a fundamental problem. If dispatching on the CMK is boring, it's because the line is working as intended—it’s a high-speed transit corridor, not a shunting yard. Forcing 100 km/h cargo trains into the path of 200 km/h Pendolinos just to 'give dispatchers something to do' is artificial difficulty that ruins the experience for drivers. The real solution isn't to mess up the CMK's schedule, but to provide a proper environment for mixed traffic: Line 1 (LK1 via Częstochowa). That is where EN57s and heavy cargo belong. There, the 'fun' for dispatchers comes naturally from the density of stations and diverse rolling stock, not from forcing a tractor onto a highway. If you want cargo on the CMK, move it to the night slots (10 PM – 6 AM). That would be realistic and would give night-shift dispatchers the challenge they crave, while leaving the day for high-speed runs. Don't sacrifice the primary purpose of the CMK just to mask the fact that the map is currently missing the necessary alternative routes.

In 2026, real dispatching on the CMK should be as boring as watching paint dry. To be honest, the only window to push freight trains through should be at night, from 10 PM to 6 AM. In reality, a dispatcher can’t afford to delay a high-priority train (EIP/IC) — if they do, their head will roll. The root cause of this problem lies in the lack of a viable alternative route in the game's current map. Without a fully operational Line 1 (via Częstochowa) to handle the bulk of the freight traffic between Central Poland and the South (Kraków/Katowice), the CMK is forced to swallow everything. In the current SimRail reality, we are stuck with a frustrating choice: either endure the daily nightmare of slow cargo blocking a high-speed line, or remove freight altogether and go back to 'watching paint dry' while dispatching.

Częściowe rozwiązanie Twojego problemu jest tutaj: SimRail.PL - Nadchodzące pociągi

Nie zmieniam swojej opinii, że najprostszą opcją, dającą sensowną unifikację na poziomie I/O z zachowaniem sensownej rozdzielczości i łatwości wdrożeniowej jest wprowadzenie obsługi MIDI... To już przetestowana wielokrotnie opcja, począwszy od branży eventowej, a skończywszy na produkcji muzyki.

I tak, i nie. Życie pokazało już wielokrotnie, że z 1 tekstury można teksturować modułowo wiele modeli, a tu głównie o to się rozbija.

Teraz spojrzałem, że dobiliśmy do 15 stron... co też mają w głowach pracownicy i podwykonawcy firmy czytając tyle merytorycznego linczu słownego... tego nie wie nawet moja żona, a możecie wierzyć, że moja żona wie WSZYSTKO lepiej.

Nie widziałem kodu źródłowego ale mam dysonans poznawczy bo weźmy na szybko osobę Króliczastego Specjalisty Fizyki Zwłaszcza Hamulcowej. KSFZH ma wiedzę, umiejętności i świadomość czego nie robić aby było dobrze. Jeśli nikt nie narzeka na SPKS to znaczy, że 14 lat doświadczenia wystarczyło żeby zrobić to dobrze nawet w Unity. Taki developer to skarb na miarę worka złota. W kontrze do tego mamy cuda dziejące się z botami ogarniającymi SRK, cuda cudów (godne wycieczki do miasta świętej wieży) z naprawą zgłoszonych milion razy błędów (w tym krytycznych), zerową komunikację z nabywcami będącymi testerami, system generowania terenu, który nie może wygenerować reszty trasy do Krakowa, wdrażanie parowozu jako ekologiczny postulat wobec lokomotyw spal-ele... no i prawie zapomniałem o tragikomedii na miarę wzajemnej uznawalności wyroków TK i SN vide optymalizacja grafiki. Przeciętnie świadoma osoba ma rozdwojenie jaźni.

Można odnieść wrażenie, że kasa z początkowego "hajpu" została przeżarta zanim udało się zapłacić za robotę potrzebną do skończenia obietnic. Milionowe przychody to wciąż nie dochody... a developerom płacić trzeba. Trudno uwierzyć, że ludzie zebrani z innych projektów pokroju Maszyna, TD2, Tainz są tak słabi merytorycznie żeby wdrożyć krytycznie złe rozwiązania, które teraz związały ręce w zakresie czegokolwiek albo wręcz wszystkiego. Sprawa z DLC wygląda trochę jak sprawa z Amber Gold - ot jazda na deficycie i egzystowanie na kolejnych, którzy uwierzyli w opis produktu. To tylko moje przypuszczenie ale póki co trzeba czekać na aktualizacje danych Aleo żeby ocenić kondycję twórców. Sprawozdania finansowe nie mówią wszystkiego ale przynajmniej nie kłamią. Tak jak na początku byłem podjarany, że dostałem Maszynę po mefedronie tak teraz widzę bardziej mefedron po maszynie...

Spójrzmy prawdzie w oczy, głównym hamulcowym projektu jest sam "twórca" aka Simkol bo, to tylko moje przypuszczenie, brak edytora vide narzędzi twórczych jest celowym działaniem nastawionym na bezwzględny zarobek. Z jednej strony nie podcina się gałęzi, na której się siedzi z drugiej jednak strony, przy obecnym zaangażowaniu mamy tu realizację strategii "pies ogrodnika". Będę marudził, narzekał i krytykował bo takie jest moje święte prawo jako nabywcy pewnych obietnic bo chyba tak jak każdy wiedziałem za co płacę. Okropnie, wręcz nieznośnie irytuje mnie próba zakłamywania rzeczywistości okraszona staropolskim: "inni mają gorzej i nie narzekają".

Na litość boską... przestań czytać wybiórczo. Wymagam zbyt wiele? Cytujesz coś selektywnie, wybierasz sobie to co pasuje do Twojej pseudologiki ubranej w beletrystykę i jeszcze używasz słowa polemika? To się nie dzieje... [swoją drogą to co zrobiłeś z cytatem mojej wypowiedzi to jest matactwo godne TVPIS w swoim najlepszym czasie] Siedzę sobie w tej tematyce od 2004 roku, nie używam jednak argumentu 20 letniej historii bo nie o to chodzi ale czy jeśli napiszę Ci, że jest staropolskie przysłowie "darowanemu koniowi w zęby się nie zagląda" i dodam, że Simrail nie jest darmowy to zrozumiesz, że płacąc możesz czegoś wymagać? Prościej byłoby Ci jednak pobrać ową MaSzynę i przeczytać pobieżnie ichnie forum żeby zrozumieć, że nawet darmowy projekt może funkcjonować na takiej umowie społecznej, która daje Ci przynajmniej wrażenie, iż nie jesteś tylko przelewem na firmowym rachunku bankowym.

Pośród wielu możliwych opcji, w poważnej dyskusji używanie argumentu ilościowego bez odniesienia jakościowego to po prostu beletrystyka. Z czystej przyzwoitości lepiej milczeć niż odezwać się, napisać coś i rozwiać wszelkie wątpliwości. Użyłem argumentu opartego o MaSzynę bo jest to ten sam typ produktu. Główna różnica wynika z tego, że MaSzyna jest darmowa i opiera się o rozwiązania równie bezpłatne. SimRail korzysta z płatnego silnika graficznego i sam z siebie jest płatny. Czy teraz dociera do Ciebie, że jestem w stanie przeżyć singla z grafiką gorszej jakości (choć wbrew pozorom nieznacznie gorszą). Powiem Ci nawet, że Maciej swojego SPKS'a wdrożył najpierw w MaSzynie. Sama fizyka w Maszynie funkcjonuje lepiej. Taboru jest tam w cholerę i ciut... można wymieniać ale to nie ma sensu. To argument tyczący się tego, że za takie pieniądze, które kasowane są "in blanco" może wymagać jakiegoś minimum, prawda?

Czyli nie wiesz, nie sprawdziłeś ale wiesz. Cóż, chyba doszedłeś do sejmowego poziomu absurdalności logicznej. Mam nadzieję, że to tylko prowokacja z Twojej strony gdyż w innym przypadku należy uznać to za próbę rozmycia dyskusji na właściwy temat. Postaraj się w tym trollowaniu stosować reprezentatywne minimum merytoryczne.

Boli to kontakt z osobami, które cokolwiek mogą zmienić. Gdzie jest Szociu? Mateu pod 5 postaciami też wyparował, Milek? youBy? Nagle wszyscy zapadli się ze wstydu czy może już odcinają kupony bo naiwni zapłacili za nowe alufelgi do Izery, która jeździ tylko na stole kreślarskim? Jak można pchać DLC z patchem nie naprawiając błędów krytycznych i jeszcze dokładać nowe? Zapłaciłem za EA po bożemu pełną kwotę, a teraz czuję się jak frajer bo nadal tkwimy w EA z błędami etapu playtestów, a już przeceniono ten sztandarowy projekt Simkolu mimo dorzucenia EN57 i kilku nastawni... no i DLC bo majówkę lepiej spędzać w Egipcie niż w Mietkowie. Komunikacja na linii producent - odbiorcy nie istnieje. Responsywność na zgłoszone błędy zerowa. Wiarygodność - puka w dno od spodu. Jak czytam obrońców firmy to uzmysławiam sobie, że żarcik "niskie wymagania kluczem do zadowolenia" jest prawdą objawioną. Pan Wiesio czuje dumę. Nikt Wam nie da tyle ile producent obieca. Teraz czas na wstrząs: pomijając tryb wieloosobowy to darmowa Maszyna wciąga nosem Simrail'a. Jakby tego było mało to dzieło tych samych osób, które teraz podpisują się pod tą płatną nijakością. Smuteczek.

Standardy pokolenia Z... Istnieje coś takiego jak krytyka nie będąca hejtem. Upraszczając, nie każda krytyka to hejt. Krytyka to krytyka ale dla rozwiania wątpliwości - SJP:

Ty albo chodzisz albo zbyt długo chodziłeś do placówek oświatowych i to tych mentalnie zakorzenionych w czasach słusznie minionych. Mnie i pewnie większość wypowiadających się, nie obchodzą inne produkty wraz z ich problemami. Nie moim problemem jest to, że używasz zwrotów, których nie rozumiesz, dodatkowo podpierając to logiką godną mediów "gadzinowych".

Oczywiście. Nie mam syndromu PO-PISu i jasno mówię, że białe jest białe, a czarne jest czarne. Ilość błędów, które są od czasu playtestów, a które to są olewane jest ogromna. To nie jest pojedyncza literówka w nazwie czegoś w menu. Mamy całą masę błędów istotnie wpływających na jakość i możliwość rozgrywki i logarytmicznie przyrastającą ilość błędów krytycznych, widocznych zwłaszcza w trybie wieloosobowym. Ci z Was, którzy pracują - spróbujcie pracować w taki sposób jak obecnie pracuje jaśnie wielmożny zespół developerów.