- Symulator MaSzyna -
Symulator EU07 (i nie tylko) => Na warsztacie => Wątek zaczęty przez: jakubg1 w 27 Stycznia 2023, 22:37:10
-
Ogłoszenie: Jeśli umiesz programować w C++, masz dużo wolnego czasu i chciałbyś pomóc w refactoringu kodu MaSzyny, napisz do mnie PW. Każdy, kto potrafi pomóc jest mile widziany!
Cześć. Jako że ostatnio programistów exe jest jak na lekarstwo, a ostatnio udało mi się skompilować exe do generowania mmd do generatora paczki, pomyślałem, że fajnie by było trochę kodu tam też naskrobać. Przedstawiam więc listę moich pomysłów, które chciałbym zrealizować w bliżej lub dalej nieokreślonym czasie. Niektóre to surrealistyczne porywanie się z motyką na słońce - na pewno nie dam rady zrobić ich na początku.
Od razu zaznaczam, że strony stricte renderera nie chcę tykać - żadne nowe algorytmy renderowania, generowanie kropel na szybie czy inne graficzne wodotryski to stanowczo za dużo czytania dla mnie i nie chcę tego implementować. Przynajmniej nie w najbliższym lub bliżej nieokreślonym czasie.
Jak chcecie, dajcie znać które z tych pomysłów są najbardziej oczekiwane, to może posortuję według priorytetu.
- Oddzielne dźwięki zewnętrzne i wewnętrzne @Miłosz Dorsz
- Możliwość płynnej regulacji położenia elementów sterowanych universalami (okna, drzwi, rolety itp.) @Irek_Wd
- Zmiany na szeroką skalę w edytorze scenerii:
- Podświetlanie obecnie zaznaczonego obiektu.
- Poruszanie obiektami w zależności od klikniętego miejsca (lekkie muśnięcie nie powoduje, że obiekt "skacze").
- Pędzel do malowania obiektami z puli @Kolej w Polsce
- Jakiś interfejs z guzikami zapisz itd. wraz z informacjami "zapisano" itp.
- Autozapis z możliwością ustawienia interwału między zapisami sygnowanymi datą i godziną w nazwie pliku @Toprus
- Możliwość wstawiania obiektów z losowym obrotem.
- Wstawianie includów zamiast node model.
- Podgląd punktów końcowych zaznaczonego toru @matek123
- Zwiększenie stabilności multiplayera @Darriio100
- Inne dźwięki poruszania się po mostach/tunelach/itp.
- Naprawa dźwięku turbiny dla spal-ele @mareczek
- Rozdzielenie drzwi z wirtualnie jednych na człon do faktycznej liczby, aby urealnić ciepły guzik, a także umożliwić uruchomienie obu drzwi w np. wagonach 111Ainw @mikolzmalopolski
- Oddzielenie suwaka opadów i zachmurzenia (faktyczne opady = opady * zachmurzenie, ilość słońca = 1 - zachmurzenie, itd itp).
- Sieć trakcyjna na geometrii a nie na node::lines, bo to nie jest 2005 rok.
- Opcja losowania dźwięków przy każdym odtworzeniu, a nie raz na symulację.
- Seedowanie losowych np. syren i buczków do drzwi z tym samym ziarnem na całą jednostkę, i być może każdy egzemplarz z tym samym ziarnem (generowanym na podstawie nazwy tekstury?)
Duże projekty, które mogą okazać się zbyt ciężkie do zrobienia dla mnie w pojedynkę póki co:
- Dynamiczne generowanie krzyżownic. Coś co jest na granicy, bo jest to bardzo ciężkie do zrobienia, ale da bardzo duży krok w stronę realizmu w symulatorze.
- Dynamiczne "losowania" graficzne np. w kwestii kiwania się pojazdów czy wysokości podsypki @Balaclava
- Bardziej rozbudowane graficznie warunki pogodowe (tęcza, burza).
- Przebudowa generowania tablic kierunkowych i wbudowanie bezpośrednio w exe @mikolzmalopolski
- Przebudowa systemu obsad i układu kabin:
- Dowolna liczba pomieszczeń na pojazd zamiast 3 - kabina A, maszynownia, kabina B.
- Jakaś graficzna reprezentacja tego, coś na wzór Consist Monitora(?) w MSTS/Open Rails, z wyszczególnionymi pomieszczeniami, i możliwością przejścia. Plus zaznaczenie gdzie jest aktywne AI, jaka kabina jest aktywna itp. A kliknięcie na konkretne pomieszczenie może nas tam przenosić. To można zrobić na początku.
- Możliwość ustawienia kilku pojazdów z obsadą headdriver w jednym składzie - wówczas do każdego niewybranego wchodzi AI, i działa jako popych.
Jak coś mi się jeszcze nawinie, zedytuję tego posta. Zapraszam do składania propozycji!
I tak, skończy się jak z lua
-
Z drobiazgów, przydałoby się, żeby w trybie edytora f11 po kliknięciu na tor na końcach toru pojawiały się kulki/boxy z cyferką 1 i 2 odpowiadające punktowi początkowemu i końcowemu danego toru.
-
System dynamicznie generowanych ostrzeżeń dla szlaków. Raz jedziemy i tu będzie zwolnienie, innym razem tam, a innym razem opuszczenie pantografów. Brzmi ambitnie ale byłoby zaje...ekhem fajne.
-
Możliwość przypisania osobnych dźwięków wewnętrznych i zewnętrznych np. dla silnika lub syreny.
-
Przydałaby się animacja wycieraczek i próba powrotu do płynnej regulacji wysokości wysunięcia szyb, czy wychylenia daszków przeciwsłonecznych.
-
Może w takim razie podkłady w 3D?
-
System dynamicznie generowanych ostrzeżeń dla szlaków. Raz jedziemy i tu będzie zwolnienie, innym razem tam, a innym razem opuszczenie pantografów. Brzmi ambitnie ale byłoby zaje...ekhem fajne.
Zupełnie oderwany od rzeczywistości bajer. Jadąc daną linia maszynista ma mieć znajomość szlaku, a ty chcesz zgadywankę co za następnym łukiem nowego nas czeka.
-
System dynamicznie generowanych ostrzeżeń dla szlaków. Raz jedziemy i tu będzie zwolnienie, innym razem tam, a innym razem opuszczenie pantografów. Brzmi ambitnie ale byłoby zaje...ekhem fajne.
To już raczej pasowałoby do generatora scenerii. A to najpewniej nigdy nie nastąpi. Bynajmniej takie coś raczej nie w exe, a jako oddzielny program.
Może w takim razie podkłady w 3D?
Wymaga instancjonowania geometrii, a ja w silniku graficznym zmian robić nie zamierzam.
-
- Wstawianie includów zamiast node model.
Strasznie trudno będzie wtedy przestawić/usunąć coś w przypadku, gdyby z jakiegoś powodu nie pasowało, a już się raz zapisało i wyszło z edytora. Nieraz przy samym EC zdarzało mi się przegapić jakieś lewitujące drzewko, ustawienie tego od razu w includzie bardzo utrudniłoby jego zlokalizowanie w plikach i usunięcie. Chyba, że będzie opcja przesuwania już ustawionych obiektów. Wiem, sprawdzać przed zapisem, ale jak się robi coś wieczorami to niekoniecznie wszystkie styki w głowie chodzą poprawnie i łatwo idzie coś pominąć.
-
System dynamicznie generowanych ostrzeżeń dla szlaków. Raz jedziemy i tu będzie zwolnienie, innym razem tam, a innym razem opuszczenie pantografów. Brzmi ambitnie ale byłoby zaje...ekhem fajne.
Zupełnie oderwany od rzeczywistości bajer. Jadąc daną linia maszynista ma mieć znajomość szlaku, a ty chcesz zgadywankę co za następnym łukiem nowego nas czeka.
Miałem na myśli ostrzeżenia czasowe z R-307 wydawanego na stacjach. Nie wspomniałem - moje niedopatrzenie.
-
To ja podrzucam - przywrócenie pracy turbiny dla spal-elek. Ostatnio (z pół roku temu?) ktoś popsuł i już nie naprawił.
-
Nie wiem na ile jest to możliwe, ale pasuje do wątku więc rzucam luźno - umożliwienie wykonywania fizyki na pojazdy dwutrakcyjne, np. E6ACTad (z silnikiem dojazdowym), czy też przyszłościowo hybryda. Ale mówię, nie wiem na ile to realne.
-
- Wstawianie includów zamiast node model.
Strasznie trudno będzie wtedy przestawić/usunąć coś w przypadku, gdyby z jakiegoś powodu nie pasowało, a już się raz zapisało i wyszło z edytora. Nieraz przy samym EC zdarzało mi się przegapić jakieś lewitujące drzewko, ustawienie tego od razu w includzie bardzo utrudniłoby jego zlokalizowanie w plikach i usunięcie. Chyba, że będzie opcja przesuwania już ustawionych obiektów. Wiem, sprawdzać przed zapisem, ale jak się robi coś wieczorami to niekoniecznie wszystkie styki w głowie chodzą poprawnie i łatwo idzie coś pominąć.
To będzie do rozgryzienia. Include includowi nie równy i różne rzeczy mogą wymagać różnego traktowania. Myślałem nad grupowaniem obiektów tak jak chociażby w (ekhem ekhem) TD2. Ale w założeniu zawartość plików *.inc jest stała, więc po prostu przesuwałoby się całe includy. Ale żeby nie pogrupowało całej roślinności na scenerii razem (bo plik scenerii sam w sobie zawiera includy do poszczególnych elementów), można filtrować po rozszerzeniu. Najwyżej się dostosuje rozszerzenia jeżeli któraś sceneria ma elementy "wirtualne foldery" w pliku inc.
Nie wiem na ile jest to możliwe, ale pasuje do wątku więc rzucam luźno - umożliwienie wykonywania fizyki na pojazdy dwutrakcyjne, np. E6ACTad (z silnikiem dojazdowym), czy też przyszłościowo hybryda. Ale mówię, nie wiem na ile to realne.
Myślę, że youBy będzie umiał to ogarnąć - zna się na fizyce i póki jeszcze coś tam skrobie co jakiś czas, jest na to szansa.
-
Możliwość opcji autozapisu do edytora F11, najfajniej by było gdyby dało się samemu ustawić interwał między zapisami, a pliki wypluwane z autozapisu albo były oddzielne do tych, które sami tworzymy ctrl+shift+f11, albo aby wszystkie pliki (i te eksportowane przez nas i przez autozapis) miały oddzielne nazwy i się nie nadpisywały, niech będą nawet oznaczane datą stworzenia pliku.
-
Najważniejsza opcją edytora powinien byc pędzel do malowania trawki i drzew, że można ustawić sobie rozmiar pędzla i gęstość trawy/drzew
-
Nie wiem ja sie tam nie znam na exe, ale fajną opcją była by możliwość łatwego dodawania trakcji do torów na podstawie jak dziś np. Co klikniesz drzewko i je masz. Dodał bym jeszcze sposób ubierania sie w różnych okresach roku. Bo np latem ktoś na scenerii w kurtce jest. A zimą w krótkich gaciach i podkoszulku. Ale to tak jak mówie, ja sie tam nie znam.
-
Jeśli chodzi o ubiór to po prostu nie ma kto ubrać ludzi w zimowe ubranka i dorobić maty. Żadne zmiany w exe nie są potrzebne, tylko trzeba zagonić jakiegoś jelenia co umie w blenderka i być może malarza substancji.
A co do sieci trakcyjnej, Jan coś tam robi, więc na razie nie wiem. Pewnie będą jakieś wpisy do nodebanku kiedyś tam.
-
Powodzenia w sieciowaniu przez edytor w exe... Do tego są/będą odpowiednie narzędzia dzięki którym zrobi się to zgodnie ze sztuką, a nie na szybko i byle jak.
-
Jeśli chodzi o ubiór to po prostu nie ma kto ubrać ludzi w zimowe ubranka i dorobić maty. Żadne zmiany w exe nie są potrzebne, tylko trzeba zagonić jakiegoś jelenia co umie w blenderka i być może malarza substancji.
Rozumiem, że po prostu połowa układu by była na ciuchy letnie, a druga na zimowe? Jeżeli tak, to co proponujesz to bardzo mocna proteza i marnotrawstwo miejsca na teksturach. Ja kiedyś proponowałem możliwość definiowania submodelom sezonowości. Wspominałem o tym pod kątem osłon metalowych/brezentowych na pojazdy w zimę, ale przy ludzikach też by się to sprawdziło.
- Możliwość zaznaczania torów @matek123
To już się da robić i zwraca nazwę toru, tylko chciałbym, żeby była informacja przestrzenna o kierunkowości toru. :)
-
Rozumiem, że po prostu połowa układu by była na ciuchy letnie, a druga na zimowe? Jeżeli tak, to co proponujesz to bardzo mocna proteza i marnotrawstwo miejsca na teksturach. Ja kiedyś proponowałem możliwość definiowania submodelom sezonowości. Wspominałem o tym pod kątem osłon metalowych/brezentowych na pojazdy w zimę, ale przy ludzikach też by się to sprawdziło.
Dorobić maty i zdefiniować, która tekstura ma się ładować przy jakiej porze roku.
-
Losowe przemieszczenie wierzchołków dolnej podstawy trapezu podsypki na całej długości toru, żeby tłuczeń nie leżał jak od linijki.
-
Jeśli to możliwe dodać pojedynczo otwierane drzwi w wagonach i ezt oraz dodać animowane tablice kierunkowe.
-
Pojedynczo otwierane drzwi dodałem do listy, ale jeśli chodzi o animowane tablice kierunkowe wymagałoby to przebudowania całego systemu tablic kierunkowych.
A przyczyny to między innymi:
- fakt, że tablice są generowane w Pythonie, który nie najlepiej radzi sobie z optymalizacją, szczególnie w archaicznej wersji drugiej,
- tablice obecnie mają generowany bloom, co zajmuje kilka sekund na wyrenderowanie jednej tablicy.
Pomysł słuszny, ale niestety implementacja póki co delikatnie mówiąc ssie. Mam pomysł na naprawienie tych błędów, ale nie wiem, kiedy i czy uda mi się to zrobić. Jest to dość skomplikowane.
No i na pewno nie zostanie to wdrożone wcześniej niż dynamiczny bloom.
-
Fajnie byłoby zaobserwować zadymki śnieżne ponieważ bardzo tego w maszynie brakuje.
-
Od razu zaznaczam, że strony stricte renderera nie chcę tykać - żadne nowe algorytmy renderowania, generowanie kropel na szybie czy inne graficzne wodotryski to stanowczo za dużo czytania dla mnie i nie chcę tego implementować
-
Rozwinąć multiplayer, wszędzie w symmulatorach jest tylko nie w MaSZynie.
-
Jak obstawiam limit świateł dynamicznych też podchodzi pod renderer?
Co do automatycznego rozwieszania drutów, to czy taki system nie ułatwiłby roboty w jakikolwiek sposób, chociażby na długich odcinkach?
-
Rozwinąć multiplayer, wszędzie w symmulatorach jest tylko nie w MaSZynie.
Jest mało stabilna opcja pojeżdżenia ze znajomymi w trybie p2p. Multiplayera z serwerem nie przewidujemy.
-
Rozwinąć multiplayer, wszędzie w symmulatorach jest tylko nie w MaSZynie.
W Trainzie też nie ma hehe
Zwiększenie stabilności multiplayera jest w planach.
-
Jak obstawiam limit świateł dynamicznych też podchodzi pod renderer?
Podobno da się ten limit zdjąć, ale przy obecnym renderze to się zemści ekstremalnie na wydajności.
Co do automatycznego rozwieszania drutów, to czy taki system nie ułatwiłby roboty w jakikolwiek sposób, chociażby na długich odcinkach?
Można pomyśleć nad automatycznym rozwieszaniem drutów po implementacji "typów sieci", gdy do narysowania druta będą potrzebne tylko współrzędne "łapek" trzymających kabelki, a reszta będzie określana w pliku definiującym typ sieci trakcyjnej.
-
Należałoby zacząć od implementacji ustawiania słupów teletechnicznych i energetycznych.
-
AI i ciężkie, długie ładowne brutta. Już kiedyś sygnalizowałem problem, dziś dla testu puściłem na torze doświadczalnym ET41+35x622Za, 3700 Ton, 600 metrów. Rozruch ze "sprężynowaniem" ale całe kółko TD jamnik dał radę. Problem pojawił się gdy zatrzymał się na S1 przed żeberkiem, po podaniu semafora i rozjazdu na bok ET41 wciągnęła połowę składu i nagle AI zdecydowało żeby dać nastawnik na zero i skład został rozerwany, dodam jeszcze że WS-a nie wywaliło ani nie została przekroczona prędkość jazdy. Podobne sytuacje przy ciężkich pociągach obserwowałem na kaliskiej gdzie dodatkowo obecne mogą być "dziury" w scenerii oraz spore wahania napięcia w sieci trakcyjnej. Na innych sceneriach nie zaobserwowałem podobnego problemu ponieważ większość z nich jak np. L053 ma "kolejkowe" składy towarowe wynikające ze zbyt krótkich torów stacyjnych które to nie pozwalają na zestawienie dłuższych pociągów, adekwatnych do mocy i możliwości lokomotyw np. ET41/42, E6ACT, TRAXX itd. Obserwując zachowania AI domyślam się że wirtualny mechanik zbyt raptownie operuje nastawnikiem oraz kranem hamulca choć w mniejszym stopniu, co daje ww. efekt sprężynowania i w rezultacie rozerwanie pociągu. Zauważone na czystej paczce 22.11 i wcześniejszych.
Drugi mój pomysł dotyczący największej bolączki MaSzyny - scenerii. Ciekawym rozwiązaniem byłoby stworzenie jakiegoś edytora scenariuszy w oparciu o exe, podobnie jak edytor pod F11. Na dzień dzisiejszy możemy wyświetlać nazwę toru, semaforów, rozjazdu itd. Wskaźników już nie, eventów przypisanych do toru także. Coś co moim zdaniem byłoby pomocne to np. edytor/generator eventów/scenariuszy w oparciu o fizyczne "kliknięcie" lub zaznaczenie na scenerii szlaku/drogi przebiegu, nadając pociągom flagę braną chociażby z rozkładu jazdy (za pomocą event whois) opracowując tym samym we wstępnie zdefiniowanej logice dyżurnego ruchu czy towarowy puszcza pośpiecha czy może się doturlać do następnej stacji. W skrócie LCS w MaSzynie, tworzenie scenariuszy za pomocą exe a nie notatnika. Domyślam się że jest to projekt kategorii science-fiction i sam przedstawiłem to dość chaotycznie ale taka idea jest moim zdaniem ciekawa.
Na koniec tego przydługiego posta dodam że od ponad 15 lat jeżdżę w MaSzynie (z przerwami), przez ten czas nastąpił gigantyczny progres projektu dzięki pracy wielu osób, niestety w porównaniu do ilości, ciągle podnoszonej jakości taboru i możliwości exe borykamy się z problemem który ktoś trafnie nazwał "mamy czym jeździć, nie mamy po czym", stąd pomysł na edytor scenariuszy.
Z mojej strony pozdrawiam i dziękuję wszystkim osobom które przyczyniają się do rozwoju MaSzyny, podziękowania również dla @jakubg1 za otwarcie tematu nad rozwojem projektu, chęć do pracy nad exe i wysłuchanie naszych "gorzkich żali".
-
Jakubku zgłaszam
że styrta sie pali fajnie by było jakby edytor w exe drutował słupy :3
-
c.d. przemyśleń przy okazji projektowania systemu osprzetu rozjazdowego:
- możliwość wycięcia trapezowego zagłębienia w podsypce na zadanej odległości od P1, z parametrami głębokości oraz szerokości góry i dołu wycięcia. Wszelkie detale w stylu spon iglicowych czy też prętów nastawczych dużo na tym zyskają, bo nie będą się topić w tłuczniu.
- w edytorze możliwość przyciągania obiektu do toru (z uwzględnieniem odsunięcia od jego osi) oraz możliwość przesuwania go wzdłuż toru.
- naprawa błędów animacji (przeskok pod koniec)
- możliwość skalowania wstawionych modeli
-
Poszperałem trochę w kodzie exe i szczerze - już mi przeszło. Według mnie ten codebase jest nie do odratowania. Chyba że przebrnie przez niego grupa doświadczonych programistów za kilkanaście tysięcy złotych.
Wątek póki co zamykam. Nie wyrzucać, bo wciąż jest to sporo idei zebranych w jedno miejsce.
Sorry za narobienie smaku i nadziei, jednak muszę skapitulować. Żeby w ogóle się za to zabrać, musiałbym w zasadzie rzucić wszystko. Pracę i wszystkie inne projekty. Z drugiej strony, nigdzie nie obiecałem że na pewno podejmę się tego tematu.
-
Ten pan post wyżej pieprzy...
W każdym razie, opublikowałem na GitHubie zaczątki refactoringu. Już trochę grubych commitów wleciało, ale sporo jeszcze przede mną. Chciałbym jednak zapytać doświadczonych osób, a w szczególności tych, którzy nad exe w ostatnich latach pracowały, jakie były zamysły (jest sporo kodu nazwanego legacy/deprecated a nigdy następcy się nie doczekały) i jaką konwencję by preferowały. Mam nadzieję, że zapał nie ostygnie zbyt szybko. Na razie mam mniej więcej pojęcie jak wygląda ogólna struktura kodu symka. Można zerknąć na historię commitów.
Link: https://github.com/jakubg1/maszyna
Kod jakby co jest w 100% kompilowalny i działa tak jak dotychczas, z paroma zmianami, które są tymczasowe.
-
Sama zmiana nazw dla samej zmiany nazw, raczej mnie martwi. Polecam robić bardziej zlokalizowane commity, np. dodanie nowego ficzera, lub kompleksowy refactoring wybranego modułu (nie tylko zmiany nazw), a nie zaczynać od zmian nazw rozrzuconych po całym projekcie. Łatwiej wtedy przeanalizować takie zmiany, i nie generuje aż tylu niepotrzebnych problemów przy mergowaniu.
-
Zmiana nazw w ten sposób w moim założeniu ma stanowić utworzenie podstawy pod spójny kod, który będzie można łatwiej edytować. Na razie nie będę tam zamieszczał zmian w samym działaniu symulatora, a jeżeli już jakieś się pojawią, to marginalne.
Zakres zmian opisałem w README.md na forku na GitHubie:
Todo for this fork:
Reorganize classes into folders
Split all files in such a way that one cpp+h pair = one class
Rename classes so they match filenames or vice versa
Take care of launcher, network, vr and widgets folders
(w ostatnim punkcie mowa o rozdzieleniu zawartości tych folderów razem z zawartością głównego katalogu)
-
Wiem, że to było wałkowane wiele razy, ale zapis
gry stanu symulacji. Tak, wiem, maszynista na żywo nie wychodzi sobie w środku pola i idzie do domu, ale ludzie, przy scenariuszach 3 godziny i powyżej to jest konieczność, inaczej jedynie krótsze scenerie będą miały sens. W powstających "Bieszczadach", jak się nie mylę, ma być scenariusz na siedem godzin. Serio myślicie, że ktoś będzie siedział przed kompem 7 godzin non-stop? Jest różnica między zabawą przy symulatorze, a prawdziwą służbą, na której ma się płacone od godziny i przejechanych kilometrów.
-
Przecież 7 godzinna służba to jest na ten moment maksymalny wariant. Jak napisałbym ciut więcej eventów to można by zrobić 24 godzinną misję. Z noclegiem w Łupkowie i łącznie chyba 6 godzinami stania na stacjach końcowych. Jeden pojeździ 1.5h, drugi będzie siedział 3h, trzeci posiedzi 15 minut i stwierdzi że to nie jego klimaty, a czwarty ruszy o 12:30, pojeździ 8-10 godzin, prześpi się i wróci do Zagórza.
-
Mimo wszystko przydałaby się opcja zapisu przecież. W innym temacie były poruszone usterki i każdy mówi, że byłaby to opcja niszowa, to co dopiero scenariusze na kilka lub kilkanaście(!) godzin bez możliwości ogrania ich na raty. Nie każdy ma na tyle wolnego czasu, ale z chęcią by taki scenariusz przejechał, więc opcja zapisu byłaby dla nich "zbawieniem".
O ile postoje można sobie przyspieszyć kompresją czasu w opcjach debugowania, to z jazdą jest o wiele ciężej.
-
Robisz pauze i minimalizujesz maszynę, robię tak od lat jak mi się już nie chce jechać.
-
Zaniki napięcia są nie tylko w sieci trakcyjnej (zarówno na szlaku, jak i w Maszynie) i na to pauza niestety nie pomoże. Moim zdaniem bardzo przydatna by była opcja zapisu stanu. :)
-
Da się też na danym torze (ale trzeba wiedzieć jak i nie każdemu się chce) stanąć składem np. stacja X tor xyz. Zapisać ten tor w scn jako miejsce startu (po wznowieniu jazdy) Niby jakaś opcja jest, ale to znów później trzeba ustawić miejsce startu oryginalne. I takie to przepisywanie i bawienie się troche bez sensu i za dużo zamieszania. Z tego co wiem w LOG zapisują się parametry, ale cóż z tego, jak po ponownym uruchomieniu robi się nowy Ja sie tam nie znam, ale może jakiś mini programik, który by wyłapywał pociąg gracza ? I startował go z ostatniego zapisanego tora, na który wjechał skład gracza. Tyle, że gdyby to tak się dało hop - siup, to pewnie byśmy to już dawno mieli w Maszynie.
-
A gdyby tak dana trasa była podzielona na kilka fragmentów i wtedy każdy mógłby wybrać albo przejazd całą trasą i katował by się np. z Janiszewa do Wilisia ponad 2h albo wybrał by np. segment nr 5, czyli tylko manewry w Wilisiu i wjazd na poligon z tamtejszymi manewrami, co zajęło by mu np. 30 minut i byłby zadowolony, że przejechał się na najciekawszym wg niego odcinku/misji w czasie, którym prywatnie dysponował? Jak to wyglądałoby ze strony ładowania się fragmentów scenerii?
-
Całe Bieszczady są podzielone na kawałki, więc w tym przypadku nie stanowi to problemu. Całkowo chyba nie jest w ogóle podzielone. O eventy nie ma raczej co się martwić, kwestia tylko tego żeby ktoś to ogarnął i żeby nie powstał milion scenariuszy.
-
Największym wyzwaniem w tym przypadku jest zapisywanie stanu pojazdu, tym bardziej biorąc pod uwagę jaki bałagan panuje w kodzie w tym zakresie.
-
Względnie na 1 scenerii dać 2 składy. Jeden docelowo robił by całą scenerie, a drugi gdzieś z połowy scenerii ruszał jaki Ai za głównym prowadzącym. I tu gdyby gracz sam dojechał do końca, to AI za nim (powiedzmy w odstępie czasu 30 minut) Gdyby się w połowie drogi znudziło albo brakło czasu, tp przy ponownym odpaleniu Maszyny startowało tym składem z połowy scenerii. Np. Jedziesz z Sandomierza do Wolicy przez Dębice. I albo cały odcinek albo w Dębicy zamykasz. I następnym razem odpalasz ten 2 skład z Dębicy do Wolicy. Coś mniej więcej na tym przykładzie, ja tak u siebie mam podzielone. Chce jadę całość, nie to nie. I zawsze mogę startnąć ze stacji na której poprzednio skończyłem. Jakieś rozwiązanie problemu jest. Pozdrawiam i S2 na torach.
-
Ja to bardzo bym chciał rozszerzenie ustawień ruchomości kamery. Takie ustawienie jak np. w ETS 2 lub MSFS. Dodało by to dużo według mnie, najbardziej żeby wzmocnić różne efekty ruchome.
-
Dzień dobry!/ Witam!
Propozycje do symulatora :
- Aktywacja kabiny w EP/EU07 bo fajnie tak się zmienia
-Możliwość dania kamery do wagonów pasażerskich np. ETZ oraz wagony osobowe ICC wiadomo o co mi chodzi :-)
Wsumie tyle bo maSzyna jest tak rozwinięta, że praktycznie nie trzeba dodawać jakiś tak ustawieć wielkich ale gdyby zrobiło by sie aktywacje to ooo kurcze realne było hohoho
Pozdrawiam wszystkich serdecznie :-)
Proszę poprawić linijkę zaczynającą się od "Wsumie"
Matek123
-
-Możliwość dania kamery do wagonów pasażerskich np. ETZ oraz wagony osobowe ICC wiadomo o co mi chodzi :-)
Można w starterze ustawić wagonowi obsadę pasanger, wybrać go i uruchomić symulator. To zadziała tylko na niektórych scenariuszach - tych w 100% dostosowanych do AI.
-
Już jakiś czas temu wspominałem, że dla realizmu symulacji dobrze by było uzależnić rodzaj opadów atmosferycznych od temperatury powietrza, a nie jedynie pory roku, tj. żeby jak w grudniu jest +10°C, to jednak padał deszcz a nie mimo wszystko śnieg i odwrotnie, gdy jest -5, to żeby padał śnieg, a nie dalej deszcz, bo akurat kalendarzowa zima jeszcze się nie zaczęła.
Wiem, że to trochę nie w temacie, bo dotyczy to kwestii związanych z grafiką, ale jak dla mnie bardzo dużym wzbogaceniem realizmu symulacji (a przez to znaczącym postępem dla rozwoju symulatora) byłoby mityczne już wprowadzenie szeroko rozumianej obsługi wycieraczek oraz efektu zbierania się opadów na szybie i jej przecierania...
-
Jeszcze jedna sprawa, dla mnie osobiście istotna jako, że lubię nieco pomieszać w ustawieniach, choć dyskusyjna - jednak wydaje mi się, że z uwagi na fakt, iż jest to symulator, to nawet wskazane, by umożliwiał pewną dowolność stosowania ustawień - mianowicie chodzi mi o wirtualnego rewidenta, by wprowadzić możliwość jego wyłączania (choćby w ustawieniach) - tak, by nie mieszał ręcznie przyjętymi nastawami hamulców.
-
Taka opcja już jest pod nazwą "Wirtualny manewrowy" w Starterze (zakładka Ogólne). Spróbuj ją wyłączyć.
-
Tu chodzi o co innego - bot obecnie w pierwszej klatce przejmuje wszystkie pociągi, w tym wybrany przez gracza.
-
Odnośnie samoczynnego zmieniania nastaw hamulca przez bota, to odkryłem jeszcze coś innego. Mam u siebie na scenerii wpisane w tory następujące eventy zmiany oświetlenia czoła pociągu:
//Sterowanie sygnałami Pc1 i Pc2 dla AI: eventy ponizsze sa wpisane bezposrednio w tory, aby AI zmienialo oswietlenie czola
event ustaw_pc1 putvalues 2 none 0 0 0 SetLights -1 -1 endevent //wyjazd na tor zasadniczy
event ustaw_pc2 putvalues 0 none 0 0 0 SetLights 22 -1 endevent //wyjazd na tor przeciwny do zasadniczego... i mimo tego, że mam wirtualnego manewrowego wyłączonego, ustawię sobie (już podczas symulacji) cały skład na nastawę "P", to i tak przy wywołaniu w/w eventów (czyli de facto co posterunek) cały skład zamienia mi na "G".