Autor Wątek: [Pomysł] Ciekawe pomysły na udoskonalenie ISDR  (Przeczytany 131580 razy)

Offline Paweł

  • Administrator
  • Użytkownik
  • Wiadomości: 1014
    • Zobacz profil
  • Skąd: Kęty
Odp: [Pomysł] Ciekawe pomysły na udoskonalenie ISDR
« Odpowiedź #30 dnia: 20 Maj 2014, 18:25:16 »
A co do metod działania urządzeń srk, można znaleść dużo na ten temat w internecie (wystarczy zapytać wójka google  :P ).

Ale chyba nie masz na myśli mojej strony? ;) Tam jest tylko "ekstrakt" z całej tematyki. Jeżeli już chcesz się na czymś opierać, to polecam zaopatrzyć się w jakieś porządne książki, np. "Elektryczne urządzenia zrk" WKŁ 1982. Ale to i tak nie zastąpi wiedzy praktycznej - gdybym tworzył symulację wyłącznie na podstawie literatury, to pewnie działała by trochę inaczej.

Odnośnie mindmapy. Jako "core" obecnie można potraktować wspomnianą bibliotekę, która kontroluje upływ czasu, symuluje ruch i działanie urządzeń zewnętrznych srk oraz dostarcza interfejs do sterowania nimi w dowolny sposób. To jest podstawa całej symulacji. Biblioteka ta otoczona jest podstawowymi funkcjami programu, tzn. obsługa Podglądu sytuacji w terenie, wysyłanie poleceń do składów, główne procedury łączności, podstawowe narzędzia i elementy interfejsu użytkownika itp.

"Wymiennymi modułami" są blokady liniowe, SSP, logika współpracujących posterunków, pulpity nastawcze, a docelowo także rzeczy które są obecnie zagnieżdżone w kodzie głównego pliku: zależności stacyjne, SWDR, RASP, powtarzacze SSP. Przy czym ich wymienność polega na tym, że można je dodać prosto do projektu i nie do końca prosto powiązać z resztą na poziomie kodu źródłowego (ale nie dlatego, że nie są w C++, tylko dlatego, że tych powiązań jest dużo i są zależne od specyfiki - np. dla nietypowej blokady trzeba wymyślić zmieniony sposób jej obsługi przez AI).

Być może część z tych rzeczy w przyszłości będzie tworzona/wiązana dynamicznie na podstawie danych z zewnątrz, czy też będzie działać jako zewnętrzne dynamiczne biblioteki. Może zajmiemy się tym po zrobieniu niektórych ważniejszych rzeczy, aktualnie nie jest to duży problem. Na razie myślę prędzej o automatyzacji tworzenia niektórych typowych powiązań poprzez generowanie potrzebnego kodu na podstawie wprowadzonych danych o posterunku i jego otoczeniu. Nie wchodzi w grę natomiast zmienianie całej architektury programu czy przepisywanie na inne języki - za dużo pracy, za małe korzyści.

Otóż pomysł, który mi przyszedł do głowy to planowe, nocne zamknięcie toru na czas wykonania jakiś sieciowych prac. Zamykamy tor, puszczamy sieciowca i niech sobie buszuje na torze, a w tym czasie ruch prowadzony będzie po torze sąsiednim (oczywiście jeśli istnieje).

Zamykać można, puścić sieciowca też można. Być może kiedyś wprowadzone zostaną scenariusze wybierane tak jak rozkład jazdy, które same będą generowały niektóre "atrakcje"; aktualnie trzeba je wywołać samemu (nie licząc losowych usterek).

Offline mcgiwer

  • Użytkownik
  • Wiadomości: 24
    • Zobacz profil
  • Skąd: Wrocław
Odp: [Pomysł] Ciekawe pomysły na udoskonalenie ISDR
« Odpowiedź #31 dnia: 20 Maj 2014, 19:48:15 »

