Udało mi się rozpędzić autobus do 177km/h używając hamulca ;) Trasa:
http://eu07.pl/forum/index.php/topic,29021.0.html. Niestety nie udało mi się tego powtórzyć. Efekt osiągnąłem zaczynając prowadząc EP07, potem zaobserwowałem jak autosan przejeżdża przez zamknięty przejazd, potem się do niego przesiadłem, próbowałem go rozpędzić i zahamować. Hamulec zadziałał tylko na chwilę, potem przestał hamować. Po zwolnieniu hamulca autosan zaczął mocno przyśpieszać pomimo zjechania gazem do zera. Przyśpieszył do 177, dalej nie mógł, bo zwalniał na zakrętach szybciej niż był w stanie przyśpieszyć.
Udało mi się też (bawiąc się przyśpieszaniem i hamowaniem) uzyskać ruch autosana do tyłu pomimo biegu ustawionego do przodu. I znów zamienił się w bolid, popyla właśnie 100km/h do tyłu. Ciężko to powtórzyć, ale się da.
W ED72 coś takiego:
Failed to locate sub-model "przetwwyl" in 3d model "dynamic\pkp\ed72_v1\kabina_a.e3d"
Failed to locate sub-model "pantopuszcz" in 3d model "dynamic\pkp\ed72_v1\kabina_a.e3d"
Tak na marginesie, nie mogę włączyć przetwornicy. Plik e3d - model, grafika. Błąd w pliku danych dla grafiki powoduje błędne działanie logiki. Czy to jest aby na pewno prawidłowa konstrukcja? Rozumiem docelowo kliknięcie na hebelku powinno włączyć przetwornicę. Zacna idea, tak powinno być. Ale czy nie powinno też być tak, że naciśnięcie "X" powinno wysyłać komendy włączenia przetwornicy dokładnie tak samo jak kliknięcie na hebelku, tak samo jak wysłanie sygnału przez USB, tak samo jak polecenie skryptu sterującego AI? I teraz odwrotnie, jeśli takie polecenie zostało odebrane - hebelek powinien zostać przestawiony, powinien się odtworzyć odpowiedni "klik" albo "klak", w zależności od danych modelu hebelek może sobie zostać w przestawionej pozycji lub wrócić. Nie wiem jak to jest teraz zrobione, ale wiem, że tak jak piszę byłoby po prostu logicznie. Teraz jeśli dany pojazd wyróżnia się brakiem danego przełącznika - to mogłoby być zapisane w jakiejś konfiguracji. Dla tego pojazdu AI też nie powinna mieć opcji uruchomienia tej funkcji, bo pojazd nie ma tej funkcji i tyle. Natomiast jeśli artysta nie stworzył animacji hebelka, względnie nie zdążył lub zapomniał określić do czego jest jego hebelek - powinno działać, aczkolwiek nie dać się kliknąć / nie powodować efektu graficznego.
Teraz dlaczego "jakaś konfiguracja". To umożliwiłoby żeby usiadła do tego jedna osoba, i w ciągu jednego dnia poustawiała to dla wszystkich występujących w symulatorze lokomotyw. Szybko. "Na jutro". Użytkownicy mogliby testować nowe exe, przejeżdżać różne trasy różnym taborem i dostarczać użytecznych informacji dotyczących działania exe.
Żeby było wiadomo, że dany model ma braki - wystarczy zapis w errors.txt, a jeszcze lepiej - to mogłoby się automatycznie wysyłać na serwer. Góra parę dni i czy ktoś to zgłosi czy nie zgłosi, mamy listę wszystkich braków. Żeby nie spamować każdy wysłany na serwer błąd miałby hash utworzony z lokalizacji (np błąd modelu), wersji exe i IP usera. W ten sposób każdy błąd zapisuje się tylko raz dla wersji.
Teraz sytuacja jest niejasna. Coraz ciężej testować exe, bo różne rzeczy nie działają. Dobra, ktoś znajduje błąd w czymś niezwiązanym z exe, co wyszło po wprowadzeniu zmiany. I co dalej? Powiedzmy błąd w modelu to informacja użyteczna dla modelarzy, ale to tu ma być wklejona i tu będą jej szukać? No i problem, bo jeśli nie da się za bardzo ruszyć danym pojazdem, albo wykonać jakiegoś manewru, to może być więcej błędów związanych z pojazdem, ale nie zostaną wykryte bo testowanie zakończy się przedwcześnie. Uważam, że testowanie rzeczy niekompletnych jest bardzo użyteczne. Potrzebujemy informacji, że coś jest niekompletne, z drugiej strony pójdzie szybciej, jeśli to niekompletne coś da się dalej testować i zebrać więcej danych.
Jaki priorytet ma dodanie funkcji obsługi urządzeń w kabinie myszą? Czy możemy się spodziewać tego w najbliższym czasie, czy są pilniejsze rzeczy? Tak sobie myślę, że poprawienie dużych bugów chyba mogłoby być pilniejsze. Np zachowanie aut. Np trzęsienie obrazu i elementów. Np wysypy. Np połączenie różnych opcji renderowania w jedną wspólną. To pozwoliłoby wypuszczenie czegoś działającego dużo wcześniej, przed kolejną "dużą wersją" mającą tony nowych funkcjonalności.
Czy nie miałoby sensu zamknięcie tego wątku i założenie nowego, bo czy przypadkiem konwersja exe na C++ już się nie zakończyła? Zgłaszane błędy dotyczą albo nowych funkcji (np nowej obsługi klawiatury) albo rzeczy działających nieprawidłowo przed konwersją (trzęsienie elementów obrazu).
Myślę, że obecna wersja exe jest o włos od stabilnej nadającej się do oficjalnego wydania. Prawie wszystko działa dobrze, poza nieszczęsnymi klawiszami i autami na przejazdach. Wysypy były tak samo na borlandowej, obraz może cały nie latał na boki, ale podsypki się trzęsły i tak. VBO na wersji borlandowej nie działało dobrze (a w zasadzie nie dało się tego używać).
