Kontrolery gier

[JarkPomsky]

Zgłaszałem kiedyś coś podobnego, niestety bez odezwu.

 

 

[0x8000ffff]

Witam, podobny wątek, sprzed około dwóch lat znajduje się w Archiwum forum 

Mogę teraz odpowiedzieć twierdząco: tak, używam. W dwa dni stworzyłem i przetestowałem taki oto Panel sterowniczy na tablecie:

 

Symulator na dzień dzisiejszy nie obsługuje udostępniania danych zwrotnych o stanie pojazdu, więc komunikacja przebiega w jedną stronę, z apki na tablecie do komputera. Po prostu rozwiązanie to zastępuje używanie klawiatury. Jak dla mnie taki sposób obsługi pojazdów w symulatorze jest dużo przyjemniejszy, prostszy od budowania fizycznych pulpitów i wreszcie nie muszę się zastanawiać jaki klawisz czy ich kombinacja odpowiada za daną akcję.

Elementy sterujące (przyciski, przełączniki) oraz elementy opisowe i dekoracyjne ułożyłem sobie w sposób intuicyjny i przejrzysty (w moim odczuciu). Poza testami działania przejechałem z użyciem mojego dzieła kilkanaście godzin.

Projekt jest zrobiony pod Pendolino, tj. poza tłem z tym pociągiem odwzorowałem tam, oczywiście w sposób uproszczony umiejscowienie elementów sterujących w kabinie Pendolino.

Górny rząd dużych, okrągłych przycisków to w większości widoki kamer, reszta jest podzielona na opisane grupy i zaopatrzona w sugestywne (moim zdaniem) ikonki.

Jak widać nie dorobiłem jeszcze sterowania pantografami, ale nie wiem czy warto. Nie miałem jeszcze na żadnej trasie przypadku, że wymagane było opuszczenie pantografów.

Podsumowując, kupiłem apkę (początkowo pod Farming Simulator 22 i 25), zarejestrowałem się w społeczności użytkowników SimDashbord, wykonałem powyższe dzieło, przesłałem do akceptacji. Jest już dostępne do pobrania z repozytorium społeczności, jeśli ktoś będzie miał takie życzenie 😉 

 

[error723]

Zacząłem się bawić, jak reaguje SimRail z elektroniką. Chcę użyć potencjometr do hamulca EU07 (i całej reszty). I o ile nie ma problemu z czterema stanami (jazda, odcięcie, luzowanie, hamowanie nagłe), o tyle przeliczanie kolejnych pozycji hamowania pomiędzy "jazda", a "hamowanie nagłe" to już nie jest takie proste, tym bardziej, że aktualny stan, który przechowuje, wcale nie musi odzwierciedlać tego co jest w symulatorze. I tutaj mam pytanie @Królik Uszasty czy jest opcja by kolejne stany hamowania były przełożone na klawiaturę? Czyli "poziom 1" = !, "poziom 2" = @, ... itp. To raczej nie będzie wielka zmiana, dodanie do interfejsu tego co pewnie i tak już symulator obsługuje, a znacznie uprości to obsługę kranu hamulca.
Druga sprawa, pytałem o to w oddzielnym wątku -> jaki jest zakres szesnastkowo, znaków, które są akceptowalne przez symulator. Czy to jest ASCII printable czyli od 0x20 do 0x7F, czy może rozszerzone do 0xFF? Czy są jakieś wykluczenia?

Króliku, wymieniłem Ciebie, bo z moich krótkich obserwacji wynika, że jesteś najbardziej responsywny z zespołu.
Z góry dzięki za info.

Edited August 21, 2025 by error723

[Maciej_ZG]

A my w wątku wciąż czekamy na oficjalny support IO który był obiecany dawno temu.

Sam planowałem zrobić konwersję pomiędzy tym co mam w pulpicie a wirtualną klawiaturą ale stwierdziłem że nie ma sensu skoro support do IO miało się pojawić.

