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.