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.


Pokaż wątki - Ra

Strony: [1] 2 3 ... 5
1
Bieżące Symulatorowe / Do załatwienia na odchodne
« dnia: 25 Marca 2015, 12:20:32 »
Ponieważ jestem oskarżany o hamowanie rozwoju MaSzyny poprzez m.in. zbyt wielkie wymagania jakościowe, wprowadzanie niezrozumiałych i niepotrzebnych zmian oraz zmuszanie innych do syzyfowego poprawiania dawno skończonych scenerii, a także inne dziwne rzeczy, o których żal wspominać, jest to najprawdopodobniej ostatni rok mojego zaangażowania. Budzi to mój niesmak i coraz mniej mam ochotę w tym uczestniczyć.

Prosiłbym o wypisanie, co przez te ostatnie miesiące ewentualnie mógłbym jeszcze dokończyć, bo wiele rzeczy zacząłem, a na wszystkie na pewno nie wystarczy czasu. Chodzi mi głównie o drobiazgi, bo robienie np. sterowania na Ladder Diagram, czy obliczanie sieci trakcyjnej metodą potencjałów węzłowych wydają mi się zbyt pracochłonne i za mało atrakcyjne wizualnie, żeby warto było poświęcać im czas i to jeszcze własnym kosztem.

2
Bocznica / Odp: Odskakiwanie manipulatorów
« dnia: 21 Marca 2015, 10:22:53 »
Ja bym się za to zabrał, ale się boję, że znów będzie narzekanie, że robię niepotrzebne i niezrozumiałe zmiany według własnego widzimisię, przez co inni muszą poprawiać inne pliki, żeby działało jak poprzednio.
Wiadomości raportowane jako "nie na temat". Bocznica.
Sawi

3
Na warsztacie / Sterowanie ruchem z Rainsted
« dnia: 10 Marca 2015, 07:58:26 »
Po wstępnym dostosowaniu Linii 61 zabrałem się za naprawianie sterowania ruchem z Rainsted. Było to zaczęte w 2010 roku i poprawiane w 2011, ale potem leżało odłogiem.

Co jest potrzebne

1. Dwa komputery w sieci TCP/IP, w tym jeden ze stałym IP (może być lokalne), najlepiej z Windows. Można też testować na jednym komputerze, ale jest to uciążliwe. Podejrzewam, że obecnie to już chyba każdy ma jakiś drugi komputer, używany kilka lat wcześniej. Ten gorszy można użyć jako serwer ruchu (ze stałym IP), bo ma mniejsze wymagania sprzętowe.

2. Paczka MaSzyna 15.02 z wgraną ostatnią łatką, dostępną pod adresem eu07.pl/daily. Na komputerze z serwerem ruchu dobrze by przynajmniej było mieć zaktualizowany katalog scenery z paczki.

3. Zaktualizowany Rainsted, najlepiej w trybie dla trasopisarzy (od razu wczytuje wszystkie include bez parametrów i łączy tory przy wejściu na Podgląd terenu).

4. Plik scenerii bez zbędnych rzeczy, z którego będzie można utworzyć RSF dla serwera ruchu. Przykładowy plik dla Linii 61:
Kod: ("linia61.scn") [Zaznacz]
include linia61/l61_tory.scm end
include linia61/l61_sygnalizacja.scm end
include linia61/l61_drogi.scm end
include linia61/l61_hekto.scm end
Po wybraniu takiego pliku w Rainsted trzeba albo wczytać wszystkie include bez parametrów, połączyć tory i dowiązać semafory, albo włączyć tryb dla trasopisarzy i otworzyć Podgląd terenu, która to operacja wykona automatycznie wcześniej wypisane. Następnie należy wyeksportować scenerię do RSF. Dla poprawy prędkości wczytywania RSF dobrze by było jeszcze otworzyć edytor, wybrać utworzony plik RSF i zapisać go. Dzięki temu zostanie uaktualniony do najnowszej wersji struktury i nie będzie ta operacja powtarzana przy każdym uruchomieniu serwera (eksport zapisuje nieco starszą wersję niż edytor). Plik ten trzeba przekopiować albo utworzyć na komputerze z serwerem ruchu. Ja aktualnie testuję Linię 61, inne scenerie mogą wymagać pewnych drobnych zmian (np. nazwania wszystkich torów, przypisania semaforów, itp.). Nie zamieszczę gotowego pliku RSF, ponieważ na dniach mam zamiar wymienić nazwy rozjazdów i semaforów na zgodne ze schematami i po tej operacji trzeba będzie zrobić nowy RSF. Więc najlepiej zrobić sobie samodzielnie z ostatnio pobranej nakładki na paczkę i w razie pobrania nowszej nakładki powtórzyć tworzenie RSF.

Procedura uruchomienia

5. Na komputerze przeznaczonym na serwer ruchu uruchamiamy najnowszy Rainsted i z zakładki Ustawienia uruchamiamy serwer ruchu guzikiem po prawej. W otwartym oknie możemy wybrać zrobiony wcześniej plik RSF dla scenerii oraz zmienić port z domyślnego 42400 na inny. Następnie użyć przycisku Uruchom serwer. Serwer ma dwa tryby pracy, o czym poniżej — można wybrać tylko jeden.

6. Na komputerze z symulacją wybieramy scenerię — jeśli RSF będzie utworzony z Linii 61 w sposób opisany powyżej, to można wybrać dowolny z 8 scenariuszy. Co do innych scenerii, to nie mogę zagwarantować, że będą współpracować. Scenerię uruchamiamy bez wyłączania Rainsted. Po wczytaniu scenerii używamy przycisku Multiplayer na dole okna Rainsted i wpisujemy IP serwera oraz numer portu. Wpisane dane powinno dać się zapisać i wtedy nie będzie potrzeby ich ponownego wpisywania przy kolejnym uruchomieniu. Login i hasło są obecnie bez znaczenia. Istotny jest ptaszek przy Ponawiaj, ponieważ w razie błędu połączenia bądź rozłączenia z poziomu serwera wykona ponowne zalogowanie. W momencie logowania zapamiętywany jest numer okna symulatora — gdyby tam nadal było 0, to oznacza jakiś problem z oknami.

Dwa tryby pracy

Wspomniałem wcześniej o dwóch trybach pracy. Różnią się one sposobem współpracy z symulacją, a główną cechą jest liczba jednocześnie podłączonych użytkowników.

Pierwszy nazwałem Instruktor i jest tryb, w którym można uruchamiać normalne scenariusze. Na podglądzie serwera ruchu powinny być widoczne zajętości odcinków (tory rysowane kolorem czerwonym) oraz stany semaforów. Osoba obsługująca serwer ruchu może ingerować w działanie scenariusza — gasić semafory, zmieniać drogę przebiegu, podawać inne sygnały. Należy jednak znać działanie scenariusza i dokonywać zmian dopiero po tym, gdy uruchomią się mechanizmy scenariusza (inaczej to scenariusz poustawia rozjazdy i semafory). Ten tryb pozwala obsłużyć tylko jednego podłączonego użytkownika, ponieważ niemożliwy byłby jednoczesny podgląd stanu scenerii u wielu użytkowników na raz. Oprócz zabawy w dwie osoby tryb ten może być przydatny do eksperymentowania z modyfikowaniem scenariuszy, a także testowania scenariuszy w trakcie ich tworzenia.

