Pokaż wiadomości

Ta sekcja pozwala Ci zobaczyć wszystkie wiadomości wysłane przez tego użytkownika. Zwróć uwagę, że możesz widzieć tylko wiadomości wysłane w działach do których masz aktualnie dostęp.


Wiadomości - AntoniS

Strony: [1] 2 3
1
Bieżące Symulatorowe / Odp: L_053 poranek - występujące błędy i problemy.
« dnia: 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...

2
Bieżące Symulatorowe / Odp: L_053 poranek - występujące błędy i problemy.
« dnia: 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?

3
Bieżące Symulatorowe / Odp: L_053 poranek - występujące błędy i problemy.
« dnia: 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...

4
Bieżące Symulatorowe / L_053 poranek - występujące błędy i problemy.
« 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.

5
Symulator / Odp: Nastawy hamulca.
« dnia: 19 Maja 2020, 00:24:28 »
Rzeczywiście ładnie skomentowany :-)

6
Symulator / Odp: Nastawy hamulca.
« dnia: 18 Maja 2020, 19:21:51 »
OK. Czyli rozumiem, praktycznie jakiekolwiek wpisy w sekcji "trainset" w pliku *.scn są praktycznie bez sensu, gdyż są całkowicie pomijane przez symulator (oczywiście w zakresie nastaw hamulca). W sumie może fajnie by było móc jednak w jakiś trwały sposób (chociaż na jeden przejazd lub do następnej zmiany) móc narzucać jakieś odgórne ustawienia... Jeszcze mam pytanie, czy jest jakiś algorytm (tzn. na pewno jest :-)... ale czy pytanie jaki - losowy, czy jakoś logiczny), wg którego tenże wirtualny rewident nastawia hamulce w poszczególnych wagonach składu? A jeżeli kieruje się jakąś logiką, to czy ktoś może zdradzić jaką (tzn. wg jakiego algorytmu lub jakich zasad)? Będę wdzięczny.

7
Symulator / Odp: Nastawy hamulca.
« dnia: 18 Maja 2020, 02:14:16 »
Rozumiem, dziękuję za informację. A czy jest możliwe określenie kiedy ten wirtualny rewident się przebudza? Czy to jest całkowicie losowe zdarzenie niezależne od niczego?

8
Symulator / Nastawy hamulca.
« dnia: 17 Maja 2020, 23:15:47 »
Witajcie,

zauważyłem, że nawet jeżeli zmienię w tymczasowym pliku scenerii nastawy hamulca, tzn. dla danego składu konkretnie je określę np. "3.BGF" - czyli towarowy, ładowny to po uruchomieniu symulatora i tak hamulce w części wagonów mają inne nastawy np. "P". Mało tego, po ręcznym ustawieniu ich na "G" znów powracają (nijako samoczynnie) do stanu wyjściowego, czyli przełączają się na "P" po np. zmianie kabiny w ciągnącej te wagony lokomotywie. Będę wdzięczny za informację czemu tak się dzieje przede wszystkim co zrobić, by zmiana nastaw była trwała? Ostatnio kilka razy ręcznie zmieniałem nastawy hamulca, niby się udawało, a po chwili gdy sprawdzałem okazywało się, że znowu powróciły do nastaw pierwotnych....

9
Bieżące Symulatorowe / Odp: Opady - zależność rodzaju.
« dnia: 11 Marca 2020, 22:18:25 »
Mogę spróbować. Przyznam szczerze, że nie bardzo czuję się na siłach, bo wprawdzie nie przyglądałem i nie wgłębiałem się jak dotąd w temat, tak tylko rzuciłem okiem na folder ze źródłami symulatora, no i nie wiele z tego rozumiem. Jednak może rzeczywiście, gdy się zagłębię w temat, to nie będzie to wszystko takie nie jasne. Póki co, to nie bardzo w siebie wierzę, więc tym bardziej będę miał satysfakcję, jeżeli by mi się udało. Najgorsze, to znaleźć na to czas - nie wiem kiedy uda mi się uda, ale się postaram. W razie czego pozwolę sobie zwrócić się z prośbą o pomoc - oczywiście, nie na zasadzie zrób to za mnie :-) tylko ewentualnie o wskazówki lub podpowiedz :-).

