Symulator EU07 (i nie tylko) > Na warsztacie
Zastąpienie eventów językiem skryptowym
Milek7:
Obecny system eventów jest dość prymitywny i zrobienie na nim bardziej złożonych scenariuszy wymaga okropnych konstrukcji z kaskadami multiple. Zamiast próbować rozszerzać do używalności składnię tego co już jest, planuję użyć pełnego języka skryptowego.
Z prostych do zabudowania w symulatorze języków jest Lua lub Squirrel. Mimo że składniowo Squirrel jest zdecydowanie bardziej ogarnięty (Lua ma kilka bzdur, takich jakich begin..end, czy numerowanie tablic od 1), stawiałbym na Luę 5.1 ze względu LuaJIT, które ma świetne C FFI co znacząco ułatwi tworzenie bindingów w exe, jak i kompilator JIT co znacząco poprawi wydajność kodu (i o ile w przypadku eventów to jest bez znaczenia, to w przyszłości planuję też na luę przepiąć pythonowe wyświetlacze).
Oczywiście nie przepiszemy wszystkich scenariuszy w jeden dzień na skrypty, więc zostaną one doczepione do istniejącego systemu eventów - skrypty będą mogły rejestrować eventy które będą normalnie widoczne przez stary system, a także wywoływać stare eventy.
No i w tym wątku prosiłbym o opinię oraz życzenia funkcjonalności (ponad te dostępne już w eventach) które mają pojawić się w skryptowym API.
Mariusz1970:
Kiedys juz sie troche sprzeczalem w podobnym temacie. Postaram sie w skrocie przedstawic swoja opinie. Na temat tych jezykow skryptowych, ktore proponujesz, to sie nie wypowiem, bo ich nie znam. Nie mam pojecia, czy one ulatwia czy tez nie pisanie scenariuszy przez Kowlaskiego nieprogramisty. Otoz moje zaloznie jest takie, ze powinnismy unikac sytuacji, ktora bedzie implementowala cos od programisty dla programisty. Zalozyc nalezy, ze Kowalski piszacy scenariusz, programista nie jest i nawet nie chce nim zostac, chcac napisac scenariusz. Jesli mamy zrobic duzy skok, to pisanie scenariuszy powinno sie sprowadzac, iz Kowalski na wejsciu podaje potrzebne dane o pociagu (gdzie, skad, dokad, o ktorej, przez co) ma jechac (czyli wszystkie niezbedne dane), a nazwijmy to "system" robi sam, automatycznie wszystko, aby to zrealizowac. Uzytkownik nie powinien w ogole wchodzic w szczegoly, jak to tam dziala ten system, jaki jest uzyty jezyk itp.
Kwestia teraz jest taka, ze aby mogly powstac fundamenty tego systemu, to potrzeba jest uzycia np. tych jezykow skryptowych, ktore proponujesz, to jestem jak najbardziej za. Jesli natomiast na tych fundamentach sie zatrzymamy, to duzego pozytku dla Kowalskiego nie widze z tego co proponujesz.
Balaclava:
Postulowałem kiedyś o wprowadzenie do plików SCN takiego mini języka, który na przykład pozwoliłby ustawiać include za pomocą pętli. Wtedy prosto można by napisać np. skrypt sadzący drzewka. Jeżeli chodzi o eventy, to faktycznie lepsze byłoby coś w stylu dyspozytora AI w połączeniu z tym, o czym pisze Mariusz. Ponadto uważam, że praktycznie każde zdarzenie na scenerii powinno być losowe, aby nigdy nie można było przewidzieć jej przebiegu - to taka luźna opinia, niepowiązana bezpośrednio z tematem.
Kacper9:
Innymi słowy SCS'owy ANP w symku?
carmel4a:
To o czym piszecie da się zrealizować w dobrym API, w języku skryptowym. Podejście takie jest o tyle dobre, że Kowalsy, jak i programiści będą mieli to samo API. Tylko będą je wykorzystywać w różnym zakresie. Może przeciesz istnieć metoda _dodaj_pojazd(parometry) jak i ustal_przebieg() ;>
Ps. nazwy to tylko przykłady by pokazać o co mi chodzi. Powynny być po angielsku. API powinno być otwarte.
Ps2. ba - takie podejście umożliwi zrobienie takich "trainzowych" i "raillwordsowych" edytorów misji - ładnych nakładek/edytorów do API.
Nawigacja
[#] Następna strona
Idź do wersji pełnej