Drugi tryb nazwałem Dyżurny i jest on przeznaczony do synchronizacji stanu urządzeń u wielu użytkowników. Używane scenerie powinny być raczej pozbawione scenariuszy, ponieważ mogą one wprowadzać chaos. W tym przypadku to osoba obsługująca serwer ruchu decyduje i ustawia rozjazdy oraz semafory. Zmieniony stan jest rozsyłany do wszystkich użytkowników i do czasu potwierdzenia urządzenie migocze kolorem białym ("brak kontroli", czyli u każdego użytkownika może być inny stan). Nowy użytkownik dostaje po zalogowaniu eventy przestawiające urządzenia, które są w stanie innym niż podstawowy (zakłada się, że po wczytaniu scenerii zwrotnice są na wprost, a semafory i tarcze zabraniają jazdy — z wyjątkiem SBL). Serwer ruchu pozwala synchronizować scenerie w zakresie urządzeń, czyli dany użytkownik jeździ jednym pociągiem, a pozostałe są prowadzone przez AI. Nie ma synchronizacji pozycji pojazdów, więc nie są możliwe interakcje pomiędzy użytkownikami (np. popych).

Z czasem pewnie będzie to ewoluować, być może nawet oba tryby da się połączyć w jeden (tzn. będzie podgląd stanu scenerii wybranego użytkownika). Być może z czasem dojdzie synchronizacja położenia pojazdów czy sterowania. Ale póki co do rozwiązania jest wiele innych problemów.

4
Symulator / Poziomy realistyczności scenerii
« dnia: 09 Marca 2015, 05:42:31 »
Ponieważ pojawia się pytanie, kiedy scenerię można uznać za realistyczną, chciałbym podzielić się moimi przemyśleniami na ten temat. Moim zdaniem, realistyczność może mieć kilka poziomów, czy też stopni.

0. Jako poziom odniesienia można przyjąć scenerię nierealistyczną w sensie "kompletnie błędną", która by nigdy w rzeczywistości nie powstała z powodu niezgodności z przepisami i braku sensu. Dobrym przykładem (o ile pamiętam) jest Transylwania, gdzie sąsiadujące na stacji tory nie są ze sobą nijak połączone.

1. Jako minimum realistyczności sceneria powinna mieć minimalny sens i zgrubną poprawność (błędy nie rzucające się w oczy). Taką scenerią jest np. Quark, gdzie układy torowe wyglądają niby sensownie, ale po głębszym zastanowieniu dochodzi się do wniosku, że jednak trzeba by je zrobić inaczej. Dalsze błędy to brak profilu pionowego, pętla, której nikt by nie zbudował i zbyt długie stacje.

2. Wyższym poziomem realistyczności jest np. Linia 053, na której stacje są wzorowane na rzeczywistych, a linia wydaje się mieć sens. Nie wiem, czy rozstawy torów itp. są prawidłowe, ale powiedzmy, że na tym poziomie nie muszą być.

3. Kolejny poziom osiągamy, gdy sceneria nadal jest fikcyjna, ale za to układy torowe są zrysowane z rzeczywistości, a profile pionowe są zrobione zgodnie z wytycznymi. Taką scenerią jest np. Tarniowo2.

4. Następny poziom jest wtedy, gdy modelowany jest rzeczywisty szlak, ale poziom błędów i niedokładności powoduje, że sceneria tylko nawiązuje do rzeczywistości. Tutaj można umieścić trasę Bochnia – Brzesko Okocim.

5. Wyższy poziom będzie, jeśli sceneria bardziej nawiązuje do rzeczywistości, a poziom błędów nie jest katastrofalny. Tu można zaliczyć Linię 61 w wersji do 2014 roku.

6. Kolejny poziom bym dał, jeśli sceneria zachowuje wymiary zgodne z mapą na tyle, że położenie poszczególnych obiektów można skonfrontować. Na tym etapie znajduje się sceneria Linia 61 obecnie, choć wymaga przerobienia stacji.

7. Dalszy poziom osiąga się, jeśli scenerię można odnieść do mapy bezpośrednio. Na tym poziomie znajduje się obecna wersja Manewrowo3, gdzie tory ułożone są z dużą dokładnością, a wszelkie inne obiekty (np. latarnie) można ustawić w konkretnych miejscach z dokładnością mniejszą niż pół metra.

8. Jeśli wszystko by już pasowało do mapy, ale byłyby jakieś błędy (np. niedokładny profil pionowy, braki specyficznych rozjazdów), osiągamy przedostatni poziom.

9. Ostatni poziom realistyczności byłby wtedy, gdy wszelkie urządzenia są rozmieszczone z dokładnością do 10cm, profil pionowy jest zgodny z dokumentacją/pomiarami, a błędy otoczenia nie są specjalnie zauważalne.

Użytkownik zwrócił uwagę, że piszemy Brzesko Okocim, a nie Brzesko – Okocim. Poprawiłem.
Benek

5
Na warsztacie / Modyfikacja linii 61
« dnia: 14 Lutego 2015, 18:05:29 »
Chciałbym poinformować, że prowadzę prace nad modyfikacją linii 61, mające na celu ustawienie przebiegu torów zgodnie z mapą. W paczce MaSzyna 15.02 są już częściowo przetworzone pliki — przygotowane do dalszych przekształceń. Między innymi została uporządkowana struktura wpisów w ośmiu klonach torów. Pozostałe obiekty (teren, sieć trakcyjną, zieleń, drogi) zintegrowali wcześniej koledzy przygotowujący paczkę.

Dziś wydzieliłem do osobnego pliku tory, które były identyczne w każdym klonie — stanowią one około 25% wszystkich torów. Zmieniłem też współczynniki tarcia na 0.15. Zmiany wykonałem na poziomie plików tekstowych. Bieżące prace może śledzić, pobierając archiwa spod adresu eu07.pl/daily/, zaczynające się od 877- (drugi człon to data ostatniego spakowania — należy wybrać plik z najnowszą datą). Paczki należy wypakowywać na czystą paczkę MaSzyna 15.02, z nadpisaniem wszystkich plików (można potem używać ten sam katalog MaSzyny do wgrywania kolejnych archiwów). Nowe paczki są tworzone automatycznie przed 6: rano, wyjątkowo dziś przygotowałem paczkę po ostatnich zmianach. Jeśli w paczce pojawi plik eu07.exe, to tej wersji należy używać do testów, gdyż wcześniejsze nie będą działać prawidłowo ze zmodyfikowanymi plikami scenerii (planowana jest zmiana sposobu powiązania eventów z torami, co będzie wymagać nowszej wersji EXE).

Podczas testów należy zwracać uwagę na przejezdność poszczególnych scenariuszy, w szczególności czy coś nie zostało uszkodzone względem poprzedniego stanu. Po uwspólnieniu torów przejdę do etapu przesuwania — wtedy przez kilka dni tory mogą nie być przejezdne, a w terenie pojawią się dziury i zakładki. Będzie to sukcesywnie usuwane. W przypadku znalezienia błędów proszę o jak najszybsze zgłaszanie, bowiem po kilku dniach sytuacja może już być inna. Jeśli będą widoczne poważne błędy w dużej ilości, to nie ma potrzeby ich zgłaszać, gdyż zapewne będzie to etap przejściowy prac i w krótkim czasie większość zostanie poprawiona.

  Dodano: 14 Lutego 2015, 19:03:26
Po przejechaniu któregoś ze scenariuszy na zmodyfikowanych plikach proszę o odpowiedź w tym wątku ze wskazaniem nazwy scenariusza oraz daty paczki, nawet jeśli żadne błędy nie będą widoczne. W przypadku błędów proszę o opis z podaniem miejsca, ewentualnie załączenie errors.txt, jeśli taki się wygeneruje. Jeśli jakieś pociągi będą stać w nieprawidłowych miejscach, proszę o zrzut ekranu w pobliżu pociągu, po dwukrotnym użyciu klawisza [F2] (z widoczną tabelką skanowania w kolorze zielonym). Będę też wdzięczny za zamieszczenie porównania z zachowaniem na poprzedniej paczce, ponieważ sam nie znam dobrze tych scenariuszy.