Pozdrawiam!

10
Bieżące Symulatorowe / Odp: Opady - zależność rodzaju.
« dnia: 11 Marca 2020, 21:18:15 »
W sumie wciśnięcie mu tego do gałęzi mogłoby być dobrą rozgrzewką na zapoznanie się z kodem, nie wymagającą programowania. :)

Czy sugerujesz, żebym spróbował to zrobić?

11
Bieżące Symulatorowe / Odp: Opady - zależność rodzaju.
« dnia: 02 Marca 2020, 00:37:31 »
No wiem, tylko z kolei wg mojej wiedzy exe Milka różni się z kolei innymi kwestiami od tmj, czyli tego, które jest w paczce całościowej... Nota bene, ja mam to z paczki całościowej i o ile dotąd zawsze był w logu zapis ładowanych dźwięków, to obecnie go nie ma (przynajmniej w wersji, którą dysponuję)... Czy nie dałoby się tego jakoś przywrócić, a swoją drogą ujednolicić?
Chyba, że to ja mam coś nie tak w ustawieniach, ale szczerze mówiąc zupełnie nie kojarzę, w którym miejscu i w jaki sposób mogłem wyłączyć zapis informacji o ładowanych plikach dźwiękowych?

Choć w sumie nie wiem, czy Twoje przywołanie exe Milka dotyczy tematu opadów, czy zapisu dźwięków? :-) Tak, czy inaczej osobiście uważam, że warto byłoby te dwie kwestie dograć i wydaje mi się (jeśli jestem w błędzie, to bardzo przepraszam), że nie kosztowałoby to zbyt dużo pracy. Jeśli miałbym z kolei wybierać, to wbrew pozorom kwestia logowania plików dźwiękowych jest dla mnie osobiście ważniejsza.

12
Bieżące Symulatorowe / Odp: Opady - zależność rodzaju.
« dnia: 23 Lutego 2020, 02:54:36 »
Przy okazji tego wątku i tej dyskusji mam jeszcze inny wniosek/pytanie:
czy byłaby możliwość, by w logu, podobnie, jak wcześniej zapisywane było które konkretnie dźwięki zostały przypisane w danym pojeździe?
Przepraszam, że w tym wątku, ale to tak, żeby nie mnożyć bytów :-)

13
Bieżące Symulatorowe / Odp: Opady - zależność rodzaju.
« dnia: 23 Lutego 2020, 02:51:43 »
Rozumiem. A nie można wprowadzić zależności, że jeżeli jest podana temperatura, to od jej wartości, a jeżeli jej nie ma, to wtedy od pory roku?

Dodatkowym problemem jest ze przy padajacym w zimie deszczu a nie sniegu na 100% znalazlby sie ktos, komu przeszkadzalby w takiej sytuacji lezacy na scenerii snieg, a tekstur dla zimy bez sniegu nie mamy.

