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 ... 3 4 [5] 6
121
Poszukuję, chcę zrobić / Zmiany w obsłudze nieba?
« dnia: 13 Listopada 2008, 23:59:27 »
Chciałbym zapytać, czy są w planach zmiany obsługi nieba?

Obecnie wpis nieba składa się z pliku T3D, w którym wpisana jest tekstura. Na ile się zorientowałem, T3D jest w postaci czaszy obleczonej teksturą. Czy da się w tym T3D zrobić animację?

Co by było z sensem zrobić:
 - zmienną teksturę dla T3D - sky plik.T3D plik.BMP endsky,
 - obrót nieba wokół osi (gwiazdy, ruch słońca),
 - ustalenie kąta nachylenia osi obrotu,
 - Słońce/Księżyc niezależnie od chmur, chmury w postaci kulistej czaszy poruszającej się szybciej i w różnych kierunkach,
 - zmiana jasności oświetlenia jeśli Słońce/Księżyc są zakryte chmurą (chmury w postaci TGA z kanałem przezroczystości).

A wspominam o tym tylko dlatego, że robię konfigurację pogody i chciałbym zrobić obrazki mini dla nieba. Teksturę nieba muszę wyciągać z pliku T3D. Gdyby była planowana zmiana formatu komendy sky, to chciałbym już z góry w odpowiednią stronę poprawki robić.

Przy okazji, odnośnie nowych komend - dobrze by było, gdyby w przypadku unrecognized command: nnn, parser pomijał tekst aż do znalezienia endnnn, zamiast się wysypywać.

122
Bocznica / Informacje dla moderatorów
« dnia: 13 Listopada 2008, 22:16:00 »
Ponieważ ten działa trochę inaczej, chciałbym tu zebrać pewne informacje i wnioski, które powinni uwzględnić moderatorzy działając w tym dziale.


1. Wątki w większości są zakładane przez automat "w imieniu" użytkownika. Pierwsza wiadomość jest najczęściej generowana automatycznie (użytkownicy mogą też samodzielnie zakładać nowe wątki). Składa się ona z trzech części: linku do paczki, spisu plików w paczce (w szczególnych przypadkach może się nie wygenerować) oraz pliku informacyjnego (może nie być). Jeśli w paczce jest plik info.txt albo czytajto.txt, albo readme.txt, to jego treść jest doklejana do postu w trzeciej części. Jeśli są błędy (np. ortograficzne, formatowania), to one zostały zrobione w tym pliku, a nie w poście.

2. Automat wysyłający zapamiętuje numer wątku, który założył dla określonej paczki. W przypadku wysłania kolejnej paczki o podobnej nazwie, wiadomość zostanie doklejona na końcu zapamiętanego wątku. Z tego względu zamykanie wątków nie jest wskazane, gdyż automat nie będzie w stanie dodać kolejnej wiadomości.

3. Może się zdarzyć, że zostanie wysłana paczka zawierająca poprawki do wcześniejszej, ale z uwagi na inną nazwę zostanie założony nowy wątek. W takiej sytuacji można scalić ten wątek z wcześniejszym, należy jedynie upewnić się, że ten wcześniejszy został założony przez tego samego użytkownika.

4. Jeśli użytkownik wyśle w innym dziale wiadomość z linkiem do paczki przed zakończeniem jej testów, można taką wiadomość (wątek) przenieść do działu Paczki i scalić z wiadomością wysłaną przez automat. Ważne jest, żeby scalić z wątkiem założonym przez tego użytkownika.

5. Po zakończeniu testów i wydaniu paczki, można wątek usunąć całkowicie, szczególnie jeśli nie było uwag albo uwagi bardzo konkretnie odnosiły się do dzieła i nie miały charakteru uniwersalnego (żeby można było na podstawie zgłoszonych uwag opracować wskazówki dla twórców).


//Usuwam ten wątek, gdyż według mnie jest on nieprzydatny skoro wszystko jest wyszczególnione w Regulaminie Testu Dodatków. RoboBatman.

123
Symulator / Profil pionowy trasy.
« dnia: 03 Listopada 2008, 01:09:06 »
Tak mi się kołacze pomysł na plik z opisem profilu pionowego trasy. Byłby to oddzielny od plików scenerii plik, ale powiązany z nimi. W zasadzie to zawierałby wszystkie te informacje, co na tym rysunku:
http://img.wklej.org/images/24086profil-przyklad.jpg
plus dodatkowo informacje o torach (node track) należących do danej trasy.

Plik miałby strukturę rekordów o stałej długości. Można by wykorzystać format DBF z zapisem binarnym, a do edycji ręcznej konwertować na CSV.

Było by kilka typów rekordów:
-co 100m, określające położenie słupków hektometrowych,
-informacje o prostych, łukach i krzywych przejściowych,
-informacje o wiaduktach, mostach i przejazdach,
-informacje o torach (node track) przyklejonych,
-informacje o semaforach,
-informacje o słupach trakcji elektrycznej.

Rekordy powinny zawierać:
-typ rekordu,
-współrzędne XYZ punktu,
-współczynniki kierunkowe stycznej,
-odległość obiektu do osi lub kąt nachylenia,
-wysokości torów (dwie wystarczą?),
-głębokości rowów,
-odległości rowu od osi,
-wysokość terenu,
-kąty nachylenia skarp,
-pochylenie wzdłużne i boczne toru,
-ewentualnie eventy,
-tekstury dla torów,
-opis słowny.

W zasadzie edytorem scenerii zmieniało by się ten plik, a z niego było by generowane najbliższe otoczenie toru. Zawierałby on całą definicję toru. Po zaznaczeniu punktu początkowego można by też wygenerować taki plik z istniejącej scenerii (np. do poprawienia łuków). Dla potrzeb symulacji zawierałby on zbyt dużo danych, bo zarówno dane wizualne jak i ruchowe. Zaletą takiego pliku była by możliwość wielokontekstowej edycji. Można by go edytować zarówno w podglądzie 3D, wprowadzając dane z oryginalnej dokumentacji, jak również np. weryfikować z danymi SRTM i UMP.

Piszę o tym, żeby zapytać, co jeszcze powinno być w takim pliku, zanim zabiorę się za realizację.

124
WWW / Formularz zgłaszania problemów
« dnia: 22 Października 2008, 14:24:03 »
Padła propozycja, aby wprowadzić szablon zgłaszania problemów. Proponuję, aby zrobić specjalną stronę z formularzem, w którym będzie się zaznaczać odpowiednie pola. W związku z tym proszę o propozycje, jakie pola powinien zawierać formularz.

Formularz po wypełnieniu zakładałby wątek na forum w dziale Pomoc, ewentualnie byłby połączony z rejestracją nowego użytkownika, gdyby zgłaszający problem konta na forum nie posiadał.

125
Poszukuję, chcę zrobić / Czy łączyć fikcyjne z realistycznymi?
« dnia: 18 Października 2008, 23:57:01 »
Chcę zrobić połączenie tras fikcyjnych, aby było po czym jeździć, zanim tworzenie tras realistycznych stanie się łatwiejsze. Trasy realistyczne będą budowane wg współrzędnych PUWG 1992. Współrzędne te obejmują obszar Polski z pewnym marginesem. Margines ten pozostawia około 200km na północ od Władysławowa i 300km od Świnoujścia.

Margines ten pozwalałby umieścić w nim scenerie fikcyjne, z możliwością przejazdu na realistyczne poprzez jakieś bocznice w portach. Formalnie scenerie znajdowałyby się na obszarze Morza Bałtyckiego. Wadą takiego rozwiązania byłoby ograniczenie obszaru scenerii fikcyjnych do czworokąta o wielkości około 300km×200km, bez możliwości dalszej rozbudowy i sztywnym położeniem względem obszaru Polski. W obecnym projekcie połączenia scenerii fikcyjnych mieszczą się one w kwadracie 160km×160km i jeszcze jest dużo wolnego miejsca.

