Pokaż wiadomości

Ta sekcja pozwala Ci zobaczyć wszystkie wiadomości wysłane przez tego użytkownika. Zwróć uwagę, że możesz widzieć tylko wiadomości wysłane w działach do których masz aktualnie dostęp.


Wiadomości - firleju

Strony: 1 [2] 3
31
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 09 Marca 2017, 07:06:46 »
Z dzisiejszych zabawek wstępna koncepcja wyświetlania tabelki prędkości. Jak to zobaczyłem to się zacząłem zastanawiać czemu mnie tak denerwuje, ale już miałem "następna stacja: Kraków Płaszów" i zbierałem się w ekspresowym tempie.

32
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 08 Marca 2017, 07:38:06 »
Jakim cudem na braku zwykłego przemnożenia możesz mieć takie różnice w wydajności? Musi być coś więcej od tego uzależnione i teraz jak się wyświetla freespot to nie robi jakiś bardzo kosztownych obliczeń. Co w takim razie to są za obliczenia?
Zająłem się ponownie tabelką prędkości. Jak narazie to nie działa w ogóle. Babrzę się z wyświetlaniem tabelki na ekranie bo zupełnie to zepsułem.

33
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 04 Marca 2017, 09:53:10 »
Mam sugestię, żeby wszystkie utils i tools wrzucić do jednego pliku. Dawniej było mctools, potem każdy robił własny plik i będzie straszne zamieszanie. Może jednak to połączyć co? Proponuję wykorzystanie pliku usefull.

34
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 03 Marca 2017, 07:08:39 »
No ja myślę, że nie jestem najbardziej odpowiednią osobą do zakładania nowego wątku. Już mnie tutaj obiegli. Co najwyżej można zamknąć temat konwersji i nową nazwę dać adekwatną do planowanych zmian w exe. Ja obecnie tylko zbieram zmiany i przerzucam pomiędzy repozytoriami.

@HTD: poruszanie się po kabinach jest właśnie teraz obliczane po czasie symulacji i stąd są te błędy (co jest bardzo ciekawe swoją drogą). Może bardziej chodzi o to, że nie obcina przesunięcia do granicy i przeskakuje do tej po drugiej stronie?

No i mimo wszystko mamy ciągle błędy u EP08 które nie zostały rozwiązane a warto by było jednak stwierdzić co się dzieje, nawet jeśli to jest jakiś błąd instalacji.

35
Na warsztacie / Odp: Sterowanie ruchem przez zewnętrzną aplikację
« dnia: 01 Marca 2017, 21:08:07 »
Z SCS jest jak z Rainsted. Nie ma launchera w exe więc korzystamy z dobrego zewnętrznego softu. Paul ma pomysł na sterowanie scenariuszem więc to jest lepsza droga niż zabawa w implementację logiki układania przebiegów, która już została zaimplementowana i przetestowana.
Dla mnie nie jest problemem, że automatycznie odpalasz na kompie drugi proces, który komunikuje się z tym głównym. Może być nawet bezokienny jeśli komuś to będzie wadziło.

36
Na warsztacie / Odp: Planowane zmiany w exe
« dnia: 28 Lutego 2017, 20:37:28 »
Zamiast robić jednej długiej zmiennej lepiej to podzielić i wysyłać osobno w kolejnych ramkach. W pierwszej wrzucasz liczbę ramek a potem już układ do pulpitu na podstawie opisu wie co ma wyciągnąć z której. W ten sposób masz elastyczny mechanizm, który Ci się raczej nie skończy.

37
Na warsztacie / Odp: Planowane zmiany w exe
« dnia: 28 Lutego 2017, 19:37:11 »
A jak nie ma przycisku w kabinie to nie działa (por. piasecznica, przyp. redaktora). Tylko jak się w to już bawić to na docelowo. Powiedzmy, że pomysł ze sterowaniem tmj jest ok, tzn Train przechwytuje zdarzenie i rozsyła po wszystkich pojazdach. Każdy pojazd zmienia swój stan wewnętrzny na podstawie właściwości (prowadzący, ukrotniony czy co tam jeszcze) i przesyła dane do wszystkich instancji kabin. Te sobie ustawiają na podstawie stanu odpowiednie urządzenia (wtedy w kabinie B będą się załączały lampki przy sterowaniu w kabinie A). Wtedy brak przycisku po prostu nic nie animuje, ale sam stan pojazdu się zmieni.