To niestety rzeczywiście jest wielce prawdopodobne... :-) Choć ja dla takich osób miałbym dwa argumenty:
1. W rzeczywistości zdarza się i to wcale nie rzadko przy ciepłym froncie w zimie np. przy wietrze halnym, że jest nagłe ocieplenie i choć na ziemi jest pełno śniegu, to z nieba pada deszcz, a temperatura powietrza to nawet powyżej +5 st. C potrafi być.
2. Jeżeli komuś to bardzo przeszkadza mimo powyższego, to zawsze może sobie odpowiednim wpisem w scenerii lub jej pliku tymczasowym zmienić. Z kolei w obecnym stanie rzeczy dostosowanie rodzaju opadu jest możliwe tylko przez zmianę pory roku, a to pociąga za sobą dużo więcej efektów ubocznych. Innymi słowy przy zależności opadów od temperatury wzrasta, a nie maleje realizm, a do tego jeżeli komuś się nie podoba, to może sobie zmienić. Natomiast w obecnej sytuacji jest to dużo mniej realistyczne, a do tego praktycznie nie możliwe jest dostosowanie rodzaju opadów do temperatury powietrza (tylko przez zmianę pory roku, ale to z kolei wpływa negatywnie na wiele innych rzeczy - choćby kwestie związane z dniem i nocą, przez co jest praktycznie bezsensu, a w dodatku aburdalne.

14
Bieżące Symulatorowe / Opady - zależność rodzaju.
« dnia: 23 Lutego 2020, 00:46:37 »
Witam,

mam taką propozycję, czy nie lepiej by było uzależnić rodzaj opadów występujących podczas symulacji od aktualnie występującej temperatury otoczenia niż sztywno od kalendarza, czyli pory roku? Trochę to nie realistyczne, że niezależnie od temperatury ustawionej w scenariuszu w styczniu zawsze pada śnieg, a nigdy deszcz, a z kolei w czerwcu jest odwrotnie? Myślę, że nie wiele byłoby z tym zachodu, a jednak poprawa realizmu byłaby niemała...

15
Pomoc doraźna / Odp: MaSzyna 20.01 - problemy
« dnia: 23 Lutego 2020, 00:23:53 »
Dzięki za informację - spróbuję z tym move jeszcze. Co do ilości pamięci, to wg menedżera zadań eu07.exe z załadowaną scenerią l053_noc zajmuje ok. 1,6 GB pamięci, także nie przekraczam tutaj żadnych limitów. Mało tego według menedżera zadań zajętość pamięci jest na poziomie ok. 75% a symulator kończy przedwcześnie swoje działanie z komunikatami, jak opisywałem wcześniej - i tego za bardzo nie mogę zrozumieć. Bo gdybym miał 1005 zajętej pamięci i symulacja zostałaby przerwana przy próbie zapisu jakiejś kolejnej rzeczy w pamięci, to ok. rozumiem - brakło miejsca, ale tak, to albo informacje pokazywane w menedżerze zadań nie są rzeczywiste, albo coś jeszcze jest nie tak. A co do pliku stronicowania, to zawsze wydawało mi się, że właśnie służy on temu, by umożliwić pracę systemu i innych programów w momencie, gdy w pamięci fizycznej brakuje dla nich miejsca. Czy z tego co napisałeś wynika, że jeżeli mam system 32-bit i 4 GB RAMu, to włączenie stronicowania pamięci RAM na dysku nie ma sensu, bo i tak system tego zasobu nie użyje?

W między czasie doszedłem do tego, że w dużej mierze problemy powodowało podanie w pliku ini większej rozdzielczości obrazu niż ustawiona jednocześnie maksymalna możliwa rozdzielczość monitora - po skorygowaniu tego wpisu symulator zaczął o wiele lepiej na tej scenerii działać, jednak nadal maksymalnie, co pozwala na jego używanie to rozmiar tekstur zmniejszony do 256 a tekstur kabiny do 1024.

16
Pomoc doraźna / Odp: MaSzyna 20.01 - problemy
« dnia: 17 Lutego 2020, 23:11:55 »
Jeszcze w załączeniu okno informacyjne z Windowsa z zamknięciu eu07 - problem dotyczy ucrtbase.dll.

17
Pomoc doraźna / Odp: MaSzyna 20.01 - problemy
« dnia: 17 Lutego 2020, 22:05:30 »
Jeszcze jedno: czy możliwe jest, że coś w plikach maszyny albo innych zasobach, z których korzysta się przestawiło/przestało działać? Pytam, bo obecnie uruchomiłem symulację na "pustym" tj. świeżo uruchomionym systemie, zużycie pamięci RAM na poziomie 2,66 GB (po za ładowaniu symulacji), tj. 65% wykorzystania pamięci fizycznej, z czego zadeklarowane przez eu07 - ok. 1,6 GB  efekt jak wcześniej tj. wywalenie symulacji nie długo po starcie. W załączeniu log, error, ustawienia oraz screen z menedżera zadań (po załadowaniu symulacji, gdy jeszcze działała - tuż przed wywaleniem...)? Szczerze mówiąc nic już z tego nie rozumiem...

Innymi słówy, czy jest sens ponownie instalować maszynę, czy tylko przeinstalować któreś pliki, czy w ogóle to nie tu jest problem?

Usuwam załączony screen - masa zbędnego białego miejsca. Do robienia screenów zamiast Painta użyj lepiej narzędzia wycinania, w Win10 jest pod skrótem klawiszowym WIN+Shift+S i wytnij tylko potrzebne informacje.

18
Pomoc doraźna / Odp: MaSzyna 20.01 - problemy
« dnia: 17 Lutego 2020, 19:23:35 »
Wyprobuj moze taki zestaw wpisow:
gfxrenderer simple
maxtexturesize 512
maxcabtexturesize 1024
Część scenariuszy takich jak nowsze l053 mogą i tak mieć problem z wersja 32-bitowa -- różnorodność użytego tam taboru prowadzi do zużycia pamięci na poziomie 6-8 GB czyli grubo powyżej tego, co może zaadresować 32-bitowy Windows.

Przepraszam, że powracam do tematu, który w tej dyskusji zszedł już trochę na bok, jednak problem cały czas mnie dręczy - praktycznie 97,5% :-) uruchomień kończy się zakończeniem zaraz po załadowaniu misji i przystąpieniu do uruchamiania lokomotywy. Problem zawsze ten sam tzn.: "...memory bad allocation". Ustawienie simple niestety nic nie zmienia (w zużyciu pamięci widocznym w menedżerze zadań. Wczoraj natomiast, gdy włączyłem plik stronicowania pamięci na dysku, na którym mam maszynę (na systemowym mam włączone cały czas w zakresie 4000-6000 MB) z zakresem 16-2705 MB raz, czy dwa razy z rzędu udało mi się uruchomić i mnie nie wywaliło (sam po chwili zakończyłem symulację) przy czym menedżer zadań pokazał ponad 3,6 GB przydzielonej pamięci i jednocześnie określił jako ok. 50% zajętości (zwykle po uruchomieniu symulacji jest przydzielone między 3,1-3,4 GB, symulacja się zawiesza i kończy w/wym. błędem, a poziom zajętości pamięci menedżer zadań pokazuje w granicach 80-90%... Niestety, gdy następnie zmieniłem ustawienia rozmiaru na 2048 - 2048 problem powrócił, podobnie i nawet po ustawieniu opcji, by system sam decydował o wielkości pliku stronicowania nic nie pomaga. W związku z powyższym mam kilka pytań i bardzo proszę o odpowiedź oraz pomoc tych, którzy się bardziej na tym znają ode mnie, otóż:
1. Czy zakładając, że systemowe 4GB fizycznie zainstalowanego RAMu jest za mało, to system ładując/wykonując symulację nie powinien skorzystać z pliku stronicowania?
2. Jak ewentualnie go do tego zmusić lub co może być nie tak, że przeważnie tak się nie dzieje?
3. Czy rzeczywiście jedyny możliwy sposób rozwiązania tego problemu, to przejście na system 64bit-owy, czyli wymiana komputera (w obecnym musiałbym co najmniej wymienić procesor i dokupić pamięci RAM, czy coś jeszcze?).

Powiem szczerze nie bardzo rozumiem, czemu raz (choć rzadko) działa, a raz nie. Robiłem windowsowy test pamięci, ale nic nie wykazał. Będę wdzięczny za jakąś pomocną informację lub poradę. Szczerze mówiąc to wymiany sprzętu wolałbym raczej uniknąć, bo choć obecny nie jest może super, ale też nie jest jakiś tragiczny wydaje mi się. Dodam, że FPS-y mam po uruchomieniu rzędu 20-30, gfxrenderer legacy (stawienie na simple nic nie zmienia), a testowany scenariusz to l053_noc. W razie potrzeby oczywiście służę logiem i errorem. Pamięć vRam na karcie graficznej to bodajże 1 GB.

19
Pomoc doraźna / Odp: MaSzyna 20.01 - problemy
« dnia: 06 Lutego 2020, 00:04:01 »
Zatem przejechałem scenariusz l053_noc (udało się cały) jednak na mocno okrojonych funkcjach grafiki oraz ograniczonych teksturach, przy czym pozostałem w trybie legacy. Dokładne ustawienia w załączeniu.

20
Pomoc doraźna / Odp: MaSzyna 20.01 - problemy
« dnia: 05 Lutego 2020, 21:43:28 »
Wyprobuj moze taki zestaw wpisow:
gfxrenderer simple
maxtexturesize 512
maxcabtexturesize 1024
Czesc scenariuszy takich jak nowsze l053 moga i tak miec problem z wersja 32-bitowa -- roznorodnosc uzytego tam taboru prowadzi do zuzycia pamieci na poziomie 6-8 gb czyli grubo powyzej tego, co moze zaadresowac 32-bitowy Windows.

Dzięki serdeczne za poradę - spróbuję i dam znać co i jak. Co do Win 32bit, to przy poprzedniej wersji 19.08 i ustawieniu gfxrenderer=full oraz max rozmiarze tekstur 1024 ok. połowa służb na tym scenariuszu była ukończona, a przy 512 100% (całkowicie bez problemu)...

21
Pomoc doraźna / Odp: MaSzyna 20.01 - problemy
« dnia: 05 Lutego 2020, 03:46:05 »
U mnie jest podobnie na scenerii l053_noc, tzn. wszystko się ładuje, inicjalizuje i po chwili crash... "critical error:memory allocation failure: bad allocation". Gfxrenderer ustawione na "legacy", rozmiar tekstur nawet już na 128... 32-bit Windows 7, 4 GB Ramu (dostępnych 3,48), karta AMD Radeon HD 7300 Series z 1 GB VRAMu.
W załączeniu log i errors.

22
:-)

23
Tylko u Milka zapisuje dźwięki do logu. Tmj nigdy tego nie miał.

Dziękuję za odpowiedź - rozumiem.

Co do wersji, to powiem szczerze, że dla mnie trudny wybór. Rzeczywiście w exe117 jest głośno i nie będę się sprzeczał, że nie :-). Wprawdzie dla mnie to nie problem, bo można sobie ściszyć i to znacznie efektywniej i prościej niż podgłośnić, ale też rozumiem, że nie o to chodzi, by trzeba kombinować. W exe119 jest to bardziej stonowane, ale jednocześnie o niebo lepiej niż w exe oficjalnym z paczki 19.08. Nie wiem, gdzie jest bardziej naturalnie (bliższe rzeczywistości), więc powiem remis i uznając, że jakiś kompromis być musi nie będę protestował, którakolwiek wersja zostanie wybrana. Mam jedynie sugestię, by wybierając właściwą wersję i oceniając, która jest bardziej realistyczna nie patrzeć na głośność bezwzględną konkretnych dźwięków. Myślę, że najistotniejsza jest głośność względna (w stosunku do innych dźwięków), bo jak tu będzie dobrze, to zgłośnić/ściszyć wszystko raczej nie stanowi problemu dla nikogo. Także uważam, że najistotniejsze jest osiągnięcie najbardziej właściwych poziomów poszczególnych dźwięków właśnie w kabinie, bo zdecydowana większość symulacji przez zdecydowaną większość czasu ich trwania jest wykonywana właśnie z punktu widzenia kabiny maszynisty - przynajmniej tak mi się wydaje. Dlatego wg mnie dobrze by było, by wypowiedziało się w tym temacie jak najwięcej praktyków (prawdziwych maszynistów), których na forum raczej też nie brakuje. To właśnie ich zdanie i pogląd w tej kwestii powinny być najważniejsze i decydujące.

24
Chciałem porównać oba exe z konkretnie tymi samym dźwiękami, ale niestety w log .txt nie zapisuje się które konkretnie pliki dźwiękowe zostały wylosowane i przypisane pod konkretne dźwięki... Czy zapisywanie tych informacji w nowych exe zostało już wyłączone, czy to są tylko wersje robocze i przez to nie zapisują pełnego logu? Czy można ewentualnie ten zapis rozszerzyć lub jakoś inaczej sprawdzić który konkretnie zestaw dźwięków został w danej symulacji wylosowany?

25
W nastepnym uaktualnieniu, 20.117 eksperymentalnie zastosowana bedzie inna metoda tlumienia dzwiekow, korygujaca ich zasieg zamiast glosnosci bazowej. Jest to w pewnym sensie szamynstwo, ale efektem powinno byc inne rozlozenie akcentow -- dzwieki o duzym zasiegu jak syreny powinny byc duzo bardziej "odporne" na wyciszenie. Uaktualnienie bedzie dostepne nieco pozniej, gdy wyjdzie prosze o porownanie z wersja obecna i wypowiedzi ktora powinna pojsc w kubel.

Pewnie nikogo to nie zdziwi, gdy powiem, że pomysł mi się podoba. Choć oczywiście zobaczymy jak to wyjdzie. Gdyby coś w tej kwestii można pomóc, to w miarę możliwości chętnie pomogę.