6
Symulator / Tablice kierunkowe dla taboru
« dnia: 03 Stycznia 2015, 15:32:34 »
Od wersji 460 EU07.EXE działa ustawianie tablic kierunkowych na taborze, które wykorzystuje obecny od dawna mechanizm czterech wymiennych tekstur. Działa to tak, że w momencie przypisania rozkładu do składu wydzielana jest nazwa stacji docelowej, a następnie dla każdego pojazdu w składzie jest wyszukiwana tekstura o takiej nazwie. Każdy pojazd szuka tekstury w swoim katalogu w dynamic, tak więc np. tablice muszą istnieć osobno dla EN57 oraz EN57-2000, gdyż mają one osobne katalogi.

W załączeniu są zmodyfikowane pudła EN57-2000 oraz przykładowe tekstury. W modelu T3D wyświetlacz musi być osobnym submodelem, aby dało mu się zmieniać teksturę podczas symulacji. Submodel ten musi mieć właściwość Map: -4, co oznacza wymienną teksturę numer 4. Pozostałe 3 wymienne tekstury są/będą dostępne z poziomu wpisów albo MMD. Również jeśli w taborze zostaną od razu użyte 4 wymienne tekstury, to czwarta nie będzie podmieniana rozkładem. Domyślnie tekstura wyłączonego wyświetlacza ma nazwę nowhere (pierwotnie chciałem użyć none, ale mogło by to konfliktować z rozwiązaniami zastosowanymi dla taboru bez wymiennych tekstur).

Jeśli w katalogu pojazdu jest kilka modeli różniących się wyświetlaczem, to tekstura o nazwie stacji powinna zawierać jednocześnie wszystkie wersje, a modele używać tylko odpowiedniego fragmentu z niej. Zapewne rozwiązanie będzie ewoluować w miarę rozpoznania potrzeb.

7
Tabor kolejowy / EUDDplus - europejski pulpit przyszłości
« dnia: 02 Listopada 2014, 02:30:39 »
Gdyby ktoś się zastanawiał, jaki pulpit zbudować sobie "na zaś"...

W Europie opracowano nowy pulpit sterowniczy dla pociągów towarowych i pasażerskich. Pulpit, w którym uwzględniono zaawansowane zasady ergonomii oraz zastosowano system elektroniczny z nowo opracowanym oprogramowaniem, stanie się integralną częścią nowej, kolejowej sieci transeuropejskiej (Trans-European Network, TEN).

Drogowy transport towarowy jest całkowicie zależny od paliw kopalnych i jest jednym z głównych źródeł emisji dwutlenku węgla (CO2). W ramach inicjatyw europejskich, takich jak Program Marco Polo, w celach polityki transportowej ujęto zmianę charakteru transportu towarowego z drogowego na bardziej przyjazne dla środowiska sposoby, takie jak transport kolejowy.

Jednym z kluczowych obszarów, w których dostępne są możliwości udoskonalenia pociągów, jest pulpit sterowniczy — interfejs człowiek-maszyna (MMI). Udoskonalenie oprogramowania w tym decydującym obszarze oraz ustandaryzowanie działania pulpitu przyniesie według szacunków zmniejszenie kosztów związanych z cyklem eksploatacji o 15%. W ramach finansowanego ze środków UE projektu "Wdrażanie koncepcji zaawansowanego europejskiego pulpitu sterowniczego — wspomaganie interoperacyjności" (Euddplus) opracowano wszechstronnie przetestowany pulpit sterowniczy o zharmonizowanej konfiguracji i elementach sterowania.

Na podstawie doświadczeń zgromadzonych we wcześniejszych projektach UE eksperci z dziedziny interfejsów człowiek-maszyna opracowali testy na symulatorach. Przeprowadzono próby terenowe, obejmujące działania transgraniczne, w których wzięli udział maszyniści pracujący dla kilku europejskich przewoźników, aby przetestować zalety pulpitu sterowniczego (testy przydatności). W celu przetestowania ergonomii pulpitu użyto system śledzący ruchy gałek ocznych, a na podstawie wyników sformułowano wymogi związane ze skupieniem uwagi oraz powody, dla których użytkownik musi wykonywać intensywny wysiłek umysłowy.

Nowy pulpit zapewnia kierującemu optymalne właściwości ergonomiczne. Prezentacja informacji dostosowana do sytuacji gwarantuje bezpieczne kierowanie pojazdem oraz pomaga zapewnić odpowiednie i adekwatne reakcje w niebezpiecznych lub niespodziewanych sytuacjach. Wszystkie części elektromechaniczne zastąpiono całkowicie elektronicznymi wyświetlaczami, które zwiększają niezawodność i bezpieczeństwo, a także obniżają koszty konserwacji.

Europejski system kolejnictwa skorzysta na tym na wiele sposobów. Ujednolicone procesy przyczynią się do zmniejszenia nakładów związanych ze szkoleniem maszynistów oraz do obniżenia kosztów w związku ze wszechstronnością personelu. Niższe koszty konserwacji zostaną zrealizowane dzięki zastosowaniu masowo produkowanych części zamiennych zamiast części maszyn dostosowanych do potrzeb kolejnictwa.

Stworzenie europejskiego pulpitu sterowniczego zaowocowało innowacyjną koncepcją pojazdu przeznaczonego zarówno dla transportu pasażerskiego, jak i towarowego. Transport kolejowy ma stać się bezpieczniejszą, tańszą, wydajniejszą oraz bardziej realną alternatywą w europejskim systemie transportowym.

Cały raport w PDF (język angielski).

8
Bieżące Symulatorowe / MaSzyna w porównaniu do Trainz Simulator 2010
« dnia: 28 Października 2014, 20:56:08 »
Znalazłem dziś taki film...

9
Bieżące Symulatorowe / Zdarzenia związane z siecią trakcyjną
« dnia: 22 Października 2014, 18:19:52 »
Zdarzenia związane z siecią trakcyjną obecnie w MaSzynie nie istnieją. Oryginalnie w Scenery.doc był opis zdarzenia CurrentEvent, wykonywany przy poborze prądu z sieci, jednak nie został on zrealizowany i nie wiadomo, do czego miał być używany (wczesna wersja przełączania zwrotnic tramwajowych?). Z drugiej strony mamy wskaźniki We — pomijając te informacyjne, istotne dla AI będą:
— We2 — nakaz opuszczenia pantografu, ograniczenie prędkości do 60km/h,
— We3 — podniesienie pantografu,
— We4 — zakaz wjazdu elektrycznych,
— We8 — jazda bez poboru prądu,
— We9 — możliwy pobór prądu.

Do powyższych przypadków proponował bym umieszczenie w torze eventu PutValues z komendą Overhead. Pierwszy parametr określałby znamionowe napięcie w sieci (np. 3000, -600, 15000, 25000) i jednocześnie zezwolenie na podniesienie pantografu. Wartość 0 oznaczałaby brak sieci (tożsamy z zakazem wjazdu elektrycznych). Drugi parametr regulowałby stan pantografu: >0 — opuszczenie pantografu i ograniczenie prędkości, 0 — przejazd bez pobierania prądu, -1 — można pobierać prąd. Czyli było by tak:
— We2 — Overhead 3000 60 — nakaz opuszczenia pantografu, wcześniej ograniczenie prędkości do 60km/h,
— We3 — Overhead 3000 -1 albo Overhead 3000 0 — możliwe podniesienie pantografu,
— We4 — Overhead 0 0 — zakaz wjazdu elektrycznych,
— We8 — Overhead 3000 0 — jazda bez poboru prądu,
— We9 — Overhead 3000 -1 — możliwy pobór prądu.

Ewentualnie, zamiast wartości 1 w drugim parametrze, można by podać zalecany pobór prądu w amperach (jeśli by to miało jakiś głębszy sens, bo zawsze może jechać kilka pociągów pod rząd i ograniczanie poboru w jednym nic nie da).

10
Bieżące Symulatorowe / Formaty plików dla symulatora
« dnia: 22 Października 2014, 17:02:34 »
Chciałbym zebrać informacje, co sądzicie o formatach plików. Istnieje kilka koncepcji, na ile formaty powinny być uniwersalne (z opisaną strukturą, obsługiwaną przez różnorakie programy narzędziowe), a na ile dedykowane (zoptymalizowane pod konkretne potrzeby).