Chciałbym zapytać, co myślicie na ten temat. Czy scenerie fikcyjne powinny zostać połączone z realistycznymi, kosztem ograniczenia ich obszaru, czy też lepiej aby posiadały swój własny układ współrzędnych i nieograniczone możliwości rozbudowy (no, powiedzmy, 400km w każdą stronę).

Zobacz także:
Kolejowa Mapa Polski
"Konkurs" na połączenie scenerii

126
Bieżące Symulatorowe / Paczka torrentowa
« dnia: 30 Września 2008, 21:00:36 »
Widzę po logach, że wchodzą na moją stronę z adresu:
http://torrent.info.pl/komentarze,147901,Symulator.html

Wie ktoś może, co to za paczka? Rozmiar: 332.85 MB.

127
WWW / Domena eu07.pl, czy www.eu07.pl?
« dnia: 14 Września 2008, 01:38:44 »
Mam problem z budowaniem linków. Nie wiem, czy lepiej podawać eu07.pl, czy www.eu07.pl. Większość linków zewnętrznych wskazuje na tę dłuższą formę. Z kolei na forum pojawiają się linki z krótszą. Moim zdaniem trzeba by się zdecydować na jedną i konsekwentnie tego trzymać.

128
Symulator / Dane wektorowe UMP
« dnia: 12 Września 2008, 23:03:49 »
Niedawno zacząłem eksplorację tego tematu. Użytkownicy odbiorników GPS chodzą sobie po świecie i zapisują współrzędne różnych punktów. Potem przegrywają te współrzędne do komputerów i rysują mapy. Współrzędne mają dokładność 0.00001°, co się przekłada na 1.1m na linii N-S i około 0.7m na linii W-E. Są już odbiorniki podające jedną cyfrę więcej, ale to melodia przyszłości. Aktualnie badam na ile te dane mogą być przydatne do tworzenia scenerii realistycznych.

Format źródłowy danych wygląda mniej więcej tak:
[POLYLINE]
Type=0x6
Label=Wyzwolenia
EndLevel=1
Data0=(50.23861,18.95753),(50.23834,18.95747),(50.23800,18.95733)
[END]

Więcej informacji:
http://www.ump.waw.pl/faq.html
http://ump.waw.pl/pliki/UMP-signify.txt
http://okapi.ict.pwr.wroc.pl/~tsurmacz/gps/pl/


No i żeby nie być gołosłownym, zrobiłem poglądowy zrzut ekranu (ulice w Sosnowcu; niedokładności widać nawet przy 500px/km, ale za to o ile mniej rysowania).

129
Symulator / Ortofotomapa jako teren
« dnia: 05 Września 2008, 19:47:48 »
Ortofotomapa z geoserwer.pl jako teren

Dziś po raz pierwszy wstawiłem ortofotomapę jako teksturę terenu. Oryginał pochodzi z geoserwer.pl:


Plik ma rozmiar 1251×1251 i obrazuje powierzchnię 1km2. Został przetworzony w następujący sposób:
 1. Został zmniejszony rozmiar do 1000×1000 pikseli, aby na jeden metr przypadał jeden piksel.
 2. Został dodany margines 24 piksele z prawej i od dołu, aby uzyskać teksturę 1024×1024 pikseli. Docelowo margines będzie użyty do powielenia na nim fragmentów sąsiednich kwadratów, aby uniknąć efektu zawijania tekstury (po lewej stronie widać jej prawy fragment - najczęściej widać to jako czarne kreski nad lasami, np. w Quarku).
 3. Plik zapisany w formacie BMP zajmuje 3MB.
 4. Namiastka scenerii z widokiem na ortofotomapę jest w załączniku. (Nie są uwzględnione wysokości SRTM - zrobię później.)

Jak widać, ortofotomapa nadaje się dobrze do symulatora lotów. Do celów Symulatora EU07 przydatna będzie przy edycji scenerii oraz może jako widok w dolinę. W zbliżeniu (przez szybę SM03) wygląda marnie i raczej się nie nadaje na najbliższe otoczenie torów (w końcu ma 1px/m).

2009-12-31 Zmiana tytułu wątku.

130
Symulator / SRTM vs NMT z geoportal.gov.pl
« dnia: 05 Września 2008, 05:32:05 »
Jako że pracuję nad edytorem scenerii realistycznych, rozważałem też temat automatycznego ustalania wysokości terenu i jego rzeźby. Serwis geoportal.gov.pl, oprócz rewelacyjnych ortofotomap oferuje również numeryczny model terenu (NMT). Model ten ma niby siatkę 25m, czyli 3-4 lepszą niż SRTM. Przyjrzałem się temu dziś. Porównałem fragment wielkości 0.1° wygenerowany na podstawie SRTM z tym, co jest oferowane przez geoportal.gov.pl jako NMT (od 19°E i 50°N w kierunku wzrostu współrzędnych, okolica między Tychami, Oświęcimiem i Pszczyną, rzeki od dołu to Pszczynka, Korzenica i Gostynia; obszar ok. 7km×11km, ale pokazany jako kwadrat). Porównanie wygląda tak:


131
Pomoc w tworzeniu / Optymalizacja modeli taboru
« dnia: 19 Sierpnia 2008, 01:13:14 »
Czytając o modelach do MSTS znalazłem taki przykład użycia programu konwertującego z 3DS:

Cytuj
For example:
Conv3ds.exe Dash9.s Dash9200.3ds will create the Dash9.s file for the game and make it viewable up to 200 meters.

Conv3ds.exe Dash9.s Dash9200.3ds Dash9500.3ds Dash91000.3ds Dash92000.3ds will create one Dash9.s file with four distance levels built into it at 200, 500, 1000, and 2000 meters. This of course means that there must be four .3ds files created using the same shape but with reduced polygons to make rendering more efficient on slower computers, and reduce rendering on distant objects.

O co chodzi? Że nie jest to jeden model, ale cztery różne modele tej samej lokomotywy. Im większy dystans, tym modele są bardziej uproszczone. Tymczasem - przy mojej znajomości modeli do Symka - odnoszę wrażenie, że w większości przypadków model jest jeden, widoczny od zera do maksimum, co najwyżej wraz z odległością znikają pewne szczegóły.

Chciałbym zaproponować stworzenie (lub przerobienie) jakiegoś modelu w następujący sposób:
- szczegółowy model widoczny jest do odległości 200m;
- od 200m do 500m widoczny jest model bardziej uproszczony;
- powyżej 500m model ma około około 20 trójkątów.

Odległości wziąłem z podanego przykładu, trzeba by poeksperymentować z ich dobraniem do szczegółowości modelu. Nie chodzi tylko o to, żeby znikały wycieraczki, klamki i barierki, tylko żeby podmienić cały model na całkiem inny (ale z tą samą teksturą). Oczywiście odległości muszą być dobrane w taki sposób, żeby moment przejścia nie był dostrzegalny.

Do wstępnych testów można użyć np. starego i nowego modelu ET22, połączonych w jednym T3D z odpowiednio ustawionymi MaxDistance i MinDistance (np. zmiana modelu w odległości 200m). Następnie wstawiamy do scenerii skład z 50 starych modeli, potem 50 nowych i następnie 50 mieszańców. Porównujemy FPS w różnych punktach składu (scenerii).


(Trochę inne zagadnienie, ale podobna zasada.) Jakiś czas temu robiłem optymalizację światła w latarniach drogowych. Jest tam świecąca tekstura oraz punkt świetlny (FreeSpotLight). Po wielu próbach wyszło mi, że tekstura świecącej lampy powinna być widoczna w przedziale 0-200m, a punkt świetlny powyżej 50m. Wtedy praktycznie nie dostrzega się momentu przejścia (ani zniknięcia tekstury, ani pojawienia się punktu). Dla porównania, w semaforach punkt świetlny włączany jest powyżej 20m - niemniej świecą one pod innym kątem. Ich jeszcze nie próbowałem optymalizować.