26
Jak już pisałem w innym wątku na podobny temat, w celu uzyskania głośniejszych dźwięków np. syreny, możesz spróbować użyć funkcji normalizacji w programie do obróbki dźwięku, następnie zapisać go w oryginalnym formacie. W niektórych wypadkach daje lepszy efekt, a roboty z tym na 5 minut.

Dzięki za radę. Problem z tym jedynie jest taki, że normalizacja ma dość ograniczoną skalę, a po jej przekroczeniu traci się na jakości dźwięku.

27
Wedlug tego co uslyszalem od ludzi faktycznie prowadzacych pociagi, dzwieki z przedzialu maszynowego sa, przy zamknietych drzwiach, malo slyszalne. To jest cos co mozesz bardzo latwo zweryfikowac -- wpisz sobie na youtube np "EU07 jazda w kabinie" i klikaj do woli. Naprawde trudno jest nie zauwazyc, ze dzwieki nastawnika, haslera czy kranu hamulca sa duzo glosniejsze niz innych urzadzen.
Racja, też to zauważyłem, a skoro tak twierdzą specjaliści to tak jest i kropka. Natomiast pozostaje kwestia trąbek, o które przede wszystkim mi też chodziło. One są na zewnątrz, nad kabiną, nie w przedziale maszynowym i śmiem twierdzić, z góry przepraszam, jeżeli się mylę, że w tejże kabinie podczas jazdy są dość wyraźnie słyszalne, choć oczywiście na zewnątrz (przed lokomotywą) słychać jest głośniej.
Cytuj
Rozumiem ze mozna sie klocic ze jakies tam jedno nagranie nie jest reprezentatywne, ale argument upada gdy takich "niereprezentatywnych nagran" jest dominujaca wiekszosc. Nie powinno byc to rowniez jakims specjalnym zaskoczeniem, bo ostatecznie lokomotyw nie projektuja idioci, ale ludzie ktorzy w ramach studiow sa edukowani w kwestii ergonomii i koniecznosci tlumienia halasu na jaki narazony jest mechanik prowadzacy sklady przez caly dzien/noc.
Nigdy nie podważałem (przynajmniej nie miałem takiego zamiaru) reprezentatywności nagrań, więc jeżeli tak wyszło, to przepraszam. Jedyne co podważałem to poziom wyciszenia w kabinie co poniektórych dźwięków. Przyznaję, że trochę się w tym rozpędziłem i w części było to niesłuszne.

