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 - MW

Strony: [1] 2
1
Co do bałaganu w /scenery - pełna zgoda.  Swój sposób obsługi wdrożyłem u siebie dlatego, że istniejący ok. 2012/13 r. stan był niewystarczający dla potrzeb które się pojawiły przy tworzeniu scenerii. Jak porównuję teraz pliki mające związek z obsługą powtarzaczy w 2013 r. i w nowej paczce to nie widzę istotnych różnic – chyba, że coś przeoczyłem. Jasne, że przy takim systemie plików .inc jaki istnieje w /scenery bez jego przebudowy, nowa funkcjonalność może niestety wymagać dodania nowych plików.
(Uwaga: daty dołączonych plików są nowe ze wzgl. na edycje komentarzy wewnątrz, elementy sterujące zostały dodane w 2013 r.)

Oczywiście, każdy może używać takiego systemu jaki uważa za najlepszy i który spełnia wszystkie jego oczekiwania.

W ramach dyskusji chciałbym się odnieść do uwag Kolegi @Marconi.

1. Odnośnie przeniesienia polecenia sterującego z TO do semafora.
To właśnie m.in. sterowanie powtarzaczami z tarczy było tym, co skłoniło mnie do opracowania swojego sposobu.
Nie bardzo rozumiem, dlaczego obsługa powtarzaczy ma być przywiązana do obsługi tarcz ostrzegawczych. Na realnych stacjach istnieje wiele semaforów wyjazdowych z powtarzaczami – i tam zwykle nie może być mowy o tarczach.

Kilka przykładów z odcinka Pilawa – Dęblin LK 7 (stan przed modernizacją), kolejne stacje:
Pilawa: powtarzacze do sem. wjazdowego B bez TO, powiązanego z sem. B na podg. Jaźwiny; wjazdowego W z TO.
Garwolin: powtarzacze do wyjazdowych sem. L, M, N, O (brak do wjazdowych)
Ruda Talubska: powtarzacz do wyjazdowego sem. N (kiedyś był też do L, brak do wjazdowych)
Łaskarzew:  powtarzacze do wjazdowych P, R
Sobolew: powtarzacze do wjazdowych P, R
Życzyn: powtarzacze do wyjazdowych sem. C, D, E, F (2 szt. do E), (brak do wjazdowych)
Dęblin: powtarzacze do wyjazdowego H, wjazdowych X, Y

Istniejący obecnie stan w /scenery to sterowanie z ponad 10 includów TO dla jednego oraz dla dwóch powtarzaczy przez jawne podanie ich nazw (parametry p7, p8), a także osobno kilka incl. dla semaforów wyjazdowych (jeśli się nie mylę tylko  4-komorowych)  z poleceniem sterowania jednym powtarzaczem (parametr p7). Może czegoś nie zauważyłem, ale nie widzę istniejącego mechanizmu przesyłania sterowania do następnych powtarzaczy.

Na realnych posterunkach może być od 1 do 3 sygnalizatorów powtarzających do semafora z TO i bez TO i to skłoniło mnie do stworzenia ujednoliconego i spójnego sposobu sterowania SP z uniknięciem  przesyłania ich nazw jako parametrów.

Co do innowacyjności, to jakoś nie widzę, żeby w istniejącym stanie nowe nazwy w inc generowane były przez rozszerzenie przesłanego parametru?

2. Odnośnie rygorów w kwestii nazewnictwa.
Oczywiście można mieć różne zdania, ale wydaję mi się, że pełna swoboda w nadawaniu nazw powtarzaczy właśnie zwiększa ryzyko popełnienia błędu, zwłaszcza przy konieczności jawnego przesyłania ich jako parametrów.
Wydaje się też, że jakaś standaryzacja znacznie ułatwia opracowanie mechanizmów automatyzacji. Oczywiście jest do dyskusji przyjęcie konkretnych form. Zresztą częściowo wyraziłem swoje stanowisko w tej sprawie w pierwszym poście.

Jeszcze raz podkreślę, że nie jest moim zamiarem narzucanie swojego rozwiązanie - chciałem się podzielić. Kto chce może korzystać. Być może kiedyś /scenery zostanie uporządkowane. W końcu obecny stan jest wynikiem 2 dekad spontanicznych działań sympatyków symulatora.

2
Od czasu do czasu na forum poruszana bywa sprawa obsługi sygnalizatorów powtarzających na sceneriach.
Chciałbym tu przedstawić swoje rozwiązanie, które stosuję z powodzeniem od 10 lat.

A. Założenia i działanie:
1. Automatyczna obsługa kolejnych powtarzaczy odbywa się kaskadowo – na zasadzie domina – przez powiązane nazwy. Nie trzeba też przesyłać jawnie żadnych nazw w parametrach „inców” (jak to np. ma miejsce w przypadku tarcz ostrzegawczych). Opisywana metoda jest niezależna od obsługi tarcz ostrzegawczych.
2. Semafor wywołuje event ustawiający sygnał na pierwszym powtarzaczu, który następnie ustawia drugi powtarzacz, a ten z kolei trzeci.
3. Nazwy powtarzaczy muszą być utworzone przez odpowiednie rozszerzenie nazwy semafora. Tu przyjęto następującą konwencję z przyrostkami (przykład dla semafora o nazwie „Zc_B”). Kolejne powtarzacze (maksymalnie 3) powinny  mieć nazwy: „Zc_B_pi”, „Zc_B_pii”, „Zc_B_piii”.
4. Odpowiednie eventy znajdują się w plikach .inc semaforów z przyrostkiem –ps (np. ss5zpcpby-ps.inc) oraz „incach” powtarzaczy z przyrostkiem –d (np. ps3pzbyy-d.inc). W .inc semaforów jest „(p1)_pi_ sygnałpowtarzający”.  We wszystkich „incach” z przyrostkiem -d wywołanie sygnału na następnym powtarzaczu to „(p1)i_sygnałpowtarzający”.
5. Ostatni powtarzacz w kolejności powinien mieć „zwyczajny” .inc (bo nic dalej nie przekazuje) – i tak jest np. przy tylko jednym powtarzaczu.

Jednorazowe, prawidłowe wstawienie na scenerii semaforów i powiązanych powtarzaczy z właściwymi nazwami i „incami” pozwala zapomnieć na zawsze o obsłudze powtarzaczy – odbywa się ona automatycznie.

B. Uwagi do nazw sygnalizatorów powtarzających.
Przyjęta konwencja z przyrostkami nie odpowiada oznaczeniom występującym na planach schematycznych posterunków (gdzie np. jest ISpB, IISpB, IIISpB do semafora B). Tam nazwy są lokalne dla posterunku. Symulator wymaga nazw unikalnych dla całej scenerii. Czyli dla naszego przykładu to mogłoby być np. ISp-Zc_B albo prościej ip_Zc_B itd. Oczywiście taki wariant z przedrostkami można przyjąć i to by działało tak samo jak z przyrostkami (wywołanie w ss*-sp.inc semaforów „ip_(p1)_ sygnałpowtarzający” i w incach –d: „i(p1)_sygnałpowtarzający”).

Wersję z przyrostkami przyjęto głównie dlatego, że na listach sygnałów w edytorze, sortowanych alfabetycznie, nazwy powtarzaczy znajdują się w grupie obok nazwy semafora, co ułatwia ich szukanie i ewentualne dokonywanie zmian/poprawek i w ogóle panowanie nad nimi wśród tysięcy nazw dla całej większej scenerii. Poza tym automatyczna obsługa powtarzaczy powoduje, że formy ich nazw są nieistotne np. dla scenarzystów. Natomiast dla użytkowników symulatora powtarzacze mają widoczne na tabliczkach właściwe „rzeczywiste” oznaczenia ustawione w czasie tworzenia scenerii.
Poza wszystkim okazało się też , że od wersji exe 171023 dodawanie przedrostków do parametru przestało działać.

C. Pliki do testowania/użycia dla zainteresowanych
W załączeniu poniżej jest link do archiwum z dostosowanymi plikami .inc semaforów (ss*-ps.inc) i powtarzaczy (ps*-d.inc). Znajdują się tam pliki, które stosuję na swojej scenerii. Inne semafory łatwo dostosować przez analogię. Uwaga:  w/w „inci” odwołują się do starszych modeli .t3d (takie nadal wykorzystowuję i są one ciągle dostępne w nowej paczce). Dołączony jest też podobny zestaw dla nowych modeli semaforów i powtarzaczy – dla odróżnienia do nazw „inców” dodano na końcu „n” (ss*-psn.inc i ps*-dn.inc, można je sobie przemianować). Pliki należy rozpakować do katalogu „scenery”.

W archiwum jest też mikroscenka do testowania obsługi powtarzaczy. Blisko siebie ustawione semafor, trzy sygnalizatory powtarzające i tarcza ostrzegawcza pozwalają obserwować zmianę sygnałów. Sygnały na semaforze można ustawiać ręcznie kombinacjami klawiszy shift1, shift2,....shift0. W pliku .scn można dla testów samemu wstawiać  różne .inc semaforów i powtarzaczy. Oczywiście obsługa niektórych sygnałów oraz tarczy ostrzegawczej zależy od rodzaju semafora.

https://eu07.pl/userfiles/24693/_SP-obsluga_automat.7z

4
Chciałbym przedstawić kolejną wersję próby rekonstrukcji ruchu kolejowego  w postaci wykresów ruchu pociągów w części OK-4 (Katowice) oraz obszarach przyległych - RJ 2007 (i częściowo RJ 2011). Inspiracją do rekonstrukcji był rozwój dla Maszyny scenerii realistycznych z tych rejonów (LK 61 i 144, LK 14, LK 139 i innych w trakcie tworzenia) .
Pierwsza wersja powstała w 2016 r. w oparciu o metody wypracowane na potrzeby własnej scenerii (IR-2/OK-2). Szczególna uwaga została zwrócona na odtworzenie ruchu towarowego (ruch pasażerski łatwiej zrekonstruować ze względu na dostępność sieciowych rj). Obecna siódma wersja obejmuje większy zakres sieci kolejowej, poprawione zostały też błędy zauważone w poprzednich wersjach.

Być może opracowanie to zainspiruje kogoś do tworzenia nowych scenariuszy dla istniejących/ rozwijanych scenerii realistycznych albo nawet do rozpoczęcia budowy nowej scenerii z innymi liniami tego obszaru (intensywność i różnorodność ruchu kolejowego była/jest tam rzeczywiście imponująca).

Zainteresowanym proponuję zapoznać się na początek z plikiem „IR-4_2007-pociagi7”, gdzie można znaleźć szczegóły dotyczące rekonstrukcji, a także – mam nadzieję - odpowiedzi na większość mogących się nasuwać pytań.

Może warto przy okazji przypomnieć, że na realnych kolejach  wykresy ruchu pociągów są głównymi, podstawowymi dokumentami rozkładu jazdy pociągów. I to  dopiero na ich podstawie powstają inne formy RJP: służbowe, sieciowe, stacyjne itd.  (w przedstawianej tu rekonstrukcji kolejność jest ze zrozumiałych względów odwrotna).
Na PKP sprawy dotyczące tworzenia i publikowania rozkładów jazdy regulowane są w „Instrukcjach o rozkładzie jazdy pociągów”.  Od początku lat 50-tych XX w. były to kolejno instrukcje: R 51 z 23.06.1951 r., R 11 z 28.05.1961 r. (II wydanie z 31.07.1979 r. z uwzględnieniem zmian), Ir-11 z grudnia 2015 r. i aktualna Ir-11 z 12.10.2021 r.
Cytat:  „Wykres ruchu  pociągów jest graficznym przedstawieniem jazdy i postoju każdego pociągu, jako funkcji czasu i odległości”. Wykresy ruchu sporządza się dla poszczególnych linii lub odcinków. Oś pozioma to czas (zakres jednej doby), na osi pionowej odkłada się położenie posterunków ruchu i punktów handlowych.
Już pobieżna analiza wykresu może dać wyobrażenie o całości ruchu kolejowego w ciągu doby na zobrazowanym odcinku linii.

Link do na dole (archiwum może być  od czasu do czasu aktualizowane).
----------------
Zawartość archiwum (wersja 7):

A. Wykresy ruchu

1. RJ 2006/7
 a) Plik "IR-4_2007-pociagi7" - uzupełnienia i komentarze do wykresów oraz wykazy pociągów.
 b) 25 plików "*.TAB" z wykresami ruchu dla programu Timegraph (pierwsze miesiące rozkładu).
(linie/odcinki: LK 1-137a, 4, 8b-62-156, 8b-c, 14-355-281, 61-144b, 93-150, 94-138, 97, 117, 131, 133, 135-132a-277, 137-136-132b, 139, 143a-272, 143b, 144a, 146, 148, 152(+137-135-132), 154-171-141-200, 157-190-191, 181, 190-90)
 c) 11 plików "*.TAB" z wykresami ruchu dla programu Timegraph (po poprawkach RJ).
 d) Stacyjne RJ z próbą rekonstrukcji rozkładu jazdy dla pojedynczych stacji (pliki .xls):
 "Lubliniec_2007", "Cz_Stradom_2007", "Czechowice_Dz_2007", "Bielsko_B_2007"

2. RJ 2010/11 (ograniczony zakres rekonstrukcji  na podstawie niekompletnego zestawu służbowych rj)
 a) Plik "IR-4_2011-pociagi3" - uzupełnienia i komentarze do wykresów oraz wykazy pociągów.
 b) 10 plików "*.TAB" z wykresami ruchu dla programu Timegraph.
(linie/odcinki: LK 1, 61-144b, 93-150, 131, 139, 143a-272, 144a, 146, 152, 181)

B. Przykładowe pliki rozkładów jazdy w konwencji "Maszyny":
 a) Plik "Rozkłady_Maszyna3" - uwagi i komentarze do załączonych rozkładów.
 b) Sto kilkadziesiąt  rozkładów "maszynowych" (*.txt) dla RJ 2007 i RJ 2011.

C. Materiały pomocnicze
 a) Plik "IR4_zmiany_predkosci4" - zmiany prędkości drogowych linii kolejowych ujętych w opracowaniu od RJ 2005/6 do RJ 2013/14.
 b) Plik "IR4_predk_tow_2007_1" - prędkości poc. towarowych w 2007 r.
 c) Plik "WOS_IR_Katowice_2007"
 d) Plik "WOS_IR_Kraków_2007"

D. Dodatek
 Plik "Numeracja_pociągów_od_2000 r" (oznaczenia rodzajów i numerowanie pociągów od 2000 r.)

5

Na dole zamieściłem link do archiwum z ostatnią wersją wykresów ruchu.
W katalogu "RJ_MaSzyna\rj2007_ok4" zostały dodane rozkłady jazdy z parametrami posterunków ruchu dla wyżej wymienionych pociągów osobowych i towarowych (to te z najnowszymi datami).
W plikach rozkładów na końcu znajdują się komentarze dotyczące rekonstrukcji i samych pociągów.
Dodanych jest też kilka przykładowych rozkładów poc. osobowych i pośpiesznych z odcinka Katowice - Gliwice. Łatwo mogą być przerobione na rozkłady także innych pociągów, mijających na odc. Katowice - Chorzów Batory pociągi z projektu scenariusza.

Odcinek LK137 Katowice - Gliwice jest teraz uwzględniony na wykresie LK1. Uzupełniony jest też ruch od Ch.Batory do Tarnowskich G. na wykresie LK131.

Jeśli chodzi o nazwy posterunków, to ponieważ nie znałem ich form (W4) przyjętych na scenerii, we wspomnianych rozkladach występują dwa warianty niektórych nazw. W rozkładach poc. towarowych (przypadkowo) nazwy utrzymane są w konwencji ze scenerii LK61. W rozkładach poc. pasażerskich konsekwentnie zastosowane są formy przyjęte w służbowych rjp - m.in. w szczególności nazwy stacji węzłowych pisane są wielkimi literam i z polskimi znakami diakrytycznymi. Oczywiście będzie to musiało być ujednolicone i uzgodnione z wpisami W4 w scenerii. Kiedyś występowały chyba problemy w traktowaniu przez exe polskich znaków, zwłaszcza wielkich liter (w rozkładach i W4). Nie sprawdzałem jak jest teraz - wówczas na potrzeby swojej scenerii musiałem zrezygnować z polskich znaków (ale poza tym nazwy zostały uzgodnione ze służbowymi rj).

Czasy na posterunkach pośrednich w rozkładach będą musiały być zweryfikowane w trakcie prób symulacji. Chodzi tu o punkty między posterunkami o znanych czasach rozkładowych (z sieciowego rj, albo "Planu zestawiania poc. towarowych PKP Cargo"). Służbowe rj z innych lat mogą tu być tylko częściowo pomocne (por. rozkłady dla 2011r), ze względu na zmienne w ciągu lat parametry linii kolejowych. Największa pewność występuje w przypadku tras katalogowych (są tam szczegółowe rj i mogą to być wzory dla innych pociągów towarowych).
Myślę, że pomocne mogą być zawarte w archiwum pliki "IR-4 Zmiany prędkości..", "IR-4 Prędkosci pociągów towarowych 2007" i WOS.

6
Problemy zauważone przy instalacji najnowszych wersji scenerii Linia61 z dołączonymi mostami.

1. Instalator pobiera chyba tylko nagłówek archiwum 7z z mostami i dalej zawiesza się wskazując niepełną instalację (ok. 89%).
Doraźnie można pobrać archiwum z postu powyżej (2018.12.01), wypakować i ponowić instalację.

2. Po instalacji niewidoczny jest wiadukt drogowy w Herbach Nowych.
Aby temu doraźnie zaradzić należy w pliku „scenery\linia61\l61_tory.scm” podmienić ostatnią linijkę:
//include linia61/wiad_L131-DK46_HN.inc none -1878.884 287.5 -307.112 281.873 0 0 0 0 end
include eng/mostymw/wiad_L131-DK46_HN.inc none -1878.884 287.5 -307.112 281.873 0 0 0 0 end

Poprawka: w załączeniu plik „mostram_psl_24-54_m1.t3d” z poprawioną ścieżką do jednej z tekstur (w archiwum przez przeoczenie pozostała starsza wersja sprzed zmiany katalogów) – należy go umieścić w „models\eng\mostymw\”
(nie aktualizuję na razie archiwum, aby nie mieszać znowu z przedrostkiem).

7
W linku wersja ze zmodyfikowaną strukturą katalogową (zgodnie z sugestiami Stelego).
http://eu07.pl/userfiles/24693/mw_mosty_L61_v2.7z

Zmiany formalne (porządkujące)
1. Do plików ".inc" dodane wykazy tekstur wymiennych.
2. Zmieniona struktura katalogów:
- modele elementów skladowych przesunięte z "models/mw/mosty/" do "models/eng/mostymw/"
- tekstury przesunięte z "textures/mw/" do "textures/eng/mw/"
- pliki ".inc" wstawiające gotowe mosty przesunięte z "scenery/mw/mosty/" do "scenery/eng/mostymw/"
(to tylko dla celów niniejszej archiwizacji - Ra umieścił je docelowo w katalogach linii61)

Uwaga:
Ze względu na zmianę struktury katalogowej, należy podmienić pliki INC z katalogów linii61 !!!

8
Na warsztacie / Odp: Porządki w PKP/EAOS_v1
« dnia: 12 Października 2018, 21:45:45 »
@Joachimowicz:
Przykro mi, że nie zrozumiałeś mojej wypowiedzi. W żadnym miejscu nie dałem do zrozumienia, że czegoś oczekuję lub kiedykolwiek oczekiwałem, że ktoś coś zrobi spełniając jakieś moje zachcianki. Odniosłem się tylko do odpowiedzi na moją uwagę kilka postów wyżej i rozwinąłem swoją argumentację. Obserwuję rozwój Maszyny od 10 lat, widzę potężny postęp i nie przyszło by mi nigdy do głowy, żeby to negować. Z mojej wypowiedzi wyraźnie wynika, że w swojej dłubaninie zdaję sobie sprawę z istniejących jeszcze ograniczeń, radzę sobie z tym po swojemu, do nikogo nie mam pretensji i od nikogo niczego nie oczekuję. Jeżeli tylko nie masz złej woli, przeczytaj to jeszcze raz na spokojnie.

9
Na warsztacie / Odp: Porządki w PKP/EAOS_v1
« dnia: 12 Października 2018, 19:03:17 »
Cytuj
„Węglarce można zarzucić chociażby to, że nie jest to 401W, a CFR/E. Rozumiem, że wagon nie jest tragicznie zły i czymś trzeba zapełnić wahadła z Bogdanki, ale nie jest to dobra droga...”
Akurat doskonale wiem, że tabor LWB to głównie węglarki CRF/E. Jest tylko taki malutki problem, że odpowiedniego modelu w Maszynie jak dotąd brak i np. ja z dużym prawdopodobieństwem graniczącym z pewnością takiego nie stworzę. W tych warunkach ta „niedobra droga” jest dla mnie jedynie racjonalna.  Do czasu, kiedy być może pojawi się właściwy model z odpowiednią teksturą, będę kroczył tą niedobrą drogą i z pewnością żadne cenzorskie zapędy mnie od tego nie odwiodą. Cytowane wyżej frazy miałyby jakiś konstruktywny sens gdyby kończyły się np. tak: „... Ale nie martw się - jest na to rozwiązanie - mamy przygotowany model węglarki CFR/E z teksturą Bogdanki”. Wtedy z mojej strony gratulacje i serdeczne podziękowania.

Wyczuwam w tym wątku jakąś mniej lub bardziej ukrytą dziwną logikę: wywalimy to i tamto wg przyjętych przez nas jakichś arbitralnych kryteriów, a w przypadku różnych zgłaszanych wątpliwości, no cóż – być może ktoś przeniesie tekstury na nowy model, stworzy nowy model, nowe tekstury.  Kluczowe w tym wszystkim jest to, co oddałem tu przez „być może”. Nie trzeba dowodzić, że kolejność powinna być odwrotna. Przykładem niech będą modele ET41 v1 -> v2. Pomijam już to, że przy takim podejściu mogą się poczuć zlekceważeni ci, którzy tworzyli te tekstury. Rzecz jasna, uwagi powyższe nie dotyczą najstarszych, nieczytelnych tekstur.

Odnośnie niezgodności modelu z teksturami, można znaleźć inne przykłady wśród wagonów towarowych, w tym w jednym z najbardziej lubianych, jak się wydaje, wśród użytkowników. Celowo go nie wymieniam, żeby jakiś nieznany jeszcze samorodny entuzjasta nie wpadł na pomysł zabrania się za porządki w imię czystości dogmatycznej.

Inne przykłady różnych niezgodności. W niektórych relacjach pociągi osobowe obsługiwane były i są autobusami szynowymi, dla których, jak wiadomo, brak było w Maszynie użytecznych modeli. Dla testowania realnych RJ stosowałem dostępne modele SN61, których w danym regionie nikt nie widział. Obecnie używam nowego modelu SA134 z teksturą mającą się nijak do testowanych RJ. Mówi się trudno, nie będę rezygnował z testów w imię jakiegoś dogmatu.

Skrajny dogmatyzm nigdy nie prowadzi do niczego dobrego. W realnym życiu, w konkretnych uwarunkowaniach, trzeba często iść na różne kompromisy. Tym bardziej tutaj, gdzie się w końcu bawimy i hobby z samej swojej istoty powinno sprawiać przyjemność, a nie być polem walki rozmaitych dogmatycznych postaw.
Proszę przyjąć moje wypociny bez urazy, w żadnym wypadku nie były moim celem jakiekolwiek wycieczki osobiste, po prostu, może zbyt dosadnie, wyraziłem swój pogląd.

P.S. Odnośnie dogmatyzmu – przypomniałem sobie pewne zdarzenie z własnego życia. Przed laty żona, w imię dogmatyzmu porządkowego wywaliła (co prawda nieświadomie) jakieś moje materiały hobbystyczne. Sam wynosiłem śmieci, nie wiedząc co tam jest. Na szczęście zorientowałem się po kilku godzinach i spędziłem romantyczny wieczór z latarką na śmietniku, próbując coś wyratować, zanim rano zjadą chłopcy na śmieciarce.

10
Na warsztacie / Odp: Exe - zmiany w stosie graficznym i dźwiękowym
« dnia: 11 Października 2018, 17:54:32 »
Dzięki za błyskawiczną reakcję. Na ostatnim exe jest znowu OK.

11
Na warsztacie / Odp: Porządki w PKP/EAOS_v1
« dnia: 11 Października 2018, 17:53:30 »
Podpisuję się obiema rękami pod uwagami Kolegi Eisenmanna. Ze swojej strony dodam, że np. tekstura 401W-LWB (co jej można zarzucić?) jest jedyną dla wagonów tej spółki. Na tworzonej scenerii uruchamiam testowo kilka pociągów zestawionych w całości właśnie z takich wagonów.

12
Na warsztacie / Odp: Exe - zmiany w stosie graficznym i dźwiękowym
« dnia: 11 Października 2018, 17:10:12 »
Od wersji exe 181005 coś zepsuło się z wyświetlaniem peronów tworzonych z obiektów typu „road”. Tekstury są odwrócone, a pionowe krawędzie peronów malowane są nieoczekiwanie na biało (jasnoszarą teksturą ?). W niektórych przypadkach na krawędziach pojawia się jakaś tekstura inna niż zadeklarowana we wpisie. Odwrócenie widać szczególnie przy mapowaniu teksturami niesymetrycznymi.
Problem dotyczy też dróg (w końcu to takie same obiekty), chociaż to mniej rzuca się w oczy niż w przypadku peronów i może umknąć przy pobieżnej obserwacji. Tu wyraźnie widać odwrócenie np. w przypadku tekstury pobocza z białym pasem  „asphalt1_side1”.
Do exe 181003 włącznie wyświetlanie było prawidłowe.
Jeżeli jest to jakiś nieoczekiwany skutek uboczny nowego mapowania podsypek rozjazdów (wprowadzonego właśnie w exe 181005), to melduję, że błędy występują zarówno przy włączonym jak i wyłączonym mapowaniu.

13
Dzięki za uwagę. Poprawione w pierwszym poście. Na marginesie - chyba symulator inteligentnie wyświetlał to prawidłowo mimo błędu. Może dlatego, że to ostatni submodel.

14
O ile się orientuję, to includowanie w t3d jest teraz stosowane w przypadku nowszych modeli pojazdów. Wydaje się to rozsądnym i eleganckim rozwiązaniem pozwalającym na ekonomiczne wykorzystanie przy budowie nowych pojazdów elementów powtarzalnych (np. wózki, sprzęgi itd.) i pewnie znacznie ułatwia tworzenie.

Może się mylę, ale w przypadku obiektów takich jak omawiane w tym wątku może to niestety stanowić pewne utrudnienie dla użytkownika niezorientowanego w strukturze t3d i chcącego zestawić na potrzeby swojej scenerii nowy model z gotowych elementów.
Zapisy w .inc wydają się stosunkowo przejrzyste i łatwo zorientować się w znaczeniu poszczególnych parametrów „node ... models”. W przypadku includowania w t3d należałoby chyba dla każdego elementu składowego podać punkt zaczepienia (zerowy submodel) i w jego transformie dokonać odpowiednich translacji i obrotów (o ile słusznie zakładam, że w t3d nie są rozpoznawane parametry wpisów include). Szczególnie obroty mogą sprawiać trudności – w .inc wystarczy podać intuicyjnie zrozumiały kąt, natomiast w t3d wypełnienie macierzy transformacji może być dla wielu barierą nie do przekroczenia. W tak rozumianych warunkach znacznie mniej przejrzysta zawartość końcowego pliku t3d oraz jego zwiększona objętość mogłyby odstraszać potencjalnych użytkowników.
Ponadto wydaje się, że problemy mogłyby wystąpić w nazwami parent w elementach składowych i nazwami punktów zaczepienia tych elementów w nadrzędnym t3d – trzeba by je uzgadniać, co chyba zanegowało by niezależność modeli składowych i obróciło z niwecz samą ich koncepcję (muszą przecież być zupełnie niezależne).
Pomijam już fakt, że rzeczywiście pliki t3d są usuwane w paczce użytkowej i dla nowego użytkownika chcącego coś zrobić brak łatwo dostępnych wzorów.

15
Co do folderów zasadniczo masz rację odnośnie łatwości szukania. Problem w tym, że tworząc na użytek swojej scenerii modele obiektów inżynieryjnych, przyjąłem, jak napisałem, pewien spójny system modułowy z konsekwentnym symbolicznym nazewnictwem pozwalającym na orientację wśród bardzo dużej liczby różnych elementów składowych (w tym wątku wrzuciłem tylko niewielką część). Dotyczy to w szczególności „models”. Wrzucenie tego w ogólny folder models/eng (zawierający w zasadzie modele gotowe lub moduły innych systemów) powodowało by niezły  bigos nie do strawienia dla użytkowników. Być może rozwiązaniem byłoby umieszczenie tego w wydzielonym podkatalogu w models/eng. Konkretne obiekty wstawiane do scenerii zestawiane są w plikach inc. Te same elementy składowe (models) mogą być wielokrotnie użyte w kontekście różnych obiektów. Czyli faktycznie to pliki inc są ostatecznymi modelami. Te oczywiście można by umieszczać w scenery na przyjętych w Maszynie zasadach ogólnych. Gdyby te mosty miały kiedyś wejść do Maszyny, to zarówno elementy „scenery” jak i „textures” (tu też bym się nie upierał) można by zintegrować z istniejącym podziałem funkcjonalnym katalogów. Jeśli chodzi o kompatybilność z aktualną wersją stabilną scenerii, to wygląda na to, że w plikach, które dotyczą tematu, zasadniczych zmian nie było i powinno to pasować. Tekstury wymienne postaram się wpisać też do inców, chociaż dla mnie źródłowe informacje znajdują się w t3d.

16
Na warsztacie / Propozycja kilku mostów/wiaduktów dla scenerii Linia 61
« dnia: 25 Września 2018, 13:35:31 »
Chciałbym zaproponować kilka nowych modeli mostów/wiaduktów dla scenerii "linia61/144". Modele mogłyby posłużyć do zastąpienia tych dotychczasowych obiektów na scenerii, które najmniej przypominają swoje oryginały. Ich ewentualne zastosowanie pozostawiam do uznania @Ra, jako autora modyfikacji i urealnienia scenerii, a także tych, którzy chcieliby poeksperymentować we własnym zakresie.

Zastosowałem modułową konstrukcję modeli - są zestawiane w plikach .inc z poszczególnych zasadniczych elementów. Umożliwia to lepsze dostosowanie obiektów do sytuacji na scenerii, m.in. dzięki możliwym translacjom i obrotom elementów składowych. Na tej zasadzie można też z dostępnych elementów zestawiać inne obiekty. Modele powstały z wykorzystaniem niektórych - odpowiednio przystosowanych - elementów modeli tworzonych na potrzeby własnej scenerii.

Uprzedzając ewentualne pytania wyjaśniam:
•   Nowe modele nie są ścisłym odwzorowaniem realnych mostów/wiaduktów na interesującym obszarze. Wydaje się jednak, że przypominają je pod względem typu konstrukcyjnego, ogólnego pokroju i zasadniczych wymiarów (z rozsądnym przybliżeniem). Ponieważ nie miałem dostępu do szczegółowych informacji technicznych, do ich utworzenia wykorzystane zostały filmy z jazd i dostępne zdjęcia, w tym ortofotomapa.
•   Modele były z założenia wykonywane z poszanowaniem fps (jeśli chodzi o liczbę wierzchołków i odległości wyświetlania submodeli).
•   Co do szczegółów, to wiele elementów zostało świadomie pominiętych albo odwzorowanych w znacznym uproszczeniu lub jedynie symbolicznie, albo są tylko zamarkowane teksturą. Dotyczy to zwłaszcza elementów mało widocznych z pojazdu, a także drobniejszych i uznanych za mniej istotne dla ogólnego wyglądu obiektu.
•   Wykorzystane zostały uniwersalne tekstury dostępne w symulatorze lub ich modyfikacje oraz inne wykonane na własne potrzeby.
•   Modele elementów betonowych, przęseł z kratownicą otwartą i odbojnic obsługują tekstury wymienne - można je zmieniać w plikach inc. Wykazy pasujących tekstur znajdują się w nagłówkach plików t3d.
•   Modele .t3d i pliki .inc są przystosowane do wstawiania w edytorze RSF na poziomie główki szyny z zerowym przesunięciem w pionie. W przypadku wstawiania z poziomu podstawy szyny, należy je podnieść o 0.18 m.
•   Struktura katalogowa jest przyjęta na potrzeby własnej scenerii. Zwłaszcza podkatalogi w katalogach "models" i "textures" zawierają elementy stanowiące część pewnego całościowego spójnego systemu ze znaczącym symbolicznym nazewnictwem. Do katalogu "textures/eng" dodane zostały modyfikacje istniejących tekstur o nazwach „filar..” (żadne pliki nie są nadpisywane).

Dla celów testowych nowe mosty/wiadukty wstawiłem na jednej z najnowszych modyfikacji scenerii (z lutego 2018). Okazuje się, że po podmianie dotychczasowych obiektów, w niektórych miejscach powstają luki w terenie, które wymagałyby modyfikacji nasypów albo brzegów wykopów. W innych miejscach teren może zasłaniać przyczółki. W kilku przypadkach największe dziury zostały tymczasowo "załatane" dołączonymi do modeli protezami nasypów. Niektóre tory na obiektach wymagały podziału (tam gdzie tor na mostownicach). W kilku przypadkach modyfikacji wymagałaby sieć trakcyjna (zwłaszcza w przypadku wiaduktu LK61 tor nr 2 nad LK131, gdzie pod wiaduktem znalazły się dwa słupy z naprężeniem, przebijające razem z przewodami nośnymi pomost wiaduktu - słupy usunąłem dla testów).

Wykaz modeli:
1.   "most_L61_Gnaszyn_1.inc" - most kolejowy przed wjazdem do st. Gnaszyn, LK61 km 121.3, nad rz. Gorzelanka
2.   "most_L61_Gnaszyn_3.inc" - wiadukt kolejowy, szlak Gnaszyn-Blachownia, LK61 km 123.5, nad ul. Kolorową (a)
3.   "most_L61tor1-L131_old.inc" - wiadukt kolejowy, LK61 tor nr 1 nad LK 131, szlak Herby Stare - Liswarta, wariant starszy
4.   "most_L61tor2-L131.inc" - wiadukt kolejowy żelbetowy, LK61 tor nr 2 nad LK 131, szlak Herby Stare - Liswarta (a)
5.   "most_L61_Lisow.inc" - oddzielnie wstawiane dwa mosty kolejowe, LK61 km 141.0, wjazd na st. Lisów, nad rz. Liswarta
6.   "wiad_L131-DK46_HN.inc" - wiadukt drogowy żelbetowy na DK46 nad LK131, st. Herby Nowe (a)
7.   "most_L131-181_HN_1.inc" - wiadukt kolejowy, tzw. "Żelazny Most", LK131 nad LK181, koło st. Herby Nowe
8.   "most_L181_HN_1.inc" - wiadukt kolejowy żelbetowy, LK181, pod "Żelaznym Mostem" na LK131 (b)
9.   "most_L144_Fosowskie.inc" - most kolejowy, LK144, wyjazd ze st. Fosowskie, nad rz. Mała Panew (c)
10.   "most_L181_WD.inc" - most kolejowy, LK181 km 65.6, za wyjazdem  ze st. Wieluń Dąbrowa, nad rz. Pyszna (b)

Uwagi:
(a) - dołączone protezy nasypów dla tymczasowego załatania luk w terenie powstałych po zamianie modeli.
 (b) - na scenerii w ogóle brak dotąd takich obiektów, niezbędna jest przeróbka nasypów LK181 dla ich umieszczenia
 (c) - zdaje się, że w tej części scenerii (LK144) tory nie były jeszcze gruntowniej zmodyfikowane i nie pasują do ortofotomapy; tor na moście jest robiony chyba flexem o nieokreślonym promieniu i nie można go było rozsądnie podzielić dla celów testowych (wymagany jest odcinek bez podsypki na moście); w rzeczywistości most leży raczej na prostej lub może na połączeniu odcinka prostego z końcem krzywej przejściowej od strony stacji; na szybko ułożyłem surowy tor wjazdowy od strony Ozimka na ortofotomapie i to by się potwierdzało  (zrzut ekranowy mostu na tym torze w załączeniu).

Wśród elementów składowych są w sumie 4 modele przęseł z kratownicą otwartą, 4 modele przęseł blachownicowych, 2(4) modele przęseł żelbetowych belkowych, elementy jednej konstrukcji żelbetowej ramownicowej, elementy jednego wiaduktu drogowego żelbetowego, klika modeli przyczółków, filarów itd.

W dołączonym opisie przedstawiłem wykonane dla celów testowych zmiany w plikach "l61_tory.scm", "l61_elementy.scm" i "v3_teren.scm" (scenery\mw\MW_modyfikacje_v2.txt).

http://eu07.pl/userfiles/24693/priv-mw_mosty_L61_1a.7z

17
Na warsztacie / Odp: Exe - zmiany w stosie graficznym i dźwiękowym
« dnia: 25 Czerwca 2018, 18:38:02 »
To dla jednolitości obsługi RJ. Jeśli w realnym RJ towaru jest np. rozkładowy postój na stacji A z przyjazdem o godzinie  X i odjazdem o godz. Y, to chciałbym to odwzorować w symulatorowym RJ. Jeżeli zajdzie np. sytuacja  opisana wyżej, to pociąg zatrzyma się w peronach z ogonem na szlaku. Sytuacja taka nie zajdzie jeśli w maszynowym RJ będzie przelot, i pociąg zatrzyma przed semaforem. Ale chciałbym, żeby mój RJ odpowiadał realnemu, a to by było odstępstwo. Podobnie z końcem jazdy rozkładowej. Niewidoczne W4 w torach towarowych umieszczam w bezpośredniej bliskości semaforów, co z zewnątrz wygląda jakby pociąg dojeżdżał do semafora. Podobnie niewidoczne W4 umieszczam np. na podg., choć z formalnej definicji W4 jest to bez sensu – robię to po to, żeby podg. był odwzorowany w RJ ,  był widoczny dla AI i aby rozkład się mógł przewijać. Jeszcze raz podkreślę, że takie podejście sprawdza mi się doskonale i uruchamiam testowo pociągi towarowe z dziesiątkami różnych rozkładów wzorowanych na realnych.

P.S. Widzę, że @Stele to już klarownie objaśnił.

18
Na warsztacie / Odp: Exe - zmiany w stosie graficznym i dźwiękowym
« dnia: 25 Czerwca 2018, 17:50:05 »
Owszem, ale to by mogło lawino komplikować sytuację, np. symbole kategorii pociągów zmieniały się wiele razy nawet tylko w ostatnich dwóch dekadach, niektóre były efemeryczne. Trzeba by też uwzględniać różne pociągi służbowe, robocze a tu zmiany symboli i samych kategorii były szczególnie liczne, itp., itd. Z mojego punktu widzenia stosowanie W4 też dla innych niż pasażerski rodzajów ruchu jest w porządku, mimo takich, czy innych niedogodności.

19
Na warsztacie / Odp: Exe - zmiany w stosie graficznym i dźwiękowym
« dnia: 25 Czerwca 2018, 17:28:04 »
Wielkie dzięki, "niepoważne" W4 rzeczywiście ponownie są traktowane serio.

A troszkę "poważniej" o W4 w symulatorze:) Obecnie funkcjonalności związane z tymi wskaźnikami są właściwie jedynym  mechanizmem pozwalającym na rozsądną obsługę rozkładów jazdy, niezależnie od tego czy chodzi o pociągi pasażerskie,  czy towarowe. Jeśli idzie o ruch pasażerski, to wszystkie te sprytne własności związane z W4, jak wybór miejsca  zatrzymania, strona otwarcia drzwi itd. są przydatne w sposób oczywisty. Ale w ruchu towarowym już niekoniecznie -  zwłaszcza strona rozładunku. Mając na uwadze obsługę rozkładów jazdy, W4 (niewidoczne) na torach towarowych mają  największy sens tylko na torach głównych, gdzie trudno oczekiwać czynności ładunkowych.

Zresztą zastosowanie tego jedynego mechanizmu dla wszystkich rodzajów ruchu pociągowego niesie za sobą pewne  komplikacje w przypadku prób odwzorowania realistycznych układów torowych. Weźmy na przykład stację z peronami  znajdującymi się w pobliżu jednej głowicy rozjazdowej i wszystkie tory główne przechodzą przy peronach. Jeżeli w  rzeczywistości na stacji takiej mają miejsce rozkładowe zatrzymania pociągów towarowych, to łatwo zauważyć, że np.  przy wjeździe od strony głowicy przyperonowej, pociąg towarowy zatrzyma się w peronach z końcem za głowicą, być może  jeszcze na szlaku. Jest jeszcze znacznie więcej różnych dziwnych sytuacji. Dotyczy to szczególnie przypadków, gdzie w  realnych rozkładach jazdy występuje jednolita nazwa stacji, to znaczy jeśli nazwy takie nie uwzględniają różnych  rejonów stacji. I tu trzeba iść na kompromis - wbrew faktom trzeba samemu stosować różne nazwy (modyfikacje nazwy  realnej) dla wpisów w RJ i W4, żeby jakoś rozdzielić te różne rodzaje ruchu pociągowego.
Ale takie kompromisy są chyba nieuniknione, bo trudno sobie wyobrazić drugi, obok W4 sposób na obsługę rozkładów jazdy  - bo niby jak AI mogłoby to właściwie rozpoznawać na podstawie analizy rozkładu.

20
Na warsztacie / Odp: Exe - zmiany w stosie graficznym i dźwiękowym
« dnia: 23 Czerwca 2018, 18:12:24 »
Przy okazji porządkowania obsługi parametrów W4, od wersji exe 180618 pojawiły się pewne nieoczekiwane zachowania AI. Nie wiem czy jest to zamierzone, czy też nie.

Objawia się to w przypadku, kiedy pojazd z przydzielonym rozkładem jazdy stoi na torze z przypisanym wskaźnikiem W4, który ma zerowy drugi parametr. Pojazd/pociąg ma rozpocząć jazdę pociągową, albo zatrzymanie wynika z rozkładu jazdy. Po otrzymaniu sygnału zezwalającego pociąg rusza bez „zaliczenia” posterunku (przewinięcia rozkładu) . Nazwa takiego posterunku wyświetlana jest nadal, aż do napotkania W4 z następnych pozycji rozkładu. Sprawa dotyczy w praktyce niewidzialnych W4 przypisanych do torów towarowych.

Być może zostało to wprowadzone w celu wymuszenia wpisów parametrów W4 w sceneriach. Ale czy nie warto byłoby przy drugim zerowym parametrze przywrócić dotychczasowe zachowanie AI w tym aspekcie. Na dużych sceneriach mogą być setki wpisów W4 w torach towarowych i duża część z nich może nadal nie mieć wpisanej użytkowej długości toru jako drugi parametr. Z drugiej strony jeżeli AI dociągnie długi zazwyczaj skład aż pod W4 po wjeździe na taki tor, to nie będzie to taka strata jak w przypadku torów peronowych, gdzie miejsce zatrzymania może być istotne i dobrze jest to kontrolować ze względu na miejscowe warunki. Oczywiście nie zmienia to ogólnej oceny, że co do zasady rozszerzenie obsługi W4 jest godne najwyższej pochwały i jak sądzę było od dawna oczekiwane.

21
Na warsztacie / Odp: Exe - zmiany w stosie graficznym i dźwiękowym
« dnia: 17 Czerwca 2018, 14:07:53 »
Dzięki, wygląda na to, że zgłoszone problemy z AI po zakończeniu jazdy rozkładowej zniknęły w ostatniej wersji.

22
Na warsztacie / Odp: Exe - zmiany w stosie graficznym i dźwiękowym
« dnia: 16 Czerwca 2018, 20:53:27 »
Od wersji exe 180601 uległo zmianie zostało zachowanie AI po osiągnięciu ostatniej pozycji w rozkładzie jazdy.
Po dojechaniu do W4, skład po ok. minucie podjeżdża pod najbliższy semafor. Wygląda to dość dziwnie – np. w przypadku pociągów pasażerskich można sobie wyobrazić, że odjazd następuje podczas wysiadania pasażerów. Uniemożliwia to ponadto wykorzystanie jednopozycyjnych, szczątkowych rozkładów jazdy do łatwego i wygodnego podstawiania próżnych składów pasażerskich / EZT z torów postojowych pod W4 w peronach.
W poprzednich wersjach (sprawdzone do exe 180516) po zakończeniu jazdy skład pozostawał pod W4, oczekując na ewentualne sygnały/komendy – i takie zachowanie AI należałoby uznać za właściwe.
Jak się wydaje, kilka lat temu, podobne do obecnego działanie AI występowało początkowo po wprowadzeniu obsługi W4, ale szczęśliwie zostało to wówczas poprawione.

23
Na warsztacie / Odp: Exe - zmiany w stosie graficznym i dźwiękowym
« dnia: 02 Czerwca 2018, 11:59:34 »
@tmj – serdeczne dzięki za szybkie działanie.  Zgłoszone problemy z manewrami pod W5 zniknęły w wersji exe180601.

24
Na warsztacie / Odp: Exe - zmiany w stosie graficznym i dźwiękowym
« dnia: 01 Czerwca 2018, 08:39:12 »
Zgoda, wiedziałem o tym (przypisanie To do toru nie jest intencjonalne, edytor sam to robi). Nie zmienia to jednak istoty rzeczy - cokolwiek by stało za W5, nie powinno mieć wpływu na zachowanie AI w trybie manewrowym, tak jak to było do wersji exe 170810.

25
W załączeniu minimalny układzik torowy do testowania, wycięty z jednej stacji – same potrzebne gołe tory bez podsypek rozjazdów (bo moich  brak w paczce) oraz niezbędne sygnały.
Muszę  wyjaśnić istotne okoliczności. Testy z omawianymi manewrami przeprowadzałem w specyficznych układach torowych i srk, co ma istotny na działanie AI.
1. Zgłoszone błędy przy manewrach pod W5 dotyczą sytuacji, gdy za W5 znajduje się To następnego posterunku (mam kilka takich stacji na scenerii - tak tam jest też w rzeczywistości ). Teraz stwierdziłem, że w innych sytuacjach (bez To) AI zachowuje się poprawnie także na nowszych exe.
2. Przypadek w wjazdem na żeberko pod Z1 na koźle oporowym, został przeze mnie przez nieuwagę źle zinterpretowany. Chodzi o to, że na stacji, gdzie takie manewry intensywnie wykorzystywałem wystąpiły następujące okoliczności:
- na torach żeberkowych znajdowały się niewidoczne wskaźniki W5, umieszczone tam przed zastosowaniem KO z aktywnymi Z1 i przez nieuwagę nie zostały usunięte.
- kilka torów żeberkowych na tej stacji znajduje się na pochyłości w kierunku KO (ok. 7 -8 promili).
W tej sytuacji problemy zgłoszone jako związane z Z1 należy potraktować jako odnoszące się do W5 na sporym pochyleniu.
W dołączonych torach starałem się odtworzyć w przybliżeniu tę sytuację (to inna stacja).  Testy na załączonych torach wskazują dość losowe zachowanie AI na nowszych exe w tych warunkach – niekiedy błędne jak już opisałem, innym razem AI powstrzymuje się od staczania w kierunku kozła i reaguje na Tm.

Załącznik zawiera dwie wersje układu torowego – jedna z sygnałami sprawiającymi problem, i druga – dla porównania - bez nich.
Można uruchamiać dwa warianty manewrów – bez wjazdu na żeberko (1) i z wjazdem (2). Łącznie są  4 kombinacje. (alternatywne wersje układu torowego są do wyboru w plikach scn ). Jeszcze jedna uwaga: być może na paczce 18.03 będzie wysyp przy starszych wersjach exe (np. 1708nn, ja tak mam) – u siebie testuję na własnej paczce roboczej, aktualizowanej w istotnych elementach.

26
Testy przeprowadzałem na własnej tworzonej scenerii na kilku stacjach dla różnych pociągów towarowych.
Warto podkreślić, że błędne działanie zaczęło się od wersji 170814, która wprowadziła jak się zdaje liczne zmiany w zachowaniu AI i w której przy okazji pojawiły się też inne błędy, m.in. związane z hamowaniem ciężkich składów na spadkach, co zresztą zgłaszałem w tym wątku (2017.09.12). Problemy z jazdą manewrową zauważyłem dopiero teraz wracając po dłuższym czasie do swoich prób w tym zakresie.

27
Chciałbym zgłosić błędne działanie AI w niektórych elementach jazdy manewrowej. Problemy pojawiły się od wersji exe 170814. 

Błędy zostały zauważone podczas testowania symulacji kilku przypadków zmiany czoła pociągu na stacjach węzłowych. W rozkładzie jazdy w parametrach takiej stacji umieszczony jest znak @, powodujący odczepienie lokomotywy, która oczekuje na sygnały manewrowe do oblotu składu, ponownego podczepienia, a następnie na sygnał do kontynuacji jazdy pociągowej.

Zauważone problemy dotyczą następujących sytuacji w trakcie jazdy manewrowej.
1. Wyjazd lokomotywy pod wskaźnik W5
 - działanie poprawne do w. 170810: pojazd odbija się od W5, zmienia czoło i podjeżdża pod najbliższą tarczę manewrową;
 - działanie błędne od w. 170814: lokomotywa ignoruje wskaźnik, wyjeżdża luzem na szlak i radośnie rozpędza się do prędkości rozkładowej (rozkład nie zostaje przewinięty).
2. Wjazd lokomotywy na żeberko zakończone kozłem oporowym z aktywnym wskaźnikiem Z1
 - działanie poprawne do w. 170810: jak w przypadku W5, pojazd odbija się od Z1, zmienia czoło i podjeżdża pod najbliższą tarczę manewrową;
 - działanie błędne od w. 170814: pojazd odbija się od Z1, zmienia czoło i nieoczekiwanie cofa się w kierunku kozła, ignorując tym razem Z1 i w następstwie wykoleja się na koźle; w tym przypadku nawet wcześniejsze podanie sygnału Ms2 jeszcze przed wykolejeniem nie zmienia zachowania AI.

28
Bieżące Symulatorowe / Odp: ET41 v2 - problemy z fizyką
« dnia: 05 Maja 2018, 09:46:01 »
Po podmianie fizyki w członie B (przekopiowanie z członu A wersji v2), czasy przejazdu w testach odpowiadają wersji v1 (a może nawet AI odrobinę żwawiej sobie poczyna). Czyli z tego punktu widzenia jest teraz OK.
----
@Stele: jeśli mnie oczy nie mylą, to na repo w 203e-b.fiz po podmianie nadal pozostały stare parametry w sekcjach „MotorParamTable:” i „RList:”. Swój powyższy test wykonałem po przekopiowaniu także tych sekcji z członu A (ściślej - skopiowałem całość).

29
Bieżące Symulatorowe / Odp: ET41 v2 - problemy z fizyką
« dnia: 04 Maja 2018, 19:03:55 »
W załączeniu wszystkie testowane pliki fiz dla ET41.

30
Bieżące Symulatorowe / ET41 v2 - problemy z fizyką
« dnia: 04 Maja 2018, 18:33:41 »
W związku z planami usunięcia modelu ET41 v1, chciałbym zwrócić uwagę na pewne problemy z fizyką dołączoną do  ET41 v2.
Na tworzonej własnej scenerii od początku stosuję poślizgiem model ET41 v1, intensywnie wykorzystywany do prowadzenia ciężkich pociągów węglowych. Ponieważ model ma być usunięty, postanowiłem zastąpić go wersją v2. Okazuje się, że nowy model zachowuje się wyraźnie gorzej od poprzednika na scenerii z realnym profilem pionowym i w  warunkach ruchu według rzeczywistych rozkładów jazdy.

Przeprowadziłem testy ET41 v2 z kilkoma wariantami plików fiz z najnowszej paczki. Testy wykonane zostały w trybie AI, exe „eu07-x86_180411”,  na scenerii z realnym, zróżnicowanym profilem,  jazda wg rzeczywistego rozkładu jazdy dla pociągu z ET41 + brutto 3200 t.
1. Fizyka przekopiowana z ET41 v1 (203e-a.fiz z dn. 2015-02-08,  203e-b.fiz z dn. 2015-02-15). Jak należało się spodziewać, zachowanie jest takie jak w przypadku v1. Pociąg trzyma się rozkładu jazdy, niekiedy czasy przejazdu poszczególnych odcinków/szlaków są nieco krótsze od rozkładowych. Mając na uwadze, że rozkłady konstruuje się z pewną rezerwą czasową, zachowanie AI z tą fizyką jest w pełni satysfakcjonujące.
2. Fizyka oryginalna z ET41 v2 (203e-a.fiz z dn. 2015-02-15,  203e-b.fiz z dn. 2015-02-09). Daje się zauważyć, że pociąg jest zdecydowanie „mułowaty” na szlakach z przewagą profilu wznoszącego.
3. Dla pewności sprawdzona fizyka v2 z repozytorium (bez wcześniejszego porównania zawartości) – zachowanie AI jak na fizyce v2 z paczki.

Przykładowe czasy przejazdu (każdy odcinek z zatrzymania):
1. Odcinek A - 56.5 km (zróżnicowany profil): wg RJ – 65 min; v1 – 64 min; v2 – 72 min. Opóźnienie v2 „złapane” na szlakach z przewagą jazdy „pod górkę”.
2. Odcinek B – 36.2 km (przewaga profili spadkowych): wg RJ – 37 min, v1 i v2 jednakowo – 36 min.

Przy pobieżnym przejrzeniu zawartości plików fiz, w v2 rzucają się przede wszystkim w oczy różne wpisy w sekcji „MotorParamTable:” dla członów a i b (te z 203e-b są podobne do tych starszych sprzed 2015 r.) . Czy tak ma być?
Co do różnic między wpisami v1 i v2 w innych sekcjach trudno mi ocenić jaki mogą mieć wpływ na dynamikę ruchu. Np. różne współczynniki oporu aerodynamicznego  (większe w v2), chyba tu nie ważą, bo problemy dotyczą ruchu z małymi prędkościami.



Strony: [1] 2