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]
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
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 !!!

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

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

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

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

11
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

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

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

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

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

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

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



18
Na warsztacie / Odp: Exe - zmiany w stosie graficznym i dźwiękowym
« dnia: 13 Listopada 2017, 18:42:18 »
Mam kłopot z zachowaniem AI w przypadku sterowania pojazdami w ukrotnieniu. Problem związany jest z traktowaniem przez AI drugiego pojazdu w ukrotnieniu. Wygląda na to, że po rozłączeniu ukrotnionych pojazdów drugi z nich staje się „martwy” i nie udaje się zmusić AI do przejęcia sterowania nad nim. Dotyczy to zarówno lokomotyw jak i EZT. Sprawa nie jest wydumana, dotyczy sytuacji mogących wystąpić w scenariuszach i najlepiej gdy zilustruję to następującymi przykładami (testowanymi na tworzonej scenerii).

1. Dwie jednostki EZT jadą w ukrotnieniu jako pociąg. Na stacji końcowej następuje rozłączenie składu i zgodnie z realnym RJ i planem obiegów jeden EZT - powiedzmy po kilkunastu min. - jedzie dalej jako inny pociąg, a następnie druga jednostka ma zjechać na tory postojowe, zwalniając tor peronowy dla innych pociągów. Dla informacji: sprzęgi wewnętrzne są zablokowane (-55), sprzęg łączący dwa EZT ma maskę 55.
2. Pociąg towarowy prowadzony jest dwiema lokomotywami, np. pociągową i manewrową, jak to bywa u przewoźników prywatnych. Na stacji końcowej lokomotywa pociągowa po odczepieniu zjeżdża na tor postojowy, a manewrowa ma rozpocząć obsługę bocznic.
3. Dwie lokomotywy luzem przejeżdżają odcinek w ukrotnieniu i po rozłączeniu na pewnej stacji każda ma być skierowana w inne miejsce (tu ukrotnienie zastosowałem dla celów testowych).

Zachowanie AI
Pierwszy pojazd zachowuje się po rozłączeniu zgodnie z oczekiwaniem, drugi niestety nie. Nie reaguje na żadne komendy wysyłane na różne testowane sposoby – z komórki sygnalizatora, z komórki przypisanej w pliku sterującym do odcinka toru, itd. Wygląda na to, że AI traktuje pojazd jako nieobsadzony i nic nie robi. Po pierwszych niepowodzeniach naiwnie założyłem, że jeśli wstępnie, przed rozpoczęciem jazdy pociągowej, złączę manewrami dwa obsadzone pojazdy (dla drugiego testowane headdriver i reardriver), to AI zapamięta, że drugi pojazd był obsadzony i przywróci ten stan po rozłączeniu. Niestety to nie pomogło.
Przy okazji wyszły na jaw pewne osobliwe zachowania.
1. Dwie lokomotywy obsadzone:
a) po połączeniu druga jest zahamowana, AI jej nie odhamowuje i skład stoi bezczynnie nie wykonując kolejnych komend (tabelka skanowania OK). Ten lub podobny problem jest zdaje się znany i był już chyba gdzieś poruszany.
b) kilka razy zdarzyło się, że po rozłączeniu dwóch lokomotyw jadących luzem, druga odrzucana jest do tyłu i porusza się ze stałą prędkością nie reagując na żadne sygnały i wbrew prawom fizyki – nie uwzględnia oporów ruchu i pochyłości toru.
2. Ukrotnione EZT – złączone manewrami dwie obsadzone jednostki. Od październikowych wersji exe pociąg tak zestawiony zatrzymuje się daleko za W4 – całością lub częścią składu. W przypadku gdy zaraz za W4 znajduje się semafor i dalej przed rozjazdem odcinek toru wygaszający semafor, skład sam sobie potrafi zablokować dalszą jazdę. Dotyczy to sytuacji gdy druga jednostka przed połączeniem ma obsadę headdriver (przy reardriver nie zauważyłem tego problemu). Jest to szczególnie niepokojące, bo w scenariuszach mogą zgodnie z realiami wystąpić sytuacje, kiedy do jednostki kończącej jazdę doczepiany jest drugi EZT i skład ma odjechać dalej jako nowy pociąg.