Ale chyba nie masz na myśli mojej strony? ;) Tam jest tylko "ekstrakt" z całej tematyki. Jeżeli już chcesz się na czymś opierać, to polecam zaopatrzyć się w jakieś porządne książki, np. "Elektryczne urządzenia zrk" WKŁ 1982. Ale to i tak nie zastąpi wiedzy praktycznej - gdybym tworzył symulację wyłącznie na podstawie literatury, to pewnie działała by trochę inaczej.

Pisałem ogólnie  :P jak wpisałem w google hasła związane z srk to dostałem sporo wyników

Odnośnie mindmapy. Jako "core" obecnie można potraktować wspomnianą bibliotekę, która kontroluje upływ czasu, symuluje ruch i działanie urządzeń zewnętrznych srk oraz dostarcza interfejs do sterowania nimi w dowolny sposób. To jest podstawa całej symulacji. Biblioteka ta otoczona jest podstawowymi funkcjami programu, tzn. obsługa Podglądu sytuacji w terenie, wysyłanie poleceń do składów, główne procedury łączności, podstawowe narzędzia i elementy interfejsu użytkownika itp.

"Wymiennymi modułami" są blokady liniowe, SSP, logika współpracujących posterunków, pulpity nastawcze, a docelowo także rzeczy które są obecnie zagnieżdżone w kodzie głównego pliku: zależności stacyjne, SWDR, RASP, powtarzacze SSP.

Zgadza się, tylko jak mniemam, "core", czyli główny kod został nadmiernie obciążony zbyt wieloma rzeczami i funkcjami, co powoduje również zwiększone zużycie zasobów komputera (ok 17 MB) oraz zwiększenie objętości kodu


Przy czym ich wymienność polega na tym, że można je dodać prosto do projektu i nie do końca prosto powiązać z resztą na poziomie kodu źródłowego (ale nie dlatego, że nie są w C++, tylko dlatego, że tych powiązań jest dużo i są zależne od specyfiki - np. dla nietypowej blokady trzeba wymyślić zmieniony sposób jej obsługi przez AI).

Co sądzicie aby w wersji deweloperskiej spróbować rozwiązania aby stworzyć tzw. "pliki funkcyjne", czyli w odpowiednich katalogach stworzyć pliki w których umieściło by się pogrupowane wg. kategorii funkcjonalności funkcje?

Następnym krokiem było by utworzenie w głównej bibliotece funkcji która wczytywała by te pliki bezpośrednio z plików w tych katalogach. To rozwiązało by sprawę dynamicznego ładowania modułów i innych danych zewnętrznych

Na razie myślę prędzej o automatyzacji tworzenia niektórych typowych powiązań poprzez generowanie potrzebnego kodu na podstawie wprowadzonych danych o posterunku i jego otoczeniu. Nie wchodzi w grę natomiast zmienianie całej architektury programu czy przepisywanie na inne języki - za dużo pracy, za małe korzyści.

Ja mogę pomóc na ochotnika  ;)

Przy okazji, co myślisz Pawle o wbudowaniu do ISDR takich edytorów jak np.: edytor RJ, epk, eps, itd. ?

Offline Paweł

  • Administrator
  • Użytkownik
  • Wiadomości: 1014
    • Zobacz profil
  • Skąd: Kęty
Odp: [Pomysł] Ciekawe pomysły na udoskonalenie ISDR
« Odpowiedź #32 dnia: 20 Maj 2014, 21:13:26 »
Zgadza się, tylko jak mniemam, "core", czyli główny kod został nadmiernie obciążony zbyt wieloma rzeczami i funkcjami, co powoduje również zwiększone zużycie zasobów komputera (ok 17 MB) oraz zwiększenie objętości kodu

Z tych 17 MB najwięcej to prawdopodobnie bitmapy na których rysowany jest pulpit i podgląd sytuacji w terenie (bitmapa robocza, bitmapa aktualnie wyświetlana, dla pulpitu dodatkowo oryginalna bitmapa tła). Sam moduł symulacji ruchu i urządzeń srk, wraz z podgladem sytuacji w terenie, zajmuje ok. 5 MB. Patrząc na niektóre programy nie wydaje mi się, żeby takie zużycie pamięci było dużym problemem, na pewno większym jest CPU-żerne rysowanie sytuacji w terenie (głównie to obciąża procesor - wystarczy zobaczyć, co się stanie, gdy się przełączy zakładkę) - nie jest tu wykorzystywana żadna biblioteka graficzna, jedynie podstawowe funkcje VCL, ale w razie czego można to w miarę bezinwazyjnie zmienić.