Kwestia teraz ile jeszcze trzeba czekać...

[Conrad]

8 minut temu, error723 napisał(a):

Zacząłem się bawić, jak reaguje SimRail z elektroniką. Chcę użyć potencjometr do hamulca EU07 (i całej reszty). I o ile nie ma problemu z czterema stanami (jazda, odcięcie, luzowanie, hamowanie nagłe), o tyle przeliczanie kolejnych pozycji hamowania pomiędzy "jazda", a "hamowanie nagłe" to już nie jest takie proste, tym bardziej, że aktualny stan, który przechowuje, wcale nie musi odzwierciedlać tego co jest w symulatorze. I tutaj mam pytanie @Królik Uszasty czy jest opcja by kolejne stany hamowania były przełożone na klawiaturę? Czyli "poziom 1" = !, "poziom 2" = @, ... itp. To raczej nie będzie wielka zmiana, dodanie do interfejsu tego co pewnie i tak już symulator obsługuje, a znacznie uprości to obsługę kranu hamulca.
Druga sprawa, pytałem o to w oddzielnym wątku -> jaki jest zakres szesnastkowo, znaków, które są akceptowalne przez symulator. Czy to jest ASCII printable czyli od 0x20 do 0x7F, czy może rozszerzone do 0xFF? Czy są jakieś wykluczenia?

Króliku, wymieniłem Ciebie, bo z moich krótkich obserwacji wynika, że jesteś najbardziej responsywny z zespołu.
Z góry dzięki za info.

Na razie w  ustawieniach wyłącz płynne hamowanie, to poprawi, ale nie jest to rozwiązaniem problemu, czekamy na interfejs  input/output.

[error723]

Nie wiem czy out także będzie, ale in właściwie jest gotowy -> wygląda jakby znaczna część akcji była wystawiona (przynajmniej dla klawiatury). I rozumiem, że to jest koszt podczas tworzenia produktu, a tym bardziej, że raczej się nie zwróci, bo tych, którzy są w stanie i zrobią własne urządzenia jest raczej niewielu. Dlatego proszę o informację dotyczącą zakresu akceptowalnych znaków przy wejściu oraz informację, czy jest opcja dołożenia do obsługi z klawiatury, każdej pozycji kranu hamulca (oczywiście, że wolałbym wartości procentowe, dzięki temu bardziej by to odwzorowywało działanie urządzenia).
Dziś, gdy sprawdzam zachowanie, niestety bez choćby skoków, nie jestem w stanie w pełni odzwierciedlić działanie - wystarczy, że za szybko ruszę wajchą i zrobię to ustawiając na przykład "pozycja 5", "pozycja 3", "pozycja 4" (za szybko HID przesłał "+") i w symulacji zostaje na "pozycja 3", a u mnie odczyt na serial monitor pokazuje "pozycja 4". Co ciekawe, jak płynnie i nie gwałtownie przesunę w "pozycja 4", to serial monitor pokazuje to samo co symulacja. Brak stanów pośrednich, którym mógłbym przypisać konkretne HEX, a nie przeskakiwanie z pozycji na pozycję wysyłając "+" lub "-".
Dlatego proszę o informację dotyczącą mapowania, jaki zakres ASCII jest dostępny i proszę o dodanie stanów pośrednich dla hamulca - nie sądzę, byśmy się doczekali pełnoprawnego IN/OUT.

[Conrad]

Zapowiedzieli i/o w roadmap, więc jakaś szansa jest. Udostepnienie tego na pewno przełożyłoby się na marketing, więc nawet jak mała grupa ludzi to wykorzystać, to medialnie będzie to bardzo pozytywnie odbierane. Dzięki temu można bardzo wyróżnić sie na tle konkurencji. 

[Maciej_ZG]

Halo @Królik Uszasty, @uetam

Jakiś update kiedy można się spodziewać supportu dla pulpitów ? 

[error723]

