Jedna osoba poprawi wyświetlanie belki, zacommituje do gita (wybaczcie za slang), druga zrobi nowe menu, zacommituje. W taki sposób powstaje prawdziwe, darmowe oprogramowanie.
Ja bym jednak wolał, żeby nikt nie dodawał kolejnej lampki czy kolejnego przełącznika przy obecnych metodach obsługi tego typu rzeczy. W 2009 roku zostało przerobione wyświetlanie obiektów, ale że autor tej przeróbki nie był zorientowany, które źródła są najlepiej zintegrowane, zrobił w ten sposób oddzielną linię rozwojową. Potem 1.5 roku zajęło mi integrowanie tych dwóch linii rozwojowych (z trzecią poszło w miarę szybko). Nadal jeszcze nie wszystko zostało naprawione i spotykam się z uwagami, że można by coś tam przywrócić, bo w 2007 roku to działało (w innej linii rozwojowej). W praktyce nie ma jednej osoby na tyle zorientowanej, żeby mogła zatwierdzać modyfikacje źródeł i odrzucać próby ewidentnego psucia kodu. W efekcie każdy modyfikujący EXE ciągnie w stronę własnej linii rozwojowej.
Brakuje chodzenia po peronie. Wsiadanie, wysiadanie. Zamiast tego jest latanie. Myślę, że zrobienie, żeby to przypominało chodzenie jest trywialne!
Nie jest trywialne — nie ma obecnie możliwości wyznaczenia wysokości (Y) oparcia dla współrzędnych płaskich (XZ). Nawet gdyby to zrobić, to priorytetem raczej jest dynamiczna obsługa komórek (kawałków) scenerii. I ewentualny mechanizm "chodzenia po scenerii" trzeba by do tego dostosować, a nie opierać na obecnych rozwiązaniach.
Wypadków z samochodami nie zrobisz, bo oddzielne trajektorie nie oddziałują na siebie.
Dało by się zrobić, ale takich rzeczy do zrobienia jest dużo, czy ta jest priorytetem? No i wcześniej trzeba by poprawić hamulce samochodom, bo taki jelczostar — znając z góry punkt zatrzymania — hamuje kilka metrów za nim.
Miało być to jakoś upraszczane w przyszłości, by w każdym kroku fizyki nie liczyć równać całkowych na ugięcie buforów.
Z buforami jest tak, że są liczone z "równań różniczkowych", do których wstawia się upływ czasu od poprzedniego przeliczenia. W efekcie przy większej prędkości i niskim FPS pojazdy "wbijają się w siebie" bardziej niż by faktycznie pozwoliła im materia, przez co powstają ogromne siły odbijające. Przykładowo, 100km/h to jest 27.8m/s, co przy kroku fizyki 0.01s daje przeskok o ~30cm w każdym kroku. Czyli jak w jednym kroku zderzaki się jeszcze nie zetknęły, to w następnym będą miały już ugięcie rzędu ~15cm każdy. W rzeczywistości przy tej prędkości wystąpiły by już inne zjawiska, bo tak duże ugięcie sprężyn nie jest możliwe.
Ten filmik podważył tylko realistyczność Maszyny, brak wyłącznika CSK, niezgodne z rzeczywistością włączanie wyłącznika szybkiego, ET22 ma dwie pozycje nawrotnika do przodu w Maszynie jest jedna.
Jak już wspominałem, symulacja ET22 nie jest najlepszą. Podobnie można się czepiać uzależnień EN57, albo udawania, że EP05 też się zachowuje jak siódemka. Realistyczność to nie tylko liczba przełączników potrzebnych do uruchomienia. To również charakterystyki trakcyjne, czasy działania hamulca, spadki napięcia w sieci trakcyjnej, opory ruchu składów. Również np. poślizgi — a tym czasem większość torów na sceneriach ma wpisany współczynnik tarcia 0.25, podczas gdy standardowo powinno być 0.15. Czemu nikt się tym nie przejmuje?