132
Poszukuję, chcę zrobić / Kozioł oporowy jako dynamic
« dnia: 13 Sierpnia 2008, 12:38:41 »
Zastanawiałem się przez długi czas, w jaki sposób można by zatrzymać jadący pociąg. Kozioł oporowy zrobiony z torów nie stanowi żadnej przeszkody, większość pojazdów przejeżdża go na wylot. Testowałem pionowe tory - też nic nie dają. EU07 rozpędzona do prędkości 160km/h (wpisem w trainset - wiem, że nieosiągalna) - wspięła się po pionowym torze na wysokość około 100m, przy okazji dziwnie zmieniając rozmiary (błąd w transform?).



Dosyć skuteczne okazały się niewidoczne tory wykolejające, ułożone pod kątem do kończącego się toru (mechanizm nullstop). Ale jak zatrzymać bez wykolejenia?

Wpadłem na taki pomysł, aby zrobić kozioł oporowy w formie pojazdu. Jego budowa byłaby maksymalnie prosta, tylko wygięte w górę szyny trzeba wymodelować (gdyż raczej nie da się użyć tych wystających z terenu). Jeśli chodzi o parametry, to musiałby mieć bardzo dużą masę (rzędu dziesiątek tysięcy ton) i mieć maksymalnie zepsuty hamulec. Uderzenie pociągu o masie 3000t z prędkością 70km/h powinno nieznacznie go przesuwać. Wymiary muszą być takie, żeby dało się dojechać do belki. Sprzęgi itp. oczywiście niepotrzebne.

Niestety nie mam tyle czasu, żeby w ciągu najbliższych tygodni zająć się produkcją i testami, dlatego publikuję ten pomysł. Może ktoś zrobi to szybciej, niż ja.

133
Poszukuję, chcę zrobić / Sceneria edukacyjna dla początkujących
« dnia: 11 Sierpnia 2008, 04:23:04 »
Chciałbym zaproponować, że pomogę chętnym osobom zrealizować scenerię o charakterze edukacyjnym, w zakresie korzystania z Symulatora i przepisów kolejowych. Sam nie zrobię, chyba że nagle zacznę mieć ogrom wolnego czasu...

Sceneria mogłaby zostać wydana jako jedna kompletna paczka, razem z EXE Symulatora (bez startera) i umieszczona na głównej stronie, jako wersja demo dla początkujących.

1. Po uruchomieniu Symulatora zaczynamy w EU07, a przed kabiną znajduje się duża biała tekstura ("dymek") z napisem "Włącz obwód główny - przyciśnij [M]" (ewentualnie odpowiednik po angielsku, niemiecku, rosyjsku). Jednocześnie, w miejscu startu lokomotywy znajduje się eventlauncher, który czeka na naciśnięcie klawisza. Po jego naciśnięciu, zmienia teksturę z napisem, sugerując, co trzeba nacisnąć dalej. Pierwszym zadaniem byłoby uruchomienie lokomotywy i pojechanie do przodu.

2. Następne zadanie to zatrzymanie jej w określonym miejscu. Jeździło by się w kółko - w jednym miejscu byłby W4 wraz z opisem sposobu zatrzymania. Zatrzymanie lokomotywy na odpowiednio krótkim torze przestawiało by zwrotnicę, pozwalającą na zwiększenie kółka lub przejechanie do następnego. Można by tu dać warunek konieczności trzykrotnego zatrzymania - przejechanie przez punkt zatrzymania powoduje liczenie od początku. Po zatrzymaniu trzeba by wyświetlać informacje o sposobie ponownego ruszenia. Plansze muszą znikać tak, by nie pojawiły się wewnątrz kabiny.

3. Gdy ktoś się już nauczy ruszać i zatrzymywać, przejeżdża do kolejnego zadania - tam jest jazda z określoną prędkością. Na pewnym odcinku następuje pomiar czasu - przejazd musi się zmieścić pomiędzy eventami uruchamianymi czasowo. Dać duże kółko, kilka odcinków z ograniczeniem np. 30, 50, 80 km/h i punktem zatrzymania. Prawidłowe przejechanie przez te odcinki powoduje przejście do kolejnego zadania.

4. Kolejnym zadaniem będzie zmiana kabiny. Zamiast jazdy w kółko, jest jazda zygzakiem. Dojechanie za zwrotnicę, zmiana kabiny (zwrotnicy też) i jazda w przeciwną stronę. I tak 3-4 razy.

5. Dalej, podczepianie wagonów i jazda z nimi w inne miejsce. Tu trzeba by eventami wykryć jednoczesną obecność wagonów w różnych miejscach torów. Wagony trzeba zostawić w określonym miejscu (znów detekcja), żeby przestawić zwrotnicę i pojechać dalej.

6. Następnie jazda plątaniną torów z dużym zagęszczeniem sygnalizacji świetlnej i kształtowej. Niezatrzymanie się w odpowiednim miejscu, zatrzymanie w nieodpowiednim, albo zbyt długi czas jazdy powoduje konieczność powtórzenia przejazdu po raz kolejny. Na starcie etapu byłaby wyświetlana plansza ze znaczeniami semaforów, a dalej ustawiałyby się one trochę "losowo". Np kilka odcinków, na których możemy jechać torem głównym "na wprost" (S6), albo torem bocznym z ograniczeniem prędkości (S11). Etap można rozdzielić na dwa, albo trzy - w pierwszym byłaby ograniczona liczba sygnałów (S1, S2, S5, S10, S13, Sz, Sr1, Sr2, Sr3, Ms1, Ms2 + tarecze ostrzegawcze), później dopiero wprowadzone migające i pasy świetlne.


Kolejne etapy powinny prowadzić przez pozostałe zakamarki E1 itp., wyświetlając plansze z napisami i sprawdzając poprawność wykonania eventami. Myślę, że taki interaktywny kurs obsługi Symulatora przyczyniłby się do jego popularyzacji, zwłaszcza na eksport.

Proszę o propozycje kolejnych zadań oraz szkice realizacji poszczególnych etapów.

Co do urozmaicenia terenu - można by to zignorować (zrobić zieloną pustynię), albo zrobić "wypas" (o ile będzie ktoś chętny) - wstawić budynki, wkleić zdjęcia jako tło, zrobić ruch AI na sąsiednich torach... Można też użyć kawałek istniejącej scenerii, albo realistycznego układu torowego jeśli się przyda na jakimś etapie.

134
Symulator / SWDB - dane wodne jako dopasowanie SRTM
« dnia: 31 Lipca 2008, 21:47:34 »
Aby wypozycjonować (skalibrować) dane SRTM dla mapy topograficznej z siatką kilometrową, postanowiłem zacząć od danych wodnych SWDB (kształty zbiorników wodnych), dołączanych do SRTM. (Rzecz dotyczy aktualnie scenerii PMP-PW, ale może się to przydać dla innych rejonów też.)

Napisałem sobie proste klasy w C++, które wczytują tzw. shapefile (.shp), w którym zapisane są wektorowo kształty zbiorników. (Dodatkowo są dwa pliki - indeksowy oraz .DBF - na razie nieprzydatne.) Shapefile ma troszkę zamotaną strukturę, z uwagi na pomieszane Big Endian z Little Endian oraz długości podawane w słowach (dwubajtach).

Wektorowe kształty zbiorników to rażąca pikseloza. Wygląda to tak, jakby ktoś na zdjęciu satelitarnym o niskiej rozdzielczości zaznaczył "niebieskie" obszary narzędziem wypełniającym. Piksele te zostają obrysowane łamaną o kątach 90° - dane zupełnie nieprzydatne do dalszego przetwarzania, chyba żeby aproksymować łamaną za pomocą krzywej Béziera. Współrzędne punktów są zapisane w stopniach.

Aby narysować te obrysy na mapie, użyłem funkcji przekształcenia:

xm=a*x+b*y+c*x*y+d
ym=e*x+f*y+g*x*y+h

Następnie dopasowywałem współczynniki tak, aby obrysy pokryły się ze zbiornikami Pogoria III, Zalew Sosina, J. Dziećkowice. Udało się to osiągnąć przy następujących współczynnikach:
a=71350 - [m/°] w poziomie
b=2850 - obrót
c=-0.6544 -skalowanie
d=1510770 - przesunięcie
e=1600 - obrót
f=-111200 - [m/°] w pionie
g=-0.05179 -skalowanie
h=5556800 - przesunięcie