1. Jeden ze skrajnych przypadków to używanie wyłącznie uniwersalnych formatów. W MaSzynie nigdy tak nie było, bo były używane własne formaty TEX oraz T3D. O ile jeszcze TEX dało się przerobić na TGA, to już T3D jest formatem dedykowanym. Nawet gdyby zamiast T3D używać pliki 3DS, to jeszcze pozostaje kwestia znalezienia uniwersalnego formatu dla plików scenerii (być może DXF by się nadawał), a także parametrów fizyki (obecnie FIZ i MMD). Używanie wyłącznie uniwersalnych plików ogranicza rozwój do aktualnie dostępnych opcji i uzależnia od możliwości programów narzędziowych obcego autorstwa. W praktyce ma sens chyba tylko w początkowej fazie rozwoju, gdy nie ma się jeszcze własnych programów narzędziowych i tworzy się coś w ramach silnika graficznego, bazującego na formatach uniwersalnych.

2. Maksymalizacja formatów uniwersalnych. Jest to przypadek z początków MaSzyny, gdy formaty dedykowane (SCN, T3D, CHK, MMD) były tam, gdzie było to potrzebne, natomiast większość plików była w formatach uniwersalnych (BMP, TGA, WAV). Można sobie też wyobrazić, że MaSzyna będzie kiedyś w stanie wczytać i obsługiwać formaty modeli z MSTS albo Trainz, które w takim kontekście będzie można uznać za uniwersalne.

3. Formaty optymalizowane. W MaSzynie się to zaczęło wraz z wprowadzeniem formatu DDS, a potem E3D. Format DDS jest co prawda formatem uniwersalnym, jednak z powodu stratnej kompresji nie nadaje się on do wtórnej edycji i oryginalny plik trzeba mieć w innym formacie (np. TGA). Z kolei E3D jest formatem dedykowanym, do którego obsługi nie powstały jeszcze narzędzia, i który nie do końca daje się przerobić wtórnie na T3D. Obydwa formaty przyczyniają się do przyspieszenia wczytywania scenerii i zwiększenia wydajności wyświetlania. Pliki E3D są tworzone po wczytaniu T3D i wykonaniu związanych z tym formatem obliczeń. Można też sobie wyobrazić wczytywanie formatu 3DS, po którym również będzie zapisywany plik E3D.

4. Jest jeszcze drugi skrajny przypadek, w którym istnieją wyłącznie optymalizowane pliki dedykowane, a pliki uniwersalne nie są używane wcale. Jest tak np. w przypadku użycia OpenSceneGraph, który po prostu zapisuje i wczytuje własne pliki, a opis ich struktury może nie istnieć. Podobnie jest w silniku graficznym Esenthel. Chcąc edytować cokolwiek, używa się albo dostarczonych z silnikiem graficznym narzędzi, albo istnieją metody konwersji na formaty uniwersalne (np. TGA, WAV). Praktycznie nierealne jest stworzenie własnych narzędzi bez wykorzystania kodu takiego silnika graficznego, ewentualnie edytować można zestaw własnych plików, które następnie konwertuje się w jedną stronę na potrzeby silnika graficznego (tak jak TGA na DDS). Dedykowane formaty teoretycznie zapewniają maksymalną efektywność, jednak próby samodzielnego wprowadzenia własnych modyfikacji mogą napotykać na trudności (podobnie jak np. nie ma sensu edycja plików DDS — trzeba się postarać o nieskompresowane TGA).

11
Bieżące Symulatorowe / Przejście na Blender (blender.org)
« dnia: 28 Sierpnia 2014, 13:31:42 »
Chciałbym rozpocząć dyskusję na temat przeorientowania rozwoju MaSzyny na Blender (edytor graficzny 3D). Dotychczas używany jest głównie 3ds Max, który jest dosyć drogim "frameworkiem", a bezpłatne wersje edukacyjne mają ograniczenia licencyjne. Z kolei GMax jest wczesną i okrojoną wersją 3ds Max, która ma swoje ograniczenia i nie jest dalej rozwijana. Scenerie można już w bardzo dużym stopniu edytować w Rainsted, czego efekty widać na Tarniowo2.

Na ile się zorientowałem, do Blendera można tworzyć wtyczki rozszerzające w języku Python. W pierwszej kolejności należało by zrobić możliwość eksportowania T3D, najlepiej razem z importowaniem.

12
Bieżące Symulatorowe / Budowa pulpitu w skali
« dnia: 05 Czerwca 2014, 04:52:24 »
Myślę o tym, aby sobie również zbudować pulpit, jednak chciałbym, aby nie był zbyt duży. Nie zależy mi na wiernym odzwierciedleniu wnętrza pojazdu ani nawet zachowaniu odległości. Istotna jest również kwestia transportu — miniaturowy pulpit można bez problemu zabrać ze sobą i komuś zademonstrować, a zrobi lepsze wrażenie niż uruchamianie symulacji z klawiatury. Mniejszy rozmiar to również mniejszy koszt, a także możliwość posiadania osobnych pulpitów dla kliku różnych pojazdów. Pierwszym krokiem jest wybór skali. Robiąc przegląd dostępnych w handlu przełączników ustaliłem, że minimalna wymiar obudowy to około 8mm (mniejsze są droższe). Z drugiej strony mamy lampki LS48, które można montować (1:1) w rozstawie 5cm i jest to chyba najmniejsza odległość, jaką trzeba uwzględnić. Myślę, że lepiej by było się zdecydować na jakąś jedną skalę niż próbować robić pulpity w kilku różnych.

1:6 — moim zdaniem najmniejsza sensowna skala. Jest popularna w modelarstwie (aczkolwiek głównie w figurkach o tematyce wojskowej, które są z kolei wypierane przez mniejsze/tańsze 1:8). Lokomotywa w tej skali miała by około 50cm szerokości (da się wsiąść), a tor normalny miały by rozstaw 24cm. Średnica nastawnika wyszła by około 7cm. Trzeba by używać najmniejszych dostępnych przełączników dźwigienkowych. Za to lampki LS48 można by modelować diodami świecącymi o przekroju kwadratowym i boku 5mm.

1:5.5 — tzw. skala X, znana też jako rozstaw szyn 10¼" (26cm), stosowana w miniaturowych kolejkach parkowych. Współczynnik podziału jest trochę mało okrągły, za to nadrabia popularnością, gdyby ktoś chciał zbudować model całej lokomotywy i coś z nim dalej robić.

1:5 — mniej popularna niż dwie powyższe, za to wygodny współczynnik podziału. Rozstaw normalny to 28.7cm, szerokość lokomotywy — ok. 60cm. Średnica nastawnika ok. 8cm.