38
Na warsztacie / Odp: Planowane zmiany w exe
« dnia: 28 Lutego 2017, 19:16:16 »
Wątek troszkę podupadł bo tmj zajął się światłami, a trzeba pozbierać nasze myśli. Maćku jeśli teraz zaczniesz coś grzebać to ugrzęźniesz i albo przerobisz na swoją modłę i tak zostanie na wieki wieków albo narobisz się a potem to i tak będzie trzeba wyrzucić.
Jeśli dotykać Traina pod kątem sterowania to najlepiej ustalić do czego docelowo chcemy dojść bez rozpiski na poszczególne kroki i potem powolna implementacja małymi krokami.

39
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 28 Lutego 2017, 10:47:15 »
Nowego skanowania w najbliższym czasie się nie spodziewajcie bo mam dłuższą przerwę w pracach. Miałem tygodniową delegację a teraz mam parę projektów do zrobienia do końca tygodnia a potem trzeba dom wiosennie ogarnąć więc dopóki się nie zrobi luźniej to do tematu nie wrócę.

40
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 17 Lutego 2017, 22:39:00 »
Tylko, że grafika nie uwzględnia że światło lepiej się przebija przez mgłę niż obiekty oświetlane (czyli światło odbite, musi pokonać dwa razy tą samą drogę i jeszcze masz straty na odbiciu). Więc we mgle zobaczysz sygnał na semaforze np. ze 150m a przedmiot przy torze na 20m. Dodatkowo ta sama mgła w nocy da Ci widzialność na 30 m a w dzień na 200 m. Miałem tak kiedyś za Pilznem. Leciałem autostradą 120 km/h przy widzialności drogi ok. 30m gdyż każdy samochód (czyt. jego tylne światła) który doganiałem widziałem na kilkadziesiąt sekund przed wyprzedzaniem (czyli coś ze 300m tak naprawdę).
Z tego wynika, że freespot powinien mieć wartość jasności i zanikania inaczej przeliczany względem wpisu atmo niż reszta obiektów. Nie jest też przeliczana jasność względna, tak jak obecnie dla smugi.

41
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 16 Lutego 2017, 19:50:43 »
Moje zmiany są w połowie drogi w tej chwili. Nieużyteczne i nieużywalne. Znaczy wszystko popsułem i jeszcze nie naprawiłem. Na razie grzebię w obsłudze W4, np wyrzucam różne rzeczy do osobnych funkcji bo niepotrzebnie to wszystko na kupie jest.Idzie mi jak po grudzie bo złapałem 2 dodatkowe projekty i teraz troszkę innych zajęć mam. Ale czeka mnie w najbliższym czasie 2 x 14 godzin w pociągu to pewnie prace posuną się do przodu.

42
Na warsztacie / Odp: Kaliska - sceneria do pobrania w pierwszym poście!
« dnia: 16 Lutego 2017, 07:33:29 »
Ja mam w notatniku wyprowadzony wzór na odległość hamowania z zmienną prędkości plus do wprowadzenia do tego jeszcze zmiennych od pozycji kranu i siły na klockach w zależności od ciśnienia w przewodzie. To ostatnie to jest trik ale do zrobienia w przybliżeniu. Wszytko jest całką po czasie. Wtedy możesz wyliczyć sobie za ile staniesz na podstawie aktualnej prędkości uwzględniając prędkość rozchodzenia się fali po składzie.

43
Na warsztacie / Odp: Kaliska - sceneria do pobrania w pierwszym poście!
« dnia: 15 Lutego 2017, 19:24:53 »
Właśnie to jest dziwne bo akurat ta część odpowiedzialna za ten kawałek był w c++ wcześniej i nic na nowych exe nie ruszałem. Jak dla mnie magia i w ogóle do d.. to jest zrobione obecnie. Ja pamiętam, że w pewnym momencie dałem skanowanie dalsze żeby czegoś tam nie przeoczył to AI przestało przyspieszać. Jeszcze nie doszedłem do tego miejsca, na razie mozolnie przerabiam skanowanie, potem zajmę się reakcją na wyliczenia skanowania bo jak to jest zrobione obecnie jest nie do utrzymania na dłuższą metę.