Z kolei dane wyliczone z map topograficznych wyglądają następująco:
- odległość między 19°E a 20°E wzdłuż równoleżnika 51°N: 70406m,
- odległość między 19°E a 20°E wzdłuż równoleżnika 50°N: 71695m,
- odległość między 50°N a 51°N wzdłuż południka 19°E: 111339m,
- odległość między 50°N a 51°N wzdłuż południka 20°E: 111237m.

W efekcie wspomniane trzy zbiorniki pasowały prawie idealnie. Zbiorniki wodne w okolicy Sosnowiec-Mysłowice pasowały w miarę dobrze. Dla porównania zrobiłem sobie mapkę okolicy Koniecpola (13 km od Włoszczowy w stronę Częstochowy), z zawartym tam zbiornikiem. Zbiornik ten odstawał ok. 4km na północny-wschód. Wszelkie próby sprowadzenia go na wskazane na mapie miejsce kończyły się znacznymi odchyleniami wcześniej ustawionych trzech zbiorników.

Dalsze możliwości są następujące:
- ograniczyć przetwarzanie SRTM do obszaru, w którym dopasowanie danych wodnych ma dosyć dużą dokładność (nie chodzi tylko o SRTM, bo można wykorzystać inne dane, tworzone w oparciu o GPS - stosując tę samą konwersję współrzędnych, co dla SWDB);
- wybrać punkty charakterystyczne z SWDB (np. końce zbiorników, ostre łuki) i wyliczyć ich docelową pozycję na mapie; następnie wyliczać współczynniki metodą najmniejszych kwadratów/sześcianów;
- zmienić funkcję konwersji - np. przeliczanie współrzędnych biegunowych.

Pokażę mniej więcej, jak to wygląda. Czerwonym kolorem są tory (wstępnie przesunięte, ale nie dopieszczone - widać ząbek po lewej na dole), a jasnoniebieskim jest zarys zbiorników z SWDB (załącznik 1).

Dla porównania, okolice Koniecpola z zaznaczonym zbiornikiem (załącznik 2). Jest też niewielkie prawdopodobieństwo, że ten zbiornik jest błędnie narysowany... trzeba by znaleźć kolejny i próbować dalej.

Znalazłem jakieś wzory przekształcające współrzędne geograficzne na współrzędne prostokątne płaskie. Nie wyglądają ciekawie... http://www.navi.pl/gps/artykuly/uklady/uklady.html.

135
Od roku próbuję nadrobić to, że przez poprzednie lata nie zainteresowałem się Symkiem. Udało mi zorganizować skatalogowanie zawartości (na dzień dzisiejszy) 676 paczek oraz 876 linków do większości z nich. Aktualnie tworzę spis tras i oglądam postępy w pracach nad Symulatorem w 2003 roku... Taboru jeszcze nie ruszyłem, ale pewnie do tego też dojdę.

Przeglądając forum, znalazłem nieaktywne linki do materiałów, które mnie zainteresowały. Działających linków nie znalazłem. Nie było mnie wtedy tu i nie mogłem obejrzeć, gdy linki działały. Na pewno nie ma tego w tych zbiorach, z którymi się zapoznałem. Jakby ktoś mógł wystawić te paczki, to byłbym wdzięczny.

1. Quark-reaktywacja.
http://eu07.pl/forum/index.php/topic,1916.0.html

2. Nadodrzanka.
http://eu07.pl/forum/index.php/topic,3288.msg30161.html#msg30161

3. Sławków.
http://eu07.pl/forum/index.php/topic,3288.msg30142.html#msg30142

136
Symulator / Eventy domyślne dla torów
« dnia: 24 Lipca 2008, 21:53:07 »
Czy dałoby się zrobić tak, żeby dla każdego toru o nazwie innej niż none, były generowane domyślne eventy o nazwach utworzonych z nazwy toru i przyrostka _0, _1, _2, _all0, _all1, _all2?

Może nie tyle chodzi o generowanie eventów przez wszystkie tory po kolei, co o dynamiczne tworzenie połączenia eventów z torami podczas wczytywania. Dzięki temu, chcąc dodać nowy event do toru wystarczyłoby, aby w pliku z torami każdy ważniejszy tor miał inną nazwę, a nazwa eventu była utworzona z nazwy toru. Eventy mogłyby być w innym pliku niż tory i nie trzeba by edytować kilkumegowego pliku z torami.

Ewentualnie jakiś typ eventów multiple z jednym eventem na pokładzie (tzn. właściwie zmieniający tylko nazwę) byłby redukowany do stanu takiego, jaki obecnie jest po wpisaniu eventu od semafora do toru. Czyli np. tor tor16321 wyzwala event o nazwie tor16321_1, a za pomocą eventu multiple jest to zamieniane na stacjaA_seminfo, przy czym sam wpis tego eventu multiple zostałby "skrócony" podczas wczytywania.

Wiem, nie było by to zgodne wstecz, ale być może tworzenie eventów stałoby się nieco prostsze, bo nie trzeba by modyfikować wpisów torów.

137
Symulator / Porządkowanie podkatalogów w dynamic\PKP
« dnia: 05 Lipca 2008, 03:00:01 »
Może w niezbyt szybkim tempie, ale zmierzam do zrobienia instalatora paczek. Instalator ma składać coś w rodzaju paczki całościowej poprzez instalowanie pojedynczych paczek. Czyli uruchamiamy moduł instalatora, wchodzimy na zakładkę Tabor, wybieramy typ pojazdu (np. ED72), a instalator pobiera skrypt instalacyjny z serwera danych, sprawdza już zainstalowane pliki, pobiera brakujące paczki, których nie znajdzie na naszym dysku, a następnie rozpakowuje pliki do odpowiednich katalogów.

No i tu jest problem z odpowiednimi katalogami. Niektóre pojazdy istnieją w kilku, niezgodnych ze sobą, wersjach. W perspektywie może to dotyczyć każdego pojazdu, bo zawsze można zrobić lepsze modele i tekstury dające więcej szczegółów i możliwości konfiguracji. Nazwy katalogów nadawane przez autorów mają różną konstrukcję, przez co trudno zorientować się, co jest czym. Teoretycznie można by trzymać wszystkie wersje w jednym katalogu, bo często używane są wspólne tekstury (np. wózków), ale wtedy trudno będzie się pozbyć jednej z wersji, która nie będzie się nam podobać.

I tu mam prośbę do wszystkich, którzy są lepiej zorientowani w taborze, niż ja, aby wypowiedzieli się co do ujednolicenia nazewnictwa katalogów. Kolega @Class66 zaproponował taką strukturę (z tym, że np. SU45spec jest do wyrzucenia).


Czy stosować nazwy fabryczne, czy inwentarzowe PKP? (Lepiej się ograniczyć do jednych, w miarę możliwości.)

Jakiego typu przyrostek dodawać do tej nazwy? (Można takie: _v2, _2, _A, _08. Lepiej nie używać _NEW, bo zawsze może powstać jeszcze nowsz wersja.)

Czy do wszystkich katalogów dodać _v1, bo jest możliwość, że do wszystkiego powstaną nowe modele? Czy pozostawić katalog bez przyrostka, jako pierwotny? (Z teksturami w niskiej rozdzielczości i modelami z lat 2002-2004. Docelowo nie byłby on instalowany, chyba że użytkownik preferuje większą ilość FPS niż wygląd taboru.)


Dla uproszczenia odpowiedzi dodałem ankietę. Proszę nie sugerować się kolejnością opcji - jest ona przypadkowa.

Oczywiście starter będzie wyposażony w mechanizm automatycznej zmiany nazwy katalogu w scenerii. Tak więc zmiany nazw katalogów będą jedynie formalnością, ułatwiającą segregowanie tekstur i różnych kabin. Użytkownik będzie mógł wybrać, które wersje pojazdów chce używać i tylko te będą instalowane - ale zawsze w katalogach o nazwach odpowiednich dla wersji.

