- Symulator MaSzyna -
Symulator EU07 (i nie tylko) => Pomoc w tworzeniu => Wątek zaczęty przez: Quark-t w 11 Marca 2012, 21:19:32
-
@loha.
Pytanie do scenarzystów - jakie uzaleznienia od razu w trasie są najbardziej przydatne podczas pisania nowych misji? Zwłaszcza na "cudzej" scenerii?
- Wygaszanie semaforów wjazdowych/wyjazdowych po minięciu;
- Działająca SBL i SHP;
- SBL "ciemna" w kierunku przeciwnym;
- W4 i stoppointy;
Coś jeszcze? O logicznym, spójnym i zgodnym z zasadami nazywaniu elementów (zwrotnice, semafory) nie mówię, bo to logiczne. Czy pisanie gotowych przebiegów od razu ma sens?
-
Pisanie gotowych przebiegów ma sens jeśli mówimy o multiplayerze. Ra kiedyś zlecił mi wypisanie możliwych przebiegów na Krzyżowej. Zadanie to kontynuował Libertyn. Projekt ucichł. Do Twojej listy dodałbym:
- eventy związane z W6 dla AI
- otwieranie i zamykanie przejazdów oparte zwłaszcza na odcinkach izolowanych
- przechwyt z sygnalizatora za pomocą sem_info
- koniec granicy przetaczania związanej z W5 dla AI. W ten sposób AI rozpędza się do prędkości zadanej w srjp
- eventy mówiące o ograniczeniu związane z W9. Aczkolwiek tu się mogę mylić, gdyż chyba można to zastąpić używając velocity w torach
- zdarzenia włączające i wygaszające TOP-y. Ogólnie powiązanie semafora z TOP-em
Tak mniej więcej powinno się to robić żeby było dobrze. Do tej pory tak nie robiono ze względu na niemądre zachowanie AI. Nikt nie myślał o rozkładach czy ograniczeniach. Zastępowano wiele z tych punktów hybrydami. Dzięki Ra jest już możliwość stworzenia scenariusza z prawdziwego zdarzenia, zamierzam to wszystko wykorzystać na MOP-ie. Mam nadzieję, że się uda.
W kwestii "uzależnień eventowych". Należy też zwracać uwagę na ułożoną drogę przebiegu i ochronę pozostałych torów (po których przebieg się nie odbywa). Niewielu o tym pamięta. Można sobie popatrzeć na scenariusze z PC2010.
-
1. Byłoby fajnie - obecnie event wygaszający dodaję do innego eventu, który jest następny w kolejce, żeby nie pisać kolejnych eventów, bo mi się nie chce. Niewątpliwie podniosłoby to realizm i oszczędziło klawiaturę scenarzysty.
2. Też ważne, ale nie miałem z tym jeszcze do czynienia.
3. Jw.
4. To nowość, przyda się do misji osobowych.
Jak do tej pory nie spotkałem się z problemem związanym z brakiem sem_info, ale 2 osoby pisały do mnie, że mają z tym problem - AI mija S1. Z tymi przebiegami to nie wiem czy to będzie miało sens - np. w scenerii będzie na sztywno 200 linijek kodu odpowiadającego za przebiegi, podczas gdy można samemu napisać jednego multipla, nie potrzebujemy ustawiać wszystkich przebiegów na scenerii jednocześnie.
EDIT.
Przeglądam jeszcze plik RFC i myślę co by można było jeszcze dodać czego @Benek jeszcze nie wymienił. Na pewno przydałoby się, żeby tory, na których ładuje się węgiel lub inny surowiec (np. na Quarku) miały już zrobione zdarzenia ładujące/rozładowujące wagony, z tym że, żeby były aktywne trzeba by było jedynie zmienić wartość jakieś memcella. Można by było to ugryźć jak przejazdy, tak żeby scenarzysta odpalając jeden event, np. Dejawy_load nie musiał się martwić o pozostałe.
-
1. Byłoby fajnie - obecnie event wygaszający dodaję do innego eventu, który jest następny w kolejce, żeby nie pisać kolejnych eventów, bo mi się nie chce. Niewątpliwie podniosłoby to realizm i oszczędziło klawiaturę scenarzysty.
Jednak jeśli następny event masz za 10km to raczej semek się nie wygasi dopiero wtedy bo taki przypadek to w życiu realizmu nie wąchał. :) Jeśli masz event po evencie np.: manewry na stacji to wtedy to jest dobra opcja jednak na trasie to odpada. Wtedy pozostaje napisać event wygaszający i dopisać do toru za semaforem.
-
Yoda - ale tu nie chodzi o komentowanie "że tak się nie robi" tylko co jest przydatne.
W pierwszej wiadomości nie pisałem o chociażby _sem_info, bo wydawało mi się to logiczne. Natomiast po Waszych wiadomościach postuluję o nie pomijanie czegokolwiek, spróbujemy zrobić pełną listę, bez względu na "oczywistą oczywistość" rozwiązań.
-
Umyka mi cel tej listy ;)
-
Umyka mi cel tej listy ;)
Krótko - skleroza autora (mnie) oraz posiadanie listy z elementami do "odhaczania". Poza tym, tak dawno robiłem scenerię, że od tamtego czasu wiele się zmieniło. I po prostu nie chcę być w tyle :) A może i do SPT się przyda, aby część rzeczy robiła się w edytorze z automatu. Prościej mieć listę, niż na bieżąco wymyślać "a może to".
A jeszcze krócej - nie czepiaj się wątku admina :D
-
Natomiast po Waszych wiadomościach postuluję o nie pomijanie czegokolwiek, spróbujemy zrobić pełną listę, bez względu na "oczywistą oczywistość" rozwiązań.
Oczywistą oczywistością jest to, że sem_info powinno być. Nie ma go jednak wszędzie tam gdzie byśmy chcieli. Dlatego też o tym napisałem.
-
1. Byłoby fajnie - obecnie event wygaszający dodaję do innego eventu, który jest następny w kolejce, żeby nie pisać kolejnych eventów, bo mi się nie chce.
Event wygaszający semafor powinien być za tym semaforem w torach. Niebawem powinny się ukazać urządzenia przytorowe, tam bodajże jest ta puszeczka odpowiedzialna za S1 na semaforze. Tak będzie najbardziej realistycznie. Nie wspominam już, że dwa AI mogą jechać za sobą po tym samym torze, wtedy wygaśnięcie S1 zaraz za semaforem jest musem.
-
Słuchajcie, wygaszenie po minięciu semafora mamy już obgadane :)
-
Nie wspominam już, że dwa AI mogą jechać za sobą po tym samym torze, wtedy wygaśnięcie S1 zaraz za semaforem jest musem.
Od kiedy pociągi jeżdżą za sobą na ten sam sygnał?
-
Benkowi raczej chodziło o jazdę na odstęp.
-
A co w sytuacji gdy na torze stoją dwa pociągi -luzak a za nim np jakiś towarowy?. Luzak dostaje wyjazd i teraz pytanie jak zachowa się AI za luzakiem? W rzeczywistości takie rzeczy się zdarzają jak dyżurny nie ma wolnych torów, albo lok prowadząca odczepia się od pociągu i jedzie później w innym planie.
-
A, "musem"... Przeczytałem "minusem". :(
-
Benkowi raczej chodziło o jazdę na odstęp.
Tak, o to właśnie chodziło. Wiem, że się nie znam, no ale coś tam w końcu o tej kolei wiem.
-
Niebawem powinny się ukazać urządzenia przytorowe, tam bodajże jest ta puszeczka odpowiedzialna za S1 na semaforze. Tak będzie najbardziej realistycznie.
Nie jestem znawcą SRK, chyba to bardziej działka ZiomalaCl, ale czy przypadkiem to nie jest zwykła puszka od obwodów torowych? Przecież są jedne i te same obwody torowe dla każdego sygnału/semafora/rozjazdu/wykolejnicy/blokady liniowej/etc, a za wygaszenie odpowiadają przekaźniki (w nowszych systemach kompy), które "wiedzą" kiedy mają wygasić sygnał na podstawie stanu zajętości obwodu torowego. Dobrze mówię?
-
A co w sytuacji gdy na torze stoją dwa pociągi -luzak a za nim np jakiś towarowy?
Robiłem kiedyś testy jazdy AI (w zasadzie zatrzymywania) na takiej scenerii, gdzie były dwie tarcze (pewnie jeszcze gdzieś jest jako załącznik). Jedno AI widzi sygnalizator, a drugie kolizję z tym pierwszym. Pierwsze reagowało na Ms2 i jechało, a drugie zanim się zebrało, to tarcza była już wygaszona. Także to jest przetestowane i działa.
-
SKP, tak właśnie jest, tabor znajdujący się na danym odcinku izolowanym powoduje odwzbudzenie przekaźnika torowego, co wpływa następnie na inne urządzenia.
-
Jeśli już mielibyście się zdecydować na przebiegi, to trzeba iść jeszcze dalej. Może zrobić takie uzależnienie, że jeśli którykolwiek z torów w danym przebiegu będzie zajęty, wyświeci się S1? Wtedy nie trzeba by było pisać osobnych eventów dla wygaśnięcia S1, a symulacja byłaby jeszcze bardziej realistyczna. W symulatorze niejednokrotnie się zdarzało, że skład AI z niewiadomych przyczyn się rozerwał i wagony wjechały na nasz tor, w ten sposób byśmy się zabezpieczyli przed takim wypadkiem, a nawet błąd wyglądał jak zamierzony efekt w scenariuszu - z tym, że najprawdopodobniej dalej nie pojedziemy. Tylko pytanie czy zrobienie takich przebiegów w ten sposób jak ja zaproponowałem nie zajmie więcej czasu niż, żeby Ra miał przepisać EXE do Assemblera.
-
Ja bym proponował losowe zdarzenia a konkretnie na większych stacjach na różne perony. Sytuacje w towarowym: np. Mamy mieć przelot a dyżurnemu się pomyliło i bierze nas na bok i dalej na szlak. Chodzi mi o takie sytuacje jakie są na prawdę na kolei.
-
Robiłem kiedyś testy jazdy AI (w zasadzie zatrzymywania) na takiej scenerii, gdzie były dwie tarcze (pewnie jeszcze gdzieś jest jako załącznik). Jedno AI widzi sygnalizator, a drugie kolizję z tym pierwszym. Pierwsze reagowało na Ms2 i jechało, a drugie zanim się zebrało, to tarcza była już wygaszona. Także to jest przetestowane i działa.
Pytanie, jak to zadziała po ostatniej poprawce na prowadzenie przez AI pojazdów z większą prędkością. Poprzednio przy prędkości 120 km/h AI wyszukało ewentualnej kolizji na 7,2 km do przodu - obecnie będzie to tylko ok. 1,5 km. Czyli obecnie pojazd jadący z tyłu będzie się trzymał 'bliżej' jeśli dobrze rozumuję. Nie powinno być problemów, ale może warto przetestować, kojarzysz gdzie ta sceneria jest wystawiona?
-
Moim zdaniem będzie to działać tak samo. Pojazd zatrzymuje się ok. 50m przed kolizją. Natomiast poprawiona odległość dotyczyła wysyłania SetProximityVelocity, czyli ostrzegania o potencjalnej kolizji. Ogólnie cały ten mechanizm jest do przerobienia (aby AI widziało sygnalizatory bezpośrednio, bez przesyłania komend i musi być tabelka rozróżniająca poszczególne ograniczenia), ale to jest zajęcie na dłużej i nie jest pilne.
Sceneria testowa Tm jest tu w załączniku:
http://eu07.pl/forum/index.php/topic,19161.msg220692.html#msg220692
-
Potwierdzam - sprawdziłem sobie przy okazji testowania jazd AI po SBL. Swoją drogą SBL w symku ma dwie wady - AI ma problem z sensownym zatrzymaniem się i minięciem semafora z S1 (bo jak już minie, to jedzie 20 km/h ładnie) oraz samo w sobie sterowanie wskazaniami semaforów. O ile pociągi nie zatrzymują się gdzieś na odstępie i jest ich niewiele, to jest ok. Ale jeśli już jakieś AI wjedzie na zajęty wcześniej odstęp - zjazd pierwszego składu powoduje wyświetlenie sygnału zezwalającego na semaforze osłaniającym odstęp, co przy znajdującym się tam drugim składzie jest "be".
-
Do tego wypadałoby użyć odcinków izolowanych — właściwie to powinien być teraz standard.
-
Na bazie eventu AddValues oraz komórki pamięci można zrobić "licznik osi". Komórka pamięci powinna być początkowo ustawiona na 0. Jedna komórka może obsługiwać dwa tory albo dwa kolejne odcinki. Wykonanie eventu licznika osi powinno powodować zwiększenie bądź zmniejszenie licznika, zależnie od kierunku jazdy. Można również korzystać z Multiple i jednocześnie zmniejszać w jednej, a zwiększać w drugiej komórce.
-
Czyżby chodziło Ci o identyfikację składu i wpuszczenie go na dany tor na stacji?
-
Nie, o odpowiednik licznika osi (http://pl.wikipedia.org/wiki/Licznik_osi).
-
Na bazie eventu AddValues oraz komórki pamięci można zrobić "licznik osi".
Tak w kwestii doprecyzowania - czy jest możliwość liczenia osi tym eventem, czy to na razie propozycja?
Cofam pytanie. Wpadłem już na to, jak liczyć osie. Zrobiłem krótki odcinek toru, taki żeby mieściło się na nim tylko jedno koło. Odcinek izolowałem. Każda oś zjeżdżająca z niego uruchamia event *:free, który powiększa wartość w komórce (addvalues).