61
A teraz napiszę sobie jak trole: łał, 4000. wiadomość!
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.
62
Bocznica / Wydzielone z: Uruchamianie laptopa.
« dnia: 25 Listopada 2012, 14:29:17 »
Czy my tu prowadzimy serwis komputerowy?
63
Infrastruktura kolejowa / Zasilanie elektryczne kolei w różnych krajach
« dnia: 11 Października 2012, 17:22:20 »
Znalazłem mapkę przedstawiającą napięcia zasilające na liniach kolejowych w Europie. Myślę, że dobrze by było ją zachować.
Mapka pochodzi ze strony http://www.eurotrib.com/story/2009/7/4/62819/62696.
 | Żółty: 25kV, 50Hz Czerwony: 15kV, 16.7Hz Fiolet: 11kV, 16.7Hz (1000mm) Zielony: 3kV stały Niebieski: 1.5kV stały Turkus: trzecia szyna 750V stały Szary: spalinowe albo brak kolei |
Mapka pochodzi ze strony http://www.eurotrib.com/story/2009/7/4/62819/62696.
64
Infrastruktura kolejowa / Profil pionowy linii 144
« dnia: 02 Października 2012, 12:37:40 »
Na podstawie mapy topograficznej udało mi się ustalić położenie kilku punktów geodezyjnych na tej linii. Potrzebna by była jednak ich weryfikacja w terenie i pomierzenie wysokości od punktu do główki szyny (dokładność ±10cm wystarczy). Ewentualnie przyda się przejazd tamtędy z odbiornikiem GPS, czy pomiary na szynie przy słupkach hektometrowych.
53.211 - 184.3m - skrzyżowanie przy przejeździe
53.901 - 183.8m - budynek przy przjeździe
55.375 - 183.4m - budynek stacyjny Ozimek
56.335 - 182.4m - przepust
57.177 - 190.0m - poziomica na początku przekopu
62.565 - 175.3m - budynek
63.945 - 170.0m - poziomica
66.931 - 162.0m - punkt geodezyjny
67.538 - 162.28m - punkt geodezyjny
68.169 - 162.77m - przejazd (Suchy Bór)
69.058 - 160.18m - przepust w lesie
69.907 - 159.82m - przejazd w lesie
70.167 - 159.03m - przepust w lesie
Oczywiście, gdyby się już za to ktoś poważnie zabierał, to trzeba też sprawdzić na mapach topograficznych (geoportal.gov.pl) wcześniejszy odcinek (50km) i wypisać w podobny jak powyżej sposób wszystkie możliwe punkty wyznaczenia wysokości.
53.211 - 184.3m - skrzyżowanie przy przejeździe
53.901 - 183.8m - budynek przy przjeździe
55.375 - 183.4m - budynek stacyjny Ozimek
56.335 - 182.4m - przepust
57.177 - 190.0m - poziomica na początku przekopu
62.565 - 175.3m - budynek
63.945 - 170.0m - poziomica
66.931 - 162.0m - punkt geodezyjny
67.538 - 162.28m - punkt geodezyjny
68.169 - 162.77m - przejazd (Suchy Bór)
69.058 - 160.18m - przepust w lesie
69.907 - 159.82m - przejazd w lesie
70.167 - 159.03m - przepust w lesie
Oczywiście, gdyby się już za to ktoś poważnie zabierał, to trzeba też sprawdzić na mapach topograficznych (geoportal.gov.pl) wcześniejszy odcinek (50km) i wypisać w podobny jak powyżej sposób wszystkie możliwe punkty wyznaczenia wysokości.
65
Tabor kolejowy / MÁV V43 - zbiór informacji
« dnia: 22 Września 2012, 21:05:28 »
MÁV V43 to węgierska lokomotywa elektryczna, zbudowana w latach '60 XX wieku. Zasilana prądem przemiennym 25kV/50 Hz.
http://en.wikipedia.org/wiki/M%C3%81V_Class_V43
Strona ze schematem:
http://elektroman.uw.hu/vasut/v43.htm
Film z charakterystykami:
http://en.wikipedia.org/wiki/M%C3%81V_Class_V43
Strona ze schematem:
http://elektroman.uw.hu/vasut/v43.htm
Film z charakterystykami:
66
Bieżące Symulatorowe / Co poprawić w pierwszej kolejności?
« dnia: 26 Lipca 2012, 01:34:12 »
Podobnie jak w ubiegłym roku, mam zamiar uruchomić ankietę z propozycjami zmian. Względem poprzedniej paczki został skrócony czas wczytywania scenerii (było 97 głosów czyli 12.1%), zwiększona jest wydajność grafiki (46 - 5.6%), znacznie lepiej działa AI (39 - 4.9%), również w zakresie zatrzymywania samochodów na przejazdach (17 - 2.1%). Z propozycji o mniejszej ilości głosów zostało zrealizowane przechodzenie do innych pojazdów (2 - 0.2%). Nie wyliczam tutaj propozycji zmian w sceneriach, modelach i scenariuszach, którymi bezpośrednio się nie zajmuję i trudno mi zweryfikować, na ile postulaty zostały zrealizowane (np. czy jest wystarczająco więcej ludzi na peronach).
Zastanówcie się, co należało by dopracować w pierwszej kolejności, biorąc pod uwagę PC2011, EU07.EXE 355oraz planowane obecnie do wydania Całkowo 2.0. Ankietę uruchomię kilka dni po wydaniu tej scenerii, ponieważ będzie ona wykorzystywać nowe możliwości i chcę dać czas na zapoznanie się z nimi.
Tak jak poprzednio, będę dodawał do ankiety kolejne zgłaszane propozycje, a swoje głosy będzie można modyfikować aż do zamknięcia ankiety, co nastąpi po paru tygodniach. Ankieta posłuży mi do ustalenia priorytetów dla dalszych prac, w szczególności kilku zaczętych pomysłów.
Zastanówcie się, co należało by dopracować w pierwszej kolejności, biorąc pod uwagę PC2011, EU07.EXE 355
Tak jak poprzednio, będę dodawał do ankiety kolejne zgłaszane propozycje, a swoje głosy będzie można modyfikować aż do zamknięcia ankiety, co nastąpi po paru tygodniach. Ankieta posłuży mi do ustalenia priorytetów dla dalszych prac, w szczególności kilku zaczętych pomysłów.
67
Bieżące Symulatorowe / Mapowanie podsypki
« dnia: 15 Sierpnia 2012, 13:14:08 »
Dotychczas poprzeczne mapowanie podsypki wykonywane było z podziałem tekstury na 3 części. Od 0 do 0.33 mapowane jest lewe pochylenie, od 0.33 do 0.67 jest górna płaszczyzna, a od 0.67 do 1 prawy bok. Przy standardowym (tzn. z Księżyca wziętym) profilu 0.2 0.5 1.1 i np. 512 pikselach na szerokość daje to:
Dodatkowo górna powierzchnia zawiera szyny, pomiędzy którymi powinna zostać zachowana stała odległość, niezależnie od szerokości tej powierzchni.
W efekcie przygotowując teksturę podsypki trzeba ją odpowiednio skalować, jak również każdy profil wymaga innego zestawu tekstur. Padła propozycja, aby mapować teksturę podsypki ze stałą rozdzielczością px/m. Wadą tego rozwiązania będzie brak możliwości robienia zielonych brzegów na łączeniu z terenem. A przynajmniej będzie trudniej z nimi trafić, bo mapowanie nie będzie od 0 do 1, tylko zostanie wyliczone w zależności od całkowitej długości przekroju.
Do uzgodnienia jest kwestia, jak to powinno być mapowane, żeby było dobrze, tzn. żeby prościej było robić tekstury albo aby wyglądały one lepiej, albo żeby się dało używać tej samej tekstury na różne profile. Wiadomo, że podkłady mają określoną długość i raczej się ich nie skaluje przy zmianie rozstawu torów. W drodze wyjątku dla podsypki 0.2 0.5 1.1 można zachować dotychczasowe mapowanie.
- 0.33*512/1.118=151.13 pikseli na metr na boku
- 0.34*512/2.435=71.49 pikseli na metr na górnej powierzchni
- 0.33*512/1.082=156.2 pikseli na metr na boku
- 0.34*512/3.235=53.81 pikseli na metr na górnej powierzchni
Dodatkowo górna powierzchnia zawiera szyny, pomiędzy którymi powinna zostać zachowana stała odległość, niezależnie od szerokości tej powierzchni.
W efekcie przygotowując teksturę podsypki trzeba ją odpowiednio skalować, jak również każdy profil wymaga innego zestawu tekstur. Padła propozycja, aby mapować teksturę podsypki ze stałą rozdzielczością px/m. Wadą tego rozwiązania będzie brak możliwości robienia zielonych brzegów na łączeniu z terenem. A przynajmniej będzie trudniej z nimi trafić, bo mapowanie nie będzie od 0 do 1, tylko zostanie wyliczone w zależności od całkowitej długości przekroju.
Do uzgodnienia jest kwestia, jak to powinno być mapowane, żeby było dobrze, tzn. żeby prościej było robić tekstury albo aby wyglądały one lepiej, albo żeby się dało używać tej samej tekstury na różne profile. Wiadomo, że podkłady mają określoną długość i raczej się ich nie skaluje przy zmianie rozstawu torów. W drodze wyjątku dla podsypki 0.2 0.5 1.1 można zachować dotychczasowe mapowanie.
68
Bieżące Symulatorowe / Chodzące ludziki
« dnia: 28 Lipca 2012, 18:22:43 »
Znalazłem taką stronę: http://www.proviz3d.com/
Można stamtąd pobrać bezpłatnie modele 3D chodzących ludzi. Do symulatora się nie nadadzą, ze względu na licencję. Ale można się zapoznać, jak to jest zrobione i coś pomyśleć nad własnymi.
Można stamtąd pobrać bezpłatnie modele 3D chodzących ludzi. Do symulatora się nie nadadzą, ze względu na licencję. Ale można się zapoznać, jak to jest zrobione i coś pomyśleć nad własnymi.
69
Publikacje / EU07.EXE, wersje: 355, 372 i 390
« dnia: 19 Lipca 2012, 00:03:19 »
Wersja 1.8.595.355 EU07.EXE powstała na początku czerwca w wyniku sukcesywnego wprowadzania poprawek i eliminowania błędów zauważonych podczas pracy nad Paczką Całościową 2011 i po jej wydaniu. Do chwili obecnej jest to najlepsza istniejąca wersja.
Najważniejszą zmianą jest ulepszony sposób skanowania torów przez AI. Ze względu na tę zmianę, w niektórych przypadkach, scenerie z PC2011 mogą nie działać poprawnie. Dotychczas AI widziało tylko jedno ograniczenie i do niego się stosowało. Nie zawsze był to optymalny wybór. Obecnie AI bierze pod uwagę zarówno ograniczenia wpisane w tory jak i podawane przez semafory, a także uwzględnia prędkość pojazdu z przodu (ważne dla samochodów). Dodatkowo, po użyciu klawisza [F2] można w czwartej linijce odczytać aktualną zalecaną prędkość (Vd), prędkość na kolejnym odcinku (Vn) i odległość do tego odcinka (Pd). Dane te są również pokazywane w przypadku sterowania lokomotywy przez użytkownika. Ze względu na niepełne dostosowanie scenerii, pokazywane informacje mogą się różnić od wytycznych scenariusza (gdy np. przejechanie S1 na rozkaz dyktowany przez radio nie zostało przewidziane do wykonania przez AI, albo wskaźniki ograniczenia prędkości ustawione przy torze nie są poparte wpisaniem zmniejszonej prędkości w tory).
Ważniejsze poprawki błędów względem wersji 325 (PC2011):
Ważniejsze nowe funkcje:
Więcej informacji o wersji 355 EU07.EXE... Proszę się zapoznać z zawartością tej strony przed zgłoszeniem błędu na forum (paczka nie zawiera pliku informacyjnego).
Plik udostępniam ze względu na zgłaszane błędy (niepełna blokada klawiatury, nagłe zatrzymania na łukach) oraz w związku z planami wydania nowych scenariuszy, które nie będą działały prawidłowo na wersji 325.
Zawartość archiwum należy wypakować do katalogu z EU07.EXE, ewentualnie zmienić nazwę EU07_355.EXE na EU07.EXE.
Najważniejszą zmianą jest ulepszony sposób skanowania torów przez AI. Ze względu na tę zmianę, w niektórych przypadkach, scenerie z PC2011 mogą nie działać poprawnie. Dotychczas AI widziało tylko jedno ograniczenie i do niego się stosowało. Nie zawsze był to optymalny wybór. Obecnie AI bierze pod uwagę zarówno ograniczenia wpisane w tory jak i podawane przez semafory, a także uwzględnia prędkość pojazdu z przodu (ważne dla samochodów). Dodatkowo, po użyciu klawisza [F2] można w czwartej linijce odczytać aktualną zalecaną prędkość (Vd), prędkość na kolejnym odcinku (Vn) i odległość do tego odcinka (Pd). Dane te są również pokazywane w przypadku sterowania lokomotywy przez użytkownika. Ze względu na niepełne dostosowanie scenerii, pokazywane informacje mogą się różnić od wytycznych scenariusza (gdy np. przejechanie S1 na rozkaz dyktowany przez radio nie zostało przewidziane do wykonania przez AI, albo wskaźniki ograniczenia prędkości ustawione przy torze nie są poparte wpisaniem zmniejszonej prędkości w tory).
Ważniejsze poprawki błędów względem wersji 325 (PC2011):
- Lepsza blokada klawiatury przy działaniu w tle
- Poprawiony ruch samochodów
- Lepsze przechylanie pojazdów (niepotrzebne są banany)
- Poprawione liczenie długości łuku (powodowały nagłe zatrzymanie)
- Przywrócone logowanie parametrów fizycznych
Ważniejsze nowe funkcje:
- Osobny plik do logowania błędów errors.txt
- Regulacja promienia renderowania (FPS od 16 do 25)
- Końcówki w nieaktywnych składach (ostatni sprzęg decyduje)
- Tabelka prędkości dla AI
Więcej informacji o wersji 355 EU07.EXE... Proszę się zapoznać z zawartością tej strony przed zgłoszeniem błędu na forum (paczka nie zawiera pliku informacyjnego).
Plik udostępniam ze względu na zgłaszane błędy (niepełna blokada klawiatury, nagłe zatrzymania na łukach) oraz w związku z planami wydania nowych scenariuszy, które nie będą działały prawidłowo na wersji 325.
Zawartość archiwum należy wypakować do katalogu z EU07.EXE, ewentualnie zmienić nazwę EU07_355.EXE na EU07.EXE.
70
Bieżące Symulatorowe / [F5] - tryb jazdy/uruchomienia
« dnia: 16 Lipca 2012, 12:43:08 »
Ponieważ wyczerpują się pomału klawisze na klawiaturze, proponuję wprowadzić rozdzielenie trybu jazdy od uruchomienia. Przełączało by się to w dowolnym momencie klawiszem [F5], będąc wewnątrz pojazdu.
W trybie uruchomienia lokomotywy było by dostępne przechodzenie pomiędzy kabinami, załączanie baterii, rozrządu, sprężarki pomocniczej pantografu, a także poruszanie hamulcem postojowym i drzwiami. Było by to zamiast np. zapalania świateł i innych opcji potrzebnych raczej podczas jazdy. Naciśnięcie prawego przycisku myszy ustawiało by na pozycji stojącej.
W trybie jazdy powyższe funkcje były by niedostępne, a większość funkcji działała by tak jak obecnie. Naciśnięcie prawego przycisku myszy ustawiało by na pozycji siedzącej.
W trybie uruchomienia lokomotywy było by dostępne przechodzenie pomiędzy kabinami, załączanie baterii, rozrządu, sprężarki pomocniczej pantografu, a także poruszanie hamulcem postojowym i drzwiami. Było by to zamiast np. zapalania świateł i innych opcji potrzebnych raczej podczas jazdy. Naciśnięcie prawego przycisku myszy ustawiało by na pozycji stojącej.
W trybie jazdy powyższe funkcje były by niedostępne, a większość funkcji działała by tak jak obecnie. Naciśnięcie prawego przycisku myszy ustawiało by na pozycji siedzącej.
71
Jedną z rzeczy, które nie są zrobione porządnie (albo prawie wcale) są ukresy (W17). Ukres to miejsce, w którym skład się powinien zatrzymać przed rozjazdem albo skrzyżowaniem torów tak, aby nie kolidować z ruchem na sąsiednim torze.
Najbliższy funkcjonalnie ukresowi obiekt to zatrzymanie przy peronie (W4). W4 działa w ten sposób, że na podstawie rozkładu ustalana jest nazwa stacji/przystanku, której W4 mają być widoczne. Wszystkie inne, niepasujące do nazwy w rozkładzie będą ignorowane. W4 posiada event PutValues, z komendą PassengerStopPoint:*, zawierającą nazwę stacji/przystanku. Nazwa eventu musi być unikalna na scenerii, ponieważ istotne są współrzędne W4. Z kolei nazwa stacji musi być identyczna we wszystkich W4 na całej stacji. Zostało to rozwiązane poprzez użycie znaku # w nazwie eventu oraz w komendzie, przy czym w komendzie znaki od # są automatycznie ignorowane. W4 musi być oddzielny dla każdego toru, ponieważ określa również z której strony toru znajduje się peron (które drzwi otworzyć). Przykład zastosowania aktywnych W4 i ruch AI z uwzględnieniem W4 można prześledzić na scenerii Quark z PC2011.
W17 lepiej by było przypisywać od razu do obu sąsiednich torów, dzięki czemu będzie mniej eventów. Obecna wersja AI rzutuje sobie wszelkie sygnały na swoją trajektorię ruchu, więc odległość sygnału (miejsca wstawienia XYZ eventu) od osi toru nie ma znaczenia.
Osobną kwestią jest zaprogramowanie AI, żeby wiedziało, jak ma się zatrzymać względem ukresów. Tzn. czy tylko wjechać za ukres, czy dojechać do następnego. W szczególnym przypadku, co zrobić, jeśli skład jest dłuższy niż dostępny tor (np. przejechać za semafor aż do ukresu).
Kolejna kwestia jest taka, że ukresy powinny zawierać informację o torach, przy których się znajdują, aby AI podczas manewrów mogło określić, na którym jest torze. Można by utworzyć komendę FoulingPoint:* (z nazwą stacji i unikalnym numerem po znaku #), a jako parametry liczbowe podać numery torów po lewej i prawej stronie.
Najbliższy funkcjonalnie ukresowi obiekt to zatrzymanie przy peronie (W4). W4 działa w ten sposób, że na podstawie rozkładu ustalana jest nazwa stacji/przystanku, której W4 mają być widoczne. Wszystkie inne, niepasujące do nazwy w rozkładzie będą ignorowane. W4 posiada event PutValues, z komendą PassengerStopPoint:*, zawierającą nazwę stacji/przystanku. Nazwa eventu musi być unikalna na scenerii, ponieważ istotne są współrzędne W4. Z kolei nazwa stacji musi być identyczna we wszystkich W4 na całej stacji. Zostało to rozwiązane poprzez użycie znaku # w nazwie eventu oraz w komendzie, przy czym w komendzie znaki od # są automatycznie ignorowane. W4 musi być oddzielny dla każdego toru, ponieważ określa również z której strony toru znajduje się peron (które drzwi otworzyć). Przykład zastosowania aktywnych W4 i ruch AI z uwzględnieniem W4 można prześledzić na scenerii Quark z PC2011.
W17 lepiej by było przypisywać od razu do obu sąsiednich torów, dzięki czemu będzie mniej eventów. Obecna wersja AI rzutuje sobie wszelkie sygnały na swoją trajektorię ruchu, więc odległość sygnału (miejsca wstawienia XYZ eventu) od osi toru nie ma znaczenia.
Osobną kwestią jest zaprogramowanie AI, żeby wiedziało, jak ma się zatrzymać względem ukresów. Tzn. czy tylko wjechać za ukres, czy dojechać do następnego. W szczególnym przypadku, co zrobić, jeśli skład jest dłuższy niż dostępny tor (np. przejechać za semafor aż do ukresu).
Kolejna kwestia jest taka, że ukresy powinny zawierać informację o torach, przy których się znajdują, aby AI podczas manewrów mogło określić, na którym jest torze. Można by utworzyć komendę FoulingPoint:* (z nazwą stacji i unikalnym numerem po znaku #), a jako parametry liczbowe podać numery torów po lewej i prawej stronie.
72
Na warsztacie / Kozłów - Psary
« dnia: 10 Czerwca 2012, 00:49:13 »
Jakiś czas temu zacząłem modelować w Rainsted linię 64 Kozłów - Koniecpol wraz z wjazdem na CMK oraz stacją Psary. Przy stacji Kozłów przebiega fragment LHS (linia 65). Na zdjęciach z Geoportalu stacja Sczekociny ma jeszcze tory dodatkowe, ale ja zrobiłem w wersji bez nich. Również dodałem posterunek Sprowa.
Zastanawiam się, w jakiej postaci można by wydać tę scenerię. Dopracowanie jej pod względem graficznym zajmie dużo czasu, nawet mimo tego, że przebiega ona w terenie niezurbanizowanym. Z drugiej strony linia jest ciekawa technicznie, ponieważ można będzie na niej jeździć 150km/h (po wymianie sieci trakcyjnej), a przez stację Kozłów przechodzi praktycznie cały ruch pomiędzy Warszawą a Krakowem. Do tego pociągi LHS.
Zastanawiam się, w jakiej postaci można by wydać tę scenerię. Dopracowanie jej pod względem graficznym zajmie dużo czasu, nawet mimo tego, że przebiega ona w terenie niezurbanizowanym. Z drugiej strony linia jest ciekawa technicznie, ponieważ można będzie na niej jeździć 150km/h (po wymianie sieci trakcyjnej), a przez stację Kozłów przechodzi praktycznie cały ruch pomiędzy Warszawą a Krakowem. Do tego pociągi LHS.
73
Poszukuję, chcę zrobić / Symulator kierownika
« dnia: 25 Maja 2012, 20:10:10 »
Chciałbym w nowej wersji AI zrobić symulację kierownika pociągu osobowego. Moim zdaniem numer pociągu podawany przez radio można by składać z oddzielnie nagranych fraz, jak to robi Ivona albo nawigacje samochodowe (chociaż tym wychodzi to raczej kiepsko). Potrzebne by były nagrane liczebniki (czy od 1 do 99 wystarczy, czy potrzebne są także setki?) oraz kilka wersji "gotów" czy "odjazd" (o nieco innej intonacji). AI by wiedziało, gdzie znajduje się kierownik i jeśli w tym samym członie EZT, to odtwarzana by była wersja bezpośrednia a nie radiowa (i bez numeru).
Oczywiście automatyczna komenda gotowości/odjazdu będzie podawana po zatrzymaniu na W4, gdy upłynie godzina odjazdu i będzie podana wolna droga. Docelowo powinno być kilka kompletów głosów i dla każdego składu byłby losowany głos...
Prosiłbym o przygotowanie próbek nagrań i ewentualnie uwagi do uwzględnienia.
Oczywiście automatyczna komenda gotowości/odjazdu będzie podawana po zatrzymaniu na W4, gdy upłynie godzina odjazdu i będzie podana wolna droga. Docelowo powinno być kilka kompletów głosów i dla każdego składu byłby losowany głos...
Prosiłbym o przygotowanie próbek nagrań i ewentualnie uwagi do uwzględnienia.
74
Inne niekolejowe / Referendum emerytalne
« dnia: 22 Marca 2012, 18:15:19 »
W związku ze zbieraniem podpisów dotyczących reformy emerytalnej, przedstawiam moją wersję pytań.
Jednocześnie przypominam, że emerytury wynalazł niejaki Otto von Bismarck pod koniec XIX wieku, aby zatrzymać emigrację Niemców do USA, gdzie stawki za pracę były większe, ale nie było żadnej pomocy socjalnej. Do pobierania emerytury uprawniało wtedy ukończenie 70 lat, przy średniej wieku około 45 lat (obecnie około 75 lat).
P.s. Zapomniałem dodać, że w XIX w. ludzie pracowali po 12 godzin dziennie albo więcej i nie było wolnych sobót.
Jednocześnie przypominam, że emerytury wynalazł niejaki Otto von Bismarck pod koniec XIX wieku, aby zatrzymać emigrację Niemców do USA, gdzie stawki za pracę były większe, ale nie było żadnej pomocy socjalnej. Do pobierania emerytury uprawniało wtedy ukończenie 70 lat, przy średniej wieku około 45 lat (obecnie około 75 lat).
P.s. Zapomniałem dodać, że w XIX w. ludzie pracowali po 12 godzin dziennie albo więcej i nie było wolnych sobót.
75
Symulator / FreeSpotLight w modelu
« dnia: 10 Marca 2012, 10:58:41 »
Jest to punkt świecący, widoczny "z daleka", używany jako światła sygnalizatorów, latarń oraz pojazdów. Sposób świecenia takiego punktu określają parametry, ale póki co nie wszystkie są wykorzystane. Przykładowe parametry:
Parent: headlamp11_on - nazwa obiektu nadrzędnego
Type: FreeSpotLight - typ dla punktu świecącego
Name: Fspot03 - nazwa punktu (zwykle nieistotna)
Anim: false - zwykle nie ma animacji
Diffuse: 255.0 205.0 147.0 - kolor światła
SelfIllum: true - czy ma świecić
NearAttenStart: 0.0 - nieużywany
NearAttenEnd: 40.0 - nieużywany
UseNearAtten: false - nieużywany
FarAttenDecayType: 1 - nieużywany
FarDecayRadius: 40.0 - nieużywany
FalloffAngle: 45.0 - kąt wygaszenia światła
HotspotAngle: 43.0 - kąt pełnej jasności światła
MaxDistance: 1000 - maksymalna odległość
MinDistance: 20 - minimalna odległość
Zaczynając od końca, trzeba ustawić minimalną odległość na wartość większą od zera, inaczej po zbliżeniu się do obiektu będzie widoczny wyraźny punkt np. w środku światła. Były argumenty, że ma to symulować żarnik żarówki, ale w tej roli sprawdza się kiepsko.
Światło jest widoczne w kierunku, w którym zostanie ustawiona oś OX (to trzeba jeszcze sprawdzić). Jasność światła jest taka sama do kąta ±HotspotAngle:, a przy większym kącie jest coraz słabiej widoczne, aż do kąta ±FalloffAngle:, przy którym zanika. W załączeniu obrazek. Drugi przedstawia zależność efektu od proporcji tych kątów. Oczywiście w MaSzynie nie ma daje to efektu smugi reflektora, raczej jest to "patrzenie w światło".
Trochę więcej na ten temat:
http://www.povray.org/documentation/view/3.6.0/310/
Dodano: 14 Marca 2012, 12:16:11
Od wersji 325 EU07.EXE kąt podany we FreeSpotLight jest traktowany jako kąt oparty na średnicy, a nie na promieniu. Czyli przykładowo dla lampy umieszczonej na płaskiej ścianie należy podawać 180°, a światło z kątem 360° będzie widoczne ze wszystkich stron.
Odnośnie semaforów:
Parent: headlamp11_on - nazwa obiektu nadrzędnego
Type: FreeSpotLight - typ dla punktu świecącego
Name: Fspot03 - nazwa punktu (zwykle nieistotna)
Anim: false - zwykle nie ma animacji
Diffuse: 255.0 205.0 147.0 - kolor światła
SelfIllum: true - czy ma świecić
NearAttenStart: 0.0 - nieużywany
NearAttenEnd: 40.0 - nieużywany
UseNearAtten: false - nieużywany
FarAttenDecayType: 1 - nieużywany
FarDecayRadius: 40.0 - nieużywany
FalloffAngle: 45.0 - kąt wygaszenia światła
HotspotAngle: 43.0 - kąt pełnej jasności światła
MaxDistance: 1000 - maksymalna odległość
MinDistance: 20 - minimalna odległość
Zaczynając od końca, trzeba ustawić minimalną odległość na wartość większą od zera, inaczej po zbliżeniu się do obiektu będzie widoczny wyraźny punkt np. w środku światła. Były argumenty, że ma to symulować żarnik żarówki, ale w tej roli sprawdza się kiepsko.
Światło jest widoczne w kierunku, w którym zostanie ustawiona oś OX (to trzeba jeszcze sprawdzić). Jasność światła jest taka sama do kąta ±HotspotAngle:, a przy większym kącie jest coraz słabiej widoczne, aż do kąta ±FalloffAngle:, przy którym zanika. W załączeniu obrazek. Drugi przedstawia zależność efektu od proporcji tych kątów. Oczywiście w MaSzynie nie ma daje to efektu smugi reflektora, raczej jest to "patrzenie w światło".
Trochę więcej na ten temat:
http://www.povray.org/documentation/view/3.6.0/310/
Dodano: 14 Marca 2012, 12:16:11
Od wersji 325 EU07.EXE kąt podany we FreeSpotLight jest traktowany jako kąt oparty na średnicy, a nie na promieniu. Czyli przykładowo dla lampy umieszczonej na płaskiej ścianie należy podawać 180°, a światło z kątem 360° będzie widoczne ze wszystkich stron.
Odnośnie semaforów:
Cytuj
Na obwodzie zewnętrznych soczewek semaforów znajdują się sektory, które odchylają strumień światła o kąt 55 stopni, dzięki czemu maszynista w pojeździe trakcyjnym stojącym blisko sygnalizatora jest w stanie rozpoznać, które lampy emitują światło.i jak rozumiem odchylają o kąt od linii poziomej, czyli jest to kąt w sensie promienia, a w sensie średnicy to było by 110°. Byłbym wdzięczny, gdyby ktoś mógł zweryfikować tę informację.
76
Symulator / Przechyłka a oś obrotu
« dnia: 03 Marca 2012, 11:22:26 »
Obecnie jest tak, że jak w torze jest przechyłka, to jedna szyna jest podnoszona do góry, a druga opuszczana w dół. W efekcie oś obrotu jest na środku toru, a powinna znajdować się na środku wewnętrznej szyny łuku (przyjmuje się rozstaw 1.5m dla toru normalnego).
Przeniesienie osi obrotu ze środka na szynę wydawać by się mogło sprawą prostą, ale tak nie jest. Składa się na to trajektoria ruchu pojazdu oraz wysokość podsypki. Przy podnoszeniu jedynie zewnętrznej szyny (przy tworzeniu modelu 3D toru), należy również podnieść płaszczyznę trajektorii ruchu, inaczej pojazd zagłębi się w szynach. Z kolei jeśli już podniesiemy trajektorię, to należy odpowiednio zwiększyć wysokość podsypki, inaczej będzie ona wisieć ponad poziomem terenu.
Pytanie jest, w którym momencie danych należy podwyższyć trajektorię? Można to zrobić na etapie plików scenerii, wtedy symulacja będzie po takiej trajektorii, jaka została zdefiniowana, ale trzeba o tym pamiętać, jak również o zwiększeniu wysokości podsypki albo podwyższenia terenu. Można też to zrobić automatycznie po wczytaniu scenerii, ale wtedy mamy taką sytuację, że co innego modelujemy, a co innego jest używane w symulacji.
Jest jeszcze jeden problem, a mianowicie podwójna rampa przechyłkowa na poszerzeniach toru (stosuje się to często np. przed peronami). W tym przypadku na początku rampy mamy kąt x°, który na jej końcu zamienia się w -x°. Jednak tym razem oś obrotu jest na środku pomiędzy szynami, a rampa ta styka się z łukami odwrotnymi, które mają oś obrotu na wewnętrznych szynach!
Przeniesienie osi obrotu ze środka na szynę wydawać by się mogło sprawą prostą, ale tak nie jest. Składa się na to trajektoria ruchu pojazdu oraz wysokość podsypki. Przy podnoszeniu jedynie zewnętrznej szyny (przy tworzeniu modelu 3D toru), należy również podnieść płaszczyznę trajektorii ruchu, inaczej pojazd zagłębi się w szynach. Z kolei jeśli już podniesiemy trajektorię, to należy odpowiednio zwiększyć wysokość podsypki, inaczej będzie ona wisieć ponad poziomem terenu.
Pytanie jest, w którym momencie danych należy podwyższyć trajektorię? Można to zrobić na etapie plików scenerii, wtedy symulacja będzie po takiej trajektorii, jaka została zdefiniowana, ale trzeba o tym pamiętać, jak również o zwiększeniu wysokości podsypki albo podwyższenia terenu. Można też to zrobić automatycznie po wczytaniu scenerii, ale wtedy mamy taką sytuację, że co innego modelujemy, a co innego jest używane w symulacji.
Jest jeszcze jeden problem, a mianowicie podwójna rampa przechyłkowa na poszerzeniach toru (stosuje się to często np. przed peronami). W tym przypadku na początku rampy mamy kąt x°, który na jej końcu zamienia się w -x°. Jednak tym razem oś obrotu jest na środku pomiędzy szynami, a rampa ta styka się z łukami odwrotnymi, które mają oś obrotu na wewnętrznych szynach!
77
Pomoc doraźna / EU07.EXE nie działa na sterownikach ATI 11.8
« dnia: 18 Sierpnia 2011, 20:48:54 »
Gdyby komuś przyszło do głowy zaktualizować sterowniki do Catalyst 11.8, to wszystkie EU07.EXE wysypują się na otwieraniu okna OpenGL, które na wcześniejszych sterownikach działało. Inne programy z grafiką 3D wydają się działać prawidłowo. Na chwilę obecną przyczyna ani rozwiązanie nie są znane.
78
Wydział zamówień / Płyty przejazdowe
« dnia: 07 Sierpnia 2011, 20:43:44 »
Od pewnego czasu nurtuje mnie temat poprawienia wyglądu przejazdów (skrzyżowań torów z drogami). To, co obecnie jest widać w Symulatorze daleko odbiega od rzeczywistości - szyny wystają z asfaltu, albo jest kawałek "betonu" położony na drodze.
Według tego, co obserwowałem, pomiędzy szynami oraz na zewnątrz nich umieszczone są równolegle do torów płyty betonowe. Jeśli droga jest pod kątem do torów, to płyty są odpowiednio szersze i ułożone schodkowo. Najczęściej są użyte dwie albo trzy płyty, jedna ewentualnie na drogach polnych. Płyty pomiędzy szynami mają ścięte rogi. Chodzi mi o takie płyty:
http://www.transportszynowy.pl/kolrognaped2.html
http://www.transportszynowy.pl/kolrognaped2a.html
Obserwowałem płyty w centralnej Polsce, być może gdzieś indziej stosuje się inne rozwiązania, np. płyty o mniejszych rozmiarach:
http://www.transportszynowy.pl/rogatka1.html
http://www.transportszynowy.pl/kolprzejazddrew1.html
Potrzebne są wymiary takich płyt (wspomniane międzyszynowe prawdopodobnie 1300×3000 mm) oraz zdjęcia na tekstury robione z góry.
Według tego, co obserwowałem, pomiędzy szynami oraz na zewnątrz nich umieszczone są równolegle do torów płyty betonowe. Jeśli droga jest pod kątem do torów, to płyty są odpowiednio szersze i ułożone schodkowo. Najczęściej są użyte dwie albo trzy płyty, jedna ewentualnie na drogach polnych. Płyty pomiędzy szynami mają ścięte rogi. Chodzi mi o takie płyty:
http://www.transportszynowy.pl/kolrognaped2.html
http://www.transportszynowy.pl/kolrognaped2a.html
Obserwowałem płyty w centralnej Polsce, być może gdzieś indziej stosuje się inne rozwiązania, np. płyty o mniejszych rozmiarach:
http://www.transportszynowy.pl/rogatka1.html
http://www.transportszynowy.pl/kolprzejazddrew1.html
Potrzebne są wymiary takich płyt (wspomniane międzyszynowe prawdopodobnie 1300×3000 mm) oraz zdjęcia na tekstury robione z góry.
79
Publikacje / EU07.EXE, wersje: 212, 231, 291
« dnia: 03 Sierpnia 2011, 01:44:22 »
W najbliższych dniach mam zamiar opublikować nową wersję pliku EU07.EXE. Mam nadzieję, że będzie to poważny krok w rozwoju i przygotowane przeze mnie (i nie tylko) zmiany się przyjmą do dalszego użytkowania. Pełna lista zmian będzie załączona do paczki. Najważniejsze zmiany to:
Niestety wprowadzone zmiany nie są w pełni zgodne wstecz. Większość animowanych modeli infrastruktury (zwrotniki, semafory kształtowe itp.) wymaga specjalnego oznaczenia, które submodele są w nich animowane. Optymalizacja submodeli daje wzrost FPS, ale w niektórych modelach pojawiają się problemy z nakładającymi się powierzchniami (np. podświetlenie migocze), co wymaga ręcznych poprawek w nich. Inaczej działające AI może w niektórych sceneriach powodować nieoczekiwane efekty uboczne.
Mam nadzieję, że niedogodności te zostaną naprawione w najbliższej paczce całościowej (na razie prace nad nią się nie rozpoczęły). Mam też nadzieję, że sukcesywnie będą udostępniane poprawki do sprawiających kłopoty modeli oraz scenerii.
Podziękowania należą się testującym, którzy znajdowali błędy i sygnalizowali problemy (Żabek, Siecool, EP08_015, Quark-t, surgeon, Krzysiek626, jochand, Patrykos, maacius, Sawi, Mati_An, motonita2002, youBy, libertyn89, ZiomalCl, WSK, Lorem, ISDR, Woku, przepioramarcin, szogun, Szociu), a także oddzielnie kolegom ZiomalCl oraz youBy, którzy opracowali i udostępnili poprawki do AI.
Uwaga! Przed użyciem EXE należy zapoznać się z treścią pliku tekstowego załączonego do paczki, aby nie zgłaszać na forum opisanych tam zmian i możliwych błędów. Paczka ma wielkość 450kB i zawiera zestaw plików E3D z poprawioną animacją submodeli (przygotował je Szociu). Wcześniejsze pliki E3D należy nadpisać tymi z paczki.
http://eu07.pl/userfiles/4245/EU07_212.7z
Pliki binarne modeli (E3D) są tworzone przy pierwszym uruchomieniu scenerii, a wzrost prędkości wczytywania będzie widoczny dopiero przy kolejnych uruchomieniach. Pliki E3D a także ewentualnie niepotrzebne już pliki T3D można usunąć najnowszą wersją Rainsted - na razie dostępną do testów.
Udostępniona wcześniej wersja 210 może nieprawidłowo przeliczać wektory normalne, przez co modele są nieprawidłowo oświetlane. Zostało również poprawione mapowanie chodników przy ulicach.
- Poprawione poruszanie się pojazdów: wyeliminowane urywanie wagonów, rezygnacja z "NULL track", rozprucie zwrotnicy bez przeskoku, mijanie się samochodów i statków, naprawiona obsługa przesunięcia w trainset, wstawianie pojazdów tyłem.
- Lepiej jeżdżące AI: reakcja na sygnały manewrowe, zatrzymywanie na W4 wg rozkładu wraz z odjazdem o podanej godzinie, zatrzymywanie na końcu toru, lepsze hamowanie (youBy), sygnały końca pociągu (ZiomalCl), poprawiona zmiana kierunku (ZiomalCl).
- Rozwinięte wsparcie dla sterowania ruchem: eventy rozprucia zwrotnicy, odcinki izolowane wyzwalające eventy zajęcia i zwolnienia grupy torów (można zrobić np. lepiej działające przejazdy), radio-stop, globalne wyzwalacze czasowe.
- Zwiększenie wydajności: automatyczna optymalizacja modeli, poprawione przeliczanie ruchu osi, specjalne traktowanie submodeli z jednostkowymi transformami, ignorowanie zbyt dużych trójkątów w modelach, działanie programu w tle (można korzystać z innego programu czekając na sygnał wolnej drogi).
- Szybsze wczytywanie scenerii: modele zapisywane w plikach binarnych, optymalizacja InitTracks i InitEvents.
Niestety wprowadzone zmiany nie są w pełni zgodne wstecz. Większość animowanych modeli infrastruktury (zwrotniki, semafory kształtowe itp.) wymaga specjalnego oznaczenia, które submodele są w nich animowane. Optymalizacja submodeli daje wzrost FPS, ale w niektórych modelach pojawiają się problemy z nakładającymi się powierzchniami (np. podświetlenie migocze), co wymaga ręcznych poprawek w nich. Inaczej działające AI może w niektórych sceneriach powodować nieoczekiwane efekty uboczne.
Mam nadzieję, że niedogodności te zostaną naprawione w najbliższej paczce całościowej (na razie prace nad nią się nie rozpoczęły). Mam też nadzieję, że sukcesywnie będą udostępniane poprawki do sprawiających kłopoty modeli oraz scenerii.
Podziękowania należą się testującym, którzy znajdowali błędy i sygnalizowali problemy (Żabek, Siecool, EP08_015, Quark-t, surgeon, Krzysiek626, jochand, Patrykos, maacius, Sawi, Mati_An, motonita2002, youBy, libertyn89, ZiomalCl, WSK, Lorem, ISDR, Woku, przepioramarcin, szogun, Szociu), a także oddzielnie kolegom ZiomalCl oraz youBy, którzy opracowali i udostępnili poprawki do AI.
Uwaga! Przed użyciem EXE należy zapoznać się z treścią pliku tekstowego załączonego do paczki, aby nie zgłaszać na forum opisanych tam zmian i możliwych błędów. Paczka ma wielkość 450kB i zawiera zestaw plików E3D z poprawioną animacją submodeli (przygotował je Szociu). Wcześniejsze pliki E3D należy nadpisać tymi z paczki.
http://eu07.pl/userfiles/4245/EU07_212.7z
Pliki binarne modeli (E3D) są tworzone przy pierwszym uruchomieniu scenerii, a wzrost prędkości wczytywania będzie widoczny dopiero przy kolejnych uruchomieniach. Pliki E3D a także ewentualnie niepotrzebne już pliki T3D można usunąć najnowszą wersją Rainsted - na razie dostępną do testów.
Udostępniona wcześniej wersja 210 może nieprawidłowo przeliczać wektory normalne, przez co modele są nieprawidłowo oświetlane. Zostało również poprawione mapowanie chodników przy ulicach.
80
Bieżące Symulatorowe / Testy ruchu AI
« dnia: 08 Lipca 2011, 17:37:36 »
Ostatnio znalazłem i usunąłem pewne błędy w ruchu AI, związane z funkcjonowaniem sprzęgów wirtualnych. Nie wiem jednak, czy są to wszystkie błędy, czy są jeszcze jakieś. Dlatego potrzebna będzie większa pomoc użytkowników MaSzyny w zakresie testów. Testowanie nie wymaga znajomości wpisów, konstrukcji scenerii czy taboru, wymaga natomiast czasu oraz znajomości scenerii oraz scenariuszy, w tym również ze starszych paczek (2004 i 2006).
Uwaga! Oprócz ruchu AI są zmienione są również inne drobne rzeczy i być może coś się nie będzie wyświetlać prawidłowo. Niemniej jednak można na to nie zwracać uwagi, gdyż najistotniejszą kwestią jest urywanie składów oraz reakcja AI na skład jadący z naprzeciwka po tym samym torze.
W przypadku wykrycia nieprawidłowej sytuacji należy ją opisać, podając nazwę paczki, nazwę scenerii, nazwę prowadzonego składu (ewentualnie wpisy składów, jeżeli zostały podmienione) oraz miejsce, w którym awaria nastąpiła, najlepiej z obrazkiem przedstawiającym. Należy również uruchomić kilka razy tę samą scenerię z identycznymi warunkami, aby sprawdzić, czy sytuacja się powtórzy. Najbardziej wartościowe są te sytuacje, które można powtórzyć.
Na koniec jeszcze jedna uwaga. Osoby nie zainteresowane testowaniem nie powinny używać tego EXE, ponieważ może ono powodować problemy, do których pomoc nie będzie udzielana. EXE będzie wstępnie przetestowane przez Betatesterów na okoliczność łatwych do zauważenia błędów.
Uwaga! Oprócz ruchu AI są zmienione są również inne drobne rzeczy i być może coś się nie będzie wyświetlać prawidłowo. Niemniej jednak można na to nie zwracać uwagi, gdyż najistotniejszą kwestią jest urywanie składów oraz reakcja AI na skład jadący z naprzeciwka po tym samym torze.
W przypadku wykrycia nieprawidłowej sytuacji należy ją opisać, podając nazwę paczki, nazwę scenerii, nazwę prowadzonego składu (ewentualnie wpisy składów, jeżeli zostały podmienione) oraz miejsce, w którym awaria nastąpiła, najlepiej z obrazkiem przedstawiającym. Należy również uruchomić kilka razy tę samą scenerię z identycznymi warunkami, aby sprawdzić, czy sytuacja się powtórzy. Najbardziej wartościowe są te sytuacje, które można powtórzyć.
Na koniec jeszcze jedna uwaga. Osoby nie zainteresowane testowaniem nie powinny używać tego EXE, ponieważ może ono powodować problemy, do których pomoc nie będzie udzielana. EXE będzie wstępnie przetestowane przez Betatesterów na okoliczność łatwych do zauważenia błędów.
81
Inne niekolejowe / Modelarstwo cyfrowe - miasta 3D
« dnia: 02 Lipca 2011, 17:02:09 »
A niektórzy nie mają co robić i modelują swoją okolicę. Tak na początek fragment Bytomia:
82
Tabor kolejowy / VT 63 aka SAx 90080
« dnia: 06 Czerwca 2011, 20:09:22 »
Tak mi się marzy zobaczyć takie cudo w symulatorze. W załączeniu schemat, to drugie to w zasadzie VT 62, który miał inny przód (pionowy), w razie potrzeby można się sugerować detalami boków, które są podobne. Jest dostępne kilka zdjęć w Internecie, jak również ze 2 filmy.
83
Publikacje / Ruchome niebo nocne
« dnia: 04 Czerwca 2011, 12:38:03 »
Postanowiłem udostępnić opracowany przeze mnie ruchomy model nocnego nieba. Nie jest on idealny, ale nie mam dalszych pomysłów na jego udoskonalenie. Model ten nie posiada tekstury, zamiast niej są animowane punkty świecące, załączające się, gdy jest ciemno. Wymaga EU07.EXE w wersji co najmniej 162, ale nie działa w trybie VBO (na kartach Intela). Pozycje gwiazd są zależne od aktualnej godziny (wpis time w scenerii) oraz od dnia w roku, ustawionego przez movelight (0 — pobierana data systemowa, 1÷365 — wskazany dzień w roku).
Przy symulacji za dnia model nie będzie widoczny — trzeba ustawić tak czas, aby jazda przynajmniej częściowo była w nocy. W momencie wschodu oraz zachodu Słońca występuje skokowa zmiana jasności światła. Zaobserwowano również wzrost FPS, gdy Słońce jest pod horyzontem — najprawdopodobniej z powodu mniejszej ilości świateł do przetworzenia.
Wpis do scenerii:
Poza tym, w pliku eu07.ini powinny się znaleźć wpisy:
http://eu07.pl/userfiles/4245/skystars.7z
Przy symulacji za dnia model nie będzie widoczny — trzeba ustawić tak czas, aby jazda przynajmniej częściowo była w nocy. W momencie wschodu oraz zachodu Słońca występuje skokowa zmiana jasności światła. Zaobserwowano również wzrost FPS, gdy Słońce jest pod horyzontem — najprawdopodobniej z powodu mniejszej ilości świateł do przetworzenia.
Wpis do scenerii:
Kod: [Zaznacz]
sky skystars.t3d endsky
atmo 0.423 0.702 1.0 1700 2000 0.70 0.80 0.9 endatmoPoza tym, w pliku eu07.ini powinny się znaleźć wpisy:
Kod: [Zaznacz]
movelight 0 //albo inna wartość 1÷365
doubleambient nohttp://eu07.pl/userfiles/4245/skystars.7z
84
Bieżące Symulatorowe / Co jest obecnie największą wadą MaSzyny?
« dnia: 21 Maja 2011, 17:14:12 »
W ostatnim czasie zrealizowałem bardzo wiele postulowanych zmian w EXE. Mimo to ich wykorzystanie pozostaje na niewielkim poziomie. Wiem, że dostosowanie modeli czy scenerii nie dokona się od razu. Jednak trudno mi pozbyć się wrażenia, że część rzeczy zrobiłem niepotrzebnie.
Aby można było lepiej ukierunkować prace, postanowiłem utworzyć ankietę. Oczekuję zgłaszania konkretnych propozycji, które będę sukcesywnie w niej zamieszczał. Propozycje zbyt ogólne (np. "grafika") nie będą uwzględniane. Ankieta będzie otwarta co najmniej kilka tygodni i będzie można zmienić swój głos w miarę pojawiania się kolejnych propozycji.
Aby można było lepiej ukierunkować prace, postanowiłem utworzyć ankietę. Oczekuję zgłaszania konkretnych propozycji, które będę sukcesywnie w niej zamieszczał. Propozycje zbyt ogólne (np. "grafika") nie będą uwzględniane. Ankieta będzie otwarta co najmniej kilka tygodni i będzie można zmienić swój głos w miarę pojawiania się kolejnych propozycji.
85
Publikacje / Starsze EXE wczytujące TGA
« dnia: 21 Maja 2011, 01:48:10 »
W związku z rezygnacją z użycia tekstur BMP na rzecz TGA pojawiła się konieczność dopisania w PC2010 jawnych rozszerzeń tekstur, aby starsze EXE nie szukały plików BMP. Rozwiązanie to ma taką wadę, że w przypadku użycia wymiennie tekstur TGA i DDS dla nowszych EXE, pliki T3D czy SCN z jawnymi rozszerzeniami TGA nie nadają się do wersji DDS.
Aby zaradzić zjawisku dublowania plików modeli i scenerii, przygotowałem modyfikację starszych EXE, polegającą na tym, że domyślnie przyjmowane jest rozszerzenie TGA zamiast BMP. W związku z powyższym nowo wydawane modele i scenerie nie będą musiały mieć oddzielnych wersji dla TGA i DDS.
http://eu07.pl/userfiles/4245/wersje_exe.7z
Zawartość paczki:
wersje_exe/stare_exe_621/eu07.exe
wersje_exe/exe_664kb/eu07.exe
wersje_exe/exe_699kb/eu07.exe
wersje_exe/exe_kursa_717/eu07.exe
wersje_exe/dizel_pack_735/eu07.exe
Uwaga! Powyższe pliki wykonywalne mogą wymagać podania innych charakterystyk taboru (CHK) niż udostępnione w ostatnich paczkach całościowych, a także pewnych zmian w sceneriach (deaktywacja obrotnic, usunięcie wpisów time, sky itd.). Również nie ma większego sensu uruchamianie ich na paczce DDS (chyba że ktoś napisze nakładkę, która będzie symulować wczytywanie plików TGA w oparciu o zawartość DDS). Zmiany publikuję głównie dla użytkowników paczki TGA, którzy będą chcieli korzystać z owych EXE po wgraniu do niej nowych dodatków, które nie będą posiadały jawnych rozszerzeń TGA. (Najnowsze EU07_162.EXE samo dobiera odpowiednie rozszerzenie na podstawie plików znalezionych na dysku.)
Aby zaradzić zjawisku dublowania plików modeli i scenerii, przygotowałem modyfikację starszych EXE, polegającą na tym, że domyślnie przyjmowane jest rozszerzenie TGA zamiast BMP. W związku z powyższym nowo wydawane modele i scenerie nie będą musiały mieć oddzielnych wersji dla TGA i DDS.
http://eu07.pl/userfiles/4245/wersje_exe.7z
Zawartość paczki:
wersje_exe/stare_exe_621/eu07.exe
wersje_exe/exe_664kb/eu07.exe
wersje_exe/exe_699kb/eu07.exe
wersje_exe/exe_kursa_717/eu07.exe
wersje_exe/dizel_pack_735/eu07.exe
Uwaga! Powyższe pliki wykonywalne mogą wymagać podania innych charakterystyk taboru (CHK) niż udostępnione w ostatnich paczkach całościowych, a także pewnych zmian w sceneriach (deaktywacja obrotnic, usunięcie wpisów time, sky itd.). Również nie ma większego sensu uruchamianie ich na paczce DDS (chyba że ktoś napisze nakładkę, która będzie symulować wczytywanie plików TGA w oparciu o zawartość DDS). Zmiany publikuję głównie dla użytkowników paczki TGA, którzy będą chcieli korzystać z owych EXE po wgraniu do niej nowych dodatków, które nie będą posiadały jawnych rozszerzeń TGA. (Najnowsze EU07_162.EXE samo dobiera odpowiednie rozszerzenie na podstawie plików znalezionych na dysku.)
86
Poradniki / [CTR] Rozkład jazdy
« dnia: 25 Kwietnia 2011, 02:56:49 »
Zabrałem się za analizę kodu wczytującego rozkład jazdy, więc opiszę tutaj, jak powinien być taki plik skonstruowany. W poniższym opisie przez słowo należy rozumieć ciąg znaków niezawierający białych znaków (spacja, tabulacja, nowa linia). Plik ten składa się ze słów, a podział na poszczególne wiersze jedynie zwiększa przejrzystość (mogło by być wszystko w jednej linijce). Również nie ma znaczenia ilość spacji czy szerokość kolumn (z wyjątkiem kolumny prędkości szlakowej, która może zawierać znacznik zmiany prędkości |_____|, z pięcioma podkreśleniami między kreskami pionowymi).
Przenoszę do poradników. @Stele
- Pierwsza linijka (górna ramka) powinna zawierać co najmniej 19 znaków podkreślenia. Zawartość linijek wcześniejszych będzie ignorowana, co oznacza, iż można dopisać w nich dodatkowe informacje.
______________________________________________________________ - Druga linijka musi się zaczynać otwierającym nawiasem kwadratowym [, a następnie musi być słowo Rodzaj, po nim wyszukiwana jest kreska pionowa |, a następnie jest nazwa pociągu, która musi być taka sama, jak nazwa pliku (inaczej błąd -7).
Pośrednio jest to przyczyną, że rozkłady nie mogą być umieszczone w podkatalogu scenerii.
[ Rodzaj i numer pociagu | TME4252 ] - Kolejne słowa są pomijane, aż do takiego, który zawiera _______| (7 podkreśleń i pionową kreskę — zwykle trzecia linijka). Ewentualnie można po pierwszej linii wstawić kolejne linie z dodatkowymi informacjami, o ile nie będą zawierały szukanego ciągu.
[________________________________________________|_____________] - W kolejnej linii oczekiwany jest otwierający nawias kwadratowy [, a za nim pionowa kreska luzem |, a za nią pierwsza miejscowość relacji. Nazwa nie może zawierać spacji.
[ | Koniewice ] - W kolejnej linii musi znajdować się słowo Relacja, a za nim pionowa kreska luzem |, po której jest druga miejscowość relacji (również bez spacji).
[ Relacja pociagu | Wielki_Kac ] - W kolejnej linii poszukiwane jest słowo Wymagany (oddzielenie poziome od relacji nie jest wymagane), a za nim znów pionowa kreska luzem |, po której następuje liczba zakończona znakiem %.
[________________________________________________|_____________]
[ Wymagany % ciezaru hamujacego | 106% ] - W kolejnej linii poszukiwane jest słowo Seria, a po pionowej kresce luzem | powinien być typ lokomotywy oraz liczba, oddzielone spacjami.
[________________________________________________|_____________]
[ Seria i obciazenie lokomotywy | EU07 234 ] - Kolejne linie są ignorowane, aż do znalezienia słowa zawierającego ciąg [______________ (kwadratowy nawias otwierający i 14 podkreśleń). Kolejne pozycje stanowią spis stacji, maksymalnie może być ich 100. Ostatni wiersz zawiera znacznik końca _|_ (pokreślenie, pionowa kreska, podkreślenie).
[________________________________________________|_____________] - Linijka stacji zaczyna się od kwadratowego nawiasu otwierającego [, jeśli go nie będzie, pojawi się błąd -4. Kolejne słowo może być kilometrażem, albo zawierać pionową kreską |. Jeśli ją zawiera, może też zawierać znacznik zmiany prędkości szlakowej |_____| (pionowa kreska, 5 pokreśleń, pionowa kreska). Jeśli nie ma tego znacznika, kolejne słowo powinno być pionową kreską albo prędkością szlakową (wtedy po niej dalsze słowa są pomijane aż do pionowej kreski). Kolejne słowo to nazwa stacji (również bez spacji). Następne słowa są pomijane, aż do znalezienia słowa 1 albo 2 — jest to ilość torów szlakowych. Dalej może być pionowa kreska albo czas przyjazdu w postaci HH.MM albo MM (z wyjątkiem pierwszej stacji). Następnie słowa są pomijane aż do pionowej kreski luzem (jak już była zamiast godziny, to musi być druga). Następne słowo to albo nawias kwadratowy zamykający, albo "czas jazdy do tej stacji w minutach".
[ 47.0 | | Koniewice 2 10.18 | ] - Dalsze słowa są ignorowane aż do nawiasu kwadratowego otwierającego. Jeśli kolejne słowo nie zawiera pionowej kreski, zostanie ono zignorowane i wzięte zostanie następne (czyli tu kilometraż już nie może być, a przynajmniej nie będzie mieć znaczenia). Może ono również zawierać wspomniany znacznik zmiany prędkości szlakowej. Jeśli nie, spodziewana jest prędkość szlakowa i pionowa kreska albo sama pionowa kreska. Następnie znajduje się zakodowana informacja o typie i wyposażeniu stacji (oddzielanie przecinkami). Kolejne słowa są ignorowane, aż do znalezienia 1 albo 2 (znaczenie j. w., nadpisuje poprzednie). Następnie jest pionowa kreska lub czas odjazdu — jeśli jest podany, wyliczany jest czas oczekiwania jako różnica do czasu przyjazdu zwiększona o 6 sekund. Kolejne słowa są pomijane aż do pionowej kreski, po której jest opcjonalnie "czas jazdy do tej stacji w minutach" (nadpisze poprzedni) albo nawias kwadratowy zamykający luzem.
[ | | R1,OT,S 2 | ] - Kolejne słowa są ignorowane aż do słowa zawierającego nawias kwadratowy otwierający. Jeśli nie zawiera ono znacznika końca _|_, to pod uwagę brane jest kolejne. Jeśli analizowane słowo nie zawiera kreski pionowej, to wczytywane jest kolejne (jakby znów pomijanie kilometrażu). Dalej jest identycznie jak w poprzednich dwóch linijkach — można podać prędkość szlakową albo znacznik zmiany prędkości. Następnie musi być słowo zawierające pionową kreskę, a następnie zawierające nawias zamykający (może być to samo). Cyfra i minusy to już raczej do ozdoby i żeby nie wygenerować znacznika końca podkreśleniami obok pionowej kreski.
[ | 90 |----------------------------------2--------|----] - Dalej mogą być informacje o kolejnych stacjach. Jeśli jednak słowo zawiera znacznik końca, to dalej już nie jest wczytywane, czyli można spokojnie dokleić jakieś objaśnienia.
[_______|_____|__________________________________2________|____]
Przenoszę do poradników. @Stele
87
Symulator / Światło nieba w ciągu roku
« dnia: 19 Lutego 2011, 17:58:46 »
Chciałbym poruszyć ten temat, ponieważ przymierzam się do ustawiania pogody w inny sposób, niż dotychczas. Zamiast podania wpisów na konkretne światło i mgłę, można by światło wyznaczać z podanego czasu oraz lokalnych warunków pogodowych. Współrzędne geograficzne można zignorować, chyba że zaczniemy robić zagraniczne scenerie…
Jeśli chodzi o Słońce, sprawa jest dosyć prosta, wystarczy znać godzinę oraz dzień roku. W przypadku Księżyca rok jest już istotny. Możliwości są dwie - albo wyliczamy pozycje i światło w czasie rzeczywistym, albo korzystamy z wstępnie przeliczonej tabelki światła.
W załączniku przykładowa tabelka wschodów i zachodów Słońca i Księżyca dla roku 2006. W poziomie przypada jeden piksel na 15 minut. Dane dla kolejnych dni są od dołu.
Nie uwzględnia ona zmiany koloru (zaczerwienienia) podczas wschodu i zachodu, gdyż nie znalazłem materiałów na ten temat. Być może da się to policzyć, można też próbować fotografować białą kartkę co kilka minut (oświetloną przez Słońce/Księżyc), mając balans bieli ustawiony w ciągu dnia.
Byłbym wdzięczny za wszelkie informacje na ten temat.
Jeśli chodzi o Słońce, sprawa jest dosyć prosta, wystarczy znać godzinę oraz dzień roku. W przypadku Księżyca rok jest już istotny. Możliwości są dwie - albo wyliczamy pozycje i światło w czasie rzeczywistym, albo korzystamy z wstępnie przeliczonej tabelki światła.
W załączniku przykładowa tabelka wschodów i zachodów Słońca i Księżyca dla roku 2006. W poziomie przypada jeden piksel na 15 minut. Dane dla kolejnych dni są od dołu.
Nie uwzględnia ona zmiany koloru (zaczerwienienia) podczas wschodu i zachodu, gdyż nie znalazłem materiałów na ten temat. Być może da się to policzyć, można też próbować fotografować białą kartkę co kilka minut (oświetloną przez Słońce/Księżyc), mając balans bieli ustawiony w ciągu dnia.
Byłbym wdzięczny za wszelkie informacje na ten temat.
88
Publikacje / EU07.EXE: 113, 120, 162
« dnia: 12 Lutego 2011, 00:10:47 »
Postanowiłem opublikować dotychczasowy zbór prac nad EXE Symulatora (wersja 1.2.77.113). Świadom jestem, że wiele rzeczy wymaga jeszcze dopracowania, np. wyświetlanie na kartach Intel, sieć trakcyjna, dźwięk turbo. Jednak obecnie nie mam wystarczająco dużo czasu, aby prace kontynuować – ciąg dalszy planuję na maj 2011. Z drugiej strony, udało mi się naprawić najbardziej palące problemy, takie jak błąd na kartach ATI, nadmiarowa animacja modeli czy niedziałająca animacja translate.
Również dodałem kilka zupełnie nowych pomysłów. Między innymi zwiększenie wydajności poprzez rezygnację z wyświetlania obiektów znajdujących się z tyłu kamery. Ma to niestety niepożądany efekt uboczny. Jeśli w scenerii są duże trójkąty terenu, może być widoczne znikanie fragmentu trójkąta, którego środek znajduje się dalej niż 500m z tyłu kamery. Przykładowo w TD.scn niektóre trójkąty mają boki po prawie 1700 m. Rozwiązanie z automatycznym podziałem trójkątów na mniejsze (bok do 300m) podczas wczytywania scenerii się nie sprawdziło.
Pełna lista zmian jest załączona w archiwum, proszę o zapoznanie się z nią. Zostały zachowane wszystkie zmiany z EU07_71.EXE, ich listę również dołączyłem. W przypadku uzasadnionych wątpliwości co do funkcjonowania wprowadzonych zmian, będę udzielał wyjaśnień w tym wątku. W paczce jest również plik smuga.tga, ponieważ tylko taka nazwa jest używana dla smugi, niezależnie od ustawienia domyślnego rozszerzenia.
http://eu07.pl/userfiles/4245/EU07_113.7z
UWAGA! Znany jest błąd występujący podczas przechodzenia między członami pojazdów wielosekcyjnych (opisany TU).Będzie on poprawiony w kolejnym wydaniu exe. Dla tego typu pojazdów, proszę używać wcześniejszej wersji exe.
14.02.2011. Quark-t
Błąd został naprawiony w EXE 120, do którego link znajduje się w następnym poście.
libertyn89
Również dodałem kilka zupełnie nowych pomysłów. Między innymi zwiększenie wydajności poprzez rezygnację z wyświetlania obiektów znajdujących się z tyłu kamery. Ma to niestety niepożądany efekt uboczny. Jeśli w scenerii są duże trójkąty terenu, może być widoczne znikanie fragmentu trójkąta, którego środek znajduje się dalej niż 500m z tyłu kamery. Przykładowo w TD.scn niektóre trójkąty mają boki po prawie 1700 m. Rozwiązanie z automatycznym podziałem trójkątów na mniejsze (bok do 300m) podczas wczytywania scenerii się nie sprawdziło.
Pełna lista zmian jest załączona w archiwum, proszę o zapoznanie się z nią. Zostały zachowane wszystkie zmiany z EU07_71.EXE, ich listę również dołączyłem. W przypadku uzasadnionych wątpliwości co do funkcjonowania wprowadzonych zmian, będę udzielał wyjaśnień w tym wątku. W paczce jest również plik smuga.tga, ponieważ tylko taka nazwa jest używana dla smugi, niezależnie od ustawienia domyślnego rozszerzenia.
http://eu07.pl/userfiles/4245/EU07_113.7z
UWAGA! Znany jest błąd występujący podczas przechodzenia między członami pojazdów wielosekcyjnych (opisany TU).
14.02.2011. Quark-t
Błąd został naprawiony w EXE 120, do którego link znajduje się w następnym poście.
libertyn89
89
Bieżące Symulatorowe / Jaką masz wersję OpenGL?
« dnia: 14 Stycznia 2011, 22:59:52 »
Ponieważ robię aktualnie poprawki w EXE, chciałbym się zorientować, na ile popularne są poszczególne wersje OpenGL. Otwórz plik log.txt, dziesiąta linijka powinna mieć zawartość "OpenGL Version:", a poniżej jest numer. Istotne są pierwsze dwie liczby.
Jeśli używasz MaSzynę na kilku komputerach (i chcesz to robić nadal), podaj najmniejszy z numerów.
« Dodano: 23 Stycznia 2011, 22:13:51 »
Na chwilę obecną w ankiecie są 92 głosy i kolejne przybywają już dosyć wolno. Pytanie zadałem, ponieważ przerabiam MaSzynę na VBO, które dostępne jest w OpenGL 1.5. Można powiedzieć, że 95% użytkowników nie będzie mieć z tym problemu. Wersję 1.1 zaznaczyłem sam, więc można tego nie liczyć. Posiadacz wersji 1.2 powinien się zacząć rozglądać za nową kartą graficzną. Natomiast jeśli ktoś ma 1.4, powinien w pierwszej kolejności sprawdzić, czy na początku logu (za linią "Supported Extensions:") pojawia się tekst GL_ARB_vertex_buffer_object. Jeśli tak, to można spać spokojnie. Jeśli nie, trzeba zaktualizować sterowniki karty graficznej. Jeśli aktualizacja sterowników nie jest możliwa lub nie spowoduje pojawienia się takiego tekstu, pozostaje szukanie nowszej karty graficznej.
Jeśli używasz MaSzynę na kilku komputerach (i chcesz to robić nadal), podaj najmniejszy z numerów.
« Dodano: 23 Stycznia 2011, 22:13:51 »
Na chwilę obecną w ankiecie są 92 głosy i kolejne przybywają już dosyć wolno. Pytanie zadałem, ponieważ przerabiam MaSzynę na VBO, które dostępne jest w OpenGL 1.5. Można powiedzieć, że 95% użytkowników nie będzie mieć z tym problemu. Wersję 1.1 zaznaczyłem sam, więc można tego nie liczyć. Posiadacz wersji 1.2 powinien się zacząć rozglądać za nową kartą graficzną. Natomiast jeśli ktoś ma 1.4, powinien w pierwszej kolejności sprawdzić, czy na początku logu (za linią "Supported Extensions:") pojawia się tekst GL_ARB_vertex_buffer_object. Jeśli tak, to można spać spokojnie. Jeśli nie, trzeba zaktualizować sterowniki karty graficznej. Jeśli aktualizacja sterowników nie jest możliwa lub nie spowoduje pojawienia się takiego tekstu, pozostaje szukanie nowszej karty graficznej.
90
Poszukuję, chcę zrobić / Zdjęcia na podpisy do pulpitu
« dnia: 10 Stycznia 2011, 15:13:30 »
Czy ktoś mógłby mi wskazać zdjęcia kabiny EU07 nadające się do wykonania fotoreplik podpisów pod przełącznikami na pulpicie do Symulatora? Ewentualnie udostępnić takie zdjęcia?