Co sądzicie aby w wersji deweloperskiej spróbować rozwiązania aby stworzyć tzw. "pliki funkcyjne", czyli w odpowiednich katalogach stworzyć pliki w których umieściło by się pogrupowane wg. kategorii funkcjonalności funkcje?

Następnym krokiem było by utworzenie w głównej bibliotece funkcji która wczytywała by te pliki bezpośrednio z plików w tych katalogach. To rozwiązało by sprawę dynamicznego ładowania modułów i innych danych zewnętrznych

Cały czas wracasz do tej głównej biblioteki :) Ona sobie działa od dawna mniej więcej w takiej postaci; jeżeli objętość jej kodu zacznie sprawiać problem, to można się zastanawiać jak go rozwiązać, ale jak na razie problemu nie widzę. Jej zagmatwanie na pewno nie spowalnia rozwoju programu, bo po prostu się do niej praktycznie nie zagląda. Co innego, gdybyśmy sobie teraz wymyślili, że zrobimy na jej podstawie np. symulator jazdy lokomotywą... (teoretycznie się da).

Ja mogę pomóc na ochotnika  ;)

Jeżeli masz na myśli ostatnie zdanie, tzn. przepisanie całości, a inaczej mówiąc stworzenie od zera "ISDR 2", to nie widzę przeszkód żeby zaczynać, stary kod raczej nie będzie do tego potrzebny (wystarczy wyspecyfikować działanie), powodzenia ;) Choć nadal nie widzę sensu takiej operacji, aktualna organizacja projektu sprawdza się nieźle.

Przy okazji, co myślisz Pawle o wbudowaniu do ISDR takich edytorów jak np.: edytor RJ, epk, eps, itd. ?

Aktualnie wszystkie edytory są odrębnymi programami i nie widzę powodu, aby je łączyć razem z symulatorem w jakiś wielki kombajn. Zresztą, tak jak wcześniej pisałem, na razie zmiany wprowadzane są, i jeszcze długo będą, na poziomie źródeł (nie licząc rozkładu jazdy). Inną sprawą, związaną z otworzeniem wszystkiego do edycji, jest nieuniknione pojawienie się wielu gniotów a nie symulatorów.

W chwili obecnej trwają prace nad nowym, realistycznym posterunkiem; kiedy metoda jego budowy się sprawdzi, mogę chętnym udostępniać materiały i narzędzia do pomocy przy tworzeniu kolejnych. Ale nie wszystko naraz.

Offline mcgiwer

  • Użytkownik
  • Wiadomości: 24
    • Zobacz profil
  • Skąd: Wrocław
Odp: [Pomysł] Ciekawe pomysły na udoskonalenie ISDR
« Odpowiedź #33 dnia: 21 Maj 2014, 13:38:11 »
Jeżeli masz na myśli ostatnie zdanie, tzn. przepisanie całości, a inaczej mówiąc stworzenie od zera "ISDR 2", to nie widzę przeszkód żeby zaczynać, stary kod raczej nie będzie do tego potrzebny (wystarczy wyspecyfikować działanie), powodzenia ;) Choć nadal nie widzę sensu takiej operacji, aktualna organizacja projektu sprawdza się nieźle.

Ja myślałem raczej o pomocy w dokumentacji i drobnych pracach nad ISDR żeby pomóc tobie, a nie pisaniu ISDR 2 od zera  ;)

Offline axtomek

  • Użytkownik
  • Wiadomości: 110
    • Zobacz profil
  • Skąd: Z-Nienacka
Odp: [Pomysł] Ciekawe pomysły na udoskonalenie ISDR
« Odpowiedź #34 dnia: 21 Maj 2014, 17:24:55 »
Jak to w dokumentacji i drobnych pracach? Przecież proponowałeś przepisanie ISDR na inny język programowania? To nie są drobne prace. Kto wówczas miałby wykonać tę "zasadniczą" część pracy? ;)

