All Activity

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.

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.

Otwarta restauracja w pociągu

Z podziękowaniami dla drogich nam wszystkim Panów Jasona, Clouda, Maqitta oraz Etcsa. No i zdarzyło się, trzeba się szybko stawić u klienta, bo to mu cieknie jakiś płyn w agregacie chłodniczym. No tak powiedział mi przez telefon, bo ta babka z call, no gdzie odbiera zgłoszenia na awarie, to nie miała tego co on mówił na ekranie, to powiedziała że go z serwisem połączy, a ja akurat se siedziałem na dyżurze z tymi wybrakowanymi słuchawkami na jedno ucho, a druga to ta na dół wygięta, co to ją na mikrofon zrobili. Nie no, wiadomo że nic nie zrobię, bo wóz serwisowy w warsztacie a klamotów to w nic mniejszego nie wsadzę, ale obsługa klienta na poziomie być musi. Szef zaleca skorzystać z usług kolei. No niby mówi że mogę swoim autem, bo jak się uprę to mi w delegacji paliwko pokryje, no ale wicie, rozumicie, kolej to nowoczesność w transporcie i korki Pan ominiesz. To chociaż swoim transportem na dworcowy parking się podrzucę, i tak przecież żadnych bagażów nie wiozę. O masz babo placek! Jeszcze ostatnio to tu parkometr stał, co to monety przyjmował, a jak nie to cieć parkingowy miał ten, no... terminal na plastikowy pieniądz, ale w miejscu jego kontenerka to takie nowoczesne urządzenie stoi, co to ma z całym tym webem czy czymś tam łączenie i to mi babskim głosem gada, że komórkowca mam na opłatę parkowania przyłożyć, albo tego Blika jej podać. To lecę na parking auto przestawić tam pod wiadukt. Nawet taniej będzie i monetami zapłacę i bilet da, to mi szef wróci za to płatne stanie. Alem się zdyszał na ten dworzec! To już tam mój pociąg stoi, ale odjazd zaraz, to po bilet do konduktora. Że co? Terminal mu zawisł i biletu nie sprzeda, do kasy trzeba. No cztery są i kolejka tylko do jednej. A, tamte zamknięte. Rozpycham się więc grzecznie łokciami, nie mam czasu na odpowiadanie na zaczepki, bo pociąg stał tam wiecznie nie będzie. Konduktor mówił że się spieszyć trzeba, że zaraz światło na szlag dostanie. Szlag to mnie zaraz trafi. Kasa ma tylko bilety na swojego przewoźnika, na tamtego co na torach w peronach, to tylko przez interneta, no z komórki Pan se zamówi, kasjerka mi podpowiada. A skąd u diabła ona wie, że mam jego w komórkowcu, skoro ja nic o tym nie wiem? Zaraz, bo to ostatnio coś mi wnuk pokazywał, że tu trzeba... o jest, no ta podglądarka się pokazała. - Pan mi to da - mówi babka z kasy - to Panu QR'a zeskanuję... o jest system biletowy, to Pan sobie teraz kliknie. - To niech już mi Pani zamówi ten bilet, jak już tak daleko Pani jest - mój ton głosu jest zazwyczaj dość przekonujący. - No tak... ale widzi Pan, tu w systemie jest że pociąg już odjechał z naszej stacji, to biletu już Pan nie kupi, ale u konduktora Pan dostanie. Patrzę to na peron, to na nią wybałuszonymi oczyma. Jak odjechał, stoi przecież. - Nic Panu więcej nie pomogę - uśmiecha się Pani przepraszająco. Podziękowałem i walę nazad do konduktora. Ten mi o awarii chmury i że biletu nadal sprzedać nie może. Nie wiem o co mu chodziło (niebo jest dziś czyste). _ No dobra - mówię - to ja se wsiądę i jak te chmury się pojawią to mi Pan już podczas jazdy da ten bilet. Ale, pomimo że pociągu już nie ma na stacji (nie wiem, ja widzę że jest, piwko albo dwa to po robocie musowo), to w tej radiowej szczekaczce u konduktora słyszę, że z myszą nie mogą sobie poradzić żeby wajchę jakąś przestawić na zwrotnicy i że na eksperta z IT... (nie usłyszałem dalej, chyba urwało) czekają, ale to potrwa bo z województwa jedzie. Pytam konduktora co jest grane, a on mi że pisemny będą dyktować na 150 megaherc, bo GSM-ry przestało działać, jak tylko sokiści poszli na przerwę śniadaniową i żarcie to oni na tej starej mikrofali robią, co to im zakłóca wszystko. No ja tam nie wiem, ale kierownik przyszedł i mówi że jak bileta nie mam to mi karę wypisać musi, no chyba że wysiądę. A tu widzę, że szef już pyta na wiadomościach tekstowych, czy ja daleko jestem, to wyłażę na peron z wagonu i udaję brak zasięgu. Alem się zdyszał na ten parking! Jeszcze ta parkometrowa cholera mi paragona nie dała, bo jakiś "Error: Paper Out". Szlag... Odpalam moją starą dwusetkę D, co to niejedną setkę trasy zaliczyła. Dobrze, że mi ostatnio Władeczek chciał wtrysk podregulować i teraz staruszek idzie jak burza, to tę stówkę zrobię w niecałą godzinkę. Bo jak do serwisu pojechałem, to... co mi ten mechanik powiedział? Że nie da rady bo on musi mieć kana żeby mi wtryski odczytać? No zjeżył mnie wtedy, co za głupot oni ich teraz w tych serwisach uczą?! No dobra, mnie też taki przenośny ekran dali jak to on mi opowiadał, że go zapiąć do tego kana musi, co to jak do agregata se podłączę to mi pisze co mam naprawiać, ale nie korzystam za bardzo, no bo to obciach, że każdy frajer z czymś takim będzie mądry. Ma człowiek swoją zawodową godność. No to jedziemy w trasę. Robota na miejscu to najpierw że dymi z agregatu, no ale jak otworzyłem to im mówię że jak ma nie dymić, jak opaska z węża spadła i się olej na gorącą obudowę leje, to i dymić musi. To oni mi tam, że na wskaźnikach to nic takiego nie mają, i że jakby się olej lał, to by im system to powiedział, a nowoczesny podobno jest. To ja się dogadałem z takim jednym, żeby mi narzędzia podstawowe jakieś dał, to naprawię od ręki. No to był ślusarz ze starej szkoły, to żeśmy we dwóch młotkiem i przecinakiem radę dali. Jak przestało dymić, agregat ruszył i tylko fakturę chcieli, to ja do Pani Helenki od nas z rachuby za telefon, żeby se z nimi dogadała co i jak, bo to nie moja działka przecież. Już w drodze powrotnej na szlabanach na torach stojąc w gadkę się z dróżnikiem wdałem, to się okazało, że to na mój pociąg, co to nim miałem jechać czeka. Zdziwiony pytam, co on tak długo jedzie, to on mówi (nie wiem czy dobrze zrozumiałem) że jakiś ETC.. no coś tam im pozwala tylko 20 km/h jechać , bo balasy jakieś w torach padły i on (ten pociąg) myśli że przez przejazd bez rogatek zamkniętych jedzie, to się wlecze tak już długo 20 km/h, bo oni tam w tej lokomotywie nie mogą tego komputra wyłączyć, żeby jechać szybciej, bo wyłącznik jakiś im zaspawali, bo go ciągle maszyniści używali. Mówi że to zarząd jakiś wkurzało, bo unijne pieniądze poszły i miało być tak europejsko. Ja tam nie wiem, przez te szlabany to się pewnie w dniówce nie zmieszczę i będę sie ze starym wykłócał o dietę w delegacji, bo to mi dniówka już dawno zeszła przez te nowoczesne transporty. Ot życie...

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.

