1. Tylko TCP/IP lub inne sposoby komunikacji międzyprocesowej, WM_COPYDATA to nie jest sposób komunikacji.
2. Chciałem od dawna zaimplementować w exe ZeroMQ w tym celu. Wymaga opracowania protokołów danych, ale można wtedy przesyłać wszystko binarnie i w trybie push. Czy jest to do zrobienia w SCS?
W obecnym rozwiązaniu stosowane jest WM_COPYDATA, ponieważ zostało już wcześniej przewidziane w Maszynie do takich celów i radzi sobie całkiem dobrze. WM_COPYDATA przewiduje ponadto kilka innych funkcji nieużywanych przez SCS.
Dla zdalnego sterowania docelowo proponuję tekstowe TCP/IP z uwagi na prostotę i możliwość sterowania z innego komputera (Maszyna w roli serwera TCP/IP, tak jak działa to dla TD2). Idealnie było by uzyskać protokół jak najbardziej ujednolicony dla obu obecnie obsługiwanych symulatorów (Maszyna i TD2) - dla TD2 powstawał od zera, bez bałaganu narzuconego przez stare pliki i warto to wykorzystać (notacja "<obiekt>:<akcja>"). Chyba że ZeroMQ również sobie poradzi przez sieć i posiada jakieś istotne zalety w porównaniu do komunikatów TCP/IP.
3. Chciałbym zupełnie wyrzucić eventy ze sterowania. To też było już dyskutowane wstępnie. Czyli
a. Niskopoziomowo nie uruchamiamy eventów do sterowania srk tylko żądamy konkretnego stanu (ustawienia) dla danego urządzenia. Urządzenie wysyła nam swój stan po zmianie lub na żądanie.
Jeżeli eventy z Maszyny zostaną usunięte i zastąpione innym rozwiązaniem, dostosowanie SCS nie będzie większym problemem (pod warunkiem, że jakieś istotne sygnały/stany nie zostaną pominięte).
b. Średniopoziomowo to łatwiej by było, gdyby nie trzeba generować tego poziomu w ogóle, czyli SCS sam tworzy na swoje potrzeby ten poziom za pomocą parsera scenerii podczas wczytywania.
SCS automatyzuje zależności tam gdzie to możliwe, ale nadal niektóre parametry trzeba wprowadzić ręcznie (wszelkie nietypowe uzależnienia i dane których nie da się odgadnąć z samego kształtu układu torowego). Generowanie danych dla tej warstwy automatycznie, wprost ze scenerii będzie i tak wymagało wprowadzania tych parametrów dla obiektów scenerii, co niekoniecznie będzie bardziej wygodne od ich wprowadzenia w przeznaczonym do tego edytorze. Ponadto automat nie wygeneruje estetycznie wyglądającego schematu układu torowego.
c. Wysokopoziomowo żeby to zaimplementować jest potrzebny element sterowania scenariuszem: czyli wyznaczanie przebiegów jak i wysyłanie poleceń do pojazdów (zmień kierunek, odepnij się od wagonów i takie tam). To co teraz jest robione za pomocą sygnałów co jest ogólnie chorym pomysłem z punktu widzenia architekturalnego.
W podanym rozwiązaniu w pliku .anp definiowane jest, które przebiegi są wjazdowe i wyjazdowe dla poszczególnych posterunków, czy też w zależności od kategorii pociągu, manewry itp. Po przyjęciu przejrzystej notacji dla tych przebiegów warstwa wyżej może zająć się już ściśle rozkładem jazdy, bez zastanawiania się jakie konkretnie przebiegi nastawiać, oraz ewentualnymi poleceniami dla pojazdów typu połącz/odłącz - choć te myślałem "doklejać" do definicji przebiegów w planie .anp (typu - gdy pociąg X wjedzie na stację A, ustaw manewr za semafor wyjazdowy i jednocześnie każ odłączyć lokomotywę).
@Paul: a czy Testowo dało by się do tego modyfikować? IMO pulpit kostkowy wydaje się być bardziej elastyczny w konstrukcji (zarówno w pamięci komputera jak i namacalnego pulpitu dla chętnych) i podpięciu do symka jako źródła danych o ruchu pojazdów.
Jest możliwe podłączenie do opisanego interfejsu symulatora urządzeń przekaźnikowych, ale raczej jako symulator urządzeń przekaźnikowych, a nie kompleksowe narzędzie zarządzania i sterowania ruchem w scenerii. Pulpit kostkowy jest bardziej pracochłonny do przygotowania (tu mamy zróżnicowane szczegóły graficzne kostek, różne przyciski dla poszczególnych obiektów, natomiast w wersji komputerowej w zasadzie obiekty i łączące je linie), dla dużych odcinków sterowania będzie niezbyt przejrzysty i kiepsko nadaje się do automatyzacji. Można niby zrobić to samo co w SCS, wyglądające z grubsza jak pulpit kostkowy, ale powstanie twór który nie istnieje w rzeczywistości - tymczasem interfejs graficzny i sposób działania SCS wzorowany jest na rzeczywistych centrach sterowania.
Mianowicie, zauwazylem, iz zwrotnice w scenerii maja geometrie bliska linii prostej. Dopiero do koncowek zwrotnicy, masz odpowiednio wygiete tory.
Rozjazd złożony jest tu z części zwrotnicy - mniej więcej o rzeczywistej długości iglic - oraz odcinków stanowiących resztę. Obie części są łukiem o promieniu 300 m. Nietypowy format rozjazdów wynika z tego, że sceneria jest eksportem z edytora którego zasadniczo używam do ISDR.