Cytuj
Przed wprowadzeniem dzwiekow pozycjonowanych wszystkie dzwieki w symulatorze byly odgrywane doslownie "w glowie" prowadzacego pojazd. Oczywiscie byly dzieki temu zauwazalnie glosniejsze, ale polemizowalbym ze to wlasnie mialo zero wspolnego z realizmem, i nie powinno byc przedstawiane jako coz, do czego nalezy ponownie dazyc.
Oczywiście. Też tak uważam. Chodziło mi jedynie o wskazanie (znowu podkreślę: w moim, być może błędnym mniemaniu) właściwszej głośności części z tych dźwięków. Na pewno nie sugerowałbym, by "cofać się w rozwoju" ani nie uważam, że tamto było lepsze, czy realniejsze.
W gwoli wyjaśnienia (dla jasności), jak już napisałem - nie było moim zamiarem krytykowanie, czy też twierdzenie, że to co jest obecnie jest źle, czy że było lepiej, czy żeby jakoś specjalnie rozbudowywać do granic możliwości realizm i jakość symulacji dźwięków. Jak już wcześniej powiedziałem - uważam, że nie po to jest ten symulator i nie o to w nim chodzi (to jest symulator jazdy i prowadzenia pociągu, a nie generator występujących przy tym dźwięków). Pozwoliłem sobie poruszyć ten temat po pierwsze dlatego, by upewnić się odnośnie możliwości sterowania głośnością poszczególnych dźwięków, po drugie: by przedyskutować i tą drogą zweryfikować dręczący mnie w jakimś sensie problem, że coś jest za cicho, a coś za głośno. Oczywiście, że gdyby z tej dyskusji wyszło, że w jakimś stopniu mam rację, to fajnie byłoby, gdyby w przyszłości jakoś to zostało uwzględnione w symulatorze, ale nie stawiałem sobie tego za cel ani się przy tym nie upieram. Zwłaszcza, jeżeli w czymś nie mam racji, a także licząc się i uznając fakt, że jest cała masa innych, ważniejszych rzeczy do zrobienia lub poprawienia w symulatorze, a z kolei osób go tworzących jest raczej mała ilość i też mają one ograniczone możliwości czasowe poświęcaniu się temu projektowi.
DLATEGO TYM BARDZIEJ CHWAŁA I DZIĘKI IM ZA TO, CO JEST, BO JEST CORAZ LEPIEJ A W PORÓWNANIU DO TEGO, CO JESZCZE NIE TAK DAWNO BYŁO, TO NAPRAWDĘ OGROMNY POSTĘP!!!

