"Celownik" do exe symulatora

[HTD]

Chłopaki, a nie dało by się tak zrobić, żeby pod jakimś klawiszem włączyć "celownik"? Obok wyświetlał by się dokładny punkt gdzie celuje celownik i azymut kamery. W ten sposób można by sobie w symku pozaznaczać punkty gdzie wstawić np brakujące W4 czy jakieś inne elementy. W ten sposób za pomocą samego symka i notatnika można by pouzupełniać scenerię.
Bez celownika też się tak da, tylko jest mało precyzyjnie. Jeszcze podgląd współrzędnych pod F2 ma taką wadę, że sam się przełącza na informacje o składzie, jak jest w pobliżu. Tymczasem widok celownika powinien zawsze wyświetlać tylko współrzędne. Byłoby też idealnie, jakby dodatkowo wyświetlał się poziom gruntu. To chyba nie jest jakaś kosmicznie trudna zmiana, jak ktoś zna budowę exe i jak działa w nim wyświetlanie "OSD" to chyba jest drobiazg na 15 minut.
Opcja full-wypas - wciśnięcie klawisza zrzuca współrzędne celownika do pliku tekstowego. Czyli powiedzmy Ctrl+F2 włącza celownik, Ctrl+F3 zrzuca.

To byłaby ogromna pomoc w tworzeniu (a raczej poprawianiu) scenerii.

[Krzysiek626]

Idźmy zatem dalej. Chciałbym, aby exe zawierało moduł/tryb wstawiania niektórych elementów infrastruktury według danych z celownika. Jest to możliwe, taką edycję próbował zrobić @Q, ale nie skończył. Na początku mogły to być tabliczki, wskaźniki, ukresy, może kiedyś słupy, semafory i elementy torowe.

[HTD]

Albo może pójść inną drogą - zrobić jakieś mikro API do komunikacji z zewnętrznego procesu - dostęp do wszystkich ważniejszych zmiennych (tego co jest pod F2), i opcję w stylu wstaw "include..." lub "node...". Jakbym dostał takie API, mogę na boku postawić apkę, która np zaznacza naszą bieżącą pozycję na mapie torów, wstawia obiekty do plików scenerii na bieżąco itd. Odpalasz 2 okna obok siebie, na jednym symek, na drugim apka łącząca się z API (mapa 2D, skrypty, opcje). Co do komunikacji - http na porcie. Windows API ma to w standardzie. Wymiana danych na zasadzie podobnej jak w konsoli: wchodzi tekst, wychodzi tekst. Symek parsuje tekst tym samym parserem co scenerie, zwraca dane identycznie jak w logu.

Wg mnie wstawienie nowego obiektu z include lub node jest trywialne, domyślam się, że największy problem byłby z modyfikacją już istniejącego obiektu albo usunięciem go. Nie wiem czy symek ma w ogóle metody do usuwania i modyfikacji obiektów. Generalnie trzeba by przeparsować wszystkie include, do poziomu node - a dalej to już sprawa prosta - modyfikacja obiektu typu node jest już trywialna. Parser jest w symku, więc w zasadzie trzeba go tylko wywołać dla zewnętrznego skryptu i zamiast użyć do wstawiania, użyć do modyfikacji lub usuwania. Powiedzmy składnia '+include x' wstawia nowy obiekt x, 'include x' modyfikuje właściwości obiektu x (przesuwa), '-include x' usuwa obiekt x.

Dochodzimy w końcu do tego, że mógłby to być zalążek pełnego edytora 3D, z czego symek odpowiada wyłącznie za rysowanie i zmazywanie, cała reszta jest w zewnętrznej apce OpenSource. OK, może modelowanie nadal wymagałoby narzędzi typu 3DS czy Blender, ale poskładać scenerię z gotowych modeli można by w całości 1 darmową apką. Edytor scenerii 2D już robię (tzn nie w chwili obecnej, bo zmieniam pracę teraz), ale wrócę do niego. Wg mnie dorobienie takiego API do symka to mniej roboty niż zrobienie porządnego edytora 2D, gdyby robić te 2 rzeczy równolegle efekt mógłby wyjść ciekawy i wręcz rewolucyjny. Z jednej strony low-level od 3D, z drugiej high-level od ficzerów typu UI. Dobre, że nikt nie musi na nikogo czekać. Do końca roku chcę wypuścić swoje cudo, jakby w tym czasie powstało takie mikro API to w ciągu paru miesięcy mielibyśmy porządny edytor 3D, w ciągu pół roku - idealnie dopieszczone wszystkie istniejące scenerie, w ciągu drugiego roku - wysyp nowych.

Inna korzyść - każdy może sobie w sumie napisać swój edytor wykorzystujący API symka ;)

Gdyby @Q był zainteresowany czymś takim, to byłoby super.

[Stele]

Piekne marzenia. Kod zostal uwolniony, by wlasnie kazdy mogl je realizowac. Probowales cos w nim dlubac? Pamietam, ze jak tylko sie zarejestrowales byles nim zainteresowany, gdy byl dostepny dla wybranych. Skoro jestes programista i masz wizje, to dlaczego czekasz na innych? Wiesci od Q nie slyszalem od miesiecy niestety.

[HTD]

Powody takie jak u większości - problemy z utrzymaniem się przy życiu (praca, i to nie 8h). Ale temat jest otwarty i naturalnie wezmę się za to jak tylko będę mógł. Gdyby jeszcze dało się to kompilować pod VS to by już w ogóle bajka była.

Wiesz, mi chodziło głównie o to, że jak ktoś ma już gotowe (skonfigurowane) środowisko do budowania exe i wie gdzie coś jest - to taka zmiana jest szybka. Zanim ja to wszystko od zera ogarnę to zajmie mi dość dużo czasu. Większą wydajność osiągnę kończąc edytor 2D najpierw, bo środowisko uruchomieniowe już mam, wiem gdzie co jest itd.

Na chwilę obecną to się cieszę jak mi się uda przejechać 1 trasę w ciągu dnia ;) Strasznie mnie drażni jak się w tej trasie jeszcze coś krzaczy i sypie, dlatego mnie korci, żeby podłubać. Jak tylko będę miał czas będę nacierać. Mam nadzieję, że ktoś się do tego dołączy później.

[Mariusz1970]

Obawiam sie jednak, ze dla zmian obiektow w locie i ich natychmiastowe wyswietlanie, bedzie wymagalo duzych zmian w kodzie MaSzyny.

[Stele]

Z tego co pamiętam, to edytor Q pozwalał jedynie na umieszczanie nowych. Nie dało się ich potem przemieścić ani usunąć. A zarzucony został przez tragiczną stabilność.

[pol102]

Bzdura. Zarzucone zostało bo był kłopot z wielopoziomowymi incami. Świnia nie będę i jak ktoś się zgłosi PW, to linka do Qedytora dostanie.