44
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 14 Lutego 2017, 22:53:34 »
Krzyśku, uważam że nie masz racji. Post Milka to nie było otwarcie dyskusji nad sensem tylko poinformowanie, że on sensu nie widzi i usuwa. Nie widzę tu oznak próby dyskusji. Więc nie ma czego prowadzić.
Milek, nie wiem czy mylisz idee z praktyką, czy nie ale twoje podejście jest ideowe a nie praktyczne. A praktyka mówi, że nasz kod nie aktualizuje używanych bibliotek zbyt często. I jeśli nie masz libów na repo to za jakiś czas możesz nie znaleźć odpowiednich w sieci (znajdź mi lib-y i dll-ki do GTK2.0.1, spróbuj) i zaczną się posty w stylu "chłopaki, podrzućcie mi liba bo skompilować nie mogę".

45
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 13 Lutego 2017, 08:34:39 »
Eeee, a możemy doprowadzić exe do stanu używalności i wrzucić już to na mastera, a potem zacząć rozgrzebywać nowe rzeczy?

46
Na warsztacie / Odp: Planowane zmiany w exe
« dnia: 11 Lutego 2017, 15:37:26 »
WM_COPYDATA jest używane do multiplayera. Docelowo idzie bezpośrednio na TCP/IP.
LPT i COM muszą zostać bo są używane do sterowania pulpitami fizycznymi.
Dźwięk: czytałem i OpenAL nie jest już w zasadzie rozwijane, są też lepsze biblioteki ale mają taką wadę jak Unity, tj. można za free użyć to projektów niekomercyjnych. Licencja może się kiedyś zmienić (ale to dotyczy chyba wszystkiego).
Fonty: mnie jest obojętne, byleby dało się to normalnie ubrać w jakąś strukturę, a nie tak jak teraz że musisz ręcznie ustalać pozycję na ekranie gdzie to wyrenderować.
Co do minimum OpenGL to się nie wypowiem. Ostatnie badanie kto co ma było ze 5 lat temu. Ja mam min. 4.0 więc mnie osobiście to wsio radno.

47
Na warsztacie / Odp: Planowane zmiany w exe
« dnia: 11 Lutego 2017, 12:05:59 »
@tmj: no ale po co Ci elastyczny wrapper który zajmuje się tylko przekazywaniem danych dalej. Ponadto wagony skrajne w zespole muszę mieć wskaźniki na wagony skrajne w innych zespołach, gdyż inaczej nie policzysz hamulców oraz sił na sprzęgach. Oczywiście można inaczej zorganizować dane, żeby nie było wskaźników bezpośrednio do pojazdów tylko do potrzebnych danych, ale wtedy te dane trzeba trzymać na poziomie pociągu a nie zespołu (co nie znaczy, że pociąg ma robić z nimi cokolwiek poza trzymaniem). Nie widzę sensu istnienia dodatkowego poziomu abstrakcji, który w 99% przypadków będzie się sprowadzał do zwiększania opóźnień a nie będzie nic wnosił.
Moją myślą było to, żeby zespół miał taki sam interfejs jak pojazd, ale nie był pojazdem. Tak, żeby pociąg miał zestaw zespołów / pojazdów o tym samym interfejsie. W przypadku zespołu dochodziłoby odpowiednie zarządzanie informacją w stosunku do pojazdów wewnątrz. W przypadku pojazdów nie ma takiej potrzeby żeby coś tam było wyżej. Przynajmniej ja takiej nie widzę.
Troszkę się zapętliliśmy w dyskusji. Trzeba konkretnie rozpisać co dana klasa miałaby trzymać za informację i jakie mieć API do poszczególnych warstw wyższej i niższej oraz między tym samym poziomem. Inaczej do niczego nie dojdziemy.
@yB: a co z liczeniem sił pomiędzy pojazdami wewnątrz zespołu? To też trzeba liczyć bo przecież to nie jest monolit.

48
Na warsztacie / Odp: Planowane zmiany w exe
« dnia: 10 Lutego 2017, 07:24:02 »
Tylko, że jeśli klasa zespół ma być obecna dla każdego rodzaju pojazdu, to czym będzie się zajmować w przypadku wagonów towarowych, gdzie co najwyżej używasz hamulca? Rozsyłaniem komend do zespołów zajmuje się pociąg. Koniec końców kończysz z ilomaś wersjami klasy zespół, gdyż musisz mieć osobne dla każdego typu zespołu jaki Ci się zdarzy żeby obsługiwać te wszystkie dziwne wyjątki jakie masz obecnie w fizyce i w dynamic + klasa dla wagonu.
Czym interakcja pociąg - zespół ma się różnić od interakcji bezpośredniej pociąg - wagon?
Nie widzę potrzeby trzymania nadmiarowych informacji w zespole w mojej wersji, gdyż pojazdy dla takiego zawsze będą miały dedykowane klasy i można takie napisać w wersji uproszczonej.

49
Na warsztacie / Odp: Planowane zmiany w exe
« dnia: 09 Lutego 2017, 07:45:18 »
Zrobiłem funkcję rzutującą pozycję komórki na tor. Narazie w wersji wstępnej niezoptymalizowanej wygląda to jak:
1. Weź punkt1 toru.
2. Policz odległość od eventu.
3. Policz punkt na bezierze w odległości +0.1 od poprzedniego
3. Policz odległość od eventu
4. Jeśli mniejsza wróć do punktu 3. Jeśli koniec toru przejdź na następny.
Algorytm łopatologiczny, nieoptymalny, dający odległość w rozdzielczości obecnie ok. 10m ale eventów jest na tyle mało, że nie powinien specjalnie rzutować na wydajność a na ruch też nie. W następnej wersji zwiększę rozdzielczość sprawdzania dla znalezionej pary punktów pomiędzy którymi jest event do mniej więcej 1m.
Ponadto zmieniłem deque dla wskaźników na std::list ze względu na to, że potrafię sobie wyobrazić przypisanie wskaźników w odwrotnej kolejności i w dziwnych miejscach. Obecnie przerabiam funkcję TableUpdate. Przy okazji pytanie czy nie lepiej konwertować czas przyjazdu i odjazdu w rozkładzie na czas, nie trzymać jak obecnie. Jak do tej pory po zmianie poprzednich funkcji schodzę o mniej więcej 2 do 3 "wcięć" w kodzie. Szczególnie, że teraz rozbijam sprawdzanie pozycji osobno na tabelę tylko z torami i tylko ze wskaźnikami.
Aktualizacja wpisów w tabelce teraz polega tylko na sprawdzeniu stanów, a aktualizacja dystansu jest osobno za pomocą odległości przejechanej przez pierwszy pojazd. Czyli po bożemu. Do zrobienia jest zaktulizowanie przeliczania długości toru podczas jego inicjalizacji na propozycję @HTD co powinno polepszyć przemieszczanie taboru po torach i aktualizację tabelki, aczkolwiek obecna metoda jest wystarczająco dokładna to raczej nieoptymalna.

Co do fizyki, to z podziałem TMover to jak najbardziej. Tu się troszkę nie zrozumieliśmy. Mnie chodzi to, żeby nie powstała sytuacja w której masz taki układ:
Kod: [Zaznacz]
pociąg   -> pojazd -> wagon
                       -> wagon
             -> pojazd -> wagon
             -> pojazd -> wagon
             -> pojazd -> wagon
             -> pojazd -> wagon
             -> pojazd -> wagon
             -> pojazd -> wagon
             -> pojazd -> wagoni tak 40 razy. Czym to się różni w architekturze od obecnego:
Kod: [Zaznacz]
Train -> DynamicObject
      -> TCab
DynamiObject -> TMoverParameters
DynamiObject -> TMoverParameters
DynamiObject -> TMoverParameters
DynamiObject -> TMoverParameters
DynamiObject -> TMoverParametersitd.

50
Na warsztacie / Odp: Planowane zmiany w exe
« dnia: 07 Lutego 2017, 21:59:42 »
eventy cd.
Obecnie robię to tak, że rozdzieliłem tabelkę na dwie. Jedna trzyma informacje o zeskanowanych torach, druga o zeskanowanych wskaźnikach. W tej chwili obie to std::deque gdyż doszedłem do wniosku, że modyfikacja kolejek odbywa się raz na parenaście sekund więc narzut związany z ewentualną alokacją pamięci jest pomijalny. Takie rozbicie pozwala np. sprawdzać szybciej sobie ograniczenia ze wskaźników (tabelka jest o wiele mniejsza). Modyfikacja odległości w tabelkach odbywa się przez odjęcie odległości przejechanej przez pociąg co wszystko upraszcza. Całe clue zabawy polega na prawidłowym policzeniu odległości do obiektu podczas skanowania z czym aktualnie walczę.
Wydaje się, że sposób łączenia torów z wskaźnikami zostanie bardzo podobny do obecnego. Po prostu nie będzie uruchamiania tego punktu przez najeżdżający wózek.

Co do pojazdów z fizyką, to zważ że jeśli zmiksujesz DynamicObject z TMoverParameters ze stworzeniem tego dla każdej klasy pojazdu osobno to w przypadku jeśli zawsze pociąg będzie zawierał zespoły i te dopiero pojazdy to dla typowego składu cargo sytuacja nie rożni się od obecnej.