28
... w byku, wyły wentylatory i sprężarka, w kabinie nie dało się rozmawiać. Trzeba było krzyczeć aby coś powiedzieć. Chcecie takie dźwięki?

Nie, nie o to chodzi. Mnie chodzi o poziom poszczególnych dźwięków względem innych dźwięków. Jak ktoś będzie chciał mieć taki realizm, to nie ma problemu sobie podgłośnić. Natomiast problem jest, jeżeli głośność jednych dźwięków jest niewspółmierna do głośności innych dźwięków.

Cytuj
Za to Rp1 dawane w siódemce ciągniętej przez byka, było mało co słyszalne.

No dobrze, tylko ja nie mówię o Rp1 z ciągniętej lokomotywy a słyszanym w innej lokomotywie, tylko o słyszanym w tej lokomotywie, w której jest dawane. Swoją drogą, jeżeli było tam tak głośno, to wcale nie dziwne i możliwe, że tamto Rp1 było mało słyszalne. Choćby właśnie z powodów podobnych do tych, o których mówiłem w komentowanym filmie. Nie uważam także abym się wygłupiał. Nie twierdzę, że mam 100% racji, być może wcale jej nie mam, nie uważam się też za jakiś autorytet w tym temacie, ale to nie znaczy, że nie mogę wypowiedzieć swojego zdania i swoich argumentów licząc m.in. na to, że właśnie zostanie to zweryfikowane i ewentualnie sprostowane lub poparte przez osoby, które w tej kwestii mogą wypowiadać się autorytatywnie przede wszystkim z uwagi na swoje doświadczenie.

29
Cytuj
Podważasz nagrany film, więc nie ma o czym dyskutować.

Nie podważam nagranego filmu. Podważam, a raczej dyskutuję z wnioskami wyciąganymi na jego podstawie. Także na jego podstawie wyciągam swoje wnioski.

30
Cytuj
Na wklejonym przykladzie w okolicy 2:30 mozna zaobserwowac mijanke z innym skladem i dojsc do wniosku ze wyciszenie jakie mamy w symulatorze jest wrecz niedostateczne ;>