19
Na warsztacie / Odp: Wstęp do linii nr 7
« dnia: 10 Października 2017, 15:11:40 »
@AtapiCl: o ile sobie przypominam, to na dobre w 2011 r. Z wymienionych już powodów tempo znacznie zmalało od ok. dwóch lat.  Być może ktoś mógłby zapytać po co się wpakowałem w takie - w obecnych warunkach – utopijne zadanie. Właściwie to najbardziej interesuje mnie odwzorowanie realnego ruchu kolejowego, stąd od samego początku prac nad scenerią starałem się, aby testowo uruchamiać tam pociągi jeżdżące wg rzeczywistego rozkładu jazdy z realnymi składami i żeby mogło tym sterować AI.  To napędzało rozwój scenerii. Przykładowo, jeśli startuję w Jaszczowie z TMZEc 33694/5 z węglem dla elektrowni Kozienice i dojeżdżam do Sadurek, to rodzi się pytanie, dlaczego nie do Zarzeki, a potem może do stacji końcowej w Świerżach Grn. Tak przyrastały kolejne stacje. I mimo wszystkich oczywistych braków i niedociągnięć scenerii, obserwacja na niej ruchu wielu pociągów jest niezłą zabawą. Budowa nawet skomplikowanych układów torowych w edytorze RSF jest prosta, w miarę szybka i daje sporo satysfakcji. Może kiedyś osiągnie to stan nadający się do publikacji.

20
Na warsztacie / Odp: Wstęp do linii nr 7
« dnia: 08 Października 2017, 11:51:44 »
@KrisMK – jak już pisałem, układ torowy tworzony jest w edytorze RSF na podkładzie ortofotomapy w układzie współrzędnych geograficznych PUWG92 – co daje gwarancje zachowania dużej dokładności odwzorowania wymiarów. Promienie łuków, wielkości przechyłek, długości krzywych przejściowych konfrontowane są z dostępnymi danymi PLK. Gdzie brak takich danych wykorzystywane są dla wyliczenia krzywych przejściowych i przechyłek odpowiednie wzory stosowane w inżynierii dróg kolejowych.
W załączeniu zrzuty z kilku rejonów stacji Pilawa, jak widać brak tu sieci trakcyjnej, terenu i otoczenia.

21
Na warsztacie / Odp: Exe - zmiany w stosie graficznym i dźwiękowym
« dnia: 12 Września 2017, 16:39:38 »
Wrzucę wkrótce jakiś tor testowy.

-------------------
W załączeniu tor testowy na którym można zaobserwować działanie AI na pochyleniach.

22
Na warsztacie / Odp: Exe - zmiany w stosie graficznym i dźwiękowym
« dnia: 12 Września 2017, 16:24:20 »
Zauważyłem, że od wersji exe 0814 występują problemy z hamowaniem w trybie AI (a raczej brakiem hamowania) pewnej kategorii składów w określonych sytuacjach.

Problemy dają się zauważyć np. w następujących warunkach:
1. AI prowadzi ciężki skład towarowy (z lokomotywą ET41 lub ET22 – te sprawdzono) zestawiony z węglarek (sprawdzone dla modeli z Eaos_v1, 408w_v1 i 412w_v1).
2. Pociąg wjeżdża na długi, wielokilometrowy odcinek toru o dużych pochyleniach (spadkach).
3. Przypisany jest rozkład jazdy z zadaną prędkością maksymalną na danym odcinku.
4. Prędkość drogowa wpisana jest w tory.

Zachowanie takiego składu:
1. Po wjeździe na odcinek ze spadkiem pociąg pod wpływem siły ciężkości zaczyna się rozpędzać przekraczając znacznie prędkość rozkładową i drogową. Załóżmy, że prędkości te wynoszą odpowiednio 70 i 90 km/h – skład rozpędza się np. do 115-120 km/h. Ze strony  AI nie widać żadnej chęci do rozpoczęcia hamowania.
2. Jeżeli na drodze przejazdu znajdują się semafory pokazujące sygnał S2, nie wpływa to na powyższe zachowanie AI.
3. Otrzeźwienie AI następuje dopiero po zauważeniu sygnału S1 i chyba innych nakazujących zmniejszenie prędkości.

Powyższe zachowanie AI nie występuje na takim odcinku w przypadku jazdy wspomnianych lokomotyw luzem i składów pasażerskich  z EU07 – innych wariantów nie sprawdzałem.

Testowałem to m.in. na paczce 17.07 (pliki .fiz i .mmd pojazdów aktualne). Sprawdziłem wszystkie wersje exe od 0814 do 0911. Na starszych exe  - do 0810  włącznie - AI działa w opisanych warunkach prawidłowo.

23
Na warsztacie / Odp: Wstęp do linii nr 7
« dnia: 09 Września 2017, 10:59:36 »
@maciekkolej - ad linia 72 - podałem zakres objęty scenerią i dotyczy to wszystkich wymienionych linii. Tam, gdzie jest ujęta cała linia zostało to zaznaczone.

24
Na warsztacie / Odp: Wstęp do linii nr 7
« dnia: 08 Września 2017, 23:50:19 »