138
WWW / Dokumentacja na WikiMedia w eu07.pl
« dnia: 03 Lipca 2008, 13:46:01 »
Zakładam nowy wątek, bo temat dokumentacji już zupełnie nie dotyczy błędów w regulaminie...

Niewątpliwie brak dostępnej na stronie WWW dokumentacji to w tej chwili jedna z większych bolączek symulatora. Jakiś czas temu była próba zrobienia z tym porządku - przeniesienie artykułów m. in. Jarasa z mojej wiki na MediaWiki, które docelowo miało się znaleźć na serwerze eu07.pl. Jak zwykle niestety zapał się szybko skończył, a osoby które zadeklarowały pomoc zniknęły...

Jaka jest możliwość zainstalowania MediaWiki na stronie eu07.pl? Chodzi mi konkretnie o tę domenę, ponieważ jeśli wiki miałaby być tworzona przez kogoś w zaciszu i opublikowana dopiero po ukończeniu, to w sukces takiego działania nie wierzę.

Nie deklaruję się, że przygotuję sam całą dokumentację. Ale mógłbym czasem doklejać jakieś informacje, które uda mi się sprecyzować. Ale jest tak warunek, że musi być to na bieżąco dostępne na eu07.pl.

139
Istnieje taka możliwość, aby starter uruchamiał jedną z wielu wersji danej trasy, zależnie od godziny uruchomienia. Poniżej opisałem, jak by to mogło wyglądać od strony technicznej. Pomysł nie jest mój (tu jest opis autora) i mam wątpliwość, czy będzie wystarczające zainteresowanie taką funkcjonalnością.

1. Wybieramy scenerię, powiedzmy o nazwie zwrotnicowo.scn.
2. Starter sprawdza, czy istnieje katalog scenery/zwrotnicowo - jeśli nie ma takiego katalogu, uruchamia normalnie.
3. W katalogu scenery/zwrotnicowo szuka plików o nazwie time*.inc - jeśli nie znajdzie żadnego, uruchamia normalnie.
4. Jeśli jest jakikolwiek plik time*.inc, wybierany jest ten, w którym cyfry umieszczone za słowem time są najbliższe aktualnej godzinie. Jeśli mamy trzy pliki time1203.inc, time1439.inc, time1811.inc, a jest godzina 15:07, wybrany zostanie time1439.inc.
5. Z tymczasowego pliku scenerii ($.scn), powstałego z pliku zwrotnicowo.scn, usuwane są wszelkie eventy i składy.
6. Jeśli w wybranym pliku time1439.inc są wpisy atmo, light, time, sky, zostaną one przeniesione do tymczasowego pliku scenerii w miejsce oryginalnych.
7. Pozostałe wpisy z wybranego pliku time1439.inc (eventy, składy, ewentualnie jakieś dodatkowe obiekty) zostają dopisane do tymczasowego pliku scenerii w odpowiednim miejscu względem FirstInit (składy po, reszta przed).
8. Sceneria zostaje uruchomiona.

Taki mechanizm daje w najprostszym przypadku możliwość wstawiania w scenerię składów o budowie uzależnionej od godziny. Czyli np. rano jedziemy inną lokomotywą, niż po południu, a w godzinach szczytu mamy więcej wagonów. Istnieje również możliwość zmiany parametrów światła, zależnie od godziny (wieczorem jest ciemniej). Użytkownicy mogą sami tworzyć składy na poszczególne godziny. Poszczególne wersje składów nie powiększają listy scenerii i uwalniają od konieczności samodzielnej edycji składów dla uzyskania różnorodności. (Istniejący mechanizm losowania tekstur nie zmienia modeli pojazdów ani ilości wagonów.)

W zaawansowanej wersji możliwa jest zmiana tras pociągów poprzez edycję eventów. A nawet można by zrobić w ten sposób obsługę różnych misji, co obecnie jest robione oddzielnymi plikami scenerii (np. jest ich 6 dla Linii 546).


Aby realizacja pomysłu była przydatna, ktoś musiałby przygotować pliki z wersjami składów na poszczególne godziny. Biorąc pod uwagę, że np. nie ma chętnych do katalogowania paczek, mam uzasadnioną wątpliwość, czy komukolwiek będzie się chciało takie pliki przygotować. Ja ich robić na pewno nie będę.

140
Symulator / Jak to działa, czyli efekty grzebania w chk.
« dnia: 11 Czerwca 2008, 18:46:48 »
Jakiś czas temu zrobiłem w moim programie wyświetlanie parametrów z plików .chk. To częściowo działało (dla EU07), a częściowo się program sypał. Nie chciało mi się dochodzić, co jest przyczyną. Zwłaszcza, że na pierwszy rzut oka wyglądało, że jest wszystko dobrze.

Przed dwoma dniami zabrałem się do zapisywania wszystkich parametrów w pliku bazy danych. No i pojawiły się te same problemy, tylko w bardziej zmasowany sposób. Najwięcej problemów tworzyła tabelka z MotorParamTable:. Zaczynając od EU07, mamy tak:

Cytat: dynamic\PKP\EU07\303e.chk
MotorParamTable:
0 23.34 206  124  118   
1 42.12 826  124  165   
2 25.81 380  123  218   
3 27.89 558  129  324   
4 30.48 798  130  427   
5 25.26 742  131  555   
6 23.27 807  145  852   
END-MPT

No ładnie wszystko. Nie ma co prawda zapisanej ilości pozycji, jak niektóre inne tabelki, ale ma znacznik końca. W każdej linii jest 5 parametrów, idzie to jakoś ogarnąć. Ale dalej jest coś takiego:

Cytat: dynamic\PKP\ET22\201e.chk
MotorParamTable:
0 23.34 206  124  118   
1 42.12 826  124  165   
2 25.81 380  123  218   
3 27.89 558  129  324   
4 30.48 798  130  427   
5 25.26 742  131  555   
6 23.27 807  145  852   
Circuit: CircuitRes=0.01 ImaxLo=600 ImaxHi=750 IminLo=350 IminHi=450
END-MPT


To co ja mam z tym zrobić? W EU07 jest to na zewnątrz tabelki. Uznałem to za błędne i poprawiłem plik .chk, żeby program przeszedł dalej. Musiałem to jeszcze poprawić w kilku innych plikach. Ale dalej czekała mnie kolejna niespodzianka:

Cytat: dynamic\PKP\SM03\Ls150.chk
MotorParamTable: minVelfullengage=7.8 engageDia=0.5 engageMaxForce=8000 engagefriction=0.8
0   0   0   -1    1    
1   5.056   -1   20.5  1
2   3.325   14.2   31.6  1
3   2.259   25.2   46.4  1
4   1.486   41.6   71.2  1
5   1.000   68.6   200   1
END-MPT


Jak widać doszły kolejne parametry w nagłówku, które psują trochę formę. Pozmieniałem to tymczasowo w plikach, bo mi się nie chciało dorabiać analizatora. Niemniej jednak program się wysypał na kolejnym:

Cytat: dynamic\PKP\EN57\6bs.chk
MotorParamTable:
0 20.68 63.8   149  76    1
1 20.48 84.5   144 106    1
2 22.41 147    140 134    1
3 21.94 188    120 132    0
END-MPT


Co jest? Otórz doszedł szósty parametr, który nie ma żadnego opisu. Dobra, przeżyję. Zrobiłem obsługę warunkowego parametru. Nie na długo. Następne było:

Cytat: dynamic\PKP\SM42\SM42.chk
MotorParamTable:
0   17.567   64   1500   15   0   0
1   15   183.3   2000   49   0   0
END-MPT

Co tu jest inaczej? Otórz jest siódmy parametr. Plik ten pochodzi z paczki całościowej z 2004 roku. W paczce z 2006 już tego ostatniego parametru nie ma. Coś można jeszcze wymyślić? Można. Proszę:

