- Symulator MaSzyna -

Symulator EU07 (i nie tylko) => Bieżące Symulatorowe => Wątek zaczęty przez: AntoniS w 19 Października 2020, 02:48:06

Tytuł: L_053 poranek - występujące błędy i problemy.
Wiadomość wysłana przez: AntoniS w 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.
Tytuł: Odp: L_053 poranek - występujące błędy i problemy.
Wiadomość wysłana przez: tmj w 19 Października 2020, 06:16:44
Re: problemy z pamiecia, glupie pytanie, ale czy na pewno uruchamiasz 64-bitowa wersje exe? Mozna to sprawdzic po identyfikatorze wersji exe, w pierwszej linijce log.txt albo na panelu F12 w czasie symulacji (przedostatnia liczba w identyfikatorze, powinna wynosic 64)  Pytam poniewaz wersja 32-bit ma ograniczenie mozliwosci adresowania na poziomie 3 GB, bez wzgledu na to czy uruchomiona jest na systemie 32- czy 64-bitowym.
Tytuł: Odp: L_053 poranek - występujące błędy i problemy.
Wiadomość wysłana przez: Stele w 19 Października 2020, 09:49:42
maxtexturesize: 1722 to jakieś dziwactwo. Jeśli istotnie działa, to zarżnie ci kartę graficzną. Rozmiar musi być potęgą dwójki.
Pierwsze dwa błędy są rozwiązane po stronie exe. 20.09 tu pomoże. Z pozostałymi problemami ruchowymi, to log w zipa i męczyć autora.
Tytuł: Odp: L_053 poranek - występujące błędy i problemy.
Wiadomość wysłana przez: Milek7 w 19 Października 2020, 13:00:43
Nie wiem skąd pomysł na 1722, ale to zadziała tak samo jak 1024.
Tytuł: Odp: L_053 poranek - występujące błędy i problemy.
Wiadomość wysłana przez: AntoniS w 19 Października 2020, 20:18:41
Re: problemy z pamiecia, glupie pytanie, ale czy na pewno uruchamiasz 64-bitowa wersje exe? Można to sprawdzic po identyfikatorze wersji exe, w pierwszej linijce log.txt albo na panelu F12 w czasie symulacji (przedostatnia liczba w identyfikatorze, powinna wynosic 64)  Pytam poniewaz wersja 32-bit ma ograniczenie mozliwosci adresowania na poziomie 3 GB, bez wzgledu na to czy uruchomiona jest na systemie 32- czy 64-bitowym.

:-) nie takie głupie - też mi to wczoraj (dopiero) przyszło do głowy, ale z uwagi na późną porę już tego nie sprawdziłem, a fakt faktem, że przeszedłem z wersji win 32 na win64, ale instalacja Maszyny została po staremu (nie ruszona....) Innymi słowy potwierdzam - cały czas korzystałem z wersji 32bit symulatora... - muszę przyznać, że mam teraz głupią minę... przepraszam zatem za zawracanie głowy, bo przyczyna problemu z pamięcią wydaje się oczywista.

