All Activity

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

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

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!

No chciałem, zaspokoiłem też swoją potrzebę przekazania z własnego doświadczenia, że można to zrobić prosto, bez przerostu formy nad treścią, przynajmniej w Maszynie to moim zdaniem wystarcza. Automatyka czy elektronika to moje hobby, nie usiłuję udawać że wiem czegoś, czego nie wiem. Nie lubię też gdy inni usiłują w dyskusji wywierać wrażenie ekspertów, bo nikt nikomu dyplomu czy świadectw kwalifikacyjnych nie przedstawiał. Może za MQTT przemawiają jakieś argumenty, jeśli projekt o który toczy się dyskusja miałby pełnić szersze funkcje niż fizycznego pulpitu zastępującego klawiaturę i przyrządy na ekranie, ale odniosłem wrażenie, że dyskusja jest o owym pulpicie z kontrolkami i wskaźnikami.

There is no space for more trains, route to Sieradz does not have ABS, routes from Zgierz to the north could only have few trains every hour because of the same reason. You could try new timetable which is available on INT5 for example, but dont expect much more traffic but overall it is better than current state. Ł. Kaliska deserve 4 level but do not have much traffic. I can say that is the only station on DLC that has less traffic than IRL, because IRL many trains end or start here. I have already mentioned plans of changing the timetable. You can take part in that on official discord server.

Hijacking the discussion a little bit; if the balance on driving trains and dispatching them is a sensitive thing, then what happened around Lodz? We've got a great expansion with some more railway lines and a lot of signal boxes, but to be honest, nothing ever happens there. There's this hourly local service and a few IC trains and that's it. For example, Lodz Kaliska is a Difficulty 4 signal box, but the only thing that happens is the few trains that turn to and from Retkinia and then the tedious wait for the next local train to pass by. Is the timetable around Lodz more realistic than the timetables on the CMK? Widzew-Galkowek is great, but everything from the last DLC seems focussed on the single player. Are there any plans to 'upgrade' the DLC timetable to a more 'playable' variant?

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

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ć?

Ja mam komputer z NVidia GTX 1050 mobile (2GB VRAM) (i 12 GB RAM głównego, rocznik ca. 2018). Gra(łe)m w 1920x1080 na minimalnych, na 1/4 rozdzielczosci tekstur, ładowanie gry po wybraniu (zwłaszcza wieloosobowego) scenariusza zajmowało minutę jak nie więcej, i na większych stacjach potrafiło spadać mi do 10FPS. Nawet Lossless Scaling nie pomagało zbytnio. Z nowym ustawieniem 'mipmap', ładuje się subiektywnie krócej, z task managera wynika, że nie używa współdzielonej pamięci VRAM (karta graf. i cpu mogą współdzielić 6GB, tak to jest laptop), ale za to, z tego co zdążyłem zauważyć, chyba nie zacina mi się już na większych stacjach (muszę się jeszcze przejechać parę razy) i osiąga 20-25 FPS (i nadal wygląda jak ... kupa bo to stary sprzęt itp. rozumiem - ale trudno, jest płynnie(j) niż było to jak dla mnie jest 'win') a z LS nawet 40. Jak miałem 'budżet' ustawiony na więcej niż 'niski' to nie mogłem wejść na Koluszki, a nawet na niektóre mniejsze nastawnie (Płyćwia) - gra się wieszała - ale na 'niskim' wszedłem i działało bez problemu.

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

