ISDR - Symulator prowadzenia ruchu kolejowego
Forum Główne => ISDR - Tematy ogólne => Wątek zaczęty przez: mcgiwer w 09 Kwiecień 2014, 15:02:25
-
Mam kilka pomysłów które mogły by udoskonalić symulator oraz ułatwić jego rozwój. Dodatkowo, myślę że mogły by one również zadowolić tych bardziej wymagających użytkowników.
Aby mój zapis był bardziej czytelny, podzielę moje pomysły na sekcje, punkty i podpunkty.
== Lista pomysłów ==
I. Ułatwienie rozwoju ISDR:
- utworzenie tzw. stałego "jądra (core)" programu zawierającego główny interfejs z menu, w którym były by takie funkcje jak m.in.:
- nowa symulacja (z możliwością wybrania pliku pulpitu)
- otwórz zapisaną symulację
- zapisz symulację
- opcje programu (może zawierać funkcję włączającą zaawansowane ustawienia i funkcje programu)
- Wszystkie elementy oprócz "core" powinny być zrobione w postaci dołączanych "snippetów" i/lub modułów, co ułatwiło by rozbudowę bez potrzeby ingerencji w główny kod programu
- edytor umożliwiający tworzenie i edycję pulpitów. W tym edytorze były by dostępne wszystkie elementy i kostki z których można by było samemu ułożyć sobie w pełni funkcjonalny pulpit
Powyższe rozwiązanie pozwoliło by ludziom nie będącym programistami tworzyć własne pulpity bez ingerencji w kod programu
II. Inne powiązane pomysły:
- wersje dla systemów innych niż Windows
Polecam również stronę: Beskidzka Strona Kolejowa (http://www.kontrakt-bhp.com.pl/paul/kolej/srk.php) zawierająca wiele ciekawych informacji dotyczących infrastruktury kolejowej oraz sterowania ruchem kolejowym
c.d.n.
-
No to siadaj do kompa i pisz...
Jak oglądałem serial Mc Gyver, to on umiał wszystko zrobic ;)
-
Każdy może złożyć własny pulpit w programie EPK. Tylko nie wiem jaki ma sens wymyślanie własnego pulpitu do gotowej stacji.
Polecam również stronę: Beskidzka Strona Kolejowa (http://www.kontrakt-bhp.com.pl/paul/kolej/srk.php) zawierająca wiele ciekawych informacji dotyczących infrastruktury kolejowej oraz sterowania ruchem kolejowym
To akurat jest strona autora tego symulatora ;)
-
edytor umożliwiający tworzenie i edycję pulpitów. W tym edytorze były by dostępne wszystkie elementy i kostki z których można by było samemu ułożyć sobie w pełni funkcjonalny pulpit
Urządzenia stacyjne to nie tylko pulpit, ale przede wszystkim system zależności. W chwili obecnej zależności zapisane są jako kawałek (kawał...) kodu źródłowego i są ściśle powiązane z pulpitem i urządzeniami zewnętrznymi. W planach jest zastąpienie tego uniwersalnym modułem zależności opartym na modułach o układzie geograficznym, który prawdopodobnie będzie mniej realistycznie odzwierciedlał urządzenia typu E (będzie je bardziej udawał niż wiernie symulował obwody przekaźników), ale za to będzie bardziej zwarty, mniej problematyczny do "zaprogramowania" i pozwoli na symulowanie innych systemów. Nie mniej jednak tworzenie nowego symulatora wiązać się będzie z koniecznością poskładania tego finalnie na poziomie kodu i nie prędko się to zmieni.
wersje dla systemów innych niż Windows
W planach jest też przeniesienie kodu na Lazarusa, który pozwoli tworzyć wersje na inne platformy.
-
W planach jest też przeniesienie kodu na Lazarusa, który pozwoli tworzyć wersje na inne platformy.
A może tak spróbować napisać w C++ lub javie? myślę że był by to bardziej uniwersalny język i mogło by to zwiększyć liczbę ludzi rozwijających program ;)
Można opublikować również pliki z kodem w takich serwisach jak GitHub i/lub Sourceforge
Urządzenia stacyjne to nie tylko pulpit, ale przede wszystkim system zależności. W chwili obecnej zależności zapisane są jako kawałek (kawał...) kodu źródłowego i są ściśle powiązane z pulpitem i urządzeniami zewnętrznymi.
Pomyślałem że gdyby interfejs był by modułowy, a do kostek był przypisany obsługujący je (i zależności) kod to można by było ułatwić rozbudowę
Nie mniej jednak tworzenie nowego symulatora wiązać się będzie z koniecznością poskładania tego finalnie na poziomie kodu i nie prędko się to zmieni.
Gdyby udało się zrobić, że te snippety i moduły były by ładowane dynamicznie to rozwiązało by wspomniany problem
No to siadaj do kompa i pisz...
Niestety nie piszę w Delphi ani Pascalu :(
Każdy może złożyć własny pulpit w programie EPK. Tylko nie wiem jaki ma sens wymyślanie własnego pulpitu do gotowej stacji.
Możesz mnie podlinkować do strony z tym EPK? Dzięki
-
Możesz mnie podlinkować do strony z tym EPK? Dzięki
Odezwij się bezpośrednio do Pawła. Najlepiej poprzez PW.
-
A może tak spróbować napisać w C++ lub javie? myślę że był by to bardziej uniwersalny język i mogło by to zwiększyć liczbę ludzi rozwijających program ;)
Chyba nie orientujesz się jak duży jest kod ISDRa podając takie propozycje...
-
Chyba nie orientujesz się jak duży jest kod ISDRa podając takie propozycje...
Odsyłam spowrotem do mojego pomysłu z pocztku, gdzie napisałem, że kod można by było rozbić na moduły, co ułatwiło by prace rozwojowe, gdyż pracowało by się z mniejszymi partiami kodu
No to siadaj do kompa i pisz...
Niestety, kod isdr nie jest chyba nigdzie udostępniony
-
No to siadaj do kompa i pisz...
Niestety, kod isdr nie jest chyba nigdzie udostępniony
Ale przecież twórcy co jakiś czas na forum poszukują osób chętnych do współpracy. Kiedyś odpowiedziałem, ale na tamten czas nie programistów poszukiwali. Paweł jednak pozwolił mi się zapoznać z biblioteką ISDR.
Chyba nie orientujesz się jak duży jest kod ISDRa podając takie propozycje...
Odsyłam spowrotem do mojego pomysłu z pocztku, gdzie napisałem, że kod można by było rozbić na moduły, co ułatwiło by prace rozwojowe, gdyż pracowało by się z mniejszymi partiami kodu
Więc właśnie... miałem okazję zapoznać się z biblioteką i
1/ jest potężna, więc jej rozbicie na mniejsze moduły przechowywane np. w postaci dll-i, to gigantyczna praca,
2/ trzeba znać się nie tylko na języku programowania, ale przede wszystkim znać się na pracy ISDR żeby wiedzieć, jaka procedura i funkcja w bibliotece symuluje jakie zdarzenie w urządzeniach SRK, łączności i jaką sytuację ruchową.
Jeśli jednak mimo to chcesz spróbować swoich sił, zgłoś się do Pawła, może pozwoli Tobie zapoznać się z biblioteką, ale obawiam się, że to będzie słomiany zapał. ;)
-
1/ jest potężna, więc jej rozbicie na mniejsze moduły przechowywane np. w postaci dll-i, to gigantyczna praca,
można przecież stworzyć własny rodzaj bibliotek (np. z rozszerzeniem .isdrmod), które było by wykorzystywane wyłącznie przez IDSR, co pozwoliło by w przyszłości łatwiej przenieść na inne systemy operacyjne
Jeśli jednak mimo to chcesz spróbować swoich sił, zgłoś się do Pawła, może pozwoli Tobie zapoznać się z biblioteką, ale obawiam się, że to będzie słomiany zapał. ;)
Paweł jest chyba bardzo zajęty skoro jeszcze nie odpisał na moje poprzednie PM ;)
Dodatkowo, myślę że dobrym pomysłem było by przeniesienie projektu z Deplhi na np. C++ lub javę, które w przeciwieństwie do Delphi i Pascala umożliwiają stworzenie (w przypadku C++ kompilację) wersji dla np. Linuxa
-
Dodatkowo, myślę że dobrym pomysłem było by przeniesienie projektu z Deplhi na np. C++ lub javę...
Aż wczoraj sprawdziłem z ciekawości... Obecna biblioteka ma ponad 16,3 tys linii kodu. Paweł zaczął pracę nad nią w 2007 roku. Także wybacz, nie zgadzam się z Tobą. Przeniesienie wszystkiego na inny język to nie jest praca polegająca na wrzucenie do Google Translate... To jest konieczność napisania wszystkiego od nowa, z uwzględnieniem bardzo wielu różnic, jakie występują pomiędzy Delphi, Javą i C++ i oczywiście koniecznie trzeba by kod zoptymalizować. To jest wytężona praca programistyczna. Zakładam, że jesteś kozak w C++ i Javie, skoro tak usilnie to proponujesz, ale i tak to zbyt wiele pracy dla jednego programisty, aby we w miarę racjonalnym czasie (a być może i w ogóle) doczekać się oprogramowania symulatora pod nowym silnikiem.
...z Deplhi na np. C++ lub javę, które w przeciwieństwie do Delphi i Pascala umożliwiają stworzenie (w przypadku C++ kompilację) wersji dla np. Linuxa
Sorry... ale muszę zadać Ci kłam ;). Gadasz bzdury. Czy kiedykolwiek zapoznawałeś się z projektem zwanym Lazarus? To narzędzie umożliwiające zakodowanie multiplatformowych aplikacji w języku Delphi. Jest to na tyle świetne narzędzie, że można kod napisać jeden raz i bez żadnych poprawek kompilować pod Lazarusem w Linuxie, Windowsie aplikacje przeznaczone dla konkretnych systemów operacyjnych.
Jakie są zatem racjonalne przesłanki, żeby przepisywać ponad 16 tys. linii kodu napisanego w Delphi na inny język programowania. Tylko nie mów proszę, że wydajność C++ lub Java jest wyższa, bo będę musiał znowu zadać Ci kłam.
Po pierwsze. To dziecinne argumenty osób, które przymierzały się do pisania gier w Delphi wykorzystując gotowe pakiety do programowania 3D. Faktycznie wydajność takich gier była zdecydowanie niższa, niż gier 3D pisanych w C++. Ale szczerze? Nie znam porządnego programisty, który pisząc gry 3D z prawdziwego zdarzenia korzysta z gotowych komponentów. Takie gry nie będą nigdy wydajne, bo oprócz tego, co jest tam potrzebne znajdzie się tam mnóstwo kodu absolutnie niepotrzebnego. Każdy szanujący się programista 3D sam oprogramowuje sobie tylko to, co jest mu potrzebne.
Po drugie. ISDR jest prostą aplikacją okienkową, nie obciążającą zanadto zasobów systemowych. W takich aplikacjach pojęcie wydajności jest w ogóle bardzo mało istotne.
Takie jest moje zdanie :)
-
Szkoda, że nie znam się na programowaniu, nie wiem czy można się samemu nauczyć tzn na pewno można, ale wtedy trzeba mieć większe IQ. Nie ma nawet takiej szkoły czy kursów w moim mieście, które by uczyły od podstaw programowania. Przeglądnąłem kilka książek ale jednak to nie jest to. Co innego uczyć się samemu z książek, a co innego chodzić na kurs do profesjonalnego programisty. Ale ciekawy jestem jak wygląda "Obecna biblioteka, która ma ponad 16,3 tys linii kodu".
-
Chcieć, to już sporo. Wystarczy zaopatrzyć się w oprogramowanie tzw "turbo pascala", przegrzebać google w poszukiwaniu kursów i można stworzyć swój pierwszy program. Wystarczą chęci.
A co do biblioteki isdr, to jest duża. A jak już wspomniał @axtomek, do jej zrozumienia potrzebne jej minimum wiedzy z zakresu inżynierii ruchu i przede wszystkim automatyki urządzeń srk.
-
...nie wiem czy można się samemu nauczyć tzn na pewno można...
Można można, tylko trwa to zdecydowanie dłużej, niż w szkole, bo do wszystkiego dochodzi się samemu. Ja jestem samoukiem. Siedzę jednak w Delphi od 1998 roku i nadal jest mnóstwo rzeczy, których nie umiem. W szkole masz instruktora, który pokaże Ci co i jak zrobić, więc jest łatwiej, ale masz kolokwia, egzaminy i zwyczajnie musisz gonić z materiałem, nawet, jeśli jest on dla Ciebie nie zrozumiały. Grozi to tym, że programowanie nie będzie sprawiało Tobie przyjemności, bo się będzie kojarzyło z przykrymi obowiązkami. Gdy uczysz się samemu, to jest to mozolny i długotrwały proces, ale masz satysfakcję z każdej nawet "pierdółki", którą uda się Tobie rozgryźć. Programowanie wtedy jest dla Ciebie frajdą.
@MaKu: Jeśli ktoś chce zacząć przygodę z Delphi (Pascalem) w najczystszej postaci API to można polecić darmowy Free Pascal Compiler. Jeśli zaś koś miałby chęć uderzyć od razu w kierunku programowania obiektowego, wtedy polecam również darmowego, wspomnianego wcześniej, Lazarusa.
-
Jeśli ktoś chce zacząć przygodę z Delphi (Pascalem) w najczystszej postaci API to można polecić darmowy Free Pascal Compiler.
Ja co nieco pisałem w Turbo Pascalu i polecam kompilator firmy Borland. Teraz już jest darmowy, więc można go legalne ściągnąć. Ewentualnie gdzieś też posiadam instalkę do wersji 5 i 7.
-
Kompilator firmy Borland (Turbo Pascal) jest naprawdę udany i ma sporo bibliotek do wykorzystania, ale na jego niekorzyść przemawia to, że jest to oprogramowanie nierozwijane od bardzo już wielu lat. Nie ma gwarancji, że skompilowane w nim aplikacje będą działać prawidłowo szczególnie pod nowszymi wersjami Windows. FPC jest projektem rozpowszechnianym na licencji GNU i cały czas rozwijany. Jeśli nawet są jakieś bugi, to są one zgłaszane i usuwane na bieżąco.
Na korzyść FPC przemawia też, że podobnie, jak Lazarus jest to oprogramowanie multiplatformowe i tak samo można tworzyć aplikacje na różne systemy operacyjne. Turbo Pascal jest aplikacją stworzoną dla MS DOS i działa w systemach MS DOS oraz wspierających je MS Windows. Podobnie tworzone w nim aplikacje.
W żadnym jednak wypadku nie odradzam Turbo Pascala. Wybór należy do każdego z osobna.
-
Nie ma gwarancji, że skompilowane w nim aplikacje będą działać prawidłowo szczególnie pod nowszymi wersjami Windows.
To niestety racja. Programy zawsze pisałem na WinXP, ale na Win7 działać nie chciały. Po skompilowaniu w FPC wszystko ładnie chodziło. :)
A, jeszcze w Borlandzie funkcja Delay nie działała prawidłowo i program zamiast czekać 9 sekund, czekał mniej niż sekundę. :(
-
A, jeszcze w Borlandzie funkcja Delay nie działała prawidłowo i program zamiast czekać 9 sekund, czekał mniej niż sekundę. :(
Akurat z tym problemem się nigdy nie spotkałem... Działała mi ładnie i w Borlandzie, ale Turbo Pascala nie używam od wielu wielu lat... Być może ma to związek z tym, że gdy Pascal był pisany komputery były jeszcze prymitywne. Jego funkcje czasowe były ściśle związane z częstotliwością taktowania procesora. Szczegółów nie powiem, bo się nie zagłębiałem, ale pamiętam, że był wiele lat temu moment, gdy wdrożono jakąś nową technologię w konstrukcji procesora (nie wiem, czy to nie był Pentium II lub III) i aplikacje pisane pod Pascalem w ogóle nie chciały działać, bo pojawiał się jakiś problem dzielenia przez 0. Były później oczywiście opracowane rozwiązania tego problemu i Turbo Pascal można było dalej eksploatować. Twój problem może mieć podobne źródło. Takie są uroki korzystania z przestarzałego oprogramowania. Ja przez wiele lat korzystałem z Delphi 7 (notabene też już darmowy w pewnych wersjach). W końcu po przejściu na Win Vista zabrakło mi cierpliwości, bo z Delphi 7 działy się rzeczy najróżniejsze. Teraz jestem szczęśliwym użytkownikiem Lazarusa i bardzo sobie ten pakiet cenię.
-
Ja rozumiem że wielu z was uważa mój pomysł za zły, lecz moją intencją była jedynie chęć ułatwienia rozwoju symulatora poprzez rozbicie tych 16,3 tys. linijek kodu na mniejsze porcje, co pozwoliło by znacznie skrócić czas pracy ;)
-
OK. Intencje Twoje w kwestii podzielenia kodu są akurat jasne. Nie są jasne wprawdzie intencje w kwestii przepisywania kodu pod innym językiem programowania, ale to zostawmy.
Mnie nurtuje coś zupełnie innego. Czy zamierzasz się podjąć osobiście przetworzenia tej biblioteki na odpowiednie moduły, czy proponujesz, aby zajęli się tym inni? ;)
Samego pomysłu nie uważam za zły, ale uważam go za mało realny. Poza tym nie jestem pewien, w czym Twoim zdaniem miałoby pomóc rozbicie jednej dużej biblioteki, na kilka mniejszych - tak konkretnie.
-
Czy zamierzasz się podjąć osobiście przetworzenia tej biblioteki na odpowiednie moduły, czy proponujesz, aby zajęli się tym inni? ;)
mogę spróbować sam, ale każda pomoc będzie mile widziana ;)
Poza tym nie jestem pewien, w czym Twoim zdaniem miałoby pomóc rozbicie jednej dużej biblioteki, na kilka mniejszych - tak konkretnie.
Jak napisałem w PM do Pawła, rozbicie kodu na mniejsze pozwoliło by pracować na mniejszych partiach kodu (zamiast pracować na raz nad 16,3 tys. linijkami kodu), co przyśpieszyło by prace rozwojowe.
Pracuję nad tak zwaną mindmapą (mapą myśli jakby ktoś nie wiedział co to jest ;) ) która schematycznie pokazała by przykład proponowanego przeze mnie rozwiązania.
-
Poza tym nie jestem pewien, w czym Twoim zdaniem miałoby pomóc rozbicie jednej dużej biblioteki, na kilka mniejszych - tak konkretnie.
Jak napisałem w PM do Pawła, rozbicie kodu na mniejsze pozwoliło by pracować na mniejszych partiach kodu (zamiast pracować na raz nad 16,3 tys. linijkami kodu), co przyśpieszyło by prace rozwojowe.
Aktualnie prace rozwojowe raczej pójdą w kierunku innym, niż rozbudowa kodu źródłowego. Wspomniana biblioteka jest doprowadzona do takiej funkcjonalności, że nie wymaga większych zmian, nie licząc wprowadzanych od czasu do czasu poprawek. Inna sprawa, że próby jej ruszania to jak gra w bierki ;)
-
Najpierw powstał interfejs pulpitu a później kod? Wiem, ze to głupie pytanie ale ktoś musi takie zadawać :D
-
Jaki interfejs pulpitu i jaki kod masz na myśli?
-
Nie jestem pewien, ale pewnie chodzi mu o elementy wizualne (komponenty osadzone na formatce) i bibliotekę.
-
Nie jestem pewien, ale pewnie chodzi mu o elementy wizualne (komponenty osadzone na formatce) i bibliotekę.
Tak jest właśnie o to mi chodzi, nie precyzyjnie zadawane pytania wynikają z małej jak na razie znajomości tematu
-
Chciałbym zauważyć to co jest napisane w aktualnej dokumentacji ISDR dołączonej do programu:
Podczas tworzenia programu położono duży nacisk na uniwersalność i modułową budowę kodu źródłowego,
co ma w przyszłości ułatwić tworzenie na jego podstawie symulatorów innych posterunków.
Może to zabrzmi dziwnie, ale to co próbuję zrobić pasowało by do cytowanego przeze mnie założenia opisanego w dokumentacji.
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 ). Dokumentacja ISDR zawiera również wiele ciekawych informacji na ten i inne tematy
Załaczam mindmapę o której pisałem wcześniej. Nie ma na niej wszystkich funkcji, gdyż spowodowało by to zmniejszenie jej czytelności.
Notatka: Załączona mindmapa jest jedynie przykładem
-
Witam serdecznie!
Dzisiaj jak jechałem sobie do domu z pracy to przyszedł mi do głowy taki mały, diabelski pomysł na udoskonalenie ISDR do zrealizowania za parę lat. ;) 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).
Pozdrawiam,
Fryderyk
-
Zamykać uszkadzać to można dowolnie, takie pomysły były już tu z tego co pamiętam. Uszkodziłem ostatnio anglika (całego) 27ab/cd czyli w położeniu na wprost, dało to niemożność jazdy z grupy na Lisków Ryn. i odwrotnie do tego poleciała jeszcze izolacja toru 2c i młyn gotowy bez zamykania toru szlakowego, bo jednak do Rynku poc. trzeba puścić. Gama usterek jest spora, rozwiązywanie problemów również.
-
Dzisiaj jak jechałem sobie do domu z pracy to przyszedł mi do głowy taki mały, diabelski pomysł na udoskonalenie ISDR do zrealizowania za parę lat. ;) 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).
Nikt Ci nie broni zrobić czegoś takiego. Zamykasz tor, zamawiasz sieciowego i hulaj dusza :)
-
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).
-
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. ?
-
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.
-
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 ;)
-
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? ;)
-
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ść ;)
-
czyli nigdy :P
-
panda3d - może w tym szybciej dało by się zrobić symulator w wersji 3d
-
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
-
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ć.
-
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
-
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.
-
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:
- ...
- ...
-
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 :)
-
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.
-
Panowie, to co proponujecie, to w większości niepotrzebne wodotryski. Zgadzam się z @Maku, że bardziej potrzebne jest łatwiejsze robienie nowych pulpitów, niż 3d, które nie wiem do czego zastosować?
-
Ja w istocie też tak uważam. Ale skoro zaczęto mówić o 3D, to odniosłem się do tego. Jednak uważam, że absolutnym priorytetem powinno być dokończenie ISDR-a w takiej postaci w jakiej jest.
-
Tak na pewno będzie. Rzuciłem temat, w razie gdyby ktoś czuł się na siłach, chciał pomóc i przygotował tę część 3D tak, żeby Paweł nie musiał tego robić samodzielnie.
-
Można przyjżeć się silnikom graficznym dla Lazarusa, w związku z tym, że prawdopodobnie projekt docelowo zostanie na niego przeniesiony (ale to jest na razie tak samo bliskie realizacji, jak sam silnik 3D). Słyszałem m.in. o Castle Game Engine, nie wiem na ile to jest dopracowane i wydajne. Kiedyś testowałem demo komercyjnego TrueVision w Delphi i było to dość proste w obsłudze - można było ładować modele w popularnych formatach, ustawiać ich położenie, ustawiać kamerę, światło itp. bez wgłębiania się w działanie samego silnika (ale wymagało to instalacji silnika w systemie).
-
No właśnie... wszystkie te silniki mają w zasadzie te same cechy... są proste w użyciu, ale niestety kuleją z wydajnością, bo ładują mnóstwo nie wykorzystywanych funkcji i procedur. Do prostego 3D się sprawdzą, ale szału nie będzie. Zawrotnej ilości FPS się na tym nie uzyska. Fajnie, jakby w ekipie znalazł się jakiś konkretny programista 3D. Można by pokusić się o napisanie własnego silnika, a co za tym idzie uzyskanie wydajności z prawdziwego zdarzenia.
Jest jeszcze inne rozwiązanie... takie o którym pisałem wcześniej... zapożyczyć trochę wiedzy z kodu Open Source'owego Open Rails. Poza możliwością skonstruowania wydajnego silnika 3D, takie rozwiązanie ma jeszcze pewne dodatkowe korzyści. Open Rails jest kompatybilny z taborem MS Train Simulator, a co za tym idzie na pewno nie zabrakłoby modeli pociągów i infrastruktury kolejowej. Tego po prostu w internecie jest opór.
=== DOPISANE ===
Choć widzę, że ORTS też korzysta przynajmniej częściowo z gotowych komponentów (XNA Game Studio 3.1)
-
Paweł czy jest możliwość wprowadzenia opcji zatrzymania składu osobowego z powodu tego, że ktoś nie zdarzył wsiąść, albo inna sytuacja wypadek na przejeździe? Zerwanie trakcji, konieczność serwisu torów, a w przyszłości jeśli będą inne stacje informacja o konieczności skomunikowania? Czy to już za wiele ? ;)
-
Zatrzymanie składu bo ktoś nie zdążył wsiąść to raczej mało istotna rzecz w symulatorze nastawni. Na jedno wychodzi z losowym opóźnieniem odjazdu. Zatrzymanie pociągu z przyczyn losowych, może być na przejeździe, jest w przyszłości przewidywane. Wymóg skomunikowania można zawrzeć w opisie rozkładu jazdy.
-
W kolejnej wersji isdr mogło by być w rozkładzie standardowym jakieś roboty na szlaku i zamknięcia
-
To zamów sobie drezynę/sieciowego zamknij tor wyślij je na szlak i już masz roboty. :)
-
Według mnie przydałoby się podnieść prędkość do Testowa przynajmniej na 100 km/h i "dobudować" 3 tor na Wilamowice np. z SBL i prędkością powiedzmy 140 (w tymi przebudowa przejazdu kat. C na B, żeby wg przepisów było ok :D) ,wtedy mogłoby być większe obłożenie i zawrotniejsze prędkości. Przynajmniej dla ekspresów 8)
Chociaż jak wiadomo trzeba na to poświęcić nie mało czasu.
-
Fikcyjne posterunki nie będą rozbudowywane. Aktualne prace idą w kierunku dość istotnych zmian w architekturze symulatora i sposobie symulacji zależności, a w dalszej kolejności odwzorowania posterunków rzeczywistych.
Roboty na szlaku itp. przewidywane są w postaci scenariuszy, których wprowadzenie planowane jest w przyszłości.
-
A kiedy ma wyjsc kolejna wersja isdr??
-
@komandos250319 jak kod napiszesz programu to wyjdzie ;D.
-
@komandos250319 jak kod napiszesz programu to wyjdzie ;D.
ale, ze stylistyką zdania wszystko ok.?
-
@EN57-002 nie czepiaj się już ;)
-
A czy jest możliwosć, aby wybrać sobie tryb nocny tzn. aby okienka podgląd terenu, łącznosć itp. były w odwróconych kolorach. Bo teraz wieczorem na lapku jak włącze podgląd terenu to aż w oczy nap**dala. :'(
-
Przyciemnij wyświetlacz i już nie będzie za bardzo świecić w oczka ;)
-
Czy Autorzy mają w swoich planach ulepszenie edytora rozkładu? Bo ja mam pomysła... ;) mógłbym zrobić aplikację, która robiłaby rj, wystarczyłoby wpisać co jedzie i o której rusza, a program sam wyliczyłby z dokładnością do 1 sek. czas przejazdu. Modyfikacje byłyby bardziej intuicyjne np. jeśli rodzaj poc. to ROJ to automatycznie jest przypisywane: ident. W4, typ poc. osobowy, sem. wyj. oraz nie trzeba będzie szukać parametrów i liczyć długości pojazdów. Co Wy na to?
-
To może zrób pdfa z podpisami co gdzie i jak wstawić by samemu zrobić rozkład jazdy, mnie udało sie zrobić 1 pociąg, aa drugi nie idze.
-
Weź pod uwagę, że wpiszujesz ROJ. Ok, osobowy, więc zakładamy, że wszędzie staje, jednostka elektryczna trakcyjna. Tylko teraz: musiałbyś jeszcze zrobić generowanie składów. Np. wybieram EN57, Elfa itp. Liczbę sztuk w składzie. A, niektóre "typy", jak np. Elf, o ile dobrze kojarzę, są w różnych wersjach długości... Nie mówiąc o ROE....
-
A jeszcze gdyby dał MOJ, MPJ, APJ, fakt jest tyle do wyboru że hoho.
Teraz czytałem a profilu PLK-i że w pn jest chat z ludźmi co tworzą rozkład, zapytaj ich o rzeczy co Cię martwią.
-
To może zrób pdfa z podpisami co gdzie i jak wstawić by samemu zrobić rozkład jazdy, mnie udało sie zrobić 1 pociąg, aa drugi nie idze.
Program ma za zadanie zminimalizować prawdopodobieństwo błędu przez użytkownika, więc niektóre funkcje będą automatycznie przypisywane podczas podawania podstawowych danych.
Teraz czytałem a profilu PLK-i że w pn jest chat z ludźmi co tworzą rozkład, zapytaj ich o rzeczy co Cię martwią.
Zapytam czy użyczyliby mi SKRJ, OT, KWR, SRR ;D
-
@DamDam w jakim języku piszesz, ten "program"?
-
Czy Autorzy mają w swoich planach ulepszenie edytora rozkładu?
W planach jest całkowita zmiana formatu rozkładu jazdy, ale to dopiero za jakiś czas. Jednak nie przewiduję automatycznego obliczania czasów - to zadanie dla oprogramowania do liczenia przejazdów teoretycznych, a nie edytora rozkładu jazdy. Aktualny edytor informuje jedynie o czasach mocno różniących się od pozostałych jako potencjalnych błędach.
-
@DamDam w jakim języku piszesz, ten "program"?
Na razie ucze się C++.
Czy Autorzy mają w swoich planach ulepszenie edytora rozkładu?
Aktualny edytor informuje jedynie o czasach mocno różniących się od pozostałych jako potencjalnych błędach.
A mój program będzie te błędy eliminował w czasie rzeczywsitym. :P
-
Ale, jaki ma sens obliczanie rzeczywistych czasów przejazdu? Przecież, jest rozkładowy. Wiadomo, że każdy mech inaczej kręci kołem, zależy też to od rodzaju pociągu. Chyba, że macie na myśli coś innego? A opóźnienia, w SWDR, wynikają z "wklepywania" godzin, przez ISDRów.
-
A mój program będzie te błędy eliminował w czasie rzeczywsitym. :P
Możesz przybliżyć, na podstawie czego będzie eliminował błędy (wpisywanie standardowych czasów ustalonych dla danej kategorii pociągu, obliczanie czasów na podstawie parametrów fizycznych składu?), i co to znaczy w czasie rzeczywistym?
Odnośnie poprzedniego pytania, przewiduję tryb "nocny" podglądu sytuacji w terenie.
-
Cześć!
To mój pierwszy post, więc witam wszystkich :)
Mam następujący pomysł: Na przykład do stacji Wilamowice można dodać coś a'la ZNTK (hala, do której mogą wjeżdżać zdefektowane jednostki do naprawy). Po wjeździe symulator losowałby długość naprawy (od kilku godzin do kilku dni).
Co o tym sądzicie?
-
Mechaniq
Fikcyjne posterunki nie będą rozbudowywane. Aktualne prace idą w kierunku dość istotnych zmian w architekturze symulatora i sposobie symulacji zależności, a w dalszej kolejności odwzorowania posterunków rzeczywistych.
Roboty na szlaku itp. przewidywane są w postaci scenariuszy, których wprowadzenie planowane jest w przyszłości.
-
Wilamowic nie ma ;) Można w rozkładzie zrobić jakieś "podsyły" wirtualne...
-
Stacja Wilamowice posłużyła mi jedynie jako przykład. Chodzi o sam pomysł.
-
Chodzi o sam pomysł.
Witaj na forum :) Wiesz ktoś ten pomysł musiał by, zrealizować. A autorzy programu mają, swe priorytety.
-
Nie przewiduję symulowania ZNTK naprawiającego usterki taboru w symulatorze.
-
Wystarczy że chłopaki już porobili firmy, rampy place ładunkowe, a tego jest zdecydowanie więcej w kraju niż ZNTK. Ja tylko proponuję na obecnych rampach wprowadzić ograniczenia prędkości z powodu złego stanu toru, oraz jeśli to jest możliwe losowe wykolejanie składów bo np zamiast SM42 wepchaliśmy Class66. Ot taki mały realizm by był ;p
-
Wtrącę trochę z innej beczki. Uprzejmie melduję że na Win10 symulatory śmigają aż miło (przynajmniej na obecnym buildzie)
-
Taka sprawa w przyszlym isdrze przydalo by sie zrobic takie cos jak wystepuje usterka blokady liniowej z Testowa Do liskowa to niech zglaszaja o ktorej ten pociag odjechal
-
Od tego jest TZP, które się zgłasza po zauważeniu takowej usterki. Edit: A czy udało by się zaimplementować widok zewnętrzny 2D w takiej postaci jak w załączonym obrazku z rainsted?
-
A w jakim celu? Poza tym głupio by to wyglądało, obecnie widok na grunt jest "od góry", a pociągi raczej na boku nie jeżdżą :)
-
Być może zostanie w przyszłości zaimplementowany podgląd składów (w osobnym oknie, nie jako widok zewnętrzny), ale na razie to nie jest możliwe.
-
Gdzie mogę uzyskać dostęp lub pobrać program do budowy pulpitu ISDR dyżurnego ruchu, wraz z rysowaniem planu schematycznego na ewentulany widok podglądu stacji itp.? :)
-
Gdzie mogę uzyskać dostęp lub pobrać program do budowy pulpitu ISDR dyżurnego ruchu, wraz z rysowaniem planu schematycznego na ewentulany widok podglądu stacji itp.? :)
Proś autora. Kiedyś miał na serwerze, ale część zniknęła.
http://www.kontrakt-bhp.com.pl/paul/ (http://www.kontrakt-bhp.com.pl/paul/)
Mam nadzieję, że Paweł mnie za to nie zabije. EPK masz do "kostek".
-
To tylko edytor grafiki pulpitu. Nie ma aktualnie możliwości dokonywania zmian w ISDR przez użytkowników.
-
Bo ja dla smyka chciałbym stworzyć stację. I dlatego pytam o program do tworzenia stacji, pulpitu kostkowego itp. :)
-
Bo ja dla smyka chciałbym stworzyć stację. I dlatego pytam o program do tworzenia stacji, pulpitu kostkowego itp. :)
Zrobienie bitmapy pulpitu, rozrysowanie układu, grupy szczelin itp itd, zależności, potem złożenie, tak to "wyglądało", ale chyba szykują się zmiany.