Dla tych, którzy nie używają discord, to warto. Właśnie powstał nowy kanał dedykowany kontrolerom gry https://discord.com/channels/1067073812560093264/1432656623926640652

[andy.lbn]

Co się stało z kanałem na discordzie?

[Conrad]

3 godziny temu, andy.lbn napisał(a):

Co się stało z kanałem na discordzie?

Istnieje.

[andy.lbn]

18 godzin temu, Conrad napisał(a):

Istnieje.

Niezależnie od urządzenia, nie ładuje się

[error723]

18 minut temu, andy.lbn napisał(a):

Niezależnie od urządzenia, nie ładuje się

Działa. Może przeładuj ctrl+shif+r ?

[andy.lbn]

10 minut temu, error723 napisał(a):

Działa. Może przeładuj ctrl+shif+r ?

Uwierz mi - próbowałem wszystkiego (jestem z branży web dev) 🙂

[error723]

16 minut temu, andy.lbn napisał(a):

Uwierz mi - próbowałem wszystkiego (jestem z branży web dev) 🙂

Wierzę, ale wygląda jak lokalny problem. 

[andy.lbn]

Dobra, już wiem - przeszedłem do kanału z selekcją ról - zaznaczenie odpowiednich pomogło.

[Mywasher]

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.

[error723]

W dniu 4.04.2026 o 14:31, Mywasher napisał(a):

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.

Zaproponowany serwer MQTT to możliwość pozbycia się "kabli" wpinanych do komputera. Dzięki temu, możesz budować niezależne, małe moduły, którymi nie musisz zarządzać, dbać o przerwania, timery i całą masę niskopoziomowych niedoskonałości interfejsu MIDI, który powstał 43 lata temu. Klient MQTT mieści się na esp32 c3 (aktualny koszt 7zł na ali), na którym masz 11 pinów do swobodnego działania. I wówczas, jedyne czego potrzebujesz to zasilanie - i tutaj kolejna zaleta, jeśli tworzysz sekcję z samymi przełącznikami to wystarczy ogniwo 18650 (moduły ładowania kosztują kilkanaście zł za 10 sztuk) = zero kabli. I dodatkowo, nie zarządzasz kolejką zdarzeń, gdyż ta jest obsługiwana przez serwer. Jak dla mnie MQTT to obecnie, najlepsze możliwe rozwiązanie i cieszy mnie, że w tym kierunku programiści poszli.
Oczywiście, że wypróbowane standardy, które były wykorzystywane przez lata, słusznie są oznaczane jako niezawodne. Jednak technologia idzie do przodu, a patrząc na transmisję danych przez ogólny rozwój telekomunikacji, to naprawdę nie warto zatrzymywać się na sprawdzonych, aczkolwiek bardzo starych interfejsach.

Edited yesterday at 08:59 AM by error723

[Mywasher]

 

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.

 

Edited 21 hours ago by Mywasher

[Conrad]

Dramatyzuje ten AI, ale miło się czyta :D. I tak będzie MQTT 🙂

Edited 20 hours ago by Conrad

[error723]

Zajrzyj na Discord, wyraźnie napisano, gdzie będzie broker. Wprowadzasz w błąd twierdząc, że samodzielnie będziesz musiał obsługiwać kolejki.
Do reszty szkoda mi się nawet odnosić, bo każdy kto robi IoT, urządzenia EDGE, które muszą się komunikować, wie, że MQTT to jedno z lepszych rozwiązań, a próba mówienia o zakłóceniach mikrofalówką sąsiada to argument rodem z płaskiej ziemi - no chyba, że router trzymasz w tejże mikrofalówce, to aż dziw, że w ogóle jakiekolwiek fale stamtąd wychodzą (wątpię byś zrozumiał).

[Mywasher]

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.

Edited 16 hours ago by Mywasher
literówka

[error723]

8 godzin temu, Mywasher napisał(a):

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.

Metafora wyprodukowana przez gpt... Ty chociaż zweryfikowałeś to co tu wkleiłeś?

