error723

Też bym tak chciał. Natomiast zastanawiam się, co się stanie z Running Train, gdy dodadzą ruch AI, pasażerów oraz MP - mam nadzieję, że wydajnościowo nic się nie zmieni i faktycznie będziemy mogli zacząć krucjatę w SR. Ten powyższy filmik robi na mnie olbrzymie i pozytywne wrażenie. edited: Podobno działa tak z kartą rtx3060ti, a gra zawiera ruch AI. Nie chcę piać z zachwytu póki nie uruchomię u siebie, ale optymalizacja wygląda na DOPRACOWANĄ!

Przykre, że nawet tak oczywistej różnicy nie widzisz. @Dyspozytor Liniowy zapytał kogo, Ty stwierdziłeś, że to moja grafomania. To tak dla jasności.

Tak, oczywiście, przypisałeś mi utwór Waligórskiego: A teraz, gdy jednak zweryfikowałeś wycofujesz się raczkiem, zakrywając swoją ignorancję moją "chamskością". To, że nie masz odwagi udowodniłeś już wcześniej, gdy ubliżałeś mi, przypisując opcję polityczną. Potrafisz obrażać, potrafisz używać argumentów nie rozumiejąc kontekstu, potrafisz nawet używać czegoś o czym nie masz pojęcia, byle podkreślić swoją "rację". Tak, każdy powinien się uczyć i obserwować, jak zachowują się trolle internetowe, co można wyczytać tutaj: https://pl.wikipedia.org/wiki/Trollowanie

Popisałeś się nieznajomością Mistrza rozrywki Polskiego Radia, rozumiem, za młody jesteś by usłyszeć go na żywo, ale w dobie internetu, gdzie można wkleić pierwszy wers, pisać iż to grafomania, a następnie przypisywać to innemu użytkownikowi, to już szczyt ignorancji. Nigdy bym nie przypisał sobie czyjegoś utworu, nigdy bym nie pomyślał o tym, by obrażać kogokolwiek na podstawie cytatu utworu literackiego - tak, jesteś tylko forumowym trollem, więc Twoja opinia dotycząca twórczości osoby, o której istnieniu nigdy nie słyszałeś, bezwartościowa (tutaj są znacznie mocniejsze słowa, które każdy sobie dopowie, widząc w jaki sposób traktujesz wybitnego radiowca). I do tego sprowadza się cała Twoja bytność na tym forum, z reguły nie masz pojęcia o czym piszesz, obrażasz używając "polityki", tylko by wyłożyć swoje "racje". I widzisz, to że postawisz prawidłowo kropkę lub przecinek, nie znaczy, iż treść którą wstawisz ma jakąkolwiek wartość - a tym bardziej, gdy z taką częstotliwością chwalisz się ignorancją.

Poraża mnie Twoja indolencja - zweryfikuj najpierw kim był Andrzej Waligórski, co uczynił dla Polskiego Radia i jakie treści tworzył. Bezwstydna ignorancja, gratuluję.

To, że nazwiesz kogoś przegrywem lub przypiszesz mu rolę poddańczą, to świadczy o Tobie, Twojej kulturze osobistej oraz poziomie elokwencji.

Jak Was tak czytam to nie wiem dlaczego, ale przed oczami staje mi fraszka Mistrza Waligórskiego "Zapylała raz pszczółka jakiegoś badyla, Wtem czuje, że od tyłu też ją ktoś zapyla. Patrzy się, a to truteń, niejaki Zenobi. Morał - rób dobrze innym, tobie też ktoś zrobi." I gdyby pojawiły się jakieś głosy, że to niezgodne z regulaminem, polecam "Bajeczki Babci Pimpusiowej". A teraz, możecie wrócić do utyskiwania na każdego, kto się z wami nie zgadza - Don Kichoty SimRaila...

