Pokaż wiadomości

Ta sekcja pozwala Ci zobaczyć wszystkie wiadomości wysłane przez tego użytkownika. Zwróć uwagę, że możesz widzieć tylko wiadomości wysłane w działach do których masz aktualnie dostęp.


Wiadomości - maciek001

Strony: [1]
1
Na warsztacie / Odp: Sterowanie ruchem przez zewnętrzną aplikację
« dnia: 09 Stycznia 2018, 00:29:12 »
Odkopując "trochę", fajnie by było gdyby SCS obsługiwał coraz częściej pojawiające się cuda w postaci rozsuniętych semaforów blokady lub miejscowo zagęszczonych jednokierunkowo odstępów, gdzie w drugim kierunku muszą być dwa odcinki osłaniane jednym semaforem. Bo obecnie przy próbie skonstruowania czegoś takiego, udać się uda żeby właściwie reagowały semafory podczas przejazdu przez oba odcinki, ale zrywa cały czas połączenie.

2
Ekrany wczytywania z plikow o identycznej nazwie jak plik misji (.scn) - wtedy dla kazdej misji automatycznie sie ustawia odpowiedni obrazek. Jezeli brak pliku to defaultowy ogolny dla scenerii a gdy brak defaultowego to np po prostu logo MaSzyny. Tak jakos to mialem zrobione.

3
Żeby nie dociążać exe takimi zadania lepiej mieć odrębny kawałek softu, który mógłby służyć też jako miejsce rozsyłania plików / scenerii (wtedy jest pewność, że wszyscy mają taką samą).
Sek w tym, ze ten odrebny kawalek i tak bedzie musial miec w zasadzie pelna funkcjonalnosc symulatora (oprocz moze strony wizualnej, dlatego m.in. wspominalem ze jednym z celow zmian powinno byc rozdzielenie symulacji od renderingu) wiec czy dolozy sie do exe pare klockow, czy tez dolozy sie symulator do tej samej pary klockow i nazwie sie to "odrebny kawalek softu", to i tak wyjdzie na to samo :) Ale w przypadku odrebnego softu dojdzie koniecznosc wprowadzania zmian do dwoch programow i utrzymywania tychze, zamiast tylko jednego... co chyba nie jest zbyt praktyczne.

4
Z SCS jest jak z Rainsted. Nie ma launchera w exe więc korzystamy z dobrego zewnętrznego softu. Paul ma pomysł na sterowanie scenariuszem więc to jest lepsza droga niż zabawa w implementację logiki układania przebiegów, która już została zaimplementowana i przetestowana.
Dla mnie nie jest problemem, że automatycznie odpalasz na kompie drugi proces, który komunikuje się z tym głównym. Może być nawet bezokienny jeśli komuś to będzie wadziło.

5
Na warsztacie / Odp: Planowane zmiany w exe
« dnia: 01 Marca 2017, 04:55:08 »
A jak nie ma przycisku w kabinie to nie działa (por. piasecznica, przyp. redaktora). Tylko jak się w to już bawić to na docelowo. Powiedzmy, że pomysł ze sterowaniem tmj jest ok, tzn Train przechwytuje zdarzenie i rozsyła po wszystkich pojazdach. Każdy pojazd zmienia swój stan wewnętrzny na podstawie właściwości (prowadzący, ukrotniony czy co tam jeszcze) i przesyła dane do wszystkich instancji kabin. Te sobie ustawiają na podstawie stanu odpowiednie urządzenia (wtedy w kabinie B będą się załączały lampki przy sterowaniu w kabinie A). Wtedy brak przycisku po prostu nic nie animuje, ale sam stan pojazdu się zmieni.
Tzn. mozna to zrobic tak, a jakby ktos sie uparl zeby bylo bardziej "prawdziwie" to mozna aranzowac w ten sposob, ze na pewnym poziomie sa urzadzenia wejscia (interpreter klawiatury, konsoli, joysticka, klikania na element w kabinie, AI mechanic czy co tam jeszcze) i te przekladaja otrzymane od uzytkownika sygnaly na instrukcje uniwersalne typu "nastawnik raz do przodu", ktore sa przesylane do klasy-posrednika. A na drugim poziomie masz obiekt - odpowiednik konsoli sterowania w lokomotywie, ktory sie u tego posrednika subskrybuje, ze chce otrzymywac konkretne instrukcje zgodne z tym, w co dana konsola jest wyposazona. I po otrzymaniu takich instrukcji konsola uaktualnia sobie swoj stan, i przekazuje instrukcje do pociagu, ktory juz ja sobie wykonuje/rozsyla dalej itp. Ta metoda mozna troche prosciej realizowac warianty typu dwie konsole w jednej kabinie, czy co tam jeszcze wyskoczy.

Do pewnego stopnia ten model juz jest, tylko zapackany przez dorzucone modyfikacje o shift, ctrl itp, ktore powinny byc zamiast tego osobnymi, pelnoprawnymi instrukcjami

Strony: [1]