Exe - konwersja na C++

[AtapiCl]

Po prostu jest cała lista rzeczy, które oczekują na zrobienie lub ustosunkowanie się do nich (http://eu07.pl/forum/index.php?project=1;area=issues;start=0). Dodałeś tam też ten dźwięk no i dobrze, niech czeka na swoją kolej. Nie zginie.

[tmj]

I co było przyczyną braku dźwięku falowników?

Blad w kodzie :)

(nie byl wczytywany parametr od ktorego obecnosci zalezala kalkulacja "predkosci wentylatorow" w asynchronach)

Co do blokady drzwi, z tego co widze to przynajmniej czesciowo to juz jest w kodzie: plik .fiz w sekcji Doors: potrzebuje wpisu "DoorBlocked=Yes", a w kabinie musi byc obecny przycisk "door_signalling_sw:" Stan przelacznika kontrolowany jest klawiszem S (czyli w EZT w takiej sytuacji nie dziala piasecznica, ale to juz inna para kaloszy) Tak czy inaczej, obecny kibel z paczki nie spelnia zadnego z tych dwoch warunkow. Jesli ktoremus z modelarzy zechce sie to zrobic, to mozna bawic sie dalej w podpiecie dzwieku pod ten event (o ile juz nie jest to zrobione, ale chyba jeszcze nie)

[Stele]

Żadne z posiadanych u nas EZT nie mają piasecznicy sterowanej ręcznie z dostępnych mi danych. W każdym razie tak już było gdy ulepszałem sygnalizację blokady i nikt nie krzyczał by zmienić.
Dźwięku pod załapanie blokady nie ma. Jakby co, to do zewnętrznych z nim.

[AtapiCl]

EN57AL mają ;) Ale tam się problem rozwiązuje, gdyż ze względu na zastosowane drzwi odskokowo - przesuwne, dźwięku blokady drzwi o której teraz mowa po prostu nie słychać.

[Stele]

Na naszej fiz nie da im się wyłączyć automatycznej. :P

[AtapiCl]

Widzisz, a one automatycznej właśnie nie mają. Zdejmują moc z silników jedynie przy poślizgu, ale piachu nie sypią.

[Stele]

A co do autek, to będzie szosa testowa na TD. Też mi to potrzebne. Męczę ludzi a jak mnie zleją to w końcu sam ułożę.

[Krzysiek626]

SN61 świeci. Objechałem Całkowo w obie strony. Drawinowo i Kaliską, także Bałtyk i Kawałek Zwierzyńca. Nie sypie się, a to najważniejsze.
Testów na intelu nie będzie z mojej strony. Okazało się że musiałbym wyjąć grafikę GF z płyty głównej, to aż tak bardzo to mi się nie chciało.
Czysto teoretyczne pytanie, czy w ini dałoby się zmienić kolor czcionki (po dopisaniu czegoś w kodzie)?

[Wiggle]

Nie wiem czy u innych też, ale u mnie znacznie wydłużył się czas ładowania scenerii na wersji 64-bitowej. l61 ładowała się 80-90 sekund, a teraz jest to 485... Co może być tego przyczyną? Sprawdzić czy na 32 będzie tak samo?

[Krzysiek626]

Napisz który scenariusz, sprawdzę za trochę jak odpalę inny dysk.

[tmj]

Hmm linia61_osobowy1 wchodzi u mnie na x86 w 48 sek. "na sucho", 33 sek. przy powtornym ladowaniu.
x64 uruchomione po nim, czyli powtorne ladowanie, 29 sekund.
Czyli raczej nie wykazuje tego typu bledu. Tak duzo spowolnienie, moze system byl zapchany i zaczal sobie przerzucac miedzy pamiecia fizyczna i wirtualna? Zobacz jak bedzie przy uruchomieniu po swiezym starcie systemu, bez zadnych innych aplikacji?

[joey]