[0x8000ffff]

Kolejna gównoburza o wyższość Świąt Wielkiej Nocy nad Świętami Bożego Narodzenia. Nad argumentami technicznymi przeważa chęć udowodnienia drugiej stronie swojej racji na zasadzie emocjonalnej "moje musi być na wierzchu, bo tak i już".
Do symulatora "Maszyna" zrobiłem swego czasu eksperymentalny pulpit: potencjometry, później enkodery, silniczki krokowe jako manometry, diody LED jako lampki na pulpicie, komunikacja obustronna po porcie szeregowym. Wszystko działało jak należy. Arduino + kod w Lua i C. Wystarczyło. Nie jestem wcale pewien czy MIDI zapewnia komunikację dwukierunkową. Da się przy jego pomocy realizować np. funkcje nastawnika, ale czy zapali mi diodę CA/SHP? Nie jestem tego pewien. Z kolei internet rzeczy do sterowania lokomotywą? Czy to nie jest przerost formy nad treścią? Bo modne, to musi to być?

[error723]

Godzinę temu, 0x8000ffff napisał(a):

Kolejna gównoburza o wyższość Świąt Wielkiej Nocy nad Świętami Bożego Narodzenia. Nad argumentami technicznymi przeważa chęć udowodnienia drugiej stronie swojej racji na zasadzie emocjonalnej "moje musi być na wierzchu, bo tak i już".
Do symulatora "Maszyna" zrobiłem swego czasu eksperymentalny pulpit: potencjometry, później enkodery, silniczki krokowe jako manometry, diody LED jako lampki na pulpicie, komunikacja obustronna po porcie szeregowym. Wszystko działało jak należy. Arduino + kod w Lua i C. Wystarczyło. Nie jestem wcale pewien czy MIDI zapewnia komunikację dwukierunkową. Da się przy jego pomocy realizować np. funkcje nastawnika, ale czy zapali mi diodę CA/SHP? Nie jestem tego pewien. Z kolei internet rzeczy do sterowania lokomotywą? Czy to nie jest przerost formy nad treścią? Bo modne, to musi to być?

Przeczytaj choćby wiki na ten temat https://pl.wikipedia.org/wiki/MQTT , nie mówiąc o historii powstania i na jakie potrzeby zamówienie było realizowane - wtedy o internecie rzeczy nikt nie słyszał. Wiem, chciałeś swoje zdanie dołożyć, dołożyłeś - tak w kwestii emocjonalnych uniesień, do których się odwołujesz.
MIDI jest dwukierunkowy, także warto było choćby zerknąć do wiki https://pl.wikipedia.org/wiki/MIDI  - i tak, pierwotnie został zaprojektowany do urządzeń muzycznych, ale szybko zyskał uznanie w wielu projektach, jako niezawodny protokół komunikacyjny.
Porównując je, każdy może uznać, że to przerost formy, przecież można obsłużyć to przez zbudowanie własnych bramek, ale od tego mamy rozwój technologii by móc z niej korzystać.

edited
Dodam jeszcze, że MQTT pozwoli na to by średnio ogarnięty fascynat był w stanie samodzielnie zbudować i podłączyć własne moduły, MIDI wymaga znacznie większej wiedzy i umiejętności, na niższej warstwie abstrakcji (piszę o samej komunikacji, by się ktoś za chwilę nie przyczepił, że twierdzę, iż mqtt będzie zarządzać konkretnymi przełącznikami/diodami czy co tam jeszcze - nie będzie, to trzeba obsłużyć mikro-kontrolerem). I to także jest ułatwienie dla programistów SR, bo obsługa MIDI jest upierdliwa i ma jedną wadę, nie jest skalowalna (masz 3 bajty i koniec, nie ważne czy ich w tym momencie potrzebujesz, czy nie - nie wspominając o możliwości dodawania obsługi kolejnych elementów).

Edited 3 hours ago by error723