Exe - konwersja na C++

[El Mecánico]

Dobrze by było, aby każda krytyczna zmienna miała domyślną wartość początkową ustawioną na jakąś bezpieczną wartość...

[tmj]

Coś zepsułeś w hamulcach, gdyż po narzuceniu twoich zmian z pull-a znowu nie ma ciśnienia w cylindrach hamulcowych po starcie TD a powinno być. Mnie już naprawdę nie chce się tego szukać n-ty raz. Hamulce działają na wersji c3 i tak powinno zostać.

Masz na mysli to, co jest wlaczone do twojej wersji, czy to co dodalem u siebie ostatnio? Jesli to pierwsze to nie wiem czy to moja wina, bo akurat hamulcow w tej wersji patcha nie dotykalem :) (dodalem mu tam #pragma once i tyle) Natomiast w niektorych hamulcach bylo wtedy jeszcze pare niezainicjalizowanych zmiennych, wiec byc moze to jest przyczyna tego zachowania. To jest poprawione w uaktualnieniu ktore wrzucilem pozniej, tutaj na 99% inicjalizuje wszystkie zmienne tak, jak by to robil Borland, wiec powinno pomoc, a nie zaszkodzic (chociaz moze tez pomoc w uaktywnieniu bledow ktore sa gdzie indziej, a do tej pory byly maskowane przez brak inicjalizacji)

[firleju]

My fault. Nie zauważyłem, że nadałem prędkość i dawał wartości jak dla odjazdu a nie zatrzymania. Tak właśnie jest jak się robi parę rzeczy na raz.

[firleju]

Wersja release. Może zawierać poprzednie błędy. Na repo wszystkie rzeczy potrzebne do budowania na VS2013 lub VS2015. Może nie działać na WinXP, ale powinno. W załączniku także potrzebny dll do Glew wersji 2.0.
Tmj, niestety nowy pull nie pójdzie łatwo. Są konflikty.

[tmj]

Ah ok, bo juz sie przestraszylem. Przy okazji pchnalem dotychczasowe poprawki, ale troche sie spoznilem, bedziesz musial porownac czy tam cos sie nie wcina :) (teoretycznie nie powinno, ale teoria sobie itp)

[firleju]

Tak czy siak jak zaciągniesz zmiany to będzie trzeba poprawić, a w tym co zrobiłeś to chyba się lepiej orientujesz. Z pierwszego rzutu oka to nie wiem po co usuwasz inicjację zmiennych w hamulcach.

[tmj]

Tak czy siak jak zaciągniesz zmiany to będzie trzeba poprawić, a w tym co zrobiłeś to chyba się lepiej orientujesz. Z pierwszego rzutu oka to nie wiem po co usuwasz inicjację zmiennych w hamulcach.

Inicjacja jest teraz wpisana bezposrednio w definicji zmiennych w naglowku, wiec to, co bylo w konstruktorze to tylko (wolniejszy) duplikat. Trudniej w ten sposob przeoczyc brak inicjalizacji.

Przegladam konflikty -- w driver.cpp mozesz dac moja wersje, to jest tylko minimalna kosmetyka przy komunikacie. Reszte podam jak sprawdze.
dynobj.cpp -- tak samo, mozesz dac moj kod. podejrzewam ze diff w wiekszosci glupieje bo w komentarzach sa pozostalosci po polskich znakach i on nie bardzo wie jak to lyknac.

[firleju]

No tak. Przeglądając nie zauważyłem. W klasach hamulców wystarczy unique_ptr. Tam nie ma żadnego dzielenia się wskaźnikami. Szczególnie w przypadku czegokolwiek na TReservoir.
Nie ma sensu poprawiania komentarzy. Używam clang_format i to leci automatem. Tak samo odległości pomiędzy znakami itd.

Właśnie nie wiem co z tymi byłymi polskimi znakami. Na jakimś etapie w niektórych plikach źle zostały skonwertowane.

[tmj]

No ja nie wiedzialem czy tam we flakach nie ma jakiegos przekazywania parametrow, wiec dla pewnosci dalem shared. Jak sie to wszystko wyprostuje to mozna poprawic, na razie nie szkodzi specjalnie, ze jest.