To i ja się pochwalę. Również tworzę własną scenerię w edytorze RSF - zacząłem także od linii 7. Sceneria zaczęła się stopniowo rozrastać i obecnie obejmuje większość OK-2 i przyległe rejony OK-1. Łącznie jest to ok. 3500 km w sensie pojedynczego toru.

Oczywiście, tak jak jest to dotychczas ze sceneriami tworzonymi w wymienionym edytorze, nie nadaje się jeszcze do publikacji, głównie ze względu na trudności z tworzeniem terenu. Także sieć trakcyjna czeka na wymiarowe modele i zwiększenie możliwości edytora. Brakuje ponadto większości charakterystycznych dla odwzorowanej sieci budynków kolejowych i innych elementów infrastruktury.

Stan scenerii:

1. Zakres (stacje graniczne scenerii z wylotami co najmniej kilkaset metrów za To):

linia  2: podg Doły - Międzyrzec Podl.
linia  7: Zabieżki - Dorohusk (GP)
linia  8: Czachówek - Zagnańsk
linia 12: Tarczyn - Łuków
linia 13: Grzebowilk - Pilawa
linia 22: Wolanów - Radom
linia 25: I. Bliżyn - Wąchock
    II. Stary Garbów - Chmielów k.Tarnobrz. (dwie niepołączone części)
linia 26: Łuków - Radom (cała)
linia 30: Łuków - Lublin (cała)
Linia 63 (1520 mm): Dorohusk (GP) - Zawadówka Naftobaza (cała)
linia 65 (LHS 1520mm): Miączyn - Puszcza
linia 66: Zwierzyniec Tow. - Stalowa Wola Płd. (cała)
linia 67: Lublin - Lublin Tatary - Świdnik (cała)
linia 68: Lublin - Łętownia
linia 69: Rejowiec - Zwierzyniec Tow.
linia 72: Zawada - Miączyn
linia 74: Sobów - Stal. Wola Rozwadów (cała)
linie 76, 77: Bąkowiec - Świerże Górne/elektrownia Kozienice (cała)
linia 78: Sandomierz - Grębów (cała)
linia 80: Furmany - Olendry (cała)
linia 81: Chełm - Uhrusk
linia 83: Zawada  Zamość Bortatycze (cała)
linia 84: Grębów - Olendry (cała)
linia LWB (kopalniana): Jaszczów - Bogdanka (cała)
- uwzględnione zostały wszystkie łącznice w zakresie scenerii i najważniejsze bocznice.

2. Profil pionowy jest ustawiony wg danych PLK dla kilku linii (w tym 7), dla innych prowizorycznie wg map topo. Długości krzywych  przejściowych i wartości przechyłek dla niektórych linii zgodne są z danymi PLK.
3. Na wszystkich posterunkach ruchu dodana sygnalizacja wg dostępnych danych. Aktywne W4 wstawione na wszystkich torach głównych (zasadniczych i dodatkowych). Wszystkie sygnały niezbędne dla prawidłowego działania AI zostały przypisane do torów.
4. Zastosowane jest jednolite, znaczące nazewnictwo każdego odcinka torów scenerii z uwzględnieniem numeru linii, skrótów nazw posterunków (szlaku) i numeru toru.
5. Prędkości drogowe wg danych PLK wpisane w tory. Ograniczenia również.
6. Trochę własnych modeli mostów, wiaduktów, nastawni, dworców, wież wodnych, kładek, wiat typowych dla niektórych linii, tablice peronowe, perony z trójkątów lub "road" (dla niektórych budynków brak materiałów na tekstury).
7. Testowo został wstawiony tu i ówdzie teren z SRTM i pokryty ortofotomapą i wygląda to bardzo obiecująco. Ale to na razie nie współgra z przekrojami poprzecznymi.

Na scenerii można testowo uruchamiać kilkadziesiąt pociągów wg rzeczywistego RJ z 2006/7 r. (trasy towarowe zrekonstruowane wg dodatku IV do RJ, tras katalogowych i służbowych rj). Sterowanie jest jeszcze prowizoryczne, ale działa OK w trybie AI. Dla każdej głównej linii/ odcinka odtworzono wykresy ruchu z RJ 2006/2007 dla ułatwienia orientacji i ewentualnego dalszego tworzenia scenariuszy. Wykorzystano możliwość zapisu komend w komórkach sygnalizatorów, dynamiczne nadawanie RJ itd., itp. Z założenia żadne zdarzenia zależne od scenariusza nie są przypisywane do torów.

Niestety wymienione ograniczenia znacznie spowolniły rozwój scenerii (teren i oczekiwanie na sensowne wstawianie odpowiednich modeli sieci trakcyjnej, brak odpowiednich budynków itd.).

W załączeniu zrzut widoku scenerii w programie STV z dodanymi opisami. Stan na lato 2016 (linia 8 została już od tego czasu przedłużona na południe).


Strony: [1]