1:4 — kolejny wygodny dzielnik, za to ze znikomą popularnością (14", 36cm).

1:3.7664 — czyli rozstaw 15" (38cm) — chyba najbardziej popularny z kolejek nadających się do jeżdżenia w terenie. Lokomotywa szerokości ok. 80cm, nastawnik — 11cm. To jest chyba największa skala, przy której nie ma jeszcze problemów z rozmiarami.

Przy większych skalach (1:3 czy 1:2) trzeba raczej zrezygnować z pełnej szerokości kabiny na rzecz ograniczenia się do najbardziej istotnej części pulpitu. A Wam — pomijając 1:1 — jaka skala by najbardziej odpowiadała?

13
Forum / Kolekcja fajnych tekstów, czyli polska język trudna
« dnia: 23 Kwietnia 2014, 22:27:24 »
Będę sobie tu zbierał specyficzne teksty. Niestety, forum nie ma guziczków "Lubię to".

Cytuj
kiedy kol wiek
Cytuj
ja poczekam na serowanie myszą
Cytuj
Wgl Cb nie rozumiem bo masz jak wół napisane żeby dać tu $.scn i nie dajesz.
Cytuj
Może masz coś na mieszane?

14
Symulator / Naprawianie sieci trakcyjnej
« dnia: 02 Kwietnia 2014, 15:11:17 »
Po wprowadzeniu współpracy odbieraka z siecią trakcyjną okazało się, że wiele scenerii ma nieprawidłowo rozmieszczoną sieć. Błędy te powodują, że pantograf wysuwa się na bok poza drut. Jeśli przerwa jest niewielka, rozłączy się jedynie wyłącznik szybki, a pantograf zdąży "wejść" pod kolejny drut, zanim się podniesie zbyt wysoko. Jeśli jednak przerwa jest większa, a pantograf podniesie się wyżej niż 15cm, to zostanie połamany. Innym przykładem błędu jest zbyt duża różnica wysokości zawieszenia drutu ponad rozjazdami, która nie powinna przekraczać 3-5cm, a dochodzi do 20cm.

Układy torowe na sceneriach mamy na tyle kiepskiej jakości, że nie ma sensu przykładać dużej uwagi do precyzyjnego zawieszenia sieci. Wystarczające będzie przesunięcie końców przęseł na tyle, żeby pantograf nie spadał. Sposób poprawienia zależy od rodzaju błędu.

1. Na łuku, poprawienie danego miejsca sprowadza się do ustalenia współrzędnych "słupa", a następnie przesunięcia o 0.3 wzdłuż jednej z osi. Przynajmniej tak robiłem na Quarku i uważam to za wystarczające. Przykład:
Cytat: przed zmianą było -6011.36
node 800 0  none traction pwr01 3500 4500 0.01 al 3.0 1
-6026.99 -6.39999 9597.5
-6011.36 -6.39999 9549.8
-6026.99 -4.69999 9597.5
-6011.36 -4.69999 9549.8
0.6 4.0 3 0.04 vis
endtraction
include tr/l-stb1-3k.inc -6011.36 -6.39999 9549.8 158.995 betonrelief1 end

node 800 0  none traction pwr01 3500 4500 0.01 al 3.0 1
-6011.36 -6.39999 9549.8
-5990.55 -6.39999 9503.68
-6011.36 -4.69999 9549.8
-5990.55 -4.69999 9503.68
0.6 4.0 3 0.04 vis
endtraction
include tr/l-stb1-3k.inc -5990.55 -6.39999 9503.68 153.264 betonrelief1 end
Cytat: zmiana na -6011.06, w pięciu miejscach
node 800 0  none traction pwr01 3500 4500 0.01 al 3.0 1
-6026.99 -6.39999 9597.5
-6011.06 -6.39999 9549.8
-6026.99 -4.69999 9597.5
-6011.06 -4.69999 9549.8
0.6 4.0 3 0.04 vis
endtraction
include tr/l-stb1-3k.inc -6011.06 -6.39999 9549.8 158.995 betonrelief1 end

node 800 0  none traction pwr01 3500 4500 0.01 al 3.0 1
-6011.06 -6.39999 9549.8
-5990.55 -6.39999 9503.68
-6011.06 -4.69999 9549.8
-5990.55 -4.69999 9503.68
0.6 4.0 3 0.04 vis
endtraction
include tr/l-stb1-3k.inc -5990.55 -6.39999 9503.68 153.264 betonrelief1 end

2. Zbyt duża różnica wysokości drutu na naprężaniu powoduje wywalenie WS, a nad nad zwrotnicami wjechanie pantografem ponad drut. W tym przypadku trzeba zmienić wysokość zawieszenia drutu. Przykład:
Cytat: przed zmianą było 6.0
node -1 0 none traction dej_pwr01 3500 4500 0.01 al 3.0 1
-2244.21 6.4 7450.42
-2243.5 6.0 7489.12
-2244.21 7.2 7450.42
-2243.5 7.45 7489.12
1 10 3 0.04 vis
endtraction
include tr/-p-okk.inc -2243.5 6.0 7489.12 1.20056 wys-ni-kotwk end

node -1 0 none traction dej_pwr01 3500 4500 0.01 al 3.0 1
-2243.5 6.0 7489.12
-2244.18 5.8 7539.8
-2243.5 7.45 7489.12
-2244.18 7.5 7539.8
0.8 4.0 3 0.04 vis
endtraction
include tr/l+zwis1d-3d.inc -2244.18 5.8 7539.8 -0.876038 #zwis1 end
Cytat: zmiana na 5.9 w trzech miejscach plus dodatkowo w dwóch obniżenie liny nośnej
node -1 0 none traction dej_pwr01 3500 4500 0.01 al 3.0 1
-2244.21 6.4 7450.42
-2243.5 5.9 7489.12
-2244.21 7.2 7450.42
-2243.5 7.35 7489.12
1 10 3 0.04 vis
endtraction
include tr/-p-okk.inc -2243.5 5.9 7489.12 1.20056 wys-ni-kotwk end

node -1 0 none traction dej_pwr01 3500 4500 0.01 al 3.0 1
-2243.5 5.9 7489.12
-2244.18 5.8 7539.8
-2243.5 7.35 7489.12
-2244.18 7.5 7539.8
0.8 4.0 3 0.04 vis
endtraction
include tr/l+zwis1d-3d.inc -2244.18 5.8 7539.8 -0.876038 #zwis1 end

3. Czasem końce przęseł się nie stykają. Wtedy trzeba znaleźć w plikach oba końce oraz słup, a następnie ujednolicić im współrzędne. Dobrze się to uwidacznia już po podłączeniu zasilania, ale to jest już kolejny etap ulepszania sieci.

4. Czasem przęsła są zdublowane, wtedy nadmiarowe trzeba usunąć. Mogą się uwidocznić po wykonaniu pierwszych przesunięć albo dopiero po podłączeniu zasilania. Jednak te błędy rzadko mają wpływ na łamanie pantografu.

5. Czasem trzeba słup przesunąć o więcej niż 0.3m. Miałem taki przypadek nad łukiem o promieniu 300m w głowicy stacyjnej. Słup trzeba wtedy ustawić w okolicy wierzchołka kąta tworzonego przez tory proste. Na Quarku było jedno takie miejsce, chyba przesuwałem słup o jakieś 10m. Modyfikowałem te współrzędne kilka razy, zanim pantograf zaczął przechodzić bez problemu. Oczywiście sprawa się komplikuje, jeśli po przestawieniu słupa znajduje się on np. na środku drogi. Wtedy trzeba podejść do tego bardziej kreatywnie, np. dodać dodatkowe przęsło i słup.

Przyklejam.
Quark-t

15
W związku z kwestią faz LoD dla modeli i koniecznością dobierania odległości przejścia tak, aby nie były one zauważalne, ustalić trzeba, przy jakiej rozdzielczości pionowej powinno to być testowane. Proszę o zaznaczenie w ankiecie najczęściej używanej rozdzielczości pionowej. Chodzi o rozdzielczość wybieraną do uruchomienia MaSzyny (niekoniecznie maksymalną sprzętu).

  Dodano: 31 Marca 2014, 01:07:53
Myślę, że przy 54 głosach wyniki są już jednoznaczne i nie zmienią się znacząco: rozdzielczość 768 jest najczęściej występującą (~30%) i najbardziej dostępną (~96%). To znaczy, że odległości przechodzenia faz LoD należy dobierać przy rozdzielczości pionowej 768 (czyli np. 1024×768, 1366×768, opcjonalnie 1280×800), przy wyłączonym multisamplingu. Rozdzielczość ta zostanie przyjęta jako bazowa do przeliczania odległości widoczności obiektów (zarówno przy większej rozdzielczości jak i przy włączonym multisamplingu).

16
EU07 Simulator English forum / Subtitles for MaSzyna sounds
« dnia: 19 Lutego 2014, 20:59:46 »
Since version 427 of EU07.EXE it is possible to add subtitles in any language to sounds played by MaSzyna. This mainly concerns sounds like radio conversation with traffic control or train stuff. For every WAV sound a TXT file can be created. After the minus sign a language code must be placed, default is pl. E.g for radio25.wav the subtitles can be radio25-pl.txt for Polish, radio25-en.txt for English or radio25-es.txt for Spain. The language suffix is defined in eu07.ini file, after lang keyword.

The text files are in MPL2 format, that is very popular in Poland as subtitles for movies. The timing is based on 0.1s intervals. Start and end time are placed in square brackets, so the [123][456] means showing message from 12.3 to 45.6 seconds of the sound. In case the brackets are missed, subtitle will be shown all the time when sound is played. For long sentences, a vertical line | can be used to split sentence into lines. Also, slash / can be used as the first character of text line to use italics, what means unimportant background speaking (this is still not supported, so the slash is shown directly). Example:
Kod: (sz_wygaslo-en.txt) [Zaznacz]
[11][28]I'm giving you a substitute signal. Did it fade?
[35][49]Yes it did.
[58][70]Substitute granted.
[72][85]I see it, I'm gonna drive on.

If you would like to test the feature or create subtitles for your language, please contact me via PM or in this topic. We are in progress with English translation.

17
Bieżące Symulatorowe / Eksperyment z łatką binarną
« dnia: 05 Lutego 2014, 18:45:42 »
Korzystając z okazji chciałbym przeprowadzić eksperyment ze stosowaniem łatek binarnych. Do jego zastosowania niezbędny jest malutki programik bspatch.exe. Program jest do pobrania ze strony autora:
http://sites.inka.de/tesla/others.html#bsdiff
albo z bezpośredniego linku (wersja pod Windows – 73kB):
http://sites.inka.de/tesla/download/bsdiff4.3-win32.zip

W załączniku znajduje się spakowany pliczek EU07_424.exe.bsdiff. Należy go wypakować wraz z wyżej wymienionym archiwum do głównego folderu MaSzyny, a następnie z linii poleceń wykonać:bspatch EU07_424.exe EU07_424a.exe EU07_424.exe.bsdiffNałożenie tej łatki powinno naprawić otwieranie drzwi w EZT, jeśli do uruchomienia scenerii użyje się zmodyfikowanego pliku. Jeśli eksperyment się powiedzie, to będzie można taką funkcjonalność wbudować w Rainsted i udostępniać np. poprawki modeli czy tekstur w formie bardzo krótkich łatek. Jednym z problemów do rozpoznania jest nałożenie łatki na nieodpowiednią wersję pliku. Już teraz widzę, że możliwe jest podanie tej samej nazwy jako plik pierwotny i wynikowy, a wielokrotne nałożenie łatki daje w takim przypadku za kolejnym razem inną zawartość pliku wynikowego. Bezpieczniej by było, gdyby w łatce zapisane były np. CRC32 pliku sprzed i po modyfikacji, a program by zgłaszał błąd w przypadku niezgodności.

18
Publikacje / EU07.EXE, wersja: 424
« dnia: 04 Lutego 2014, 01:52:37 »
Po ponad roku prac nad kodem (o zmiennej intensywności) udostępniam kolejną wersję EU07.EXE, tym razem oznaczoną numerkiem 424 (dokładniej 14.2.929.424).

Najważniejsze zmiany, z którymi należy się zapoznać, aby np. nie zgłaszać ich jako błędy:
  • Zintegrowany kod z Megapacka, w szczególności wymagane jest załączenie baterii przez [Shift]+[J].
  • Zmieniony sposób animacji pantografów, więc w niektórych lokomotywach pantografy będą ustawiały się nieprawidłowo względem drutu. Modele te będą wymagały poprawienia, albo przynajmniej trzeba im ustawić parametry w MMD.
  • Zmieniony sposób uruchamiania lokomotywy, w szczególności jeśli jest za mało powietrza, by podnieść pantografy.
  • Zmienione działanie sieci trakcyjnej. Błędy rozwieszenia sieci w sceneriach będą powodowały wyłączanie wyłącznika szybkiego albo nawet połamanie pantografu.
  • Zmieniony sposób sterowania EN57, konieczna jest poprawka do plików FIZ.

Szczegółowy opis zmian znajduje się pod adresem:
http://rainsted.com/pl/Symulator/MaSzyna/EU07.EXE_424
niemniej niektóre zmiany zostały opisane na innych stronach:
http://rainsted.com/pl/Symulator/MaSzyna/Mega_Pack_KURS%27a_90
http://rainsted.com/pl/Symulator/MaSzyna/EU07.EXE_Kurs_2013
http://rainsted.com/pl/Symulator/MaSzyna/EU07.EXE_414

Z jednej strony jest to najlepsza wersja ze wszystkich, jakie dotychczas się pojawiły, a z drugiej strony można by nad tym siedzieć i kolejny rok, a zawsze pozostanie coś fajnego do zrobienia dodatkowo. Testy w zamkniętym gronie nie wykazują już poważnych błędów, przyszedł czas na testy otwarte. Myślę, że za parę miesięcy pojawi się kolejna wersja, uwzględniająca zgłoszone przez ten okres uwagi, a być może będzie też zawierała jakieś nowości. Mam cichą nadzieję, że do tego momentu zostaną również poprawione błędy w modelach i sceneriach, a nowe dodatki będą prawidłowo działały na niniejszej wersji.

W załączonej paczce znajdują się:
- nowe EU07.EXE
- sceneria TD z możliwością zmiany napięcia zasilającego przez [Shift]+[5] do [Shift]+[7]
- poprawione pliki FIZ i MMD dla EZT z paczki MaSzyna 08.13

19
Symulator / Ladder Diagram (LD), czyli zapis schematów
« dnia: 23 Stycznia 2014, 01:09:21 »
Chciałbym zaproponować sposób zapisu schematów sterowania lokomotyw (docelowo również np. urządzeń przekaźnikowych) w pliku tekstowym, w języku Ladder Diagram (LD albo LAD, czyli logika drabinki) na użytek MaSzyny.

Plik powinien się zaczynać od definicji zmiennych binarnych (tzn. przyjmujących stan 0 albo 1), reprezentujących stan przełączników, lampek oraz warunków opisanych analogowo (np. U>2200[V] by reprezentowało minimalne napięcie pozwalające na załączenie wyłącznika szybkiego). Docelowy format nie został jeszcze określony, na razie proponuję wypisać nazwy występujące na schematach, a po dwóch ukośnikach // dać opis.

Właściwy schemat będzie opisany za pomocą "słów", rozdzielonych spacjami. Na słowa składają się wieloznakowe symbole oraz wymienione wcześniej zmienne binarne. Zestaw symboli:
Styk
zwierny
Styk
rozwierny
Opis
LD-[LD-[/Pierwsze wejście szczebla drabinki
]-[]-[/Kolejne wejście, połączenie szeregowe
]-(]-(/Wyjście (jako ostatni element szczebla)
)Koniec szczebla drabinki
]-Nazwa węzła (odczep do innego szczebla)
-[-[/Koniec nazwy węzła, kolejne wejście
-(-(/Koniec nazwy węzła, wyjście
]+]+/Połączenie równoległe wejścia
+[+[/Kolejne wejście szeregowo

Styk zwierny: styk normalnie otwarty, zamykany po załączeniu przełącznika albo stycznika.
Styk rozwierny: styk normalnie zamknięty, otwierany po załączeniu przełącznika albo stycznika.
W miarę potrzeby będą definiowane kolejne typy wejść i wyjść, np. ze zwłoką czasową.

Przykład:S1 //przełącznik 1
S2 //przełącznik 2
S3 //przełącznik 3
S4 //przełącznik 4
K1 //kontrolka 1
K2 //kontrolka 2
Z1 //połączenie równoległe

LD-[ S1 ]-[ S2 ]- Z1 -( K1 )
LD-[/ S3 ]+ Z1 +[ S4 ]-( K2 )
W powyższym przykładzie kontrolka K1 zapali się po zamknięciu przełączników S1 oraz S2. Jednocześnie zmienna Z1 będzie miała ten sam stan, co kontrolka K1. Kontrolka K2 zapali się, gdy będzie zamknięty przełącznik S4 oraz będzie otwarty przełącznik S3 lub zamknięte będą S1 i S2 (poprzez Z1).


Jest to pierwsza wersja, która zapewne będzie podlegać zmianom.

20
Bieżące Symulatorowe / Konwencja odwołań do submodeli
« dnia: 05 Stycznia 2014, 13:47:01 »
Potrzeba taka występuje w paru przypadkach, jednak obecnie jest to potrzebne dla eventu wykonywanego po zakończeniu animacji submodelu. Niby można równocześnie z uruchomieniem animacji modelu dodać do kolejki event z odpowiednim opóźnieniem, ale trzeba to opóźnienie dobrać lub policzyć, co się nie sprawdza, jeśli istnieje możliwość przedłużenia lub zmiany kierunku animacji.

Przykładowo, czas ruchu obrotnicy zależy od jej aktualnego i docelowego położenia, a do tego obsługując obrotnicę ręcznie można zadać jej nową pozycję zanim osiągnie poprzednio zadaną. Wyliczanie z góry czasu trwania tego ruchu było by dosyć karkołomne. Podobna sytuacja jest w przypadku zapór, które mogą być opuszczone zaraz po lekkim podniesieniu, albo ponownie podniesione, gdy już rozpoczęto ich opuszczanie.

Dlatego wczoraj dodałem opcję generowania eventu po zakończeniu animacji. Event ten jest generowany przez submodel, który podlega animacji. Ponieważ w modelu może być wiele animowanych submodeli, nazwa eventu musi zawierać nazwę modelu oraz nazwę submodelu. Na początek utworzyłem nazwę o postaci model.submodel:done, gdzie "model" oraz "submodel" są odpowiednimi nazwami obiektów, a ":done" jest końcówką związaną z zakończeniem animacji. Niemniej równie dobrze mogła by być używana nazwa submodel@model:done albo model->submodel:done.

Być może ktoś ma lepsze propozycje, to dodam je do ankiety.

21
Bieżące Symulatorowe / Mapowanie trawy
« dnia: 15 Listopada 2013, 03:26:41 »
Mam problem z mapowaniem terenu teksturą trawy. Chciałbym, aby sposób mapowania terenu został ujednolicony i aby było jasne, jak nakładać teksturę. W różnych sceneriach spotkałem się z różnymi długościami powielania tekstury. Przykładowo, w Quarku i Tarniowie jest to 2.5m, z kolei 10m było w Testowie. Wydaje mi się, że powtarzanie 5m też widziałem. Chodzi mi o teksturę typu grass.

Na razie roboczo przyjąłem, że najlepsze będzie mapowanie na 5m. Ewentualnie do zaakceptowania jest 10m. Mapowanie na 2.5m wydaje mi się zbyt gęste i za bardzo widać wzorki na trawie. Jeśli ktoś ma jakieś argumenty, to chętnie się z nimi zapoznam. O ile dobrze kojarzę, Trainz przeszedł z siatki 10m na 5m około 2009 roku.

22
Inne niekolejowe / Automatyka dla maniaków
« dnia: 06 Listopada 2013, 23:39:49 »
Gdyby ktoś przypadkiem zainteresował się programowaniem automatyki, to uprzedzam, że produkty firmy Siemens są dla ambitnie cierpliwych. W załączeniu jeden z kwiatków, a spotykam się z problemami tego typu już któryś raz...

23
Bieżące Symulatorowe / Czy eventy losowe działają?
« dnia: 02 Listopada 2013, 04:39:03 »
Chciałem zrobić zdarzenia losowe w Quarku. Jednak gdy uruchamiałem scenerię kilkukrotnie, za każdym razem "losowała" mi się wartość 0.28 jako pierwsza i 0.8967 jako druga. Wygląda na to, że zamiast wartości "losowych" mamy stały ciąg liczb przy każdym uruchomieniu. Nie korzystałem wcześniej ze zdarzeń losowych, więc wiem, czy to w ogóle działało. Czy ktoś ma jakieś doświadczenie w tym zakresie? Czy były jakieś wersje EXE, na których przy każdym uruchomieniu był inny ciąg liczb? Czy może tylko u mnie się to tak dziwnie robi?

24
Wydział zamówień / Znaki drogowe
« dnia: 01 Listopada 2013, 22:15:50 »
Robiąc przekop koło Mydelniczki poprowadziłem drogę wzdłuż toru. Chciałbym poustawiać na niej znaki drogowe, bo będą widoczne z toru. Jednak nie bardzo jest co. Ze znaków mamy tylko serię G (i to w kiepskiej jakości). Przydało by się zrobić minimum kilkudziesięciu najczęściej spotykanych znaków. Dobrze by było, gdyby ktoś zajął się znakami drogowymi, zamiast robić kolejną teksturę EU07...

W zakresie tekstur możliwe są 3 rozwiązania:
  • Tekstura każdego znaku w osobnym pliku. Jest to najbardziej elastyczne rozwiązanie, gdyż zawsze można dodać bądź wymienić plik. Można też tworzyć dowolną liczbę wariantów uszkodzonych znaków. Zaletą tego rozwiązania jest łatwość utworzenia nowego znaku, gdyż modele będą wspólne. Wadą jest duża liczba plików tekstur.
  • Tekstura zbiorcza regularna. Połączenie tekstur pojedynczych znaków w większą teksturę poprawi wydajność, zwłaszcza jeśli na teksturze umieści się najczęściej spotykane znaki. Wadą tego rozwiązania jest konieczność tworzenia osobnych modeli, ponieważ każdy będzie zamapowany inaczej (innym fragmentem tekstury). Regularność tekstury (np. siatka 8×8 znaków) pozwoli na względnie łatwe zmodyfikowanie modelu, poprzez dodanie stałych do współrzędnych mapowania (można modele tworzyć generatorem).
  • Tekstura zbiorcza upakowana. W tym przypadku powierzchnia tekstury ma być maksymalnie wykorzystana, łącznie z odwracaniem w pionie trójkątnych znaków oraz użyciem mniejszej rozdzielczości dla znaków o prostszym rysunku. Pozwoli to na zmniejszenie liczby tekstur, kosztem zwiększenia liczby modeli, gdyż dla każdego znaku trzeba będzie indywidualnie dopasowywać mapowanie. Jeśli modele znaków były by łączone w ramach sektora, zwiększyło by to wydajność. Jednak przygotowanie takiej tekstury będzie wymagać starannej selekcji znaków i ręcznego przygotowania mapowania modelu dla każdego z nich.
Myślę, że trzeba będzie zacząć od rozwiązania 1, ale myśleć o docelowym zastosowaniu rozwiązania 2 albo 3. Ponadto należy uwzględnić, że znaki w innych krajach mogą wyglądać inaczej (np. słowackie są zauważalnie inne niż polskie), dlatego trzeba przewidzieć podkatalogi na poszczególne kraje. Dobrze by było przyjąć, że na jeden znak będzie przypadać kwadratowa tekstura o boku będącym całkowitą potęgą liczby 2, np. 64 albo 128 pikseli (łącznie z niewielkim marginesem).

Oprócz oznakowania pionowego, przydały by się również tekstury dróg z oznakowaniem poziomym, w szczególności potrzebne są linie zatrzymania na przejazdach kolejowych.

25
Symulator / Klatki na sekundę (FPS)
« dnia: 08 Sierpnia 2013, 03:59:37 »
Ponieważ w wątku dotyczącym modyfikacji Tarniowa pojawiło się pytanie o wydajność po zmianach, chciałbym pokrótce przybliżyć ten temat, gdyż może nie wszyscy śledzą listę zmian w EU07.EXE.

1. Rozmiar scenerii nie ma wpływu na FPS. Niezależnie od tego, jak wielka jest powierzchnia scenerii, nieużywane jej fragmenty jedynie zajmują miejsce w pamięci, ale nie są przetwarzane. Sceneria jest zorganizowana w dwuwymiarową mapę, a do wyświetlania są kwalifikowane tylko te obiekty, które znajdują się w bezpośredniej okolicy kamery użytkownika. FPS bardziej zależy od liczby i skomplikowania tych najbliższych obiektów, a także od ogólnej liczby uruchomionych pojazdów.

2. Promień wyświetlanej scenerii jest regulowany automatycznie tak, aby uzyskać około 20 FPS. Tzn. przy domyślnych ustawieniach promień będzie zwiększany, jeśli wydajność przekracza 25 FPS, a zmniejszany, jeśli będzie mniej niż 16 FPS. Jeśli ktoś uzyskuje więcej niż 25 FPS to znaczy, że wyświetla mu się maksymalna odległość widzenia (domyślnie to jest 3km). Na sprzęcie, który nie osiąga 15 FPS niewiele da się zrobić. Symulator działa w miarę poprawnie do 5 FPS, potem zaczyna oszukiwać na fizyce (np. pociągi jeżdżą wolniej niż wynikało by to ze wskazania prędkościomierza).

3. Z moich obserwacji forum wynika, że dawno już nikt się nie skarżył na słabą wydajność, pomijając problemy konfiguracyjne. Np. wybrania nieodpowiedniej z dwu kart graficznych, braku sterowników, czy włączenia multisamplingu na kartach Intel. W pewnych przypadkach symulacja startuje z bardzo kiepską wydajnością i poprawia się to dopiero po uruchomieniu jakiegoś dźwięku (np. zatrąbieniu) – przyczyna takiego zachowania nie jest znana.

4. Sporadycznie spadek wydajności może być obserwowany w przypadku błędnych tekstur (np. o bokach nie będących naturalną potęgą liczby 2) albo nieoptymalnych modeli (gdy jest zbyt wiele submodeli). Opisywane też były przypadki spadku wydajności, jeśli np. las zrobiony pojedynczymi drzewami używa zbyt wielu różnorodnych tekstur.

5. Teoretycznie istnieje jeszcze dalsza możliwość poprawy wydajności, np. poprzez łączenie siatek prostych modeli (słupów, wysięgników), czy drzew o tej samej teksturze. Jednak w ostatniej ankiecie dotyczącej najpilniejszych zmian temat ten się w ogóle nie pojawił, w odróżnieniu od wcześniejszej, w której był jednym z dominujących.

6. Postęp techniczny i sukcesywna wymiana starszego sprzętu na nowy powoduje, że skrajne optymalizacje wydajności (np. specjalnie uproszczone modele, celowo odchudzone scenerie) interesują niewielki już odsetek użytkowników. Oni i tak wymienią sobie sprzęt wcześniej lub później, a wtedy cała ta praca pójdzie w zapomnienie. Optymalizacja symulacji jest potrzebna i istotna zawsze, ale powinna też mieć rozsądne granice.

26
Na warsztacie / Tarniowo2 (Modyfikacja scenerii Tarniowo)
« dnia: 07 Sierpnia 2013, 13:51:27 »
Przymierzam się do przerobienia scenerii Tarniowo. Obecnie wygląda ona jak makieta typu tort:


Ponumerowałem poszczególne szlaki, ponieważ chcę każdy z nich wydzielić. Te oznaczone cyframi 1 oraz 4 odkładam chwilowo na później. Dwa wewnętrzne, oznaczone cyframi 2 i 3 mam zamiar połączyć razem i umieścić pomiędzy Mydelniczką a scenerią Strzęsowiec – Karpice (SDR19). Będzie to wyglądało mniej więcej tak:


Podsypki i rozjazdy zostaną wymienione na te, które niedawno opublikował Benek (będzie to linia drugorzędna). Układów torowych stacji na razie nie planuję poprawiać, bo nie jest to priorytetem (być może wyjdzie inaczej). Zachodnie fragmenty szlaków 1 oraz 3 staną się bocznicami. Sieć trakcyjna zostanie usunięta (z jednej strony dla uproszczenia, z drugiej dla uzyskania niezelektryfikowanej linii, łączącej Czerwice z Wilisiem).

Cele do zrealizowania:
- przetestowanie i dopracowanie narzędzi edycyjnych w Rainsted,
- naliczenie kilometrażu linii przechodzącej przez Mydelniczkę (od Czerwic),
- rozszerzenie funkcjonalności dotychczasowych scenerii Quark i Tarniowo,
- przetestowanie scenariuszy dla scenerii opartej na komórkach.

2014-08-24 Zmiana tematu, ponieważ sceneria została udostępniona pod nazwą "Tarniowo2".

27
Forum / Doprecyzowanie przeznaczenia działów
« dnia: 22 Czerwca 2013, 13:41:52 »
Od czasu reformy działów obserwuję, że istnieje pewne pomieszanie co do przeznaczenia poszczególnych działów. W szczególności Symulator, Bieżące symulatorowe, Pomoc doraźna i Pomoc w tworzeniu. Chciałbym niniejszym doprecyzować moją wizję funkcjonowania tych działów.

Symulator
Dział o tym, co obecnie w MaSzynie jest, co jak działa, w jaki sposób można uzyskać jakieś efekty – za pomocą wpisów, plików itd. Podobnie jak w działach Tabor kolejowy oraz Infrastruktura kolejowa podstawą odniesienia jest rzeczywisty stan.

Pomoc doraźna
Pomoc doraźna to pomoc w uruchomieniu MaSzyny. Przede wszystkim sytuacje, gdy komuś nie działa symulacja, a powinna działać, bo innym działa.

Pomoc w tworzeniu
To pomoc w użytkowaniu programów innych niż MaSzyna, a które służą do tworzenia scenerii, modeli, czy dźwięków. Czyli opisy wszelkiego rodzaju edytorów, a także innych narzędzi do konwersji czy przetwarzania plików. Również tu powinny być porady w zakresie zbierania materiałów, czyli nagrywania dźwięków, robienia zdjęć, wykonywania pomiarów itp.

Bieżące symulatorowe
Tu powinny być umieszczane tematy, których znaczenie jest tymczasowe. W szczególności zgłaszanie błędów w symulacji (nie z uruchomieniem i nie przy tworzeniu dodatków), a także propozycji zmian.


W miarę rozwoju treści wątku może okazać się właściwe przeniesienie do innego działu. Np. problem zgłoszony w Pomoc doraźna może okazać się problemem z symulatorem, wtedy powinien być przeniesiony do Bieżące symulatorowe. Z kolei propozycja zmiany funkcjonalności symulacji, zgłoszona w Bieżące symulatorowe, powinna być przeniesiona do Symulator po jej wprowadzeniu do użytkowania.

28
Bocznica / Wydzielone z: Wybór karty sieciowej
« dnia: 16 Maja 2013, 17:14:24 »
Naprawdę jest to forum dla specjalistów od kart sieciowych?

Bocznica.
Rozi

29
Ja tylko dodam, że pierwsze efekty prac można już oglądać na scenerii Quark z paczki MaSzyna 01.13, pomiędzy Wielkim Kacem a Skwarkami. Jest to pierwsza wersja betonowych podkładów, które są wstawione eksperymentalnie dla oceny wpływu na FPS oraz wrażeń wizualnych.

30
Co ta informacja wnosi w zakresie rozwoju symulatora i dlaczego użytkownicy nie mogą sobie przeczytać tego sami, wchodząc np. na stronę http://www.rynek-kolejowy.pl/?

Opcja "Zgłoś do moderatora" funkcjonuje. W przypadku łamania regulaminu, zareagujemy.
Bocznica.
Rozi

Strony: [1] 2 3 ... 5