Train Driver 2
Dział ogólny => Dyskusje => Wątek zaczęty przez: Sunsie w 25 Września 2022, 00:54:05
-
Cześć,
Wpadłem na, wydaje mi się, dość trudny do realizacji pomysł. Dokładniej chodzi o wcześniej ustalone perony i tory przy nich dla pociągów pasażerskich. Jest to element, którego w TeDeku bardzo brakuje. Są scenerie, np. Okoń Główny, na których są dwa perony, każdy po dwa tory. Jeśli taka funkcja zostałaby dodana, pociągi nie zatrzymywałyby się tam, gdzie dyżurny sobie wymyśli, tylko na wyznaczonym torze. Dodatkowo DR z pierwszej stacji musiałaby wskazać, na którym peronie i torze pociąg ma zacząć bieg.
Edit:
Zamiast tworzyć nowy wątek, postanowiłem edytować ten.
Wraz z wprowadzeniem ustaleń torów i peronów, można wprowadzić automatyczne zapowiadanie pociągów, które, jako manualne, było kiedyś stworzone (nigdy się z nim nie spotkałem). Komunikat głosowy IVONY byłby słyszany przez DR oraz wszystkich ludzi stacji peronach. W przypadku zmiany peronu, musiałoby zostać użyte dodatkowe narzędzie (coś jak SUP). Wszystko mogłoby zostać połączone z wyświetlaczami na peronach, których synchronizacja nie powinna być tak trudna do zrobienia, jak samo narzędzie.
Cały SIP (proponuję taką nazwę programu) mógłby być ogromną zmianą na plus, która dodałaby realizmu do tego symulatora.
-
Wersja krótka:
Może kiedyś ale nie teraz.
Wersja długa:
A tak na poważnie to sam temat był pewnie nieraz wałkowany czy to na forum czy na mm i samo hasło "zapowiedzi stacyjne" to tylko wierzchołek góry lodowej. Sam się kiedyś zastanawiałem jak od strony technicznej można by zaimplementować system zapowiedzi i odpowiedź brzmi: trzeba nad tym posiedzieć dłużej niż się wydaje. Jak wiadomo najsłabszym ogniwem w każdym systemie jest człowiek i nie inaczej jest tym razem - może w tym wypadku nie tyle jest najsłabszym co najbardziej nieprzewidywalnym. Na dobry początek można zacząć od przypisania torów do poszczególnych pociągów. Jak wiemy symulacja jaką dostajemy jest na takim poziomie na jakim sobie ją fundujemy - jedni dyżurni będą dyktować pełne rozkazy pisemne, będą zawsze podawać powód podania sygnału zastępczego, a inni będą dawać rozkazy typu "Rozkaz pisemny J - jedź bo mi szlak blokujesz" i będzie im zależeć tylko na tym, żeby tylko wszystko wyprawić. Co w wypadku tego drugiego typu osób? Jak dopilnować aby każdy stosował się do tego systemu? Raczej nie chcemy sytuacji gdzie ktoś złoży skargę bo dyżurny wpuści pociąg na tor 1 bo tak mu będzie wygodnie, a w zapowiedzi będzie, że wjedzie na tor 6 (brzmi absurdalnie ale trzeba brać pod uwagę wszystkie możliwe przypadki). Zapewne odpowiesz, że do tego by miał służyć program w którym dr zmienił by numer toru na który wpuści pociąg i po problemie ale znowu pytanie jak zobligować użytkownika do korzystania z takiego programu? Najlepszym przykładem pokazującym problemy z dodatkowymi programami jest wspomniany SUP, który też zdarza się, że nie jest uruchamiany i na pytanie czemu program nie jest włączony dr odpowiada "bo mi nie działa" albo "a co to takiego?". Teraz pora na kwestię zapowiedzi typu "pociąg wjedzie ...", "pociąg podstawia się ...", "pociąg stoi przy ..." - kiedy wiedzieć jaki typ zapowiedzi podać? Inaczej będzie trzeba zareagować w przypadku scenerii gdzie mamy spawn gdzieś na bocznicy, a inaczej gdy spawn jest w peronie. Następnym problem jest system podawania opóźnienia - można pójść niby na łatwiznę i pobierać godzinę odjazdu z poprzedniej stacji ale ... no właśnie to słynne "ale" czyli pobieram godzinę odjazdu z ostatniej stacji ale co jeśli dr z poprzedniej stacji tej godziny nie wpisze? Pobieram godzinę ale pociąg stanie na szlaku bo albo był RS albo nie wiem jak odhamować i opóźnienie dalej rośnie? To co wyżej to tylko jedna część zadania czyli rozwiązanie tych najbardziej podstawowych problemów - druga część to przygotowanie pod ten system zarówno symulatora i swdra czyli jednym słowem mówiąc: implementacja - a i tutaj też problemy się nie kończą ponieważ, żeby zachować jak najwyższy poziom realizmu to zapowiedzi powinny mieć ten swój charakterystyczny megafonowy wydźwięk, który pewnie da się uzyskać przy pomocy jakiejś biblioteki - którą najpierw trzeba znaleźć.
Reasumując:
Nie od dziś wiadomo, że im bardziej prymitywny jest system to tym bardziej zaawansowany musi być jego użytkownik i odwrotnie - tutaj trzeba znaleźć ten złoty środek aby sam system mógł powstać relatywnie niskim nakładem pracy jednocześnie będąc przygotowanym na takie anomalie jak wyżej opisałem oraz żeby nie wymagał do poprawnego działania jakiejś nadmiernej ingerencji użytkownika. No i oczywiście najważniejsze o czym nie napisałem to żeby coś takiego zrobić to potrzebny jest czas - dużo czasu, a przy obecnych jego zasobach nie ma co ukrywać, że lepiej go przeznaczyć na sprawy niecierpiące zwłoki i przynajmniej je doprowadzić do mety. Parafrazując na koniec to co napisałem w wersji krótkiej: zapowiedzi stacyjne to aktualnie pieśń przyszłości i jedynie pozostaje liczyć, że symulator rozwinie się w takim kierunku, że przyjdzie nam na nie czekać krócej niż dłużej.