Offline mcgiwer

  • Użytkownik
  • Wiadomości: 24
    • Zobacz profil
  • Skąd: Wrocław
Odp: [Pomysł] Ciekawe pomysły na udoskonalenie ISDR
« Odpowiedź #35 dnia: 22 Maj 2014, 15:25:41 »
Jak to w dokumentacji i drobnych pracach?

zależy co potrzeba  ;)

Przecież proponowałeś przepisanie ISDR na inny język programowania? To nie są drobne prace. Kto wówczas miałby wykonać tę "zasadniczą" część pracy? ;)

Nie do końca zrozumiałeś mój kontekst  :P

Pomysł przepisania ISDR na inny język był jedynie pomysłem na daleką przyszłość  ;)

Offline piotr1859

  • Użytkownik
  • Wiadomości: 39
    • Zobacz profil
  • Skąd: Z Google
Odp: [Pomysł] Ciekawe pomysły na udoskonalenie ISDR
« Odpowiedź #36 dnia: 23 Maj 2014, 22:23:43 »
czyli nigdy :P

Offline piotr1859

  • Użytkownik
  • Wiadomości: 39
    • Zobacz profil
  • Skąd: Z Google
Odp: [Pomysł] Ciekawe pomysły na udoskonalenie ISDR
« Odpowiedź #37 dnia: 29 Maj 2014, 11:38:12 »
panda3d - może w tym szybciej dało by się zrobić symulator w wersji 3d

Offline MaKu

  • Moderator
  • Użytkownik
  • Wiadomości: 565
  • Starszy Dyżurny Ruchu
    • Zobacz profil
Odp: [Pomysł] Ciekawe pomysły na udoskonalenie ISDR
« Odpowiedź #38 dnia: 29 Maj 2014, 14:08:07 »
panda3d - może w tym szybciej dało by się zrobić symulator w wersji 3d

Możesz rozwinąć swoją wypowiedź? 3D? Po co?  o_O

Offline jageer

  • Projektant
  • Użytkownik
  • Wiadomości: 1395
  • Podg. Papago
    • Zobacz profil
  • Skąd: wieś Papago.
Odp: [Pomysł] Ciekawe pomysły na udoskonalenie ISDR
« Odpowiedź #39 dnia: 29 Maj 2014, 14:15:18 »
panda3d - może w tym szybciej dało by się zrobić symulator w wersji 3d

Możesz rozwinąć swoją wypowiedź? 3D? Po co?  o_O

Kolega chce wymodelować nastawnię w środku, otoczenie, stacje, pociągi w 3d. I widok pewno w stylu FPP ;-) Skoro mamy symulować pracę ISDR-a, to pasuje tez korzystać z WC, smarować wajchy, czasem coś zjeść, no i po 12h pracy do domu wyskoczyć.
Tak też można mili moi.
Tor zajęty, a wjazd stoi.

Offline dedyk

  • Użytkownik
  • Wiadomości: 59
    • Zobacz profil
  • Skąd: okolice Warszawy
Odp: [Pomysł] Ciekawe pomysły na udoskonalenie ISDR
« Odpowiedź #40 dnia: 29 Maj 2014, 20:14:32 »
3D to już trochę przyrost formy na treścią.

Ja też mam swój kolejny, malutki pomysł na rozważenie. Otóż zauważyłem, że semafory w ISDR działają zbyt dobrze w stosunku rzeczywistości, tj. czasami samoistnie nie wygaszają się np. pod wpływem poboru prąd przez pociąg. Można by wprowadzić funkcjonalność samoistnego wygaszania semaforów tuż przed nosem pociągu tak, aby pociąg nie zdążył zatrzymać się. W takiej sytuacji należałoby podyktować eSa na kontynuowanie jazdy.

Pozdrawiam,
Fryderyk

Offline Paweł

  • Administrator
  • Użytkownik
  • Wiadomości: 1014
    • Zobacz profil
  • Skąd: Kęty