Cytat: dynamic\PKP\Dl2\Dl2.chk
MotorParamTable: minVelfullengage=3.8 engageDia=0.3 engageMaxForce=5000 engagefriction=0.8
0   0   0   -1        
1   15.9   -1   20.5 
2   8.7   14.2   31.6 
3   5.3   51.2   46.4     
END-MPT

Ja jestem pełen podziwu, że to w ogóle działa.

141
Symulator / Zachowanie AI - hamowanie
« dnia: 25 Maja 2008, 22:03:01 »
Przejechałem właśnie Nowy Świat na SN61 razem z AI (EXE Dizelpack). Mam parę obserwacji.

1. Parametr velocity w torze działa tak, że AI hamuje nieco wcześniej, ale i tak nie daje rady wjechać z podaną prędkością na ten tor. Następnie ustawia sobie podaną prędkość jako obowiązującą do odwołania. Innymi słowy, od toru z velocity 50 AI pojedzie dalej 50km/h po torach bez velocity. Skądinąd STV pokazuje tory z velocity jako ograniczenie prędkości, tak jakby ograniczenie obowiązywało tylko na tym torze. Wg Scenery.doc: "Velocity (opcjonalny) - prędkość jakiej będzie się starał nie przekroczyć jadący przez ten tor obiekt dynamic jeśli jest sterowany przez AI". Nie ma mowy, że będzie tą prędkość utrzymywać dalej, po zjechaniu z tego toru. Czyli zgodnie z STV, a niezgodnie z EXE.

2. AI bardzo beztrosko używa hamulca. Hamując, w zasadzie co rusz zwiększa stopień hamowania (co ok. sekundę). Zupełnie "nie wie" o tym, że wystarczyło by ustawić którąś pozycję i poczekać na zadziałanie hamulca. Moim zdaniem hamuje tak, jakby jechało samochodem (o niewielkiej masie), czy też miało hamulce tarczowe - im bardziej wciśniemy hamulec, tym z większą siłą hamujemy. W pociągu jednak tak nie jest.

3. AI jest bardzo rygorystyczne. Jeśli jadąc 90km/h zobaczy tor z velocity 50, zacznie hamować, ale zbyt późno i zbyt słabo. Jeśli następnie wjedzie na ten tor z prędkością np. 53km/h, będzie nadal zwiększać siłę hamowania "bo przecież większa niż 50" - a już powinien odhamowywać. W efekcie zatrzyma się, bo gdy zwolni poniżej 50km/h, to ciśnienie będzie na tyle duże, że odhamowanie w tym momencie niewiele da. Żeby znów ruszyć, ustawi kran na odhamowanie, a nastawnik na maksimum, nie czekając z tym na spadek ciśnienia w cylindrach hamulcowych. Czyli "będzie się starał nie przekroczyć" oznacza tu, że jak przekroczy choćby o minimum, to zahamuje tak, że się zatrzyma.

4. Jeśli ktoś ustawi velocity 1, czy velocity 5, AI będzie wykonywać następującą procedurę: nastawnik na maksumum -> przekroczona prędkość -> hamulec na maksimum -> prędkość poniżej limitu -> odhamowanie -> zatrzymanie (bo hamulec działa z opóźnieniem) -> nastawnik na maksimum -> ruszenie po spadku ciśnienia w cylindrach hamulcowych -> przekroczona prędkość... W efekcie porusza się "żabimi skokami" i nie jest w stanie jechać z niewielką prędkością.

5. Moim zdaniem, zamiast kręcić regularnie kranem hamulca jak nastawnikiem w SN61, hamowanie powinno być zrobione inaczej. Powinien wyliczyć różnicę prędkości (między obecną a oczekiwaną) i w zależności od dostępnej drogi hamowania ustawić kran hamulca na parę sekund. Następnie np. co sekundę wyliczać uzyskane opóźnienie chwilowe (przyspieszenie ujemne) i wyliczać czas do uzyskania oczekiwanej prędkości. W zależności od tego czasu, albo zwiększyć siłę hamowania, albo ją zmniejszyć - ale po zmianie znów odczekać 5 sekund. No i więcej tolerancji. Jeśli aktualna prędkość jest większa od oczekiwanej o 10%, a już hamujemy, to nie ma potrzeby zaciskać bardziej szczęk i stanąć. Żeby zwolnić o 2% nie potrzeba od razu używać hamulca, który zadziała po 10 sekundach, wystarczy wyłączyć napęd i zdać się na opory ruchu. Zmiana położenia kranu hamulca powinna odbywać się w dłuższych odstępach czasu (5-10s), za to być bardziej przemyślana (wyliczana).

6. Wracając do velocity w torze, w obecnej sytuacji należałoby przed velocity 50 wstawić tor z velocity 75, żeby zdążył trochę zwolnić, a z kolei z drugiej strony wstawić tor z velocity 160, żeby nie jechał dalej ciągle 50km/h. Aby taki tor był przejezdny z sensem w obydwie strony, musiałoby być po kolei velocity 160, velocity 75, velocity 50, velocity 75, velocity 160. Być może musiałoby być więcej takich torów, z mniejszym skokiem prędkości. Trzeba by to sprawdzić doświadczalnie. To już się bez sensu robi, ale takie mamy AI.

142
Symulator / Kto co wie o T3D?
« dnia: 25 Maja 2008, 07:05:45 »
Jestem w trakcie rozpracowania plików .T3D. Niestety nie ma do nich żadnej dokumentacji (przynajmniej ja nie znalazłem).

Wiem, że mają strukturę hierarchiczną (typu drzewo). Każdy element ma najpierw parametry opisowe, potem macierz transformacji i na końcu listę trójkątów. Hierarchię, macierz transformacji i trójkąty rozpracowałem na tyle, że udało mi się je wyeksportować do pliku .3DS.

Natomiast zagadką są dla mnie pozostałe parametry opisowe. W pliku EU07.EXE są znalazłem następujące ciągi:
  • type: - możliwe wartości: mesh, point, freespotlight. Mesh to siatka trójkątów. Freespotlight to punkt świetlny (rodzaj reflektora). Ale czym jest point?
  • anim: - chyba zawsze jest false, może mieć inne wartości?
  • nearattenstart: - niby początek zanikania światła w zbliżeniu, ale czy to działa?
  • map: - nazwa pliku tekstury albo słowo replacableskin, jeśli teksturę można podmienić.

Ponadto nie ma ciągów (chyba?), ale są rozpoznawane:
  • Parent: - nazwa obiektu wyżej w hierarchii (słowo none dla głównego elementu).
  • Name: - nazwa elementu, może być użyta do animacji w event ... animation. Jeśli nazwa jest postaci Light_On## albo Light_Off##, element może być pokazywany i chowany za pomocą event ... lights (uwzględniana hierarchia). W modelach pojazdów są jeszcze inne nazwy specjalne (np. HeadLamp12_on), podobnie w kabinach.
  • Diffuse: - kolor świecenia elementu (RGB, trzy liczby 0..255).
  • SelfIllum: - świecenie elementu: true albo false.
  • MaxDistance: - maksymalna odległość, z jakiej widać element (hierarchia ignorowana).
  • MinDistance: - minimalna odległość, z jakiej widać element (j.w.).
  • Transform: - początek macierzy transformacji.
  • NumVerts: - ilość wierzchołków i definicje trójkątów.

Nie jest mi znane działanie następujących parametrów (nie chodzi o ogólne znaczenie, bo to można znaleźć w instrukcji 3D Studio Max, tylko o zastosowanie w Symulatorze):
  • Ambient: (RGB, trzy liczby 0..255)
  • Specular: (RGB, trzy liczby 0..255)
  • Wire: false
  • WireSize: 1.0
  • Opacity: 100.0
  • NearAttenStart: 0.0
  • NearAttenEnd: 80.0
  • UseNearAtten: true
  • FarAttenDecayType: 2
  • FarDecayRadius: 80.0
  • FalloffAngle: 45.0
  • HotspotAngle: 10.0

