1
Bocznica / Odp: Odp: Vectron - Texture Set 2
« dnia: 26 Października 2025, 22:05:45 »
Ciii...
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.
2
Na warsztacie / Odp: Przebudowa Ostrowa Wielkopolskiego
« dnia: 13 Października 2025, 19:04:59 »
Dzięki za zainteresowanie i chęć pomocy. Pytanie jednak jest, co umiesz robić i czym?
1. Aby dostosować stację do mapy, w pierwszej kolejności trzeba wyznaczyć azymut jakiegoś długiego i prostego toru. Ponieważ mam RSF dla Ostrowa, z liniami kierunkowymi, azymut można odczytać z linii kierunkowej, np. dla toru przy peronie. Linia kierunkowa podaje kąt 2.2376° i jest to kąt od północy na zachód (czyli azymut będzie 357.7624°).
2. Scenerię "Kaliska" też mam w postaci RSF. Może nie jest to ostatnia wersja, ale nie spodziewam się drastycznych zmian. Wstawiam linię kierunkową w odpowiednik wybranego toru i uzyskuję kąt 159.8463°. Kierunkowa na torze obok daje 159.8284°. Czyli jest pewna dowolność w tym zakresie, bo dokładnie i tak nie będzie pasować. Przyjmijmy kąt z tego drugiego toru, bo wygląda na dłuższy. Azymut będzie w tym przypadku 20.0716°.
3. Z różnicy azymutów wychodzi kąt obrotu scenerii (stacji w zasadzie). Dla podanych wyżej wartości jest to obrót o kąt 22.3092° w prawo (czyli zgodnie z ruchem wskazówek zegara). Wczytać trzeba scenerię (tzn. wystarczą same tory na tym etapie) do edytora SCN w Rainsted, wykonać obrót i następnie przesunąć tory tak, aby coś dopasować, np. peron albo wyjazd na Kalisz. Ogólnie trzeba się zorientować, jaka jest skala niedokładności.
4. Najprostszym mechanizmem przeliczania scenerii jest przeliczenie prostokątami. Polega to na tym, że pierwotną scenerię dzielimy na prostokąty o bokach równoległych do osi układu współrzędnych. Następnie każdy prostokąt może być obrócony o inny kąt i przesunięty o inny wektor. Niestety na łączeniach przeliczonych prostokątów pojawią się błędy, które następnie trzeba poprawić. Przykłady przeliczenia prostokątami można sobie wyświetlić, wybierając w edytorze SCN w Rainsted opcję "Poprawki konkretnych scenerii" z menu Operacje. Lub na zakładce Komórki są przyciski pokazujące prostokąty dla scenerii "Kaliska" o nazwach [Kaliska 2E], [3F], [3G] — są to różne warianty przeliczeń części środkowej i trasy do Częstochowy. Dla Ostrowa podział na prostokąty nie jest jeszcze przygotowany.
5. Jeśli jest już zrobiony podział na prostokąty i są dobrane obroty i przesunięcia dla nich, to dodatkową opcją są trójkąty. Służą one głównie do zmiany promieni łuków. Podaje się środek pierwotnego łuku jako jeden z wierzchołków trójkąta. W Ostrowie prawdopodobnie trzeba będzie kąt wyjazdu na Kalisz, być może również w pozostałych kierunkach.
6. Jeśli podział na prostokąty i trójkąty nie wystarczy, to istnieje jeszcze opcja skalowania prostokątów. Pozwala ona skrócić lub wydłużyć odcinek toru. Trzeba jednak zadbać, żeby w obszarze skalowania nie znalazły się rozjazdy, bo one nie powinny być skalowane (ewentualnie można też przeskalować rozjazdy, ale raczej tylko z 34m na 33.23m, czyli 97.7353%). Skalowanie nie powinno być zbyt duże, bo stanie się widoczne na odległościach pomiędzy słupami.
7. Zakładając, że prostokątami i trójkątami da się przeliczyć stację do zgodności z mapą, kolejnym etapem jest korekta profilu pionowego. Szczegółów w tej chwili nie pamiętam, ale trzeba przygotować niweletę w RSF albo wygenerować listę punktów XYZ dla łamanej przeliczającej i odpowiedni algorytm przeliczy wysokości na scenerii wzdłuż tej łamanej.
8. Dostosowanie linii kolejowej do map jest podobne do dostosowania stacji, tylko trzeba wyznaczyć dużo więcej prostokątów i trójkątów do przeliczenia. Jest też dodatkowa opcja przeliczenia niweletami (która nie nadaje się do przeliczania stacji). W skrócie: trzeba ułożyć dwie niwelety, jedną na scenerii do przeliczenia, a drugą docelową na mapach. Algorytm przeliczający wyznacza pozycję obiektu względem pierwszej niwelety, a następnie umieszcza obiekt w tej samej pozycji względem drugiej niwelety. Pozwala to skalować długość odcinków prostych, zmieniać promienie łuków, a także od razu dodaje profil pionowy. W ten sposób został przeliczony odcinek od Lublińca do Ozimka, dzięki czemu da się już dojechać do Opola i Wrocławia.
W załączeniu przykładowy obrazek z zestawem prostokątów i trójkątów do przeliczenia LK131 do map. Po lewej stronie przed wykonaniem przeliczenia, po prawej po przeliczeniu.
1. Aby dostosować stację do mapy, w pierwszej kolejności trzeba wyznaczyć azymut jakiegoś długiego i prostego toru. Ponieważ mam RSF dla Ostrowa, z liniami kierunkowymi, azymut można odczytać z linii kierunkowej, np. dla toru przy peronie. Linia kierunkowa podaje kąt 2.2376° i jest to kąt od północy na zachód (czyli azymut będzie 357.7624°).
2. Scenerię "Kaliska" też mam w postaci RSF. Może nie jest to ostatnia wersja, ale nie spodziewam się drastycznych zmian. Wstawiam linię kierunkową w odpowiednik wybranego toru i uzyskuję kąt 159.8463°. Kierunkowa na torze obok daje 159.8284°. Czyli jest pewna dowolność w tym zakresie, bo dokładnie i tak nie będzie pasować. Przyjmijmy kąt z tego drugiego toru, bo wygląda na dłuższy. Azymut będzie w tym przypadku 20.0716°.
3. Z różnicy azymutów wychodzi kąt obrotu scenerii (stacji w zasadzie). Dla podanych wyżej wartości jest to obrót o kąt 22.3092° w prawo (czyli zgodnie z ruchem wskazówek zegara). Wczytać trzeba scenerię (tzn. wystarczą same tory na tym etapie) do edytora SCN w Rainsted, wykonać obrót i następnie przesunąć tory tak, aby coś dopasować, np. peron albo wyjazd na Kalisz. Ogólnie trzeba się zorientować, jaka jest skala niedokładności.
4. Najprostszym mechanizmem przeliczania scenerii jest przeliczenie prostokątami. Polega to na tym, że pierwotną scenerię dzielimy na prostokąty o bokach równoległych do osi układu współrzędnych. Następnie każdy prostokąt może być obrócony o inny kąt i przesunięty o inny wektor. Niestety na łączeniach przeliczonych prostokątów pojawią się błędy, które następnie trzeba poprawić. Przykłady przeliczenia prostokątami można sobie wyświetlić, wybierając w edytorze SCN w Rainsted opcję "Poprawki konkretnych scenerii" z menu Operacje. Lub na zakładce Komórki są przyciski pokazujące prostokąty dla scenerii "Kaliska" o nazwach [Kaliska 2E], [3F], [3G] — są to różne warianty przeliczeń części środkowej i trasy do Częstochowy. Dla Ostrowa podział na prostokąty nie jest jeszcze przygotowany.
5. Jeśli jest już zrobiony podział na prostokąty i są dobrane obroty i przesunięcia dla nich, to dodatkową opcją są trójkąty. Służą one głównie do zmiany promieni łuków. Podaje się środek pierwotnego łuku jako jeden z wierzchołków trójkąta. W Ostrowie prawdopodobnie trzeba będzie kąt wyjazdu na Kalisz, być może również w pozostałych kierunkach.
6. Jeśli podział na prostokąty i trójkąty nie wystarczy, to istnieje jeszcze opcja skalowania prostokątów. Pozwala ona skrócić lub wydłużyć odcinek toru. Trzeba jednak zadbać, żeby w obszarze skalowania nie znalazły się rozjazdy, bo one nie powinny być skalowane (ewentualnie można też przeskalować rozjazdy, ale raczej tylko z 34m na 33.23m, czyli 97.7353%). Skalowanie nie powinno być zbyt duże, bo stanie się widoczne na odległościach pomiędzy słupami.
7. Zakładając, że prostokątami i trójkątami da się przeliczyć stację do zgodności z mapą, kolejnym etapem jest korekta profilu pionowego. Szczegółów w tej chwili nie pamiętam, ale trzeba przygotować niweletę w RSF albo wygenerować listę punktów XYZ dla łamanej przeliczającej i odpowiedni algorytm przeliczy wysokości na scenerii wzdłuż tej łamanej.
8. Dostosowanie linii kolejowej do map jest podobne do dostosowania stacji, tylko trzeba wyznaczyć dużo więcej prostokątów i trójkątów do przeliczenia. Jest też dodatkowa opcja przeliczenia niweletami (która nie nadaje się do przeliczania stacji). W skrócie: trzeba ułożyć dwie niwelety, jedną na scenerii do przeliczenia, a drugą docelową na mapach. Algorytm przeliczający wyznacza pozycję obiektu względem pierwszej niwelety, a następnie umieszcza obiekt w tej samej pozycji względem drugiej niwelety. Pozwala to skalować długość odcinków prostych, zmieniać promienie łuków, a także od razu dodaje profil pionowy. W ten sposób został przeliczony odcinek od Lublińca do Ozimka, dzięki czemu da się już dojechać do Opola i Wrocławia.
W załączeniu przykładowy obrazek z zestawem prostokątów i trójkątów do przeliczenia LK131 do map. Po lewej stronie przed wykonaniem przeliczenia, po prawej po przeliczeniu.
3
Na warsztacie / Odp: Kaliska - sceneria do pobrania w pierwszym poście!
« dnia: 25 Sierpnia 2025, 11:21:26 »
Przejrzałem tory i nie widzę, żeby jakieś krzyżowe miały nadmiarowe tory, jest tylko masa niezgodnych końców. Tory się nakładają jedynie w okolicy "ls_peron4_tor1". Problemem wielu zwrotnic w rozjazdach krzyżowych jest to, że punkty 2 i 4 są blisko siebie, przez co mogą być błędnie wiązane z sąsiednimi odcinkami. Ale to już kwestia algorytmu łączącego odcinki w symulacji... Z mojego punktu widzenia jest to łatwe do naprawienia, tylko trzeba określić zakres naprawy... czy skorygować tylko kilka problematycznych zwrotnic, czy zrobić algorytm regeneracji całych krzyżowych, czy wymienić krzyżowe na skos 1:9 i od razu zrobić poprawne literowanie zwrotnic... Bo problem głównie wynika z zaokrąglania współrzędnych do 10cm, również w torach okolicznych, przez co krzyżowe nawet ze skosem 1:8.7857192453929776240776066680375 mogą nadal wyglądać na połamane.
Tylko że ja nie znam tej scenerii, bo przejechałem może ze dwa razy, więc nie wiem, co gdzie jest zepsute i jak określić, że zostało naprawione. 10 lat temu mieliśmy do MaSzyny przygotowane trasy kilka razy dłuższe niż Kaliska i tam był problem z ruchem pociągów i nie z powodu niedokładności w torach...
Tylko że ja nie znam tej scenerii, bo przejechałem może ze dwa razy, więc nie wiem, co gdzie jest zepsute i jak określić, że zostało naprawione. 10 lat temu mieliśmy do MaSzyny przygotowane trasy kilka razy dłuższe niż Kaliska i tam był problem z ruchem pociągów i nie z powodu niedokładności w torach...
4
Na warsztacie / Odp: D29-97/98/99/94/117 - Zakopianka
« dnia: 22 Sierpnia 2025, 16:29:57 »
Przejrzałem tory od Zakopanego i tam nazewnictwo rozjazdów jest odpowiednie (z małymi wyjątkami, bo trafiłem przynajmniej jedną automatyczną nazwę rozjazdu). Więc zrobienie izolacji rozjazdów to jest kwestia wybrania odpowiedniej operacji z menu (Operacje -> Izolacje -> Zrób odcinki izolowane przy rozjazdach). Ewentualnie potem przejrzenia torów, gdzie się izolacje nie zrobiły, albo wystąpiły konflikty (podświetlają się grupy, konflikty są na czerwono). Do wstawiania izolacji głównych torów oraz blokad liniowych też robiłem jakiś automat, że wystarczyło dodać ścieżkę do grupy i wybrać operację z menu (Grupa -> Zrób izolację dla torów w ścieżce). Robiłem w ten sposób izolacje i blokady liniowe na północ od Lublińca (chyba od Kępna do Ostrowa). Niestety, przycisnął mnie metabolizm i nie pamiętam, na jakim etapie to zawiesiłem, czy automat działał wystarczająco dobrze, czy jednak coś miesza i wymaga dalszych poprawek. A być może blokady się wstawia w innym miejscu... (Plik -> Generator sterowania..., potem zakładka "Blokady liniowe").
Są błędnie przypisane sygnały. Np. semafor Zp_A ma odczyt z dwóch torów (zkp_t197 oraz zkp_t6190), powinien mieć tylko z najbliższego. Również Zp_A_SHP ma odczyt z zkp_t201 (OK) oraz zkp_t6190 (w przeciwną stronę do semafora). Dalej, Zp_ToA_SHP również ma odczyt z dwóch sąsiednich torów, Po_ToH_SHP również, Po_H_SHP ma dodatkowy odczyt z toru z semaforem, Po_W5#Poronin-Biały_Dunajec również ma odczyt w dwóch sąsiednich torach. Dalej na północ też jest podobnie. Takie podwójne odczyty będą zakłócać pracę generatora skryptów, nie testowałem go w takiej sytuacji. Można to naprawić z menu Punktowy -> Przyklej do bliższego toru, o ile nazwa urządzenia nie jest powiązana z nazwą odcinka toru i nie potrzeba skorygować nazw. Hm, wyszukiwarka błędów sprawdza tylko przypisanie do najbliższego toru, ale jeśli jest więcej niż jedno przypisanie, to nie raportuje...
Są błędnie przypisane sygnały. Np. semafor Zp_A ma odczyt z dwóch torów (zkp_t197 oraz zkp_t6190), powinien mieć tylko z najbliższego. Również Zp_A_SHP ma odczyt z zkp_t201 (OK) oraz zkp_t6190 (w przeciwną stronę do semafora). Dalej, Zp_ToA_SHP również ma odczyt z dwóch sąsiednich torów, Po_ToH_SHP również, Po_H_SHP ma dodatkowy odczyt z toru z semaforem, Po_W5#Poronin-Biały_Dunajec również ma odczyt w dwóch sąsiednich torach. Dalej na północ też jest podobnie. Takie podwójne odczyty będą zakłócać pracę generatora skryptów, nie testowałem go w takiej sytuacji. Można to naprawić z menu Punktowy -> Przyklej do bliższego toru, o ile nazwa urządzenia nie jest powiązana z nazwą odcinka toru i nie potrzeba skorygować nazw. Hm, wyszukiwarka błędów sprawdza tylko przypisanie do najbliższego toru, ale jeśli jest więcej niż jedno przypisanie, to nie raportuje...
5
Na warsztacie / Odp: D29-97/98/99/94/117 - Zakopianka
« dnia: 22 Sierpnia 2025, 15:08:11 »
Heh, w związku z brakiem sterowania ruchem chciałem sprawdzić, czy da się wygenerować skrypty sterujące stacjami... No ale nie ma izolacji torów i rozjazdów, ani też nie ma blokad liniowych. Czy dałoby jakoś radę uzupełnić izolacje?
Mam też wrażenie, że ktoś zrobił regulację sieci trakcyjnej poprzez namnożenie modeli. Ale muszę się temu przyjrzeć dokładniej.
Mam też wrażenie, że ktoś zrobił regulację sieci trakcyjnej poprzez namnożenie modeli. Ale muszę się temu przyjrzeć dokładniej.
6
EU07 Simulator English forum / Odp: Questions from a beginner
« dnia: 13 Sierpnia 2025, 11:20:51 »
Hello!
Radio communications often happen quite quickly and if you're not paying attention, you can miss an important instruction. Is there a way to read the radio log from the past communications in the simulator?When I added the radio sound subtitles in 2014, I had no plans for log review. At that time many sounds did not have their subtitles, so it was more of a curiosity than something useful. But it would be a good idea. Another good option would be a list of tasks, whose approval will be recognized by the scenario. I mean, apart from driving according to the timetable and regulations.
But there, only the next stop is ever displayed. Is there an option to display the complete timetable?I've implemented the passenger stop points — previously, timetables were just a passive text file. Due to limited screen space and very long timetables in some cases, I have limited the display to only the nearest stop. It would be a good idea to have an option to scroll all the timetable. Also, the developers after 2015 promised "timetables” (lists of tasks) for maneuvers, but did not complete them for unknown reasons.
Is there a way to adjust this more precisely or is there a better way to do this in general? I also have a Raildriver if it can be set up as a joystick with Maszyna.This can be done from the eu07.ini file or the starter program. I don't know if there are settings in the simulation itself (this is probably explained in the documentation).
During one task, I accidentally passed the stop signal. I wasn't sure what Maszyna wanted me to do next. I pressed ZEW3, which only triggered a radio test and nothing else. Do I have to go back behind the signal in Maszyna and wait for the virtual dispatcher to respond to me, or has the task already failed?Probably it's over. ;) Traffic management in MaSzyna is quite cumbersome and in most cases does not take into account unusual situations. And is not interactive at all. If you have slightly exceeded the stop signal, there is still some safe distance ahead of you, so you can wait and see if there will be any consequences. I have developed station control scripts that should handle situations where an unauthorized train enters the route. However, they have not gained popularity and are only used in a few sceneries. They also need more effort to offer interactivity...
The starter already has a nice list of routes and their tasks. Is that all that's available, or is there more that can be installed here in the forum?No, there are many extra things, but you have to find them and then install them correctly, taking into account all dependencies and consequences yourself. Years ago I've developed a method for installing add-ons, but it was abandoned in favor of solutions that do not exist.
7
Na warsztacie / Odp: Z kronikarskiego obowiązku - mapa scenerii do Maszyny na terenie Polski
« dnia: 09 Sierpnia 2025, 12:27:41 »
Istnieje trasa Kutno – Płock. Ale straciłem kontakt z autorem, a poza tym jakoś tak przestało mi zależeć na tym, żeby scenerie zrobione w Rainsted były publikowane...
8
Na warsztacie / Odp: Przebudowa Ostrowa Wielkopolskiego
« dnia: 03 Sierpnia 2025, 12:38:30 »
Kontynuuję w tym wątku, ponieważ jest tutaj w miarę kompletna informacja o paczkach, które należy pobrać w pierwszej kolejności. W podkatalogu paczki całościowej doszła paczka linia61-f2407.7z, w której jest zebrana ostatnia tura poprawek. Aktualna paczka poprawek jest w podkatalogu chwilowe, jako linia61-250803.7z — jednak może być wymieniona na nowszą, gdy dojdą jakieś zmiany. Od ponad roku nie zrobiłem prawie nic w zakresie linii 61 i 144...
Niemniej, dostałem niedawno raport z testów wraz z obrazkami z miejsc, które warto by było poprawić. Niektóre korekty są trywialne (np. przesunięcie wskaźnika poza skrajnię), poprawienie innych jest niemożliwe (np. brak regulacji sieci trakcyjnej) albo pracochłonne (konieczność przestawienia bardzo wielu rzeczy). Zmotywowało mnie to jednak do przejrzenia plików scenerii i poprawienia większości zgłoszonych drobiazgów. Poprawki dotyczą stacji Fosowskie oraz odcinka Fosowskie – Ozimek.
Na stacji Fosowskie zabrałem się za remont kapitalny. Zmodyfikowałem wysokość peronów (było ok. 80cm, jak pod EW58), obecnie jest 30cm. Perony są obecnie na wysokości 196.515, na Geoportalu są wysokości po remoncie i teraz wychodzi około 196.8. Jednak gdy mierzyłem poprzednio, to przejścia przez tory w Fosowskich były na 196.1 oraz 196.2, więc po doliczeniu 30cm na peron wychodziło średnio 196.45... No ale nie robię dokumentacji technicznej, tylko staram się dopasować na tyle, by można było użyć innych danych geodezyjnych (np. brył CityGML). Zmodyfikowałem też peron pomiędzy torem 1 i 2, co pozwoliło na lepsze ułożenie toru 2. Do przesunięcia pozostają tory 4 i 6 oraz peron pomiędzy torami 2 i 4. W ramach testów przesunąłem wcześniej kilka torów na wschodniej grupie (tam też jeszcze 2 tory do poprawienia i peron pomiędzy nimi)... Okazało się, że edytor SCM całkiem sprawnie pozwala skorygować sieć nad przemieszczonymi torami. Nie jest to jeszcze stan w pełni zadowalający, ale jest dużo lepiej niż poprzednio. Poprawiłem też wskaźniki (zdublowane We, brakujące W6a, nieprecyzyjnie ustawione ograniczenia prędkości). Dodałem też kilka torów zakończonych kozłami i bocznicę na południu. Fosowskie wraz z przyległymi szlakami są jako pliki SCM, a z poziomu RSF można ewentualnie generować pojedyncze obiekty, ponieważ plik RSF jest mocno prowizoryczny i nie nadaje się do bezpośredniego eksportowania.
Na szlaku Fosowskie – Ozimek poszerzyłem nasyp, aby wskaźniki, To i słupki hektometrowe nie lewitowały. Poszerzenie nasypu edytorem SCM okazało się prostsze niż wygenerowanie go edytorem RSF i wszywanie w teren, co mogłoby zepsuć mapowanie pól. Jako prowizorka jest całkiem dobre. Poprawiłem w kilku miejscach obrócone kotwienia (niemniej ich spasowanie ze słupami to mordęga, bo nie ma dobrych narzędzi do regulacji sieci). Na przejazdach dodałem płyty przejazdowe. Skorygowałem też wysokość zawieszenia sieci, bo po przeliczeniu profilu pionowego zrobiła się bardzo nierówna. Ozimek (i pół szlaku) jest obecnie eksportowany z RSF, jedynym problemem jest połączenie przejazdów z torami, które się nieprawidłowo eksportuje i muszę to sprawdzić.
Na razie nie mam planów, co do dalszych modyfikacji. Pewnie kiedyś jeszcze przesunę pozostałe tory w Fosowskich do stanu widocznego na ortofotomapie. Najlepiej by było przejść z tym na RSF, wtedy dalsze poprawki będą prostsze...
Pytanie mam ewentualnie co do modeli budynków w Fosowskich. Mam bryły z CityGML i modele zrobione kiedyś tam są niewymiarowe. Najlepiej by było je przeskalować do bardziej realnych wymiarów, ale jeśli są wstawione też w innych sceneriach, to mogą być z czymś na styk i ich modyfikowanie nie będzie dobrym pomysłem. Lepiej by było więc zapisać je w osobnych plikach. Gdyby ktoś się chciał zająć ulepszeniem modeli CityGML i przemapowaniem dotychczasowych tekstur, to mogę jakoś podesłać bryły.
Niemniej, dostałem niedawno raport z testów wraz z obrazkami z miejsc, które warto by było poprawić. Niektóre korekty są trywialne (np. przesunięcie wskaźnika poza skrajnię), poprawienie innych jest niemożliwe (np. brak regulacji sieci trakcyjnej) albo pracochłonne (konieczność przestawienia bardzo wielu rzeczy). Zmotywowało mnie to jednak do przejrzenia plików scenerii i poprawienia większości zgłoszonych drobiazgów. Poprawki dotyczą stacji Fosowskie oraz odcinka Fosowskie – Ozimek.
Na stacji Fosowskie zabrałem się za remont kapitalny. Zmodyfikowałem wysokość peronów (było ok. 80cm, jak pod EW58), obecnie jest 30cm. Perony są obecnie na wysokości 196.515, na Geoportalu są wysokości po remoncie i teraz wychodzi około 196.8. Jednak gdy mierzyłem poprzednio, to przejścia przez tory w Fosowskich były na 196.1 oraz 196.2, więc po doliczeniu 30cm na peron wychodziło średnio 196.45... No ale nie robię dokumentacji technicznej, tylko staram się dopasować na tyle, by można było użyć innych danych geodezyjnych (np. brył CityGML). Zmodyfikowałem też peron pomiędzy torem 1 i 2, co pozwoliło na lepsze ułożenie toru 2. Do przesunięcia pozostają tory 4 i 6 oraz peron pomiędzy torami 2 i 4. W ramach testów przesunąłem wcześniej kilka torów na wschodniej grupie (tam też jeszcze 2 tory do poprawienia i peron pomiędzy nimi)... Okazało się, że edytor SCM całkiem sprawnie pozwala skorygować sieć nad przemieszczonymi torami. Nie jest to jeszcze stan w pełni zadowalający, ale jest dużo lepiej niż poprzednio. Poprawiłem też wskaźniki (zdublowane We, brakujące W6a, nieprecyzyjnie ustawione ograniczenia prędkości). Dodałem też kilka torów zakończonych kozłami i bocznicę na południu. Fosowskie wraz z przyległymi szlakami są jako pliki SCM, a z poziomu RSF można ewentualnie generować pojedyncze obiekty, ponieważ plik RSF jest mocno prowizoryczny i nie nadaje się do bezpośredniego eksportowania.
Na szlaku Fosowskie – Ozimek poszerzyłem nasyp, aby wskaźniki, To i słupki hektometrowe nie lewitowały. Poszerzenie nasypu edytorem SCM okazało się prostsze niż wygenerowanie go edytorem RSF i wszywanie w teren, co mogłoby zepsuć mapowanie pól. Jako prowizorka jest całkiem dobre. Poprawiłem w kilku miejscach obrócone kotwienia (niemniej ich spasowanie ze słupami to mordęga, bo nie ma dobrych narzędzi do regulacji sieci). Na przejazdach dodałem płyty przejazdowe. Skorygowałem też wysokość zawieszenia sieci, bo po przeliczeniu profilu pionowego zrobiła się bardzo nierówna. Ozimek (i pół szlaku) jest obecnie eksportowany z RSF, jedynym problemem jest połączenie przejazdów z torami, które się nieprawidłowo eksportuje i muszę to sprawdzić.
Na razie nie mam planów, co do dalszych modyfikacji. Pewnie kiedyś jeszcze przesunę pozostałe tory w Fosowskich do stanu widocznego na ortofotomapie. Najlepiej by było przejść z tym na RSF, wtedy dalsze poprawki będą prostsze...
Pytanie mam ewentualnie co do modeli budynków w Fosowskich. Mam bryły z CityGML i modele zrobione kiedyś tam są niewymiarowe. Najlepiej by było je przeskalować do bardziej realnych wymiarów, ale jeśli są wstawione też w innych sceneriach, to mogą być z czymś na styk i ich modyfikowanie nie będzie dobrym pomysłem. Lepiej by było więc zapisać je w osobnych plikach. Gdyby ktoś się chciał zająć ulepszeniem modeli CityGML i przemapowaniem dotychczasowych tekstur, to mogę jakoś podesłać bryły.
9
Na warsztacie / Odp: siudemka.exe - swego rodzaju dalszy rozwój
« dnia: 03 Kwietnia 2025, 10:42:34 »Dalem do ini opcje priorityLoadText3D (domyślnie no) - przyjmuje yes lub no - pozwala na ustawienie priorytetu ładowania t3d nad e3d. Zrobilem to bo sie wkurzylem na to ze trzeba e3d z paczki usuwac xdNajprościej to sprawdzać daty plików. Powinno to być jako opcja, aby normalnie nie szukało niepotrzebnie.
Jeszcze przejrzalem sobie czy daloby sie zrobic aby dzialal crossloading t3d-e3d jesli sa includy ALE z tego co na razie wyczytalem to e3d nie obsluguje includow ani parametrow w sobie i w paczce e3d posiadaja w sobie od razu wszystkie modele includowane przeliczone. Jakas nowa koncepcja modeli musialaby powstac (format pliku) aby dalo sie to odpalic. W skrocie? Nie warto sie za to zabierac (a przynajmniej na razie)Używanie include w T3D jest patologią, która będzie prowadzić do coraz większych problemów. Zwłaszcza jeśli include jest jedynie mechanizmem parsera, niewidocznym dla kodu analizującego. Jako twórca E3D mogę powiedzieć, że format ten miał przede wszystkim przyspieszyć wczytywanie i uwolnić od potrzeby każdorazowego przeliczania wektorów normalnych, a także poprawić dynamiczne zarządzanie pamięcią (rozmiar danych jest znany z góry). Niestety nie dokończyłem dopracowania koncepcji E3D w zakresie dołączania innych modeli we wskazanych miejscach, czy powielania submodeli. W pierwszej kolejności należałoby zmienić sposób łączenia modeli w T3D w taki sposób, aby nie było to wykonywane przez parser.
10
Trasy / Odp: Sceneria quark.
« dnia: 17 Marca 2025, 20:44:25 »Przy okazji jeszcze w wk sokista chodzi do tyłu a w zasadzie to biega.Z sokistą nigdy nic nie robiłem, to musi być jakiś nowy "ficzer".
Przy okazji zapytam czy ten sokista to wyzwalacz eventów czy dekoracja?Sokista zawsze był dekoracyjny, formalnie był pojazdem drogowym. Był tam też gdzieś gość na koniu, ale dawno nie sprawdzałem.
Po drodze że skwarek do jelonkowa było bardzo dużo otwartych przejazdów w zasadzie to na całej scenerii to występuje. Tylko nieliczne są zamknięte.Dodałem zamykanie przejazdów, ale póki co sterowanie jest prowizoryczne, bo nazewnictwo semaforów i rozjazdów jest od czapy i trzeba by je najpierw uporządkować...
Czy wyjazd z jelonkowa musi być tak mocno opóźniony? Już jest po 5 a my ciągle stoimy. O której jest rzeczywistym wyjazd z jelonkowa?No jednak przesuwanie rozkładów nie działało dobrze, zwłaszcza że skład jest wstawiony z nieprzesuniętym rozkładem, a w takiej sytuacji opieranie się na pobieraniu rozkładu z sygnalizatora więcej komplikuje niż pomaga. Skorygowałem rozkład tak, aby godziny w pliku były już przesunięte o 10 minut później. Jednak wtedy występuje konflikt z pośpiesznym na dojeździe do Koniewic i pojawiło się dodatkowe opóźnienie (rzędu 5 minut). Więc jednak zrobiłem wyjazd z Jelonkowa wg wcześniejszych godzin (4:48), a dodatkowe 10 minut postoju dołożyłem w Koniewicach. Przy okazji dodałem w Koniewicach wyjazd synchronizowany z rozkładem.
Wpadłem też na pomysł, że skoro pociągi jadą na koniec toru w Koniewicach, to może zrobić chamówę i faktycznie wstawić event zmiany kierunku? Chyba trochę pomaga. Niemniej Koniewice się nadal korkują, bo EZT startujący z toru postojowego jakoś długo stał i nie zdążył odjechać zgodnie z rozkładem. A potem przyjechał kolejny ze Skwarek i pojechał w kolejnym cyklu, a ten ostatni z toru postojowego został przy peronie i następny jadący od Skwarek nie miał gdzie wjechać. Na koniec symulacja się zawiesiła i nie wiem dlaczego. Sprawdzę Koniewice jeszcze raz w najbliższym czasie, może z tym jawnym zawracaniem błądzących składów da się jakoś zapętlić ruch...
11
Trasy / Odp: Sceneria quark.
« dnia: 17 Marca 2025, 14:35:01 »
Po przesunięciu godzin odjazdu o 10 minut się za wcześnie uruchamia przygotowanie rozkładu dla kolejnego pociągu. Załączam plik z poprawionymi godzinami dla wersji z odjazdami co godzinę. Sprawdzę to później jeszcze, bo na razie nie uruchamiałem.
Usunąłem, bo to nie działało.
Usunąłem, bo to nie działało.
12
Trasy / Odp: Sceneria quark.
« dnia: 16 Marca 2025, 18:33:36 »
Pojęcia nie mam. Kiedy programowałem działanie AI, to koncepcja była taka, że stojąc w trybie manewrowym AI "rozgląda się" w obie strony w poszukiwaniu sygnału do jazdy (chyba że natrafi na W5, to wtedy spodziewa się jedynie z przeciwnej strony). Jeśli z którejś strony dostanie sygnał do jazdy, to przełącza się kierunkiem jazdy w stronę tego sygnału i rusza. Jeśli zaś sygnał będzie pociągowym (SetVelocity), to przełącza się w tryb pociągowy, w którym analizuje tylko sygnały w kierunku jazdy. W efekcie wystarczyło zapalać semafory (oraz Tm) i żadne dalsze eventy zmiany kierunku nie były potrzebne. Tak to działało do którejś z przedostatnich wersji. Jak to działa teraz, to nie wiem. Zmianę zauważyłem ongiś na Linii 61 w Lublińcu, kiedy EN57 dostając Ms2 na karzełkowym X zawsze podjeżdżał w perony, a od nowej paczki zaczął wrzucać wsteczny i jechać sobie na koniec toru. Mam tylko podejrzenie, że to jest powiązane z kierunkiem wstawienia składu, bo w Quarku niektóre składy jadą w kierunku semafora, a inne wolą w przeciwną stronę.
13
Trasy / Odp: Sceneria quark.
« dnia: 16 Marca 2025, 16:47:21 »Niestety utknalem w dej dół. Z powodu braku wjazdu pospiecha do koniewic a to jest z kolei z powodu kibla 1146 który nie zmienił czoła pomimo podanego wyjazdu.To jest (moim zdaniem) błąd w EXE, którego sensu wprowadzenia nie rozumiem i który mnie zniechęcił do dalszych prac nad zapętleniem ruchu. Pozostaje czekać, aż Ktoś naprawi albo uzupełni dokumentację o opis, co dokładnie należy zrobić, aby pociąg pojechał w stronę podanego semafora, a nie w przeciwną. Kiedyś wystarczyło zapalić wyjazd na semaforze...
Semafor sbl 142 w stronę skwarek podaje błędnie s1 mimo wolnego szlaku.To zostawiłem specjalnie. Myślałem nad tym, żeby dodać tam losowość, tzn. żeby czasem się załączał, a czasem zostawał z S1, ale póki pozostał w stanie zepsutym. Pierwszy przejeżdżający pociąg zostawia S1, które się nie resetuje.
14
Bieżące Symulatorowe / Odp: Linia kolejowa nr 274 (Wrocław Świebodzki - Zgorzelec)
« dnia: 16 Marca 2025, 13:10:55 »
Na ile wiem, to nie ma planów, żeby ta trasa została wydana. Ostatnie zmiany mam z połowy 2021 roku, więc chyba od tego czasu się nic nie zmieniło.
15
Trasy / Odp: Sceneria quark.
« dnia: 16 Marca 2025, 09:18:43 »Niestety jadąc spotem przed psiakami wykoleilem się przed mostem z powodu nieoznaczenia miejsca wskaźnikami ograniczenia prędkości. Sierżanta są dopiero na moście a i tak niewiadomo do ilu trzeba zwolnić.Łuk przed mostem ma promień 250m (wg wpisu), więc ograniczenie powinno być do 40km/h. Trzeba by to jeszcze zweryfikować, bo ten odcinek na symetryczny nie wygląda. Wcześniej jest łuk o promieniu 500m, tam powinno być 60km/h (może z przechyłką trochę więcej), a jest 100... To już jest patologia z pierwotnej scenerii, bo ja nie weryfikowałem prawidłowości ograniczeń. Ogólnie Psiary i tory na wschód wydają się mieć więcej dziwactw, np. nazewnictwo semaforów i rozjazdów jest mocno losowe, wskaźniki W5 potrafią nie mieć unikalnych nazw (są jako "none").
Przy okazji już starą pętelka z kopalni do koniewic już się nie jeździ? Widzę z okna że tory wpadają w pagór.Od Kopalni na wprost (na północ) zacząłem robić połączenie do scenerii MZD (Myślenice) i tam trzeba by zmodyfikować teren po ustaleniu profilu pionowego. Nie pamiętam różnicy wysokości, ale kilka metrów, jeśli już — ewentualnie zamiast prawie poziomo można by w górę i w dół przejechać. Planowałem jeszcze wymienić pozostałości pętli na Chomikowo, ale trzeba by wyprowadzić różnicę wysokości rzędu 12m, a tam są jakieś jeziora... Chyba wstępnie miałem jakiś pomysł, żeby się to zmieściło i nie wyglądało dziwacznie. Myślałem nawet nad przeniesieniem misji ze Zwierzyńca na te przerobione tory... Ale unifikacja klonów Zwierzyńca utknęła mi w 2017 roku chyba z powodu znacznych różnic pomiędzy klonami (np. w sieci trakcyjnej) i już nie wróciłem do tego po awarii dysku.
16
Trasy / Odp: Sceneria quark.
« dnia: 15 Marca 2025, 17:14:23 »Do tej mapy dołączył bym jeszcze Jelitkowo.Jelitkowo było w poprzedniej wersji na zachód od Moczników. Jednak ze względu na wydłużenie Całkowa na południe torami bez drutów, poprzednia wersja przestała mieć sens.
http://eu07.rainsted.com/scenerie/razem5.html
Mało popularna opinia - ale za Grodziskiem lepiej pasowałby tor na Całkowov2 ew. połączenie z tamtejszym Janiszewem. A jak dobrze wiemy, za tą stacją jest Bałtyk, przynajmniej w głowach trasopisarzy. Jak łączyć te scenerie to po wydaniu cv2 i raz a porządnie.Mi chodziło o połączenie wszystkich scenerii fikcyjnych w stałą sieć kolejową, w miarę z dopasowaniem szlaków pod względem liczby torów, elektryfikacji oraz prędkości. A nie o dopięcie jednej scenerii do innej, bo to było praktykowane wielokrotnie w różnych doraźnych konfiguracjach. Połączenie scenerii fikcyjnych (w przeważającej większości poziomych) miało być etapem pośrednim przed wdrożeniem dynamicznego wczytywania scenerii realistycznych, których dopracowanie wymagało znacznie więcej pracy. Obecnie po sceneriach realistycznych da się w miarę przejechać ze Słowacji do Ostrowa Wlkp., a wyginając nieco Kaliską to nawet i do Łodzi, a biorąc też pod uwagę zaginioną scenerię, to z Łodzi do Torunia. Z drugiej strony, w temacie dynamicznego wczytywania scenerii, to jest chyba zastój?
17
Trasy / Odp: Sceneria quark.
« dnia: 15 Marca 2025, 09:56:10 »
Nie pamiętam w tej chwili dokładnie, jaki jest stan mojej wersji scenerii Drawinowo, bo dawno tam nie zaglądałem. Ogólnie to przerabiałem układ torowy pod kątem uruchomienia wyjazdów na północ i połączenia z innymi sceneriami. Z Grodziska Zachodniego miał być wyjazd na Linię 546, z Lubniewa na Moczniki, z Grabówka oraz Włodowic na Linię 053. Poszczególne etapy zmian są opisane na stronie https://rainsted.com/pl/Sceneria/Drawinowo/Zmiany. Do paczki całościowej MaSzyny trafiła wersja z paczki drawinowo-170905.7z albo drawinowo-180303.7z — kiedyś próbowałem sprawdzić, ale nie zapisałem sobie rezultatu. Ponieważ różne scenerie zostały przedłużone w sposób nie uwzględniający moich propozycji połączenia, dalsze próby łączenia czegoś od Drawinowa na północ straciły swój sens i ewentualnie należałoby to ponownie przemyśleć. Tu jest ostatnia mapa wcześniej proponowanych połączeń: http://eu07.rainsted.com/scenerie/razem6.html.
18
Trasy / Odp: Sceneria quark.
« dnia: 14 Marca 2025, 18:36:26 »Witam. Postanowilem sobie po latach przejechac sie po starej scenerii quark i natknalem sie na problem. Wiem ze w ta sceneriua kiedys zajmowal sie @RA. Otoz nie jest juz przejezdna. Wjazd do Koniewic blokuje kibel przez co pospieszny konczy swoja sluzbe na laczniku pod S1 zaraz za kopalnia. Wiem ze to sceneria historyczna ale czy jest jakies rozwizanie tego problemu?Błąd w działaniu wynikał z tego, że ktoś dodając moje poprawki do paczki całościowej nie uwzględnił zmian w pliku tarczy zaporowej, w której zapisane były dalsze komendy dla składów. Brak dodania tej zmiany do paczki spowodował, że oczekująca komenda była nadpisywana sygnałem S1 i się nie wykonywała.
Możliwych rozwiązań jest kilka:
1. Dodać do paczki tarczę zaporową w stanie zaproponowanym przeze mnie, w której oczekująca komenda nie będzie blokowana.
2. Przerobić sterowanie tak, aby nie używać komend zapisanych do tarczy zaporowej.
3. Dodać do paczki moją późniejszą poprawkę.
Jesli poprawa bledow na tej scenerii to strata czasu to postuluje o jej usuniecie z paczki. Podobnie pierwsza wersja drawinowa tez nie jest w pelni przejezdna i w niej tez maczal swe palce @Ra.Też postuluję usunięcie scenerii, skoro nikt nie jest w stanie dopilnować wgrania zmian do paczki i przetestowania poprawności. Oraz uprzejmie proszę się ode mnie odpieprzyć i nie powtarzać w kółko, że wszystko źle działa, bo ja maczałem w tym palce. O ile dobrze pamiętam, moje modyfikacje Drawinowa od 2018 roku nie trafiały już do paczki całościowej, a ja nie mogę odpowiadać za to, że ktoś coś zmienia i nie testuje potem.
19
Pomoc doraźna / Odp: Problem z trasą linia61 pospieszny.
« dnia: 20 Stycznia 2025, 15:47:34 »Niby jest wszystko, dobrze jak jadę to mijam na trasie. Baner z logiem maszyna i pisze koniec trasy. Jade dalej nie ma trakcji i potem koniec. Może coś źle robię ?No jak jest "koniec trasy", to jest koniec trasy i dalszego ciągu może nie być.
A tam czasem Ra nie robił czegoś przy tym?W tym scenariuszu dawno nic nie zmieniałem, bo został on dołączony do innego, gdzie jest dojazd z Ozimka do Lublińca. Powinny być podłączone Wyczerpy, czyli powinno się dać wyjechać kawałek za Częstochowę. Ale poprawki na teren i otoczenie robiłem tam niedawno, więc w paczkowej wersji mogą być same tory. Wg moich notatek powinny być cztery pociągi do poprowadzenia, w tym wyjazd z Lublińca osobowym za tym TLK. Teoretycznie w Częstochowie powinno się spotkać pociąg 16105, jadący w przeciwną stronę, ale ten skład raczej nie został wstawiony w SCN. Ja mam u siebie wersję z dołączonymi torami w stronę Opola (przygotowanie pod 16105 z opcją przesiadki w Fosowskich na 61106, też nieobecny).
20
Pomoc w tworzeniu / Odp: Wykolejnice
« dnia: 09 Stycznia 2025, 09:12:48 »
Na potrzeby scenerii testowej (Tarniowo2) przerobiłem kiedyś sterowanie wykolejnicami pod ustalone w czasie testów potrzeby. Niestety później nie zostało to uporządkowane, nie wszystkie wykolejnice to mają, nie są podłączone do torów, a niektóre modele 3D wykolejnic są obrócone o 180° w osi pionowej względem działania semaforów (wykolejnica powinna być widoczna z toru przed wykolejnicą, a za wykolejnicą są rozjazdy).
Nazwy sygnałów są zrobione ze zgodnością z sygnalizatorami świetlnymi dla większej czytelności. Nie przy wszystkich wykolejnicach jest dodatkowy sygnalizator, a jeśli jest, to wtedy można używać tylko wykolejnica:o oraz wykolejnica:z wraz z tym sygnalizatorem.
- wykolejnica:o — otwarcie wykolejnicy, jeśli tabor jest w trybie jazdy manewrowej, to pojedzie do W5 lub najbliższego sygnalizatora, w trybie pociągowym może wyjechać na szlak, ale nie ruszy się, jeśli jest w trybie oczekiwania na komendy,
- wykolejnica:z — zamknięcie wykolejnicy, odpowiednik S1 dla taboru (blokada jazdy manewrowej i pociągowej), zmienia własność toru z wykolejnicą — jeśli skład pojedzie w stronę wykolejnicy, to się wykolei na tym torze,
- wykolejnica:Ms1 — otwarcie wykolejnicy, zablokowanie jazdy taboru w trybie jazdy manewrowej, tabor w trybie pociągowym może pojechać w stronę wykolejnicy,
- wykolejnica:Ms2 — otwarcie wykolejnicy, przełączenie taboru w tryb jazdy manewrowej w stronę wykolejnicy,
- wykolejnica:S1 — otwarcie wykolejnicy, podanie sygnału zakazu jazdy dla taboru (ale możliwy przejazd bez wykolejenia),
- wykolejnica:S10 — otwarcie wykolejnicy, przełączenie taboru w tryb jazdy pociągowej w stronę wykolejnicy,
Nazwy sygnałów są zrobione ze zgodnością z sygnalizatorami świetlnymi dla większej czytelności. Nie przy wszystkich wykolejnicach jest dodatkowy sygnalizator, a jeśli jest, to wtedy można używać tylko wykolejnica:o oraz wykolejnica:z wraz z tym sygnalizatorem.
21
Bieżące Symulatorowe / Odp: Pytanie do dewelopera
« dnia: 12 Grudnia 2024, 18:44:14 »
Bardzo dziękuję za to pytanie!
Nie wiem, jak to jest robione teraz. Ale na samym początku było tak, że każda oś miała swój osobny obiekt, na wózek były dwie osie, a z ich wzajemnego położenia były wyznaczane wektory: styczny i prostopadły do toru (dodatkowo wyliczanie tych wektorów z osi było uzależnione od FPS albo ustawień w INI, co robiło masę dodatkowych problemów). Ponieważ 4 osie na pojazd robiły problemy z obsługą eventów przy zmianie kierunku jazdy na łączeniu torów (zmieniała się oś decydująca o przypisaniu pojazdu do odcinka toru), tymczasowo uprościłem ten mechanizm do dwóch osi na pojazd, a wektory zacząłem wyliczać ze wzoru na pochodne krzywej Béziera. Kwestia osi decydującej była związana z obsługą zajętości torów i czymś jeszcze, czego nie pamiętam (być może wyliczania odległości od sygnałów). Co do zasady osią decydującą była pierwsza od kierunku jazdy, natomiast po zmianie kierunku jazdy oś decydująca musiała przełączać się dopiero na odpowiednio długim torze, na którym obie osie mogły się znajdować jednocześnie. Redukcja do dwóch osi była tymczasowa, tzn. po uporaniu się ze wszystkim problemami z prowadzeniem pojazdów po torach planowałem przywrócić obsługę dowolnej liczby osi (podanej w FIZ), żeby możliwe były poślizgi pojedynczych osi, a także aby obsługiwać "dostosowania sił do nacisku kół".
Drugi problem z osiami był taki, że każda mogła pojechać innym torem i wtedy pudło pojazdu znajdowało się po środku, często doprowadzając do lewitacji. Przyczyna była taka, że osie zawsze były przesuwane o stałą odległość, wynikającą z prędkości i czasu kroku fizyki. W szczególności się to objawiło po uruchomieniu skrzyżowań, kiedy każda oś samochodu wylosowała inny kierunek. Postanowiłem to naprawić wprowadzając stałą odległość pomiędzy wózkami, co doprowadzałoby do wykolejenia po zbyt dużym rozjechaniu wózków na różne tory, a w przypadku samochodów zawsze ciągnęłoby tylną oś za pierwszą. Jednocześnie stała odległość pomiędzy wózkami pozwoliłaby na prawidłowe liczenie zwiększonych oporów jazdy na łukach, a także sensowniejsze liczenie sił na zderzakach oraz sprzęgach.
Trzeci problem, to zbędność skomplikowanych obliczeń dla krzywych Béziera, które w 90% przypadków można by uprościć do okręgu. Odpada wtedy przybliżanie łuku okręgu łamaną i różne inne absurdalne kombinacje (np. z liczeniem długości i wyznaczaniem momentu przejechania na sąsiedni tor).
Czwarty problem związany z osiami był widoczny w postaci niedopasowania kół do szyn (przesunięcie w bok). Nie pamiętam szczegółów, ale na pewno było to motywacją do zabrania się z obliczenia związane z prowadzeniem osi. Chyba też występowały problemy na złożeniu łuków pionowych w łukami w planie, gdzie promienie łuków pionowych są orientacyjnie 10 razy większe od promieni łuków w planie, gdy tymczasem długość wektorów kontrolnych może być powiązana tylko z jednym promieniem. Mogę się mylić, gdyż nie mam tego przemyślanego do końca, ponieważ szczegółowe analizy przełożyłem na później i nigdy ich nie wykonałem (nie jestem odpowiedzialny za prawidłowość obliczeń w MaSzynie).
Niestety, w czasie moich prac nad poprawą pozycjonowania wózków okazało się natychmiastowo niezbędne "odhamowanie rozwoju" poprzez opublikowanie kodu wraz ze zniszczeniem używanych przeze mnie narzędzi, a moje prace zostały nazwane brakiem przejrzystości i sabotażem. Od tej pory dalszą pracą nad kodem miały się zająć inne osoby, których wskazać nie potrafię. Później nikt mnie nawet nie pytał, nad czym pracowałem ani jakie plany miałem wobec poszczególnych rozwiązań, więc pewnie inni są dużo lepiej zorientowani w tych zagadnieniach.
Nie wiem, czy nadal możliwe jest rozjechanie wózków pojazdów kolejowych na różne tory bez wykolejenia, bo dawno tego nie sprawdzałem. Wydaje mi się, że lewitujące samochody jeszcze niedawno widziałem (nie pobrałem jeszcze tegorocznej paczki, a nie wydaje mi się, żebym zauważył poprawienie tego na liście wprowadzonych zmian). Również mam pytanie do dewelopera, czy opisany wyżej bałagan z prowadzeniem osi i wózków został doprowadzony do jakiegoś sensownego stanu? Być może jest gdzieś szczegółowa analiza tych problemów w ukrytych działach, albo dyskusja się odbyła na czacie? Chciałbym o tym poczytać więcej i będę wdzięczny za wskazanie. Dziękuję!
Regulamin, zakazy 23, obowiązki 1, 11.
+10
Nie wiem, jak to jest robione teraz. Ale na samym początku było tak, że każda oś miała swój osobny obiekt, na wózek były dwie osie, a z ich wzajemnego położenia były wyznaczane wektory: styczny i prostopadły do toru (dodatkowo wyliczanie tych wektorów z osi było uzależnione od FPS albo ustawień w INI, co robiło masę dodatkowych problemów). Ponieważ 4 osie na pojazd robiły problemy z obsługą eventów przy zmianie kierunku jazdy na łączeniu torów (zmieniała się oś decydująca o przypisaniu pojazdu do odcinka toru), tymczasowo uprościłem ten mechanizm do dwóch osi na pojazd, a wektory zacząłem wyliczać ze wzoru na pochodne krzywej Béziera. Kwestia osi decydującej była związana z obsługą zajętości torów i czymś jeszcze, czego nie pamiętam (być może wyliczania odległości od sygnałów). Co do zasady osią decydującą była pierwsza od kierunku jazdy, natomiast po zmianie kierunku jazdy oś decydująca musiała przełączać się dopiero na odpowiednio długim torze, na którym obie osie mogły się znajdować jednocześnie. Redukcja do dwóch osi była tymczasowa, tzn. po uporaniu się ze wszystkim problemami z prowadzeniem pojazdów po torach planowałem przywrócić obsługę dowolnej liczby osi (podanej w FIZ), żeby możliwe były poślizgi pojedynczych osi, a także aby obsługiwać "dostosowania sił do nacisku kół".
Drugi problem z osiami był taki, że każda mogła pojechać innym torem i wtedy pudło pojazdu znajdowało się po środku, często doprowadzając do lewitacji. Przyczyna była taka, że osie zawsze były przesuwane o stałą odległość, wynikającą z prędkości i czasu kroku fizyki. W szczególności się to objawiło po uruchomieniu skrzyżowań, kiedy każda oś samochodu wylosowała inny kierunek. Postanowiłem to naprawić wprowadzając stałą odległość pomiędzy wózkami, co doprowadzałoby do wykolejenia po zbyt dużym rozjechaniu wózków na różne tory, a w przypadku samochodów zawsze ciągnęłoby tylną oś za pierwszą. Jednocześnie stała odległość pomiędzy wózkami pozwoliłaby na prawidłowe liczenie zwiększonych oporów jazdy na łukach, a także sensowniejsze liczenie sił na zderzakach oraz sprzęgach.
Trzeci problem, to zbędność skomplikowanych obliczeń dla krzywych Béziera, które w 90% przypadków można by uprościć do okręgu. Odpada wtedy przybliżanie łuku okręgu łamaną i różne inne absurdalne kombinacje (np. z liczeniem długości i wyznaczaniem momentu przejechania na sąsiedni tor).
Czwarty problem związany z osiami był widoczny w postaci niedopasowania kół do szyn (przesunięcie w bok). Nie pamiętam szczegółów, ale na pewno było to motywacją do zabrania się z obliczenia związane z prowadzeniem osi. Chyba też występowały problemy na złożeniu łuków pionowych w łukami w planie, gdzie promienie łuków pionowych są orientacyjnie 10 razy większe od promieni łuków w planie, gdy tymczasem długość wektorów kontrolnych może być powiązana tylko z jednym promieniem. Mogę się mylić, gdyż nie mam tego przemyślanego do końca, ponieważ szczegółowe analizy przełożyłem na później i nigdy ich nie wykonałem (nie jestem odpowiedzialny za prawidłowość obliczeń w MaSzynie).
Niestety, w czasie moich prac nad poprawą pozycjonowania wózków okazało się natychmiastowo niezbędne "odhamowanie rozwoju" poprzez opublikowanie kodu wraz ze zniszczeniem używanych przeze mnie narzędzi, a moje prace zostały nazwane brakiem przejrzystości i sabotażem. Od tej pory dalszą pracą nad kodem miały się zająć inne osoby, których wskazać nie potrafię. Później nikt mnie nawet nie pytał, nad czym pracowałem ani jakie plany miałem wobec poszczególnych rozwiązań, więc pewnie inni są dużo lepiej zorientowani w tych zagadnieniach.
Nie wiem, czy nadal możliwe jest rozjechanie wózków pojazdów kolejowych na różne tory bez wykolejenia, bo dawno tego nie sprawdzałem. Wydaje mi się, że lewitujące samochody jeszcze niedawno widziałem (nie pobrałem jeszcze tegorocznej paczki, a nie wydaje mi się, żebym zauważył poprawienie tego na liście wprowadzonych zmian). Również mam pytanie do dewelopera, czy opisany wyżej bałagan z prowadzeniem osi i wózków został doprowadzony do jakiegoś sensownego stanu? Być może jest gdzieś szczegółowa analiza tych problemów w ukrytych działach, albo dyskusja się odbyła na czacie? Chciałbym o tym poczytać więcej i będę wdzięczny za wskazanie. Dziękuję!
Regulamin, zakazy 23, obowiązki 1, 11.
+10
22
Na warsztacie / Odp: Uruchomienie LK7
« dnia: 10 Grudnia 2024, 00:18:09 »
W kwestie estetyki nie chcę się wtrącać, detale zawsze można poprawić, a ja w tamtej okolicy nigdy pociągiem nie jechałem. Wysokości jestem w stanie przeliczyć do obecnego terenu. Gdzieś widziałem ogromne kominy ustawione na torach, to by trzeba było przynajmniej usunąć. Główne moje cele to podział na komórki oraz uruchomienie sterowania ruchem, ewentualnie pomoc w dopracowaniu czegoś, z czym sobie edytor jeszcze niezbyt radzi.
Co do sieci trakcyjnej, to w planach mam wprowadzenie regulacji, dzięki czemu będzie można wstawiać słupy bez obawy o naruszanie skrajni sąsiedniego toru czy lewitujące wysięgniki w bramkach oraz słupach parasolowych. Gdy odwieszę prace, to jeszcze to przejrzę. Semafory powinny być jakoś ujednolicone, planowałem kiedyś zrobić generator, ale teraz pewnie są już jakieś nowocześniejsze rozwiązania. Na potrzeby linii 61 robiłem osobny semafor z opcjonalnymi wskaźnikami i wtedy uznałem, że sterowanie nim jest na tyle odmienne, że powinien być trzymany osobno. Jestem również za trzymaniem przejazdów osobno, one rzadko są uniwersalne. Co do innych obiektów, to nadal czekam na podsumowanie prac zespołu, który w 2015 roku szumnie zapowiadał totalne przeoranie struktury katalogowej.
Co do sieci trakcyjnej, to w planach mam wprowadzenie regulacji, dzięki czemu będzie można wstawiać słupy bez obawy o naruszanie skrajni sąsiedniego toru czy lewitujące wysięgniki w bramkach oraz słupach parasolowych. Gdy odwieszę prace, to jeszcze to przejrzę. Semafory powinny być jakoś ujednolicone, planowałem kiedyś zrobić generator, ale teraz pewnie są już jakieś nowocześniejsze rozwiązania. Na potrzeby linii 61 robiłem osobny semafor z opcjonalnymi wskaźnikami i wtedy uznałem, że sterowanie nim jest na tyle odmienne, że powinien być trzymany osobno. Jestem również za trzymaniem przejazdów osobno, one rzadko są uniwersalne. Co do innych obiektów, to nadal czekam na podsumowanie prac zespołu, który w 2015 roku szumnie zapowiadał totalne przeoranie struktury katalogowej.
23
Na warsztacie / Odp: Uruchomienie LK7
« dnia: 08 Grudnia 2024, 15:50:59 »
Stan na dziś jest taki, że infrastrukturę oraz teren z RSF podzieliłem na komórki (podkatalogi lk7/ oraz lk69/). Podobnie podzieliłem obiekty z otoczenie.scm, przepuszczając przez RSF — zauważalne jest niedopasowanie wysokości do terenu. Paczka lk7-241208.7z jest do pobrania z https://rainsted.com/warsztat/chwilowe/ (jeśli takiej nie będzie, to powinna być kolejna, z nowszą datą).
Scenariuszy nie uruchamiałem, zrobię to przy następnej okazji. Planuję przenieść scenariusze na wersję podzieloną na komórki i przymierzyć się do wygenerowania skryptów sterujących dla stacji (minimalnych, czyli głównie obsługujących przelot ze sprawdzeniem blokady liniowej).
Ponieważ plik RSF ma ponad 40MB, a dodatkowo z obiektów otoczenia utworzyło się kolejne 30MB (i nie są jeszcze wliczone bryły CityGML), to zastanawiam się nad wydzielaniem komórek na poziomie RSF. W ten sposób każda komórka by miała osobny (i mniejszy) RSF, a potencjalnie mogłoby się to również przydać, gdyby zostało uruchomione wczytywanie scenerii z RSF. Szybko to nie będzie, bo to masa pracy, a póki co dalsze prace nad Rainsted mam zawieszone i ograniczam się tylko do ewentualnej naprawy krytycznych błędów.
Scenariuszy nie uruchamiałem, zrobię to przy następnej okazji. Planuję przenieść scenariusze na wersję podzieloną na komórki i przymierzyć się do wygenerowania skryptów sterujących dla stacji (minimalnych, czyli głównie obsługujących przelot ze sprawdzeniem blokady liniowej).
Ponieważ plik RSF ma ponad 40MB, a dodatkowo z obiektów otoczenia utworzyło się kolejne 30MB (i nie są jeszcze wliczone bryły CityGML), to zastanawiam się nad wydzielaniem komórek na poziomie RSF. W ten sposób każda komórka by miała osobny (i mniejszy) RSF, a potencjalnie mogłoby się to również przydać, gdyby zostało uruchomione wczytywanie scenerii z RSF. Szybko to nie będzie, bo to masa pracy, a póki co dalsze prace nad Rainsted mam zawieszone i ograniczam się tylko do ewentualnej naprawy krytycznych błędów.
24
Na warsztacie / Odp: Kaliska - sceneria do pobrania w pierwszym poście!
« dnia: 24 Sierpnia 2024, 12:04:27 »W momencie gdy scenerii są problemy z torami, problemy z rozjazdami oraz różne inne problemy, naprawdę uważasz że tamta dyskusja jest potrzebna na ten moment?Nie, uważam to* za proste do ogarnięcia.
*) "problemy z torami, problemy z rozjazdami oraz różne inne problemy"oraz "błędy w torach, które mogą skutkować nullami itp."
25
Na warsztacie / Odp: Kaliska - sceneria do pobrania w pierwszym poście!
« dnia: 24 Sierpnia 2024, 11:32:51 »
Kiedyś wystarczyło otworzyć plik SCM z torami w Rainsted, uruchomić łączenie odcinków i obejrzeć rezultaty. Wszystkie niezgodności końców torów większe od 1.5mm (domyślnie, można odległość graniczną zmienić na inną) oraz niezgodności przechyłek pokazywały się jako niewypełnione okręgi, w odróżnieniu od mniejszych kropek na prawidłowych połączeniach. Tory można było następnie naprawić, zapamiętując jeden z końców i ustawiając z pamięci odpowiedni koniec sąsiedniego toru. Potem plik można było zapisać — tylko zmodyfikowane odcinki były na nowo generowane, pozostałe zapisywane były w pierwotnej formie tekstowej. Naprawa przechyłek jest bardziej skomplikowana, bo trzeba się nad tym zastanowić i wpisać ręcznie w edytorze tekstowym (odcinki można wyszukać po nazwach). Co się takiego stało, że obecnie są błędy w torach i po ośmiu latach pracy nad scenerią nadal jest to tak poważny problem, że dyskusja o innych zagadnieniach jest zbędna?
26
Pomoc doraźna / Odp: Nie działa mi poprawnie Linia 61
« dnia: 13 Sierpnia 2024, 20:11:32 »
W paczkowej wersji LK64 jest poprawiona? To dlaczego loguje błędy? Ja LK64 nie ruszałem chyba od 2013 roku.
Kiedyś ściągnąłem jakąś nową paczkę. W okolicy Liswarty oraz Gnaszyna były eventy od radiostopu. Coś, co przedtem działało, zaczęło się wysypywać, dalszych testów przejezdności misji nie dało się przeprowadzić.
Kiedyś ściągnąłem inną nową paczkę i przeniosłem na nią pliki LK181... Pociąg z Wielunia po dojechaniu do Herbów Starych spowodował wywalenie się symulacji. Uruchomiłem to kilka razy, rezultat był taki sam. Pozostało mi czekać na nową paczkę i testować na starej, na której to działało.
Kiedyś ściągnąłem jeszcze inną nową paczkę. Uruchomiłem misję z wyjazdem towarowego z Lublińca. Pociąg jadący dwa tory zderzył się wirtualnie z "moim" składem i zaczął go pchać. Dalsze testy nie miały już sensu. Wcześniej to działało poprawnie, tzn. pociągi będące na równoległych do siebie torach się nie zderzały ze sobą.
Kiedyś ściągnąłem jedną z ostatnich nowych paczek. Odpaliłem EN71, który powinien podjechać pod peron w Lublińcu, a przynajmniej dotychczas zawsze tak robił. Po otrzymaniu Ms2 w stronę peronów wrzucił wsteczny i pojechał się wykoleić na końcu toru.
Plus jeszcze kilka innych dziwnych rzeczy, których szczegółów w tej chwili nie pamiętam (typu przestało działać wybudzanie wyłączonych lokomotyw). Testowanie zmian w sceneriach na nowych paczkach nie ma większego sensu, przynajmniej zanim nie wykryje się wszystkich rzeczy, które nie działają. Jeśli są usuwane jakieś pliki z paczki, to powinna być prowadzona lista tych usunięć wraz z informacją, co należy w związku z tym zrobić w pozostałych sceneriach, które w paczce całościowej nie są. Ja o usunięciu koziolbeton.inc dowiedziałem się dzisiaj. Jeszcze bym rozumiał, gdyby to zostało przeniesione do podkatalogu, np. pkp/. Ale w tym samym miejscu pozostał koziol.inc. Więc jaki był cel usunięcia koziolbeton.inc?
Kiedyś ściągnąłem jakąś nową paczkę. W okolicy Liswarty oraz Gnaszyna były eventy od radiostopu. Coś, co przedtem działało, zaczęło się wysypywać, dalszych testów przejezdności misji nie dało się przeprowadzić.
Kiedyś ściągnąłem inną nową paczkę i przeniosłem na nią pliki LK181... Pociąg z Wielunia po dojechaniu do Herbów Starych spowodował wywalenie się symulacji. Uruchomiłem to kilka razy, rezultat był taki sam. Pozostało mi czekać na nową paczkę i testować na starej, na której to działało.
Kiedyś ściągnąłem jeszcze inną nową paczkę. Uruchomiłem misję z wyjazdem towarowego z Lublińca. Pociąg jadący dwa tory zderzył się wirtualnie z "moim" składem i zaczął go pchać. Dalsze testy nie miały już sensu. Wcześniej to działało poprawnie, tzn. pociągi będące na równoległych do siebie torach się nie zderzały ze sobą.
Kiedyś ściągnąłem jedną z ostatnich nowych paczek. Odpaliłem EN71, który powinien podjechać pod peron w Lublińcu, a przynajmniej dotychczas zawsze tak robił. Po otrzymaniu Ms2 w stronę peronów wrzucił wsteczny i pojechał się wykoleić na końcu toru.
Plus jeszcze kilka innych dziwnych rzeczy, których szczegółów w tej chwili nie pamiętam (typu przestało działać wybudzanie wyłączonych lokomotyw). Testowanie zmian w sceneriach na nowych paczkach nie ma większego sensu, przynajmniej zanim nie wykryje się wszystkich rzeczy, które nie działają. Jeśli są usuwane jakieś pliki z paczki, to powinna być prowadzona lista tych usunięć wraz z informacją, co należy w związku z tym zrobić w pozostałych sceneriach, które w paczce całościowej nie są. Ja o usunięciu koziolbeton.inc dowiedziałem się dzisiaj. Jeszcze bym rozumiał, gdyby to zostało przeniesione do podkatalogu, np. pkp/. Ale w tym samym miejscu pozostał koziol.inc. Więc jaki był cel usunięcia koziolbeton.inc?
27
Pomoc doraźna / Odp: Nie działa mi poprawnie Linia 61
« dnia: 13 Sierpnia 2024, 16:25:33 »
Dalej trzeba by wprowadzić zmiany w zarządzaniu projektem, żeby osoby wprowadzające zmiany brały na siebie odpowiedzialność za konsekwencje swoich działań i w razie doprowadzenia do bałaganu były gotowe przywrócić poprawne działanie bądź zorganizować inne osoby, które to zrobią. Póki co jest tak, że każdy może wprowadzać takie zmiany, jakie chce, a potem bujajcie się wszyscy i może przez kolejne lata dojdziecie z tym do ładu. Przykład z usuniętym kozłem: ktoś "zrobił lepiej", a po 7 (słownie: siedmiu) latach nadal loguje się błąd i nikt nie wie dlaczego. I to jest tylko jedna z tysięcy rzeczy, która jest niedopracowana.
Ja kiedyś proponowałem przejść z wczytywaniem scenerii na format RSF i zrobić wczytywanie fragmentami, wtedy by było łatwiej zweryfikować spójność i poprawność scenerii. Ale ktoś postanowił, że trzeba zrobić inaczej, a potem się wypiął. Pojęcia nie mam, co zrobić. Ja się nawet boję pobierać kolejną paczkę całościową, bo nigdy nie wiadomo co kolejnym razem zniknie i co przestanie działać. Więc chyba najlepsza rada, to dać sobie spokój.
Ja kiedyś proponowałem przejść z wczytywaniem scenerii na format RSF i zrobić wczytywanie fragmentami, wtedy by było łatwiej zweryfikować spójność i poprawność scenerii. Ale ktoś postanowił, że trzeba zrobić inaczej, a potem się wypiął. Pojęcia nie mam, co zrobić. Ja się nawet boję pobierać kolejną paczkę całościową, bo nigdy nie wiadomo co kolejnym razem zniknie i co przestanie działać. Więc chyba najlepsza rada, to dać sobie spokój.
28
Pomoc doraźna / Odp: Nie działa mi poprawnie Linia 61
« dnia: 12 Sierpnia 2024, 15:25:53 »O co chodzi ?O totalny bałagan w plikach? O brak sensu niektórych rzeczy?
Kod: [Zaznacz]
Bad scenario: duplicate track name "t501" defined in file "scenery/lk64.scm" (line 740)
Failed to open file "scenery/koziolbeton.inc"LK64? Ten kozioł był od niepamiętnych czasów, jeśli ktoś go postanowił przesunąć, to również powinien dostosować scenerie do tej zmiany.Kod: [Zaznacz]
Bad scenario: duplicate event name "none_dzwiek"Kiedyś zaproponowałem, żeby eventy zaczynane od "none_" były ignorowane, aby można było wstawiać niektóre obiekty z ignorowaniem powiązań (np. semafor ma wbudowane sterowanie tarczą ostrzegawczą, ale chcemy go wstawić bez tej tarczy i żeby nie wywalało to błędów). Obecnie ktoś uznał, że trzeba to logować jako duplikaty, chętnie przeczytałbym uzasadnienie.Kod: [Zaznacz]
Bad scenario: duplicate 3d model instance name "editor_39251.483753" defined in file "scenery/linia61/otoczenie/otoczenie_trawy_wielkopow.scm" (line 3146)Zawartość pliku wczytana dwukrotnie?Kod: [Zaznacz]
Bad scenario: unexpected token "ode" defined in file "scenery/linia61/otoczenie/otoczenie_drzewa_male.scm" Niechlujstwo?Kod: [Zaznacz]
Missed file: noneZa ten komunikat to ktoś powinien dostać nagrodę w konkursie na najbardziej bezsensowny kod.
29
Bieżące Symulatorowe / Odp: MaSzyna na androida
« dnia: 11 Sierpnia 2024, 22:51:08 »
No to szwankuje obsługa pliku INI, bo również tam są zapisywane składy idące do magazynu. Sprawdzanie taboru również zapisuje plik INI — dynamic/textures.ini — tworzony z danych pobranych z plików textures.txt.
30
Bieżące Symulatorowe / Odp: MaSzyna na androida
« dnia: 11 Sierpnia 2024, 19:48:01 »
Jeśli do INI się zapisuje poprawnie, a potem się jakoś gubi, to będę musiał sprawdzić. W przypadku EN57 trzeba było ustawić obsadę connected, żeby się sterowanie przesyłało z rozrządczego do silnikowego, czy coś takiego.