Proba zapalenia swiatel lokomotywy na widoku zewnetrznym lub proba wyjscia z pojazdu przy zapalonych swiatlach powoduje u mnie wysyp za kazdym razem. Linux Mint 17.1, Wine 2.3, 2 GB RAM DDR2, Radeon HD5450 512 MB RAM na sterownikach AMD. Jeden crashdump w zalaczniku.

[Krzysiek626]

Na windzie tego nie mam, wielokrotne opuszczenie i powracanie, a także przejmowanie pojazdów pod F5.

[tmj]

Jeden crashdump w zalaczniku.

To gdzies w kernel32 jest, bez zadnych danych co tam mogloby byc nie tak :<  Czy na poprzednich wersjach (0315 albo wczesniej) bylo poprawnie? Podrzuc tez jesli mozesz log.txt

[firleju]

Ja już głupieję. MSAA na 0. Odpalam rózne exe. I teraz głupieję. Na exe, które mam oznaczone jako range_factor mam 40 FPS (i okno samo nadaje MSAA). Na camera_fustrum mam 30 FPS i MSAA. Na 16.03 brak MSAA i nadal 30 FPS.
Muszę przestać testować na baterii, ale ciągle robię to w pociągu :(

[Krzysiek626]

Nie wiem czy u innych też, ale u mnie znacznie wydłużył się czas ładowania scenerii na wersji 64-bitowej. l61 ładowała się 80-90 sekund, a teraz jest to 485... Co może być tego przyczyną? Sprawdzić czy na 32 będzie tak samo?

170316, po odpaleniu windowsa (64 bit) i zaraz potem rainsted z trasą L061_osobowy1, czas wczytywania wyniósł 69 sek. Log w załączniku 1.
Ed:
Drugie czytanie było wydłużone i trwało 131 sek. Log w załączniku 2.
Trzecie podejście trwało zaledwie 54 sek. Log w załączniku 3.
Czwarty raz tylko 41 sek.

[tmj]

Ja już głupieję. MSAA na 0. Odpalam rózne exe. I teraz głupieję. Na exe, które mam oznaczone jako range_factor mam 40 FPS (i okno samo nadaje MSAA). Na camera_fustrum mam 30 FPS i MSAA. Na 16.03 brak MSAA i nadal 30 FPS.
Muszę przestać testować na baterii, ale ciągle robię to w pociągu :(

No ja tez juz nie wiem, ze zmian tam sie chyba ostala tylko kalkulacja fizyki bez ograniczenia do 20 krokow, ale to by sie pojawilo dopiero gdzies tak przy 5 fps. Pchnalem najswiezsza wersje na githuba, skompiluj to u siebie (tylko zdefiniuj EU07_USE_OLD_RENDERCODE) i przepusc przez Analyze -> Performance & Diagnostics w VS. Daj exe popracowac tak z 10 minut, moze wylapie w raporcie co tam u ciebie tak fps zre ;/

[AtapiCl]

A ja z ciekawości postanowiłem Kaliską odpalić na 170316 x86 (bo nie chcę się póki co bawić w zamianę na x64). I gdzieś tam przy wczytywaniu taboru wywala do windowsa, z tym że wyskakuje to:

Po kilku uruchomieniach widzę, że podczas wczytywania taboru w różnych momentach się to dzieje, no i niestety brak crashdump... Czyżbym za mało bibliotek miał już zainstalowanych? :D

[tmj]

Ten komunikat to chyba dlatego, ze exe ustawia sobie funkcje by wygenerowac crashdump, ale czegos tam w systemie brakuje zeby go wyprodukowac. Natomiast samo wywalenie odbywa sie z innych przyczyn, chociaz nie wiadomo jakich. Ale jesli swoja droga brakuje my bibliotek dla crashdump to tam sie potencjalnie cos dziwnego w systemie dzieje, bo standardowo chyba powinny byc.

Czy mozesz sprawdzic, jak zachowuja sie inne exe? 0315 albo troche wczesniejsze?

[AtapiCl]

Inne scenerie chodzą, nawet Drawinowa i takie tam. Zaraz rzucę okiem. Crashdumpy też się generowały. Jedyną systemową zmianą była chyba wymuszona przez R* instalacja MSVC R 2015 x86 14.0.24215, która miała miejsce wczoraj :P

[Krzysiek626]

Atapi, odpalałeś nową ST44?.  Tam były pliki t3d, które u mnie wygenerowały się jako e3d i kaliska nie chciała odpalić. Musiałem przywrócić stary model z paczki i pomogło.

[tmj]

Czekaj czekaj, to sie nie powinno zdarzyc. Czym byly te t3d konwertowane? Jak starym exe to nowe powinno je lyknac, a nowe ma konwersje zablokowana (chyba ze wymusic w .ini) ale wtedy tez powinno odczytac "swoje wlasne" e3d. Co sie dokladnie stalo?

[dymus]

e3d kabin do ST44 były konwertowane na exe 474.

[Wiggle]

U mnie nadal to samo, bardzo długo ładują się tekstury, a na początku jeszcze przez około 20 sekund pisze o odczytywaniu scenerii z $.scn

[Krzysiek626]

Być może kompatybyliść została zepsuta już w obie strony. Nie żartuje, po przywróceniu starego st44 poszło ok.
No właśnie dawno już wyłączyłem zapis do $. scn. Między innymi że blokuje otworzenie dwóch scenerii naraz, ponieważ rainsted nie jest w stanie zapisać drugiego pliku $.scn.

[Wiggle]

Po wyłączeniu zapisu pomaga jedynie tyle, że ten bardziej zielony pasek postępu się przesuwa, a tak stał na początku i dopiero pod koniec wariował z lotem na koniec, ale ładowanie scenerii nadal w okolicach 300-400

[joey]

To gdzies w kernel32 jest, bez zadnych danych co tam mogloby byc nie tak :<  Czy na poprzednich wersjach (0315 albo wczesniej) bylo poprawnie? Podrzuc tez jesli mozesz log.txt

W 170315 i 170314b dziala to w porzadku. Zalaczam log.txt i errors.txt z tamtego crasha (baltyk.scn, misja SU45) oraz to, co wyswietlil mi wine'owy komunikat o bledzie.

[tmj]

Zalaczam log.txt i errors.txt z tamtego crasha (baltyk.scn, misja SU45) oraz to, co wyswietlil mi wine'owy komunikat o bledzie.

Dzieki, backtrace wyjasnilo sprawe. Zastapilem funkcje, ktora do tej pory byla uzywana przy kalkulacji sily swiatel inna, troche dokladniejsza, ktora takze jest w standardzie c++ ale wyglada na to, ze odmiana ktora masz u siebie nie ma jej zaimplementowanej. Wroce do starej funkcji, powinno przywrocic dzialanie.

Być może kompatybyliść została zepsuta już w obie strony. Nie żartuje, po przywróceniu starego st44 poszło ok.

Hmm no nie wiem, mam zainstalowana dzisiejsza(?) paczke z nowa kabina co poszla do testu, i tam sa z jednym wyjatkiem same pliki .e3d i na nowym exe weszly bez zadnych bledow. Dziwne to jakies, jesli ci nie dzialaly o.O

[AtapiCl]

Zamiana wszystkich składów oprócz mojego na EU07 spowodowała odpalenie scn, ale tutaj już problemy natury konwersji E3D się zaczęły dziać (typu jadące same wnętrza lokomotywy, bez modelu zewnętrznego itd). Przeinstalowałem też MSVR - bez skutku. Exe z początku lutego ma to samo.

[tmj]

To faktycznie brzmi jakby sie bajzel narobil przy konwersji, chociaz nie wiadomo w ktora strone. U siebie mam w .ini convertmodels ustawiony na 0, bo to co produkuje nowe exe moze sie nie podobac staremu, a w najnowszych uaktualnieniach trzeba konwersje wymusic, ale moze stare cos napsulo. Moze warto by bylo postawic paczke od poczatku, tzn calosciowa, patch i zablokowac konwersje w .ini, zeby sobie poszczegolne wersje nie psuly plikow :/