Nie są mi też znane okoliczności pojawienia się komunikatu Degenerated triangle found. Domyślam się, że może się pojawić w sytuacji, gdy wierzchołki trójkąta się pokrywają, ewentuallnie są na jednej prostej.

To tyle, co ja wiem. Ktoś wie coś więcej?

143
WWW / Problemy z serwerami trzymającymi paczki do MaSzyny
« dnia: 25 Maja 2008, 05:46:54 »
Od jakiegoś czasu staram się uporządkować informacje o paczkach i linkach do nich. Uruchomiłem serwis do katalogowania paczek i sprawdzania aktualności linków. Niestety linki wygasają, domeny i serwery przestają funkcjonować, a katalogować paczek nie ma kto. Znikają przez to bezpowrotnie paczki zawierające pewien wkład pracy do rozwoju Symulatora. A nowi użytkownicy mogą już nigdy ich już nie znaleźć.

Chciałbym, aby w tym wątku były dopisywane informacje o problemach z serwerami, oferującymi paczki do MaSzyny, a także o ewentualnym naprawieniu ich. Ostatnio jest duże nasilenie. Aktualnie są problemy z następującymi serwerami:
  • kolej.pl - domena wygasła, nie wiadomo, czy będzie przywrócona,
  • q.nastawnia.org - domena wygasła, nie wiadomo, czy będzie przywrócona,
  • milosz.nastawnia.org - domena wygasła, nie wiadomo, czy będzie przywrócona,
  • mamut.mysza.eu.org - serwer nie odpowiada,
  • chomikuj.pl - wymagane jest zalogowanie do serwisu,
  • ziemowitdtp.nazwa.pl - zablokowany dostęp (403) - hosting wygasł?,
  • www.speedyshare.com - pliki usuwane po 7 dniach od ostatniego pobrania,
  • www.kurczak.one.pl - hosting wygasł?,

144
Symulator / Kolory światła (freespot/stars)
« dnia: 22 Maja 2008, 16:19:16 »
Oglądając jedną z tras zauważyłem lampy świecące na obrzydliwie żółty kolor. Nigdy nie widziałem lampy świecącej na taki kolor. Wydaje mi się, że jest możliwe ustalenie kolorów RGB, które by odpowiadały poszczególnym źródłom światła. W zasadzie mamy pięć rodzajów światła (nie liczę semaforów):
  • słoneczne,
  • żarówek wolframowych,
  • halogenowe,
  • sodowe,
  • rtęciowe.

