5
« dnia: 19 Października 2020, 02:48:06 »
Witam,
w ramach krótkiego wstępu chcę powiedzieć, że poniżej opisuję występujące i jak dotąd przeze mnie ujawnione problemy/błędy w scenariuszu l-053 południe południe podczas prowadzenia składu nr 1 tj. poc. RPE 23115 "Galicja" - jednak sądzę, że są to błędy "systemowe", a nie związane z konkretną "misją", więc pewnie będą występowały niezależnie od wyboru składu. Jednocześnie z góry przepraszam, jeżeli jakaś kwestia się powtórzy, a była już wcześniej zgłoszona.
Uwaga wstępna nr 2: do symulacji korzystałem z paczki 20.04 pobranej i zainstalowanej 6 maja br. - wiem nie jest to najnowsze wydanie Symulatora, jednak według danych z repozytorium paczki w przedmiotowej scenerii od tego czasu nie zaszły zmiany rzutujące na niżej opisane błędy w scenariuszu, dlatego myślę, że fakt iż nie jest to najnowsze wydanie Maszyny nie ma specjalnego znaczenia.
1. Na początku jednostka EN57 po wjechaniu w peron w Dębicy jako poc. ROJ 23133 nie przełącza się w tryb pociągowy, a pozostaje w manewrowym, w efekcie czego nie odjeżdża planowo z Dębicy (po próbie hamulca i podaniu S10 na semaforze wyjazdowym), co skutkuje zablokowaniem wyjazdu z Dębicy dla innych pociągów. W tym przypadku problem jest związany z tym, że przypisanie rozkładu dla ROJ23133 następuje przed zmianą jego kierunku (po zatrzymaniu w peronie). W efekcie czego rozkład dostaje człon rb, a w międzyczasie następuje zmiana czoła na człon ra (nieposiadający rozkładu) i w efekcie cała jednostka pozostaje w trybie manewrowym. Tutaj pomogło opóźnienie zablokowania nadawania rozkładu jazdy (jest on nadawany przy pomocy zdarzenia "event0" przypisanego do toru na którym stoi nasza jednostka i w oryginale po jednorazowym wykonaniu zmienia się stan komórki pamięci i kolejne wywołania tego "event0" nie powodują już nadania rozkładu po zmianie czoła przez AI). Ja opóźniłem zmianę wartości odpowiedzialnej za realizację tej blokady komórki pamięci (o bodajże 20 czy 30 sek) i w ten sposób AI po zmianie czoła na człon ra dostaje ponownie rozkład, dzięki czemu przechodzi w tryb pociągowy a dalej akcja toczy się zgodnie z założeniem autorów scenariusza.
2. Niestety przejeżdżając "Galicją" przez Rudawę i mijając tam tą jednostkę stojącą przy peronie, która przyjechała jako ROJ 23133 a ma odjechać z powrotem jako ROJ 32134 tylko raz (na kilka razy) zauważyłem, że poprawnie zmieniła kierunek i przeszła w tryb pociągowy. We wszystkich pozostałych przypadkach stoi przy peronie podobnie, jak wcześniej w Dębicy, w rybie manewrowym, z przypisanym właściwym rozkładem jazdy i choć jest już po godz. odjazdu i ma podany semafor wyjazdowy (S10), to nic się nie dzieje. Z oczywistych względów nie czekałem, czy coś się wydarzy, bo mając odjazd swojego składu ruszałem i jechałem dalej. Jednak sądzę, że problem jest dokładnie taki sam, jak na początku scenerii w Dębicy, czyli zmiana rozkładu jazdy następuje zanim/równo ze zmianą kierunku w trybie manewrowym i w efekcie rozkład przypisuje się tym razem do członu ra (tylnego po zmianie kierunku) i przez to dochodzi do zablokowania składu i jego AI. Pewnie zastosowanie podobnego opóźnienia rozwiąże problem - jeszcze nie próbowałem.
Natomiast mam wrażenie, że w obu przypadkach opóźnianie ustawienia komórek blokujących nadawanie rozkładu jazdy jest jedynie "szamaństwem" mającym "na skróty" osiągnięcie pożądanego efektu, a nie rzeczywistym i uniwersalnym rozwiązaniem problemu. No bo co w przypadku opóźnienia albo wykonywania przez symulator w tym czasie jakichś dodatkowych operacji... Zastanawiam się jak można by zrealizować nadanie rozkładu jazdy w bardziej uniwersalny i bezbłędnie działający sposób przy założeniu, że do nadania rozkładu dochodzi podczas postoju składu przy peronie, a jednocześnie przed podaniem semafora wyjazdowego...
Inną kwestią jest fakt, że jeżeli na danym torze stoi więcej niż jeden pojazd (np. lokomotywa i wagon) a przypisanie rozkładu następuje za pomocą komórki pamięci powiązanej z tym torem, to możliwe jest, że rozkład otrzyma wagon, a nie ciągnąca go lokomotywa, co powoduje zablokowanie AI (jeżeli lokomotywa w jakiś inny sposób nie przejdzie w tryb obey_train) - doświadczyłem już tego zjawiska na innej scenerii, gdy usiłowałem nadawać rozkład jazdy stojącemu już na danym torze składowi. Wtedy także rozwiązałem problem przez szamaństwo w postaci odpowiedniego przesunięcia składu - jednak podobnie nie jest to rozwiązanie systemowe, a jedynie doraźne lekarstwo. W związku z tym mam postulat, czy nie można by tego jakoś zmienić, by przypisywany rozkład zawsze trafiał do lokomotywy (nawet jeżeli na danym torze stoi także jakiś inny wagon) albo raczej, by jeżeli rozkład zostanie przypisany do jakiegokolwiek pojazdu z danego składu, to by automatycznie przypisywał się do aktywnej lokomotywy lub obu pojazdów znajdujących się na obu końcach - wersja dla zespołów trakcyjnych? Oczywiście dopuszczam, że takie rozwiązanie byłoby niewskazane lub szkodliwe z innych powodów i dla innych przypadków i dlatego celowo tak nie jest. Jednak w takim przypadku, to aż prosiłoby się o wyraźną informację w opisach dotyczących komendy "timetable", że nadaje ona rozkład temu a temu pojazdowi (z wytłumaczeniem któremu i od czego to jest zależne - jeżeli jest wysyłana np. przez tor, na którym stoi więcej niż jeden pojazd).
3. Raz zdarzyło mi się, że w Żernikach zostałem skierowany na tor lewy (na prawym były prowadzone roboty, więc był czasowo nieczynny). Niestety udało mi się tylko dojechać do Skwarek, gdzie nie doczekałem się na sygnał zezwalający na semaforze. Po długim czasie oczekiwania pojechałem na "S1", by zobaczyć o co chodzi. Na wjeździe do Sandomierza zastałem "korek" tj. składy stojące na obu torach przed S1 na obu wjazdowych (skład na prawym torze wcześniej wyprzedził mnie, gdy stałem na lewym w Skwarkach, bo w między czasie pociąg roboczy zjechał Żernik...) Po oglądnięciu sytuacji ruchowej na obu stacjach w Sandomierzu, stwierdziłem jedynie, że wszystkie składy mają "Stój", więc nie wiem co spowodowało blokadę. Domyślam się jedynie, że z jakiegoś powodu błędnie zadziałała lub nie zadziałała obsługa przebiegów wjazdowych do Sandomierza Towarowego po torze lewym od Żernik (w efekcie czego stojący przede mną skład nie zjechał ze szlaku, więc i nic na tenże szlak nie mogło już wyjechać, bo w między czasie zjechał pociąg roboczy i także prawy tor szlakowy został zablokowany). Podkreślam, że sytuacja ruchowa na Sandomierzu Towarowym zupełnie nie uniemożliwiała wjazdu torem lewym ani tym bardziej prawym.... Taka sytuacja zdarzyła mi się jak dotąd tylko raz, ale też tylko wtedy w Żernikach zostałem puszczony na tor lewy (w pozostałych przypadkach zawsze prawym).
4. Dzisiaj dojechałem do Sandomierza, co udało mi się także kilka razy wcześniej. Jednak na miejscu po raz pierwszy spotkałem się z sytuacją, że przy peronie na którym Galicja kończy bieg (z drugiej strony) stał towarowy TME 414526 - w oczekiwaniu na podanie wyjazdu (według mojego przypuszczenia). Na marginesie: generalnie wszystkie pociągi jadące z Sandomierza w kierunku Dębicy miały dość duże opóźnienia (nawet do godziny), czego przyczyną było, jak mniemam, pojawienie się pociągu roboczego na torze szlakowym nr 1 z Żarnik do Sandomierza i jego zablokowanie. Jednakże dotąd jeszcze wszystko wyglądało normalnie, poza długim postojem w Żernikach i przepuszczeniem 2 towarowych z Sandomierza i zjeżdżającego zaraz po drugim towarowym pociągu roboczego. W Sandomierzu na polecenie dyżurnego odczepiłem się od składu i na Ms2 na semaforze pojechałem do przodu (jak zwykle celem zjechania na postój na Sandomierz Towarowy po zmianie kabiny). Po zmianie kabiny znowu dostałem Ms2 na Tm33, więc ruszyłem, jednak dość szybko okazało się, że jadę wprost na stojący przede mną towarowy TME 414526. Udało mi się przed nim zatrzymać i tu jeszcze nie koniec historii, bo po chwili tenże towarowy ruszył, ale w trybie manewrowym (podejrzewam, że dostał Ms2 na sem. M, które było przewidziane dla mnie... Dojechał więc do Tm23, przed którą znów się zatrzymał, jako że wyświetlała Ms1. Na tym etapie po pewnym czasie oczekiwania zakończyłem symulację jako, że wyglądało na to, że już nic więcej się nie stanie.
Niestety nie dysponuję logami tych symulacji. Jednak ewidentnie obsługa Sandomierza wymaga poprawek uwzględniających "nietypowe (czyli inne niż podstawowy przebieg zdarzeń w scenariuszu)" sytuacje ruchowe. Mogę spróbować przejechać jeszcze raz wymuszając zamknięcie prawego toru do Sandomierza i zapisać loga, jednakże błędy te nie występują zawsze, gdy zamknięcie "1" do Sandomierza ma miejsce, bo wcześniej zdarzyło mi się z dwa razy i jednak takie cuda się nie działy. Inna sprawa, że wtedy pociągi z Sandomierza nie były aż tak bardzo opóźnione i jednocześnie z Żernik pojechałem normalnie (torem prawym), bo pociąg roboczy już zdąrzył zjechać lub zaczekałem, by go wypuścić....
Kolejna sprawa (nie związana już z samą l_053) to problem kończącej się pamięci w wysypu symulatora z errorem "Bad memory allocation" - jakiś czas temu już za moją sprawą była o tym dyskusja... Jednak powracam do tego tematu, bo sytuacja się nieco zmieniła i mam wrażenie, że także jest to jakiś problem z działaniem symulatora - być może akurat na moim sprzęcie.
Mianowicie: obecna konfiguracja mojego sprzętu to:
system: win7 professional 64 bit
10 GB RAM (8+2)
grafika AMD Radeon HD 7350 1GB
procesor: Intel Celeron G1610 2×2,6 GHz
czyli zwiększyłem ilość RAMU i zgodnie z zaleceniami na stronie symulatora (min. 6, zalecane 8 GB) powinna być ona wystarczająca...
Niestety przy takiej konfiguracji, aby móc uruchomić scenerię "l_053 poranek" zmuszony byłem do ustawienia:
-maxtexturesize: 1722 (przy 2048 kończyło się błędem w alokacji pamięci nie długo po starcie) przy innych parametrach na poziomie:
maxcabtexturesize 1024
multisampling 1
usevbo yes
defaultext tga
convertmodels 0
anisotropicfiltering 8
dynamiclights 7
pyscreenrendererpriority normal
shadows yes
shadowtune 1722 250 150 300
splinefidelity 2
gfxrenderer legacy
fullphysics yes
gfx.resource.sweep yes
gfx.resource.move yes
gfx.skippipeline no
gfx.framebuffer.width 1680
gfx.framebuffer.height 1050
gfx.shadowmap.enabled yes
gfx.extraeffects yes
gfx.shadows.cab.range 30
gfx.envmap.enabled yes
gfx.reflections.framerate 1
gfx.postfx.motionblur.enabled no
gfx.postfx.chromaticaberration.enabled no
gfx.smoke yes
gfx.smoke.fidelity 1
python.mipmaps yes
compresstex yes
python.threadedupload yes
czyli tak naprawdę bardzo minimalnie (w stosunku to domyślnych ustawień symulatora)...
Dodatkowo poczyniłem obserwację, że za "wykolejenia symulacji" wskutek problemu z pamięcią zawsze dochodzi, gdy symulator "zeżre" całą wolną pamięć tj. do 10 GB, przy czym zajęte jest ok. 3÷4 lub 5 GB (w zależności od ustawionego rozmiaru tekstur), a reszta jest pamięcią wstrzymaną (która wedle wszelkich reguł i prawideł) powinna być dostępna do wykorzystania w razie potrzeby, a w tym przypadku tak się nie dzieje - zamiast jej wykorzystania symulacja pada z błędem "memory bad allocation"...
Mam zatem prośbe do tych, co się znają w informację, czy mam coś źle w systemie ustawione, czy jednak coś w symulatorze szwankuje, czy co innego powoduje, że mając 10 GB RAMU przy scenerii "l_053 poranek", czyli owszem dużej, ale chyba jednak nie największej mi tej pamięci brakuje, przy czym pamięć "wstrzymana" okazuje się rezerwą nie do ruszenia - przynajmniej dla procesu symulatora, choć według wszelkich informacji, jakie znalazłem i prawideł, do których dotarłem bez problemu system i symulator powinny z niej móc skorzystać (w razie takiej potrzeby)?
Z góry dziękuję za pochylenie się nad tymi problemami i przepraszam za ich mnogość, długość opisu oraz nade wszystko, jeżeli z czymś się powtórzyłem.
Pokaż wiadomości
1 Lubię to