Pozwolę sobie polemizować, choć jak już wcześniej wspomniałem nie jestem specjalistą - ani mechem ani akustykiem. Jednak wydaje mi się, że praktycznie niesłyszalna mijanka z innym składem wynika przede wszystkim z faktu, że na dźwięk powstający przy mijaniu składa się przede wszystkim szum powietrza + dźwięki emitowane przez zestawy kołowe (zawieszenie) mijanego składu. Do tego dochodzą oczywiście dźwięki wytwarzane prze ciągnącą go lokomotywę (głównie wentylatory w sytuacji, gdy jedzie on rozpędem bez znacznego przyśpieszania, czy hamowania). Wszystkie te dźwięki są słabo słyszalne, bo nakładają się na na nie bardzo podobne, bliźniacze dźwięki pochodzące z naszego składu, które w dodatku są dużo głośniejsze. Jak do tego dodać jeszcze jakość sprzętu nagrywającego (mikrofonu), to nic dziwnego, że specjalnie składu jadącego z przeciwka nie słychać... podejrzewam, że nawet przelatujący obok samolot zdawałby się w tych warunkach (na nagraniu z jadącego elektrowozu) bardzo wyciszony. Myślę, że w rzeczywistości maszynista doskonale słyszy hałas powstający przy mijaniu innego, jadącego składu. W dodatku chodziło mi głównie o nadmierne wyciszenie dźwięków spoza kabiny, ale pochodzących głównie z urządzeń tej samej lokomotywy, a nie z tła czy otoczenia. Natomiast na filmie akurat sygnał baczność w minucie 1:50 i późniejszych słychać znacznie lepiej, głośniej i wyraźniej niż ma to miejsce w "naszym" symulatorze. Podobnie mijanka ze składem PKP IC (podejrzewam, że jadącym szybciej niż poprzedni towarowy) w 6:13 jest już znacznie lepiej słyszalna, łącznie z Rp-1 podanym z tamtej lokomotywy. Podobne odczucia miałem kiedyś jadąc szynobusem SA-133 (jako pasażer na miejscu zaraz za kabiną maszynisty) . Podawane przez niego sygnały dźwiękowe były bardzo dobrze i głośno słyszalne. Tymczasem w symulatorze wewnątrz kabiny lokomotywy dźwięk syreny tejże lokomotywy swoim natężeniem bardziej przypomina dźwięk słyszany przez pasażera w n-tym wagonie za lokomotywą niż przez prowadzącego ją mechanika. Oczywiście nie chodzi tutaj o to by idealnie odwzorować każdy z dźwięków, bo nie taka jest rola tego symulatora i też jest to kosmetyka, a są znacznie potrzebniejsze rzeczy do zrobienia. Jednak wydaje mi się, że poziom dźwięków w poprzednich wersjach (15.04 czy 17.07) był znacznie realniejszy. Zdaję sobie sprawę, że zmiany wynikły z wprowadzenia pozycjonowania dźwięków i uwzględnienia w ich głośności właśnie miejsca ich pochodzenia - to oczywiście świetnie i bardzo dobrze. Tyle tylko, że to wyciszenie zwłaszcza syren a po części też innych urządzeń lokomotywy, jak np. przetwornica jest z punktu widzenia kabiny maszynisty nadmierne. Szczególnie w odniesieniu do z kolei głośności choćby radio telefonu (gdyby nie to, to nie było by problemu, żeby sobie podgłośnić w ustawieniach systemu albo na głośniku)....
Proszę nie traktować mnie ani tego co piszę jako krytykanta szukającego dziury w całym i czepiającego się o szczegóły, bo nie jest to moim celem. Jedynie dzielę się moimi wrażeniami i odczuciami, nieśmiało licząc, że może w przyszłości coś się poprawi :-)... Natomiast w żadnym wypadku nie dążę i nie namawiam do dalszego rozbudowywania w symulatorze mechanizmów obsługi dźwięków. Wręcz uważam, że to co jest w tym względzie, jest naprawdę dobre i wystarczające - kwestia tylko odpowiedniego zgrania głośności poszczególnych grup dźwięków i ewentualnego skorygowania współczynników wyciszenia.

Strony: [1] 2 3