Zatem podsumowując temat (odnośnie tego, co pisał także Stele - zainstaluję najnowszą paczkę, tym razem już dopilnowując, by korzystać z wersji 64bit i jak rozumiem to rozwiąże problemy z rozkładami a mam nadzieję, że problem pamięci także zniknie.

Dzięki serdeczne i przepraszam, bo wychodzi na to, że to ja zadawałem głupie pytania lub też wyszukiwałem nieistniejące w rzeczywistości (bo sam je wcześniej stworzyłem) problemy...
Tytuł: Odp: L_053 poranek - występujące błędy i problemy.
Wiadomość wysłana przez: AntoniS w 19 Października 2020, 20:52:03
Nie wiem skąd pomysł na 1722, ale to zadziała tak samo jak 1024.

No właśnie tak mi się wydawało, że jest to "nietypowe" i wątpliwe :-) rozwiązanie, bo wszędzie właśnie te potęgi 2 występują, ale 1722 (kB) wzięło mi się stąd, że:
rozdzielczość obrazu: 1680×1050, czyli: 1.764.000 punktów, po 4B na każdy z nich, to 7.056.000 B, czyli 6.890,625 kB i dzieląc to na cztery (bo przyjmując czterokrotne przeskalowanie tekstury - każdy jej piksel to 4 piksele na ekranie) daje właśnie 1722 kB (po zaokrągleniu w dół).
Jeżeli to moje rozumowanie to totalne herezje - proszę się nie śmiać (choć jeśli jest to śmieszne, to nie mam nic przeciwko - sam się śmieję), ale moja wiedza w tej kwestii jest całkowicie podstawowa. Swoją drogą to jeśli ktoś umiałby wytłumaczyć dlaczego inna wartość niż potęga dwójki nie ma sensu i dlaczego 1722 działa jak 1024 to będę wdzięczny. Chyba, że błędie założyłem, że to chodzi o rozmiar w kB?
Tytuł: Odp: L_053 poranek - występujące błędy i problemy.
Wiadomość wysłana przez: Joachimowicz w 19 Października 2020, 20:58:52
Chodzi o rozdzielczość tekstur, a nie o to ile ważą.
Tytuł: Odp: L_053 poranek - występujące błędy i problemy.
Wiadomość wysłana przez: tmj w 19 Października 2020, 22:32:57
Swoją drogą to jeśli ktoś umiałby wytłumaczyć dlaczego inna wartość niż potęga dwójki nie ma sensu i dlaczego 1722 działa jak 1024 to będę wdzięczny.
To poniekad zaszlosc z czasow slusznie minionych; komputery ogolnie lubia potegi dwojki, i dawno, dawno temu rozdzielczosc tekstur obslugiwanych przez karty graficzne byla ograniczona wlasnie do kolejnych poteg dwojki. Technika poszla do przodu, ale ze wzgledu na to ze duzo uzytkownikow symulatora ze sprzetem do przodu nie poszla ten standard jest utrzymywany.
Tytuł: Odp: L_053 poranek - występujące błędy i problemy.
Wiadomość wysłana przez: AntoniS w 31 Października 2020, 16:41:15
Rozumiem i dziękuję za wszystkie odpowiedzi.

Trochę spóźnione (za co przepraszam), ale odnośnie wymienionych w tym wątku problemów:
1. Przyczyną problemów z pamięcią rzeczywiście było uruchamianie przeze mnie wersji exe 32-bit zamiast 64-bit :-) - po "przejściu na wersję 64-bit problemy zniknęły, choć przyznam, że przy uruchomionych innych programach np. kilka stron w firefoksie plus jakiś excel i word lub tym podobne zdarzają się sporadycznie komunikaty systemowe o potrzebie zamknięcia aplikacji z powodu braku lub małej ilości pamięci albo o utracie danych. Jednak jak dotąd nie doświadczyłem awarii symulatora podczas symulacji związanej z brakiem pamięci.
2. Po zainstalowaniu najnowszej wersji tj. 20.09 problemy z wczytywaniem rozkładu jazdy do innego pojazdu w składzie niż pierwszy w kierunku jazdy i związane z tym blokowanie ai danego składu także znikły - czyli tak, jak napisał Stele - kwestie te zostały w tym wydaniu rozwiązane.
3. Odnośnie złego działania scenariusza w Sandomierzu póki co mi się to nie przydarzyło ponownie, więc na razie uznaję, że jest dobrze. Być może błędy te już nie powrócą z uwagi na rozwiązania i możliwości exe z paczki 20.09 albo były one powodowane właśnie przez nieodjeżdżające pociągi. Jeżeli natomiast znowu coś takiego się stanie, wtedy poinformuję autora scenerii (zgodnie z poradą Stele'a).

Dziękuję za pomoc i w sumie chyba temat do zamknięcia...