Komentarzy w wiekszosci nie tykalem, posklejalem tylko niektore linie
ktore
wygladaly
tak,
zeby to prosciej bylo ogarnac ;) polskie znaki moze w ogole wyrzucic z komentarzy? prawdopodobnie glupieje, bo u mnie jest angielski win 10, a pliki nie sa chyba zapisane w Unicode wiec to sie zmienia w te i we w te.

[tmj]

train.cpp jest bardziej skomplikowany, tak pol na pol twoich poprawek, i moich. najlepiej odwolam update, polacze to na spokojnie lokalnie u siebie, i pchne jeszcze raz.

[firleju]

To zanim zaczniesz się bawić przeglądnę wszystkie pliki i spróbuję naprawić kodowanie. a potem konwersja na UTF-8.

[tmj]

No juz za pozno, zaczalem sie bawic zanim przeczytalem :)  nowy pull request wyslany, powinno sie polaczyc. Lokalnie kompiluje sie i dziala, chociaz czy cos sie nie zchrzanilo wyjdzie dopiero w praniu.

[ryba825]

Używacie jakichś linterów? Formatowanie kodu (wcięcia) wygląda jakby decydowała o tym funkcja "random". ;)

[ryba825]

Mam na myśli takie coś. https://google.github.io/styleguide/cppguide.html#Spaces_vs._Tabs Czyli używanie 2 spacji zamiast tabulatora. Bardzo skraca zagnieżdżenia.

[tmj]

formatowanie wyglada jak wyglada, bo kazdy robi tak, jak jest przyzwyczajony, a standardow jest tyle ile programistow + 1 ;)

2 spacje sa wg mnie raczej nieczytelne; przy wiekszym monitorze w niektorych ukladach zaczynasz sie zastanawiac czy to wciecie czy tylko cie oczy myla. A i zagniezdzen nie ma co za bardzo splaszczac -- jak ci zaczyna linia wychodzic za ekran z powodu zagniezdzen, to jest to niezly sygnalizator ze z kodem jest pewnie cos nie tak na bardziej ogolnym poziomie.

[ryba825]

Używam 2 spacji w Rubym i Javascripicie i nie mam problemu z czytelnością. ;)

[tmj]

Ja tez bylem kiedys mlody i mialem dobre oczy. ;d

[ryba825]

To już od Was zależy. Ja tylko proponuję. ;)

[firleju]

Ryba, każdy plik przeszedł tutaj wstępnie przez formater kodu. To potem są jaja bo nie po każdej zmianie się tego używa, a VS studiu domyślnie używa tabów zamiast spacji (co można zmienić w opcjach oczywiście). Ale wystarczy znowu przejechać formaterem i wszystkie tabulatory lecą na spacje z automatu. VS też ma dodatek do zainstalowania jak coś.
No widziałem, że zrobiłeś zmiany, a ja już w tym czasie zdążyłem zrobić 3 kolejne commity z ponad 60 plikami na zmienionym formacie. Teraz lecę te najgorsze, które trzeba nadgrywać z ostatniej dobrej wersji. Zobaczymy, czy będzie się chciało połączyć.

[tmj]

A tak z innej beczki, no koozwa, ja nie moge -- czy czytanie negatywnych indeksow z tablicy, jak na zalaczonym screenie to jest by design, czy sie tylko przemknelo do tej pory niezauwazone, bo sobie kod po prostu lapal cos tam z poprzedniej zmiennej, a AttachPrev() lyka wszytko bez weryfikacji? o.O

[firleju]

Jak to jest w Ground to od początku jest w cpp. Więc by design, lub by błąd. ;) Nie wie nikt, ale uważaj jak zmieniasz, bo łatwo zepsuć, bardzo trudno naprawić. Możesz też chwilę poczekać ze zmianami aż ogarniemy kodowanie?

[tmj]

No wlasnie boje sie ruszyc bo tam straszna sieczka jest, dlatego pytam :)  na razie nie bede grzebal wiecej, poczekam az skonczysz formatowanie itp, to tylko wyskoczylo przy okazji, jak probowalem ogarnac, czemu nie renderowal zadnych pojazdow na drogach. Wyszlo na to, ze w kodzie sporo jeszcze opiera sie na odczycie troche 'na slepo', a tryb debug specjalnie inicjalizuje pamiec smieciami, zeby to latwiej wylapac, wiec faktycznie zaczyna to wychodzic. No, ale samochody znowu jezdza, i nawet maja wszystkie cztery kolka ;)