51
Na warsztacie / Odp: Planowane zmiany w exe
« dnia: 05 Lutego 2017, 21:19:11 »
Chciałbyś umieścić fizykę w klasie pojazdu?
Chciałbym uniknąć niepotrzebnego tworzenia klasy zespół dla pojedynczych pojazdów. Tak naprawdę zespół jest potrzebny tylko do ezt. Cała reszta tego nie potrzebuje.

Teraz eventy. Ogólnie mamy konsensus, że trzeba to wywalić, ale na potrzeby aktualnych prac myślałem nad tym jak AI współpracuje z modelem scenerii. Wpływ na prowadzenie postrzeganie trasy mają dwie rzeczy: tory oraz wszelakiego typu wskaźniki i semafory. Obecnie AI skanuje tor przed sobą i czyta czy jest do niego przypisany event od strony od której nadjeżdża. Potem event jest sprawdzany na okoliczność uznania go za "pasywny". Do tego punktu wszystko jest ok. Następnie wszystko jest wrzucane do wspólnego worka pod nazwą SpeedTable, która ma własne algorytmy przeliczania odległości od obiektów. Niestety, te algorytmy działają tylko przy założeniu, że urządzenia są przypisane do torów przy których stoją i w kolejności w jakiej stoją. Wszelkie błędy powodują nieprawidłowe przeliczanie odległości.
cdn..

52
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 03 Lutego 2017, 22:31:33 »
Parametry eventów można odczytać tylko na podstawie tego do którego akurat odnosi się w danym miejscu i co z nim robi. ZTCP to coś koło 8, 9 to jest memcell, wartości. Pierwsze to chyba położenie. Nigdy nie odgadłem co kierowało tym gościem co to zaprojektował.

Z innych rzeczy. Tabelka jest niepoprawialna. Jedynym sposobem, żeby dobrze działała to jest wiązanie eventów do torów, które stoją obok. Przy okazji na Sieradzu po zmianie wiązań eventów udało mi się znaleźć powtarzalny efekt nie widzenia w4.
Żeby poprawić tabelkę na elastyczną należy zmienić cale SpeedPosTable na unordered_map i sortować po trasowaniu torów. Ponadto dodać możliwość przypisywania więcej niż jednego eventu w danym punkcie (np. dwa eventy1) i wszystkie zmiany, które się z tym wiążą. Szczerze? Łatwiej chyba zaprojektować to od nowa.

53
Na warsztacie / Odp: Kaliska - sceneria do pobrania w pierwszym poście!
« dnia: 03 Lutego 2017, 08:41:54 »
Super sprawa z tym dumpem. To jest jedna z rzeczy, których brakowało. Działa też release?
Ja dalej ślęczę nad poprawkami do tabelki prędkości. Na razie rekurencyjny algorytm przechodzenia do następnego toru.

54
Na warsztacie / Odp: Kaliska - sceneria do pobrania w pierwszym poście!
« dnia: 02 Lutego 2017, 22:09:30 »
Jestem na testach rozwiązania więc nie spieszcie się tak z przerabianiem. Błąd na pewno będzie poprawiony w exe c++. W starszym nie wiem czy będzie chciało mi się przenosić. Nowe exe wygląda na coraz bardziej użyteczne dzięki tmj.

55
Na warsztacie / Odp: Kaliska - sceneria do pobrania w pierwszym poście!
« dnia: 02 Lutego 2017, 18:47:24 »
Takie wywałki jak mówisz nie znajdziemy po logu niestety. Teraz pracuję nad zmianą odczytywania odległości od eventu jeśli nie jest przypisany do toru obok i zobaczymy czy to coś da.

56
Na warsztacie / Odp: Planowane zmiany w exe
« dnia: 02 Lutego 2017, 11:34:40 »
Do spraw, do zrobienia jest sterowanie pociągiem. To co yB wyłuszczył jest dość istotne dla prowadzenia symulacji. Więc trzeba zaprojektować nową architekturę, która uwzględni nowe pojazdy. Może coś takiego:
Pociąg -> Pojazd / Wagon -> Fizyka
Wtedy poszczególne elementy zawierają:
  • Pociąg: zawiera wszystkie pojazdy / wagony, przechowuje rozkład jazdy, przechowuje AI / człowieka dla wszystkich pojazdów, które mają sterowanie (np. podwójna trakcja).
  • Pojazd / Wagon jest dość ciekawą konstrukcją. Z punktu widzenia Pociągu to to jest to samo. Z punktu widzenia Wagonu Pojazd jest pociągiem. Czyli Pojazd jest specyficzną konstrukcją, która przechowuje poszczególne Wagony oraz logikę przekazującą polecenia AI dla poszczególnych Wagonów. Pojazd byłby lepiej napisanym odpowiednikiem obecnego sprzęgu depotowego.
  • Fizyka: zawiera obliczanie zmiennych fizycznych dla danego Wagonu. Np. dla wagonów to może być tylko liczenie sił na sprzęgach oraz układ hamulcowy. Dla części EZT to może być różna fizyka zależnie od posiadania lub nie odpowiednich elementów.