Personally I strongly prefer lines with mixed traffic. These tend to be interesting, because of the mixe. A racetrack with only high speed trains is not very interesting at all. As it happens, the Pendolino is the least interesting train to see passing, since they are all the same.* But I do understand the frustration of running late due to slower trains driving in the way. The SimRail network is running way more trains then the real Polish network. This can cause congestion if bad decisions are made by dispatch (or mistakes by drivers). Maybe the AI could be improved, in handling pt's or looking beyond the first other station? But why your focus to have the CMK as a pendolino racetrack? Having it that way seems a bit of a goal in itself, not only a preference of you, Mywasher. I noticed you keep talking about getting rid of the CMK cargo trains, but seem to not mention ic trains (120 & 140 km/h) holding up pendolino trains, which happens too. Its also very common for ic (both pendolino and normal and slow intercity) to be held up by stopping trains and cargo trains elsewhere. This may in face cause more problems than their are on the CMK, since cargo trains are faster then stopping trains and their are stations for overtaking, with enough distance in-between for planning overtaking. I hope they do remain, but I am aware that they come with plenty of problems. But I play mostly as a dispatcher. In fact, I got this game for the dispatching. I do not care about train sims itself, if its just about driving a train and that's it (driving trains in simrail is, only enough, an acquired taste). To come back on trains holding each other up, stopper trains are often delayed because they are sided to make way for ic trains. Cargo too. And cargo trains get delayed in favour of stopping trains, sometimes even if its an fast cargo train with a higher vmax than the stopper has. All of this can be rather frustrating, but regional and cargo drivers are rarely advocating to get rid of the other trains. Why are CMK Pendolino's so important for you? The CMK is not build as a dedicated high speed only line (when compared to, for example, the high speed line from Amsterdam to Paris). For me, the interaction between trains and different players makes the game interesting. Just seeing green SBL signals is not entertaining for me, even if I am on time. Maybe the schedules could be planned more forgiving, so you can drive delays out and get back on time? Although I have read, that is not very realistic for Poland. And then the fuss with early Pendolino's could return, which where known of complaining about not getting green vmax signals all the way, even if they where very early. Also, Mywasher, you keep talking off the CMK alone. But a lot of delays are encountered outside the CMK. Those wont improve with less cargo trains on the CMK. On the other hand, if the dev team forces cargo trains outside the CMK, they would need to increase cargo traffic outside the CMK to keep the train count balanced. This would create more conflicts outside the CMK. And the schedule is not robust with delays at all. That would just spread everywhere. This already happens. *Well technically, we have nowadays four Pendolino variants running around, but so far I was able to see only the vehicle numbers are different. When it is as it should be, CMK dispatchers should not get to see that.

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 😉

Dear Mywasher Still, I think we see the case differently. Real life dispatching can be really boring as hell without all the other activities. Real life driving can also be boring and you can pass only 2-3 trains during an hour-long drive and have no contact with any dispatcher. And this is the fact that affects the gameplay on the entire map. I see that you see only CMK as a problem, which very limited approach. Redirecting all freights from CMK to LK1 is not a complex solution, it is just moving the problem into other parts of a map and creating a clean playground for some drivers. We can get rid of freights there, but when argument of "realism" kicks in, there come also questions about the limit of it and why this thing is more "real" than the others. Maybe we should cancel most of 16xx/61xx pendolinos, as in reality there are only two or three of them per day? Maybe we should cancel all 161xx/611xx as there are no TLK's to Wrocław via CMK? Maybe we should cancel a half of pendolinos and EuroCity trains to Katowice as in reality they are mixed and pendolinos mostly fill the gaps between international trains? As you can see, all of them make more room on the line to drive trains without delays. AFAIK in normal operations there should be no or very, very low number of overtakes on CMK. No overtakes = always green. Nope, sorry. LK1 is not a proper environment for mixed traffic. The line is not prepared for traffic required by online multiplayer game (as most of our Polish lines). It has a lot of "interesting" solutions in station tracks layouts which significantly decrease capacity. It doesn't matter if it is big station like Skierniewice, Koluszki or it is a small station like Rogów, Płyćwia, Rokiciny, Baby... I hit the wall many times preparing the current timetable and we hit the same wall preparing the next timetable - fundamental design philosophy for those stations and their layouts. Well, but average 50 km/h EN57 or even 70 km/h EN76 put just before 140 km/h Intercity or 160 km/h Sprinter does not ruin the experience for drivers? Maybe in absolute values it sound as less distruptive, but it is even less than 50% of desired speed of a fast train. Then you cannot just set cruise control to 90-100 km/h and go with constant speeed - you have to brake every three blocks as the regional train approaches passenger stop and then you have to accelerate as there are other trains behind you. On the other hand - what about being held in side track in a heavy freight train for too long and falling out of "slot"? I heard complaints about getting stuck in Pruszków or Grodzisk in freight train because dispatcher misjudged necessary time or feared not to delay passenger train instead of letting a freight train go when it was already at full speed and it should reach the planned overtaking spot. I believe that with current tool we will be able to prepare a proper timetable for night time with more freight trains, however with a minimal amount of priority passenger trains it may not set enough pressure on dispatchers.

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

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

The "parking" functionality is common to most modern trains made in Italy and, in simple terms, lets you put the train "in stand-by", so to speak. IRL you'd need to put all levers to zero, empty the brake pipe and put the brake handle in isolated, then, holding the parking key the whole time, you can lower the pantograph switches and remove the master key, and the train will remain on, with the pantographs raised. It is used when changing cab, or when leaving the train in a yard for some hours, so you don't need to turn everything off and on again, and you don't even need to do a brake test.