Światło słoneczne uważamy za naturalnie białe (RGB=#FFFFFF) i w jego odniesieniu są (powinny być) robione zdjęcia na tekstury. Fotografie robione przy innym świetle (żarowe, lampa błyskowa) powinny mieć skorygowany punkt bieli. Źródło światła słonecznego do scenerii wstawiamy wpisem light.

Światło żarówek wolframowych występuje w przypadku reflektorów, a także jako białe światło semaforów. Na razie ustaliłem, że światło to odpowiada promieniowaniu ciała doskonale czarnego o temperaturze 2856K i w modelu barw CIE XYZ 1931, a dokładniej Yxy ma współrzędne x=0.44757, y=0.40744. Znalazłem kalkulator, który pozwala wyliczyć pozostałe informacje, przede wszystkim kolor RGB:
HTTP       =  #FFB263
Web safe   =  #FF9966
RGB 0-255  =   254.59   178.17    99.46
RGB 0-FF   =       FE       B2       63
RGB 0-0.1  =  0.99841  0.69872  0.39004
CMY 0-0.1  =  0.00159  0.30128  0.60996
CMYK %     =    0.000   30.016   60.934    0.159
XYZ        =   59.319   54.000   19.216
Yxy        =   54.000  0.44757  0.40744
CIE-L*ab   =   78.462   21.075   54.450
CIE-L*CH   =   78.462   58.387   68.841
CIE-L*uv   =   78.462   64.181   65.532
HunterLab  =   73.485   15.491   35.935
Illuminant =  D75
Observer   =  10° (1964)
Jak widać kolor żarówek (#FFB263) jest mocno pomarańczowy, co zauważalne jest tylko w porównaniu do światła słonecznego (w nocy tego nie zauważamy, szczególnie na zdjęciach ze skorygowaną bielą). Dokładnie ten kolor ten widać na niektórych teksturach po zbliżeniu się do reflektorów. Teraz by trzeba było sprawdzić, czy wstawienie takiego światła (emisyjnego) do reflektorów lokomotywy wyglądać będzie naturalnie.

Jak znajdę parametry pozostałych źródeł światła, to dopiszę, może ktoś mi pomoże.

Poniżej obrazek SN61. Reflektor po lewej ma oryginalną barwę, jaka była w modelu. Ten po prawej jest zmodyfikowany zgodnie w wyliczonym wyżej RGB.

145
Poszukuję, chcę zrobić / Kompozycja ekranu startowego
« dnia: 09 Maja 2008, 02:06:21 »
Jakiś czas temu powstał zestaw ekranów startowych, które można sobie podmieniać. Do mojego programu dorobiłem więc możliwość losowania jednego z nich i kopiowania do textures\logo.bmp. Potem również możliwość przypisania jednego obrazka do nazwy toru w uruchamianej scenerii.

W ostatniej wersji zrobiłem wczytywanie obrazków w formacie .jpg, więc jest teraz możliwość zapisania ekranu startowego nie tylko w .bmp, ale również w oszczędniejszym .jpg.

Zastanawiałem się nad tym, jak uzależnić pokazywany ekran startowy od wybranej scenerii oraz prowadzonego pojazdu. Wpadłem na pomysł, że skoro konwertuję .jpg na .bmp, zmieniając przy tym rozmiar, to równie dobrze mogę złożyć kilka obrazków w jeden. Czyli np. połączyć w jedną całość zbliżenie wybranej lokomotywy, jakiś motyw ze scenerii, a w tle umieścić schemat torów z zazaczonymi i opisanymi stacjami oraz czasami odjazdu. Można by też umieścić jakieś dodatkowe napisy, np. opis klawiszy sterujących eventami w scenerii.

Jeśli znajdzie się ktoś chętny, żeby przygotować kompozycje (rozmieszczenie poszczególnych obrazków składowych) oraz screeny pojazdów, to w najbliższym możliwym czasie opracuję format pliku generującego ekran startowy (tzn. opisu kompozycji dla programu).

146
Bieżące Symulatorowe / Jak uruchamiasz Symulator?
« dnia: 04 Maja 2008, 22:30:47 »
Chciałbym się zorientować w aktualnym stanie preferencji.

147
Symulator / Informacje o plikach *.INC
« dnia: 03 Maja 2008, 02:23:58 »
Jako że zrobiłem przesuwanie i przekręcanie o kąt torów, chciałbym również zrobić to samo z obiektami wstawianymi przez include. Tu nie jest sprawa prosta, bo o ile w przypadku node z góry wiadomo, w którym miejscu są jakie parametry, to w przypadku include jest to mocno umowne.

Postanowiłem przymierzyć się do spisu plików *.INC, zawierającego informacje o typie parametrów. Wymyśliłem taką strukturę:
Cytat: download\inc-pl.ini
[INFO]
Plik "inc-pl" z opisem parametrów do plików include (w języku polskim).
Sekcja [INFO]: opis dla użytkowników, ignorowany przez program.
Sekcja [TYPE]: typy elementów w include, jednen znak (ew. kilka).
Sekcja [PARAM]: możliwe parametry i ich nazwy, jeden znak.
Sekcja [INC]: dla pliku podany typ oraz kolejność i typ parametrów.
- Po znaku komentarza podany opis, w nawiasie autor i rok utworzenia.
Inne sekcje mogą być dodane w przyszłości.

[TYPE]
s=semafor
z=zwrotnica
b=budynek
w=wskaźnik
p=przejazd
t=drzewo
k=kilometraż
u=ukres
*=sceneria

[PARAM]
x=odcięta
y=rzędna
z=kota
a=kąt_OX
b=kąt_OY
c=kąt_OZ
n=nazwa
t=tekstura
m=model
v=prędkość
w=szerokość
h=wysokość
l=długość

[INC]
SS3pkz.inc=s,nxyzbt//semafor 3-komorowy powtarzający karzełkowy (Speed, 2003)

Najpierw mamy jednoznakowy kod określający, czym dane include jest, a przez to, co można z nim zrobić podczas edycji. Np. drzewa można obracać i przesuwać, w zwrotnicy zmieniać teksturę podsypki, a semafory itp. powinny być przesuwane razem z torem, który jest w ich pobliżu. Oczywiście są to przykłady i należało by się zastanowić, jakie rozróżnienie typu w zasadzie potrzebujemy.

Kolejna sekcja definiuje typy parametrów. Tu też są jednoznakowe kody typu parametru. Myślę, że nie wymaga to szczegółowego komentarza.

W ostatniej sekcji jest informacja o pliku. Przed znakiem równości jest nazwa pliku, a dalej kod typu pliku, kody kolejnych parametrów i opis tekstowy. Na każdy plik byłaby jedna pozycja. Trzeba się pewnie będzie zdecydować na zapis nazwy wielkimi lub małymi literami.

Na koniec chciałbym wspomnieć, że są takie include, które nie nadają się do edycji. Tzn. przeliczenie parametrów w jakikolwiek sposób spowoduje błędy. Ma to miejsce, gdy parametr musi być liczbą całkowitą, bo jest np. mnożony przez 10 poprzez dopisanie zera - (p3)0.


2008-05-19 Poprawiony opis wewnątrz pliku.

148
Poszukuję, chcę zrobić / Krótki opis scenerii dla instalatora
« dnia: 21 Kwietnia 2008, 03:12:34 »
Robię spis scenerii (tras) na potrzeby instalatora. Do każdej scenerii potrzebuję krótki opis (do 255 znaków) z informacją, co ona sobą przedstawia. Opis ten jest przeznaczony dla początkujących użytkowników, którym nazwy scenerii nic nie mówią. (Będzie też tłumaczony na angielski.)

Do spisu kwalifikują się wszelkie scenerie, które wyglądają na kompletne. Tzn. mają tory, teren, oraz misję, którą da się wykonać. Błędy w eventach oraz braki, które można by łatwo naprawić nie dyskwalifikują scenerii. Oceny scenerii będą wystawiane oddzielnie. Jeśli sceneria istnieje w kilku różnych wersjach (i nie są one poprawkami błędów - np. Quark, Całkowo), to opis jest potrzebny do każdej wersji osobno.

Przykład opisu:
Bizonowo: Zamknięta krzywa długości 5km. Brak zwrotnic i trakcji. SN61 ze zbyt dużym składem. Ciekawe pagórki. (2004)

(W powyższym przykładzie przydało by się jeszcze jedno zdanie na temat okoliczności powstania trasy, czy jakaś ciekawostka, ale nie są mi one znane.)


Proszę wszystkich, którzy mają wyrobione własne zdanie, o propozycje opisania poszczególnych scenerii początkującym użytkownikom.

Lista tras jest pod adresem http://eu07.pl/forum/index.php/topic,5932.0.html.

149
Na warsztacie / Serwer ruchu - pociągi towarowe
« dnia: 19 Kwietnia 2008, 09:46:55 »
Zastanawiam się właśnie nad działaniem serwera ruchu. (Serwer ruchu ma pamiętać bieżący stan scenerii i synchronizować zdarzenia pomiędzy użytkownikami.) O ile samo przesuwanie pociągów po torach i przesyłanie danych jest dosyć proste, to zatrzymałem nad powodem, dla którego pociągi mają jeździć.

Otóż większego problemu nie ma z pociągami osobowymi - mamy rozkład jazdy z podanymi godzinami i budową składu. O ile nie trzeba rozformowywać składów i pożyczać wagonów do innych składów, wydaje się to być proste do zrobienia. Wystarczy tabela odjazdów, przystanków, prędkości szlakowych i będzie śmigać.

Problem zaczyna się w przypadku pociągów towarowych. Można je puszczać wg rozkładu jak osobowe i bez większych problemów będą kursować między kopalnią a elektrownią. Ale np. jak zrobić misję, w której trzeba zostawić po jednym wagonie z węglem na każdej stacji, a potem zebrać puste? Albo jak wozić węgiel między kopalnią a elektrownią i hutą w sposób nie planowy? (Tzn. węglarki i lokomotywy są przydzielane dynamicznie tam, gdzie jest większa potrzeba.) Albo jak wozić drewno z tartaku do miejsc, gdzie jest potrzebne? Jak zaprogramować, że po wjechaniu ze składem na bocznicę, ma z tartaku wyjechać SM03 i zabierając po 2 wagony na raz rozformować skład, po czym również po 2-3 wagony sformować inny? (I to nie ma być jednorazowo, tylko powtarzać się co jakiś czas.)

Pierwszy mój pomysł polegał na tym, żeby przypisać do wagonu miejsce załadunku i rozładunku. No tak, ale to jest skutek, a nie przyczyna. Przyczyną jest potrzeba przewiezienia ładunku z jednego punktu do innego. Znając typ ładunku (sypki, gabarytowy, kontener) i jego ilość, trzeba by poszukać odpowiednich wagonów, a następnie lokomotywy... Zebrać wagony w odpowiednim miejscu, za pomocą lokomotywy manewrowej załadować, a następnie wysłać w drogę i rozładować.

Z drugiej strony, zarządzanie wagonami i lokomotywami wydaje się być zbyt skomplikowane, jak na zadania prostego serwera ruchu, który nawet nie ma informacji o współrzędnych torów w terenie (jedynie o ich połączeniach i długości).

Drugi pomysł nazwałem roboczo MovLoader. Jest to taki tor, który umie załadować lub rozładować postawiony na nim wagon. Również, w zależności od typu wagonu oraz stanu jego załadowania, potrafi zmienić punkt docelowy umieszczenia wagonu (wskazać inny MovLoader).


Piszę o tym tutaj z nadzieją, że może ktoś zna sytuację lepiej niż ja i może podsunąć jakieś rozwiązania. Obecnie mamy misje manewrowe ograniczające się do podłączenia się pod stojący skład, zmianę czoła, zmianę składu oraz odjechania od składu na końcu trasy. (Może coś pominąłem, ale nie ma to większego znaczenia. Eaosy w Dejawach nie ładują się węglem w sposób przydatny dla misji i nie da wozić węgla do Skwarek przez całą dobę.)

Żeby serwer ruchu mógł prowadzić towarowe pociągi AI oraz sterować lokomotywami manewrowymi, musi być dokładnie poinformowany, co ma gdzie przemieścić. Ponadto ma działać przez całą dobę i dowolnie długi czas, więc ustawienie eventów na jednorazową akcję odpada.

150
EU07 Simulator English forum / Instalator+Starter+Editor (Rainsted)
« dnia: 13 Kwietnia 2008, 15:31:23 »
I have written a tool that can be used as MaSzyna starter. In future also as data editor and installator (these features are very limited now). The name of the tool is Rainsted, however it is in MaSzyna.EXE file.

You can download the program from http://eu07.rainsted.com. There are two packages needed: one is the recent version, second contains Borland libraries. (Several old versions are kept available in case of troubles with the recent one.) After downloading, you should unpack both archives into MaSzyna main directory, where the EU07.EXE is located. You need also the 7-Zip archiviser. If you don't have one, you will be asked to download and install.

In case you will see Polish texts, select the Ustawienia tab and look for ComboBox with pl - polski - and change it to en - English. Since version 1.0.52 also it - Italiano is available.

In present 1.0.52 version most of texts are translated. However you can see some messages in Polish. In case you see some, or errors in translation, please report to me using Private Message of this forum or any other way. There's also possibility to add more languages, so if you make the translation I can include it in next version.

The program has auto-update feature. Once launched it will ask you for new version downolading and then installing. With current settings it will ask about this every 3 days.

Enjoy.

Strony: 1 ... 3 4 [5] 6