Zdarzenia związane z siecią trakcyjną

[Ra]

Zdarzenia związane z siecią trakcyjną obecnie w MaSzynie nie istnieją. Oryginalnie w Scenery.doc był opis zdarzenia CurrentEvent, wykonywany przy poborze prądu z sieci, jednak nie został on zrealizowany i nie wiadomo, do czego miał być używany (wczesna wersja przełączania zwrotnic tramwajowych?). Z drugiej strony mamy wskaźniki We — pomijając te informacyjne, istotne dla AI będą:
— We2 — nakaz opuszczenia pantografu, ograniczenie prędkości do 60km/h,
— We3 — podniesienie pantografu,
— We4 — zakaz wjazdu elektrycznych,
— We8 — jazda bez poboru prądu,
— We9 — możliwy pobór prądu.

Do powyższych przypadków proponował bym umieszczenie w torze eventu PutValues z komendą Overhead. Pierwszy parametr określałby znamionowe napięcie w sieci (np. 3000, -600, 15000, 25000) i jednocześnie zezwolenie na podniesienie pantografu. Wartość 0 oznaczałaby brak sieci (tożsamy z zakazem wjazdu elektrycznych). Drugi parametr regulowałby stan pantografu: >0 — opuszczenie pantografu i ograniczenie prędkości, 0 — przejazd bez pobierania prądu, -1 — można pobierać prąd. Czyli było by tak:
— We2 — Overhead 3000 60 — nakaz opuszczenia pantografu, wcześniej ograniczenie prędkości do 60km/h,
— We3 — Overhead 3000 -1 albo Overhead 3000 0 — możliwe podniesienie pantografu,
— We4 — Overhead 0 0 — zakaz wjazdu elektrycznych,
— We8 — Overhead 3000 0 — jazda bez poboru prądu,
— We9 — Overhead 3000 -1 — możliwy pobór prądu.

Ewentualnie, zamiast wartości 1 w drugim parametrze, można by podać zalecany pobór prądu w amperach (jeśli by to miało jakiś głębszy sens, bo zawsze może jechać kilka pociągów pod rząd i ograniczanie poboru w jednym nic nie da).

[Stele]

Zamiast parametru dozwolonego prądu już lepiej by AI kontrolowało spadek napięcia na sekcji i porównywało z zabezpieczeniami wyłącznika. Tylko czy ma to sens? Na poprawnie napisanym scenariuszu nie powinno dochodzić to przeciążeń a nawet jeśli, to nie powinien się sypać przez zwłokę do ponownego załączenia napięcia, a takie sytuacje dodadzą trochę kolorytu.
Pierwszy parametr ma blokować wjazd pojazdów nieprzystosowanych do danej sieci?

[Ra]

Parametry sieci (napięcie, zabezpieczenia) można stwierdzić dopiero po podniesieniu pantografu, no chyba żeby jakiś wirtualny podnosić albo opracować inną metodę "oszukiwania" (istnieją np. asymetryczne pantografy do współpracy z siecią o innym napięciu). Co do drugiego parametru, to myślałem o wyborze pantografu w przypadku maszyn wielosystemowych. W Polsce jeszcze tego nie ma, nie licząc granicy z Niemcami. No i Słowacja przechodzi na 25kV. Wcześniej czy później powstanie sceneria ze zmianą napięcia (możliwe nawet, że linia 139 będzie taką).
  Dodano: 22 Października 2014, 21:16:17 Dobra, drugi parametr może być prędkością jazdy z opuszczonym pantografem, czyli dojdzie opcja realizacji We2.

[Stele]

Czy wersje b/c mogą mieć komórkę we wskaźniku i event przypisany dopiero do toru za rozjazdem? Będzie to działać poprawnie? Przydałoby się jeszcze rozróżnienie na lokomotywy i EZT do We 9 i We 3b, którego nawet nie posiadamy.
Jeśli nazwę eventu dałem jako P1 inca wskaźnika, to każdy nieunikalny będzie logował duplikat, gdy ma tam none, czy zostanie pominięty?

[Ra]

Zasadniczo to eventy sieci powinny być skanowane, więc PutValues musi się znajdować (współrzędne) za rozjazdem, nawet jeśli wskaźnik jest przed. Rozróżnienie EZT/nie będzie raczej na poziomie AI pojazdu, AI będzie w stanie wiedzieć, gdzie ma pantografy. Wskaźniki (w sensie PutValues) muszą być unikalne, żeby był przypisane do toru w odpowiednim miejscu. W tej chwili nie ma to znaczenia, ale po przerobieniu na skanowanie będzie miało, więc lepiej od razu zrobić dobrze.

Testowałem wersję 459 na TD, gdzie zamiast semaforów podłączyłem Overhead i wersja ta działa błędnie. Jest już zrobiona poprawka i przetestowana, ale czekam na inne uwagi przed złożeniem kolejnej wersji.

[Stele]

To eventy skanowanie nie są przesuwane po trajektorii do rzutu komórki, nawet gdy ta wypada przy innym odcinku toru? Jeśli wskaźnik będzie sztucznie przesunięty za rozjazd, to taki pojazd wjedzie na zwrotnicę i stanie na niej, uszkadzając pantograf.
Pytam się o wskaźniki nieprzypisane do toru. Tak, by można było dodać wpisy bez klonowania wskaźników. Wszystkie przypisane to będziemy mieli za trzy lata. Czy "event none putvalues..." będzie logowany jako duplikat?

[Ra]

Eventy skanowane mają współrzędne, które są rzutowane na trajektorię (konkretniej na wektor ruchu). Natomiast wskaźniki We na ogół stawia się przed zwrotnicą, podczas gdy informacja powinna być za zwrotnicą. Gdyby umieścić przed zwrotnicą, trzeba by używać komórki pamięci i zmieniać jej zawartość zależnie od ustawienia zwrotnicy. Skanowanie obejmuje co najmniej 150m przy minimalnej prędkości, być może zwrotnice powinny przedłużać skanowanie. Czy jest sens dodawać puste eventy do wskaźników, to nie wiem. Jest to doraźne rozwiązanie i pewnie wyjdą jakieś efekty uboczne, na które trzeba będzie znaleźć rozwiązanie. O ile pamiętam, to eventy o nazwie none są ignorowane.

[Stele]

W załączniku paczka wskaźników zmodyfikowana o wpisy eventu. W torze pod wskaźnikiem należy umieścić event kierunkowy o nazwie identycznej z nazwą egzemplarza wskaźnika.
Niestety jednak "none" nie jest ignorowane. "none_warning" z nieprzypisanych W6 są ignorowane a "none" z We logowane jako duplikaty. Nie powinno to szkodzić symulacji, ale brzydko wygląda.

[Ra]

Pewnie by to musiało być "none_". Ewentualnie można dać znak # na początku nazwy, takie też powinny być ignorowane (w sensie nielogowania duplikatów). Ja bym proponował wstawić opuszczanie pantografu do Bałtyku, a jak się uda, to dam jazdę bezprądową pod żabą w Quarku.
  Dodano: 30 Grudnia 2014, 03:15:11 Jednak to nie może tak być, bo jeden izolator to cztery eventy w torach. Prościej będzie dodać to we właściwościach sieci i dorobić skanowanie przęseł pod kątem izolatora. A jedynie w specyficznych przypadkach dawać Overhead w tory, kiedy się nie da zrobić tego prościej.