Kwestia umiejscowienia kabiny i miejsca przechwytywania sterowania jest do rozwiązania.

57
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 01 Lutego 2017, 09:30:16 »
Sprzęgi depotowe zrobił yB. Ogólnie cała konstrukcja sterowania pociągiem jest poroniona:
  • DynamicObject jest klasą opakowującą dla Mover, tylko że Mover jest jeden i to jest bez sensu jeśli Mover nie jest polimorficzny.
  • Dynamic trzyma TController, i dla sterowania sprawdzany jest każdy obiekt, po to żeby zrobić if-a że nie ma.
  • Nie istnieje klasa trzymająca całość pociągu.
  • Klasa Train jest używana do trzymania kabiny oraz wskaźników czym ta kabina steruje.
Wszędzie jest pełno odwołań bezpośrednio do zmiennych w danych klasach co powoduje, że wszystkie zmienne w mover są publiczne. Tak na wszelki wypadek.

58
Na warsztacie / Planowane zmiany w exe
« dnia: 01 Lutego 2017, 09:17:40 »
Otwieram dyskusję o tym w których miejscach należy zmienić kod oraz jak to zrobić, żeby osiągnąć cele. Na początek szybka lista tego co moim zdaniem wymaga zmian:
  • Rozbicie mover na klasy odpowiadające typom (prądu stałego, asynchrony, diesel, diesel electric, itp) a następnie poszczególnym modelom (obecnie rozróżnienie przez dt_xx). Za tym idą zmiany w parserze plików fiz, bo będzie można wywalić wszystkie niepotrzebne zmienne. Nie mówiąc już, że jakiekolwiek dodanie nowego typu pojazdu będzie łatwiejsze. Z minusów wymaga to zmian w interfejsie do pythona na pobieranie przez skrypt wybranych danych, ale samych ekranów nie jest jeszcze na tyle, żeby nie dało się tego wykonać.
  • Rozbicie Driver na część tylko dla człowieka oraz tylko dla AI, być może AI dla specjalnych okazji jeśli mają być takowe.
  • Implementacja protokołu do wymiany danych z SCS. Wywalenie eventów. Dość trudne, gdyż już teraz na etapie zmian w tabelce dochodzę do kwestii kompatybilności z tym co obecnie można robić, a co będzie możliwe po zmianach. Tu jest pytanie czy tylko naprawić co jest na potrzeby Kaliskiej w obecnej wersji i po prostu zrobić to od nowa, ale wtedy wszystkie scenariusze będą do zrobienia na nowo (chociaż zapewne odtworzenie będzie bardzo łatwe przy pomocy SCS).
  • Serializacja danych w celu zapisu i odtworzenia stanu sesji jest możliwa, szczególnie jeśli porozbijamy monolityczne klasy jak obecnie.

59
Na warsztacie / Odp: Exe od wersji 476
« dnia: 26 Stycznia 2017, 19:02:01 »
Walczę z kaliską. Na razie bez powodzenia. Tylko stwierdziłem, że sam event jest przypisywany pierwotnie do tabelki z zeskanowaną dotychczas odległością, co daje punkt początkowy toru do którego jest przypisany.

EDIT:
Skład zawsze skanuje od końca składu. W tej chwili dorzuciłem informację o długości składu przy pierwszym skanowaniu, żeby seradz_pod100 był od razu na ujemnej długości.

60
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 24 Stycznia 2017, 11:31:59 »
Widzę, że dalej usuwa solucję. Ale zostaw, po prostu ją wrzucę z powrotem.
EDIT:
Połączyłem. W jednym pliku zaposiała się niepolska literka, ale to już poprawię. Wieczorkiem dorzucę zmiany do VBO i wystawię exe do testów. No i zacznę w końcu szukanie zgłoszonych błędów. I ewentualne poprawki dla Kaliskiej.

Strony: 1 [2] 3