Przyłączam się do prośby o poprawę syren. Masakra.

Ja ze swej strony dziękuję za odpowiedź, nie jestem znawcą tematu, więc nie muszę również wiedzieć, dlaczego takie a nie inne rozwiązanie zostało wybrane, prawdopodobnie że względu na optymalizację, prostotę, czy też wspomniane upakowanie danych. Bez szczegółów technicznych, ale też i bez zbędnej filozofii. Ważne aby było łatwe w implementacji i zrozumiałe dla twórców pulpitów. Na podstawie podanego przykładu zastosowania w IoT wyciągnąłem wniosek, że to będzie pobieranie danych z Internetu.

From this reply I get the feeling you don't get the picture I'm trying to draw: This fictional track would just work as an entry and exit point at Lodz Kaliska. So you can send an arriving train there, after disembarkation of the passengers, shunt it into the fictional track and to get it back one minute later to shunt it back to the same platform as a starting train. Then suddenly, you've got the option to let a train return in service at 'the end of the line', where the engine (currently) doesn't allow that within the multiplayer. This way you could get more trains running, within the game. I think that could be an option, I'm not saying it's a solution. It does need space to let trains run, I'm not sure if that's a possibility in the first place. That's why I'm asking 😊

@Mywasher Nie uważasz, że jednak Twoje wypowiedzi trochę zbyt emocjonalnie podchodzą do tematu, a niektóre porównania wręcz niesmaczne? Wydaje mi się, że jest już bliżej jak dalej do ukończenia prac i z jakiegoś powodu taki standard został wybrany - nie wiem, nie znam się i nie będę tłumaczył powodów wyboru i całego toku myślowego, jaki za tym stał. Nie sądzę, żeby na tym etapie ktoś zaorał wszystko tylko dlatego, że jeden użytkownik forsuje inny standard. Natomiast porównywanie pulpitu w domu do rozwiązań przemysłowych (a już co gorsza - pojazdów kolejowych) nie jest chyba na miejscu. Ja wiem, że nawet wyolbrzymione pół sekundy opóźnienia przy włączaniu hamowania przy prędkości 200 km/h to prawie 30 metrów różnicy w miejscu zatrzymania, ale bądźmy szczerzy - jeśli komuś naprawdę takie coś uniemożliwiałoby za każdym razem zatrzymanie się w miejscu, to jednak chyba trzeba zmienić technikę jazdy. Inna sprawa, że ja nie spodziewałbym się jakichś dużych i zauważalnych opóźnień w transmisji, zwłaszcza że te istotnie responsywne to muszą być w większości wypadków ze... 4(?) manipulatory (nastawnik, bocznik/tempomat, hamulec zespolony, hamulec pomocniczy). Myślę, że prawdziwe pojazdy w niektórych sytuacjach serwują większe opóźnienia (typu zawieszający się na kilka sekund monitor diagnostyczny przy włączaniu hamowania nagłego, bo musi przetworzyć na raz kilkanaście komunikatów o błędach). Sam do MaSzyny skonfigurowałem swój pulpit do komunikacji co 100 ms i jeździło mi się dobrze. Głównie dlatego, że wystarczyło ruszyć ręką zamiast korzystać z klawiatury. Co do samych magistral komunikacyjnych, no to cóż... no mamy na przykładowoym pojeździe (EZT) magistralę CAN, nawet 5-6 niezależnych linii, żeby te dane przesłać, ale wciąż hamowanie nagłe to otwarcie dziury pod grzybem lub zadajnikiem hamulca oraz równolegle poprowadzony przewód wzdłuż całego pojazdu (tzw. "pętla bezpieczeństwa"), który w tradycyjny sposób odcina zasilanie zaworów bezpieczeństwa. No i na tyle, na ile liznąłem TMCSów (systemów sterowania pojazdami), to tam komunikacja jest raczej dosyć surowa z odczytywaniem bitów i bajtów po adresach/pozycjach w ramce. MQTT wraz z bibliotekami pozwoli to opakować w trochę bardziej przyjazną formę odczytu. Na pewno nie będzie to ciągnięcie danych z internetu - dane będą przetwarzane i wystawiane lokalnie, szczegółów podłączenia nie znam, ale na pewno będą podane.

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:

Czytam, po translacji: Jedną z takich usług opracowanych przez BMW Mobility Services jest produkt car-sharingowy dla operatorów flot. Usługa ta umożliwia operatorom zdalne zarządzanie flotą pojazdów, wydawanie zdalnych poleceń poszczególnym pojazdom (np. blokowanie/odblokowywanie) oraz gromadzenie danych z każdego pojazdu. Mam jeden pulpit i jedna lokomotywę, pulpit lokalny, podłączony do portu komunikacyjnego. Mnie interesuje takie rozwiązanie, a nie ciągnięcie danych z internetu o lokomotywie, która mam lokalnie. Do tego nie jest mi potrzebny żaden pośrednik (chyba że sprzętowy), ale nie kolejny serwer czy coś w tym rodzaju... Chyba jestem idiotą, bo ni w ząb tego nie rozumiem, zatem kończę wtrącanie się w tematykę, która mnie przerasta.

Adding a fictional track that magically removes trains from existence and/or somehow transports them on a fictional route in order to stop them running on real tracks where they'd obstruct other trains completely goes against the entire premise of SimRail altogether, it's a terrible solution for a multitude of reasons, and I don't even know where to start. I'm with jeroezie here: Separating the traffic would make the entire track boring for both the dispatchers and the drivers, and it's important to keep in mind that passenger and freight trains can coexist, which they do, on real tracks, in real life. I also agree with Mywasher: In that time-window separation is, after carefully considering the vast inferiority of the other options, like: -The removal of freight trains from CMK altogether, which would make dispatching, like Mywasher said, as boring as watching paint dry -The creation of a fictional alternative route, which is about the most unrealistic solution I can even think of, short of adding jet-assisted takeoff thrusters to all freight locomotives, and -Accepting the current state of having a weird sort of "Pendolino lottery" in which you get delays, annoyed drivers and complaints, sometimes for no apparent reason, the correct (read: "least awful") way to deal with this issue. As a personal note, I prefer dispatching over driving, and while I do agree that mixed traffic is more fun to dispatch, I can't help but notice that having to deal with the chaos it inevitably causes does take some of the fun out of being a dispatcher, especially at the more busy posts, and especially especially when it stems from upstream damage done by AI, over which I have no control, just like the AI seemingly doesn't have control over anything at all. It's not uncommon for the AI to ask me if I can accept a high-priority train on the opposite track because the freight train that it sent out just a few minutes earlier is still blocking the track that goes in the correct direction and, perhaps more importantly, wouldn't have slowed the higher-priority train down even more than it just was by this completely unnecessary kerfuffle.

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.

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

