Kategorie prędkości

[firleju]

Witam,

Podczas prac nad tabelką prędkości w exe, które wynikły z błędu ruszania z W4 gdy zostaną wykryte dwa semafory (wątek http://eu07.pl/forum/index.php/topic,26938.0.html) doszedłem do wniosku, że jest potrzebne rozróżnianie na rodzaje prędkości, które są wrzucane AI.
W tej chwili exe rozróżnia 3 rodzaje:
SetVelocity - ogólna prędkość kasowana pierwszą zmianą, jest używana we wszelakich semaforach
ShuntVelocity - prędkość do jazd manewrowych
SetProximityVelocity - pierwotnie służyła AI do hamowania przed zwolnieniami, obecnie nie brana pod uwagę (używana jest w W9 oraz tarczach ostrzegawczych)

Problem leży w SetVelocity, która jest zbyt ogólna i na jej podstawie nie można stwierdzić kto wrzuca tak naprawdę tą prędkość. W związku z tym nie ma możliwości wykrycia że widzimy dwa semafory, a nie semafor i ograniczenie w torach. Dodatkowo każde ograniczenie prędkości zmienia prędkość nadaną przez semafor, więc jeśli na semaforze było 40, a potem jest komórka z prędkością 60 to AI uzna że ograniczenie to 60.

Co chciałbym zrobić: dodać nowe kategorie dla semaforów, ograniczeń prędkości oraz prędkości drogowej. Dzięki temu można zbudować tabelkę z której wybiera sobie najmniejszą dostępną i nie będą się nawzajem nadpisywać. Problem mam z nazwaniem.
Jeśli chodzi o prędkośc z semafora to prawdopodobnie z nowym exe pójdzie paczka zmieniająca nazwę typu prędkości co rozwiąże wiele problemów. Czy to samo zrobić dla reszty typów ograniczeń?
W tej chwili W9 tworzy dwie komórki i nadają one prędkość proximity co w ogóle ze sobą nie gra. Mogę stworzyć specjalne wersje wskaźników lub zmodyfikować istniejące. Szczególnie to pytanie dotyczy tarcz ostrzegawczych (ktokolwiek przypisuje te eventy do torów?).
Drugą kwestią jest, że jest to potencjalne złamanie wstecznej kompatybilności czego naprawdę chciałbym uniknąć

[surgeon]

Witam,

Podczas prac nad tabelką prędkości w exe, które wynikły z błędu ruszania z W4 gdy zostaną wykryte dwa semafory (wątek http://eu07.pl/forum/index.php/topic,26938.0.html) doszedłem do wniosku, że jest potrzebne rozróżnianie na rodzaje prędkości, które są wrzucane AI.

Jesteś pewien, że winna jest tabelka a nie np. błędy w scenerii? Jeśli pociąg stoi pod W4 i semaforem wyjazdowym to AI nim sterująca raczej nie powinna widzieć semafora wjazdowego 1400 m dalej.

Problem leży w SetVelocity, która jest zbyt ogólna i na jej podstawie nie można stwierdzić kto wrzuca tak naprawdę tą prędkość. W związku z tym nie ma możliwości wykrycia że widzimy dwa semafory, a nie semafor i ograniczenie w torach. Dodatkowo każde ograniczenie prędkości zmienia prędkość nadaną przez semafor, więc jeśli na semaforze było 40, a potem jest komórka z prędkością 60 to AI uzna że ograniczenie to 60.

Jeszcze całkiem niedawno nie było żadnego problemu z semaforami z małą odległością od siebie i różnymi prędkościami. Tabelka działała jak należy i bez problemu dobierała odpowiednie prędkości do sygnałów z semaforów. Może ktoś ostatnio coś niepotrzebnie popsuł?

[matek123]

A to nie jest wina, że w złej kolejności są eventy? Np. najpierw jest Sem info, a później Stop info.

[firleju]

Podczas pierwszego skanowania tabelka jest wypełniania do 2500 m. Potem podczas jazdy jest skanowana na odległość pi*drzwi hamowania. Druga rzecz że jest jakiś błąd skanowania i nie zawsze widział semafor za W4 (nie wiem czemu, obszedłem ten błąd przez skanowanie także poza ograniczenie, gdyż wcześniej jeśli trafiał na zatrzymanie to nie skanował torów dalej).
Ten błąd nadpisywania prędkości istniał zawsze, tylko ograniczenia prędkości robiło się poprzez wpis w tor a nie za pomocą eventu (co byłoby logiczne). W tej chwili masz tak, że na semaforze masz np. 40, potem masz zwrotnicę z jazdą na bok i w tor wpisane 50, ale zakładasz na niej ograniczenie do 20, to jeśli to ograniczenie zrobiłbyś za pomocą eventów to W9 na końcu ograniczenia usunęło by ograniczenie z semafora.
Testowałem taką sytuację także i kolejność owszem ma znaczenie, ale w testowej sytuacji miałem odjazd z W4 po podaniu semafora i widział dwa kolejne semafory. W związku z tym, że na drugim było S1 to nie chciał odjechać pomimo podania pierwszego.

[surgeon]

Druga rzecz że jest jakiś błąd skanowania i nie zawsze widział semafor za W4 (nie wiem czemu, obszedłem ten błąd przez skanowanie także poza ograniczenie, gdyż wcześniej jeśli trafiał na zatrzymanie to nie skanował torów dalej).

Nie potwierdzam. W ostatnich czasach nie nie zdarzyło mi się (a testowałem to dosyć intensywnie :), żeby AI miało problem z widocznością semafora za W4. Wyjątek stanowiły źle przypisane do torów semafor i/lub W4.

Ten błąd nadpisywania prędkości istniał zawsze, tylko ograniczenia prędkości robiło się poprzez wpis w tor a nie za pomocą eventu (co byłoby logiczne). W tej chwili masz tak, że na semaforze masz np. 40, potem masz zwrotnicę z jazdą na bok i w tor wpisane 50, ale zakładasz na niej ograniczenie do 20, to jeśli to ograniczenie zrobiłbyś za pomocą eventów to W9 na końcu ograniczenia usunęło by ograniczenie z semafora.

Ponieważ AI dobrze sobie radzi z odczytem prędkości z torów i semaforów, nie ma sensu stosować ograniczeń prędkości za pomocą dodatkowych eventów. Zamiast jak to napisałeś zakładania ograniczenia 20 na tor z wpisaną prędkością 50, wystarczy wpisać w tor 20, zamiast 50 i problem z głowy.

[firleju]

To, że nie trafiłeś na ten błąd nie znaczy, że go nie ma. Ja trafiłem, testowałem w różnych wersjach, łącznie z przypisywaniem semafora do różnych odcinków, które exe na pewno skanuje i nic. Dopiero jak mu usunąłem blokadę skanowania to zaczął zachowywać się poprawnie czyli widział skanowany event.
Chcę dać możliwość wpisywania ograniczeń w postaci eventów żeby nie było trzeba robić n-tej wersji torów tylko ze względu na ograniczenia. Tu chodzi o koncepcję nie o to czy obecne rozwiązanie działa, bo wiem że działa.

[youBy]

Od biedy prędkość do torów można przypisać eventem. Gdyby rozszerzyć funkcjonalność takiego zdarzenia (podanie długości ograniczenia, jego kierunku względem zadanego toru i flag nadpisywania), to można by było zdarzeniem onstart przypisać wszystkie zmienione ograniczenia, a nawet losować niektóre czasowe.

[firleju]

Teoretycznie istnieje taki event jak SetProximityVelocity, który do niczego nie służy. Można pomyśleć o takim evencie czasowym wkomponowanym w W9p.inc, który od miejsca umieszczenia komórki dawałby ograniczenie na jakiejś odległości. Ale wtedy trzeba bardzo dokładnie wstawiać W9k. Do tego taka wersja ma ograniczenie w postaci tego, że nie możesz wstawiać ograniczenia o różnej długość w zależności od kierunku w jakim pojedziesz (odcinek obejmujący rozjazd). Event w wersji W9p z ograniczeniem prędkości drogowej i W9k z prędkością -1 jest chyba bardziej elastyczny. Oczywiście można tak zrobić te ince żeby tor był przypisywany niejawnie (za pomocą HiddenEvents).