A następnie to: Logika godna trolla i to przeciętnego, bo by w jednym wątku tak sobie zaprzeczać... Cóż, ode mnie masz trwałego ignora.

Bloody hell, Mate, that looks great!

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.

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.

Potrafisz to udowodnić czy jedynie będziesz pisać o tych opóźnieniach? No chyba, że jak na trolla przystało, jedyne co masz, to własną opinię, którą będziesz przepychać ubliżając innym użytkownikom. Proste, udowodnij opóźnienia. Brokery FB ogarniają miliardy wiadomości na sekundę, brawo, masz jeszcze jakieś przykłady, które można przełożyć na obsługę symulatora, a może, ponownie, jesteś jedynie trollem, który własne tezy broni absurdami, byleby wpasować do kontekstu (czekaj, to nie Ty wypisywałeś o manipulacji rodem z tvpis?). Udowodnij ten narzut - a dokładnie koszt, ile taktów zegara w nowoczesnym procesorze zajmuje obsługa ramek MQTT. I który pojazd ma 200 pozycji na zadajniku jazdy, który będziesz obsługiwać enkoderem? Kolejny trollowy argument - byle by wkleić? (ponownie, co pisałeś o manipulowaniu?) W Twoich wypowiedziach nie ma ani jednego faktu odnośnie MQTT, który realnie mógłby wpłynąć na działanie w zakresie symulatora, który będzie miał obsłużyć kilkanaście wiadomości na sekundę. Są za to bzdury, o tym, że MQTT nie jest wykorzystywane w automatyce - sam protokół powstał do monitorowania i zarządzania rurociągiem, uwaga pod koniec XX wieku, czyli jest używany od blisko 30 lat w projektach wymagających nie tylko wysokiej wydajności, ale także dokładności. Piszesz o testowaniu obciążeń, to napiszę wprost, jak ktoś czego nie umie, to wychodzą takie kwiatki, że broker blokuje się już przy 100 wiadomościach na sekundę - znasz to skądś? Nie? To zajrzyj na stack, a odkryjesz, że tysiące użytkowników zapychają MIDI, bo nie są w stanie prawidłowo zsynchronizować, czy choćby zbudować kolejki. Podsumowując, manipulujesz wklejając dane od FB i nakładając na projekt o zupełnie innej skali, kłamiesz pisząc o tym, że nikt nie wykorzystuje MQTT - żyjemy w trzeciej dekadzie XXI wieku, każdy może wpisać w wyszukiwarkę i dostać informację o takich projektach, a do tego, by podkreślić "moc" tych kłamstw i manipulacji, ubliżasz - to jest niesmaczne i z definicji nazywane jest trollowaniem. Dla każdego, kto nie wie czym MQTT jest polecam oficjalną stronę projektu https://mqtt.org/ , a dla tych, którzy chcą zobaczyć jak to działa i nauczyć się w jaki sposób odpowiada subscriber (taką rolę będziecie musieli obsłużyć) polecam https://www.rabbitmq.com/ - w tym projekcie jest bardzo dobrze udokumentowane "jak to działa" ( https://www.rabbitmq.com/tutorials ), z przykładami w popularnych językach.

Z jakiego internetu? Broker działa na sockecie na Twoim hoście, lokalnie!

Skończ już z wycieczkami osobistymi, chyba, że to jedyne co potrafisz w formie argumentacji: I teraz udowodnij, na liczbach, ile zajmuje Publish - Routing (w brokerze) - Deliver do subscriber. Wykaż, że naprawdę wiesz o czym mówisz utyskując na "opóźnienia". Do obliczeń użyj najsłabszego procesora jaki jest rekomendowany, czyli . Chcę zobaczyć tą "kompetencję", której mi odmawiasz, nie mając pojęcia kim jestem. I by było jasne, ja naprawdę widziałem te Twoje obrzydlistwa:

Przecież MQTT nie broni Ci wpięcia urządzenia po USB, co napisałem tu: MQTT w takim ujęciu jest jedynie API dla Twojego sterownika, którym łączysz się po USB, czy nawet porcie szeregowym (jak masz ochotę). Tak, w takim ujęciu masz dodatkową pracę, bo musisz napisać adapter, który zepnie komunikację MIDI czy jaką tam sobie wymyślisz, z API wystawionym przez programistów (MQTT). To wszystko. Pisanie o narzucie miałoby sens, gdybyśmy mieli jednordzeniowe procesory pokroju 80286 - faktycznie, dodanie ramek byłoby kosztowne, ale nie dla wielordzeniowych procesorów mających miliardy operacji na rdzeń! Mówimy o brokerze i subskrybencie na tym samym hoście, koszt "narzutu" to 100µs na wiadomość? Tak, mówimy o rzędzie wielkości 100 mikro sekund, gdzie jedna mikro sekunda jest jedną milionową sekundy. Utyskiwanie na opóźnienia przy tego typu procesorach (a ten minimalny, zalecany do gry to: jest absurdalne. I uzupełnijmy, jakiekolwiek by API przez programistów nie było, to i tak na Tobie wisi stworzenie sterownika, do układu który chcesz podłączyć, a MQTT zwalnia każdego chętnego choćby z tworzenia kolejek i priorytetów, bo tym zajmuje się broker, który będzie wystawiony jako API. A jeśli chodzi o "trendi" i automotive https://bmw-cardata.bmwgroup.com/customer/public/api-documentation/Id-Streaming_MQTT-example tutaj masz więcej o samym projekcie, ile funkcjonuje, jak funkcjonuje i w jakim zakresie https://www.hivemq.com/case-studies/bmw-mobility-services/ I wierz mi, to nie jest jedyne rozwiązanie MQTT w szeroko rozumianej automatyce. edited. Ponadto, jak API się pojawi to sam na github wystawie repo, które udokumentuje i pokaże jak podpinać kolejne elementy, a z pewnością nie będę jedynym. Powstaną nie tylko gotowe projekty, ale także template dla różnych rozwiazań.

Kompetencja forumowa? Widzę członek elektrody 🙂 Pozdrawiam serdecznie 🙂

Jakim cudem zajmujesz się automatyką skoro zdań prostych nie potrafisz przeczytać ze zrozumieniem? Jak chcesz na lekcje, to zapraszam. W przeciwnym razie, odrób lekcje samodzielnie - wiele napisano o projektach. I przelicz w taktach, ile procesorowi, który jest wymagany jako minimalny dla gry zejdzie na "obrobienie ramek" skoro tak straszysz narzutem. BTW, decyzja podjęta, pozostaje Ci marudzenie, że ktoś podjął decyzję inną niż byś chciał.

Rozszerzę i może się to komuś przyda przy własnej przygodzie z budową panelu pod proponowane rozwiązanie z MQTT. Broker będzie uruchomiony na Twoim hoście, będąc wpięty do silnika gry, czyli jego latencja to 1-5ms(?) - wiadomości możesz odbierać już na swoim PC czyli nadal możesz stworzyć adapter, którym obsłużysz MIDI (jest to narzut, ale można jak ktoś chce - można także podpiąć RPi0 jako HID, a można spiąć małe ESP32 bezpośrednio z brokerem). I tutaj masz dowolność, czy podepniesz panel po lan, wi-fi, czy rs... każde medium to obsłuży bo jest jedynie pośrednikiem. Czyli model wygląda tak: panel -> wi-fi/lan -> localhost broker (wbudowany w SR) -> silnik gry. W takim ujęciu zapchanie kolejki brokera może być spowodowane złą implementacją własną, notify wywoływane jest jedynie przy zmianie stanu, a nie odpytywanie o każdy element kilka razy na sekundę. Działasz na zasadzie "słucham i reaguje na subskrybowane zdarzenia", nie mnie, nie więcej. Nie, nie ma mowy, że w takim ujęciu zapchasz kolejkę brokera i przez to hamulec zacznie działać po 100ms czy więcej. Tutaj trzeba dodać, jeden broker może obsługiwać wiele kolejek, a to pozwala na to, że notify=hamulec będzie mieć priorytet nad notify=ustawŚwiatłoReflektoraGórnegoStanWłączone. Oczywiście, że nie zaprojektowałbym takiego rozwiązania w urządzeniach typu hard real-time, ale to jest symulator, gra i tutaj przede wszystkim ważne jest to, by jak najwięcej osób było w stanie samodzielnie wykonać zewnętrzne urządzenia bo to pozwoli na rozwój samego produktu - jasne, że chciałbym by było to jak najbardziej skomplikowane, mógłbym zarobić na budowie takich paneli, ale z perspektywy wydawcy, lepiej by chodziły w sieci samouczki z przykładami lub gotowymi rozwiązaniami. MQTT to inny poziom abstrakcji w ujęciu "komunikacja" i to jest kluczem w tej propozycji - niezwykle łatwo to rozszerzyć o kolejne pojazdy, nawet jeśli miałyby nowe elementy do obsługi. Ba, właściwie można przygotować API do każdego elementu w grze oddzielnie, przez co każda lokomotywa byłaby obsługiwana przez dedykowane wiadomości dzięki czemu unikamy konfliktów. Uniwersalność i prostota, a zarazem rozszerzalność - i podkreślam, to jest symulator, tutaj nikt nie zginie jeśli hamulec awaryjny zacznie działać z opóźnieniem 10, 50 czy nawet 100ms!

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

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

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

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.

Niestety, coraz więcej takich, co to "rozumieją" cały świat SR. Nie jest istotne, że potem kolejka na szlaku, bo małe posterunki do których dociera ruch z "okienek" nie są w stanie prawidłowo obsłużyć priorytetów. Co tam EDR, co tam priorytety - przecież to jeno wskazówki, dla tych, co twierdzą, iż wiedzą więcej. I zgodnie z popularnym hasłem, "wyrzuć książki, wyłącz telewizor i włącz myślenie" - samozwańczy guru.

I chyba warto dodać, że lepiej zapytać na Discord moderatorów w kanale #🔀︱pl_multiplayer niż zasięgać "opinii" samozwańczego "profesjonalisty". Jak misiek napisał, czytaj EDR oraz pilnuj priorytetów - tyle wystarczy by żaden raport nie był groźny, nawet gdy wyśle go EIP jadący za towarowym (jeśli jechał 250 km/h, był przed czasem i dogonił TOW to jego sprawa - nawet piloci samolotów mają korytarze oraz muszą trzymać się zasad, więc kolejny amator prędkości może jedynie uzyskać blokadę na wysyłanie raportów, jeśli będzie takie systematycznie wysyłać).

1. Sprawdź czy jesteś podpięty pod właściwy proces, 2. Sprawdź runttime, nie wiem jak jest w przypadku wpinania pliku lua, ale warto sprawdzić czy został prawidłowo wczytany 3. Sprawdź czy port należy do właściwego procesu, dla linuxa weryfikuje się PID z portem, dla widnowsa nie wiem. 4. Czasem reguły firewall hosta potrafią blokować porty, warto sprawdzić czy nie masz zamkniętego tego konkretnego, albo czy inny proces zeń nie korzysta. Tak, w NetBeans jest wszystko automatycznie, a vs code wymaga ręcznego spięcia runtime + port + debuger. Najpierw sprawdź czy PID procesu faktycznie jest spięty z portem, potem runtime. Dodatkowo, vs code pozwala spiąć agenta AI, który może sprawdzić konfigurację -> wystarczy konto na github, jest wersja darmowa, są też płatne (darmowa powinna sobie poradzić z podpowiedziami w kwestii konfiguracji).