Dobre... 🙂 Ja tam się nie znam, ale czytałem, że to rozwiązanie MQTT to jest do inteligentnych domów i IoT. W motoryzacji np. są różne bardzo nowoczesne rozwiązania, ale jednak sterowanie jest przez "staroświecką" magistralę CAN. To skąd ten upór żeby to stosować do sterowania lokomotywami w symulatorze? W dyskusji tylko same docinki i zgryźliwości jednych wobec drugich, merytorycznej argumentacji jak na lekarstwo. Tylko słyszę że tak, bo to jest nowoczesne. Tak, to będzie sarkazm, nie próba dowalenia komukolwiek, ale czy naprawdę zamiast joysticka wpiętego do portu USB muszę mieć urządzenia wpinane do internetu, bo to jest trendi?

Honestly, for me as someone who primarily, though not exclusively, plays as driver – on the rare occasions that I do play EIJ or EIE, I actually like when things go a little sideways and I don't a green signal immediately everywhere. Always straight through with no disruptions means that you're always on time without even really needing to try, so there's no real challenge, which makes it way less fun for me. This is why I prefer regional trains or freights – keeping the timetable is just generally more challenging and requires more skill (in my opinion). I do agree, though, that being stuck at red signals all the time gets frustrating, too. You definitely need some balance.

Z informacji od różnych osób wyłania się chaos, jednemu się poprawiło na RTX4060, a drugiemu mocno pogorszyło na RTX5070. Na RX9070XT też padaka jest, więc zespół powinien się temu bliżej przyjrzeć.

Se han publicado algunos post en el foro en este sentido, con opiniones diversas al respecto. Voy a contar mi experiencia en relación con el guardado y posterior carga de escenarios en la versión actual de esta opción (beta 9.2) por si le resulta de utilidad a algún usuario de la comunidad hispanohablante. Como entiendo que esta explicación es un poco larga, puedes dejar de leer en este momento y quedarte con esta conclusión: EL GUARDADO Y POSTERIOR CARGADO DE UN ESCENARIO FUNCIONA. Si deseas saber cómo lo he hecho, descarga y lee este archivo adjunto. Guardado y carga de un escenario.pdf