All Activity

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

I understand, thank you for your explanation! Would it be an -even though arcade- option to add a non-existing track to Lodz Kaliska with a exit/entry point, just to have a location outside the map to send a train to? Or an existing track that gets taken out of the simulation and replaced by a entry/exit point, as if the train has to be shunted in and out that track. So you can add train services in between the existing trains and add some more 'action'?

Up to 1 month of waiting as far as I know. Bug reports usually are accepted within 2 weeks or less, depends if the person responsible for that have time or is available.

How long does it usually take for bug reports to be approved? I filed a bug report about some misplaced props near Lazy Lc about two days ago, and it is still pending approval. By all means, this isn't an urgent issue, and frankly I don't care if or when it gets fixed. I was just curious, because two days is already longer than I was anticipating.

To może protokół MQTT poprzez sprzętowy interfejs MIDI 😉 będzie wilk syty i owca cała 😉 BP,MSPANC

To chyba kwestia tego, której funkcji użyje autor scenariusza. PlayNarrationAudioClip (najczęściej używana) wycisza inne dźwięki na czas odtworzenia pliku komunikatu radiowego. PlayAudioClip nie wycisza innych dźwięków. https://wiki.simrail.eu/en/LUA/functions/PlayNarrationAudioClip https://wiki.simrail.eu/en/LUA/functions/PlayAudioClip

Dołączam się do prośby. Dla mnie jest to bardzo irytujące, psuje imersję. Może pozostawić opcję w ustawieniach dźwięku?

the same answer applies: All three exits on the west side of Łódź are low capacity lines: double track line no. 14 without ABS towards Zduńska Wola, Sieradz, Sędzice, two single track lines no. 15 and 16 from Zgierz towards Łowicz and Kutno combined with some limitations of our engine: (1) a train needs to go from point outside the map and to another point outside the map, (2) no reversing of trains (even EMUs). It means that there is no possibility to increase the traffic by adding trains going only to Zgierz or going the sequence of Retkinia <-> Kaliska (rev.) <-> Chojny as in reality. I think we have about 10 (pairs of) slots per hour and all of them have to be divided between Marysin (to Zgierz), Kaliska (to Zgierz) and Retkinia (to Zduńska Wola via Pabianice, Łask). Maybe it may be a bit artificially optimised for one or two trains more, but it may cause som trains to have excessive long stops. Well, is it a proper one? On the main lines there are missing only three big stations in Warszawa (and all three seem to not be very exciting, although busy) and three - mechanical ones: Sosnowiec Dańdówka (62+171), Piotrków Trybunalski (1) and Sieradz (14). Of course there are also Charsznica, Wolbrom, Jaroszowiec Olkuski, Olkusz - but they are affected by line no. 62 low capacity layout - and signalboxes in side freight lines in Silesia (Staszic, KMB, Stawiska, Kozioł, DTA R5, Przemiarki) - also not exciting, low capacity and remarkably not mixed traffic. Also - I don't get it. How adding signalboxes in one part of the map resolve a problem of too low traffic not being entertaining enough? Does it change a lot if you replace 100 km/h freight train with 120 km/h (or even 140 km/h) passenger train from Knapówka and then you have to go full section from Psary to Góra Włodowska (the longest one!) with reduced speed? Or if you wait in Psary for couple of minutes (if you have good luck, but if you have bad luck you can be stuck in Starzyny at entry signal forever)) when someone sent any train (even 140 km/h 531xx TLK) just before you? To be not distrupted at all we would need to wipe out everything but pendolinos from CMK and create a big time window on the other lines just in case something goes wrong. In the upcoming timetable there might be a bit less of freights during day-time on CMK as we see more details and we can apply some timetable rules more strictly now. In consequence we have already heard that this makes some signalboxes, which are very responsible now like Szeligi, not interesting at all.

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

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.

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