Odp: [Pomysł] Ciekawe pomysły na udoskonalenie ISDR
« Odpowiedź #41 dnia: 29 Maj 2014, 21:39:26 »
3D to już trochę przyrost formy na treścią.

Odwzorowanie całej nastawni, a zwłaszcza rzeczy takich jak monitory w 3D to może przesada, ale nie wykluczam w przyszłości zrobienia 3D podglądu sytuacji w terenie. Wymagało by to pewnych modyfikacji silnika fizycznego (wyznaczanie położeń poszczególnych pojazdów, dodanie współrzędnej pionowej), a silnik graficzny (plus udźwiękowienie) był by oddzielnym modułem działającym na podstawie informacji o położeniach i stanie obiektów z silnika fizycznego.

Ja też mam swój kolejny, malutki pomysł na rozważenie. Otóż zauważyłem, że semafory w ISDR działają zbyt dobrze w stosunku rzeczywistości, tj. czasami samoistnie nie wygaszają się np. pod wpływem poboru prąd przez pociąg. Można by wprowadzić funkcjonalność samoistnego wygaszania semaforów tuż przed nosem pociągu tak, aby pociąg nie zdążył zatrzymać się. W takiej sytuacji należałoby podyktować eSa na kontynuowanie jazdy.

Taka sytuacja może się zdarzyć, nieprawidłowa praca dławików przy rozruchu jest przewidziana, przy czym mało prawdopodobne jest, że pociąg nie zdąży się zatrzymać (zajętość symulowana jest zaraz po ruszeniu), jedynie zgłosi wygaszenie sygnału.

Offline djuzi

  • Użytkownik
  • Wiadomości: 175
  • Prawie jak Dyżurny Ruchu
    • Zobacz profil
  • Skąd: IZ Warszawa
Odp: [Pomysł] Ciekawe pomysły na udoskonalenie ISDR
« Odpowiedź #42 dnia: 01 Czerwiec 2014, 21:38:30 »
Jeżeli ktoś orientuje się w zabawach 3D - można rzucić jakieś konkrety. Dobry pomysł zawsze wart jest przemyślenia.

1) Oczekiwania:
- ...
- ...
2) Co spełnia te oczekiwania:
- ...
- ...
3) Pomysł na sposób implementacji:
- ...
- ...

Offline axtomek

  • Użytkownik
  • Wiadomości: 110
    • Zobacz profil
  • Skąd: Z-Nienacka
Odp: [Pomysł] Ciekawe pomysły na udoskonalenie ISDR
« Odpowiedź #43 dnia: 02 Czerwiec 2014, 09:23:42 »
Ja bym za bardzo nie brnął w tworzenie silnika 3D, bo to dużo pracy. Do tego potrzebne są modele 3D kolejowej infrastruktury i pociągów. Można oczywiście wykorzystać projekt, który już dorobił się dużej ilości takich obiektów. np. MSTS, do którego polskich dodatków jest zatrzęsienie, a sposób ich implementacji można podpatrzeć w rozwijającym się na licencji GNU symulatorze OpenRails. Niemniej moim zdaniem podgląd sytuacji w terenie w 3D fajny gadżet, ale tylko gadżet. Nie wiem, czy nawet zrobienie w miejsce obecnego, podglądu w kolorze z otoczeniem, z dokładnym graficznym odwzorowaniem pociągów ale nadal w 2D (od góry), nie wystarczyło by. A jeśli Paweł masz ciśnienie na 3D, to zrób symulator nastawni mechanicznej scentralizowanej i widok 3D wewnątrz nastawni. Przekładanie dźwigni w trybie FPP, etc. To by było piękne :)

Offline MaKu

  • Moderator
  • Użytkownik
  • Wiadomości: 565
  • Starszy Dyżurny Ruchu
    • Zobacz profil
Odp: [Pomysł] Ciekawe pomysły na udoskonalenie ISDR
« Odpowiedź #44 dnia: 02 Czerwiec 2014, 18:39:11 »
A ja uważam, że obecnie najważniejsze jest zakończenie przez Pawła Testowa, a następnie przygotowanie kodu oraz manualów tak, aby tworzenie następnych posterunków było łatwiejsze niż teraz.