- Symulator MaSzyna -
Symulator EU07 (i nie tylko) => Bieżące Symulatorowe => Wątek zaczęty przez: HTD w 01 Stycznia 2017, 21:16:50
-
Pracuję właśnie nad nowym rozkładem i sterowaniem dla scenerii baltyk_en57. Straciłem kilka godzin na najdziwniejszy błąd, przerastający nawet to co się dzieje na Drawinowie przy podpięciu się do drugiego składu.
Przypisałem wszystkie potrzebne W4 na trasie do torów i przystanków. Przypisałem wszystkie semafory na szlaku, żeby kierpoć wiedział, kiedy może dać "gotów". I...
Losowo kierpoć nie działa. Nie daje odjazdu pomimo tego, że ma drogę wolną, ja sobie grzecznie stoję przed W4 gotowy do odjazdu.
I teraz SZOK:
Sprawdzam w tabelce (F2,F2) czy widzę W4. Nie widzę. Był i się zmył, był jeszcze minutę wcześniej, i nagle sobie zniknął. Gdybym miał na semaforze wyjazdowym S1, to bym się tak nie zdziwił, ale mam S2 albo SZ, tymczasem W4 znika z tabeli skanowania.
I drugi szok:
Przestawiam nawrotnik na jazdę do tyłu, i natychmiast na jazdę do przodu. Bez sensu, nie? Tymczasem nagle dostaję "gotów" od kierpocia, bo nagle pojawia się "zniknięty" W4.
CO JEST?! Normalnie WTF?!
To się zdarza przy przechodzeniu na drugi koniec składu w EZT, ale nie zawsze. Przed chwilą mi się zdarzyło po dojechaniu kiblem do Bałtyku Głównego. Dojeżdżam, zatrzymuję pod W4, to przystanek końcowy. Ale rozkład nie znika tak jak powinien. Patrzę w tabelę skanowania, oczywiście W4 się zmył, nie ma. To wciskam 3xR, 3xD i co się dzieje? Brakujący W4 się pojawia, rozkład znika. NO LUDZIE! Czary?
Czy ktoś się z czymś takim spotkał albo może mieć jakąś wskazówkę dlaczego taki dziwne rzeczy się dzieją? Patrzę szczególnie w kierunku głównych inżynierów MaSzyny.
UWAGA: Błąd występuje całkowicie losowo. Jeden przejazd jest OK, w innym, na oko identycznym kursie W4 sobie znikają i pojawiają się, po "wrzuceniu wstecznego" na chwilę.
UWAGA2: W niektórych miejscach gdzie to się dzieje występuje takie przypisanie wskaźników - najbliżej jest W4, a na kolejnym torze (za W4) jest przypisany semafor. Jednak Bielkowo nie ma semafora, a tam też zdarzyło mi się losowe zignorowanie W4 przez kierpocia.
UWAGA3: Nie, W4 nie jest przypisany do toru za mną i nie jest widoczny gdy daję nawrotnik na jazdę do tyłu. W tabeli skanowania pojawia się dopiero wtedy, kiedy przestawiam nawrotnik na jazdę do przodu. Testowałem to tylko na EZT i nie wiem czy problem występuje też z innymi pojazdami.
W wolnej chwili (a nie będzie łatwo w tygodniu) spróbuję zmontować jakiś szybki test, żeby można odtworzyć ten problem w ciągu paru minut.
-
Zobacz na exe
472 482 z devs (wątek Dragona) albo jakimś sprzed tego jak zacząłem się bawić kierpociem, by stał na przystanku jak jest spóźniony. Nie pamiętam teraz numerka, musisz changeloga zobaczyć. Mam podejrzenia, że to z jakiegoś powodu napsuło odhaczanie W4 i zrobiłem cofkę na próbę, ale nikt nie pali się do testów.
-
Masz na myśli 482?
-
Tak. Trzeba będzie w końcu przejść na poprawną numerację wersji swoją drogą...
-
To możesz pociągnąć wątek, który założyłem jakieś 10 miesięcy temu...
-
Ten babol jest super-wredny, zrobiłem specjalną misję do testów (na bazie TD), tzn po kolei wstawiłem W4 (ze stoinfo), semafor i kasowanie semafora w 3 kolejnych torach. Zrobiłem wysyłanie rozkładu do torów (tak jak mam zrobione na Bałtyku), ustawiłem sobie wysyłanie i kasowanie rozkładu pod Ctrl+1 / Ctrl+2. Testuję na EP07-424, działa.
Wersja exe 481. Nie jestem w stanie wywołać zniknięcia W4. Zrobię sobie jeszcze mruganie semaforem na Ctrl+3 / Ctrl+4, może od tego się sypnie...
Dodano: 02 Stycznia 2017, 14:47:21
Nie mogę odtworzyć tego buga na TD, to lipa straszna. Testowałem wszystkie kombinacje podawania i zabierania rozkładu i mrugania semaforem. Owszem, W4 na moment znika przy podawaniu semafora albo rozkładu, ale za chwilę sam się pojawia. Podmieniłem też EP07 na kibel, też nie chce się popsuć. Ja już nie wiem co tu się za czary dzieją, może po prostu po restarcie systemu błąd już nie występuje... nie wiem. Albo po prostu jest bardzo specyficzny dla konkretnej scenerii.
-
HTD. Możesz to zbadać na zwykłym Bałtyku obojętnie czy na letnim, czy zimowym.
-
Testowałem oba exe (482 i 483rc3), zachowują się tak samo, przynajmniej na TD. Nie wiem czemu na obydwu nie działa kierpoć. Może kwestia tego, że W4 są za blisko siebie. Zrobiłem prosty rozkład, 2 przystanki, z tego co widzę najbliższy semafor jest przypisany, W4 też, w tabeli skanowania wszystko jest ok, godzina się zgadza, jak przychodzi do odjazdu nic się nie dzieje. Znakiem tego coś jest nie tak z tym testem na TD.
Może kwestia tego, że tor się zapętla? ;)
Na marginesie, nie ma nic dziwnego w errors.txt ani log.txt.
-
Nie mam pojęcia. W4 zawsze były zabugowane. Dobrze by je było od nowa napisać, najlepiej wraz z nową strukturą rozkładu jazdy, ale to nie na mój mały rozumek.
-
Na TD nie da się odtworzyć buga, ale dobra wiadomość, na tym Bałtyku przy którym dłubię - problem jest w 100% powtarzalny. Niestety muszę kiblem najpierw wykonać manewry, jak sobie go podstawiłem pod W4 od razu, to widział go. Jak najpierw wykonałem manewry, wjechałem pod W4 i zmieniłem kabinę - wtedy znika. Jednak szukając dalej dziury w całym zauważyłem, że w scenerii jest błąd w definicji W4 i ma on tylko 8 parametrów zamiast 9 zdefiniowanych, co może powodować diabli wiedzą co. Poprawiłem go, ustawiłem mu otwieranie drzwi po właściwej stronie i właściwą reakcję na semafor (czyli 1 1), cóż, pierwszy test (z kiblem podstawionym pod wskaźnik) zaliczył, teraz odpalę test z manewrami...
Dodano: 02 Stycznia 2017, 18:07:53
Poprawienie W5 nic nie dało, ten sam błąd. I testowane na exe 483rc3.
-
Z tymi parametrami, to ja zrobiłem swego czasu, globalną analizę, która jest w dziale WPC. Jednak otrzymałem odpowiedź, iż to się"ślizga" na obecnych exe i nie ma się czym przejmować, bo to są formalne w gruncie rzeczy błędy. Dodatkowo, brak chętnych na poprawki. W załączniku wynik analizy, jaki był wstawiony do działu WPC (Excel).
-
Część już poprawiłem. Ale nie ma co, kończę z tym. Za dużo zabawy, żeby to robić ręcznie. Jakiś czas temu rozpocząłem budowę dużego automatu, który umożliwi zrobienie tego seryjnie na wszystkich sceneriach, w dodatku może uda się nim usunąć 50 wersji torów do tej samej scenerii. Wiem, w 100% automatycznie się nie da, ale w 99% się da. Program jest w stanie przypisać automatycznie sygnalizację do torów, jest w stanie zmienić nazwę wszystkich torów na unikalne identyfikatory, dzięki czemu ten sam tor będzie zawsze tym samym torem w każdej misji. I nie, zdarzenia się nie posypią, bo program zmieni także odwołania razem z nazwami. Następnie jak już nie będzie śmietnika w torach, będzie można wywalić duplikaty.
I to samo jeśli się tyczy plików typu "inne", "pozostałe", "reszta" itd. Plan jest taki - cała sceneria (ze wszystkimi include) ładuje się do pamięci. Tam jest sortowana, duplikaty są usuwane. Następnie produkowane są nowe pliki: osobno tory, trakcja, teren, sygnały, sterowanie. Przy okazji include są sprawdzane na poprawność, wg kryteriów jakie ustalimy.
Jeśli chodzi o parametry include - niektóre mogą być opcjonalne. Właśnie napisałem skrypt wysyłający rozkład z 7 parametrami, z czego ostatnich 4 są opcjonalne i nic się złego nie stanie, jeśli się ich nie poda. Ot utworzą się 4 puste komórki pamięci i tyle. Niestety w przypadku W4 nie wiem jak exe zinterpretuje brak ostatniego parametru. Z tego co sobie czytam o pracach przy konwersji - inicjowanie zmiennych to pięta achillesowa tego exe. Czyli wartości przesyłane mogą być nie do końca określone co może mieć różne efekty. Trzeba by to sprawdzić (zobaczyć gdzie ostatecznie trafia parametr i jakie mogą być konsekwencje wbicia tam losowej wartości).
Co do błędów w sceneriach - nagminnym, występującym na większości scenerii jest kompletny brak przypisania sygnalizacji do torów. Przez to cała automatyka i AI nie ma prawa działać na scenerii dopóki się tego nie zrobi. Robienie tego z ręki jest katorgą, dla automatu to nie jest takie ciężkie. Wystarczy się przejść po torach i policzyć po odległościach punktu od krzywej. Z tego jak robiłem to ręcznie z użyciem mapy - zwykle punkt najbliżej krzywej jest punktem prawidłowym i właśnie do tego toru należy wiązać. Troszkę bardziej skomplikowane jest określenie który event ma być wiązany, ale też do zrobienia. Program potrzebowałby do rozpoczęcia pracy określenia punktów końcowych, po tym określi którego kierunku dotyczy sygnał. Więc jedyne co robię ręcznie dla scenerii to podaję współrzędne początku trasy i końca trasy. Jeśli sceneria jest bardziej skomplikowana, może być konieczne podanie więcej współrzędnych. Ale to i tak o niebo łatwiejsze niż wyszukiwanie każdego wskaźnika i toru ręcznie i ręczne dodawanie eventów.
No ale to scenerie. Bugi w exe to osobna bajka. Co z tego, że się odpicuje scenerie idealnie, jak i tak się będzie losowo sypać lub po prostu nie działać jak trzeba. Tydzień zajęło mi posprzątanie śmietnika do 1 misji na Bałtyku, niestety jak krew w piach, bo skład sobie ignoruje W4 losowo. W dodatku bug się nie ukatywnia, jak sobie podstawię skład skryptem. Nie, muszę wykonać manewry, podjechać, zmienić kabinę, dopiero wtedy wychodzi albo nie wychodzi. Wszelkie uproszczenia do testów nic nie dają, w uproszczonych testach wszystko działa idealnie.
-
Kilka programów do sortowania już było, wszystkie jakieś defekty miały. Pamiętaj o sortowaniu torów i druta po trajektorii a potem po jakiejś współrzędnej oraz przyklejaniu słupów trakcyjnych do przęseł przewodu. Ra mi kiedyś wypominał brzydkie wywalenie słupów na koniec pliku przy wydzielaniu trakcji na jakiejś scenerii.
-
Jeśli chodzi o automat przypisujący np. semafory do torów, ja to zrobiłem i chciałbym Cię ostrzec, abyś nie zrobił tego samego błędu założenia co ja. Mianowicie, są sytuacje w sceneriach (i to wcale nie rzadkie), gdy najbliższy tor odległościowo nie jest tym torem, do którego ma być przypisany ten semek. Ja sobie zaimplementowałem taki system, że szuka dwóch najbliższych torów, ale nie połączonych ze sobą, względem danego semka. Jeśli różnica odległości semka do jednego toru z odległością semka do drugiego toru jest niewielka (mieści się w jakimś przedziale), wtedy sytuacja taka jest sytuacją niepewną i wtedy pokazuje się to miejsce na mapie, te dwa tory i semek i człowiek dokonuje wyboru. Ty możesz sobie obrać inny system, jednak przestrzegam, bo szukanie źle przypisanych semków w scenerii, może być udręką lub mogą wychodzić różne kwiatki po paru latach.
Żeby nie było, że nie ostrzegałem ;)
Dwa, nawiązując do tych 99%, to ja już Tobie tłumaczyłem, jaki byś kombajn nie zrobił, to i tak to jest kropla w morzu potrzeb. Wiem co mówię, bo siedzę w tym parę lat. Na każde zauważone zjawisko błędów reagowałem odpowiednim narzędziem. Tak więc z perspektywy czasu, wiem, że jeśli wypuścisz jakiś swój kombajn, znając typy błędów (te które ja znam), okaże się, że to będzie kombajnusiczek :) Nie piszę, aby Cię zniechęcić, ale sam widzisz, czego się nie dorwiesz, błędy.
-
Chyba nie ma innego sposobu na te błędy i niesamowitą czasochłonność ich poprawiania (a także tworzenia nowych misji) niż zrobienie narzędzia graficznego. Musi być bardzo dokładna, super szybka i wygodna mapa torów i terenu. Wystarczy 2D. Mapa musi być w pełni zintegrowana z porządnym edytorem skryptów. Do tego na koniec wtyczki, umożliwiające operacje na sygnałach, wskaźnikach i torach. Efekt działania każdej wtyczki z prezentacją graficzną i z możliwością wskazania klikiem jednej z opcji. Mam dobre komponenty do tego. Super szybkie, częściowo to już działa. Do zrobienia cała masa detali. Ale jak ruszy silnik, to ruszy poprawianie błędów. Czas na ręczne poprawki nie był stracony. Przynajmniej coś tam się dowiedziałem jak to działa. No i poprawiałem dla siebie, bo lubię jeździć, a jak coś się krzaczy to średnia zabawa. Dzięki za wskazówki, będę miał to na uwadze. Z pewnością moje narzędzie będzie mocno interaktywne. Dużo klikania, żeby automat miał prostsze zadanie.
-
Jeszcze dodam w kwestii przypisań, bo mi się przypomniało :), podobnie jak i Ty jestem fanem automatyzacji i miałem taki system, iż jak doszło do sytuacji niepewnej i człowiek wybrał jakiś tor, to tor ten był już pomijany przy następnych przypisaniach semków. Miało to w założeniu zminimalizować udział człowieka. Jednak okazuje się, że w sceneriach do jednego toru potrzeba przypisań więcej niż jeden raz (np. semki blisko siebie w przeciwnych kierunkach). Automat już nie wykrywał sytuacji niepewnej i błędnie przypisywał. Zrezygnowałem więc z zapamiętywania torów po każdym przypisaniu. Tak na wyrost piszę, bo fanatycy automatyzacji nie mają hamulców :)
No i problem dzielenia toru, gdy dany event w torze jest już zajęty. Mnie on nie dotyczy, ze względu na antyczne exe, Ciebie już będzie dotyczył.
-
A mogę mieć jeszcze inna propozycję niż naprawianie nienaprawialnego? Exe wymaga naprawdę porządnej przebudowy, a eventy to jest najgorszy syf w tym wszystkim (nawet fizyka nie jest takim syfem jak eventy). Chciałbym przejść na coś innego, porządnie zaprojektowanego, co będzie łatwo implementować, łatwo tworzyć za pomocą narzędzi i ewentualnie ręcznie i będzie korzystać z naszych doświadczeń. Ale sam tego nie zrobię, bo mogę coś zrobić po stronie exe, ale nie po stronie narzędzi. Praca pi razy oko na 2 lata (poprawianie tego co jest zajmie więcej), ale myślę, ze warto.
-
Nawet lepiej. Myślałeś o jakimś sposobie konwersji istniejących scenerii?
-
HTD, moim zdaniem lepiej najpierw coś zrobić "po nowemu", a dopiero zastanawiać się jak stare można dostosować do nowego. Robiąc odwrotnie jest się bardziej ograniczonym.
-
Grzegorz, ja jestem za. Tylko problem, kto ma pisac te narzedzia? Ja sie wyeksploatowalem (chyba, ze nabiore sil po detoksie :)). Zostal sie HTD. Moze, niech kolega nic nie robi do tego czasu, aby nie dopadlo wypalenie :). Zagadkowy kolega tmj, na pewno napisalby jakies pozyteczne narzedzia o ile bedzie chcial. Jeszcze kto tam, El Mechanico, kto jeszcze o kim zapomnialem :)? Nie no, Q jeszcze.
-
Dobra, ja mam tyle roboty w pracy, że lepiej na teraz się tym zająć, żeby został później czas wolny na rozwijanie narzędzi do MaSzyny.
W międzyczasie jednak warto ustalić jakiś kierunek, żeby jakieś drobiazgi szło już robić jak ma się wolną godzinkę czy kilka i żeby był już jakiś efekt.
Myślę, że nowy starter bardzo by się przydał. Mam już pierwsze ekrany zrobione, z resztą nawet przy nowym exe i sterowaniu i tak starter będzie potrzebny. Założeniem nowego startera ma być przede wszystkim przyjazny wygląd, nowoczesna grafika kojarząca się raczej z grami AAA, wygodna prezentacja detali scenariuszy takich jak misje, składy, rozkłady jazdy, opisy, konfiguracja.
Rainsted ma wszystko co potrzeba, ale wygląda i działa jak jakaś aplikacja inżynierska. Wygodą obsługi nie grzeszy, jego okno nie da się nawet przenosić normalnymi skrótami windows (ignoruje wszelkie skróty z klawiszem Windows), po przeniesieniu na drugi monitor nadal wyświetla się na pasku zadań głównego monitora. Edycja składów jest toporna i wiesza się. Podgląd mapy jest wolny i bardzo toporny, brakuje dobrego wyszukiwania obiektów i sensownego ich zaznaczania na mapie. Brakuje domyślnego układu graficznego, który umożliwia wyświetlenie na 1 monitorze wszystkich potrzebnych detali misji, a na drugim samej symulacji. Nie zapamiętuje swoich ustawień widoku. W końcu brak trybu jasnego i ciemnego do misji nocnych.
Nowy starter wymaga pełnego parsera skryptów, żeby zrozumieć wszystkie detale scenariusza i misji. Z kolei pełny parser skryptów (niestety w obecnym formacie) będzie potrzebny, żeby kiedykolwiek wprowadzić nowy standard budowy scenariuszy. W końcu coś będzie musiało stare skrypty zaimportować i wyeksportować do nowego formatu. Więc parser nie będzie tylko pustym bajerem, i tak jest potrzebny.
Dalej nowy standard będzie wymagał mapy do wspomagania edycji. Prawdopodobnie również dobrego edytora tekstu do ręcznej modyfikacji skryptów. Uważam, że zewnętrzne narzędzia (poza starterem) powinny być wymagane jedynie do grafiki i programowania. Sama modyfikacja misji powinna się dać wykonywać spod startera - w pewnym zakresie Rainsted to umożliwia. Ale jest to na tyle toporne, żeby napisać to od nowa.
Wydaje mi się, że nowy format oskryptowania misji musi umożliwiać ocenę przejazdu użytkownika. Czyli wykryć kolizję, wykryć przekroczenie prędkości czy zignorowanie sygnału. Przejazd powinien produkować statystykę, którą będzie wyświetlał starter po zakończeniu misji. Czyli przykładowo: czy została ona w ogóle wykonana (warunek - dotrzeć z punktu A do B w czasie C przykładowo), listę błędów (prędkość po W8 nr x przekroczona o 2km/h, zatrzymanie 50 metrów przed W4 nr y, ostre hamowanie, spóźnienie na przystankach ...).
Względnie w podsumowaniu może wyświetlać się też dowolny tekst zdefiniowany w skrypcie.
Stare misje importujemy do nowego formatu. Niestety to właśnie będzie bardzo trudne i będzie wymagać interakcji. Nowy format musi zabraniać umieszczania jakichkolwiek znaczących informacji w torach poza opcjonalnym komentarzem. Każdy tor zamiast nazwy będzie posiadać unikalny identyfikator złożony z jego punktu startowego i końcowego (hex bez najmłodszych bitów). Skrypt będzie mógł się odwołać do toru przez ten identyfikator. Dowolna ilość zdarzeń będzie mogła być przypisana do toru w skrypcie, ale to skrypt powinien definiować zdarzenia i wiązać je z torem, nigdy nie powinno być to w pliku toru.
Oprócz tego każdy aktywny wskaźnik i sygnalizator będzie MUSIAŁ być przypisany do torów obiektem przypisania (nie mylić ze zdarzeniem). Przypisania nie mogą być elementem skryptu, muszą istnieć w osobnym pliku. Skrypt będzie mógł się odwołać do sygnalizatora po identyfikatorze. Myślę, że wysyłanie zdarzeń po torach powinno zostać. W 3 odmianach - wysyłanie zdarzenia do konkretnego toru (wskazuję identyfikator), do odcinka izolowanego, do toru z propagacją - zdarzenie obiega wszystkie tory i może zostać odebrane przez wszystkie obiekty dynamic i sygnalizatory leżące na przebiegu (do powiedzmy jakiegoś punktu zatrzymania którym może być koniec toru, S1, wykolejnica, kozioł oporowy czy co tam się jeszcze wymyśli).
Myślę, że wszystkie istniejące scenariusze da się przepisać tak, aby spełniały powyższe wymagania. Do utworzenia przypisań będzie konieczny edytor z mapą. Mapa musi być na tyle szczegółowa i zintegrowana z edytorem, żeby można było większość wątpliwych sytuacji ogarnąć bez uruchamiania symulatora i innych narzędzi.
Konwersja i rozbudowa exe zajmie około roku, mniej więcej tyle czasu zajmie budowa szkieletu nowego startera, który będzie zawierał cały interfejs do uruchamiania symulacji oraz edytor skryptów z mapą. Za detale konwersji będą odpowiadać wtyczki, które będziemy mogli robić już równolegle i niezależnie. Podstawowa wersja będzie już sobie działać a dalsza rozbudowa będzie dużo prostsza i szybsza. Każdy nowy format definiowania scenariuszy będzie już tylko prostszy i łatwiejszy w implementacji niż to co jest.
Myślę, że taka architektura i plan prac pozwoliłyby na optymalne wykorzystanie czasu. Zamiast się rozdrabniać, planowo po prostu zrobić dużą rzecz, którą później będzie można rozwijać przyrostowo mniejszymi krokami. Ważne jest też, że pierwsze działające wersje będą na Gicie i więcej osób będzie się mogło przyłączyć. Niedziałających nie ma raczej sensu wrzucać na Gita.
Propozycja architektury scenariusza dla MaSzyny 2.x:
[tracks ]<---+ +--->[scripts]<---+
[traction]<---| | |
[terrain ]<---+<===>[bindings]<===+--->[signals]<---+--->[dynamics]
[objects ]<---+ | |
+--->[events ]<---+
Trzymając się historycznych konwencji, nowy starter będzie nazywał się EP09.exe ;) Nowy format scenerii mógłby się nazywać M2.
-
Kilka programów do sortowania już było, wszystkie jakieś defekty miały. Pamiętaj o sortowaniu torów i druta po trajektorii a potem po jakiejś współrzędnej oraz przyklejaniu słupów trakcyjnych do przęseł przewodu. Ra mi kiedyś wypominał brzydkie wywalenie słupów na koniec pliku przy wydzielaniu trakcji na jakiejś scenerii.
Nie wiem, czy Cię dobrze zrozumiałem. Ja kiedyś pisałem narzędzie do wydzielania tematycznie poszczególnych części scenerii i nie było w tym narzędziu, żadnego defektu o ile był dobrze skonfigurowany. Domyślna konfiguracja, była przykładowa i sorry, ale ja nie odpowiadam, za konfigurację, bo komuś nie chciało. To jest defekt, ale użytkownika. Byś może z innymi podobnymi narzędziami, było podobnie.
-
Narzędzia Adama myślę, że będą jak najbardziej do dostosowania. Przy okazji zrobi się konwersję starych scenerii.
Myśli ogólne:
1. Nie da się uniknąć przypisania elementów traktowanych obecnie jako eventy pasywne do torów (wskaźniki, semafory,itp.) gdyż pociąg nie odnajdzie ich, szczególnie że możemy te elementy stawiać po prawej, lewej i u góry.
2. Elementy pasywne powinny być dopisywane do toru za pomocą innego słowa kluczowego niż event tak, żeby tor miał listy takich elementów w zupełnie innym miejscu co ułatwi odnajdywanie i sprawdzanie elementu.
3. Każdy element powinien mieć nadany typ już na etapie parsowania scenerii, np zdefiniowany przez rozszerzenie.
4. Może należy podawać odległość od punkty doczepienia (p1, p2 toru) żeby tego nie rzutować na tor na etapie symulacji, tylko po prostu sobie dodać. Obecnie exe liczy odległość do tych elementów poprzez proste policzenie punktu loka i eventu a powinien po torze, szczególnie że zna swoją pozycję na nim (odległość którą na nim przejechał).
5. Sterowanie scenariuszem to jest wielkie pole do usprawnień. Jeśli można pozostawić jakieś proste eventy do takich rzeczy jak przejazdy to sterowanie całymi stacjami to wg mnie jest kwestia eventu typu uruchom skrypt. Z tym, że to raczej powinien być punkt zgłoszenia, w którym przekazujemy uruchomionemu skryptowi dużo informacji, żeby mógł sobie to wszystko optymalnie policzyć.
Póżniej odniosę się do wypowiedzi HTD bo jestem w pracy.
-
ad 2 i 3: To nie powinno być w ogóle w skrypcie scenariusza. Scenariusz powinien wyłącznie obejmować sterowanie ruchem. Czyli de facto być instrukcją dla automatycznego dyżurnego ruchu. Dyżurny ruchu nie buduje urządzeń SRK. Urządzenia są dane, stacja jest dana, układ torowy, zwrotnice i sygnalizacja są dane. Dyżurny po prostu steruje tym co ma na nastawni. No i komunikuje się z maszynistami na szlaku. Jestem za tym, żeby przypisania były w osobnym pliku i żeby najlepiej symulator to wymuszał, inaczej ludzie znów będą wrzucać rzeczy do jednego wora tak, że będzie problem żeby to w ogóle ogarnąć.
Tak na marginesie to się prosi o nowy wątek. Przy okazji jak już robić coś od nowa lepiej, to może by tak skoncentrować scenariusz wokół obiektu posterunku ruchu, czyli czegoś, czego w MaSzynie na dobrą sprawę nie ma. Stacja, posterunek. Wyobraź sobie, że na scenerii masz główne posterunki ruchu, i każdy posiada własny skrypt który dotyczy tylko tego posterunku. Jeśli misja się krzaczy w okolicach Pcimia, otwierasz plik "pcim.script" i szukasz co tam jest nie tak.
W końcu każde urządzenie SRK przynależy do jakiegoś posterunku ruchu, nie? Na istniejących sceneriach raczej nie widzę obiektów typu "semafor_1_m" tylko przykładowo "pcim_m". Dlatego sceneria powinna mieć swój katalog, w tym katalogu podkatalogi posterunków. W tych podkatalogach przypisania ("pcim.bindings") i skrypty ("pcim.script"). Reszta nie musi być tak podzielona. Tory i inne obiekty, nawet cała sygnalizacja - wszystko może siedzieć w głównym katalogu scenerii. Te rzeczy mogą pozostać bez większych zmian.
Kolejna sprawa to opcje wyglądu scenerii. Nie orientuję się w tym za dobrze, ale z tego co wiem wiele obiektów ma wersje dzienne i nocne, zimowe a nawet jesienne. To nie powinno być na sztywno ustawiane w scenerii i nie powinno wymagać jej dublowania celem uzyskania powiedzmy misji w Całkowie zimą. Może w definicjach obiektów można by zrobić jakąś wersję opcjonalną, że jeśli exe chce zimy, to sprawdza czy jest tekstura czy model zimowy i ładuje go zamiast domyślnego. Czyli przykładowo jak ładuje ludzików, to w kurtkach i czapkach.
A nawet jeśli dublowanie ma swoje plusy i jest pożądane w tym wypadku, to dublowane powinny być wyłącznie fragmenty związane z wyglądem scenerii, a nie przykładowo układem torowym czy sygnalizacją. Bałtyk i Bałtyk-zima to zdublowana sceneria, w której jednak nie zgadzają się nazwy torów, a skrypty od jednej nie pasują do drugiej. Z resztą nie ma nawet możliwości żeby to pasowało, skoro można je sobie rozłącznie zmieniać jak się komu podoba. Gdyby używały większości wspólnych plików dawałoby to opcje wyboru pory roku w starterze.
Coś co chcę koniecznie zrobić w starterze to wybór czasu rozpoczęcia misji, dokładnie jak jest w TD2 (i kilku innych symulatorach). Nie ma problemu, żeby przeliczyć wszystkie rozkłady na scenerii względem nowej godziny. Oczywiście zalecany jest czas domyślny, bo autor miał jakiś zamysł wybierając taki a nie inny czas i będzie on przeważnie optymalny.
Nie ma potrzeby istnienia osobno scenerii Drawinowo i Drawinowo-noc. Fajnie, że teraz są, bo są inne składy do prowadzenia na nich, ale z drugiej strony gdyby starter miał przyjaźniejszy wybór składów (który się nie sypie po pierwszym uruchomieniu symulacji) - to składy by sobie każdy mógł wybrać (najlepiej z jakiejś listy zalecanej dla scenerii - czyli np na scenerii bez drutów nie powinny pokazywać się w menu elektrowozy i EZT).
-
Zgodnie z obietnicą:
1. Format binarny scenerii: już jest jeden, nazywa się RSF. Nie widzę możliwości łatwego wprowadzenia. To nie jest kwestia wrzucenia do exe. To jest kwestia edytora. Na pierwszy rzut odpada, na drugi rzut można zrobić konwerter w dwie strony, ale nie sądzę żeby po modernizacji parsera dało się osiągnąć jakieś większe zyski na ładowaniu scenerii, a tracimy na elastyczności i kompatybilności.
2. Nie zaimportujesz starych misji do nowego formatu. Już zmiana sposobu uruchamiania skryptów spowoduje, że przenoszenie logiki będzie awykonalne. Można ewentualnie stworzyć nowe mechanizmy próbując nie zniszczyć starych.
3. Propagacja po elementach: to jest już zabawa w dyżurnego ruchu, ale nie widzę sensu ładowania tego w exe, gdyż sama logika każdego elementu w przebiegu zebrana do exe to jest nowa binarka, wiem, bo już taką napisałem. Niestety napisałem w Visual C++.net ver 1.1 i jest obecnie nieprzenaszalna bez poważnych modyfikacji (SortedList kiedyś nie miały przechowywanego typu i tego typu zabawy).
4. Rozdzielenie zdarzeń od torów: obiekty dynamic poruszają się po torach. Więc to tor musi mieć listę wskaźników na elementy interaktywne. Inaczej bawisz się w przeszukiwanie tablic, a po co. Ale jak najbardziej fizyczne rozdzielenie przypisania do opisu elementów (tak jak obecnie eventy niejawne) jest zalecane. Ponadto wymagane jest pozostawienie rozdzielenia na kierunki zadziałania / skanowania.
5. Jeśli pisać dyżurnego ruchu to opis misji musi mieć zupełnie oddzielny plik w którym jest także rozkład jazdy. Ale to jest naprawdę ogromna skala wyzwań, związanych m.in. z opisem scenerii, które muszą być spełnione, aby to działało.
6. Można zautomatyzować tworzenie odcinków izolowanych jeśli będą przypisane wszystkie semafory, do ręcznych poprawek na późniejszym etapie.
Co zrobić z obecnym formatem scenerii?
Nie widzę możliwości utrzymania plików inc w takiej formie jakiej są obecnie. Na starcie trzeba nadać podstawowe typy obiektów, które są wstawiane, gdyż ten plik tak samo może mieć rozszerzenie scm, ctr, czy jakkolwiek inne i nie ma to znaczenia. Chciałbym rozpoznawać typ po rozszerzeniu: 1. Łatwo sprawdza typ obiektu i może inicjować osobny, zoptymalizowany parser tylko dla niego z indywidualną składnią; 2. Łatwo rozpoznać typ w katalogu, choćby posortować po rozszerzeniu.
Co z rozkładem jazdy?
Tutaj to już zostaje tylko całkiem nowy format, starego nie da się utrzymać. W nowym oprócz samego rozkładu powinna być część odpowiedzialna np. za manewry, zmiany kierunku, nadanie nowego rozkładu i takie tam.
-
Zgadzam się ze wszystkim. Może poza tym, że nie da się skonwertować starych scenerii. Dlaczego ma się nie dać? To nie będzie może proste, ale wykonalne. Masz przykładowo teraz eventy. Wyzwalane przez tor. Wywalasz wyzwalanie z toru, przenosisz do skryptu. Nowy format skryptu scenerii będzie przecież jak najbardziej obsługiwał zdarzenia typu "skład wjechał na tor x w kierunku y". Czyli możesz w tym skrypcie umieścić takie zdarzenie. Sterowanie semaforami i zwrotnicami można przenieść prawie w całości.
Domyślam się w czym jeszcze leży problem: od dawna postulowałeś (z resztą, swojego czasu @Ra chyba też), żeby nie dotykać semaforów bez potrzeby, nie sterować ruchem całkowicie ręcznie. Tzn skrypt ustawia przebieg, ale nie zapala sygnałów, sygnały się zapalają w zależności od przebiegu i ruchu składów. No i większość istniejących scenariuszy by z tym się gryzła. Ale jest na to sposób. Opcja manual i auto przełączana w skrypcie. W manualu wyłączasz całą automatykę sygnalizacji. Semaforki się zapalają tylko jak im każesz skryptem. Może z wyjątkiem SBL-ki. Nie widzę potrzeby sterowania nią ręcznie. A jeśli skrypt próbowałby wysłać coś poza Sz do semafora SBL to powinno być ignorowane, a nawet wylecieć przy konwersji.
W sumie nowy format będzie umożliwiał wszystko to co stary format, poza jedną rzeczą: nie wolno w torach umieszczać zdarzeń sterujących, muszą być w skryptach. Tak samo z resztą najlepiej zrobić z przypisaniami. Ani w torach, ani w skryptach, w osobnych plikach najlepiej. No ale to w zasadzie jest trywialna zmiana i to dałoby się skonwertować w pełni automatycznie. Tzn efektem konwersji automatycznej byłaby sceneria która działa, aczkolwiek nie ma większości rzeczy przypisanych i sterowana jest w pełni manualnie. Przejście na full-auto wymagałoby już w zasadzie napisania scenariusza na nowo - ale byłoby to łatwiejsze mając automatyczną obsługę SRK.
Co do rozkładów i opisów misji - oczywiście, nowy format jest konieczny. Moje narzędzie może produkować z tego PDF-y, nie ma sensu, żeby się bawić z tym w jakiś Wordach i Excelach. Nowy rozkład powinien zawierać wszystko, co jest potrzebne do wygenerowania takiego PDF-a. Do tego być prosty. JSON? A może CSV?
Co do formatu binarnego scenerii - bajer. Może być, może nie być. U mnie i tak przez 99% czasu ładują się tekstury. To jest IMHO trywialny problem.
Ostatnia sprawa: język. C++ to taki język, w którym proste rzeczy są koszmarnie trudne. Ten język ma zastosowanie wszędzie tam, gdzie zasoby sprzętowe są mocno ograniczone, a i można zainwestować dużo czasu i pieniędzy w developerkę. Do tego robi się coś raz "na fest" i nie dotyka przez lata. Ale robienie skomplikowanej logiki w tym języku to jak budowa komputera z wiadra tranzystorów i bramek logicznych. Kiedyś wszystko się robiło z elementów dyskretnych, teraz prawie nikt się w to nie bawi, nawet jeśli jest to prosty sterownik silniczka, to wrzuca się mu jakiś seryjnie produkowany procesor i po krzyku.
Największym deficytem projektu jakim jest MaSzyna nie są zasoby sprzętowe, a czas pracy developerów. Na wagę złota jest nie krzem, a czas wymagany do wprowadzenia jakiejś funkcjonalności a także czas potrzebny na rozwój. C# sprawdziłby się lepiej. No ale przejście nie byłoby łatwe. Baza kodowa jest potężna. Ale szaleć to szaleć ;) Jak dla mnie optymalne byłoby połączenie C# z C++ (a jeszcze lepiej Rustem zamiast C++, tylko kto zna Rusta?). W końcu nie bez powodu pojawił się w MaSzynie Python, problem w tym, że Python jest dość wolny. Ciężko byłoby go używać do dużych obliczeń fizyki w czasie rzeczywistym. Ale C# dałby radę z dużym zapasem. Przy czym ogromny skok kompatybilności, framework oddziela program nie tylko od metalu, ale i od bebechów systemu operacyjnego, które mogą się zmieniać. To mogłoby nawet na upartego stać się realnie wieloplatformowe. No ale wiem, to już czyste fantazje.
Co do "strasznego GC" - to dziś bardziej mit niż fakt. Głównie ze względu na to, że Windows i tak stosuje prawdziwą wielozadaniowość z wywłaszczeniem i to bardzo konkretnym wywłaszczeniem. Nie ma zmiłuj, jak OS postanowi sobie zwolnić trochę pamięci czy wykonać inne "super ważne zadanie", będzie zacinka, chociażby program był pisany w czystym assemblerze. Czas rzeczywisty w systemie takim jak Windows jest raczej nieosiągalny dla user-space. Jedynie na poziomie sterowników i jądra. Owszem, zbiórki GC mają swój koszt, ale na tyle niewielki, że na dzisiejszym sprzęcie jest to prawie niezauważalne. Druga sprawa, że działanie GC da się zoptymalizować tak, żeby w ogóle nie przeszkadzało. Na upartego nawet bezczelnie obejść i zabronić w krytycznych fragmentach.
I druga strona medalu - programując z niskiego poziomu można docisnąć CPU i nie grać fair z resztą systemu. I mamy potem gry z których ciężko zrobić Alt+Tab żeby wyjść na chwilę odpisać na ważnego maila. Jak dla mnie dla kilku dodatkowych FPS kompletnie nie warto. Wolę takie, które nie biorą sobie 101% zasobów systemu i zostawiają jakąś niewielką funkcjonalność tła. A jak mi czasem FPS spadnie na chwilę z 60 do 40, da się przeżyć. Jeszcze jedno - w C++ zrobienie dobrego kodu wielowątkowego korzystającego z wielordzeniowych CPU to zadanie dość ambitne i trudne. To samo w C# jest niemal trywialne. No dobra, amator nie zrobi stabilnej synchronizacji wątków, ale .NET ma niesamowite automaty zrównoleglające wątki. Jak wiesz jak tego użyć, oszczędzisz miesiące czasu. Przy okazji źródła są czytelne i mniej podatne na błędy. Robiłem tez test polegający na przydzieleniu przemieleniu kilku GB (powyżej 4) w C++ i C#. Różnice wydajności były pomijalne. Jasne, wersję w C++ można by zoptymalizować tak, żeby banglała 100x szybciej, ale to już byłby ASM i programowanie pod konkretny sprzęt, głównie CPU.
-
W nawiazaniu do punktacji i tego typu rzeczy i innych tam badziewow, jedna z opinii. Warto wysluchac calosc. Wiem, ze ten temat w zasadzie nie powinien byc dyskutowany na tym etapie, jednak mnie korcilo :)
-
Zastanawiałem się. Abstrahując od dywagacji użycia C#, które osobiście lubię, ale jednak tylko Unity używa go jako języka skryptowego, a pozostałe silniki nie, to problem leży w tym, że pozostałe silniki używają C++ i radzą sobie z dużymi sceneriami a Unity nie ;) Nie sadzę żeby to był problem samego .net tylko bardziej implementacji silnika, który powstał w troszkę innych celach i teraz to się mści przy większych projektach.
Przechodząc do meritum, to wydaje mi się, że można napisać "prostego dyżurnego ruchu", który nie będzie bazował na odcinkach izolowanych, jednak wtedy do torów będzie trzeba zrobić specjalną logikę odpowiedzialną za interakcję, tudzież tworzyć obiekty równoległe. Ogólnie jak robiłem poprzednią implementację to opierałem się na założeniu, że twórca nie powinien dostawać więcej niż elementy do złożenia torów, a cała reszta ma się dziać automagicznie. Nawet działało.
Kwestia napisania skryptów scenariusza to jest zapis idei sterowania. Powinno być jak najprostsze. Czyli podajesz dla każdego składu miejsce wjazdu, tor pośredni, tory opcjonalne, miejsce wyjazdu, prawdopodobieństwa zdarzeń. To może być w formie języka programowania lub opisu, przy czym opis wygląda na bardziej uniwersalny jeśli będzie miał odpowiedni format pliku. Najtrudniej będzie uwzględnić wariantowanie przebiegów w zależności od sytuacji ruchowej. Myślałem nad YAML, JSON też może być. Pierwotnie robiłem w XML, ale toto się nie nadaje do szybkiego pisania ręcznie.
-
W sumie racja: przy założeniu, że każdy sygnał jest przypisany do toru - nie ma problemu z takim sterowaniem. Przebieg z punktu A do B złoży prosty algorytm typu back-tracking (a lepszy algorytm ułoży jeszcze optymalny, najszybszy przebieg). Ale to jest proste tylko wtedy, kiedy tory nie są współdzielone przez poruszające się w tym samym czasie składy. To troszkę się skomplikuje. W takim układzie musiałbyś zrobić symulację ruchu składów po przebiegach, żeby obliczyć w którym punkcie przebiegu są w danej chwili, uwzględniając postoje na przystankach.
Jak już to masz, możesz uzyskać odcinki konfliktowe - czyli takie, które w czasie + / - powiedzmy 5 czy 10 minut są na trasie więcej niż jednego składu. I dalej wydaje mi się, że są 2 opcje - nadajesz im priorytety, i skład B musi czekać aż A zwolni konfliktujący tor. Albo druga opcja - próbujesz ułożyć inny przebieg.
Dobra, sprzedane, to ma sens, da się zrobić.
Dobra, mapa będzie potrzebna, więc robię, no i przypisanie obiektów do torów też będzie potrzebne. Pół automat, co da radę niech dopasuje sam, czego nie da rady, niech pyta i mu się przeklika. Byłoby super, jakby się dało zrobić podgląd 3D fragmentu dla orientacji... A w sumie czemu nie? A gdyby tak wziąć zbiór obiektów ze scenerii, odfiltrować po współrzędnych, żeby ładować tylko te, które się mieszczą w pewnej odległości od punktu - to byłoby bardzo niewiele do załadowania i pozwalałoby na bardzo szybki podgląd za pomocą exe symulatora. Tylko wywalić ten komunikat "player train does not exist".
Robisz exe, super, pisałeś, że brakuje edytora 3D. Na razie wystarczy podgląd. Dołóż do exe celownik, tryb "pomiarowy", w którym nie interesują nas w ogóle parametry pociągu a za to elementy scenerii. Zrób wstawianie celownika jako płaszczyzny (zgrywanie współrzędnych płaszczyzny do pliku). Za pomocą prostokąta wstawianego w silniku graficznym i zapisywania jego współrzędnych można sporo zdziałać w kwestii wstawiania obiektów na scenerię BEZ jakiegokolwiek edytora 3D. Kolejna sprawa - słupki kilometrowe. Irytujące jest, że brakuje ich na różnych odcinkach scenerii. Albo są nierówno rozstawione. Albo w niektórych miejscach są jakieś za małe i nieczytelne. Przydałaby się funkcja w exe która podaje odległość w metrach po łuku toru od ostatniego słupka kilometrowego do punktu wskazanego na torze. No i funkcja w edytorze, która powstawia brakujące słupki automatycznie.
-
Jak już to masz, możesz uzyskać odcinki konfliktowe - czyli takie, które w czasie + / - powiedzmy 5 czy 10 minut są na trasie więcej niż jednego składu. I dalej wydaje mi się, że są 2 opcje - nadajesz im priorytety, i skład B musi czekać aż A zwolni konfliktujący tor. Albo druga opcja - próbujesz ułożyć inny przebieg.
Rozkłady powinny wykluczyć takie sytuacje, ale wiadomo... Skromnie dodam, ułożenie innej drogi odpada, nie zawsze można. Priorytet, zawsze taki sam, bardziej spóźniony ustępuje miejsca.
-
No nie zawsze, bo planowy towar ma puszczać opóźniony ekspres.
Te bajery z podglądem na silniku symka to w exekach Q w jakiejś części były.
Słupki hektometrowe każdy edytor wstawia bez większych problemów. Rainsted nawet ma opcję rozciągania zakłamania kilometrażu na krzywych sceneriach. ;)
-
No, jak chcesz implementować podgląd 3d to już lepiej zaimplementuj własny, niż używanie exe. Ono jest wystarczająco skomplikowane. To nie musi być super wypas tylko zorientowanie się, więc myślę, że da się bez problemu zrobić na bibliotekach .net-a.