Forum Główne > ISDR - Tematy ogólne
[Pomysł] Ciekawe pomysły na udoskonalenie ISDR
Paweł:
--- Cytat: mcgiwer w 13 Maj 2014, 16:11:17 ---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 ).
--- Koniec cytatu ---
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.
--- Cytat: dedyk w 19 Maj 2014, 23:03:20 ---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).
--- Koniec cytatu ---
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).
mcgiwer:
--- Cytat: Paweł w 20 Maj 2014, 18:25:16 ---
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.
--- Koniec cytatu ---
Pisałem ogólnie :P jak wpisałem w google hasła związane z srk to dostałem sporo wyników
--- Cytat: Paweł w 20 Maj 2014, 18:25:16 ---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.
--- Koniec cytatu ---
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
--- Cytat: Paweł w 20 Maj 2014, 18:25:16 ---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).
--- Koniec cytatu ---
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
--- Cytat: Paweł w 20 Maj 2014, 18:25:16 ---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.
--- Koniec cytatu ---
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. ?
Paweł:
--- Cytat: mcgiwer w 20 Maj 2014, 19:48:15 ---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
--- Koniec cytatu ---
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ć.
--- Cytat: mcgiwer w 20 Maj 2014, 19:48:15 ---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
--- Koniec cytatu ---
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).
--- Cytat: mcgiwer w 20 Maj 2014, 19:48:15 ---Ja mogę pomóc na ochotnika ;)
--- Koniec cytatu ---
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.
--- Cytat: mcgiwer w 20 Maj 2014, 19:48:15 ---Przy okazji, co myślisz Pawle o wbudowaniu do ISDR takich edytorów jak np.: edytor RJ, epk, eps, itd. ?
--- Koniec cytatu ---
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.
mcgiwer:
--- Cytat: Paweł w 20 Maj 2014, 21:13:26 ---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.
--- Koniec cytatu ---
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 ;)
axtomek:
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? ;)
Nawigacja
[#] Następna strona
Idź do wersji pełnej