[firleju]

Jeśli dobrze pójdzie to dzisiaj skończę z formatowaniem.
Proponuję ustalić podział prac na najbliższy czas, żeby nie robić sobie konfliktów.
No i może najważniejsze w jaką stronę idziemy z modernizacją kodu.
Z mojej strony to najpierw rozwiązać błędy zgłoszone podczas pierwszych testów a potem rozdzielenie movera na klasy poszczególnych pojazdów a nie jeden worek do wszystkiego.

[tmj]

Ja sie tam specjalnie wtracac nie bede ;) a propos rozwiazywania bledow, SU45 (i zapewne pokrewne, jesli sa) nie jezdzi, bo ma chyba podlaczony zly kod -- z tego co zauwazylem to probuje uzywac tablicy DList, ktora jest w jej przypadku pusta/wypelniona smieciami, natomiast odczytu zawartosci WWList z pliku .fiz nie ma jeszcze w kodzie. Ladowanie tablicy akurat moge dopisac, nie powinno sie z niczym pogryzc, ale podlaczanie kodu do jazdy, to juz musi sie tym zajac ktos ciezko doswiadczony.

[firleju]

W takim razie nie jeżdżą spalinowe w ogóle. Do kodu podłączać nie trzeba. "Tylko" wczytać wszystkie parametry z pliku fiz. Do tego trzeba już porównywać kod pascalowy. Jeśli chcesz to ok, jeśli nie to zrobię to jak tylko skończę poprawiać polskie litery.

[tmj]

Do kodu podłączać nie trzeba. "Tylko" wczytać wszystkie parametry z pliku fiz.

OK, zeby sie upewnic -- to, co jest zapisane w pliku .fiz pod identyfikatorem "WWList" powinno byc umieszczone w tablicy DElist w TMoverParameters, tak? I jeszcze taki kwiatek -- parametr Size jest o 1 mniejszy niz liczba wpisow, np:

Kod: [Zaznacz]

WWList: Size=11
496 0 0 0
496 30 870 3000
496 75 870 3000
496 105 870 3000
496 135 870 3000
568 213 870 3000
640 305 870 3000
712 395 870 3000
784 495 870 3000
856 595 870 3000
928 705 870 3000
1000 800 870 3000
END-WWL

jak to interpretowac? Ignorowac pierwsza linie, czy Size?

[youBy]

Wiersze są ponumerowane od 0 do size, czyli jest ok ;)

[tmj]

Wiersze są ponumerowane od 0 do size, czyli jest ok ;)

Ale dla normalnego czlowieka nie-programisty to nieintuicyjnie jest ;)
Tabela sie teraz laduje i wydaje sie, ze silnik na obroty wchodzi jak trzeba, wkazniki sie ruszaja itp, ale nie rusza dran z miejsca. Ktos kumaty musialby porownac to co tam jest w c++ z tym co jest w oryginale, moze cos zostalo nie popdpiete, idk.

edit: chyba znalazlem. funkcja ladujaca .fiz nie odzytuje niektorych parametrow (FTmax itp) i wszystkie zostaja na domyslnym 0.

[youBy]

Tak na dobrą sprawę, to można size usunąć, o ile zmienna rozmiaru tabelki będzie sukcesywnie powiększana podczas wczytywania. Sęk w tym, że nie będzie to do końca kompatybilne wstecz.

[tmj]

ZTCW to Size i tak nie bylo uzywane -- funkcja ma swoj wlasny licznik i zwieksza go z kazdym przebiegiem, i dopisuje do tabeli nowe wartosci tak dlugo, jak jest jeszcze miejsce. W przyszlosci mozna faktycznie zrobic tabele np. na vector zwiekszanym dynamicznie, jesli 30+ wpisow to za malo.

Okazalo sie, ze nie ladowalo tez sekcji "MotorParamTable:" bo mialo na sztywne ustawione zeby szukac tylko "MotorParamTable0:"  Czy te dwie wersje sie czyms roznia, poza brakiem ostatniego parametru? W kazdym razie SU juz sobie jezdzi, chociaz nie wiem czy na 100% jak trzeba: