- Symulator MaSzyna -

Symulator EU07 (i nie tylko) => Na warsztacie => Wątek zaczęty przez: firleju w 08 Września 2016, 10:51:21

Tytuł: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 08 Września 2016, 10:51:21
Witam,

Mam nadzieję, że jeszcze w tym tygodniu dam w tym wątku specjalne exe do testów. Pierwszą zmianą jak będzie wprowadzona będzie wyprowadzenie obsługi rozkładów jazdy z Pascala do c++. Dlaczego? Był to najprostszy moduł do zrobienia. Nie miał interakcji z pozostałymi plikami Pascala więc można było na nim przetestować np. wykorzystany konwerter.
Jakie są wstępne wnioski: konwersja nie będzie łatwa i przyjemna. Jest dużo takich fajnych kruczków, które powodują, że każdą linijkę trzeba przejrzeć, szczególnie przy obsłudze pętli oraz funkcji z ObjectPascala / Delphi.

Biblioteka glew32 potrzebna do uruchomienia (wejdzie w skład paczki) http://eu07.pl/forum/index.php/topic,28159.msg437252.html#msg437252
Tytuł: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 08 Września 2016, 12:00:03
Na teraz moge powiedziec tyle, ze przetlumaczenie fizyki (bez hamulcow) bedzie prostsze jak tlumaczeie queryparsercomp.
Queryparsercomp'a generalnie nie oplaca sie tlumaczyc a powinno sie zastapic CParserem (nie powino byc z tym wiekszych probleow).
Na koniec pozostanie zamiana typow lancuchowych AnsiString, mysle ze najlepiej na string z std:: bo jest latwy w laczeniu.
Jezeli o niczym nie zapomnialem to bylyby te 3 kwestie do ogarniecia - fizyka, parser i AnsiStringi. Jesli by sie dobrze zmotywowac to
moglby byc to ostatni rok MaSzyny na starym srodowisku pisanej w dwoch jezykach. Jescze ciekawostka na koniec...
Odkrylem ze program mozna kompilowac w C++ Builderze 6 - tam tez jest support pascala, ale aby skomilowac nalezy zakomentowac pewna dyrektywe w cparser.cpp. Skutki uboczne sa takie, ze powstaje cos  stylu wycieku pamieci i natsepuje zawieszenie podczas wczytywania.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Cesky Kretek w 08 Września 2016, 12:46:08
Jak skończycie przenosić całą MaSzynę na C++ do końca tego roku to zamówię Wam po kracie piwa z dostawą do domu (jakieś Tesco Ezakupy czy inny Auchan Direct).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 09 Września 2016, 09:02:51
Jak narazie jestem na etapie sprawdzania czemu mi się wywala na EAccesVolation. Wygląda jakby nie inicjował mi zmiennej i jest ona ciągle NULL (chociaż jest inicjowana przed użyciem). Jako, że mam czas 2 x 0,5 godziny dziennie to nie widzę specjalnie możliwości przetłumaczenia tego do końca roku. Do tego jestem bezalkoholowy więc zgrzewka piwa odpada w przedbiegach ;)

  Dodano: 09 Września 2016, 09:12:12
PS.
Największe problemy obecnie są z określeniem czy dana struktura powinna być typu struct czy class.
Trzeba dopisać też często wszystkie konstruktory.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Benek w 09 Września 2016, 11:50:14
W C++ struktura i klasa to to samo. Różnią się tylko domyślnym typem dostępu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 09 Września 2016, 14:49:54
Nie wiem czemu to rozdzielili w zasadzie. Nie inicjuje się prawdopodobnie gdyż nie ma konstruktora (nie występuje coś takiego w Pascalu)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Benek w 09 Września 2016, 15:16:49
C++ to potomek C, chodzi o kompatybilność wsteczną napisanych już programów.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 10 Września 2016, 13:49:13
W każdym bądź razie to nie problem konstruktora, gdyż znalazłem takowe, i poprawnie się inicjują. Tylko cała zainicjowana klasa nie jest przypisywana do wskaźnika. Ma to chyba związek z warningiem linkera, że mam w wielu plikach obj zdefiniowaną zmienną (wszystkich w których inkluduje nagłówek ze zmienną). Nie wiem o co biega, gdyż definicja wygląda jak wszystkiego innego a tam nie ma takiego problemu. Zresztą jak było to w pascalu to nagłówek też miał tą zmienną i nie było takiego problemu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: El Mecánico w 10 Września 2016, 21:48:05
Firlej, a w *.hpp w którym jest deklaracja tejże klasy, lub wskaźnika, masz extern przy definicji?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 11 Września 2016, 11:12:07
Owszem, w .hpp jest. Tylko, że jak rozumiem extern używa się wtedy kiedy masz zmienną w bindingu. A w ty przypadku już nie inkluduję .hpp w ogóle. Ale spróbuję skompilować z extern w tym miejscu, może pójdzie.

  Dodano: 11 Września 2016, 12:39:27
Doczytałem sobie. Konwerter źle to zrobił i trzeba było poprawiać. To przy okazji następnych konwersji będzie przydatna wiedza. Było trzeba w nagłówku dać extern i drugi raz definiować zmienną w pliku cpp. Teraz działa poprawnie. Dalej walczę gdyż co coś poprawię to mam jakieś kolejne babole.

  Dodano: 11 Września 2016, 13:44:38
Muszę poprawić wszystkie odwołania liczbowe w substring, gdyż okazuje się, że AnsiString ma liczone od 1 a std::string od 0. No i AnsiString.SubString odwołuje się do innego miejsca w stringu niż std::string::substr w tym momencie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: janek32 w 11 Września 2016, 13:54:47
Generalnie struktura powstała już w C i może zawierać dane i wskaźniki na dane/wskaźniki na funkcję, i tak jak napisał @Benek, cała jej zawartość jest publiczna. Klasa została wprowadzona w C++ i może zawierać funkcje (metody), posiada konstruktory i destruktor, domyślnie (bez użycia słów kluczowych public: albo protected:) jej zawartość jest prywatna.
Nie jestem pewny, jak struktura zachowuje się w C++ (nigdy np. funkcji w strukturze pisać nie próbowałem), ale raczej dobrze jest trzymać w kodzie takie rozróżnienie i struktur używać do tego, do czego historycznie służyły.

Klasa w C++ nie musi mieć zdefiniowanych konstruktorów, jeżeli nie ma, używane są domyślne. ZTCW zwykły konstruktor wtedy nic nie robi, kopiujący po kolei przepisuje zawartość wszystkich zmiennych. Własne konstruktory i destruktor przede wszystkim trzeba zdefiniować, jeżeli w klasie wykorzystuje się dynamicznie przydzielaną pamięć - ale czasami to może być też wygodne w innych sytuacjach, po prostu jak przy inicjalizacji obiektu trzeba coś zrobić.

Co do ostrzeżenia linkera - próbowałeś użyć dyrektyw IFNDEF?
#ifndef _NazwaPliku_H_
#define _NazwaPliku_H_

(kod)

#endif _NazwaPliku_H_
Wtedy jeżeli oznaczony w ten sposób plik jest przy linkowaniu dołączany kilka razy, kod z niego trafia do głównego tylko raz.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 11 Września 2016, 14:07:30
#ifndef jest od samego początku. To była zmienna poza jakąkolwiek klasą i w związku z tym, że była w pliku nagłówkowym tylko to każdy cpp ją sobie domyślnie inicjował sam. Rozwiązaniem była deklaracja w nagłówku (extern) oraz definicja w jednym cpp. Teraz już działa.
W tej chwili walczę z funkcją konwersji int na string. W c++11 jest to_string(), ale wcześniej nie było i musiałem sobie zdefiniować taką globalną. Ale żeby była globalna zwraca static std::string to i nie chce mi jej dodawać do innego stringa za pomocą operator+. Chyba będę musiał użyć append.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 11 Września 2016, 18:55:08
zrob sobie oddzielny modul z fukcjami, zobacz jak ja mam w qutils.h/cpp, laczenie jest bezproblemowe

atos atoi atof

lub

std::string itoss( int x ) {
  int length = snprintf( NULL, 0, "%d", x );
  assert( length >= 0 );
  char* buf = new char[length + 1];
  snprintf( buf, length + 1, "%d", x );
  std::string str( buf );
  delete[] buf;
  return str;
}

lub

std::string itoss(int val)
{
  std::stringstream ss;
  ss << val;

 return ss.str()
}

std::string itoss(int val)
{
 string tmp; // brzydkie rozwiązanie
 itoa(val, (char*)tmp.c_str(), 10);
 string str = tmp.c_str();
 return str;
}

char* itochp(int n)
{
     int i = 0;
     char tmp[12];
     static char ret[12];
     if(n < 0) {
      *ret = '-';
      i++;
      n = -n;
     }
     do {
      *tmp = n % 10 + 48;
      n -= n % 10;
      if(n > 9) *tmp++;
     }
     while(n /= 10);
     while(ret[i++] = *tmp--);
     return ret;
}
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 12 Września 2016, 08:22:29
Robię sprintf() ale coś nie bangla. Sprawdzę jak działa z twoją wersją.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 12 Września 2016, 10:46:41
Jeszcze przyklad konwersji z float/double z obsluga wyjatku

inline std::string dtoss(double val)
{
  std::ostringstream o;
  if (!(o << val))
    throw BadConversion("stringify(double)");
  return o.str();
}
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 12 Września 2016, 16:09:03
Nie chcę używać strigstream narazie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 12 Września 2016, 16:34:36
Jakies przeciwwskazania weszysz?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 12 Września 2016, 19:37:49
Patrzę w qutils i nie widzę tych funkcji. Chyba mam jakąś starą wersję repo, albo co. Skopiowałem twoją funkcję, ale jest taki problem, że:
int length = snprintf( NULL, 0, "%d", x );ta linijka zwraca mi -1 co teoretycznie oznacza problem ze zrzuceniem. Nie mam pojęcia jaki może mieć problem jeśli int przychodzi mu o wartości 18.
Nie chcę linkować całej biblioteki, żeby zrobić z niej jedną funkcję, którą docelowo i tak zamienię na std:to_string()
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 12 Września 2016, 19:56:51
Moze zamiana %d na %i rozwiarze problem...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 12 Września 2016, 22:02:06
Nie rozwiązało. Zrobiłem na streamie i bangla. Borland sucks...

  Dodano: 12 Września 2016, 22:13:04
Dobra, w załączniku testowe exe. Bazuje na 478 plus parę commitów, więc nie ma tutaj wszystkich ostatnich poprawek. Sprawdzamy czy rozkład poprawnie się wczytuje oraz ogólnie wszystko działa jak poprzednio.

  Dodano: 13 Września 2016, 07:55:28
Rano narzuciłem zmiany z gałęzi głównej na moją gałąź. Delikatne poprawki na zmiany wprowadzone przez Stele i teraz możemy lecieć dalej z konwersją. Jak się będą objawiać jakieś błędy w rozkładach to poprawki będą na bieżąco.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 21 Września 2016, 07:27:53
Czuje się jak Ra. Wszyscy biorą, nikt nie napisze, że dobrze... Ehhh...
Dobra, koniec narzekania. Z najnowszych wiadomości z frontu to jestem gdzieś w połowie konwersji pliku OerlikonEst. Jako, że wygląda na dość spokojną końcówkę września jeśli chodzi o czas wolny (znaczy brak dodatkowych projektów) jest pewna szansa na zakończenie tego do końca tego miesiąca. Wbrew temu co pisze Q konwersja nie jest jakaś super prosta, gdyż konwerter nie zamienia automatycznie niektórych słów kluczowych object pascala na ich odpowiedniki w c++. W każdym razie powoli posuwam się do przodu zdobywając z każdą linijką nowe pole do wykazania się moją niewiedzą ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 21 Września 2016, 20:05:39
Skoro czujesz sie jak @Ra to  w takim razie juz Cie nie lubie ;D, ale wracajac do tematu przepisywania hamulcow... Moje pytanie jest nastepujace - czy czujesz sie na silach przetlumaczyc te wszystkie moduly? Konkretnie chodzi mi o to ze tam jest pokomplikowane to wszystko poprzez te okropne dziedziczenie klas. Ja poleglem przepisujac to recznie kontrolujac i wiedzac co robie, Ty zas do tlumaczenia uzywasz jakiegos konwertera, a to nie wplywa pozytywnie na zapoznanie sie z
tym co sie przepisuje - tak mi sie przynajmniej wydaje :). Mysle ze powinienes ogarnac prostsze sprawy np. takie jak zamiana typow lancuchowych
na std::string czy, zamiana parserow na CParser, bo po przetlumaczeniu SPKSa, moze okazac sie, ze MaSZynum zawiesza sie na wczytywaniu scenerii :D.
Mozesz mi nie wierzyc Grzesiu, ale hamulce najlepiej zostawic na sam koniec - bo najtrudniejsze :).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Balaclava w 21 Września 2016, 20:22:18
Zassałem exe na dysk i próby odpalenia misji na Quarku, l61_pospieszny (tej od @Ra) i l053-sluzba2-night zakończyły swe wczytywanie na takiej oto linijce:
New timetable for [nazwa_loka]: rozkladCzysta paczka + patch 16.08.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 21 Września 2016, 20:57:51
Mi się ładuje. Przetestowałem na l61_regio od Ra.
Wyjazd z Osobowej zaświeciło na zielono i usunęło z tabelki. W pierwszym wersie w kolejnej stacji jednak nadal wyświetla "Częstochowa Osobowa" i po zatrzymaniu się na Stradomiu nie reaguje na W4.
Z moich ostatnich zmian, to nie odtwarza dźwięku drzwi.
Na td przy pustym rozkładzie zawiecha na ładowaniu rozkładu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 22 Września 2016, 08:42:35
@Krzysiek: Zawiecha na ładowaniu rozkładu to jest brak wyjścia z pętli. Na pewno masz ostatnie exe? Bo poprawiałem na pewno ten błąd. Podaj mi który rozkład ładowałeś w misji l053 to spróbuję na td go załadować i zobaczę co się stanie.
@Stele: Brak skasowania odjazdu to raczej nie jest wina konwersji. Cała obsługa pozostała tak jak poprzednio. Na normalnym exe też się tak zachowuje?
@Q: Nie ma większego znaczenia czy zacznę od najtrudniejszego, czy najłatwiejszego. Teoretycznie zacząłem od najłatwiejszego, a okazało się, że cały moduł jest zakręcony jak jelita. Wiem, że tu jest fajne dziedziczenie, ale da się to opanować. Podpieram się tym co generuje Borland do bindingów.

  Dodano: 26 Września 2016, 08:51:15
Kolejne wieści z frontu:
Całość modułu jest przetłumaczona. Niestety nie kompiluje się, gdyż w Pascalu w jednej funkcji użyty jest parametr domyślny na zmiennej i okazuje się, że przez binding to nie działa. Więc albo dopisze sobie funkcje w Pascalu, albo od razu przetłumaczę komplementarny plik, bo robienie funkcji inline po to żeby ją zaraz skasować chyba nie ma sensu. W takim układzie do tłumaczenia idzie hamulce.pas.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mac310 w 27 Września 2016, 21:28:49
Nie mam teraz na nic czasu więc ani nie mogę pojeździć na działającym exe, ani potestować niczego nowego. Chwila w hotelu i mała próba z TD i 478c1 i zawiesza się ładowanie na komunikacie "New timetable for ep07-424: rozklad" więc nie potestuję niczego więcej :(
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 27 Września 2016, 22:17:04
Czyli ma problem z pustymi rozkladami. Testowałem tylko na istniejących. Ehh...

  Dodano: 29 Września 2016, 13:46:06
Z placu boju: jestem w połowie pliku hamulce.pas. Rozkładami się zajmę jak to skończę, gdyż jeśli dobrze pamiętam, to będzie trzeba napisać ładowanie od nowa.

  Dodano: 30 Września 2016, 14:43:58
Stan na dzisiaj: wstępnie poprawiony hamulce.cpp. Szacun dla króliczka bo myślałem, że nie skończę tego pliku. Teraz jeszcze pozostało posprawdzać co źle zostało skonwertowane i dorzucić konstruktory z pliku generowanego przez Borlanda.

  Dodano: 02 Października 2016, 10:58:26
Stana na 02.10: pliki kompilują się poprawnie, jednak linker ma problem z odwołaniami przy _mover. Będę musiał posprawdzać do czego się odnoszą poszczególne pozycje. natknąłem się też na parę funkcji, które bardzo chętnie bym użył, tylko pojawiły się od C++11 i narazie napisałem protezy. Stąd prawdopodobnie hamulce mogą nie do końca zachować się tak jak powinny do czasu poprawnej implementacji (no chyba, że to nie ma znaczenia, ale nie jestem w stanie tego rozpoznać). Chodzi o funkcję Round(i_bcp).

  Dodano: 03 Października 2016, 07:33:27
03.10: Zacząłem od tyłka strony okazuje się. Nie zbuduję projektu dopóki całe mover nie pójdzie do konwersji. W związku z tym dzisiaj rankiem do tłumaczenia poszło friction.pas i po południu zaczynam _mover.pas. Prośba do jubaja o konsultacje w sprawie macierzy, które zakres miały ujemne .. dodatnie: czy wystarczy że w implementacji będę do zmiennej otrzymanej dodawał tak, że przy zgłoszeniu najbardziej ujemnej wartości zwróci mi 0?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 20 Października 2016, 14:46:01
Witam po dłuższej przerwie.
Stan na 20.10: _mover przetłumaczony. W tym miejscu podziękowania do Q za jego wielki wkład. Obecnie dalej exe się nie kompiluje, gdyż zmieniam wszystkie AnsiString na std::string, co jeszcze chwilę potrwa. Zmieniam też wszystkie funkcje z bibliotek Borlanda na standard C++98 (jak coś jest w tylko bibliotece standardowej C++11 to dopisuję na szybko do mctools do czasu przejścia na nowszy kompilator). Jeszcze nie wiem czy rozwiązałem problem z tablicami BPT, ale to pewnie okaże się jak w końcu uda mi się wszystko skompilować. Nie poprawiłem jeszcze błędu zawieszania wczytywania pustych rozkładów, ale to jest kwestia przywrócenia jednej funkcji do stanu korzystającego z funkcji w mctools i powinno być już dobrze. Dalszy postęp prac jest uzależniony od dostępności czasu (a może go być mało, ale wcale nie musi). Aktualny kod dostępny na repo w branchu "mover in c++".
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Cesky Kretek w 21 Października 2016, 11:06:48
Czy dostęp do źródeł przepisanych na C++ będzie (bądź jest) ogólnodostępny jak w przypadku starych źródeł?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 21 Października 2016, 11:12:35
Jest dostępny ogólnie: github.com/firleju/maszyna

  Dodano: 21 Października 2016, 11:13:30
Zaznaczam, że w obecnej chwili projektu nie da się skompilować ze względu na nieskończone zmiany.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Cesky Kretek w 21 Października 2016, 15:11:35
Spoko, zastanawiam się czy kod C++ nie lepiej żeby był na chwilę obecną dostępny tylko dla developerów pracujących nad nimi.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 21 Października 2016, 19:12:32
To nie ma znaczenia dla mnie. Oszem, mogę przestać wrzucać następne wersje i zrobić sobie jakieś chwilowe repo na bitbucket, ale nie wiem czy jest sens. Oficjalne repo jest gdzie indziej, a prywatne repa na githubie są płatne niestety.

  Dodano: 25 Października 2016, 09:16:48
Z placu boju: powoli zaczyna kompilować się większość plików. W tej chwili drążę DynamicObject. Nie uda mi się na pewno przy tym podejściu wyrzucić wszystkich zależności od STL Borlanda. Najpierw zbudowanie projektu i poprawa wszystkich błędów, które na pewno się objawią. Pamiętam też o błędach w rozkładzie jazdy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 25 Października 2016, 17:51:42
Nie wiem co miałoby na celu zamykanie źródła. Repo na Gicie i tak ma prawa zapisu tylko dla autora, reszta z tego co wiem może co najwyżej wysłać pull request albo rozwijać swojego forka. W sumie im więcej osób zobaczy kod tym lepiej (bo może przykładowo błąd wyłapać), ale znając życie mało kto zagląda. Z tego co wiem nawet niektóre komercyjne projekty są Open Source, właśnie ze względu na większą szansę wyłapania błędów. Co do forkowania - IMHO strata czasu. No chyba, że się potem połączy to jakoś.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 25 Października 2016, 22:06:46
W tej chwili flow wygląda tak, że Stele ma forka, wysyła do mnie PullRequest, ja go akceptuję. Po jakimś czasie robię PullRequest to głównego repo. Nikt inny nic nie wysyła, więc się nie martwię specjalnie.

  Dodano: 26 Października 2016, 08:06:19
Przeszedłem z DynamicObject na TMoverParamters. Ubawiłem się jak zacząłem poprawiać funkcję w związku z przejściem na std::string i stwierdziłem, że Q napisał niektóre funkcje raz jeszcze.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 26 Października 2016, 22:11:19
... zastanawiam się czy kod C++ nie lepiej żeby był na chwilę obecną dostępny tylko dla developerów pracujących nad nimi.
Skad taki pomysl? Prosze nie odpowiadac, pytanie jest czysto retoryczne. Schowanie zrodel juz raz sklocilo uzytkownikow forum, to chyba jest jakas nauczka. Jestem za tym, aby wszelkie propozycje solidnie uzasadniac.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Cesky Kretek w 27 Października 2016, 00:28:27
Wiem, sam przecież byłem i dalej jestem za otwartymi źródłami ale w formie końcowej (działającej). Na chwilę obecną skoro są przepisywane pojedyncze funkcje tak naprawdę można odwalić czarną robotę a ktoś skorzysta z gotowych rozwiązań - co innego gdy mamy już działającą np. wersję 1.0. Jeżeli uważacie że nie ma to sensu to nie ma sprawy, to była tylko luźna propozycja.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 27 Października 2016, 09:03:35
Moje repo na githubie jest robocze. Oficjalne, działające, wersje są na innym koncie (możemy go nazwać oficjalnym). Nie widzę sensu chować tych prac bo i tak nikt z nich nie skorzysta, bo się nie da tego skompilować obecnie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: El Mecánico w 27 Października 2016, 17:37:38
@Firlej, a czy na obecnym etapie dało by się już "odpiąć" sterowanie pojazdem od klawiatury?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 27 Października 2016, 19:34:34
Szczerze powiedziawszy to nie wiem. Sterowanie jest bodajże zaszyte gdzieś w kodzie przy pomocy skanowania wejścia. Klawiaturę trzeba będzie zostawić i to jest pytanie jak to zrobić wtedy inaczej, a raczej jak wprowadzić alternatywę.

  Dodano: 28 Października 2016, 08:18:53
Prace idą do przodu. W tej chwili jestem na RealSound gdzie trzeba zmienić "tylko" char* na const char* ;) Tak zupełnie przy okazji wymuszam poprawne tworzenie tych obiektów poprzez stworzenie konstruktora. Wkurza mnie jak nie wiem stare podejście: najpierw tworzymy klasę a potem ręcznie dopisujemy zmienne więc są one publiczne tylko z tej okazji. Fajne miejsce żeby mieć wysypy jak czegoś zapomnisz dopisać.
Muszę niestety stwierdzić, że kod będzie można użyć jako całość albo w ogóle, gdyż jest za dużo zmian. Coś jak ze zmianami Q z zeszłego roku.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: adamst w 28 Października 2016, 10:17:12
Szczerze powiedziawszy to nie wiem. Sterowanie jest bodajże zaszyte gdzieś w kodzie przy pomocy skanowania wejścia. Klawiaturę trzeba będzie zostawić i to jest pytanie jak to zrobić wtedy inaczej, a raczej jak wprowadzić alternatywę.

Osobiście widziałbym mechanizm takiego rodzaju, że w trakcie skanowania wejścia naciśnięcie/zwolnienie klawisza generuje jakieś tam komunikaty w rodzaju "KeyXXXOn/KeyXXXOff", natomiast ich powiązanie z konkretnymi funkcjami pojazdu dokonywałoby się np z poziomu mmd.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 28 Października 2016, 18:14:01
To już prędzej trzeba zrobić klasę bazową, która ma pewne API na zbieranie poleceń ze świata zewnętrznego. Wtedy możemy pisać osobne klasy, które np. będą potomne i w zależności od tego jakie dane będą zbierać będą przetwarzać na ustalone kody poleceń. W tej chwili wielokrotne parsowanie stringów (bo tak przesyłane są polecenia między modułami) może nie jest krytycznym elementem do natychmiastowej optymalizacji, ale zdecydowanie nie jest eleganckim rozwiązaniem, które pozwala na różną rozbudowę funkcjonalności (nie ma np. wspólnej bazy komend i trzeba ręcznie wpisywać te samy nazwy wielokrotnie).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: El Mecánico w 28 Października 2016, 19:59:30
Dokładnie to potrzebujemy czegoś, co poprzez klawiaturę będzie oddziaływało TYLKO na elementy które mechanik może obsługiwać w kabinie. Dalej, między kabinę i fizykę, wpinamy sterowanie w LD. Interfejsy najlepiej zrobić na vector<bool>, bo bit na styk jest wystarczający.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 30 Października 2016, 21:39:53
Tak myślę, że powinien być zestaw modułów zbierających wejścia z rożnych interfejsów i współdziałający z jednym modułem który już bezpośrednio pracuje z elementami exe. Wtedy można podpinać różne urządzenia jednocześnie. Komunikacja za pomocą zdefiniowanego API. Czy moduł współpracujący wewnętrzny będzie zmieniał zmienne dla LD czy robił coś innego to już sprawa wtórna.

  Dodano: 31 Października 2016, 09:19:44
Dzisiaj rano udało się zbudować projekt. Niestety nie da się obecnie uruchomić gdyż wyrzuca błąd dostępu do pamięci ale debugger nie pokazuje w którym miejscu. Jest także 3k warningów co może mieć przyczynę. Może ktoś mi wytłumaczy czemu zmienna globalna inicjowana w nagłówku wg kompilatora jest generowana w każdym pliku cpp który includuje ten nagłówek pomimo ifndef? Być może wyrzuca właśnie tutaj.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 31 Października 2016, 12:39:16
Może ktoś mi wytłumaczy czemu zmienna globalna inicjowana w nagłówku wg kompilatora jest generowana w każdym pliku cpp który includuje ten nagłówek pomimo ifndef? Być może wyrzuca właśnie tutaj.
ifndef zabezpiecza tylko przed uzyciem tego samego naglowka po kilka razy przy kompilowaniu jednego .cpp, ale nie powstrzymuje kompilatora przed wlaczeniem tego naglowka i wygenerowaniem kopii zmiennej dla kazdego .cpp z osobna. A potem linker wariuje bo nagle ma cala kope kandydatow na zmienna globalna, zamiast jednej sztuki.

Od takich rzeczy jest extern tzn. w plikach .h robisz np.

extern std::string foo;

a potem w jednym tylko .cpp ma miejsce wygenerowanie zmiennej czyli

std::string foo = "bar";

i linker to wszystko sobie wtedy posklada.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 31 Października 2016, 14:16:40
No tak właśnie myślałem, że będę musiał przez extern pójść. Jak będę wracał do domciu to skompiluję raz jeszcze i zobaczymy czy zabangla. Ofkoz są błędy, gdyż nie udało się poprawnie załadować charakterystyk, ale mimo wszystko jednak nie powinien się na tym wysypać.

  Dodano: 01 Listopada 2016, 06:42:11
Z placu boju: Exe się buduje. Nie ma warningów, aczkolwiek kompilator stał się bardo niestabilny i co jakiś czas muszę kasować wszystkie pliki .obj. Wyrzuca błąd, który jak to producent określa "nie powinien występować w praktyce". W tej chwili poprawiam nowe funkcje ładowania plików charakterystyk napisane przez Q.

  Dodano: 02 Listopada 2016, 08:03:50
Mam ochotę zabić Borlanda. Otóż okazuje się, że wszystkie zmienne typu bool, jeśli ich nie zainicjujesz otwarcie, domyślnie ustawione są na true. No i całość trzeba wziąć i dopisać otwarcie. Aaaaa....
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: El Mecánico w 02 Listopada 2016, 19:46:37
Heh, kompilatory GNU domyślnie nie ustawiają żadnych wartości dla typów podstawowych, tak więc są tam wartości losowe, jakie akurat zostały w RAM w chwili rezerwowania adresu...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 02 Listopada 2016, 20:21:28
Inicjalizacja zmiennych w sumie powinna byc w kodzie od poczatku, wlasnie dlatego ze w standardzie nie ma gwarantowanych wartosci domyslnych. Pewnie warto by przy przenosinach sprawdzic wszystko pod tym katem, bo wiecej takich kwiatkow moze wyskoczyc...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 02 Listopada 2016, 21:37:58
Pierwsze przykazanie programisty maszyny: Będę używał konstruktora zgodnie z jego przeznaczeniem, a nie funkcji Init, którą muszę ręcznie uruchomić później.

  Dodano: 04 Listopada 2016, 21:05:36
Witam. Stana na 04.11: wyrzucam funkcję Init z wszystkich klas hamulców (jak się bawić to na całego) i dostosowuję do tego inicjację DynamicObject. Idzie nieźle.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 05 Listopada 2016, 11:59:06
Możesz dać namiary na repo, gdzie puszczasz commity?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 05 Listopada 2016, 20:11:12
github.com/firleju/maszyna - branch mover_in_c++. Nie jest kompilowalne w czymś innym niż Borland jak na razie, gdyż jeszcze korzysta w niektórych miejscach z STL Borlanda oraz w paru miejscach z parsera delphi.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 05 Listopada 2016, 21:30:56
Dzięki. Zapewne planujesz większe porządki w kodzie dopiero po przeniesieniu?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 06 Listopada 2016, 09:55:33
Najpierw chcę zejść z Borlanda. Potem dobrze będzie zejść z bezpośrednich odwołań do konkretnych windowsowych API (np uchwyt do okna, dźwięki). Tutaj są najróżniejsze opcje i niczego nie przesądzam. Kiedyś myślałem nad użyciem Qt a Shax do dźwięku proponował OpenAL, ale to może być cokolwiek innego co pozwoli skompilować exe na inne systemy niż windows i ewentualnie obejść problemy jakie mamy w tej chwili (np. obsługa różnych formatów plików dźwiękowych).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 06 Listopada 2016, 12:20:42
Próbowałem zrobić większą swobodę wava przy pomocy konkretnych windowsowych api ostatnio, ale działało kompletnie inaczej, niż w dokumentacji. :P
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 08 Listopada 2016, 07:40:43
Przeszedłem inicjację hamulców. Teraz sypie się na animacji pantografów. Kaj czort? Jakim prawem, nic tam nie tykałem. Ehhh...

  Dodano: 08 Listopada 2016, 18:15:24
Znalazłem przyczynę wywałki. Źle użyłem funkcji sprawdzającej długość wczytanego pliku i w związku z tym nie parsował w ogóle plików mmd. Exe nie sprawdza czy ten plik został poprawnie sparsowany, co niczym samym w sobie nie szkodzi. Tylko, że w konstruktorze DynamicObject domyślnym ustawieniem liczby pooszczególnych obiektów definiowanych po słowie "animations" nie było 0 tylko maksimum. W związku z czym pomimo nie parsowania tego pliku exe wierzyło, że coś tam jest i próbowało się odwołać do tablicy, która była NULL.

  Dodano: 08 Listopada 2016, 19:38:39
Pierwsze koty za płoty. Exe wstało poprawnie i nawet wyświetliło wszystko poprawnie. Szkoda tylko, że nie działa podnoszenie pantografów...

  Dodano: 08 Listopada 2016, 21:34:15
Wygląda, że działa. Szkoda, że dzieci mi popsuły klawiaturę i sobie nie pojeżdżę. Teraz jeszcze poprawka na pusty rozkład i do testów.

  Dodano: 09 Listopada 2016, 19:49:10
Powinno już ładować pusty rozkład. Testowe exe w załączniku. Może mnie ktoś oświecić czemu uruchomienie w debugerze Borlanda powoduje, że nie wyświetla obrazu i jakby się zawiesza w przesuwaniu składu po torze, a przy normalnym uruchomieniu wszystko jest ok? Dawniej coś takiego mi się działo od czasu do czasu, ale najczęściej uruchomienie ponowne pomagało. Teraz nic nie pomaga i nie jestem w stanie uruchomić żadnej trasy w trybie AI, żeby złapać ewentualne wysypy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 09 Listopada 2016, 23:56:20
Nie wiem czy to Twoja klawiatura, ale ja widzę, że hamulce nie działają w ogóle. Stan początkowy jest dziwny: hasler tyka i pokazuje między 15-20km/h. Wskazówka się buja. Nie startuję we właściwej kabinie. Da się włączyć rozrząd, podnieść patyki, a nawet włączyć przetwornicę i sprężarkę. Ale po nabiciu ciśnienia jakiekolwiek manipulacje kranem hamulca nic nie dają. Wcisnąłem 2x numlock i kran zaczął działać, tzn można nim kręcić, ale bez żadnego efektu na PG. Spróbowałem użyć odluźniacza, ale spuścił mi ciśnienie ze zbiornika głównego, a nie cylindrów hamulcowych. Oczywiście po spuszczeniu powietrza z ZG patyki opadają.

Coś jest z wyświetlaniem grafiki - u mnie Alt+Tab powoduje wyczyszczenie ekranu ładowania który staje się czarny, widać jeden napis na nim tylko. Symulacja się uruchamia, ale wiesza przykładowo po zmianie kabiny.

I jeszcze jedno - niektóre błędy w plikach scenerii / dynamic powodują wyświetlenie dialogu systemowego wymagającego przejścia do niego przez Alt+Tab i kliknięcia OK. Jakbyś mógł to usunąć i zastąpić po prostu zapisaniem linijki w logu byłoby super.

Testowałem na TD i Zwierzyniec Transport.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 10 Listopada 2016, 08:55:34
Czyli jednak muszę kupić sobie klawiaturę, żeby więcej potestować. Ostatnia jaką kupiłem była kiepska więc mi nie żal, że ją dzieci uszkodziły. Te okna błędów były już wcześniej, jeśli dobrze widziałem w kodzie, ale bez problemów można to usunąć. Czyli walczymy dalej.

  Dodano: 10 Listopada 2016, 08:58:30
P.S. Dzisiaj już debugger działa. It's a kind of magic, magiiiiiccccc.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 10 Listopada 2016, 11:49:25
Ja potwierdzę opisane błędy przez @HTD. Dodam jeszcze, że w trybie testowym nie udało mi się odluźnić lokomotywy. W trybie normalnym pojechałem, wygląda na to jakby nie było fizyki. Nie ma też pozycji nastawnika, działa jakbym sterował kolejką elektryczną.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 10 Listopada 2016, 13:44:39
Hamulce to wiem gdzie prawdopodobnie jest błąd. Tam były tabele które w Pascalu mają ujemne indeksy i jak widać nie udało mi się tego porządnie odtworzyć w c++.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 10 Listopada 2016, 18:59:18
Taka drobna sugestia jeszcze, jakby to było trywialne (w innym wypadku szkoda czasu): jak się symek ładuje, wyświetla na ekranie startowym napisy co się ładuje, ale wygląda na to, że ten wątek jest odcięty podczas ładowania, dlatego ten ekran się nie odświeża. Przy przełączeniu via Alt+Tab czasem coś się dzieje z tym ekranem, napisy się aktualizują. A czasem nie. W wersji skonwertowanej widać, że ekran wtedy próbuje się odświeżyć, ale nawet tła nie rysuje. Zgaduję, że brakuje przepuszczania komunikatów przez to okno przed startem symulatora. Z innych drobiazgów - byłoby super czadowo, gdyby plik log.txt był otwierany w trybie współdzielenia odczytu. W tym momencie inna aplikacja mogłaby go czytać podczas pracy symulatora. To samo odnośnie plików w physicslog, chociaż akurat tych nie sprawdzałem. Wydaje mi się, że wystarczy tylko ustawić 1 flagę przy otwieraniu. To blokowanie ekranu startowego i logów istnieje oczywiście w obecnej wersji, ale jeśli przy przepisywaniu można to szybko zmienić, to już nowa wersja mogłaby zyskać ciekawe właściwości. Ogólnie to jest tak, że plik log.txt mogę odczytać wyłącznie po zamknięciu symka, wcześniej system widzi go jako plik o długości 0.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 10 Listopada 2016, 19:19:22
Cytuj
Ogólnie to jest tak, że plik log.txt mogę odczytać wyłącznie po zamknięciu symka, wcześniej system widzi go jako plik o długości 0.
To ciekawe co piszesz, jakiś czas temu należało zamknąć i powtórnie otworzyć czytany tekst, aby zaktualizować dopisany przez aplikację tekst. Nigdy nie miałem problemu z czytaniem pliku log.txt na bieżąco w trakcie symulacji.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 11 Listopada 2016, 09:55:55
Walczę z hamulcami narazie. Loga nie będę ruszał. Cały czas jest tak jak był - w zasadzie po każdym zdarzeniu następuje zapisanie od pliku.

  Dodano: 14 Listopada 2016, 08:48:13
Do d... Zafiksowałem się na jednym rozwiązaniu co mi utrudniło robotę. Sprawdziłem alternatywę i wyszło, że trafienie w std::map przy 12 pozycjach wynosi O(1,07) zamiast O(1) przy zwykłej tablicy. Natomiast przy 8 pozycjach (dla kranu FV4aM) wynosi O(0,9) ;) A użycie std::map rozwiązuje większość problemów i jest "kompatybilne" z ujemnymi indeksacjami tablic w Pascalu.

  Dodano: 14 Listopada 2016, 23:33:09
Coś jest ostro zwalone. Hamulec pomocniczy sam się zaciąga i za ChRL nie chce ustawić się w innej pozycji. Główny w ogóle nie reaguje. A Hasler pokazuje jakąś losową wartość około 18 i lekko drga. Czyli cały mover jest do solidnego przejrzenia. Najpierw to wszystko uruchomić, potem dopiero zabawa w optymalizację.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Listopada 2016, 07:25:39
Do d... Zafiksowałem się na jednym rozwiązaniu co mi utrudniło robotę. Sprawdziłem alternatywę i wyszło, że trafienie w std::map przy 12 pozycjach wynosi O(1,07) zamiast O(1) przy zwykłej tablicy. Natomiast przy 8 pozycjach (dla kranu FV4aM) wynosi O(0,9) ;) A użycie std::map rozwiązuje większość problemów i jest "kompatybilne" z ujemnymi indeksacjami tablic w Pascalu.
std::map jest implementowana z uzyciem red-black tree, stad jest wolniejsza. Jesli potrzebujesz O(1) uzyj std::unordered_map (http://en.cppreference.com/w/cpp/container/unordered_map)  Interface jest o ile dobrze pamietam taki sam, wiec to tylko zmiana kontenera, a unordered_map jest oparta o hash, wiec z reguly da ci linearny czas dostepu.

(poza tym najpierw robi sie implementacje, a optymalizacje to ewentualnie i po testach ktore wykaza ze jest tu w ogole problem do usuniecia ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 16 Listopada 2016, 07:52:22
Panie, Panie. Kompiluje na Borlandzie 5.02 (rok. prod. 2000). Nie na VS2013. Żadnego unordered_map nie ma.

  Dodano: 16 Listopada 2016, 08:02:38
P.S.
W tej chwili nie ma żadnego profilera, na którym można sprawdzić jak się kod zachowuje. Mam nadzieję, że jak się uwolnimy od Borlanda to uda się takie narzędzie wprowadzić i zobaczymy co zajmuje nam dużo czasu, a co nie jest problemem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 16 Listopada 2016, 16:38:43
A to ja przepraszam :)  Myslalem, ze wszystkie zaleglosci z Borlanda juz sa wyprute.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 16 Listopada 2016, 21:42:13
Sprawdzam co się porobiło z moverem, że nie chce toto działać. Potem zostaje już "tylko" główny parser QueryParserComp. Jak on pójdzie to będzie już z górki.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 16 Listopada 2016, 22:08:11
A nie da sie zastapic Query na cParser, zamiast przepisywac Query? W sumie oba robia to samo, tyle ze jeden sie kompiluje poza Borlandem a drugi nie ;) Z tego co widze w kodzie to Query jest uzywany tylko do wyciagania tokenow jeden po drugim ze stringa, wiec nawet nic dopisywac nie trzeba, co najwyzej pozmieniac odwolania.

troche czytelniej by sie tez zrobilo. np. zamiast
(w geom.cpp)
        tf = Parser->GetNextSymbol().ToDouble();
        TempVerts[i].Point.x = tf;
        tf = Parser->GetNextSymbol().ToDouble();
        TempVerts[i].Point.y = tf;
        tf = Parser->GetNextSymbol().ToDouble();
        TempVerts[i].Point.z = tf;
        tf = Parser->GetNextSymbol().ToDouble();
        TempVerts[i].Normal.x = tf;
        tf = Parser->GetNextSymbol().ToDouble();
        TempVerts[i].Normal.y = tf;
        tf = Parser->GetNextSymbol().ToDouble();
        TempVerts[i].Normal.z = tf;

moglo by wejsc
Parser->getTokens( 6, false );
*Parser
>> TempVerts[i].Point.x
>> TempVerts[i].Point.y
>> TempVerts[i].Point.z
>> TempVerts[i].Normal.x
>> TempVerts[i].Normal.y
>> TempVerts[i].Normal.z;

itp. Latwiej wtedy wylapac literowki i inne pluskwy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 17 Listopada 2016, 08:22:19
Byłbym bardzo wdzięczny jeśli byś chciał się tym zająć. Ta zmiana powinna być możliwa do zrobienia niezależnie od moich prac nad konwersją. Ogólnie sam cParser jest określony jako mniej wydajny niż Query. Da się to zoptymalizować, gdyż w tej chwili robi alokację stringa z każdym pobraniem znaku. Jeśliby robić tą alokację na każdym słowie myślę, że byłoby zdecydowanie szybciej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 17 Listopada 2016, 16:59:36
Da się to zoptymalizować, gdyż w tej chwili robi alokację stringa z każdym pobraniem znaku. Jeśliby robić tą alokację na każdym słowie myślę, że byłoby zdecydowanie szybciej.
Hmm? Moze ja zle patrze, ale w zrodlach tego nie widze... alokacja jest robiona raz na slowo:

std::string cParser::readToken(bool ToLower, const char *Break)
{
    std::string token = "";

(...)

    char c;
    do
    {
        while (mStream->peek() != EOF && strchr(Break, c = mStream->get()) == NULL)
        {
            if (ToLower)
                c = tolower(c);
            token += c;
            if (trimComments(token)) // don't glue together words separated with comment
                break;
        }
    } while (token == "" && mStream->peek() != EOF); // double check to deal with trailing spaces
edit: jesli masz na mysli, ze bedzie miala miejsce re-alokacja przy token += c, to wiekszosci mozna uniknac przez dodanie
    std::string token = "";
    token.reserve(16); // should be enough in most cases
a jeszcze lepiej wrzucic token do naglowka jako member, i tylko kasowac zawartosc w readToken().

Ogolnie rzecz biorac akurat tutaj wydajnoscia bym sie specjalnie nie przejmowal -- parser jest uzywany glownie do wczytywania konfiguracji podczas ladowania itp, wiec waskim gardlem i tak bedzie przede wszystkim odczyt z dysku.

Co do zajecia sie, nie mam niestety Borlanda wiec raczej nie jestem w stanie -- poprawki musialbym robic "na sucho" bez mozliwosci sprawdzenia czegokolwiek. Ale z tego co widze, to prowizorycznie wystaczyloby dopisac do cParsera:
std::string GetNextSymbol() {

std::string token;
getToken( token );
return token;
}
I tak z 90% istniejacego kodu lyknie zwykla zamiane "TQueryParserComp" na "cParser" (nie bedzie to najbardziej optymalne, ale bedzie dzialac)
edit 2: a nie, czekaj, nie bedzie, bo chyba nie masz zamiennikow ToDouble() itp dla zwyklego std::string? czyli i tak trzeba bedzie pozmieniac odwolania do konwersji, bleh.

Pozostale 10% to zmiana wywolan typu
    TQueryParserComp *Parser;
    Parser = new TQueryParserComp(NULL);
    Parser->TextToParse = str;
    Parser->First();
na
    cParser *Parser;
    Parser = new cParser( str );
i juz. Jak sie skompiluje i pojdzie, to wtedy mozna sie bawic w zastapienie istniejacych odwolan do GetNextSymbol() na bardziej eleganckie itp.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 17 Listopada 2016, 20:41:35
Tak, chodziło mi właśnie o token += c. To jest kod jaki został podany za przykład na realokację za każdym wywołaniem. Wiesz, niektórzy tutaj napisali własne formaty plików, żeby przyspieszyć ładowanie. Masz różnice między 10min a 5min. Odwołaniami do ToDouble() nie ma co się przejmować. Albo zrobię klasę potomną do std::stringa z samymi funkcjami inline, albo po prostu pozmieniam. W końcu już w tylu miejscach pozmieniałem, że to nie problem jest.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 18 Listopada 2016, 00:59:31
Tak, chodziło mi właśnie o token += c. To jest kod jaki został podany za przykład na realokację za każdym wywołaniem.
Ah, ok. Akurat z tym to roznie bywa (dlatego nie rzucilo mi sie w oczy od razu), bo co prawda w standardzie tego nie ma, ale nowsze implementacje czesto stosuja cos, co nazywaja "Small String Optimisation", taki prywatny maly bufor wbudowany w string, na ktorym operuja najpierw, zeby uniknac alokacji. A przy wiekszych stringach re-alokacja tez jest wiekszymi kawalkami, zamiast co znak. Tak czy owak, z dodanym reserve() nie powinno byc tutaj problemow, nawet przy starszym kompilatorze.

edit: tutaj jest fajny artykul pokazujacy jak wyglada SSO w roznych kompilatorach: http://info.prelert.com/blog/cpp-stdstring-implementations
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 22 Listopada 2016, 09:31:29
Z tego co poczytałem to Borland powinien mieć zaimplementowane Copy-on-Write wraz z powiększaniem stringa o troszkę więcej niż alokacja. Więc teoretycznie im dłuższy string tym mniej powinno być do niego alokacji przy kolejnym dodawaniu znaków. Ale nawet patrząc teoretycznie to przy mnożniku 1.5 i średniej liczbie znaków koło 6 to liczba alokacji wynosi: 1 - alokowanie pustego stringa, 2 - pierwszy znak + drugi znak, 3 - 3,4,5 znak, 4 - 6 - 9 znak. To chyba niezbyt wydajne, żeby robić alokację 4-krotnie przy liczbie znaków 6-9? To reserve faktycznie powinno pomóc.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 22 Listopada 2016, 12:43:13
Włos mi się zjeżył na głowie jak przeczytałem o przydzielaniu pamięci dla pojedynczych znaków. Zgroza. (No chyba, że czegoś tu nie wiem).

Od jakiegoś czasu używam prywatnie parsera formatu MaSzyny do swoich celów (robię nowy, lepszy starter) - działa na zasadzie FSM-Lexer/Parser. Na razie wszystko mu jedno co jest w tych plikach, działa jako iterator, czyli od podpiętego modułu zależy, co do czego będzie parsował. Starter interesuje tylko niewielki podzbiór, więc ten podzbiór jest czytany, cała reszta jest ignorowana, w momencie jak przestanę ją ignorować, nie będą mnie obchodzić stringi w skryptach - dostanę gotowe obiekty. Przypuśćmy, że mam obiekt składający się po prostu ze współrzędnych X, Y, Z. Czyli strukturę z 3 double. Funkcja parsera "ParseVector()" pobierze 3 tokeny, sparsuje 3 stringi jako double i zapisze w strukturze. Do tego jest jeszcze parsowanie kolorów RGB, ścieżek do plików i czasów.

Jak tam to działa? Masz jeden blok pamięci z całym skryptem. Lexer analizuje za każdym krokiem 1 do 2 znaków skryptu. Znaczenie znaku jest interpretowane w zależności od stanu (int). Stan zmienia się w zależności od napotkanych znaków. Szybciej się nie da. Pierwsza faza (analiza leksykalna) rozdziela logicznie skrypt na "encje" (powiedzmy znaczące słowa), znaki rozdzielające i komentarze. Wynikiem tej fazy są wyłącznie offsety i długości w skrypcie. Biorąc "string" z takiego tokena z góry znasz jego długość. Dodatkowo każdy taki string możesz praktycznie zapisać dokładnie w tym samym przydzielonym 1KB (dałbym nawet 64KB, żeby zapas był). Oczywiście nie unikniesz "ToDouble()", ale przynajmniej nie będzie to zużywać bez porównania większego czasu na przydzielanie pamięci. Z doświadczenia wiem, że mało rzeczy jest wolniejszych od przydzielania. Jak pętla ma przejść po 100MB danych, w środku nie może być praktycznie żadnego przydzielania.

Gdybym potrzebował wydajności (optymalizacja czasu ładowania) - zapisałbym wynikowe obiekty jako binarki. Przykładowo "nazwa.scm => nazwa.bin", albo "katalog/nazwa.scm => "cache/nazwa.bin". I po krzyku. Pierwsze uruchomienie - ładowanie 5 minut, drugie uruchomienie ładowanie 10 sekund. Zastanowiłbym się nawet nad przepuszczeniem strumienia cache przez kompresor. Być może byłoby to szybsze niż ładowanie dłuższych plików nieskompresowanych.

Do tego nie trzeba n "własnych formatów". Dokładnie jeden ogólny. Wynikający ze struktury binarnej obiektu. Format definiuje struktura. Serializację gotowy serializer. Broń boziu pisać własny, szkoda czasu. Pierwsza faza ładuje, parsuje i cache-uje pliki. Dalej w kodzie nie powinno być już kompletnie nic związanego z parsowaniem. Koniecznie osobne przebiegi. Nie "parsuj linię, załaduj teksturę, parsuj kolejną", tylko "załaduj wszystkie skrypty (łącznie z include), przejdź do ładowania pozostałych zasobów". Mam nadzieję, że rozkłady jazdy mają wewnętrznie jakąś sensowną binarną reprezentację, bo parsowanie tych koszmarków "na żywca" musi być bardzo wolne.

Dla optymizacji można by pokusić się o własną wersję "ToDouble" - ignorującą masę przypadków brzegowych jak różne formaty liczb. Ale to słaba opcja, lepiej dopuścić w skryptach bardziej "poluzowaną" notację kosztem wydajności, a zapisywać binarki w cache. Do zrobienia: 1 ogólny format cache, testowanie aktualności przez porównanie dat plików.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 22 Listopada 2016, 14:51:53
Włos mi się zjeżył na głowie jak przeczytałem o przydzielaniu pamięci dla pojedynczych znaków. Zgroza. (No chyba, że czegoś tu nie wiem).
Raczej niezrozumienie jak dziala std::string. Zadna normalna/rozsadna implementacja nie przydziela pamieci dla pojedynczych znakow z osobna, nie ma co panikowac.

Dla zaspokojenia ciekawosci zrobilem sobie nastepujacy test:
// start
cParser parser( scenefile, cParser::buffer_FILE, subpath );
std::string token;
do {
token = "";
parser.getTokens();
parser >> token;

} while(token != "" );
// stop
i przepuscilem przez niego scenery/quarkmce.scn (w sumie na oko jakies 10mb tekstu) Calosc zajela ok. 1.7 sek, przy odczycie z normalnego, starego HDD. Wiec akurat nad wydajnoscia parsera bym sie nie spinal -- raczej nie jest on odpowiedzialny za ladowanie scen w 5-10 minut, i naweg gdyby Borland byl jakims sposobem kilka razy szybszy (nie moge skompilowac/sprawdzic) to i tak mowimy tu o roznicy wielkosci ulamka sekundy, w procesie ktory wykonuje sie raz na uruchomienie.

(zeby bylo smieszniej, przeniesienie zmiennej do naglowka itp nie ma realnego wplywu na predkosci testu; podejrzewam ze najwolniejszym elementem jest, tak jak mozna bylo sie spodziewac, samo ladowanie zawartosci plikow z dysku)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: El Mecánico w 22 Listopada 2016, 16:24:31
A czy aby wąskim gardłem tutaj nie będzie przeskakiwanie do funkcji ładujących elementy scenerii i czekanie za każdym razem na ich zakończenie? IMO, ładowanie elementów mogło by spokojnie latać w osobnych wątkach i operować na obiektach przygotowywanych z już określonym rozmiarem i zarezerwowaną pamięcią przed wywołaniem funkcji ładującej. Komunikacja przez semafory.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 22 Listopada 2016, 18:55:28
Jak najbardziej, z tym ze przy programowaniu wielowatkowym znacznie latwiej cos schrzanic niz zwykle, wiec troche trzeba przy tym uwazac. Dobrze byloby pewnie najpierw naprawic i uporzadkowac to, co jest, rozdzielic na jakies sensowne moduly i takie tam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 22 Listopada 2016, 19:32:52
Większym problemem przy parsowaniu pliku scenerii jest to, ze mamy mnóstwo braku trafień w cache, a związane z brakiem parsowania całego pliku naraz  a dopiero potem inicjacja obiektów. W tej chwili ładujesz plik tekstowy do zmiennej, coś na niej czytasz, robisz mnóstwo innych operacji przy okazji i co chwila nie trafiasz w cache procesora. Jak wracasz do parsowanego tekstu to już go w cache znowu nie ma i musisz go ściągać z pamięci głównej. Tylko, że nie wiem czy jest sens rozgrzebywać ładowanie scenerii kiedy działa. Chociaż z drugiej strony ładowanie kaliskiej na moim kompie to jakieś 20 min, więc może jest o co walczyć.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 22 Listopada 2016, 20:02:02
IMHO jest sens, ale nie teraz. Na początek potrzebna byłaby wersja exe identyczna z bieżącą oficjalną, tyle, że już bez Borlanda. To byłby dobry punkt wyjścia. Gdyby robić optymalizację exe przedtem - ten etap, kamień milowy pewnie mocno by się opóźnił w czasie. A tak, zanim się ruszy optymalizacje - można by poprawić bugi, czy dodać kilka mocno usprawniających symulację usprawnień. No i zawsze lepiej chyba optymalizować już co w 100% działa, nie?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: El Mecánico w 22 Listopada 2016, 20:14:40
Oczywiście, że jest o co walczyć. Sama konwersja z jednego systemu programistycznego do innego już sporo bałaganu narobiła, więc równolegle montowanie novum to tego (nowy branch) jest odpowiednim momentem.

Zastanawiam się nad jeszcze jednym rozwiązaniem problema: dla ładowania jako tako nie jest problemem zapis jednego elementu skryptu scenerii w jednej linii, więc... "zwijamy" wiersze, tniemy plik przy ładowaniu linijka po linijce, i w takiej kolejce popychamy do parsera. Kolejki obiektów na ogół nie są w całości cofane z cache, przynajmniej trochę z góry powinno zostać. Teraz dopiero przystępujemy do zasadniczej obróbki materiału. Rezerwujemy pamięć pod obiekt i zasadniczego konstruktora albo puszczamy w odrębny wątek, albo jeśli nie chcemy się w wielowątkowość bawić (shame!) czekamy aż konstruktor skończy i zgłosi gotowość.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 22 Listopada 2016, 21:45:17
IMHO jest sens, ale nie teraz. Na początek potrzebna byłaby wersja exe identyczna z bieżącą oficjalną, tyle, że już bez Borlanda. To byłby dobry punkt wyjścia.
Tez wydaje mi sie, ze najrozsadniej chyba byloby skupic sie najpierw na wykopaniu Borlanda do konca, a jak juz sie da skompilowac rezultat gdzie indziej, to mozna go puscic przez profiler i na podstawie tego robic optymalizacje tego, co faktycznie obciaza proces.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 23 Listopada 2016, 00:01:05
Z mojego doświadczenia wrzucanie czasochłonnych rzeczy do konstruktorów jest średnim pomysłem. Nie, żeby się nie dało, ale w C# przykładowo standardem jest puszczanie takich rzeczy jako dajmy na to LoadAsync, co oczywiście odpala się w równoległych wątkach, a potem można poczekać aż wszystkie skończą, czy też dowolnie pokolejkować przykładowo semaforami.
Ale to daleki strzał, i wg mnie dość prosta rzecz do zrobienia. Nie ma się co bawić przy tym formacie w linie, dla formatu EOL, spacja, tab czy średnik znaczą dokładnie to samo. To powinien (jak ma być naprawdę szybko) robić lexer, od tego jest. Oczywiście może sobie chodzić szeregowo w łańcuszku z parserem, a może nawet równolegle, ale to już trochę zabawy z synchronizacją. Ważne, żeby dane były sparsowane ZANIM symulacja w ogóle odpali, parsowanie podczas symulacji jest oddawaniem cykli CPU za darmo. Warto je przeznaczyć na ciekawsze zadania.

ALE: z tego co widziałem, przy ładowaniu scenerii i tak 99% czasu wydaje się zajmować ładowanie tekstur. Reszta się u mnie ładuje w kilka sekund. No chyba, że zielone okienko kłamie. Tekstury ładują się tak długo, bo na długiej trasie może być ich naprawdę sporo. Może i nawet musi. Im więcej tym lepiej. Im większe tym lepiej. Może tylko niekoniecznie powinny ładować się wszystkie na raz. Co się stanie z silnikiem Fallout 4 gdy spróbujemy załadować kilka kilometrów kwadratowych na raz? Albo chociaż spróbujemy przemieścić się z prędkością maksymalną EP09? Wysypie się. Tzn nie do Windowsa, po prostu się okrutnie przytnie, zawiesi na chwilę, bo musi sobie dograć tekstury. Tego normalnie podczas gry nie widać (dogrywają się dynamicznie).

I prędzej czy później to będzie w MaSzynie też potrzebne. Sprawdzanie jakie obiekty są powiedzmy w promieniu 2km, i te mają się dograć. OK, na początek i tak będą się musiały wgrać wszystkie co wyświetlają się przy starcie, ale potem będzie dość czasu na dogranie. To musi być rzecz jasna opcja, bo na muzealnym sprzęcie by zacinało. Ale na współczesnych komputerach spokojnie wszystko nadąży.

Tylko oczywiście nie teraz. Teraz wylatuje Borland, potem będzie parę szybkich bugów do usunięcia. I parę potrzebnych ficzerów do dodania. Optymalizacja ładowania to będzie wisienka na torcie ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 23 Listopada 2016, 13:12:25
Z mojego doświadczenia brak inicjacji w konstruktorze zmiennych, do których odwołanie odbywa się przez wskaźnik prowadzi wprost do wysypów w dziwnych i nieoczekiwanych okolicznościach.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 23 Listopada 2016, 14:06:54
Z mojego doświadczenia brak inicjacji w konstruktorze zmiennych, do których odwołanie odbywa się przez wskaźnik prowadzi wprost do wysypów w dziwnych i nieoczekiwanych okolicznościach.
No, tak sie konczy proba odwolania do czegos co nie jest gotowe :)  Ale to nie znaczy ze trzeba caly process przygotowania modelu robic w konstruktorze. Konstruktor moze np oznaczyc obiekt jako 'niegotowy' (I albo odpalic proces ladowania/obrobki albo zostawic to dla managera) a reszta kodu jest wtedy tresowana zeby tego nie tykac dopoki flaga gotowosci nie jest przestawiona.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 23 Listopada 2016, 18:42:03
I to mi się podoba. Konstruktor powinien inicjować wszystko co da się zrobić natychmiast. Czyli wszystkie zmienne, ale już nie obiekty większe od 1kB, te powinny być ustawione na jakieś null-e i być inicjowane kiedy są potrzebne, względnie w jakimś osobnym wątku inicjacyjnym.

Te rzeczy można nawet robić od razu, tzn bez kombinowania z wątkami na początku, niech będą sobie w osobnej funkcji typu Init lub Load, i niech to się odpala zaraz po konstruktorze. Jak zabangla, to można wtedy kombinować z przeniesieniem tych wywołań w bardziej optymalne miejsce.

Gorzej, jeśli przy tworzeniu obiektów nie wszystko jest sparsowane, to już jest węzeł do rozplątania.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 24 Listopada 2016, 10:05:48
Tylko powiedz mi czym różni się Kontruktor(); Init(); od wrzucenie wszystkiego do Konstruktor() ? Ja miałem wysypy bo konstruktor nie tworzył jakichś obiektów i wskaźniki były na NULL (gdyż autor poprawki nie wywołał nigdzie Init() ). Wole stworzyć nowy obiekt z domyślnymi wartościami, ale nie bawić się w jego obróbkę, gdyż jeśli ktoś coś potem zawali to nie mamy niespodziewanych wysypów w dziwnych miejscach. Już nie mówiąc, o całej klasie TMoverParameters, którą trzeba rozbić na wszystkie występujące przypadki, a nie wrzucać do jednego worka wszystkich możliwych fizyk i potem mamy if-y włącznie z takimi kwiatkami jak if(dt_et22) coś tam coś tam else coś tam dla reszty.
Ale wracając do inicjacji obiektów, to w tej chwili ja wolę to mieć w konstruktorze i być pewnym, że się coś nie sypnie, aczkolwiek większość obiektów ma wydzieloną funkcję Init() tylko, że jest to dalsza część konstruktora tak naprawdę i nie można używać tych obiektów dopóki ona nie zostanie wywołana. Używać rozumiem pod pojęciem, że wywołanie zwróci błędne dane, ale nie wysypie programu na odwołaniu do NULL.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 24 Listopada 2016, 15:52:30
Powinno wyglądać docelowo tak: if (krowa.dane != null) krowa.Init(); Brak null-checka w miejscu, gdzie obiekt może być jeszcze niezaładowany to po prostu bug. Tzn na razie może zostać, ale lepiej to później poprawić.

Przy czym jestem przeciwnikiem wszelkich technik "ukrywania błędów". Ludzie poświęcają zadziwiająco dużo energii, żeby nie dopuścić do sypania się apki podczas działania, ale omijają szerokim łukiem rzeczywiste programowanie defensywne, czyli takie, gdzie sama poprawność konstrukcji uniemożliwia sypanie kodu.

Mało tego, jestem za taką konstrukcją, która jak najbardziej wywali wyjątek, zamiast po cichu obejdzie czy zignoruje. Masz twardy wysyp - to widzisz gdzie jest bug i możesz go poprawić. Ale możesz to ukryć w ten sposób, że część rzeczy będzie śmigać, a część kiedyś tam się wysypie, jak już wszyscy zapomną od czego. Myślę, że niektóre zmienne powinny być wręcz jawnie ustawione na null, żeby posypało się wszystko co tylko może. Dzięki temu można wyłapać te miejsca i poprawić. Jasne, że nie ma sensu dawać null-checka w jakiejś pętli mielącej coś pierdyliard razy, ale domyślam się, że problem jest wyłącznie przy uruchamianiu, jak symulator startuje wszystko jest wgrane i gotowe. Swoją drogą byłoby fajnie też, żeby do wersji dla userów dać kilka try / catch w kluczowych miejscach i wysyłać wyjątki do logu. Jak ktoś zaliczy wysyp, to będzie mógł przynajmniej wysłać co się złożyło.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 25 Listopada 2016, 07:27:53
Yyyy.... Wiesz, raz mi się sypało na braku kabiny. Tylko nikt nie wie czemu kabina usunięta i załadowana w tej samej funkcji i przypisana do wskaźnika w następnym cyklu wskaźnik był ustawiony na null a w następnym już był przypisany. W innym przypadku sypało na braku przypisania nazwy do PowerSource w funkcji logowania przeciążenia stacji. Okazało się, że nazwa była przypisywana ręcznie do klasy (do zmiennej public) i w jednym miejscu tworzenia klasy to było zrobione a w innym nie. I teraz mi powiedz, że nie zrobienie tego w konstruktorze (kiedy mamy te dane) jest normalne i logiczne. Za to zgadzam się, że ładowanie pliku przez konstruktor to nie jest najlepszy pomysł.

  Dodano: 25 Listopada 2016, 07:32:22
Ahhh... A miałem coś powiedzieć z ciekawostek fizyki. Otóż w funkcji getVDc() mamy trzy bloki if-a. W ostatnim liczy różnicę przepływów przez połączenia do pojazdów. Cała funkcja obliczająca różnicę jest zestawem kolejnych mnożeń. Po środku nawet wołana jest funkcja klasy hamulca, jakieś sprawdzania maksimów. Po wyliczeniu wywoływane funkcje zmiany przepływów w pojazdach obok. Super prawda?
Szkoda tylko, że na końcu funkcji obliczającej różnicę jest wielkie * 0. Ktoś mi powie po co to wszystko wyliczać kiedy żadnych zmian nie będzie?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Listopada 2016, 13:18:02
I teraz mi powiedz, że nie zrobienie tego w konstruktorze (kiedy mamy te dane) jest normalne i logiczne. Za to zgadzam się, że ładowanie pliku przez konstruktor to nie jest najlepszy pomysł.
Ale chyba nikt nie sugeruje, zeby w konstruktorze w ogole nic nie robic? Tylko zeby rozdzielic takie rzeczy jak np proste ustawienie wartosci dla stringa z nazwa (konstruktor) z jednej strony, a ladowanie i obrobka siatki 3d powiazanej z modelem (init/load/whathaveyou)

Ale tak przy okazji, to jesli chodzi o te przyklady, to 1) z kabina, to wlasnie jest raczej przyklad tego, ze nie ma co na slepo odwolywac sie do obiektu bez sprawdzenia czy nie jest on czasem ustawiony na null -- tutaj taki test albo kontrolowany wysyp duzo latwiej byloby wysledzic 2) to oczywiscie powinno byc zrobione w konstruktorze; ale nawet jesli nie bylo, to wysyp mial raczej miejsce dlatego, ze domyslnie  w ogole nie bylo tam nic przypisane, a na zdrowy rozum powinno to byc cos jak "unspecified class" albo nawet pusty string, ale /jakis/ string a nie dziura do pamieci, ktorej glupi komputer od stringa nie odroznia :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 25 Listopada 2016, 20:34:40
Ja w konstruktorach ustawiam zmienne, ale nie robię następujących rzeczy: operacji wejścia / wyjścia, iteracji dużych zbiorów.
Te rzeczy zostawiam dla funkcji asynchronicznych. Sprawdzałem przed chwilą: w C++ jest w miarę sensowna obsługa tego.
Jak wielowątkowość może przyśpieszyć program to wiesz. A nie ma specjalnie dużo więcej pisania. Potem masz swobodę poukładania sobie, co się musi wgrać pierwsze, co musi poczekać, a co może się inicjować jednocześnie. Oczywiście to wymaga porządku w kodzie. Zawsze musisz sprawdzić, czy dane w konkretnym punkcie są już dostępne. Albo wołać operację na danych, kiedy masz pewność że masz dane (bo poczekałeś na wątek inicjujący). No i masz potem czasem przypadek, że nie musisz nawet czekać, bo wątek zdążył skończyć. Czysty zysk w takim przypadku.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 25 Listopada 2016, 23:02:57
Ahhh... A miałem coś powiedzieć z ciekawostek fizyki. Otóż w funkcji getVDc() mamy trzy bloki if-a. W ostatnim liczy różnicę przepływów przez połączenia do pojazdów. Cała funkcja obliczająca różnicę jest zestawem kolejnych mnożeń. Po środku nawet wołana jest funkcja klasy hamulca, jakieś sprawdzania maksimów. Po wyliczeniu wywoływane funkcje zmiany przepływów w pojazdach obok. Super prawda?
Szkoda tylko, że na końcu funkcji obliczającej różnicę jest wielkie * 0. Ktoś mi powie po co to wszystko wyliczać kiedy żadnych zmian nie będzie?
Trzeci blok ifa został z czasów kalibracji przepływów. Koniec końców okazało się, że bez tej części symulator działa najlepiej – nie posprzątałem po sobie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: El Mecánico w 26 Listopada 2016, 14:20:54
IMO konstruktor powinien skończyć robotę jak najszybciej i tylko przygotować zestaw zmiennych dla kolejnych funkcji ładujących, czyli poinicjalizować wskaźniki na null, powpisywać nazwy plików (bez ich otwierania) i wrócić do miejsca wywołania. Tak wstępnie powstałe obiekty wypadało by posortować pod względem istotności dla _rozpoczęcia_ symulacji i w takiej kolejności ładować grube dane. Pierwsza pewnie komórka (komórki) scenerii na której znajduje się nasz pojazd/skład, potem w odległości wyświetlania, uzależnienia/sterowanie w tej lokalnej komórce. Całą resztę scenerii można załadować w tak minimalnej postaci jak tylko to możliwe i konieczne do obliczenia dynamiki i interakcji pojazdów, czyli pomijając całe modelowanie. Na to czas będzie nawet już w czasie symulacji. Generalnie fizyka i grafika powinny być w zależności podległej (grafika wyświetla dopiero jak fizyka policzy), bez pobierania z grafiki jakichkolwiek danych, nawet synchronizacji. Grafika powinna liczyć na _kopii_ danych otrzymanych od fizyki, żeby nie było, że między początkiem a końcem tworzenia klatki fizyka podmieni dane.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 27 Listopada 2016, 13:11:06
W tej chwili na pewno fizyka nic nie podmienia, gdyż jest liczona w każdej klatce na nowo. Stąd były takie problemy, że jeśli FPS spadał zbyt bardzo to cuda zaczynały się dziać z zachowaniem składów. Tamtego if-a w GetVDc zakomentowałem. Zresztą nie tylko tam bo było jeszcze parę miejsc gdzie były if-y prowadzące np. do zakomentowanych funkcji, chyba najlepszym miejscem były trzy if-y po kolei sprawdzające jakieś tam rzeczy po czym we wszystkich odnogach każda potencjalnie wywoływana funkcja była zakomentowana w związku z czym exe po zrobieniu iluś branchy (z każdym traci cykle pracy) nie robiło nic.

  Dodano: 29 Listopada 2016, 20:12:18
Pogadaliśmy sobie troszkę, a ja tu pracuję ;)
Z placu boju to teraz sprawdzam każdą funkcję w moverze i poprawiam, uzupełniam braki i ewentualnie usuwam niepotrzebne rzeczy, np coś takiego:
PosRatio = -PosRatio * 0;albo takiego
PosRatio = 1.0 * (PosRatio * 0 + 1) * PosRatio; // 1 * 1 * PosRatio = PosRatio.
Właśnie skończyłem tracktionforce i zaczynam brakeforce. Idzie do przodu. Narazie commitów nie wrzucam na serwer bo to bez sensu jest. Wrzucę wszystko jak skończę i będzie można skompilować.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: El Mecánico w 29 Listopada 2016, 21:05:27
W tej chwili na pewno fizyka nic nie podmienia, gdyż jest liczona w każdej klatce na nowo. Stąd były takie problemy, że jeśli FPS spadał zbyt bardzo to cuda zaczynały się dziać z zachowaniem składów.[ciach]

No i dlatego fizykę wypadało by z tego oczekiwania wybić i ograniczyć częstotliwość przeliczania do arbitralnej liczby max 120 powtórzeń na sekundę. Wyniki obliczeń fizycznych wystawiać na kontener, a grafika na początku każdej klatki robiła by sobie szybką kopię na własne potrzeby.
Wiem, na starszych komputerach było to marnowanie mocy obliczeniowej, która przydawała się w obliczaniu grafiki, ale dzisiaj nic nie tracimy. A jak kiedyś byśmy chcieli pomyśleć o multi, to bez tego się nie obejdzie...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 29 Listopada 2016, 23:11:05
No i dlatego fizykę wypadało by z tego oczekiwania wybić i ograniczyć częstotliwość przeliczania do arbitralnej liczby max 120 powtórzeń na sekundę.
120 to bylby tzw overkill -- w zasadzie wszystkie gry publikowane dzisiaj maja fizyke liczona 15-20 razy na sek., okazjonalnie moze 30/sek. Silnik trzyma sobie zapisana aktualna i poprzednia kalkulacje, i interpoluje miedzy nimi na potrzeby wizualizacji.

tutaj jest bardzo ladna seria artykulow na ten temat: http://gafferongames.com/game-physics/ z kodem c++ i mnostwem innych przydatnych rzeczy (jak np. fizyka typu klient-serwer, bardzo przydatna do multiplayera itp)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 30 Listopada 2016, 13:02:54
Ja tam uważam, że już na początek samo zrobienie osobnej fizyki do wagonów będzie powodowało mniej miss-cache (w tej chwili każdy wagon przechowuje wszystkie zmienne każdego możliwego typu napędu). Tych danych jest na tyle dużo, że bez sensu jest trzymanie ich niepotrzebnie w każdym obiekcie. Jeśli jeszcze samo rozseparowanie wagonu on lokomotywy zrobi się zgodnie z Data Oriented Programming to można pewnie przyspieszyć obliczanie fizyki z dwa razy.
Widzę tutaj jednak pewną problematyczną sprawę, że w fizyce jest mnóstwo miejsc kiedy obiekty wywołują siebie nawzajem. Być może da się zredukować niektóre z tych wywołań do obliczeń na jednej macierzy danych dla większości obiektów.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 30 Listopada 2016, 16:37:02
No i dlatego fizykę wypadało by z tego oczekiwania wybić i ograniczyć częstotliwość przeliczania do arbitralnej liczby max 120 powtórzeń na sekundę.
120 to bylby tzw overkill -- w zasadzie wszystkie gry publikowane dzisiaj maja fizyke liczona 15-20 razy na sek., okazjonalnie moze 30/sek. Silnik trzyma sobie zapisana aktualna i poprzednia kalkulacje, i interpoluje miedzy nimi na potrzeby wizualizacji.
U nas fizyka musi być liczona z krokiem nie większym niż 100 razy na sekundę ze względu na stabilność sprzęgów i przepływów.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: El Mecánico w 30 Listopada 2016, 21:54:51
No i to 100 to i tak może być dużo, albowiem wiele gier i aplikacji 3D ma w opcjach przełącznik ograniczający częstotliwość wyświetlania do 60 klatek (chociaż 50-55 jest dla ludzkiego oka płynne).
Za czasów świetności Delphi nie było jeszcze wzorców, stąd zapewne wszystkie dynamic'i przechowują komplet zmiennych dla wszystkich typów napędu. Znowu pole do orania (yy, do popisu :D) i przerobienie budowania obiektów dynamic wg wzorców i ograniczanie ilości danych i metod to rzeczywiście używanych w danym typie pojazdu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Grudnia 2016, 00:43:52
U nas fizyka musi być liczona z krokiem nie większym niż 100 razy na sekundę ze względu na stabilność sprzęgów i przepływów.
Nie jestem pewien czy dobrze to czytam, ale czy masz na mysli ze fizyka musi byc liczona co najmniej 100 razy/sek? Czy przeciwnie, nie wiecej niz 100 razy? Jesli to pierwsze, to chyba raczej w tej chwili nie ma to miejsca jesli fizyka jest liczona raz na ramke graficzna, bo 100 fps raczej rzadko sie zdarza, nawet przy wylaczonym vsync (no chyba ze kalkulacje sa robione z malym krokiem tyle razy ile trzeba, co ramke graficzna, ale wtedy nie wariowaloby przy niskim framerate?)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: matek123 w 01 Grudnia 2016, 07:36:35
" nie większym niż 100" czyli maksymalnie 100 kroków w sekundę.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Grudnia 2016, 12:40:17
" nie większym niż 100" czyli maksymalnie 100 kroków w sekundę.
Ale tam bylo "z krokiem nie wiekszym niz", i zaczalem kombinowac, ze to wskazuje ze krok musi byc jak najmniejszy, a to akurat zwieksza ilosc kalkulacji na sekunde, a nie zmniejsza :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 02 Grudnia 2016, 08:11:48
Za czasów świetności Delphi nie było jeszcze wzorców, stąd zapewne wszystkie dynamic'i przechowują komplet zmiennych dla wszystkich typów napędu. Znowu pole do orania (yy, do popisu :D) i przerobienie budowania obiektów dynamic wg wzorców i ograniczanie ilości danych i metod to rzeczywiście używanych w danym typie pojazdu.
Nie zgodzę się, gdyż cały SPKS ma zrobione hamulce na obiektach i pochodnych a pierwotnie napisany był w Delphi. Więc dany obiekt nie przechowuje niepotrzebnych danych.
Ja widzę raczej problem, że funkcje w jednym obiekcie wywołują te same funkcje w następnym obiekcie i to powoduje przeładowanie wszystkiego w pamięci. Brakuje trzymania pociągu w kontenerze (tzn kontener jest ale do tego nie służy), z którego pobierane są dane wspólne, np. komendy rozsyłane po składzie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 02 Grudnia 2016, 17:37:57
Nie jestem pewien czy dobrze to czytam, ale czy masz na mysli ze fizyka musi byc liczona co najmniej 100 razy/sek? Czy przeciwnie, nie wiecej niz 100 razy? Jesli to pierwsze, to chyba raczej w tej chwili nie ma to miejsca jesli fizyka jest liczona raz na ramke graficzna, bo 100 fps raczej rzadko sie zdarza, nawet przy wylaczonym vsync (no chyba ze kalkulacje sa robione z malym krokiem tyle razy ile trzeba, co ramke graficzna, ale wtedy nie wariowaloby przy niskim framerate?)
Dokładnie tak jest - jeśli czas wygenerowania ramki graficznej przekroczył 10 ms, wtedy fizyka jest liczona wielokrotnie, żeby czas jednej iteracji fizyki nie przekroczył 10 ms. Przy ekstremalnie niskim fps (poniżej 5) fizyka jest liczona najwyżej 20 razy na klatkę, co skutuje spowolnieniem upływu czasu w symulacji.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 02 Grudnia 2016, 23:35:39
Skończyłem poprawiać cały TMoverParameters. Mam nadzieję, że niczego nie przeoczyłem. Udało się też skompilować projekt. W związku z tym poprawki wrzuciłem na repo. Jutro testy odpalania czy to wszystko w ogóle będzie działać.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 03 Grudnia 2016, 12:19:28
Zapodasz skompilowany efekt pracy?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 03 Grudnia 2016, 19:17:16
Niestety nie, gdyż nie ma czego zapodawać. Nadal występują błędy obsługi hamulców. Ponadto wsadza mechanika nie do tej kabiny i próbuję w tej chwili dojść dlaczego.

  Dodano: 03 Grudnia 2016, 20:08:44
Czemu była nieprawidłowa kabina już znalazłem. Ale błąd jest dziwny i muszę rozgryźć dlaczego funkcja znajdowania w stringu nie działa prawidłowo. Za to hamulec jest spowodowany włączeniem flagi działania AI pomimo narzuconej obsady. Pewnie też coś w ten deseń jak poprzednio. Przejście z Borlanda na VS to nie będzie łatwa i przyjemna droga widzę.

  Dodano: 03 Grudnia 2016, 20:22:11
Dobra, znalazłem dwa błędy odnośnie inicjacji mechanika i już teraz ładuje dobrą kabinę. AI się włącza bo uruchamiam w debug. <facepalm>. Teraz odkrywanie czemu nie reaguje na klawisze hamulców.

  Dodano: 05 Grudnia 2016, 10:28:20
Znalazłem już przyczynę braku reakcji na hamulce. FV4aM działa. Teraz jeszcze tylko reszta kranów. Następnie będziemy sprawdzać, czy hamulce dobrze działają bo mam wątpliwości. Następnie, czemu po wrzuceniu pierwszej pozycji nastawnika nie pojawia się prąd na silnikach. No i widać, że nie ma co wydawać jak narazie.

  Dodano: 06 Grudnia 2016, 08:00:12
Nie mogę dojść do ładu i składu z hamulcami. Po przestawieniu kranu hamulec w ogóle nie reaguje. Sprawdziłem czy może uruchamia funkcje z klasy bazowej zamiast potomnej ale wygląda ok. Zaczynam głupieć.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: djuzi w 06 Grudnia 2016, 11:05:19
Grzesiek...porwałeś się na te hamulce. Czasem lepiej zostawić to na kilka dni i zająć się czymś innym. Póżniej gdy się wróci do tego na świeżo będzie dużo prościej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 06 Grudnia 2016, 12:40:08
No jak hamulce trykną, to można w zasadzie już wydać to nowe exe, chyba, że jeszcze jakieś regresje są w stosunku do borlandowego exe. Później warto by się zastanowić które bugi i w jakiej kolejności wziąć na tapetę. Z mojej strony głosowałbym na ten, który kładzie symulator po odwołaniu do nieistniejącej komórki pamięci. To powinno zapisywać normalnie komunikat do error.txt i ignorować polecenie. Ludzie piszą, że Kaliska się składa od czasu do czasu, ja jeszcze nie testowałem, ale gdyby po testach mieć  wpisy w error.txt zamiast wysypów byłoby łatwiej znaleźć przyczyny błędów, bo teraz niektórzy piszą, że sypanie na Kaliskiej wynika z błędów exe, a całkiem możliwe, że to błędy skryptów, tylko trudno to póki co odróżnić.

Drugi w kolejności do zaatakowania (IMHO) byłby ten, że syk hamulców (i ogólnie dźwięki) zawieszają się, kiedy nagle oddalimy się od źródła dźwięku. Np stoję przy syczącym wagonie na końcu długiego składu i wciskam F4 - ten syk się wtedy nie wycisza, jest zawieszony, żeby go "odwiesić" muszę jeszcze raz podejść do tego samego wagonu i powoli od niego odejść. Niestety jeśli źródłem dźwięku nie jest nasz skład, tylko inny, który sobie już odjechał, to ciężko odwiesić, bo trzeba by znaleźć źródło.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 06 Grudnia 2016, 13:20:04
Nie wydać chyba, raczej pokazać. Może nawet w zamkniętym dziale. Zbyt szeroka dyskusja rozmydli problemy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 06 Grudnia 2016, 15:22:54
Nie mogę dojść do ładu i składu z hamulcami. Po przestawieniu kranu hamulec w ogóle nie reaguje. Sprawdziłem czy może uruchamia funkcje z klasy bazowej zamiast potomnej ale wygląda ok. Zaczynam głupieć.
Jesli mozna cos zasugerowac, wytnij najpierw Borlanda do konca, a jak juz zrodla da sie skompilowac gdzie indziej, to i odpluskwianie i cala reszte bedzie duzo latwiej przeprowadzic.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 07 Grudnia 2016, 19:07:56
Najpierw to musiałem wyciąć taki fajny błąd, który powodował że nie dało się nic testować na debugerze w 9 na 10 przypadków. Po prostu symek się zawieszał. Po całym dniu szukania znalazłem, tą fajną różnicę, że Pascal inicjuje zmienne do wartości 0, a c++ jak chce. Więc jak nie zainicjujesz zmiennej, której potem nigdzie nie modyfikujesz przed pierwszym użyciem (w tym konkretnym przypadku przesunięcie taboru) to dziwne rzeczy się dzieją (np. dL = 1.38e+220) no i skład się próbuje ciągle przesunąć.
Tak ostatnio myślałem czy by nie wyciąć Borlanda do końca, ale musiałby się chyba znaleźć jakiś chętny co by wydziergał QueryParserComp z brancha. Jak się jakiś chętny znajdzie to resztę już i tak robię.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 07 Grudnia 2016, 21:16:58
Po całym dniu szukania znalazłem, tą fajną różnicę, że Pascal inicjuje zmienne do wartości 0, a c++ jak chce.
No, to akurat standard :)  Tzn nie, ze c/c++ inicjalizuje jak chce, tylko samo z siebie nie inicjalizuje w ogole, wiec dostajesz to co sie akurat trafi w pamieci, a trafic moze sie wszystko (przynajmniej w trybie release, debug moze sobie rozne rzeczy tam ustawiac)

Jak zrobisz wszystko inne, to jesli nie znajdzie sie nikt inny to ja moge sie poswiecic i tego parsera wyciac, ale to na samym koncu bo tak jak wspomnialem, inaczej nie bede w stanie tego skompilowac, wiec musialbym edycje na sucho robic.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 07 Grudnia 2016, 21:30:52
Ja ci borlanda udostępnię jak coś. Zawsze możesz go zainstalować na wirtualce (cd xp sp3 też się znajdzie).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 07 Grudnia 2016, 22:11:13
Tak szczerze to ja nie chce dranstwa tykac, bo nie mam zaufania ani do siebie ze czegos przy okazji nie spieprze, ani do niego ze mi w system jakos nie napaskudzi :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 08 Grudnia 2016, 08:37:14
No właśnie dlatego mówię o wirtualce. Jak dla mnie na sucho też może być.

  Dodano: 08 Grudnia 2016, 08:46:01
Okazuje się, że w hamulcach mam dziurę w przewodzie sterującym. Teraz szukam miejsca rozszczelnienia.

  Dodano: 08 Grudnia 2016, 18:11:53
Nie powinienem się brać za konstrukcję kranów bo źle podłączyłem i miałem tam wielką dziurę. Już załatana i wygląda, że powietrze mi narazie nie ulatuje. Teraz jakieś testy tego ustrojstwa i patrzymy co nie działa dalej.

  Dodano: 08 Grudnia 2016, 22:28:12
Znalazłem kolejną dziurę i teraz działa także sprężarka ;) Nie ma jak błąd w globalnej funkcji ustawiającej bity w zmiennej.
Teraz skład sam luzuje. Ciekawe gdzie znajdę ten feature, który to powoduje.

  Dodano: 10 Grudnia 2016, 19:57:33
Wygląda, że znalazłem dziurę w hamulcach. Takie zabawy są bez sensu. Trzeba przeglądnąć całe hamulce i dopisać inicjację wszelakich zmiennych w konstruktorze.

  Dodano: 10 Grudnia 2016, 22:52:17
Dziury już nie ma. Szkoda tylko, że po zmianie pozycji hamulca na jazdę przewód sterujący nie napełnia się do końca. W związku z czym hamulce też nie puszczają do końca. Pochlastam się chyba. W takim tempie to nie skończę tego do końca przyszłego roku.

  Dodano: 12 Grudnia 2016, 19:39:51
Narazie żadnych postępów. Nie wiem jak będzie w najbliższym czasie, gdyż w małopolsce poprawa komunikacji na linii do Tarnowa polega na wycięciu co drugiego pociągu w szczycie dla większości miejscowości. W związku z tym szansa, że sobie rano siądę z lapkiem spadła z 95% do mniej więcej 0%.

  Dodano: 14 Grudnia 2016, 08:14:03
Nie mogę znaleźć tego co jest źle. Na pewno coś się źle liczy tudzież sprawdza, ale nie wiem gdzie. Następny krok: nauczyć się jak uruchomić debugera dla kodu pascalowego (mam nadzieję, że nie będzie trudne) i sprawdzić na starej wersji jak się to wszystko liczy. Ogólnie już w pierwszym kroku obliczeń są różnice w ciśnieniach więc na pewno coś jest nie halo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: El Mecánico w 14 Grudnia 2016, 18:17:56
W ustawieniach kompilatora upewnij się, że nie ma optymalizacji na szybkość (-Ocyfra), zostaw ew optymalizację na rozmiar kodu (-Os). Jeśli dalej będą problemy, wyłącz też optymalizację na rozmiar.

  Dodano: 14 Grudnia 2016, 19:51:26
Jeśli to się uda, to będziemy potem szukać gdzie rzutować z volatile: http://stackoverflow.com/a/2219839 (http://stackoverflow.com/a/2219839)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Grudnia 2016, 01:55:39
Ogólnie już w pierwszym kroku obliczeń są różnice w ciśnieniach więc na pewno coś jest nie halo.
Warto tez pewnie zweryfikowac czy kod dostaje te same dane wejsciowe, jeszcze przed obliczeniami -- wspominales nieinicjalizowane zmienne, wiec moze sie jeszcze jakies takie kwiatki ostaly.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 15 Grudnia 2016, 06:53:23
Ranna sesja poszła na checkout 481 i debug zmiennych nadawanych i otrzymywanych w funkcjach UpdatePipePressure i UpdateSecondPipePressure. Jak się uda usiąść po południu to zrobię to samo dla wersji c++ i zobaczę co tam się oblicza. Trochę robota głupiego ale nie mam wyjścia. Zastanawiałem się, czy aby nie przyspieszyć sobie tego przez sklonowanie repo. Muszę sprawdzić, czy można trzymać jednocześnie dwa BCB otwarte.

  Dodano: 17 Grudnia 2016, 16:43:42
No i pudło. Te dwie funkcje jak na razie liczą identycznie. Ładnie się zaczyna. Teraz będzie przerwa bo wróciła mi fucha do poprawek (po pół roku, jak ja to uwielbiam) więc narazie więcej nie potestuję. Jak ktoś ma ochotę to sprawdzić to przyjmę każdą pomocną dłoń.

  Dodano: 19 Grudnia 2016, 09:05:13
Stwierdziłem, że podejdę do tematu troszkę inaczej. Przygotowałem sobie nową wersję DynObj, która po każdym przeliczeniu fizyki w Mover->ComputeMovement wyrzuca do loga obliczone wartości PipePress, ScndPipePress, EqvtPipePress, BrakePress i CntrlPipePress. Jak po południu będzie czas to krótki zrzut do loga i patrzymy gdzie zacznie liczyć źle.

  Dodano: 20 Grudnia 2016, 07:13:16
No i dowiedziałem się tyle, że źle inicjowana jest wartość ciśnienia w hamulcach. Rano poprawiłem i sprawdziłem przy okazji całą funkcję i też zrobiłem poprawki (ale nie miały wpływu na te testy, na inne pewnie by miały). Po południu kolejne testy.

  Dodano: 20 Grudnia 2016, 19:25:41
Ha, znalazłem gada. Jednak debugowanie pascala ma swój głęboki sens. Funkcja Init hamulców uruchamia funkcje Init klas-matek. To teraz będzie łatwiej. Ciekawe co jeszcze ciekawego znajdę.

  Dodano: 21 Grudnia 2016, 07:20:10
Rano poprawiłem klasy hamulców. Jeszcze nie testowałem. Jak będzie ok to na tapetę idzie rozruch pojazdu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Mariusz1970 w 21 Grudnia 2016, 16:32:23
Wg mnie, przydałoby się jeśli nie masz jakieś narzędzie  do sprawdzania zmiennych np. ich inicjacji, ich wykorzystania, sprawdzania jakiś klas,  w danych funkcjach, procedurach, modułach itp. w zależności od zasięgu zmiennych. Ja na swój użytek, napisałem sobie własne narzędzie do sprawdzania kodu. Różne rzeczy mi sprawdza m.in. to powyższe. Ogólnie, mimo, iż trochę czasu zajeło napisanie narzędzia, opłacało się. Różne kwiatki wychodziły np. dana zmienna była zadeklarowane i zainicjowana, lecz jej później nie wykorzystywałem (ot sobie taka była niepotrzebna). Czasami z tego własnego narzędzia korzystam, przy jakiś złożonym długim kodzie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 21 Grudnia 2016, 19:31:15
Ale ten błąd był po części winą konwertera, którego użyłem a po części moją, gdyż nie znam Delphi i jak czegoś nie wiem to muszę najpierw sprawdzić co to robi. W c++ wywołanie funkcji z klas-matek odbywa się jawnie (tzn. musisz napisać kod uruchamiający konkretną funkcję) a w Delphi definiujesz przynajmniej na dwa różne sposoby stosując słowo kluczowe, którego nazwa nie jest dla mnie oczywistym uruchomieniem funkcji. Do tego w jednym przypadku robisz to globalnie dla wszystkich funkcji potomnych.
Dla C++ istnieją analizatory kodu więc nie ma potrzeby tego pisać samemu. Nie chcę teraz tego robić, ale na pewno znajdą mnóstwo zmiennych nieużywanych nigdzie. Dodatkowo Q dorzucił troszkę zmiennych używanych jednokrotnie ale tego nie tykam (bo działa) póki nie będzie działać cała reszta.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Mariusz1970 w 21 Grudnia 2016, 20:33:27
Ja mialem na mysli nie tylko ten blad, lecz jakies opisane w tym watku. Czyli wychodzi na to, ze sa analizatory, ale nie wiem, czy je uzywasz. Chyba nie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 22 Grudnia 2016, 08:52:48
Nie używam, gdyż na obecnym etapie to jest bez sensu. Kod movera jest tak scalony, że najpierw go trzeba rozdzielić, a dopiero potem można bawić się w analizę czy jest coś nieoptymalnego typu nieużywane zmienne. Chociaż być może znalazłyby się miejsca, gdzie mamy wysypy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Mariusz1970 w 22 Grudnia 2016, 09:14:34
Ok, to szukaj dalej na piechote np. nie zaincjowanych zmiennych z ktorymi miales zdaje sie problemy i straciles sporo czasu na identyfikacje problemu a to juz na tym etapie daloby sie zidentyfikowac albo poprzez gotowy albo wlasny analizator. Jesli chodzi o nieuzywane, to czesciowo juz mozna identyfikowac np. zmienne ktore sa hermetyczne w danej funkcji. Mialbys juz czysta nowa dodana funkcje, ale skoro twierdzisz, ze analizatory na tym etapuie sa bez sensu, ok. Ja nie zamierzam Cie uszczesliwiac na sile. Masz swoj styl pracy, swoje zasady, trzymaj sie ich :).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 22 Grudnia 2016, 10:51:00
Problem nie leżał w tym, że zmienna nie była inicjowana w ogóle. Była. Tylko nie w konstruktorze a w funkcji inicjującej, i nie w klasie budowanej tylko w klasie matce. To było łatwo znaleźć. Większym problemem było zorientowanie się, że źle inicjowane są wartości poprzez brak uruchomienia funkcji klas matek (a nie nie inicjowane w ogóle). Tego żaden analizator mi nie znajdzie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Mariusz1970 w 22 Grudnia 2016, 11:21:27
Byc moze, jednak nie wierze, aby nie dalo sie wymyslic analizatora te takie rzeczy, jesli jest warte zaintersesowania.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 22 Grudnia 2016, 11:35:18
No, tylko analizator nie sprawdzi czy jest potrzeba uruchomienia danej funkcji. Może Ci sprawdzić czy robisz to optymalnie. Ale żeby nie było, żem beton (ciekawe czy Kuba się będzie rzucał), to szukam jakiegoś dobrego narzędzia i może w święta zrobię analizę. Jak będą oczywiste błędy to można poprawić, ale nie chcę grzebać w nowych miejscach jeśli jest rozgrzebane coś takiego jak cała fizyka.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 22 Grudnia 2016, 13:37:17
Ale żeby nie było, żem beton (ciekawe czy Kuba się będzie rzucał), to szukam jakiegoś dobrego narzędzia i może w święta zrobię analizę.
Dla swietego spokoju mozesz kod przepuscic przez http://cppcheck.sourceforge.net/ zdaje sie ze jest calkiem przyzwoity i nie wymaga jakiegos specjalnego zaangazowania. Pisanie na wlasna reke jakis dedykowanych narzedzi raczej mija sie z celem, imo.

  Dodano: 22 Grudnia 2016, 15:57:28
Przepuscilem to co jest na githubie przez cppcheck, i troche kwiatkow znalazl, w tym kilka grubszych. Te z kategorii (error) trzeba by raczej poprawic, reszta to juz roznie. Czesc jest bardziej powazna, czesc mniej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 22 Grudnia 2016, 21:32:33
O, miło. Zerknąłem. Te z plików hamulce i Oerlikon są już nieaktualne. Tylko tych commitów nie wrzuciłem jeszcze na github-a. Chcę to jeszcze przetestować w wersji trial, któregoś z tych dużych komercyjnych analizatorów.

  Dodano: [time]23 Grudnia 2016, 10:33:42[/time]
No i hamulce dalej nie działają tak jak trzeba. Lok nie luzuje. Jakaś masakra. Mam teraz 20k logów do porównania i będę szukał, gdzie to się sypie. Przez święta raczej postępów nie będzie bo wyjeżdżam.

  Dodano: 29 Grudnia 2016, 07:52:25
Jak narazie udało się rzucić okiem na logi i wychodzi, że ciśnienie w przewodzie głównym (???) - zmienna PipePress nie podnosi się tak samo wysoko jak w wersji paszczalowej. Przepływ z przewodu zasilającego jest teoretycznie kontrolowany przez Handle->GetPF() i wygląda, że wracam do tematu implementacji tablicy wartości przepływu dla poszczególnych pozycji kranu. Może dzisiaj coś więcej zrobię wieczorem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 30 Grudnia 2016, 08:08:11
Nosz wkurzyłem się. Błąd był spowodowany nieprawidłowym użyciem przez kompilator funkcji abs(). Zamiast używać tej z cmath używał z stdlib (pomimo includowania nagłówka). A w stdlib jest wersja tylko dla int, a funkcja używa wersji dla double. Więc obliczał sobie double a potem niejawnie, bez ostrzeżenia , rzutował na int (co w tym przypadku oznaczało, że zamiast 0.xxxx było 0). I w konsekwencji zbiornik sterujący w kranie się nie wypełniał.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 30 Grudnia 2016, 09:51:14
Język Szatana! Ten problem to nawet jest popularny, programiści C++ lubią opisywać podobne przypadki na blogach. Ten język to jedno wielkie pole minowe.
To co, koniec blisko?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 30 Grudnia 2016, 10:45:50
Nosz wkurzyłem się. Błąd był spowodowany nieprawidłowym użyciem przez kompilator funkcji abs(). Zamiast używać tej z cmath używał z stdlib (pomimo includowania nagłówka). A w stdlib jest wersja tylko dla int, a funkcja używa wersji dla double.
Z tego co widze w zrodlach to kompilator dzialal tutaj poprawnie -- abs() z <cmath> jest ulokowany w namespace std, czyli zeby go uzyc trzeba wywolac std::abs() a w kodzie jest tylko abs(). No i jakies ostrzezenie przy kompilacji powinno tam byc, chocby dlatego ze parameter typu double jest konwertowany do int na wejsciu. Nawiasem mowiac ten sam blad ma miejsce przy innych funkcjach -- jest tam np. sqrt() zamiast std::sqrt()

Jak juz przy tym jestesmy, to w std:: sa tez min() and max(), mozna nimi zastapic te z mctools. Sa o tyle wygodniejsze, ze dzialaja na wszystkich typach zmiennych wiec nie trzeba pamietac ktory wariant jest do int, a ktory do double, itp.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 30 Grudnia 2016, 10:53:03
Najlepsze, że VS, którego używam jako IDE poprawnie łapie funkcję z double. Sprawę rozwiąże pewnie using namespace std;Teraz nie chcę się bawić w dostosowanie do użycia STL wszędzie gdzie się da, bo to nie jest ten etap. Teraz to ma działać. Czy koniec to nie wiem. Poprzednio kojarzę, że mogłem odhamować, ale już nie ruszyć ;) Więc wszystko po kolei.
Apropos szatana, to informatyka idealnie podpada pod definicję antychrysta ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Cesky Kretek w 30 Grudnia 2016, 11:45:15
Jestem pełen podziwu dla Twojej wytrwałości. Coś czuję, że po zakończonej transformacji trzeba będzie zrobić duuużą zrzutę na forum na jakiś prezent w ramach wdzięczności. :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 30 Grudnia 2016, 12:54:51
W stosunku do średniej wytrwałości twórców tras to narazie to słomiany ogień.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: surgeon w 30 Grudnia 2016, 17:01:02
Najlepsze, że VS, którego używam jako IDE poprawnie łapie funkcję z double. Sprawę rozwiąże pewnie using namespace std;
Używanie using namespace std; to proszenie się o kłopoty. Dodawaj wszędzie std:: i problem z głowy, a  czytelność kodu większa. Jeśli chodzi o IDE to lepiej jednak byłoby używać coś, co jest wieloplatformowe, czyli np. CodeBlocks, albo notatnik, a nie microsoftowy VS, który pewnie ma tam jakieś swoje dodatki działające wyłącznie pod windowsem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 30 Grudnia 2016, 17:18:59
Ale MaSzyna nie jest wieloplatformowa. Mogłaby być, jak ktoś cały kod przepisze np do C#.
Na razie zależy od DirectX i Win32API.
W przyszłości widziałbym cały kod w C# + Unity, wtedy byłoby wieloplatformowe.
Nie ma lepszego IDE od VS, ale jest lżejsze wieloplatformowe Visual Studio Code. Tyle, że jest sens go używać jak kod jest wieloplatformowy. Do kodu natywnego najlepiej używać narzędzia specjalizowanego. VS CE jest darmowe, więc każdy może sobie pobrać i zainstalować, najnowsza wersja ma też opcję minimalną (bez wszystkich krowiastych ficzerów).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 30 Grudnia 2016, 17:26:53
@HTD, @Surgeon to wie, rozpoczął 14 rok pobytu na tym forum. Jest od początku.
Ja nie widzę potrzeby, aby Maszyna była wieloplatformowa. A skoro już zacząłem, to coraz mniej widzę potrzebę multi playera co do tej pory wydawało się niezbędne.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 30 Grudnia 2016, 18:31:46
Jeśli chodzi o IDE to lepiej jednak byłoby używać coś, co jest wieloplatformowe, czyli np. CodeBlocks, albo notatnik, a nie microsoftowy VS, który pewnie ma tam jakieś swoje dodatki działające wyłącznie pod windowsem.
IDE to tylko IDE; nie ma raczej wplywu na kod, a pisanie czegokolwiek przy uzyciu notatnika to bezsensowny masochizm, ktory tylko stwarza pole dla trywialnych bledow. Of tego jest glupi komputer, zeby pamietal definicje klas i funkcji, i pilnowal czy skladnia sie zgadza.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 30 Grudnia 2016, 19:13:02
A skoro już zacząłem, to coraz mniej widzę potrzebę multi playera co do tej pory wydawało się niezbędne.

Wpierw trzeba opanować samą w sobie symulację, a fajerwerki zostawić na potem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 30 Grudnia 2016, 19:39:02
Przecież nikomu nie bronię pisać w notatniku. VS potrafi pisać kod multiplatformowy jeśli pamiętasz o tym, że chcesz to robić i nie używasz MFC, czy rzeczy z Visual C++ albo WinAPI albo DirectX.
Od razu też powiem, że problem nie leżał w użyciu std::abs() czy using namespace. Obie metody nie działają, gdyż wygląda, że Borland nie ma w STL zaimplemetowanego abs dla czego innego niż int. Na szybko dodałem dwie implementacje w mctools i działa ok.
Inna rzecz, że hamulce nie działają po podłączeniu wagonów. Teraz szukam, dlaczego ucieka powietrze z przewodu głównego.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Cesky Kretek w 31 Grudnia 2016, 11:39:37
W stosunku do średniej wytrwałości twórców tras to narazie to słomiany ogień.
Ale za to da nam to ogromny postęp i otworzy nowe możliwości.
Prowadzisz jakieś statystyki ile Ci jeszcze pozostało kodu do przepisania? Jakieś status-bary itp.? Tak z czystej ciekawości. :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 31 Grudnia 2016, 12:58:38
Z kodu do przepisania stricte pozostało już tylko wczytywanie za pomocą pascalowego parsera, co da się zmienić już teraz niezależnie od moich prac. Z tego co ja robię to teraz są poprawki błędów konwersji. Całość jest już na c++.
Jak na teraz to odkryłem, że mi ktoś włączył hamulec awaryjny w wagonach.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: El Mecánico w 01 Stycznia 2017, 14:39:30
Jak na teraz to odkryłem, że mi ktoś włączył hamulec awaryjny w wagonach.
Proponuję sprawdzić, czy aby ta zmienna/flaga jest inicjalizowana do właściwej wartości. Jeśli nie, trzeba prześledzić ścieżkę od parsera. Jeśli tak, to trzeba sprawdzić, czy od inicjalizacji do startu symulacji coś jej nie nadpisuje.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 02 Stycznia 2017, 07:02:33
Już myślałem, że sprawdziłem wszystkie zmienne w konstruktorze, ale nie. Ciągle są braki. Cóż, wagon nie dość, że miał zaciągnięty hamulec to i uszkodzony silnik ;) Teraz jeszcze raz po kolei sprawdzam każdą zmienną jaka jest zadeklarowana w moverze czy jest inicjowana w konstruktorze. Jestem tak pi razy drzwi w 1/4. Może do końca tygodnia wszystko sprawdzę i wtedy kolejny test.

  Dodano: [time]03 Stycznia 2017, 21:00:10[/time]
Zainicjowałem wszystko co brakowało. Dalej coś nie halo, ale już mniej. Z przewodu ma ubywać, ale teraz jest za szybko. Coś tam dalej źle się liczy. Mam lekko dość tej zabawy.

  Dodano: 03 Stycznia 2017, 22:55:29
Wstępnie obstawiam błędy w Oerlikonie wagonowym. Z pierwszych odkryć to nie działa mi typeid(T) i chciałbym się dowiedzieć dlaczego.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 04 Stycznia 2017, 01:43:03
Z pierwszych odkryć to nie działa mi typeid(T) i chciałbym się dowiedzieć dlaczego.
Sprawdz, czy wlaczona jest generacja danych RTTI w ustawieniach kompilatora. Ale takie rzeczy to powinno sie raczej robic przez wirtualna funkcje w klasie bazowej, ktora konkretne warianty juz sobie implementuja tak, jak im to pasuje. Reczne sprawdzanie typow i wywolywanie odzielnych funkcji na tej podstawie to troche dokladanie sobie roboty i proszenie sie o klopot ;/

edit:
patrzac w kod, to najprawdopodobniej nie dziala bo porownujesz wskaznik do klasy z klasa, wiec tam rownosci nigdy nie bedzie. Czyli nie powinno byc
typeid( foopointer ) == typeid( bar )
ale
typeid( *foopointer ) == typeid( bar )
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 04 Stycznia 2017, 07:01:04
Ahh, ile jeszcze rzeczy do odkrycia w c++... ;) Czemu w innych językach to jest proste a tu nie może.

  Dodano: [time]04 Stycznia 2017, 07:54:53[/time]
Chyba się przesiądę na VS2017RC ze względu na tą funkcję:
Cytuj
Find All References (Shift+F12) now helps you get around easily, even in complex codebases. It provides advanced grouping, filtering, sorting, searching within results, and (for some languages) colorization, so you can get a clear understanding of your references. For C++, the new UI includes information about whether we are reading from or writing to a variable.

  Dodano: [time]05 Stycznia 2017, 09:47:22[/time]
Znalazłem błąd. Spowodowany moim gapostwem, gdyż to jest niedogodność konwersji, że czasem wrzuca słowa sterujące za komentarze i zamiast else if masz komentarz. Zawsze przeglądam pliki po konwersji, żeby to znaleźć, a w tym przypadku mi umknęło. Teraz powietrze nie ucieka już. Późno było to już nie robiłem znaczących testów. Dzisiaj odhamowanie składu i ruszenie. Jeśli się uda ruszyć ;)

  Dodano: [time]05 Stycznia 2017, 23:35:14[/time]
No znalazłem więcej błędów. Jeden z nich to była błędna konwersja typu wkładki hamulca, i wszystko miało te same wkładki żeliwne ;) Było też parę innych błędów, ale ciągle wagon jest nieodhamowywalny. Bo ostatniej poprawce zrobiłem nową dziurę i teraz ciśnienie w przewodzie mam -1 ;)

  Dodano: [time]06 Stycznia 2017, 21:02:47[/time]
Przewód załatany. Brak dopisania funkcji jako wirtualnej w klasie polimorficznej. Nadal źle liczy ciśnienie w hamulcu.

  Dodano: 06 Stycznia 2017, 23:58:48
No powiem, że ostatni błąd był najgłupszym jaki widziałem do tej pory. Otóż
if ((BrakeStatus & b_on == b_on)) nie jest tożsame z if ((BrakeStatus & b_on) == b_on) Nie wiem czemu tak to działa ale po zmianie na poprawną wersję hamulce działają jak potrzeba.
Elektrykiem da się ruszyć, ale reaguje tylko na pierwszą pozycję i nie zwiększa prądu wraz z wejściem na kolejne.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 07 Stycznia 2017, 01:46:11
Nie wiem czemu tak to działa ale po zmianie na poprawną wersję hamulce działają jak potrzeba.
Bo taka jest typowa kolejnosc operacji w c++ ( http://en.cppreference.com/w/cpp/language/operator_precedence )

kombinacje bitowe i logiczne (#10-14) sa z reguly wykonywane po porownaniach (#8-9) czyli ta pierwsza wersja to w praktyce
if( BrakeStatus & 1 )
bo b_on == b_on bedzie zawsze prawdziwe.

porownanie to operator jak kazdy inny, a c++ te rzeczy sa w zasadzie defniowane luzno, jesli w ogole, dlatego prawie zawsze warto dla pewnosci wymuszac kolejnosc nawiasami itp, inaczej ugryzie cie to nie wiadomo kiedy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 07 Stycznia 2017, 16:17:31
W każdym razie w jednych if-aach było poprawnie a w innych nie.
Z dzisiejszych testów wynika, że czuwak nie działa, znaczy włącza się, ale nie hamuje ;)
Teraz sprawdzam czemu źle liczy prąd w obwodzie.

  Dodano: [time]07 Stycznia 2017, 16:50:31[/time]
Uwielbiam C++. Do tej pory nie mogę zrozumieć co przyświecało twórcom kompilatorów, że jeśli wynik jest typu double, a pierwsza liczba wymnażana po prawej jest typu int to policzy całość mnożenia w liczbach całkowitych i wynik zrzutuje na double.

  Dodano: 07 Stycznia 2017, 16:58:50
Ahh, zapomniałem dodać, że kiedy wrzucam pozycje na czysto to nie przeskakuje zmienna, ale jeśli na funkcji obsługującej klawisze wrzucę breakpointa to ją przerzuca.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 07 Stycznia 2017, 17:50:15
Uwielbiam C++. Do tej pory nie mogę zrozumieć co przyświecało twórcom kompilatorów, że jeśli wynik jest typu double, a pierwsza liczba wymnażana po prawej jest typu int to policzy całość mnożenia w liczbach całkowitych i wynik zrzutuje na double.
A to akurat dziwne. Standardowo jest w druga strone (https://msdn.microsoft.com/en-us/library/aetzh118.aspx) tzn jesli jest np float = int * float to kompilator promuje int do float i wszystko dziala: 1 * 1.5 = 1.5  Chociaz i tak dla pewnosci warto stosowac static_cast itp, ale to chyba cos z Borlandem, a nie c++ jako takim.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: ryba825 w 07 Stycznia 2017, 19:48:06
Uwielbiam C++. Do tej pory nie mogę zrozumieć co przyświecało twórcom kompilatorów, że jeśli wynik jest typu double, a pierwsza liczba wymnażana po prawej jest typu int to policzy całość mnożenia w liczbach całkowitych i wynik zrzutuje na double.
A to akurat byłoby bardzo dziwnie, bo to nie ma żadnego sensu. Może bug kompilatora?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 08 Stycznia 2017, 18:00:29
To musi być Borland, bo w jego przypadku double x = 3/2 => 1, a 3.0/2 => 1.5. Więc wczoraj wieczorem przeglądałem cały mover, żeby wychwycić te wszystkie miejsca gdzie liczy na całkowitych.

  Dodano: 08 Stycznia 2017, 18:25:41
Da się normalnie jeździć, tylko nie działa czuwak. Szukam przyczyny czuwaka. Chciałbym jeszcze też zrobić parę testów zanim puszczę do was, żeby nie było strasznego crapa.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 08 Stycznia 2017, 18:57:08
To musi być Borland, bo w jego przypadku double x = 3/2 => 1, a 3.0/2 => 1.5. Więc wczoraj wieczorem przeglądałem cały mover, żeby wychwycić te wszystkie miejsca gdzie liczy na całkowitych.
A nie, 3/2 = 1 to akurat "normalne" -- konwersja z liczb calkowitych na zmiennoprzecinkowe ma miejsce, jesli przynajmniej jeden ze skladnikow operacji matematycznej jest typu float albo double. Jesli oba sa typu int, to kompilator tak je zostawi. Przypisanie wyniku do zmiennej nastepuje juz po fakcie, jako odrebna operacja, wiec nie wplywa na to jak przeprowadzana jest sama matematyka; o tym decyduja tylko typy skladnikow.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 08 Stycznia 2017, 20:00:42
Znalazłem czuwak. Wyszło, że błąd był w funkcji SetFlag, która przetłumaczyłem jakieś 2 miechy temu. Jeśli dwukrotnie ustawiałem flagę to za drugim razem była kasowana. Jeszcze kółeczko po TD z hamowaniem, żeby sprawdzić czy na pewno wszystko gra i chyba włączę jakiś scenariusz.

  Dodano: [time]08 Stycznia 2017, 20:21:21[/time]
Scenariusz: failed. Źle ładuje się EP09 i kibelki.
Przy okazji wyłączyłem okienko błędów.

  Dodano: [time]08 Stycznia 2017, 21:39:56[/time]
Poprawiam teraz funkcje wczytywania fizyki, bo się komuś zapomniało dodać paru wyjątków.

  Dodano: 10 Stycznia 2017, 06:57:27
Fizyka ładuje się już poprawnie. Ale scenariusz dalej nie działa, gdyż odezwał się stary błąd z nieskończonym przesuwaniem pojazdu. Tym razem przyczyna jest inna, gdyż zmienna w debugerze wyświetla -NAN i teraz dochodzę w którym momencie przyjmuje taką wartość (jest inicjowana, więc to nie to raczej).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 10 Stycznia 2017, 07:46:38
NaN z reguly (moga byc roznice zaleznie od kompilatora, niektore to wylapia) wyskakuje przy dzieleniu zero przez zero, albo gdy probujesz liczyc sqrt() z liczby ujemnej. Bardziej prawdopodobny jest ten drugi wariant.

do wylapania gdzie to sie dzieje mozesz uzyc assert( foo == foo ); zatrzyma sie kiedy foo = NaN
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 10 Stycznia 2017, 08:02:02
No to jest ciekawe, gdyż zmienną inicjuję dzieląc wartość wejściową konstruktora przez 3.6. Więc nawet jak jest 0.0 na wejściu to nie powinno być NaN. Musi być coś jeszcze gdzieś indziej. Najlepsze, że tak się dzieje nie przy każdym uruchomieniu a to by wskazywało na brak inicjacji zmiennej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 10 Stycznia 2017, 19:47:47
Nie wiem, czy ma to zwiazek, ale zwroc uwage na ComputeCollision()
v1 = w1 * sqrt(1 - beta); // niejawna zmiana predkosci wskutek zderzenia
v2 = w2 * sqrt(1 - beta);
Nie ma tu zadnego zabezpieczenia przed sytuacja gdzie beta > 1 i nie zdziwilbym sie, gdyby wyszlo ze wywolanie z CollisionDetect() produkuje takie wlasnie wartosci od czasu do czasu, takie rzeczy jak Couplers[CouplerN].Connected->Couplers[Couplers[CouplerN].ConnectedNr].beta az prosza sie o klopot, i omylkowe czytanie danych z miejsc, gdzie zadnych danych nie ma :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 10 Stycznia 2017, 20:47:10
To nie jest w CollisionDetect. Znalazłem już przyczynę, ale to nie będzie łatwe do obejścia. Wygląda, że przekręcam licznik podczas obliczeń. Podejrzewam, że w Delphi przy wyjściu poza zakres nadawał wartość min/maks, a teraz już nie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 10 Stycznia 2017, 21:05:32
Co on tam tak liczy, ze mu sie w double albo long nie miesci? o.O
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 11 Stycznia 2017, 07:51:14
Z porannej sesji dowiedziałem się tylko, że przeskok wartości następuje na sprzęgu. Z wartości 0.00004 wrzuca na -1.00+e45 w następnym kroku dla pojazdu. Jako, że wartość na sprzęgach jest liczona wzajemnie to teraz będę przechodził krok po kroku każdy pojazd i sprawdzał skąd to się bierze.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 11 Stycznia 2017, 09:54:20
Ja tylko zaczynam się bać, czy z takiego "makaronu" powstanie w tym kroku sensowny kod? Tzn po przepisaniu - jak działanie tego jest tak anty-intuicyjne - to nadal nie będzie rozwijalne. Kod którego działanie jest anty-intuicyjne to "makaron" właśnie. Nie nadaje się do dalszego rozwoju. No, chyba, że teoretycznie, to będziemy mieli teoretyczny rozwój.

C++ to przeżytek na miarę Internet Explorera! Nie wiem czy nie da się tego zrobić w C++ tak, żeby obliczenia i ich wyniki były jasne dla osoby, która rozumie samą matematykę w nich użytą. Jeśli tak, to będzie trzeba tak to przerobić. Jeśli nie, to chyba warto pomyśleć o języku, w którym 2+2 zawsze jest 4, a idiotyczne i niebezpieczne konwersje typów będą odrzucane przez kompilator.

Jak dla mnie to kompletny brak rozwijalności - jeśli programista próbujący rozwijać kod musi tracić godziny na kombinowanie czemu 2 + 2 nie działa. Jak 2 + 2 nie działa i wymaga wgłębiania się w detale komponentów zupełnie niezwiązanych z realizowanym zadaniem - coś jest grubo nie tak.

Jak potrzebujemy rakiety kosmicznej żeby odpalić MaSzynę na kalkulatorze czy zegarku - są do tego nowoczesne języki niskopoziomowe. Jest Rust. Jest Haskell. I kilka innych. Wszystkie powstały z podobnych powodów. Komuś znudziło się zarywanie kolejnej nocki na debugowaniu 2 + 2.

Na mój gust do całej fizyki w MaSzynie wystarczyłby C#. Matematyka w C# liczy się tak samo szybko jak w C++, pod warunkiem sensownego gospodarowania pamięcią. Jedyne co będzie w C# wolniejsze (i to o rzędy wielkości) to operacje typu "weź 2GB danych i przemiel". Wolniejsze będzie I/O i takie tam. Rzeczy, które można zamknąć w osobnym niskopoziomowym module/dll. Module, który nic nie będzie liczył, chyba że hurtowe przekształcenia dla shaderów.

Mamy ramkę. Dla uproszczenia 1/60 sekundy. Jeśli mamy w tej ramce przeliczyć tysiące rzeczy - runtime nam w tym nie przeszkodzi. Nawet na zabytkowym kompie. Problem byłby dopiero wtedy, gdybyśmy musieli przeliczyć miliony czy miliardy rzeczy. Ale od tego są niskopoziomowe moduły właśnie. Tia. Przy takiej konstrukcji kod byłby rozwijalny.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: szczawik w 11 Stycznia 2017, 10:07:18
@HTD, póki co Twoje posty są tyle warte co ten mój. Zwykłe rozważania o tym jak fajnie by było gdyby to i tamto. Ani nie pomożesz @firleju, ani nie przyczynisz się do pchnięcia tego w jakąkolwiek stronę.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Mariusz1970 w 11 Stycznia 2017, 10:34:44
Coś jest na rzeczy, o czym pisze HTD, jednak przypomina mi to to:
t=05m00s
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 11 Stycznia 2017, 13:28:49
C++ to przeżytek na miarę Internet Explorera! Nie wiem czy nie da się tego zrobić w C++ tak, żeby obliczenia i ich wyniki były jasne dla osoby, która rozumie samą matematykę w nich użytą. Jeśli tak, to będzie trzeba tak to przerobić. Jeśli nie, to chyba warto pomyśleć o języku, w którym 2+2 zawsze jest 4, a idiotyczne i niebezpieczne konwersje typów będą odrzucane przez kompilator.
Idiotyczne i niebezpieczne konwersje typow zawsze generuja ostrzezenia. Jak ktos chce, to moze sobie wlaczyc zasade, ze ostrzezenie = blad, i kompilacja nie pojdzie. Tyle, ze w kodzie maszyny ostrzezen jest pewnie tyle, ze usuwanie ich potrwaloby do przyszlej wiosny. Takich rzeczy trzeba pilnowac i usuwac je na biezaco, inaczej to sie szybko nawarstwia.

Czy c++ jest przezytkiem... troche mylisz tutaj dwie rzeczy -- maszyna jest w duzej mierze pisana pod Borland c++ ktory skonczyl rozwoj przed rokiem 2000. To jest faktycznie przezytek, ale tez ma on malo wspolnego z c++11 ( https://en.wikipedia.org/wiki/C%2B%2B11 ) i nowszymi wersjami jezyka. To troche tak jakby mowic ze openGL jest przezytkiem, bo opieramy sie na wersji 1.2 gdy tymczasem standard rozwinal sie do wersji 4.5 i posuwa sie dalej.

No, ale nic nie stoi na przeszkodzie, bys przepisal maszyne na C# jesli uwazasz ze to jedyna perspektywiczna droga rozwoju :)

@firleju podaj troche szczegolow jesli mozesz. Co to za funkcja, ktora liczy i chrzani te sprzegi?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 11 Stycznia 2017, 13:44:39
ComputeCollision i ComputeCouplerForce jak sądzę (nie pamiętam dokładnie nazw). Wywoływane z TGround::Update. Zmieniana jest zmienna CForce.

  Dodano: 11 Stycznia 2017, 13:48:37
@HTD: zrób prosty eksperyment. Zainicjuj zmienną małą wartością, np, 2.3e-5. Potem dziel ją powoli przez jakieś 50, najlepiej tak żeby kompilator nie mógł sobie tego policzyć przed uruchomieniem programu i tak ze 100 razy. Powiedz jaki jest wynik w C#.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 11 Stycznia 2017, 13:56:48
Dobrze wiedzieć, temat tylko obserwowałem, nigdy nie używałem C++, chyba że absolutnie musiałem. To nie panikuję już, w końcu jak VS pokaże te wszystkie ostrzeżenia, to da się to ogarnąć. Nie twierdzę, że C# to jedynie słuszna opcja. No byłoby szybciej, a dlatego teraz tego nie robię, bo czas, czas i jeszcze raz czas. Robię teraz 5 projektów na raz, od 5 rano do północy dzień w dzień, tak że nie mam nawet czasu jeździć ;) Ale dalej i tak nie mam w planach grzebać przy exe, wolę zaatakować temat narzędzi graficznych. Mam sporo rozgrzebanego kodu i szkoda wyrzucać tego do kosza, bo może zaoszczędzić w przyszłości całe miesiące dłubania w sceneriach.

Podziwiam cierpliwość Grześka, ja bym chyba wyskoczył przez okno od takich bugów ;)

var x = 2.3e-5d;
for (int i = 0; i < 10000; i++) x /= 50d;
Console.WriteLine($"x = {x}");
Console.ReadKey(true);

Wynik 0 dla double. Dla float tak samo wynik 0.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 11 Stycznia 2017, 14:48:47
Dla mnie trochę niezrozumiała jest natura błędu. W jednym obliczeniu mam delikatną ujemną siłę, a w następnym jakby ktoś rypnął w wagon. Najlepsze, że potem oblicza przejechaną odległość w kategoriach kosmicznych ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 11 Stycznia 2017, 15:22:39
Zainicjuj zmienną małą wartością, np, 2.3e-5. Potem dziel ją powoli przez jakieś 50, najlepiej tak żeby kompilator nie mógł sobie tego policzyć przed uruchomieniem programu i tak ze 100 razy. Powiedz jaki jest wynik w C#.
visual c++ 2013
double x = 2.3e-5;
for( int i = 0; i < 100; ++i ) {

x /= 50.0;
assert( x == x );
}
przy typie double x = 2.9155963805249270e-175
przy typie float x = 0

Borland to liczy, czy sie wysypuje?

jesli ComputeCollision() ma swoj udzial, to zwroc uwage na ten kawalek 1 - beta o ktorym wspomnialem (o ile to jeszcze tam jest) CouplerForce() wyglada jak spaghetti, ale nie ma tam nic strasznie podejrzanego, no chyba ze probuje gdzies czytac cos, co akurat nie jest danymi.

Chyba naprawde najlepiej byloby w tym momencie wywalic borlandowy parser, zeby to sie wszystki zaczelo kompilowac w jakims sensowniejszym srodowisku, i wtedy spokojnie szukac bledow
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 12 Stycznia 2017, 07:48:18
Wygląda to strasznie dziwnie. Porobiłem logowanie zmiennych i wygląda, że nadawana wartość CForce jest normalna. A mimo wszystko w następnej funkcji liczy jakieś kosmiczne wartości przyspieszenia. Najlepsze, że tak się dzieje tylko w jednym wagonie i tylko jak jest więcej składów na scenerii. Jak wytnę resztę składów to liczy normalnie.
Ja bardzo chętnie zrezygnuję z Borlanda. Mogę udostępnić całość skonwertowaną i trzeba tylko wywalić ten parser i pousuwać resztę AnsiStringów (został chyba tylko zapis e3d z tego co pamiętam) i powinno się skompilować bez problemów (trzeba zakomentować funkcję abs i to_string w mctools, specjalnie zrobione żeby nie powielać później funkcji z STL). Przyjmę każdą pomocną dłoń w tym zakresie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 12 Stycznia 2017, 16:49:08
Jesli tam zostal tylko parser do zrobienia, to pchnij jak mozesz aktualna wersje na githuba. Na 100% nie moge obiecac, ale postaram sie zerknac w weekend czy da sie zrobic zamiane i doprowadzic to do kompilacji w czyms innym.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 12 Stycznia 2017, 19:40:37
Znalazłem miejsce błędu, wiem jak naprawić, ale nie wiem dlaczego on się pojawia. Analizuję co tam się dzieje teraz.

  Dodano: [time]12 Stycznia 2017, 19:59:12[/time]
A jednak okazało się, że była jeszcze jedna nie zainicjowana zmienna w moverze. Naprawdę nie wiem jak ją minąłem.

  Dodano: [time]12 Stycznia 2017, 20:37:13[/time]
Hehe, kolejny "błąd". Okazuje się, że nie czyta dodatkowych wpisów do hamulców taboru w scenerii by yB.

  Dodano: 12 Stycznia 2017, 20:56:15
Tak sobie pomyślałem, że to pewnie efekt uboczny usuwania AnsiStringów z wcześniejszych etapów.
Ponadto pchnąłem wszystko co do tej pory zrobiłem na git-a. Wygląda, że da się już jeździć i oprócz tych wagonów Quark wystartował.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 13 Stycznia 2017, 07:08:00
Wczesnym rankiem zrobiłem poprawkę na poprawne parsowanie flagi bitowej sprzęgu. Teraz już działa. Wieczorkiem puszczam kontrolnie Quarka i jak się nic nie będzie sypało to idzie do was na większe testy. Przy okazji zerknąłem na kod pod kątem kompilacji w VS i jest tam jeszcze troszkę rzeczy do poprawienia, np. zmienne typu Byte i takie tam. VS lubię ze względu na fajny sposób zaznaczania linijek z błędami.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 13 Stycznia 2017, 09:52:37
Przy okazji zerknąłem na kod pod kątem kompilacji w VS i jest tam jeszcze troszkę rzeczy do poprawienia
To jest delikatnie powiedziane :)  Zajrzalem tam sobie dzisiaj, i niestety na samym wycieciu parsera sie nie skonczy, sporo tam jeszcze sie paleta ansistringow, borlandowych naglowkow i innych takich. Ale jak juz zaczalem grzebac, to skoncze (chociaz ladnie jeszcze nie bedzie, na to przyjdzie czas pozniej)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 13 Stycznia 2017, 11:00:47
Ładnie, proszę Cię, całość jest do refaktoringu. Ale po kolei. Ci którzy chcieli pisać wszystko na nowo kończyli smętnie.
Ja kończę jak widać z samą konwersją. Jak już pójdzie to zrobię merga z najnowszymi zmianami na masterze i dalej do testów. Jak będzie ok, to wrzucam na upstream-a i dalsze prace to:
1. Zejście z BCB
2. Opracowanie grafu zależności danych, czyli gdzie jakie klasy są trzymane.
3. Zmiana organizacji przechowywania danych na prostszą:
a. Pojazdy są w 4 różnych klasach, trzy odpowiadają za reakcję pojazdu na różne zdarzenia i jedna steruje. Brak podziału na poszczególne typy pojazdów nie mówiąc o różnicach w sterowaniu poszczególnych modeli. To samo tyczy rozróżnienia AI / człowiek.
b. Trzeba przemyśleć sposób przechowywania danych geometrycznych w kolejnych poziomach. Mnie tam wygląda, że jest dużo miejsca do optymalizacji, no i większej przejrzystości.
c. Należy się zastanowić nad zejściem z DisplayList na rzecz tylko VBO. Wtedy wprowadzić shadery, będzie można zrobić normalne oświetlenie.
4. Po drodze jeszcze są kwestie:
a. Wymiany danych z innymi systemami, w szczególności SCS i koncepcyjnym VD (implementacja komunikacji międzyprocesowej za pomocą Message Quequing)
b. Poprawy błędów na obecnych sceneriach
5. Nie ma żadnych testów i to naprawdę boli. Niestety kod jest tak napisany, że w niektórych momentach trudno wykonać zaimplementować testy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 13 Stycznia 2017, 17:45:01
Ładnie, proszę Cię, całość jest do refaktoringu. Ale po kolei. Ci którzy chcieli pisać wszystko na nowo kończyli smętnie.
Nie no bez przesady, ja nie planuje tutaj nic dotykac w samej strukturze. Probuje tylko doprowadzic do kompilacji w VC to, co jest. Na razie sprowadza sie to do parsera, stringow i usuniecia odwolan do pozostalych resztek po Borlandzie. Tylko mowie, ze zostalo tego troche wiecej niz mialem nadzieje, ze bedzie; ale trudno :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 13 Stycznia 2017, 18:58:10
Też tak myślałem, że to tylko tyle i szybko pójdzie ;)

A w załączniku prezent poświąteczny. Wprost z kompilatora, zagrzało mi procek ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: szogun w 13 Stycznia 2017, 20:09:21
Z tego co zauważyłem po krótkiej jeździe na TD - nie działa woltomierz baterii, przyhamowanie przy poślizgu, piasecznica daje tylko dźwięk a piachu nie sypie i odluźniacz nie żyje. Ciekawy efekt się też pojawia po powrocie do pojazdu z freefly, jest takie płynne lekkie bujnięcie kamerą jakby maszynista się poprawiał w fotelu ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: matek123 w 13 Stycznia 2017, 20:32:44
U mnie miota w kabinie prawie cały czas, jakby "maszynista" miał padaczkę. Nie zamyka mi WS. A jak dałem autopilota, to mrugała lampka od WSa.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 13 Stycznia 2017, 20:35:12
Wersja skompilowana wysypuje się zaraz po starcie. Dodaje kilka eventów do kolejki, słychać luzowanie hamulca i wysyp. Siódemka na TD czy Bałtyk.
Źródła się nie kompilują. Nie widzi klasy Hamulce.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 14 Stycznia 2017, 07:16:55
Train.cpp jak na razie rozwalil konwersje -- okazuje sie, ze kompilator ma twardy limit 127 blokow else-if, a InitializeCab() nic sobie z tego nie robi. Trzeba sie bedzie przyjrzec, jak to przerobic na cos rozsadnego... 90% daloby sie ladnie zautomatyzowac, ale nie wiem jak to jest potem obslugiwane w symulacji. Tez wszystko recznie, jedna kontrolka po drugiej?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: El Mecánico w 14 Stycznia 2017, 12:31:02
Nie da się tego zestawu else-if'ów przerobić na switch-case?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 14 Stycznia 2017, 17:07:49
Nie bardzo, bo sa oparte na porownywaniu stringow. Plus, calkiem mozliwe ze switch() ma podobne ograniczenie. Tymczasowo rozbije to na dwa osobne bloki, powinno wystarczyc, a w przyszlosci mozna sie pobawic przebudowaniem kodu kabiny na cos bardziej sensownego.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: El Mecánico w 14 Stycznia 2017, 18:48:55
Stringów? Zazwyczaj wale tam int'a (ew. enum'a, który wewnętrznie i tak jest konwertowany na int'a) i jakoś działa. Czyżby kompilator napotykając switch'a robił konwersję zmiennej niejawnie do stringa?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 14 Stycznia 2017, 19:31:41
Nie zrozumielismy sie :)

https://github.com/firleju/maszyna/blob/mover_in_c%2B%2B/Train.cpp

zerknij do InitializeCab()
(..)
            else if (str == AnsiString("mainctrlact:")) // zabek pozycji aktualnej
                ggMainCtrlAct.Load(Parser, DynamicObject->mdKabina);
            else if (str == AnsiString("scndctrl:")) // bocznik
                ggScndCtrl.Load(Parser, DynamicObject->mdKabina);
            else if (str == AnsiString("dirkey:")) // klucz kierunku
                ggDirKey.Load(Parser, DynamicObject->mdKabina);
(..)
i tak jeszcze ze 100 razy. Tego sie nie da za bardzo wprost przerobic na switch() bo switch musi miec stale wartosci (czyli int albo enum, tak jak mowisz) i nie lyka w takiej sytuacji wyszukiwania przypadku wg stringa. Tzn mozna by sie pewnie bawic z jakas tabela konwersji string->enum i zrobic switch() dla tych konwertowanych wartosci, ale to jest troche pisania bez gwarancji, ze i tak nie wyskoczy mu ten sam limit. To w takiej sytuacji wole to na razie zostawic, a przerobic mozna potem raz a porzadnie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Stycznia 2017, 05:50:11
Nawet nie probowalem uruchamiac, bo to nie ma prawa dzialac (ponad tysiac ostrzezen roznej masci) niemniej (maly) krok naprzod jest ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: przepioramarcin w 15 Stycznia 2017, 08:03:02
TD, EU07 - Od strony elektryki wszystko wydaje się OK. Problem z hamulcem pomocniczym - działa dopiero na ostatniej pozycji hamowania. Nie działa odluźniacz. Hamulec zasadniczy OK.
Faktycznie trochę bardziej buja :).
TD, SU45 - nie udało się ruszyć. Po uruchomieniu silnika gdy załączymy sprężarkę słychać ponowny rozruch silnika. Ciśnienie w zbiorniku głównym stoi na zerze.
TD, EN57 - chyba wszystko w porządku. Nawet nie rzuca mechanikiem tak jak w EU07.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Stycznia 2017, 14:31:40
"I'm making a note here:
 Huge success!"


Az sie zdziwilem, bo szybciej sie to wszystko uruchomilo niz myslalem. Milion rzeczy tam jest jeszcze do poprawienia na 100 procent, ale w kazdym razie gra, jezdzi i buczy.

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 16 Stycznia 2017, 10:33:40
Jako, że masz te same błędy co ja, to z tym jeździ bym nie przesadzał ;)
Ale chętnie przyjmę poprawki, żeby już też się pozbyć BCB. Nadal nie umiem w solucji zrobić takich ładnych folderów z plikami i mam wszystko płaskie :(
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 16 Stycznia 2017, 14:44:30
No nie calkiem te same, pare poprawilem ;)
musze jeszcze zintegrowac z poprawkami ktore zrobiles w miedzyczasie, ale wersja tymczasowa jest tutaj: https://github.com/tmj-fstate/maszyna/tree/parser_replacement

a co do folderow w visual studio, kliknij prawym przyciskiem na projekcie albo folderze w okienku solution, i Add->New Filter. Mozesz wtedy wrzucac do nich pliki przez drag&drop.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: El Mecánico w 16 Stycznia 2017, 15:00:00
[ciach] i tak jeszcze ze 100 razy. [/ciach]
Czyli kwestia tego, że mamy bardzo dużo słów kluczowych definiujących elementy taboru. Wiem, naleciałość z czasów, kiedy jedynym dostępnym edytorem do MaSzyny był zwykły edytor tekstu. A próbował ktoś kompilatora GNU? Może to ograniczenie dotyczy tylko kompilatora ze stajni M$?

[luźna_dywagacja]
A tak docelowo, to chyba trzeba będzie trochę wcześniej niż później przejść na jakiś (pre)kompilowany format zapisu danych konfiguracyjnych i odejście od postaci tekstowych.
[/luźna_dywagacja]
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 16 Stycznia 2017, 15:36:25
Czyli kwestia tego, że mamy bardzo dużo słów kluczowych definiujących elementy taboru. Wiem, naleciałość z czasów, kiedy jedynym dostępnym edytorem do MaSzyny był zwykły edytor tekstu. A próbował ktoś kompilatora GNU? Może to ograniczenie dotyczy tylko kompilatora ze stajni M$?
Inne kompilatory powinny sobie poradzic, standardowo limit to 256 tego typu blokow. Tak czy owak nie ma to juz znaczenia, rozbilem funkcje na pare blokow i chodzi, a w przyszlosci mozna to w ogole zautomatyzowac, np budujac w locie tabele elementow z otrzymanych typow/nazw, zamiast kodowania na sztywno.

@firleju merge zrobiony, podrzucilem pull request. Mozesz ciagnac kiedy ci pasuje :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 16 Stycznia 2017, 16:05:16
Aha, z zauwazalnych bledow -- cos jest na rzeczy z kolami/wozkami (moze innymi sub-modelami tez, nie przygladalem sie) W wagonach i samochodach przednie kola znikaja gdzies jak tylko pojazd zaczyna sie ruszac. W lokomotywach chyba jest w porzadku. Tak samo jest w tym skompilowanym .exe umieszczonym wczesniej w watku, czyli to nie moja wina ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 16 Stycznia 2017, 21:30:51
Ja i tak jestem szczęśliwy, że nie będę miał już dwóch środowisk do pracy. BCB mnie już doprowadzał do szału topornością. No, ale jak się nie dziwię, jak popatrzę na VS6 to obsługa wygląda podobnie, czyli raczej taki był standard tamtych czasów.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 16 Stycznia 2017, 21:44:44
Nadal nie wierzę :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 16 Stycznia 2017, 21:47:46
Cytat: Yoda
I dlatego ci się nie udaje.
:)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 16 Stycznia 2017, 21:52:59
Jak tak patrze w ten mover.cpp to tam wiekszosc jest tak jak bylo po moim tlumaczeniu, szkoda ze Firlej nie podkreslil bledow, teraz nie ma dowodow ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 16 Stycznia 2017, 21:54:39
Cesky, szykuj browary czy co tam mialo byc,  bo w tym przypadku opoznienie sie nie liczy :).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 16 Stycznia 2017, 21:59:19
Q, całą historię znajdziesz na githubie ;) Więc wszystko jest publiczne :D Zresztą ciężko popełniać błędy w czymś czego nie ma :DDDD
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 16 Stycznia 2017, 23:03:38
Aha, cppcheck znalazl takie cos w mover.cpp
            if ((TrainType != dt_ET22) ||
                ((TrainType == dt_ET22) &&
                 (ScndCtrlPos ==
                  0))) // w ET22 nie da si&ecirc; kr&ecirc;ci&aelig; nastawnikiem przy w&sup3;&sup1;czonym boczniku

Redundant condition: TrainType==dt_ET22. 'TrainType!=dt_ET22 || (TrainType==dt_ET22 && ScndCtrlPos==0)' is equivalent to 'TrainType!=dt_ET22 || ScndCtrlPos==0'
czyli warunek bedzie spelniony zawsze, gdy ScndCTrlPos = 0 albo gdy pociag nie jest typu ET22. Sadzac po komentarzu to nie jest dokladnie to, co autor mial na mysli, ale nie wiem co dokladnie autor mial na mysli, wiec wolalem nie ruszac... ale to prawdopodobnie przyczyna dlaczego sterowanie nie jest calkiem takie, jak powinno byc.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 17 Stycznia 2017, 00:04:02
W pascalu nie ma tu żadnych niejasności.
if (TrainType<>dt_ET22) or ((TrainType=dt_ET22) and (ScndCtrlPos=0)) then //w ET22 nie da się kręcić nastawnikiem przy włączonym boczniku
Kontrola nastawnika jest, jeśli pojazd nie jest et22 lub jest et22 z bocznikiem na pozycji 0.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: ryba825 w 17 Stycznia 2017, 00:14:41
Stele, skoro TrainType<>dt_ET22 jest fałszem to TrainType=dt_ET22 jest prawdą, więc skraca się do if TrainType<>dt_ET22 or ScndCtrlPos=0
Coś pominąłem?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 17 Stycznia 2017, 00:38:40
No TrainType=dt_ET22 and ScndCtrlPos<>0 dla którego ma być fałsz. Patrząc na nawiasy, to matematycznie powinno działać. A że cpp potrafi traktować to nieco inaczej, to już Grześ się przekonał wyżej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: ryba825 w 17 Stycznia 2017, 01:01:29
Żeby wzięło pod uwagę drugi warunek, to TrainType musi być dt_ET22, więc nie ma sensu sprawdzać tego drugi raz. Jeśli TrainType nie nie jest dt_ET22, to jest dt_ET22, więc tylko zerowość ScndCtrlPos jest brana pod uwagę. No chyba że w Pascalu porównanie i różność działają inaczej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 17 Stycznia 2017, 01:12:25
Istotnie, macie rację.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 17 Stycznia 2017, 01:37:20
Kontrola nastawnika jest, jeśli pojazd nie jest et22 lub jest et22 z bocznikiem na pozycji 0.
Czyli ujmujac to inaczej, jesli pociag to ET22 z bocznikiem na pozycji innej niz neutralna, to kontroli nie ma? Zmienilem zapis na
if( false == (( TrainType == dt_ET22 ) && ( ScndCtrlPos != 0 )) ) {
...
}
wychodzi na to samo, ale z malym rozumkiem troche latwiej to ogarnac :)

edit: a jak sie zastanowic, to mozna z tego wyrzucic negacje i po prostu od razu zwracac false, zamiast sie bawic w zagniezdzanie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 17 Stycznia 2017, 07:22:24
tmj, możesz też podrzucić solucję. Chcę mieć pewność, że czegoś nie zwaliłem podczas już lat pracy na dwóch środowiskach i 3 różnych wersjach VS. Jakąś zresztą będzie trzeba wrzucić na git-a.
Odnosząc się do warunku to chyba łatwiej będzie zapisać
if (TrainType != dt_ET22 || ScndCtrlPos == 0)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: surgeon w 17 Stycznia 2017, 17:02:55
Aha, cppcheck znalazl takie cos w mover.cpp
            if ((TrainType != dt_ET22) ||
                ((TrainType == dt_ET22) &&
                 (ScndCtrlPos ==
                  0))) // w ET22 nie da si&ecirc; kr&ecirc;ci&aelig; nastawnikiem przy w&sup3;&sup1;czonym boczniku

Redundant condition: TrainType==dt_ET22. 'TrainType!=dt_ET22 || (TrainType==dt_ET22 && ScndCtrlPos==0)' is equivalent to 'TrainType!=dt_ET22 || ScndCtrlPos==0'
czyli warunek bedzie spelniony zawsze, gdy ScndCTrlPos = 0 albo gdy pociag nie jest typu ET22. Sadzac po komentarzu to nie jest dokladnie to, co autor mial na mysli, ale nie wiem co dokladnie autor mial na mysli, wiec wolalem nie ruszac... ale to prawdopodobnie przyczyna dlaczego sterowanie nie jest calkiem takie, jak powinno byc.
Moim zdaniem wskazany fragment pascala został przetłumaczony prawidłowo. Po prostu można to skrócić do tego co zaproponował cppcheck i nadal będzie to działało tak samo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 17 Stycznia 2017, 18:21:29
tmj, możesz też podrzucić solucję. Chcę mieć pewność, że czegoś nie zwaliłem podczas już lat pracy na dwóch środowiskach i 3 różnych wersjach VS. Jakąś zresztą będzie trzeba wrzucić na git-a.
Dolaczam ta, ktorej uzywam, chociaz pewnie trzeba bedzie poprawic sciezke (skonfigurowany jest zeby ciagnac dsound.lib z instalacji directX SDK)

Uporzadkowalem troche IncMainCtrl() dla latwiejszego czytania, i bylbym wdzieczny gdyby ktos rzucil okiem, czy tam jest wszystko w porzadku pod wzgledem logiki, bo ja sie na pociagach az tak nie znam :)  zwlaszcza sekcja ElectricSeriesMotors:

// basic fail conditions:
if( ( CabNo == 0 )
|| ( MainCtrlPosNo <= 0 ) ) {
// nie ma sterowania
return false;
}
if( ( TrainType == dt_ET22 ) && ( ScndCtrlPos != 0 ) ) {
// w ET22 nie da si&ecirc; kr&ecirc;ci&aelig; nastawnikiem przy w&sup3;&sup1;czonym boczniku
return false;
}
if( ( TrainType == dt_EZT ) && ( ActiveDir == 0 ) ) {
// w EZT nie da si&ecirc; za&sup3;&sup1;czy&aelig; pozycji bez ustawienia kierunku
return false;
}

bool OK = false;
    if (MainCtrlPos < MainCtrlPosNo)
    {
switch( EngineType ) {
case None:
case Dumb:
case DieselElectric:
case ElectricInductionMotor:
{
if( CtrlSpeed > 1 ) {
OK = ( IncMainCtrl( 1 )
&& IncMainCtrl( CtrlSpeed - 1 ) ); // a fail will propagate up the recursion chain. should this be || instead?
}
else {
++MainCtrlPos;
OK = true;
}
break;
}

case ElectricSeriesMotor:
{
if( ActiveDir == 0 ) { return false; }

if( CtrlSpeed > 1 ) {
// szybkie przejœcie na bezoporow&sup1;
if( TrainType == dt_ET40 ) {
break; // this means ET40 won't react at all to fast acceleration command. should it issue just IncMainCtrl(1) instead?
}
while( ( RList[ MainCtrlPos ].R > 0.0 )
&& IncMainCtrl( 1 ) ) {
// all work is done in the loop header
;
}
// OK:=true ; {takie chamskie, potem poprawie} <-Ra: kto mia&sup3; to
// poprawi&aelig; i po co?
if( ActiveDir == -1 ) {
while( ( RList[ MainCtrlPos ].Bn > 1 )
&& IncMainCtrl( 1 ) ) {
--MainCtrlPos;
}
}
OK = false; // shouldn't this be part of the loop above?
}
else { // CtrlSpeed == 1
++MainCtrlPos;
OK = true;
if( Imax == ImaxHi ) {
if( RList[ MainCtrlPos ].Bn > 1 ) {
if( true == MaxCurrentSwitch( false )) {
// wylaczanie wysokiego rozruchu
SetFlag( SoundFlag, sound_relay );
}
if( TrainType == dt_ET42 ) {
--MainCtrlPos;
OK = false;
}
}
}
if( ActiveDir == -1 ) {
if( ( TrainType != dt_PseudoDiesel )
&& ( RList[ MainCtrlPos ].Bn > 1 ) ) {
// blokada wejœcia na równoleg&sup3;&sup1; podczas jazdy do ty&sup3;u
--MainCtrlPos;
OK = false;
}
}
}

if( ( TrainType == dt_ET42 ) && ( true == DynamicBrakeFlag ) ) {
if( MainCtrlPos > 20 ) {
MainCtrlPos = 20;
OK = false;
}
}
// return OK;
break;
}

case DieselEngine:
{
if( CtrlSpeed > 1 ) {
while( MainCtrlPos < MainCtrlPosNo ) {
IncMainCtrl( 1 );
}
}
else {
++MainCtrlPos;
if( MainCtrlPos > 0 ) { CompressorAllow = true; }
else                  { CompressorAllow = false; }
}
OK = true;
break;
}

case WheelsDriven:
{
OK = AddPulseForce( CtrlSpeed );
break;
}
} // switch EngineType of
    }
    else {// MainCtrlPos>=MainCtrlPosNo
if( true == CoupledCtrl ) {
// wspólny wa&sup3; nastawnika jazdy i bocznikowania
if( ScndCtrlPos < ScndCtrlPosNo ) { // 3<3 -> false
++ScndCtrlPos;
OK = true;
}
else {
OK = false;
}
}
    }
konkretnie to kawalek if( ActiveDir == -1 ) bo tam jednoczesnie zwieksza ciag o 1 uzywajac wywolanie IncMainCtrl(1) i zaraz w tej samej petli zmniejsza o 1, co wydaje sie troche bez sensu..? Aha, i jeszcze to, ze blok dla CtrSpeed > 1 zawsze zwraca false. Nie powinno to byc ograniczone tylko to pod-bloku ActiveDir == -1, tak jak w pozostalych miejscach?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 17 Stycznia 2017, 21:36:03
Na mojej wersji mam 44 errory, najczęściej związane z char* niezgodny z LPCWSTR. Ściągam repo tmj i zobaczę na nim czy czegoś nie zwaliłem razem z łączeniem.

EDIT:
Nie chce mi się bawić. Nadgrywam na moje repo solucję tmj, bo tak będzie szybciej i prościej niż szukanie różnic w ustawieniach.

EDIT2:
Ranna sesja zakończona pomyślnym zbudowaniem. Niestety brakuje jakiejś dll-ki. Gdzie są wpisane .lib których używa przy budowaniu?

EDIT3:
Już wiem co się stało z dll-k - mam jakiś błąd instalacji VS i muszę przeinstalować jeden komponent. Lib-y już też znalazłem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 18 Stycznia 2017, 08:04:54
Jesli brakuje .dll to najprawdopodobniej glew32.dll, ze strony glew ( http://glew.sourceforge.net/ )  poprzednio bylo to chyba laczone statycznie, i domyslnie brakuje jej w paczce z maszyna.

Wrzucilem na githuba male uaktualnienie -- glownie poprawiona wiekszosc memory leaks, przy okazji poczyscilem troche komponenty do hamulcow itp, wylazlo tam kilka wiecej nieinicjalizowanych zmiennych ;)  teraz beda chyba wszystkie, moze poprawi to troche niektore ze zgloszonych bledow, a moze nie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 18 Stycznia 2017, 08:44:40
Glew już ściągnąłem, gdyż nie budował ;) Teraz lib jest także na repo.
Ja bym Cię prosił, żeby jednak używać CamelBack do nazw funkcji.

EDIT:
Ta dll-ka to jest komponent vsredist, a dokładnie ucrtbased.dll.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 18 Stycznia 2017, 19:49:37
Podlaczylem z powrotem otwieranie drzwi, choc na razie jest po chamsku zakodowane na sztywno dla skladow EZT
Docelowo powinien to byc zapewne wpic w .mmd albo coos, z tym ze w takiej sytuacji powinno to nastapic przed ladowanie glownego pudla, zeby kod byl w stanie podczepic prawidlowa wersje funkcji animujacej.

edit: znalazlem przyczyne znikajacych niektorych osi -- kod ladujacy pliki .fiz potrafil ustawic srednice na 0.0 (kiedy parameter nie byl podany) i przepuszczal to, bo mial zle ustawiony warunek brzegowy. W rezultacie przy kalkulacji obrotow bylo dzielenie przez 0. Teraz powinno byc dobrze, ale moze warto zmienic funkcje getkeyval() na cos w stylu bool getkeyval( _Type &Parameter, std::string const &Key) wtedy bedzie mogla automatycznie uaktualnic docelowa zmienna, a jak nie znajdzie wartosci to zwroci false. I przy okazji odpadnie koniecznosc recznego definiowania typow.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 19 Stycznia 2017, 07:07:34
getkeyval to wytwór Q. Najlepiej by było chyba zrobić wersję z parametrem domyślnym w przypadku nie znalezienia słowa kluczowego.
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ć.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: El Mecánico w 19 Stycznia 2017, 13:35:31
Dobrze by było, aby każda krytyczna zmienna miała domyślną wartość początkową ustawioną na jakąś bezpieczną wartość...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 19 Stycznia 2017, 17:12:31
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)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 19 Stycznia 2017, 17:38:03
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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 19 Stycznia 2017, 18:12:24
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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 19 Stycznia 2017, 18:16:53
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)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 19 Stycznia 2017, 18:21:55
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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 19 Stycznia 2017, 18:27:27
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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 19 Stycznia 2017, 18:33:02
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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 19 Stycznia 2017, 18:42:20
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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 19 Stycznia 2017, 18:45:17
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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 19 Stycznia 2017, 18:56:52
To zanim zaczniesz się bawić przeglądnę wszystkie pliki i spróbuję naprawić kodowanie. a potem konwersja na UTF-8.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 19 Stycznia 2017, 20:26:13
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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: ryba825 w 19 Stycznia 2017, 20:45:16
Używacie jakichś linterów? Formatowanie kodu (wcięcia) wygląda jakby decydowała o tym funkcja "random". ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: ryba825 w 19 Stycznia 2017, 20:54:41
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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 19 Stycznia 2017, 21:09:54
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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: ryba825 w 19 Stycznia 2017, 21:19:30
Używam 2 spacji w Rubym i Javascripicie i nie mam problemu z czytelnością. ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 19 Stycznia 2017, 22:10:05
Ja tez bylem kiedys mlody i mialem dobre oczy. ;d
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: ryba825 w 19 Stycznia 2017, 22:18:42
To już od Was zależy. Ja tylko proponuję. ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 20 Stycznia 2017, 07:37:45
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ć.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 20 Stycznia 2017, 08:47:03
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
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 20 Stycznia 2017, 08:52:31
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?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 20 Stycznia 2017, 09:10:11
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 ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 20 Stycznia 2017, 10:44:45
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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 20 Stycznia 2017, 16:10:49
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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 20 Stycznia 2017, 17:09:12
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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 20 Stycznia 2017, 18:58:25
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:
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?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 20 Stycznia 2017, 19:00:24
Wiersze są ponumerowane od 0 do size, czyli jest ok ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 20 Stycznia 2017, 20:06:26
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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 20 Stycznia 2017, 20:47:33
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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 20 Stycznia 2017, 21:46:30
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:

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 20 Stycznia 2017, 21:56:23
Ja za to robię już prawdopodobnie ostatni plik. Choć teraz idzie trochę po grudzie, bo muszę się bawić w sprawdzanie ręczne każdej zmiany. Poczeka do jutra, idę spać.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 20 Stycznia 2017, 22:46:02
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:
Co do Size - w Pascalu działało i w ten sposób można było zaczytać np. tylko 8 wierszy z 10.

MPT0 umożliwia podanie dodatkowej wartości (oidp fi0) dla lepszego dopasowania charakterystyki. MPT przypisywało jej wartość 0.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 20 Stycznia 2017, 23:29:42
MPT0 umożliwia podanie dodatkowej wartości (oidp fi0) dla lepszego dopasowania charakterystyki. MPT przypisywało jej wartość 0.
Hmm tu w ogole bajzel troche jest:

h9-21 (DieselEngine)
MotorParamTable: minVelfullengage=9.5 engageDia=0.352 engageMaxForce=2000 engagefriction=0.8
0 0 0 -1
1 6.93 -1 10
2 4.03 4 28
3 2.36 15 50
4 1.40 25 88
5 1.00 47 100
END-MPT 

301d (DieselElectric)
MotorParamTable:
0 20 100 3000 20.8 1340 1713
1 18.5 110 2700 25 1340 1713
2 17.2 135 2500 30 1340 1713
3 14.3 170 2000 48.5 1340 1713
END-MPT 

rozumiem, ze parametry sa rozne w zaleznosci od typu silnika, ale trzeba to jakos uporzadkowac, bo parser glupieje. Albo switch mozna dac, ale ktore parametry i w jakiej kolejnosci sa wpisane w jednej i drugiej wersji?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 21 Stycznia 2017, 09:18:21
To wszystko wynika stąd, że zmienne są współdzielone między różnymi rodzajami silników.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 21 Stycznia 2017, 17:12:06
OK, ale ktore zmienne sa podane w ktorej wersji, bo teraz sa co najmniej 3 warianty, i kazdy inny. Z tego co moge znalezc w wersji Pascalowej to jest:

MotorParamTable
ElectricSeries: (wiersz) mfi, mIsat, fi, Isat, (opcja autoswitch)
DieselElectric: (wiersz) mfi, mIsat, fi, Isat, MPTRelay[k].Iup, MPTRelay[k].Idown
DieselMotor: (wiersz) mIsat, fi, mfi, (opcja autoswitch)

MotorParamTable0
(wiersz) mfi, mIsat, mfi0, fi, Isat, fi0, (opcja autoswitch)

czy to sie wszystko zgadza, czy cos zle czytam?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 21 Stycznia 2017, 21:37:38
OK, jeszcze jedno glupie pytanie, jak juz przy tym jestem. Do ladowania zawartosci tablicy DList w wersji Pascalowej uzyte jest:

(wiersz), RList[k].Relay, RList[k].R, RList[k].Mn

To sa cztery parametry, ale we wszystkich plikach .fiz sa podawane tylko 3. Czy 4-ty jest opcjonalny, czy jest to jakos inaczej obslugiwane?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 22 Stycznia 2017, 11:09:33
Do zrobienia zostały mi dwa pliki z głównego katalogu (DynObj.cpp i EU07.cpp) i do sprawdzenia wszystkie podkatalogi. Jest weekend więc prace prawie nie idą. Pewnie skończę dopiero w tygodniu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 22 Stycznia 2017, 17:18:56
W takim razie, jesli mozesz, pchnij to co jest zrobione do tej pory? Podlacze sobie na swoim koncu, i bedzie mniej roboty jak skonczysz reszte.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 22 Stycznia 2017, 19:06:20
Dopiero jak wrócę do domu. Teraz w gościach bawię się w domowego informatyka.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 23 Stycznia 2017, 04:50:51
Z ciekawostek: po wprowadzeniu bardziej kompletnego ladowania plikow .fiz i poprawek dla najbardziej widocznych bledow .exe uruchamia sie takze i nawet dziala w trybie release. Release to w tej chwili jazda po bandzie, bo w kodzie na 100% sa jeszcze kwiatki w stylu czytania danych nie stamtad, gdzie trzeba, ale skok wydajnosci jest calkiem niezly -- np scenariusz Calkowo, ktory oficjalny .exe z paczki laduje u mnie 90 sekund, w nowym .exe wchodzi w 35 ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 23 Stycznia 2017, 07:02:15
No mam nadzieję, że nie startowałeś na exe z paczki na zimno, a na nowym na ciepło. Wrzuciłem te pliki, które już zrobiłem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 23 Stycznia 2017, 10:33:03
No mam nadzieję, że nie startowałeś na exe z paczki na zimno, a na nowym na ciepło.
Bogdan, ja Cie prosze :) Uruchamiane naprzemiennie kilka razy; na zimno to .exe z paczki meczy sie jakies 2 minuty.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 23 Stycznia 2017, 12:06:50
Heh, tylko wiesz, że c4 już skompilowałem w release i działało ;) I nie mam na imię Bogdan :P
Ale dobrze wiedzieć, że wreszcie widać jakieś konkretne efekty wywalenia Borlanda.
Mnie pozostały jeszcze tylko podkatalogi, więc jeśli nie zasnę zaraz po obiedzie to może uda się dzisiaj to zrobić.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 23 Stycznia 2017, 14:04:39
Ja wlaczylem u siebie exceptions dla bledow koprocesora, wiec release wylatywal praktycznie natychmiast :d  Teraz jest juz troche lepiej, chociaz w duzej mierze losowo, bo ZTCW funkcje zwiazane z konstrukcja geometrii lubia sobie pisac gdzie chca, wiec czasem wszystko dziala, a czasem jest sieczka. Debug w zasadzie chodzi przyzwoicie caly czas.
Polaczylem to co zrobiles z moimi poprawkami i na razie lezy i czeka na reszte.
A Bogdan to z takiej glupiej reklamy, jakos tak wbila mi sie w pamiec ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 23 Stycznia 2017, 15:36:23
Wszystkie pliki na utf-8 już na repo. Mogę spokojnie iść spać.
Ahh, jeśli masz jakieś poprawki do solucji to je wrzuć na repo a nie kasuj całej solucji z repo ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 23 Stycznia 2017, 19:16:55
OK, polaczylem poprawki, pull request wyslany.
Przepuscilem przez ta wersje scenerie z paczki calosciowej, wyglada na to ze (prawie) wszystko dziala. Z rzeczy do sprawdzenia jest prawdopodobnie konwersja z t3d -> e3d, symulator sie na tym (lub w okolicach) wysypuje, przy ladowaniu linii 61. Jesli wylacze konwersje w pliku .ini to wchodzi.
Aha, plikow solucji nie dotykalem, ale mam lokalnie *.sln i inne rzeczy z VS wrzucone do ignore, wiec moze git cos tam miesza. Jak znowu sprobuje cos tam kasowac to daj znac, dodam tez do swojej wersji na wszelki wypadek.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 24 Stycznia 2017, 07:44:52
Tak specjalnie zrobiłeś pull-a na mastera a nie na mover_c++ ???
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 24 Stycznia 2017, 10:01:17
Nie, sorry, kliknalem tylko w "compare & pull" i nawet nie spojrzalem, do glowy mi nie przyszlo ze on to tam wrzuci, bo poprzednim razem ustawil wszystko prawidlowo, i to jest branch od mover_in_c++ a nie od master. Moze GitHub cos sam wymyslil jak zobaczyl, ze nie ma konfliktow. Zaraz poprawie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 24 Stycznia 2017, 11:17:26
Aha, przy okazji. Nie bede robil kolejnego commita tylko dla takiego drobiazgu, ale jak mozesz to zmien deklaracje w VBO.h na:
class CVertNormTex
{
  public:
    float x = 0.0; // X wierzchołka
    float y = 0.0; // Y wierzchołka
    float z = 0.0; // Z wierzchołka
    float nx = 0.0; // X wektora normalnego
    float ny = 0.0; // Y wektora normalnego
    float nz = 0.0; // Z wektora normalnego
    float u = 0.0; // U mapowania
    float v = 0.0; // V mapowania
};
wyglada na to, ze inicjalizacja usuwa wiekszosc smieci z renderingu w trybie release, i staje sie on calkiem uzywalny, takze przy wylaczonym uzyciu VBO.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 24 Stycznia 2017, 12:50:25
Wiekszosc zgloszonych bledow nt. niefunkcjonujacych lokomotyw itp. powinna byc juz usunieta w tej wersji, przyczyna bylo niekompletne ladowanie definicji z plikow .fiz i pare bledow w komponentach. Tak wiec po nowych testach mozesz miec mniej do szukania ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 24 Stycznia 2017, 16:41:55
Testów nie będzie, gdyż nie kompiluje projektu ze względu na Severity Code Description Project File Line Suppression State
Error C2338 The C++ Standard forbids containers of const elements because allocator<const T> is ill-formed. (compiling source file EU07.cpp) maszyna c:\program files (x86)\microsoft visual studio 14.0\vc\include\xmemory0 665
Kompiluje w VS2015. Błąd się pojawił w commicie 6ab550831dc4fd8508362ff075f476ec46c6bd4c "basic patches for most of discovered memory leaks, fixes for brake system components"

EDIT:
Zmiany dotyczące elementów const były tylko w hamulcach i pythonie. Wstępnie hamulce odrzuciłem więc został tylko python do sprawdzenia. Teraz niestety przerwa z mojej strony gdyż wychodzę i wrócę pewnie dopiero wieczorem, więc następne prace pewnie rano w pociągu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 24 Stycznia 2017, 17:44:07
W PyInt.h zmien

std::set<std::string const> _classes;
na
std::set<std::string> _classes;

i powinno pomoc.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 25 Stycznia 2017, 07:50:42
No tak przypuszczałem, że to pomoże. Przy okazji wyszło, że twój pull wywalił także glew.lib z katalogu opengl. Przywracam i po modernizacji funkcji losującej (przejście na <random> i normalne losowanie z wybranego zakresu, a nie taka prowizorka jaka jest) wrzucę exe na testy.
Info dla tych, którzy dziwili się, że dostają radiostop za każdym razem na l61. Nie dziwota jeśli funkcja losująca w paszczalu były błędnie użyta i za każdym uruchomieniem exe losowała te same liczby :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 25 Stycznia 2017, 16:29:49
Najnowsze exe to sprawdzenia. Tmj twierdzi, że część błędów już nie powinna być obecna.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: RoboBatman w 25 Stycznia 2017, 17:27:21
Przy próbie przetestowania exe na scenerii TD razem z EU07-195, po wciśnięciu przycisku "Uruchom symulator" wywala mi oto taki komunikat o braku pliku:
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 25 Stycznia 2017, 17:30:36
U mnie na początek taki: brak msvcp140.dll
W zasadzie mogę brakujące pliki pościągać, tyle że robiąc to nie mam pewności źródła. Stąd myślę, że warto dodawać do nowych kompilacji biblioteki które są nowością dla danego numerku.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Stycznia 2017, 17:43:44
glew.dll na oficjalnej stronie glew: http://glew.sourceforge.net/ (wersja 'binaries', bezposredni link: https://sourceforge.net/projects/glew/files/glew/2.0.0/glew-2.0.0-win32.zip/download )
biblioteki msvc z oficjalnej paczki Microsoft: https://www.microsoft.com/en-us/download/details.aspx?id=48145
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 25 Stycznia 2017, 18:10:29
Wymaga redist-a także dla release? Hmmm...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Stycznia 2017, 19:27:36
Mozesz  to zmienic w opcjach projektu: C++ > Code Generation > Runtime Library, domyslnie jest DLL w wersji debug albo release (dlatego release tez wymaga)  Jesli ustawisz tam tylko "multi-threaded/multi-threaded debug" to procedury z DLL beda wlaczone do .exe... ale moim zdaniem to niepotrzebne, VC Runtime jest standardowo dolaczany do instalacji kazdej profesjonalnie wydanej gry, wiec wiekszosc uzytkownikow albo juz bedzie to miala, albo jesli jest dolaczone do paczki to sobie bez problemu zainstaluje, nie jest to jakies szczegolne wymaganie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 25 Stycznia 2017, 19:53:57
Na czas testów można by włączyć.
Sypie się na zapisie e3d. W dziwnym miejscu bo ma out_of_range na t.substr(t.rfind). Trzeba też sprawdzić ukrotnienie bo RoboBatman zgłasza wysyp.
Już wiem, szukanie rozszerzenia kończy się wartością npos, która na substr zwraca właśnie out_of_range.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 25 Stycznia 2017, 20:25:23
W siódemce nie działa odluźniacz (6 na klawiaturze numerycznej). Animuje się przycisk, jednak nie spuszcza z cylindrów powietrza. Ciśnienie pozostaje na 4,4. Na innych pojazdach nie wiem. Zagrypiłem się na maxa, nie idzie testowanie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Stycznia 2017, 20:26:50
Trzeba tez chyba zerknac na wyswietlanie ladunku w wagonach, bo np. 163 pokazuja pasazerow w oficjalnym .exe, a w tej same scenie w nowym sa puste.

Tak przy okazji, to w plikach .mmd do tych wagonow jest blad -- wpis lowpolyinterior: jest umieszczony przed animations: i w rezultacie w ogole nie laduje animacji do nich.

ale z drugiej strony, z pozytywnych rzeczy to po poprawce .mmd dziala animacji drzwi. Tzn. normalnie to nie dziala, bo laczenie domyslne to sprzeg + pneumatyka, i nie przekazuje sygnalow kontrolnych, ale jak sie to obejdzie, to wszystko chodzi ;)

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Stycznia 2017, 22:32:25
Znalazlem, co bylo nie tak z brakiem ladunku w wagonach -- po prostu loader .fiz nie mial wpisanego przekazania akurat tej zmiennej do docelowego obiektu. W sumie zemscilo sie lenistwo, gdybym przerobil wszystkie sekcje, zeby uzywaly nowej wersji funkcji, to pewnie by to wyszlo, a tak przegapilem :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Stycznia 2017, 03:00:47
Znalazl sie tez blad w odluzniaczu. W oryginale w Pascalu bylo
procedure TBrake.Releaser(state: byte);
begin
  BrakeStatus:=(BrakeStatus and 247) or state*b_rls;
end;

w tlumaczeniu bylo

BrakeStatus = (BrakeStatus & 247) || state * b_rls;

a powinno byc

BrakeStatus = (BrakeStatus & 247) | ( state * b_rls );

bo w C++ logiczne or czyli || i or bitowe czyli | to sa dwie rozne operacje. Ot tak, zeby latwiej sie bylo powiesic ;d

(tak na 90% ten blad wyskoczy jeszcze pewnie gdzie indziej, bo wystapil co najmniej w dwoch przupadkach, ale wybitnie nie chce mi sie czesac calego pliku zeby sprawdzic czy aby na pewno. Moze kiedys)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 26 Stycznia 2017, 07:02:13
No ten ostatni to mojsza błęda. W zasadzie te kwiatki powinny występować tylko przy brakestatus więc to można łatwo sprawdzić.
Na pocieszenie exe c6 z poprawionym wysypem na zapisie e3d oraz szukaniu eventów skanowanych. Nie ma poprawek tmj (jeszcze).
W archiwum glew.dll a w exe brak zależności od plików ze strony microsoftu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Stycznia 2017, 19:26:43
Polaczylem i pchnalem poprawki z mojej strony. Jesli to mozliwe, to na przyszlosc chyba dobrze byloby przesunac pliki visual studio do "untracked files" w zakladce git'a (przeciagnij je z "Included Changes" do "Untracked Files" i VS bedzie to juz pamietal) bo inaczej bedziemy je sobie na przemian nadpisywali, co jest troche bez sensu :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 26 Stycznia 2017, 20:20:34
W 2015CE nie ma tej opcji :(
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Stycznia 2017, 20:26:16
A to widac cos pozmieniali :/  to mozna chyba tez przelaczyc w .gitignore, te trzy linie:
*.sln
*.vcxproj
*.filters
trzeba je tylko odkomentowac. na 100% nie jestem pewien, ale powinno pomoc, moze byc tez potrzebne git rm tak jak to opisali tutaj: https://www.visualstudio.com/en-us/docs/git/tutorial/ignore-files ale warto sprobowac.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 27 Stycznia 2017, 00:46:30
Sprobowalem zaladowac Kaliska do nowego .exe, ale glupial na starcie bo nie mogl rozgryzc ukladu torow przy niezainicjalizowanych zmiennych. Dopisalem wiec pelna inicjalizacje do kilku najczesciej uzywanych typow, zeby bylo bardziej jak w Borlandzie. Teraz uruchamia Kaliska gladko, i przy okazji obrotomierze przestaly sie glupio krecic na starcie. Przy odrobinie szczescia powinno to tez naprawic okazyjny blad z kamera robiaca caly czas powolny zoom.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 27 Stycznia 2017, 08:05:29
Ja się wk... i robię refactoring tabelki prędkości bo to co jest jest nienaprawialne. Nie musisz robić pull-a. Mam Cię jako remote i ewentualnie mogę sam robić merge-a. Wystarczy, że wyślesz na serwer zmiany.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 27 Stycznia 2017, 22:52:22
Wymienilem tablice Dynamics w torach na deque z stl -- efektow negatywnych nie widac, natomiast ma to potencjalnie pozytywny efekt usuniecia limitu 40 pojazdow na tor.

edit: podmienilem kilka dodatkowych drobiazgow i poprawilem kilka malych bledow. Grubszych spraw na razie nie ruszam, zeby nie kolidowalo z tymi zmianami skanowania, czy co tam robisz.

Dolaczona wersja .exe ma wbudowana poprawke na czytanie cudzyslowow w plikach konfiguracji, jesli ktos chce sie bawic w testowanie uaktualniania konfiguracji do standard yaml. Albo inne testy :)

Co do grubszych zmian, zastanawiajac sie nad tym, co powinno byc zrobione, wyszla mi nastepujaca lista:

* rozdzielenie symulacji od wizualizacji. Czesc z tego jest juz chyba zrobiona, ale docelowo kompletny uklad torow i lista poruszajacych sie po nich obiektow, obsluga eventow + kalkulacje fizyki dla tych obiektow powinna pracowac praktycznie niezaleznie jako odrebny modul. Stan obiektow symulacji moze byc podawany zainteresowanym sluchaczom, a czy tym sluchaczem jest silnik graficzny (czy wrecz caly klient w systemie multiplayer), przekaznik informacji dla pulpitu, modul kontroli ruchu czy jeszcze cos innego, to juz symulacji nie obchodzi.

* powiazane z powyzszym i opcjonalna, reorganizacja sterowania symulacja na uklad dwustopniowy -- pomijajac siec trakcyjna, stopien pierwszy czyli 'swiat' symulacji zredukowany jest do ukladu torow i uniwersalnych 'punktow sygnalowych' ktore sa zrodlem instrukcji dla AI pojazdow, i z reguly umieszczone sa tam, gdzie znajduja sie fizyczne wskaznikow/sygnalow/itp. Konkretne jakie instrukcje emitowane przez punkty sygnalowe zalezy od stopnia 2-ego, tj. skryptu i/lub modul(ow) spietych z danym punktem. Uprosciloby to tworzenie scenerii -- uklad torow i wskaznikow robiony jest raz, a kontrola sygnalow zajmuje sie juz modul kontrolera, w zaleznosci od otrzymanego scenariusza. I czy tym kontrolerem jest modul AI, czy zywy czlowiek albo nawet kilku, to juz symulacji nie obchodzi.

* opcjonalne, uporzadkowanie zmiennych w glownych klasach. Te wieksze maja cos z 50+ parametrow, wszystko wrzucone na jedna kupe. Trudno dojsc co jest pobierane z plikow konfiguracji, co jest kalkulowane, co nie jest uzywane w ogole. Pogrupowanie tego w sensowne struktury ulatwiloby punkt nastepny

* krytyczne, wprowadzenie zapisu 'swiata' z poziomu symulatora, i wczytywanie tego zapisu. Glownie majace na celu uproszczenie i przyspieszenie edycji scenerii; zamiast zabawy edytorami tekstu, zewnetrznymi narzedziami itp powinno to byc cos, co robisz bezposrednio w programie i "what you see is what you get". Zamiast zgadywac, jak prezentuje sie obiekt umieszczony w scenerii, po prostu mozna to od razu zobaczyc, tak jak i wprowadzane poprawki. W polaczeniu ze zmianami powyzej pozytywnym efektem ubocznym mogloby byc tutaj przyspieszenie ladowania scenariuszy -- program moglby wczytac od razu uklad torow i zestaw pojazdow, a nastepnie doczytac sobie w locie dane potrzebne do wizualizacji.

edit 2: poprawka, bo z rozpedu dolaczylem stara wersje. Tak to jest jak sie trzyma plik binarny w innym katalogu ;/
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: szogun w 30 Stycznia 2017, 08:31:32
Zastanawia mnie czemu pierwsze wczytanie TD trwa 4-6 sekund, a za drugim razem to już tylko sekunda? Exe z ostatniego załącznika nie działa, winda się pluje że nie jest prawidłową aplikacją.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 30 Stycznia 2017, 09:06:35
Bo ma wszystkie assety na ramie. Zawsze kolejne wczytywanie tego samego było szybsze.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 30 Stycznia 2017, 16:28:29
Exe z ostatniego załącznika nie działa, winda się pluje że nie jest prawidłową aplikacją.
Hmm a jaka to wersja windy? Kompilowane bylo z ustawieniem od Visty w gore, nie wiem, czy pojdzie na czyms starszym.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Sowik2 w 30 Stycznia 2017, 16:33:02
No właśnie, a u mnie (niestety) jeszcze poczciwy Xp-ek.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 30 Stycznia 2017, 16:52:01
OK, przekompilowalem z ustawieniem na xp i nowsze. Nie wiem, czy cos zmieni, ale miejmy nadzieje, ze tak.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 30 Stycznia 2017, 18:59:22
Wsparcie dla xp ma być albo zwijam zabawki. :D Zaraz przetestuję czy działa.
Nie działa. Nieprawidłowa aplikacja Win32.
A Mariusz prosi o kompatybilność w Win98 SE. ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 30 Stycznia 2017, 19:27:28
Ściągnąłem z ciekawości i odpaliłem TD - wygląda, że działa, nawet sobie pojechałem. Rzuciłem więc exeka na głębszą wodę i spróbowałem odpalić swoją scenerię, ale niestety program się wywala - wygląda na to, że wysypuje się na wczytaniu tekstury *.bmp. Dotyczy zarówno exeka @tmj pod xp, jak i 483c6 od @firleju.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 30 Stycznia 2017, 19:30:27
No zesz koorna, to juz nie wiem. Kompilacja chyba ma domyslnie wlaczone uzywanie SSE w procesorze i takie tam, ale jesli w ogole, to by chyba raczej powodowalo inny rodzaj bledow. Nie mam tu xp, wiec nie moge sprawdzic. A ta wersja co ja firleju robi uruchamia sie u Ciebie?
Moge przestawic kompilacje na 98se, ale jak nie widzi tego jako prawidlowa aplikacje, to bedzie sztuka dla sztuki ;/

fake edit: przyjrze sie ladowaniu bmp przy okazji, choc tam chyba nic nie bylo ruszane.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 30 Stycznia 2017, 19:42:29
exec++ się nie uruchamia, wyświetla nieprawidłową aplikację na winxp. Otwierane przez rainsted, brak kompletnie reakcji.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 30 Stycznia 2017, 19:43:46
C6 od Firleja działa.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 30 Stycznia 2017, 19:53:28
Firlej, ustawiales cos extra w parametrach kompilacji?

Ladowanie BMP faktycznie wyglada na skopane, ale tak juz mial 'od urodzenia' -- funkcja traktuje wszystkie pliki jako 24bit, tak ze jak cos ma alpha channel, to sie sypie i w najlepszym wypadku wychodzi sieczka. Poprawie to troche w miedzyczasie, przynajmniej minimalnie, w dekompresje RLE raczej bawic sie nie bede.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 30 Stycznia 2017, 20:11:23
C6 działa, nawet jakoś ładniej się wczytuje i wygląda. Nie no, nadal nie ma naprawionego odluźniacza, dlatego chciałem to od tmjota;) Co do BMP, nigdy nie było wysypów na teksturach BMP, więc jeśli od urodzenia co tam jest nie tak, to jest to wiadomość zaskakująca. No chyba, że mnie przy czymś nie było i przegapiłem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 30 Stycznia 2017, 20:21:40
Dokonałem eksperymentu i przekonwertowałem sobie teksturę do *.dds, zostawiając ten sam model - teraz działa na obu exekach. Zatem faktycznie coś jest nie tak z ładowaniem tekstur *.bmp.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: guest23436 w 30 Stycznia 2017, 20:34:48
Czy było coś zmieniane w animacji patyków? W mojej EP02 - 08 nie podnoszą się, co na starym exe się działo.
Albo ja czegoś nie umiem, albo nie da się na tym exe (exe++) ruszyć ganzem i SM04.

Poza tym bez zarzutów.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 30 Stycznia 2017, 20:42:23
OK, pogrzebalem troche i okazalo sie, ze do kompilacji dla xp jest osobne ustawienie w vs2013. Przelaczylem i skompilowalem jeszcze raz, jesli mozesz to sprawdz, czy robi to jakas roznice?

Ladowanie BMP jest poprawione. Uwaga: tekstury BMP musza byc zapisane bez kompresji, a dodatkowo w porownaniu do .dds sa obrocone w pionie. W sumie chyba wygodniej Ci bedzie pracowac z TGA/DDS, ale przynajmniej nie powinno sie na nich teraz wysypywac.

edit: sn61 w testach ktore robilem dzialal, ale trzeba dosc dlugo przytrzymac rozruch zeby zaskoczyl. SM03 moze miec klopoty, bo w ogolnym kodzie hamulcow czy czego tam jest blad ktorego jeszcze nie poprawilem (w szczegolnych sytuacjach dochodzi do wyciagania pierwiastka z liczby ujemnej i cala symulacja glupieje)  EP02 nie mam, wiec nie wiem, ale pozostale dzialaja normalnie, po zalaczeniu baterii.

edit2: hmm sprawdzilem dla pewnosci i masz racje, teraz nie odpala. sprawdze co tam w miedzyczasie popsulem ;/
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 30 Stycznia 2017, 20:55:15
Odpala na winXP, tu jest ok, natomiast ganz ni huhu. Coś jest zepsute w stosunku do C6, bo tam ganz ładnie pali.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 30 Stycznia 2017, 21:02:29
Nadal się wysypuje na BMP, ale umówmy się, że a) nie jest to istotny bład; b) nie sprawdzałem, czy ten plik spełnia warunki, o których piszesz. Jedyne co mnie dziwi to fakt, że na poprzednich exe z tymi plikami działało to bez problemu. Pracuję na BMP jako teksturach roboczych, bo taki plik najszybciej można poprawić w razie potrzeby, ale i tak muszę je w końcu skonwertować do TGA/DDS, więc jest to do przeżycia.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 30 Stycznia 2017, 21:04:18
Jesli to nie problem to doczep ten plik .bmp ktory sprawia problemy do tego watka, zerkne pozniej co z nim moze byc nie tak.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 30 Stycznia 2017, 21:25:18
Musiałem spakować, bo forum nie łyka BMP.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 30 Stycznia 2017, 22:06:32
Na XP działa. Dziewiątka AI się uruchomiła, przejechała do wyjazdowego z TD i zahamowała bez problemów. Pod F1 w debugu jest fps zamiast diagnostyki, ale to zapewne zamierzone.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 30 Stycznia 2017, 22:09:59
@tmj, do planowanych zmian i myśli proponuję założyć osobny wątek bo tu się dużo rzeczy traci.
Trzeba by wyczyścić repo z nieużywanych plików, lub ewentualnie przenieść je do jakiegoś osobnego katalogu. To są wszystkie pascalowe plus parę z c++. Co proponujesz?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 30 Stycznia 2017, 23:17:01
Ten plik BMP ma naglowek w nowszym standardzie i wiekszy niz to, czego maszyna oczekuje, dlatego szedl w maliny. Wstawilem test dla bezpieczenstwa, wiec sie juz nie wywali przy ladowaniu, ale i tak nie obsluguje tego pliku zbyt dobrze. W sumie TGA/DDS beda mniej problematyczne, jesli Ci to nie przeszkadza.

Doszedlem, czemu spalinowe nie dzialaja. Zrobilem zle zalozenie przy odczycie DList, i wylazlo przypadkiem po zmianie kodu parsera. W sumie dziwne, ze dzialalo przedtem :)  Poprawione, znowu chodza. Uaktualnione .exe w zalaczniku.

Co do watku, chyba jak najbardzie. Co do zmian -- ja tu w sumie tylko troche sprzatam ;)  podlacz z moich poprawek ktore chcesz, poukladaj pliki tak, jak Ci pasuje, a ja sobie sciagne zmiany i sie dostosuje.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 30 Stycznia 2017, 23:22:39
Zgadza się, ganz odpalił. Dajcie znać jak publikacja będzie wspólna, bo tak to trochę rozczep jaźni jest co gdzie i u kogo. Aha, odluźniacz działa. Jakby ktoś pytał, ukończyłem pięknie Bałtyk.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 30 Stycznia 2017, 23:34:43
Ja na razie zastopuje z moimi -- pchnalem najnowsza wersje do Gita, tak ze Firleju moze sobia spokojnie zrobic to, nad czym pracuje, polaczyc te wersje i poustawiac pliki, a potem sie zobaczy :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 30 Stycznia 2017, 23:59:00
Poproszę o łopatologiczną instrukcję kompilacji. Jaka wersja VS by to działało. Co poustawiać w opcjach projektu by było dobrze. Krzyś będzie za mną łaził z bajerami od Q, to wypadałoby ogarnąć kompilację w nowym środowisku. Najlepiej w nowym wątku to.
Problem z większym nagłówkiem ma też rainsted. Wyprosiłem u Ra konwerter do starszego formatu. Tylko tam jest to problem używania bibliotek systemowych do obsługi bmp, przez co na XP nie czytało mi plików zrobionych w nowych paintach.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 31 Stycznia 2017, 00:02:45
Zapomnialem w rozkladzie zamiast bałtyk bylo ba,tyk. Takze nazwa pod f1 byla tak znieksztalcona.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 31 Stycznia 2017, 00:52:41
O ile sie nie myle to pliki projektow sa na chwile obecna w obu wersjach zrodel -- w mojej dla VS2013, u Firleju do VS2015. Tak ze teoretycznie wystarczy sciagnac wersje pasujaca do wersji VS ktora masz, i zaladowac plik maszyna.sln w Visual Studio. Moze byc tez potrzebna instalacja directX SDK ze strony Microsoftu, zeby dalo sie dolaczyc .lib do dzwieku. Sciezki do bibliotek itp w zasadzie powinien wszystkie miec, ale jesli trzeba to mozna je dopisac we wlasciwosciach projektu, jak na zalacznikach.

Litery w rozkladach u mnie tez sa dziwne, ale zalozylem ze to dlatego, ze u mnie jest angielskojezyczny windows bez polskich liter, i on ma kodowanie plikow ascii inaczej niz wersja polska. Jezeli tak samo jest w wersji kompilowanej w polskim systemie, to trzeba bedzie szukac przyczyn.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 31 Stycznia 2017, 08:06:22
Plik silucji maszyna.sln jest w wersji VS2013, ale to nie ma większego znaczenia, gdyż VS od wersji 2010 nie konwertują wersji na nowszą tylko używają starszej. Kompilowałem na VS2013, VS2015 i VS2017 na tej samej solucji i nie ma problemów z tym.
Zalecane jest VS2013 i w górę ze względu na rozpoczęcie używania c++11 w kodzie i na VS2010 raczej się już nie skompiluje.
Wszystkie potrzebne pliki .lib są na repo i nie powinno być problemu.
Największe różnice polegają na ustawieniu debugera, żeby korzystał z katalogu maszyny i ewentualnej nazwy generowanego exe i to może nadpisywać solucję. Ogólna zasada jest obecnie taka, że ściągasz repo, zmieniasz na parametry tobie potrzebne i nie wgrywasz na repo zmian, o ile nie dodasz jakiegoś nowego pliku.
Z racji powyższego zastanawiam się czy nie przejść na CMake lub coś podobnego.
Na nasze potrzeby jest wystarczająca wersja CommunityEdition.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 31 Stycznia 2017, 21:54:17
Odpaliłem swoją scenerię na eu07++, BMP wszystkie przeszły i wygląda, że przynajmniej na starcie działa. Z rzeczy widocznych na pierwszy rzut oka:
- EN57 mimo ustawienia prędkości początkowej 0.1 nie uruchamiają się;
- program wywala następujące błędy, których nie wywala exe 481:
Failed to load 3d model "dynamic\pkp\1xxa_v1\passengers.t3d"
Failed to load 3d model "dynamic\pkp\z1_v2\passengers.t3d"
Failed to load 3d model "dynamic\pkp\en57_v1\przedsionki.t3d"
Failed to load 3d model "dynamic\pkp\en57-2000_v1\przedsionki.t3d"
- po paru minutach program się wysypuje nawiązując tym samym do światłych tradycji swych przodków ;) Wygląda na to, że problemem jest próba wykonania eventu "copyvalues" (przy trzech próbach właśnie tam kończył się log):
event jan_osob_nadajrozklad_tor11_osobI copyvalues 0.0 jan_osob_g_sem_mem jan_osob_rozkladosob endeventgdzie jan_osob_rozkladosob ma wartość jak poniżej:
event osobA_rozklad1239 updatevalues 0.0 jan_osob_rozkladosob Timetable:slimson/calkowo_v2/ROPr55415 10 0 endevent
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 31 Stycznia 2017, 23:40:55
Brakujace modele to nic nowego, po prostu do tej pory .exe nie traktowal tego jako blad warty zgloszenia ;)

Po sprawdzeniu EN57 faktycznie wyglada na martwy. Tzn recznie jezdzi bez problemu, ale jesli wlacze AI to wyglada na to, ze ono w ogole nie probuje sterowac. Nie pamietam czy wczesniej sobie radzilo, w kazdym razie do sprawdzenia.

Eventow i komorek pamieci w zasadzie jeszcze nie ruszalem, wiec tam sie moze dziac wszystko.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 31 Stycznia 2017, 23:50:46
Przedsionki byłyby do wywalenia kiedyś przy okazji, bo ich sztywne ładowanie we wszystkich ezt to głupota. Są tożsame z lowpolyint i cab 2&0.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Lutego 2017, 04:33:26
Przyjrzalem sie EZT, i wychodzi na to, ze winny jest bajzel :)

* do prawidlowego dzialania zespolu wymagane sa minimum: polaczenie wys. napiecia i "polaczenie fabryczne" czyli flaga 128, miedzy czescia sterujaca i czescia silnikowa.
* zestawy w sceneriach sa typowo laczone kombinacja 55, ktora nie przenosi zadnej z tych dwoch flag.
* zeby bylo smieszniej, to plik .fiz dla EN57 (i pewnie pozostalych, nie sprawdzilem) definiuje AllowedFlag na 103 z jednej strony, i -119 z drugiej, co najwidoczniej kiedys dodalo by "polaczenie fabryczne" do podanej flagi, ale wartosci ujemne nie sa juz obslugiwane, i modul dostaje 103 na obu koncach.

w rezultacie, z punktu widzenia AI siedzi ono w wydmuszce bez zadnego silnika i pradu, wiec nawet nie probuje nic ruszac.

mozna to rozwiazac albo zmiana w pliku .fiz i podaniem wlasciwych AllowedFlag, z uwzglednieniem wartosci +8 i +128, i poprawieniem wpisow skladow w sceneriach, albo przywroceniem obslugi wartosci ujemnych (i poprawieniem wpisow skladow w sceneriach). Zakladam, ze wartosci ujemne przestano obslugiwac z jakiegos powodu, wiec nie bede sie spieszyl z wlaczaniem tego kawalka ponownie. Niech sie madrzejsi ludzie zastanowia, jak chca to miec zrobione ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 01 Lutego 2017, 06:53:08
Nie są obsługiwane ujemne na wczytywaniu czy na obsłudze? Jeśli to pierwsze to to jest błąd niezamierzony. Jeśli to drugie to coś namieszało przy konwersji, bo na pewno to powinno działać jak poprzednio.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Lutego 2017, 07:42:28
Przy wczytaniu:

    if (fAllowedFlag > 0)
        Couplers[0].AllowedFlag = fAllowedFlag;
    if (Couplers[0].AllowedFlag < 0)
        Couplers[0].AllowedFlag = ((-Couplers[0].AllowedFlag) || ctrain_depot);
AllowedFlag jest zmieniana z domyslnej wartosci (0) tylko jest wartosc wzieta z pliku .fiz jest dodatnia. A potem sprawdzana jest juz wartosc docelowa, ktora w przypadku wartosci ujemnej w pliku .fiz zostaje niezmieniona, czyli w zasadzie ten drugi warunek nie wykonuje sie nigdy.

Jesli to pomylka to ok, poprawilem ta sekcje (przy okazji odczytuje tez odrebne parametry dla kazdego sprzegu jesli sa podane osobno, w oryginale kopiowal zawartosc pierwszego do drugiego) Chociaz AI w EZT specjalnie to nie pomoglo, bo teraz procedura wyszukiwania silnika znajduje co trzeba, i AI w kabinie kontrolnej glupieje w inny sposob ;)  Docelowo trzeba by chyba przerobic troche caly system, tak zeby kontrola stanu opierala sie o caly 'zespol trakcyjny' a nie tylko pojedynczy czlon. A czy ten 'zespol' to tylko pojedyncza lokomotywa, czy kilka sztuk albo czlonow spietych ze soba, i ktory konkretnie element napedza calosc, w to juz kod sterujacy wnikac nie musi.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 01 Lutego 2017, 09:18:51
W pascalowym moverze dozwolone flagi tyczyły się tylko sprzęgania w czasie symulacji. Wpisy z trainseta ignorowały te ograniczenia i można było sobie spokojnie ukrotnić dwie węglarki z przewodem ogrzewania i szyną WN.
Szyna WN była potrzebna tylko gdy kilka pojazdów miało napęd ale tylko jeden odbierak prądu. Przykładowo w ED72 przy podniesieniu jednego pantografu. EN57 ma pantograf i silniki w tym samym członie, wiec na 55 działał.
Flaga ujemna była tożsama z +256. Zresztą patrząc na diagnostykę te flagi wewnętrznie i tak przyjmowały inne wartości niż w trainsecie. Coś ukrytego było jeszcze dodawane. Nie wiem dlaczego Ra yB zdecydował się na ujemne zamiast jawnego +256 dla sprzęgu depotowego. Może uznał, że tak będzie czytelniej dla ustawiaczy i wygodniej przy zmianach.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 01 Lutego 2017, 09:30:16
Sprzęgi depotowe zrobił yB. Ogólnie cała konstrukcja sterowania pociągiem jest poroniona:
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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 01 Lutego 2017, 14:15:47

Ciekawie zaczyna się robić, gdy przeanalizuje się pracę nowoczesnych zespołów trakcyjnych w trakcji wielokrotnej. Jednostki centralne pojadów komunikują się ze sobą, natomiast każda z jednostek centralnych oddzielnie zarządza swoim pojazdem. Podsumowując: jednostka centralna pojazdu-mistrza wie wszystko o pociągu, zostawiając nieco autonomii pojazdom-niewolnikom w sterowaniu pojazdem.
W chwili obecnej w DynObj (z braku lepszego miejsca…) jest sterownik hamulca EP+ED dla asynchronów, który musi sterować oddzielnie każdym członem, zamiast zadać każdemu pojazdowi odpowiednią siłę hamowania. Każdy z pojazdów powinien mieć wgraną tabelkę blendingu (ile można dać hamulca ep przy pełnym ed), natomiast ja byłem zmuszony napisać algorytm, który robi to w czasie rzeczywistym i jest w stanie poradzić sobie z dowolną konfiguracją pociągu we wszystkich sytuacjach ruchowych (łącznie z poślizgiem pojedynczych osi) ;-)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Lutego 2017, 16:27:56
Udalo sie prowizorycznie uruchomic EZT -- w kodzie ustawiajacym aktywna kabine byl blad, po usunieciu AI radzi sobie calkiem niezle. Oprocz tego, nie jestem pewien ale wyglada na to, ze domyslnie AI jest ustawione zeby nie ruszac niczego dopoki nie otrzyma rozkazow, a skanowanie/rozkazy nie zaczynaja byc wysylane dopoki pociag nie wlaczy przynajmniej baterii... wiec zdarzaja sie sytuacje typu kiedy AI czeka na sygnal I odwrotnie, I nic sie nie dzieje. Tymczasowo wylaczylem dla AI to oczekiwanie, I teraz zawsze sprawdza/uruchamia silnik, co popycha troche wszystko do przodu. Jesli to zly pomysl, to zawsze mozna cofnac ;)

Wyglada na to, ze jest klopot z SM42 -- sama jeszcze jezdzi, ale wydaje sie, ze nie ma zadnej sily pociagowej, I z przyczepionym wagonem stoi w miejscu (albo wchodzi w poslizg na zbyt wysokich obrotach) Nie wiem czy to przez zmiany w ladowaniu .fiz czy cos innego, przyjrze sie. Nie pamietam, czy wczesniej jezdzila lepiej.

Sklady AI czasami hamuja tez z duzym opoznieniem, ale to chyba tez ma zwiazek ze skanowaniem, wiec na razie nie ruszam.

Z innych rzeczy zrobilem przy okazji male przesuniecia w funkcji renderujacej, tak ze wszytkie uaktualnienia sceny sa teraz wykonane najpierw, a rysowanie na ekranie nastepuje potem. Samo w sobie nie robi to zadnej roznicy, ale otwiera pewne... mozliwosci.

(palpatine.jpg)

uaktualnione .exe w zalaczniku, dla sprawdzenia EZT, i co tam kto chce ;d
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 01 Lutego 2017, 16:56:53
Na scenerii Kaliska sm42 sama podpina sie w peronach do skladu 9 pudel i po otrzymaniu ms2 udaje sie w perony. W innej czesci scenerii wykonujemy manewry z pociagiem odstawczym, nie jest lekki. Ten lok zwawo sie rusza i do slabych nie nalezy. Jesli z jednym wagonem stoi, to jest zepsuta. EZT i kazdy pojazd w scenerii obsadzony przez AI na starcie, powinien miec wlaczona baterie. Chyba, ze zostal w tej scenerii umieszczony jako nobody. Brak checi zabrania sie ai do pracy bywal zawsze.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Lutego 2017, 17:27:39
Na scenerii Kaliska sm42 sama podpina sie w peronach do skladu 9 pudel i po otrzymaniu ms2 udaje sie w perony. W innej czesci scenerii wykonujemy manewry z pociagiem odstawczym, nie jest lekki. Ten lok zwawo sie rusza i do slabych nie nalezy. Jesli z jednym wagonem stoi, to jest zepsuta.
No, okazuje sie ze to cos innego. Zmontowalem kilka roznych skladow i z tymi SM42 spisuje sie normalnie. Za to symulacja glupieje z zestawem Bhp -- pierwszy czlon jedzie, a reszta stoi jak wryta. Jak podpialem EU07 zamiast SM to prawie rozerwala sklad na pol o.O
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 01 Lutego 2017, 17:48:38
Pewnie coś ze sprzęgiem depotowym. Bhp są "nierozrywalne" we flagach.
Zachowanie ai zależało od prędkości. Dla v0=0 nic nie robił i czekał na rozkaz. Dla v0=0.1 się uruchamiał i skanował.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Lutego 2017, 18:18:54
To sie objawia nawet przy polaczeniu standardowym czyli sprzeg + hamulec. Na pierwszy rzut oka podejrzewam, ze to moga byc parametry dla sprzegu typu Articulated -- czesc z nich jest mnozona przez Ftmax ktory domyslnie ma wartosc 0.0, a to chyba nie wplywa najlepiej na symulacje? (problem wylazi gdy jeden z wagonow Bhp stuknie o drugi)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 01 Lutego 2017, 18:36:23
Taki dziwny stan (nieustalony?) po stuknieciu juz bywal. Sprawdz czy cala bhp stoi na jednym torze, czy na dwu. Nie jestem przekonany czy to dobry trop, ale moze wylaza przy okazji jakies czary z dawnych czasow.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Lutego 2017, 22:16:18
Blad sie znalazl. Jak zwykle, zemscilo sie przepisywanie parsera .fiz po kawalku :s  w rezultacie ustawial zbyt male niektore wartosci dla sprzegow articulated, i symulacja wariowala. Teraz jest juz ok.

edit: mala aktualizacja -- w EZT nie dzialala tez sprezarka. Teraz dziala, czyli koniec blogies ciszy w trakcie prowadzenia. Doczepiam .exe, bo przez chwile najprawdopodobniej sie nie zmieni, wiec lepsze takie, z mniejsza iloscia pluskiew.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 02 Lutego 2017, 20:07:41
Dodałem do bugtrackera kategorię Maszyna 2017>Mover C++ i dałem @tmj devsa tam by mógł moderować tickety. Nie wiem czy w wątku wam nie wygodniej, ale można korzystać.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 02 Lutego 2017, 20:48:38
Szkoda, że ten tracker jest o tyle ubogi, że nie ma w nim możliwości zdefiniowania kamieni milowych. Ba, tam nawet sortowania listy nie ma po kategoriach zgłoszeń...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 02 Lutego 2017, 21:32:56
Tak przy okazji – będzie się komuś chciało od razu wprowadzić klasę wózek i klasę oś wraz z indywidualnym liczeniem nacisków, przyczepności i obrotów?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 02 Lutego 2017, 21:58:06
Chciec to moze by sie i chcialo, ale ja z fizyki kompletna noga jestem ;/ moglbym co najwyzej poprzestawiac to co jest metoda kopiuj/wklej, bez zadnej gwarancji ze to da rezultaty zblizone do oryginalu. Jesli mozesz cos takiego wyprodukowac albo znasz kogos, kto moze, to jak najbardziej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 02 Lutego 2017, 22:07:31
Niestety, obecnie tego w symulatorze nie ma. W tym momencie jeden pojazd (Mover) musi mieć dwa wózki, a wszystkie osie kręcą się z tą samą prędkością. Formę docelową mógłbym rozpisać na kartce w bloczkach/pseudokodzie (co można zrobić właściwie wszędzie), natomiast do kodowania potrzebny jest już komputer ze źródłami i kompilatorem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 02 Lutego 2017, 22:20:10
Teoretycznie wózek jest. Ale raczej tylko do śledzenia toru i wyświetlania grafiki, tudzież wyzwalania eventów.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 03 Lutego 2017, 18:11:49
Na ostatnim exe07++ EN57 się odpalają, ino drzwi nie otwierają przy postoju. Nie wiem jeszcze, czy jeżdżą, bo znowu wykonał mi się event "copyvalues", symulator znowu się wysypał, ale dorzucił w gratisie nowy, ciekawy błąd - screen w załączeniu. Zdaje się, że to efekt próby wykonania tego crashdumpa. Plik dbgHelp.dll z paczki wrzuciłem do folderu z MaSzyną, on ma być może w jakiejś konkretnej lokalizacji?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 03 Lutego 2017, 18:51:56
Nie jestem pewien -- z tego, co moge wyczytac to byc moze twoj Windows juz ma zainstalowana wlasciwa wersje tej biblioteki, i ta ktora dolaczylem mu nie pasuje. Sprobuj wyrzucic ja z folderu (w ten sposob OS bedzie sie musial posluzyc tym, co ma dostepne systemowo) i zobacz co sie stanie jak .exe wysypie sie kolejny raz?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 03 Lutego 2017, 19:22:19
Podziałało. W załączeniu spakowany crashdump.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Bochi w 03 Lutego 2017, 20:20:37
Hej, jestem tu nowy i jeśli to niewłaściwy wątek to przepraszam, ale znam C++11, ObjectPascal i chciałbym dać jakiś wkład w symulator. Chciałbym spytać, czy mogę w jakiś sposób pomóc, a jeśli nie tu, to czy są jakieś "drobniejsze" prace w których mógłbym się przydać. Zależy mi przede wszystkim na nauce. Dzięki :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 03 Lutego 2017, 20:22:09
Cos jest na pewno na rzeczy z copyvalues (i prawdopodobnie eventami w ogole), bo podobny problem wystepuje np. na linii61_osobowy1 ktora wykrzacza sie prawie na samym poczatku, rowniez na evencie tego typu, ktory jakims sposoboem nie ma w ogole zainicjowanych parametrow. Ale system eventow jest zakrecony jak baranie kiszki i nie bardzo wiem czy warto brac sie za ich rozplatywanie, bo podejrzewam ze Firleju sie z przyjemnoscia pozbedzie tego w calosci, jak przyjdzie do rekonstrukcji tej czesci program ;)

edit:
@Bochi, zrodla symulatora sa na Githubie (aktywne galezie do wejrzenia tutaj: https://github.com/eu07/maszyna/network )  obejrzyj sobie, i na pewno znajdzie sie cos, co zechcialbys poprawic.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 03 Lutego 2017, 20:35:52
Myślę, że przejście na system post-eventowy to kwestia na tyle odległa, że warto byłoby jednak spróbować te baranie kiszki rozprostować, na ile się da :) Choćby dla kompatybilności wstecznej, bo zanim wszystkie scenerie zostałyby przepisane na nowy wariant sterowania, też minęłoby sporo czasu. Poza tym bez w pełni działających eventów ciężko będzie dobrze przetestować nową wersję exe i wyłapać wszystkie kwiatki.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 03 Lutego 2017, 20:47:37
Co prawda to prawda. Jest gdzies w ogole jakis opis, jak eventy maja (w teorii funkcjonowac) w wersji obecnej? chcialem sprawdzic na wiki ale od paru dni serwer na ktorym lezalo eu07.es chyba nie zyje ;/
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 03 Lutego 2017, 20:55:28
Eventy masz opisane na wiki Ra. Na wiki Q było kopiuj-wklej o ile wiem. Może trochę przeredagowane przez Firleja. Mam nadzieję, że Q opłaci serwer i wiki wstanie. Teraz jak mam ftp eu07.pl mogę przenieść wszystko tu, tylko musi mi się chcieć. Zdaje się nawet jakieś mediawiki jest już wgrane.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Sowik2 w 03 Lutego 2017, 21:17:30
Coś dalej jest nie tak z tym parserem. Wszystko się ładuje, ale wywala błędy (za każdym razem te same, ale nie wszystkie, które na logikę powinno wywalić) tak np.
Missed sound: [1007]estluz.wav 50
Missed sound: [1007]estluz.wav 50
Tymczasem w pliku jest jeszcze jeden dźwięk z dodanymi cudzysłowami, ale jego nie wywala mimo, że cudzysłowy są dane w tych samych miejsch.
unbrake: "[1007]estluz.wav 50"
brakeacc: "[1007]est_bac.wav 50"
Dodam, że tych dźwięków, które wywali, nie słychać. Nie wiem od czego to zależy. Czyli jedno parsuje poprawnie, a drugie w całości bierze jako nazwę.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 03 Lutego 2017, 21:47:36
Eventy masz opisane na wiki Ra.
Na wlasnie nie bardzo. Na stronie Ra w scenery.doc jest w tekscie link Eventy, a gdy go klikne to dostaje tylko
Cytuj
Ta strona została usunięta. Rejestr usunięć i zmian nazwy tej strony jest pokazany poniżej.
22:17, 11 lis 2014 Ra (dyskusja | edycje) przeniósł stronę Symulator/MaSzyna/Eventy na Symulator/MaSzyna/Pojazdy, bez pozostawienia przekierowania pod starym tytułem
I na stronie docelowej o eventach nic nie ma. Sam event ma 13 parametrow w jednej tablicy, i kod je tam sobie wedlug wlasnego widzimisie przestawia/kopiuje itp, ale dlaczego akurat te a nie inne to raczej czarna magia, wiec trudno dojsc czy akurat robi cos blednie.

@Sowik, trudno powiedziec czy to jest parser, czy na przyklad funkcja ktora probuje zaladowac dzwiek nie wyczynia czegos z argumentem, ktory dostaje. Czy to jest na jakiejs okreslonej scenerii z paczki calosciowej? Najlepiej jakbym mogl to przesledzic u siebie, co on tam robi.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 03 Lutego 2017, 21:50:39
A tak technicznie jak to działa od strony kodu to niestety nigdzie nie było opisane.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Sowik2 w 03 Lutego 2017, 21:57:49
@tmj, jutro spakuję Ci zestaw tych plików, a testowałem na td.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 03 Lutego 2017, 22:43:38
@tmj, jutro spakuję Ci zestaw tych plików, a testowałem na td.
OK, bede wdzieczny.

W miedzyczasie udalo sie chyba, odpukac, poprawic blad z copyvalues. Na szczescie to chyba nie bylo w samym kodzie eventu, ale przy pobieraniu danych do logowania -- po zmianach w wersji 464 jedna procedura byla uzywana dla dwoch typow eventow, ale w przypadku copyvalues tych danych do pobrania po prostu nie bylo. Teraz powinno byc w porzadku, uaktualnione .exe dolaczone, do sprawdzenia.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 03 Lutego 2017, 23:41:41
Na wlasnie nie bardzo. Na stronie Ra w scenery.doc jest w tekscie link Eventy, a gdy go klikne to dostaje tylko
Cytuj
Ta strona została usunięta. Rejestr usunięć i zmian nazwy tej strony jest pokazany poniżej.
22:17, 11 lis 2014 Ra (dyskusja | edycje) przeniósł stronę Symulator/MaSzyna/Eventy na Symulator/MaSzyna/Pojazdy, bez pozostawienia przekierowania pod starym tytułem
I na stronie docelowej o eventach nic nie ma.

W sensie... O tym mowa? http://rainsted.com/pl/Symulator/MaSzyna/Scenery.doc
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 04 Lutego 2017, 02:30:44
Tak, z tym ze mialem nadzieje ze na tej brakujacej stronie jest troche detail od strone .exe, ale wychodzi na to ze tego nigdy nie bylo... na szczescie przynajmniej na razie dalo sie obejsc bez takich szczegolow :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: matek123 w 04 Lutego 2017, 09:24:54
Trochę opisów eventów masz w instrukcji do event generatora.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 04 Lutego 2017, 09:40:15
tmj, byłoby miło, gdybyś takie lib-y tez wrzucał na repo. Jedyne jakie posiadam na dysku są od BCB.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 04 Lutego 2017, 09:53:15
Ale tu chodzi o wewnętrzną strukturę klasy Event, nie o opis działania.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 04 Lutego 2017, 14:55:50
Dobra, copyvalues już się nie sypie, ale za to wpadłem na kolejne ciekawostki:
- podwójne EN57 spięte ze sobą nie działają np. takie coś:
node -1 0 EN57-1641ra dynamic pkp\en57_v1 en57-1641ra 6baii 0.0 headdriver 55 0 enddynamic
node -1 0 EN57-1641s dynamic pkp\en57_v1 en57-1641s 6bsii 0.0 nobody 55 0 enddynamic
node -1 0 EN57-1641rb dynamic pkp\en57_v1 en57-1641rb 6bbii 0.0 nobody 55 0 enddynamic
node -1 0 EN57-1642ra dynamic pkp\en57_v1 en57-1641ra 6baii 0.0 nobody 55 0 enddynamic
node -1 0 EN57-1642s dynamic pkp\en57_v1 en57-1641s 6bsii 0.0 nobody 55 0 enddynamic
node -1 0 EN57-1642rb dynamic pkp\en57_v1 en57-1641rb 6bbii 0.0 nobody 0 0 enddynamic
endtrainset
Wygląda to tak, że stoi sobie taka bidula, patyczki ma podniesione, w ostatnim EZT są nawet końcówki włączone, ale w pierwszym świateł nie ma i wydaje mi się, że oba w ogóle nie są uruchomione (nie słychać sprężarek czy przetwornic). Pojedyncze EZT działają.

- nie działa odczytywanie / interpretacja / whatever rozkładów. W liście skanowanych torów pojawiają się co prawda stopinfo, ale zawsze z prędkością v=0, która jest i tak ignorowana. Jak pociąg wyjedzie na szlak, nie zatrzymuje się na przystankach. W konsekwencji nie działa też kierpoć.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Sowik2 w 04 Lutego 2017, 15:45:52
Przesyłam paczkę, w której jest kilka plików .mmd, które uważam, że są dobrze przerobione, exe, na którym testowałem i przykładowy log i errors.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 04 Lutego 2017, 17:57:24
to tak, że stoi sobie taka bidula, patyczki ma podniesione, w ostatnim EZT są nawet końcówki włączone, ale w pierwszym świateł nie ma i wydaje mi się, że oba w ogóle nie są uruchomione (nie słychać sprężarek czy przetwornic). Pojedyncze EZT działają.
Hmm u mnie dzialaja. Skopiowalem sobie zestaw z kaliska_cegielski, postawilem na TD, wlaczylem mu AI i kula sie bez problemow (screenshot na dowod) Z EN jest chyba ogolnie jakis dziwny blad ktory objawia sie od czasu do czasu -- zespol odpala sie normalnie, ale jak tylko ustawi sie kierunek do przodu/tylo, silnik wywala i tyle. Trudno to wylapac, bo trafia sie od czasu do czasu (czyli pewnie gdzies tam jest nieinicjalizowana zmienna albo cos)

Rozkladow/skanowania na razie nie ruszam w ogole, bo Firleju to ogarnia, wiec nie chce zeby sie bajzel zrobil.

Aha, i jakie .liby mam dolaczac? Nic dodatkowego nie dokladalem, jesli to dbghelp to ona sobie lezy w Windows SDK ktory przychodzi z VS, i linker ja sobie ciagnie z domyslnych sciezek.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 04 Lutego 2017, 19:15:05
@Sowik2, z tego co widze to problem raczej nie jest z parserem, a bierze sie z tego, jak uzywane sa cudzyslowy:

engine: "[1007]silnik_st45_1.wav  190.0  0.3 0.85  0.01 0.8"
takie cos powoduje, ze caly blok 6-u parametrow jest wciagniety jako jeden token, i podany jako nazwa dzwieku dla silnika. Takiego dzwieku oczywiscie nie ma, a dodatkowo kod glupieje, bo kiedy probuje odczytac 5 pozostalych parametrow poza dzwiekiem silnika, zaczyna brac dane z nastepnych linii, ktore sa konfiguracja pozostalych parametrow, i wszystko sie rozjezdza. Nie znam sie na YAML, ale w cudzyslowach powinien byc chyba tylko ten kawalek, w ktorym wystepuje klamra, tzn.:

engine: "[1007]silnik_st45_1.wav"  190.0  0.3 0.85  0.01 0.8

Oprocz tego, wylazl problem: YAML oznacza komentarze znakiem '#', a parser nie rozpoznaje tego jako komentarz. Mozna by to latwo zmienic, ale symulator uzywa znaku # do takich rzeczy jak #include itp. w pozostalych plikach, wiec jesli zaczyna je ignorowac jako komentarze, rozwala to cale ladowanie. Na chwile obecna "rozwiazaniem" jest nie umieszczanie komentarzy w plikach yaml.

edit: obszedlem to w inny sposob -- # jako komentarz jest rozpoznawane przez parser opcjonalnie, domylsnie wylaczone i w chwili obecnej aktywowane tylko w czasie ladowania plikow .mmd  Oznacza to, ze pliki te nie moga uzywac #include, ale chyba nikt tam tego nie stosowal..?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Sawi w 04 Lutego 2017, 19:41:00
Masz na myśli wpis include do t3d?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 04 Lutego 2017, 20:15:24
Ogolnie to mi sie poplatalo :)  wydawalo mi sie, ze w maszynie sa dyrektywy typu #include w plikach i dlatego przy uniwersalnym traktowaniu # jako znaku komentarza ladowanie szlo w maliny, ale on tam wystepuje w innym charakterze, chociaz efekt jest ten sam. Ogolnie to chyba # uzywany jest na tyle czesto, ze komentarze YAML trzeba bedzie sobie darowac. Albo zastapic # jako znak specjalny w konfiguracjach czyms innym.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 04 Lutego 2017, 20:20:31
...- nie działa odczytywanie / interpretacja / whatever rozkładów. W liście skanowanych torów pojawiają się co prawda stopinfo, ale zawsze z prędkością v=0, która jest i tak ignorowana. Jak pociąg wyjedzie na szlak, nie zatrzymuje się na przystankach. W konsekwencji nie działa też kierpoć.
Potwierdzam. Dodatkowo proszę o numerację kompilacji. Ciężko to później w paczce ponazywać i porównywać. Nadpisanie poprzedniego nie wchodzi w grę, w razie potrzeby porównania, rodzi to komplikacje. Może do nazwy C++ dodawać miesiąc i dzień kompilacji?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 05 Lutego 2017, 01:04:13
Udalo sie chyba poprawic W4, bez wlazenia w skanowanie itp -- bledy byly w pobieraniu i porownywaniu nazw przystankow z rozkladem. Prawdopodobnie ciagle moga wyskoczyc jakies krzaki przy stacjach z polskimi literami w nazwach, ale to wyjdzie w praniu.

Wlaczylem tez z powrotem rzucanie pudlem w widoku wewnetrznym. Nie jest identyczne, i prawdopodobnie przesadzone w porownaniu z rzeczywistoscia, ale o tym niech sie wypowiedza ludzie z rzeczywistym doswiadczeniem ;)

edit: iiiiiii poprawka, bo gdybym za pierwszym podejsciem czegos nie przegapil, to za dobrze by bylo. Teraz widzi co trzeba.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 05 Lutego 2017, 07:04:47
Krzaki wyszły przy wyświetlaniu. Ale porównuje OK, tzn kierpoć zadziałał na stacji "Ba,tyk". Symulacja uruchamia się z dźwiękiem włączenia hamulca awaryjnego, tak chyba nie powinno być. W przypadku kibla ten dźwięk odtwarza się bez końca i nie da się go wyłączyć.
Z różnic między starym exe a nowym (bo pierwszy raz testuję) - ładowanie scenerii jest jakieś 2x szybsze (Całkowo v2 ładuje się 2 minuty zamiast 4). Ciekawe czemu?
Coś ze sterowaniem jest nie tak, odpaliłem nową misję Bałtyk_en57 - ciężarówka przejechała przez szlaban i utknęła tam, zablokowała ruch, misja nieprzejezdna dzięki temu. Na exe 481 działa (chociaż kierpoć się wiesza).

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 05 Lutego 2017, 07:37:57
Jeszcze jeden bug: sterowanie hamulcem pomocniczym działa źle - wciskam Num1 raz, nic, dwa razy nic, trzy razy nic, cztery razy - hamulec przeskakuje nagle w pełne zahamowanie. Czyli brak możliwości regulacji siły hamowania.

(Sorki za drugi post, dopiero teraz zauważyłem, że forum nie scala.) Wybaczamy, liczymy na poprawę w przyszłości ;)     /@m.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Sowik2 w 05 Lutego 2017, 10:07:06
engine: "[1007]silnik_st45_1.wav"  190.0  0.3 0.85  0.01 0.8
Z tymi cudzysłowami próbowałem już kiedyś tak, jak mówisz, ale potem parser yaml-owski nie wie co zrobić z resztą parametrów.  Mam pewien pomysł, ale sprawdzę go chyba dopiero jutro.
A jeżeli chodzi o komentarze, to można by było zrobić (a może już jest, proszę o link) plik, w którym jest cały opis pliku mmd ze wszystkimi parametrami i ich przeznaczeniem, a te komentarze usunąć, bo jest dużo niepotrzebnych. Natomiast nie wiem co z parametrami odkomentowanymi.
Przesyłam specyfikację YAML 1.2 może się do czegoś przyda.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 05 Lutego 2017, 12:26:05
Apropos W4, to dziwię się że coś wyszło gdyż to była pierwsza rzecz jaką konwertowałem i testowałem wtedy te zmiany. Błee, co za syf.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 05 Lutego 2017, 13:08:03
Coś ze sterowaniem jest nie tak, odpaliłem nową misję Bałtyk_en57 - ciężarówka przejechała przez szlaban i utknęła tam, zablokowała ruch, misja nieprzejezdna dzięki temu. Na exe 481 działa (chociaż kierpoć się wiesza).
Ta ciężarówka ma problem z hamulcami od zawsze, więc to z exe raczej nie ma nic wspólnego. No chyba, że by zrobić ai uwzględniajace za słabe hamulce przy kalkulacji drogi hamowania. ;)

Jakiś komentarz w mmd by się jednak przydał. Przy testach wpisów dobrze mieć możliwość zachowania starego w pliku, by móc się cofnąć jak coś nie bangla.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 05 Lutego 2017, 17:34:56
Z różnic między starym exe a nowym (bo pierwszy raz testuję) - ładowanie scenerii jest jakieś 2x szybsze (Całkowo v2 ładuje się 2 minuty zamiast 4). Ciekawe czemu?
Bo wymienilismy parser na ten, o ktorym wszyscy mowili, ze bedzie za wolny ;)

A tak na serio, to przez 10 lat z okladem od czasow Borlanda kompilatory poprawily sie w optymalizacji, wykorzystywaniu nowych instrukcji procesorow, itp.

Cytuj
Coś ze sterowaniem jest nie tak, odpaliłem nową misję Bałtyk_en57 - ciężarówka przejechała przez szlaban i utknęła tam, zablokowała ruch, misja nieprzejezdna dzięki temu. Na exe 481 działa (chociaż kierpoć się wiesza).

Ta ciezarowka co tam utkwila specjalnie mnie nie dziwi, na Baltyku w ogole sa jakies siupy z polaczeniami drog (np. samochody zderzaja sie na skrzyzowaniu i pojawiaja jakies 100 m. dalej, na drugim koncu odcinka szosy) Chociaz chyba wylazly tam jakies nowe rzeczy w miedzyczasie, przyjrze sie.

Co do dzwiekow to trudno mi cos powiedziec, na testach EN57 slysze tylko kompresor i cykacz, czyli wydaje sie w porzadku. Jest na poczatku jakis krotki szum (i AI korzysta z bledu i wlacza odluzniacz ktory normalnie w EN nie dziala) ale nie wiem czy tak ma byc, az tak sie na pociagach nie znam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 05 Lutego 2017, 18:04:16
Z tymi cudzysłowami próbowałem już kiedyś tak, jak mówisz, ale potem parser yaml-owski nie wie co zrobić z resztą parametrów.  Mam pewien pomysł, ale sprawdzę go chyba dopiero jutro.
A jeżeli chodzi o komentarze, to można by było zrobić (a może już jest, proszę o link) plik, w którym jest cały opis pliku mmd ze wszystkimi parametrami i ich przeznaczeniem, a te komentarze usunąć, bo jest dużo niepotrzebnych. Natomiast nie wiem co z parametrami odkomentowanymi.
Przesyłam specyfikację YAML 1.2 może się do czegoś przyda.
Wyglada na to, ze YAML jest tak skonstruowany, ze jednak nieco gryzie sie z tym, jak symulator ma zorganizowane pliki. Z tego co widze, mozliwosci jest kilka:

1. brak komentarzy w plikach .mmd -- najmniej pracy, ale brak komentarzy

2. zgrupowanie wszystkich parametrow dzwieku w jeden token przy uzyciu cudzyslowow, i zmiana w kodzie symulatora, zeby to wewnetrznie rozbijac na poszczegolne parametry. Z jednej strony ma to jakas zalete (troche lepsza kontrola nad parametrami dla dzwieku), z drugiej strony wymaga to poprawienia wszystkich istniejacych .mmd

3. podawanie parametrow w formie
foo:
 - bar.wav
 - 50
 - 75
itp. i zmiana w kodzie parsera, zeby ignorowal ciagi typu " - " Rowniez wymaga zmian we wszystkich plikach .mmd, i jest szansa ze przy okazji skoliduje z czyms gdzie indziej, czego na razie nie jestem w stanie przewidziec.

4. zrobienie "tego co trzeba", tzn. zapis plikow .mmd w pelnym formacie YAML, i dla wygody podpiecie parsera ktory to obsluguje, jako alternatywy dla biezacego kodu, ktory moze nadal obslugiwac stary format .mmd, ten bez identyfikatora YAML na poczatku. Jako ze jest to najbardziej pracochlonne rozwiazanie, wstrzymalbym sie z tym do czasu, gdy mamy obiekty symulatora przerobione na nowy standard (po tym jak w ogole powstanie nowy standard) zeby nie uczyc parsera dwa razy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 05 Lutego 2017, 18:28:05
Zasadniczo nowe exe wygląda coraz lepiej, ale jeszcze trochę poprawek się przyda:
- podwójne EN57 faktycznie mi zadziałało, ale dla odmiany AI popsuło się w jednej z EP09 - prawdopodobnie jest to błąd, o którym wspominałeś (jakaś nieinicjowana zmienna), bo poprzednim razem ten pociąg działał - objawy te same: pantograf w górze, rozkład ma nadany, końcówki się świecą, ale oświetlenia czoła nie ma i nie reaguje na podawane semafory
- wygląda na to, że SN61 utracił hamulce. Jeździć jeździ, ale zatrzymuje się dopiero, jak mu rozpędu braknie :)
- symulator pod F1 wyświetla godzinę przyjazdu do kolejnej stacji bez zer tj. np. 14:05 to 14:5; w widoku rozkładu pod F3 jest normalnie
- faktycznie model kabiny jakoś dziwnie skacze w czasie jazdy

Ale tak poza tymi rzeczami to wygląda na to, że jest naprawdę spoko. Puściłem na jednej ze swoich misji na nowym Całkowie AI, nieco dziwnie kręci nastawnikiem i hamulcami, ale w sumie jedzie i nawet się bardzo nie spóźnia. Reszta pociągów też jeździ, zmienia czoła bez problemów, rozkłady są im nadawane i się przewijają, obloty i podczepianie się loków też działa.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 05 Lutego 2017, 22:44:31
Ja tylko zasugeruje wyłączenie bujania do czasu, aż będzie to można ogarnąć inaczej (opis w innym wątku). Na długim odcinku Kaliskiej można ocipieć od skakania kabiny. Dzięki za numerowanie kompilacji. Inne pojazdy i scenerie następnym razem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: art72 w 06 Lutego 2017, 00:29:23
Przejechałem dziewiątką w obie strony Drawinowo. Dwukrotnie - raz wczoraj i raz dziś. Bez żadnych problemów.

Jedyny zgrzyt to brak potrzebnej biblioteki glew32.dll.

Sceneria wczytuje się błyskawicznie. W dodatku bardzo podoba mi się wyświetlanie zainicjowanych zmiennych - znak, że wszystko jest pod kontrolą.

Potwierdzam irytujące buczenie zaraz po uruchomieniu/pokazaniu kabiny. Na szczęście szybko można się go pozbyć wyłącznikiem czuwaka.

Na moje niefachowe oko wszystkie wskaźniki działają prawidłowo: mierniki natężenia/napięcia, manometry, hasler, diody po lewej stronie woltomierzy, kontrolki itd.

Nie jestem tylko pewien, czy kran hamulca po wciśnięciu klawisza "4" ustawia się na tej samej pozycji, co w poprzednim exeku. Jutro to sprawdzę.

Z widocznych błędów potwierdzam brak polskich znaków diakrytycznych w rozkładzie jazdy i treści wyświetlanych komunikatów radiowych.

Sam rozkład jest identyczny dla drogi "tam" i "z powrotem".

Podczas wczorajszej jazdy powrotnej spotkała mnie miła niespodzianka. Otóż przed wjazdem na stację w Grabówku zostałem (po raz pierwszy) skierowany na inny peron. I semafory po drodze (bodajże dwa) pokazywały odpowiednie sygnały.

[za to na przeciwnym torze, pod semaforem wjazdowym stały... 3 towary, jeden za drugim. Normalnie kolejowy traffic jam :D ]

Nie ukrywam - było to przyjemne urozmaicenie jazdy trasą znaną niemal na pamięć.

Niestety, dziś to już się nie powtórzyło.

Gdyby komuś chciało się dociec, jakie czynniki spowodowały wspomniane odchylenie - załączyłem skompresowany log z wczorajszej służby.

@firleju (i @tmj też) odwaliłeś kawał świetnej, potrzebnej i żmudnej (jak pchanie łańcucha pod górę) roboty.

Podłączam się do propozycji któregoś z przedmówców: możemy spokojnie zacząć zrzutkę na browar, szkocką, czy co tam zechcesz. Podaj tylko numer konta (ewentualnie numer, na który należy wysyłać SMSy o treści "firleju" ;)) coby przelew mógł się dokonać.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 06 Lutego 2017, 00:51:21
Po przeczesaniu zrodel szczotka znalazla sie jedna przyczyna bledu hamulca lokalnego. Pomoglo w przypadku EU i chyba takze innych, ale SN61 pozostaje odporny (w SN dziala hamulec glowny, ale AI go nie uzywa, no i lokalny tez powinien chodzic, wiec cos tam jeszcze jest skopane)

Skorygowalem przy okazji troche obsluge drzwi w skladach AI; powinny teraz pozostawac otwarte na przystanku az do odjazdu, bez wachlowania co chwila, gdy mechanik sie budzi.

Rzucanie kamera zredukowane do bardziej sensownych rozmiarow. Poczatkowo bylo dopasowane do EU07, ktora ma dosc lagodnie ustawione paramtery w konfiguracji, wiec w pozostalych pudlach dzialo sie, ze hej.

Jesli brak glew.dll jest problemem to w przyszlosci mozna by skompilowac go w jedna calosc z .exe, ale plik bedzie tak ze dwa razy wiekszy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 06 Lutego 2017, 16:09:40
Exe po konwersji ma kłopot z rysowaniem niektórych obiektów. Złapałem takie coś jak w załączniku. Prawidłowy screen zrobiony na exe 483 z paczki.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 06 Lutego 2017, 16:14:59
W ktorej scenerii wystepuje to miejsce? Nie bardzo mi sie widzi szukanie na slepo :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 06 Lutego 2017, 16:23:04
Tylko czym to się technicznie różni od drzewa? Node triangle z alfą.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 06 Lutego 2017, 16:32:35
Screeny z błędem zrobiłem w nocy, późno już było. To są domki na Kaliskiej po lewej od torów przed Lublinkiem. Miałem też kilka tak narysowanych drzew, ale nie wszystkie. Kilometraż widać na screenie (po 6 kilometrach). Exe z 170205. Jednak jeszcze sprawdzę na tej nowszej kompilacji. Wcześniej bawiłem się klawiszami F5, F6, F7 i F8, one przełączają też widok teksturowania, może nie wróciło jak trzeba. Sprawdzam teraz 170206, może to jednorazowy wybryk. Wczytywanie Kaliskiej skróciło się o 300 sekund.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 06 Lutego 2017, 16:44:13
U mnie wyglada jak trzeba, chociaz nie sprawdzilem tez przy wlaczonym VBO, zobacze za chwile. Moze to bylo po zabawie klawiszami funkcyjnymi? Ten drugi screen wyglada jakby wlaczony byl tryb wireframe albo cos.

edit: VBO rysuje tak samo, znaczy sie widac plot na obu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 06 Lutego 2017, 16:47:48
Witam.
 Wczoraj w ramach testu uruchomiłem na Exe++170205 Kaliską z towarem Sieradz - Ostrów ( ET22+ Gags). Zaobserwowałem że lok wpada bardzo łatwo w poślizg podczas rozruchu. A co najważniejsze ani piasecznica, ani hamulec przeciwpoślizgowy nie powodują żadnej reakcji. Ba, nawet zjechanie nastawnikiem do zera nic nie daje. Pomaga dopiero zdecydowane hamowanie hamulcem zasadniczym. Czy zauważył ktoś z kolegów podobny problem? Dzisiaj ustawie ten sam skład na TD i sprawdzę czy jest on powtarzalny.
  Czy hamulce nie są zbyt słabe w tej wersji? Nawet przy nastawie P w całym skladzie pociągu, reakcja jest dużo słabsza, niż na oficjalnych wersjach exe. Zauważyłem rownież brak wskazań woltomierza NN.
O bujaniu kamery, i hamulcu pomocniczym była już mowa.
Generalnie jakoś ładniej wygląda grafika na tym exeku. Scenerie ładują się o wiele szybciej. Pociągi prowadzone przez AI jadą normalnie, reagując na semafory, W4 jak trzeba.
Pozdrawiam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 06 Lutego 2017, 17:07:20
Witam.
 Wczoraj w ramach testu uruchomiłem na Exe++170205 Kaliską z towarem Sieradz - Ostrów ( ET22+ Gags). Zaobserwowałem że lok wpada bardzo łatwo w poślizg podczas rozruchu. A co najważniejsze ani piasecznica, ani hamulec przeciwpoślizgowy nie powodują żadnej reakcji. Ba, nawet zjechanie nastawnikiem do zera nic nie daje. Pomaga dopiero zdecydowane hamowanie hamulcem zasadniczym. Czy zauważył ktoś z kolegów podobny problem? Dzisiaj ustawie ten sam skład na TD i sprawdzę czy jest on powtarzalny.
Coz moze byc nie tak z obsluga tego konkretnego wariantu ET22. Postawilem go na TD i nawet gdy stoi nieruchomo rzuca sie w nim kamera, co sie normalnie nie powinno zdarzac. I faktycznie, slizga sie. Zobaczymy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 06 Lutego 2017, 17:12:43
Na 170206 rzucanie Kabiną (nie kamerą) mam znośne, co nie znaczy że jest dobrze. Wyświetlanie drzew i płotów wygląda na jednorazowy wybryk, ale będę to miał na uwadze. Na składach osobowych natomiast nie potwierdzę ślizgania, bo nie udało mi się do tego doprowadzić. O ile pamiętam powinien pomóc hamulec przeciwpoślizgowy, na numerycznej klawisz 0. num enter. Zero to nagłe. | @Stele
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 06 Lutego 2017, 21:12:17
Jesli brak glew.dll jest problemem to w przyszlosci mozna by skompilowac go w jedna calosc z .exe, ale plik bedzie tak ze dwa razy wiekszy.
Jak wersja tego pliku się nie zmienia z kolejnymi exe-kami, to po co? Powinien być jak najlżejszy, to będą lżejsze aktualizacje.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 06 Lutego 2017, 23:03:23
Na 170206 rzucanie Kabiną (nie kamerą) mam znośne, co nie znaczy że jest dobrze. Wyświetlanie drzew i płotów wygląda na jednorazowy wybryk, ale będę to miał na uwadze. Na składach osobowych natomiast nie potwierdzę ślizgania, bo nie udało mi się do tego doprowadzić. O ile pamiętam powinien pomóc hamulec przeciwpoślizgowy, na numerycznej klawisz 0. num enter. Zero to nagłe. | @Stele
Witam.
Oczywiście chodzi o kabinę, a nie kamerę. Dzięki za poprawienie. Co do poślizgu, sprawdziłem na TD z tym samym składem- taka sama sytuacja. Brak przyczepności, brak reakcji na sypanie piasku, w bardzo niewielkim stopniu pomaga hamulec przeciwpoślizgowy. Po zejściu nastawnikiem do zera, zestawy kołowe nadal rolują okresowo. Hasler wskazuje poprzednią prędkość. Jak dla mnie ET22 jest na tej wersji EXE ciężka do prowadzenia z pociągiem towarowym. Niby działa, ale nie tak jak powinna.
Pozdrawiam.
Edit:
To samo dzieje się podczas jazdy siódemką na TD domyślnym składem ( Exe C++ 170206). Jak dać jej ok 600A to zaczyna rolować i przestać nie chce:-) Jakby niewidzialna ręka lała litrami olej na szyny, a silniki trakcyjne zasilała energia kosmosu ( nastawnik na zero). Identycznie jak w ET22 poprzednio.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 06 Lutego 2017, 23:46:29
Jadę w tej chwili kiblem po kaliskiej, więc nie sprawdzę tego. Jednak dziwi mnie, po co dawać 600A przy rozruchu? Jeśli maszyny nie wychodzą z rolowania, to pewnie jest jakiś bug. Do tej pory jazdy, które zaliczyłem na ET22 i EU07 na C++, nie udało mi się złapać poślizgu. Po za tym, ja Ciebie nie poprawiałem z tą kamerą, albo źle mnie zrozumiałeś. W tej chwili okropnie trzęsie kabiną, a moim zdaniem ruchy powinna wykonywać kamera jako bezwładny element w kabinie, tak jak nasza głowa z oczami. Zakres amplitudy tych drgań powinien się zawierać w kilku centymetrach i większy powinien być w poziomie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 07 Lutego 2017, 00:57:48
Jeśli maszyny nie wychodzą z rolowania, to pewnie jest jakiś bug.
Zdecydowanie tak, i wyglada na to ze jest to dosc uniwersalne, ale ciezko w tym momencie znalezc przyczyne. Tzn mam potencjalnego kandydata, ale zrekonstruowanie go troche potrwa, no i nie ma gwarancji ze to jest akurat to.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 07 Lutego 2017, 01:07:43
W pliku ini i także w rainsted jest możliwość zaznaczenia uruchamiania elektryków nawet jeśli nie ma drutu jezdnego.
Na C++ ta funkcja nie działa. Na Kaliskiej są pętle startowe (tory) z których podstawiają się składy. Nie można takiego składu ruszyć nawet jeśli odhaczono "Napięcie tylko pod trakcją". Pętle te nie mają powieszonej sieci. Póki co to poważny problem. Może też powodować przypadkowe utknięcia składów w miejscach gdzie sieć jest marnie dopasowana, a skład musiał się zatrzymać.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: MaciejM w 07 Lutego 2017, 12:30:52
Nie działa przestawianie pozycji rozjazdów (T/t), chociażby w rozjazdach @Benka, innych nie sprawdzałem. Potwierdzam brak działania elektrowozów / EZT-ów na torze bez sieci przy wyłączonej w/w funkcji. Potwierdzam błąd związany z poślizgiem - objawia się nie tylko przy ruszaniu, ale też przy hamowaniu, gdzie osie trą po szynie i możemy stracić hamowanie. Smuga mi działa o każdej porze dnia i nocy, to samo podświetlanie okien w budynkach, latarń itd. Kamera buja, aż miło. Może aż za bardzo buja.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 07 Lutego 2017, 17:16:35
Dziś rano próbowałem pojechać Całkowo SN-61, i okazało się, że nie działa klawisz W (nie odpala zdarzenia), więc siłą rzeczy nie szło przejechać tej misji. I druga sprawa, chciałem zatrzymać szynobus hamulcem pomocniczym i tu ciekawostka - kran hamulca na ekranie się przekręcił, ale nie zadziałał. W ogóle brak hamowania.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: matek123 w 07 Lutego 2017, 17:46:00
Czyli nie działają eventlaunchery wyzwalane klawiszem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 07 Lutego 2017, 22:00:10
Uzupelnilem parser plikow .fiz o brakujace elementy, pozytywny efekty ktore dalo sie zaobserwowac (moga byc tez takie, ktorych nie zauwazylem) to przywrocenie mozliwosci jazdy elektrowozami bez drutu przy zaznaczonej opcji, i dzialajacy znowu woltomierz. Niestety nie pomoglo to z poslizgiem, na co mialem nadzieje, czyli problem jest gdzie indziej.
Poprawiony jest tez blad z rozjezdzajacym sie rozkladem przy braku podanego wyposazenia stacji.

edit: znalazlem ten cholerny poslizg :d  dla zainteresowanych, w Pascalowym oryginale bylo:
    if Max0R(Abs(FTrain),Fb)>TotalMassxg*Adhesive(RunningTrack.friction) then    {poslizg}
     SlippingWheels:=true;
    if SlippingWheels then
      begin
     nrot:=ComputeRotatingWheel ( ... // etc

a w tlumaczeniu:
    if (Max0R(abs(FTrain), Fb) > TotalMassxg * Adhesive(RunningTrack.friction)) // poslizg
    {
      SlippingWheels = true;
      nrot = ComputeRotatingWheel( ... // etc

i w rezultacie w wersji c++ po wpadnieciu w poslizg predkosc obrotowa kol byla przeliczana tylko raz, a potem juz zawsze krecily sie ze stala predkoscia bez szans na zatrzymanie. Teraz jest juz jak trzeba :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 08 Lutego 2017, 22:53:12
Elektryki wstały bez drutu. Lubię to.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: MaciejM w 08 Lutego 2017, 23:07:50
Siadło filtrowanie. Tutaj przykładowo tektura o nazwie #nazwa.tga nie powinna się rozmywać. Elektryki bez sieci działają ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 08 Lutego 2017, 23:28:02
Siadło filtrowanie. Tutaj przykładowo tektura o nazwie #nazwa.tga nie powinna się rozmywać.
Przyznam bez bicia ze nie siadlo, tylko jest specjalnie wylaczone bo do takich rzeczy to jest texture_bias, a nie zmuszanie karty do mordowania pixeli ;)  Roznica dosc imo ewidentna na dolaczonym screenie, chociaz ten akurat fragment kodu jeszcze nie jest wlaczony do wydanego .exe
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 09 Lutego 2017, 00:13:53
Witam.
Na nowej wersji (exe++ 170208) rolowanie ustało, lokomotywy wykazują normalną przyczepność. Bujanie jest na dość przyjemnym poziomie. Ażeby nie było tak słodko, hamulec zespolony działa coś nie tak. Testuje exe na Kaliskiej. AI prowadząc ET22-293 plus puste węglarki w Sędzicach przerżnęło S1 wyjeżdżając częściowo na szlak. Sprawdziłem, i okazało się że przy ciśnieniu 2,1 atm na wagonach, one prawie nie hamują. Dopiero przestawienie kranu na pełne hamowanie służbowe daje jakiś skutek. Może problem z zależnością hamowania od masy ładunku?
Pozdrawiam.
 Edit: Przetestowałem jeszcze inaczej. Zahamowałem skład hamulcem zespolonym, wyluzowałem samą lokomotywę i... ruszyłem bez problemu ze sznurkiem węglarek na haku ( zahamowanych).
 Wniosek: wagony nie hamują, pomimo wzrostu ciśnienia w cylindrach hamulcowych.
  Jeszcze jedno, w jadącym z naprzeciwka składzie światła nagle "przygasają" w odległości ok 400m od nas. Jakby maszynista go prowadzący, zgasił reflektory.
Pozdrawiam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 09 Lutego 2017, 14:51:55
Glupie pytanie, ale jak wlasciwie sa organizowane (zakladam ze na poziomie plikow scenerii) takie rzeczy jak przelaczanie zwrotnic przez T, albo eventy z klawisza W? Bo domyslnie te klawisze robia zupelnie cos innego, i jesli to mozliwe przydalby sie jakis punkt zaczepienia, zanim zaczne przegrzebywac cale .exe...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 09 Lutego 2017, 14:54:19
Jest to typ eventlauchera wyzwalany klawiszem w danym promieniu.
http://rainsted.com/pl/Symulator/MaSzyna/Scenery.doc#node_.E2.80.A6_eventlauncher
Zwrotnice hardkodowane kiedyś były, ale zostały usunięte dawno temu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 09 Lutego 2017, 15:37:04
Dzieki, znalazlo sie. Tradycyjnie juz zrodlem byla roznica w kodowaniu stringow w Borlandzie (gdzie znaki numerowane sa od 1) i w stl (gdzie numerowane sa od 0). W rezultacie eventy nie dostawaly swojego klawisza sterujacego. Teraz jest ok, bedzie w nastepnej wersji .exe
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 09 Lutego 2017, 15:37:27
Witam ponownie.
Nie dam spokoju z tymi hamulcami. Sprawdziłem teraz na TD, wagony pasażerskie hamują normalnie, natomiast towarowe wcale, niezależnie od lokomotywy. Moim zdaniem ma to związek z nastawą hamulca w wagonach G, P, R. Na R hamuje normalnie. Sprawdzał ktoś ten błąd? Exe C++ 170208.
Pozdrawiam.
Edit: Można by jeszcze sprawdzić co da przestawienie hamulca w kabinie. Zaraz przetestuje.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 09 Lutego 2017, 16:04:34
To by odpowiadało temu, że zaobserwowałem przerżnięcie składów towarowych na kaliskiej przez S1. Sprawdzę czy efekt powtórzę na zwykłym exe, jeśli pójdzie dobrze, to z hamulcami wagonów jest słabo. ET42 urwało mi się od składu, ale tu nie mam jakiegoś konkretnego punktu zaczepienia.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 09 Lutego 2017, 16:37:57
Witam.
Sprawdziłem teraz ponownie na TD. Przestawienie hamulca na R w lokomotywie, ani na P w wagonach nic nie dało. Zdecydowanie z hamulcami w towarowych jest problem. Nastawa R w pasażerskich działa, G oraz P w towarowych już nie. Skład nie hamuje wcale.
Edit: Sprawdziłem na oficjalnym exe z paczki. Wagony towarowe w stanie zahamowanym trzymają jak przyspawane.
Pozdrawiam.
Ps. Wczoraj na Kaliskiej u mnie też urwało byka od talbotów w Błaszkach. Nie wiem czemu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 09 Lutego 2017, 17:06:07
Czy moglbys jeszcze sprawdzic, czy po przestawieniu wagonow pasazerskich z R na cos innego dalej zachowuja sie normalnie, czy ida w maliny?

Ze z hamulcami jest cos na rzeczy bylo raczej pewne od momentu gdy SN61 jezdzil sobie, kompletnie je ignorujac, ale ten system jest tak rozlegly, ze dobrze byloby znalezc punkt startu. Na chwile obecna nie wiem czy sa to nastawy, czy tez moze blad siedzi w kodzie jakiegos konkretnego typu/rodziny hamulcow.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 09 Lutego 2017, 17:15:27
 Chciałem to właśnie sprawdzić przestawiając z R na P, tyle że nie mogę za nic zmienić nastawy z R na coś innego. Kombinacja klawiszy dla towarowych nie powoduje żadnej reakcji w pasażerskich. Bo byłby wtedy jak piszesz, punkt zaczepienia czego szukać. Zna ktoś sposób? Nawet z poziomu startera się nie udaje.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 09 Lutego 2017, 17:20:56
Musisz chyba zmienic wpis dla wagonu w pliku .fiz -- np dla 1xxa jest:
Cntrl. BrakeSystem=Pneumatic LocalBrake=ManualBrake BrakeDelays=R ASB=Yes MCPN=1
co, o ile sie nie myle oznacza, ze wagon przyjmie tylko nastawienie R.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 09 Lutego 2017, 17:36:48
A o tym nie pomyślałem. Zmieniłem nastawę dla wagonu 111A na P, a następnie G. I niestety to zły trop, są zahamowane przy spadku ciśnienia w PG jak trzeba. Szkoda...
Edit: W ramach eksperymentu dodałem linijkę " ASB=Yes " w nastawie losowego wagonu towarowego ( 412z), która występuje w fiz. 111A, niestety dalej to samo.
A może podmienić zawory rozrządcze? - " tonący brzytwy się chwyta"
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 09 Lutego 2017, 17:55:47
Jesli udalo sie to wykluczyc, to akurat nie jest zla wiadomosc. W takim razie potencjalnym kandydatem bylyby hamulce z rodziny ESt3 (a konkretnie TNESt3) bo wystepuje on chyba we wszystkich problematycznych wagonach... chociaz takze chyba w bhp_v1 ktore zdaje sie nie jezdza normalnie? Warto by je moze tez sprawdzic.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 09 Lutego 2017, 17:58:12
Jeździłem z wagonami BHP, nie miałem problemów z hamulcami. Ale niech jeszcze ktoś to sprawdzi.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 09 Lutego 2017, 18:00:40
Bingo. Podmieniłem zawory rozrządcze pomiędzy 111A i 412Z wagony towarowe teraz hamują. Ale tylko gdy wkleiłem cały wpis hamulca, gdy podmieniony sam zawór-to samo:-(
Czyli to: Brake: BrakeValve=ESt3 Size=16 MBF=144 MaxBP=3.8 BCN=1 BCR=0.2032 BCD=0.14 BCMlo=3.43 BCMHi=12.00 NBpA=4 BM=P10-Bg BCS=2.7 BSA=16.00 BVV=88 BRE=0.8Na to:Brake: BrakeValve=ESt4 Size=200 NBpA=4 MBF=90 MaxBP=4.0 BCN=2 BCR=0.1778 BCD=0.150 BCM=8.44 BCS=1.4 BSA=8.0 BM=P10-Bgu BVV=200
BRE=0.87
Bipy zaraz sprawdzę.
  No i Bipa niestety hamuje jak trzeba. Ja już głupi jestem...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 09 Lutego 2017, 18:36:13
Hmm a robi jakas roznice jak sie wymieni BhP BrakeValve z ESt3AL2 na zwykle Est3 ?

(w kodzie powoduje to wymiane jednego z elementow na zwykla rure. ale w pascalowym oryginale jest to samo, wiec nie wiem czy ma to jakies znaczenie. Tutaj by sie musial przyjrzec ktos, kto sie zna jak hamulce w ogole dzialaja)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 09 Lutego 2017, 18:57:12
Na hamulcach jak nikt zna tylko królik. Można by powiedzieć, że spędził nad nimi pod nimi (Stele ;)) 1/3 życia. @YouBy przybywaj!
Grześ, wybacz mi;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 09 Lutego 2017, 21:52:27
Tak, wagony 111A mają tylko nastawienie R. W 120A (Bh) powinny być dostępne obie nastawy przy pozostałych parametrach właściwie takich samych.

Jeśli ciśnienie w cylindrach rośnie prawidłowo, to problemu należy szukać w układzie siłowym (między cylindrem a klockami). Stawiam na to, że problemem jest określanie właściwej wartości P2FTrans. Wagony towarowe proste mają dwie wartości BCM (zmieniane).
Przy okazji - czy coś się zmienia po zmianie nastawy próżny/ładowny (h/H w widoku freefly)?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 09 Lutego 2017, 22:05:03
Na C++ 170208 dwa razy z rzędu wywaliło mnie do windowsa z logiem kończącym się jak w załączniku. Zrobiłem screen komunikatu, ale się nie zapisał, więc dodam tylko, że czegoś program nie znalazł po czym się zwiesił i zamknął. Były to dwa różne scenariusze. Skład ET42+ beczki, hamowanie miałem normalne, to skład który wcześniej urwał się od loka i zablokował ukończenie jazdy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 09 Lutego 2017, 22:19:30
Jeśli ciśnienie w cylindrach rośnie prawidłowo, to problemu należy szukać w układzie siłowym (między cylindrem a klockami). Stawiam na to, że problemem jest określanie właściwej wartości P2FTrans. Wagony towarowe proste mają dwie wartości BCM (zmieniane).
Z tego co moge znalezc, funkcja BrakeForce zwraca wartosc 0 poniewaz wyliczona wartosc u jest mnozona przez K, ktore w przypadku ManualBrake ma wartosc 0, poniewaz ManualBrakePos ma wartosc 0, i nie wyglada zeby cokolwiek ja zmienialo. Z tym, ze Bhp ktore rowniez maja hamulec lokalny ManualBrake jakos hamuja, wiec chyba dzieje sie tutaj cos jeszcze... no i akurat ten kod jest identyczny z tym co jest w Pascalu, wiec za bardzo to nie pomaga. Trzeba grzebac dalej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 09 Lutego 2017, 22:21:19
Na C++ 170208 dwa razy z rzędu wywaliło mnie do windowsa z logiem kończącym się jak w załączniku. Zrobiłem screen komunikatu, ale się nie zapisał, więc dodam tylko, że czegoś program nie znalazł po czym się zwiesił i zamknął.
Jesli to nie problem, mozesz sprawdzic czy w katalogu symulatora znajduje sie plik z eu07 z 'crashdump' w nazwie, i jesli jest, to czy moglbys go tutaj dolaczyc?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 09 Lutego 2017, 22:31:58
W katalogu głównym nie znalazłem takiego pliku, odpaliłem jeszcze raz ten sam scenariusz z ET42, chwilę jeszcze mam do odjazdu. Za każdym razem jest podobny odcinek czasu od uruchomienia scenerii do wysypu. Wyłączyłem w konsoli zapis jakichkolwiek logów, za to przygotowałem się na zarejestrowanie komunikatu na ekranie. W momencie jego pojawienia niestety printscreen nie zadziała.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 09 Lutego 2017, 22:47:10
W katalogu głównym nie znalazłem takiego pliku
Hmm sprawdzilem na szybko u siebie, i tutaj crashdump dziala normalnie... nie trzymasz chyba symulatora w podkatalogu Program Files, albo cos takiego?

Czy to jest na Kaliskiej, czy gdzie indziej? W ostatecznosci moge sprobowac odpalic u siebie, moze tez mi wyleci.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 09 Lutego 2017, 23:09:20
Maszyna trzymam w katalogu z zamienioną nazwą EU07, na "czysta paczka". Katalog jest na dysku C winXP. Wyłączyłem zapis wszelkich logów i zamknąłem konsolę, moment wysypu dawno minąłem. Wygląda, że zapisywanie ma z tym związek. Zamienię, ale to już jutro, nazwę katalogu na EU07 i odpalę jeszcze raz, ale z włączonymi zapisami logów i plików. Czy nazwa katalogu głównego z plikami maszyny jest w tym przypadku krytyczna? Niestety nie zauważyłem wcześniej, hamulce w beczkach są żadne, sam nie wiem jak to przeoczyłem. Natomiast sprawdziłem w trybie freefly, że w cylindrach jest ciśnienie. Jadę dokąd się nie wywalę z braku hamulca...
Tak, Kaliska ET42-024.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 09 Lutego 2017, 23:14:51
Jeśli ciśnienie w cylindrach rośnie prawidłowo, to problemu należy szukać w układzie siłowym (między cylindrem a klockami).
Tak ciśnienie rośnie normalnie do nominalnej wartości. Ale jest jeszcze inna dziwna rzecz. Wagony momentalnie luzują, tak jakby miały nastawę R, mają przecież G. Widać to doskonale po naciśnięciu F2 i przeleceniu nad składem. Ostatnio zresztą to nawet nim nie ruszam w celu sprawdzenia, gdyż wystarczy uruchomić lokomotywę i nacisnąć num6. Potem nastawnik do przodu i już wiadomo czy jest dobrze czy nie. Taki przykład: EU07 z załadowanymi podkładami 24 platformami sgs, masa ładunku ustawiona na 20 ton. Ciśnienie w cylindrach hamulcowych ok 2 atm, a pociąg rusza bez zająknięcia, po wyluzowaniu samej lokomotywy.
Cytuj
Przy okazji - czy coś się zmienia po zmianie nastawy próżny/ładowny (h/H w widoku freefly)?
Tego nie sprawdzałem.

  @Tmj, czy przypadkiem każdy typ zaworu nie jest w exe osobno opisany. Bo bipa ma jednak trochę inny typ-ESt3AL2. Może gdzieś jakaś literówka się wkradła przy tym nieszczęsnym ESt3?
Pozdrawiam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 09 Lutego 2017, 23:24:51
A ja w sprawie wysypu. Tym razem złapałem komunikat w załączniku, logu nie mam bo wyłączyłem opcję.Kurcze, czy tylko ja mam taki wysyp? Jutro sprawdzę na exe z 6 lutego, nie miałem tam takich zapaści.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 09 Lutego 2017, 23:40:36
Nazwa katalogu raczej nie ma znaczenia, o Program Files zapytalem bo na nowszych wersjach Windows zapis w tym katalogu jest wylaczony, ale wtedy nie dzialalo by tez tworzenie logow, wiec nie wiem czemu nie wyprodukowal crashdump.

Jesli wylaczenie logu pomoglo, to najprawdopodobniej wywala sie, gdy probuje zapisac dane jakiegos eventu albo czegos, ktory w rzeczywistosci nie istnieje. Jeden taki blad wycialem wczesniej, ale widac jest wiecej.

Co do hamulcow, znalazlem (kolejnego) potencjalnego kandydata -- IncBrakeMult() nie zwieksza ustawienia BrakeCylMult[0] poniewaz zalezy to (miedzy innymi) od wartosci parametru MaxBPMass, ktory jest domyslnie ustawiony na 1 * 1000, a test oczekuje wartosci nie wiekszej niz 2. @youBy, czy to mnozenie ma tam byc, czy jest to jakas pomylka? Po usunieciu mnoznika IncBrakeMult() zalacza sie, i wagony towarowe hamuja jak trzeba, ale nie wiem czy to nie psuje czegos gdzie indziej..?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 09 Lutego 2017, 23:46:28
Tylko że, do poprzednich wersji C++ nie miałem wysypów, dla mnie to nowa sytuacja. Wysypało mnie, mimo wyłączenia komunikatów, tyle że sporo później. Nic nie dodawałem do paczki, prócz następnego exe. Jest dziś zbyt późno aby jeszcze raz inicjować przejazd, ale jutro to zrobię. No i nikt inny nie zgłasza problemu, ten komunikat coś wyjaśnia?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 10 Lutego 2017, 00:00:37
Nie bardzo, tzn wyjasnia, dlaczego sie wysypal (nie znalazl potrzebnej funkcji) ale nie wyjasnia dlaczego nagle zaczeloby mu tej funkcji brakowac. Sprobuj zainstalowac ponownie VC2013 runtime ( ze strony Microsoftu, https://www.microsoft.com/en-us/download/details.aspx?id=40784 ) ale szczerze mowiac nie wiem, czy to pomoze.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 10 Lutego 2017, 01:38:21
Witam ponownie.
Jeszcze taka drobnostka, która mnie osobiście razi. Gdy zbliża się skład z naprzeciwka jego czoło na początku wygląda normalnie. Czyli widoczne z oddali trzy wyraźne punkty świetlne ( pierwszy screen), a po paru metrach wszystko "gaśnie" i wygląda jak na drugim obrazku.
 I kolejna sprawa związana z oświetleniem. Czynne w danej chwili komory semaforów jak dla mnie są zbyt słabo widoczne. Trzeba mocno się wpatrzeć, aby dostrzec co semafor wyświetla w danej chwili.
  Wiem że są dużo poważniejsze problemy obecnie, ale zgłaszam jak coś znajdę:-)
 
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 10 Lutego 2017, 02:25:06
Doinstalowalem biblioteki do systemu i pomoglo. Zaznaczylem zapis wszystkich logow i nie wysypalo. Co prawda nie ukonczylem calej trasy ze wzgledu na hamulce w towarach, ktore nie daja rady zatrzymac sie przed semaforem  z S1. Potwierdzam znikanie trojkata swiatel, z semaforami nie zauwazylem, ale mialem inne klopoty to moglo mi uciec. A mialem spac...
Do znalezienia i naprawy hamulca w towarach, nie ma co meczyc przejezdnosci.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 10 Lutego 2017, 03:46:04
Na ile moge powiedziec po pobieznych testach, to usuniecie mnoznika przy ladowaniu parametru MaxBPMass powoduje poprawne startowe ustawianie hamulcow w zaleznosci od ladunku, i sklady towarowe hamuja tak, jak oczekuje tego AI (z dokladnoscia 10-15m do wskaznika) a przy tym nie widac jakichs negatywnych skutkow ubocznych dla skladow osobowych. Nie wiem, czy ten sposob rozwiazania sprawy jest koszerny, ale dopoki nie wypowiedza sie eksperci, idzie to testow.

W uaktualnieniu poprawione jest tez przypisywanie klawiszy do eventow, jak rowniez obsluga ewentualnych duplikatow.

Oprocz tego zmieniona jest nieco obsluga tekstur, na sprzecie z openGL 1.4 lub nowszym. Od razu mowie ze jakiegos specjalnego szalu nie ma, niemniej jest chyba nieco lepiej, a w kazdym razie wyrazniej :)

Jesli chodzi o swiatla, to mozliwe, ze po przeniesieniu na c++ ogolna wydajnosc podniosla sie na tyle, ze silnik wlacza teraz wyswietlanie tekstur zamiast punktow swietlnych nieco wczesniej niz poprzednio, co paradoksalnie redukuje ich widocznosc. Ale sprobuje sie przyjrzec.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 10 Lutego 2017, 09:23:39
Punkty świetlne powinny być widoczne zgodnie z ustawieniem w t3d, jak wszystkie inne obiekty. Nie było to hardkodowane i nigdy nie było ustawiane na tak wielką wartość. Raczej na kilka-kilkanaście metrów, gdy wyraźnie widać już teksturę i ten pikselik mógłby razić.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 10 Lutego 2017, 13:43:36
Wstepnie po jednym przejezdzie powiem, ze sklady towarowe zaczely hamowac jak trzeba. Przejechalem EU07-344 az do Zdunskiej Woli i tu zrobil sie problem. Podkusilo mnie przejac mijany sklad ET42-024, wcisnalem F5. Jest jakis problem zwiazany z urywaniem skladu od loka. Uruchomienie autopilota powoduje natychmiastowe hamowanie, ponowne ruszenie skutkuje rozpieciem sprzegu. Odpalilem jesze raz osobowy, jechalem na zmiane ja i wlaczylem AI, natychmiastowe wdrozenie hamowania do zatrzymania, po ponownym ruszeniu okazalo sie, ze lok sie wypial. Sprawdzenie wagonow zostawionych na szlaku - pozostaja zachamowane. Jest mozliwosc ponownego spiecia skladu i odjazdu. C++170209. Trzeba to sprawdzic na TD, odpalanie Kaliskiej zbyt dlugo trwa.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 10 Lutego 2017, 13:52:27
Tzn problem wystepuje, jesli prowadzisz pociag, i po rozpedzeniu wlaczysz autopilota przez shift+Q, czy przy przejmowaniu przez f5? Czy moze w oby przypadkach?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: joey w 10 Lutego 2017, 14:08:27
Wszystko testowane pod Linuksem Mint 17.1 z Wine 2.1, Pentium Dual CPU E2180 2GHz, 2GB RAM, Radeon HD5450 512MB RAM.
Wrazenia na eu07++170209.exe:
· Skrocony czas ladowania (Calkowo PMT zima – 5'43" na exe 481 vs 3'01" na testowanym).
· Bardzo podoba mi sie jak filtrowane sa teraz drzewa, niestety inne tekstury zaczely nieco pikselizowac z oddali, a w kabinie SP42 pojawily sie grube biale ramki wokol wskazowek (ramki.jpg).
· Bujanie jest wciaz absurdalne, bardzo ograniczajace widocznosc na lukach, zwlaszcza w S*42.
· We wspomnianym scenariuszu samochody osobowe z luboscia przejezdzaja przez zamkniete szlabany (gotcha.jpg), tylko Autosan zatrzymywal sie jak nalezy, na exe 481 jest ok.
· Zauwazalny, choc nieduzy spadek wydajnosci objawiajacy sie przede wszystkim opoznionym reagowaniem na klawisze klawiatury.

Na eu07++170209.exe zauwazylem, ze z opcja pauzy na starcie przy lokomotywach spalinowych slyszalny jest syk hamulca, ktory nie chce zniknac (moze byc kwestia systemu).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 10 Lutego 2017, 14:09:01
W obu przypadkach. F5 i shift+Q
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 10 Lutego 2017, 14:21:46
Witam.
Potwierdzam błąd z porzucaniem wagonów. Wczoraj go wymacałem na exe 170208, z tym że u mnie  wypięcie składu wystąpiło w jednym tylko pociągu ( Kaliska, sklad ET22-213 plus talboty). Chciałem sprawdzić to jeszcze dziasiaj, czy jest powtarzalne. W logu jest chyba newet ślad po tym zdarzeniu w postaci komendy "shunt velocity" czy coś w ten deseń (sprawdzę dokładnie jak wrócę do domu). Może Ai chwilowo przechodzi w tryb manewrowy? Świadczyło by o tym towarzyszące temu zjawisku wygaszenie na chwilę reflektorów i podniesienie drugiego pantografu ( u mnie tak to wygląda).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 10 Lutego 2017, 14:39:34
Zgadzam sie z tym, ze wyglada to na przejscie w tryb manewrowy. Mam te same objawy. Dodatkowo ET42 ktore przejmowalem mialo caly czas wlaczona syrene, co wlasnie sklonilo mnie do jego przejecia. Wycie ciagle syreny ET 42 obserwowalem juz wczesniej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 10 Lutego 2017, 14:40:05
&middot; Bardzo podoba mi sie jak filtrowane sa teraz drzewa, niestety inne tekstury zaczely nieco pikselizowac z oddali, a w kabinie SP42 pojawily sie grube biale ramki wokol wskazowek (ramki.jpg).
To moze byc zwiazane z ustawieniami karty graficznej w systemie -- u siebie nie obserwuje tego, nawet po wylaczeniu na probe multisamplingu (zalacznik) Tak czy owak w duzej mierze winna jest tutaj tekstura, na ktorej wskazowki maja takie wlasnie biale tlo (chyba, ze jest to efekt zamierzony) Elementy powinny miec obwodki ktore sa niejako "przedluzeniem" koloru obiektu na co najmniej kilka sasiednich pikseli, eliminuje to tego typu artefakty.

W obu przypadkach. F5 i shift+Q
Puscilem na probe sklad towarowy po TD, rozpedzilem go do ~70 km/h i wrzucilem autopilota -- autopilot istotnie wdusil hamulec, ale na ile moge powiedziec to bylo to spowodowane aktualna predkoscia szlakowa (Vd pod f2) ktora wynosila 40 km/h -- po zwolnieniu do tej predkosci autopilot zluzowal hamulce i jechal dalej, bez zatrzymywania.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 10 Lutego 2017, 15:08:23
A tam wskazówki nie są prostokątami z teksturą na alfie? W wielu starszych pojazdach tak jest.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 10 Lutego 2017, 15:14:18
Sa zdjeciami wskazowek na bialym tle, z alfa. I problem w tym ze pomalowana na czarno jest tylko ta czesc, ktora pasuje do alfy co do piksela. I przy aktywowanym mip-mappingu, czyli tak jak to powinno byc, karta graficzna ciagnie kolory takze z sasiednich pikseli, ktore w tym wypadku sa biale. Dlatego elementy normalnie umieszcza sie na tle w kolorze elementu, wtedy te dane z sasiednich pixeli nie wplywaja negatywnie na kolor koncowy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 10 Lutego 2017, 15:15:36
Witam.
W logu u mnie jest jak się nie mylę taki wpis z tego zdarzenia odprzęgnięcia ET22-213 od reszty składu:
EVENT ADDED TO QUEUE: se_i12_s1 by et22-213
EVENT LAUNCHED: se_i12_s1 by et22-213
SetVelocity    40.00     0.00 != ShuntVelocity * *
Multiple passed
EVENT ADDED TO QUEUE: se_i12_sem_ligh1 by et22-213
EVENT ADDED TO QUEUE: se_i12_sem_info_stop by et22-213
EVENT LAUNCHED: se_i12_sem_ligh1 by et22-213
EVENT LAUNCHED: se_i12_sem_info_stop by et22-213
Type: UpdateValues - SetVelocity 0.000000 0.000000
Z tego co pamiętam komenda "Shunt" odnosi się właśnie do przejścia Ai w tryb manewrowy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 10 Lutego 2017, 15:19:07
O eventach nie mam niestety zielonego pojecia :) Moge sprobowac wylapac sytuacje, w ktorych wlaczany jest tryb manewrowy, ale jesli jest to reakcja AI na otrzymana komende. to czy klopot moze byc z tym, jak oskryptowany jest scenariusz?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 10 Lutego 2017, 15:21:15
S1 dodał się do kolejki i został wyzwolony. Sprawdził, że komórka semafora nie zawiera eventu ShuntVelocity i poszedł w alternatywę, czyli podanie S1. Wygląda na zabezpieczenie przed wygaszaniem tarczy i nie wysyła komendy rozprzęgania w żadnym razie.

Cytuj
Sa zdjeciami wskazowek na bialym tle, z alfa. I problem w tym ze pomalowana na czarno jest tylko ta czesc, ktora pasuje do alfy co do piksela.
Rozumiem. Problem będzie w wielu miejscach, bo raczej nikt z naszych grafików o tym nie myślał.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 10 Lutego 2017, 15:38:48
Rozpięcie pospiesznego:
EVENT ADDED TO QUEUE: ow_tm79_ms1 by ep07-344
EVENT LAUNCHED: ow_tm79_ms1 by ep07-344
Multiple passed
EVENT ADDED TO QUEUE: ow_tm79_sem_ligh1 by ep07-344
EVENT ADDED TO QUEUE: ow_tm79_sem_info_stop by ep07-344
EVENT LAUNCHED: ow_tm79_sem_ligh1 by ep07-344
EVENT LAUNCHED: ow_tm79_sem_info_stop by ep07-344
ShuntVelocity     0.00     0.00 = ShuntVelocity * *
Type: UpdateValues - ShuntVelocity 0.000000 0.000000
Eventlauncher sieradz_zapala_semafory
Przejęcie towarowego:
Key pressed: [F5]
Loading - binary model: dynamic\pkp\et42_v2\42]kabina_a.e3d
Loading - texture: dynamic\pkp\et42_v2\42]podloga.dds
Loading - texture: dynamic\pkp\et42_v2\42]kontrolki.dds
Loading - texture: dynamic\pkp\et42_v2\42]wskazniki.dds
Loading - texture: dynamic\pkp\et42_v2\42]wskpr.dds
Loading - texture: dynamic\pkp\et42_v2\42]lampa.dds
Loading - texture: dynamic\pkp\et42_v2\42]radiotelefon.dds
Loading - texture: dynamic\pkp\et42_v2\42]fotel.dds
Loading - texture: dynamic\pkp\et42_v2\42]oslona_przeciwsloneczna.dds
Loading - texture: dynamic\pkp\et42_v2\42]sciana_boczna.dds
Loading - texture: dynamic\pkp\et42_v2\42]wskazniki_p.dds
Loading - texture: dynamic\pkp\et42_v2\42]rt9_tarcza_p.dds
Loading - texture: dynamic\pkp\et42_v2\42]grzalka.dds
Loading - texture: dynamic\pkp\et42_v2\42]podnozek.dds
Loading - texture: dynamic\pkp\et42_v2\42]tyl.dds
Loading - texture: dynamic\pkp\et42_v2\42]grzejniki.dds
Loading - texture: dynamic\pkp\et42_v2\42]przod.dds
Loading - texture: dynamic\pkp\et42_v2\42]pulpit_dol.dds
Loading - texture: dynamic\pkp\et42_v2\42]przelaczniki.dds
Loading - texture: dynamic\pkp\et42_v2\42]pomocniczy.dds
Loading - texture: dynamic\pkp\et42_v2\42]wskzeg.dds
Loading - texture: dynamic\pkp\et42_v2\42]rt9_tarcza.dds
Loading - texture: dynamic\pkp\et42_v2\42]rt9.dds
Loading - texture: dynamic\pkp\et42_v2\42]fv4a.dds
Loading - texture: dynamic\pkp\et42_v2\42]kran_zasadniczy.dds
Loading - texture: dynamic\pkp\et42_v2\42]kierunkowy.dds
Loading - texture: dynamic\pkp\et42_v2\42]pulpit2.dds
Loading - texture: dynamic\pkp\et42_v2\42]pulpit_gora.dds
Loading - texture: dynamic\pkp\et42_v2\42]pulpit2a.dds
Loading - texture: dynamic\pkp\et42_v2\42]nastawnik.dds
Loading - texture: dynamic\pkp\et42_v2\42]pulpit1.dds
Loading - texture: dynamic\pkp\et42_v2\42]szyba.dds
Loading - texture: dynamic\pkp\et42_v2\42]sufit.dds
Loading - texture: dynamic\pkp\et42_v2\42]tyl_szafki.dds
Loading - texture: dynamic\pkp\et42_v2\42]rozklad.dds
Loading - texture: dynamic\pkp\et42_v2\42]pulpit1a.dds
rozpięcie:
EVENT ADDED TO QUEUE: zw_tm11_ms1 by et42-024-a
EVENT LAUNCHED: zw_tm11_ms1 by et42-024-a
Multiple passed
EVENT ADDED TO QUEUE: zw_tm11_sem_ligh1 by et42-024-a
EVENT ADDED TO QUEUE: zw_tm11_sem_info_stop by et42-024-a
EVENT LAUNCHED: zw_tm11_sem_ligh1 by et42-024-a
EVENT LAUNCHED: zw_tm11_sem_info_stop by et42-024-a
ShuntVelocity     0.00     0.00 = ShuntVelocity * *
Type: UpdateValues - ShuntVelocity 0.000000 0.000000
EVENT LAUNCHED: zdunskawola1_rozw by et42-024-a
Type: UpdateValues - rozw 0.000000 0.000000
Cały log w załączniku.
Cytuj
Wygląda na zabezpieczenie przed wygaszaniem tarczy i nie wysyła komendy rozprzęgania w żadnym razie.
Jesteś pewny? Coś jednak rozpina loka od reszty składu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 10 Lutego 2017, 16:18:29
Próbowałem wywołać to rozprzęgnięcie na TD. Bez skutku, podobnie jak u kolegi @Tmj. Wieczorem uruchomię Kaliską na różnych exe, i zobaczę co się będzie działo. Całkiem możliwe, że powoduje to też sama sceneria. Chociaż na oficjalnych exe nie zaobserwowałem tego typu zdarzeń.
Pozdrawiam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: SQT w 10 Lutego 2017, 16:25:33
Czy ktoś zauważył że na EU07 na tym skonwertowanym exe, sprężarka działa bez przetwornicy ?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 10 Lutego 2017, 17:24:16
Urwanie się loka jest często powtarzalne, skład osobowy z 07-344, kaliska. Wciśnięcie [Shift]+[Q], AI hamuje do zatrzymania. Następnie podnosi oba patyki luzuje, przez moment światła manewrowe i odjeżdża samym lokiem. Załączniki to obrazki z wystawki i log. Jeśli nie ma tego w eventach, to Key pressed: [Shift]+[Q] przynosi więcej skutków niż tylko proste włączenie autopilota. Ponieważ zaraz wyłączyłem symulacje, w logu to będzie pierwsze od końca Key pressed: [Shift]+[Q].
Edycja.
Dopiszę jeszcze raz, lokomotywa pozostawia zahamowane wagony, co widać na screenie nie widać, ale sprawdzałem. Nie zdążyłem jednak zauważyć, czy lok do odpięcia dociskał się do wagonów. CX MANIAK, jakby co, zwróć uwagę czy jest rewers napędu i dociskanie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 10 Lutego 2017, 17:52:28
Testowo odpaliłem AI na TD, zamiast jednego semafora wstawiłem tarczę manewrową i AI nie odpina się ani na sygnał ms1, ani na ms2. Ładnie przechodzi w tryb manewrowy przy ms2.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 10 Lutego 2017, 17:59:32
CX meldował, że na TD nie dał rady sprowokować to kuku. Jechałem ponad stówkę i AI zrobiło jak zrobiło, to też nie jest tak, że zawsze. Czasem przejmuje loka na spokojnie. Czasem zachowuje się tak jakby uruchamiał go od zimnego, mimo że jesteśmy w ruchu. Po za tym, nie chodzi o żadne semafory czy tarcze, to zwyczajnie dzieje się na szlaku. Choć w obrębie stacji też widziałem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 10 Lutego 2017, 19:27:35
Tak cos mi sie dziwnie wydaje, ze to rozlaczanie moze miec zwiazek ze zmiana w funkcji przejecia kontroli przez AI. Anulowalem na probe ta zmiane, i wlaczylem przy okazji logowanie aktualnego rozkazu dla pojazdow prowadzonych przez AI, wiec bedzie troche lepiej widac, co tam sie dzieje.

Wlaczona jest tez generacja mipmap dla tekstur .dds ktorym ich brakuje -- takich tekstur jest calkiem sporo, a po zmianach w renderingu moglo to powodowac brak tekstur na obiektach, co bylo dosc zauwazalne ;d

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 10 Lutego 2017, 19:41:32
Na warunkach, na jakich udało mi się wcześniej ten błąd powielić, na tym exe już tak się nie dzieje. Wyglądało to tak, że należało najpierw samodzielnie odpalić loka i włączyć AI, jeżeli tarcza wskazywała Ms2. Wtedy faktycznie lok się odpinał, bo przechodził do kolejnej komendy z listy (Disconnect). Jeżeli włączało się AI w sytuacji, gdy Ms2 już się świeciło, ale na kompletnie zimnym loku, AI robiło wszystko po kolei dobrze i się nie odpinało. Jeżeli odpaliło się loka, ale włączyło AI przy Ms1, a dopiero po chwili dało Ms2 też wszystko działało dobrze.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 10 Lutego 2017, 22:27:02
Zajęło mi to dużo czasu, ale objechałem Kaliską z Karsznic do Ostrowa i powrót na Kaliski. Nie udało mi się urwać wagonów, choć próbowałem dziesiątki razy. AI przejmuje skład tak jak powinien. Nie zwracałem uwagi na inne rzeczy, ale wszystkie składy towarowe na szlaku poruszały się prawidłowo, lub prawidłowo przepuszczały mnie, stojąc na boku. Na screenach manewry 07-344 na tory postojowe.
tmj - Jesteś Wielki.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 10 Lutego 2017, 23:11:48
Witam.
Ja również próbowałem na różne znane mi sposoby sprowokować AI do urwania składu, bez skutku! Co więcej teraz nie wygasza reflektorów jak poprzednio, przy oddawaniu mu sterów.
Brawo Tmj!
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 10 Lutego 2017, 23:20:53
Mam wrażenie, że zmniejszył się efekt gasnącego trójkąta nadjeżdżających z przeciwnej strony loków.
... Jeśli nie ma tego w eventach, to Key pressed: [Shift]+[Q] przynosi więcej skutków niż tylko proste włączenie autopilota. ...
Tak cos mi sie dziwnie wydaje, ze to rozlaczanie moze miec zwiazek ze zmiana w funkcji przejecia kontroli przez AI. Anulowalem na probe ta zmiane, i wlaczylem przy okazji logowanie aktualnego rozkazu dla pojazdow prowadzonych przez AI, wiec bedzie troche lepiej widac, co tam sie dzieje.
Krótko mówiąc, zgadłem.
Nie wstawiałem loga z jazdy, jeśli jest potrzebny, to mam z archiwizowany.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 11 Lutego 2017, 07:50:33
Odpaliłem z ciekawości Całkowo SN61, teraz wyzwalanie zdarzeń z klawisza działa, ale hamulec pomocniczy w SN61 nie. Dziwny bug, bo widać, że klawisz prawidłowo steruje kranem, ale skład w ogóle nie hamuje. Co również dziwne, hamulec zespolony hamuje dużo gorzej niż na starym exe, czyli próba zatrzymania się przed kozłem oporowym zakończyła się przyciśnięciem składu do kozła. Biorąc pod uwagę, że jechałem 20km/h, hamowanie rozpocząłem jakieś 400m od kozła, miałem pełen ZG i ustawienie hamulca P - po prostu coś jest nie tak z tym hamulcem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: RoboBatman w 11 Lutego 2017, 12:50:07
Kolego @tmj,chcąc stestować exe o nazwie "eu07++170210.rar" wybrałem sobie do jazdy byka ET22-R004. Chciałbym zgłosić iż na tym exe nie działa przyhamowanie poślizgu które znajduje się pod klawiszem "ENTER". Nie wiem czy tylko u mnie tak jest czy u innych też. Teraz druga wiadomość -tym razem dobra - ciesze się, że na tym exe, sceneria "TD" wczytuje się błyskawicznie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 11 Lutego 2017, 12:56:50
SN61 w ogole jakis dziwny jest :)  kiedys moze uda sie go rozgryzc, ale jeszcze nie teraz.

Na razie naprawilem obsluge pythona w bardziej zaawansowanych typach. Nawiasem mowiac, tekstura 2k na ekrany to troche przegiecie, 1k chyba bedzie wygladac calkiem przyzwoicie, zwlaszcza przy nieco ulepszonym renderingu, a obciazy system tak z 4x mniej.

Przy okazji, jest taki dosc ogolny problem logiczny na styku otwierania drzwi I obslugi ekranow -- uzywaja one tych samych klawiszy, co prowadzi do roznych sytuacji, od smiesznych takich jak AI wlaczajaca/wylaczajaca ekran zamiast otwierac drzwi na stacjach (w ST45), po bardziej powazne jak 186-2 otwierajaca drzwi na przystanku, i nie bedaca w stanie jechac dalej, bo dopoki drzwi sa otwarte wlaczony jest hamulec dynamiczny, co uniemozliwia zwiekszenie ciagu, a drzwi zamknac nie moze, bo nie ma tego w konfiguracji :d

edit:
Kolego @tmj,chcąc stestować exe o nazwie "eu07++170210.rar" wybrałem sobie do jazdy byka ET22-R004. Chciałbym zgłosić iż na tym exe nie działa przyhamowanie poślizgu które znajduje się pod klawiszem "ENTER". Nie wiem czy tylko u mnie tak jest czy u innych też.

O ile dobrze pamietam to w innych egzemplarzach ET22 dzialalo to, nie wiem czy ten sie akurat czyms rozni, czy tez cos sie w miedzyczasie popsulo, sprawdze.

edit2:
z tego co widze w widoku z zewnatrz, to po wprawieniu kol w pozlizg i nacisnieciu Enter so one na krotka chwile przyhamowane do zera, ale w tym czasie trzeba zmniejszyc ciag, bo w przeciwnym razie po chwili kiedy system przestaje dzialac i silnik znowu zaczyna napedzac kola na wysokich obrotach, to znowu zaczna sie one slizgac. To nie tak ma dzialac?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 11 Lutego 2017, 13:17:51
Hehe, widzę że cofnąłeś się o miesiąc z datą ;) Enter daje bodajże przyhamowanie i posypanie piaskiem. Na pewno nie powinno dojść do stanięcia kół w miejscu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 11 Lutego 2017, 13:25:38
O faktycznie, glupia literowka :)  tzn moze zle sie wyrazilem, one sie zatrzymuja 'w miejscu' w sytuacji, gdy sklad buksuje przy narzuceniu zbyt duzej sily zanim wszystko sie ruszy z miejsca (bo na poziomie kodu ten system na twardo wylacza flage poslizgu, i powoduje zmiane przeliczania predkosci obrotowej na tryb 'zwykly' tzn na podstawie predkosci poruszania sie lokomotywy. Jesli poslizg mial miejsce w ruchu, to beda sie krecic 'luzno' dopoki silnik znow nie dojdzie do glosu. Nie wiem czy tak to ma byc, tak juz bylo i nie zagladalem tam za bardzo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 11 Lutego 2017, 13:26:42
Pseudodrzwi trzeba wywalać gdzie się da. Chciałem zrobić alternatywę, ale syf w samej obsłudze drzwi mnie trochę przyhamował. Dla pojazdów bez drzwi, chciałem pod te klawisze przypisać universale nie robiące fizycznie nic. Tylko zapalające lampki, odtwarzające dźwięki i ruszające przełączniki, używające starych kluczy drzwiowych dla kompatybilności z modelami i mmd. Została kwestia od czego uzależnić ich obecność i możliwie ładnego wciśnięcia tego w kod.
VS na xp nie postawię z tego co widzę, więc zostajecie sami, póki nie kupię nowego komputera.

W traksie jest inny problem. Kierownik otwiera drzwi w wagonach. Lokomotywa nie ma już drzwi w fiz od dawna. Hamulec postojowy był pisany z myślą o EZT i włącza się przy otwartych drzwiach. No i przy wagonach też łapie. Co ciekawe mimo braku wpisu drzwi w lokomotywie, wciśnięcie klawisza odpowiedzialnego za zamknięcie drzwi je "zamyka" i ściąga blokadę jazdy. Świta mi, że z yB daliśmy wpis na obecność postojowego do fiz.

Co do SN61, to yB pracował nad nową przekładnią hydrokinetyczną, w pewnych konfiguracjach pracującą podobnie jak mechaniczne sprzęgło. Działało to w miarę dobrze, lepiej od obecnego sprzęgła na pewno, tylko nie udało mu się zrobić sprzęgła na nastawniku, tak jak w SM03 to jest. Źródłami niestety się nie podzielił. Dobrze byłoby to przepisać na cpp i zintegrować. Kaczuchę poświęcimy, jak nie uda się rozwiązać problemu.
Uciążliwą przekładnię ma także machajka, ale to problem niszowy.

Co do ekranów, traxx i dragon mają 1k*2k na dwa ekrany. Coś ma większą? Przy 512 napisy byłyby raczej nieczytelne. Można sprawdzić skalując na wyjściu, ale bez automatu skalującego wszystkie współrzędne i czcionki, przerabianie ręczne pod małą rozdzielczość byłoby męczące.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: matek123 w 11 Lutego 2017, 13:30:18
Nawiasem mowiac, tekstura 2k na ekrany to troche przegiecie, 1k chyba bedzie wygladac calkiem przyzwoicie, zwlaszcza przy nieco ulepszonym renderingu, a obciazy system tak z 4x mniej.
A jak wtedy będą wyglądać tabelki które są narysowane z linii o grubości 1-2 px?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: pinokio w 11 Lutego 2017, 13:31:07
U mnie na exe eu07++170210 fps na Kaliskiej zwiększył się z 20 do 60, skrócił się również czas wczytywania scenerii, super. Na EU07 sprężarka działa bez konieczności włączenia przetwornicy, nie słychać również wentylatorów oporów rozruchowych.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 11 Lutego 2017, 13:35:49
Co do ekranów, traxx i dragon mają 1k*2k na dwa ekrany. Coś ma większą?
No z tego co widze to tekstura ek1 w 186_v2 ktora robi za tlo ma 2048x2048. Mysle ze przy rysowaniu na 1k to i tak byloby ok, bo ekrany nie maja w normalnych warunkach wiecej niz 500 pikseli na ekranie, a przeskalowaniem w dol z rozmiaru bazowego zajmuje sie karta graficzna. Ale ze skrypt pythona ma to wszystko zakodowane na sztywno, to sprawdzenie wymagaloby sporo recznego dlubania.

edit:
A jak wtedy będą wyglądać tabelki które są narysowane z linii o grubości 1-2 px?
Trudno powiedziec, ale na przyklad linie 1-2 px w 6dg, na pulpicie uzywajacym tekstury 512x512 wygladaja tak jak w zalaczniku. imo calkiem wyraznie. Nie jest to oczywiscie produkt pythona, ale z punktu widzenia silnika tekstura to tekstura, zrodlo nie robi mu specjalnie roznicy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 11 Lutego 2017, 13:50:39
Pojedyncze ekrany normalnie mają rozdzielczości 640x480 i 800x600. Nie wiem, czy któryś z pojazdów nie ma więcej.

Co do poślizgów, to trzeba do tego podejść trochę inaczej, ale nie mam jeszcze gotowego rozwiązania.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 11 Lutego 2017, 13:51:23
Może zmieniłeś, ale tekstura z pythona nie była rozmywana przy skalowaniu. Z cienkich linii robiły się pływające, zanikające linie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 11 Lutego 2017, 13:54:56
No wlasnie zmienilem, dlatego wspominam :)  W przeciwnym wypadku faktycznie nizsze rozdzielczosci wygladalby tak sobie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 11 Lutego 2017, 18:03:18
ET41_v1 na ostatnim exe++ zrobiło mi oblot jednym członem :) Szkoda, że ten pociąg i tak nie miał przewidzianego powrotu, bo ciekaw jestem, czy by pojechał w takim stanie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 11 Lutego 2017, 19:51:55
W końcu odpaliłem coś do jazdy. Drzewa przy nowym filtrowaniu jakoś mniej mi się podobają, ale to kwestia przyzwyczajenia.
Luzujący skład strasznie skacze przy rozpychaniu buforami. Kwestia 40 km od zera, czy coś zmieniałeś w kroku obliczeń tutaj? Wcześniej całymi obiektami mi rzucało, ale takiego efektu nie widziałem.
Brak dźwięku wentylatora oporów odbiera większość frajdy z jazdy.
Filtrowanie paskudnie wygląda na ścianach lasu. One maja spory kawał alfy u góry na tle nieba.
Nie działa liczenie jednostek w pythonie "unit_no". Pewnie kolejny bug sprzęgu depotowego. Rozwala to ekran w en57a.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 11 Lutego 2017, 22:22:21
W końcu odpaliłem coś do jazdy. Drzewa przy nowym filtrowaniu jakoś mniej mi się podobają, ale to kwestia przyzwyczajenia.
Luzujący skład strasznie skacze przy rozpychaniu buforami. Kwestia 40 km od zera, czy coś zmieniałeś w kroku obliczeń tutaj? Wcześniej całymi obiektami mi rzucało, ale takiego efektu nie widziałem.
Brak dźwięku wentylatora oporów odbiera większość frajdy z jazdy.
Filtrowanie paskudnie wygląda na ścianach lasu. One maja spory kawał alfy u góry na tle nieba.
Nie działa liczenie jednostek w pythonie "unit_no". Pewnie kolejny bug sprzęgu depotowego. Rozwala to ekran w en57a.
Z tego co widze w kodzie, unit_no jest zwiekszany dla jednostek polaczonych z flaga 128, czyli nie zadziala przy 'standardowym' laczeniu na 55. Wentylatory sa naprawione, beda w nastepnej wersji .exe
Fizyki w zasadzie nie ruszalem, wiec jakiekolwiek skoki to zapewne cos co powstalo przy translacji. Nie bardzo rozumiem co znaczy rozpychanie buforami, jesli mozesz dac mi opis jak wywolac efekt moge sprobowac sie przyjrzec.

Krawedzie na teksturze lasu to niestety konsekwencja kombinacji dwoch czynnikow -- raz, wszystkie tekstury sa ustawiane domyslnie na 'zawijanie' w pionie i w poziomie. A dwa, mapowanie jest ustawione na cala powierzchnie tekstury, czyli mipmapping powoduje, ze gorna krawedz ciagnie piksele z samego spodu, ktory z reguly jest zielony i nieprzezroczysty.
Jakims tam rozwiazaniem mogloby byc dodanie cienkiego paska alfy na samym spodzie tekstury drzew -- wtedy gora zrobilaby sie przezroczysta, a tak malej przezroczystosci nie powinno byc widac przy gruncie. Lepszym wyjsciem byloby dodanie kontroli zawijania do tekstur, np przez dodawanie S albo T do parametrow w nazwie. Opcjonalnie polaczone z troche bardziej konswerwatywnym generowaniem koordynatow dla drzew itp. Tzn zamiast zakresu 0-100% uzywac cos w style 1-99%

A teraz z zupelnie innej beczki: testujac na Kaliskiej, wychodzi mi ze ladowanie tekstur to ~15% calego procesu ladowania -- roznica w czasie odpalenia scenerii to 95 sek vs 112. Zastanawiam sie wiec, czy bawic sie w opoznione ladowanie tekstur, bo zysk chociaz jest, to raczej niewielki, w porownaniu do wprowadzanej komplikacji.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 11 Lutego 2017, 23:00:34
Fork z okienkami i sterowaniem na GLFW:
https://github.com/Milek7/maszyna/tree/mover_in_c++
Obecnie zepsułem WM_COPYDATA i renderowanie tekstu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 11 Lutego 2017, 23:04:58
Cytuj
Z tego co widze w kodzie, unit_no jest zwiekszany dla jednostek polaczonych z flaga 128, czyli nie zadziala przy 'standardowym' laczeniu na 55.
Moja wina, miałem jakiś lipny skład w magazynie. Na starym exe to działało, ale raczej tu naprawiłeś błąd, a nie zrobiłeś nowy.
Cytuj
Nie bardzo rozumiem co znaczy rozpychanie buforami, jesli mozesz dac mi opis jak wywolac efekt moge sprobowac sie przyjrzec.
Ustaw długi skład, zahamuj z zatrzymaniem bez luzowania, mając powietrze w początku składu. Zluzuj skład. Sprzęgi będą się rozprężać, rozpychając skład o kilkadziesiąt cm, jako że końcówka będzie dłużej zahamowana od czoła. Ale to pewnie błąd współrzędnych, bo obserwowałem to na Olechowie.
Cytuj
Lepszym wyjsciem byloby dodanie kontroli zawijania do tekstur, np przez dodawanie S albo T do parametrow w nazwie.
To byłoby chyba najlepsze. Znacznik w nazwie tekstury, wyłączający zawijanie. W pionie dla ścian lasu/płotów i w obu osiach dla drzew. Nawet jak dać v na 0.95 to góra ciągnie z dołu i pojawia się pasek na górze modelu. Próbowałem z tym walczyć przy polach i cudów nie zdziałałem.

---------
Nie działa lod w t3d. Mimo wpisu maxdist w t3d wyświetla submodel do zasięgu renderowania. E3d nie badałem póki co.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 12 Lutego 2017, 20:22:33
Uaktualnienie z poprawkami dla wentylatorow rozruchowych i domyslnego typu sprezarki, powinna wymagac teraz czego trzeba.

Rozgrzebalem system obslugi tekstur i chwile to potrwa zanim sie z powrotem caly posklada, wiec przejscie/podlaczenie glfw potrwa kilka dni. Przy okazji, chyba nie warto od razu wycinac w pien elementow tylko dlatego, ze sa zrobione w oparciu o Windows -- #ifdef _WINDOWS i niech sobie siedza dopoki nie znajdzie sie bardziej uniwersalny odpowiednik, o ile w ogole sie znajdzie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 12 Lutego 2017, 21:14:55
Witam serdecznie.
 Nie wiem czy ktoś zgłaszał. Znalazłem jeszcze jeden mały problem. Na exe C++170210, ET41-V2 (np. ET41-166) nie daje się uruchomić. Nie podnoszą się po prostu patyki. Uprzedzam pytanie, ciśnienia w zbiornikach w normie. Nawet AI nie jest w stanie nic wskórać (uruchamia sprężarkę pomocniczą, przestawia kurek trójdrożny). Na exe Next4 lub z paczki, działa bez problemu.
Pozdrawiam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 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?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 13 Lutego 2017, 09:29:08
Mamy pewne doswiadczenia, ktore swiadcza o slusznosci propozycji postawionej przez firleya. Bedzie ciezko oceniac wyglad grafiki majac bledy w sterowaniu taborem.
Podzielam tez poglad, ze nie nalezy wycinac w pien elementow opierajacych sie o windowsa. To musi byc poparte korzysciami a nie niechecia do systemu Microsoftu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 13 Lutego 2017, 12:12:13
OK, jakie bledy na chwile obecna sa jeszcze do wylapania/poprawienia? Przydaloby sie zebrac je razem, bo rozwloczone sa po kilku stronach.

- hamulec reczny SN61. byc moze hamulce w SN61 w ogole, bo glowny np. hamuje ale nie wiem, czy dostatecznie szybko, nie znam sie (zarobiony jestem)
- ET41, problemy z urchamianiem itp
- na Calkowie "exe wylatuje po zalaczeniu baterii w tamarze". Co to jest tamara D: sprawdzilem SU45, SP42 i dla pewnosci ST44, ale zaden nie wylecial.
- wysyp, prawdopodobnie przy przelaczeniu do kamery ustawionej w terenie skrotem klawiszowym. Przyjrze sie, jesli uda mi sie to wywolac u siebie. crashdump by tutaj pomogl.
- blad z brakujacym dzwiekiem kranow w ET21, EN57, od czasu wprowadzenia SPKS

czy jest cos jeszcze, o czym wiadomo?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 13 Lutego 2017, 12:13:04
Dlatego wam dostosowałem bugtrackera. Róbcie tickety, dyskutujcie na konkretne tematy i zamykajcie sobie. ;)
Tamara to SM48.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 13 Lutego 2017, 13:21:21
Tamara to SM48.
Dzieki; na TD zachowuje sie bezproblemowo, ale przy okazji wyskoczylo, ze lotos_calkowo laduje sie bez szyn, wiec cos tam sie rozjezdza w parserze, do sprawadzenia.

Z innej beczki: w kodzie obslugi tekstur sa wzmianki, ze znak | moze rozdzielac kilka tekstur, a po ":" moga byc dostarczane parametry. Czy to jest jakos wykorzystywane w praktyce? Myslalem wlasnie o umieszczeniu parametrow zawijania itp w formacie nazwa:parametry ale wolalbym uniknac tutaj jakichs konfliktow.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 13 Lutego 2017, 13:24:14
Pokaż ten kawałek kodu, bo nigdy na to nie wpadłem. Były prefiksy @ # i sufiksy %n (filtrowanie) ,n (wiele wymiennych).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 13 Lutego 2017, 13:41:44
Właśnie sprawdziłem, TEM2 działa poprawnie. Pozwoliłem sobie na mały załącznik. Szkoda, że sobota i niedziela wypadły mi daleko od komputera, sprawdziłbym to wcześniej.
Tamara to SM48.
W symulatorze nie mamy plików z nazwą SM48. Prawidłowo Tamara, to TEM2. Wiem, że to to samo, ale patrząc z punktu widzenia obsługi MaSzyny, bardziej jednoznaczna nazwa, to TEM2.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 13 Lutego 2017, 13:42:15
Pokaż ten kawałek kodu, bo nigdy na to nie wpadłem. Były prefiksy @ # i sufiksy %n (filtrowanie) ,n (wiele wymiennych).
To jest w GetTextureID() na poczatku:
    size_t pos = fileName.find(':'); // szukamy dwukropka
    if (pos != std::string::npos) // po dwukropku moga byc podane dodatkowe informacje
        fileName = fileName.substr(0, pos); // nie bedace nazwa tekstury
    pos = fileName.find('|'); // szukamy separatora tekstur
    if (pos != std::string::npos) // po | moze byc nazwa kolejnej tekstury
        fileName = fileName.substr(0, pos); // i trzeba to obciac
przy pobieraniu tekstury takie dane sa ignorowane, ale nie wiem czy to nie wyskakuje gdzie indziej. Przepuscilem na probe jedna z wiekszych scenerii przez .exe i nie bylo tam w uzyciu ani razu, ale wole sprawdzic.

Jak wyglada w praktyce ten zapis o n (wiele wymiennych) Tzn. na prostym przykladzie jak wyglada zapis, jesli to nie problem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 13 Lutego 2017, 14:00:26
Nie potwierdzam braku możliwości uruchomienia ET42-166. Załączniki pokazują ją w ruchu. Jedna uwaga, po załączeniu baterii nie daje wyłączyć się buczka nastawnikiem kierunku. W tym przypadku należy wcisnąć spację.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 13 Lutego 2017, 14:28:58
nazwa_textury_w_node_dynamic,1.ext
...
nazwa_textury_w_node_dynamic,4.ext
Działa tylko dla dynamic i wymaga jakiegoś znacznika w mmd w definicji modelu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: joey w 13 Lutego 2017, 14:48:14
Wydaje mi sie, ze wysyp SM48 na Calkowie (misja niebezpieczny pociag) ma u mnie miejsce za kazdym razem, gdy ma dojsc do wyswietlenia podpisu dla dzwieku (w tym przypadku calkowo_np_wg01-pl.txt).
Zauwazylem takze, ze wygenerowane przez eu07++170210.exe modele e3d swieca cale, jakby w t3d 'selfillum: true' bylo dla kazdego submodelu, a jest najwyzej dla kilku. Nie wiem jak generuja sie e3d, gdy nie ma zadnego submodelu z 'selfillum: true' w t3d.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 13 Lutego 2017, 14:59:11
Wrócę do SN61, hamulec zasadniczy działa, droga zatrzymania pojedynczego Ganza ze 100km/h to 740m. Dla porównania dodam, że sprawdziłem również drogę hamowania siódemki, tu droga hamowania jest 500m ze 100km/h obojętne czy to hamulec zasadniczy czy pomocniczy. Hamulec pomocniczy w SN61 nie działa, jak widać w załączniku animuje się rączka, natomiast nie rośnie ciśnienie w cylindrach hamulcowych. Jest jednak plus dla tego pojazdu, po przejściu na C++ ustąpiło gaśnięcie silnika przy sterowaniu z kabiny B. Jak pisał @Stele, wybitne przypadki błędów bez żadnej dyskusji należałoby wrzucać na bugtrackera.
Dzisiejsze posty to testy exe170212
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 13 Lutego 2017, 15:33:42
nazwa_textury_w_node_dynamic,1.ext
...
nazwa_textury_w_node_dynamic,4.ext
Działa tylko dla dynamic i wymaga jakiegoś znacznika w mmd w definicji modelu.
OK, z tego co widze ",4" itd jest czescia tekstury, wiec nie powinno sie gryzc z nowym mechanizmem. Mysle o czyms w rodzaju
texturename.ext:traits
gdzie .ext to opcjonalne rozszerzenie nazwy pliku, a :traits to zdefiniowane opcjonalne parametry:
s (wylacza zawijanie tekstury w 'poziomie')
t (wylacza zawijanie tekstury w 'pionie')
# (odpowiednik obecnego # na poczatku nazwy)
docelowo takze inne, ale od tych mozna zaczac.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 13 Lutego 2017, 18:21:34
Testuję cały czas przejezdność i funkcjonalność pojazdów, z tym że tym razem uruchomiłem tryb VBO i mam takie kwiatki. Z tego co widzę, to nie tylko ja mam taki problem. Problem leży w teksturach i w exe, tu pytanie, czy tryb VBO pozostanie i czy można z tym coś zrobić?
Najciekawszy wydał mi się efekt ufo, co prawda widoczny tylko z kabiny siódemki (przez szybę), Po wyjściu z loka "kosmitów" już nie było.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 13 Lutego 2017, 18:50:19
Sciezka renderowania VBO w ogole jest cokolwiek niedopracowana (brakujace skrzyzowania itp) ale z uporzadkowaniem tego wstrzymalbym sie do czasu przejscia na ulepszony renderer, jesli w ogole (bo np. moze sie okazac ze prosciej bedzie spiac calosc z jakims istniejacym silnikiem, zamiast praktycznie pisac od nowa wlasny)

W dzisiejszym uaktualnieniu male poprawki bledow i niedopatrzen -- Calkowo powinno sie teraz ladowac poprawnie, "interfejs uzytkownika" czyli teksty spod klawiszy funkcyjnych nie beda wiecej sie gryzly z otoczeniem i znikaly, co zdarzalo im sie w EZT i innych ciasnych spalinowkach. A w ramach bezuzytecznych bajerow sila smugi swiatla zalezy teraz od ilosci wlaczonych reflektorow, i pory dnia.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 13 Lutego 2017, 18:54:52
Sciezka renderowania VBO w ogole jest cokolwiek niedopracowana (brakujace skrzyzowania itp) ale z uporzadkowaniem tego wstrzymalbym sie do czasu przejscia na ulepszony renderer, jesli w ogole (bo np. moze sie okazac ze prosciej bedzie spiac calosc z jakims istniejacym silnikiem, zamiast praktycznie pisac od nowa wlasny)

W dzisiejszym uaktualnieniu male poprawki bledow i niedopatrzen -- Calkowo powinno sie teraz ladowac poprawnie, "interfejs uzytkownika" czyli teksty spod klawiszy funkcyjnych nie beda wiecej sie gryzly z otoczeniem i znikaly, co zdarzalo im sie w EZT i innych ciasnych spalinowkach. A w ramach bezuzytecznych bajerow sila smugi swiatla zalezy teraz od ilosci wlaczonych reflektorow, i pory dnia.
Wrzucisz źródła na githuba?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 13 Lutego 2017, 19:01:33
To może póki co, wyłączyć VBO. Tylko zamęt sieje i będą zbędne narzekania przy majstrowaniu w renderowaniu. U mnie VBO od początku się nie sprawdzał, a grafika na pewno obsługuje Vertex Buffer Objects. Właśnie sobie o tym poczytałem.
Siła smugi światła była już dzielona według ilości reflektorów. Dla mnie super gadżet.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 13 Lutego 2017, 19:21:25
Wrzucisz źródła na githuba?
Pchne dzisiaj, tylko zastanawiam sie czy wlaczyc przy okazji przerobiony teksture manager, bo nie ma jeszcze przywroconej sciezki dla openGL starszego niz 1.4 (czort wie, czy sa w ogole jeszcze takie w uzyciu)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 13 Lutego 2017, 19:25:43
Pchne dzisiaj, tylko zastanawiam sie czy wlaczyc przy okazji przerobiony teksture manager, bo nie ma jeszcze przywroconego rendering dla openGL starszego niz 1.4 (czort wie, czy sa w ogole jeszcze takie w uzyciu)
Moim zdaniem szkoda roboty na zachowywanie kompatybilności z czymkolwiek poniżej 2.0. (albo i nawet 3, bo właściwie każda sensowna karta graficzna w ostatnich 10 latach powinna to wspierać)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 13 Lutego 2017, 19:33:03
Moim zdaniem szkoda roboty na zachowywanie kompatybilności z czymkolwiek poniżej 2.0. (albo i nawet 3, bo właściwie każda sensowna karta graficzna w ostatnich 10 latach powinna to wspierać)
Niby tak, ale biorac pod uwage ze sa uzytkownicy z XP i roznymi laptopami to akurat na powszechna obecnosc sensownych kart graficznych specjalnie bym nie liczyl ;d  Poki co zachowanie tego co bylo specjalnie skomplikowane nie jest, porzadki mozna zrobic przy przejsciu na shadery itp.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 13 Lutego 2017, 19:44:13
Jako wywołany oświadczam, że mam wsparcie dla OGL 3.3. :P
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 13 Lutego 2017, 20:16:24
OK, jakie bledy na chwile obecna sa jeszcze do wylapania/poprawienia?
Jeśli mogę coś zaproponować, to zwiększenie nieszczelności układów pneumatycznych (głównie chodzi o hamulce). Tzn. w rzeczywistości dość często bywa tak, że przy czterdziestowagonowym składzie np. Eaos-ów z ET41 na przodzie (a więc z raz większym niż przy jednoczłonowej lokomotywie zapasem powietrza w zbiornikach głównych), sprężarki potrafią się załączać nawet co 5 minut w trakcie postoju na stacji, bo takie są nieszczelności na złączkach przewodu głównego w całym składzie. Kiedy testowałem to kiedyś w MaSzynie, spadek ciśnienia w zbiornikach głównych z 0,8-0,7MPa zajął ponad 130 minut (po długim, porządnym wyluzowaniu w pozycji jazdy i nabiciu powietrza do 0,8MPa), więc na początek proponowałbym trzynastokrotne zwiększenie nieszczelności, co powinno dać załączanie się sprężarek co ok. 10 minut, a to już będzie znacznie łatwiej przetestować w celu ostatecznej "regulacji". Nawet nie tylko przy staniu pod S1, ale też w trakcie jazdy doda to realizmu, jeśli sprężarki będą się załączać nie tylko po luzowaniu hamulców, ale też częściej podczas jazdy bez hamowania.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 13 Lutego 2017, 20:37:39
Cytuj
zwiększenie nieszczelności układów pneumatycznych
To akurat do bugtrackera trzeba zgłosić.
Pchne dzisiaj, tylko zastanawiam sie czy wlaczyc przy okazji przerobiony teksture manager, bo nie ma jeszcze przywroconego rendering dla openGL starszego niz 1.4 (czort wie, czy sa w ogole jeszcze takie w uzyciu)
Moim zdaniem szkoda roboty na zachowywanie kompatybilności z czymkolwiek poniżej 2.0. (albo i nawet 3, bo właściwie każda sensowna karta graficzna w ostatnich 10 latach powinna to wspierać)
Skoro to nie jest kłopot, to pozostawił bym jak jest i nie roztrząsał tego w tej chwili.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 13 Lutego 2017, 21:03:14
Cytuj
zwiększenie nieszczelności układów pneumatycznych
To akurat do bugtrackera trzeba zgłosić.
Ok, zrobione.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: sawe w 13 Lutego 2017, 21:58:54
Nie potwierdzam braku możliwości uruchomienia ET42-166.
Witam.
Pewnie chodzi o ET41- ... z folderu v2. Tych lokomotyw rzeczywiście nie można uruchomić.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 13 Lutego 2017, 22:47:13
Jako wywołany oświadczam, że mam wsparcie dla OGL 3.3. :P
OK, nastepne uaktualnienie bedzie eksperymentalnie z min. wymaganiem openGL 1.4, i jesli dla czyjegos sprzetu okaze sie to za duzo, bedzie na Ciebie ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 13 Lutego 2017, 23:59:37
Nie potwierdzam braku możliwości uruchomienia ET42-166.
Witam.
Pewnie chodzi o ET41- ... z folderu v2. Tych lokomotyw rzeczywiście nie można uruchomić.
Niestety musze potwierdzic. Zgadza sie, mozna wlaczyc baterie, zapalic swiatelka i nijak nie ma sposobu podniesc patyki. Przegladalem mmd i fiz, ale jest zbyt pozno aby wyciagac jakies wnioski. Oczywiscie na exe z paczki wszystko jest ok. To chyba ostatni pojazd z problemami, pojezdzilem dzis EN57 po Quarku, wydaje sie, ze jezdza bez problemow. Ale pewnosc bede mial jutro po porownaniu jazd.
PS: sprawdzana ET41-144
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 14 Lutego 2017, 01:00:17
Witam.
 Właśnie pisałem o ET41 w wersji v2 (być może za słabo to zaznaczyłem w poście, albo strzeliłem gafę z numerkiem loka). Sprawdziłem ją w różnych konfiguracjach i na kilku exe. Problem występuje od dość wczesnej wersji C++. W plikach pojazdów  v1 i v2 nie grzebałem.
  Nie wiem czy to tylko u mnie, ale jakby od wersji exe C++170212 spadła wydajność grafiki. Jest mniej fps, szczególnie gdy znajdą się inne składy w polu widzenia kamery. U kolegów jak to wygląda?
Pozdrawiam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 14 Lutego 2017, 05:11:48
Sugerowalem sie numerem lokomotywy 166 i taka wstawilem na TD. Fps akurat u mnie nie jest miarodajny. W raz z wydajnoscia podnioslem antyaliasing do 8, a w jednej scenerii do 16. Oczywiscie zerkne na to zadajac te same parametry dla roznych kompilacji.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 14 Lutego 2017, 13:55:04
Przyjrzalem sie ET41_v2, i wychodzi na to, ze nie dziala ona poniewaz brakuje wpisu animations: w plikach .mmd
Starsze wersje oryginalnego .exe radzily sobie z tym, definiujac 'domyslne' ilosci animacji w takim wypadku, ale przy przesiadce na c++ zostalo to najwyrazniej celowo wylaczone:
// ustawienie liczby modeli animowanych podczas konstruowania obiektu a nie na 0
// prowadzi prosto do wysypów jeśli źle zdefiniowane mmd

dlatego tez nie przywrocilem tej funkcji. Od nastepnego uaktualnienia w logu bedzie umieszczane ostrzezenie o brakujacym wpisie animations: zeby latwiej to bylo wylapac i poprawic w .mmd

Na probe przekopiowalem tagi animations: z et41_v1 do et41_v2 i wszystko zaczelo chodzic normalnie.

edit: co do zmian w wydajnosci, trudno powiedziec. Jakis wplyw zapewne ma przelaczenie trybu renderowania tekstur z linearnego na uwzglednianie mipmaps itp, ale tu juz wplyw bedzie miala rodzaj zainstalowanej karty i ustawienia systemowe.

edit2:
Jedna uwaga, po załączeniu baterii nie daje wyłączyć się buczka nastawnikiem kierunku. W tym przypadku należy wcisnąć spację.
To akurat jest chyba raczej uniwersalne? Tzn chyba we wszystkich lokach samo ustawienie kierunku nie wylacza czuwaka, trzeba wcisnac guzik, i wylaczy sie o ile kierunek jest ustawiony. Tak samo dziala to w EU07 i innych, i tak jest do zaaranzowane/udokumentowane w kodzie. Czy powinno to dzialac jakos inaczej?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 14 Lutego 2017, 14:14:37
Z mojego doświadczenia wynika, że w niektórych lokomotywach wystarczy ruszyć nastawnik kierunku. Co do plików mmd, miałem je porównać, ale późna pora zmusiła mnie do odwrotu. Sprawdziłem na Quark.scn jak zachowują się EN57 i EN71. Wszystkie dojechały do celu, wszystkie dają się należycie sterować. Jednak tutaj, prosiłbym kogoś o sprawdzenie jeszcze jednostek EZT, nie czuję się na siłach wydać sam wyroku 100% sprawności. Nie widać więcej zażaleń na działanie pojazdów. Jeśli chodzi o wydajność grafiki, ostatnio pozwoliłem sobie na maksymalny antyaliasing, jednak porównałem exe sprzed 12 lutego i obecne w tych samych warunkach. Mógłbym pokusić o stwierdzenie, iż fps nieco spadł, ale u mnie jest to ledwo zauważalne.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 14 Lutego 2017, 14:23:47
Z mojego doświadczenia wynika, że w niektórych lokomotywach wystarczy ruszyć nastawnik kierunku.
Akurat w ET41 i podobnych normalnie trzeba jeszcze skasować SHP przyciskiem po załączeniu baterii i ustawieniu kierunku, więc jest dobrze (pomijając, że normalnie trzeba jeszcze załączyć przełącznik rozrządu, żeby lampki SHP w ogóle się zaświeciły i zadziałał buczek oraz całe sterowanie z danej kabiny - ale tego jeszcze nie ma w MaSzynie). Jeśli jakaś ma inaczej, to już na pewno indywidualna przeróbka warsztatowa. Za pomocą nastawnika kierunkowego jest natomiast w MaSzynie zrobiona aktywacja czuwaka z danej kabiny (to, co kiedyś było chyba pod [Shift] + [W], żeby czuwak nie zadziałał w tylnej kabinie).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: El Mecánico w 14 Lutego 2017, 14:51:51
Takie małe "zamówienie" odnośnie przyszłego LD: wszędzie gdzie jest interakcja z obwodami elektrycznymi przez klawiaturę dajcie w linijce komentarz:
//__PRZENIESC_DO_LD__.
Dziękować:)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 14 Lutego 2017, 17:18:57
Ktoś wie o co tu chodzi, bo wygląda że ktoś palił coś mocnego jak to pisał
https://github.com/tmj-fstate/maszyna/blob/mover_in_c%2B%2B/World.cpp#L1245
TSubModel::iInstance = reinterpret_cast<int>( Train->Dynamic() );Train->Dynamic() zwraca *TDynamicModel, TSubModel::iInstance to int, podpisany jako "// identyfikator egzemplarza, który aktualnie renderuje model". Więc to bierze wskaźnik i wpycha go do zwykłego inta(!). Ale to jeszcze nic, bo w https://github.com/tmj-fstate/maszyna/blob/mover_in_c%2B%2B/Model3d.cpp#L669
iInstance += s->iNumVerts; // pozycja dla następnegoDodaje do tego inta zrobionego ze wskaźnika....liczbę wierzchołków?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 14 Lutego 2017, 17:41:42
To nie moje :) ale raczej nic tak niezwyklego -- ten pierwszy fragment robi sobie identyfikator z 'fizycznego' adresu obiektu w pamieci, ktory chyba pozostaje staly przez caly czas trwania programu (konkretna wartosc bedzie sie roznic miedzy uruchomieniami, ale nie musi byc identyczna) Poniewaz dwa obiekty nie moga dzielic adresu, masz gwarancje ze wartosci takich identyfikatorow beda rozne.

To drugie to nie wiem, ale to chyba jakis lokalny wariant matematyki na wskaznikach czyli np std::vector<char> foo; &foo[0] + 5 == foo[5]. Tzn nie zdziwilbym sie, gdyby ten iInstance byl w ktoryms miejscu ponownie rzutowany na wskaznik. Ale zbyt gleboko sie nie przygladalem, to jest legacy code, czyli obchodzic sie jak ze smierdzacym jajkiem -- albo wyrzucic, albo nie ruszac ;)

edit: no i oczywiscie to sobie moze dzialac przy kodzie 32-bit, ale przy przejsciu na 64 to moga wyskoczyc cuda wianki.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 14 Lutego 2017, 17:51:17
ET41_v2 poprawione. Rev: 1641.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 14 Lutego 2017, 17:52:37
edit: no i oczywiscie to sobie moze dzialac przy kodzie 32-bit, ale przy przejsciu na 64 to moga wyskoczyc cuda wianki.
No właśnie dodaję wsparcie 64bit, inaczej bym tego nie ruszał :)
Z tym TSubModel to tu są niezłe cuda, inicjalizacja TWorld przechodzi tylko jeśli sizeof(TSubModel) == 256, więc pewnie jest jakaś turbomagia na wskaźnikach.
PS: dodane jest tam tylko 8 bajtów wypełniacza, a na 64bit klasa spuchła i ma 304 bajty. świetnie.
PS2: ok, jest wyjaśnienie:
    // Ra: ta klasa ma mieć wielkość 256 bajtów, aby pokryła się z formatem binarnym
    // Ra: nie przestawiać zmiennych, bo wczytują się z pliku binarnego!
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: ic_kolobrzeg w 14 Lutego 2017, 18:44:55
EXE 170213, nie widać łuny światła reflektorów w ST43

Fałszywy alarm :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 14 Lutego 2017, 20:00:35
Wersja GLFW z ostatnimi zmianami tmj.
Zrobiłem porządek w repo, wywaliłem nieużywane pliki, nagłówki i binarki bibliotek (repo to nie jest miejsce do składowania tego), system budowania zmieniłem na cmake, pozbyłem się warningów: trochę kodu zmieniłem żeby mu pasowało, dwa warningi wyłączyłem flagami: ostrzeganie o funkcjach "deprecated" według msvc i wpisywanie doubla do float. Jeden warning wskazywał na prawdziwy błąd, chyba gdzieś przy tworzeniu TTextSound nie był podawany ostatni argument. Myślałem że uda mi się wrzucić dzisiaj 64bitowy build, ale muszę zrobić normalną serializację i deserializację E3D żeby była niezależna od układu w pamięci.
Przy porządkach bibliotek być może coś zaktualizowałem, więc dorzucam do zipa dllki.
edit: oj, coś zepusłem. zaraz poprawię
e2: coś się pokasztaniło, już nie mam dzisiaj do tego głowy
e3: ok, teraz powinno być ok: https://milek7.pl/.stuff/eu07exe/eu07xxng-7c98a177.zip
e4: jest tam jakiś błąd i niektórym psuje się po inicjalizacji TWorld, jutro coś nad tym pomyślę
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 14 Lutego 2017, 20:27:24
Milek, ja się bardzo cieszę że robisz, ale NIE ZAPYTAŁEŚ SIĘ O TO CZY MOŻNA USUNĄĆ TE LIBY. Nie przyjmę takich commitów na mastera i już. Nowy devs ma sobie ściągnąć repo i mieć wszystkie potrzebne biblioteki na dysku a nie szukać po sieci.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 14 Lutego 2017, 20:50:43
Nie przekonasz mnie dowolną ilością caps locka żeby trzymać binarki na repo :)
Można zrobić dodatkowego zipa ze wszystkimi bibliotekami żeby tylko wypakować i nie szukać osobno pythona, glfw, glut, glew, ale trzymanie tego na repo jest bez sensu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 14 Lutego 2017, 21:18:44
Sorki, wtrącę się. Nie sądzę, że firleju chciał Ciebie przekonać. Sądzę, że wyraził dezaprobatę i wolę zamykając drogę do dyskusji. Jako najstarszy w rodzinie wolałbym nie czytać takich wiadomości już na początku Waszej współpracy, to nie wróży nic dobrego.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 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ę".
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Lutego 2017, 00:32:23
Tak jak straszylem, dzisiejsze uaktualnienie ma eksperymentalnie wlaczone wymaganie openGL minimum 1.4 :d

Z wiekszych, chociaz --miejmy nadzieje-- niewidocznych zmian jest przerobka podsystemu obslugi tekstur I obsluga wspomnianych wczesniej w watku flag zawijania zawartosci tekstury, co powinno pomoc przy renderowaniu lasow itp (nie od razu, bo wymaga to uaktualnienia plikow scenariuszy, ale zawsze)

Ze zmian mniejszych ale bardziej widocznych, naprawilem wyswietlanie wersji tekstowej odgrywanych dzwiekow. Czyli np nowy scenariusz dla Calkowa nie bedzie sie juz wywalal po kilku sekundach :P  Nawiasem mowiac, oryginalny kod oczekiwal podania czasu wyswietlenia i ukrycia tekstu dla kazdej linii, a nie kazdy tekst w scenariuszach to ma. Na chwile obecna .exe wyswietla tego typu teksty i daje informacje w logu, o braku parametrow. Jesli zle to zinterpretowalem, to informacje z logu mozna w przyszlosci usunac.

Przy okazji poprawilem tez wyswietlanie tekstow z polskimi literami (a raczej konwersje tekstu na wersje bez polskich liter, ale wychodzi na to samo)

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 15 Lutego 2017, 02:09:12
Podawanie timingów przy napisach nie było wymagane. Przy braku całość pliku była wyświetlana na czas odtwarzania dźwięku, ewentualnie stały czas. Większość napisów nie ma timingów wpisanych, bo to krótkie komendy i nikomu nie chciało się tego formatować.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Lutego 2017, 03:18:47
Aha, w sumie sensownie. Wylacze zapis do logu w nastepnej wersji.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 15 Lutego 2017, 12:32:11
Słuchajcie, czy tylko u mnie jest tak, że jak wrzucam sobie EN57 na td to nie mogę podnieś patyków na exe c++ niezależnie od wersji? (sprawdzałem te ostatnie i te starsze).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Lutego 2017, 12:38:30
U mnie jezdza ;/ zwroc uwage, ze zestaw musi byc spiety sprzegiem 55 (albo -55 albo 183 jesli chcesz tez miec polaczenie 'na sztywno') bo inaczej dane sterowania z kabiny nie beda przechodzic do modulu z silnikiem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 15 Lutego 2017, 12:51:46
Zestaw mam spięty 55 nobody dla 2 i 0 nobody dla ostatniego, a pierwszy wiadomo 55 headdriver.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 15 Lutego 2017, 12:53:36
Zaraz to sprawdzę, katuję ET42 w Dionizowie. Wpis robiłeś ręcznie, czy wstawiałeś rainstedem?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Lutego 2017, 12:56:02
No jak tak, to nie wiem. Chyba, ze to jakis nietypowy egzemplarz i brakuje mu wpisu animations: w .mmd, tak jak temu ET41_v2 z wczesniejszej strony. Ale te z paczki standardowej jezdza u mnie normalnie, sprawdzilem przed chwila EN57-2000 i kulal sie bez problemu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 15 Lutego 2017, 13:08:42
Wrzuć wpis na którym testujesz.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 15 Lutego 2017, 13:09:19
A wysokie napiecie kolega podlaczyl? Ustaw w starterze wszystko z wyjatkiem sprzegu ogrzewania. Musi dzialac. Chodz niewiem po co sprzeg ogrzewania skoro i tak tego nie obslugujemy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 15 Lutego 2017, 13:10:11
Wygenerowany skład w rainstedzie, wpis jest taki:
node -1 0 EN57-001 dynamic PKP\EN57_V1 EN57-001RA 6BAI  0 headdriver 55 0 enddynamic
node -1 0 EN57-001 dynamic PKP\EN57_V1 EN57-001S 6BSI  0 nobody 55 0 enddynamic
node -1 0 EN57-001 dynamic PKP\EN57_V1 EN57-001RB 6BBI  0 nobody 3 0 enddynamic
W załączniku skład gotowy do odjazdu i konsola exe. Log dla świętego spokoju. Jeśli coś wam nie odpala podawajcie nie tylko typ składu/lokomotywy, trzeba także podawać numer uruchamianego pojazdu. Ważne z punktu widzenia doświadczeń ET41
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 15 Lutego 2017, 13:10:30
Na et41 sprzegu wysokiego nie spinaj. I na et40 wersja 4 patykowa.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 15 Lutego 2017, 19:50:06
Okej, na tej wersji z wpisem EPka działa, ale kiedy zmienię na EN57-1025 to syczy hamulec cały czas. Załączam log choć nie wiem co to da.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 15 Lutego 2017, 19:57:04
Nie wiem jaki wpis jest epka, bo go nikt nie podał, proszony byłeś o podanie/wklejenie wpisu, bo tak to ganiamy się w kółko i guzik wiemy. Za chwilę wstawię po swojemu i okaże się że działa...
Ja już jestem zmęczony, dawaj ten wpis tego EN57-1025, sprawdzę co tam jest to będziemy szukać. Jak raportować, to dokładnie proszę.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 15 Lutego 2017, 20:01:09
Sorki, chodziło mi wpis od Ciebie, a zmieniłem tylko teksturę w starterze.


Sprawdziłem, syczy nadal.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 15 Lutego 2017, 20:06:17
No właśnie, zapakowałem go w rainstedzie i odpaliłem bez problemu na TD.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Lutego 2017, 20:09:10
Sorki, chodziło mi wpis od Ciebie, a zmieniłem tylko teksturę w starterze.
Sprawdziłem, syczy nadal.
No, sama zmiana tekstury raczej nie ma wplywu na dzialanie. Sprawdzilem u siebie dla pewnosci -- wzialem dzialajacego 1051, zmienilem teksture w starterze na 1025 i jezdzi. Nie syczy tez, wiec obawiam sie nie bardzo wiem co tam sie moze dziac u Ciebie. Jesli instalowales jakies dodatki, moze dla pewnosci przeinstalowac paczke calosciowa, na wypadek gdyby ktores pliki ulegly uszkodzeniu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 15 Lutego 2017, 20:11:42
Mi również odpala się bez problemu i śmiga, ale cały czas od początku coś syczy i jest to dźwięk jakby odluźniacza, który jest w EN57. Sprawdziłem jeszcze ET41 i na sprzęgu 55 nie podnosiły sie patyki.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 15 Lutego 2017, 20:16:42
Ja powiem tak, albo wklejasz nam tu swoje wpisy, albo przestaję zwracać uwagę na nic nie znaczące wiadomości. Mam taki wpis tego kibla i nic nie syczy!
node -1 0 EN57-1025 dynamic PKP\EN57_V1 EN57-1025RA 6BAII  0 headdriver 55 0 enddynamic
node -1 0 EN57-1025 dynamic PKP\EN57_V1 EN57-1025S 6BSII  0 nobody 55 0 enddynamic
node -1 0 EN57-1025 dynamic PKP\EN57_V1 EN57-1025RB 6BBII  0 nobody 3 0 enddynamic
Proszę o Twój wpis każdego pojazdu, który Wam nie chce działać!
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 15 Lutego 2017, 20:18:32
Ja u siebie dla tego kibello mam taki wpis:

trainset drawinowo\IKSE1703 start 0 0
//$o Tor doświadczalny.
node -1 0 EN57-1025 dynamic PKP\EN57_V1 EN57-1025RA 6BAII  0 headdriver 191 0 enddynamic
node -1 0 EN57-1025 dynamic PKP\EN57_V1 EN57-1025S 6BSII  0 nobody 191 0 enddynamic
node -1 0 EN57-1025 dynamic PKP\EN57_V1 EN57-1025RB 6BBII  0 nobody 0 0 enddynamic
endtrainset

I działa bez kłopotu.

exe c++ 014

Dziala bez kłopotu także na poniższym wpisie, dawanym z automatu dla ezt przez startera RA:

trainset drawinowo\IKSE1703 start 0 0
//$o Tor doświadczalny.
node -1 0 EN57-1025 dynamic PKP\EN57_V1 EN57-1025RA 6BAII  0 headdriver 55 0 enddynamic
node -1 0 EN57-1025 dynamic PKP\EN57_V1 EN57-1025S 6BSII  0 nobody 55 0 enddynamic
node -1 0 EN57-1025 dynamic PKP\EN57_V1 EN57-1025RB 6BBII  0 nobody 0 0 enddynamic
endtrainset
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 15 Lutego 2017, 20:21:51
Po wklejeniu waszych wpisów działa bez problemu. Nie wiem co robiłem nie tak skoro, przy wstawienie składu z rainsted zaczyna syczeć.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 15 Lutego 2017, 20:24:27
Pamietaj ze trzeba z pol minuty zaczekać az sprezarka dobije powietrza wtedy odluzujesz.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 15 Lutego 2017, 20:24:44
Czy ja nie dość wyraźnie napisałem, że skład generowałem w rainsted? Oprócz wstawienia loka i wybrania tekstur należy skonfigurować sprzęgi w zakładce "sprzęgi" w rainsted. Za każdym wagonem należy ten sprzęg ustawić. Prosiłem o podanie Twoich wpisów ze 4 razy i co?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 15 Lutego 2017, 20:27:24
Cytuj
Oprócz wstawienia loka i wybrania tekstur należy skonfigurować sprzęgi w zakładce "sprzęgi" w rainsted

Jak widać nie dla każdego jest to jasne. Mnie ludziska zadaja pytanie jak zrobić pasażera, chodz maja opis w txt krok po kroku i za raczke do przedszkola. Wiekszosc olewa wszelkie redme i info.txt. Olewaja także faq symulatora. Stad wychodzą takie rzeczy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 15 Lutego 2017, 20:28:27
Kuźwa używam MaSzyny nie od dziś i chyba wiem, co się powinno robić, żeby dodać skład do scenerii, bo przez kilka lat jakoś nie miałem z tym problemu, a pojawia się nowe exe w C++, chcę pomóc przy wyłapaniu błędów, robię wszystko tak jak robiłem do tej pory i nagle syczy jak nigdy wcześniej... Nie jestem kurde nowym laikiem, który dopiero co zobaczył symulator i nie wie co zrobić..
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 15 Lutego 2017, 20:30:28
Jesteś laikiem, nawet nie umiesz albo nie chcesz wkleić swoich wpisów. Prostej rzeczy nie zrobiłeś! Też mam zaćmienia, każdemu może się zdarzyć zapomnieć.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 15 Lutego 2017, 20:31:32
node -1 0 EN57-1025 dynamic PKP\EN57_V1 EN57-1025RA 6BAII  0 headdriver 55 0 enddynamic
node -1 0 EN57-1025 dynamic PKP\EN57_V1 EN57-1025S 6BSII  0 nobody 55 0 enddynamic
node -1 0 EN57-1025 dynamic PKP\EN57_V1 EN57-1025RB 6BBII  0 nobody 3 0 enddynamic

Proszę bardzo, wstawiam na TD i syczy

Edit. Lecz syczy tylko jeśli wstawię w "trainset rozklad start 0.0 0.0", bo jeśli w to drugie "trainset none tor_st1_2 0.0 0.1", to problem syczenia nie występuje.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 15 Lutego 2017, 20:34:33
No a u mnie nie syczy. Tzn z początku zanim nabije powietrza do zbiornika i zanim odluzuje to syczy ale przestaje. Max pol minutki. Jak już PG osiągnie swoje ciśnienie i ZG tez a sprezarka zaraz po odpaleniu się wylaczy, to przestanie syczeć. Daj mu minutke.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Lutego 2017, 20:43:20
Edit. Lecz syczy tylko jeśli wstawię w "trainset rozklad start 0.0 0.0", bo jeśli w to drugie "trainset none tor_st1_2 0.0 0.1", to problem syczenia nie występuje.
A tam nie ma czasem roznicy na TD, ze na torze start sklad zaczyna zahamowany, a na tym drugim nie? Bo to by moze wyjasnilo dlaczego w jednym przypadku syczy (bo luzuje) a w drugim nie (bo nie ma co luzowac)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 15 Lutego 2017, 20:49:42
W trybie debug mode jest krótkie syknięcie może trwa sekundę. W trybie normalnym nie mam żadnego syknięcia. Uruchamiam baterię, podnoszę patyki włączam przetwornicę i sprężarkę, jak nabije to luzuję. Luzuję nawet jak nie nabije i nie syczy. Nie wiem jaką masz paczkę i jakie masz mmd, bo zmian było od diabła:) Ale to musisz sam już ogarnąć. Zaś jeśli chodzi o wstawianie, to: trainset rozklad start 0.0 0.0
jak przypisano w TD
A propo wpisu składu, to nie jest Twój wpis na którym nic nie działało (nawet patyków nie podniosłeś), a o ten wpis prosiłem... Dla mnie to koniec tematu.
ED:
Wydaje mi się, że jeśli jest zahamowany po wczytaniu, to syczeć powinien tylko jak zaczniesz sam luzować. Jeśli odpalasz na debug mode, to jest zahamowany, ale AI na starcie nie uruchamia loka, więc go nie luzuje. Ja mam tylko krótkie syknięcie. Może nie trwa nawet sekundy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Lutego 2017, 20:56:19
A tak z innej beczki. Dzisiaj uaktualnienia nie ma, ale jako ze malunek jest podobno wart tysiaca slow, to mamy trzy tysiace slow w zrzutach z ekranu :d

(dla ulatwienia, 15-ego lutego zachod slonca w Polsce ma miejsce ok. 16.50  A ambient wylaczony jest chwilowo, coby efekt bylo latwiej sprawdzic)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 15 Lutego 2017, 20:59:25
No jest odlotowo. Nawet dobrze że nie ma nowego, bo na dziś mam już dość. Z 20 razy odpalałem kaliską. O TD nie wspomnę. Niebo jakieś bezchmurne, czy bez wpisu tekstury było, tylko samo światło?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 15 Lutego 2017, 21:04:52
Nieba mamy 2 rodzaje. Skaystars czyli samo swiatlo i jak jest ciemno to same gwiazdy widać, oraz dynamic sky czyli niebo z tekstura chmur. Samo swiatlo + gwiazdy + animowana tekstura chmur nie jestem pewny czy dynamic sky nie posiada także słoneczka i księżyca.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Lutego 2017, 21:09:43
Niebo jakieś bezchmurne, czy bez wpisu tekstury było, tylko samo światło?
Wyczyszczone do testow, zebym lepiej mogl sprawdzic jasnosc, bez wcinajacych sie tekstur.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 15 Lutego 2017, 21:16:13
Sorki, że jeszcze wtrącę temat syczenia.. EN57-20xx bez problemu wszystko działa, nic nie syczy, natomiast w zwykłym kiblu miałem ten inny plik mmd co mogło być przyczyną, bo 608 i 001 działają bez problemu. Mój błąd, sorki, ale wydaje mi się, że dobrze, że napisałem. Pozdr.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 15 Lutego 2017, 21:23:45
@pbzylek: Cieszę się, że mogliśmy pomóc. @tmj: Tak myślałem, że jest bez tekstury to niebo, stary dobry exek664, ale to już historia.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 15 Lutego 2017, 22:59:05
Jesteście pewni, że ten syk to odluźniacz? Ten jako-tako ogarnąłem. Problem z dźwiękami był przy piaskowaniu. Luzujące ai może łapać lekkie poślizgi, gdy bufory rozpychają mu skład i sypać piachem, co przy obecnej realizacji piaskowania generuje brzydkie dźwięki.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 15 Lutego 2017, 23:02:57
Mnie się wydaje, że coś z tym sykiem jest jednak nie tak, bo co któreś włączenie td z tym samym wpisem EN57, który działał to syk się włącza. Nie za każdym razem ale raz na 3 uruchomienia na pewno.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 15 Lutego 2017, 23:12:42
Ten syk jeśli jest, ma dźwięk podobny do upustu powietrza z PG kurkiem na przewodzie powietrza umieszczonym na końcu składu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 16 Lutego 2017, 19:24:46
Czy możemy uznać ostatnie zmiany już za w miarę stabilne? Chciałbym wrzucić zmiany na mastera i przerzucić to na oficjalne repo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 16 Lutego 2017, 19:42:03
Chyba tak, tzn. ciagle sa do ogarniecia indywidualne przypadki jak SN61, ale bardziej przesuwa sie to w strone wprowadzania nowych rzeczy i naprawiania bledow z oryginalnego exe, niz latanie dziur w c++

Tak przy okazji, czy w tej wersji ktora masz u siebie przerobka tabelki skanowania jest funkcjonalna, czy jeszcze jej czegos brakuje? Pytam bo oryginalne skanowanie jakims cudem psuje sie po wylaczeniu czesci odwolan do oswietlenia openGL, co jest nieco absurdalne, i chcialbym sprawdzic, czy wstawienie zamiennika nie opartego na wskaznikach itp uleczy to szalenstwo.

W zalaczniku aktualizacja .exe z poprawkami dla MWD of macka001, poza tym na razie bez zmian of wersji poprzedniej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 16 Lutego 2017, 19:43:31
A to duża odpowiedzialność tej oceny? Jak dla mnie, stabilność nie odbiega od exe z PC. Nie jestem w stanie wszystkiego przejeździć, nikt nie zgłasza już problemów, a te co są wydają się już bardzo drobne i raczej nie wpływają na stabilność. Do sterowania niektórych pojazdów pewnie trzeba będzie doszlifować jakieś poprawki, ale na to trzeba czasu, aż takie propozycje spłyną od użytkowników. Jeśli to potraktować jak zakończenie etapu, to wrzucaj. Po ilości poborów kompilacji, można się spodziewać opinii jeszcze innych osób.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 16 Lutego 2017, 20:20:15
Powiedzcie mi, czy w ekranach Pythona było coś zmieniane? Mam ekran w EN57AKŁ i na exe c++ nie wyświetla niektórych rzeczy. Więcej w załącznikach (tam gdzie jest to całe pole EZT1 to stare exe, a tam gdzie nie ma nic to C++)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 16 Lutego 2017, 20:21:12
Już zgłaszałem. Musisz mieć sprzęg depotowy na długość jednostki. +128 do sprzęgów.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 16 Lutego 2017, 20:23:33
Okej, sorki nie doczytałem. ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 16 Lutego 2017, 22:32:37
Wrzuciłem wszystkie zmiany na mastera włącznie z dzisiejszą zmianą Maćka. Jak znajdę w najbliższym okresie chwilkę czasu to przeanalizuję co wyrzucał Milek i poczyszczę repo z niepotrzebnych plików związanych z BCB.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 16 Lutego 2017, 22:37:35
Jeszcze nie polecam, niektórzy zgłaszali że crashuje się po world init. Jak wytropię tego buga i skończę z przeróbką deserializacji dla x64 to wtedy będzie można mergować.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 16 Lutego 2017, 22:48:05
Kompilacje @tmj, u mnie nie wysypuja, dzialaja poprawnie na winxp i win7. Owszem, wysypuje sie kompilacja od Ciebie na obu systemach, ale z tego co widze to Twoje pomysly i tak na przyszlosc trzeba odlozyc.
@tmj, w jakim systemie operacyjnym kompilujesz?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 16 Lutego 2017, 23:53:48
Win10 64-bit. Nawiasem mowiac przypomnialo mi sie, ze przynajmniej jedno zrodlo wywalania, ktore jest w kodzie od dawna i raczej nie zostalo jeszcze usuniete, wystepuje jesli brakuje jakiegos pliku do dzwieku (bo np zly wpis w konfiguracji jest), bo na chwile obecna exe sie tym nie bardzo przejmuje, i probuje taki nieistniejacy dzwiek i tak odegrac.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 17 Lutego 2017, 11:36:58
Było zgłoszenie w temacie widoczności świateł semaforów. W Zwierzyńcu nie widać świecenia już od 150m. Trzeba to naprawić, na ten moment AI jest w stanie dostrzec semafor.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 17 Lutego 2017, 12:22:15
Przyznam, ze za bardzo tego nie widze, tzn w kodzie do rysowania nic nie bylo zmieniane, i porownujac te same ujecia z oficjalnego exe i przepisanego, akurat sygnaly wygladaja dla mnie praktycznie tak samo?

(zrzuty w png, bo .jpg zamordowalby widocznosc czegokolwiek)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Sawi w 17 Lutego 2017, 12:25:48
Ten problem można powiedzieć jest odwieczny i faktycznie momentami jest to dość uciążliwe.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 17 Lutego 2017, 12:30:31
Na tapecie mam Zwierzyniec, scenariusz z ED72. Tam jest specyficzna atmosfera, szaro i ponuro, postaram się dać jakiegoś screena. Jeśli nawet różnica w widoczności świateł semaforów jest nie wielka, jednak nie wystarczająca, to może trzeba się pochylić nad problemem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 17 Lutego 2017, 12:33:31
Ten problem można powiedzieć jest odwieczny i faktycznie momentami jest to dość uciążliwe.
Aha, czyli to w starym kodzie siedzi? Moze uda sie tu cos poprawic jak skoncze go odlaczac/porzadkowac, ale gwarancji nie ma -- widocznosc sygnalow to chyba bolaczka wszystkich symulatorow, dlatego daja te protezy w stylu informacji na wyswietlaczu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 17 Lutego 2017, 12:39:15
Inna widoczność jest też przez szybę z kabiny, w wielu przypadkach jej "przezroczystość" mocno przeszkadza. Twoje załączniki zrobione są z innej perspektywy. Do tej pory radziłem sobie z widocznością, dopiero Zwierzyniec objawił się negatywnie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 17 Lutego 2017, 12:48:31
Ja widzę równicę w jasności punktów na tych skrinach. Z mastera są jaśniej czerwone niż na c++. Ogólnie freespotlight trzeba by zrobić bardziej świetliste. Przecież z tej odległości to wyraźnie widać sygnał a semafor to ledwo ledwo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 17 Lutego 2017, 12:53:54
Pozwolę sobie też w PNG załączyć, aby nie zabić kompresją widoczności. Niestety ktoś nie przypisał semaforów do torów w sem_info, w związku z czym nie widać ich w tabeli skanowania (gratulacje). Screeny zrobione w Kociarach, ostatni z kabiny w kierunku naszego odjazdu. Widać cień semafora, światła już nie.
Załącznik 1 -na końcu peronu jest semafor.
Załącznik 2 -podjechałem bliżej, nadal nie widać semafora (światła)
Załącznik 3- zmiana kabiny włączona tabela skanowanie, brak światła na semaforach.
ED:
Dokładam screen sem34 i sem35, zrobiony na starym exe z paczki, jest z tego samego miejsca. Mało, ale jednak widać S1, a z drugiej strony światła na powtarzaczu.
ED1:
Forum obcięło mi pliki po uploadzie. Dokładam linki do screenów.
foto-sem1.PNG  (http://eu07.pl/userfiles/1234/foto-sem1.PNG)
foto-sem2.PNG (http://eu07.pl/userfiles/1234/foto-sem2.PNG)
foto-sem3.PNG (http://eu07.pl/userfiles/1234/foto-sem3.PNG)
foto-sem34.PNG (http://eu07.pl/userfiles/1234/foto-sem34.PNG)
foto-sem35.PNG (http://eu07.pl/userfiles/1234/foto-sem35.PNG)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 17 Lutego 2017, 16:35:42
Eksperymentalnie zwiekszylem rozmiary punktow swietlnych co powinno nieco pomoc z widocznoscia na dluzsze dystanse, ale z gory mowie, ze to jest tylko proteza wiec specjalnego szalu nie ma ;d  O czyms bardziej funkcjonalnym bedzie mozna pomyslec w przyszlosci, jak juz renderer bedzie sensowniej ogarniety itp.

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: MaciejM w 17 Lutego 2017, 16:58:22
Na 170216 zaobserwowałem trzystopniową smugę, w zależności od ilości włączonych reflektorów. Jest świetnie :D Chociaż w mojej ocenie poziom "drugi" powinien być poziomem maksymalnym, bo przy włączonych trzech reflektorach wszystko aż błyszczy. Tutaj musieliby coś powiedzieć maszyniści.

http://eu07.pl/userfiles/8463/refl_0.png
http://eu07.pl/userfiles/8463/refl_1.png
http://eu07.pl/userfiles/8463/refl_2.png
http://eu07.pl/userfiles/8463/refl_3.png
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 17 Lutego 2017, 17:03:58
@tmj, tak czy inaczej semafory na załącznikach wyglądają obiecująco, nawet jeśli to proteza. Jak tylko będzie kompilacja, wsiadam i jadę...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 17 Lutego 2017, 21:21:21
Sama zmiana wielkosci swiatel to byloby troche malo na aktualizacje :d  Dodalem przy okazji pare drobiazgow brakujacych z wersji Stele, i dalem dwie poprawki do sterowania, ktore mnie wku- denerwowaly:
- przelaczniki tylnych swiatel byly odwrocone, tzn zeby zapalic manewrowy trzeba bylo kombinowac w stylu shift + I, ale ctrl+shift+Y. Teraz ten sam klawisz obsluguje przednie i tylne swiatlo po jednej stronie
- chodzenie w kabinie dziala teraz tak samo jak wszedzie indziej, czyli na podstawie kata obrotu kamery, zamiast byc oparte na sztywno na orientacji pojazdu. To jest chyba troche bardziej intuicyjne niz mentalna gimnastyka w stylu 'patrze w lewa strone wiec nacisniecie 'w przod' przesunie mnie w prawo' itp.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 17 Lutego 2017, 21:24:22
Ha, już jadę. Ze światłami tylnymi to ktoś pewnie skomentuje, pewne, że trzeba się przyzwyczaić.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 17 Lutego 2017, 21:34:59
Uniezależniłeś może prędkość ruchu w kabinie od fps? Strasznie to wkurzało.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: maciek001 w 17 Lutego 2017, 21:40:13
Na 170216 zaobserwowałem trzystopniową smugę, w zależności od ilości włączonych reflektorów.
Swego czasu Q zrobił trzy osobne smugi do każdego z reflektorów. Na pulpicie są jeszcze magiczne przełączniki przyciemniania reflektorów, które można łatwo wprowadzić ale nie mam pomysłu pod jaką kombinacją klawiszy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: RoboBatman w 17 Lutego 2017, 21:44:08
@maciek001: co do
Cytuj
a pulpicie są jeszcze magiczne przełączniki przyciemniania reflektorów[...] ale nie mam pomysłu pod jaką kombinacją klawiszy.
proponuję kombinację :
Shift lub Ctrl+> - Rozjaśnianie reflektorów
Shift lub Ctrl+< - Przyciemnianie reflektorów
Z tego co pamiętam, taka kombinacja jeszcze nie jest używana.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 17 Lutego 2017, 21:45:26
Uniezależniłeś może prędkość ruchu w kabinie od fps? Strasznie to wkurzało.
Ah nie, tam bylo dt w kodzie ale wykomentowane, nie przyjrzalem sie specjalnie i zalozylem ze uzaleznienie jest zrobione gdzie indziej (nie bardzo mam jak sprawdzic, bo praktycznie zawsze chodzi u mnie na 60fps)  Zrobi sie w nastepnej wersji.

Na pulpicie są jeszcze magiczne przełączniki przyciemniania reflektorów, które można łatwo wprowadzić ale nie mam pomysłu pod jaką kombinacją klawiszy.
EP08_015 proponowal ctrl + shift + ? do wspolnego przyciemnienia. Przydaloby sie przy okazji dodac funkcjonalny przelacznik do kabiny -- jest wymodelowany np. w EU07 ale chyba do niczego nie podpiety.

shift + < > sa juz uzywane, w dodatku do dwoch roznych rzeczy (drzwi i/lub wyswietlacze)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 17 Lutego 2017, 21:58:14
Może przyciemnianie zrobić dopiero w wersji sterowania myszką? Wiem, daleko jeszcze... Niemniej skrótów już tyle, że trzeba ze ściągawką jeździć (żart). Semafory lepiej widać, ale dobrze nie jest. Trzeba wyjść w teren i zerknąć po ciemnicy jak to widać z końca peronu w Pabianicach. Zrobiłem dwa obrazki i wrzucam na upload, bo forum i tak mi obcina png. Może jeszcze nie czas na świecące bajery.
http://eu07.pl/userfiles/1234/foto-11.PNG (http://eu07.pl/userfiles/1234/foto-11.PNG)
http://eu07.pl/userfiles/1234/foto-22.PNG (http://eu07.pl/userfiles/1234/foto-22.PNG)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 17 Lutego 2017, 22:11:58
Na tapecie mam Zwierzyniec, scenariusz z ED72. Tam jest specyficzna atmosfera, szaro i ponuro, postaram się dać jakiegoś screena. Jeśli nawet różnica w widoczności świateł semaforów jest nie wielka, jednak nie wystarczająca, to może trzeba się pochylić nad problemem.

No trudno żeby były lepiej widoczne, skoro w tej scenerii są właśnie takie wpisy atmo, które ograniczają widoczność w granicach 1 - 250 metrów...
Cytuj
atmo 0.086 0.118 0.145 1 250 0.055 0.082 0.086 endatmo
light 500 100 1000 0.078 0.102 0.126 0.09 0.118 0.157 0 0 0 endlight
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 17 Lutego 2017, 22:18:24
Tomasz, Tobie to dobrze masz porównanie z pobytu na szlaku. Moim zdaniem właśnie @tmj zrobił te 250m. Screen przed poprawkami ze skanowaniem, do pierwszej zwrotnicy było 199m. Semafor jest sporo wcześniej i niewidoczny. Poprzednio nawet ze 150 nie było nic widać. Sprawdzę jutro jak to na Quarku widać ciemną nocą dla porównania i może jeszcze jakąś scenerię.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 17 Lutego 2017, 22:27:49
Moim zdaniem właśnie @tmj zrobił te 250m.

Nie.
Cytuj
Screen przed poprawkami ze skanowaniem, do pierwszej zwrotnicy było 199m. Semafor jest sporo wcześniej i niewidoczny. Poprzednio nawet ze 150 nie było nic widać. Sprawdzę jutro jak to na Quarku widać ciemną nocą dla porównania i może jeszcze jakąś scenerię.

Sprawdzałem na różnych exe i z tej samej odległości widać na tym wpisie atmo sygnał na semaforze. I na dedykowanym starym exe z paczki, i na exe cpp z dzisiaj. To jest tylko i wyłącznie kwestia wpisu atmo. Widzisz szary semafor tylko dlatego, że wpisy atmo w zasadzie nie są skomponowane do tła. A widoczność jest jaka jest, w życiu bywa gorsza i się jedzie. Nomen omen np. dziś:

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 17 Lutego 2017, 22:43:41
Zgadza się, że tak powinno być. Ja tylko mówię, że względem poprzedniego exe nic się nie zmieniło na gorsze ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 17 Lutego 2017, 23:29:13
Witam.
  Pamiętacie koledzy, jak Q wprowadził w exe eksperymentalnie poświatę w semaforach? Całkiem fajnie to wyglądało. Na mgłę jak znalazł.
  Byłbym zapomniał. Testowałem dla odmiany kolejowy "plankton", w postaci SM03, SM04 na TD. W nich również nie działa hamulec dodatkowy ( exe 170216). Zasadniczy też czasem wariuje. Wskazówki od manometrów sporadycznie kręcą się w kółko jak oszalałe. W sumie to dość zabawnie nawet wygląda. To będzie chyba podobny problem, jak w przypadku SN61.
Pozdrawiam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 17 Lutego 2017, 23:38:13
Poświaty freespota miały jeden spory mankament. Przy standardowej pulsacji lights 2 gasły nim zdążyły się rozpalić. Wymuszało to żonglerkę exekami przy nagrywaniu kolędy, bo zastępczego nie było widać. ;)
SM03 i SN61 mają kompletnie inne zawory i krany, więc problem nawet jak podobny, to w różnych miejscach siedzi.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: djuzi w 18 Lutego 2017, 10:06:41
Chociaż w mojej ocenie poziom "drugi" powinien być poziomem maksymalnym, bo przy włączonych trzech reflektorach wszystko aż błyszczy. Tutaj musieliby coś powiedzieć maszyniści.
Tak, to jest faktycznie za mocne i zbyt białe światło. Owszem, w rzeczywistości jest tak, że gdy wskazniki są blisko reflektora, to są przebłyszczone światłem. Światło reflektorów powinno być bardziej żółtawe.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 18 Lutego 2017, 10:27:49
Zgadza się, że tak powinno być. Ja tylko mówię, że względem poprzedniego exe nic się nie zmieniło na gorsze ;)
Ja tylko mogę się wypowiedzieć na temat tego co widzę na monitorze. Jak dla mnie pierwsza wersja po konwersji owocowała pogorszoną widocznością świateł semaforowych. Zresztą zgłaszane także było, że mijające nas lokomotywy traciły swe światła gdy znalazły się blisko nas, to jest na forum i jest faktem. Ostatnia wersja C++ jest ok, przynajmniej w sprawie semaforów, nie jest gorzej niż na wersji z paczki. Widoczność ich w Zwierzyńcu rozwiązałem indywidualnie, ponieważ męczy mnie taka jazda, zwłaszcza jak chcę zwrócić uwagę na inne elementy. Snop światła, według mnie jest i tak mniejszy niż poprzednio, wyżartych bieli jest mniej, drażni mnie faktura prążków 3, może 4 milimetrowych pionowych prążków pojawiających się po zapaleniu reflektorów. Ale taka uroda tego świetlistego mechanizmu.
Atapi, Firlejczyk, dziękuję za dogłębne wytłumaczenia funkcjonowania freespotów.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 18 Lutego 2017, 15:07:22
Tak, to jest faktycznie za mocne i zbyt białe światło. Owszem, w rzeczywistości jest tak, że gdy wskazniki są blisko reflektora, to są przebłyszczone światłem. Światło reflektorów powinno być bardziej żółtawe.
Biezacy efekt oswietlenia jest w duzej mierze modyfikowany przez parametry scenariusza tzn oswietlenie, mgle, uzyte tekstury itp. Ciezko tutaj jest dobrac wartosci, ktore sie uniwersalnie sprawdza -- te obecne byly dobierane na podstawie TD, gdzie poziom 3 wyglada jak na zalaczonym screenie. Byc moze jest to zbyt jasno, ale z drugiej strony w dedykowanych scenariuszach 'nocnych' efekt moze byc nawet o polowe slabszy, a to juz dosc ciezko zauwazyc, nie mowiac o dalszej redukcji.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: joey w 18 Lutego 2017, 15:55:34
- chodzenie w kabinie dziala teraz tak samo jak wszedzie indziej, czyli na podstawie kata obrotu kamery, zamiast byc oparte na sztywno na orientacji pojazdu. To jest chyba troche bardziej intuicyjne niz mentalna gimnastyka w stylu 'patrze w lewa strone wiec nacisniecie 'w przod' przesunie mnie w prawo' itp.
W kabinie B mamy teraz sterowanie odwrotne - lewo to prawo, prawo to lewo, przod to tyl i tyl to przod.
Ponadto zauwazylem w wersji 170214, moze i wczesniej, zmienil sie sposob filtrowania szyn i podkladow. Dawniej mozna to bylo ustawic w eu07.ini, teraz tego tam nie widze. Przy obecnych ustawieniach wyglada to moim zdaniem gorzej, niz przed zmiana. Podobnie wagony, zwlaszcza osobowe, rozmazuja sie za szybko i z nawet niewielkiej odleglosci, jesli patrzy sie pod katem, zaczynaja zanikac istotne detale, np. okna.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 18 Lutego 2017, 16:43:29
Oj, to zla wersje zaladowalem. W nastepnym uaktualnieniu bedzie jak trzeba.
Co do filtrowania duza role odgrywa teraz parametr "anisotropic filtering" kontrolowany z poziomu systemowych ustawien karty graficznej. Przy sensownych ustawieniach jak x8 albo x16 rozmycie jest w zasadzie wyeliminowane, a jednoczesnie redukuje to znieksztalcenia ktore powstaja przy wymuszaniu filtrowania linearnego.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 18 Lutego 2017, 17:30:55
Nie ma czegoś takiego jak "systemowe ustawienia karty graficznej". Wszystko ustawia się z poziomu GL. https://www.khronos.org/opengl/wiki/Sampler_Object#Anisotropic_filtering
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 18 Lutego 2017, 17:45:39
A jak nazwać te ustawienia z okna w załączniku? Wydawca sterownika określa je jako globalne. Według mnie to systemowe ustawienia karty graficznej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 18 Lutego 2017, 17:58:58
Nie ma czegoś takiego jak "systemowe ustawienia karty graficznej". Wszystko ustawia się z poziomu GL.
Nazwalem to systemowym w sensie "na ta chwile symulator nie ustawia tego w kodzie, wiec trzeba sie pofatygowac do panelu kontrolnego karty z reguly dodanego do systemu przez instalator sterownikow". Chociaz jakby sie zastanowic to mozna by go przy okazji dodac do kodu, uprosciloby to sprawe.

edit: ok, wstawilem to bezposrednio do symulatora. Filtrowanie domyslnie ustawione jest na wartosc 8, na wypadek starszych kart o mniejszej wydajnosci. Konkretna wartosc mozna sobie ustawic w .ini, zapisem
anisotropicfiltering wartosc

Przy okazji w tym uaktualnieniu powinna byc juz wlasciwa wersja sterowania w kabinie B (a takze uniezaleznienie predkosci ruchu w kabinie od fps)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: dymus w 18 Lutego 2017, 19:45:08
eu07++170218 (wcześniejsze wersje też): liczy kilometry jako dziesiątki, plus zaczyna stan od 2km dla jednostek.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 18 Lutego 2017, 21:13:45
Tak przy okazji, to czy licznik kilometrow powinien przeskakiwac co pozycje przy kazdym przejechanym kilometrze, czy obracac sie gladko, tzn po przejechaniu np. 500 m byc w polowie drogi miedzy 0 i 1 na ostatniej pozycji?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: maciek001 w 18 Lutego 2017, 21:45:34
Licznik przeskakuje o ile dobrze pamiętam. Na moich filmikach na YT nie ma niestety momenty przejścia na kolejną cyfrę.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 18 Lutego 2017, 21:52:35
Przesyłam crashdumpa z nowego exeka. Program wysypał się przy próbie ruszenia ST44 po zmianie kabiny. Używałem nowej wersji kabiny ST44 z testów, więc może to też jest jakiś przyczynek do zaistniałej sytuacji.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: ryba825 w 18 Lutego 2017, 22:11:35
Windows 10 najnowszy, sypie się na ładowaniu Pythona (td).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: sawe w 18 Lutego 2017, 22:37:41
Witam.

Jeszcze na temat ET41 i ET42. Otóż na eu07++ te lokomotywy prowadzone przez AI w czasie manewrów nie odłączają się od wagonów, tylko rozłączają się i pierwszy człon jedzie dalej. Być może występuje to tylko u mnie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 18 Lutego 2017, 23:00:00
Przesyłam crashdumpa z nowego exeka. Program wysypał się przy próbie ruszenia ST44 po zmianie kabiny. Używałem nowej wersji kabiny ST44 z testów, więc może to też jest jakiś przyczynek do zaistniałej sytuacji.
Czy to byl jednorazowy wysyp, czy cos stalego? Pobralem ta kabine z testow, wypakowalem u siebie ale tutaj dziala, tzn ST44 jezdzi normalnie, sterowana tak z kabiny A jak i z B.

Windows 10 najnowszy, sypie się na ładowaniu Pythona (td).
Sypie sie akurat na probie zgloszenia bledu, wiec bedzie trudno dojsc co tam jest konkretnie nie tak ;/  Czy jest python27.dll w katalogu, i czy laduje sie poprawnie z oficjalnym exe, albo jakims innym?

Jeszcze na temat ET41 i ET42. Otóż na eu07++ te lokomotywy prowadzone przez AI w czasie manewrów nie odłączają się od wagonów, tylko rozłączają się i pierwszy człon jedzie dalej. Być może występuje to tylko u mnie.
Komus chyba sie to tez przytrafilo wczesniej w watku. Dla pewnosci, czy czlony sa polaczone sprzegiem +128? Tzn polaczenie +191 albo -63?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: sawe w 19 Lutego 2017, 00:19:05
Cytuj
Komus chyba sie to tez przytrafilo wczesniej w watku. Dla pewnosci, czy czlony sa polaczone sprzegiem +128? Tzn polaczenie +191 albo -63?

Po zmianie sprzęgu na -63 odczepianie działa prawidłowo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: ryba825 w 19 Lutego 2017, 00:21:35
tmj, tak, miałem. Dropnąłem folder z maszyną, wypakowałem jeszcze raz i działa. Magic.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: maciek001 w 19 Lutego 2017, 01:42:49
Nie wiem czy w dobrym miejscu piszę ale cóż: mam małe "ale" co do działania analogowego kranu FVel6: dotychczasowo PoKeys sterował tym kranem tak samo jak FV4a.
FV4a ma pozycje od -2 do 6, a FVel6 ma od -1 do 6. Proponuję przerobić to w następujący sposób:
do Train.cpp przekazywać wartość od 0 do 1 i dopiero tam wyliczać dokładne położenie kranu w zależności od rodzaju ustrojstwa.
Zmiana niewielka w kodzie i prosta więc mogę się tego podjąć. Wadą tego rozwiązania jest potrzeba ponownej kalibracji kranów przez użytkowników PoKeys.
Proszę o wypowiedzenie się czy to dobry pomysł. Można pisać w PW żeby tu nie śmiecić.

Ciekawostka: FVel6 kręci się ale nie luzuje na pozycji -1 i to niezależnie czy wprowadziłem zmiany czy nie. Z klawiatury działa poprawnie. naprawiłem ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 19 Lutego 2017, 16:35:22
Na kranach sie nie znam, wiec nie bede sie wypowiadal, niech to sobie madrzejsi ludzie rozpracuja :)

W dzisiejszym uaktualnieniu: naprawiony blad licznika kilometrow, a w ramach walki z wiatrakami, tzn widocznoscia sygnalow, dodana proteza: zoom pod srodkowym klawiszem myszy. Od razu nalezy zauwazyc ze pomaga to co najwyzej srednio, ale poki co technicznie rzecz biorac swoim istnieniem (chyba) nie przeszkadza.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 19 Lutego 2017, 16:46:04
Jak już jesteśmy przy zoomie, to mógłbyś zaimplementować płynną zmianę fow? Ja bym to na scrollu widział, ale niektórzy mają pod niego wyprowadzone jakieś bajery w stylu nastawnika. Na pewno nie tak na wierzchu jak było, bo szkoda klawiatury. Może jakiś klawisz+scroll. W załączniku implementacja od Q, wymagająca nieco poprawek, których nie zdążyłem zrobić przed ucieczką z borlanda.
Jak dodasz, to ustawimy kamery należycie w ciasnych pojazdach i ci, którym nie chce się myszą machać, sobie ustawią rybie oko.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 19 Lutego 2017, 17:35:07
Do ciasnych pojazdow kupuje sie po prostu dobry monitor i tyle ;)

kontrole fov mozna dodac, chociaz chyba nie na szybko bo z tego co pamietam fov jest tez uzywany do okreslenia ktore sektory powinny byc renderowane, wiec potencjalnie moga wyjsc krzaki w stylu odswiezania tylko czesci obrazu. Moze zamiast klawiszy zrobic z tego ustawienie w .ini?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 19 Lutego 2017, 17:38:46
Ta implementacja ma opcję ustawienia w ini. Ale chodzi głównie o te ciasne pojazdy, gdzie niektórzy chcą szerszego pola widzenia by objąć wszystkie mierniki na ekranie, a niektórzy kamery w miejscu głowy maszynisty a nie metr za ścianą.
Była to jedna z pierwszych zmian wprowadzonych przez Q w zeszłym roku i nikt problemów nie znalazł.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 19 Lutego 2017, 17:42:10
FOV powinien też wpływać na widoczność modeli - im mniejszy kąt, tym obiekty w oddali są większe.
Swoją drogą, pozycja napisów jest teraz niezależna od fov?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 19 Lutego 2017, 17:53:57
Swoją drogą, pozycja napisów jest teraz niezależna od fov?
Do pewnego stopnia bylo tak juz przedtem, ale tak, bo to raczej troche bez sensu bylo zeby o pozycjonowaniu UI decydowal kat widzenia kamery -- po wlaczeniu zblizenia UI wyjezdzalo za ekran, i trzeba by to recznie wylapywac i kontrowac.

edit: Ok, dodana eksperymentalnie kontrola fov ustawieniem w .ini:
fieldofview X
gdzie X jest katem widzenia w pionie (wartosc pozioma jest dopasowywana na podstawie stosunku szerokosci/wysokosci okna) Standardowa wartoscia w symulatorze jest 45 stopni, wpisem w .ini mozna to zmienic w zakresie 37.5 - 70 stopni.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: adamst w 19 Lutego 2017, 18:56:09
O, to 45 to faktycznie było dość wąsko. W trainz jeżdżę sobie domyślnie na 55 - nie ma jeszcze efektu rybiego oka, da się ogarnąć pulpit kibelka, i co najwyżej leciutko trzeba się wychylić żeby zerknąć na prędkościomierz. Najgorszy jest SN61 - tam jest tak ciasno, że żadna kamera nie poradzi ;-)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 19 Lutego 2017, 19:14:03
Dziwna sprawa. Na sp32 nie kjreca mi się kola. Na poprzednich exe było ok. W innych modelach jest ok. Sprawdzalem na elektryku i sp42. Ciekawe w czym rzecz. Już mam. Brak wpisu animacion w mmd. Wczesniej to nie przeszkadzalo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 19 Lutego 2017, 19:16:52
gdzie X jest katem widzenia w pionie (wartosc pozioma jest dopasowywana na podstawie stosunku szerokosci/wysokosci okna) Standardowa wartoscia w symulatorze jest 45 stopni, wpisem w .ini mozna to zmienic w zakresie 37.5 - 70 stopni.
Można prosić o poszerzenie zakresu do 15 stopni? Obecnie do realnych odczuć na telewizorze potrzebuję jakieś 19.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 19 Lutego 2017, 19:36:03
Dla porównania wrzucam 6 sreenów z tego co zrobił QueuedEU. Dwa są w trybie debug mode. Pokazałem maksymalne zbliżenie i oddalenie.
ED:
Kontrola zbliżenia/kąta widzenia
[shift]+[PPM] należy przytrzymać do ustalenia pożądanego widoku.
[shift]+[LPM] należy przytrzymać do ustalenia pożądanego widoku.
Regulacja jest płynna i pozostaje na wybranym poziomie po uwolnieniu przycisków.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: dymus w 19 Lutego 2017, 22:57:53
Zauważyłem, że w przypadku wygenerowania e3d na exe elementy mają zby dużą jasność, porównanie jak wygląda na wcześniejszych exe i na tym ostatnim.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 19 Lutego 2017, 23:06:02
Kontrolki w siódemce, gdzie są kontrolowane materiałem mają kolor? Wnętrza tuneli/hal (Drawinowo/Moczniki) są ciemne? Jakby w Drawinowie na nowo wygenerować e3d terenu, byłoby ok?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: dymus w 19 Lutego 2017, 23:12:09
Hmm kabina 4E taka sama jasna, plus lampki, od WS wygląda dobrze, reszta coś nie badzo (po zadziałaniu nadmiarów, załączeniu grzania ich lampki są szare, wyglądają jakby nie przyjęły barwienia materiału).
Moczniki odpalone na exe c++ stare e3d, oraz odpalone na exe c++ wygenerowane e3d na nowo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 20 Lutego 2017, 01:02:27
Można prosić o poszerzenie zakresu do 15 stopni? Obecnie do realnych odczuć na telewizorze potrzebuję jakieś 19.
Nie bardzo rozumiem jak to odczytac, zakres 15 stopni tzn +-15 od domyslnego 45? Czy jakos inaczej? Mozna to zmienic bez problemu, ale nie przypuszczalem ze ktos bedzie chcial zejsc z katem widzenia tak nisko, bo 19 stopni w pionie na ekranie 4:3 wyglada jak na screenie, tzn jakby ogladac kabine przez dziurke od klucza.

edit:
Zauważyłem, że w przypadku wygenerowania e3d na exe elementy mają zby dużą jasność, porównanie jak wygląda na wcześniejszych exe i na tym ostatnim.
Ktos juz chyba zglosil ze cos jest potencjalnie nie tak z ladowaniem plikow .t3d, ale mam u siebie tylko instalacje wersji binarnych, wiec nie mialem okazji na to zerknac.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: maciek001 w 20 Lutego 2017, 10:04:19
Na kranach sie nie znam, wiec nie bede sie wypowiadal, niech to sobie madrzejsi ludzie rozpracuja :)
Opracowałem rozwiązanie o którym pisałem. To co było do tej pory powodowało wyjście poza zakres dla kranu FVel6 (minimalna wartość -1, a podać można było -2). Przerobiłem cały kod tak jak pisałem, przekazywanie wartości położenia kranu od 0 do 1 z Console. Dopiero w Train przeliczane jest na położenie kranu w zależności od jego typu. Powinno to ułatwić dodawanie sterowania innymi kranami. Dodałem jeszcze zapis do loga wyliczonej wartości dla kranu. Dzięki temu można na bieżąco podglądać jaka jest wartość ustawiana i jak reaguje kran w symulacji.

Tak jak pisałem: wprowadzenie tej poprawki zmusi posiadaczy PoKeys do przeliczenia wpisów kalibracyjnych dlatego też pytam o zgodę Was!
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 20 Lutego 2017, 15:22:21
Wygenerowałem paczkę tga/t3d z obecnego archiwum na SVN. Potwierdzam problemy poruszone przez @Dymusa. Dodatkowo lampki SHP w EN57 nie świecą na czerwono mimo alarmu. Testy na tej paczce dopiero zacząłem, jeśli zauważę nieprawidłowości to zgłoszę. Wydaje się, że podobne "hece" były przy przejściu z tga na dds.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 20 Lutego 2017, 15:25:43
Blad w .t3d sie znalazl (zgubila sie konwersja kolorow ze skali 0-255 do 0-1, w rezultacie praktycznie wszystkie elementy byly renderowane w pelni biale), poprawka bedzie w nastepnym uaktualnieniu. Puscilbym teraz, ale chce przy okazji zmiescic ewentualna zmiane katow kamery dla youBy, o ile dowiem sie o co tam chodzi ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 20 Lutego 2017, 16:06:50
Można prosić o poszerzenie zakresu do 15 stopni? Obecnie do realnych odczuć na telewizorze potrzebuję jakieś 19.
Nie bardzo rozumiem jak to odczytac, zakres 15 stopni tzn +-15 od domyslnego 45? Czy jakos inaczej? Mozna to zmienic bez problemu, ale nie przypuszczalem ze ktos bedzie chcial zejsc z katem widzenia tak nisko, bo 19 stopni w pionie na ekranie 4:3 wyglada jak na screenie, tzn jakby ogladac kabine przez dziurke od klucza.
Dokładnie tak to ma wyglądać – chodziło mi o ustawienie minimalnego kątu patrzenia jako 15°.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 20 Lutego 2017, 16:23:33
Hmm nie bede udawal ze rozumiem, ale ok ;)

Zmienilem dopuszczalny zakres do 15-75 stopni, powinno tez byc poprawione ladowanie .t3d
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 20 Lutego 2017, 17:21:49
Największy problemem z testowaniem paczki tga są... Trzeba hurtowo wywalać pliki E3D, co jest upierdliwe. Chyba, że macie na to jakiś sposób?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 20 Lutego 2017, 17:26:55
w bashu find . -iname "*.e3d" -delete, a w cmd to pewnie del /s /q *.e3d
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 20 Lutego 2017, 17:30:33
Kazałem szukać szukajce plików .e3d w katalogu z symulatorem, w sumie też nieźle idzie. Dzięki.
Pobrałem, zaraz sprawdzę co z mocznikami i kiblem. Poprzednia kompilacja wysypywała mi się na Całkowie sn61 w tga, ale tu trzeba kilka podejść zrobić i sprawdzić.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 20 Lutego 2017, 18:11:17
Wyłączyć tworzenie e3d?
Kod: ("eu07.ini") [Zaznacz]
convertmodels 0
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 20 Lutego 2017, 18:16:54
Wyłączyć można, ale wtedy za każdym razem długi czas wczytywania. W zasadzie poprawne tworzenie modeli e3d w exe dodawanych do paczki z teksturami dds nie jest potrzebne. Tak czy inaczej poprawny mechanizm tworzenia e3d być musi, natomiast użytkowe exe może tego wcale nie mieć. Ktoś zadecyduje? To są ważne decyzje, może na lata.
Melduje poprawne utworzenie plików w Mocznikach i prawidłowe wyświetlenie lampek. Może jeszcze komuś uda się to sprawdzić?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: dymus w 20 Lutego 2017, 18:35:31
Sprawdziłem wygenerowanie e3d na losowej kabinie jest ok, to samo dworzec w mocznikach, też jest dobrze.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 20 Lutego 2017, 19:50:02
Buildy z forka z GLFW.
Coś się zepsuło ze skalowaniem obrazka startowego ale na dzisiaj mam już dość.

32bit: https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng32-64e3e810.zip
64bit: https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng64-64e3e810.zip
Wersja 64bit szuka bibliotek pythona w katalogu python64. Trzeba do niego skopiować local z obecnego katalogu python, a DLLs i Lib należy skopiować z katalogu instalacji pythona z zainstalowanym pillow.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 20 Lutego 2017, 19:52:12
A właśnie, w buildzie TMJ też się skalowanie obrazka startowego zepsuło. Przy 16:9 zamiast być w 4:3 plus kolorowe pasy po bokach, to go skaluje.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 20 Lutego 2017, 20:09:49
A fakt, przerzucilem ustawianie perspektywy do petli renderujacej, wiec ekran startowy zostal, jak to sie ladnie mowi, z przyrodzeniem w garsci. Domyslna konfiguracje mam z oknem 4:3 wiec nie rzucilo mi sie to w oczy, poprawie przy nastepnej wersji.

edit: Ciekawostka, wersja GLFW renderuje troche inaczej (na screenach to ta po prawej) Uzywa domyslnie sRGB albo czegos?

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 20 Lutego 2017, 22:50:54
Niestety na c++ wysypuje mi na odpalaniu paczki t3d/tga. Wysypy są w różnych miejscach. Czasem po inicjalizacji pojazdów, czasem już na wstępie. Niestety nie generują się crashdumpy mimo, że od Milka7 te pliki miałem. Poprawnie wczytałem tylko Bałtyk i TD, także Moczniki. Nie wczytuje mi także scenerii kiedy wcześniej generowałem e3d innym exe. Na paczce e3d jest dobrze, nie ma wysypów, wprowadzane zmiany funkcjonują. Przykładowy log w załączniku.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 20 Lutego 2017, 23:03:40
Jest gdzies w ogole link skad mozna pobrac wersje .tga/.t3d bardziej aktualna niz 15.02?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 20 Lutego 2017, 23:06:50
Partiami dla wszystkich: http://eu07.pl/daily/
Do kupy dla rangowych: http://eu07.pl/svn/pctga/
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 20 Lutego 2017, 23:20:51
Dzieki. Do rangowego nie mam dostepu, a dzienny to tak na oko jest z 4-5gb w 40+ plikach, tu trzeba kogos z sila woli/OCD wiekszym niz moje, zeby to sobie recznie posciagac i poskladac :x  Zobacze, co sie uda wylapac na 15.02
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 20 Lutego 2017, 23:22:32
Ściągając z svn to jakieś 25GB na dysk. Uprawnienia powinieneś dostać od admina.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 20 Lutego 2017, 23:27:26
Już masz uprawnienia. A na daily masz co jakiś czas reset archiwum. Trzeba patrzeć po wadze i pobierać ostatnie przed tym jak się zmniejsza waga. Czyli:
12-Feb-2015 00:40    298M ściągasz
23-Feb-2015 05:50    2.6M już nie
24-Feb-2015 05:50    2.6M też nie
10-Apr-2015 05:54    176M tak, bo zawiera dwa powyższe
27-Apr-2015 05:50    15M    znowu nie
I tak dalej.

Ja nie odpalę większości scenerii na paczce TGA. Za mało ramu na wczytanie tak ciężkich tekstur. Efekt to abmormal termination jak braknie pamięci na wczytywanie kolejnych. Na nowych exekach nie patrzyłem, czy generuje crashdumpa w tej sytuacji.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 20 Lutego 2017, 23:34:19
Aha. No jak wylatuje na braku pamieci to tutaj za bardzo nic sie nie zrobi. Tzn moze gdyby zaczac sie bawic w generacje/wymiane danych w locie na podstawie tego co jest potrzebne/uzywane, ale w sumie to bylaby raczej sztuka dla sztuki.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 20 Lutego 2017, 23:35:53
edit: Ciekawostka, wersja GLFW renderuje troche inaczej (na screenach to ta po prawej) Uzywa domyslnie sRGB albo czegos?
Raczej nie, powinno tworzyć taki sam kontekst jak wcześniej. Trochę widzę że na alfie się różni, bo w kolorach to nie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 20 Lutego 2017, 23:40:15
To tak przy okazji. 07++NG odpala mi scenerie w paczce z tga i t3d, ale nigdy w pojeździe. Nie wiem czy wszystkie, runtime error miałem jak odpalałem Moczniki Zwierzyniec.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 20 Lutego 2017, 23:42:30
Raczej nie, powinno tworzyć taki sam kontekst jak wcześniej. Trochę widzę że na alfie się różni, bo w kolorach to nie.
Glownie wychodzi to na chmurach -- te ze 'standardowego' exe sa troche bardziej przeswietlone, tak jakby tam troche inna gamma byla. A dane zrodlowe i kod ladowania sa w sumie te same, wiec cos musi byc tam gdzie inne :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 21 Lutego 2017, 18:02:06
To tak przy okazji. 07++NG odpala mi scenerie w paczce z tga i t3d, ale nigdy w pojeździe. Nie wiem czy wszystkie, runtime error miałem jak odpalałem Moczniki Zwierzyniec.
Nazwy pojazdów przy wczytywaniu scn zamieniane są na lowercase, a po moich zamianach w parserze argumentów zachowywało oryginalne i nie znajdowało pojazdu. Zmieniłem, ale nie po co to w ogóle się zamienia przy ładowaniu scn. Co do bugów przy ładowaniu TGA i T3D to zachowanie powinno być takie samo jak w buildach tmj,  ja grzebałem tylko przy ładowaniu DDS i E3D. Jeżeli zachowanie jest inne to kiepsko, bo pewnie coś pisze po pamięci i wysypy są zależne od różnych niezależnych czynników.
32b: https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng32-62e97669.zip
64b: https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng64-62e97669.zip
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 21 Lutego 2017, 18:11:25
Nazwy pojazdów przy wczytywaniu scn zamieniane są na lowercase, a po moich zamianach w parserze argumentów zachowywało oryginalne i nie znajdowało pojazdu. Zmieniłem, ale nie po co to w ogóle się zamienia przy ładowaniu scn.
To chyba glownie jako idioto-odpornosc, tzn zeby nie bylo kwiatkow w stylu ktos sobie postawi na torach "EU07", w pliku wpisze "Eu07" i potem placz, ze mu pociagu nie znajduje.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 21 Lutego 2017, 18:22:02
O tak, teraz wylądowałem w lokomotywie tak jak powinno być. Na razie na TD. Sprawdzę scenerie z którymi jest kłopot. Póki co mogę sprawdzić tylko na 32bitowym xp.
ED:
Wysyp na Zwierzyńcu, załącznik komunikatu i log.
ED2:
Zapomniałem, paczka t3d/tga i C++NG od Milek7.
Uznałem, że trzeba ogarnąć konwersję modeli.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 21 Lutego 2017, 18:55:29
Żeby coś wymyślić to musiałbym mieć crashdumpa z debug builda, ale lepiej będzie jak to zreprodukuje u siebie. Skąd to można pobrać? W paczce 15.02?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 21 Lutego 2017, 18:59:03
Linki do paczek tga są niżej wyżej (ja mam inaczej wygląd forum ustawiony), potrzebne jest hasło do svn od admina. Natomiast crash dumpa nie ma, bo się nie wygenerował.
ED:
Dorzucam log z wczytywania Quarka, inaczej się kończy, nieudane.
ED2:
Jeszcze jeden log z Mocznikami. Chyba wystarczy na ten moment.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 21 Lutego 2017, 19:52:56
Na win xp 32 bit nie wczyta większości scenerii w tga, bo nie starczy na to ramu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 21 Lutego 2017, 20:37:34
Ja mówię o sceneriach, która zawsze się wczytują na 32bitowym winXP. Nie ma takiej scenerii, która u mnie nie wczytała się z paczki TGA na na exe 483. Powiem więcej, mam tylko 4Gb pamięci ram. Za chwilę log i screen z poprawnego wczytania i jazdy na Zwierzyńcu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 21 Lutego 2017, 22:19:34
Moczniki wysypują się tylko na moim czy też na tmj?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 21 Lutego 2017, 22:37:51
Tylko na Twoim, Sprawdzalem tworzenie dworca wmocznikach, powinny byc opisy tutaj. Z tego co napisal @Stele z paczki tga nie moge otworzyc tylko jednego scenariusza na L053. Log zatrzymuje sie na generacji e3d jakiejs budki droznika. Ze wzgledow na wspoldzielenie komputera dzis nie bedzie juz testow.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 22 Lutego 2017, 02:27:01
Z wiadomosci pozytywnych: bardziej dokladna symulacja ruchu slonca i kalkulacji oswietlenia nieba itp moze tanim kosztem zrobic zauwazalna roznice.

Z wiadomosci negatywnych: niektore z istniejacych scenerii wychodza na tym tak sobie, bo jesli nie dzieja sie latem, to po godzinie 17-ej jest juz praktycznie ciemno, podczas gdy do tej pory w symulatorze bylo w miare widno tak gdzies do 21-ej. Tak wiec ewentualne dodanie tego kodu do exe zapewne wiazaloby sie z poprawkami w kilku sceneriach. Pytanie, czy komus by sie chcialo to zrobic :x

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: szczawik w 22 Lutego 2017, 06:29:31
Opisz zmiany w sceneriach do wykonania. Chodzi o wpisy pogody i oświetlenia?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 22 Lutego 2017, 08:07:09
Po konsultacjach ze @Stele, uznalismy ze wklejanie dalszych logow i screenow nie ma sensu. Tak jak napisalem wczesniej scenerie, ktore u mnie sie nie wczytuja z paczki tga na exe od @tmj i @Milka 7 wczytuja sie na exe483 z svn. Nie udaje sie wczytasc sceneriiL053 na wszystkich exe, scenarisz tlk i tu wyglada ze ilosc tekstur tga kladzie temu kres. Tu nasuwa sie pytanie, czy symulator korzysta ze swapa (biorac pod uwage wolnej pamieci przydzielonej na dysku, to nie), jesli nie to jaka jest mozliwosc wprowadzenia tego i jak wplynie to na wydajnosc i plynnosc symulacji. Czy jest sens podjac temat, skoro powszechnie uzywany jest dds? Kiedys nawet w dds przyjdzie sceneria przekraczajaca ilosc pamieci ram w niektorych komputerach.
Z wiadomosci pozytywnych: bardziej dokladna symulacja ruchu slonca i kalkulacji oswietlenia nieba itp moze tanim kosztem zrobic zauwazalna roznice.
Jesli zmiany beda tylko w plikach scn, to jest ich na tyle niewiele, ze ewentualny pacz do poprawnie dzialajacego exe nie powinien byc zadnym klopotem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 22 Lutego 2017, 14:46:29
Opisz zmiany w sceneriach do wykonania. Chodzi o wpisy pogody i oświetlenia?
Glownie tak. Tzn w niektorych sytuacjach sprowadza sie to do parametru movelight, w zalaczniku roznica na Kaliskiej miedzy wartoscia domyslna (240) i po przesunieciu 'kalendarza' o miesiac z kawalkiem wstecz (200)

W niektorych scenariuszach jak np. Calkowo samo movelight moze byc niewystarczajace, i w takiej sytuacji trzeba by tez troche przesunac zegar, rozklad i przypisane do czasu eventy. Okazjonalnie moze tez zajsc potrzeba zmiany tekstury uzytej dla nieba -- np. Baltyk uzywa tekstury ze sloncem przebijajacym przez chmury z polnocy, co nie bardzo zgadza sie z rzeczywista pozycja slonca, oswietlajacego scenerie z poludnia :d
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 22 Lutego 2017, 19:23:11
Po konsultacjach ze @Stele, uznalismy ze wklejanie dalszych logow i screenow nie ma sensu. Tak jak napisalem wczesniej scenerie, ktore u mnie sie nie wczytuja z paczki tga na exe od @tmj i @Milka 7 wczytuja sie na exe483 z svn. Nie udaje sie wczytasc sceneriiL053 na wszystkich exe, scenarisz tlk i tu wyglada ze ilosc tekstur tga kladzie temu kres. Tu nasuwa sie pytanie, czy symulator korzysta ze swapa (biorac pod uwage wolnej pamieci przydzielonej na dysku, to nie), jesli nie to jaka jest mozliwosc wprowadzenia tego i jak wplynie to na wydajnosc i plynnosc symulacji. Czy jest sens podjac temat, skoro powszechnie uzywany jest dds? Kiedys nawet w dds przyjdzie sceneria przekraczajaca ilosc pamieci ram w niektorych komputerach.
Przepraszam że zapomniałem powiedzieć wcześniej, ale jeżeli chodzi o generowanie e3d na moim exe to nie spodziewałem się zbytnio żeby zadziałało, bo robiłem zmiany w strukturze submodelu i nie przerabiałem jeszcze zapisywania. Pewnie jutro przepiszę to tak jak z wczytywaniem, serializacja zamiast bezpośredniego kopiowania pamięci.
Co do wczytywania T3D/DDS to przed chwilą przetestowałem i nie powinno być problemów. (L053 zajęło 3.3GiB, ale 4.2GiB wirtualnej więc nie dziwne że na 32bit nie rusza). Jeżeli jednak są to proszę zgłaszać.
Swap jest kontrolowany przez system operacyjny, nie przez aplikację. Do tego powyżej 4GiB na 32bit to żaden swap i tak nie pomoże. Jeszcze jest kwestia pamięci karty graficznej (to też zależne od sterownika, bo może kombinować z przerzucaniem nieużywanych tekstur do pamięci głównej).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 22 Lutego 2017, 20:27:26
Poprawki cyklu dobowego wrzucaj i się nie przejmuj. Od lat mieliśmy to zrobić, tylko nikt nie umiał. Jakbyś miał trajektorię dla słoneczka i księżyca, to też dodaj. Że atmosfera się zmieni po poprawce błędnego liczenia oświetlenia, rzecz oczywista, ale czy zła? Movelight i tak raczej nie jest używany z teksturowymi czaszami nieba.
Co do dziwnych kierunków światła, lata temu Ra obracał je do zgodności z kierunkami geograficznymi. Jak coś jeszcze jest dziwne, to wypisujcie które czasze w bugtrackerze. Się poprawi.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 22 Lutego 2017, 21:29:57
Milek, to L053 na XP Ci nie ruszy. Żeby to mogło działać możesz zająć maks 2GB dla exe.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: szogun w 22 Lutego 2017, 21:43:07
Ja tylko powiem jedno, szacun ogromny dla @firleju że zaczął temat i postanowił ruszyć MaSzynę ku lepszemu, no i również szacun dla @tmj że pomaga w debugu i dodaje swoje ficzery, kurde, jak zdebugujecie kod do końca i ulepszycie to my tu Trainza będziemy mieć :D Żeby nie był offtop, zdecydowanie trzeba obrócić nieba do stanu faktycznego, bo zauważyłem, szczególnie na Bałtyku że oświetlenie nie zgadza się ze stanem sky'a. Ten screen z Kaliskiej wygląda naprawdę dobrze i tego brakowało, bo movelight zastosowane przez @Ra chyba nie za bardzo miało coś wspólnego z oświetleniem kierunkowym. Wszystko było wyświetlane jakby dostawało światlo z każdej strony. Na TD jest domyślnie movelight w scn i wygląda to benadziejnie, a najgorsze że nowi twórcy dobierają do tego jasność, kontrast i nasycenie tekstur.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Mariusz1970 w 22 Lutego 2017, 21:58:29
Ja dodam tylko, ze u mnie na Win98, na teksturach tga, bmp, tex L053, L61, L144 dzialaja bezproblemowo. Exe wiadomo jakie ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: maciek001 w 22 Lutego 2017, 22:55:56
Zrobiłem PullRequesta z moimi plikami.
Ktoś wywalił z Globals.cpp Console::ModeSet(iFeedbackMode, iFeedbackPort); przez co nie dało się włączyć jakiegokolwiek starego FeedBacka. Było to zabezpieczoną jakąś zmienną qp ale takowej już nie ma także "leży luzem".

Moje poprawki trochę zmieniają samo sterowanie i możliwość dodania kranów innych niż FV4a i FVel6 do sterowania analogowego (przekazuje się wartość od 0 do 1). Dla FVel6 jest nowy if zrobiony (wcześniej razem z FV4a był) bo jest całkiem inny zakres działania. Dodałem swoje debugowania i udostępnię plik w excelu z całym opisem (jak już skończę).

Nie wiem czemu "nie widzi mi" poprawnie iPause. Chciałem zrobić uzależnienie, że jak pauza to prędkość poruszania jest 0. Nie działa mi to niestety na razie.

Wszystko było testowane i działa - PoKeys też. Nie trzeba wprowadzać żadnych zmian do zmiennych kalibracyjnych PoKeys.

PS:
Jak skończycie przenosić całą MaSzynę na C++ do końca tego roku to zamówię Wam po kracie piwa z dostawą do domu.
Trochę spóźnienia mieli chłopaki ale myślę, że i tak zasłużyli!
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 23 Lutego 2017, 03:05:13
Wywalilem dzisiaj na probe wszystkie pliki .e3d i .dds z instalacji, wrzucilem zamiast tego .t3d i .tga i patrzylem co sie stanie. Wyskoczyl przy okazji jeden blad w ladowaniu plikow, ale po usunieciu wszystkie scenariusze weszly bez wiekszych problemow (sprawdzilem tylko po jednym dla kazdej scenerii, bo za dlugo by trwalo) Wychodzi na to ze 3gb na karcie graficznej na razie wystarcza, nawet dla .tga ;)

Jakbyś miał trajektorię dla słoneczka i księżyca, to też dodaj.
Slonce jest juz wstawione (tzn trajektoria, samego slonca na razie nie rysuje) z ksiezycem na razie sie wstrzymuje, bo chyba jest tez ksiezyc dolaczony do modelu gwiazd ktory jest w symulatorze, a chce podpiac te gwiazdy przy rysowaniu nocy, bo ladne sa. I glupio by bylo, jakby sie dwa ksiezyce zrobily :d   Poprawilem przy okazji troche oswietlenie w nocy (w zalaczniku, Kaliska po zakonczeniu jazdy) i chyby nie jest zle. Ale pare rzeczy musze jeszcze z oswietlenia podpiac z powrotem, wiec uaktualnienia na dzisiaj nie ma jak dobrze pojdzie bedzie jutro. A potem moze bedzie mozna myslec o laczeniu z wersja Milka.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 23 Lutego 2017, 11:16:07
Na służbowym wiekowym monitorze uwalonym farbą, to widzę jedną wielką czarną plamę i kilka mniejszych jasnych plamek. :D
Księżyc można wywalić z pliku t3d notatnikiem. To wskazówka godzinowa zegara, kręcąca się w okół środka czaszy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 24 Lutego 2017, 00:39:14
Na służbowym wiekowym monitorze uwalonym farbą, to widzę jedną wielką czarną plamę i kilka mniejszych jasnych plamek. :D
Znaczy sie, jest jak trzeba ;)

Wstepna wersja uaktualnienia ze zmianami oswietlenia:
- implementowana prawidlowa sciezka slonca w zaleznosci od daty/czasu
- implementowane bardziej wierne oswietlenie nieba
- efektem ubocznym jest nieco inne oswietlenie scen (ambient gra troche mniejsza role, kolor swiatla i mgly jest bazowany bardziej na aktualnym oswietleniu nieba)
- gwiazdy sa standardowym elementem sceny, pojawiaja sie gdy zrobi sie dostatecznie ciemno, nie trzeba wiec ich recznie dokladac do sceny
- ogolny poziom oswietlenia w scenie jest kalkulowany troche inaczej; pod klawiszem F2 w trybie poza pojazdem wyswietlany jest aktualny poziom jasnosci, dla latwiejszego ustawienia parametrow w obiektach itp
- oswietlenie kabiny jest teraz widoczne w widoku zewnetrznym, jesli model ma low poly interior. ograniczeniem jest tutaj jednakowe oswietlenie calego wnetrza, ale to limitacja biezacego podejscia do modeli.

Chwilowo wylaczone:
- renderowanie chmur
- zmiana jasnosci w tunelach itp

Po zmianach oswietlenia czesc scenariuszy rozgrywa sie teraz po zmroku, zamiast jak do tej pory przed. Do pewnego stopnia mozna to "naprawic" zmiana parametru movelight w scenariuszu. Np "calkowo_niebezpieczny_pociag" po przesunieciu z movelight 231 na movelight 191 rozgrywa sie (do pewnego stopnia) jeszcze przed zmierzchem.

edit: oprocz exe w paczce jest tez model gwiazd, ktory wedruje do katalogu "models".

edit2: macku, jesli mozesz zrobic pull request bez solucji VS to bylbym wdzieczny, bo nie bardzo widzi mi sie "upgrade" do wersji, ktorej nie mam :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 24 Lutego 2017, 12:02:23
Nie wiem czy to dobry moment, ale na przyszlosc przydaloby sie zastanowic nad odlegloscia swiecenia freespotow, ktore zdaje sie ograniczone sa parametrem maxdistance rodzica. Czasami chce sie zwiekszyc widocznosc samego swiatla (semafory mam konkretnie na mysli).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: matek123 w 24 Lutego 2017, 12:10:15
To da się załatwić hierarchią.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 24 Lutego 2017, 12:49:06
- oswietlenie kabiny jest teraz widoczne w widoku zewnetrznym, jesli model ma low poly interior. ograniczeniem jest tutaj jednakowe oswietlenie calego wnetrza, ale to limitacja biezacego podejscia do modeli.
Masz jakiś pomysł jak to rozwinąć? Chodzi mi zwłaszcza o podświetlenie modelu. Kombinowałem z modyfikacją emisyjności materiału, ale to wymaga rekompilacji e3d.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 24 Lutego 2017, 13:47:52
To da się załatwić hierarchią.

No, tylko ze teraz trzeba to robic we wszystkich glowicach ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 24 Lutego 2017, 14:06:57
Masz jakiś pomysł jak to rozwinąć? Chodzi mi zwłaszcza o podświetlenie modelu. Kombinowałem z modyfikacją emisyjności materiału, ale to wymaga rekompilacji e3d.
Na ta chwile w modelu jest pojedynczy 'slot' dla uproszczonego wnetrza, wiec wymusza to w praktyce jeden scalony modul. Rozwiazaniem mogla by tu byc np rozbudowa mozliwosci definiowania kabin z podaniem wersji "low poly" modelu dla kazdej kabiny indywidualnie. Przy takim ustawieniu daloby sie oswietlac indywidualne moduly low poly, na podstawie obsadzenia kabiny i uzytych przyciskow oswietlenia.

Nie wiem czy to dobry moment, ale na przyszlosc przydaloby sie zastanowic nad odlegloscia swiecenia freespotow, ktore zdaje sie ograniczone sa parametrem maxdistance rodzica. Czasami chce sie zwiekszyc widocznosc samego swiatla (semafory mam konkretnie na mysli).
Z freespotami w ogole dziwnie jest, np te na semaforach pala sie az do maksymalnego zblizenia, ale te na swiatlach lokomotyw znikaja juz po przyblizeniu na ~100-200 m, co powoduje efekt 'wylaczania' swiatel na srednim dystansie. Wie ktos moze, jak to jest ustawione/zorganizowane?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 24 Lutego 2017, 16:56:58
Proszę spojrzeć na załącznik, słońce jest o godzinie 18 dokładnie na północy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: maciek001 w 24 Lutego 2017, 17:18:57
No ale w czym problem? Noc polarna + zmiana strefy czasowej (ktoś nie uwzględnił 6 godzin) :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 24 Lutego 2017, 17:28:20
Na ta chwile w modelu jest pojedynczy 'slot' dla uproszczonego wnetrza, wiec wymusza to w praktyce jeden scalony modul. Rozwiazaniem mogla by tu byc np rozbudowa mozliwosci definiowania kabin z podaniem wersji "low poly" modelu dla kazdej kabiny indywidualnie. Przy takim ustawieniu daloby sie oswietlac indywidualne moduly low poly, na podstawie obsadzenia kabiny i uzytych przyciskow oswietlenia.
Nie zrozumiałem o co chodzi. Umiałbyś zrobić tak, by świeciły poszczególne submodele lowpoly? Nadal byłoby jako jeden obiekt, ale podzielone na n lampek. W lokomotywie odpowiadałyby za obie kabiny, w wagonie za korytarz i różne przedziały.
Jeśli obecna koncepcja jednak się utrwali, proszę o dodanie do ai zarządzającego składem, gdzieś tam gdzie obsługa drzwi i kierownika jest, zapalanie światła w wagonach. Choć pewnie nie będzie to możliwe, jak stan światła jest w kabinie. Muszę zobaczyć w kodzie jak to zrobiłeś...

Z freespotami w ogole dziwnie jest, np te na semaforach pala sie az do maksymalnego zblizenia, ale te na swiatlach lokomotyw znikaja juz po przyblizeniu na ~100-200 m, co powoduje efekt 'wylaczania' swiatel na srednim dystansie. Wie ktos moze, jak to jest ustawione/zorganizowane?
Freespoty są zrobione tak, jak modelarz je zrobił. Zazwyczaj ustawiało się znikanie na jakąś odległość, gdy przestawały być wyraźne światła jako mesh. Jak chcesz to normalizować, to potrzebny jest automat, który łapałby ten parametr w t3d. Notatnikiem raczej tego nie złapię, za dużo parametrów pomiędzy.

Krzysiu, czy to północ? Kaliska nie trzyma zgodności z kierunkami geograficznymi.

------------
Po zmianach w ambiencie smuga jest do ponownej kalibracji. TD, północ, wszystkie reflektory włączone a efekt jakbym tor próbował kolejką PIKO oświetlać.
Przeskok freespota może wynikać z nowego filtrowania tekstur. Kiedyś świecącego mesha światła nie rozmywało aż tak, freespot był mniejszy i nie było widać przeskoku przy tych samych parametrach.
Wysypało przy zamykaniu programu. Crashdump w załączniku.
Coś z konwersją azymutu na literkę kierunku się popsuło. Mam N, EN, N, EE, S, W, S, WW.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 24 Lutego 2017, 18:02:49
Cytuj
Krzysiu, czy to północ? Kaliska nie trzyma zgodności z kierunkami geograficznymi.
W załączniku cała sceneria i wycinek na którym jest Dworzec Kaliski. Jeśli przyjąć, że odwracamy scenerię o 180 stopni (tak wynika z ałącznika i mam google, to słońce będzie nadal w złym punkcie. Przynajmniej tak mi się wydaje. Oczywiście zależy to od pory roku. Zakładam, że STV trzyma kierunki świata jak należy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 24 Lutego 2017, 18:06:39
Proszę spojrzeć na załącznik, słońce jest o godzinie 18 dokładnie na północy.
Obawiam sie, ze w symulatorze polnoc jest gdzie indziej :)

(pod klawiszem F2 poza pojazdem mozna sobie zobaczyc dokladny kat. Gdzie konkretnie zakonczy bieg slonce zalezec bedzie od szerokosci geograficznej i daty; w lecie zdazy sobie powedrowac nieco bardziej na zachod, w zimie mniej)

edit: ale swoja droga to faktycznie jest obrocone nieprawidlowo. na oko w ciagu dnia bylo dobrze wiec sie nie przygladalem, ale po testach przy ustawieniu na 21 marca wychodzi, ze trzeba obrocic calosc o 90 stopni)

Nie zrozumiałem o co chodzi. Umiałbyś zrobić tak, by świeciły poszczególne submodele lowpoly? Nadal byłoby jako jeden obiekt, ale podzielone na n lampek. W lokomotywie odpowiadałyby za obie kabiny, w wagonie za korytarz i różne przedziały.
Jeśli obecna koncepcja jednak się utrwali, proszę o dodanie do ai zarządzającego składem, gdzieś tam gdzie obsługa drzwi i kierownika jest, zapalanie światła w wagonach. Choć pewnie nie będzie to możliwe, jak stan światła jest w kabinie. Muszę zobaczyć w kodzie jak to zrobiłeś...
Na upartego daloby sie to zrobic. Na razie wyglada to tak, ze DynamicObject ma dwa dodatkowych parametry, definiujace kolor i aktualna sile oswietlenia wnetrza. Mozna by z tego zrobic tablice, ktora trzymala by te wartosci dla indywidualnych sub-modeli, i przy renderingu oswietlenie byloby dostosowywane na podstawie zgodnosci wpisu w tabeli z nazwa sub-modelu. Kontrole oswietlenia da sie wtedy realizowac np. wysylana wzdluz skladu komenda typu "swiatlo submodel wartosc", ktora ustawiala by sile swiatla w podanym sub-modelu w kazdym pojezdzie, ktory ja otrzyma.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 24 Lutego 2017, 18:40:43
Proszę spojrzeć na załącznik, słońce jest o godzinie 18 dokładnie na północy.
Obawiam sie, ze w symulatorze polnoc jest gdzie indziej :)

(pod klawiszem F2 poza pojazdem mozna sobie zobaczyc dokladny kat. Gdzie konkretnie zakonczy bieg slonce zalezec bedzie od szerokosci geograficznej i daty; w lecie zdazy sobie powedrowac nieco bardziej na zachod, w zimie mniej)

edit: ale swoja droga to faktycznie jest obrocone nieprawidlowo. na oko w ciagu dnia bylo dobrze wiec sie nie przygladalem, ale po testach przy ustawieniu na 21 marca wychodzi, ze trzeba obrocic calosc o 90 stopni)
Nie napisałem tego, aby marudzić. Zwyczajnie zwróciłem uwagę na fakt niegodności z rzeczywistością bo ten teren dobrze znam osobiście. Uważam, że światła w lokomotywach są za słabe. I tu powiem tak, one zwyczajnie są do niczego nawet jak określimy w przybliżeniu jakąś wartość jasności która zadowoli wszystkich. Póki co nie widać drutu jezdnego a słupy trakcji dostają oświetlenie (pojawia się różnica jasności) na 10 metrów przed lokiem. Testowałem przed chwilą... Wiadomo, Kaliską.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 24 Lutego 2017, 19:05:44
Nie napisałem tego, aby marudzić. Zwyczajnie zwróciłem uwagę na fakt niegodności z rzeczywistością bo ten teren dobrze znam osobiście.
Dobrze sie stalo, bo po testach faktycznie wyszedl blad -- opieralem sie na danych z HUD, a w tych z kolei byl krzak po konwertowaniu tekstu z Borlanda na std. I w rezultacie wszystko bylo obrocone o 90 stopni. W uaktualnionej wersji poprawione sa oba bledy, a przy okazji takze ekran startowy, zeby nie rozciagal sie w trybie szerokoekranowym, bo kompletnie o tym zapomnialem.

Co do oswietlenia, to obawiam sie ze tutaj duzo nie da sie zrobic przy zastosowanej metodzie, tzn po zmroku to jest jeszcze w miare, ale im pozniej tym gorzej i zwiekszanie 'sily' smugi raczej tu nie pomaga. Trzeba bedzie pomyslec o wprowadzeniu tutaj faktycznego zrodla swiatla.

Aha, @Stele ten wysyp bedzie sie na razie okazyjnie zdarzal, to wychodzi gdy logger dostaje polecenie dopisania tekstu do logu, a obiekt ktory wydal taka instrukcje jest w miedzyczasie usuwany, i zabiera tekst ze soba. Zeby to usunac trzeba poprawic logger, a ze wyskakuje to w zasadzie tylko, gdy program jest juz zamykany, specjalnie mi nie zalezalo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 24 Lutego 2017, 19:48:10
I teraz się zgodzę z pozycją słoneczka, a Kaliską obrócić trzeba o 180 stopni.
Ze smugą należało by wrócić do ostatnie wersji na 3 razy, jak komuś za widno, sobie ściemni. W końcu w paczu było jasno jak cholera i ściemni się nie dało. Dla mnie teraz nijak to wygląda.
A na "prawdziwe żarówki" to czekają wszyscy...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 24 Lutego 2017, 20:00:44
Jest szal jak sie patrzy, ale nie wiem jak sie przyspiesza czas. Niby w debugmode CTRL+F6 czy jakos tak, moze 2x szybciej sekundy leca ale czy da sie przyspieszyc o minuty na sekunde?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: surgeon w 24 Lutego 2017, 20:36:55
Jest jeszcze Shift+Ctrl+F6. Ale może to otwierać tunele czasoprzestrzenne, dlatego lepiej tego nie używać. Szczególnie przy niskim FPS.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 24 Lutego 2017, 20:38:32
Manipulacji czasu nie dotykalem w ogole (nie wiem nawet jak sie to wlacza) wiec jest tylko to, co od zawsze bylo w exe :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 24 Lutego 2017, 20:46:24
Daj tam w OnKeyPress w world.cpp

  if (Console::Pressed(VK_CONTROL) && Console::Pressed(VK_F6)) Global::fTimeSpeed = 1000.0;
  if (Console::Pressed(VK_CONTROL) && Console::Pressed(VK_F8)) Global::fTimeSpeed = 100.0;
  if (Console::Pressed(VK_CONTROL) && Console::Pressed(VK_F9)) Global::fTimeSpeed = 1.0;

  if ((Console::Pressed(VK_CONTROL)) && (Console::Pressed(VkKeyScan('='))) ) GlobalTime->UpdateMTableTime(60);    //Global::iViewMode=VK_F6;
  if ((Console::Pressed(VK_CONTROL)) && (Console::Pressed(VkKeyScan('-'))) ) GlobalTime->UpdateMTableTime(10);

albo jakiekolwiek inne jezeli te sa zajete z controlem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 24 Lutego 2017, 22:38:51
Podmienilem skale dla istniejacych klawiszy, prosciej bedzie :)

w debug mode:
f6: standardowa skala uplywu czasu
shift+f6: 1 min = 5 min
ctrl+f6: 1 min = 20 min
shift+ctrl+f6: 1 min = 1 godz.

shift + f1: przesuniecie zegara o 5 min
ctrl + f1: przesuniecie zegara o 20 min
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 25 Lutego 2017, 09:40:33
Godzina 12 w południe. Przy movelight 0 niezwykle nienaturalnie.

Kolejny przy movelight 150.

Jakie parametry atmo stosować najlepiej?

Eksperymentalnie uzylem na tym exe skydynamicstratus od ra i ciekaw jestem czemu nie widać chmur? I czemu niebo jest przypisane na stale? Nie można go zmienić starterem. Ponadto w nocy brak smugi, tzn jest ale jak w kolejce TT to nie do przyjecia.  Egipskie ciemności (ustawienie na marzec godz 19:30).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 25 Lutego 2017, 10:59:12
Renderowanie chmur wylaczono. @tmj napisal o tym, stad nie dziala zmiana w starterze a niebo jest stale. Zmiana jest tymczasowa. O smudze i swiatla h napisalem wczesniej. Prosilem o powrot do wersji wlaczanej na 3 razy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 25 Lutego 2017, 14:02:14
Cytuj
Renderowanie chmur wylaczono.

Ciekaw jestem dlaczego. Przy okazji w dynamicsky macie księżyc. I on dzialal. TMJ koniecznie odblokuj mozliwosc zmiany nieba i to co wprowadzil ra.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 25 Lutego 2017, 14:06:24
Panowie, spokojnie. Wyłączył by łatwiej nam było testować gradient tła bez zabawy we wpisy. Ra wprowadził błędny algorytm ruchu słońca i gwiazdy. Gwiazdy są, algorytm poprawił.
A jak jesteśmy przy Ra, to ma on uwagę do prac nad niebem. W ciągu dnia, po świcie, jasność powinna być stała. Ludzkie oko i aparaty fotograficzne normalizują obraz na podstawie naświetlenia.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 25 Lutego 2017, 15:27:16
Jasnosc tak, ale temperatura barwowa juz nie. Oko ma wlasciwosci akomodacyjne, uklady pomiarowe w aparatach, nie. Jak to wziac pod uwage nie wiem, w przypadku fotografii stosowalo sie filtry korekcyjne w zaleznosci od temperatury barwowej bo materialy swiatloczule nie maja na nia tolerancji. W dobie cyfrowek tego problemu nie ma, bo mamy mozliwosc dodtosowania recznego lub automatem.  Ta temperatura wazna jest z punktu widzenia odbioru jasnosci swiatla, oko ludzkie nie jest tak samo czule w calym zakresie barw, stad rozne doznania przed i po poludniu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Lutego 2017, 16:01:11
Godzina 12 w południe. Przy movelight 0 niezwykle nienaturalnie.
Niestety model nie jest idealny, i przy ustawieniach slonca na sredniej wysokosci (ktore przy ustawieniu 0 czyli dniu biezacym jest jak najbardziej naturalne: http://www.edukator.pl/zmianamiejscwschoduizachodusoca,2987.html ) wchodzi tam zbyt duzo czerwieni itp. Byc moze da sie to ewentualnie skorygowac, zobaczymy.

dynamicsky jest chwilowo wylaczony, bo oprocz dynamicznego ksiezyca ma tez dynamiczne slonce, ktore wedruje sobie sciezka zupelnie inna od 'prawdziwego' slonca (podobnie zreszta jak i dynamiczny ksiezyc) Po ogarnieciu tego wlacze z powrotem, dlugo to nie potrwa.

A jak jesteśmy przy Ra, to ma on uwagę do prac nad niebem. W ciągu dnia, po świcie, jasność powinna być stała. Ludzkie oko i aparaty fotograficzne normalizują obraz na podstawie naświetlenia.
Tutaj bym sie spieral, bo golym okiem widac roznice w sile oswietlenia tych samych obiektow w zimie i lecie, przy czystym niebie i przy niebie zachmurzonym, a roznica jest tu wlasnie ilosc dochodzacego do Ziemi swiatla. Owszem, oko sie w jakichs tam granicach dostosowuje, ale chyba jednak nie tak, ze caly czas widzimy obiekty tak samo.

A teraz z innej beczki. Jako ze smuga jaka jest, kazdy widzi (a raczej, ze jej nie widac) mamy dzisiaj eksperymentalnie wprowadzone zamiast niej rzeczywiste zrodla swiatla. Od razu uprzedzam ze szczegolnego szalu nie ma -- 'klasyczne' swiatla openGL dzialaja w oparciu o oswietlenie wierzcholkow, wiec o ile efekt jest ok na torach i otoczeniu (a i tutaj trzeba bylo wprowadzic podzial odcinkow prostych na wiecej niz jeden segment) to takie elementy jak siatka terenu czy np. perony doswietlaja sie srednio, jesli w ogole.

Ponadto implementacja jest 'na szybko' czyli taka ze od kodu zeby bola. W tym momencie swiatla przypisane sa na sztywno do modelu prowadzonego. Bardziej prawidlowa bylaby/bedzie tabela wszystkich pojazdow w scenerii razem z "wirtualnym" stanem ich oswietlenia, i przydzielaniem kilku swiatel 'rzeczywistych' do najbardziej stosownych celow na podstawie polozenia kamery itp. No i docelowo kalkulacja oswietlenia z dokladnoscia per pixel, ale to juz po przestawieniu na silnik obslugujacy shadery itp.

Sila swiatel dobrana jest "na oko" wiec jesli jest zbyt jasno/ciemno/cos tam to prosze krzyczec.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 25 Lutego 2017, 16:15:53
Odpaliłem się na Quarku i oświetla teren całkiem ładnie. A że cały trójkąt, to z kabiny zbytnio nie widać, gorzej na zewnątrz. Wywaliło mnie jednak jeszcze przed odjazdem.

Dobra, wyglądało znośnie póki nie ruszyłem tego źródła światła. Nope, vertex shader to nie jest dobra droga, nawet przy absurdalnej teselacji.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 25 Lutego 2017, 16:24:21
Nie żebym marudził, ale IMO dorzucanie teraz kolejnych funkcji ze starego opengl to strata czasu, lepiej wykorzystać go do przejścia na shadery.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Lutego 2017, 16:50:26
Akurat w tym wypadku specjalnie to nie przeszkadza imo, bo to niejako efekt uboczny przy rozlaczaniu .exe i istniejacego kodu renderera. a i po przejsciu na shadery symulator jakies pojecie gdzie sa aktualnie swiatla do renderowania musi miec, shader sam sobie tego nie urodzi. Wiec to tak troche na przyszlosc, troche na teraz.

@Stele, wysypalo sie przy skanowaniu trasy, ale samo mi to za wiele nie powie, bo trudno powiedziec konkretnie na czym. Gdzie to bylo, i czy jest powtarzalne, czy jednorazowo tak?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 25 Lutego 2017, 17:04:08
Nie żebym marudził, ale IMO dorzucanie teraz kolejnych funkcji ze starego opengl to strata czasu, lepiej wykorzystać go do przejścia na shadery.
Nie wiem czy dobrze zrozumialem, ale jesli akurat chodzi o swiatla lokomotyw, to powinny byc przynajmniej takie na moment budowy nowego exe, aby cokolwiek bylo widac w ciemnosciach. Po ciemku testy sensu maja malo a moze wcale. Nawet jesli jet to opengl. No chyba, ze ktos jest w stanie wprowadzic shadery, to chetne potestuje.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 25 Lutego 2017, 18:32:15
@Stele, wysypalo sie przy skanowaniu trasy, ale samo mi to za wiele nie powie, bo trudno powiedziec konkretnie na czym. Gdzie to bylo, i czy jest powtarzalne, czy jednorazowo tak?
Koniewice en57, skanowanie do W4. No ale nie wiadomo który skład wtedy leciał, nie? Odpaliłem się ponownie na składzie obok co miał szybciej wyjazd i przez kilka minut nic nie wysypało, wiec raczej losowe.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 25 Lutego 2017, 19:38:11
To są najlepsze światła jakie mieliśmy w exe. Wiem, mają wady, ale jak je usuniesz, to ja nie chce innych. Druga sprawa, że te światła ma tylko skład obsadzony przez nas, mijające nas składy nie prezentują takich żarówek. Nie chodzi o narzekanie, stwierdzam tylko fakt i miło by było dostać w temacie jakieś info. Załączam tym razem linki do plików PNG z prezentacją oświetlenia dla osób nie testujących nowości exe. Linki, ponieważ po zmianie warunków dodawania załączników obrazki mają po 1,5mb wagi, szkoda.
http://eu07.pl/userfiles/1234/foto-zarowki_1.PNG (http://eu07.pl/userfiles/1234/foto-zarowki_1.PNG)
http://eu07.pl/userfiles/1234/foto-zarowki1.PNG (http://eu07.pl/userfiles/1234/foto-zarowki1.PNG)
http://eu07.pl/userfiles/1234/foto-zarowki2.PNG (http://eu07.pl/userfiles/1234/foto-zarowki2.PNG)
http://eu07.pl/userfiles/1234/foto-zarowki3.PNG (http://eu07.pl/userfiles/1234/foto-zarowki3.PNG)
http://eu07.pl/userfiles/1234/foto-zarowki4.PNG (http://eu07.pl/userfiles/1234/foto-zarowki4.PNG)
http://eu07.pl/userfiles/1234/foto-zarowki5.PNG (http://eu07.pl/userfiles/1234/foto-zarowki5.PNG)
@tmj, postarałeś się.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Lutego 2017, 19:44:15
Druga sprawa, że te światła ma tylko skład obsadzony przez nas, mijające nas składy nie prezentują takich żarówek. Nie chodzi o narzekanie, stwierdzam tylko fakt i miło by było dostać w temacie jakieś info.
Tak jak pisalem oryginalnie, ta implementacja jest "na tu i teraz" zeby cos w ogole bylo widac ;)  Na dluzsza mete .exe bedzie mialo podreczna liste wszystkich kandydatow w scenariuszu, i dostepne swiatla beda "przydzielane" na podstawie stopnia oswietlenia pojazdow i odleglosci od kamery.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 25 Lutego 2017, 19:48:28
Czy coś podobnego można zrobić dla ulicznych latarni? Tekstury przy poziomie gruntu fatalnie wygladają i migoczą. Jeszcze pytanko, nie mogę wrócić pod F1 do opisu stanu pojazdu, (pozycja nastawnika, hamulca, ciśnienia...). Widać tylko docelową stację z godziną odjazdu. Tryb debug mode. Robiłeś tu jakąś zmianę?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Lutego 2017, 20:03:05
Latarnie raczej dlugo jeszcze nie, jest ich po prostu zbyt duzo, tutaj nawet samo przejscie na shadery nie zalatwi sprawy (potrzebny bylby najprawdopodobniej deferred renderer, bo inaczej sie komputer zes... tresuje liczac oswietlenie wszystkich punktow)

F1 prawdopodobnie sie popsul gdy dopisywalem przyspieszenie czasu pod F3 itd, sprawdze. Tak przy okazji, to troche inaczej dziala tez tryb wireframe pod F7, obejmuje teraz w zasadzie wszystko.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 25 Lutego 2017, 20:10:17
Tryb wireframe pod F7 jest świetny:) Natomiast pod [shift]+[F1] zmienia mi się czas, każde wciśnięcie posuwa o 5 minut. Zestresowaniem komputera nie jestem zainteresowany, chwilowo musi być jeszcze ten co mam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 25 Lutego 2017, 20:12:07
Latarnie są statyczne, wiec znośnie by wyglądały jakby obecnego plane trochę podnieść i traktować jako mapę światła. No dopóki coś by nie wlazło w snop światła.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Lutego 2017, 20:51:53
Natomiast pod [shift]+[F1] zmienia mi się czas, każde wciśnięcie posuwa o 5 minut.
Tak, Q chcial miec przyspieszenie czasu na poprzedniej stronie, wiec podpialem jako dodatkowe funkcje pod F1 bo tam jest zazwyczaj zegar, wydawalo sie w miare logiczne :)  Przelacznik na wyswietlanie parametrow na zmiane z czasem sie znalazl/naprawil, bedzie w nastepnym uaktualnieniu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 26 Lutego 2017, 06:18:42
Światła wyglądają faktycznie najlepiej, tylko 1 problem - oświetlenie obiektów, zwłaszcza terenu zmienia się skokowo od zdecydowanie zbyt ciemnego, do właściwego.
I zauważyłem dziwne zachowanie, jak jechałem ED72 zapalanie świateł zarówno w kabinie, jak i zewnętrznych reflektorów było możliwe przy opuszczonych patykach i wyłączonej baterii.
Aha, jeszcze jedno - coś chyba nie tak jest z wykolejaniem. Tak dla jaj za Jarkawkami rozbujałem się SN61 do 100km/h po ograniczeniach do 20, fajnie bo miotało pudłem jak szatan, ale wykoleić się nie chciał. No w końcu, na bardzo ostrym łuku coś tam się zrobiło, ale brakowało huku, po prostu jakiś taki dźwięk hamowania, zatrzymanie nie było bardzo nagłe, ruszyć się już nie dało, pod F2 "Damage status: OK", nie powinno być derailed? Aż sprawdzałem czy się da ruszyć, ale nie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 26 Lutego 2017, 08:06:16
Przeciez bylo napisane, ze oswietlane sa cale trojkaty, stad ta skokowa zmiana jasnosci. Nie jest to docelowe oswietlenie, prace sie nie zakonczyly. Co do reszty, potwierdze jak sam sprawdze.
ED:
Załącznik, mechanizm wykolejenia działa. Można zapytać czy prawidłową czułość ma, ale tu trzeba wielokrotnych powtórzeń i porównań ze starym exe. Nie można się wykoleić w trybie debug mode, ale tak było od zawsze i tak miało być. Nie potwierdzam możliwości włączenia lamp bez baterii w siódemce. Inne pojazdy do sprawdzenia.
ED2:
Załącznik 2 pokazuje włączenie smugi mimo braku załączenia baterii. Lampy są ciemne, te włączyć można tylko po włączeniu baterii. Należy smugę uzależnić od baterii.
ED3:
Jeszcze jedno derailed na ED72. Co do SN61 i Całkowa, całkiem możliwe, że tam nie ma wpisanych potrzebnych informacji do wykolejenia.

PS: Przy 1080*1920 nie można zrobić bardziej skompresowanego załącznika, aby coś jeszcze było widać z napisami. Celowe jest zwiększenie załącznika do 300kib.

@HTD, nie napisałeś w jakim trybie (debug mode, czy zwykły) jeździłeś. Nie podałeś na jakiej scenerii, ciężko potem potwierdzać lub zaprzeczać komunikatom. Podawanie warunków wystąpienia niepożądanych efektów zaoszczędza innym pracy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 26 Lutego 2017, 11:39:03
Przepraszam. Jechałem w trybie normalnym, na Zwierzyńcu, ED72, rano (wersja którą dawałem do testów). Nie próbowałem go wykolejać, przejechałem do końca, bo na starym exe ten scenariusz kończył się dokładnie jak zaczynało się robić jasno, chciałem porównać światło. Ogólnie jest dużo ciemniej (miałem problem w orientacji przy zapalonej tylko prawej lampie), ale trudno ocenić czy ogólna jasność jest prawidłowa, bo te trójkąty migają jak szalone, przez chwilę jest idealnie, za chwilę jest źle.

To, że oświetlenie jest dla całych trójkątów to wiem bo to widać. I tak wygląda 100x lepiej niż wszystko co było wcześniej. To jednak nie tłumaczy dlaczego ten sam trójkąt nagle robi się dużo jaśniejszy, i gwałtownie gaśnie. Wg mnie prawidłowy algorytm powinien uzależniać oświetlenie danego trójkąta od odległości od lampy - ta zmienia się płynnie. Tymczasem oświetlenie trójkątów zmienia się skokowo. Zgaduję, że do obliczeń brany jest nie ten trójkąt, tylko jakiś inny, który znajduje się za czołem składu. Skąd zgaduję? Zbliżam się do peronu, cały peron jest prawidłowo oświetlony. Nagle peron gaśnie, chociaż nie zdążyłem nawet minąć czołem składu jego początku. Nie narzekam, po prostu opisuję jak to się zachowuje w tej wersji.

Potem testowałem scenariusz Całkowo SN61, tryb normalny, tego wykolejałem, ale wykolejenie nie dało opisu "derailed" i w zasadzie nie było widać że skład był wykolejony. Po prostu dość szybko nagle zahamował i nie dało się ruszyć, po tym poznałem, że jednak się wykoleił.

Przy okazji dla SN-a testowałem też hamulec pomocniczy - nadal nie działa, ale z tego co wiem to nie było jeszcze poprawiane. Zrobiłem kilka screenów z jazd, ale nie wnoszą nic nowego do tematu więc nie wklejam.

Ciekawostka: ostre zahamowanie przechyla kamerę w pionie - bardzo fajny efekt, jakby się mechanik bujnął w fotelu ;) Niestety ten sam efekt występuje przy odhamowaniu kiedy skład się nie porusza, ani nie zaczyna się poruszać po odhamowaniu. OK, po odhamowaniu lokomotywa może się przemieścić względem składu nieznacznie i to powinno być odczuwalne w kabinie, mam jednak wrażenie, że tylko w przypadku używania hamulca pomocniczego, w przypadku zespolonego ten efekt powinien być pomijalny, zwłaszcza podczas odhamowania na postoju.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 26 Lutego 2017, 11:51:06
Nie sądzę, aby przy tej skali zmian w exe jaka mamy, można było od ręki poprawiać zjawiska fizyczne występujące w symulatorze. Sprawdził bym wykolejenie SN61 na normalnym "exe", wydaje mi się, że tam nie działało derailed. Co do świateł, nie miałem takich odczuć jak Ty, jadąc na Kaliskiej znikanie oświetlonych trójkątów jest strawne. Być może zależne jest to od wielkości trójkąta użytego do budowy terenu. Pamiętajmy, że to dopiero propozycja świateł.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 26 Lutego 2017, 11:59:21
Obecnie to się oblicza nie tyle co dla trójkątów, tylko dla wierzchołków. Jeżeli peron składa się z dwóch trójkątów, to świecenie na środku nie da nic, bo obliczenia robią się tylko na wierzchołkach a później są tylko interpolowane na resztę.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Lutego 2017, 12:14:32
To jednak nie tłumaczy dlaczego ten sam trójkąt nagle robi się dużo jaśniejszy, i gwałtownie gaśnie.
To dlatego, ze tak jak napisal Milek oswietlenie jest kalkulowane na podstawie wierzcholkow -- wystarczy, ze jeden wierzcholek nie jest oswietlony, i nastepuje interpolacja od 'oswietlony' do 'ciemny' na calej powierzchni, a przy duzych trojkatach (a z takich zazwyczaj sklada sie teren i np proste perony) ma to miejsce bardzo czesto.

edit: co do ruchu kamery, ten jest robiony na podstawie obliczanego przez symulator przyspieszenia, a po odhamowaniu gdy sklad zaczyna ruszac to przyspieszenie jest kalkulowane jako dosc wysokie, ze wzgledu na zmiane predkosci z 0 do jakiejs tam, niewazne jak malej. Tu by sie musial fizyk pochylic :d
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 26 Lutego 2017, 12:55:50
Czy w ostatniej kompilacji jest poprawka na dwuliterowe nazwy? Zgłaszane przez Macieja.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Lutego 2017, 13:03:00
Jeszcze nie, ale blad dotyczyl tylko ladowania .t3d, wiec jesli ladujesz pliki .e3d to sie nie objawia.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 26 Lutego 2017, 13:41:05
Światła wyglądają faktycznie najlepiej, tylko 1 problem - oświetlenie obiektów, zwłaszcza terenu zmienia się skokowo od zdecydowanie zbyt ciemnego, do właściwego.
I zauważyłem dziwne zachowanie, jak jechałem ED72 zapalanie świateł zarówno w kabinie, jak i zewnętrznych reflektorów było możliwe przy opuszczonych patykach i wyłączonej baterii.
Aha, jeszcze jedno - coś chyba nie tak jest z wykolejaniem. Tak dla jaj za Jarkawkami rozbujałem się SN61 do 100km/h po ograniczeniach do 20, fajnie bo miotało pudłem jak szatan, ale wykoleić się nie chciał. No w końcu, na bardzo ostrym łuku coś tam się zrobiło, ale brakowało huku, po prostu jakiś taki dźwięk hamowania, zatrzymanie nie było bardzo nagłe, ruszyć się już nie dało, pod F2 "Damage status: OK", nie powinno być derailed? Aż sprawdzałem czy się da ruszyć, ale nie.
Te Oswietlaenie czola pociagu jest na standardowych OpenGLowych swiatlach, domyslam sie bo nie oswietla terenu z powodu braku odpowiedniej teselacji. Natomiast jezeli chodzi o ladne rozchodzenie sie swiatla na geometrii toru, to domyslam sie ze zwiekszyliscie segmentacje odcinkow i to pewnie jest powodem wykolejen w pewnych przypadkach. Az sie zaraz pochwale tym co od kilku dni mam gotowe. Problemy z wykolejaniem tez mialem ale wystarczylo pewna rzecz zmienic i jest dobrze. Ja do wprowadzenia tych spotlightow (zrobilem se wszystkie trzy) ustawilem segmentacje torow na 2m i nie zauwazylem duzego spadku FPS (na 053 jest ok na duzej stacji). Sie zastanawiam... Nagrac film czy tylko screenyy...
EDIT:
Filmik poproszę //Sawi

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Lutego 2017, 16:40:52
Segmentacja nie powinna chyba wplywac na wykolejenia, bo jest tylko na poziomie generowania dodatkowych trojkatow dla wizualizacji (no i zmiana dotyczy odcinkow prostych, gdzie o wykolejenie trudno :)  Natomiast glowy nie dam ze wszystko jest w porzadku z sama procedura wykolejenie i/lub wyswietlanym stanem uszkodzen, bo nie zagladalem tam za bardzo.

W dzisiejszym uaktualnieniu w zasadzie tylko maintenance mode

- zmieniony nieco model kolorowania nieba, zolcie, roze itp pojawiaja sie dopiero gdy slonce zejdzie dostatecznie nisko, w ciagu dnia sa w zasadzie tylko biel/blekit, czyli bardziej jak w naturze

- wlaczona z powrotem obsluga chmur. Tutaj zwracam uwage, ze uzywany zazwyczaj sky_dynamic_stratus.t3d ma dodatkowe element jak slonce, ksiezyc i gwiazdy, ktore gryza sie wizualnie z tym co jest rysowane obecnie. Do .exe dolaczony jest model alternatywny, skydome_clouds.t3d ktory jest w duzym skrocie wersja sky_dynamic_stratus.t3d z wycietymi elementami dodatkowymi (czyli zostaja same chmury, a gwiazdy itp .exe i tak wyswietla/bedzie wyswietlac kiedy trzeba) Dodatkowo na kolor chmur (przynajmniej tych dynamic) ma tez wplyw biezace oswietlenie nieba, czyli nie wyglada to dokladnie tak samo jak przedtem, ale tez odrobine bardziej jak powinno, zwlaszcza w nocy

- dolaczone zmiany Macka001 dla MWD

- poprawki znalezionych bledow (niewyswietlanie niektorych sub-modeli przy ladowaniu .t3d, swiatla dzialajace bez wlaczonej baterii, moze cos tam jeszcze, czego nie pamietam
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 26 Lutego 2017, 17:37:01
Mozliwosc przyciemnienia dodawales? Czy odpusciles temat?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Lutego 2017, 18:02:15
Przyciemnienia swiatel? Nie, siedzi sobie w kolejce rzeczy do zrobienia, zrobi sie jak bedzie funkcjonujacy przelacznik w kabinach, i sensowny klawisz zeby to podpiac. W kodzie znalazlem
    TGauge ggUpperLightButton;
    TGauge ggLeftLightButton;
    TGauge ggRightLightButton;
    TGauge ggLeftEndLightButton;
    TGauge ggRightEndLightButton;
    TGauge ggLightsButton; // przelacznik reflektorow (wszystkich)
    // hunter-230112: przelacznik swiatel tylnich
    TGauge ggRearUpperLightButton;
    TGauge ggRearLeftLightButton;
    TGauge ggRearRightLightButton;
    TGauge ggRearLeftEndLightButton;
    TGauge ggRearRightEndLightButton;
    TGauge ggCabLightButton; // hunter-091012: przelacznik oswietlania kabiny
    TGauge ggCabLightDimButton; // hunter-091012: przelacznik przyciemnienia
ale do przyciemniania swiatel zewnetrznych nic nie ma. Chyba ze ggLightsButton (lights_sw) ma to miec, ale on jest chyba uzywany do wyboru kombinacji stanu swiatel.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 26 Lutego 2017, 18:04:35
Moze ja sie wypowiem na temat przyciemnienia prezetujac pseudokod.


 float dimf = 0;
  float a = 0;

  if (dimheadlights) dimf = 0.4f;

  if (k==1) SL->setlADS(0.9-dimf, 0.8-dimf, 0.7-dimf, 1.0,      0.7, 0.6, 0.7, 1.0,      0.7, 0.7, 0.7, 1.0);
  if (k==2) SL->setlADS(0.9-dimf, 0.8-dimf, 0.7-dimf, 1.0,      0.7, 0.6, 0.7, 1.0,      0.9, 0.8, 0.9, 1.0);

  if (Console::Pressed(VK_CONTROL) && (cKey == 'D')) dimheadlights = !dimheadlights;      // w OnKeyDown();


Jak widac tyle zejmuje dodanie tej opcji, nie uwzgledniajac dodania obslugi hebelka bo chyba nie ma ztcp.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Lutego 2017, 18:34:36
No wlasnie o obsluge kontrolki sie rozchodzi :)  bo dodac klawisz i wspolczynnik dla sily swiatla to nie problem, ale wtedy na 100% wyskoczy sytuacja ze ktos wcisnie kombinacje, nawet nie zauwazy, ale bedzie problem ze swiatla nagle nie dosc jasne i nie wiadomo czemu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 26 Lutego 2017, 18:55:22
Wciskania klawiszy jakbym miał dość. Nie myślałem, że kiedyś to napiszę, ale takie bajery to może zostawić wskaźnikowi myszki i prawdziwej obsłudze przełączników.
Nadal pod F1 (debug mode) nie mam parametrów pozycji nastawnika, bocznikowania i ciśnień w PG, ZG i CH, zrozumiałe że nie widać napięcia w sieci i poboru prądu. Pozycja mechanika blokowana jest w czasie jazdy AI (po wciśnięciu shift+Q), światłą nie są 3 stopniowe, po prostu pojawiają się po wciśnięciu kolejnego klawisza. Trudniej było mi przejąć inny pojazd w biegu pod F5. Księżyc jest zarąbisty. Wciśnięcie alt+Q powoduje zapytanie o wyjście z symulacji. Tyle na gorąco.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 26 Lutego 2017, 19:12:14
Wciskania klawiszy jakbym miał dość. Nie myślałem, że kiedyś to napiszę, ale takie bajery to może zostawić wskaźnikowi myszki i prawdziwej obsłudze przełączników.
Jeśli mogę zaproponować, to [Shift] + [Ctrl] + [L] załączenie przyciemnienia i [Ctrl] + [L] wyłączenie przyciemnienia. "L" to w wielu grach światła (gdyby ktoś szukał skrótu po przypadkowym załączeniu przyciemnienia), do tego na klawiaturze jest obok oświetlenia i przyciemnienia oświetlenia kabiny oraz oświetlenia przyrządów, a przyda się osobom z pulpitami. Jedynie jeszcze do Readme doda się odpowiedni wpis. Poza tym świetne to oświetlenie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 26 Lutego 2017, 19:20:01
Build GLFW z zapisywaniem E3D niezależnym od układu obiektu w pamięci:
x32: https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng32-bd9cd6f7.zip
x64: https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng64-bd9cd6f7.zip
Teraz wreszcie można się zabrać za przerabianie dźwięku.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: joey w 26 Lutego 2017, 19:25:21
Ponawiam zgloszenie o niehamujacych przed przejazdami samochodach. Zglebiajac sie w szczegoly: dotyczy to pojazdow arosa, golf, ka, nie wiem jak innych; przed przejazdem samochod taki zaczyna hamowac, blokuja sie mu kola i na poslizgu przejezdza przez szlabany, po czym kontynuuje normalna jazde
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Lutego 2017, 19:47:02
Nadal pod F1 (debug mode) nie mam parametrów pozycji nastawnika, bocznikowania i ciśnień w PG, ZG i CH, zrozumiałe że nie widać napięcia w sieci i poboru prądu.
Sprawdz jesli mozesz, czy faktycznie bylo to F1 nacisniety w debug mode, a nie w trybie zwyklym. Sprawdzajac u mnie, wyglada ze to dziala -- screen w zalaczniku, parametry podane sa tak jak byly zawsze, nic tam nie zmienialem.

Cytuj
światłą nie są 3 stopniowe, po prostu pojawiają się po wciśnięciu kolejnego klawisza.
Swiatla sa nadal 3-stopniowe, ale nalezy zwrocic uwage, ze przelaczniki swiatel mozna ustawic przy wylaczonej baterii. Czyli mozesz wlaczyc np swiatlo lewe i prawe i dopoki bateria jest nie zalaczona nie pojawi sie nic, a po wlaczeniu baterii aktywuja sie oba swiatla naraz. Natomiast jesli wlaczysz baterie najpierw, a nastepnie przelaczniki swiatel jeden po drugim, to swiatla powinny pojawic sie 3-stopniowo.

(piractwo drogowe zapewne ma cos wspolnego z zawartoscia plikow .fiz, ktos musialbys sprawdzic, czy sa tam jakies zauwazalne roznice w porownaniu do samochodow hamujacych poprawnie)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 26 Lutego 2017, 20:17:45
Może współczynnik mbf/masa. Blokują koła, a że lekkie są, to suną jak sanki. Już dawno miałem zrobić tor testowy dla samochodów i nadal nie mam nic. :(
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 26 Lutego 2017, 20:33:07
Znalazły się napisy pod F1, sorki, jakoś się źle musiało uruchomić. ;) (Kropka przed emotikonem wygląda okropnie.)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 26 Lutego 2017, 21:15:24
@Milek, jezeli chodzi o GLFW to rozumie ze na razie zrobiles tylko inicjalizacje na jego funkcjach, jako tako w kodzie reszty jescze nie pozamieinales?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 26 Lutego 2017, 21:16:55
No tworzenie okienek, kontekstu opengl i sterowanie jest przeniesione.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 26 Lutego 2017, 21:29:26
Czyli praktycznie od teraz juz jest mozliwosc wdrazania nieskonczonej ilosci ficzerow opartych na shaderach i ogolnie na nowych technologiach, ktore dostepne sa w tutkach na internetach :).
Super, dobra robota men :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 26 Lutego 2017, 21:33:19
Brawo. Teraz wrzućcie wszystko na mastera by było w jednym branchu i z czystym sumieniem devsa przyznam. :)

@tmj, bardzo podoba mi się nowy wireframe. Idealny do testów modeli dla ludzi bez maxa.
Jeden reflektor ledwo co daje, trzy mam wrażenie oświetlają skyboxa nawet, a na pewno las kilkaset metrów przed lokiem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 26 Lutego 2017, 21:48:02
Milek7, Twoja kompilacje odpale jutro, dzis nie dam juz rady a szkoda, bo zapowiada sie apetycznie. Powinienem skonczyc tez z XP bo ledwo dyszy. 
Tmj, w Twojej kompilacji lacznie ze swiatelkami jest ok. Musialo mnie przymulic przy pierwszym otwarciu. To co, za miesiac mamy nowe exe? No moze dwa. ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 26 Lutego 2017, 22:04:41
@tmj: coś się zepsuło przy mergowaniu, czy te światła zapomniałeś wrzucić na githuba?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Lutego 2017, 22:33:50
Jeszcze nie wrzucilem, bo ogarniam najpierw zeby swiecilo cos wiecej niz tylko prowadzony pojazd, chwile to zajmie :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 26 Lutego 2017, 22:51:01
Witam, takie coś mi się pojawia podczas uruchomienia. Mógłby mi ktoś powiedzieć co jest nie tak? Zauważyłem, że jeśli podmienię pliki na te od Milka w sensie pliki .dll to nie odpala wcale .exe 170226.

Edit. Natomiast jeśli pobiorę glew32.dll do którego link jest w pierwszym poście, to exe wyrzuca błąd jeszcze przed uruchomieniem konsoli i wyskakuje, że aplikacja nie może zostać uruchomiona.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 26 Lutego 2017, 23:02:02
A moje exe odpala? Dllek nie mieszać bo chyba jest inna wersja glew.

Kończy się miejsce na partycji, i tak sobie pomyślałem, co wy na zastosowanie kompresji do .e3d i .dds? Skompresowane zlibem dds zajmują prawie 3x mniej, a e3d nawet 5x. Na pewno sporo się zyska na wielkości paczki, a szybkość wczytywania to będzie zależeć od szybkości dekompresji i dysku, ale myślę że możliwe będzie żeby było szybciej, szczególnie na talerzowych.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 26 Lutego 2017, 23:13:05
I tak wszystko ładuje na starcie, wiec nie ma przeciwwskazań. Ale chciałbym mieć exeka na masterze z dopieszczonymi wszystkimi ficzerami co są i dodanym nowym skanowaniem od Firleja. Trzeba by na wiosnę paczkę wydać, a ten vertex shader średnio się dla ludzi nadaje niestety.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 26 Lutego 2017, 23:13:51
Problem rozwiązany, usunąłem stare sky_stars.e3d
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 26 Lutego 2017, 23:21:25
Ja testuje na dwie paczki, nawet nie probowalem wrzucac do jednego worka. Co do kompresowania e3d i dds, nikt nie wpadl na ten pomysl wczesniej? Trzeba poszukac na forum czy byly takie plany. Moim zdaniem nie warto kpnmpresowac i robic problemy dodatkowym obciazeniem. Dyski sa tanie i nie ma co oszczedzac.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 27 Lutego 2017, 03:46:32
OK, w nowym uaktualnieniu mamy swiatla przydzielane dynamicznie do pojazdow na podstawie odleglosci do kamery i/lub ilosci zapalonych lamp. Ilosc obslugiwanych swiatel jest kontrolowana wpisem w .ini
dynamiclights ilosc
wartoscia domyslna jest 3 (bo z tego co pamietam starsze karty moga miec klopoty z obsluga wiecej niz 4 swiatel, a jedno swiatlo jest uzyte dla oswietlenia ogolnego). Co powinno wystarczyc dla prowadzonego pociagu i 1-2 mijanych skladow. Maksymalna wartoscia jest 7, bo 8 swiatel to wymagane specyfikacja minimum i wiekszosc sterownikow nie obsluguje wiecej. Sprawdzilem z ciekawosci calkowo_niebezpieczny_pociag z ustawieniem 7 swiatel i liczylo sie to spokojnie, ale nie znaczy, ze u kazdego tak bedzie.

aha, co do zasiegu swiatel, to sa one w tej chwili ustawione na szerokosc 20 stopni od osi i faktycznie dosc daleki zasieg, bo nie wiem jak to jest w lokomotywie, a po narzekaniach ze jest za ciemno uznalem ze bezpieczniej juz przesadzic w druga strone :d  Jesli ma ktos jakies prawdziwe dane jak to wyglada w naturze, to prosze mowic.

edit: nie sprawdzilem i wyszlo dopiero po publikacji, ale jest idiotyczne nieszczescie z kiblem, ktory w symulatorze po wlaczeniu swiatel w kabinie "wlacza" je sobie we wszyskich trzech segmentach, mimo tego ze dwa z nich nie maja zadnych swiatel zainstalowanych na tym koncu. gg. O ile sie orientuje to w .fix/.mmd nie ma zadnych wpisow czy swiatla w ogole istnieja, wiec rozplatac to bedzie raczej trudno. Podejrzewam ze to samo wystapi w lokomotywach dwuczlonowych :|
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: adamst w 27 Lutego 2017, 07:44:20
Proponowałbym uzależnić zapalanie świateł w pojeździe od obecności w nim maszynisty. To powinno w miarę sprawnie obejść problem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 27 Lutego 2017, 10:47:51
@Milek7, odpaliłem Twoje exe bez problemu. Zaliczyłem TD i jakąś misję na Bałtyku. Jedyne co znalazłem, to w kabinie A siódemki przezroczystość po zapaleniu lampki SHP. W kabinie B zapalenie lampki jest ok. Nie wiem czy efekt jest uboczny, ale jak używam alt+tab mogę przełączać okna i pisać w oknie notatnika lub czatu jednocześnie obserwując symulację. Mogę też robić screeny jak na załączniku 2. Niestety teraz w Twoim exe symulacja zwijana jest z ekranu. Musi tak zostać?
@tmj, efekty oświetleniowe super, nowy rozdział symulatora. Oczywiście w takim stanie pozostawiają niedosyt, ale kierunek jest właściwy. Moim zdaniem wiązka wygląda na szerszą niż 20 stopni. Jak powinna wyglądać nie mam pojęcia i czas pewnie wybrać się na szlak z aparatem po ciemku.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 27 Lutego 2017, 11:26:03
Jaka to dokładnie lokomotywa z tą przeźroczystością? E3D z paczki, czy T3D, czy wygenerowane E3D?

Z alt+tab mówisz o trybie pełnoekranowym, tak? Mogę sprawdzić czy wyłączenie GLFW_AUTO_ICONIFY to zmieni, ale właściwie to tak jest lepiej?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 27 Lutego 2017, 11:44:38
Paczka TGA, lokomotywa EP08-006. E3D musialo sie wygenerowac wczesniej, to nie bylo pierwsze uruchomienie tej scenerii. Z alt+tab w trybie pelnoekranowym. Tutaj wolalbym, aby nie zwijalo symulacji z ekranu. Przynajmniej w debug mode, jesli sie da. Jak pisalem, przy obserwacji symulacji byla mozliwosc otwarcia malego aktywnego okna, chocby czatu, jednoczesnie widzac co dzieje sie w tle. Ta EP08 moge jeszcze raz wygenerowac, jesli to sie przyda.
ED:
Na dzisiejszym exe od @tmj, nie mam tej przezroczystości. Spróbuję powtórzyć na Twoim.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Sawi w 27 Lutego 2017, 12:03:08
Jeśli nie było wprowadzanych żadnych zmian do modelu świni, to nie ma sensu od nowa generować tego pliku.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 27 Lutego 2017, 12:03:33
Już mam u siebie, zepsute jest na E3D. Zaraz to poprawię.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: maciek001 w 27 Lutego 2017, 12:22:49
Panowie będę miał prośbę. Możecie dodać przyciemnianie reflektorów? Na razie może być bez przycisku na klawiaturze - wystarczy sama metoda. Może wystarczy zdefiniowanie gdzieś jasności po przyciemnieniu i zrobienie Dim-a z boolem :) widzi się to komuś?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 27 Lutego 2017, 12:28:56
Jeśli nie było wprowadzanych żadnych zmian do modelu świni, to nie ma sensu od nowa generować tego pliku.
E3d były generowane innym starszym exe od tmj, stąd sprawdzenie powtórne na exe od Milek7. Natomiast chętnie poznam przyczynę dla której w kabinie B, było ok.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 27 Lutego 2017, 12:35:43
Też jest źle. Pewnie na A miałeś już wygenerowane i wczytało E3D, a na B wczytało się T3D i dopiero się generowało.

Coś jest namieszane z Opacity, bo w kodzie z tym "float Opacity; // nie używane, ale wczytywane" to w ogóle jakieś cuda na kiju są.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 27 Lutego 2017, 12:38:55
No i po wywaleniu starych e3d z katalogu EP08, wygenerowało się powtórnie i poprawnie na Twojej kompilacji. W sumie z mojej strony po temacie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 27 Lutego 2017, 12:43:32
Czekaj, jak poprawnie? Wychodzi mi że na T3D jest ok, a E3D źle, niezależnie od tego na czym było generowane. Pamiętaj że jak się generują e3d to użyte będą dopiero przy następnym uruchomieniu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 27 Lutego 2017, 13:26:55
Poprawiłem, wystarczyło usunąć kilka linijek. Ten bug był już wcześniej, tylko się nie ujawniał. Na próbę wyłączyłem auto iconify i zmergowałem to co tmj wrzucił na githuba.
32b: https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng32-e3df71c0.zip
64b: https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng64-e3df71c0.zip

@tmj: tak btw to brakuje notki licencyjnej MPL2 w niektórych plikach które dodałeś
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 27 Lutego 2017, 13:31:30
Proponowałbym uzależnić zapalanie świateł w pojeździe od obecności w nim maszynisty. To powinno w miarę sprawnie obejść problem.
Mniej wiecej na tym sie na dana chwile skonczylo -- dodalem test na pojazdy, ktora sa ustawione jako "AIdriver" ale bez przydzielonego kontrolera AI, I wyglada na to, ze dziala (takze dla ET41 i innych dziwnych kombinacji)  Caly problem wzial sie stad, ze pojazdy nie przechowuja zawsze wlasnego stanu swiatel, ale czasami sa konfigurowane by kopiowac stan czlonu prowadzacego. Czemu, przyrodzenie raczy wiedziec :x

edit:
@tmj: tak btw to brakuje notki licencyjnej MPL2 w niektórych plikach które dodałeś
Ja do takich glupot glowy nie mam :)  Cos sie chyba nie calkiem polaczylo, bo sprawdzajac na szybko to swiatla nie dzialaja w ogole.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: dymus w 27 Lutego 2017, 13:50:21
To dotyczy poprzednich exe c++, ale brakuje dźwięków falowników.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 27 Lutego 2017, 14:04:34
Zgubiłem init gfxrenderer :p
32b: https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng32-82109b03.zip
64b: https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng64-82109b03.zip
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: ST44-003 w 27 Lutego 2017, 14:13:37
Ja mam jedno pytanko, ale zaznaczam, nie testowałem tego drugi raz, więc może po poprawce się to zmieniło.
Wczoraj testowałem Bałtyk_IR na ET22. Od momentu załączenia symulacji aż do jej wyłączenia cały czas był słyszalny syk hamulca. Dźwięk luzowania hamulca, bardzo głośny z resztą. Powód mi jest nie znany.
Natomiast sprawdzając chwilę po tym skład fabrycznie wstawiony na TD tego problemu już nie było.

Chcę też zapytać, jak to jest z przejściem tego oświetlenia w inny rejon. Smuga nie przechodzi płynnie po drzewach, słupach czy terenie, tylko skacze, aczkolwiek poruszając się delikatnie płynnie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 27 Lutego 2017, 14:40:48
Chcę też zapytać, jak to jest z przejściem tego oświetlenia w inny rejon. Smuga nie przechodzi płynnie po drzewach, słupach czy terenie, tylko skacze, aczkolwiek poruszając się delikatnie płynnie.
Powodem tutaj jest stosowany model oswietlenia -- "stary" openGL oblicza sobie swiatlo dla wierzcholkow bryl umieszczonych w scenie, wiec rozklad i 'skoki' w oswietleniu zaleza glownie od tego ile tych wierzcholkow wystepuje w danym modelu. Roznice miedzy tym modelem, a bardziej dokladnym oswietleniem liczonym osobno dla kazdego piksela dosc dobrze widac na tym przykladzie:


Poniewaz duza czesc obiektow w symulatorze (drzewa, ploty, itp) opiera sie na maksymalnie uproszczonych plaszczyznach z 2-4 trojkatow na krzyz, zmiany jasnosci sa bardzo wyrazne. Raczej nie da sie tutaj nic zrobic do czasu odlaczenia/przebudowy silnika graficznego. Tzn mozna by sie bawic w reczny podzial bryl i inne takie, ale to raczej marnowanie czasu.

To dotyczy poprzednich exe c++, ale brakuje dźwięków falowników.
Jakbym wiedzial co to falownik i jak to powinno brzmiec, to byloby latwiej ;/ do syczenia w lokomotywach to specjalistow trzeba, niestety.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 27 Lutego 2017, 15:29:48
Czekaj, jak poprawnie? Wychodzi mi że na T3D jest ok, a E3D źle, niezależnie od tego na czym było generowane. Pamiętaj że jak się generują e3d to użyte będą dopiero przy następnym uruchomieniu.
Twoje exe uruchomiłem na paczce t3d/tga. Jednak plik e3d istniejący w katalogu z lokiem był wygenerowany jakiś czas temu przez inne exe. Zakładam, że przez którąś poprzednią z Twoich kompilacji. Ponieważ błąd z lampką pojawił się w jednej kabinie, uznałem, że wygeneruję jeszcze raz e3d, w tym celu usunąłem podejrzane pliki  i uruchomiłem jeszcze raz symulację. Tym razem, Twoje exe spreparowało poprawny plik e3d, czyli ustąpiła przezroczystość lampki. Mam nadzieję, że zrozumiale wytłumaczyłem, może za wcześnie podniosłem alarm. Jednak warto zwracać uwagę na takie rzeczy.
Wywalił mi się monitor, stąd długie poszukiwanie jakiegoś zamiennika i brak odpowiedzi z mojej strony.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 27 Lutego 2017, 15:40:37
Bug już poprawiony w ostatniej wersji, ale w kwestii wyjaśnienia: po skasowaniu e3d i uruchomieniu, wczytują się t3d i dopiero zapisują nowe e3d. Zostaną one użyte dopiero przy następnym uruchomieniu. Raczej więc niemożliwe żeby na tamtym buildzie załadowała się dobra przeźroczystość z e3d. Ale to już nieistotne.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 27 Lutego 2017, 15:58:17
Przyznam, że tego nie wiedziałem. Myślałem, że jeśli generuje przy uruchamianiu e3d, to są one używane do wyświetlania modeli.
Coś jednak zepsułeś, 3 uruchomienia, nie działa F1. Alt+tab kompletnie pomieszany, lepiej wrócić do tego co było, straciłem kontrolę co ma być na wierzchu w oknie.
ED:
Wygląda na to, jakbyś dawno nie używał windowsa, zostaw to może jak było. Kompilacja tmj przełącza się bardzo ładnie między oknami aplikacji. Choć jeszcze muszę sprawdzić tą po południową.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: dymus w 27 Lutego 2017, 16:48:04
Cytuj
Jakbym wiedzial co to falownik i jak to powinno brzmiec, to byloby latwiej ;/
Dźwięk z sekcji sounds, ventilator:  w pliku mmd ;) Ogólnie ventilator odpowiada za wentylatory oporów tam gdzie są opory rozruchowe, ale przy asynchronicznych u nas odpowiada to za dźwięk właśnie falownika.
A falownik reguluje napięcie i częstotliwość które jest podawane na silniki asynchroniczne.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: fuji8 w 27 Lutego 2017, 17:24:39
Zgłaszam że exe na radeonie nie hula, zamiast smugi, po prostu podświetla mi całą scenerię. Załączam tylko crashdumpa ponieważ loga wogóle nie chce mi zapisać.zrobiłem to inaczej i załączam także log.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 27 Lutego 2017, 17:36:06
Podrzuc jesli mozesz log, obojetnie z jakiej sceny, moze byc TD.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: ST44-003 w 27 Lutego 2017, 17:45:59
@tmj, rozumiem, że exe odczytuje datę z systemu i do niej dobiera wysokość słońca? Dałoby się może to przenieść do ręcznej zmiany daty i godziny? Tak jak to ma miejsce np. w OMSI? Jesteśmy na tą chwile uzależnieni od daty i godziny systemowej, a czasem chciałbym sobie sam dobrać godzinę do warunków na scenerii ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 27 Lutego 2017, 17:54:24
Przywróciłem auto iconify tak jak było i poprawiłem F1.
Ktoś robi dziwne konstrukcje rodzaju false == Console::Pressed( VK_CONTROL ) i przeoczyłem negację.

https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng32-5a8c158d.zip
https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng64-5a8c158d.zip
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 27 Lutego 2017, 18:19:28
@tmj, rozumiem, że exe odczytuje datę z systemu i do niej dobiera wysokość słońca? Dałoby się może to przenieść do ręcznej zmiany daty i godziny? Tak jak to ma miejsce np. w OMSI? Jesteśmy na tą chwile uzależnieni od daty i godziny systemowej, a czasem chciałbym sobie sam dobrać godzinę do warunków na scenerii ;)
Nie jestes uzalezniony, systemowa data jest pobierana przy ustawieniu dla scenerii parametru movelight 0 ale zamiast 0 mozesz podac liczbe od 1-365, ktora wymusi ustawienie na konkretny dzien roku :)  a godzina jest podobnie definiowana w scenariuszu. W debug mode mozesz uzyc shift+F1/ctrl+F1 zeby przesunac zegar o 5/20 minut naprzod, zeby latwiej znalezc dobrze wygladajacy czas.

edit:
Ktoś robi dziwne konstrukcje rodzaju false == Console::Pressed( VK_CONTROL ) i przeoczyłem negację.
Spedzisz dosc czasu wylapujac glupie bledy w stylu foo = false zamiast foo == false to tez bedziesz robil dziwne konstrukcje ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 27 Lutego 2017, 18:25:41
Milek7, sprawdziłem. Mam pod F1 co trzeba. Z tym przełączaniem aktywnych okien (alt+tab), skonsultuj z tmj.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 27 Lutego 2017, 18:33:17
Zgłaszam że exe na radeonie nie hula, zamiast smugi, po prostu podświetla mi całą scenerię. Załączam tylko crashdumpa ponieważ loga wogóle nie chce mi zapisać.zrobiłem to inaczej i załączam także log.
Z tego logu to wynika, ze tobie sie exe uruchamia nie na Radeonie, a na systemowej grafice Intela:
Renderer:
Intel(R) HD Graphics 4400
Vendor:
Intel
OpenGL Version:
4.3.0 - Build 10.18.14.4264
Czy Intel sobie poradzi to nie wiem (chociaz powinien), ale jak masz w systemie karte ATI, to warto moze wylaczyc w BIOS Intel Graphics czy jak to sie tam nazywa. Powinno byc jakies ustawienie, ze preferowana jest grafika na PCI Express, albo cos.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 27 Lutego 2017, 18:45:38
Jak to laptop to może trzeba po prostu w ustawieniach sterownika wybrać exe i wybrać kartę na której ma się uruchamiać.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: fuji8 w 27 Lutego 2017, 19:10:56
Dokładnie tak jak napisał @Miłek, wystarczyło przełączyć kartę graficzną, wszystko już działa. :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 27 Lutego 2017, 19:15:30
OK, glupie pytanie z innej beczki, dla specjalistow od hamulcow. W pliku .fiz dla 3e3-zez (wariant ET21) jest taki zapis:
BrakeValve=K
problem w tym, ze ten wariant nie jest praktycznie w ogole obslugiwany w kodzie, takze w wersji pascalowej. I w rezultacie hamulec lokomotywy nie dziala. Pytanie: czy mozna traktowac typ K tak samo jak typ W, biorac pod uwage ze w obu wypadkach w lokomotywie instalowany jest dokladnie ten sam obiekt hamulca (TWest)?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 27 Lutego 2017, 19:21:20
Póki co tak, może kiedyś doczekamy się oddzielnej implementacji dla zaworu K. Funkcjonalnie jest zbliżony do W, więc nie zakłamujemy rzeczywistości za bardzo :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 27 Lutego 2017, 19:50:03
Ta wersja et jak i mod4 maja oerlikona przynajmniej krany. A co znaczy to W?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 27 Lutego 2017, 19:53:16
Hamulec Westinghouse (https://en.wikipedia.org/wiki/Railway_air_brake#Westinghouse_air_brake) o ile dobrze czytam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: szogun w 27 Lutego 2017, 21:19:40
Manewrowo, wysyp przy ładowaniu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 27 Lutego 2017, 21:22:03
Kaliskiej od 19-stej nie mogę uruchomić. Wywala albo zaraz po wejściu do loka albo w momencie wcisniecia f5. Zdaza się tez ze mrugają mi chmury na tym nowym modelu nieba. A czasami nie mrugają.

http://eu07.pl/userfiles/212/priv-migajace-niebo.rar

Mam dość dobranoc.

Na tym exe nie da się nawet kaliskiej zacząć chyba ze jako wolny obserwator to może tak.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 27 Lutego 2017, 21:34:33
@EP, cos tam nie tak poszlo, pliki w tym archiwum maja wielkosc 0 bajtow. Na dysku u ciebie tez takie sa?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 27 Lutego 2017, 21:35:20
Mam wysyp na Quarku, paczka dds. W logu różne zapisy na końcu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: szogun w 27 Lutego 2017, 21:40:06
Światła - zajefajne jak mamy dwa reflektory zapalone, ale na trzech to chyba trochę zbyt wiele :D No i jak się wjedzie w światła innego pojazdu to oświetla kabinę.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 27 Lutego 2017, 21:50:32
Jeśli będą liczone piksele, nie wierzchołki trójkątów, to światła powinny być ok. Tam gdzie trójkąty nie są pobudzone do świecenie (nie ma ich), albo są zbyt małe aby to zauważyć, jest nieźle.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 27 Lutego 2017, 21:55:29
Manewrowo, wysyp przy ładowaniu.
Skopany jest plik "dynamic/db/rlmmp_v1/gray.dds" ma wewnetrznie wielkosc 0 i nawet Photoshop nie potrafi tego odczytac. Po nadpisaniu poprawna wersja uruchamia sie normalnie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: szogun w 27 Lutego 2017, 21:58:10
https://youtu.be/j0W0A6QVh5I
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 27 Lutego 2017, 22:08:19
@EP, cos tam nie tak poszlo, pliki w tym archiwum maja wielkosc 0 bajtow. Na dysku u ciebie tez takie sa?

Tak tez mam takie. Widocznie tak zrobilo. Nie ingerowalem w to.

Krzysiek troche ci zazdroszcze ze to exe nie sprawia ci tylu problemow co mi. A moze to exe nie lubi systemu x64? Sam niewiem. Na td jest ok nawet pyton sie laduje ale td jest mala scn. Na kaliskiej gdzie scn duzo wazy o zapewnia duze mozliwosci juz sa kwiatki i pyton na tym samym loku nie dziala. W jezdzie jako pasazer nie da sie klawiszami ani podniesc okna ani otworzyc drzwi przedzialu a proba zabawy oswietleniem skutkuje wysypem. Ogolnie poza ladnym niebem i naprawde kozackimi smugami to tp exe jest niezwykle niestabilne i nieprzewidywalne, krasze niewiadomo z czego. Chodz linie546 na tym exe zaliczylem. Ale kaliskiej gdzie w gre wchodza przrsiadki i zmiany kabin nawet nie wystartuje ze stacji na wlokniarzu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 27 Lutego 2017, 22:21:10
Tak tez mam takie. Widocznie tak zrobilo. Nie ingerowalem w to.
OK, ten jeden ktory jest sensownej dlugosci pokazuje, ze wylecialo na probie odegrania nieistniejacego dzwieku, po wywolaniu kombinacji Ctrl+Universal4. Czyli najprawdopodobniej jest bledny zapis w pliku .mmd, albo brakujacy plik .wav albo inna cholera. Ktoregos dnia trzeba bedzie to poprawic kod, zeby przestalo na slepo probowac odtwarzac cos, czego nie ma. A w miedzyczasie kierowac uwagi o niekompletnym contencie do jego tworcow ;s

Mam wysyp na Quarku, paczka dds. W logu różne zapisy na końcu.
Obawiam sie, ze Quark laduje sie u mnie bez wysypu ;/ ale ten komunikat to mi wyglada na jakis klopot z bibliotekami VC runtime. Sprobuj pobrac instalke z https://www.microsoft.com/en-us/download/details.aspx?id=40784 i zobacz, czy cos pomoze.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 27 Lutego 2017, 22:24:28
Ale log starego exe nie pokazuje braku dzwieku. Ani w loku ani w wagonie. Czyzby stare exe to olewalo?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 27 Lutego 2017, 22:30:43
Ale log starego exe nie pokazuje braku dzwieku. Ani w loku ani w wagonie. Czyzby stare exe to olewalo?
Nie mam zielonego pojecia, mozliwe ze jest tam jakas roznica w ladowaniu plikow, ktora wylazla akurat przy tym czyms, czym probujesz jezdzic jako pasazer. I stare exe albo sobie radzi, albo olewa. Bez mozliwosci zaladowania tego u siebie nie mam jak sprawdzic, w zasadzie testy robie tylko na zawartosci paczki standardowej + kaliska + calkowo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 27 Lutego 2017, 22:42:41
Obawiam sie, ze Quark laduje sie u mnie bez wysypu ;/ ale ten komunikat to mi wyglada na jakis klopot z bibliotekami VC runtime. Sprobuj pobrac instalke z https://www.microsoft.com/en-us/download/details.aspx?id=40784 (https://www.microsoft.com/en-us/download/details.aspx?id=40784) i zobacz, czy cos pomoze.
Ładuje się za każdym razem, ale wysyp jest po 2 do 10 minut. Biblioteki instalowałem, ale może coś źle poszło. Na którymś z poprzednich exe było ok. Ale to muszę wrócić i sprawdzić
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 27 Lutego 2017, 22:58:00
Widzę po logach że niektórzy mają jeszcze opengl 2.0, więc póki co gl3 odpada przy modernizacji silnika.

BTW: ma ktoś cpu intela z architekturą skylake lub nowszą?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 27 Lutego 2017, 23:05:32
Ładuje się za każdym razem, ale wysyp jest po 2 do 10 minut.
Aha ok, uruchomie u siebie i zobacze, jak mu pojdzie. To jest przy jezdzie kiblem 2040, czy czyms innym? Czy bez roznicy?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 27 Lutego 2017, 23:18:30
Kiblem 2040, zwykle wysyp jest chwile po odjezdzie tego kibla po prawej. Raz udalo mi sie kawalek ujechac.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 27 Lutego 2017, 23:32:18
Kiblem 2040, zwykle wysyp jest chwile po odjezdzie tego kibla po prawej. Raz udalo mi sie kawalek ujechac.
Hmm no to raczej u mnie tego nie ma. Kibel z prawej pojechal, a 2040 na autopilocie jedzie jak profesjonalista, na zegarku symulatora 5:03 i idzie dalej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 27 Lutego 2017, 23:34:24
Ok, szukam u siebie. Wiem ze na pewno dzialala ta sceneria. Dzieki

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 28 Lutego 2017, 07:30:06
EN57: załączanie świateł zewnętrznych oświetla wnętrze kabiny nieprawidłowo. Uwaga: na wszystkich zdjęciach rzeczywiste oświetlenie kabiny jest wyłączone.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 28 Lutego 2017, 07:32:38
EN57: oświetlenie składu i scenerii od zewnątrz działa nieprawidłowo. Na zdjęciach odpowiednio włączone 0, 1, 2 i 3 reflektory. Skład wydaje się oświetlony od zewnątrz swoimi własnymi przednimi reflektorami.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 28 Lutego 2017, 07:47:52
Przywróciłem auto iconify tak jak było i poprawiłem F1.
Ktoś robi dziwne konstrukcje rodzaju false == Console::Pressed( VK_CONTROL ) i przeoczyłem negację.

https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng32-5a8c158d.zip
https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng64-5a8c158d.zip

Nie za bardzo poprawione. Nie da się wyłączać OSD, kolejne naciskanie F1 nic nie daje. Tak samo kolejne naciśnięcie F3 nie powoduje ukrycia rozkładu jazdy. Nie działa ESC dla wyłączenia pauzy w trybie normalnym. W trybie pełnoekranowym nie mogę wyświetlić innego okna na oknie ładowania, na wcześniejszych exe (tych od tmj) mogłem.

W poprzednich wersjach (do eu07++170227.exe) wyświetlanie okna programu (i konsoli) działało prawidłowo. Prawidłowo były także obsługiwane klawisze. Szczególnie przydatna była możliwość podglądu okna konsoli nałożonego na ekran ładowania (ten z notesem) na tym samym monitorze. Proponowałbym wprowadzenie alternatywnego ekranu ładowania, gdzie podczas całego procesu ładowania wyświetlana jest konsola. Chodzi mi o połączenie tych 2 rzeczy. Tzn konsolę graficzną: komunikaty w czasie rzeczywistym rysowane są w prostokącie ekranu głównego okna. Sam obrazek można dostosować, żeby zamiast małego notatniczka pokazywał się jakiś większy obiekt zajmujący większość ekranu. Niech będzie to przykładowo zdjęcie wyświetlacza z Traxx-a, gdzie ekran zajmuje większość wysokości okna. Dlaczego tak? Ekran ładowania jest bardzo statyczny, jest wyświetlany długo i wyświetla błędne informacje. W momencie kiedy pokazuje "ładowanie tekstur...OK" tekstury dopiero zaczęły się ładować i ładują się praktycznie przez cały czas do momentu wyświetlenia komunikatu "przygotowanie kabiny" (ten akurat pokazuje się we właściwym momencie).

Oprócz tego: bardzo przydatna będzie także możliwość wyłączenia nowego modelu oświetlenia w ini.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: ST44-003 w 28 Lutego 2017, 08:28:34
Jak masz grafikę Radeona, to niestety tak będzie. Radek sobie nie radzi z tym nowym ficzerem :(
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 28 Lutego 2017, 09:09:01
Jeśli coś działa na NVidii a nie działa na Radeonie - IMHO bug (nieprawidłowa, niekompatybilna implementacja).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: ST44-003 w 28 Lutego 2017, 09:19:03
Na razie ta wersja exe jest na etapie rozwoju. Ale zmierza w dobrą stronę, więc myślę, że szybko sobie z tym poradzą :D
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 28 Lutego 2017, 09:35:37
Z niedziałaniem świateł na radeonie, to bullshit. Jedyne co na radkach powszechnie nie działa, to napisy na ekranie ładowania.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 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ę.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 28 Lutego 2017, 11:33:38
Strasznie dziwna sprawa z tymi wysypami. Exeki z dnia 26 i 27 lutego nie wysypują się na Quarku, natomiast na 170227b wysyp był raz za razem. Próba doinstalowania bibliotek nic nie zmieniła w tej materii. Odpaliłem scenerię jeszcze raz na 170226 zakończyłem jazdę sukcesem, odpaliłem na 170227 - dotarłem do celu bez żadnych problemów. odpaliłem po raz kolejny na 170227b i... tym razem dojechałem do celu bez wysypu. Co najmniej dziwne. Usunę jeszcze plik $.scn, jeśli powtórzę dojazd do celu, będą musiał uznać że wysypy minęły. Jednak jest małe co nieco. W EN57-2040 na 170227b, nie odtwarza się dźwięk gwizdka, dokładnie to: 2000_odjazd.wavNa poprzednich exe do 170227 włącznie, gwizdek jest.
PS: Nie daje rady zainstalować bibliotek MS na win7, wyskakuje nieznany błąd opisany w sieci. Póki co, wersja 64 bitowa i odpalanie Maszyny na win7 w exe_c++, mogę zapomnieć.
Jeśli ktoś miał podobny problem i go rozwiązał, proszę o info na PW.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Lutego 2017, 13:39:37
EN57: oświetlenie składu i scenerii od zewnątrz działa nieprawidłowo. Na zdjęciach odpowiednio włączone 0, 1, 2 i 3 reflektory. Skład wydaje się oświetlony od zewnątrz swoimi własnymi przednimi reflektorami.
Ktora to wersja exe? Ten blad byl w 170227, powinien byc usuniety w 170227b

Jak masz grafikę Radeona, to niestety tak będzie. Radek sobie nie radzi z tym nowym ficzerem :(
Pierwsze slysze, ma ktos Radeona, na ktorym to nie dziala? Jednej osobie wydawalo sie, ze jego Radeon sobie nie radzi, ale okazalo sie, ze to byla wbudowana karta Intela, a jego Radeon nie byl wlaczony, I po wlaczeniu wszystko poszlo.

Jednak jest małe co nieco. W EN57-2040 na 170227b, nie odtwarza się dźwięk gwizdka, dokładnie to: 2000_odjazd.wavNa poprzednich exe do 170227 włącznie, gwizdek jest.
PS: Nie daje rady zainstalować bibliotek MS na win7, wyskakuje nieznany błąd opisany w sieci. Póki co, wersja 64 bitowa i odpalanie Maszyny na win7 w exe_c++, mogę zapomnieć.
Jeśli ktoś miał podobny problem i go rozwiązał, proszę o info na PW.
Brak gwizdka w 170227b brzmi co najmniej dziwnie, bo ta wersja jest identyczna z poprzednimi, minus drobna zmiana obslugi swiatel. Co do VC2013 runtime, sprobuj pobrac I zainstalowac poprawke umieszczona tutaj: https://support.microsoft.com/en-us/help/3179560

Co do samego .exe, to przyszlo mi wlasnie do glowy, ze zapewne sporo osob jezdzi sobie z wlaczona opcja VBO, ktore jest zaimplementowane raczej srednio I moze byc zrodlem dodatkowych bledow wizualnych.  W nowym uaktualnieniu (poza obsluga hamulcow typu K) chwilowo wylaczylem renderowanie VBO. Jesli mozna, to prosze sprawdzic czy zgloszone bledy (migotanie chmur itp) wystepuja nadal w tej wersji.



Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 28 Lutego 2017, 14:13:28
Przywróciłem auto iconify tak jak było i poprawiłem F1.
Ktoś robi dziwne konstrukcje rodzaju false == Console::Pressed( VK_CONTROL ) i przeoczyłem negację.

https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng32-5a8c158d.zip
https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng64-5a8c158d.zip

Nie za bardzo poprawione. Nie da się wyłączać OSD, kolejne naciskanie F1 nic nie daje. Tak samo kolejne naciśnięcie F3 nie powoduje ukrycia rozkładu jazdy. Nie działa ESC dla wyłączenia pauzy w trybie normalnym. W trybie pełnoekranowym nie mogę wyświetlić innego okna na oknie ładowania, na wcześniejszych exe (tych od tmj) mogłem.
Zachowanie z ukrywaniem okienka przy alt-tab jest powodowane przez GLFW, moim zdaniem to właściwie lepiej, ale nic z tym raczej nie zrobię. Ekran ładowania się zmieni poźniej żeby wypisywało na nim komunikaty z konsoli. Na F3 zobaczę później, ale ukrywanie przez ponowne naciśnięcie F1 na pewno działa.

---

@tmj: popatrzyłem na kod od tego kolorowego nieba co zrobiłeś, i niezbyt to ładne. Będziesz jeszcze coś w tym zmieniał, czy mogę przerobić na vbo?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 28 Lutego 2017, 15:04:41
Zachowanie z ukrywaniem okienka przy alt-tab jest powodowane przez GLFW, moim zdaniem to właściwie lepiej, ale nic z tym raczej nie zrobię.
Nie zrozumiałem z tego zdania, co jest lepsze. Dla użytkownika windows zmiana okienek przy alt tab jest podstawową funkcją poruszania się po systemie. Oczywiście to przyzwyczajenie i można to zmienić. Może się wydawać, że jak zabawa z maszyną to nie kombinujemy z innymi aplikacjami. I zgodzę się z tym, jednak całymi dniami testując zachowania exe lub jakiejś nowej scenerii jest upierdliwe. Gdybym miał odpaloną symulację na Twojej kompilacji nie mógł bym napisać teraz tej wiadomości.
PS: Komunikaty u mnie wyłącza F6.
PS2: @tmj, jakkolwiek to wygląda, jest faktem, że dźwięk gwizdka znika na wczorajszej wersji b.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 28 Lutego 2017, 15:13:18
Nie rozumiem. Alt-tab powinien działać. Z tego co zrozumiałem rozchodzi się o to, że nie da się mieć innego okienka zasłaniającego symulator, bo po przełączeniu focusa na inne okienko symulator się chowa, tak?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Lutego 2017, 15:15:08
@tmj: popatrzyłem na kod od tego kolorowego nieba co zrobiłeś, i niezbyt to ładne. Będziesz jeszcze coś w tym zmieniał, czy mogę przerobić na vbo?
Przerob jesli chcesz, ale biorac pod uwage ze polowa danych i tak zmienia sie regularnie i trzeba odswiezac zawartosc bufora, a calosc to raptem ~1500 wierzcholkow, to troche imo sztuka dla sztuki :) Docelowo i tak powinno byc w 90% przesuniete do shadera, zakladajac ze kiedys beda.

PS2: @tmj, jakkolwiek to wygląda, jest faktem, że dźwięk gwizdka znika na wczorajszej wersji b.
A co z dzisiejsza wersja, tez brak, czy gwizdze? Pytam, bo u mnie na 100% gwizdal na 170227b podczas wczorajszych testow.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 28 Lutego 2017, 15:16:11
Tak, po przełączeniu choćby na IE aby zerknąć na forum (oczywiście bez pełnego ekranu), znika symulacja. Wersję 170228 dopiero zassałem, będę sprawdzał gwizdanie. :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Lutego 2017, 15:18:51
Nie rozumiem. Alt-tab powinien działać. Z tego co zrozumiałem rozchodzi się o to, że nie da się mieć innego okienka zasłaniającego symulator, bo po przełączeniu focusa na inne okienko symulator się chowa, tak?
O ile dobrze rozumiem rozchodzi sie o to, ze niektorzy maja otwarte okno symulatora, i jak sie tam malo dzieje to sledza zawartosc jednym okiem, a drugie maja na oknie przegladarki czy gdzie indziej (sam tak robie dosc czesto) Wiec gdy symulator sie chowa, to ta funkcjonalnosc tez zanika.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 28 Lutego 2017, 15:24:39
Przerob jesli chcesz, ale biorac pod uwage ze polowa danych i tak zmienia sie regularnie i trzeba odswiezac zawartosc bufora, a calosc to raptem ~1500 wierzcholkow, to troche imo sztuka dla sztuki :) Docelowo i tak powinno byc w 90% przesuniete do shadera, zakladajac ze kiedys beda.
Zmienia się, ale to nie znaczy że trzeba nachrzaniać 3000 calli do drivera co klatkę. Jedno VBO na wierzchołki, drugie na kolory, połączyć razem w VAO, a bufor z kolorami aktualizować przez glMapBuffer.
Shadera to mógłbym zrobić i teraz, tylko zastanawiam się czy liczenie tych wzorów co klatkę ma sens, bo obecnie jest rzadziej. Można by z taką samą częstotliwością jak teraz renderować do tekstury, ale z drugiej strony wtedy znowu trzeba liczyć dla całego nieba mimo że zwykle widoczny jest tylko fragment, więc pod tym względem liczenie tego co klatkę jest lepsze.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Lutego 2017, 15:29:14
Można by z taką samą częstotliwością jak teraz renderować do tekstury, ale z drugiej strony wtedy znowu trzeba liczyć dla całego nieba mimo że zwykle widoczny jest tylko fragment, więc pod tym względem liczenie tego co klatkę jest lepsze.
Liczyc calosc warto i tak, bo srednia jest wykorzystywana takze do innych celow (kontrola jasnosci obiektow itp), wiec jak zaczniesz kalkulowac tylko to co uzytkownik widzi przez kamere, to beda bezsensowne skoki na podstawie tego, gdzie akurat wcelowana jest kamera.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 28 Lutego 2017, 15:29:48
Tak, po przełączeniu choćby na IE aby zerknąć na forum (oczywiście bez pełnego ekranu), znika symulacja. Wersję 170228 dopiero zassałem, będę sprawdzał gwizdanie. :)
No bez pełnego ekranu to u mnie jest ok, można przełączyć na inne okienko i symulator się nie chowa. Sprawdzone na win7.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 28 Lutego 2017, 16:04:58
Jesli chodzi o dzisiejsze 170228 to melduje, ze gwizdek jest. Wieczorem powalcze z bibliotekami MS na win7.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 28 Lutego 2017, 17:19:29
Na Win10 (i oryginalnym exe) nie ma problemu na pełnym ekranie wyświetlić okienko z konsolą. Symulator nie ma się chować po przejściu do innego okna dlatego, że jak masz 2 monitory to możesz coś zrobić na drugim monitorze. Ja zwykle na drugim monitorze mam Rainsted, rozkład jazdy albo inny dokument.

BTW, alt+tab domyślnie po prostu przykrywa okno symulatora innym oknem, bez chowania symulatora. To jest sensowne zachowanie i tak powinno być. Zauważyłem, że niektóre gry też tak mają. Nie cierpię takich, które uniemożliwiają mi podgląd pełnego ekranu gry podczas używania innych aplikacji, przykładowo przeglądarki.

Ogólnie zachowanie okienek jest nie bez powodu obsługiwane przez system operacyjny i żadna aplikacja nie powinna tego zmieniać. Nie ma sensu ograniczania opcji jakie ma użytkownik. Każdy sobie ustawi po swojemu jak mu pasuje. I jeszcze raz - to było dobrze w starym exe a skoro było dobrze, to nie ma sensu zmieniać takich rzeczy bo to jest krok wstecz. Jest wystarczająco dużo pilnych rzeczy do poprawienia, mam na myśli konkretnych bugów typu niedziałający hamulec pomocniczy w SN61 czy światła oświetlające kabinę i wszystko wokół w kiblach.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Lutego 2017, 17:25:44
światła oświetlające kabinę i wszystko wokół w kiblach.
Masz to nadal na nowszych exe (120227b, 120228)?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 28 Lutego 2017, 17:29:02
Przerzuciłem aktualny stan prac na mojego mastera. I tak wiem, że wszyscy korzystają z repo tmj-a więc będę od czasu aktualizował stan prac u siebie a potem na głównym repo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 28 Lutego 2017, 17:52:46
Sorki, moja wina, przeoczyłem 120227b. Nie, w 120227b jest ok. A tak na marginesie, gdzie jest 120228?
 
światła oświetlające kabinę i wszystko wokół w kiblach.
Masz to nadal na nowszych exe (120227b, 120228)?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 28 Lutego 2017, 17:59:37
@HTD, nie potwierdzam swiecenia kabiny i skladu EN57 juz od exe 170227b. Mam takie dziwne wrazenie jakbys nie czytal zbyt uwaznie informacji o zmianach. Zgadzam sie za to z alt + tab.
@tmj, dzisiejszy plik gwizdze, jezdzi, swieci. Przynajmniej na kilku pojazdach i sceneriach co testuje. Nie ukrywam, ze jestem rozczarowany iloscia osob pobierajacych i testujacych najwazniejszy plik w calej MaSzynie.
Dodam dzis jeszcze pewna wskazowke na wysyp exekow. Przynajmniej z tym komunikatem, ktory publikowalem wczesniej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Lutego 2017, 18:04:56
A tak na marginesie, gdzie jest 120228?
Troche wyzej na tej stronie :)  http://eu07.pl/forum/index.php/topic,28159.msg442600.html#msg442600

uaktualnienia w sumie dosc latwo przegapic, jesli watek posuwa sie szybko, ale jesli mozliwe to wzmianka, ktora wersja byla testowana gdy trafil sie blad, jest przydatna.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 28 Lutego 2017, 18:15:15
Załączam dwa zrzuty ekranu na podstawie których, chcę pokazać wywalenie błędu. W exe pascalowym nigdy nie było problemu, aby zamknąć program za pomocą przycisku x na konsoli. Zaznaczyłem ten przycisk w załączniku. Jednak po przenosinach na C++ próba zamknięcia programu zawsze wywala komunikat o błędzie, na wszelki wypadek ten komunikat załączam powtórnie. Może to nic ważnego, ale większość wysypów, jak nie wszystkie, kończy się u mnie takim komunikatem. Przy testach kiedy symulację zamykam przed jej dokończeniem taka forma zamykania była przeze mnie stosowana. Może to nic nie znaczy, ale uznałem, że warto o tym wspomnieć.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Lutego 2017, 18:21:21
Zgadza sie, tam jest taki glupi blad zwiazany z logowaniem, ktory objawia sie okazjonalnie przy zamknieciu, ale wymagaloby to sporej ilosci drobnych poprawek, wiec na razie to odkladam, bo blad jest malo istotny. Jak mnie dostatecznie zdenerwuje to sie za niego wezme ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 28 Lutego 2017, 19:04:26
Jeszcze dodam, że objawia się na wersji debug a na wersji release nie zauważyłem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 28 Lutego 2017, 19:23:47
Aha, jeszcze taki bug ze światłem jest, że przyciemnienie światła w kabinie prawie nic nie daje. Tzn za mało ściemnia. Oczywiście testowane na wersji 120228.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 28 Lutego 2017, 19:26:56
Wrzuć jakiś poglądowy obrazek, chyba mi ostatnio brakuje wyobraźni.
Zgadza sie, tam jest taki glupi blad zwiazany z logowaniem, ktory objawia sie okazjonalnie przy zamknieciu, ale wymagaloby to sporej ilosci drobnych poprawek, wiec na razie to odkladam, bo blad jest malo istotny. Jak mnie dostatecznie zdenerwuje to sie za niego wezme ;)
Ja mam za każdym razem jak tak zamykam. Tak jak wspomniał Grzegorz w debug mode. Samo zamykanie mnie nie gnębi, liczyłem że jest to przyczyną wysypów w trakcie symulacji.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 28 Lutego 2017, 19:48:52
debug mode to nie jest to samo co wersja debug i release exe.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 28 Lutego 2017, 20:04:26
Szkoda, że nie dopisałeś jaka jest różnica. Mimo wszystko, nie jestem wszystkiego świadomy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 28 Lutego 2017, 20:34:09
O co tu chodzi?

Multiple passed
EVENT ADDED TO QUEUE: sr_toc_sem_ligh2n by et22-216
Traceback (most recent call last):
  File "<string>", line 46, in render
  File "E:\MaSzyna_15_04_uzytkowa\python\lib\site-packages\PIL\Image.py", line 1908, in transpose
    return self._new(self.im.transpose(method))
MemoryError

EVENT LAUNCHED: sr_toc_sem_ligh2n by et22-216
Unknown python texture size!
Traceback (most recent call last):
  File "<string>", line 43, in render
  File "<string>", line 22, in _render
  File "E:\MaSzyna_15_04_uzytkowa\python\lib\site-packages\PIL\Image.py", line 1002, in copy
    im = self.im.copy()
MemoryError

Unknown python texture size!
Traceback (most recent call last):
  File "<string>", line 46, in render
  File "E:\MaSzyna_15_04_uzytkowa\python\lib\site-packages\PIL\Image.py", line 1908, in transpose
    return self._new(self.im.transpose(method))
MemoryError

Unknown python texture size!
Key pressed: [Num+]

Jedyna teksturę jaka używa ekran pytona w tym przypadku ma 128x32x24bpp

CIagle mi na kaliskiej wypieprza exeka nawet numer 28. Niebo dalej migocze chodz przestalo po wyjechaniu za semafor. Tam exeka wywalilo. Niewiem ale stare exe nie było az tak wrażliwe.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Lutego 2017, 20:58:01
"Unknown python texture size" to jest blad, ktory exe wywala gdy nie uda mu sie okreslic wymiarow textury. Albo brakuje mu tej tekstury, albo jest cos nie tak z instalacja pythona. U siebie uzywam 32-bitowej instalacji z https://www.python.org/ftp/python/2.7.13/python-2.7.13.msi umieszczonej w domyslnym folderze I w polaczeniu z Win10 64-bit dziala to bez zadnych klopotow wiec nie, nie jest to kwestia 64-bit windows.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 28 Lutego 2017, 21:01:11
Tak jak pisalem tekstura ma rozmiar 128 32 24bpp i jest wczytywana. Inaczej ekran sie nie wyswietli a sie wyswietla. Na win 7 x32 tez wywalilo. Dzieki. BYlo milo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Lutego 2017, 21:14:19
Sorry,zwyczajnie nie wiem co tam moze byc zle. Wyraznie klopot jest gdzies albo z sama instalacja pythona na twoim komputerze, albo w tym jak jest on polaczony z reszta kodu w .exe (lub kombinacja jednego I drugiego) ale to jest praktycznie w calosci kod wziety z oryginalnego exe, I musialby sie nad tym pochylic autor. Problem nie wystepuje u mnie, wiec nie moge tego zdebugowac.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 28 Lutego 2017, 21:21:59
No dobra ok zamienilem loka z pytonem ma loka bez pytona i wywalilo natychmiast po wcisnieciu f5. Sprawdzalem tego samego loka na td i ladowal sie ok. Ale co innego ladowac td a co innego kaliska. Tak jak pisalem stare exe tak nie szaleja. Teraz test na win 7 x32. Jak wywali to juz koncze z tym.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 28 Lutego 2017, 21:23:13
Sorry,zwyczajnie nie wiem co tam moze byc zle. Wyraznie klopot jest gdzies albo z sama instalacja pythona na twoim komputerze, albo w tym jak jest on polaczony z reszta kodu w .exe (lub kombinacja jednego I drugiego) ale to jest praktycznie w calosci kod wziety z oryginalnego exe, I musialby sie nad tym pochylic autor. Problem nie wystepuje u mnie, wiec nie moge tego zdebugowac.
Wszystko potrzebne do pythona jest dostarczane razem z paczką, więc to raczej nie to.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 28 Lutego 2017, 21:25:39
Stare exe pytona nie wywalaja. Powiem wprost befa cyrki z tym exe. Jak narazie u nielicznych dziala na kaliskiej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Lutego 2017, 21:45:57
EP, u kogo poza toba nie dziala Kaliska? Jesli nie chce im sie tego zglosic tutaj, to raczej bledy same sie nie znajda i nie usuna. Moge sprawdzic i poprawic tylko to, co zobacze u siebie, a u mnie niestety Kaliska jak i reszta scenariuszy na ta chwile dziala. Kilka zgloszonych bledow (slizgajace samochody, hamulec SN61, brak niektorych dzwiekow itp) czeka na poprawienie, bo te widze i jest tu jakis punkt zaczepienia, ale takie klopoty jak ty masz, to ja nawet nie moge wykluczyc czy to zwyczajnie cos nie jest ze sprzetem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 28 Lutego 2017, 22:06:01
To ok ja kompa dla nowego exe nie wymienie. Wlasnie wywalilo na win7 x32 .

Bezprzerwy tym sieje.

Unknown python texture size!
New timetable for en57-1051ra: kaliska/cegielski/17233
Traceback (most recent call last):
  File "<string>", line 47, in render
  File "K:\MaSzyna_15_04_uzytkowa\python\lib\site-packages\PIL\Image.py", line 684, in tobytes
    l, s, d = e.encode(bufsize)
MemoryError
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Lutego 2017, 22:19:36
Widzisz kurcze, nawet crashdump nie daje rady zapisac i produkuje pusty, to raczej nie jest normalne ;/  Ten blad pythona to wyskakuje na wszystkich sceneriach, tych mniejszych tez? Czy tylko na Kaliskiej?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 28 Lutego 2017, 22:43:33
Nie bede tego sprawdzac. Ja juz koncze zabawe z tym exe. Najwyrazniej na moim sprzecie nie bedzie dzialac niezaleznie od systemu. Trudno. Na tym etapie puki stare exe da rade to ok skorzystam.
 Jak juz wszystko przejdzie na to nowe exe to wyglada na to ze bedzie to moj koniec przygody z tym symulatorem. Napewno dla exe nie zainwestuje w nowy komp na to mnie nie stac. Jestem pelen uznania dla ciebie za czas i ogrom pracy jaki w to wkladasz. O takim dynamicznym niebebie i swiatlach marzylem od lat. Niestety jak widac puki co nie kazdy skorzysta.
Pozdrawiam cie serdecznie i zycze wytrwalosci w osiagnieciu zamierzonego celu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Lutego 2017, 22:46:33
Akurat niebo I swiatla sa na tyle prymitywne, ze pewnie calkiem latwo daloby sie je przeszczepic do starego exe, tylko musialby to skompilowac ktos z Borlandem. Ale jakas nadzieja jest ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 28 Lutego 2017, 23:53:21
Witam.
Aż z ciekawości uruchomiłem kaliską z Cegielskim na najnowszym exe i w zasadzie wszystko w normie, jedynie czapajew zjeżdżający po wiadukcie do ZWK nie chciał ruszyć z pod semafora, ale chwilowy restart AI i ożył. Reszta składów mijanych po trasie jechała normalnie. Wczoraj natomiast na poprzedniej kompilacji exe, zbugował się bardzo dziwnie EN57 na L053. Zablokował się nastawnik wirtualnie na najwyższej pozycji jazdy, nie działały hamulce. Zestawy zaczęły rolować, aż wyskoczył komunikat "wheel wear". Ogólnie pociąg widmo. Pomógł dopiero restart jednostki (wyłączenie WS, przetwornicy, sprężarki). Być może to jednostkowy przypadek, nie wina exe.
Pozdrawiam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 28 Lutego 2017, 23:59:57
Ten ET42 ma blednie wpisana predkosc startowa w trainsecie. Zamiast 6 nalezy wpisac 0.1  zreszta nie tylmo ten sklad tak ma.
Bylo o tym w watku o Kaliskiej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Marca 2017, 04:25:54
OK, w dzisiejszym uaktualnieniu mamy pierwsza faze przeszczepu GLFW of Milka. Tzn jak na razie .exe zostalo spiete z GLFW, a do sprawdzenia jest, czy nie rozsypala sie przy okazji obsluga jakis funkcji obslugi klawiatury, zachowania okna itp (na 80-90% posypala sie obsluga eventow wyzwalanych klawiszem, bo tutaj uzywane byly kody specyficzne dla windowsa, ale to sie naprawi. moze) Oprocz tego dobrze byloby, gdyby ktos mogl przetestowac czy wymiana danych przez COPYDATA jeszcze dziala, bo zrobiona jest niejako na doczepke a nie wiem z czym to sprawdzic. Jesli testy pojda dobrze to bedzie mozna przeszczepic reszte, czyli serializacje i wersje 64 bit.

A zeby nie bylo calkiem nudno, to jest tez drobna zmiana w funkcjonowaniu F4. Teraz po nacisnieciu F4 ladujemy na zewnatrz lokomotywy, mniej wiecej w okolicy drzwi do kabiny ktora zajmowalismy, coby nie trzeba bylo za kazdym razem dralowac przez pole do sprzegow. A jesli komus potrzebna jest teleportacja na dalszy dystans, dla obserwacji scenicznych przejazdow czy czego tam, to od tego jest teraz shift + F4.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 01 Marca 2017, 05:45:59
Datownik w aplikacji na 170331?
No coz zawsze to jakies oznaczenie, na koniec marca zrobisz sobie wolne.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 01 Marca 2017, 06:59:44
1. Okno nie pozwala na wyświetlenie innego okna na nim (regresja).
2. Zepsuty anti-aliasing, podczas jazdy widać mocno trzęsące się ostre, niewygładzone linie. Trakcja i wskazówki manometrów wyglądają gorzej.
3. Ignorowanie opcji Napisy z GLUT32.DLL. Czyli brzydki szeryfowy za gruby font.

Na plus:
+ obsługa F4 - IDEAŁ. O to chodziło.
+ oświetlenie (bez świateł, chodzi o słońce i księżyc): IDEAŁ. Odpaliłem misję o tej godzinie co na zegarku, o świcie, i mam w symku to samo co za oknem. Opad szczęki.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 01 Marca 2017, 08:33:30
Włodek, próbowałeś rozpakować nowe exe na czystą paczkę z nagraną tylko kaliską? Jeszcze pozostaje sprawdzenie czy na VBO działa czy nie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 01 Marca 2017, 09:07:23
Witam.
 Panowie, a pod XP Pro SP3 da radę exe 170331 uruchomić w ogóle? Bo u mnie krzyczy o brakujące dl-ki. Jedną znalazłem ( vcruntime140.dll ) w sieci, to teraz żąda api-ms-win-crt-runtime-l1-1-0.dll, i nie mogę namierzyć. Chciałem przetestować współdziałanie z SCS, a tu kicha...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 01 Marca 2017, 09:15:02
1. Okno nie pozwala na wyświetlenie innego okna na nim (regresja).
2. Zepsuty anti-aliasing, podczas jazdy widać mocno trzęsące się ostre, niewygładzone linie. Trakcja i wskazówki manometrów wyglądają gorzej.
3. Ignorowanie opcji Napisy z GLUT32.DLL. Czyli brzydki szeryfowy za gruby font.
ad1: No tu tragedia, robienie więcej niż jednego zrzutu ekranu do pamięci przestało być możliwe, nie można wywlec choćby painta aby zapisać screena. To trzeba naprawić, a jakby się chciało to kiedyś Q zrobił robienie zrzutów pod F12, które zapisywały się do folderu SCR w katalogu głównym z maszyną.
ad2: Dam tego jednego screena z antyaliasingiem na 16 z kabiny siódemki. Wygląda dobrze, na 1 możliwie jak ktoś ma słaby sprzęt. Jazdę sprawdzę wieczorem, teraz nie miałem na to czasu.
ad3: To dla mnie nie jest zauważalne, raczej mało istotny szczegół estetyczny
Na plus:
+ obsługa F4 - IDEAŁ. O to chodziło.
+ oświetlenie (bez świateł, chodzi o słońce i księżyc): IDEAŁ. Odpaliłem misję o tej godzinie co na zegarku, o świcie, i mam w symku to samo co za oknem. Opad szczęki.
Tu nie ma co deliberować, jest super. Tym bardziej super, że dostałem następną swoją zabawkę o którą prosiłem, pod F4 Twierdzono, że za dużo zachodu i niemożliwe, a w ogóle to fanaberia.
Załącznik wielkiej wagi: http://eu07.pl/userfiles/1234/foto-a.PNG (http://eu07.pl/userfiles/1234/foto-a.PNG)
CX Maniak, uruchomiłem pod XP z sp3, ale biblioteki też mi wołał.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 01 Marca 2017, 09:36:17
@tmj: nie wiem jak to zrobiłeś bo znowu zapomniałeś wrzucić na githuba, ale glfw i wm_copydata raczej nie pogodzisz. Wysyłane przez PostMessage można przechywić peekując komunikaty przed glfwpollevents, ale tym nie da się przesyłać payloadu. Trzeba użyć SendMessage a to idzie prosto do callbacka w glfw, więc musiałbyś wydrzeć callbacka z glfw do siebie, przetworzyć niektóre komunikaty i spowrotem przekazać do glfw.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 01 Marca 2017, 11:12:35
Załącznik nr1, wydajność w trakcie symulacji. Zmniejszenie obciążenia procesora, bardzo widoczne zwiększenie ilości FPS. Nie wiem jak to zrobiliście, bo to Kaliska z antyaliasingiem na 16. Dojechałem do Łasku czapajewem z Olechowa, żadnych wysypów i nienormalnych zachowań. Szkoda że do pamięci podręcznej można wrzucić tylko jeden obrazek, bo nie ma jak go zapisać. Stąd tylko jeden. Światła, nie wiem czy na Kaliskiej teren przy torach jest z małych trójkątów, pewnie tak, bo dziś to wygląda jakby był pixelshader.
Załącznik numer dwa, to zapis obciążenia (spadek) po wyłączeniu symulatora. Dla mnie - bomba.
Alt +tab trzeba koniecznie poprawić, jedyne okno gdzie można wyłożyć na wierzch, to alt+ctrl+del. Dlatego jest wydajność systemu na screenie.
Na Kaliskiej w trasie mam 60 FPS, na stacjach około 40.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 01 Marca 2017, 11:27:04
@Krzysiek626:
Mój "słaby sprzęt" to GTX960, opcja anti-aliasing: "Application setting". Może to słabo widać na JPG, na PNG widać wyraźnie. Jest spore pogorszenie i to jest na 100% bug (prawdopodobnie brak prawidłowego zaczytania opcji z ini).

Jak już jesteśmy przy bugach:
 - Przyciemnienie światła w kabinie - wielkość przyciemnienia jest zbyt niska, ledwo widać efekt, opcja z bardzo przydatnej zrobiła się niemal bezużyteczna.
 - Zapalenie jednego światła (np prawego reflektora) daje zbyt słabe oświetlenie, w nocy oznakowanie jest ledwie widoczne, z trudem można w ogóle zauważyć zapalenie światła. Widać na większości scenerii nocnych.
 - Opcja w ini "glutfont yes" nie działa.
 - Odtwarzanie głośnego szumu przy starcie EN57. Uniemożliwia jazdy EN57 (z włączonym dźwiękiem). Uwaga: raz na kilka uruchomień nie ma tego szumu. Testowane na "baltyk_en57". Jak ktoś nie ma, to "baltyk_zima".
 - Gwałtowne gaszenie trójkątów podczas jazdy ze światłami (zapalanie jest już OK, rozjaśniają się płynnie w funkcji odległości, ale gasną gwałtownie). Testowane na "quarkmce2007".
 - Hamulec pomocniczy w SN-61 nie działa. Testowane na "całkowo_sn61"

Nie wiem czy w ramach burzy mózgów mogę coś zaproponować: z tym światłem - zostawić naturalne oświetlenie jak jest, bo jest po prostu idealne. Co do lamp - wprowadzić opcje w ini: headlights=n, gdzie n = 0 - wyłączone, brak, nie działają (do jazdy w dzień), n = 1 - stare lampy, n = 2 - nowe lampy. Opcje będzie można wyrzucić po zmianie oświetlenia na shader.

Co do algorytmu: a gdyby tak zmienić funkcję ładującą trójkąty i dodać do niej dzielenie dużych trójkątów na mniejsze? Taka super prosta "teselacja", to byłoby wręcz banalne. Jak tam gdzieś siedzi funkcja "odczytaj trójkąty=>zwróć trójkąty", zmienić ją na "odczytaj trójkąty=>dla każdego sprawdź czy najdłuższy bok nie większy niż x, jeśli tak, dziel wzdłuż boku tak długo, aż najdłuższy bok nie będzie większy niż x=>zwróć oryginalne i podzielone trójkąty". W ten sposób zniknie problem migania, chociaż może wystąpić spadek FPS. Maksymalną długość podziału można też dać w ini, wtedy dla zera będzie tak jak jest, dla innych wartości to będzie maksymalna długość boku trójkąta w metrach. Warto to sprawdzić. Ten algorytm dla wierzchołków się po prostu nie nadaje. Fajny bajer, ale na dłuższą metę irytujący i psujący klimat. Podatne osoby mogą ponadto padaczki dostać od tego migania ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 01 Marca 2017, 12:00:32
...
Ale kombinujecie, prościej po prostu już zrobić to oświetlenie na shaderze, dzisiaj wieczorem spróbuję.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: pinokio w 01 Marca 2017, 12:55:27
Witam u mnie przy próbie uruchomienia na exe 170331 wyskakuje takie okienko:
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 01 Marca 2017, 13:03:38
Miałem to samo, ale pomogła zmiana pliku glew32.dll na starszy, a nie ten najnowszy
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Marca 2017, 14:17:53
1. Okno nie pozwala na wyświetlenie innego okna na nim (regresja).
Hmm czy to jest w trybie pelnoekranowym, czy w oknie? Jesli w oknie to obawiam sie, ze u mnie to dziala (w zalaczniku)

Cytuj
3. Ignorowanie opcji Napisy z GLUT32.DLL. Czyli brzydki szeryfowy za gruby font.
Font jest akurat bezszeryfowy, bo to Lucida Console :) Dalem grubszy, bo cienkie linie dosc zle sie w moim doswiadczeniu czyta. Moge dac cienszy, ale czy ktos nie bedzie wtedy narzekal ze zle widzi? Pod dyskusje.
Aha, glut jest faktycznie wylaczony, ale to nie ma specjalnego wplywu na font, bo ustawic mozna dosc dowolny. Sprowadza sie do tego, ktore beda dostepne na wiekszosci komputerow, i czytelnosci.

@tmj: nie wiem jak to zrobiłeś bo znowu zapomniałeś wrzucić na githuba, ale glfw i wm_copydata raczej nie pogodzisz. Wysyłane przez PostMessage można przechywić peekując komunikaty przed glfwpollevents, ale tym nie da się przesyłać payloadu. Trzeba użyć SendMessage a to idzie prosto do callbacka w glfw, więc musiałbyś wydrzeć callbacka z glfw do siebie, przetworzyć niektóre komunikaty i spowrotem przekazać do glfw.
No i mniej wiecej tak to dziala. glfw pod windows to ciagle jest okno windows, tyle ze ma wlasna procedure obslugi komunikatow windows. A windows systemowo pozwala na podmiane window proc. Czyli robisz takie cos:
#ifdef _WINDOWS

HWND Hwnd;
WNDPROC BaseWindowProc;

LRESULT APIENTRY WndProc( HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
    switch( uMsg ) // check for windows messages
    {
        case WM_COPYDATA: {
            // obsługa danych przesłanych przez program sterujący
            pDane = (PCOPYDATASTRUCT)lParam;
            if( pDane->dwData == 'EU07' ) // sygnatura danych
                World.OnCommandGet( (DaneRozkaz *)( pDane->lpData ) );
            break;
        }
    }
    // pass all unhandled messages to DefWindowProc
    return CallWindowProc( BaseWindowProc, Hwnd, uMsg, wParam, lParam );
};

(...)

    // setup wrapper for base glfw window proc, to handle copydata messages
    Hwnd = glfwGetWin32Window( window );
    BaseWindowProc = (WNDPROC)::SetWindowLongPtr( Hwnd, GWLP_WNDPROC, (LONG)WndProc );
#endif
i juz. Jak przychodzi COPYDATA to exe obsluguje je pierwsza, a wszystko inne idzie przelotowo do glfw. (COPYDATA tez idzie, tylko moment pozniej)

Na githuba jeszcze nie wrzucilem bo o 5-ej nad ranem juz mi sie nie chcialo. Sprawdze jeszcze u siebie pare rzeczy i pojdzie troche pozniej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 01 Marca 2017, 15:00:35
1. Okno nie pozwala na wyświetlenie innego okna na nim (regresja).
Hmm czy to jest w trybie pelnoekranowym, czy w oknie? Jesli w oknie to obawiam sie, ze u mnie to dziala (w zalaczniku)
Ja wcześniej pisałem, że w trybie pełnoekranowym. Jazda w trybie okienka windows jest dla mnie nieatrakcyjna. Po za tym trudno, aby na wolnej przestrzeni ekranowej czegoś nie otworzyć, dlatego w trybie okienkowym można otwierać inne okna.
Upierdliwe to, bo uruchomiłem symulacje na Kaliskie na innym exe niż chciałem i przez 10 minut nie mogłem nic zrobić, aby się z tego wycofać. Nie mogłem kliknąć na krzyżyk okna konsoli. No chyba że alt+ctrl+del i w oknie kliknąć zamknij aplikację. Chyba nie tak powinno być.
@Krzysiek626:
Mój "słaby sprzęt" to GTX960, opcja anti-aliasing: "Application setting". Może to słabo widać na JPG, na PNG widać wyraźnie. Jest spore pogorszenie i to jest na 100% bug (prawdopodobnie brak prawidłowego zaczytania opcji z ini).
Nie przejmuj się, mam słabszy sprzęt, bo GT9600GT silent i słaby intel E6300, nie miałem kompletnie na myśli Ciebie.
PS: Czcionka ma być czytelna, przed komputerem siedzę w szkłach +3 i astygmatyzm.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 01 Marca 2017, 15:56:53
IMO trzeba by było zrobić przejście pełny ekran/okno za pomocą alt + enter, jak to ma miejsce w większości gier.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Marca 2017, 17:24:47
OK, uaktualnienie z poprawkami:
- fullscreen powinien teraz pozwalac na umieszczenie na nim innych okien, zamiast decydowac sobie ze bedzie TOPMOST i juz
- eksperymentalnie, fullscreen nie przelacza monitora na rozdzielczosc podana w .ini, a zachowuje aktualnie ustawiona rozdzielczosc desktopu. Jak sie nie podoba, prosze krzyczec.
- opcja glutfont yes wyswietla cienka wersje czcionki, dla uzytkownikow z sokolim wzrokiem i/lub masochistow
- bardziej zaakcentowana roznica oswietlenia kabiny po uzyciu przelacznika przyciemnienia
- zmieniona nieco kalkulacja sily swiatel, pojedyncze swiatlo powinno miec teraz wiekszy efekt
- prawidlowa numeracja wesji exe :P

edit:
aha, tak na marginesie, program mozna tez zamknac standardowym alt+f4, nie ma koniecznosci klikania na okienko konsoli.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 01 Marca 2017, 17:35:25
Działa, wszystko co opisałeś działa!
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: fuji8 w 01 Marca 2017, 19:27:22
Teraz jak włączymy reflektory w jednej i drugiej kabinie, smuga nagle przestaje działać.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 01 Marca 2017, 20:06:46
Anti-aliasing nadal zepsuty. Chudy font też nie ma AA. Światła semaforów z oddali są mocno powiększone, takie wielkie kropy, to ma też związek z AA.
Nie działa prawidłowo filtrowanie tekstur - ruszają się wzorki na torach (widać tylko podczas jazdy), przed zmianą psującą AA było dobrze. Domyślam się, że jak wymuszę AA w sterowniku od karty to będzie OK, ale to tylko ukryje buga. Część osób może mieć nadpisane ustawienia domyślne sterownika karty graficznej i u nich będzie się prawidłowo wyświetlać.
Domyślnie sterownik nie dotyka AA, zostawia to aplikacji.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Marca 2017, 20:15:15
Teraz jak włączymy reflektory w jednej i drugiej kabinie, smuga nagle przestaje działać.
Hmm, czy to bylo w jakims okreslonym rodzaju lokomotywy? Sprawdzajac w EU07 wyglada ze oswietlenie obu stron dziala, w dowolnej kombinacji swiatel.
Warto tez zwrocic uwage, ze przy domyslnej ilosci swiatel w .ini swiatla manewrowe latwo moga 'zniknac' jesli w poblizu jest lokomotywa z wlaczonym calym zestawem. Po prostu exe uzywa dostepnych swiatel na zobrazowanie tego, co ma wiekszy wplyw na cala scenerie. Daj wpis dynamiclights 7 I zobacz, czy to pomoze?

@HTD anti-aliasing sie znalazl i naprawil, bedzie w nastepnym uaktualnieniu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 01 Marca 2017, 20:19:48
Domyślnie sterownik nie dotyka AA, zostawia to aplikacji.
W sterowniku NVidii, można tworzyć profile do każdej aplikacji z zapisem sztywnych reguł. Kilka gier zwykle jest wpisanych już. Ale ja nie o tym, sprawdziłem jazdę z traxem w Drawinowie. U mnie nie ma żadnyh problemów z pythonem, wyświetlacz działa i nic nie wywala. Okazało się jednak, że tekstura nieba
sky sky_dynamic_stratus.t3d endskymruga w tempie 2 może 3 razy na sekundę. To potwierdza wpis EP08-015. Niestety nie wiem jak to pokazać, nie dysponuje możliwością nagrania filmu. Różnica jasności jest znaczna.
Teraz jak włączymy reflektory w jednej i drugiej kabinie, smuga nagle przestaje działać.
Nie rozumiem jak w jednej i drugiej kabinie? Ale potwierdzam, że zauważyłem na dzisiejszej kompilacji momenty wygaszania smugi (wpis dynamiclights 3).
Exeki testuje na czystej paczce dds z doinstalowaną kaliską na winXP z sp3.
ED:
Cytuj
@HTD anti-aliasing sie znalazl i naprawil, bedzie w nastepnym uaktualnieniu.
To znaczy, że zmieniłem monitor na byle jaki.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Marca 2017, 20:34:06
Okazało się jednak, że tekstura nieba
sky sky_dynamic_stratus.t3d endskymruga w tempie 2 może 3 razy na sekundę. To potwierdza wpis EP08-015. Niestety nie wiem jak to pokazać, nie dysponuje możliwością nagrania filmu. Różnica jasności jest znaczna.
Filmik EP mi wystarczy, ale niestety nie moge tego zaobserwowac u siebie. Jesli to nie problem, czy mozesz sprawdzic czy migotanie wystepuje rowniez przy wpisie
sky skydome_clouds.t3d endsky
I przy wylaczonych w ogole chmurach? (wpisem skyenabled no w .ini)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: fuji8 w 01 Marca 2017, 20:36:48
Pomogła rada @tmj, trzeba było dodać wartość 7 do "dynamiclights".
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 01 Marca 2017, 20:38:38
Zaraz też zrobię 7 we wpisie i sprawdzę niebo.
ED:
skyenabled noU mnie, nie działa. Rainsted podstawia na siłę. Mruga także:
sky sky_dynamic_stratus.t3d endskyNatomiast odpaliłem inny pojazd gdzie nie pytonowego wyświetlacza (ET22) i nie było mrugania. Muszę jeszcze przenieść traxa na inną scenerię, gdzie wiem, że mrugania niema.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 01 Marca 2017, 21:09:52
Czy tylko u mnie nie można włączyć "pauzy"? Ani klawiszem esc, ani pause :/
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 01 Marca 2017, 21:33:02
Pauza nie działa. Przeniosłem niebo sky skydome_clouds.t3d endsky
 i sky sky_dynamic_stratus.t3d endsky
na Bałtyk i mruga.
ED:
OK, znalazłem. Przeniosłem traxa na bałtyk i postawiłem obok siódemki. Odpaliłem na traxie, mruga. Odpaliłem na siódemce nie mruga. Wyszedłem z siódemki F4 i wszedłem do traxa F5, zaczęło mrugać. Po powrocie do siódemki przestało mrugać, tak wkółko. Nie wszystkie modele nieba mrugają, ale jeśli tak to tylko jak się jedzie traxem.
Nie udało mi się wyłączyć nieba wpisem w ini.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 01 Marca 2017, 21:52:19
Wygląda, że python się gryzie z niebem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Marca 2017, 21:56:37
Na 99% renderer w watku pythona wcina sie ze swoimi ustawieniami dla openGL, przestawiajac parametry uzyte do kreslenia nieba. To musi byc jakos synchronizowane, inaczej wystepowaloby nie tylko dla nieba, pytanie tylko jak :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 01 Marca 2017, 22:14:38
Może pythonowi zrobić osobny kontekst? Tekstury chyba da się udostępniać między kontekstami.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 01 Marca 2017, 22:28:07
Witam.
  Panowie walczę z tymi dl-kami, aby odpalić najnowsze exe u siebie pod XP Pro SP3. Trwało to trochę, ale mam wszystkie. Niestety przy starcie wywala błąd "aplikacja nie została właściwie zainicjowana (0xc0000142)kliknij"... itd. Przypuszczam niewłaściwą wersję którejś z bibliotek, tylko która to?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 01 Marca 2017, 22:30:42
Robiłeś restart kompa? Zablokuj jeszcze zapis pliku $.scn U mnie pomogło na wysyp symulacji z "niewiadomych" przyczyn na Quarku.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 01 Marca 2017, 22:47:22
Restartu nie robiłem. Te Dll-ki pościągałem po prostu z neta i powrzucałem do folderu z Maszyną. Tyle tylko że są różna wersje 6.3.9600.16384 albo 10.0.10586.212. Są też jeszcze inne. No i która właściwa jest?  To że mają być pod 32bit to wiadomo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 01 Marca 2017, 22:55:44
Tych z MS dll nie wrzuca się od tak do folderu z maszyną. Wysłałem Tobie PW.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 02 Marca 2017, 04:21:59
Zaraz mnie cos trafi :x

Przy testach wyszlo, ze przy aktywnym pytonie nie migaja chmury, ale niebo za nimi. Pomyslalem ze moze msci sie tutaj reczne renderowanie, bo to jednak chwile trwa wiec pyton mial wieksza szanse wciac sie w srodek ze swoim przebudowywaniem tekstury. Przerobilem niebo na VBO, zeby rysowalo sie za jednym zamachem, ale nie, mrugalo dalej. Zaczalem przepisywac pytona, zeby uzywal wlasnego kontekstu, ale wylazlo ze kazdy lok z pytonem ma swoj wlasny watek, a to by znaczylo osobny kontekst i osobne dodatkowe niewidzialne okno (bo glfw inaczej kontekstow nie robi) dla kazdej lokomotywy :|
Z ciekawosci przesunalem rysowanie nieba na pozniej, tzn po rysowaniu terenu, i przestalo migac D: ale to akurat nie rozwiazanie, bo gryzlo by sie z elementami przezroczystymi itp...

nie przedluzajac jeszcze bardziej, poprawka sprowadzila sie do recznego ustawienia 'nie uzywaj tekstury' na czas renderowania nieba.
GfxRenderer.Bind( 0 );
ot i caly fix. z jakiegos powodu przebudowanie tekstury przez pytona w trakcie psulo rysowanie geometrii, mimo ze ona tej tekstury (ani zadnej innej) do niczego nie uzywala.

Tyle z tego dobrego, ze teraz mamy niebo rysowane przez VBO zamiast recznie. Chociaz tego akurat, w odroznieniu od migotania, specjalnie nie widac :d  A takze poprawiona obsluga anti-aliasingu, jak wczesniej wspomnialem.

edit: aha, i pauza pod Esc jest naprawiona.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 02 Marca 2017, 05:50:27
Nurtuje mnie czemu nie kazde niebo mrugalo. Pauza byla pod klawiszem [pause], pod [escape] bylo przyspieszanie symulacji w debug mode (wyglada jak szybkie przewijanie obrazu do przodu). Jednak nie wiem czy ktos to uzywal, ja nie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 02 Marca 2017, 06:47:19
No prawie dobrze ;) Teraz żeby tylko z powrotem eventy od klawiszy działały. Sprawdzałem na Zwierzyńcu - próba hamulca z obsługą klawiatury numerycznej nie działa.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 02 Marca 2017, 08:39:39
Poprawka udana. Niebo w Drawinowie nie mruga, antyaliasing na 16 daje popalić przy wyszukanej jakości obrazu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 02 Marca 2017, 14:10:50
Nurtuje mnie czemu nie kazde niebo mrugalo.
Migotalo tylko to niebo ktore jest niejako "za" chmurami, wiec w sceneriach w ktorych uzyte jest statyczne niebo bez alfy migotanie (razem z calym niebem) bylo maskowane. Efekt wylazil w scenach gdzie uzyte byly polprzezroczyste chmury, pokazujace to co jest za nimi.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 02 Marca 2017, 16:46:48
Zaczalem przepisywac pytona, zeby uzywal wlasnego kontekstu, ale wylazlo ze kazdy lok z pytonem ma swoj wlasny watek, a to by znaczylo osobny kontekst i osobne dodatkowe niewidzialne okno (bo glfw inaczej kontekstow nie robi) dla kazdej lokomotywy :|
Co masz na myśli? Przecież python jest liczony tylko dla aktywnej kabiny.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 02 Marca 2017, 16:48:00
Ponieważ exe samo w sobie jest nieźle dopieszczone, postanowiłem sprawdzić jak przeciętny użytkownik poradzi sobie z instalacją paczki opartej na ostatniej kompilacji. Z mojego rozeznania wynika, że każdy z nas co miał w tym wątku problemy z odpaleniem aplikacji, radził sobie na swój sposób. Czyli inaczej. Podjąłem próbę sprawdzenia trudności jakie pojawiły się po przejściu na C++, być może jest to przyczyna małej ilości osób zabierających głos w tym wątku. Szczególnie dziwny wydał mi się brak głosu developerów, beta testerów.
Oto lista rzeczy które zrobiłem:
1. Na sformatowany dysk zainstalowałem winXP 32 bit z sp3.
2. Zainstalowałem sterowniki do płyty głównej, dźwięk, sie i pozostałe do czipsetów.
3. Zainstalowałem sterowniki do karty graficznej GF 9600GT z chłodzeniem pasywnym.
4. Zainstalowałem biblioteki MS 2013 i 2015 z podanych na w wątku linków.
5. Przeniosłem na dysk C (partycja systemowa), katalog główny symulatora. Jest to paczka, która działa na innym dysku z systemem winXP.
6. Odpaliłem rainsted, zaznaczyłem TD, wybrałem dzisiejsze exe i dostałem komunikat jak w załączniku 1.
---------
To niestety nie jest instrukcja uruchomienia, bo nie zadziałała. Moim skromnym zdaniem, należy przemyśleć sposób instalacji tak, aby była łatwiejsza dla przeciętnych zjadaczy chleba. Taki poradnik moim zdaniem jest potrzebny, trzeba go opracować i przypiąć w tym dziale.
Nie szukałem dalej rozwiązania problemu, ponieważ uważam, że już instalacja bibliotek MS jest zbyt skomplikowana, aby jeszcze szukać dalszych ekwilibrystycznych rozwiązań.
Dla mnie to teraz najpilniejszy problem.
Załącznik 2: widok instalacji systemowych.
Załącznik 3: widok katalogu głównego z maszyną.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: joey w 02 Marca 2017, 18:04:33
Odpalane na na Linuksie (Mint 17.1) + Wine 2.2, exe eu07++170302, proba nacisniecia strzalki w kabinie konczy sie efektem jak w filmie (kolor rozjasniony przez Youtube, bo lepiej widac), trzesienie kamery zatrzymuje dopiero F4.

Na TD, gdzie z natury FPS jest wyzszy, drgania sa znacznie, znacznie mniejsze, wystepuja w wiekszosci przypadkow tylko zaraz po wcisnieciu i puszczeniu strzalki i ustaja po ok. sekundzie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 02 Marca 2017, 18:19:16
Nie związane z wine, u mnie działa ok.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 02 Marca 2017, 18:29:58
To wygląda jakby przeskakiwał miedzy pozycjami lusterek prawym i lewym.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 02 Marca 2017, 18:44:33
Moim skromnym zdaniem, należy przemyśleć sposób instalacji tak, aby była łatwiejsza dla przeciętnych zjadaczy chleba. Taki poradnik moim zdaniem jest potrzebny, trzeba go opracować i przypiąć w tym dziale.
Nie szukałem dalej rozwiązania problemu, ponieważ uważam, że już instalacja bibliotek MS jest zbyt skomplikowana, aby jeszcze szukać dalszych ekwilibrystycznych rozwiązań.

W jakims stopniu moze pomoc wlaczenie czesci bibliotek do .exe, ale nie wiem na ile. Na probe skompilowalem symulator razem z CRT, i wrzucilem do paczki biblioteki, ktorych potrzebuje do uruchomienia, i z ktorymi u mnie chodzi. Wrzuc to do tego testowego katalogu, nadpisz wszystkie istniejace pliki tymi z zalacznika, i zobacz czy sie polepszy?

fake edit: i doopa, bo limit zalacznikow jest 1500kb, a archiwum ma 1520 ;/  rozdzielilem na dwie paczki
To wrzucaj na nasz upload, przedrostek bugs-, tam limit jest znacznie większy: http://eu07.pl/upload/ | @macius5991

Odpalane na na Linuksie (Mint 17.1) + Wine 2.2, exe eu07++170302, proba nacisniecia strzalki w kabinie konczy sie efektem jak w filmie (kolor rozjasniony przez Youtube, bo lepiej widac), trzesienie kamery zatrzymuje dopiero F4.
Niestety, u mnie chodzenie dziala normalnie :<  jest mozliwosc, ze wywolane jest to zmianami w obsludze poruszania sie w kabinie i wystepuje przy niskim fps, ktory nie bardzo mam jak przetestowac. Mozesz sprawdzic wartosc FPS wyswietlana pod F8?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 02 Marca 2017, 19:02:03
Nic z tego, ten sam blad. Jedyna zmiana to najpierw pokazalo sie okno o nieznanym dostawcy aplikacji z pytaniem uruchom lub nie. Odpale "starego" windowsaXp, wejde z niego w ten katalog i zrobie probe odpalenia exe.
ED:
Ze starego systemu XP ten sam katalog z dzisiejszym exe i exe+biblioteki, odpalone. W załącznikach wyniki badań. Wygląda na to, że problem tkwi w konfiguracji systemu. Stary XP postawiłem 22 marca 2015, odpala się długo, zaliczył kilka napraw. W komputerze mam teraz 2 razy XP na oddzielnych dyskach i płytę w której mogę pod F12 dedykować dysk z którego startuje OS.
ED2:
W załączniku 3, zestaw uzbieranych bibliotek i pomocy od MS na "starym" XP.Oba systemy instalowane z tej samej płyty CD i na tej samej płycie głównej komputera.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: joey w 02 Marca 2017, 20:24:52
Mozesz sprawdzic wartosc FPS wyswietlana pod F8?
Od 14.8 do 20 FPS.
To wygląda jakby przeskakiwał miedzy pozycjami lusterek prawym i lewym.
Wcisniecie ctrl+strzalka powoduje ustanie trzesienia kamera i poprawne przelaczenie do widoku lusterka, do momentu puszczenia klawiszy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 02 Marca 2017, 20:38:23
Od 14.8 do 20 FPS.
Aha, to by wyjasnialo zachowanie. Dalem poprawke, w nastepnym uaktualnieniu powinno byc uporzadkowane.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 02 Marca 2017, 20:52:56
Brak uruchomienia na czystym XP wiąże się zapewne z innym DirectX (a konkretnie DirectSound) niż na długo używanym systemie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 02 Marca 2017, 21:20:28
To ma sens, nie pamietam czy XP nie wymaga w ogole instalacji directX, bo chyba 'w pudelku' nie ma, a juz na pewno nie aktualna.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 02 Marca 2017, 21:37:40
To może jakiś check i okienko z czytelnym błędem? Można dodać do wymagań, ale tego i tak nikt nie czyta...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 02 Marca 2017, 21:40:21
Nie wiem czy sie da, bo tego typu blad wystepuje niejako jeszcze przed uruchomieniem .exe. Chociaz ten akurat troche dziwny jest, bo brak .dll z reguly wiaze sie z komunikatem o braku danej .dll, a nie takim krzakiem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 02 Marca 2017, 21:42:08
Wątpię że o to chodzi, directsound był w ...directx 8, na pewno dostarczany z XP.
PS: dependency walker pokazuje że python27.dll wymaga msvcr90.dll (vs2008). może o to chodzi?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 02 Marca 2017, 21:50:46
Jeśli .dll jest w innej wersji to występuje ten sam błąd co pokazał Krzysiu, miałem to samo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 02 Marca 2017, 22:08:52
Z porownan dat plikow wychodzi, ze mam na starym windowsie pliki z data 20160208, mimo ze jest to directx 9.0C. Na stronie MS znalazlem DX9.29,ale jego instalacja nic nie zmienila. Pozostaje skopiowac folder dllek i wkleic brakujace do nowego. System postawilem jako doswiadczalny,  nie bedzie straty.
9.0c instalowany jest z plyty xp.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 02 Marca 2017, 22:52:36
a ten redistibutable c++ 2008 sprawdzałeś?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 02 Marca 2017, 23:10:05
Bingo.
Przekopiowałem część bibliotek, ale nic to nie dało. Grzebać w tym jest trudno. Doinstalowałem redistibutable c++ 2008 i ruszyło. Teraz taka prośba o założenie wątku i przyklejenie go w dziale na warsztacie. Wątek należy zamknąć w jednym poście i publikować tam ewentualne pliki potrzebnych bibliotek, ogólnie należy zebrać co potrzeba w jednym poście, tu zrobiło się zbyt zawile. Propozycję kieruję do @tmj i @Milek7 jako, że najwięcej mogą dopomóc, a także dysponują największą wiedzą.
Mam sygnały, od przeciętnych zjadaczy chleba, że jest taka potrzeba.
PS:
Na czystym systemie podskoczył FPS
ED:
Dodałem załącznik z zawartością dodaj usuń programy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 02 Marca 2017, 23:26:50
Tak z ciekawosci, sprawdz jeszcze moze, czy uruchomi sie na tym 'czystym' systemie po odinstalowaniu Redistributable dla 2013 i 2015? 2013 jest teraz teoretycznie wlaczony do .exe, a 2015 jest dla wersji kompilowanych przez Firleju i Milka, wiec jesli bawimy sie w skonstruowanie najprostszej wersji instalacji, byc moze da sie ja odseparowac.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 02 Marca 2017, 23:35:48
2015 można odinstalować, obydwa dzisiejsze pliki obchodzą się bez tego. Po odinstalowaniu 2013 poranny i popołudniowy zawołał msvcr120.dll. na początek.
Cytuj
PS: dependency walker pokazuje że python27.dll wymaga msvcr90.dll (vs2008). może o to chodzi?
Nie widziałem tego dopisku, byłoby szybciej, dobrze że powtórzyłeś post.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 02 Marca 2017, 23:51:04
2015 można odinstalować, obydwa dzisiejsze pliki obchodzą się bez tego. Po odinstalowaniu 2013 poranny i popołudniowy zawołał msvcr120.dll. na początek.
Aha, pewnie i tak potrzebuje jej jedna z pozostalych bibliotek. Czyli w sumie moge darowac sobie wlaczanie jej do .exe, plik bedzie mniejszy.

Podsumowujac wiec, cala paczka instalacyjna sprowadzalaby sie do:
http://eu07.pl/userfiles/24014/bugs-170303.rar

jest w niej biezace .exe i dodatkowe pliki modeli dla nieba, biblioteki glfw.dll i glew.dll, i pliki instalacyjne dla vc 2008 i 2013. Instalacja powinna sie sprowadzic do wypakowania zawartosci do katalogu z maszyna, jednorazowym uruchomieniu kazdego z dwoch plikow vcredist.exe i mozna jechac.

Co do nowego watku to moze najlepiej jesli popelni go Firleju, to w sumie najbardziej jego praca a i ludzie wiecej uwagi zwroca na to co starszyzna robi ;d
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 02 Marca 2017, 23:57:17
No, racja taka, że zapomniałem Firleja wymienić. :(
Co do paczki 170303, mam na 3 dysku win7, co też nie chciało ruszyć. Tam wypróbuję ją jutro w całości. Dziś jeszcze tu na nowym xp i koniec. Także chwila jeszcze.
ED:
Pakiet działa, trzeba jeszcze taką paczkę na 64 bitowe systemy naszykować (bardzo proszę) i będzie dobrze. Nawiasem mówiąc instalki vc2008 i 2013 widać jako exeki w rainsted i można je odpalić przez rainsted.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 03 Marca 2017, 00:13:34
Wersje 64bit bedzie musial Milek zrobic, bo tylko on ma na razie dzialajaca kompilacje :)  Tam bedzie chyba trzeba dorzucic vc2015 i 64-bit wersje .dll dla pythona, i glfw.dll bedzie nowsza.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 03 Marca 2017, 00:16:03
Jutro zrobię moje buildy. Do nich trzeba jeszcze dorzucić cały folder z pythonowymi bibliotekami.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 03 Marca 2017, 00:18:35
To ja jeszcze dopytam, jest coś jeszcze dopisane/poprawione między 170302b i 170303? Oprócz tego że odchudzone o biblioteki jest.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 03 Marca 2017, 00:26:24
Jest tam mala poprawka ktora powinna teoretycznie uleczyc zgloszone miotanie sie po kabinie przy niskim FPS, poza tym roznicy o ile dobrze pamietam nie ma.

Aha, od 170302 w gore jest dodatkowa opcja w .ini
vsync yes
uzycie vsync no usuwa limit 60 (zazwyczaj fps) i symulator liczy tyle, na ile mu sprzet pozwala. Dodana glownie dlatego, ze po przejsciu na glfw i wlaczonej synchronizacji zdarzaly mi sie brzydkie spadki framerate do ~30 fps, mimo ze aktualna predkosc rysowania byla ok. 50-55. Domyslnie opcja ustawiona jest na yes, wiec dla zwyklego uzytkownika w zasadzie tak, jakby nie istniala, ale jako opcja jest.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 03 Marca 2017, 00:33:05
Mamy jeszcze jakieś pomysły na teraz? I tak już jest dziś.Dziękuję za dobrą współpracę.

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: joey w 03 Marca 2017, 00:35:45
Jest tam mala poprawka ktora powinna teoretycznie uleczyc zgloszone miotanie sie po kabinie przy niskim FPS
Uleczyla, dziala pieknie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 03 Marca 2017, 00:39:49
@Milek7, zapomniał bym, jak tam wczorajsze prace nad szaderami, wspominałeś że wieczorem coś zrobisz.
PS, ktoś poleci cichą klawiaturę, bo chcą mnie tu zamordować? @tmj, coś na rano wydłubiesz jeszcze? Zaplanować dzień chciałem.
Wyczaiłem bład na kaliskiej, Ostanie linijki logu:
Loading texture data from "dynamic\road\a4\tabr.dds"
------------------------------------------------------
init default physic values for golfj, [golf], []
LOAD FIZ FROM dynamic\road\golf\golf.fiz
CERROR: 0, SUCCES: true
check locomotive parameters...
Braked
Loading - binary model: dynamic\road\golf\golf.e3d
Dalej nie chce ruszyć na ostatnim.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 03 Marca 2017, 01:15:54
@tmj, coś na rano wydłubiesz jeszcze? Zaplanować dzień chciałem.
Ale w jakim sensie :)  jesli chodzi o jakies uaktualnienia to najprawdopodobniej przez dzien-dwa nie, bede probowal podczepic pozostale zmiany Milka i uruchomic wesje 64 bit.

Kaliska obawiam sie laduje sie u mnie normalnie na najnowszej wersji, nie wykazuje bledow ani nic :/
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 03 Marca 2017, 06:43:44
Co do chodzenia po kabinie, to coś jest nie tak. Odpalam sobie TD gdzie mam teoretycznie 100FPS. Podczas chodzenia po kabinie ekran trzęsie się, efekt jest tragiczny. Na TD to ja miałem ponad 60FPS-ów nawet na karcie wbudowanej w laptopa, i to tej gorszej z dwóch. Problemem nie jest wydajność symulatora czy silnika graficznego, tylko okropna prowizorka w obsłudze poruszania się po kabinie. Proponuję następujący oczywisty algorytm:

Klawisze strzałek powodują nadanie kamerze przyśpieszenia, które następnie jest szybko wytracane (hamowane) po zwolnieniu klawisza. Czyli klawisze sterują przyśpieszeniem, w najbardziej uproszczonym przypadku prędkością, a nie bezpośrednio pozycją kamery. Pozycja kamery musi być obliczana dla każdej klatki wyświetlania na podstawie czasu symulacji, niczego innego, dzięki temu szybkość poruszania NIE ZALEŻY od FPS.

Uproszczony zapis:
 - jeśli wciśnięto klawisz, nadaj wartość przyśpieszenia a = a1, zwiększaj dla każdego kroku symulacji (klatki) prędkość poruszania się w danym kierunku
   jako v = a * t gdzie t jest czasem symulacji niezależnym od FPS. v nie może przekroczyć oczywiście vmax.
- jeśli wciśnięto inny klawisz, ale nie zwolniono poprzedniego - nadaj wartość a = a1 dla składowej ruchu w kolejnym kierunku.
- jeśli zwolniono klawisz, nadaj wartość przyśpieszenia ujemną, czyli zmniejszaj prędkość poruszania się v = a * t, dla a = -1 aż [v = 0], czyli aż ruch w kierunku wektora przyśpieszenia nie ustanie.

Oczywiście to przesadne uproszczenie, gdyż należy wziąć pod uwagę kierunek wektora prędkości i wektora przyśpieszenia, dodawania i mnożenia wykonywać dla odpowiednich wektorów. Ruch powinien także zostać zatrzymany (poprzez wyzerowanie prędkości i przyśpieszenia) w momencie przekroczenia limitu kabiny w kroku obliczeń, musi to nastąpić przed zastosowaniem przemieszczenia kamery dla danej kratki. Czyli jeśli x = vx * t < x0 to vx = 0, ax = 0, x = x0.

To co prawda nie jest jeszcze "jak w Doomie" - ale już 100x lepiej. Koniec szarpania kamerą. Płynna animacja.

Oprócz tego bardzo bardzo bardzo przydałoby się, aby rolka myszy działała na FOV (kąt widzenia kamery) - czyli zoom z użyciem rolki.

Dalej, jeśli już ruszać kamerę: obecnie lewy i prawy przycisk myszy robią praktycznie to samo. Środkowy działa jako zoom. Opcja bardzo niewygodna. Ten sam chwilowy zoom powinien działać na prawym przycisku myszy, który jest po prostu łatwiejszy do wciśnięcia na większości myszek, co więcej, w większości gier jest właśnie wykorzystywany jako zoom. Niech lewy resetuje kamerę, albo jeszcze lepiej - np podwójne kliknięcie lewym, żeby nie wywoływało się tego przypadkowo. Środkowy przycisk myszy (klik rolką) powinien być raczej użyty do resetu samego FOV, który tą samą rolką się reguluje.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 03 Marca 2017, 11:14:46
Oto mniej więcej jak wyobrażam sobie ruch po kabinie:
https://www.codedog.pl/x/movement.html (https://www.codedog.pl/x/movement.html)

Wszystko jest w komentarzach do skryptu, można to skopiować na dysk i pobawić się parametrami.
Chodzenie działa na klawisze strzałek, sam skrypt odpala się w większości przeglądarek chromo-podobnych.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 03 Marca 2017, 11:45:24
To bardziej nadaje sie do watku: Planowane zmiany do exe. @Stele chcial jak najszybciej uzyskac stabilne exe, aby jeszce w tym roku poskladac paczke calosciowa. Prosil, aby dopiescic to co jest, naprawic znane w tej chwili problemy. Istotniejsze jest poprawienie przeliczania oswietlenia na pixele, niz zmiana sposobu poruszania sie po kabinie. Zmiana funkcji klawiszy i ppm a takze lpm i scrola, bedzie bledem. W tym roku paczka calosciowa nie moze zawierac takich zmian. Exe zostalo dopiero przepisane na c++ i po osiagnieciu stabilnosci trafic do paczki. Wymyslanie zmian, to odwlekanie wydania pc2017.
We wspomnianym watku, rodzi sie nowe zycie symulatora i dzis nawet nie wiemy jak bedzie wygladal.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 03 Marca 2017, 11:51:14
Musimy ustalić jakieś wytyczne co do stylu kodu, bo tak to będziemy się poprawiać w kółko.
Jeżeli o mnie chodzi, to preferuję:
- wcięcia tabami (przy przenoszeniu do drugiej lini taby do poziomu wcięć, później spacje do ewentualnego wyrównania argmentów)
- spacje przed otwierającym ( słowach kluczowych
- brak spacji za ( i przed )
- { w osobnych liniach
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 03 Marca 2017, 12:15:53
To bardziej nadaje sie do watku: Planowane zmiany do exe. @Stele chcial jak najszybciej uzyskac stabilne exe, aby jeszce w tym roku poskladac paczke calosciowa. Prosil, aby dopiescic to co jest, naprawic znane w tej chwili problemy. Istotniejsze jest poprawienie przeliczania oswietlenia na pixele, niz zmiana sposobu poruszania sie po kabinie. Zmiana funkcji klawiszy i ppm a takze lpm i scrola, bedzie bledem. W tym roku paczka calosciowa nie moze zawierac takich zmian. Exe zostalo dopiero przepisane na c++ i po osiagnieciu stabilnosci trafic do paczki. Wymyslanie zmian, to odwlekanie wydania pc2017.
We wspomnianym watku, rodzi sie nowe zycie symulatora i dzis nawet nie wiemy jak bedzie wygladal.
Ogarnięcie kamery jest 100x prostsze od pixel shadera. Latać też nie może. Kontrolę fov na rolce bym chciał, by ustawić porządnie kamery w ciasnych kabinach.
TMJ, Milek, ogarniacie zgłoszone bugi i wzajemnie swoją wizję? Bo ja nie. :D Jeden wątek do wszystkiego jest kłopotliwy. Jak nie chcecie tego smfowego bugtrackera, to może jakiś własny sobie zróbcie jak Ra? Albo poddział na forum i każdy problem/ficzer do rozwoju w osobnym wątku?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 03 Marca 2017, 12:16:26
W katalogu głównym masz cały styl opisany w pliku .clang_format. Użyj formatera to Ci wszystko ustali (do VS jest dostępny jako plugin).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 03 Marca 2017, 12:28:38
Ogarnięcie kamery jest 100x prostsze od pixel shadera. Latać też nie może. Kontrolę fov na rolce bym chciał, by ustawić porządnie kamery w ciasnych kabinach.
Ja też chciałem zoom, jak zapewne pamiętasz. Stosowne pliki miałem już na 1 stycznia, ale nie wyszło, nie mam pretensji, te pliki posiadało wiele osób. Ja pisałem, że fov to na [shift]+[lpm] i [shift]+[ppm], jeśli ze scrolem to pod kontrolą [shift] lub [alt]. W danej kabinie ustawiamy raz kąt widzenia i rolka nie może przypadkowo to zmienić. Latanie zdaje się poprawiono z tego co pisał zgłaszający.
PS:
Na nowym XP, odpaliłem Kaliską i dojechałem do celu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 03 Marca 2017, 12:47:13
To co prawda nie jest jeszcze "jak w Doomie" - ale już 100x lepiej. Koniec szarpania kamerą. Płynna animacja.
Dowcip polega na tym, ze mniej wiecej tak jest to robione w tym momencie. Problemy biora sie glownie z tego, ze czesc kodu obslugi kamery kabinowej (takie jak tlumienie 'szarpania' itp) jest wywolywane bez uwzglednienia czynnika dt, co prowadzi do sytuacji w ktorej wzrost fps oznacza mniejszy efekt szarpania i wolniejszy ruch kamery (bo tlumienie predkosci ruchu jest szybsze) Chyba najprostszym sposobem by to ogarnac bedzie obliczanie zmian ze stalym krokiem, podobnie jak robiona jest glowna czesc fizyki. Nie bedzie to idealne, bo dla idealnego efektu powinna byc jeszcze interpolacja miedzy wyliczonym stamen poprzednim i obecnym, ale powinno troche pomoc.

Cytuj
Oprócz tego bardzo bardzo bardzo przydałoby się, aby rolka myszy działała na FOV (kąt widzenia kamery) - czyli zoom z użyciem rolki.

Dalej, jeśli już ruszać kamerę: obecnie lewy i prawy przycisk myszy robią praktycznie to samo. Środkowy działa jako zoom. Opcja bardzo niewygodna. Ten sam chwilowy zoom powinien działać na prawym przycisku myszy, który jest po prostu łatwiejszy do wciśnięcia na większości myszek, co więcej, w większości gier jest właśnie wykorzystywany jako zoom. Niech lewy resetuje kamerę, albo jeszcze lepiej - np podwójne kliknięcie lewym, żeby nie wywoływało się tego przypadkowo. Środkowy przycisk myszy (klik rolką) powinien być raczej użyty do resetu samego FOV, który tą samą rolką się reguluje.
Zooma pod rolka nie umiescilem z dwoch powodow: po pierwsze, ze wzgledu na glosy ze niektorzy uzywaja rolki do obslugi nastawnika itp. Po drugie, jest to imo zwyczajnie mniej ergonomiczne -- zooma uzywam by zweryfikowac stan odleglego sygnalu i tutaj pojedynczy klawisz chwilowo przelaczajacy miedzy widokiem 'na dystans' i normalnym jest sporo szybsze, niz zabawa za kazdym razem z kreceniem kolkiem w przod i w tyl. Regulacja fov to cos, co widze raczej umieszczone w panelu Settings, jak juz bedzie jakies prawdziwe UI, bo takie rzeczy ustawia sie dosc rzadko. Chociaz zapewne mozna by to w miedzyczasie podpiac pod jakis klawisz w trybie debug.

Natomiast czemu srodkowy klawisz a nie prawy -- bo po wprowadzeniu obslugi mysza sensowna imo bylaby konwencja 'lewy klawisz zwieksza efekt/zalacza, prawy klawisz zmniejsza efekt/wylacza' co jest bardziej precyzyjne i szybsze niz alternatywa "trzymaj lewy i ciagnij mysz".
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 03 Marca 2017, 12:47:53
@tmj, jesteś w stanie doinstalować do VS2013 build tools 2015? To rozwiązałoby problemy z wymaganiami odnośnie bibliotek w systemie pomiędzy poszczególnymi buildami.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 03 Marca 2017, 12:57:40
Tylko różne pojazdy wymagają różnych fov do komfortowej jazdy. Nie wyobrażam sobie umieszczenia tego w mmd by skakał perspektywą przy zmianie widoku na zewnętrzny.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 03 Marca 2017, 13:17:32
@tmj, jesteś w stanie doinstalować do VS2013 build tools 2015? To rozwiązałoby problemy z wymaganiami odnośnie bibliotek w systemie pomiędzy poszczególnymi buildami.
Zobacze, chociaz nie obiecuje bo ruszanie instalacji takiego kombajnu to zawsze proszenie sie o klopoty :d
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 03 Marca 2017, 13:38:42
zmergowałem z tmj
https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng32-6545ab39.zip
https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng64-6545ab39.zip
oprócz bibliotek dołączonych w zipie do uruchomienia potrzebny jest runtime vs2015.
dla wersji 64bitowej należy przygotować sobie katalog python64: zainstalować paczkę pythona, zainstalować w niej pillow, i skopiować katalogi DLLs i Lib do katalogu python64 w symulatorze. katalog local należy przekopiować z obecnego folderu python.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 03 Marca 2017, 14:25:32
Cytuj
....dla wersji 64bitowej należy przygotować sobie katalog python64: zainstalować paczkę pythona, zainstalować w niej pillow, i skopiować katalogi DLLs i Lib do katalogu python64 w symulatorze. katalog local należy przekopiować z obecnego folderu python.....
Napisz to zrozumiale dla przeciętnego Kowalskiego co nie wie co to pillow i skąd wziącz paczkę pythona. Ja z tego rozumiem ostatnie zdanie tylko.

PS:
 miało być wyrzucone jak było puste.:)
ED:
 Zrobiłem to samo co wczoraj, ale tym razem postawiłem WIN7, doinstalowałem MS 2008, 2013 i 2015. Nie poszło na żadnym exe c++
załącznik ze stanu systemu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 03 Marca 2017, 14:38:16
instalator pythona: https://www.python.org/ftp/python/2.7.13/python-2.7.13.amd64.msi
ściągasz, instalujesz.
wciskasz win+r, wpisujesz cmd, enter. Przechodzisz do katalogu z zainstalowanym pythonem\Lib\site-packages, np. jeżeli python zainstalowany w C:\Python27_64\ to wpisujesz cd C:\Python27_64\Lib\site-packages, następnie ..\..\python.exe pip install pillow. Jak się skończy to zamykasz okienko. W katalogu z maszyną tworzysz katalog python64, i kopiujesz do niego katalogi Lib oraz DLLs z katalogu instalacji pythona. Z katalogu python w maszynie kopiujesz folder local do katalogu python64.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 03 Marca 2017, 15:03:56
@Milek7, po wykonaniu tych czynności, exe odpaliło na TD.scn, załącznik.
Dziękuję za wskazówki, proszę pamiętać, że większość z nas, nie jest obyta z lakonicznymi instrukcjami. Czy instalacja katalogu z pythonem na dysku C może być usunięta?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 03 Marca 2017, 15:09:07
tak, możesz odinstalować paczkę pythona.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 03 Marca 2017, 15:15:48
Dzięki. Jeszcze jedna rzecz mnie nurtuje, paczka instalacyjna powinna być jedna dla systemów x86 i x64. Zalety są oczywiste, takiej konfiguracji. Natomiast teraz widzę jakby rozdzielność systemu zawartości bibliotek w samym exe, jak także rozdzielność bibliotek montowanych w katalog eu07. Jak planujecie rozwiązać to zagadnienie?
Pytanie jest także do @tmj i @firlejczyka.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 03 Marca 2017, 15:29:47
Można dać obie wersje i przełączanie skryptem. Kwestia niepotrzebnego zwiększenia wagi paczki. Pythony trochę ważą
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 03 Marca 2017, 15:33:44
python to pewnie tak jak jest teraz, czyli dwa katalogi dla x32 i x64.
Co do innych dll to najlepiej by było jakby exe i dll dla niego wrzucić do osobnych katalogów. Problem jest taki, że rainsted nie potrafi uruchamiać exe z katalogów. Zgłosiłem już to kilka dni temu na bugtrackerze rainsteda.
Jeżeli nie to można pokombinować i zlinkować tak żeby oczekiwało .dll z inną nazwą dla wersji x64, tak żeby dało się wrzucić je wszystkie do głównego katalogu bez konfliktów.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 03 Marca 2017, 15:43:26
Katalogi z pythonem to jakieś 80mb obydwa. Powinny być z dystrybucją paczy lub paczek całościowych. Nie znam się na tym więc może wywołam uśmiech, ścieżka do dllek to taka jak jest do katalogu głównego, czy można by je rozdzielić (dwa katalogi), jak w przypadku pythona. Exe uwolnić od bibliotek, zostawił bym jako uniwersalne. Jeśli nie tak, to nauczyć Rainsteda odróżniać x86 od x64, niech uruchamia właściwą strukturę.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 03 Marca 2017, 15:50:51
windows szuka dll w katalogu z exe, więc nie da się rozdzielić bez wrzucania exe do innego katalogu.
ewentualnie faktycznie można zlinkować wszystko statycznie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 03 Marca 2017, 16:41:31
OK, teraz zabieramy się za problem, uruchomiłem kaliską, dwa razy, uruchomiłem td, kilka razy. Jednak nie pojeździłem. Wszystkie lokomotywy na scenerii stają. Mają tryb pod F2 Emergency_brake. Załącznik ze stanem loka, nie można ich ruszyć. WIN7 64bit i paczka od Milka7. Załącznika nie ma bo ze schowka, po wklejeniu do painta jest czarny obraz.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 03 Marca 2017, 17:11:20
heh, ctrl włączał radiostop :)
https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng32-b95af30f.zip
https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng64-b95af30f.zip

ale mnie nudzi to buildowanie dla dwóch platform, pakowanie exeków, kopiowanie z vm, wysyłanie na serwer.. chyba sobie podłączę jakieś CI na githubie
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 03 Marca 2017, 17:32:57
Milek, dałbyś z dwie godzinki czasu. To ja się produkuje, screeny robię, loga pakuje żeby potwierdzić błąd który Krzysiek zgłosił. A tu pyk i poprawiona wersja już na forum :-)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 03 Marca 2017, 17:52:53
U mnie nadal emergency_brake. Może alt+tab coś mąci, używam tego intensywnie. Albo pisanie na klawiaturze z symulatorem w tle.
Po za tym, ja napisałem o problemie po 16 godzinie, a Ty załączyłeś do poprawki exe z 15:37, jasnowidz? ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 03 Marca 2017, 18:01:42
ups, przepraszam za zamieszanie
skopiowałem exe z folder release, a zbudowałem debug ;p
https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng64-b95af30f-2.zip
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 03 Marca 2017, 18:03:51
Między czasie, wywala się bałtyk ep08. Log w załączniku, brak crasha. Wywala się na pierwszych eventach.
mam coś: załącznik.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 03 Marca 2017, 18:08:29
ok, potwierdzam.
z ciekawości, tylko u mnie czy u tmj też?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 03 Marca 2017, 18:13:04
Nie, u mnie chodzi ok. Blad jest pewnie tutaj:
Loading Python ...
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named PIL

Symulator ma jakies dodatkowe pakiety pythona o ile sie nie myle, i na golej instalacji albo ich brakuje, albo gryza sie z wersja 64bit?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 03 Marca 2017, 18:14:09
Na wersji 32 bit od tmj odpalał się bałtyk.  Ale siedzę na 64 bitowym teraz>
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 03 Marca 2017, 18:20:30
Nie, u mnie chodzi ok. Blad jest pewnie tutaj:
Loading Python ...
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named PIL

Symulator ma jakies dodatkowe pakiety pythona o ile sie nie myle, i na golej instalacji albo ich brakuje, albo gryza sie z wersja 64bit?
to nie to, psuje się gdzie indziej

@krzysiek626: to nie jest przyczyna crashu, ale wygląda jakby brakowało pillow. może ja po prostu zaraz zuploaduję ten folder python64 żeby nie było wątpliwości
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 03 Marca 2017, 18:22:47
Czemu nie mogę screenów z symulatora robić, shft+prtScr?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 03 Marca 2017, 18:39:34
widzę że są z tym problemy, wstawiam więc gotowy folder python64: https://milek7.pl/.stuff/eu07exe/python64.tar.xz

@krzysiek626: rozpakuj ten folder ode mnie i sprawdź czy już nie ma błędów z pythonem.
crashuje się w jakimś dziwnym miejscu przy wyświetlaniu displaylist, debugowanie tego trochę zajmie, visual pokazuje coś że sterta się uszkadza. tymczasowo testuj na VBO, powinno działać.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 03 Marca 2017, 18:43:16
Sprawdzę zaraz po skopiowaniu, wywaliło mnie na kaliskiej po 10 minutach symulacji nic nie dotykałem nawet klawiatury. AI. Za to nareszcie mam te crashe to załączam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 03 Marca 2017, 18:49:37
VBO sa tymczasowo wylaczone, wiec tutaj zmiana nie pomoze, i tak bedzie uzywac display lists.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 03 Marca 2017, 18:57:36
nie, na moim buildzie można wybrać vbo
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 03 Marca 2017, 19:00:09
Skopiowałem katalog python64, bałtyk się nie uruchomił. Końcówka z logu:
Player train init OK
Created texture object for "textures\smuga2.tga"
Loading texture data from "textures\smuga2.tga"
Load time: 29 seconds
EVENT LAUNCHED: onstart_zacheta
Multiple passed
EVENT ADDED TO QUEUE: baltyk_p_ms2
EVENT ADDED TO QUEUE: start
i crash w załączniku.
ED:
 Skoro tak, włączę vbo.
D2:
 Włączenie VBO skutkuje uruchomieniem Bałtyku. Nadal z schowka wklejam ciemność. Tylko w symulatorze, z pulpitu mam... pulpit.

ED3:
Psuje, na VBO zamiast szyn mam drewniane belki. Przechodzimy na epokę kamienną;)
Poważnie tak mam na Kaliskiej, w bałtyku mimo że odpaliłem nie sprawdzałem. Na gdzinę odpuszczam, nadal mam ciemność ze schowka.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 03 Marca 2017, 19:37:52
Wersja tmj 170303:
-Klawisz pause nie pauzuje. Escape tak.
-Przy pauzie nie mogę zmienić okna. EU07 zostaje na wierzchu, choć jest nieaktywne. Bez pauzy zazwyczaj się zmienia, choć i na borlandzie miałem z tym niekiedy problem.
-Strasznie ostre jest bujnięcie kamerą gdy wchodzi składowa prostopadła przyspieszenia. Odchył też, jakby maszynista miał z fotela spaść.
-Domyślna symkowa 10:30. Niebo dynamic stratus. Światło mocno niebieskie, momentami skaczące do bielszego na kilka minut. Wpis światła ma tu jakieś znaczenie?
-Znikają trójkąty o środku ~kilometr z boku kamery. Patrz załącznik. Jeziorko na Drawinowie po. Grabówek Lachy.
-Przypominam o wyłączonym modyfikatorze oświetlenia przez otoczenie we wpisie trajektorii. W tunelu widno. Przyciemnienie ścian (kolor materiału node triangles) też średnio sobie radzi z oświetleniem kierunkowym.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 03 Marca 2017, 19:45:42
-Domyślna symkowa 10:30. Niebo dynamic stratus. Światło mocno niebieskie, momentami skaczące do bielszego na kilka minut. Wpis światła ma tu jakieś znaczenie?
Wpis, raczej nie. Bez screenow trudno sie wypowiedziec, bo ta uwaga o skokach brzmi dziwnie, ale swiatlo jest niejako rozdzielone na dwa elementy -- slonce (ktore ma kolor swiatla slonecznego) i swiatlo zalamane/odbite od atmosfery, ktore ma aktualny kolor nieba, z reguly w ciagu dnia o zabarwieniu niebieskim, rano/pod wieczor rozowe/zolte. Powoduje to, ze obiekty oswietlone bezposrednio sa jasniejsze i bardziej "biale", natomiast te nie obrocone w strone slonca otrzymuja w wiekszym stopniu swiatlo odbite, i moga wydawac sie bardziej niebieskie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 03 Marca 2017, 19:54:20
Potrzebny kod na robienie skrinszotow? :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 03 Marca 2017, 19:57:39
Może zmieniała się pozycja słońca/składu i stąd różnica, ale efekt był skokowy, jakby słońce chmura zasłoniła. :P Ciężko zmianę na screenie złapać. Może w przyszłości bo dziś już nie mam cierpliwości się gapić. AI kończy przejazd. Niebo lazurowe, jak w Saint Tropez, więc pewnie stąd tak silne niebieskie zabarwienie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 03 Marca 2017, 19:58:23
O esc pisalem, ze byl do czego innego kiedy tmj pisal, ze przywrocil paze. Z kolorami nieba i atmo.... Odpal dzisiejsze wrzutki od Milk7 i porownaj. Bujania nie zaprzecze i nie potwierdze, zwyczajne 20170303 nie testowalem, posluzylo jedynie do eliminacji bledu uruchamiania exe na nowj instalacji windowsa. Ale z poprzednich wersji polecam przejechac sie kiblem i siodemka, byk jest do poprawy, tylko czy to najlepsza pora. Wyobrazam sobie ustabilizowac wczytywanie scenerii, odpalanie aplikacji i zwrocenie uwagi na latwosc instalacji paczki exe plus potrzebne biblioteki. Do wiekszych testow wydac trzeba jakis oficjalny pacz do pc z exekiem c++.
Ps, Antek, odpal na starym exe ten wagon w baltyku i na td. Jak zrobisz sceeny bedzie podobny efekt. Nie twierdze ze jest dobrze, ale mam inne priorytety.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 03 Marca 2017, 21:21:22
Stele, ty moze miales jakis problem z kompilowaniem po dodaniu tych unitow od zooma? (sccreen.cpp). Mam na mysli borladoskie exe.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 03 Marca 2017, 21:33:19
Q ty miales kilka fajnych ficzerow podziel sie z nimi. Lusterka dym ogien itd... Jak tam moj obiecany plug?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 03 Marca 2017, 21:45:13
Odpaliłem ostatnie exe, scenariusz drawinowo_noc. I mam gwiazdy na terenie i peronach.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 03 Marca 2017, 21:50:35
@EP08_015: za rok bede mial wiecej czasu na ficzery. Zreszta lepiej poczekac az sie wyklaruje fumkconalnosc exe i dopiero wtedy cokolwiek z bajerow dodawac - wtedy tez byc lepsze modele zaczna sie pojawiac.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 03 Marca 2017, 21:51:38
Stele, ty moze miales jakis problem z kompilowaniem po dodaniu tych unitow od zooma? (sccreen.cpp). Mam na mysli borladoskie exe.
Nie kompilowałem. Czekało sobie na wenę do ogarnięcia i nim ta naszła wypadł Borland.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 03 Marca 2017, 21:53:43
To dobrze, bo to raczej bedzie trzeba przystosowac do VC -  chociazby AnsiStringi wywalic, ale pewnie nie na tym sie skonczy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 03 Marca 2017, 22:37:52
Kaliska obawiam sie laduje sie u mnie normalnie na najnowszej wersji, nie wykazuje bledow ani nic :/
Naprawiłem u siebie, przy kopiowaniu paczki zrobiły się jakieś braki w katalogu dynamic. Ciekawe, utykało stojąc w nieskończoność bez żadnego komunikatu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 03 Marca 2017, 22:38:19
Odpaliłem ostatnie exe, scenariusz drawinowo_noc. I mam gwiazdy na terenie i peronach.
u mnie to w ogóle gwiazd nie ma...

tak przy okazji, dodałem robienie screenshotów pod F11. zapisują się do folderu screenshots (należy ręcznie utworzyć)
https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng32-84f54db1.zip
https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng64-84f54db1.zip
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 03 Marca 2017, 22:47:28
Przydałby się drugi komputer, nie ma szansy do jutra, aby sprawdzić foty z nowego ficzera (u Q był). Napisz jaki format i jaka kompresja, co by na forum jako załączniki można dawać.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 03 Marca 2017, 22:51:10
png, bo bezstratne. Każdy może sobie później przekonwertować na to co chce, ale jak jest potrzeba to mogę dodać jutro dodać inne (jpeg, czy tam jpeg2000)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 03 Marca 2017, 22:53:21
@Milek, ja w module od screenshotow mialem taka koncepcje, ze zapisywalo mi do folderow definiowanych w eu07.ini.  Byl tam glowny katalog do sshotow i podkatalog. Podkatalog mial sluzyc jako katalog tematyczny gdzie u mnie byl to poprostu rok, czyli np SCR/17/. Do wyboru bylo kilka formatow do ktorych mogl byc zrzucany obraz a byly to tga, bmp i jpg. Oczywiscie najbardziej praktyczny byl jpg, a dodatkowa funkcja bylo zapisywanie exif a w nim informacje o autorze, data, FoV, wspolrzedne wykonania i inne dane o scenerii takie jak ustawienia atmo, oswietlenia itp. Warto o tym pomyslec.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 03 Marca 2017, 23:56:32
Odpaliłem ostatnie exe, scenariusz drawinowo_noc. I mam gwiazdy na terenie i peronach.
Masz moze jakis screenshot? Obawiam sie, ze u mnie wyswietla gwiazdy gdzie trzeba ;/

u mnie to w ogóle gwiazd nie ma...
Do wyswietlania gwiazd potrzebny jest plik skydome_stars.t3d w katalogu models, byl dolaczany pare razy do paczki, powinien byc w tych troche wiekszych.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 04 Marca 2017, 00:08:00
png, bo bezstratne. Każdy może sobie później przekonwertować na to co chce, ale jak jest potrzeba to mogę dodać jutro dodać inne (jpeg, czy tam jpeg2000)
Pobralem wersje 32 bitowa i zainstalowalem w pacze na wczoraj postawionym xp. Musialem doinstalowac MS 2015. Screeny sa, zapis w png jak mowiles, zajmuje okolo 1.5mb przy zalozeniu 1280*1024. Brakuje klikniecia informujacego. Jak wprowadzisz jpga bedzie klawo jak cho......
@tmj, 20170304 odpalone bez najmniejszych problemow, nic nie zepsules.:) Tez na nowym xp.
Testy z jazd jutro po obiedzie. 20170303, wykonalem 3 jazdy na baltyku i jedn na Kaliskiej. Nie mam zadnych uwag. Nie psujcie tak dalej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 04 Marca 2017, 00:11:55
Dla porzadku, 170304 ma poprawiona komunikacje przez WM_COPYDATA. Troche jest tez przeorganizowana glowna petla uaktualnienia symulacji, ale tego akurat nie widac.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 04 Marca 2017, 00:19:34
Odpaliłem ostatnie exe, scenariusz drawinowo_noc. I mam gwiazdy na terenie i peronach.
U mnie 20170303 noc w Drawinowie jest gwiaździsta. Załącznik
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Paul w 04 Marca 2017, 00:48:57
Crash na 170304. Wywala się po zakończeniu wczytywania, zanim cokolwiek się wyświetli. Na 170302 efekt podobny, natomiast 170301 działa. Sugerowana przyczyna w starym sprzęcie prawdopodobna - uruchamiane na HP 550. Jutro sprawdzę na czymś nowszym. Przy okazji, log.txt twierdzi że "Compilation 2017-01-10". Można by zaktualizować lub to usunąć.

Podpis problemu:
  Nazwa zdarzenia problemu: APPCRASH
  Nazwa aplikacji: eu07++170304.exe
  Wersja aplikacji: 17.0.1175.483
  Sygnatura czasowa aplikacji: 58b9ee55
  Nazwa modułu z błędem: ig4icd32.dll
  Wersja modułu z błędem: 8.14.10.1930
  Sygnatura czasowa modułu z błędem: 4aba6fc2
  Kod wyjątku: c0000005
  Przesunięcie wyjątku: 00066b66
  Wersja systemu operacyjnego: 6.1.7601.2.1.0.256.48
  Identyfikator ustawień regionalnych: 1045
  Dodatkowe informacje 1: 0a9e
  Dodatkowe informacje 2: 0a9e372d3b4ad19135b953a78882e789
  Dodatkowe informacje 3: 0a9e
  Dodatkowe informacje 4: 0a9e372d3b4ad19135b953a78882e789
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 04 Marca 2017, 01:26:15
Interesujace, wylecialo na probie renderowania modelu nieba cgskj_overcast027.e3d, ktory z jakiegos powodu wywala blad przy ladowaniu. Przyjrze sie.

edit: ok, poprawione. Glupi blad i nie wiem jakim cudem do tej pory sie przesliznal (chyba kombinacja rzadkiego dodawania rozszerzenia do nazwy modeli, i uzywania statycznych modeli nieba) ale teraz powinno byc dobrze. Przynajmniej pod tym wzgledem :d
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 04 Marca 2017, 06:49:16
Test na zwierzyniec_transport. Zaraz po otrzymaniu wyjazdu jakaś drezyna rozpędzona do 300km/h zderzyła się ze mną czołowo. ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 04 Marca 2017, 09:28:42
Interesujace, wylecialo na probie renderowania modelu nieba cgskj_overcast027.
edit: ok, poprawione. Glupi blad i nie wiem jakim cudem do tej pory sie przesliznal
Przeslizgnelo sie, bo ja katuje Kaliska, Baltyk i Quarka. Czasem Zwierzyniec i Drawinowo. Taki blad jak u @Paula mialem na Baltyku. Wywalalo na exe od Milka, pomoglo wlaczenie VBO. Za malo nas aby szybko ogarnac wszystkie scenerie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 04 Marca 2017, 09:48:02
Interesujace, wylecialo na probie renderowania modelu nieba cgskj_overcast027.e3d, ktory z jakiegos powodu wywala blad przy ladowaniu. Przyjrze sie.

edit: ok, poprawione. Glupi blad i nie wiem jakim cudem do tej pory sie przesliznal (chyba kombinacja rzadkiego dodawania rozszerzenia do nazwy modeli, i uzywania statycznych modeli nieba) ale teraz powinno byc dobrze. Przynajmniej pod tym wzgledem :d
wrzuć źródła.
ps: a nie, jak przy ładowaniu to mi tego nie potrzeba
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Paul w 04 Marca 2017, 13:35:45
edit: ok, poprawione.

Na starym komputerze problem nie ustąpił, nadal crash na tym dll. Może faktycznie problem sprzętowy, a przez przypadek przy sprawdzaniu wylazło coś innego.

Sprawdzałem na drugim, i komunikacja WM_COPYDATA działa jak należy. Urządzenia się nastawiają, zajętości działają, można nastawiać przebiegi i jeździć. Jednak po wyświetleniu sygnałów zezwalających na jazdę pociągową na niektórych semaforach EU07 się wysypuje - konkretnie C_E, D_E, D_F w anp_test, prawdopodobnie inne z tymi samymi incami też. To są zdaje się semafory które miały być powiązane z sbl, z uwagi na umieszczenie logiki sbl w SCS ja ich używam trochę inaczej, może coś trzeba poprawić w inc ale chyba nie powinno to skutkować sypaniem się. Manewrowe, Sz na tych semaforach działają poprawnie, inne semafory i obiekty innych typów również. Po próbie wyświetlenia problematycznego sygnału EU07 jeszcze odsyła potwierdzenie przyjęcia eventu, po czym się przewraca, w oknie EU07 nie widać już wyświetlenia sygnału. W załączniku log i dmp, najpierw nastawiłem przebieg od B_F, po chwili była próba od C_E.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 04 Marca 2017, 13:53:45
Z tego co widze, wywraca sie na probie logowania nieistniejacych parametrow testowanego eventu, ale prawdopodobnie bledem jest juz to, ze te parametry nie istnieja, trudno powiedziec.
Czy moglbys podac mi jakas idioto-odporna instrukcje jak nastawiac przebiegi? Robie tak:
- uruchamiam SNSg, wybieram scenariusz anp_test
- uruchamiam symulator, z anp_test.scn i aktywna opcja multiplayer
- w okienku SCS ikona "EU07" podswietla sie na zielono
- klikam na semafor wyjazdowy, np A_H a nastepnie podwojne klikniecie (albo opcja 'koniec' z menu pod prawym) na docelowym, np B_E

... i dostaje komunikat "nie mozna ustawic przebiegu" albo podobny. Co robie zle, i co trzeba zrobic, zeby poszlo?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Paul w 04 Marca 2017, 13:59:01
Według tego co napisałeś, to robisz dobrze, tylko prawdopodobnie wybierasz zły semafor końcowy - trzeba zaznaczyć kolejne, bez pominięcia pośrednich. Dla nastawienia od A_H kliknij podwójnie na B_A. A jak chcesz do B_E za jednym zamachem, to kliknij pojedynczo na A_H, pojedynczo na B_A i podwójnie na B_E.

Uprzedzając pytanie, dla wyjazdu na szlak z sbl trzeba podwójnie kliknąć na żółtą strzałkę blokady zamiast na następny semafor.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 04 Marca 2017, 14:08:04
Ahh ok, myslalem ze wystarczy startowy i docelowy, a program sobie sam ustali przebieg "od-do". OK, sprobowalem tak jak mowisz i poszlo. Zobacze czy uda sie wylapac zrodlo wysypow.

edit: ok, wyglada to tak, ze symulator dostaje polecenie by porownac dane dla eventu np. d_em-s2 z jakimis parametrami, ktorych oczekuje w swoich danych, ale tych danych tam nie ma. Moge ustawic tutaj jakis test, zeby w takiej sytuacji dawal komunikat o bledzie do logu i nie popelnial samobojstwa, ale czy jest mozliwe, ze sytuacja spowodowana jest jakims krzakiem of strony .scn/.inc, a nie symulatora jako takiego? Czy na wersji Borlandowej dziala to normalnie?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Paul w 04 Marca 2017, 15:21:57
Ten semafor to SSd5zpcpbIW24.inc, jest tam jeszcze kilka podobnych. Problem w tym, że normalnie w jego wpisie podaje się nazwę następnego semafora (p7), i wyświetlany sygnał jest uzależniany od komórki pamięci następnego semafora. Ponieważ zależności sygnałowe realizuje SCS, w miejscu (p7) znajduje się none, i symulator próbuje sprawdzać komórkę none_sem_mem. W starych wersjach brak komórki był ignorowany i dawało się sterować sygnałami. A skoro działało, to tak zostało to rozwiązane, dzięki czemu nie trzeba było dodatkowo mnożyć inców semaforów. Można to oczywiście zmienić i dorobić wersje semaforów bez uzależnień.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 04 Marca 2017, 15:49:47
Rozwiazalem to w ten sposob, ze w przypadku takiego porownania do nieistniejacych danych symulator umieszcza wpis w logu errors, na wypadek gdyby byl to faktyczny blad, ale traktuje warunek jako spelniony, w ten sposob zachowujac sie jak stare exe. Na ile moge powiedziec, to przy takiej aranzacji wszystko dziala, udalo mi sie przeprowadzic pociagi w scenariuszu z jednego konca na drugi, w obu kierunkach. Poprawki beda w nastepnym uaktualnieniu. Do czasu gdy Milek skonstruuje komunikacje po tcp powinno wystarczyc.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 04 Marca 2017, 16:02:01
Od exe eu07++170331 nie działa odbieranie informacji przez UART z zewnętrznego mikrokontrolera zrobione przez @maćka001 i dodane od exe eu07++170226, tzn. nie da się sterować nastawnikiem, hebelkami itd. Dodatkowo, jeśli dałoby zrobić tak, aby ta komunikacja działała również wtedy, kiedy exe jest oknem w tle (przy wyłączonej pauzie, gdy w tle), to z użyciem SCSa można by na jednym komputerze obsadzić dwie osoby - maszynistę sterującego jazdą pociągu z rzeczywistego pulpitu lokomotywy i dyżurnego sterującego ruchem z aktywnego okna SCSa na drugim monitorze. Dałoby się to zrobić? Właśnie kiedy chciałem to sprawdzić, zauważyłem powyższy błąd.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Paul w 04 Marca 2017, 16:16:14
Powinno się udać, wygodniej jednak będzie SCS uruchamiać na drugim komputerze - przyszłościowo przewidziana jest taka możliwość (w aktualnie udostępnionej wersji nie zadziała, bo potrzebna jest dodatkowa aplikacja działająca jako serwer komunikacji sieciowej).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 04 Marca 2017, 16:20:19
Właśnie chodzi mi o to, żeby była też możliwość sterowania z jednego komputera. Trzeba tylko zrobić tak, żeby komunikacja z mikrokontrolerem przez UART działała też wtedy, kiedy okno exe jest w tle.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: art72 w 04 Marca 2017, 19:41:40
Najnowsze exe (170304b) pozwoliło mi zrobić rundkę w obie strony dziewiątką po Drawinowie.

Mam tylko kilka uwag:
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 04 Marca 2017, 20:02:18
Dzisiaj fps nie przekraczał 23
Sprawdz jesli mozesz, czy sytuacja poprawi sie po wpisie do .ini
vsync no
Cos tam jest nie tak na linii glfw/przelaczanie buforow ekranu/byc moze vs2013, i rezultatem jest tego rodzaju spowolnienie gdy czestotliwosc odswiezania spada ponizej czestotliwosci odswiezania ekranu, czyli zazwyczaj 60.

Zubozenie scenografii itp moze byc z tym powiazane -- renderer obniza ilosc detali i/lub zakres widocznosci przy niskim framerate.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 04 Marca 2017, 20:04:19
Ograniczanie zasięgu było u nas w kodzie i nigdy nie było tak drastyczne. Przy fps<20 była odległość rysowania na kilometr, ale nie znikały trójkąty z boku.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 04 Marca 2017, 20:15:46
Jadę właśnie w Drawinowie EP09, FPS mam prawie 60, mam inny kłopot, zamiast szyb jest kalka techniczna. Załączniki.
Ja jadę po Drawinowie z paczki całościowej. To modyfikowane w tej chwili, może nie być skończone, stąd powstrzymałbym się od oceniania braków w tej scenerii.
170304b
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 04 Marca 2017, 20:19:32
Ograniczanie zasięgu było u nas w kodzie i nigdy nie było tak drastyczne. Przy fps<20 była odległość rysowania na kilometr, ale nie znikały trójkąty z boku.
Ale art72 pisze, ze wygladalo dokladnie tak samo, jak w .exe z paczki calosciowej? :)

Co do zaniku funkcjonowania komunikacji, czy moze miec to zwiazek ze zmianami, jakie Maciek wprowadzil w ostanim uaktualnieniu? Pododawal tam chyba kila roznych przelacznikow do .ini, moze trzeba je ustawic? Pytam bo niestety nie jest to cos, co moge sensownie przetestowac -- funkcja komunikacji jest wywolywana regularnie, ale nie mam Pokeys ani niczego takiego, wiec exe nie ma sie z czym komunikowac.

edit:
Jadę właśnie w Drawinowie EP09, FPS mam prawie 60, mam inny kłopot, zamiast szyb jest kalka techniczna. Załączniki.
Ale EP09 to chyba tak akurat zrobiona jest? Na exe z paczki przezroczystosc jest mniej wiecej ta sama, tylko kolor mniej niebieski, bo oswietlenie jest biale:

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 04 Marca 2017, 20:28:33
U mnie nie wyglądało tak na exekach borlandowskich. Może wydajność spadła i ucina bardziej, ale z tymi jeziorami nie było problemu gdy przy nich majstrowąłem. Sprawdzę jak po wyłączeniu vsync.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: art72 w 04 Marca 2017, 20:29:12
@tmj, po wpisie do pliku .ini sytuacja wróciła do normy: podskoczył fps i poszczególne elementy scenerii ładnie się wczytują.

Nie napisałem o jeszcze jednym bugu. Mianowicie jakieś 100m przed lokomotywą podkłady są brzydko rysowane; tak, jakby kilka z nich oddziaływało wzajemnie na siebie w ramach "interferencyjnej podkowy". Wspomniane podkowy są skierowane ramionami na zewnątrz toru, zazwyczaj występują w parze i widać je na wszystkich torach.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 04 Marca 2017, 20:36:07
Nie napisałem o jeszcze jednym bugu. Mianowicie jakieś 100m przed lokomotywą podkłady są brzydko rysowane; tak, jakby kilka z nich oddziaływało wzajemnie na siebie w ramach "interferencyjnej podkowy". Wspomniane podkowy są skierowane ramionami na zewnątrz toru, zazwyczaj występują w parze i widać je na wszystkich torach.
Dla pewnosci przydalby sie screenshot :) Sprobuj dac w .ini
anisotropicfiltering 16
i zobacz czy sytuacja sie polepszy? To brzmi troche jak efekt mory, i bez solidnego filtrowania bedzie widoczne na elementach takich jak podklady.

Aha, sprawdzilem przy okazji EP09, i nacisniecie shift+U zapala u mnie wszystkie 3 swiatla ale kolejne nacisniecia przelaczaja miedzy zdefiniowanymi kombinacjami, wiec moze przypadkiem wcisnales shift + U wiecej niz raz?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 04 Marca 2017, 20:44:23
Nadal mam 60fps bez wpisów do ini. Synchronizacja monitora włączona. Czemu mam tak wysoki fps? Skąd taka różnica u mnie i u @art?
ED:
Podkowy na podkładach, załącznik, miejsce około słupka hektometrowego. Screen zrobiony w czasie jazdy 160/km/h
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 04 Marca 2017, 20:47:15
Prawdopodobnie na twoim sprzecie symulator jest w stanie wygenerowac wiecej niz 60 fps, wiec synchronizacja dziala jak trzeba. Jesli jestes ciekaw, tez wpisz vsync no i zobacz ile wtedy wyciagnie ;)

edit: "podkowy" sie zgadzaja, taki efekt pojawi sie przy waskich rownoleglych liniach, a te z kolei pojawiaja sie gdy teksturowana plaszczyzna jest pod duzym katem do kamery. W oryginalnej wersji symulatora bylo to do pewnego stopnia uktryte silnym rozmyciem tekstur w odleglosci wiekszej niz czubek nosa.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 04 Marca 2017, 21:16:13
Wersja 3.03.17 @tmj.
Na Drawinowie wyszedł problem z asynchronami. Traxx AI nie rusza. Zadajnik na maxa i brak siły. Przetestuję osobno na TD.
Po wyłączeniu vsync jeziorko bez zmian. 108 fps, 92 wyświetlane sektory, trójkąty nadal znikają jak się na patrzy na ich środek. Nie ruszałeś czegoś przy automacie dzielącym duże node traingles? Tam reszta terenu jest w e3d, a woda i lasy jako przezroczyste zostały w node trangles i są inaczej traktowane.
-----
Na TD lata. Odpalę się w nim na Drawinowie od początku i zobaczę co AI wyrabia.
Przypominam o braku dźwięku falownika (rwent) w asynchronach.

Startuje pod wjazdem od Grabówka. W rozkładzie ma w nim postój. Staje na W4 i coś mu odcina jazdę. Może otwiera "drzwi" na w4 i odcina jazdę? Sprawdzę na 482 i jakiegoś ezt z drzwiami na c++.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 04 Marca 2017, 21:33:20
Nie ruszałeś czegoś przy automacie dzielącym duże node traingles?
W ogole tego nie ruszalem bo tam jest zakrecone jak ruski sloik, ale nie wykluczam ze cos jest skopane. Z tym, ze poniewaz nie wiem jak to dziala, to szanse zebym to rozgryzl i poprawil sa raczej mizerne.
Docelowo i tak wolalbym przerobic teren na standardowy system siatek, chocby dlatego ze to duzo wygodniejsze w edycji i zabaw z teksturowaniem. Tzn przy zalozeniu, ze uda sie ewentualnie wprowadzic edycje scenerii z wnetrza exe.

Co do Traxxa to zgadza sie, na W4 standardowo otwiera drzwi, ale juz ich nie zamknie bo ma pod te komendy podpieta obsluge wyswietlaczy. Taki efekt uboczny uzywania tych samych klawiszy do wiecej niz jednej funkcji ;)  Zmodernizowany ET22 ma podobnie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 04 Marca 2017, 21:37:44
Ale traxx nie ma wyświetlaczy pod drzwiami od wczesnej bety. Wszystko na ekranach jest pythonem robione.
Chodzi mi o ai kierownika, próbujące otwierać drzwi na W4 i fizykę asynchronów, która odcina jazdę przy otwartych drzwiach. Gdzieś brakuje sprawdzenia czy jakiekolwiek drzwi są i się blokuje.
Te same pliki pojazdu, exe 472 borlandowskie. Nic się nie blokuje. Po odhamowaniu nadal ma jazdę.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 04 Marca 2017, 21:45:00
Nie pamietalem dokladnie, drzwi i wyswietlacz jest chyba w modernizowanej ST45. Problem z Traxxem jest troche inny, byl juz dyskutowany:

Cytuj
Przy okazji, jest taki dosc ogolny problem logiczny na styku otwierania drzwi I obslugi ekranow -- uzywaja one tych samych klawiszy, co prowadzi do roznych sytuacji, od smiesznych takich jak AI wlaczajaca/wylaczajaca ekran zamiast otwierac drzwi na stacjach (w ST45), po bardziej powazne jak 186-2 otwierajaca drzwi na przystanku, i nie bedaca w stanie jechac dalej, bo dopoki drzwi sa otwarte wlaczony jest hamulec dynamiczny, co uniemozliwia zwiekszenie ciagu, a drzwi zamknac nie moze, bo nie ma tego w konfiguracji :d
Sprowadza sie to do tego, ze dopoki dzwi sa otwarte, to hamulec dynamiczny jest zalaczony, a AI nie wysle komendy zamkniecia drzwi dopoki nie ruszy z miejsca (coby nie wachlowac nimi przy kazdym sprawdzeniu sytuacji) a nie ruszy z miejsca dopoki hamulec jest zalaczony... i takie bledne kolo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 04 Marca 2017, 21:48:23
Wyświetlacz jako lampka drzwi był w ET22, ale to chyba też zostało już poprawione. Pseudodrzwi ma na pewno ET42 jeszcze, bo tam cała sygnalizacja pulpitu i klaskon są pod to podpięte.
Powtarzam, Traxx nie ma wpisu drzwi w wersji release. Ten cytat odnosił się do wersji roboczej, przed zrobieniem mu ekranu na pythonie, gdy istotnie był włączany jako kontrolka drzwi.
Wstawiłem w to miejsce akł. Zatrzymał się otworzył drzwi i zamiast zamknąć dał zadajnik na 100%. A tu nie ma żadnego szamaństwa w fizyce. Proteza na trzaskanie drzwiami jest zbyt protetyczna, skoro pojazd z blokadą jazdy nie zamknie drzwi przed ruszeniem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 04 Marca 2017, 21:56:41
Chodzi mi o ai kierownika, próbujące otwierać drzwi na W4 i fizykę asynchronów, która odcina jazdę przy otwartych drzwiach.

IMO w przypadku TRAXXa, to póki nie ma w symulatorze wagonów PP radziłbym nie uzależniać blokady napędu od drzwi. Ba, na PP też można TAV wyłączyć i mieć samo SAT (kontrola drzwi bez blokady napędu) lub TB0 (samoczynna blokada drzwi przy V>0 podobnie jak w blokada drzwi w klasycznych wagonach).

EDIT: A jeżeli to jest kwestia AI kierownika bez względu na tabor, to tak być też nie powinno ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 04 Marca 2017, 22:06:36
@tmj, bylem nie dosc precyzyjny, szyby w dziewiatce takie sa. Nie mamy dobrego pomyslu na nie. Bylem nieprecyzyjny i wyszlo ze to wina exe, nic z tych rzeczy. Dalszy ciag, jutro.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Tomnord15 w 04 Marca 2017, 22:27:50
Ostatnia aktualizacja zepsuła możliwość wybierania nieba, przynajmniej na Quarku. Dotychczas robiłem tak, że usuwałem wpis movelight i dzięki temu mogłem jeżdzić w dzień. Po dzisiejszej aktualizacji mam cały czas noc.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 04 Marca 2017, 22:32:25
Odpaliłem swoją scenerię, exe mi się wywaliło po jakiś 7 minutach, oznak szczególnych co do przyczyn brak - w załączeniu crashdump.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 04 Marca 2017, 22:41:44
Proteza na trzaskanie drzwiami jest zbyt protetyczna, skoro pojazd z blokadą jazdy nie zamknie drzwi przed ruszeniem.
Chyba znalazlem alternatywe, ktora takze dziala, ale nie blokuje Traxxa czy jemu podobnych (a przy okazji teraz AI najpierw zamyka drzwi a potem rusza, zamiast jak do tej pory odwrotnie) W szybkim tescie na TD bylo ok, do dokladniejszego sprawdzenia bedzie w nastepnym uaktualnieniu.

Ostatnia aktualizacja zepsuła możliwość wybierania nieba, przynajmniej na Quarku. Dotychczas robiłem tak, że usuwałem wpis movelight i dzięki temu mogłem jeżdzić w dzień. Po dzisiejszej aktualizacji mam cały czas noc.
Wpis movelight okresla tylko dzien roku, a nie godzine symulacji, ktora o ile sie nie myle kontrolowana jest wpisem w sekcji time (bez tego wpisu wartosc domyslna to 10:30)  Ostatnia aktualizacja naprawila ladowanie niektorych plikow .e3d, wiec moze w tym scenariuszu jest takie wlasnie niebo (zdefiniowane w sekcji sky) ktore teraz laduje sie i zakrywa dynamiczne 'dzienne' niebo ktore jest 'pod spodem'?

edit:
Odpaliłem swoją scenerię, exe mi się wywaliło po jakiś 7 minutach, oznak szczególnych co do przyczyn brak - w załączeniu crashdump.
Wylecialo na probie odczytu parametru z RList, ale trudno tu powiedziec cos wiecej. Byc moze do sprawdzenia jest plik .fiz pojazdu, ktory byl za to odpowiedzialny.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 04 Marca 2017, 22:50:53
Trax na Drawinowie ruszył i na mój gust jedzie dobrze. Załącznik.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 04 Marca 2017, 22:55:56
W borlandowskich wpis movelight w ogóle włączał dynamiczne niebo. Bez niego było statyczne o parametrach z wpisów light&atmo.

Krzysiu, na screenie to masz wyłączone AI i jesteś przed zatrzymaniem na W4.

Jeszcze detal. Uruchamiam w trybie pełnoekranowym. Jeśli podczas ładowania zmienię okno, okno symulacji nie odświeża się do czasu załadowania. Jest nieaktywne, nie daje się przywrócić na wierzch. We wczesnych c++ chyba to działało, ale nie ma co się babrać, bo w funkcjonalności nie wadzi.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 04 Marca 2017, 23:10:17
To sie chyba wiaze z tym, ze okno symulatora odswieza sie tylko kika razy, kiedy zmieniaja sie napisy o postepie ladowania. Moze kiedys pojawi sie tam normalnie uaktualniany ekran, wtedy powinno byc jak trzeba :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 04 Marca 2017, 23:12:00
Na potrzeby screena ai wylaczylem, ale to jeszcze sprawdze. W Quarku wywalilem wszystkie wpisy i zaladowalem scenerie, co bym nie zaznaczyl mam ciemnosc. Bezposrednie wpisy nieba i atmo w scenerii nic nie daja, zawsze mam ciemno. To samo z wybieraniem w rainsted. No to odpalilem na tym z paczki, jest widno. Zreszta ta funkcjonalnosc, wybor nieba w rainsted zrobila sie bardziej skomplikowana odkad jest dynamiczne niebo.
Ed:
Potwierdzam, 170304b cos przeszkadza aby trax ruszyl spod w4 w Drawinowie. Wczesniej bylo dobrze, ale nie pamietam na ktorej wersji exe.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 05 Marca 2017, 00:52:42
Dzisiaj fps nie przekraczał 23
Sprawdz jesli mozesz, czy sytuacja poprawi sie po wpisie do .ini
vsync no
Cos tam jest nie tak na linii glfw/przelaczanie buforow ekranu/byc moze vs2013, i rezultatem jest tego rodzaju spowolnienie gdy czestotliwosc odswiezania spada ponizej czestotliwosci odswiezania ekranu, czyli zazwyczaj 60.

Zubozenie scenografii itp moze byc z tym powiazane -- renderer obniza ilosc detali i/lub zakres widocznosci przy niskim framerate.
Ale vsync tak działa - jak nie wyrobi w czasie odświeżania, to później przycina do f/2, później f/3, itd.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 05 Marca 2017, 01:53:12
Niby tak, ale do tej pory w exe go nie bylo, wiec to latwo zauwazalna zmiana. Byc moze vs2015 optymalizuje troche lepiej, bo z tego samego ujecia w Kaliskiej fps (przy vsync off) jest na poziome 61-62 czyli dosc zeby sie jeszcze wyrobic bez opoznien, ale kompilacja z vs2013 daje 58-59, czyli w efekcie ~30. Wiec majac do wyboru prawie 30 fps wiecej albo vsync, coz ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Tomnord15 w 05 Marca 2017, 10:56:42
Próbowałem uruchomić dzisiaj najnowszą wersję EP09 klasyczną na najnowszej wersji Drawinowa w misji Drawinowo noc. Pantografy się podnoszą, można uruchomić baterię, ale rozrząd, przetwornica i sprężarka nie działają. Najnowsze exe ze wszystkimi bibliotekami. W załączeniu log oraz errors. Plik crushdump nie generuje się.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 05 Marca 2017, 11:07:54
Crashdump jak sama nazwa wskazuje, generuje sie przy nieoczekiwanym zakonczeniu programu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 05 Marca 2017, 11:08:57
Tomnord: http://eu07.pl/forum/index.php/topic,28159.msg443641.html#msg443641 (http://eu07.pl/forum/index.php/topic,28159.msg443641.html#msg443641)
klika postów wyżej, to samo exe. Podaj numer loka.
OK, 043 podawanie:
Cytuj
Najnowsza
jest mało precyzyjne jak toś nie pamięta która, to po logach trzeba szukać.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Tomnord15 w 05 Marca 2017, 11:10:55
Numer EP09-043, 104E_4. Najnowsza klasyczna wersja.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 05 Marca 2017, 11:53:24
U mnie ona jeździ, sprawdzałem też 046 choć to tylko zmiana tekstury.
ED:
Moim zdaniem nie załączasz WS, za krótko trzymasz [M]. Trzymaj około 5 sekund.
ED2:
Czy istnieje wpis blokujący zapis do pliku $.scn? W Rainsted trzeba to zaznaczać za każdym razem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 05 Marca 2017, 15:14:37
Wylecialo na probie odczytu parametru z RList, ale trudno tu powiedziec cos wiecej. Byc moze do sprawdzenia jest plik .fiz pojazdu, ktory byl za to odpowiedzialny.
Tylko, jak ustalić, który to pojazd... Oki, zobaczymy, może z czasem samo wyjdzie.

Z innej beczki - da radę zrobić coś z tym niebieskim cieniem? Patrzyłem przed chwilą za okno i nijak nie widzę, żeby cienie przy słonecznej pogodzie jak dzisiaj były niebieskie... Obecnie w symulatorze wygląda to niezbyt realnie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 05 Marca 2017, 15:58:54
Mozna zmniejszyc efekt, chociaz z drugiej strony zmniejszy sie tez wplyw nieba porannego/wieczornego. Poeksperymentuje i zobaczymy.

W miedzyczasie, uaktualnienie, glownie z poprawkami:

- poprawiona logika zamykania drzwi przy odjezdzie, powinna pomoc na klopoty z traxxem itp.
- poprawiona komunikacja przez copydata, przywrocona wspolpraca z SCS
- uporzadkowana nieco obsluga kamery w kabinie, poziom drgan powinien byc teraz niezalezny od fps, w praktyce znaczy to, ze przy niskim fps bedzie sie mniej rzucac. Tutaj nalezy zwrocic uwage, ze poziom drgan zalezy tez od wpisow w pliku bodajze .mmd  Obecny poziom rzucania dobrany jest glownie na podstawie EU07/EN57, ale niektore lokomotywy maja w swoich konfigurowacjach znacznie silniejszy efekt.
- usuniete pare potencjalnych zrodel wysypow

(zalacznik usuniety, bardziej aktualna wersja ponizej)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 05 Marca 2017, 16:13:28
- usuniete pare potencjalnych zrodel wysypow
L053 sluzba tlk dalej wywala.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 05 Marca 2017, 16:23:55
Niestety, ten akurat ma miejsce w sterowniku graficznym, na tyle gleboko ze nawet nie wiadomo skad jest wywolany. Ale sprawdz, czy zaladuje ci teraz Drawinowo bez usuwania EU20?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 05 Marca 2017, 16:24:50
Potwierdzam, załącznik z komunikatem na win XP.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 05 Marca 2017, 16:30:25
Ktory to scenariusz? Bo w starterze sa trzy: l053_calkowo-sluzba-tlk, l053_calkowo-sluzba-tlk-1, l053-day-tlk83202
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 05 Marca 2017, 16:32:23
Mozna zmniejszyc efekt, chociaz z drugiej strony zmniejszy sie tez wplyw nieba porannego/wieczornego. Poeksperymentuje i zobaczymy.
Nie znam się do końca na fizyce atmosfery itp., ale wydaje mi się, że jest tu gdzieś błąd logiczny. Przy świetle dnia jest ono tak mocne, że kolor nieba nie powinien w ogóle mieć na nic wpływu. Z tego co kojarzę z własnych subiektywnych obserwacji ogólna niebieskość świata pojawia się, jeżeli słońce zajdzie za chmury i to też wyłącznie w porze zimowej, gdy jest nisko nad horyzontem. Zatem zanim zaczniemy w to brnąć zastanowiłbym się, czy zastosowana logika ma sens. Może należy to inaczej uzależnić np. właśnie od wysokości słońca nad horyzontem i obecności światła słonecznego (to tak na przyszłość, gdyby słońce zaczęły nam kiedyś chmury przesłaniać)?

Z innej beczki: nowe exe wywala mi trzy dodatkowe błędy. Przykład: "Event wolny_szlak_cal-wila_tor2 missing parameters for conditional_memcompare". Zajrzałem do eventów, a tam:
event wolny_szlak_cal-wilA_tor1 multiple 0.0 zajetosc_mac-wil wolny_szlak_cal-wil_upd condition memcompare * * 901 endevent
event wolny_szlak_cal-wilA_tor2 multiple 0.0 zajetosc_mac-wil wolny_szlak_cal-wil_upd condition memcompare * * 902 endevent
event wolny_szlak_cal-wilA_tor3 multiple 0.0 zajetosc_mac-wil wolny_szlak_cal-wil_upd condition memcompare * * 903 endevent
event wolny_szlak_cal-wilA_tor4 multiple 0.0 zajetosc_mac-wil wolny_szlak_cal-wil_upd condition memcompare * * 904 endevent
event wolny_szlak_cal-wilA_tor5 multiple 0.0 zajetosc_mac-wil wolny_szlak_cal-wil_upd condition memcompare * * 905 endevent
event wolny_szlak_cal-wilA_tor6 multiple 0.0 zajetosc_mac-wil wolny_szlak_cal-wil_upd condition memcompare * * 906 endevent
event wolny_szlak_cal-wilA_tor8 multiple 0.0 zajetosc_mac-wil wolny_szlak_cal-wil_upd condition memcompare * * 908 endevent
Nie widzę tutaj żadnego błędu, więc nasuwa się pytanie, skąd ten błąd się bierze?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 05 Marca 2017, 16:32:59
Drawinowo się uruchomilo. Natomiast nie wyswietla się pojazd eu20. Uruchomienie pojazdu wraz z wagonami powoduje jakiś tryb freefly i same wagony sa. Uruchamiane na td.

Na drugim screnie powinien być skład et22-001+eu20+chlodnie. Exe pomija tego loka przy ladowaniu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 05 Marca 2017, 16:35:16
Ewidentnie coś jest skopane z tym nowym komunikatem - jak pisałem tamtego posta miałem w tle włączony symulator i wypluło mi w międzyczasie do errors.txt prawie całą litanię eventów, w tym eventy dżwiękowe czy sterujące semaforami z plików inc. Przykład:
Event dab_zwr6_jea29_sound+ missing parameters for conditional_memcompare
Event dab_zwr3_jea29_sound0 missing parameters for conditional_memcompare
Event dab_zwr2_jea29_sound- missing parameters for conditional_memcompare
Event dab_zwr1_jea29_sound- missing parameters for conditional_memcompare
Event wil_prz1_zamykaj missing parameters for conditional_memcompare
Event cal-wilb missing parameters for conditional_memcompare
Event paszw_toe_sem_od1n missing parameters for conditional_memcompare
Event paszw_e_sem_sr1n missing parameters for conditional_memcompare
Event wil_tm17_sem_m2n missing parameters for conditional_memcompare
Event wil_k_sem_sr3n missing parameters for conditional_memcompare
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 05 Marca 2017, 16:44:40
Ciekaw jestem tego. EU04 się laduje z kabina. EU20 się nie laduje. ET21 mod i zez oraz 3e się nie laduja. Wszystkie lokomotywy laczy kran knorra ale tylko jedna z nich tzn EU04 jest załadowywana i wyswietlana (a tez nie była wcześniej). Może trzeba jakies fizyki przepatrzeć może one cos powodują? Przy okazji nie naprawiles mi działania tej lampki > i-brake_delay_r: zmcis
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 05 Marca 2017, 16:46:24
Z innej beczki: nowe exe wywala mi trzy dodatkowe błędy. Przykład: "Event wolny_szlak_cal-wila_tor2 missing parameters for conditional_memcompare".
(..)
Nie widzę tutaj żadnego błędu, więc nasuwa się pytanie, skąd ten błąd się bierze?
To wyszlo podczas naprawiania komunikacji z SCS, na poprzedniej stronie: http://eu07.pl/forum/index.php/topic,28159.msg443558.html#msg443558

W duzym skrocie, komunikat odnotowuje probe porownania z nieistniejaca(?) komorka, na wypadek gdyby byl to blad przy tworzeniu trasy, a nie dzialanie zamierzone. O ile dobrze rozumiem, to w wersji oryginalnej symulator zwyczajnie to olewal, i przyjmowal sukces.

Ciekaw jestem tego. EU04 się laduje z kabina. EU20 się nie laduje. ET21 mod i zez oraz 3e się nie laduja. Wszystkie lokomotywy laczy kran knorra ale tylko jedna z nich tzn EU04 jest załadowywana i wyswietlana. Może trzeba jakies fizyki przepatrzeć może one cos powodują?
EU20 u mnie sie laduje, ale bez kabiny. Myslalem ze to taki model dla AI ktory nie ma mozliwosci prowadzenia przez uzytkownika, ale jesli jest inaczej to sie przyjrze.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 05 Marca 2017, 16:59:44
Cytuj
EU20 u mnie sie laduje, ale bez kabiny.

Bo jubaj wywalil. Kabina jest w paczce. MMd trzeba by dopasować i będziesz miał. ALe problemem tez sa 3e ze starsza kabina i 3e mod oraz zez. One tez się nie laduja a niebyly unoffami. Zobacz 3e-30.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: maciek001 w 05 Marca 2017, 17:02:13
Od exe eu07++170331 nie działa odbieranie informacji przez UART z zewnętrznego mikrokontrolera zrobione przez @maćka001 i dodane od exe eu07++170226, tzn. nie da się sterować nastawnikiem, hebelkami itd.
Nie mam pojęcia na razie ;) Na razie proponowałbym bazować na moich exe - tych nieoficjalnych. Może uda mi się do końca tygodnia poprawić sterowanie (w zasadzie to od początku zaczynam je robić) i dorzucić do głównego repo o ile nikt nie będzie miał zastrzeżeń.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 05 Marca 2017, 17:23:46
Ewidentnie coś jest skopane z tym nowym komunikatem - jak pisałem tamtego posta miałem w tle włączony symulator i wypluło mi w międzyczasie do errors.txt prawie całą litanię eventów, w tym eventy dżwiękowe czy sterujące semaforami z plików inc.
Przyjrzalem sie dokladniej, i wyszlo ze zrobilem bledne zalozenie co do tego, jak normalne robiony jest ten test, i w rezultacie procedura wylapywala takze eventy jak najbardziej "legalne". Teraz powinno byc ok:

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Sebol82 w 05 Marca 2017, 17:31:21
Czy jest opcja posprzątania trochę i wystawienia potrzebnych bibliotek w jednej paczce?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 05 Marca 2017, 17:38:10
Kompletna paczka bibliotek itp byla chyba zamieszczona niedawno w watku, sprawdz ostatnie 2-3 strony.

Testujac dalej, @EP, 3E-30 jak najbardziej laduje sie u mnie, lacznie z kabina, i jezdzi normalnie (nawet reczny jej dziala) To jest na 'czystej' paczce calosciowej + patch 16.08 i styczniowe (chyba) uaktualnienie. Jest jakas szansa, ze robiles jakies zmiany w swojej dystrybucji?

edit: ok, watek rusza sie szybko, to bylo wiecej niz 3 strony temu. @sebol, link do paczki calosciowej: http://eu07.pl/userfiles/24014/bugs-170303.rar
exe w srodku jest sprzed paru dni, wiec zlap najnowsze z tej strony, reszta plikow powinna byc w porzadku.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 05 Marca 2017, 17:52:19
Czy istnieje wpis blokujący zapis do pliku $.scn? W Rainsted trzeba to zaznaczać za każdym razem.
Aż nie wierzę. Krzysiu specjalnie dla ciebie.
Cytuj
Wersja/17.3.125
W pliku RAINSTED.INI, w sekcji [MASZYNA] można wpisać pozycję $.scn=0, której istnienie spowoduje brak załączonego ptaszka przy opcji Zapis pliku tymczasowego. Dla przywrócenia należy zmienić na $.scn=1.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 05 Marca 2017, 18:04:36
Antek, dzięki. Tak wyszło, że rozwoju rainsteda nie śledzę i przegapiłem to. Okazuje się, że część wywaleń exeka wyeliminowałem po wykluczeniu zapisu scenerii do $.scn. Niestety nie wszystkie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 05 Marca 2017, 18:20:38
Czy możecie mi swoje fizyki i mmd wystawić? na tych z patha ostatniego mi się model nie wyswietla.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 05 Marca 2017, 18:30:15
Czy możecie mi swoje fizyki i mmd wystawić? na tych z patha ostatniego mi się model nie wyswietla.

W mojej instalacji sa takie jak w zalaczniku.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 05 Marca 2017, 18:36:04
Ok, eventy działają już prawidłowo i nie sypie w logu dziwnymi wpisami. Z błędów na razie zauważyłem, że nie działa zakładanie / zdejmowanie sygnałów końca pociągu za pomocą SHIFT+T / T.

Mam też inny, intrygujący błąd. Mianowicie uruchomienie symulatora bardzo negatywnie wpływa u mnie na inne programy działające w tle. Przykładowo jeśli przeskoczę do Firefoxa ten się natychmiast wiesza, podobnie AIMP3 (odtwarzacz muzyczny) czy nawet MS Excel. Wiesza się też pasek zadań, a razem z nim możliwość przeskakiwania między programami, a naciśnięcie Shift+Alt+Delete daje efekt dopiero po parunastu minutach. Wtedy też system jakby się odblokowuje. Nie jest to problem z tą konkretną wersją exe, ale występuje już od dobrych kilku (kilkunastu) wersji. O co tu może chodzić?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 05 Marca 2017, 18:38:37
Nie mam pojecia, nie zauwazylem u siebie tego efektu. Czy takie zachowanie bylo tez w wersji 170228 i starszych, czy wystapilo od wersji 1703.. ?

edit: wlaczanie sygnalow koncowych faktycznie bylo uszkodzone, poprawka bedzie w nastepnym uaktualnieniu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 05 Marca 2017, 18:39:57
Kaliska 75FPS w Zduńskiej Woli. Exe 170305, załącznik. Okienka przełączam bez problemu, jadę dalej, między czasie zrobiłem screena i napisałem ten post na forum i dodałem załącznik.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Sebol82 w 05 Marca 2017, 18:49:51
Mam ten sam problem co @Siecool. Mianowicie kursor myszki działa mi tylko w obrębie okna z maszyną np. 800x600 mam win7 4gb ramu stery aktualne.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 05 Marca 2017, 18:54:25
U mnie wyglada to tak, ze po uruchomieniu symulatora kursor jest niejako 'przywiazany' do okna, natomiast po przelaczeniu aktywnego program Alt+Tab porusza sie normalnie po calym pulpicie, z tym ze w obszarze okna symulatora jest niewidoczny -- pojawia sie po przesunieciu myszy "poza" okno symulatora. Podobnie jest w trybie pelnoekranowym.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 05 Marca 2017, 19:11:27
Wszystko ładnie, ale posypały się eventy na kaliskiej, wygląda tak, jakby zwrotnice przestawiały się z dużym opóźnieniem. Zwrotki przestawiają się pod taborem. Odpalałem dwa razy, ten sam efekt.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 05 Marca 2017, 19:18:36
Czy to jest na 170305, czy 170305b ? W tym pierwszym faktycznie skopana byla obsluga eventow, dlatego wyszlo 170305b
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 05 Marca 2017, 19:25:58
Nie mam pojecia, nie zauwazylem u siebie tego efektu. Czy takie zachowanie bylo tez w wersji 170228 i starszych, czy wystapilo od wersji 1703.. ?

edit: wlaczanie sygnalow koncowych faktycznie bylo uszkodzone, poprawka bedzie w nastepnym uaktualnieniu.
Sprawdzę później, w międzczasie załatwiłem Ci dwa wysypy ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 05 Marca 2017, 19:32:23
Czy to jest na 170305, czy 170305b ? W tym pierwszym faktycznie skopana byla obsluga eventow, dlatego wyszlo 170305b
Na 170305, nie zauważyłem aktualizacji, próbowałem jeszcze raz i to samo.
Zabieram się za wersję b.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Waldi 1978 w 05 Marca 2017, 19:36:45
Witam.Pobrałem nowe exe + paczka bibliotek i problem z
Linia 61 osobowy od 1 do 3 zawiesza się na pierwszej sekundzie twania symulacji.Widok z kabiny i zawieszka.
Sprawdzałem na TD,Baltyku,Drawinowie nie ma tam takich zawieszek.

System Win XP.graf.Radeon X1950 XT.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 05 Marca 2017, 19:54:25
Sprawdz jesli mozesz czy w katalogu z symulatorem pojawily sie pliki o nazwie podobnej do exe, z rozszerzeniem .dmp? Jesli tak, to byloby swietnie gdybys je tu dal jako zalaczniki.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Waldi 1978 w 05 Marca 2017, 20:07:26
@tmj nie mam, wypluwa tylko errors text.
EDIT
Dodanie log text
@Krzysiek
Umknął mi przepraszam :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 05 Marca 2017, 20:19:46
Waldi, daj chociaż log.txt to też powinieneś mieć. 170305b, eventy na kaliskiej poprawne.
Trax w drawinowie też rusza spod W4. Exe nic mi nie wiesza, programy które odpalone są razem z symkiem to FF, okno czatu, paint, do tego notatnik i sporadycznie jakieś winrary lub ściąganie czegoś z netu. Tyle, że ja mam postawiony w tym tygodniu świeży system. Więcej dziś nie zrobię.
ED:
Potwierdzam wieszanie się na L061 osobowy 1 do 3. Ukazuje się kabina i dalej już nic nie można, nawet F10 nie działa, zamknąć trzeba na konsoli iksem, W załączniku log.
ED2: Waldi, mamy ten sam błąd.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 05 Marca 2017, 20:36:28
Sory, że post pod postem, ale nie chcę by umknęło. Zaremowałem wpis pliku include linia61/l61_auta.scm end na LO061. Sceneria wczytała się poprawnie, któryś z pojazdów jest trefny i raczej dziś już go nie namierzę. Choć nie twierdzę, że nie spróbuję.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 05 Marca 2017, 20:46:46
61 osobowy u mnie sie wczytuje, z tym ze plik na pewno nie jest calkiem zdrowy bo wyglada jak w zalaczniku, i produkuje garsc bledow "scene parse error". Ale na oficjalnym exe zachowanie i wyglad jest ten sam. Nie wiem czy to tak ma byc, czy jest skopane lokalnie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 05 Marca 2017, 21:12:28
W załączniku pojazdy które musiałem wywalić. Inaczej L061 się wiesza. Nie mam pojęcia czemu. Nie mam namieszane w pliku, screen mam poprawny.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 05 Marca 2017, 21:20:46
@tmj: ja się na tym nie znam co to robi, mógłbyś na to zerknąć?
Ground.cpp:InitNormals:193:
        for (i = 2; i < iNumVerts - 2; i += 2)
        {
            v4 = Vertices[i - 1].Point - Vertices[i].Point;
            v5 = Vertices[i].Point - Vertices[i + 1].Point;
            n3 = SafeNormalize(CrossProduct(v3, v4));
            n4 = SafeNormalize(CrossProduct(v5, v4));
            if (Vertices[i].Normal == vector3(0, 0, 0))
                Vertices[i].Normal = (n1 + n2 + n3) / 3;
            if (Vertices[i + 1].Normal == vector3(0, 0, 0))
                Vertices[i + 1].Normal = (n2 + n3 + n4) / 3;
            n1 = n3;
            n2 = n4;
            v3 = v5;
        }
        if (Vertices[i].Normal == vector3(0, 0, 0))
            Vertices[i].Normal = (n1 + n2) / 2;
        if (Vertices[i + 1].Normal == vector3(0, 0, 0))
            Vertices[i + 1].Normal = n2;
Jeżeli iNumVerts jest nieparzyste to Vertices[i + 1] jest juz poza tablicą. Mogę tam po prostu wlepić ifa ale nie chcę popsuć tych obliczeń.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 05 Marca 2017, 21:22:18
To exe jest jakies nienormalne. 2 razy na swiezej paczce uruchomiłem linie 53 scn tlk i raz kaliska. Kolejna proba uruchomienia tych samych scenerii skutkowało wywaleniem do windy. CHore. Robie sobie przerwe na 2 tyg od tego. Nie bede mial juz czasu na papranie sie z tym. Teraz w robocie bede mial wiecej pracy wiec i czasu na te papranine bedzie mniej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: loko w 05 Marca 2017, 21:31:02
Ja póki co sprawdziłem przejezdność misji EP09-005 ze scenerii Krzyżowa2 i jest przejezdna do końca na eu07++170305b.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 05 Marca 2017, 21:49:34
@tmj: ja się na tym nie znam co to robi, mógłbyś na to zerknąć?
(..)
Jeżeli iNumVerts jest nieparzyste to Vertices[i + 1] jest juz poza tablicą. Mogę tam po prostu wlepić ifa ale nie chcę popsuć tych obliczeń.
Z tego co widze, to tam sie licza wektory normalne, w tym przypadku dla triangle strip. Tutaj odwolania do wierzcholkow powinny byc chyba cofniete o 1, tzn
i - 1 powinno byc i - 2
i powinno byc i - 1
i + 1 powinno byc i

ale trzeba by to przetestowac, bo ten skok wartosci i o 2 jest dziwny, triangle strip tworzy kolejne trojkaty na podstawie jednego punktu + 2 poprzednie/startowe, a nie dwoch. Moze na poczatek daj zwykly assert i zobacz czy gdziekolwiek wyleci, bo moze byc tak, ze symulator uzywa triangle strip tylko do takich rzeczy jak drogi i tory, czyli praktycznie daje gwarancje, ze liczba wierzcholkow zawsze jest parzysta.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Mariusz1970 w 05 Marca 2017, 22:11:13
Jeśli chodzi o triangle_strip, taki includ stodoladrewn01detal.inc
//--------stodola
//param: tekstura_dachu x y z kat

origin (p2) (p3) (p4)

rotate 0 (p5) 0

// front

node 1000 0 none triangle_strip wood/WoodRedBrown2_agedPlanks
0 0 7 0 0 0 5 3 end
0 0 2 0 0 0 0 3 end
0 3 7 0 0 0 5 0 end
0 3 2 0 0 0 0 0
endtri

node 1000 0 none triangle_strip wood/WoodRedBrown1_Planks
0 0 2 0 0 0 4 3 end
0 0 -2 0 0 0 0 3 end
0 3 2 0 0 0 4 0 end
0 3 -2 0 0 0 0 0
endtri

node 1000 0 none triangle_strip wood/WoodRedBrown2_agedPlanks
0 0 -2 0 0 0 5 3 end
0 0 -7 0 0 0 0 3 end
0 3 -2 0 0 0 5 0 end
0 3 -7 0 0 0 0 0
endtri

// tyl

node 1000 0 none triangle_strip wood/WoodRedBrown2_agedPlanks
-6 0 -7 0 0 0 0 3 end
-6 0 7 0 0 0 10 3 end
-6 3 -7 0 0 0 0 0 end
-6 3 7 0 0 0 10 0
endtri

// sciany szczytowe

node 1000 0 none triangle_strip wood/WoodRedBrown2_agedPlanks
0 0 -7 0 0 0 0 0 end
-6 0 -7 0 0 0 6 0 end
0 3 -7 0 0 0 0 3 end
-6 3 -7 0 0 0 6 3 end
-3 6 -7 0 0 0 3 6
endtri

node 1000 0 none triangle_strip wood/WoodRedBrown2_agedPlanks
-6 0 7 0 0 0 6 0 end
0 0 7 0 0 0 0 0 end
-6 3 7 0 0 0 6 3 end
0 3 7 0 0 0 0 3 end
-3 6 7 0 0 0 3 6
endtri

// dach

node 1000 0 none triangle_strip (p1)
0.5 2.5 7.2 0 0 0 10 3 end
0.5 2.5 -7.2 0 0 0 0 3 end
-3 6 7.2 0 0 0 10 0 end
-3 6 -7.2 0 0 0 0 0
endtri

node 1000 0 none triangle_strip (p1)
-3 6 7.2 0 0 0 10 0 end
-3 6 -7.2 0 0 0 0 0 end
-6.5 2.5 7.2 0 0 0 10 3 end
-6.5 2.5 -7.2 0 0 0 0 3
endtri

// dach - podbitki

node 1000 0 none triangle_strip wood/WoodGrayBrown1_Planks
-3 6 7.2 0 0 0 3 0 end
-3 6 -7.2 0 0 0 0 0 end
0.5 2.5 7.2 0 0 0 3 1 end
0.5 2.5 -7.2 0 0 0 0 1
endtri

node 1000 0 none triangle_strip wood/WoodGrayBrown1_Planks
-6.5 2.5 7.2 0 0 0 3 1 end
-6.5 2.5 -7.2 0 0 0 0 1 end
-3 6 7.2 0 0 0 3 0 end
-3 6 -7.2 0 0 0 0 0
endtri

rotate 0 0 0

endorigin
i dziala (raczej :P )
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 05 Marca 2017, 22:39:51
no właśnie wylatuje, na bałtyku, na innych nie sprawdzałem. (co ciekawe tylko na buildzie x64)

dodałem ifa i wpis do loga, zmergowane to co tam tmj wrzucił na gita
https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng32-b65dd1a7.zip
https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng64-b65dd1a7.zip
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 05 Marca 2017, 23:36:25
Witam.
Nie wiem czy to celowe, ale na exe Tmj 170305b smuga oświetla również podczas symkowego dnia. Widać to dość dobrze podczas jazdy. Druga sprawa, mam odczucie jakby tekstury bardziej migotały niż na poprzednich wersjach.
Pozdrawiam
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 06 Marca 2017, 00:34:42
W załączniku pojazdy które musiałem wywalić. Inaczej L061 się wiesza. Nie mam pojęcia czemu. Nie mam namieszane w pliku, screen mam poprawny.
Odrestaurowalem linie 61 z paczki calosciowej + patch, i teraz laduje sie jak trzeba, a przy tym tez blokuje sie zaraz po starcie. Z tego co widze, to cos jest nie tak albo z ladowaniem/polaczeniem/skanowaniem niektorych drog, albo przeliczaniem ruchu. Na zalacznikach jest przyklad jednego z tych problematycznych samochodow, w exe c++ i oficjalnym: na samym starcie zanim cokolwiek jest liczone, drogi i polozenie pojazdow wyglada tak samo, ale po wylaczeniu pauzy w oficjalnym exe jelczostar jedzie normalnie do przodu, a w c++ teleportuje sie natychmiast na sam poczatek drogi, a  exe glupieje. Zeby bylo smieszniej w trybie debug wszytko chodzi jak trzeba, wiec albo cos tam jest nieinicjalizowane albo nadpisywane, trudno powiedziec.

edit: ciekawostka, wycialem ze sceny wszystko oprocz drog, torow i pojazdow, i wszystko jezdzi normalnie, bez dziwnych teleportacji. Czyli jakis inny element sceny sika tu exe do mleka.

edit2: ok, krasnoludkiem okazal sie wpis camera w jednym z plikow scenariusza. Zeby bylo smieszniej to nawet nie wiadomo czemu, bo na pobiezny rzut oka wszystko w kodzie definicji kamer bylo wpisywane gdzie trzeba, a nie gdzies na zewnatrz. Tak czy inaczej po zmianie tablicy na std::vector przestalo sie sypac.

Nie wiem czy to celowe, ale na exe Tmj 170305b smuga oświetla również podczas symkowego dnia.
W pewnym sensie, tzn sila swiatel pozostaje stala, natomiast efekt na otoczeniu zalezy od oswietlenia, jakie to otoczenie otrzymuje z innych zrodel (slonce + niebo) Na razie nie robilem tego dokladniej bo nie bylem pewien, jak to wyglada w naturze, ale patrzac na youtube to w ciagu dnia efekt jest praktycznie zaden, wiec to jest to poprawienia.

Sprawdzę później, w międzczasie załatwiłem Ci dwa wysypy ;)
Pamietasz moze, w jakich okolicznosciach to sie stalo? Tzn na jakiej trasie, i czy od razu, czy kiedy robiles moze cos specyficznego. Moze sa jakies wpisy w errors.txt (oprocz tradycyjnych o braku tekstur i takich tam ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 06 Marca 2017, 07:57:08
To exe jest jakies nienormalne. 2 razy na swiezej paczce uruchomiłem linie 53 scn tlk i raz kaliska. Kolejna proba uruchomienia tych samych scenerii skutkowało wywaleniem do windy. CHore. Robie sobie przerwe na 2 tyg od tego. Nie bede mial juz czasu na papranie sie z tym. Teraz w robocie bede mial wiecej pracy wiec i czasu na te papranine bedzie mniej.
Włodku, czego Ty się spodziewasz? Nie ma tak, że ktoś przepisze i będzie działać. To nie jest dyktando, gdzie do wyłapania błędów wystarczy przeczytać. Dziennie odpalam kilkadziesiąt razy exe z jakąś scenerią, w przypadku L61 osobowy odpaliłem ponad 40 razy w ciągu 90 minut, eliminując po kolei trefne wpisy. W tym wątku pracujemy na stabilność exe i jego jak najlepsze wyniki. Jeszcze o Kaliskiej napiszę, że na niej masz wysypy odkąd jest ta sceneria, nawet na exe z paczki, o tym pisałeś wielokrotnie. Odpocznij i przemyśl co w tym wątku robimy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: art72 w 06 Marca 2017, 16:30:11
Krzysiek ma w 100% rację - nie ma powodów do "fochania".

Usuwanie bugów z aplikacji to mrówcza praca ale cieszy fakt, że topik cieszy się sporym zainteresowaniem. I co więcej, @tmj w ramach koleżeńskiej współpracy natychmiast modyfikuje kod programu.

Cenna inicjatywa tym bardziej, że na ogół informatycy, którzy umieją zrobić coś konkretnego albo liczą sobie krocie za świadczone przez siebie usługi albo trudno się z nimi rozmawia. Bo żyją w swoim, wypełnionym elektronicznymi rozkazami, świecie ;)

[EDYTA]

Nadal mam 60fps bez wpisów do ini. Synchronizacja monitora włączona. Czemu mam tak wysoki fps? Skąd taka różnica u mnie i u @art?

Krzysiu, różnice w ilości wyświetlanych klatek/sekundę mogą być pochodną małej ilości posiadanego przeze mnie RAMu: tylko 2GB.

Na XP-ku wystarczała do wszystkiego, na siódemce przydałoby się co najmniej drugie tyle.
(swoja drogą - to jakaś chora polityka, żeby "goły" system "zjadał" blisko połowę zasobów sprzętowych)

Ale nie chcę już inwestować w mojego blaszanego złoma - kości DDR2 produkcji Kingstona pewnie będą kosztowały majątek.
(no i, jak powszechnie wiadomo, kupno nowych RAM-ów ma niski WAF czyli Wife Acceptance Factor :D)

W dodatku mam 32-bitowy system, dlatego możliwość ewentualnego rozszerzenia pamięci jest mocno ograniczona.

PS. z imieniem oczywiście dobrze trafiłeś ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 06 Marca 2017, 17:15:56
Pamietasz moze, w jakich okolicznosciach to sie stalo? Tzn na jakiej trasie, i czy od razu, czy kiedy robiles moze cos specyficznego. Moze sa jakies wpisy w errors.txt (oprocz tradycyjnych o braku tekstur i takich tam ;)
Wszystkie wysypy na tej samej scenerii i misji, niestety jeszcze nieopublikowanej, ale jak będziesz chciał to mogę podrzucić. Co do czasu to pierwszy wysyp nastąpił chyba po 2h jazdy, drugi natomiast po 8 minutach. Generalnie jest to ta sama sceneria i misja, co pisałeś o błędzie z RList tylko nie wiem niestety, jakiego pojazdu to się tyczy. Errors pokazuje to co zwykle - brak passengers.t3d w wagonach plus dwa razy brak animations tag - w st44, którym jechałem i wagonach 203vb (Flls). Te dwa wysypy też wyleciały na sczytywaniu RList czy coś innego?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 06 Marca 2017, 17:24:16
Dałem Milkowi devsa, więc obaj nasi programiści maja dostęp do scenerii już. :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 06 Marca 2017, 17:41:08
Te dwa wysypy też wyleciały na sczytywaniu RList czy coś innego?
Tak, w tym samym miejscu co poprzednio. Problem w tym, ze nie ma gwarancji ze wylatuje akurat na tej linii, dlatego chcialbym jesli mozliwe wywolac ten blad u siebie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 06 Marca 2017, 18:01:41
Zajrzyj tutaj: http://eu07.pl/forum/index.php/topic,26934.msg444039.html#msg444039
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 06 Marca 2017, 18:32:57
@Milek7, katowałem twoje exe, i jak dotąd nie udało mi się wywalić je do windy. Męczyłem wersję 32 bitową na nowo postawionym win xp. Nawet raz odpaliłem dwa razy, jednocześnie załadowałem Drawinowo i L053. Jeśli wyłączyć zapis do plik $.scn, to rainsted uruchomi aplikację drugi a nawet trzeci raz. Mimo 100% mocy wykorzystania procka i gorącej grafiki oba scenariusze ukończyłem.
@tmj, oprócz L61 osobowy, wszystkie scn załadowały się bez problemu. Jednak, trzeba by sprawdzić czy okresowe wysypy u mnie na Quarku, również nie są powodowane przez wpisy samochodów. Rano wszystkie usunąłem i wysypy ustąpiły.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 06 Marca 2017, 19:02:31
@Milek7, jest gdzies do sciagniecia skompilowany .lib itp dla libpng, czy trzeba je sobie recznie skladac? ;/
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 06 Marca 2017, 19:04:55
ręcznie. dołączyłem mój, ale robiony na vs2015 więc nie wiem czy kompatybilny
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 06 Marca 2017, 19:28:32
Bleh. Dzieki, sprawdze pozniej. BTW, sizeof(TSubModel) przy kompilacji VS2013 to 300 bajtow, nie 256 (308 w trybie debug) ale po usunieciu testu wyglada na to ze dziala ok, przynajmniej jesli chodzi o ladowanie .e3d  Byc moze kwestia ustawien kompilacji, nie wiem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 06 Marca 2017, 19:36:32
mówisz o moim kodzie? tam jest zrobiona serializacja każdego pola osobno, więc wielkość nie ma znaczenia.
a jeżeli chodzi o oryginalny to raczej się posypie, bo wczytywanie/zapisywanie do pliku to bezpośrednie kopiowanie pamięci.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 06 Marca 2017, 19:56:14
mówisz o moim kodzie?
W World::Init jest taki kawalek na poczatku
if( sizeof( TSubModel ) != 256 ) {
Error( "Wrong sizeof(TSubModel) is " + std::to_string(sizeof( TSubModel )) );
return false;
}
i po polaczeniu symulator of razu sie na tym zamykal, bo wielkosc objektu jest teraz inna. Myslalem, ze to cos od ciebie, ale jak teraz sprawdzam to jest w kodzie od dawna, i po zmianach sie aktywowal, ale wyglada na to ze na 2015 sie nie czepia, jesli przeszedl niezauwazony :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 06 Marca 2017, 20:00:28
obecnie tego checka u mnie nie ma. jak mergujesz to musisz raczej z najnowszym, bo commity mogły być niepełne lub mieć krytyczne bugi naprawione dopiero w późniejszych.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 06 Marca 2017, 20:27:17
Hmm dalem mu fetch/pull tuz przed merge, wiec powinno byc najnowsze, w history pokazuje ze to stan na 22:34 z wczoraj. Nie wiem czemu tego kawalka nie wylapal, zrobie pozniej compare.

Tak czy inaczej, dzisiejsze uaktualnienie w zalaczniku. Ma teraz (teoretycznie) wszystkie zmiany od Milka, minus zgrywanie zrzutow ekranu, bo wyglada na to ze lib z 2015 mu nie pasuje, bede musial zrobic swoj. Dodatkowo poprawki z wczoraj:
- przywrocona obsluga uruchamiania eventow z klawiatury
- poprawka obslugi definiowanych kamer, nie powinno wiecej wieszac sie na l61_osobowy
- przywrocone umieszczanie sygnalow koncowych
- reflektory lokomotyw w ciagu dnia maja znikomy (czytaj zerowy) efekt
- moze cos tam jeszcze, czego nie pamietam

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 06 Marca 2017, 20:42:19
L61, nie wiesza symulacji. Co prawda trzeba by przejechać całą scenerię chociaż raz, aby być pewnym. Lamp nie widać, w porównaniu z wczorajszym, gdzie był odblask na słupach sieci.
Coraz bardziej niebiesko jest?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: dymus w 06 Marca 2017, 21:20:20
Pusta sceneria, brak zdefiniowanych eventów i shift+3 wywołuje efekt jak Radiostop (spadek ciśnienia w przewodzie), to samo na np. Bałtyku i pewnie na innych sceneriach.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 06 Marca 2017, 21:21:53
Potwierdzam, uruchomienie radiostopu na TD.scn
ED:
Brak terenu w Drawinowie, załącznik. Drawinowo: shift+3 hamowanie opróżnienie PG, ale brak ciśnienia w cylindrach hamulcowych EP09.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 06 Marca 2017, 21:32:16
Tak, zaplatalo sie pod klawisz 3, powinno byc ctrl+pause. Bedzie poprawione w nastepnej wersji.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 06 Marca 2017, 21:33:48
W misji l61_osobowy2 taki oto błąd:
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 06 Marca 2017, 21:38:49
@pbzylek, masz to samo co ja w Drawinowie. Sreen w poprzednim poście. Na poprzednim exe mam ok.
To hamowanie awaryjne było już na 170305b
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 06 Marca 2017, 21:40:33
Ja również na poprzednim exe poprawnie miałem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 06 Marca 2017, 22:17:02
Mozna dostac jakiejs wspolrzedne gdzie te dziury sa, spod F2? Bo dralowac przez cala scenerie to troche nieciekawy prospect jest :d

Drawinowo ma u mnie dziure w okolicy tuneli (i mialo od dawna, wiec to nie wina ostatniej modyfikacji) ale akurat ta stacja wyglada normalnie :/

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 06 Marca 2017, 22:22:41
Drawinowo, u mnie to tak jakby w zasiegu wzroku bylo w okol stacji. Dalej nie zapuscilem sie. L061 sprawdzalem tylko wysyp na tyc kamerach, tez nie zpuszczalem sie w glab. Przejechalem calego Quarku, tu ciemnosc, ale nic nie rzucilo sie w oczy. Zerknalem tez na manewrowo, tam jest ok. Na dzis to tyle, mam inne zajecia w domu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 06 Marca 2017, 22:25:45
Zarówno Drawinowo jak i l61 (wersja Ra) mają teren wczytywany z e3d. Tu bym szukał przyczyny. Ze dwa dni temu wczytywało go poprawnie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 06 Marca 2017, 22:28:45
Drawinowo, u mnie to tak jakby w zasiegu wzroku bylo w okol stacji. Dalej nie zapuscilem sie. L061 sprawdzalem tylko wysyp na tyc kamerach, tez nie zpuszczalem sie w glab. Przejechalem calego Quarku, tu ciemnosc, ale nic nie rzucilo sie w oczy. Zerknalem tez na manewrowo, tam jest ok. Na dzis to tyle, mam inne zajecia w domu.
A na moim exe w drawinowie nie było dziur? Bo oprócz tych screenshotów to praktycznie żadnych znaczących różnic nie powinno być teraz między moimi exekami a tmj.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 06 Marca 2017, 23:14:33
Witam.
 Z tym błędem przy wczytywaniu terenu to loteria jest. Wczoraj na L61 miałem brak terenu, dzisiaj wczytał się poprawnie. To samo exe Tmj 170305b, ta sama misja. Sprawdziłem też opisywany problem ze służbą osobowy 1-3. Uruchomiłem dwójkę, i co ciekawe sceneria została wczytana normalnie. Errors wygenerował co prawda jakieś błędy, ale nic poza tym. Czy to może od komputera zależy sam nie wiem. Byłbym zapomniał, korzystam z Lini61 w wykonaniu Ra.
Pozdrawiam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 06 Marca 2017, 23:34:54
A na moim exe w drawinowie nie było dziur? Bo oprócz tych screenshotów to praktycznie żadnych znaczących różnic nie powinno być teraz między moimi exekami a tmj.
Cos w przepisanym ladowaniu jest zakrzaczone raczej na pewno -- dla przykladu, ta beta calkowo v2 ktora robi Siecool wgrywa sie z pustym terenem, natomiast na starej kompilacji teren pojawia sie poprawnie. Blad jest zarowno na twoim exe jak i ostatnim moim, wiec to raczej nie kwestia ze cos selektywnie skopalo sie przy portowaniu.

dla ulatwienia debugowania, mozesz w pliku calkowo_v2_zdawczyB_pom.scn zakomentowac /* */ wszystko ponizej linii
node -1 -1 none model 0 0 0 0 slimson/calkowo_v2/calkowo_v2_teren.t3d none endmodel
W ten sposob bedzie ladowalo tylko obiekt terenu, ktory sie nie wyswietla.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 07 Marca 2017, 08:12:08
ok, sprawdzę po południu
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 07 Marca 2017, 09:29:32
Znowu mi wrócił błąd float to GLUint. Gdzie w opcjach się wywala ten error?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 07 Marca 2017, 10:05:10
Drawinowo, u mnie to tak jakby w zasiegu wzroku bylo w okol stacji. Dalej nie zapuscilem sie. L061 sprawdzalem tylko wysyp na tyc kamerach, tez nie zpuszczalem sie w glab. Przejechalem calego Quarku, tu ciemnosc, ale nic nie rzucilo sie w oczy. Zerknalem tez na manewrowo, tam jest ok. Na dzis to tyle, mam inne zajecia w domu.
A na moim exe w drawinowie nie było dziur? Bo oprócz tych screenshotów to praktycznie żadnych znaczących różnic nie powinno być teraz między moimi exekami a tmj.
Niestety też, załącznik. U mnie za każdym razem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 07 Marca 2017, 10:21:03
Witam.
 Z tym błędem przy wczytywaniu terenu to loteria jest. Wczoraj na L61 miałem brak terenu, dzisiaj wczytał się poprawnie. To samo exe Tmj 170305b, ta sama misja. Sprawdziłem też opisywany problem ze służbą osobowy 1-3. Uruchomiłem dwójkę, i co ciekawe sceneria została wczytana normalnie. Errors wygenerował co prawda jakieś błędy, ale nic poza tym. Czy to może od komputera zależy sam nie wiem. Byłbym zapomniał, korzystam z Lini61 w wykonaniu Ra.
Pozdrawiam.
Nie potwierdzam że to loteria, mam za każdym razem na exe od @tmj 170306 i ostatnim @milka7 (32bitowym), natomiast na 170305B mam zawsze poprawnie, załącznik 2.
Nie uruchamiam L061 od @Ra, tylko to z paczki całościowej. Jak pisałem w innym wątku, Drawinowo od @Ra jest w trakcie zmian, więc nie wiadomo czy tam się coś dodatkowo nie sypie. A szukać czy to sceneria, czy exe jest winne, nie chce mi się. Sprawdzam na sceneriach, których zachowanie potrafię przewidzieć.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 07 Marca 2017, 10:43:59
ok, nie trzeba już testować.
później zobaczę co się tam zepsuło
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 07 Marca 2017, 14:01:32
Na probe cofnalem pliki model3d do wersji poprzedniej i teren wrocil do normy, ale podejrzewam, ze problem moze byc nie w samym ladowaniu, a np w funkcjach ktore obrabiaja plik terenu -- jesli tam sa jakies sztywne zalozenia co do struktury, offsetow itp, to po zmianach cos tam sie moze rozjezdzac.

edit: znalazlo sie. Przy konwersji zgubiles ten kawalek w BinInit():
        if( Opacity < 1.0 ) // przezroczystość z tekstury brana tylko dla Opacity 0!
            iFlags |= GfxRenderer.Texture( TextureID ).has_alpha ?
            0x20 :
            0x10; // 0x10-nieprzezroczysta, 0x20-przezroczysta
        else
            iFlags |= 0x10; // normalnie nieprzezroczyste
w rezultacie teren nie mial ustawionych flag widocznosci. Po dopisaniu z powrotem wyswietla sie normalnie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 07 Marca 2017, 15:02:32
Hamowanie pod shft+3 usunąłeś?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 07 Marca 2017, 15:02:59
już wywęszyłem że to problem z flagami, ale ubiegłeś mnie :)

tak też jest źle, zobacz że pewnie zepsułeś np. czuwaka w EP08-006 (otwierane z E3D)
Pole Opacity nie istnieje w E3D i nie jest z niego ładowane. (poprzednio było, ale raczej przez przypadek, bo było w "zmiennych roboczych" i nie jest opisane na stronie rainsteda). Prawidłowe flagi przeźroczystości ustawiają się w iFlags przy ładowaniu pojazdów z T3D i zapisywane już są dobrze w E3D, pewnie brakuje tego w terenie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 07 Marca 2017, 15:04:25
To jak determinowana jest faza renderowania w której dany obiekt ma być wyświetlony?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 07 Marca 2017, 15:06:36
Jest w iFlags. Znaczy powinno być, w pojazdach jest, ale w terenie tego najwyraźniej brakuje. (trzeba by to dopisać do ładowania terenu z pliku i wygenerować jeszcze raz e3d terenu)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 07 Marca 2017, 15:46:17
Hamowanie pod shft+3 usunąłeś?
Tak, powinno byc teraz pod ctrl + pause.

tak też jest źle, zobacz że pewnie zepsułeś np. czuwaka w EP08-006 (otwierane z E3D)
Faktycznie, ale to akurat proste do poprawienia -- albo daj domyslna wartosc Opacity na 0.0f (w SubModel::FirstInit albo konstruktorze) co wymusi test tekstury, albo mozemy wymusic test bezposrednio, redukujac ten kawalek do
            iFlags |=
                ( GfxRenderer.Texture( TextureID ).has_alpha ?
                    0x20 :
                    0x10 ); // 0x10-nieprzezroczysta, 0x20-przezroczysta
bez warunkow if( Opacity ...) itd. Sprawdzilem na szybko i dziala, bedzie w nastepnym uaktualnieniu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 07 Marca 2017, 16:06:22
Może być. W takiej sytuacji można też pewnie wywalić tego ifa z Model3d.cpp:379. (żeby było tak samo jak w ładowaniu E3D, zresztą renderowanie jako nieprzeźroczyste mimo że tekstura ma alfę jest raczej bez sensu)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 07 Marca 2017, 16:11:43
Hmm pewnie tak, chocby dla ujednolicenia. Chociaz docelowo chcialbym, zeby byla mozliwosc rozroznienia miedzy tekstura z alfa ktora powinna byc blendowana, tekstura z alfa ktora powinna byc uzyta przy alpha_test, i tekstury z alfa, gfzie A jest uzywane przy multitexturing. Ale to bym raczej umiescil w 'texture traits' czyli jako parameter podawany razem z nazwa tekstury, tak jak kontrola zawijania itp.

(a juz calkiem docelowo, to powinna o tym decydowac definicja zastosowanego materialu, ale to juz inna bajka)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 07 Marca 2017, 16:21:00
Drawinowo i wyświetlanie terenu, jest OK. Hamowania awaryjne tam gdzie trzeba. Są inne problemy. Po podświetleniu przyrządów shift+; mamy przezroczystość na haslerze i dziwne cienie na manometrach i miernikach (tam gdzie jest podświetlane), załączniki. Najgorsze jest to, że po odpaleniu tym exe TD i Drawinowa, nie mogę odpalić ich starszymi exekami.

Sprawdź to proszę, bo może uszkadza jakieś pliki modyfikując je dla siebie. To na ten moment pilne jest, jakby co to trzeba zdjąć exe z załącznika bo szkodzi.

ED:
W załączniku dodaję log, gdzie niemożliwe jest otwarcie scenerii starszym plikiem. Zatrzymuje się w tym samym miejscu i stoi.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 07 Marca 2017, 16:28:11
Przeźroczystość to to samo co kiedyś zgłaszałeś z czuwakiem. (a ja "naprawiłem" i zepsułem teren :P).
Już uzgodniliśmy naprawę z tmj.

Możliwe że nowe E3D nie działają na starym exe (pewnie dlatego że już po uruchomieniu konstruktora ładuje z pliku strukturę submodelu, a w nowym e3d puste miejsce jest wypełnione zerami, a wcześniej wpychała się tam reszta obiektu), ale jak już są wygenerowane to nie powinny się nadpisywać.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 07 Marca 2017, 16:32:39
Zajmie mi nieco przekopiowanie pewnego katalogu dynamic. Sprawdzę jeszcze raz czy odpalę na starym exe z paczki, starszym C++ i dzisiejszym. Jeśli ponownie popsuje się wczytywanie na starszym exe, to tak nie może zostać. Nie każdy poradzi sobie z naprawą paczki, a testy są w otwartym dziale.
Jeśli tworzenie nowych e3d psuje możliwość użycia starszych exeków, to trzeba rozwiązać ten problem, lub przenieść testy do zamkniętego działu i ostrzegać przed taką możliwością. To zresztą chyba ostateczność.
ED:
Błąd poprzedniej przezroczystości dotyczył lampek SHP, tu jest w haslerze. Tym razem shp wyświetla się dobrze nawet podświetlone.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 07 Marca 2017, 16:40:22
Na szybko mozna zapewne tego uniknac przez ustawienie convertmodels 0 w .ini, tak zeby exe nie generowalo zadnych nowych .e3d Wczytywanie bedzie troche wolniejsze, ale nic nie zepsuje. Tymczasowo ustawie to na sztywno, zeby nie psulo ludziom, ktorzy nie beda wiedziec ze trzeba cos wpisac.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 07 Marca 2017, 16:48:27
To i tak występuje tylko na paczce T3D/TGA, a żeby wrócić do starego exe wystarczy skasować wszystkie pliki .e3d. Wyłączenie tego na sztywno pozbawi jakichkolwiek testów kodu nowego zapisywania e3d.
No ale jeżeli jest to jakiś większy problem to mogę spróbować wcisnąć tam te struktury żeby było kompatybilne ze starym exe.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 07 Marca 2017, 16:50:40
Tak, tylko paczka na której pracuje to dds z e3d. Nie mam t3d, więc tylko kopiowanie zostaje. Paczka z t3d jest paczką developerską, nie dla końcowego użytkownika. Nie wiem też, czemu exe wczytuje scenerie z e3d i potem zapisuje nowe e3d. Zresztą dokładnie sprawdzę, ja to jest, bo na ten moment nie złapałem tego za rękę.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 07 Marca 2017, 16:52:53
Jak to? E3D powinny zapisywać się tylko przy ładowaniu z T3D. Pokaż loga.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 07 Marca 2017, 17:15:32
Sprawdzajac na szybko, zapisuje u mnie tylko .t3d, natomiast .t3d to czesto miedzy innymi chmury itp (rowniez w paczce dds) wiec faktycznie latwo moga popsuc dane dla starego exe.

W ramach kompromisu, uaktualnienie:

- naprawione wyswietlanie opacity
- convertmodels jest domyslnie wylaczone, a wlaczenie wymaga wpisania w .ini convertmodels z parametrem o 128 wiekszym niz do tej pory. tzn jesli wczesniej dzialalo convertmodels 7, to teraz trzeba wpisac 135. Tym sposobem ciagle mozna testowac zapis, ale niepoinformowanym uzytkownikom nie powinno zaszkodzic.

edit: slepy jestem i dalem nie ten build, sorry :d teraz powinien byc dzisiejszy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 07 Marca 2017, 17:16:32
Tego pierwszego loga z odpalenia 170307 nie mam... Dałem wcześniej ten z td, nieudany...
Narobiłem zamieszania za co przepraszam, ale chyba sprawa istotna, z obawy by komuś w paczce nie namieszać. Jest ok, na scenerii wstawione były modele t3d i dotąd nie robiły zamieszania. Po ich zaremowaniu jest dobrze.
W załączniku poprawnie świecące manometry.
ED:
Super, jak ktoś ma modele z t3d to się nie złapie na tym. Zastanawia mnie na ile błędy u @EP08-15 mają taką genezę. Oczywiście nie wszystkie.

ED1:
Wyświetlanie podświetlonych wskaźników jest w porządku. Teren w drawinowie jest i idę wałkować inne scenerie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: dymus w 07 Marca 2017, 18:46:22
Chyba tego nie było zgłaszane ale:
eu07++170307b
•częstotliwosc migania czuwaka jest zbyt mała (mniej więcej dwa razy wolniej niż poprzednie exe)
•na przyśpieszeniu (np. ctrl+f6) czas ewentualnego zadziałania nadmiarowego przetwornicy jest taki sam jak na bez przyśpieszenia (tak jakby nie uzględniało przyśpieszenia czasu, wcześniej było ok, teraz - chyba od 2 wersji exe - to się pojawiło). tak samo czas załączenia wyłączyka szybkiego też jakby nie uzględniała przyśpieszenie czasu, poprzednie exe na przyśpieszeniu szybki załącza się od razu, tutaj na przyśpieszeniu czas jest dośc porównywalny do tego bez przyśpieszenia. to samo częstotliwość migania czuwaka na przyśpieszeniu, oraz czas po którym po naciśnięciu przycisku czuwaka zaczną migać lampki
•zwiększył się czas załączenia wyłącznika szybkiego (bez zmian w plikach fiz czy coś) (1.25 teraz, 0.75 sekundy - mniej więcej - na tym samym pojeździe, krótszy czas na exe 170303)  na innym pojeździe teraz 1.20, wcześniej 0.75 na exe 170303) więc wygląda na ogólnie dwukrotne wydłużenie czasu
•kran hamulca zaspolonego porusza się mniej więcej dwa razy wolniej (chodzi o poruszanie się klawiszami 3 i 9)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 07 Marca 2017, 19:04:36
To jak w końcu jest z e3d? +128 do flagi to rozwiązanie przejściowe? Nie straszcie potrzebą rekompilacji wszystkich modeli binarnych.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 07 Marca 2017, 19:05:30
stare działają, tylko e3d wygenerowane na nowym nie otwierają się na starym exe
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 07 Marca 2017, 19:21:32
Nie było zgłaszane, co prawda długie załączenie szybkiego za plus.
Nadal nie działa pauza, była pod Pause/break. Migotanie na styku przenikających się tekstur, dokładnie i najlepiej wkurza przy przenikaniu tekstury podsypki i trawy, to zawsze było, teraz jakby więcej. To jednak może niech ktoś jeszcze zerknie, taka ocena przecież może być subiektywna z powodu zbyt długiego ślęczenia przed komputerem.
Nie wiem czy to na później, ale jest problem z latarniami. Pierwszy obrazek, to przejazd, na którym są latarnie, z bliska mało tego światła, ale ono z natury takie było. Drugi obrazek, to widok na te same latarnie z daleka, mimo niewidocznej latarni i tego co tam jest w okół, światłość jest niewspółmiernie duża. Obawiam, się jednak, że jest to ruszenie całej struktury freespotów, łącznie z semaforami, światłami końca pociągu i tym podobne.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 07 Marca 2017, 19:38:04
Nadal nie działa pauza, była pod Pause/break.
Pauza jest pod Esc, ale nie jest zalaczana w trybie debug i/lub aktywowanej opcji multiplayer w .ini  Tak samo jest chyba w oryginalnym exe. Sprawdzilem na szybko, i w trybie normalnym u mnie dziala, notyfikacja "paused" pojawia sie kolo zegara, a zegar symulacji (i sama symulacja) staje do czasu ponownego nacisniecia Esc.

Problem z latarniami jest ten sam co z punktowymi swiatlami lokomotyw, itp -- na duzy dystans wlaczane jest rysowanie 'punktow' zamiast tekstury swiatel, ktore sa wieksze, i tym samym wyrazniejsze niz "falszywe" tekstury swiatel. Nie mam na razie konkretnych pomyslow co tam zmienic.

@dymus, czy mozesz porownac takze czestotliwosci migotania, predkosci itp z oryginalnym exe? Nie pamietam na 100% czy w 02-03 i pozniej byly jakies zmiany w tym temacie, ale porownujac "okno w okno" dzisiejsza wersje z exe Borlanda predkosci wydaja sie identyczne -- np hamulec zespolony po przytrzymaniu klawisza 3 przechodzi z polozenia 'polnoc' do 'poludnie' w ~4 sekundy, czuwak na oko miga z identyczna predkoscia, itp. Przy jakim FPS bylo to zauwazone, 60 czy mniej?

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 07 Marca 2017, 20:15:45
Jakiś programik wyłąpujący obiekty typu freespot w t3d i zmniejszajacy mindist dla zadanego progu potrzeba. Notatnikiem tego nie ogarnę. Większa kropa będzie się pojawiać wcześniej i powinno być dobrze.
Większość latarni nie ma freespota tylko "gwiazdkę" (stars, jak czasza nieba). Skoro one też są większe, to nie szkodzi to wyglądowi gwiazd na niebie?
W borlandzie była paza pod klawiszem Pause działająca w obu trybach. Pauzowanie w debugmode też jest potrzebne.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 07 Marca 2017, 20:27:10
Podczas renderowania nieba wielkosc punktow jest zmniejszana, inaczej faktycznie gwiazdy bylyby zbyt duze :)  Zmniejszenie mindist dla freespotow mozna zapewne wpisac do exe, zobacze jak to wyjdzie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 07 Marca 2017, 20:32:52
Lepiej osobny programik, co by było selektywne. Czasami może być potrzeba innych ustawień.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 07 Marca 2017, 20:44:54
Znalazlem jeden z bledow wysypow u siebie. Może się komus przyda na przyszlosc. Exe wywalalo się na uszkodzonym pliku gray.dds z folderu db/rlmmp.
Zalaczam owy uszkodzony plik. Stare exe to omijalo i po prostu pojazd był bialy. Podobny blad mam na pierwszej wersji wagonu bmz. Program iview także tych plikow nie może otworzyć. Wlasciwe dds iview otwiera (z wtyczka oczywiście) a exe je wczytuje bez kłopotu. Warto by na to spojzec. Lepiej niech wywali blad ze plik niemożliwy do wczytania, ale niech pozostawi pojazd bialy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 07 Marca 2017, 20:47:02
Skąd on jest? Trzeba go otagować do ponownej konwersji przy składaniu paczki.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: dymus w 07 Marca 2017, 21:02:40
Cytuj
@dymus, czy mozesz porownac takze czestotliwosci migotania, predkosci itp z oryginalnym exe? Nie pamietam na 100% czy w 02-03 i pozniej byly jakies zmiany w tym temacie, ale porownujac "okno w okno" dzisiejsza wersje z exe Borlanda predkosci wydaja sie identyczne -- np hamulec zespolony po przytrzymaniu klawisza 3 przechodzi z polozenia 'polnoc' do 'poludnie' w ~4 sekundy, czuwak na oko miga z identyczna predkoscia, itp. Przy jakim FPS bylo to zauwazone, 60 czy mniej?
Scn testowa (sam tor, więc mniej niż TD :P).
exe474 (jakieś tam starsze z paczki): 20mignięć czuwaka  w 7 sekund,  FPS 60, przejście od jazdy do nagłego przy klawiszu 3: 3.3sek  czuwak co 60sek (pomiędzy załączeniami podczas jazdy, jest ok).
exe++170302: 20 mignięć ~7-8sekund, FPS 170,  przejście od jazdy do nagłego przy klawiszu 3: 3.3sek, czuwak co 60sek
exe++170303: 20 mignięć ~7-8 sekundy, FPS 61 (mam zablokowane przez "vsync yes" bo coś mi się laptop przy więcej grzał, bo miał 150+ FPS), przejście jazda nagłe ok. 3 sekundy, czuwak co 60sekund
exe++170307b: 20 mignięć w 11.4sek, FPS 61 (vsync yes), przejście jazda na nagły 6sek, czuwak co 60sek
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 07 Marca 2017, 21:18:45
Ktoś zerknie na drezynę WM15? Potwierdzam, że na Zwierzyńcu transport, dostaje małpiego rozumu. Przejechałem Kaliską od Ostrowa do Łodzi. Nie miałem żadnych problemów.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 07 Marca 2017, 21:18:59
Cytuj
Skąd on jest? Trzeba go otagować do ponownej konwersji przy składaniu paczki.

dynamic/db/rlmmp_v1
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 07 Marca 2017, 21:35:17
Coś jest wyraźnie nie tak z ucinaniem obiektów z boku kamery. Oprócz tych trójkątów jeziora, pojazdy też znikają. FPS=46, 1080p 16:9, ustawiłem kamerę by mi skład wjeżdżał z rogu monitora. Wagony renderowały się dopiero gdy były już ze trzy metry na ekranie. Wcześniej środek dynamica musiał być przynajmniej z pół km za kamerą by ten się nie wyświetlał.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 07 Marca 2017, 21:38:50
Antek, to jak już to popatrz na składy z góry, tak abyś obejmował około 10-15 wagonów. Patrz pod różnym kątem w stosunku do osi toru na skład, ja nie umiem tego nazwać. Bywa, że coś znika.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 07 Marca 2017, 21:40:31
Znalazlem jeden z bledow wysypow u siebie. Może się komus przyda na przyszlosc. Exe wywalalo się na uszkodzonym pliku gray.dds z folderu db/rlmmp.
Zalaczam owy uszkodzony plik. Stare exe to omijalo i po prostu pojazd był bialy. Podobny blad mam na pierwszej wersji wagonu bmz. Program iview także tych plikow nie może otworzyć. Wlasciwe dds iview otwiera (z wtyczka oczywiście) a exe je wczytuje bez kłopotu. Warto by na to spojzec. Lepiej niech wywali blad ze plik niemożliwy do wczytania, ale niech pozostawi pojazd bialy.
Zgadza sie, ten gray.dds wyskoczyl wczesniej i wygenerowalem wtedy poprawiona wersje z .tga, ale przysiaglbym ze dalem tez poprawke zeby sie na tym nie wysypal, a wychodzi na to ze zapomnialem. Dopisze na przyszlosc poki jeszcze (znowu) pamietam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 07 Marca 2017, 21:47:54
Owszem, dawałeś w tym poście: http://eu07.pl/forum/index.php/topic,28159.msg442512.html#msg442512
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 07 Marca 2017, 21:53:18
Nie da się tego zrobić, by w podobnych przypadkach exe to olewalo? Oczywiście info do errors mile widziane i w logu tez.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 07 Marca 2017, 22:11:48
No mowie, ze wczesniej zapomnialem, a teraz bedzie, od jutra. I olewac, i krzyczec ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 07 Marca 2017, 22:25:59
moje buildy:
https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng32-53db1e51-m.zip
https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng64-53db1e51-m.zip

uwaga, generuje e3d niekompatybilne ze starymi exe! nie wszystkie zmiany od tmj są zmergowane bo coś się zkaszaniło z kamerą i nie mam już do tego dzisiaj siły.

powoli zacząłem dostosowywać ścieżkę renderowania vbo do shaderów, może za kilka dni będą jakieś efekty.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 07 Marca 2017, 22:39:15
@Milek7: Mógłbyś proszę numerować swoje kompilacje, nadpisują się i nie ma jak porównywać ze starszymi.
@tmj: Wcisnąłem F4 i po chwili rozjechał mnie pociąg z toru obok. Mała korekta pozycji po za pojazdem w kierunku opuszczanego pojazdu, może 0,5 metra?
Ciekawostka (załącznik), plik gray.tga znalazłem też w oficjalnej paczce całościowej, stąd u mnie przy zaznaczeniu wczytywania tga, manewrowo się nie wysypało.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: loko w 07 Marca 2017, 23:05:20
Drawinowo-170306, misja EP09-005. Przejechałem tylko w jedną stronę na 170307b do momentu podpięcia się do drugiego składu. Mimo, iż "docisnąłem" lok do składu, między zderzakami była znaczna odległość. Ja też odnoszę wrażenie, że zawór hamulcowy m-sty działa wolniej. Temat znany, ale po zmianie kabiny, całe sterowanie oświetleniem (wszystkie tryby) odbywało się z klawisza "U". 
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: MaciejM w 07 Marca 2017, 23:11:43
Bo tak to jest zrobione: w lokomotywach, gdzie jest przełącznik pozycyjny (a nie złączanie każdego reflektora osobno) czyli w Traxxach, EP09, EU07-15xx, ST45 sterowanie oświetleniem to U (w lewo) i Shift+U (w prawo).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 07 Marca 2017, 23:15:58
@tmj: Wcisnąłem F4 i po chwili rozjechał mnie pociąg z toru obok. Mała korekta pozycji po za pojazdem w kierunku opuszczanego pojazdu, może 0,5 metra?
Bo trzeba patrzec, kiedy sie wysiada ;)
W tej chwili kamera jest ustawiana w odleglosci ~1m od boku lokomotywy, przysuwajac ja jeszcze blizej ryzykuje ze zwyczajne przetnie sie przez pudlo w niektorych przypadkach. Nawiasem mowiac, na to gdzie wyladujesz wplyw ma tez pozycja w kabinie w chwili nacisniecia F4 -- kalkulacja jest dla pozycji w fotelu maszynisty, jesli zamiast tego siedzisz gdzies po lewej stronie (w trybie debug albo chodzac dookola) to wyrzuci cie troche dalej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 07 Marca 2017, 23:20:12
Drawinowo? Dobrze trafiło, właśnie jadę w drodze powrotnej, lok jest luźno podpięty, ale zapiąć i jechać można. Załącznik. Co wydarzyło się dalej, bo nie napisałeś czy udało się spiąć, czy był wysyp? Jaka odległość była między zderzakami?

@tmj. Przyjąłem do wiadomości, będę się rozglądał. A może jakaś inteligencja aby przypadkiem nie wsadziło mnie do loka równolegle stojącego obok? Taka luźna dywagacja jak już nie będzie co robić.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 07 Marca 2017, 23:23:22
Coś jest wyraźnie nie tak z ucinaniem obiektów z boku kamery. Oprócz tych trójkątów jeziora, pojazdy też znikają. FPS=46, 1080p 16:9, ustawiłem kamerę by mi skład wjeżdżał z rogu monitora. Wagony renderowały się dopiero gdy były już ze trzy metry na ekranie. Wcześniej środek dynamica musiał być przynajmniej z pół km za kamerą by ten się nie wyświetlał.
Jeszcze gorzej jest, kiedy popatrzy się na skład "do góry nagami" lub pionowo w dół (obojętne z jakiej odległości), choć ten problem występował już w exe z paczki 16_01 i w patchu 16_05. W załącznikach ten sam skład z różnych perspektyw.
Edit.: Jeszcze lekko z boku - zał. 4.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 08 Marca 2017, 00:10:23
Całkowo _SN61, manewry wykonane poprawnie, przejezdne. Drawinowo EP09, dokończone z powodzeniem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 08 Marca 2017, 01:21:14
OK, pogrzebalem troche w kodzie, probujac poprawic widzialnosc freespotlights, i znalazla sie ciekawostka, jeszcze z czasow oryginalu...

W kodzie jest cos, co nazywa sie "wspolczynnik odleglosci", i sadzac po wartosci domyslnej (768) i komentarzy, intencja tutaj bylo zwiekszanie zakresu widocznosci na ekranach/oknach wiekszych niz standardowe 1024x768. Tyle ze zamiast tego, zmienna byla uzyta jako sztywny mnoznik, dla zdefiniowanych minimalnego i maksymalnego zakresu widzialnosci, dla kazdego obiektu.

W praktyce oznaczalo to, ze punkty swietlne ze zdefiniowanym minimalnym zakresem widzialnosci 20m nie byly renderowane w ogole, dopoki nie znalazly sie przynajmniej ~500m od kamery :d  Jedyne co renderowalo sie poprawnie, to obiekty ze zdefiniowanym minimalnym zakresem 0.

Z jednej strony, po poprawce wszystko wyswietla sie w zakresach odleglosci takich, jakie zostaly zdefiniowane. Tzn objekt o zakresie 50-1000m widoczny jest w zakresie 50-1000m w oknie o wysokosci 768 pikseli, na wiekszym pojawia sie troche wczesniej i znika troche pozniej. Zaryzykuje opinie, ze swiatla znacznie na tym zyskuja -- te male punkty robia duza roznice.

Z drugiej strony oznacza to, ze do tej pory symulator renderowal takze elementy umieszczone dalej niz ich zdefiniowany 'zakres maksymalny'. Czyli po naprawie na ekranie moze byc widac mniej, niz przedtem. Jest to do skorygowania (zasieg moze byc dynamicznie zwiekszany na podstawie fps) i teoretycznie istnieje w kodzie, ale takze do przejrzenia.

Z trzeciej strony, oprocz poprawionej widocznosci swiatel efektem ubocznym strony drugiej jest dosc zauwazalnie poprawiona wydajnosc -- na Kaliskiej tam, gdzie do tej pory mialem 60-80 fps teraz renderowalo sie 200-250.

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 08 Marca 2017, 10:10:26
Wszystkim freespotom można ustawić maxdist=-1. Tu raczej nie ma wyjątków. Już nie mogę się doczekać testu tego pięciokrotnego wzrostu fps. :D
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 08 Marca 2017, 11:32:03
A ja odpalilem i musialem wyjsc z domu. W tej chwili usycham z ciekawosci a AI jedzie do Ostrowa. Po odpaleniu zanotowalem wzrost fps, ale mam za slaby sprzet aby byl az taki. Jesli na starcie mialem 30 do 35 to teraz bylo okolo 50. Wroce, to dokonam porownania.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 08 Marca 2017, 13:55:24
Jakim cudem na braku zwykłego przemnożenia możesz mieć takie różnice w wydajności?
Przemnozenie dotyczylo wszystkich objektow, wiec w praktyce jesli cos mialo wpisane widocznosc do 1km, to symulator "traktowal je powaznie" na dystansie niemal 28 km od kamery... a w scenach jest duzo objektow :x Nie wszystko bylo faktycznie rysowane, bo tam sa jeszcze dodatkowe limity ilosci obrabianych sektorow terenu itp, ale spowolnienie bylo.

Po odpaleniu zanotowalem wzrost fps, ale mam za slaby sprzet aby byl az taki. Jesli na starcie mialem 30 do 35 to teraz bylo okolo 50. Wroce, to dokonam porownania.
Zmiana bedzie do pewnego stopnia zalezala od scenerii -- np na Kaliskiej w Lodzi, patrzac 'w glab' dworca na poludnie, skok byl z 60 fps do ~90. 200-250 zaczal wyciagac na odcinku poza Lodzia. Ogolnie rzecz biorac, zmiana bedzie mniejsza w gesto 'zaludnionych' obszarach, wieksza na odcinkach gdzie te zaludnione obszary sa dosc daleko, i symulator (teraz) faktycznie przestaje sie nimi przejmowac.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: loko w 08 Marca 2017, 14:54:00
Co wydarzyło się dalej, bo nie napisałeś czy udało się spiąć, czy był wysyp? Jaka odległość była między zderzakami?
Ogólnie to skończyły mi się godziny i musiałem zawołać podmianę ;-) Udało się spiąć i zdążyłem jeszcze próbę zrobić, chociaż już wołali zanim jeszcze podjechałem pod skład, ale mi się zeszło z tymi światełkami. I niestety na tym musiałem zakończyć symulację. Odległość prawdopodobnie była taka sama jak na Twym skrinie, później mogę wrzucić swój zrzut.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 08 Marca 2017, 15:02:11
Nie wrzucaj, skoro było identyczne a ja dojechałem do końca, to nie ma problemu. No może wizualny i trzeba sprawdzić czemu tak jest. Nie wydaje mi się aby exe było temu winne.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 08 Marca 2017, 15:58:56
Jaki to pojazd? Może ma niezgodność modelu z fiz.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 08 Marca 2017, 16:12:08
EP09 Drawinowo. Loko jechal oryginalna dziewiatka, ja pojechalem 09-046 clasic. Dalem wyzej screen z widokiem sprzegu i zderzakow. Wygladala na luzno skrecona z wagonami.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 08 Marca 2017, 17:46:12
Chłopaki, serio zobaczcie co jest nie tak z exe na scenerii zwierzyniec_transport:
Odpalam scenerię, czekam na wyjazd, próbuję ruszyć. Cały test trwa góra 3 minuty. Efekt jest zabawny. Problem nie jest ze scenerią, bo na starych exe działa poprawnie. Myślę, że to ilustruje całkiem ciekawego i dużego buga.

Nie wiem czy ktoś już to zgłaszał (bo trochę mnie nie było), ale jak jest w Rainsted zaznaczona pauza na starcie, to zaczynamy pod lokomotywą ;) Dopiero po odpauzowaniu znajdujemy się w kabinie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 08 Marca 2017, 17:48:19
Cytuj
Zabawny
No wybacz, ale opis buga na Zwierzyniec transport jest nieco skąpy. Dorzuć coś.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: dymus w 08 Marca 2017, 18:04:21
Cytuj
Efekt jest zabawny
Przy ruszaniu jakąś magiczną siłą nasz skład zaczyna przyciągać drezynę, tak że wjeżdża na nasz skład. To było to zabawne czy coś mnie ominęło?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 08 Marca 2017, 18:14:39
Nie trzeba ruszać, wyjeżdża z Psiary Południe kilkanaście sekund po uruchomieniu scenerii. Tyle że nie wywołuje tego żaden event, a drezyna jest zahamowana..
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: art72 w 08 Marca 2017, 18:15:23
Nie wiem czy ktoś już to zgłaszał (bo trochę mnie nie było), ale jak jest w Rainsted zaznaczona pauza na starcie, to zaczynamy pod lokomotywą ;) Dopiero po odpauzowaniu znajdujemy się w kabinie.

Też tak miałem na dziewiątce w Drawinowie :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 08 Marca 2017, 18:20:39
Jeśli chodzi o drezynę, to było zgłaszane a ja potwierdziłem. Nawet dopytywałem, czy ktoś wziął temat pod lupę.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 08 Marca 2017, 19:15:21
Może to bug w samej drezynie jednak. Tak jak nie dające się wyłączyć syczenie w kiblu to błąd kibla. Na 99%. Poprawione exe ujawnia ukryte bugi w innych miejscach. Tak strzelam tylko, oczywiście. Przed chwilą przejechałem linię 053 (część osobową), nie wykryłem żadnych problemów. Może podejrzane było, że nie spaliłem silnika ani nie zniszczyłem obręczy na tych torach, bo po długiej przerwie zapomniałem gdzie są te pułapki i zareagowałem troszkę wolniej niż kierowca F1. Chociaż oczywiście to natychmiastowe niszczenie lokomotywy było zgłaszane wcześniej jako bug, więc teraz wygląda, jakby działało lepiej. Do 2 sekund na reakcję jest chyba realistycznym czasem, poprzednio jednak lokomotywa ulegała uszkodzeniu po ułamkach sekundy poślizgu. Następnym razem sprawdzę, czy jednak uda mi się zepsuć loka, bo po jakimś czasie (jakim?) powinien się jednak zepsuć.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 08 Marca 2017, 19:42:22
Drezyna jest wygaszona, zahamowana, a coś ją wystrzeliwuje ruchem przyspieszonym. Trzeba by obadać tory w jej punkcie startowym. Może coś tam jest dziwnego. Testowałem ją na TD i jeździ normalnie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 08 Marca 2017, 19:47:37
Tak jak nie dające się wyłączyć syczenie w kiblu to błąd kibla. Na 99%.
Syczenie kibla generalnie ma miejsce przy uruchomieniu symulatora z aktywowana pauza, bez pauzy jest, z tego co doswiadczylem, ok. Wiec technicznie bedzie to blad exe :)
Co do drezyny, to ja nawet nie wiem czy pliki ktore ja obsluguja sa wlaczone do kodu, chyba nie. Wydawalo mi sie ze to jest taki "Easter Egg" dlatego specjalnie sie jej nie przygladalem. Tak ze faktycznie, tam sie moze dziac wszystko.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 08 Marca 2017, 19:50:49
Ale to jest WM15. Silnik dumb, hamulec pneumatyczny oerlikona. Działa w pełni. A machajki mi nie psuj. Po coś model robiłem. :P
Pooglądałem tory gdzie startuje i nie widać tam żadnych dubli, czy niczego podejrzanego. Nie mam pomysłu co może być przyczyną.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 08 Marca 2017, 20:08:14
Powiedzcie czego brakuje... ;)

PS. Zmiana masy na 25,5 t (z obecnych 74 t) częściowo pomogła, ale nie wydaje mi się że to jest główna przyczyna.

PS2. Zauważyłem, że choć pojazd minimalnie się przesuwa (teraz, po tych zmianach), to koła się nie kręcą... dziwny poślizg?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 08 Marca 2017, 20:10:51
Ale to jest WM15. Silnik dumb, hamulec pneumatyczny oerlikona. Działa w pełni. A machajki mi nie psuj. Po coś model robiłem. :P
Pooglądałem tory gdzie startuje i nie widać tam żadnych dubli, czy niczego podejrzanego. Nie mam pomysłu co może być przyczyną.

Aha :) zobaczymy, na razie probuje naprawic wyswietlanie kabiny i pare innych rzeczy. Tego typu szalona predkosc to z reguly wynik rozjechanej kalkulacji sil przy zderzeniu, ale tam chyba nie ma sie z czym zderzyc?

edit:

PS2. Zauważyłem, że choć pojazd minimalnie się przesuwa (teraz, po tych zmianach), to koła się nie kręcą... dziwny poślizg?
Zobacz w errors.txt czy tam nie ma wzmianki o brakujacym wpisie animations, niektore mmd tak maja, i kiedys to dzialalo bo wpisywane byly wartosci domyslne, ale to z kolei powodowalo inne problemy, wiec prawidlowym podejsciem powinna byc naprawa tych .mmd  Objawem (oprocz wpisu w errors) jest wlasnie brak krecacych sie kol i jakichkolwiek innych animacji w pojezdzie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 08 Marca 2017, 20:22:38
Jak dałem prędkość początkową 1 km/h aby pojazd był uruchomiony przez AI, to koła kręcą się wówczas normalnie i normalnie się zatrzymuje, bez dalszego przesuwania co chwilę o centymetry.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 08 Marca 2017, 20:24:38
Ta drezyna jest dziwna, zamarzły jej szyby, ale w końcu to zima. Zatrzymałem ją i stoi tam gdzie powinna. Nie edytowałem jej masy, lecz w trainsecie zmieniłem wpis na nobody (było headdriver). Tym sposobem jadę suczką odprowadzić tabor na złom.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 08 Marca 2017, 20:46:23
Wstawiłem ST45 zamiast WM15 dając mu także headdriver i prędkość początkową 0 - efekt jest taki sam, rozpędza się na poślizgu i wbija w nasz skład. Danie prędkości początkowej <> 0 lub danie nobody rozwiązuje problem. Z ciekawości zamieniłem też punkty początku i końca toru (kiedyś pamiętam jakieś jaja z tym były w pewnych przypadkach), ale tabor wystrzeliwuje na poślizgu w drugą stronę, a więc nie ma to znaczenia.

EDIT: cały czas też przed wystrzeleniem słychać dźwięk piasecznicy. Wstawiłem EU07, które co prawda nie wystrzeliwuje, ale piasecznice ma non-stop odpaloną.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 08 Marca 2017, 20:56:47
Cały ten zwierzyniec... AI zatrzymuje się w połowie drogi bez powodu. W tabeli skanowania widnieje 0km/h, ale powodu nie widać. Podglądałem w STV jakie jest pochylenie i tarcie i nic. Po tym co napisał Tomek wydaje się, że błąd siedzi w scenariuszu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 08 Marca 2017, 21:21:24
AI piaskuje bardzo dziwacznie. Przy dodaniu dźwięku do tego dopiero wylazło. ...albo dźwięk się nie wycisza. Reset ai w takiej sytuacji pomaga.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 08 Marca 2017, 21:24:28
To samo jest z dźwiękiem syreny ET42, AI potrafi trąbić non stop, zgłaszałem to.
Jeszcze jedna wiadomość jest taka, że na exe od @Milka7 WM15 też robi co chce i na exe 170205 a więc z początku konwersji też jest nieposłuszna.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 08 Marca 2017, 21:39:32
Witam.
 Uruchomiłem na najnowszym exe 170308 kaliską. Fps rzeczywiście bardzo się poprawił. U mnie na poziomie ok 200-300 procent. Ale żeby nie było tak różowo, szyny zmieniły teksturę, z szyn na podsypkę. Wygląda że problem nie dotyczy flexów i chyba łuków. Sprawdzałem na TD i mam to samo. Potwierdza ktoś u siebie ten błąd?
Pozdrawiam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 08 Marca 2017, 21:41:38
Nie potwierdzam, ale może wyłącz wyświetlanie VBO w rainsted.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 08 Marca 2017, 21:44:35
Krzysiek, pomogło dzięki. Czyli uruchomiać bez ptaszka przy VBO.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 08 Marca 2017, 21:55:11
Tak, bez ptaszka. Wyświetlanie VBO jest robione przez @Milek7, ale jeszcze jakiś czas upłynie zanim skończy.
ED:
Przywróciłem wpis do fizyki usunięty przez @Ra, teraz grzecznie stoi na miejscu. W załączniku plik wm15.fiz z przywróconym wpisem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mareczek w 08 Marca 2017, 22:31:42
1) Poszedł radiostop. Powietrze zeszło, chcę popełnić i nie chce. Dojdzie prawie do 0,3 ale nie przeskoczy. Wszystkie węże sprawdzone (skład rozłączony, potem ponownie połączony), nic nie dało.
2) W ramach rozrywki dałem insert na czoło mojego loka od strony gdzie nie ma żadnych wagonów i poleciał crash.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 08 Marca 2017, 22:35:27
W ST45 hamulec stracił głos. Tzn nie ma dźwięku przy hamowaniu, przy odhamowaniu jest. Dziwne, jutro sprawdzę dokładniej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 09 Marca 2017, 00:15:55
Czyli uruchomiać bez ptaszka przy VBO.
VBO jest na chwile obecna nie ruszane, jako ze jest dosc niekompletne. Srednio-dystansowy plan jest taki, ze najpierw zaimplementowana bedzie obsluga materialow (ulatwi docelowo wprowadzenie shaderow, ale przyda sie do kilku rzeczy takze wczesniej), a wtedy zamiast dwoch odrebnych sciezek zrobi sie jedna (na VBO, w oparciu o biezace zmiany w sciezce DL) ale dzialajaca poprawnie.

Na krotka mete przywrocilem w exe ignorowanie przelacznika na VBO, coby falszywych alarmow nie bylo :d

W dzisiejszym uaktualnieniu;
- naprawione aktualizacja/wyswietlanie kabiny, wszystko powinno teraz pracowac z normalna predkoscia/czestotliwoscia
- wstepnie przebudowany system kalkulacji widocznosci; teoretycznie powinno to zakonczyc klopoty ze znikajacymi pojazdami, niewazne czy ogladane patrzac w dol, do gory nogami itp
- w ramach glupich eksperymentow wlaczone jest wygladzanie punktow swietlnych. w rezultacie sa teraz troche mniejsze, ale ladniejsze :P  jesli okaze sie, ze pogarsza to widzialnosc zbyt bardzo, to prosze krzyczec
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 09 Marca 2017, 12:49:19
Światła semaforów wyglądają dużo lepiej. Nie widzę żadnych problemów, no może poza tymi starymi, z opcją pauzy. A nie można by tego zrobić tak prowizorycznie, że po odpaleniu z opcją pauzy odpauzować na pół sekundy i zatrzymać? Wtedy nie byłoby innego działania z pauzą i bez.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 09 Marca 2017, 13:35:22
W dzisiejszym uaktualnieniu;
- naprawione aktualizacja/wyswietlanie kabiny, wszystko powinno teraz pracowac z normalna predkoscia/czestotliwoscia
- wstepnie przebudowany system kalkulacji widocznosci; teoretycznie powinno to zakonczyc klopoty ze znikajacymi pojazdami, niewazne czy ogladane patrzac w dol, do gory nogami itp
- w ramach glupich eksperymentow wlaczone jest wygladzanie punktow swietlnych. w rezultacie sa teraz troche mniejsze, ale ladniejsze :P  jesli okaze sie, ze pogarsza to widzialnosc zbyt bardzo, to prosze krzyczec
Nie mam żadnych zastrzeżeń, wszystkie powyższe aktualizacje dla mnie poprawiają komfort wizualny, są trafione. Brawo. Wzrost wydajności w FPS i czas wczytywania scenerii jest znakomity, ciekawe, czy było to do uzyskania w Borlandzie? Przepisywanie na C++ wygląda na opłacalne.
@Milek7, Twoje exe odpala się i nie wykazuje większych błędów niż exe @tmj. Oczywiście wersja 32 bitowa. Na dziś kończę testowanie, nabyłem nowy dysk i potrzebuję czasu na przepisanie danych z komputera z dysku, który ledwo zipie.
Ze znanych błędów, część wpisana jest do bugtrackera, część pamiętamy. Drobne poprawki nie będące błędem a jedynie kosmetyką działania aplikacji można zostawić na później, bo jak widzę rysują się odmienne poglądy na działanie funkcjonalności.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 09 Marca 2017, 13:40:44
ciekawe, czy było to do uzyskania w Borlandzie?
O ile sie nie myle to ten ostatnio odkryty krzak z kalkulacja zakresu widocznosci siedzial sobie w oryginalnym exe od niewiadomo kiedy, a usuniecie nie wymagalo zadnych nowosci c++ wiec potencjalnie mozna by przyspieszyc renderowanie w wersji Borlandowej o ~50% wprowadzajac ta jedna poprawke i rekompilujac. Natomiast wczytywanie itp, to juz raczej zasluga nowszych kompilatorow i lepszej optymalizacji ktora wykonuja. Tego Borland raczej nie nadrobi.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 09 Marca 2017, 14:14:38
Sorki za pytanie o być może coś oczywistego, ale o co chodzi z 64-bitowym exe? Czym się różni? Od strony testowania - utrudnienie, bo trzeba wszystkie dll-ki nadpisać, żeby działało (i wtedy nie działają 32-bitowe exe). Czy 64-bitowe exe to MaSzyna faktycznie robiąca użytek z 64-bitów, tzn szybsze operacje na liczbach typu double zamiast float itd? Czy potrzebne jest porównywanie w testach obu wersji pod kątem wydajności? Czy na razie to tylko wersja bazowa która ma się tylko skompilować jako x64, a zmiany dotyczące wydajności są zaplanowane na później?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 09 Marca 2017, 14:46:25
Wersja 64bit to glownie umozliwienie exe korzystania ze znacznie wiekszego obszaru pamieci. Ewentualne przyspieszenie mogloby sie pojawic przy starszych kompilatorach, ktore generowaly 'stary' kod dla operacji zmiennoprzecinkowych w trybie 32-bit, a wlaczaly uzycie SSE(2) przy kompilacji 64-bitowej, ale zdaje sie, ze na VS2013+ SSE jest uzywane domyslnie takze w trybie 32bit.

Ale porownanie na pewno warto zrobic, chocby dla pewnosci :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 09 Marca 2017, 14:46:59
Nigdy nie mam tak, abym na komputerze miał jeden system operacyjny. Zwykle jest XP i WIN7, są oczywiście na osobnych dyskach. XP32 bitowe, wersja nie oemowa. WIN7 jest 64 bitowy. Zwykle mam 3 dyski, więc zawsze jeszcze jakaś instalka na czysto może być w zapasie. Stąd nie mam problemu i konfliktu między poszczególnymi bibliotekami i paczkami, czy exekami. Ponadto, aby nie nadpisywać bibliotek czy innych plików mam zwykle kilka (czsem naście) paczek do testowania. Prawda, nie każdy dysponuje 3Tb miejsca w pamięci masowej, ale przy rozsądnym gospodarowaniu 1Tb też wystarczy. Zbieram wszystko co ukazało się do symulatora łącznie z unofami, posiadam około 600Gb fotografii, ale jak czegoś jest się fanem, to miejsce na to musi się znaleźć.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 09 Marca 2017, 14:49:25
Nie, tu nie chodzi o wydajność. Plusem jest możliwość zajmowania więcej niż 4GB pamięci.
Głównie to jest testowane pod przyszłą wieloplatformowość, bo o ile na windowsie obecność WoW64 jest pewna, to np. na linux nie każdy musi mieć zainstalowane w systemie biblioteki dla x32.
Od strony wydajności mogą być drobne różnice, ale naprawdę niewielkie. (na 32bit wskaźniki zajmują mniej, więc więcej struktur mieści się w cache cpu i jest mniej cache missów, z drugiej strony x64 wymaga obecności rozszerzeń SSE2 więc są właczone na tych exekach, ale oczywiście kosztem kompatybilności ze starymi cpu można włączyć nowsze rozszerzenia także dla x32).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 09 Marca 2017, 16:45:09
Właśnie przejechałem Drawinowo na ostatnim x64, brak uwag poza jedną, ze znikaniem obiektów, ale z tego co czytałem już poprawione. Na Drawinowie ostro spada FPS w Grabówku i Włodowicach. Ale to było od zawsze tam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 09 Marca 2017, 18:21:55
Druga wersja wyglądu tabelki.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 09 Marca 2017, 18:24:03
Dwie kolumny imho bardziej czytelne.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 09 Marca 2017, 18:47:06
Obie wersje sa fajne, ale zastanawiam sie, czy nie byloby praktyczniej zeby stacje byly posortowane razem z pozostalymi elementami, ale zaznaczone tym zoltym kolorem? W ten sposob nie trzeba sie zastanawiac, w ktorym miejscu sie znajduja w stosunku do pozostalych skanowanych elementow... ale nie znam sie, wiec moze z punktu robienia tras itp taka wiedza nie jest do niczego potrzebna :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 09 Marca 2017, 18:52:35
W ten sposob calosc bylaby chronologiczna.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 09 Marca 2017, 19:05:01
Jeszcze wersja dwutabelkowa z kolorowaniem.
Rozdzieliłem tabelki wskaźników i torów żebym nie musiał robić iluśtam if-ów w przechodzeniu po jednej tabelce. Nie chcę tego mieszać teraz i sortować w każdej klatce. Oczywiście jest opcja powrotu do tego co było, ale moja wersja umożliwia wstawianie wskaźników w dziwnych kolejnościach i nieprawidłowo przypisanych do torów.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 09 Marca 2017, 20:20:46
merge z tmj i skrobnąłem coś tam w malowaniu trajektorii na vbo

https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng32-39412833.zip
https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng64-39412833.zip
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 09 Marca 2017, 21:13:09
Panowie pytanko. Dużo był zmieniany kąt widzenia? Robię te poprawki ustawienia kamer dla wszystkich pojazdów i testowałem to na waszym exe c++ i było wszystko okej, natomiast po przejściu na borlandowe, jestem dość głęboko w ścianach. Pytanko czy tak to zostawić czy robić pod stare exe, chociaż raczej te poprawki nie zostaną wprowadzone wcześniej niż wyjdzie nowa paczka całościowa czy też patch.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 09 Marca 2017, 21:14:18
Jeszcze pytanko czy zależy to od proporcji ekranu i ustawionego fov? Co by dla jakiejś konfiguracji nie wylądować za ścianą.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 09 Marca 2017, 21:17:25
Domyslny kat widzenia chyba nie byl zmieniany (zmiana zalezy of wpisu fieldofview kat w .ini, natomiast zwroc uwage ze poziomy kat widzenia zalezy od proporcji okna symulatora, i 16:9 pokazuje w poziomie wiecej niz 4:3
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 09 Marca 2017, 21:21:28
Tylko jest różnica patrząc na ścianę prostopadle. Na waszych exekach widać ścianę, a na borlandowych jej nie wyświetla. Jakby wokół kamery była sfera ucinająca renderowanie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 09 Marca 2017, 21:22:12
Różnica jest ogromna.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 09 Marca 2017, 21:25:25
Aha, moze tak byc, bo kamera w openGL ma zdefiniowany zakres minimalny, i nie renderuje niczego, co jest blizej. W przepisanym exe ten zakres minimalny jest definiowany na ~10 cm, w starym exe bylo chyba 20.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Waldi 1978 w 09 Marca 2017, 21:37:23
Linia 61 towarowy1  problem. Nie wiem czy to wina exe 170309, czy ogólnie tej  trasy.
Po wyjeździe z Herbów Nowych dostałem s1. Jazdy ok 3 min, potem czekałem tam ok 20 min i dałem sobie spokój.
EDIT
@tmj
Tam nic nie widać :) Obleciałem  tył i przodek w dali stoi tylko jakiś towarowy na s1.


 
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 09 Marca 2017, 21:40:11
Tez nie wiem czy to problem trasy czy exe, ale tak mowiac ogolnie, jesli przytrafi sie cos takiego to warto wysiasc z lokomotywy i przeleciec sie z wcisnietym ctrl wzdluz toru, zeby sprawdzic czy tam cos z przodu siedzi i blokuje :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 09 Marca 2017, 21:42:38
Odpaliłem to L61_towarowy, sprawdzę. Z tym lataniem po scenerii jak jest ciemno to jest dolna część pleców. Obecnie nie umiem, lub nie potrafię zrobić dnia w Quarku. Nawet jak wywale wszystkie wpisy atmo i time, w rainsted wskaże o co mi chodzi, to i tak dostaje ciemność. No chyba, że w kamerze zrobicie szperacz;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 09 Marca 2017, 22:11:38
Latarkę do ręki jak w Farmin Simulator 2017 xd
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 09 Marca 2017, 22:19:33
W mailu podam adres na który można mi ją wysłać. Jeśli nie będzie możliwości rozłączenia zależności Czas - Światło - rozkład jazdy, to ja wypadam z testowania nocnych scenerii. Sprawa jest prosta, jeśli zablokować i wymusić jasność, to symulator zaczyna wyświetlać 10,30. Nocne rozkłady i eventlaunchery nie będą działać. Po ciemku głano, nic nie widać, to żadnego korka nikt nie wypatrzy. Owszem, potwierdzam błąd L61_towarowy_1, wyjeżdżamy i na następnym stoimy i kwitniemy.
W związku z tym, w trybie pilnym, nadzwyczajnym, proszę przywrócić możliwość włączenia słońca, nawet wtedy, kiedy jest godzina 1 w nocy. Tryb debug mode powinien, o ile nie musi ułatwiać testy. Proszę o stosowną odpowiedź.;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 09 Marca 2017, 22:23:44
W jakiej odległości jest księżyc? Wychodzi przez chmurami na moim skyboksie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 09 Marca 2017, 22:26:44
Obecnie nie umiem, lub nie potrafię zrobić dnia w Quarku.
Najszybciej chyba to przejsc do debug mode (ctrl+shift+f12 jesli nie bylo uruchomione w debug) i przytrzymac shift + F1, zeby popchnac zegar do przodu.

edit: ale jesli jest zapotrzebowanie, to moge o czyms pomyslec.

W jakiej odległości jest księżyc? Wychodzi przez chmurami na moim skyboksie.
Ksiezyc jest jeszcze z nieba ze starego exe, wiec absolutnie nie odpowiadam za jego zachowanie :)  Najlepiej zmienic wpis nieba na skydome_clouds.t3d a o starym zapomniec, chyba ze ktos lubi ogladac dwa slonca itp.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 09 Marca 2017, 22:27:42
Ale to rozsypie rozkłady i eventlaunchery, nie? Krzyś chciałby dać opcjonalne światło niezależnie od godziny w debugu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 09 Marca 2017, 22:28:46
Antek, jest ciemność i nic nie widać. Jak Ty potrafisz tam coś wypatrzeć, to próbuj. Mogę sobie rożświetlić siftem + F1, mogę zablokować ciemność wyłączając Time, ale wiesz doskonale, że posypią się rozkłady. Dla mnie przywrócenie widności w nocy bez ruszania czasu jest bezdyskusyjne, nie powinniśmy psuć oczu na wypatrywanie czegoś na ekranie.
Obecnie nie umiem, lub nie potrafię zrobić dnia w Quarku.
Najszybciej chyba to przejsc do debug mode (ctrl+shift+f12 jesli nie bylo uruchomione w debug) i przytrzymac shift + F1, zeby popchnac zegar do przodu.
edit: ale jesli jest zapotrzebowanie, to moge o czyms pomyslec.
Tak możemy oglądać statyczne obiekty, obserwacja korków i dynamiki jazdy nie jest możliwa. Bardzo proszę:)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 10 Marca 2017, 02:09:45
Dodalem przelacznik oswietlenia pod Ctrl + F7 w trybie debug. Przelacza miedzy standardowa, dynamiczna kalkulacja oswietlenia, i stalym polozeniem slonca tak, jakby byla godzina 10:30. Stan przelacznika widoczny jest na ekranie F2 (poza pojazdem) jako (*) obok parametru Light Level.

Z wiekszych, ale mam nadzieje niewidocznych zmian czesciowo rozgrzebany jest kod renderujacy grafike. Konkretnie, funkcje renderujace wycinane sa z obiektow i przenoszone do jednego modulu, zamiast obecnego rozwloczenia po calym exe. Jesli wszystko poszlo dobrze, to nie powinno to produkowac zadnych wizualnych krzakow (poza tymi znanymi do tej pory :d) ale jesli ktos zauwazy cos nie tak, prosze krzyczec.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: loko w 10 Marca 2017, 05:49:41
Kaliska_Cegielski, pos Cegielski, EXE eu07++170309. Przejezdna do końca, FPS rzeczywiście na plus, aż muszę uruchomić na EXE z paczki i porównać. Z tego co zauważyłem to na wyjeździe z Opatówka słup i sieć były odwrócone (wcześniej nie rzuciło się mi to w oczy a nie wiem czy było zgłaszane) oraz smuga wydaje się do poprawy - w Kaliszu oświetlała sufit zadaszenia peronowego. Z tego co się orientuję, to reflektory w pojazdach w realu nie mają takich ustawień.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 10 Marca 2017, 10:14:25
Najpierw podziękuję za ctrl+F7, wspaniała sprawa.
Linia 61 towarowy1  problem.Nie wiem czy to wina exe 170309 czy ogólnie tej  trasy.
Po wyjeżdzie z Herb Nowych dostałem s1. Jazdy ok 3 min czekałem tam ok 20 min i dałem sobie spokój.<ciach>
Nie ma żadnego korka. Jeśli zdecydujemy się pojechać mimo S1 to, to drogę mamy ułożoną a nastęnpe światła pozwalają nam jechać. Po złamaniu S1 dokończyłem scenariusz. Największa ciekawostka, to samo jest na exe z paczki całościowej, czyli nadal oficjalnym.
Nie pisałem tego scenariusza, on był przejezdny a w PC nie jest i szukać powodu S1 na HR_R12 nie będę.
Kaliska_Cegielski, pos Cegielski, EXE eu07++170309. <ciach> smuga wydaje się do poprawy - w Kaliszu oświetlała sufit zadaszenia peronowego. Z tego co się orientuję, to reflektory w pojazdach w realu nie mają takich ustawień.
O oświetleniu była mowa, jeśli jeden z wierzchołków trójkąta załapie się na oświetlenie, to świeci cały trójkąt. Znana przypadłość, będzie poprawiona jak zapowiadają exemajstrowie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 10 Marca 2017, 10:27:14
Niestety nie jestem tak dobry i szybki jak nasi spece i tak popsułem tabelki że mam crashe ;) Popołudniu kolejna sesyjka z próbą dowiedzenia się co jest nie ten teges.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 10 Marca 2017, 17:31:17
Nowe uaktualnienie w nowym watku ( http://eu07.pl/forum/index.php/topic,28920.0.html ) zeby nie trzeba sie bylo przekopywac przez 40 stron. W zasadzie bez zmian od wczoraj, oprocz dodanej mozliwosci zmiany FoV przy uzyciu Ctrl + kolko myszy, w trybie debug. Aktualna wartosc FoV jest tez w tym trybie wyswietlana na ekranie F8, powinno ulatwic dobranie wartosci do indywidualnych preferencji itp.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 10 Marca 2017, 19:49:14
Super z tym wątkiem. :) Czemu tylko w debugu? Jak nie sprawia problemów, to w podstawowym też by się przydało, zwłaszcza jak rewizja pozycji kamer nastąpiła.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 10 Marca 2017, 19:51:57
Popieram, w trybie normalnym też będzie się można wygodnie usadzić jak kto lubi.
Jak można, to prosił bym o sprawdzenie działania ctrl+r. Jakby nie zatykał dziury w PG (przewód główny powietrza), po użyciu ctrl+pause.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 10 Marca 2017, 19:54:57
Sprawdziłem na exeku z ósmego przed chwilą i działa. Wyłączamy radyjko, popełniamy loka, włączamy radyjko i trzyma ciśnienie. Samo kliknięcie on-off to za mało.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 10 Marca 2017, 19:57:53
Czemu tylko w debugu? Jak nie sprawia problemów, to w podstawowym też by się przydało, zwłaszcza jak rewizja pozycji kamer nastąpiła.
ZTCP to rolka jest przez niektorych uzywana do kontroli nastawnika itp, wiec wolalbym tutaj za bardzo nie mieszac. To i tak prowizorka do czasu gdy bedzie normalny ekran z ustawieniami, ktory powinien przejac tego typu sprawy. (a przelaczyc debug na szybko ctrl+shift+f12 to chyba tez nie taki straszny problem)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 10 Marca 2017, 20:00:23
Ale jak jest z controlem to spoko. Jak ktoś używa takiej kombinacji, to sobie przekonfiguruje na inny klawisz kontrolny. Chciałbym jednak by to było dla kowalskiego dostępne. Dla nas włączyć debuga, pokręcić rolką ,wyłączyć to nic, ale on jak nie zgłupieje, to przestraszy się nazwy debugmode.
Przetestowałem efekt i jest spoko, zakres nie powoduje dziwnych efektów w żadnym z ekstremów. Po mojemu to mogą sobie kręcić do woli.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 10 Marca 2017, 20:02:46
No ja wlasnie mam watpliwosci czy to jest cos do zostawienia w rekach zwyklego uzytkownika ;)  ale mozna zmienic, zobaczymy.

edit: aha, a tak zupelnie z innej beczki. Przelacznik przyciemnienia reflektorow, na ile to w rzeczywistosci przyciemnia swiatla? O polowe, mniej, wiecej?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 10 Marca 2017, 20:41:57
Zrobiłem update do najnowszej wersji i niestety, w przeciwieństwie do reszty zanotowałem spadek FPS o 50% na integrze intela. Wygląda, że na stałe włączone jest wygładzanie krawędzi.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 10 Marca 2017, 20:53:43
No ja mam skok na Bałtyku z 70 na 170 do 220FPS.
A teraz najważniejsza informacja jak dla mnie i pewnie też dla tych co nie wiedzieli. Po radio stopie można odhamować loka i skład pod warunkiem że jesteśmy w trybie normalnym. W trybie debug mode, nie uruchomimy składu, bo przewód główny nadal jest dziurawy i się nie napełni. W obu trybach sprawdziłem loki: ET22 EU07 i EP09. Tak ma być?
Zoom pod ctrl + scroll, jest genialny.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 10 Marca 2017, 21:13:46
Powiedzmy że prace nad shaderami powoli... przesuwają się do przodu :D
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 10 Marca 2017, 21:17:19
Dobrze idzie, trzymaj tak dalej. Obciąłem paznokcie, co by dziur w dłoniach nie wydrapać.:)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 10 Marca 2017, 21:17:44
Zrobiłem update do najnowszej wersji i niestety, w przeciwieństwie do reszty zanotowałem spadek FPS o 50% na integrze intela. Wygląda, że na stałe włączone jest wygładzanie krawędzi.
Tzn. multisampling? To sie chyba da wylaczyc przy ustawieniu parametru w .ini na 0 albo jakos tak. Ale nie probowalem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 10 Marca 2017, 21:20:44
Jak w ini na 0, to jak to się ma do suwaka w rainsted, gdzie jest priorytet. Nie wspomnę o ustawieniach sterownika karty graficznej bo tam priorytety można nadać.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 10 Marca 2017, 21:30:18
Przelacznik przyciemnienia reflektorow, na ile to w rzeczywistosci przyciemnia swiatla? O polowe, mniej, wiecej?
Pomierzyłem, policzyłem i wyszło mi, że tak - moc reflektorów zmniejszana jest do ok. 50%. Przynajmniej w ET41 i pochodnych ;) (EU06, EU07, EP07, EP08, pewnie też ET22 - w innych nie wiem).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 10 Marca 2017, 22:30:51
Dzieki, mniej wiecej tyle ustawilem, czyli moze dobrze bedzie.

Jak w ini na 0, to jak to się ma do suwaka w rainsted, gdzie jest priorytet. Nie wspomnę o ustawieniach sterownika karty graficznej bo tam priorytety można nadać.
Rainsted chyba ustawia ten sam parameter, tylko wyswietla wartosc 0 jako "1" itd. Jak to sie ma do ustawien karty to nie wiem, bo to chyba zalezy tez w czesci od oprogramowania karty -- np NVidia ma w opcjach odrebne ustawienia "popraw jesli exe ustawia mniej" i "ustaw tyle, i niewazne czego chce exe".
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 11 Marca 2017, 06:36:43
Żeby nie było, to porównanie z ilością FPS:
1. Stare exe 482
2. Exe na c++ bez zmian Milka (mniej więcej wersja z 27.02)
3. Wersja na GLFW (wersja z wczoraj)
Uruchamiam z tego samego katalogu, z tymi samymi ustawieniami.
ED:
Zmieniłem ustawienie na MSAAx8 (multisampling 3).
482: 30 FPS
c++ 2702: 30 FPS
c++ glfw: 20 FPS

Dodatkowo glfw na starcie nie ma MSAA a po paru sekundach ono się włącza niezależnie od ustawienia w ini.

ED2:
Pobawiłem się trochę i na wersji z 27.02 na MSAAx8 wyciągam 45 FPS, a na wersji na integracją z glfw już tylko 30 FPS.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 11 Marca 2017, 10:08:16
na wersji z glfw vsync włączony czy wyłączony?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 11 Marca 2017, 10:40:57
Tak tez wlasnie podejrzewam, ze chyba jest wlaczony. @Firleju, sprawdz na ostatniej wersji (0311) tam jest wylaczony domyslnie, albo wpisz vsync no w .ini?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 11 Marca 2017, 12:02:30
Witam.
U mnie odptaszkowanie synchronizacji na najnowszym exe podbija fps na TD do prawie 200. Na exe z paczki stoi jak zaklęte na 60. Pomimo pracy monitora na 75Hz.
 Generalnie spadek zaobserwowałem po wprowadzeniu GLFW. Ale tylko do czasu poprawy babola z liczeniem obiektów, który wykrył @ Tmj. Na wersji najnowszej mam minimum 30fps w Ostrowie na początku symulacji, gdy kamera skierowana jest od czoła na stojące składy. Czyli w polu widzenia ponad setka wagonów, kilka loków i mnóstwo torów i innych obiektów. A wcale nie mam jakiegoś wypasionego komputera. Stary biurowiec HP na E7200 z dodaną grafiką GTX460 ( ledwo zipie) i 4 Gb ramu. Zastanawiające jest, że u kolegów mających czasem nawet nowsze sprzęty, jest na odwrót. A może mój komputer lubi po prostu Maszynę:-)
Pozdrawiam.
 
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 11 Marca 2017, 12:27:08
GF9600GT + 4GB ram + IntelE6300 +XP. Jeszcze starszy, albo może raczej słabszy sprzęt, na starcie w kiblu w Ostrowie mam 41FPS załącznik. Na TD ponad 300. To wszystko jest na 170311. Ja jestem pełen uznania dla exe i swojego komputera.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 11 Marca 2017, 14:09:39
Zauważyłem taki błąd działania oświetlenia który ilustrują 2 poniższe zrzuty:
Po zapaleniu światła w kabinie teren na zewnątrz staje się jakby oświetlony i lepiej widoczny, podczas gdy powinno być dokładnie odwrotnie.
Światło odbite od szyby dodaje się do jasności obiektów na zewnątrz. Nie wiem czy coś się da z tym zrobić, bo tak chyba było od początku, ale jak już ktoś rusza te światła i poprawia, to może nie byłoby to takie niemożliwe do poprawienia.

Drugi błąd też jest związany z oświetleniem: w SN-61 nie działają lampy. Tzn jak się wyjdzie na zewnątrz to wyglądają na zapalone, ale nie oświetlają terenu. Po prostu nie ma żadnego efektu po zapaleniu światła. Testowałem na jedynej misji z SN-61, oczywiście dla porównania na tej samej misji wstawiłem stonkę zamiast SN-61 i oświetlała poprawnie.

Jeśli chodzi o działanie lamp, to chyba obecne rozwiązanie jest tymczasowe, więc może nie ma sensu zgłaszać uwag do niego. Gdyby był, to bym zgłosił, że znaki We8 i We9 są niewidoczne w nocy. Tzn migają na tak krótko, że bardzo trudno je zauważyć.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 11 Marca 2017, 14:13:54
SN ma tylko dwie lampy, wiec ma prawo świecić gorzej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 11 Marca 2017, 14:53:57
Ale ona w ogóle nie świeci. Porównywałem z SP42 na zapalonym tylko prawym reflektorze.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 11 Marca 2017, 16:04:22
Potwierdzam, brak świateł w SN61. Dojeżdżam do wagonu i żadnego oświetlenia (w załączniku). Za to jaki FPS.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 11 Marca 2017, 17:23:58
SN61 nie ma freespotów do świateł. Czy to może być tego wina?
Zauważyłem też, że auta nie świecą, ale nie wiem czy one mają animowane światła nawet. No i może nawet lepiej tak, niż by kradły sloty świateł pociągom.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 11 Marca 2017, 19:04:36
Wydaje mi się, że niektóre auta świecą. Nie mam pewności.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 11 Marca 2017, 19:13:06
Tak tez wlasnie podejrzewam, ze chyba jest wlaczony. @Firleju, sprawdz na ostatniej wersji (0311) tam jest wylaczony domyslnie, albo wpisz vsync no w .ini?
Wbiłem vsync no (chociaż teoretycznie sprawdzam na ostatniej wersji z repo). MSAAx8: 27.02 45 FPS, 11.03 30 FPS. 02.03 (glfw integration) 40FPS
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 11 Marca 2017, 19:20:31
Hmm troche dziwnie. Jesli to nie problem, moglbys jeszcze sprawdzic wydajnosc na 03.08? W 09+ wlaczone zostalo wygladzanie punktow, i moze akurat to gryzie sie ze starszym sprzetem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 11 Marca 2017, 19:24:03
Wysyp na Quarku. Wersja Ra 08.02.2017.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 11 Marca 2017, 19:59:19
Ty masz crash a ja mam tak, jak na screenie. Odpala się u mnie każdy scenariusz.
ED:
Powinienem dopisać, że tak mam na exe 170311 i na tym borlandowym z paczki całościowej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 11 Marca 2017, 20:15:56
Hmm troche dziwnie. Jesli to nie problem, moglbys jeszcze sprawdzic wydajnosc na 03.08? W 09+ wlaczone zostalo wygladzanie punktow, i moze akurat to gryzie sie ze starszym sprzetem.
Winny jest commit camera frustrum
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 11 Marca 2017, 21:30:52
Ok, ale commit ma polaczone zmiany kalkulacji widocznosci i wygladzanie punktow, natomiast w uaktualnieniach wydanych w watku bylo to podzielone -- kalkulacja widocznosci weszla w 3.08, a wygladzanie punktow w 3.09  Dlatego specjalnie pytam, czy jest jakas roznica w wydajnosci, przy porownaniu tych dwoch exe, bo moze latwiej da sie w ten sposob wylapac, co sprawia u ciebie problem.

(albo mozesz po prostu w world.cpp wykomentowac
glEnable( GL_POINT_SMOOTH );
i porownac, jesli tak jest prosciej ;d
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 11 Marca 2017, 22:16:39
W 170211 coś było zmieniane w znikaniu obiektów. No to melduję, że dynamiki wyświetla do góry nogami, ale przyduże trójkąty terenu nadal znikają jak znikały.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 11 Marca 2017, 22:20:26
Wysypik w załączeniu. To co zwykle czy jakaś odmiana? Tym razem pracowałem na luźnym komputerze, więc brak pamięci nie wchodzi w rachubę.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 11 Marca 2017, 22:27:43
Nie, to inny blad :)  Zeby bylo smieszniej, ten sam ktory trafil sie Stele kilka postow wyzej. Czy to moze tez na tym nowym Quarku? Nie bardzo wiem skad sciagnac, wiec trudno sie przyjrzec.

przyduże trójkąty terenu nadal znikają jak znikały.
Trojkaty terenu to inna czesc kodu do rysowania, probowalem sie temu dzisial przyjrzec, ale tylko na placz mi sie zebralo :|  okazuje sie ze teren jest teoretycznie podzielony na segmenty, ale co akurat w segmencie laduje, a co poza nim, to juz zupelnie inna bajka, i bez przepisania w zasadzie od nowa nie wiem, czy sie kiedykolwiek wyprostuje. Tyle dobrego, ze przy okazji zerknalem na zwiekszanie zakresu rysowania w zaleznosci od fps, ale moglo byc wiecej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 11 Marca 2017, 22:29:10
Quarka testuję w wersji http://rainsted.com/warsztat/Quark/quark-170208.7z Bo taka (po drobnych przeróbkach dekoracji joeya) ma iść do paczki, chyba że Ra uwinie się ze zmianami układów torowych wcześniej.

Cofam wszelkie oskarżenia o skopanie wyświetlania tri z boku. To ja ślepy byłem, na borlandzie jest identycznie. Dodatkowo część jeziorek miała ograniczony zasięg wyświetlania, ale to nie pomogło na widoczność boczną. Mam je w maksie to zwiększę teselację i tyle. :) Jeszcze raz przepraszam za sianie zamętu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 12 Marca 2017, 00:03:19
W sumie dobra wiadomosc, odpadnie mi szukanie krzaka ;)  Co do teselacji to jesli mozesz, sprawdz najpierw czy na dzisiejszym uaktualnieniu cos sie pod tym wzgledem polepszy/pogorszy? Wymieniony jest kod rysujacy dla kwadratow kilometrowych, ale trudno powiedziec na sucho czy zrobi jakas roznice.

Oprocz tego, wprowadzone zmiany:

- dodany now przelacznik o ktory prosilo pare osob, przygaszanie swiatel lokomotywy. Uaktywniany przez Ctrl+Shift+L, deaktywowany przez Ctrl+L. Pod samym L sa chyba styczniki liniowe, wiec moze byc zabawnie. Nazwa przelacznika w pliku .mmd to dimheadlights_sw Nawiasem mowiac, cala obsluga przelacznikow tez jest do przepisania :x

- zmienilem troche system dynamicznego zwiekszania/zmniejszania detali. Przy fps > 65 symulator stopniowo zwieksza zakres widocznosci obiektow, maksymalnie do 3x wartosci standardowej. Czyli obiekty ze zdefiniowanym zakresem widocznosci do 1km sa teraz widoczne z maks. ~3, a teoretyczny maksymalny zakres widocznosci to 7.5km Biezaca wartosc modyfikatora widoczna jest na ekranie F8.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 12 Marca 2017, 00:44:09
Nie, to inny blad :)  Zeby bylo smieszniej, ten sam ktory trafil sie Stele kilka postow wyzej. Czy to moze tez na tym nowym Quarku? Nie bardzo wiem skad sciagnac, wiec trudno sie przyjrzec.
Nie, na tej samej misji i scenerii co poprzednio.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 12 Marca 2017, 01:00:08
Aha. Krzak byl gdzies przy skanowaniu tabelki predkosci, wiec na razie odpuszcze sobie tropienie go, bo moze zginie razem z reszta skanowania, gdy Firleju skonczy swoja wersje. Z tego co pamietam to chyba raz mi sie losowo trafil przez caly czas dreczenia exe, wiec wyglada na dosc rzadki/losowy przypadek.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 12 Marca 2017, 06:40:40
Hej, ale u mnie symulator nigdy nie ma >60 FPS, bo używam opcji vsync on. FPS to nie jest dobre kryterium. Już raczej jakiś wewnętrzny czas renderowania klatki w milisekundach, niezależny od ustawień karty graficznej, sterownika i systemu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 12 Marca 2017, 07:33:55
170312, Bałtyk, Kaliska. Żadnych uwag, wszystko zadziałało tak, jak powinno.
Uwolniłem monitor od synchronizacji, skoro można. Kryterium ilości FPS zawsze było wyznacznikiem wydajności.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 12 Marca 2017, 07:51:04
OK, test na Drawinowie: cała droga 60FPS, ogromna poprawa względem 20-30 co miałem wcześniej na stacjach Grodzisk, Drawinowo, Grabówek czy Włodowice. Niestety ogromne pogorszenie jakości obrazu i to wcale nie na stacjach, które wyglądają tak samo, tylko jadąc przez las i wieś, gdzie miałem zawsze 60FPS na starym exe.

Pogorszenie polega na wyskakiwaniu dużych elementów typu ściany lasu, budynki i grupy drzew przed kamerą. Proszę, zmniejszanie widoczności obiektów kompletnie nic nie daje dla wszystkich współczesnych a nawet dość starych kart graficznych. To nie dlatego MaSzyna przycinała. Tak jak mówiłem - przycinanie występowało u mnie dokładnie identycznie dla 2 różnych kart graficznych (bardzo stary Radeon i dużo nowszy GTX960), do tej samej wartości i w tych samych miejscach - na dużych torowiskach. Jadąc przez wieś miałem 60FPS nawet na zintegrowanym Intelu we w miarę nowym laptopie.

Najlepiej dodać opcję w konfiguracji, tzn ini, drawing distance, bez limitu, albo z limitem 10km. Wtedy po szybkich testach będziemy wiedzieć co wpływa na FPS na różnych kartach graficznych, a co nie.

I jeśli już modernizujemy MaSzynę, to modernizacja raczej nie powinna się koncentrować na muzealnych komputerach. MaSzyna była muzealnym symulatorem dla muzealnych komputerów. Największą jej wadą był kompletny brak wsparcia dla nieco nowszych (a przez nowsze mam na myśli takie z 5-6 letnie) komputerów. Całe szczęście to się da pogodzić dzięki konfiguracji. Jak ktoś chce sobie MaSzynę odpalić na kalkulatorze, nie ma sprawy - może sobie wyłączyć wszystkie detale graficzne i pójdzie. Jak ktoś ma kilkuletni sprzęt (a nie kilkunastoletni) - włączy sobie wszystko na maksa i też będzie zadowolony.

Od początku mojej przygody z MaSzyną zauważyłem niemal kompletny brak wpływu włączonych poprzez sterownik karty graficznej detali a FPS. Obojętnie czy był to Radeon z seri 4, 5, 6, czy NVidia - ustawienia grafiki w ogóle nie wpływały na FPS. Mało tego - ten sam efekt obserwowałem przed i po zastosowaniu mojego patcha, który ustawiał wszystkim obiektom widoczność -1. Brak wpływu na FPS, równy przed i po (chociaż różnica w delatach grafiki była wyraźnie zauważalna). Pomimo tego, że masa osób usiłowała zaprzeczać faktowi - tak samo nie miałem żadnej różnicy w FPS pomiędzy teksturami TGA i DDS. Była niewielka różnica w czasie ładowania, ale mało zauważalna.

Ergo nie tędy droga. MaSzyna zacinała mi z kolei po ustawieniu wszystkich efektów graficznych na minimum przykładowo na Drawinowie, na stacjach. Mogłem sobie nawet wygładzanie krawędzi wyłączyć i filtrowanie tekstur, tam klatkowało i koniec. Na każdej karcie graficznej tak samo, efekt klatkowania był zależny wyłącznie od CPU, w ogóle nie od karty graficznej.

FPS jest wyznacznikiem wydajności jedynie na monitorach CRT lub tych nowszych, które mają dynamiczną synchronizację ramki. Przy opcji vsync on FPS nie mówi nic. Nawet jak moja karta jest w stanie wyświetlić 300FPS, to i tak wyświetli 60 więc co mi mówi o wydajności FPS? Nic.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 12 Marca 2017, 08:11:10
@HTD, z całym szacunkiem ale wygadujesz rzeczy, które Ty doświadczyłeś. Moje doświadczenia, są zupełnie inne. Nic mi nie wyskakuje, jakość obrazu nie pogorszyła się. Ale to subiektywna ocena. Nie zgadzam się, że wprowadzenie dds nie miało wpływu na czas ładowania, bo to dziś jeszcze można udowodnić. Do tego tekstury TGA zajmują więcej miejsca w pamięci. Ponieważ zawsze pod ręką miałem kilka komputerów, to pozwolę sobie zaprzeczyć, że efekt klatkowania zależy tylko od procesora. Przytaczać przykładów nie będę, tu nie ma miejsca na takie dywagacje, chyba, że w osobnym wątku. O ile wiem, nie mamy możliwości zrobić rewolucji na posiadanym exe, materia jest delikatna i czasem doprowadza do płaczu i krwawienia oczu (cytata za tmj i milek7). Twoje pomysły można by zastosować w aplikacji od nowa pisanej, jeśli w ogóle coś wnoszą. Przejadę Drawinowo, wypowiem się na temat wyglądu lasów i wsi.
ED:
OK, test na Drawinowie: cała droga 60FPS, ogromna poprawa względem 20-30 co miałem wcześniej na stacjach Grodzisk, Drawinowo, Grabówek czy Włodowice. Niestety ogromne pogorszenie jakości obrazu i to wcale nie na stacjach, które wyglądają tak samo, tylko jadąc przez las i wieś, gdzie miałem zawsze 60FPS na starym exe.
Pogorszenie polega na wyskakiwaniu dużych elementów typu ściany lasu, budynki i grupy drzew przed kamerą. <ciach>
Nic mi nie wyskakiwało FPS od 65 na stacjach do 200 w trasie. Oczywiście uwolniony monitor od synchronizacji. Jak wiesz posiadam nie najnowszy sprzęt i z wyniku jestem bardzo zadowolony.
Powtórzę pytanie o migotanie krawędzi przenikających się tekstur (przykład: trawa+podsypka, ale nie tylko bo są inne tekstury nakładane na trawę). Będzie można coś na to poradzić? Nie pytam z niecierpliwości, jestem zwyczajnie ciekawy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 12 Marca 2017, 12:02:53
U mnie ucina dźwięki syreny, dźwięk rozpoczynający i trwający jest, natomiast kończącego wcale nie odpala. Na exe 11.03 działa bez problemu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 12 Marca 2017, 12:11:29
Jakbyś jeszcze loka podał, bo wiesz w siódemce, ósemce i dziewiątce mam ok.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 12 Marca 2017, 12:15:25
Traxx, kibel, na razie tylko odpaliłem i był ten sam błąd. U mnie na siódemce dźwięk się kończący odpala, ale nie trwa do końca, tylko go ucina, a w tych co wymieniłem wgl sie nie odpala.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 12 Marca 2017, 12:33:34
Sprawdziłem, tak jak pisałem 07, 08, 09 mam dobrze. Trax jest dziwny na 0311 i na 0312
Kibel jest ok na 0311, jest źle na 0312. Potwierdzam, że z dźwiękami Traxa i Kibla coś się zadziało.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 12 Marca 2017, 12:54:05
Pogorszenie polega na wyskakiwaniu dużych elementów typu ściany lasu, budynki i grupy drzew przed kamerą.
Sprawdz, jesli mozesz, czy to wystepowalo przy wersji 03.12, czy takze na poprzednich? Albo wylacz na chwile vsync in 03.12 i porownaj czy dalej jest to samo?

W 03.12 przy zmianach zgubilo sie dotychczasowe zachowanie domyslne symulatora, czyli zwiekszenie poczatkowego zakresu widzialnosci przy fps > ~30. Idzie do porawki, lacznie z przebazowaniem tego na czas kreslenia ramki, bo to sensowny pomysl.

edit:
Cytuj
Proszę, zmniejszanie widoczności obiektów kompletnie nic nie daje dla wszystkich współczesnych a nawet dość starych kart graficznych.
Cytuj
OK, test na Drawinowie: cała droga 60FPS, ogromna poprawa względem 20-30 co miałem wcześniej na stacjach Grodzisk, Drawinowo, Grabówek czy Włodowice.
Nie wydaje ci sie, ze tutaj sam sobie troche przeczysz? :)  Gdyby regulacja widocznosci faktycznie nic nie dawala, to zmiany nie powinny wplynac na fps ktorego doswiadczasz, i tam gdzie miales 20-30, nadal mialbys 20-30. Skoro jednak zamiast tych 20-30 masz 60+ to chyba jednak jakis wplyw na wydajnosc to ma.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 12 Marca 2017, 13:09:10
Do kolekcji. Sceneria ta sama, misja inna, szybko poszło, bo w mniej niż 10 minut.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 12 Marca 2017, 14:51:13
Zmiana zakresu na wielkie trójkąty nie pomogła. Gdy jest 3x to jest, spoko, ale jak mi fps spadł i zeszło do 1.4x to zaczęło być brzydko. Znacznie brzydziej niż wcześniej. Nie obcina rysowania całości. Teren w e3d był po horyzont, tory ucinało w widocznej odległości, dworca wyświetlało tylko niektóre elementy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 12 Marca 2017, 16:10:27
OK, czyli wyglada na to ze eksperyment sie nie powiodl, odlozymy to do czasu gdy teren zostanie ogolnie ogarniety. A na razie wracamy do tego co bylo, a wlasciwie czesciowo do tego co bylo (kod rysujacy) ale z regulacja zakresu na podstawie predkosci rysowania ramek, a nie fps.

Nawiasem mowiac, wyglada na to ze powrot do starego renderowania terenu naprawil tez uciete dzwieki syreny. Albo moze ja gluchy jestem, ale tak czy owak magia panie, magia.

A zeby nie bylo calkiem nudno, to symulator ma teraz swoja ikone na belce okna (glownego okna, nie tego do logowania) prawie jak prawdziwy program :d

edit:
Do kolekcji. Sceneria ta sama, misja inna, szybko poszło, bo w mniej niż 10 minut.
To chyba znowu brak pamieci jest, bo wylecial na bad_alloc() jak przedtem. Chociaz zawsze w tym samym miejscu, co jest dosc podejrzane. Troche trudno dojsc, czemu akurat tam, ale jesli uda mi sie wywolac to u siebie, to sie przyjrze.

Powtórzę pytanie o migotanie krawędzi przenikających się tekstur (przykład: trawa+podsypka, ale nie tylko bo są inne tekstury nakładane na trawę). Będzie można coś na to poradzić? Nie pytam z niecierpliwości, jestem zwyczajnie ciekawy.
Tutaj wplyw ma w duzej czesci ograniczenie 'rozdzielczosci' liczb zmiennoprzecinkowych, im dalej od "punktu 0" tym jest gorzej. Byc moze uda sie cos tutaj zrobic stosujac pewne sztuczki, ale zadnej gwarancji ze cos z nich wyjdzie niestety nie ma, zwlaszcza gdy kod rysujacy jest zakrecony tak jak jest. Sam chcialbym to poprawic, mnie tez to denerwuje ;d

edit2: aha, zapomnialem, poniewaz zgloszono zapotrzebowanie to ctrl + rolka kontroluje teraz przyblizenie takze w trybie normalnym, nie tylko debug.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 12 Marca 2017, 17:56:23
@tmj, dobra, usuwam poprzedni komentarz, odnoszący się do poprzedniej wersji.

PEŁEN SUKCES. Na 312b w Drawinowie mam cały czas 60FPS i nie ma "pustyni". Ideał! Rysowanie mam 1.5x na stacjach, poza stacjami 3x, czyli teraz działa to dokładnie tak jak powinno.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 12 Marca 2017, 18:07:37
Ktoś kiedyś pisał, że nie ma sensu, żeby kosz na śmieci był widoczny z 500m, racja. Ale ściana lasu to nie wiem, nawet z kilometra powinna się wyświetlać. Podobnie budynki i drzewa.
Zgadza sie, sek w tym ze symulator nie rozumie czegos takiego jak "kosz" czy "sciana lasu" -- dla niego to jest wszystko to samo, zbior trojkatow ktore kaze mu sie narysowac. A kiedy rysowac, to juz jest w duzym stopniu decyzja autora obiektu i/lub sceny, ktory ustawia parametry minimalnego i maksymalnego zakresu widocznosci. W przypadku scian lasow i innych tego typu konstrukcji problematyczne moze byc podejscie konstruowania tychze w oparciu o pojedyncze prostokaty kilometrowej i wiekszej dlugosci. Do pewnego stopnia exe sobie to podzieli na mniejsze kawalki, ale na pewno nie pomaga to w okresleniu, gdzie taki obiekt sie znajduje, i kiedy go wyswietlic.

Jesli mozesz, to sprawdz tez jak sytuacja wyglada w 03.12b -- klopoty w 03.12 do pewnego stopnia byly kombinacja wlaczonego vsync i zmienionej regulacji widocznosci, co spowodowalo ze widziales mniej wiecej to, co symulator zazwyczaj wyswietla przez pierwszy ulamek sekundy swojej pracy. W biezacym uaktualnieniu powinno to ulec poprawie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 12 Marca 2017, 18:29:17
Jak coś, to w kodzie powinny się jeszcze pałętać resztki przesuwacza scenerii po przekroczeniu (chyba) 10 km od środka.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 12 Marca 2017, 18:31:29
Teraz jest idealnie w tej wersji. W poprzednich nie było przycinania, ale było klatkowanie. Teraz wilk syty i owca cała. Nie ma ani klatkowania ani przycinania. Jest super. Nie wiem jaką magią to osiągnąłeś, ale to mocne voodoo ;) A co do tej odległości od środka, czy to jest bug OpenGL, czy efekt jakiegoś innego problemu?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 12 Marca 2017, 18:34:36
Jak coś, to w kodzie powinny się jeszcze pałętać resztki przesuwacza scenerii po przekroczeniu (chyba) 10 km od środka.

Aha, jest tam cos takiego, ale wylaczone. Mysle raczej o zrobieniu tego dynamicznie, tzn zamiast bawic sie w ustawianie macierzy na pozycje kamery a potem przesuwac dodatkowo o wspolrzedne obiektu, mozna by sprobowac podejscia gdzie kamera jest zawsze traktowana jakby byla w punkcie 0, a obiekty sa jednynie przesuwane o roznice miedzy kamera a ich wlasna pozycja. Ale to moze wymagac zmiany tego, jak obecnie kalkulowane i przechowywane sa wspolrzedne, na sucho trudno powiedziec.

A co do tej odległości od środka, czy to jest bug OpenGL, czy efekt jakiegoś innego problemu?
To troche kombinacja czynnikow, ale oba sprowadzaja sie do tego, ze liczby typu float maja ograniczona precyzje -- im wiecej liczb po przecinku, tym mniej 'miesci sie' przed przecinkiem, i odwrotnie. Wiec przy obiektach o wspolrzednych kilku- lub kilkunastu tysiecy metrow, precyzja spada wrecz do centymetrow, i to co technicznie jest of siebie odsuniete, zaczyna sie pokrywac. Dodatkowo openGL (ale to nie jest tylko openGL) uzywa tych liczb do okreslenia na jakiej 'glebokosci' zostaly namalowane piksele, co jest uzywane przy decyzji ktore trojkaty zaslaniania inne. Podobnie wiec, wieksza precyzja blisko kamery skutkuje pogorszeniem dla obiektow odleglych. Mozna to troche kontrowac renderowaniem tzn osobno obiekty odlegle, osobno bliskie, albo kombinowaniem z tzw buforem logarytmicznym, ale to sa dodatkowe komplikacje.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 12 Marca 2017, 19:16:35
ztcp to depth buffer w opengl jest logarytmiczny
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 12 Marca 2017, 19:27:10
Nie dam glowy ze cos sie pod tym wzgledem nie zmienilo, ale do niedawna przynajmniej skalowanie bylo linearne + troche dodatkowego kombinowania*; gdyby bylo inaczej ludzie nie marnowali by wiele energii zeby temu zaradzic ;)  tutaj jest niezly artykul na ten temat: http://outerra.blogspot.com/2012/11/maximizing-depth-buffer-range-and.html

edit:
*) tutaj jest artykul o szczegolach, i fajny kalkulator ktory demonstruje jak zmienia sie rozdzielczosc w zaleznosci od parametrow bufora, i polozenia obiektu: https://www.sjbaker.org/steve/omniv/love_your_z_buffer.html
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 12 Marca 2017, 19:50:39
tak, masz rację. miałem tylko na myśli że nie jest całkowicie liniowy tylko wraz z oddalaniem się od znear precyzja maleje. (co właściwie ze względu na to że floaty też tak to jeszcze bardziej pogarsza sprawę przy dalszych obiektach)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 13 Marca 2017, 07:37:35
Ktoś wie co tu się stało? Jechałem sobie dziś na nowym exe scenariusz calkowo_sn61, ale bez SN-61, z racji tego, że popsuta jest. Zamiast tego wziąłem stonkę. I niespodzianka - trasa nagle dostała działającego kierpocia, tak sama z siebie. Nigdy na tej trasie nie słyszałem kierpocia, chociaż ewidentnie sygnał odjazdu jest nagrany. Przez całą trasę rozkład jazdy się przewijał, pomimo tego, że nigdy mi się to nie zdarzało na tej trasie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 13 Marca 2017, 10:16:33
Ale tam od jakichś dwóch lat powinien być kierpoć i przewijany rozkład. Robiłem to kiedyś razem z SKP. :D
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 13 Marca 2017, 11:39:05
Ktoś wie co tu się stało?
No to przejechałem na SN61 i też mi się przewija rozkład i mam kierpocia.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 13 Marca 2017, 13:54:07
Ale na starym exe też? Bo mi na starym exe (wersja 482 bodajże) kierpoć nie działał. Później nie testowałem, dziś pierwszy raz odpaliłem to na nowym exe i kierpoć działał. Wyglądało to tak, jakby nowe exe miało poprawionego jakiegoś buga który psuł kierpocia. No albo to jakieś czary.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 13 Marca 2017, 15:03:07
Nie sprawdzalem na exe z pacza, wydaje mi sie ze nie dzialalo. Bedzie chwila sprawdze, calej scn nie musze jechac.
ED:
Na exe 481 coś ze skanowaniem i tabelą jest nie tak, po zakończeniu manewrów w Jarkawkach, w tabeli nie ma stop_info. Nawet AI szamocze się, nie wie czy ma jechać czy stać. Myślę, że to już mało ważny szczegół jest.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 13 Marca 2017, 18:28:37
Sprawdziłem ten GL_POINT_SMOOTH i to nie to. Niestety camera frustum tutaj psuje. Myślę, ze wprowadziłeś dużo cache misses w tym kodzie i ograniczyło mocno wydajność.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 13 Marca 2017, 19:28:48
Sek w tym, ze frustum to jest zaledwie kilka przemnozen zwyklych macierzy 4x4 na ramke, i podobnie ograniczony wplyw przy kalkulacji widocznosci (kilka-kilkanascie mnozen, w porywach kilkadziesiat przy duzej ilosci pojazdow na ekranie) A symulator wykonuje takich operacji na ramke w tysiacach jesli nie dziesiatkach tysiecy, wiec 50% spadek wydajnosci ma tu bardzo malo sensu.

Przyszlo mi do glowy cos innego -- w tym uaktualnieniu eksperymentalnie jest tez wylaczony limit dla kalkulacji fizyki, tzn poprzednio liczone bylo maks. do 20 iteracji, a po zmianie liczy tyle, ile mu wyjdzie. Zastanawiam sie teraz, czy to nie powoduje roznicy przy slabszej wydajnosci, byloby to bardziej sensowne wytlumaczenie. Przywroce w nastepnym uaktualnieniu ugraniczenie i zobaczymy, czy cos sie zmieni.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 13 Marca 2017, 19:48:20
Ale robisz te dodatkowe obliczenia na danych, które masz aktualnie już użyte (więc są w cache) czy ciągniesz na nowo z ram-u? Jak to drugie to spadek wydajności masz gwarantowany.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 14 Marca 2017, 11:55:43
Przepuscilem exe przez profiler, i wychodzi ze potencjalnie zrodlem spowolnienia moze byc uzycie funkcji glGet do odczytu aktualnego ustawienia kamery; niektore implementacje/sterowniki nie lubia jej bardziej niz inne. Problem w tym, ze na chwile biezaca idealnego rozwiazania tutaj nie ma. Mozna:
- wrocic do tego co bylo, i ignorowac ze modele czasami znikaja kiedy nie powinny
- zostawic jak jest teraz i pogodzic sie ze na niektorych konfiguracjach bedzie wolniej
- wymienic odczyt na kalkulacje parametrow od strony exe. To akurat byloby najlepsze bo praktycznie calkowicie eliminuje koszt (w dodatku i tak trzeba to zrobic przy przejsciu na shadery itp) /ale/ latwo nie da sie zrobic, bo exe bardzo miesza przy renderowaniu widoku z kabiny, i dopoki sie tego nie rozsupla, zwykla wymiana wiecej psuje niz naprawia.

na razie sklaniam sie ku 2 i docelowo 3.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 14 Marca 2017, 12:02:23
Może glGet raz na ileś klatek (co sekundę?). Przez większą część czasu i tak się kamerą nie rusza specjalnie + zakres widoczności większy niż w rzeczywistości co powinno pomóc na delikatne ruchy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 14 Marca 2017, 12:41:11
Co sekunde to chyba raczej nie (trzeba by sie zaczac bawic w dodatkowe sprawdzanie czy nie bylo przelaczenia widoku np na lusterka itp) ale mozna by sprobowac uaktualniania co kilka klatek, zobaczymy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 14 Marca 2017, 13:29:03
No też wydaje mi się, że jeśli funkcja jest zasobożerna to lepiej jej nie uruchamiać za często.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 14 Marca 2017, 14:38:27
Przepuscilem exe przez profiler, i wychodzi ze potencjalnie zrodlem spowolnienia moze byc uzycie funkcji glGet do odczytu aktualnego ustawienia kamery; niektore implementacje/sterowniki nie lubia jej bardziej niz inne. Problem w tym, ze na chwile biezaca idealnego rozwiazania tutaj nie ma. Mozna:
- wrocic do tego co bylo, i ignorowac ze modele czasami znikaja kiedy nie powinny
- zostawic jak jest teraz i pogodzic sie ze na niektorych konfiguracjach bedzie wolniej
- wymienic odczyt na kalkulacje parametrow od strony exe. To akurat byloby najlepsze bo praktycznie calkowicie eliminuje koszt (w dodatku i tak trzeba to zrobic przy przejsciu na shadery itp) /ale/ latwo nie da sie zrobic, bo exe bardzo miesza przy renderowaniu widoku z kabiny, i dopoki sie tego nie rozsupla, zwykla wymiana wiecej psuje niz naprawia.

na razie sklaniam sie ku 2 i docelowo 3.
Żeby nie rozgrzebywać kodu można by zachować stos macierzy, tylko napisać klasę z api takim samym jak w opengl i najlepiej użyć GLM do obliczeń.

Shadery ostatnio podpiąłem eksperymentalnie do VBO (https://milek7.pl/.stuff/eu07scr/03-12/), tylko trzeba naprawić freespoty, uzyć współczynnika specular z obiektów, poprawić ustawienia świateł i ogólnie zrobić porządek. Póki co macierze też wyciągam z glGet przed rysowaniem i wpycham do uniformów, więc też przydało by się to poprawić skoro są problemy z wydajnością glGet. Jak ktoś chce mogę wrzucić ten kod co mam na githuba.
 
Ostatnio mam trochę innych rzeczy do roboty i będę mógł skończyć grzebanie w shaderach i zrobić stos macierzy na GLM dopiero pod koniec/w następnym tygodniu.
btw. tmj, nie wpadłbyś na irca?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 14 Marca 2017, 14:54:35
Żeby nie rozgrzebywać kodu można by zachować stos macierzy, tylko napisać klasę z api takim samym jak w opengl i najlepiej użyć GLM do obliczeń.
Sek w tym ze rozgrzebac i tak chyba trzeba bedzie, bo tak jak zauwazyles, shaderom trzeba bedzie podawac macierze do rysowania, a w trybie kabinowym sa robione takie siupy z przesunieciami, rotacja itp ze --jak to mowia-- bez pol litra nie rozbieriosz. Wiec na dluzsza mete chyba lepiej to bedzie uproscic, bo bedzie wylazilo do konca zycia. Glm podpialem do tego recznego liczenia, ale wlasnie na trybie kabinowym polegl (w zewnetrznym jest prawidlowo) Tez sie zastanawialem nad zrobieniem takiego programowego stosu, to bedzie chyba najwygodniejsze podejscie.

Aha, co do freespotow, to oswietlenie torow jest slabe, bo tory chyba nie bardzo maja ustawione wektory normalne. Przy sprzetowych swiatlach jest podobnie, i ja tam oszukuje oswietlajac je skladnikiem ambient dla swiatla ;x

Na ircu to tak chyba z 15 lat nie bylem, za leniwy jestem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 14 Marca 2017, 15:18:51
No bez rozgrzebywania to trzeba by zaimplementować glTranslate, glRotate, glScale, glMultMatrix, glPushMatrix, glPopMatrix, itp. i liczyć to sobie samemu w glm, przy każdej zmianie ustawić flagę dirty. Zwrappować glDrawArrays i jeżeli jest ustawione dirty to przepchać macierze do uniformów. Wtedy obeszło by się prawie bez zmian w obecnym kodzie.

Oczywiście przyszłościowo lepiej by było pozbyć się tego wrappera i przekazywać macierze na zwykłym stosie w argumentach metod, ale trzeba by wtedy rozgrzebać te kabiny i wszystko.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 14 Marca 2017, 20:53:49
Z cyklu "zaraz mnie cos strzeli..."

Zaczalem pisac zastepstwo dla macierzy opengl. Zrobilem tak z 90% dojechalem do gluLookAt i "przypomnialo mi sie" ze matryca produkowana przez lookAt() nie zastepuje biezacej, ale jest przez nia mnozona. Wiec z ciekawosci odkomentowalem ten nieszczesny kod, ktory wczoraj sie rozlazil, zmienilem foo = glm::lookat() na foo *= glm::lookat() i wszystko poszlo jak trzeba D:

W sumie klasa zastepcza sie nie zmarnuje, bo i tak trzeba by bylo ja kiedys zrobic, ale na razie moge sobie odpuscic konczenie jej, skoro zwykla wymiana wystarcza :d

@Firleju, sprawdz jesli mozesz czy w dzisiejszym uaktualnieniu wydajnosc sie poprawi.

Dodatkowo (zeby nie bylo nudno) wymienilem obsluge UI na cos odrobine bardziej UI-podobnego, z zalozeniem ze ulatwi to dalsza wymiane/podpiecie prawdziwego systemu UI na przyszlosc. Zmiana jest tylko 'pod maska' wiec wizualnej roznicy nie ma, poza ujednoliceniem kolorow. Nie wszystkie panele sa jeszcze przywrocone na 100% ale wiekszosc dziala, ale na oslode jest pasek postepu ladowania scenerii, zamiast dotychczasowych raczej bezuzytecznych komunikatow :P

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: RoboBatman w 14 Marca 2017, 21:06:47
Cytat: tmj
ale na oslode jest pasek postepu ladowania scenerii, zamiast dotychczasowych raczej bezużytecznych komunikatów"
Bardzo fajnie, ze zaimplementowałeś/-liście (nieprawidłowe skreślić) ten pasek ładowania zamiast jak to ty stwierdziłeś "zamiast dotychczasowych raczej bezużytecznych komunikatów". Był to jeden z pomysłów, który wpisałem w wątku odnośnie kto czego sobie "życzy/widziałby to" lub czego brakuje jeszcze w symulatorze MaSzyna. W mojej opinii - bardzo mi tego brakowało w oknie ładowania scenerii z symulacją. Może dla niektórych pasek jest bezużyteczny, ale jak dla mnie/niektórych bardzo pożyteczna rzecz.Z mojej strony Dziękuję :).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 14 Marca 2017, 21:09:53
Brak reakcji na F1, F2, F3 F8 i F10 zamierzony (Debug mode)?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 14 Marca 2017, 21:16:08
Chodzi o panel z dodatkowymi informacjami w trybie debug? Powinny byc dostepne po kolejnym wcisnieciu F1, chociaz nie ma na razie wszystkich danych.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 14 Marca 2017, 21:21:49
Nie, żadne kolejne przyciskania klawiszy co wymieniłem, nie dają rezultatów. Także w trybie normalnym.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: dymus w 14 Marca 2017, 21:25:15
U mnie działają poprawnie w normalnym i w debuge (F1, F2 i cała reszta).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 14 Marca 2017, 21:32:04
Ciekawe, u mnie tylko F4, F7 i widać zmianę czasu pod shit+F1. Aż wróciłem do wersji 12b i tam wszystko ok.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Balaclava w 14 Marca 2017, 21:55:24
Ja mam taką sugestię (może zbyt dalekosiężną), aby w przyszłości wprowadzić możliwość skalowania modelu w 3 wymiarach za pomocą podobnej składni:
scale (p1) (p2) (p3)
    node -1 0 model blablabla endmodel
endscale
Zastosowanie z życia wzięte: Nie mamy w symku chłodni kominowych o wysokości 120m, które są mi potrzebne do wstawienia w Elektrowni Rybnik. Mamy za to chłodnie, o ile dobrze pamiętam 80 metrowe. Aby mieć model 120 metrowej chłodni, zamiast tworzyć nowy model, o prostu podaję parametry skali do wpisu INC chłodni 80 metrowej.
Oprócz tego przydatne byłoby wykonywanie działań matematycznych wewnątrz plików INC. Zamiast trzymać kilkadziesiąt modeli wiaduktów o różnych długościach, wystarczyłby jeden model, a jego długość byłaby obliczana na podstawie podanych parametrów do INC.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: matek123 w 14 Marca 2017, 22:00:43
W tedy wiadukt musiałby się składać z 3 modeli, bo przyczółki też by były rozciągnięte. W sumie już mamy taki wiadukt.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 14 Marca 2017, 22:02:36
Ciekawe, u mnie tylko F4, F7 i widać zmianę czasu pod shit+F1. Aż wróciłem do wersji 12b i tam wszystko ok.
Myslalem ze moze to coz co wylazi w trybie pelnoekranowym ale nie, tam tez wszystko u mnie dziala. Byloby latwiej zrozumiec, gdybys w ogole nie mial zadnych paneli, ale jesli nie wlaczaje sie tylko niektore to nie wiem co to moze byc :<
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 14 Marca 2017, 22:05:29
Też nie wiem, nie mam żadnych opisów słownych stanu pojazdu, tabeli skanowania ani rozkładów. Testowane na paczce co zwykle.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Balaclava w 14 Marca 2017, 22:05:50
Przykładowy inc parametryzowanego wiaduktu o długości 20 metrów mógłby wyglądać podobnie:
model przyczolka
for i in range 20
    model segmentu
model przyczolka
Wtedy nie trzeba byłoby się martwić o rozciągnięte przyczółki. Ale to już bardziej podchodzi pod propozycję mini języka skryptowego dla INC.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 14 Marca 2017, 22:09:42
Też nie wiem, nie mam żadnych opisów słownych stanu pojazdu, tabeli skanowania ani rozkładów. Testowane na paczce co zwykle.
Czekaj czekaj, a ty masz na mysli panele widoczne w pojezdzie (skanowanie trasy, rozklad itp) czy te alternatywne, ktore wyswietlaja sie na zewnatrz? (pozycja kamery i inne takie) Bo jesli te drugie to faktycznie nie sa chwilowo podpiete.

Ja mam taką sugestię (może zbyt dalekosiężną), aby w przyszłości wprowadzić możliwość skalowania modelu w 3 wymiarach
Ze skalowaniem moze byc klopot, bo modele oprocz wspolrzednych wierzcholkow maja tez wektory normalne opisujace w ktora strone 'skierowany' jest kazdy trojkat, i tutaj skalowanie (zwlaszcza jesli nie jest takie samo we wszystkich wymiarach) potrafi sporo napsuc, i trzeba by to w locie korygowac.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 14 Marca 2017, 22:19:55
Nie mam ani na zewnątrz, ani wewnątrz pojazdu. Brak rozkładów i skanowania. Zmieniałem nawet klawiaturę.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 14 Marca 2017, 22:37:28
Też nie wiem, nie mam żadnych opisów słownych stanu pojazdu, tabeli skanowania ani rozkładów. Testowane na paczce co zwykle.
Czekaj czekaj, a ty masz na mysli panele widoczne w pojezdzie (skanowanie trasy, rozklad itp) czy te alternatywne, ktore wyswietlaja sie na zewnatrz? (pozycja kamery i inne takie) Bo jesli te drugie to faktycznie nie sa chwilowo podpiete.

Ja mam taką sugestię (może zbyt dalekosiężną), aby w przyszłości wprowadzić możliwość skalowania modelu w 3 wymiarach
Ze skalowaniem moze byc klopot, bo modele oprocz wspolrzednych wierzcholkow maja tez wektory normalne opisujace w ktora strone 'skierowany' jest kazdy trojkat, i tutaj skalowanie (zwlaszcza jesli nie jest takie samo we wszystkich wymiarach) potrafi sporo napsuc, i trzeba by to w locie korygowac.
Przemnożenie normalnych przez magiczny macierz mat3(transpose(inverse(macierz))) nie wystarczy?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 14 Marca 2017, 22:43:42
W zasadzie powinno, ale to sie samo nie zrobi :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 14 Marca 2017, 22:47:01
Witam.
 Potwierdzam błąd zgłaszany przez Krzyśka, brak wyświetlania parametrów po naciśnięciu F1, F2,F3 itd. Zmiana opcji na starcie też nie przynosi rezultatów.
Pozdrawiam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Tomnord15 w 14 Marca 2017, 22:54:11
U mnie brak wyświetlania parametrów wystąpił na scenerii TD, ale trwało to krótko i po chwili opcje te zadziałały.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 14 Marca 2017, 23:43:01
Obawiam sie ze napisy u mnie dzialaja, wiec trudno wylapac przyczyne. Mozecie podac troche szczegolow ustawien, w rodzaju rozdzielczosc ekranu, okno czy tryb pelnoekranowy itp? Czy napisow nie ma w ogole, czy wyswietla sie tylko panel startowy? Co z napisami dla dzwiekow, jak te ktore pojawiaja sie np w calkowo - niebezpieczny pociag, czy sa widoczne, czy tez ich nie ma?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 15 Marca 2017, 00:04:53
Bałtyk, Drawinowo, TD, Quark. Niezależnie od trybu debug, czy normal. Niezależnie czy pełno ekranowy, czy w oknie, napisów brak. Nie mam kompletnie nic. Z ustawień nie mam zaznaczonych napisów z glut 32, ale nawet jeśli zaznaczam to i tak ich nie ma. Funkcja wyjścia z programu F10 działa, ale bez opisu.
Jeszcze chwila, ale już wiem że wyświetlanie ma związek z rozdzielczością ekranu.
ED:
W rozdzielczości 1280*1024 w oknie i pełnoekranowym trybie, napisów brak. Po zmniejszeniu rozdziałki mam napisy w trybie okna, w trybie pełno ekranowym nie działa zmniejszenie rozdziałki.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 15 Marca 2017, 00:06:27
U mnie wszystko działa, klawisze działają, ekran ładowania jest fajny, tylko jedna uwaga.
Wcześniej była prędkość po wciśnięciu F2 dwukrotnym. Teraz nie ma. Jest tylko tabela skanowania. Rozumiem, że to tylko tymczasowe. Korzystając z okazji (że robisz nowe UI) - bardzo przydałoby się wyświetlanie prędkości, pozycji nastawnika, bocznikowania i chociażby 3 ciśnień dla lokomotywy. Oczywiście opcjonalne. To mogłoby się pokazywać razem z rozkładem. Obok, nad. Po naciśnięciu 2x F3. Zauważyłem, że całkiem użyteczny jest HUD w TD2. Może troszkę za duży. Nie trzeba pasków, ale parametry liczbowe były bardzo pomocne. Dzięki temu można przykładowo sprawdzić czy haslery pokazują prawidłowo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 15 Marca 2017, 00:18:35
Witam.
W moim przypadku brak jakichkolwiek napisów/parametrów pod klawiszami F1-F10. Uruchamiałem w oknie, w pełnym ekranie, odznaczałem GlUT32, i niestety bez skutku. Na panelu startowym podczas wczytywania scenerii wszystko jest oki. Problem występuje jedynie podczas symulacji, zarówno w trybie normalnym jak i debugmode. Analogicznie jak u Krzyśka. Zastanawiające, że log teraz nie odnotowuje naciśniętych klawiszy...Rozdzielczość u mnie 1280x1024. Co ciekawe zmiana jej w Rainsted nie przynosi efektu. Czy obecnie jest na sztywno brane to co ma pulpit?
Edit:
ED:
W rozdzielczości 1280*1024 w oknie i pełnoekranowym trybie, napisów brak. Po zmniejszeniu rozdziałki mam napisy w trybie okna, w trybie pełno ekranowym nie działa zmniejszenie rozdziałki.
Sprawdziłem, mam dokładnie tak samo. Przy 800x600 w oknie działa, przy pełnoekranowym i 1280x1024 już nie, a rozdzielczość jest na sztywno niezależnie od ustawień w ini.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 15 Marca 2017, 00:22:24
W trybie pełnego ekranu rozdziałka jest taka jak na pulpicie windows.
@HTD, cały problem polega na tym, że jak u kogoś jest dobrze, to nie szuka co może być przyczyną błędów u innych. Stąd w takich sytuacjach trzeba radzić sobie samemu. Pisałem, że funkcja klawiszy są zachowane, jedynie brak napisów. W poprzednim poście opisałem w jakich warunkach siadło wyświetlanie a w jakich jest. U mnie oczywiście.
ED:
Zmieniłem rozdzielczość ekranu (w ustawieniach windows) i w trybie pełnego ekranu na 1024*768 napisy się pojawiły.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Mariusz1970 w 15 Marca 2017, 00:37:45
Za skierowanie trojkata odpowiada kolejnosc wierzcholkow (lewo lub prawoskretny). Chyba, ze chodzilo o inne skierowanie :).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Marca 2017, 01:05:18
Ok, blad sie znalazl =)  UI bylo robione przy zalozeniu ze program bedzie dzialal z ekranem o proporcjach 4:3 lub szerszym, a nie wezszym, i w rezultacie kod probowal umieszczac napisy poza kadrem. W uaktualnieniu powinno byc juz w porzadku, a przy okazji powinno byc tez lepsze centrowanie grafiki w czasie ladowania, na tego typu ekranach.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 15 Marca 2017, 01:26:48
Monitory to raczej 5:4 maja. Sprawdze poprawke rano, ale z tego co przejechalem to nic wiecej sie nie popsulo. Dynamiczna regulacja widocznosci dziala. Stabilnosc jest dobra a wysypow coraz mniej. Pasek postepu dziala, ale pewnie trzeba go dopracowac. Ekran startowy przestal ginac po manipulacjach alt tab. To drobiazgi, ale wazne z punktu widzenia dbalosci o szczegoly. Dobrej nocy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Marca 2017, 01:36:59
Teraz to owszem, dosc czesto maja 16:9/10, ale ekran startowy jest dla starego "dobrego" 1024x768 wiec tego sie trzymamy ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 15 Marca 2017, 07:19:12
Ahh, czyli teraz będę musiał jeszcze pobawić się w łączenie zmian w wyświetlaniu tabelki. Cudownie. Wydajność sprawdzę dopiero po południu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Marca 2017, 12:51:39
Nie boj zaby, wyswietlanie jest teraz prostsze :) Zamiast bawic sie z glRaster, glPrint itp po prostu dodajesz skonstruowana linie tekstu do panelu i tyle, reszte robi UI.

edit: np wyswietlenie calej starej tabelki skanowania wyglada teraz tak:
                float4 linecolor( 225.0 / 255.0f, 225.0f / 255.0f, 225.0f / 255.0f, 1.0f );
                int i = 0;
                do {
                    std::string scanline = tmp->Mechanik->TableText( i );
                    if( scanline.empty() ) { break; }
                    UITable->text_lines.emplace_back( Global::Bezogonkow( scanline ), linecolor );
                    ++i;
                } while( i < 16 );
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 15 Marca 2017, 14:01:27
O, będzie przepisywanie z macierzy do macierzy ;) Teraz wrzucam do tej funkcji całą macierz a nie wywołuję ileś razy funkcje poszczególnych pół, bo to bez sensu było. I tak będę się bawił widzę. Potrzebuję też opcji przesunięcia tabelki w poziomie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Marca 2017, 14:17:59
Potrzebuję też opcji przesunięcia tabelki w poziomie.
Znaczy sie, zeby bylo nizej niz do tej pory? Domyslnie jest troche nizej niz bylo, ale kazdy panel ma swoje wspolrzedne gornego lewego rogu. Wpisujesz mu tam gdzie ma isc, i idzie :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Marca 2017, 19:01:52
OK, w dzisiejszym uaktualnieniu mamy skonczone w 95% przenosiny paneli UI. Ostatnie 5% to dodatkowa tabelka w trybie debug dla traxxa itp. Czy ktos tych danych potrzebuje/uzywa?
Aha, i mamy drobna zmiane w nazwie pliku exe, bo po skompilowaniu wersji 64 bit jakos trzeba je bylo odroznic :P

(wersja 64bit wymaga troche innych bibliotek, wrzuce paczke do watku zbiorczego za moment)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 15 Marca 2017, 19:06:30
Tylko yB je rozumie. Ja używam paru wersów. Przydałoby się tam komentarze dodać który blok cyferek jest czym w tym matriksie.
Planowałem też kiedyś zrobić podobnie rozbudowaną diagnostykę do pozostałych typów fizyki. By w diesel-electric pokazywało obroty, moce, napiecia i prądy prądnicy, silników. W diesel obroty i momenty przed i za skrzynią. W szeregowym napięcia na oporach itp.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Marca 2017, 19:09:38
Kolumny danych maja teraz naglowki (ale wziete z nazw zmiennych, wiec pewnie dalej malo pomocne)  Co do rozszerzonej diagnostyki to dobry pomysl, ale chyba wstrzymam sie z tym do czasu gdy mamy UI z prawdziwego zdarzenia, z normalnymi elementami zamiast biezacej prowizorki, i da sie to troche bardzie zautomatyzowac.

edit: aha @Milek7 dodaj post do przyklejonego watku, zeby ludzie nie musieli szukac twoich wersji ;>
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 15 Marca 2017, 19:14:43
póki co to nic w nich interesującego nie ma co by nie było u ciebie ;p
będą shadery w następnym tygodniu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Marca 2017, 19:17:30
Screenshoty sa :D  no i lepiej jak post jest zarezerwowany na samej gorze, a nie potem dodawac gdzies w srodku.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 15 Marca 2017, 20:35:26
170315. Oczywiście nie byłem w stanie objechać wszystkiego, ale bardzo ładna zmiana UI. Brak wysypów, szybko wczytuje, wydajne. Posiada znane błędy do poprawienia, być może jeszcze jakieś zmiany koncepcji i poprawienia/dopisania tu i ówdzie. Pomału testowanie staje się nudne. Jeszcze dygresja, wymieniłem jedną z kości ram i przestałem mieć wysypy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 15 Marca 2017, 22:39:51
U mnie po wrzuceniu wszystkiego i zainstalowania bibliotek co Krzysiu wstawiał tam w drugim temacie coś takiego. Działo mi się tak już na wcześniejszym exe (które wydawał Milek). Teraz po podmianie żadne exe nie odpala.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Marca 2017, 22:42:43
Ten blad wyskoczy gdy uruchamiasz 32-bitowe exe z 64-bitowymi bibliotekami, albo odwrotnie. Dla 64 bit pobierz i wypakuj http://eu07.pl/userfiles/24014/bugs-eu07cplusplus64_libraries.rar (nadpisz istniejace pliki)  Dla wersji 32-bitowej biblioteki sa w http://eu07.pl/userfiles/24014/bugs-eu07cplusplus_libraries.rar
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 15 Marca 2017, 22:43:53
Tak pobrałem paczkę 64 bitową i po odpaleniu exe 64 wyświetla się znów to ustrojstwo, ale no system mam 64 także nie wiem w czym problem.

Edit.: Natomiast po pobraniu tej paczki bibliotek dla wersji 32-bitowej i odpalenia exe dla wersji 32 bitowej wszytko jest okej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Marca 2017, 22:52:37
Aha, jeszcze jedna mozliwosc -- w katalogu maszyny zazwyczaj jest 32-bitowa wersja python27.dll  Zobacz, czy po wypakowaniu bilbliotek z paczki 64-bit i python27.dll z zalacznika 64-bitowa wersja ruszy?

(tylko zrob sobie najpierw kopie tej 32-bitowej python27.dll, bo bedzie potrzebna 32-bitowemu exe :x
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 15 Marca 2017, 22:58:16
Nadal to samo.

A na pewno wrzuciłem pythona64 do tej paczki? Bo odpalam na 32 bitowej (oczywiście wrzuciłem biblioteki z 32) i działa bez problemu na tym pythonie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 15 Marca 2017, 23:03:33
Nie wiem, nie pamiętam, doinstaluj MS c++ 2015, pewien nie jestem, a nie mam możliwości dostępu do systemu teraz.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Marca 2017, 23:05:00
Hmm to nie wiem. U mnie wyglada to tak, ze mam zainstalowany pakiet 64-bitowego pythona (z https://www.python.org/ftp/python/2.7.13/python-2.7.13.amd64.msi )w Programi Files, 32-bitowego pythona (z https://www.python.org/ftp/python/2.7.13/python-2.7.13.msi ) w Program Files x86, a w katalogu maszyny tylko glew32.dll I glfw3.dll we wlasciwej odmianie (I zadnej python27.dll) i to sie uruchamia.

edit:
VS 2015 chyba nie powinien byc potrzebny, bo to exe razem z przyleglosciami to ciagle VS 2013, ale sprobowac zapewne nie zaszkodzi.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 15 Marca 2017, 23:08:26
To tej paczki z tego linku co podałeś to nie miałem nawet wcześniej zainstalowanej. Może to pomoże, za chwilkę zobaczymy.

EDIT: Pomogło. 64 działa jak należy
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 16 Marca 2017, 04:54:06
OK, znalazl sie problem z hamulcami w SN61 :)  Obawiam sie ze gorzej bedzie z powstrzymaniem kierowcow-samobojcow, glownie dlatego ze dostepne scenerie z samochodami sa dosc rozlegle co nie pomaga w dogrzebaniu sie do sedan problemu. Poszloby duzo latwiej, gdyby ktos mogl zrobic prosta modyfikacje dla TD -- dodac kawalek prostej drogi z jednym przejazdem, przejazd moze byc caly czas zamkniety, i na tej drodze jeden samochod, najlepiej Golf albo Ka. Droga tez nie musi byc dluga, ze 100-200 m w kazda strone wystarczy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 16 Marca 2017, 10:44:23
Wydajność nowej wersji bez zmian. Bardziej irytujące jest to automatyczne włączenie wygładzania mimo wyłączenia w ini.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 16 Marca 2017, 12:35:02
Bez zmian tzn jak, dalej jest wolniej niz bylo? :/ Wygladzenie nie bedzie sie niepotrzebnie wlaczac w nastepnym uaktualnieniu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 16 Marca 2017, 13:44:44
Tak, dalej jest wolniej. Ale trudno mi to dokładnie ocenić, czy szybciej niż od poprzedniego uaktualnienia bo to jest 18 - 22 vs 25 - 30, ale dość mocno się waha i tu leży trudność.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 16 Marca 2017, 15:35:55
Ok, zobacz czy cos sie poprawi w dzisiejszym uaktualnieniu -- faktycznie bylo tam spowolnienie miedzy wersja 0309 i 0310, w zwiazku ze zmianami w kodzie rysujacym. Przepuszcze to przez profiler i sprobuje wylapac, co konkretnie mieszalo, ale na razie czesciowo przywrocilem stare wersje niektorych funkcji, i wyglada na to ze jest porownywalnie z 0309, jesli nie troche szybciej w niektorych sytuacjach.

Oprocz tego:
- naprawiony blad przy hamulcach Oerlikona. Najbardziej widocznym efektem jest prawidlowo hamujacy SN61, ale zmiana obejmuje cala klase pojazdow (glownie wagonow towarowych) wiec moglo to miec tez jakies efekty i dla nich
- dzialaja reflektory w SN61 i podobnych. Przy czym dzialaja troche smiesznie bo nieistniejace 'gorne' swiatlo tez rozjasnia jesli sie je wlaczy, ale to nie ja instalowalem ten wlacznik :P
- multisampling nie bedzie aktywowany, jesli w .ini zostal ustawiony na wartosc 0 (czyli 1 w Rainsted)

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 16 Marca 2017, 15:56:09
A co z dźwiękami falowników w pojazdach z silnikami asynchronicznymi? Wiadomo dlaczego nie działają?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 16 Marca 2017, 16:22:55
Jeszcze nie patrzylem. Aha, zapomnialbym, w tym ostatnim uaktualnieniu jest jeszcze:
- klawisz Esc pauzuje symulacje rowniez w trybie debug
- w trybie debug klawisz F1 pokazuje informacje dla najblizszego pojazdu, zamiast byc na sztywno przywiazanym do tego, ktory kontrolujemy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 16 Marca 2017, 16:26:29
Wspomnę, że pojeździłem na exe 64 bit. Właściwie nie widzę różnic. Co do MS c++2015, to mam je zainstalowane, miałem jakiś problem i dodatkowo instalowałem. Być może chodziło o wcześniejsze wersje exe. Jest sens abym porównał u siebie działanie exe na karcie intela? Posiadam takie możliwości po wyłączeniu GF i uruchomieniu zintegrowanego intela.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 16 Marca 2017, 17:05:28
Roznic w zasadzie nie bedzie, lub przynajmniej nie powinno byc (x64 moze byc bardziej sensownym wyborem przy duzych sceneriach, np. Kaliska to jest na dzien dobry ~1.1-1.2 gb pamieci, ale z drugiej strony x64 jest troche bardziej pamieciozerne, i ta sama Kaliska na x64 to ~1.3+ gb) wiec jezdzij sobie z ta, na ktorej ci wygodniej.

Co do funkcjonowania kart Intela to nie wiem, czy warto sie tutaj za bardzo przejmowac, w sensie jesli cokolwiek na nich dziala to jest to bardziej efekt uboczny niz zamierzony :)

Z innej beczki, w miedzyczasie naprawily sie falowniki, beda w nastepnym uaktualnieniu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 16 Marca 2017, 17:11:04
I co było przyczyną braku dźwięku falowników?

Ps. Czy jesteście w stanie dodać opcjonalny dźwięk przy blokadzie drzwi w EZT? Myślę, że chyba nie byłoby to dużo kodu, a tak można by dopisać dźwięk (mam nagrany) blokady drzwi w en57, który w co po niektórych słychać w całym składzie dość głośno.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 16 Marca 2017, 17:21:36
Może jednak drobne ficzery zostawić na później?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 16 Marca 2017, 17:22:12
Racja, takie bajery to później ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 16 Marca 2017, 17:27:21
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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 16 Marca 2017, 17:56:53
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)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 16 Marca 2017, 18:25:36
Ż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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 16 Marca 2017, 18:35:26
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ć.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 16 Marca 2017, 18:36:12
Na naszej fiz nie da im się wyłączyć automatycznej. :P
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 16 Marca 2017, 18:38:20
Widzisz, a one automatycznej właśnie nie mają. Zdejmują moc z silników jedynie przy poślizgu, ale piachu nie sypią.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 16 Marca 2017, 19:31:33
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żę.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 16 Marca 2017, 20:32:17
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)?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 16 Marca 2017, 21:39:52
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?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 16 Marca 2017, 21:44:27
Napisz który scenariusz, sprawdzę za trochę jak odpalę inny dysk.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 16 Marca 2017, 21:47:54
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?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: joey w 16 Marca 2017, 21:51:58
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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 16 Marca 2017, 22:01:32
Na windzie tego nie mam, wielokrotne opuszczenie i powracanie, a także przejmowanie pojazdów pod F5.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 16 Marca 2017, 22:07:57
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
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 16 Marca 2017, 22:28:51
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 :(
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 16 Marca 2017, 22:42:17
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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 16 Marca 2017, 22:48:16
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 ;/
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 16 Marca 2017, 22:50:41
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
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 16 Marca 2017, 22:57:30
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?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 16 Marca 2017, 22:58:22
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
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 16 Marca 2017, 23:02:30
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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 16 Marca 2017, 23:08:19
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?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: dymus w 16 Marca 2017, 23:12:38
e3d kabin do ST44 były konwertowane na exe 474.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 16 Marca 2017, 23:16:30
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
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 16 Marca 2017, 23:16:52
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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 16 Marca 2017, 23:23:31
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
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: joey w 16 Marca 2017, 23:26:25
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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 16 Marca 2017, 23:30:48
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
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 16 Marca 2017, 23:37:01
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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 16 Marca 2017, 23:42:20
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 :/
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 16 Marca 2017, 23:48:05
Zobaczcie w mój log, może coś wam się rzuci w oczy na temat tego uruchamiania długiego.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 16 Marca 2017, 23:50:03
U mnie nawet czytanie t3d nie daje rezultatu na tej kaliskiej :P Tracę cierpliwość.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 17 Marca 2017, 00:08:38
Zobaczcie w mój log, może coś wam się rzuci w oczy na temat tego uruchamiania długiego.
Niestety nic bezposrednio, ale z tego co widze
Unknown property: "vradius" in track "hrs_u"
Unknown property: "10000" in track "hrs_u"
Unknown property: "vradius" in track "hrs_t"
Unknown property: "10000" in track "hrs_t"
to chyba nie jest wersja z paczki, tylko po modyfikacjach Ra? Jak wyglada ladowanie na wersjach exe wczesniejszych niz 0316, tez tak samo dlugo?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 17 Marca 2017, 00:09:32
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
To nie tak, te pliki z nowej kabiny zadziałały na nowym exe, dałem w tamtym wątku screeny nawet. Tylko jak chciałem wrócić do Kaliskiej, to zaczęło wywalać błąd, który ustąpił po powrocie do starszej paczki z gagarinem. Co się gryzie, nie wiem, bo ledwo już patrzę.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 17 Marca 2017, 00:35:45
Żeby było śmieszniej - gdy kliknę na krzyżyk w momencie wyświetlania się tego okienka z informacją o MSVR, symek wysypuje się w związku z kliknięciem krzyżyka i wtedy crashdump jest :P Ale po potwierdzeniu okienka nie :D

EDIT: Po różnych walkach mam wrażenie, że symulator sobie nie radzi z tak dużą scenerią. Jak pousuwam pare rzeczy (niekoniecznie tabor, nawet elementy otoczenia, sieć etc), to się wczytuje. Z tym, że nawet na t3d pozostaje problem jeżdżących wnętrz, bez pudeł.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 17 Marca 2017, 13:20:28
EDIT: Po różnych walkach mam wrażenie, że symulator sobie nie radzi z tak dużą scenerią.

No widzisz, ale gdyby tak rzeczywiscie bylo, to te same efekty bylyby tez obserwowane przez innych. A tymczasem na roznych innych komputerach, w tym moim, sceneria obslugiwana jest normalnie. Z tym ze rzeczywiscie Kaliska /jest/ duza -- to jest ~1.2-1.3 gb zajetej pamieci na sam simulator wiec mozliwe ze na slabszych konfiguracjach i/lub przy zaladowanych innych programach moga zaczac pojawiac sie klopoty. Podobne ograniczenie dotyczy karty graficznej -- przepisany symulator zuzywa wiecej pamieci na kazda teksture, wiec moze jej zaczac brakowac szybciej niz na starym exe (zobacze czy da sie tutaj wprowadzic jakies ulepszenia, ale na razie jest jak jest)

Niestety, te crashdumpy generowane przy wymuszonym zamknieciu okna raczej nie pomoga, bo wyskakuja wtedy z innej przyczyny -- aplikacja jest zmuszona by sie zamknac i robi to troche "nie po kolei", probujac np zwalniac zasoby ktorych juz nie ma. Czyli to akurat nie pomoze w dojsciu, co tam u ciebie idzie nie tak :/

edit:
OK, w dzisiejszym uaktualnieniu mamy:
- poprawiony blad ciaglego syczenia w sytuacji, gdy symulator byl uruchamiany z zalaczona pauza.
- przywrocone roznicowanie oswietlenia w tunelach, wykopach itp. Tutaj uwaga, efektem ubocznym jest ponowne dzialanie swiatel 'zawsze', by prowizorycznie umozliwic oswietlanie tuneli itp bez skomplikowanej zabawy w skanowanie torow naprzod by sprawdzic, czy jest tam tunel itp.
- nie pamietam czy naprawa falownikow zmiescila sie w poprzednim uaktualnieniu, czy jest w tym, ale tak czy owak tez powinny dzialac

W sumie oznacza to, ze stan uzywalnosci jest teraz z grubsza taki jak starego exe. Oprocz kierowcow-samobojcow, ale zeby wyciac tamten krzak potrzebny jest tor testowy. Wiec ten blad bedzie usuniety kiedy tor sie pojawi (albo kiedy zaimplementujemy w symulatorze edycje z poziomu exe, bo raczej nie widze mozliwosci ze sobie sam taki tor inaczej wyprodukuje :d
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 17 Marca 2017, 18:10:19
Staroć od Ra, ale powinien zadziałać. Dymus się zadeklarował zrobić coś ładniejszego.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: dymus w 17 Marca 2017, 18:22:45
Staroć od Ra, ale powinien zadziałać. Dymus się zadeklarował zrobić coś ładniejszego.
Nom jakbyś jeszcze przypomniał jak to miało być konkretnie to spoko, bo nie pamiętam szczegółów z wczorajszej rozmowy na czacie.
Cytuj
- nie pamietam czy naprawa falownikow zmiescila sie w poprzednim uaktualnieniu, czy jest w tym, ale tak czy owak tez powinny dzialac
Działają :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 17 Marca 2017, 18:32:27
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 :(
Zeby bylo jeszcze smieszniej, w czasie dzisiejszego testowania dotarlo do mnie, ze ta roznica, ktora widzialem u siebie miedzy wersja 0309 a pozniejszymi wcale nie byla spowodowana zmianami w kodzie -- po prostu testowalem poprzez uruchomienie obu wersji naraz z oknami jedno obok drugiego, bo to ulatwia porownywanie fps... a system operacyjny/karta graficzna poswiecaly wiecej uwagi programowi, ktorego okno bylo aktywne.

Wiec sprawdzilem sobie exe ze starym kodem rysujacym, i to w ktorym kod jest zmieniony, w sytuacji gdy oba okna nie sa aktywne... i wyszlo ze zadnego spadku wydajnosci nie ma, a ja spedzilem pol dnia przywracajac cos, co w zasadzie nie jest juz potrzebne D:

Nom jakbyś jeszcze przypomniał jak to miało być konkretnie to spoko, bo nie pamiętam szczegółów z wczorajszej rozmowy na czacie.
Wystarczy ze bedzie przejazd i droga w poprzek torow, tak ze 100-200 m w kazda strone zeby mogl sie samochod troche rozpedzic przy nawrocie. Przejazd moze byc caly czas zamkniety, ale wazne, zeby byl "widoczny" dla AI bo ten co go Stele znalazl to chyba za stary jest -- nawet na Borlandowym exe jak zamkne przejazdy shift+1 to AI kompletnie to olewa i przejezdza przez nie, a w tabelce skanowania nic nie ma. Przejazdy na Calkowie np. sa widoczne, ale tam jest z kolei za duza sceneria ;/
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 17 Marca 2017, 19:12:24
Chciałem przetestować światło w tunelu. Odpaliłęm Drawinowo na przyspieszeniu by tylko zobaczyć czy przyciemnienie w tunelu jest naprawione i zapętliło mi --grz1-skd1. Jest w dwóch miejscach jako eventall1/2. Zawiesiło okno ogl symka i zalogowało 200tyś wykonań w kilka sekund zanim wyłączyłem.
event --GrZ1-SkD1 addvalues 0 GrZ1-SkD1 * * -1 endevent
event --GrZ1-SkD1 updatevalues 0 GrZ1-SkD1 free * * condition memcompare * * 0 endevent
EVENT LAUNCHED: --grz1-skd1
free     1.00    22.00 != * *     0.00
Zmienialiście coś w tym aspekcie? powinien się wykonać tylko kilkanaście razy dla każdego pojazdu przejeżdżającego a nie zapętlać.

------------
Tunel działa świetnie. Wejście smugi w ciemność jak i wyjście. Przejście oświetlenia kabiny też.
Gorzej z falownikiem. Wyłączyłem przetwornicę by cokolwiek słyszeć i istotnie jest modulacja, ale wcięło mnożnik głośności/amplitudy. Jeszcze porównam w warunkach testowych i na różnym taborze.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 17 Marca 2017, 19:16:42
Hmm nie, chyba tam nic nie ruszalem. Drawinowo sprawdzalem dzisiaj kilka razy, bo tez mi przyszlo do glowy ze to dobre miejsce do testowania tuneli, i wszystko jezdzilo (chyba) normalnie, ale nie probowalem tego z przyspieszeniem czasu. W ktorym trybie sie tak narobilo?

edit: puscilem jeszcze raz dla pewnosci, we wszystkich trybach przyspieszenia, i w ogole tego eventu nie uruchomil. Przynajmniej na drawinowo_ep07.scn
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 17 Marca 2017, 19:30:36
Shift+F6. Teraz jest tam x5 zdaje się. X2 mi brakuje nieco, bo to jedyny użyteczny był. Przy x5 zbytnio mi fps spada i testy przestają być miarodajne. Na x1 miałem na Drawinowie 70 fps, na x5 już tylko 12.
Sceneria w wersji Ra 11.03 (uwaga, zbugowana). Odpaliłem ponownie by sprawdzić to co miałem sprawdzić i nie wywaliło tego ponownie. Ale też nigdy wcześniej się nie spotkałem z takim zapętleniem zdarzeń.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 17 Marca 2017, 19:33:46
Tak na marginesie przy przyspieszeniu spadek moze byc teraz wiekszy, bo w ramach zmian przeliczany jest caly czas, jaki uplynal miedzy wywolaniami update(), a nie tylko pierwsze 20 krokow. Wiec z jednej strony jest wolniej, ale z drugiej troche bardziej miarodajnie, bo nie robia sie dziury czasoprzestrzenne.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 17 Marca 2017, 19:40:23
Drawinowo_ep07 to kompletny relikt. Tylko drawinowo i drawinowo_noc są utrzymywane. Event ten to licznik blokady liniowej dla odcinka Grodzisk-Stawiska dodany przez Ra z tydzień temu. Trzeba mieć wersję z warsztatu by był, ale nie polecam póki co, bo są błędy w skryptach.
Przysłuchałem się falownikom i sam już nie wiem. Mam wrażenie, że wszystko jest cichsze na dzisiejszym niż ostatnim borlandowym. Niech ktoś z lepszym słuchem oceni, czy jest różnica.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 17 Marca 2017, 19:47:01
Co do falownikow to porownujac Traxxa na exe Borlandowym i c++ wydaje mi sie, ze brzmia podobnie pod wzgledem glosnosci i tonow, ale ja mam tylko pierwszy stopien sluchu muzycznego, czyli rozrozniam kiedy graja a kiedy nie :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 17 Marca 2017, 19:50:10
I wysyp na generowaniu crashdumpa, identyczny jak u Atapiego. Wczytywanie kaliskiej, ładowanie e3d jakiejś węglarki. Niby mam 2,15GB ramu dostępne po śmierci symka.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 17 Marca 2017, 19:56:32
Paczkowe exe trzymam już tylko dla porównań. Pierwsze jest takie, że niektóre dźwięki rzeczywiście są cichsze. Ale wiele to nie jest. Ktoś kiedyś napisał, że testowanie na przyspieszeniu, aby szybciej dojść tam gdzie chcemy;) niczego dobrego nie wróży. Szczególnie na słabych maszynach. Może teraz już nie. Sprawdziłem to oświetlenie w Drawinowie wielokrotnie ostatnio w nim jeżdżąc i jest ok. Światła w SN61 świecą, hamulec pomocniczy naprawiony. Wisienką na torcie byłoby usunięcie efektu dopplera w trybie freefly, kiedy latając po terenie zniekształca nam komunikaty a po powrocie do kabiny często przynosimy obcy dźwięk z odległego miejsca mapy.
PS: Pytałem czy jest teoretyczna możliwość zmieniania kolorów napisów wpisem w ini, po małej modyfikacji exe?
I wysyp na generowaniu crashdumpa, identyczny jak u Atapiego. Wczytywanie kaliskiej, ładowanie e3d jakiejś węglarki. Niby mam 2,15GB ramu dostępne po śmierci symka.
I tego nie rozumiem, akurat na tej scenerii nigdy nie miałem wysypu przy ładowaniu, może ze dwa razy w trakcie jazdy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 17 Marca 2017, 20:03:53
PS: Pytałem czy jest teoretyczna możliwość zmieniania kolorów napisów wpisem w ini, po małej modyfikacji exe?
Sorry, musialem przegapic. Teoretyczna mozliwosc jest :)  Znieksztalcenie przy przyspieszonym freefly tez mnie troche denerwuje, wiec zobacze.

I wysyp na generowaniu crashdumpa, identyczny jak u Atapiego. Wczytywanie kaliskiej, ładowanie e3d jakiejś węglarki. Niby mam 2,15GB ramu dostępne po śmierci symka.
Co do wysypu na Kaliskiej niestety nie mam tego, laduje sie za kazdym razem, a jedyne bledy jakie zglasza to brakujace tekstury itp. Te weglarki itp to sa takie jak w paczce calosciowej, czy moze cos bylo modyfikowane od tego czasu? Chociaz Atapi pisal ze to moze nie jest z nimi zwiazane, wiec nie wiem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 17 Marca 2017, 20:08:09
Ponownie wysyp na węglarce. 1740MB na symka, ~400MB wolne w zapasie.
Pojazd raczej tykany nie był. Zresztą odpalam na paczce użytkowej 16.08+kilka unoffów.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 17 Marca 2017, 20:09:55
Ktora to weglarka? Towarowe chyba w wiekszosci Oerlikona maja, moze po naprawianiu cos tam sie odetkalo albo inny konflikt wyszedl.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 17 Marca 2017, 20:11:22
Chcecie log z poprawnie załadowanej Kaliskiej? Mam sprzed chwili.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 17 Marca 2017, 20:13:04
------------------------------------------------------
init default physic values for a58695, [408wa], []
LOAD FIZ FROM dynamic\pkp\408w_v1\408wa.fiz
CERROR: 0, SUCCES: true
check locomotive parameters...
XBT NESt3, ESt3, ESt3AL2, ESt4
Ready to depart
Loading binary format 3d model data from "dynamic\pkp\408w_v1\408wa.e3d"...

Raczej przypadek. Wstawiłem jakieś węglarki z nim w składzie skopiowane z kaliskiej na td i wczytało.

Wywaliłem trochę taboru i wysypało na innym pojeździe 1780MB pamięci użyte.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 17 Marca 2017, 20:15:45
No z poprawnie zaladowanej to mi exe robi tutaj na miejscu ;)  Ale tam tyle pociagow jest ze raczej nie usmiecha mi sie sprawdzac po kolei czy ktorys nie ma czegos dziwnego.

@Steele, mozesz jeszcze sprawdzic, czy zrobi jakas roznice gdy dasz w .ini np maxtexturesize 2048 albo 1024?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 17 Marca 2017, 20:28:19
Przy zeskalowaniu do 1024 wczytało do końca. Użycie pamięci 1390MB. Czyli wnioskujesz, że kwestia vramu?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 17 Marca 2017, 20:30:02
Jakie masz moduły pamięci RAM, po 2GB? U mnie jest 2 x po 2gb. Miałem jakieś problemy z przepisywanie i kopiowaniem długich plików. Wysypy na wczytywaniu też były, a także podczas symulacji. W niedzielę usunąłem podejrzaną kość a w poniedziałek wstawiłem nową. Wysypy i inne problemu ustąpiły.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 17 Marca 2017, 20:32:02
Jesli na 1024 weszlo, to mozliwe ze to kombinacja zbyt malej ilosci pamieci w karcie graficznej i/lub zwyklej -- karta nie miesci tekstur i zaczyna wrzucac dane do virtualnej, pamiec sie konczy i idzie w maliny.

Zastanawialem sie nad wprowadzeniem modyfikacji do modulu renderujacego, zeby wrzucal tekstury do karty tylko gdy sa potrzebne w scenie, a usuwal jesli przez dluzszy czas nie sa wywolywane; byc moze trzeba bedzie przyspieszyc ten eksperyment.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Lorem w 17 Marca 2017, 20:38:49
Z kosmetycznych błędów:
- gdy wracamy z trybu freefly do kabiny przy włączonej pauzie, to lądujemy pod lokomotywą; po wyłączeniu pauzy przeskakujemy do domyślnej pozycj w kabinie,
- z napisów pod F1..F12 tylko F1 i F10 da się wyłączyć powtórnym wciśnięciem odpowiedniego klawisza.

Potwierdzam też problem z uruchomieniem wersji 64-bitowej zgłoszony przez Wiggle i potwierdzam również, że zainstalowanie w systemie podlinkowanego przez tmj pakietu pythona rozwiązuje ten problem.

Ode mnie do rozważenia, to czy by nie przywrócić starego położenia kamery po wyjściu przez F4. Tego naprzeciw czoła prowadzonego pojazdu, przydawał się do szybkiego przelotu nad składem czy ogólnie wzdłuż szlaku. Np. pod Ctrl+F4.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 17 Marca 2017, 20:47:19
Z kosmetycznych błędów:
- gdy wracamy z trybu freefly do kabiny przy włączonej pauzie, to lądujemy pod lokomotywą; po wyłączeniu pauzy przeskakujemy do domyślnej pozycj w kabinie,
- z napisów pod F1..F12 tylko F1 i F10 da się wyłączyć powtórnym wciśnięciem odpowiedniego klawisza.
Klawisz F6 wyłącza napisy. Było, już nie jest
Cytuj
Potwierdzam też problem z uruchomieniem wersji 64-bitowej zgłoszony przez Wiggle i potwierdzam również, że zainstalowanie w systemie podlinkowanego przez tmj pakietu pythona rozwiązuje ten problem.
Takie są wymagania dla sytemu 64 bitowego, też się na tym złapałem.
Cytuj
Ode mnie do rozważenia, to czy by nie przywrócić starego położenia kamery po wyjściu przez F4. Tego naprzeciw czoła prowadzonego pojazdu, przydawał się do szybkiego przelotu nad składem czy ogólnie wzdłuż szlaku. Np. pod Ctrl+F4.
Za to całkiem do kitu kiedy trzeba lecieć do sprzęgu, tę czynność akurat częściej robię. Można rozważyć modyfikację tego usprawnienia.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 17 Marca 2017, 21:04:25
U mnie nadal jest coś nie tak z tym ładowaniem, teraz TD się ładuje 30 sekund (DŁUUGO). Ale najdłużej z tego wszystkiego ładuje się python.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 17 Marca 2017, 21:15:36
Finished loading 3d model data from "dynamic\pkp\303e_v1\303e_1]kabina_a.e3d"
Player train init OK
Load time: 15 seconds
EVENT LAUNCHED: tdo_rez_shp by ep07-426-ep
Type: PutValues
Odpaliłem TD przy załadowanej Kaliskiej, wynik jak u góry. Obie scenerie w pełnym oknie. Jak dojadę, spróbuje pojedynczo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 17 Marca 2017, 21:17:56
Kurde nie wiem o co chodzi z tym moim komputerem, było dobrze i nagle trach...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 17 Marca 2017, 21:44:17
Tylko ze u mnie z wymuszonym 1024 sie sypie, a na MSI GTX 970 4G Gaming raczej nie podejrzewalbym braku pamieci, zwlaszcza z wymuszeniem i 16 GB ramu...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 17 Marca 2017, 21:49:15
Kurde nie wiem o co chodzi z tym moim komputerem, było dobrze i nagle trach...
Czy to powolne ladowanie jest tylko przy wersji 64-bit, czy obu? Moze cos sie tam namieszalo z pythonem przy probach instalacji roznych wersji. Sprobuj moze tak:

- odinstalowac (wszystkie) wersje pythona ktore masz w systemie
- zainstalowac po kolei 32-bit i/lub 64-bit, tak jak opisane w http://eu07.pl/forum/index.php/topic,28159.msg445645.html#msg445645
- upewnij sie, ze w katalogu symulatora jest folder python i/lub python64, plus odpowiednia wersja pozostalych bibliotek, z http://eu07.pl/forum/index.php/topic,28920.0.html
- uruchomic wybrana wersje exe

Tylko ze u mnie z wymuszonym 1024 sie sypie, a na MSI GTX 970 4G Gaming raczej nie podejrzewalbym braku pamieci, zwlaszcza z wymuszeniem i 16 GB ramu...
No raczej nie powinno, u mnie zadowala sie 3gb + 8gb ram. Moze to jak u Krzyska cos z ktoras koscia pamieci jest nie teges? :/
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 17 Marca 2017, 22:13:23
Chyba mam podobny problem, tzn. wczytywanie scenerii na chwilę zatrzymuje się na wpisie "Loading scenery from $.scn". Wydaje się, że ma to jakiś związek z pojawieniem się paska ładowania. Sprawdziłem dla porównania wersję exe 170312b - czas ładowania przykładowej scenerii 74 sekundy, na exe 170314b 116 s. Czy ten czas różnicy to nie jest przypadkiem moment, gdy exe mieli wszystkie pliki, aby określić jaka jest ogólna wielkość scenerii, żeby potem móc odpowiednio rysować pasek postępu?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 17 Marca 2017, 22:14:47
Sprawdziałem na exe 12b i td ładuje się 5 sekund, a na tym nowym exe niezależnie czy 32 czy 64 jest to około 30-50 sekund
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 17 Marca 2017, 22:41:14
To jeszcze dorzucę, że całkowicie zablokowałem dodawanie pliku $.scn. Według mnie przeżytek. Też porównałem wczytanie td na starszym exe i była 1 sek. Ale po wyłączeniu Kaliskiej wynik jest taki:Loading texture data from "dynamic\pkp\303e_v1\4e_1]podloga.dds"
Finished loading 3d model data from "dynamic\pkp\303e_v1\303e_1]kabina_a.e3d"
Player train init OK
Load time: 1 seconds
EVENT LAUNCHED: tdo_rez_shp by ep07-426-ep
Type: PutValues
Kaliska wczytuje się:Finished loading 3d model data from "dynamic\pkp\et42_v2\42]kabina_a.e3d"
Player train init OK
Load time: 247 seconds
Eventlauncher cegielski_wjazd_dozwk
EVENT ADDED TO QUEUE: cegielski_wjazd_zwk
Dzisiejsze exe.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 17 Marca 2017, 22:53:23
Ja wyłączyłem zapis pliku tymczasowego i l61 na exe 12b uruchamia się 211 sekund, a na exe dzisiejszym 560... A na początkowych wersjach exe++ było to około 60

Uruchomiłem dzisiaj symulator chyba z 15 razy i było wszytko okej po za tym długim ładowaniem, a teraz chciałem już się przejechać, patrzę a po podniesieniu pantografów w żadnym pojeździe nie mam 3000 volt na voltomierzach i nie mogę WSa załączyć, bo cały czas słychać dźwięk dotknięcia pantografu.

Teraz nawet na żadnym exe już nie działa załączenie WSa przez to co napisałem wyżej, nawet na oryginalnym.

W pojazdach gdzie nie miałem e3d WS załącza się lecz w tych w których usunąłem później niestety nie działa w dalszym ciągu. A tutaj coś co się dzieje w połowie pojazdów aktualnie:
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 17 Marca 2017, 23:42:04
Dziennik zdarzeń Windows prezentuje:
Cytat: Ostrzeżenie
The NVIDIA OpenGL driver has encountered
an out of memory error. This application might
behave inconsistently and fail.
(stop logging every single event of this type
because there are too many)

oraz potem:

Cytat: Błąd
Nazwa aplikacji powodującej błąd: eu07-x86_170316.exe, wersja: 17.0.1175.483, sygnatura czasowa: 0x58caa166
Nazwa modułu powodującego błąd: OPENGL32.dll, wersja: 6.1.7600.16385, sygnatura czasowa: 0x4a5bdadb
Kod wyjątku: 0xc0000005
Przesunięcie błędu: 0x0000416c
Identyfikator procesu powodującego błąd: 0x1910
Godzina uruchomienia aplikacji powodującej błąd: 0x01d29f6dc91ca10e
Ścieżka aplikacji powodującej błąd: D:\PCTGA\eu07-x86_170316.exe
Ścieżka modułu powodującego błąd: C:\Windows\system32\OPENGL32.dll
Identyfikator raportu: c07c414e-0b62-11e7-97d1-002522cc24b2

Jestem mocno zdziwiony - VRAM dochodzi do 2GB i lipa... Czyżby jakiś limit użytego VRAM przy procesach x86? Zaraz sprawdzę biblioteki pod x64.

EDIT: Wersja x64 chodzi. Co prawda nie cały tabor się wczytał poprawnie z t3d, ale np. pojawiły się pudła lokomotyw, które wcześniej się nie wczytywały na x86. Dziwne :P W każdym razie przy pełnym taborze, scenariusz Kaliskiej z buttem ET22 z Ostrowa, na starcie w kabinie około 100 klatek/s.

EDIT2: Jednak z tym doczytywaniem pudeł coś jest nie tak. Losowo raz jedne, raz inne pudła znikają.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 18 Marca 2017, 01:24:07
Czy ten czas różnicy to nie jest przypadkiem moment, gdy exe mieli wszystkie pliki, aby określić jaka jest ogólna wielkość scenerii, żeby potem móc odpowiednio rysować pasek postępu?
Juz chcialem powiedziec ze "nie, bo exe tego nie robi" ale cos mnie tknelo i sprawdzilem, i tam faktycznie w kodzie zostalo poczatkowe przejscie przez pliki scenerii (zeby bylo smieszniej, do niczego potem nie wykorzystywane), ktore bylem pewien zostalo usuniete po tym, jak sie nie sprawdzilo :x
Samo w sobie nie wyjasnia to jednak dodatkowych 25 sekund na TD, gdy cale zaladowanie TD i wszystkich jej plikow zajmuje sekund 5. Ale po faktycznym wycieciu zbednej procedury ladowanie powinno troche przyspieszyc. Oprocz tego zmniejszylem troche czestotliwosc uaktualniania okna w czasie ladowania -- postep bedzie bardziej skokowy, ale takze powinno byc nieco szybciej. Porownujac u siebie ladowanie Kaliskiej przez wersje 0312 i nowe uaktualnienie, roznica to 108 sekund do 110.

(oprocz tego po namysle wylaczylem ponownie dzialanie swiatel w dzien, bo na dluzsza mete bylo to jednak dosc irytujace. Po tej zmianie przy wjezdzie do tunelu swiatla pojawiaja sie po krotkiej chwili, ale do tuneli wjezdza sie na tyle rzadko, ze jest to chyba do zaakceptowania)

Przyjrzalem sie tez mozliwosci wprowadzenia wgrywania tekstur nie od razu, ale wtedy gdy sa potrzebne, wychodzi jednak na to ze trzeba bedzie najpierw zmienic nieco kod tworzacy display lists, inaczej sie gryzie. Planowalem to zrobic i tak w ramach ujednolicenia kodu renderujacego, ale teraz jest dodatkowy powod :)  w miedzyczasie, w trybie debug pod F9 mozna teraz zobaczyc laczna ilosc tekstur w scenie, i ich orientacyjna objetosc w pamieci. Nie jest to wartosc dokladna (nie uwzglednia mip-maps ktore dokladaja ~25% do wersji bazowej) ale na poczatek wystarczy.

Jestem mocno zdziwiony - VRAM dochodzi do 2GB i lipa... Czyżby jakiś limit użytego VRAM przy procesach x86? Zaraz sprawdzę biblioteki pod x64.
Limitu chyba nie ma, bo gdyby byl to przeciez powinien wyskoczyc takze i u mnie i u Krzyska. A tymczasem wersja x86 chodzi nam obu normalnie. Ale wyglada na to, ze chyba cos jest nie tak, jesli tabor pojawia sie i znika... no i jesli na x86 nie wchodzi w ogole. Moze to faktycznie kwestia ramu i/lub jakiegos przegrzewania sie? Zobacz co bedzie przy vsync yes w ini?

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 18 Marca 2017, 01:38:12
A ile masz sprzętowo VRAM? Bo może w przypadku mniejszej liczby idzie gdzieś w plik wymiany albo co, a przy większej próbuje i nie chce...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 18 Marca 2017, 01:43:29
3gb (gtx 1060) wiec mniej niz u ciebie, ale wystarczajaco zeby Kaliska pomiescic, bo to jest ~1gb tekstur + reszta danych, wiec chyba 2gb nie powinno przekroczyc.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 18 Marca 2017, 01:58:25
Przy vsync yes na x64 znikające elementy taboru są nadal. Swoją drogą, czy na Kaliskiej zamykają się rogatki? Bo wszędzie mam otwarte, mimo że animacje migających świateł są włączone.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 18 Marca 2017, 02:12:50
U mnie nadal w niektórych pojazdach nie załącza się WS. Cały czas słychać dźwięk dotknięcia pantografu o trakcję i dźwięk się zapętla.

Edit. Błąd niewiadomego pochodzenia związany z moją paczką... Spróbowałem odpalić na PCTGA i jest okej. Sorki za zamieszanie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 18 Marca 2017, 02:32:28
Dla porównania oczywiście odpaliłem stare, Borlandowe exe z paczki. FPS w tym samym miejscu (Ostrów w kabinie na samym początku po zatrzymaniu przed semaforem) mniej więcej koło 80/90. Nic nie znika, nic nie wywala. Więc coś definitywnie musi być zaszyte w nowym exeku.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 18 Marca 2017, 10:36:14
20170318- urwana jeszcze jedna minuta z wczytywania Kaliskiej w porównaniu do 170317.Finished loading 3d model data from "dynamic\pkp\et42_v2\42]kabina_a.e3d"
Player train init OK
Load time: 189 seconds
Eventlauncher cegielski_wjazd_dozwk
EVENT ADDED TO QUEUE: cegielski_wjazd_zwk
Komputer dopiero po włączeniu. Wczytuje zawsze tą samą ET42 z beczkami na Olechowie. Paczka DDS i brak jakichkolwiek problemów. Moja GF9600GT ma tylko 512mb pamięci, szyna 256bitów i 4gb ramu, których XP i tak całkowicie nie widzi. W ini mam taki wpis: maxtexturesize 8192Nie zanotowałem braków wczytywania pudeł ani innych nienormalnych efektów.
ED:
170317 64bit, wczytywanie td:
Finished loading 3d model data from "dynamic\pkp\303e_v1\303e_1]kabina_a.e3d"
Player train init OK
Load time: 1 seconds
EVENT LAUNCHED: tdo_rez_shp by ep07-426-ep
Type: PutValues
Sprawdzę jeszcze Kaliską. Póki co to paczki dds. Później obczaję TGA, ja zgłaszałem że w paczkach gdzie występują pliki t3d dzieją się dziwne rzeczy, wtedy mi to umknęło a konwersja na e3d miała być wyłączona, więc zaprzestałem takich prób.
ED:
170317 64bit, wczytywanie kaliskiej wyraźnie dłużej:
Finished loading 3d model data from "dynamic\pkp\et22_v2\201e_4]kabina_a.e3d"
Player train init OK
Load time: 337 seconds
Eventlauncher cegielski_wjazd_dozwk
EVENT ADDED TO QUEUE: cegielski_wjazd_zwk
Nie ma tragedii, ale różnica jest wyraźna.
Powtórne wczytanie Kaliskiej;
Player train init OK
Load time: 169 seconds
Eventlauncher cegielski_wjazd_dozwk
EVENT ADDED TO QUEUE: cegielski_wjazd_zwk
Nie wiem, czy warto tym głowę sobie zawracać.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: jakubg1 w 18 Marca 2017, 11:38:32
Witam. Mam podobny problem co kolega Wiggle (http://eu07.pl/forum/index.php/topic,28159.msg445630.html#msg445630) tyle że tam zaproponowany sposób nie działa. Na 64-bitowym wyświetla się to co w pierwszym załączniku, a na 86-bitowym to co w drugim (mimo że instalowałem ten plik). Zainstalowałem Pythona 64 w Program Files i 32 w Program Files (x86). Jakieś rady?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 18 Marca 2017, 12:22:02
W drugim przypadku masz jakiś bałagan/braki w bibliotekach Miscrosoft Visual C++ Redistributable.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: jakubg1 w 18 Marca 2017, 12:27:41
No i w związku z tym? Jak to naprawić?
Jeszcze jedno: przy instalowaniu Microsoft C++ Redistributable pojawił się błąd (w załączniku).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 18 Marca 2017, 12:29:28
"Aplikacja nie zostala wlasciwie uruchomiona" wyskakuje, gdy biblioteki (glew, glfw) w katalogu symulatora sa dla "niewlasciwej" wersji -- czyli w tym wypadku potrzebne sa 64-bitowe wersje z http://eu07.pl/userfiles/24014/bugs-eu07cplusplus64_libraries.rar. "Brak msvcr120" itd, to chyba przy braku VS runtime 2013, w tym wypadku wersji 32-bit, bo tutaj tez chyba sa dwie. Dla pewnosci moznaby sprobowac re-instalacji jesli masz go zainstalowany, ale jesli to nie pomoze, to nie wiem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 18 Marca 2017, 12:30:37
Ja już wszystkie problemy rozwiązałem, teraz tylko muszę przetestować ładowanie scenerii
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: jakubg1 w 18 Marca 2017, 12:31:35
Ten cplusplus libraries już instalowałem i dalej to samo. Rozpakowane w głównym katalogu MaSzyny.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 18 Marca 2017, 12:40:19
Jakub, jaki masz system operacyjny?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 18 Marca 2017, 12:41:26
Sek w tym, ze w katalogu moze byc tylko jedna wersja bibliotek glfw I glew (chyba, ze uzywasz kompletnie odrebnego zestawu katalogow dla wersji x86 i x64), a ktora, to zalezy od kolejnosci w jakiej byla przeprowadzona instalacja. Wiec jesli masz w tym samym katalogu x86 i x64, to uruchomi sie tylko jedna z nich. Ja to mam u siebie "rozwiazane" w ten sposob, ze w katalogu z symulatorem mam tez spakowane zestawy bibliotek dla obu wersji (w zalaczniku) i wypakowuje sobie odpowiednia wersje, nadpisujac istniejace pliki, zaleznie od tego, ktora wersje exe chce uruchomic.

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: jakubg1 w 18 Marca 2017, 13:08:37
Jakub, jaki masz system operacyjny?
Windows 7.

[do ostatniego posta]
Niestety, mam wypakowane libraries do x64 i odpalając exe x64, mam dalej to samo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Sebol82 w 18 Marca 2017, 13:12:46
Odpaliłem kilka scenerii na exeeu07-x86_170317. Biblioteki mam pobrane wszystkie (zarówno na x86 i x64). Dodatkowo zainstalowane visual studio i inne. W przypadku odpalenia exe_ x64 wywala brak pliku MSVCP120.dll. Na paczce w wersji x86 jak wysiądzie się z loka na szlaku co jakiś czas smuga bije w odwrotną stronę i szerzej niż powinna.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 18 Marca 2017, 13:21:34
@jakubg1: A pokaż screena ile masz zainstalowanych bibliotek MSVC (Panel Sterowania - Programy/Odinstaluj program - przewiń w dół do tych bibliotek Microsoftu).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: jakubg1 w 18 Marca 2017, 13:24:02
Proszę bardzo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 18 Marca 2017, 13:26:05
Być może gryzą Ci się jedne biblioteki z innymi.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Sebol82 w 18 Marca 2017, 13:27:16
Moje biblioteki. Jeśli o nie chodzi? Przynajmniej to co miałem pobrać ( paczka od TMJ i  info od Krzyśka626).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 18 Marca 2017, 13:32:27
Spróbujcie odinstalować wszystkie powtarzające się biblioteki, restart, potem zainstalujcie jakąś dla danego roku najnowszą bądź też te wersje:
http://eu07.pl/userfiles/24014/bugs-eu07cplusplus_libraries.rar
http://eu07.pl/userfiles/24014/bugs-eu07cplusplus64_libraries.rar

i znów restart.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Sebol82 w 18 Marca 2017, 13:38:14
Tomku wywaliłem już kilka razy wszystko i stawiałem paczkę na nowo (włącznie z odinstalowaniem i zainstalowaniem na nowo, za każdym razem restart kompa. Niestety nie pomogło.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 18 Marca 2017, 13:38:33
Proszę bardzo.
Z tego co widze, to tam w ogole nie ma zainstalowanych runtime dla 2013..?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: jakubg1 w 18 Marca 2017, 13:39:45
W takim razie skąd je pobrać?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 18 Marca 2017, 13:40:50
Tomku wywaliłem już kilka razy wszystko i stawiałem paczkę na nowo (włącznie z odinstalowaniem i zainstalowaniem na nowo, za każdym razem restart kompa. Niestety nie pomogło.

No dobra, ale masz 3 wersje x86 2008, 2 wersje x64 2008... Dla x64 w ogóle nie masz 2013...

EDIT: sorry, nie ten link dałem tam wcześniej. Chodziło mi o to:
http://eu07.pl/userfiles/1234/bugs-Visual_studio_64bit.7z
i
http://eu07.pl/userfiles/24014/bugs-eu07cplusplus_libraries.rar
Czyli instalki MSVR.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 18 Marca 2017, 13:42:35
W takim razie skąd je pobrać?

Z paczki w oficjalnym watku :) http://eu07.pl/forum/index.php/topic,28920.msg445222.html#msg445222 (wykonywalny plik vcredist_2013_x86.exe)
wersja 32 bit jest w pierwszym poscie, a ta dla x64 chyba w drugim, ktory zrobil Krzysiek626

(powtarzajace sie 2008 to chyba akurat nie problem, na moim mam to samo. Dopiero pozniej Microsoft troche to ogarnal)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 18 Marca 2017, 13:43:34
Macie namieszane, jeśli zainstalowany jest windows 64 bitowy, to czemu instalujecie wisual studio x86? Wisual studio instalujemy 2008, 2013 i ewentualnie 2015.
To samo dotyczy instalacji x64 na systemach windows 32 bitowych.
W obu przypadkach w katalogu z maszyną rozpakowujemy biblioteki pod windows 64 bit, które wyraźnie są do tego oznaczone i to samo z bibliotekami pod windowsa 32 bitowego. Następne biblioteki to katalog python w katalogu z maszyną, jest inny dla wesrji 64 bitowe i inny dla wersji 32 bitowej windows. Nie wolno mieszać tych instalacji i bibliotek.
Jeżeli macie namieszane, to odinstalować wsio, zrobić restart i jeszcze raz dobrać biblioteki do posiadanego systemu. Takie same porządki zrobić w katalogu z maszyną.
Ja do wersji 32 i 64 bitowej na windows7 zrobiłem dwie paczki całościowe, każda osobno na różne kompilacje exeków 32 i 64 bitowych.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 18 Marca 2017, 13:44:39
Krzysiek, apki 32bit wymagają bibliotek 32bit ;) Dlatego one są. W drugą stronę nawet nie wiem, czy się da zainstalować biblioteki x64 w systemie x86...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 18 Marca 2017, 13:46:56
Nie dają się instalować, przechodziłem przez to.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 18 Marca 2017, 13:55:52
Na paczce w wersji x86 jak wysiądzie się z loka na szlaku co jakiś czas smuga bije w odwrotną stronę i szerzej niż powinna.
To moze brac sie z tego, ze exe ma kilka dostepnych swiatel, ktore przydziela dynamicznie do pojazdow ktore wg kalkulacja generuja najsilniejsze/najblizsze swiatla. Domyslnie ilosc takich dostepnych zrodel ustawiona jest na 3. Zobacz, czy nastapi poprawa po wpisaniu do ini
dynamiclights 7
Przy tej ilosci oswietlenie jest bardziej stabilne bo wystarczy do obslugi 5-7 najblizszych pojazdow, zamiast domyslnego ustawienia dobrego dla 2-3.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 18 Marca 2017, 13:58:32
U mnie w 18.03 poprawa szybkości ładowania, wszystko wróciło do normy
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: jakubg1 w 18 Marca 2017, 14:21:30
W takim razie skąd je pobrać?

Z paczki w oficjalnym watku :) http://eu07.pl/forum/index.php/topic,28920.msg445222.html#msg445222 (wykonywalny plik vcredist_2013_x86.exe)
wersja 32 bit jest w pierwszym poscie, a ta dla x64 chyba w drugim, ktory zrobil Krzysiek626

(powtarzajace sie 2008 to chyba akurat nie problem, na moim mam to samo. Dopiero pozniej Microsoft troche to ogarnal)
Pobrałem, zainstalowałem, dalej to samo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 18 Marca 2017, 14:28:13
Hmm a dla pewnosci masz teraz 2013 Runtime w spisie zainstalowanych programow? Bo ten blad co ci wyskoczyl przy instalacji 2015 troche zastanawiajacy byl.
(jesli jest wyswietlony ale dalej nie dziala to nie wiem. mozna by sprobowac sie skupic tylko na uruchomieniu jednej wersji, zamiast x86 i x64 naraz, ale ciezko dojsc co tam moze byc nie tak)

Dla porównania oczywiście odpaliłem stare, Borlandowe exe z paczki. FPS w tym samym miejscu (Ostrów w kabinie na samym początku po zatrzymaniu przed semaforem) mniej więcej koło 80/90. Nic nie znika, nic nie wywala. Więc coś definitywnie musi być zaszyte w nowym exeku.
Tylko teraz jest pytanie, czy to jest kwestia samego exe, czy tez moze poprzez uzycie wiekszej ilosc vram itp wylazi tutaj jakis indywidualny problem sprzetowy, np kosci pamieci w karcie, ktora przy starym exe unika obciazenia? Zastanawiam sie, no bo przeciez gdyby to bylo uniwersalnie w kodzie, to u mnie rowniez powinno sie przynajmnie raz czy dwa pojawic.

Tutaj jest taki maly program do testowania pamieci dla gpu nvidii: https://github.com/ihaque/memtestG80 (exe jest w folderze binaries a instrukcja uzycia w opisie, w skrocie wywoluje sie go z command prompt, z parametrami X Y gdzie X to ilosc megabajtow do przetestowania, a Y to ilosc testow do przeprowadzenia) Moze warto by go bylo dla swietego spokoju puscic i zobaczyc, czy cos znajdzie?

(alternatywnie jest tez OCCT, https://www.sevenforums.com/tutorials/160729-nvidia-amd-video-card-test-occt.html chociaz ten to chyba robi tylko "stress test", ale z drugiej strony latwiej go obsluzyc)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 18 Marca 2017, 15:02:53
Wiesz, nie tylko maszynę mam na komputerze i tylko tutaj mam jakikolwiek graficzny problem, tylko na tych nowych exekach :P Zapuściłem 100 iteracji dla 2440 MB testowo, jest w połowie i póki co nic. A ileś (dziesiąt) tysięcy nie chce mi się puszczać :D

EDIT:

Test iteration 100 (GPU 0, 2440 MiB): 0 errors so far
        Moving Inversions (ones and zeros): 0 errors (78 ms)
        Memtest86 Walking 8-bit: 0 errors (562 ms)
        True Walking zeros (8-bit): 0 errors (281 ms)
        True Walking ones (8-bit): 0 errors (281 ms)
        Moving Inversions (random): 0 errors (78 ms)
        Memtest86 Walking zeros (32-bit): 0 errors (1123 ms)
        Memtest86 Walking ones (32-bit): 0 errors (1123 ms)
        Random blocks: 0 errors (218 ms)
        Memtest86 Modulo-20: 0 errors (2543 ms)
        Logic (one iteration): 0 errors (47 ms)
        Logic (4 iterations): 0 errors (31 ms)
        Logic (shared memory, one iteration): 0 errors (31 ms)
        Logic (shared-memory, 4 iterations): 0 errors (47 ms)

Final error count after 100 iterations over 2440 MiB of GPU memory: 0 errors
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 18 Marca 2017, 15:10:14
No ja wiem ze dziwnie, ale z drugiej strony wez teraz wytlumacz, czemu ten problem wystepuje chyba tylko u ciebie :d  Tak dla swietego spokoju, zerknij jeszcze moze, czy ten sam problem jest na starszej wersji, sprzed glfw i zmian we wczytywaniu obiektow?

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 18 Marca 2017, 15:40:41
Na 170228 wywala tak samo, z tym że zamiast okienka z odwołaniem do MSVC, po prostu następuje koniec apki i tworzy się pusty crashdump. Pobiorę zaraz jeszcze wersję E3D/DDS i tam wrzucę Kaliską.

W Zdarzeniach systemowych oczywiście ostrzeżenie o braku pamięci OPENGL oraz błąd:

Cytuj
Nazwa aplikacji powodującej błąd: eu07++170228.exe, wersja: 17.0.1175.483, sygnatura czasowa: 0x58b56aeb
Nazwa modułu powodującego błąd: KERNELBASE.dll, wersja: 6.1.7601.23677, sygnatura czasowa: 0x589c9620
Kod wyjątku: 0xe06d7363
Przesunięcie błędu: 0x0000c54f
Identyfikator procesu powodującego błąd: 0x3f0c
Godzina uruchomienia aplikacji powodującej błąd: 0x01d29ff4102d3e63
Ścieżka aplikacji powodującej błąd: D:\PCTGA\eu07++170228.exe
Ścieżka modułu powodującego błąd: C:\Windows\syswow64\KERNELBASE.dll
Identyfikator raportu: 6d4e0a6d-0be8-11e7-b887-002522cc24b2
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 18 Marca 2017, 16:30:13
Odpaliłem Kaliską na paczce DDS, exe x86 170318.

Maszynowy matrix :D

Co ciekawe - ta godzina itd niby na teksturach to Overlay PlayClaw5 :P
Ale Panie Administratorze! Załączniki tej wagi są niedopuszczalne! :) I jeszcze post pod postem! @m.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 18 Marca 2017, 16:36:56
No niezle :P  to moze jemu sie ten overlay wcina u ciebie, albo cos? U siebie sprawdzalem w sumie tylko z fraps, i nie uzywam tego typu rzeczy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 18 Marca 2017, 16:44:30
A jesteś w stanie coś wyciągnąć z minidumpa generowanego dla MS?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 18 Marca 2017, 16:45:42
Hmm nie wiem, ale moge sprobowac. Chociaz pewnie bedzie krzyczal ze mu symboli brakuje, ale kto to wie, zerknac zawsze warto.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 18 Marca 2017, 16:48:04
Okej.

EDIT:

Dobra, na DDS na pewno matrixa robił overlay (sic!). Wszystko się teraz wczytało poprawnie. Czas 91 sekund. Odpalam teraz TGA.

EDIT2: Na t3d/tga x86 problem wysypki pozostaje.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 18 Marca 2017, 17:16:22
Naprawdę dziwne, na x64 T3D/TGA problem z matrixem pozostał (może nie aż tak mocno, ale jednak tekstury taboru, słupów latarni oświetleniowych i niektórych budynków są pomieszane). W dzienniku systemu nie mam wówczas ostrzeżeń o braku pamięci.

x64 E3D/DDS również ładnie się wczytuje, 70 sekund i 120 FPS - wszystko jest na swoim miejscu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: RoboBatman w 18 Marca 2017, 18:04:31
Chciałbym zgłosić odkryty przypadkowo przeze mnie błąd, polegający na tym, że nie mogę odpiąć wagonu/-ów od lokomotywy ani samym klawiszem Delete ani kombinacją Shift+Delete. Odkryłem to, kiedy próbowałem przepiąć 2 ukrotnione EU07 (166+167) z jednego składu (ciężki drewniak) do drugiego, już cięższego składu z węglem z węglarkami PKP CARGO na misji L053-night-towarowy-ET42 na stacji Rudawa. Ten sam skład wstawiłem (EU07-166+EU07-167+TEM2-059 +40 węglarek) na TD i miałem to samo. Czy takie anomalią są tylko u mnie, czy ktoś również miał to samo? Numer exe: 170314. Zaznaczam iż, na exe borland-owym (numer 482) wszystko działa w porządku.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 18 Marca 2017, 18:21:04
Zrobiłem sobie paczkę E3D TGA - tekstury zamieniają się nadal na x64, ale przynajmniej czas wczytywania scenerii jest 1.5 minuty, a nie 6 ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 18 Marca 2017, 18:29:29
Chciałbym zgłosić odkryty przypadkowo przeze mnie błąd, polegający na tym, że nie mogę odpiąć wagonu/-ów od lokomotywy ani samym klawiszem Delete ani kombinacją Shift+Delete.
Testujac na szybko na TD, rozlaczanie wagonow klawiszem Del dziala u mnie dla wagonow pasazerskich, natomiast przy towarowych chyba faktycznie cos jest nie tak (dziala rozlaczanie miedzy wagonami, nie dziala miedzy wagonem i lokomotywa, a ponowne laczenie wyglada dziwnie) Przyjrze sie blizej za chwile.

Zrobiłem sobie paczkę E3D TGA - tekstury zamieniają się nadal na x64, ale przynajmniej czas wczytywania scenerii jest 1.5 minuty, a nie 6 ;)
Z tego co widze na screenie tam chyba dalej jest jakis overlay, wiec moze dalej ci miesza..?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 18 Marca 2017, 18:29:59
Próbowałem powtórzyć błąd jak u @Atapiego, ale przy okazji wystąpił inny. 170318, windows7 64 bitowy, paczka tda/t3d i wyłączone generowanie t3d. Exe 32 bitowe i taki błąd jak na screenie.
Po czym bez trudu wczytałem Bałtyk, bez żadnych błędów.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 18 Marca 2017, 18:34:28
Tego overlaya włączyłem już "po", żeby zrobić screena :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 18 Marca 2017, 18:43:09
Aha :) Tak przy okazji, ten minidump calkiem ladnie sie odczytal, i wyglada na to ze wysypalo sie na probie alokacji pamieci na teksture .tga  Byc moze w paczce tga sa jakies egzemplarze wyprodukowane w taki sposob, ze loader sobie nie radzi. Bede musial wypakowac wersje .tga i sprawdzic :/  Pewnie nie ma nadziei, ze masz tam w logu info, przy ktorym .tga sie to wydarzylo?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 18 Marca 2017, 18:51:26
Zrobiłem jeszcze inny eksperyment... Domyślne eu07.ini oraz rainsted.ini... i poprawnie wczytuje się x64 E3DTGA oraz co ciekawe - x64 T3DTGA. Zaraz sprawdzę x32...

Z tym TGA to już próbowałem zamieniać tabor na taki, który wcześniej został wczytany wg loga i nie było znaczenia co wczytywało się następne (lub poprzednie, bo poprzedni tabor też zmieniałem/usuwałem). Wywalało tak czy inaczej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 18 Marca 2017, 18:54:19
Aha :) Tak przy okazji, ten minidump calkiem ladnie sie odczytal, i wyglada na to ze wysypalo sie na probie alokacji pamieci na teksture .tga  Byc moze w paczce tga sa jakies egzemplarze wyprodukowane w taki sposob, ze loader sobie nie radzi. Bede musial wypakowac wersje .tga i sprawdzic :/  Pewnie nie ma nadziei, ze masz tam w logu info, przy ktorym .tga sie to wydarzylo?
Wysypało się pewnie bo brakło przestrzenii adresowej. U mnie kaliska T3D/TGA po załadowaniu zajmuje 5.1GiB, nie ma siły żeby to się zmieściło na 32 bitowej wersji. Z jakiegoś powodu wzrosło zapotrzebowanie na pamięć po konwersji, może kwestia tego że borland pewnie miał swój własny alokator który mógł się inaczej zachowywać.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 18 Marca 2017, 18:58:44
Zrobiłem jeszcze inny eksperyment... Domyślne eu07.ini oraz rainsted.ini... i poprawnie wczytuje się x64 E3DTGA oraz co ciekawe - x64 T3DTGA. Zaraz sprawdzę x32...

Przyznam bez bicia ze ja startera w zasadzie nie uzywam, bo .exe zazwyczaj odpalam przez F5 spod visual studio, zeby bledy latwiej wylapac jak sie trafia. W starterze tam jest chyba funkcja 'randomize textures', moza ona tutaj miesza..?

U mnie kaliska T3D/TGA po załadowaniu zajmuje 5.1GiB, nie ma siły żeby to się zmieściło na 32 bitowej wersji. Z jakiegoś powodu wzrosło zapotrzebowanie na pamięć po konwersji, może kwestia tego że borland pewnie miał swój własny alokator który mógł się inaczej zachowywać.
5.1 gb? No to faktycznie, nie dziwie sie. Ale to nienormalne jest, bo e3d/dds to jest ~1.2gb  Coraz bardziej podejrzewam ze tam jest cos skopane albo z loaderem TGA albo niektorymi TGA -- loader nie sprawdza gornej granicy wymiarow i jesli odczytuje jakies glupoty w stylu width/height powyzej 16k to chyba takie bylyby rezultaty...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 18 Marca 2017, 19:05:59
Tylko tam losowe tekstury tworzą się tylko na żądanie (kliknięcie przycisku losowania). A x86 wywaliło się na ostatnim taborze (jakiś wózek na samym końcu listy taboru), ale nie wygenerował się MS mdmp. Próbuje raz jeszcze.

EDIT: Minidump systemowo tworzony działa jakoś losowo (raz chce wysyłać do MS, raz nie i nie generuje tego). Więc dorzucam dodatkowe dwa przypadki do analizy (jeden mdmp oraz drugi dmp - który de facto jest minidumpem - wymuszony w rejestrze) oraz log.

EDIT2: Dorzucam jeszcze trzeci bez overlaya w tle. Na wszelki wypadek. W tym samym miejscu się wysypało.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 18 Marca 2017, 20:35:18
W sumie jak sie troche zastanowic to tam faktycznie moze zwyczajnie brakowac pamieci, bez zadnych krzakow -- kompresja dds to jest 4:1 albo 8:1 zaleznie od wersji. A w wersji dds Kaliska zajmuje ~700 mb w samych teksturach, plus mip-mapy to jest jakies 1gb. Przemnoz to teraz przez kompresje, i te 5 gb z kawalkiem zaczyna brzmiec calkiem normalnie.

Atapi, czy ty masz u siebie wlaczony jakis plik pamieci wirtualnej, czy moze ustawiony na 0 albo cos podobnie malego?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 18 Marca 2017, 20:35:40
Matrix się wyjaśnił... Okazuje się, że nie pasuje symulatorowi... maxtexturesize 1024 :O Jak było domyślne 8GB, to było okej. Z 2048 też wszystko jest na swoim miejscu. Ale z 1024 za cholerę.

EDIT: No mam jakiś 1 GB włączony, a co?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 18 Marca 2017, 20:55:42
Oo ciekawe, przy 1024 tam chyba sporo tekstur wylatuje poza limit, a przy wersji tga trzeba to jeszcze dopracowac.

O wirtualna zapytalem, bo glowy nie dam ale chyba jesli karcie gfx brakuje pamieci to w niektorych przynajmniej okolicznosciach moze byc zmuszona korzystac z pliku swap, a nie pamieci fizycznej. Wiec przy malym swapie i duzej ilosci tekstur byc moze rzeczywiscie moze jej miejsca zabraknac.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 18 Marca 2017, 20:57:23
Udało się wywołać efekt jak na screenie, nowe malowanie czapajewa. maxsize na 512. Oczywiście Kaliska. Wywaliłem część składów i część nieistotnych inkludów, to się odpaliła na win Xp. Swapa mam 12gb.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 18 Marca 2017, 21:01:05
Znaczy... Na x86 wysyp mam niezależnie od tego, czy SWAP mam 16GB czy 0... Także tego. Przynajmniej tyle dobrego, że definitywnie wiem co powoduje u mnie matrixa (maxtexturesize 1024 lub załączony overlay - w tym przypadku PlayClaw5) i kiedy go nie ma :D .
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 18 Marca 2017, 21:04:31
Po wpisaniu w ini 8192, tekstury są dobrze wyświetlane, więc nie tylko u Tomasza tak jest.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 18 Marca 2017, 21:42:33
Dla porządku tylko dodam, że na nowym exe czas ładowania wrócił do normy - jest identyczny jak na wersjach sprzed paska ładowania.

A i jeszcze jedno - gdzieś tam w tym wątku @tmj wspominał, że za długo mu się moje całkowo ładuje dla testowania tych autek - spróbuj ograniczyć pliki inc wczytywane na początku tylko do tych:
//node -1 -1 none model 0 0 0 0 slimson/calkowo_v2/calkowo_v2_teren.t3d none endmodel

include slimson/calkowo_v2/v2_drogi.scm end
include slimson/calkowo_v2/v2_elementy.scm end
include slimson/calkowo_v2/v2_eventy.scm end
include slimson/calkowo_v2/v2_memcelle.scm end
include slimson/calkowo_v2/v2_przejazdy.scm end
include slimson/calkowo_v2/v2_rozklad.scm end
include slimson/calkowo_v2/v2_SRK.scm end
include slimson/calkowo_v2/v2_tory.scm end
include slimson/calkowo_v2/v2_wskazniki.scm end
Załaduje Ci się sceneria bez żadnych dekoracji - terenu, słupków, znaków itp., ale powinny działać wszystkie eventy i cała reszta "silnika".

// edit
Tak jeszcze a propo różnych ciekawostek w exe, choć to chyba nie jest związane z konwersją tylko stanowi chorobę przewlekłą, bo już coś podobnego kiedyś widziałem. W log.txt wpisywane są tajemnicze komendy z cyklu "TablePurger: Czyszczenie tabelki. Tabelka powiększona do X pozycji". Nie wiem do końca, o co tu chodzi, ale przed chwilą zauważyłem, że symek mi się tak kilkukrotnie śmiesznie na dłuższą chwilę przyciął - już oczekiwałem wysypu, ale nie - przeżył. Zajrzałem do loga i jedyne podejrzane rzeczy, jakie zauważyłem to taka litania:
Tabelka powiększona do 55072 pozycji
TablePurger: Czyszczenie tabelki.
Tabelka powiększona do 55088 pozycji
TablePurger: Czyszczenie tabelki.
Tabelka powiększona do 55104 pozycji
TablePurger: Czyszczenie tabelki.
Tabelka powiększona do 55120 pozycji
TablePurger: Czyszczenie tabelki.
Tabelka powiększona do 55136 pozycji
TablePurger: Czyszczenie tabelki.
Tabelka powiększona do 55152 pozycji
Początku wam oszczędzę, ale generalnie taki ciąg zaczął się przy 3008 pozycjach i od tego miejsca jest taka litania powiększania tabelki do 55132 pozycji. Niestety nie wiadomo, o jaki pojazd chodzi (zakładam, że jest tu mowa o tabelce skanowania), ale na chłopski rozum wydaje mi się, że to nie powinno tak działać...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 18 Marca 2017, 23:56:26
Dodatkowo sprawdziłem te nieszczęsne zamykanie przejazdów na Kaliskiej - na exe x64 w paczce E3D/DDS ono chodzi, ale na T3D/TGA już nie. Jest tylko migotanie sygnalizatorów i gong. Rogatki ani drgną.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 19 Marca 2017, 02:22:24
Załaduje Ci się sceneria bez żadnych dekoracji - terenu, słupków, znaków itp., ale powinny działać wszystkie eventy i cała reszta "silnika".
Od tego to ja zaczalem ;)  ale i tak sceneria jest po prostu duza w sensie wymiarow, i nawet po odkomentowaniu wiekszosci pojazdow i tak jest ich spora grupa, podczas gdy do testow najlepszy bylby pojedynczy egzemplarz ganiajacy w malym kolku, albo cos podobnego. Jak na razie zaczalem miec watpliwosci na ile to kwestia fizyki a na ile AI, bo wyglada na to, ze AI po prostu na krotko przed przejazdem luzuje hamulec i grzeje jakby nigdy nic przed siebie.

W ramach uaktualniania exe, dwie zmiany i poprawka. Poprawka to dzialajace (na razie prymitywnie ale zawsze) skalowanie tekstur .tga  Tzn jesli teraz wpisany jest maxtexturesize np. 1024 to tekstury beda faktycznie zmniejszone do tych rozmiarow. Samo w sobie akurat w ladowaniu Kaliskiej w wersji tga roznicy to nie zrobilo, natomiast zrobilo roznice w polaczeniu ze zmiana w ustawieniach kompilacji exe x86 -- exe w tej wersji ma teraz ustawiony przelacznik umozliwiajacy wykorzystanie do ~4gb pamieci  zamiast standardowych 2 gb. Gwarancji ze to czegos nie popsuje nie ma, ale z drugiej strony biorac pod uwage ze wersja x64 chodzi, to jakas szansa jest :)

Druga zmiana spowodowana jest ciaglym uzeraniem sie jakie ludzie maja z bibliotekami -- od tej pory to co sie da wlaczone jest do exe. W praktyce oznacza to, ze glfw.dll i glew.dll nie sa juz potrzebne, powinien wystarczyc python i visualc runtime.

Aha, przyjrzalem sie tez rozlaczaniu i laczeniu wagonow, ale wyglada ze tutaj  jest w porzadku. Z tym ze przy sprzegach srubowych itp trzeba sklad docisnac, wiec moze akurat z tym byl klopot.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Tomnord15 w 19 Marca 2017, 09:43:40
Kiedy na poprzednich exe Kaliska nawet nie chciala się uruchomić, to na ostatnim bez problemu uruchomiła się na moim starym stacjonarnym kompie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 19 Marca 2017, 09:52:28
Dzięki, żadne umieszczane wersje x64 (poza tą) nie uruchamiały się u mnie, niezależnie od DLL-ek. Jedyne pasujące DLL-ki wgrywał @Milek, ale ostatnio nie mogłem się nawet do nich dokopać.

Widzę, że to się coraz bardziej stabilne robi. Pytanie, czy jest w planach dodanie wyświetlania bieżącej prędkości i parametrów lokomotywy w trybie gracza? Chodzi mi o typowo użytkowy widok, jak w komercyjnych symulatorach pociągów typu Trainz / MSTS. Tzn nie chodzi o graficzny bajer, ale możliwość odczytania tego samego co jest na pulpicie bez patrzenia na pulpit. Czyli - co mam na nastawniku, manometrach i haslerze.

Druga sprawa: trzęsienie obrazu i bufor Z. To jest w trakcie przerabiania? Obserwuję zmniejszenie trzęsienia krawędzi torów, ale za to jest teraz inny artefakt, którego nie było wcześniej: Jak mam drzewo i krzaczek przed drzewem (sceneria L053, dzień) silnik nie może się zdecydować, czy krzaczek ma zasłaniać drzewo, czy udawać że jest za drzewem. Poprzednio miałem 60 takich "wersji" na sekundę, teraz mam dokładnie co sekundę. Czasem błąd jest grubszy: drzewa nie mogą się zdecydować czy są przed budynkiem czy za budynkiem.

No i w końcu kwestia shaderów. Nie rozumiem tego do końca. Dla karty graficznej wszystko co ona jest w stanie zrozumieć to shader. Więc nie bardzo widzę, jak MaSzyna może wyświetlać cokolwiek na DX czy OpenGL BEZ shaderów. To raczej niemożliwe, więc pewnie kwestia języka i żargonu, prosiłbym o wytłumaczenie dla jasności.

Oświetlenie na niektórych trasach wygląda nieźle, na niektórych troszkę gorzej, na niektórych tragicznie, w zależności od wielkości trójkątów terenu. Strzelam, że dopiero kombinacja vertex-shaderów z pixel-shaderami będzie załatwiać sprawę, ale zbudowanie pixel shaderów biorących pod uwagę geometryczne położenie wierzchołków nie jest rzeczą trywialną i raczej nie powstanie "w tym tygodniu", a nawet "w tym miesiącu". Dobrze zgaduję?

Ostatnie pytanie: VBO. Czy ta opcja w ogóle działa i powinniśmy testować z włączoną i wyłączoną? Z tego co ja testowałem w ostatnich wersjach - nie widzę żadnej różnicy, ale znów być może różnica nie jest widoczna w każdym miejscu.

Z różnicy którą widzę: dużo wyższy FPS. Poprawiony czas ładowania. Trzęsienie obiektów ma mniejszą częstotliwość (to na plus).

Na marginesie, testowałem SN61 - brak działania rozkładu dla tej lokomotywy. Rozkład się przewija jak ją podmienię na stonkę.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 19 Marca 2017, 10:37:44
No i w końcu kwestia shaderów. Nie rozumiem tego do końca. Dla karty graficznej wszystko co ona jest w stanie zrozumieć to shader. Więc nie bardzo widzę, jak MaSzyna może wyświetlać cokolwiek na DX czy OpenGL BEZ shaderów. To raczej niemożliwe, więc pewnie kwestia języka i żargonu, prosiłbym o wytłumaczenie dla jasności.

Oświetlenie na niektórych trasach wygląda nieźle, na niektórych troszkę gorzej, na niektórych tragicznie, w zależności od wielkości trójkątów terenu. Strzelam, że dopiero kombinacja vertex-shaderów z pixel-shaderami będzie załatwiać sprawę, ale zbudowanie pixel shaderów biorących pod uwagę geometryczne położenie wierzchołków nie jest rzeczą trywialną i raczej nie powstanie "w tym tygodniu", a nawet "w tym miesiącu". Dobrze zgaduję?

Ostatnie pytanie: VBO. Czy ta opcja w ogóle działa i powinniśmy testować z włączoną i wyłączoną? Z tego co ja testowałem w ostatnich wersjach - nie widzę żadnej różnicy, ale znów być może różnica nie jest widoczna w każdym miejscu.
Obecnie używane są funkcje fixed pipeline ze starego opengl1.x. Tak, wewnętrznie sterownik pewnie sobie podpina swój domyślny shader, ale aplikacja nie ma do tego dostępu.

Nie, zwykłe oświetlenie blinn-phong na shaderach jest dosyć trywialne :). Wersję eksperymentalną z shaderami wrzucę niedługo. Połączenie shaderów z display lists nie jest możliwe, więc będzie trzeba jeszcze trochę dopieścić to czego obecnie brakuje w trybie VBO.

VBO na buildach tmj jest wyłączone.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: jakubg1 w 19 Marca 2017, 11:25:39
Exe w nowej wersji w końcu się uruchomiło. Niestety nie czekałem na rozczarowanie długo, po ułamku sekundy symulator się wyłączył. W logu znalazłem coś takiego:
Font init failed
Domyślam się, że nie mam jakiejś czcionki. Log i errors w załączniku.
PS. Zaznaczenie "Napisy z GLUT32.DLL" nie rozwiązuje problemu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 19 Marca 2017, 12:04:54
Cytuj
Na marginesie, testowałem SN61 - brak działania rozkładu dla tej lokomotywy. Rozkład się przewija jak ją podmienię na stonkę.
Załącznik, przewija się rozkład, ale bardzo krytyczne są miejsca w których należy stanąć.
Cytuj
Pytanie, czy jest w planach dodanie wyświetlania bieżącej prędkości i parametrów lokomotywy w trybie gracza? Chodzi mi o typowo użytkowy widok, jak w komercyjnych symulatorach pociągów typu Trainz / MSTS.
Też byłbym zainteresowany.
Cytuj
Jak mam drzewo i krzaczek przed drzewem (sceneria L053, dzień) silnik nie może się zdecydować, czy krzaczek ma zasłaniać drzewo, czy udawać że jest za drzewem.
Tu poprosiłbym o screena w załączniku dla identyfikacji miejsca i opis w jakiej scenerii/scenariuszu wystąpiła ta ciekawostka. U siebie nic takiego nie zauważyłem, a jeżdżę dużo, nawet za dużo. Objechałem Całkowo na 170319 /32bit, jest dobrze.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 19 Marca 2017, 12:45:11
Exe w nowej wersji w końcu się uruchomiło. Niestety nie czekałem na rozczarowanie długo, po ułamku sekundy symulator się wyłączył. W logu znalazłem coś takiego:
Font init failed
Domyślam się, że nie mam jakiejś czcionki. Log i errors w załączniku.
PS. Zaznaczenie "Napisy z GLUT32.DLL" nie rozwiązuje problemu.
Uzywana czcionka jest wbudowana w kazdy windows chyba od xp w gore, wiec powinna byc :)  byc moze jest to wina karty Ati -- o ile dobrze rozumiem, to w przeszlosci byly problemy z wyswietlaniem czcionek przez display list na tych kartach. Myslalem ze moze zostalo to w miedzyczasie naprawione w sterownikach, ale mozliwe ze nie. Zrobie tutaj zmiane, zeby brak czcionki byl traktowany raczej jak niedogodnosc, a nie blad -- napisow nie bedzie (przynajmniej do czasow normalnego UI) ale reszta powinna dzialac.

Pytanie, czy jest w planach dodanie wyświetlania bieżącej prędkości i parametrów lokomotywy w trybie gracza? Chodzi mi o typowo użytkowy widok, jak w komercyjnych symulatorach pociągów typu Trainz / MSTS.
Nie bylem pewien, czy jest to cos co opinia publiczna chcialaby miec dodane, bo to podobno powazny symulator jest, a nie zabawka jak tamte ;)  Dodac ekran jak najbardziej mozna, zdecydujcie sie tylko czy i co powinno sie na nim znalezc.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 19 Marca 2017, 12:59:11
 Nie wiem co się zmieniło. Wrzuciłem wersję z 18.03 na ruszt. Skompilowałem z starą i nową ścieżką renderingu. Obie wersje trzymają teraz około 50 FPS bez MSAA oraz około 40FPS z MSAA. To jest bardzo ok. Nowa ścieżka daje troszkę mniej stabilny poziom FPS, ma częściej występujące skoki i ciągłe większe zmiany.

ui_layer nie jest zapisane w UTF-8.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 19 Marca 2017, 14:56:24
Pytanie, czy jest w planach dodanie wyświetlania bieżącej prędkości i parametrów lokomotywy w trybie gracza? Chodzi mi o typowo użytkowy widok, jak w komercyjnych symulatorach pociągów typu Trainz / MSTS.
Nie bylem pewien, czy jest to cos co opinia publiczna chcialaby miec dodane, bo to podobno powazny symulator jest, a nie zabawka jak tamte ;)  Dodac ekran jak najbardziej mozna, zdecydujcie sie tylko czy i co powinno sie na nim znalezc.
Widze to jako opcje do uruchomienia, jak jest potrzeba. Wyswietlenie tych parametrow pomaga poczatkujacym, ktorzy nie sa w stanie ocenic w jakiiej pozycji jest kolo nastawnika, czy kran hamulca. Dodanie cisnien z manometrow i predkosci tez nie powinno przeszkadzac. W ini dobrze by bylo okreslic kolor czcionki, ale to nie priorytet. Czesto zlewa sie z tlem. Mozna tez zrobic jakis kolor na stale, byle rzadko wystepujacy na sceneriach. Profesjonalnosc projektu nie ucierpi na tym. ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 19 Marca 2017, 19:16:56
Planowalem poprawiac cos innego ale dobra, nowe uaktualnienie jest w ramach koncertu zyczen :P

- Dodane nowe parametry dla pythona:
linebreaker (stan wylacznika szybkiego)
mainctrl_pos (zazadane ustawienie dla nastawnika glownego)
scndctrl_pos (zadane ustawienie nastawnika dodatkowego)
traction_voltage (wartosc napiecia na pantografach)

- dodana mozliwosc zmiany koloru tekstow interfejsu uzytkownika. Odbywa sie to wpisem w .ini
uitextcolor R, G, B
gdzie R, G, B to skladowe koloru, w zakresie 0-255

- przekonstruowany nieco rzeczony interfejs uzytkownika. Klawisze F1, F2, F3 maja teraz dwa tryby, orientacyjny i poszerzony, przelaczane kolejnymi nacisnieciami klawisza. W trybach tych podawane sa:
f1: stan nastawnikow i hamulcow, w trybie poszerzonym takze predkosc, ograniczenia i cisnienie hamulcow
f2: nastepna stacja, w trybie poszerzonym takze rozklad (dotychczas dostepne pod f3)
f3: wszystkie "flaki" pojazdu, w trybie poszerzonym takze tablica skanowania (dotychczas dostepne pod f2)

- brak czcionek jest teraz przez exe ignorowany, zamiast na twardo zamykac program
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 19 Marca 2017, 19:22:58
Wiesz, jak zobaczyłem załącznik, chciało mi się zawołać: prrrr szalony. Właśnie odpaliłem Odyseję Spalinową na porannym exe, a tu widzę - niepotrzebnie. Ale dobrze, dzięki i już pomykam na szlak.
ED:
Limit: 120km/h, next limit: 110km/h in 1,4km Szczęka mi opadła, coś dla słabo zorientowanych w sygnalizacji. Brak mi słów.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 19 Marca 2017, 19:53:24
Połączenie shaderów z display lists nie jest możliwe, więc będzie trzeba jeszcze trochę dopieścić to czego obecnie brakuje w trybie VBO.

VBO na buildach tmj jest wyłączone.

Czyli jak dobrze zrozumialem, to na obiektach z DL nie da sie zrobic swiatla stozkowego opartego na shaderach?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 19 Marca 2017, 19:58:18
W zasadzie tak, display lists to jest pozostalosc sztywnej konfiguracji ze starego openGL, i w 'nowym openGL gdzie prace wykonuja shadery po prostu ich nie ma. Dlatego nastepnym krokiem jest doprowadzenie kodu opartego na DL do stanu, gdzie w liscie skompilowane jest tylko kreslenie samej geometrii, bo wtedy mozna ta czesc latwo wywalic i zastapic VBO, ktore z shaderami pracuja normalnie (albo wyciac DL w pien i zostawic sciezke VBO, jesli uda sie ja doprowadzic do pelnej funkcjonalnosci. Zalezy glownie od tego, co bedzie prosciej zrobic)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: jakubg1 w 19 Marca 2017, 20:09:37
Przejrzałem, i w końcu odpaliło. Zostają dwa problemy:
1. W debugmode ESC dalej pauzuje zamiast przyspieszać czas.
2. Wiadomo może kiedy napisy zostaną naprawione? Szczególnie się to przydaje przy robieniu ekranów.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 19 Marca 2017, 20:12:06
1. W debugmode ESC dalej pauzuje zamiast przyspieszać czas.

No i bardzo dobrze. Od przyspieszania jest Shift/Ctrl + F6.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 19 Marca 2017, 20:14:04
Przejrzałem, i w końcu odpaliło. Zostają dwa problemy:
1. W debugmode ESC dalej pauzuje zamiast przyspieszać czas.
2. Wiadomo może kiedy napisy zostaną naprawione? Szczególnie się to przydaje przy robieniu ekranów.
Przyspieszenie czasu jest pod F6+shift i/lub ctrl. Spod Esc usunalem, bo byly komentarze ze chyba nikt tego nie uzywa, a i dwa osobne klawisze do pauzy, kazdy w innym trybie, to troche przegiecie.
Napisy wroca przy wprowadzaniu bardziej normalnego ui, ale ciezko dokladnie okreslic kiedy to bedzie, bo rzeczy do zrobienia "na juz, bo od tego zalezy 5 nastepnych" jest sporo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: jakubg1 w 19 Marca 2017, 20:18:14
Ooo, i super, można przyspieszyć czas bardziej niż Esc :D
Niestety jest pewien problem, bo podczas przyspieszenia czasu kamera w kabinie przesuwa się wolniej. Oczywiście nie trzeba tego rozwiązywać na już, większy priorytet mają dla mnie napisy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 19 Marca 2017, 20:20:04
Ale generalnie da sie zrobic te swiatala na shaderach na DL w tym momencie, czy stoja jakies przeciwwskazania techniczne, czy raczej cos by nie dzialalo do konca tak jak powinno? Pytam bo
bo mialem renderowanie swiatelka na shaderach i bylo wszystko okej, tyle ze nie potrafilem odczepic go od kamery coby w dowolnym miejscu usytuowac a takze zmienic jego kolor. Pozniej pokomentowalem te wstawki i nie wracalem do tego. Poszukac moge ale czy sobie przypomne co do czego bylo aby wydzielic co trzeba to juz nie wiem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 19 Marca 2017, 20:22:51
Spod Esc usunalem, bo byly komentarze ze chyba nikt tego nie uzywa
Dementuję – używam na codzień.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 19 Marca 2017, 20:29:31
No masz, to teraz bede musial wlepiac z powrotem ;/
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 19 Marca 2017, 20:31:35
To i tak w celach deweloperskich, więc sobie sam dorobię później ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 19 Marca 2017, 20:49:51
Ale generalnie da sie zrobic te swiatala na shaderach na DL w tym momencie, czy stoja jakies przeciwwskazania techniczne, czy raczej cos by nie dzialalo do konca tak jak powinno?
Teoretycznie to chyba mozna (bo na upartego DL mozna potraktowac po prostu jako zrodlo danych dla shadera, tak ja kazde inne) ale przyznam ze takiego laczenia nigdy nie probowalem :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 19 Marca 2017, 21:43:48
W wersji 19b spadek o 10 ftp odnotowałem na TD. Załącznik do podglądu.


Edit. Jednak po drugim uruchomieniu wróciło do normy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 19 Marca 2017, 21:59:43
Dobra przypadkiem wpadłem na inny błąd związany prawdopodobnie z pythonem. Przy podłączeniu więcej niż jednego pojazdu np. EU43, czy też EN57AKŁ jak to u mnie to nie wyświetla się ukrotnienie czyli wyświetla parametry tylko dla pierwszego pojazdu bądź ezt. Sprzęg ustawiony na 183, dodam, że na exe borlandowskim działało jak należy
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 19 Marca 2017, 22:00:25
Ja nie wiem jak to dzialalo, ale dzialao na DL posklejane zjakiegos tutka. Sam bylem pod wrazeniem efektu, no ale ze nie dalem rady z pozycjonowaniem i zmiana kolorow to poszlo w niepamiec. Dobra, szukac tego, warte to uwagi i proby wdrozenia na DL czy olewamy na rzecz ponoc przyszlosciowego VBO?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 19 Marca 2017, 22:09:06
Dobra przypadkiem wpadłem na inny błąd związany prawdopodobnie z pythonem. Przy podłączeniu więcej niż jednego pojazdu np. EU43, czy też EN57AKŁ jak to u mnie to nie wyświetla się ukrotnienie czyli wyświetla parametry tylko dla pierwszego pojazdu bądź ezt. Sprzęg ustawiony na 183, dodam, że na exe borlandowskim działało jak należy
Polaczylem 2 traxxy na TD sprzegiem 55 i wyswietlacz pokazuje parametry dla obu. Tego EN57AK nie mam, wiec niestety nie moge tego sprawdzic.

Ja nie wiem jak to dzialalo, ale dzialao na DL posklejane zjakiegos tutka. Sam bylem pod wrazeniem efektu, no ale ze nie dalem rady z pozycjonowaniem i zmiana kolorow to poszlo w niepamiec. Dobra, szukac tego, warte to uwagi i proby wdrozenia na DL czy olewamy na rzecz ponoc przyszlosciowego VBO?
Swiatla to chyba Milek ma juz dosc ogarniete w swojej wersji, podobno zobaczymy rezultaty w tym tygodniu. Ale jak chcesz to poszukaj, nigdy nie zaszkodzi miec pod reka wiecej kodu ;o
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 19 Marca 2017, 22:11:30
Panikowałem trochę z tym ukrotnieniem. Okazało się, że nie mam kodu ekranu dla trzech ukrotnionych akł, a byłem przekonany, że je zrobiłem. :D
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 19 Marca 2017, 22:13:59
Ja bym był za jak najszybszym wycięciem DL i stopniowe łatanie VBO.
Te shadery na vbo z którymi się bawiłem ostatnio wrzuciłem na github (https://github.com/Milek7/maszyna/tree/4d19e49398af9ddffc771af82dee921665c803af). Trzeba to jeszcze dopieścić bo nie działjaą świecące obiekty i obecnie światła są w ogóle niewyregulowane.
Chciałem to dzisiaj zmergować z ostatnimi zmianami tmj, tylko tutaj pojawił się problem. tmj przy wydzielaniu renderera wywalił vbo. Przydało by się tam spowrotem wrzucić vbo (i opcjonalnie w ogóle wywalić dl) bo tak to będziemy rozwijać dwie niezależne gałęzie. @tmj, masz jakieś sugestie co do sposobu wciskania vbo tam?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 19 Marca 2017, 22:15:21
Panikowałem trochę z tym ukrotnieniem. Okazało się, że nie mam kodu ekranu dla trzech ukrotnionych akł, a byłem przekonany, że je zrobiłem. :D
No to mi ulzylo, bo nie wykluczalem, ze dzisiejsze grzebanie w tym kawalku kodu zeby dodac nowe dane mialo jakies efekty uboczne :>

edit
Ja bym był za jak najszybszym wycięciem DL i stopniowe łatanie VBO.
(..)
Chciałem to dzisiaj zmergować z ostatnimi zmianami tmj, tylko tutaj pojawił się problem. tmj przy wydzielaniu renderera wywalił vbo. Przydało by się tam spowrotem wrzucić vbo (i opcjonalnie w ogóle wywalić dl) bo tak to będziemy rozwijać dwie niezależne gałęzie. @tmj, masz jakieś sugestie co do sposobu wciskania vbo tam?
Ja sie tak troche sklaniam ku robieniu tego "od konca DL" bo raz ze mozna to robic malymi krokami, co jest troche latwiejsze do sprawdzenia, a dwa (wazniejsze) ze sciezka DL jest w tej chwili "kompletna" czyli liczy wszystko, a co liczy sciezka VBO to dokladnie nie wiadomo, wiec trzeba by to wszystko dokladnie przejrzec, porownac, I wtedy ewentualnie latac, i boje sie ze to w sumie wiecej roboty bedzie. Ale jakis twardych preferencji na ten moment nie mam.

Wlaczyc z powrotem VBO do mojej wersji to w zasadzie nie bedzie duzy problem, wiec moge to dodac z powrotem do nastepnego uaktualnienia i wtedy mozesz spokojnie laczyc? A w miedzyczasie mozemy sie rozejrzec po kodzie i zastanowic z ktora opcja bedzie wygodniej. Na pierwszy krok planowalem na razie wstawic zastepczy "matrix stack" dla glTranslate, Rotate() itp, bo to sie przyda bez wzgledu ktora wersja pojdziemy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 19 Marca 2017, 22:26:52
Z rzeczy niedorobionych w VBO o których Ra pamięta:
1. Skrzyżowania dróg. Ale te są niedorobione koncepcyjnie nawet. Psują skanowanie i auta nie trzymają trajektorii.
2. Siec trakcyjna z dwoma przewodami nośnymi (chyba nieużywana nigdzie u nas).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 19 Marca 2017, 23:03:28
Wlasnie jestem w drodze na trasie drawinowo. Fatalnie wyglada kwestia oswietlania elementow scenerii. Zbyt szybko przed kabina "gasna" a powinien byc oswietlany jeszcze kilka metrow. Podsypka ok ale to co po bokach np wskazniki juz nie ok.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 19 Marca 2017, 23:06:31
A ja uważam, że i tak to za dobrze świeci względem reala ;) Bo tak idealnie to nie jest, jak sobie niektórzy wyobrażają.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 19 Marca 2017, 23:07:22
Z oświetleniem jest wiadoma sprawa, było tu tłumaczone z jakiego powodu tak wygląda. Zapowiedzi w tym temacie są optymistyczne.
Ostatnie exe, chyba nic nie zostało zepsute względem poprzedniego, same C++.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 19 Marca 2017, 23:22:48
Zbyt szybko przed kabina "gasna" a powinien byc oswietlany jeszcze kilka metrow. Podsypka ok ale to co po bokach np wskazniki juz nie ok.
To do pewnego stopnia pozostalosc po poprzedniej wersji swiatel, ktory mialy szerszy zasieg. Moge troche cofnac polozenie zrodla, zeby swiecilo 'blizej', ale z drugiej strony jesli Atapi mowi ze i tak jest za dobrze, to nie wiem :d
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 19 Marca 2017, 23:27:48
Zobaczymy co wyjdzie na shaderach, gdy odblaski dostaną specular 254 a reszta 150 albo mniej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 20 Marca 2017, 13:24:58
Wlaczyc z powrotem VBO do mojej wersji to w zasadzie nie bedzie duzy problem, wiec moge to dodac z powrotem do nastepnego uaktualnienia i wtedy mozesz spokojnie laczyc

Jakbyś mógł to się przyda.
Na pierwszy krok planowalem na razie wstawic zastepczy "matrix stack" dla glTranslate, Rotate() itp, bo to sie przyda bez wzgledu ktora wersja pojdziemy.
Być może nie będzie takiej potrzeby. Nie wiem ile jeszcze tego zostało, ale wyprułem już to z renderowania TModel3d. (pozamieniałem na glm::mat4 przekazywane w argumentach)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 20 Marca 2017, 17:20:30
Ok, podpialem z powrotem w kodzie renderowanie VBO; tak na szybko, wiec nie ma tam poprawki ktora zrobiles dla torow, wiec oswietlenie wyglada jeszcze slabiej niz zwykle, ale to chyba akurat najmniejszy problem :d

dzisiejsze pseudo-uaktualnienie naprawia predkosc poruszania sie w kabinie przy wlaczonym przyspieszeniu czasu, i wlacza ponownie korekte poziomu oswietlenia pojazdow w tunelach itp, ktora przypadkiem wylaczylem :|
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 20 Marca 2017, 18:22:57
Słuchaj, a jesteś w stanie sprawdzić przy okazji dlaczego w EZT nie działa dobrze programator świateł? To znaczy to co powinno się świecić na przodzie to świeci się na tyle, a przód ma wszystkie światła zgaszone. Sprawdzałem na EN57-2000 oraz na tym AKŁ co robię i nie działało, ale Antek mówił, że w elfie działało także problem jakiś jest ale nie wiadomo dlaczego. Oczywiście sprawdź to jeśli miałbyś czas i nie byłoby to problemem, bo pewnie więcej rzeczy masz do zrobienia w exe.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 20 Marca 2017, 18:50:28
Postawiłem świeżą paczkę, stara się zużyła. Zapakowałem nowe exeki 19b i dzisiejsze. Nie trzeba już żadnych bibliotek w katalogu z symulatorem. Super sprawa, w 64 bitowej wersji systemu operacyjnego możemy trzymać dwa exe (32 i 64 bit) i odpalać które chcemy. Odpaliłem na VBO, ale wiadomo jak tam jest, a jest do zmiany. Na 170320 na VBO, pod F9 wyświetla mi: Last openGL error: 1281 miałem tak na jednej z poprzednich kompilacji także na DisplayList. W 19b nie miałem tego błędu.
Przy moim nastawieniu na przejezdność scenerii, na wyświetlanie, obsługę, łatwość instalacji, oraz niestety małą znajomość obsługi określonych pojazdów, nie jestem w stanie wyłapać błędów przełączników, działania ekranów i tym podobnych błędów. Dlatego apeluję o wzmożenie testów, im więcej nas sprawdzi to exe, będzie lepsza paczka 2017.Proszę o to, bo instalacja exe, w tej chwili jest bardzo prosta.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 20 Marca 2017, 19:02:33
Słuchaj, a jesteś w stanie sprawdzić przy okazji dlaczego w EZT nie działa dobrze programator świateł? To znaczy to co powinno się świecić na przodzie to świeci się na tyle, a przód ma wszystkie światła zgaszone. Sprawdzałem na EN57-2000 oraz na tym AKŁ co robię i nie działało, ale Antek mówił, że w elfie działało także problem jakiś jest ale nie wiadomo dlaczego. Oczywiście sprawdź to jeśli miałbyś czas i nie byłoby to problemem, bo pewnie więcej rzeczy masz do zrobienia w exe.
Nie jestem w stanie sprawdzic, bo wersja en57-2000 z paczki ktora mam tutaj zainstalowana ma tylko standardowe swiatla (ktore dzialaja), a tego drugiego w ogole nie mam. Natomiast w innych lokomotywach (traxx i chyba ep09 albo cos, nie pamietam) sekwencje swiatel przelaczane przez klawisz U rzeczywiscie wydaja sie dzialac normalnie, wiec moze blad jest tutaj z wpisem wartosci w tabeli LightsList w pliku .fiz?

edit: skopiowalem na probe zestaw z traxxa do en57 i faktycznie, zapalaja sie na drugim koncu. Przyjrze sie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Tomnord15 w 20 Marca 2017, 19:08:59
A jak się ma sprawa z EZT, bo wcalę nie mogę uruchomić kibelków. Załączam baterię, pantografy w górę, potem rozrząd i klapa, nie pokazuje w rozrządczym napięcia sieci wcale mimo że pantografy mam podniesione. Najnowsza wersja exe. Czy może ja robię coś źle? W logu czysto za to załączam errors.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 20 Marca 2017, 19:10:56
Dokładnie tak jak piszesz, skopiowałem z traxxa no i nie działa, a przełącznik i fiz wszystko jest tak jak w traxxie (oczywiście nazwa modelu przełącznika inna).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 20 Marca 2017, 19:12:35
A jak się ma sprawa z EZT, bo wcalę nie mogę uruchomić kibelków. Załączam baterię, pantografy w górę, potem rozrząd i klapa, nie pokazuje w rozrządczym napięcia sieci wcale mimo że pantografy mam podniesione. Najnowsza wersja exe. Czy może ja robię coś źle? W logu czysto za to załączam errors.

Miałem to samo i doszedłem do tego, że błąd się pojawił w jakichś plikach t3d ponieważ postawiłem na nowo symulator i działało, lecz jak zacząłem kopiować foldery dynamic, models, textures to znów pojazdy nie miały napięcia. Ale tak jak mówię, postaw na nowo maszynę i będzie okej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 20 Marca 2017, 19:16:30
A jak się ma sprawa z EZT, bo wcalę nie mogę uruchomić kibelków. Załączam baterię, pantografy w górę, potem rozrząd i klapa, nie pokazuje w rozrządczym napięcia sieci wcale mimo że pantografy mam podniesione. Najnowsza wersja exe. Czy może ja robię coś źle? W logu czysto za to załączam errors.
Czlony EZT musza byc spiete sprzegiem 55 (lub jeszcze lepiej 183)  Przykladowy zestaw ktory dziala u mnie na TD:

trainset rozklad start 0.0 0.0
node -1 0 EN57-1542ra dynamic PKP\EN57_V1 EN57-1542RA 6BAII 0 headdriver 55 30 Passengers enddynamic
node -1 0 EN57-1542s dynamic PKP\EN57_V1 EN57-1542S 6BSII 0 nobody 55 25 Passengers enddynamic
node -1 0 EN57-1542rb dynamic PKP\EN57_V1 EN57-1542RB 6BBII 0 nobody 0 15 Passengers enddynamic
endtrainset

Na marginesie, czy w kiblach "w realu" jest tez przeprowadzony kabel ogrzewania?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: RoboBatman w 20 Marca 2017, 19:19:24
@Tomnord15: nie potwierdzam tego błędu. U mnie EN57 zwykłe (nie serii 2000 ale one też) na exe 170319b działają w bez problemu i w porządku. Musisz mieć coś u siebie skopane-złe dobranie wartości sprzęgów albo coś nie halo w plikach.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 20 Marca 2017, 19:52:58
tmj: coś tam jest popsute, próbuje czasami używać TSubModel::RenderDL mimo że wybrane VBO.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Tomnord15 w 20 Marca 2017, 20:45:25
Musi być coś nie tak w plikach. Sprzęgi mam dobrze połączone na dodatek na Quarku mimo obsady headdriver po wybraniu EN57 -2000 nie ma składu wcale na scenerii. Wypakowałem pliki z paczki i patcha EN57 oraz EN57-2000 i dalej to samo. Postawię na nowo Maszynę i zobaczę co będzie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 20 Marca 2017, 20:49:02
tmj: coś tam jest popsute, próbuje czasami używać TSubModel::RenderDL mimo że wybrane VBO.
To tylko gwiazdy sa, bo nie chcialo mi sie dopisywac VBO dla jednego obiektu :)  Natomiast z faktycznych bledow to na VBO nie wyswietla animowanych drzwi w EZT, a chyba wczesniej wyswietlal, wiec na razie to sprawdzam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 20 Marca 2017, 21:00:41
Na marginesie, czy w kiblach "w realu" jest tez przeprowadzony kabel ogrzewania?

Tak, 3000V jest prowadzone zlaczem miedzy czlonami EZT.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: matek123 w 20 Marca 2017, 21:02:12
Tylko, czy w maszynie w EN57 powinniśmy dawać sprzęg ogrzewania, czy szynę WN?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 20 Marca 2017, 21:08:57
A jaki to problem, skoro dziala? Zgodnie z rzeczywistoscia jest i byc powinien. Oczywiscie miedzy ezetami nie :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 20 Marca 2017, 21:12:52
Potwierdzam błąd zgłoszony przez:
A jak się ma sprawa z EZT, bo wcalę nie mogę uruchomić kibelków. Załączam baterię, pantografy w górę, potem rozrząd i klapa, nie pokazuje w rozrządczym napięcia sieci wcale mimo że pantografy mam podniesione. Najnowsza wersja exe. Czy może ja robię coś źle? W logu czysto za to załączam errors.
AI potrafi ruszyć tylko tego kibla z miejsca. Nie mamy możliwości załączenia WS klawiszem M. Nawet po odpięciu AI mimo że kibel jedzie, nie mamy możliwości wpływu na jego sterowanie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 20 Marca 2017, 21:14:10
Ja już pisałem co zrobiłem wtedy i pomogło i działa jak trzeba, ale no trzeba zobaczyć co się stało.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 20 Marca 2017, 21:30:00
Ten wpis działał:node -1 0 EN57-2040ra dynamic pkp\en57-2000_v1 en57-2040_ra 6ba 0 headdriver 55 0 enddynamic
node -1 0 EN57-2040s dynamic pkp\en57-2000_v1 en57-2040_s 6bs 0 nobody 55 0 enddynamic
node -1 0 EN57-2040rb dynamic pkp\en57-2000_v1 en57-2040_rb 6bb 0 nobody 0 0 enddynamic
i przestał.node -1 0 EN57-1542ra dynamic pkp\en57_v1 en57-1542ra 6baii 0 headdriver 55 0 enddynamic
node -1 0 EN57-1542s dynamic pkp\en57_v1 en57-1542s 6bsii 0 nobody 55 0 enddynamic
node -1 0 EN57-1542rb dynamic pkp\en57_v1 en57-1542rb 6bbii 0 nobody 55 0 enddynamic
, ten też przestał. Sprawdzane na paczce tej postawionej 3 tygodnie temu i tej postawionej dzisiaj. Nie ma możliwości awarii plików t3d bo ich nie mam.

ED:
node -1 0 EN57-1542ra dynamic pkp\en57_v1 en57-1542ra 6baii 0 headdriver 183 0 enddynamic
node -1 0 EN57-1542s dynamic pkp\en57_v1 en57-1542s 6bsii 0 nobody 183 0 enddynamic
node -1 0 EN57-1542rb dynamic pkp\en57_v1 en57-1542rb 6bbii 0 nobody 0 0 enddynamic
Nic z tego, taki wpis też nie działa
Mamy uruchomienie baterii, narotnik, zbijamy czuwak i podnosimy patyki. Brak napięcia nie ma WSa. Zapuszczamy AI i ono odjeżdża...
Załącznik, brak napięcia po podniesieniu patyków.

ED:2
Ostatnia wersja exe z prawidłowym uruchamianiem kibli, jest z 20170315
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 20 Marca 2017, 22:10:41
Dane pokazywane w trybie debug zmienily sie troche, pokazuje on parametry najblizszego pojazdu/czlonu. Przejdz sie w strone czesci z patykami, i powinien pokazac napiecie na podniesionym pantografie (raportowanie stanu I jest na ten moment zakrzaczone)

Postawilem sobie ten zestaw ktory zglaszasz na TD, a takze pare innych i jeszcze ED72 dla pewnosci, i u mnie wszyskie chodza. Wskaznik WN w kabinie pokazuje poprawnie po podniesieniu pantografu, silniki i kompresor zalaczaja sie poprawnie, i wszystkie EZT jezdza normalnie. Instalowaliscie sobie jakies unoffy dla EZT albo cos? :x

Z innej beczki, dopisalem brakujacy kawalek podlaczania z powrotem VBO, powinno byc teraz kompletne (chociaz ciagle na byle jak)

Przyjrzalem sie tez programatorom, i wyszlo ze gryzly sie z czyms dziwnym co stary kod wyprawial w EZT -- pierwszy czlon nie byl skonfigurowany by kontrolowac wlasne swiatla, tylko swiatla modulu silnikowego, ktory swiatel w ogole nie ma. Nie wiem czy to jakas prehistoryczna zaszlosc, ale nie wyglada na to, by usuniecie powodowalo jakies efekty uboczne, wiec teraz czlony EZT sa pod tym wzgledem traktowane jak wszystko inne, i programator dziala na nich poprawnie.

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 20 Marca 2017, 22:14:35
Ostatnia wersja exe z prawidłowym uruchamianiem kibli, jest z 20170315. Od 16 mam źle.
ED:
Potwierdzam, że w trybie normalnym można uruchomić kibla, jest napięcie i pojechać. Tym niemniej chcieli byśmy jeździć tym w debug mode też. Gdyby to było tylko zakrzaczone UI, ale nie reaguje na sterowanie.
PS: Nie zauważyłem napięcia sieci w UI w trybie normalnym - potwierdzenie podniesienia patyka, ale to przy okazji. Cały czas jeździłem na Quarku i w piątek przestałem i masz...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 20 Marca 2017, 22:40:36
Nie obserwuje u siebie zadnej roznicy dzialania w trybie debug -- po wylaczeniu automatu moge uruchamic kibla bez zadnych problemow, i jezdzi on tak samo jak w trybie normalnym. Sprawdzilem dla pewnosci z livetraction w obu opcjach, ale jest tak samo.

Jesli nie moge u siebie zreprodukowac bledu, to raczej nie jestem w stanie go tez usunac. Czy te klopoty sa na jakims konkretnym scenariuszu, czy wszedzie? Czy to jest standardowa paczka calosciowa + patch, czy cos bylo modyfikowane?

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 20 Marca 2017, 22:43:24
Super! Dzięki za rozwiązanie tego problemu z programatorem! :D
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 20 Marca 2017, 22:50:21
Klopik odpala w debugu bez problemu. Asynchroniczny również. Programator mu działa jak należy. Przy okazji wyszło dziwactwo z hamulcem w członie rb. W ra ma wartości rzędu setek, w s wyzerowane a w rb...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Lorem w 20 Marca 2017, 22:51:54
Potiwerdzam problemy z debugmode, ale tylko jeśli uruchamia się symulator z tą opcją włączoną w Rainsted/ini. Jeśli uruchomić w trybie normalnym i potem włączyć debug Shift+Ctrl+F12, to wszystko zdaje się działać dobrze.
Przy debugmode włączonym od startu inaczej też działa załączanie baterii (test SHP wyłącza się sam po ok. sekundzie, lub dużo krócej w przypadku kibla), kamera startuje w innym miejscu, sieć trakcyjna jest jasnozielona, w przypadku kibli nie działa sterowanie drzwiami... nie wiem, co z tego jest zamierzone.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 20 Marca 2017, 22:54:31
Nic takiego nie mam. Przypominam, że w debugu włącza się na starcie AI i trzeba je wyłączyć albo będzie nam "pomagać".
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Lorem w 20 Marca 2017, 22:59:13
w debugu włącza się na starcie AI
Po wyłączeniu AI wcześniej wspomnianych "nieprawidłowości" nie stwierdza się.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 20 Marca 2017, 23:01:35
No to mamy chorobę dwubiegunową. Mnie to przypominasz? Wiem że trzeba odłączyć AI, ale nawet jak nam pomoże wystartować to i tak po jego wyłączeniu nie mamy sterowania. Ustawiam tryb debug w Rainsted bo mi bliżej niż do edycji ini i powinno działać jak dawnie. Przełom jest jak pisałem między 15 a 16 dniem marca. Jest ewidentnie inne działanie trybu debug mode w kiblach. Skoro ten tryb, jest to powinien działać tak jak normal, z wyłączeniem fizyki wykolejeń.
ED:
Postawiłem tego kibla na td, bo szybciej wczytuje. Po pierwsze w członie s mam napięcie i mogę załączyć wsa, wracam do ra i nie ma napięcia, nie ma jazdy. Po drugie, nie sądzicie, że od piątku zapomniałem jak się uruchamia kibla... Po trzecie potrafię go uruchomić w trybie normalnym. Po czwarte od szesnastego jest wyraźna zmiana zachowania procedury uruchamiania. Po piąte, jeśli nawet Ai uruchomi kibla i pojedzie za nas, to po przejęciu jednostki powinna być podatna na nasze zabiegi, a nie jest. Po szóste, wygląda na to, że AI siedzi w członie S, bo nie mając napięcia w członie Ra nie mogło by jechać. Po siódme nie mam więcej argumentów.
Wyłączenie AI w pierwszej sekundzie nic nie zmienia.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 20 Marca 2017, 23:17:46
Witam.
 U mnie również kibelki na najnowszej kompilacji exe C++ 32 bit, działają normalnie w obu trybach. Udaje się uruchomić, jechać, hamować. Drzwi otwierają się również. Sprawdzałem na TD ze składem 2 xEN57 w ukrotnieniu. 
Pozdrawiam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 20 Marca 2017, 23:32:00
Po pierwsze w członie s mam napięcie i mogę załączyć wsa, wracam do ra i nie ma napięcia, nie ma jazdy.
Zaraz zaraz, wyjasnijmy sobie cos. Po pierwsze, po co wychodzisz z ra zeby zalaczyc WS? Przelacznik jest w ra, i dziala "zdalnie" stamtad, tak dlugo jak podniesiony jest patyk. Po drugie, jak stwierdzasz brak napiecia w ra? Jesli na podstawie danych wyswietlanych przez UI, to na to nie patrz, bo tam podany jest stan tego konkretnego modulu w ktorym siedzisz, a napiecie "jest" w segmencie silnikowym, i stan tego napiecia pokazany na wskazniku na pulpicie, ponizej kontrolki czuwaka.

(nawiasem mowiac, AI nie siedzi w czlonie silnikowym tylko w sterujacym, tak jak i "ludzki" maszynista, na poziomie kodu jest z maszynista dosc wymienne)

Klopik odpala w debugu bez problemu. Asynchroniczny również. Programator mu działa jak należy. Przy okazji wyszło dziwactwo z hamulcem w członie rb. W ra ma wartości rzędu setek, w s wyzerowane a w rb...
Trudno powiedziec co tam sie dzieje, to moga byc dziwne wartosci w .fiz/mmd rozwalajace kalkulacje, albo brak inicjalizacji, albo cokolwiek innego. Raczej tego nie sprawdze jesli do tego potrzebne jest ganianie za jakimis prywatnymi unoffami, az tyle wolnego czasu to ja nie mam ;x
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 20 Marca 2017, 23:56:01
Napisałeś że UI pokazuje prawidłowe napięcie w silnikowym to poszedłem sprawdzić. Taka ciekawość, a jak zobaczyłem że jest to, z ciekawości wcisnąłem shift+M. To była czysta ciekawość i nic więcej. WS załączył się, także nastawnik kierunku, nie próbowałem odjechać.

W członie Ra nie pokazuje mi napięcia na UI, ale jeśli nawet pokazuje mi na voltomierzu, to WSa i tak załączyć nie mogę. nie ma WSa nie ma jazdy. Następnie odpalam na 170315 i mam wszystko jak poprzednio. Pewnie sam bym się wypruł wcześniej z tym, ale zająłem się wyświetlaniem u Atapiego a i niedziela też była do odpoczynku. To przegapiłem zmianę.
Najważniejsze, uruchomiłem kibla na Quarku i TD w trybie debug mode. Dziękuję za cierpliwość. Co do zmiany między 15 a 16 dniem marca, to prosiłbym ciebie @tmj, o sprawdzenie skąd się wzięły te różnice. Między postawieniem patyka do sieci i wciśnięciem WSa mija jakiś czas gdzie zapalają się lampki. Po za tym mam wrażenie że przejęcie kibla po AI jest teraz problematyczne. Ale to jeszcze powałkuję. Dzięki za cierpliwość.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 21 Marca 2017, 00:04:55
Co do zmiany między 15 a 16 dniem marca, to prosiłbym ciebie @tmj, o sprawdzenie skąd się wzięły te różnice. Między postawieniem patyka do sieci i wciśnięciem WSa mija jakiś czas gdzie zapalają się lampki.
Sek w tym ze przegladajac pobieznie, tam nie bylo specjalnie zmian, ktore moglyby miec tego typu efekt. Co do pauzy, nie wiem czy warto wspomniec, ale zwroc uwage ze po nacisnieciu shift + O podniesienie pantografu trwa dobrych kilka sekund, i proby wlaczania WS w tym czasie sa skazane na niepowodzenie. Dopiero gdy patyk sie podniesie (widac kiedy, bo budzi sie wtedy woltomierz WN na pulpicie) mozna zalaczyc WS, i to na EN57 nie zajmuje dlugo, jakies 0.5 sek. A potem juz idzie normalnie, przetwornica, sprezarka itp.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Lorem w 21 Marca 2017, 00:07:15
Mnie to przypominasz? Wiem że trzeba odłączyć AI
Myślę, że mnie. Bo faktycznie, wcześniej zgłoszone przeze mnie problemy były wyłącznie wynikiem tego, że z moimi działaniami intereferowało AI, o którego wyłączeniu nie pamiętałem.

Tak czy inaczej, na ostatnim exe wersja 64bit i świeżej, dzisiaj postawionej paczce użytkowej (e3d/dds) z patchem i zainstalowaną większością oficjalnych dodatków, nie mam żadnych problemów z obsługą EZT (poza ED72, która musi mieć podniesiony pantograf od strony obsadzonej kabiny, ale na Borlandowym exe też tak jest, z tego co teraz widzę). Niezależnie od tego, czy włączam z debugmode, czy bez, czy skład uruchamia AI, czy ja, czy przeujmujemy od siebie nawzajem sterowanie, wszystko działa. Także problem nie jest uniwersalny. Chyba że dotyczy jakiegoś konkretnego mmd, ale sprawdzałem składy podane w tym poście (http://eu07.pl/forum/index.php/topic,28159.msg446672.html#msg446672) i było ok.

(Co zabawne, z członu S też da się przeprowadzić niemal cały rozruch.)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 21 Marca 2017, 00:09:43
Trudno powiedziec co tam sie dzieje, to moga byc dziwne wartosci w .fiz/mmd rozwalajace kalkulacje, albo brak inicjalizacji, albo cokolwiek innego. Raczej tego nie sprawdze jesli do tego potrzebne jest ganianie za jakimis prywatnymi unoffami, az tyle wolnego czasu to ja nie mam ;x
Spoko, do tego i tak yB musiałby siąść, bo mam wrażenie, że hamulec nieco świruje. Dęba staje, poślizgi łapie. Musi to obejrzeć ktoś, mający ideę jak być powinno.

W ED72 trzeba ustawić sprzęg szyny WN między członami silnikowymi. We wszystkich ezt mających silniki w członach bez aktywnego pantografu trzeba tak czynić.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 21 Marca 2017, 00:18:42
Co do pauzy, nie wiem czy warto wspomniec, ale zwroc uwage ze po nacisnieciu shift + O podniesienie pantografu trwa dobrych kilka sekund, i proby wlaczania WS w tym czasie sa skazane na niepowodzenie.
Wytłumaczę się jak pierwszoklasista, Czekam aż woltomierz pokażę napięcie WN, dopiero włączam WS. Zresztą ta uwaga jest mało istotna, w końcu napięci jest i WS się włączy. Czekam też na uruchomienie sprężarki po przetwornicy w siódemce, bo tak trzeba.
Może zmęczony jestem, i ta różnica zrobiła wielkie zamieszanie. Jeszcze raz przepraszam za zamieszanie, dzięki za cierpliwość. Przejąłem pojazd od AI prawidłowo. 
ed2
To jeszcze dopowiem, że na exe 64 jest podobnie jak na 32. Stabilność jest duża, tylko to nieszczęsne kiblowate. Załącznik, uruchomione  i pojechane.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 21 Marca 2017, 08:40:18
Spoko, do tego i tak yB musiałby siąść, bo mam wrażenie, że hamulec nieco świruje. Dęba staje, poślizgi łapie. Musi to obejrzeć ktoś, mający ideę jak być powinno.
Witam.
  Co do hamulca, to gdy ciśnienie w cylindrach oscyluje w okolicach ok 0,4 MPa wpada rzeczywiście w poślizg, ale jest on dziwny gdyż skład zachowuje się jakby szyny były posmarowane smarem. Prędkość spada bardzo powoli, a klop sunie jak po lodzie. Dodatkowo, gdy mamy podczas hamowania nastawnik na pozycji jazdy, to w czlonie S koła obracają się jak oszalałe, jakby hamulec w nim nie działał. W Ra i Rb są przecież w tym czasie zablokowane zestawy. Ale generalnie tak jak pisałem wcześniej jechać kiblem można.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 21 Marca 2017, 12:19:39
Tak z ciekawosci, zobacz jakie sa wpisy masy i ladunku tego kibla dla poszczegolnych czlonow (zwlaszcza b) bo te gigantyczne liczby na zdjeciu Steele znikad sie nie wziely.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: koper w 21 Marca 2017, 14:57:22
Witam. Mam taki problem. Gdy chcę odpalić na nowym exe to pokazuję się ekran ładowania a następnie mnie wywala. Co może być problemem? W załączniku plik log.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 21 Marca 2017, 15:04:12
Wyglada na to, ze wylatuje przy starcie Pythona. Czy to jest wersja x86, czy x64? x64 wymaga w katalogu symulatora folderu python64 ktory jest wlaczony do paczki bibliotek do pobrania z http://eu07.pl/userfiles/24014/bugs-eu07cplusplus64_libraries.rar

(nawiasem mowiac, ten log jest chyba z troche starszej wersji exe. Jesli to nie problem, testuj raczej na wersji najnowszej, do pobrania z zalacznika w http://eu07.pl/forum/index.php/topic,28920.msg445222.html#msg445222
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 22 Marca 2017, 09:21:09
Ja powoli walczę z tabelką. Tylko tak wrzucam narazie info, że w temacie się coś dzieje. Choć czasami mnie bierze jak widzę jak to jest skomplikowane.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 22 Marca 2017, 11:20:54
To moze szybciej by wyszlo od razu przeprojektowac jak zorganizowane sa tory zastapic eventy czyms normalnym, skoro i tak trzeba to zrobic ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 22 Marca 2017, 13:07:45
Ja to już rozdzielam w tej chwili tak, żeby dało się to zrobić. Bardziej chodzi o to jak potem dane z tabelki są używane dalej (na co sposób przekazywania danych do tabelki nie ma wpływu).
Powiem, że troszkę utrudnia mi pracę fakt, że w którymś commicie usunąłeś projekt ale zostawiłeś solucję.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 22 Marca 2017, 14:47:14
Sorry, projekt wycialem zeby nie bylo bezustannego nadpisywania go sobie nawzajem przy commitach :) dolaczam biezaca wersje, jesli sie do czegos przyda.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 22 Marca 2017, 19:45:47
Ja tam już mam na stałe wrzucone w stasha i on sobie nadpisuje tylko zmiany w katalogach do których buduje. No i wersję kompilatora.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 22 Marca 2017, 21:39:40
Przy okazji grzebania w kodzie rzucil mi sie w oczy komentarz przy swiatlach punktowych...
// dorobić aureolę!
No to dorobilem. Efekt nawet ok, ale ze kalkulacje robione byly z wykorzystaniem glGet() to wydajnosc na wiekszych stacjach spadla o jakies 25% co, biorac pod uwage ze efekt nie jest az tak dobry, bylo zdecydowanie zbyt wysoka cena. Podpialem wiec skonczone "wirtualne matryce" dla openGL, zeby sie pozbyc odwolan do glGet() i teraz zamiast spadku o 25% mamy jakas ~10% poprawe wydajnosci (bo odciazylo to tez stary kod rysujacy punkty swietle) przy wlaczonych aureolach. Efektow ubocznych byc nie powinno, ale wiadomo jak to jest w praktyce :s

tl,dr: powinno byc troche szybciej, i troche ladniej.

(aureole uzywaja tekstury nazwanej lightglare i umieszczonej w katalogu textures/fx Na ta chwile exe nie pozwala definiowac tekstur dla swiatel punktowych, ani wymiarow aureoli, kiedys moze sie to zmieni)

edit:
aha, aureole uzywaja definicji koloru swiatla punktowego, w rezultacie swiatla semaforow zrobily sie bardziej zolte niz pomaranczowe, bo taki jest kolor zdefiniowany dla punktow w tych komorach. Ktos sie bedzie musial poswiecic i je wreszcie poporawiac :d
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 22 Marca 2017, 22:59:42
Na TD mam taki widok, na Kaliskiej i Bałtyku jest ładnie. Widoczność tej zjawy zależy od kąta patrzenia. W każdym razie z kabiny widać. Na razie taki efekt jest tylko na TD, jeśli gdzieś jeszcze znajdę, dopiszę.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 22 Marca 2017, 23:02:53
Na TD mam taki widok, na Kaliskiej i Bałtyku jest ładnie. Widoczność tej zjawy zależy od kąta patrzenia. W każdym razie z kabiny widać. Na razie taki efekt jest tylko na TD, jeśli gdzieś jeszcze znajdę, dopiszę.
Ten efekt pojawia sie, gdy exe nie uda sie zaladowac tekstury aureoli. Zobacz czy cos tam nie stalo sie z plikiem w folderze textures/fx bo normalnie nie powinno sie to zdarzyc :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 22 Marca 2017, 23:04:35
Ale czemu one nie sa zrobione na glPoint()? glPoint() mozna kontrolowac, rozmiar, zanikanie i inne i moze byc ich s dziesiatki tysiecy a FPS nie spadnie. Wiem bo snieg mialem na trzech typach obiektow do wyboru - glTriangle(), glLine i glPoint i ten ostatni pozwalal nawet na kilka set tysiecy platkow przy malym spadku FPS.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 22 Marca 2017, 23:13:43
Nie wiem jak na to wpadłeś, bo napisałem że w Bałtyku i Kaliskiej jest ok. Miałeś rację, wypakowałem do dwóch paczek i tam gdzie odpaliłem TD musiałem źle upuścić rozpakowane archiwum. Oczywiście jest wszędzie dobrze.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 22 Marca 2017, 23:42:02
Ale czemu one nie sa zrobione na glPoint()? glPoint() mozna kontrolowac, rozmiar, zanikanie i inne i moze byc ich s dziesiatki tysiecy a FPS nie spadnie. Wiem bo snieg mialem na trzech typach obiektow do wyboru - glTriangle(), glLine i glPoint i ten ostatni pozwalal nawet na kilka set tysiecy platkow przy malym spadku FPS.
- nie trzeba bawic sie z recznym skalowaniem wymiarow na podstawie odleglosci
- bardziej przyjazne dla starego sprzetu, nie wiem jak wyglada teraz obsluga 'punktow' wielkosci 200-300 i wiecej pikseli, ale kiedys raczej nie bylo z tym rozowo
- widocznosc point sprites jest okreslana na podstawie widocznosci punktu centralnego. czyli np w ujeciu jak na zalaczniku aureola po prawej zostalaby obcieta
- spadek fps spowodowany byl obliczaniem punktu centralnego przez wyciaganie matrycy modelview dla kazdego punktu (co jest swoja droga kiepskim rozwiazaniem, ale w kodzie nie ma chyba kalkulacji pozycji poszczegolnych submodeli, ani w ogole danych dla poszczegolnych egzemplarzy, wszystko jest robione w oparciu o pozycje modelu bazowego i matrix push/pop 'w locie' dla poszczegolnych elementow) Czyli samo zastosowanie punktow nie zmieniloby wydajnosci -- co zreszta latwo sprawdzic, podstawowe spotlights to sa glPoints wlasnie, i przy starym kodzie kalkulacje ich pozycji mialo zauwazalny efekt na ogolnej wydajnosc, nawet gdy punktow nie bylo wiecej niz 50-100 :d

Natomiast do rzeczy takich jak snieg czy inne tego typu czasteczki to jak najbardziej. Na upartego aureole tez mozna pozniej przerobic praktycznie w calosci na shader, jak juz beda.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 22 Marca 2017, 23:47:52
Oj, będzie poprawek w modelach, będzie. Kto puścił 163a z freespotem w końcówkach w takim kolorku?
Nie ma błędu/ficzeru z wolno rozpalającymi się aureolami, dającymi prawie niewidoczne światło u Q.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 22 Marca 2017, 23:51:26
Jak to teraz masz zrobione, w sensie w ktorym miejscu jest renderowanie quada(?) z aurola i co robi funkcja Get() o ktorej mowisz?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 23 Marca 2017, 00:15:34
Rendering jest wstawiony do funkcji rysujacej przezroczyste submodele, taki symetryczny odpowiednik dla kodu rysujacego 'nieprzezroczyste' freespoty. glGet uzywany byl do wyciagania danych o biezacej konfiguracji matryc, w ten sposob:
                matrix4x4 modelview;
                ::glGetDoublev( GL_MODELVIEW_MATRIX, modelview.getArray() );
i to jest dosc kosztowne, bo zeby karta graficzna mogla dostarczyc tych danych to przerywane jest renderowanie (zeby ustalic stan itp)

wrzuce troche pozniej uaktualnienie na githuba to sobie bedziesz mogl szczegoly obejrzec~
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 23 Marca 2017, 06:42:03
No to ciekawe czy przejście na shadery też przyniesie wzrost wydajności.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 23 Marca 2017, 07:12:51
Aureole są OK (dobra, są SUPER), chociaż drobna uwaga: odnoszę wrażenie, że anty-aliasing się jakby zepsuł trochę, ale dziwnie, bo widać to wyłącznie na 2 elementach - poziomych elementach trakcji (no na tych co druty są podwieszone) i na wskazówkach od haslera w ED72.

W niektórych wersjach exe wokół tych wskazówek pojawia się biała obwódka wyglądająca super kijowo. W tej przykładowo jest.

Co do nowego interfejsu to jest miód i poziomki. O to chodziło. To wygląda, że zostały do zrobienia już tylko te światła na shaderach i hamulce od aut.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 23 Marca 2017, 08:49:08
Obwódka to efekt lipnej tekstury filtrowanej anizotropowo. Kiedyś załatwimy to globalnie automatem, tylko ktoś musi siąść i go zaprogramować.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: jakubg1 w 23 Marca 2017, 11:37:17
Znalazłem 2 błędy:
1. Przez drzwi od wewnątrz w EN57-20xx nie widać sieci trakcyjnej, cieni i niektórych lamp.
2. Aureola gryzie się z lampami.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 23 Marca 2017, 11:55:41
Gdzie mam szukać tych błędów? Sceneria jaka (Quark?) i ewentualne przybliżona lokalizacja.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: jakubg1 w 23 Marca 2017, 11:57:22
Tak, Quark. Błąd z kiblem to przystanek Dejawy Kopalnia, chociaż występuje wszędzie i na każdej scenerii. Drugi błąd to Koniewice - tarcza manewrowa od strony szlaku jednotorowego.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 23 Marca 2017, 12:16:19
W obu przypadkach o sortowanie przezroczystości chodzi. Problem stary jak grafika 3d.
Tylko dlaczego drutów nie widać?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 23 Marca 2017, 12:32:01
Tu trzeba dopowiedzieć, że nie tylko kibel ma ten błąd, także siódemka posiada problemy z przezroczystościami okienek maszynowni. Problem nie dotyczy exe C++, występuje także na exe borlandowym z PC. Jeśli chodzi o karzełki. cóż oświetlenie terenu lampami w Quarku jest żenujące, Te tekstury rzucone na grunt symulujące oświetlony teren gryzą się z innymi przezroczystościami. Też nie jest to problem C++. Efekt jest widoczny tylko w nocnym wizerunku scenerii.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 23 Marca 2017, 12:47:27
W przypadku EU07 bledem jest to, ze sciana wnetrza low poly zwyczajnie nie ma chyba wycietego srodkowego okna po prawej stronie. Wiec patrzac z lewej na prawo widzisz lita sciane. Z prawej na lewo widac jak trzeba, bo tam okno zostalo wyciete.

edit: co do przedsionka en57-2000 zaslaniajacego elementy przezroczyste, patrzac na szybko, to bierze sie z chyba tego ze te przedsionki sa wspawane w pudlo i renderowane razem z pudlem, w trakcie rysowania obiektow dynamicznych, a nie jako "kabina na samym koncu) Gdyby wszystko bylo zaaranzowane poprawnie to nie przeszkadzaloby to specjalnie -- obiekty przezroczyste powinny byc renderowane od najdalszych do najblizszych -- ale zdaje sie exe robi to dosc srednio, i np druty itp rysowane sa na koncu. Czyli w tym wypadku po tym, jak narysowane zostalo pudlo z przedsionkami, a na tym etapie karta graficzna stwierdza ze nie warto rysowac drutow ktore z jej punktu widzenia "zasloniete" sa sciana przedsionka ktory z jej punktu widzenia przezroczysty nie jest.

edit2: do pewnego stopnia blad drzwi mozna usunac, poprawiajac maske alfa tekstury pojazdu -- na etapie obiektow z przezroczystosciami exe traktuje jako "nieistniejace" wszystko oteksturowane z wartoscia kanalu alpha 10/255 lub mniejsza. Szyby przedsionka EN57 sa minimalnie "mniej przezroczyste" i jako takie sa renderowane.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 23 Marca 2017, 15:57:39
Trochę informacji z tego w czym grzebię.
Przeniosłem operacje na stosie macierzy opengl na macierze glm przekazywane w argumentach metod. @tmj, możesz zobaczyć czy coś z tego wykorzystasz https://github.com/Milek7/maszyna/commit/b92a1e58ae9b91713f789b8be3f58b86198b87a5 (póki co tylko VBO działa, ale przenieść to na DL to kilka linijek)

A w kwestii shaderów, popatrzyłem na specyfikację GLSL i dowiedziałem się, że faktycznie są tam zdefiniowane uniformy na wartości przekazywane przez fixed pipeline. Więc na dobrą sprawę to oświetlenie blinnphong da się zrobić na shaderach praktycznie bez żadnych zmian w kodzie, działające zarówno na DL i VBO. No ale to już dowiedziałem się po tym jak zrobiłem wstępnie działające shadery na własnych uniformach. Ze względu na to że funkcjonalności fixed pipeline i tak są zdeprecjonowane w nowym opengl to i tak przydało by się kontynuować te prace na własnych uniformach, wywalić DL i przenieść na opengl 3.2 core profile. Jednak z tego powodu że wymaga to jeszcze troche dopieszczenia, plan jest taki: robię dzisiaj oświetlenie shaderem kompatybilnym z opengl2 i starym kodem DL/VBO, a później na spokojnie przenosimy wszystko na 3.2 core profile i własne uniformy.

Jeszcze ze zmian w build systemie: przygotowałem paczkę z zależnościami do budowania które nie mają własnego oficjalnego windowsowego instalatora oraz dołączyłem skrypt uruchamiający cmake z odpowiednimi ścieżkami w owej paczce. Czyli żeby zbudować moje repo trzeba: zainstalować visuala, cmake i pythona, sklonować repo, i builds/cmake_win32/64.bat które ściągnie paczkę z pozostałymi zależnościami i wygeneruje pliki projektu vs.
Korzystając z automatyzacji tego skonfigurowałem CI na AppVeyor https://ci.appveyor.com/project/Milek7/maszyna .
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: RoboBatman w 23 Marca 2017, 16:58:18
@tmj: właśnie jestem po pierwszych prowizorycznych testach exe z zaimplementowaną aureolą. Mam jedną wątpliwość co do tego ficzeru. O ile jeszcze w nocy taka aureola na semaforach się pojawia i można to zauważyć, to w czasie dnia kiedy jest słońce lub jest widoczność dzienna nawet w czasie pochmurnych dni, mam wątpliwość, żeby taki ficzer w czasie dnia stosować bo nigdy takowej aureoli w czasie dnia na semaforach (nawet nowych) nie zauważyłem. Czy dałoby radę rozdzielić w exe, od kiedy do kiedy ( w konkretnych godzinach) ta aureola ma się pojawiać? Sam efekt w nocy mi się bardzo podoba-jak najbardziej na plus. Zaznaczam, iż jest to jest tylko propozycja a nie krytyka. Dziękuję z góry za odpowiedź na moją kwestię.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 23 Marca 2017, 17:56:12
Trochę informacji z tego w czym grzebię.
Przeniosłem operacje na stosie macierzy opengl na macierze glm przekazywane w argumentach metod. @tmj, możesz zobaczyć czy coś z tego wykorzystasz https://github.com/Milek7/maszyna/commit/b92a1e58ae9b91713f789b8be3f58b86198b87a5 (póki co tylko VBO działa, ale przenieść to na DL to kilka linijek)
Widzialem :) na razie ich nie ruszam, bo chce przeniesc reszte funkcji rysujacych do modulu renderujacego (tak jak jest to na razie zrobione dla czesci DL), a jak juz tam beda to renderer bedzie mial te macierze "pod reka", bez potrzeby podawania ich dla kazdej funkcji z osobna. Ulatwi to tez spiecie razem funkcji renderujacych, bo tak z 75% powtarza sie w obu wariantach, a roznice sa glownie na poziomie skad sub-modele czerpia dane geometrii (a to juz mozna zalatwic czyms w stylu ogolnej klasy bufora danych, specjalizowanej dla VBO i DL) No i latwiejsza bedzie konfiguracja renderowania w zaleznosci od celu (kolor, shadowmaps, item picking itd)

Cytuj
Jednak z tego powodu że wymaga to jeszcze troche dopieszczenia, plan jest taki: robię dzisiaj oświetlenie shaderem kompatybilnym z opengl2 i starym kodem DL/VBO, a później na spokojnie przenosimy wszystko na 3.2 core profile i własne uniformy.
W sumie jak juz robiles na wlasnych uniformach to mozna bylo jechac na tym dalej, ale ok, lepsze oswietlenie szybciej tez nie zaszkodzi ;)

Czy dałoby radę rozdzielić w exe, od kiedy do kiedy ( w konkretnych godzinach) ta aureola ma się pojawiać? Sam efekt w nocy mi się bardzo podoba-jak najbardziej na plus. Zaznaczam, iż jest to jest tylko propozycja a nie krytyka. Dziękuję z góry za odpowiedź na moją kwestię.
Mozna zrobic to tak samo jak sa w danym momencie robione swiatla, tzn sila jest modyfikowana przez ogolny poziom oswietlenia generowany przez slonce i niebo. Wstawilem to do dzisiejszego uaktualnienia, prosze sobie porownac i zdecydowac, ktora opcja lepsza :d
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 23 Marca 2017, 18:41:08
float fNearAttenStart;
float fNearAttenEnd;
bool bUseNearAtten; // te 3 zmienne okreslaja rysowanie aureoli wokol zrodla swiatla
int iFarAttenDecay; // ta zmienna okresla typ zaniku natezenia swiatla (0:brak, 1,2: potega 1/R)
float fFarDecayRadius; // normalizacja j.w.
float fCosFalloffAngle; // cosinus kąta stożka pod którym widać światło
float fCosHotspotAngle; // cosinus kąta stożka pod którym widać aureolę i zwiększone natężenie światła
Takie mamy parametry dla freespota. Z tego co widzę, fCosFalloffAngle wpływa na krycie flary, ale na krycie wpływa też odległość od źródła, a tego w kodzie nie umiem znaleźć. Możesz rozpisać jak to teraz działa? Warto by użyć parametrów ile się da, skoro i tak są w modelu. Myślę nad wywaleniem skaczących billboardów i gwiazdki na rzecz tego, tylko trzeba przemyśleć jak wyświetlać flarę freespota by ładnie wyglądała dla różnych zastosowań. Nie mam teraz głowy do wymyślania konkretnego algorytmu niestety, ale jak nikt nie podchwyci, to kiedyś pewnie mi się zachce. :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 23 Marca 2017, 19:30:10
Na ta chwile tak swiatla freespot jak i aureole uzywaja tylko parametrow fCosFalloffAngle i fCosHotspotAngle -- swiatlo jest widoczne gdy obserwator znajduje sie 'wewnatrz' stozka o kacie zdefiniowanym przez fCosFalloffAngle (w stopniach, zazwyczaj jest to wartosc ~45 stopni od osi obiektu) W 'zewnetrznej' czesci tego stozka nastepuje stopniowe zwiekszenie sily swiatla, od 0 do max. Standardowo ta strefa jest bardzo waska, jakies 2-3 stopnie, wiec swiatlo punktowe pojawia sie i znika niemal natychmiast.

Aureola jest generowana podobnie, z tym ze jej sila rosnie stopniowo miedzy zewnetrzna powierzchnia stozka widocznosci i osia srodka, tak ze jej pojawienie sie i znikanie jest bardziej stopniowe.

Jesli jest zapotrzebowanie, mozna dodatkowo podpiac pozostale parametry (sila dodatkowo zalezna od odleglosci obserwatora, co do pozostalych to nie wiem jak mialy byc uzywane, w starym kodzie wystepuja tylko raz, modyfikujac zakres widzialnosci, i jest to zakomentowane) z tym ze nie wiem czy zdefiniowane wartosci domyslne beda sensowne, bo chyba nigdy nie byly wprowadzone/testowane. Co do billboardow i gwiazd to zostawilbym je jak sa, bo maja nieco inne funkcje i mozliwosci (billboards nie znikaja w zaleznosci od kata i pozwalaja zdefiniowac inna teksture, a aureole dla "gwiazd" i tym podobnych grup punktow bylyby chyba przegieciem :)

Przy okazji, w ostanim uaktualnieniu przy okazji porzadkow wkradl sie blad, mogacy prowadzic to wysypu przy logowaniu niektorych eventow. W zalaczniku poprawka.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 23 Marca 2017, 19:38:52
Chodzi mi tylko o poświatę latarni. Teraz są tam 3 fazy billboardów i punkt świetlny wokólny (star). Można to zastąpić freespotem o szerokim kącie. By uzyskać podobny efekt, trzeba by dodać zanik i skalowanie flary w funkcji odległości. I to w obie strony. Dla małego dystansu mały quad o wysokiej alfie, skalujący się liniowo wraz z odległością, ale z ekstremum krycia blisko źródła...  Jest tam coś, pod co idzie podpiąć różne tryby działania freespota. Trzeba to przemyśleć, poeksperymentować i zobaczyć jak by to wyglądało. Może spokojnie poczekać w obecnej formie aż nie będę miał systemu wspierającego VS i sam się z tym pobawię.
Obecnej flarze zmieniłbym tylko teksturę na większy placek z krótszymi promieniami, co wymusiłoby zmniejszenie rozmiaru quada. Gołym okiem nigdy takich promieni nie doświadczysz.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 23 Marca 2017, 20:06:53
No golym okiem to w ogole poswiaty raczej nie doswiadczysz, bo to artefakt soczewek uzytych w aparatach itp ;)  Akurat takie byly na zdjeciach sygnalizatorow ktore znalazlem, o w miare dobrej jakosci, ale jesli ktos chce to zmienic to nie problem, wystaczy pobawic sie tekstura w katalogu textures/fx (ksztalt poswiaty jest w alpha channel)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 23 Marca 2017, 20:23:33
Na poprzedniej kompilacji nie odpaliłem żadnego Bałtyku, po kompletnym załadowaniu zdychał. Nie zdążyłem zgłosić. Teraz jest dobrze.
Cytuj
Obecnej flarze zmieniłbym tylko teksturę na większy placek z krótszymi promieniami, co wymusiłoby zmniejszenie rozmiaru quada. Gołym okiem nigdy takich promieni nie doświadczysz.
Teraz wygląda jakby zdjęcie robione było przez filtr na obiektywie używany do takich efektów. Ograniczenie w dzień wydaje się trafione, z tym należałoby rozważyć jak to wygląda w bardzo mglistą i wilgotną pogodę. Mam jeszcze uwagę do latarni, z pewnej odległości poświata wyłazi także przez górą powierzchnię obudowy, co jest dość nienaturalne. Postaram się pokazać screen. To nie jest krytyka, jak napisał @Stele, jak na początek jest zajefajnie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: RoboBatman w 23 Marca 2017, 20:46:10
Przy okazji testowania exe 170323b, wyczaiłem następny błąd/niedopatrzenie (nieodpowiednie skreślić). Podczas testowania aureoli na exe 170323b od @tmj, z racji tego, że korci mnie czasami potestować inne rzeczy na nowym exe, postanowiłem również zobaczyć podświetlone kabiny/kabinę (w zależności od sytuacji) widać również na zewnątrz. Owszem widać. Problem jest tego typu, że w rzeczonej EU07-1512 ( w reszcie EU07 podejrzewam również) zauważyłem błąd tego typu, iż gdy zapalam światło w kabinie numer 1, to wychodząc na zewnątrz, świecą się światła w obydwu kabinach i obydwie kabiny są podświetlone choć dałem podświetlenie tylko do jednej (do kabiny numer 1). Podgląd sytuacji zapodałem na obrazku "kabiny". Nie wiem czy problem leży po stronie exe czy po stronie modelu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 23 Marca 2017, 20:52:52
Nie wiem czy problem leży po stronie exe czy po stronie modelu.
Kombinacja obu czynnikow -- exe na ta chwile aplikuje oswietlenie dla calego modelu low poly, a dla wprowadzenia oswietlenia indywidualnych czesci, model low poly musialby zostac na takie submodele podzielony (z odpowiednimi nazwami dla kazdej czesci) Troche dyskusji na ten temat bylo w watku na bugtrackerze, nt. oswietlenia wnetrz, ale ktos musi sie poswiecic i zrobic model 3d na ktorym mozna testowac zmiany wprowadzane do exe, inaczej to jest praca na slepo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 23 Marca 2017, 21:23:01
W załączniku obrazek o którym wspominałem, widoczne z kabiny świetliste bańki. Od góry należałoby je ograniczyć. Widać z określonych odległości i kątów ustawienia kamery. Można by poprawić. Widoczność poświaty w dzień poprawiona, załącznik. Ponowię pytanie, czy można uzależnić od wpisów atmo? W nocy wygląda całkiem fajnie. Można zrobić ten placek o którym pisał Stele.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 23 Marca 2017, 22:03:03
Jest coś o czym należy wiedzieć, żeby na nowych exe wygenerować sobie plik e3d terenu scenerii? Póki co program się sypie (crashdump w załączeniu), ostatni wpis w logu "saving e3d model..".
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 23 Marca 2017, 22:04:02
należałoby rozważyć jak to wygląda w bardzo mglistą i wilgotną pogodę.
To samo można by zrobić dla reflektorów, jeśli nie ma z tym dużo roboty, tzn. we mgle dodać widoczne smugi światła dla poszczególnych lamp: https://youtu.be/xULWZx6JzyA Wtedy też przyciemnienie reflektorów nabiera większego sensu, bo zmniejsza te smugi i poprawia widoczność w miejscach oświetlonych latarniami: https://youtu.be/6pDz_uFYDEY?t=23s
A tutaj macie wygląd sygnalizatorów we mgle: https://youtu.be/sYtI1wT2VuE?t=36s, https://youtu.be/sYtI1wT2VuE?t=1m21s
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 23 Marca 2017, 22:10:10
Jest coś o czym należy wiedzieć, żeby na nowych exe wygenerować sobie plik e3d terenu scenerii? Póki co program się sypie (crashdump w załączeniu), ostatni wpis w logu "saving e3d model..".
Na jakiej scenerii to można przetestować?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 23 Marca 2017, 22:23:47
Paczkowe Drawinowo ma teren w e3d i scm źródłowy. Opisy jak to ustawić na wiki Ra.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 23 Marca 2017, 22:52:03
W załączniku obrazek o którym wspominałem, widoczne z kabiny świetliste bańki. Od góry należałoby je ograniczyć. Widać z określonych odległości i kątów ustawienia kamery.
Te banki to ktos tak po prostu narysowal okragle na teksturze, wiec beda wystawac ponad cienki prostokat obudowy bo to sie zwyczajnie geometrycznie nie miesci, troche jak logo Londynskiego metra. Trzeba zaladowac do Photoshopa albo gimpa i wymazac gorna czesc na plasko, exe nie ma tu raczej nic do rzeczy :)

edit:
Na jakiej scenerii to można przetestować?
tam wylot jest na
sn_utils::ls_int32(s, (int32_t)get_container_pos(transforms, *fMatrix));
w TSubModel::serialize() prawdopodobnie dlatego ze fMatrix ma wartosc null.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 23 Marca 2017, 22:53:01
U mnie paczkowe Drawinowo się odpala, na wersji 32 bitowej bez problemu.
Natomiast chyba zrobił się kłopot z wpisami atmo. Nie ma mgły, i mimo wpisu na 50 metrów, zakres widzialności jest maksymalny jak na screenie. Zwierzyniec ED72. Wyszło jak chciałem poświatę semków ocenić we mgle. Na borlandowym exe wpis działa. A z bańkami sam spróbuje.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 23 Marca 2017, 23:03:09
No teraz lights i atmo nie działają nijak, bo dynamiczny skybox je zastępuje. Oprócz wpływu na mgłę, jeszcze atmo mogłoby kontrolować nasycenie kolorów gradientu czaszy by stonować bardziej pochmurne pogody. Łudzę się, że ktoś zrobi inne chmurki na alfie kiedyś. Ja próbowałem jeszcze cirrusy jakieś, ale marnie wyszły i nie wydawałem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 23 Marca 2017, 23:31:20
Natomiast chyba zrobił się kłopot z wpisami atmo. Nie ma mgły, i mimo wpisu na 50 metrów, zakres widzialności jest maksymalny jak na screenie. Zwierzyniec ED72. Wyszło jak chciałem poświatę semków ocenić we mgle. Na borlandowym exe wpis działa. A z bańkami sam spróbuje.
Ten scenariusz nie ma wpisu daylight, wiec symulator przyjmuje wartosc domyslna (ustaw dzien zgodny z kalendarzem komputera) a ze idzie wiosna, to o 18:30 jeszcze jest w miare widno. W styczniu-lutym to sie tak nie rzucalo w oczy, bo wtedy juz bylo ciemno :)

Wyglada na to ze mgla sie faktycznie zgubila przy reorganizacji ustawienia parametrow (tzn byla, ale z parametrami domyslnymi) Bedzie poprawiona w nastepnym uaktualnieniu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Lorem w 24 Marca 2017, 14:10:39
Wysyp na scenariuszu linia61_towarowy1, wystarczy trochę polatać po scenerii. Logi i crashdump w załącznikach.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 24 Marca 2017, 22:32:34
@Milek7 moglbys wrzucic gdzies pliki shaderow jak znajdziesz chwile? Bo bez nich twoje nowe exe wysypuje sie na samym starcie ;/
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 24 Marca 2017, 22:33:32
"pliki z shaderami wypakować do katalogu z maszyną: https://milek7.pl/.stuff/eu07exe/fixedpipeline24.zip"
tu są, coś pominąłem?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 24 Marca 2017, 22:34:15
Poradziłem sobie. Exe z shaderami wygląda jak w załącznikach.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 24 Marca 2017, 22:36:38
"pliki z shaderami wypakować do katalogu z maszyną: https://milek7.pl/.stuff/eu07exe/fixedpipeline24.zip"
tu są, coś pominąłem?
Nie, to raczej ja przegapilem dodatek to watku info, zauwazylem tylko nowy push na githubie I poszedlem do appveyora po build :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 24 Marca 2017, 22:51:57
Mimo pierwszej w nocy nie ciemnieje niebo. Ale robota jest pierwszorzędna. Da się jeszcze to optymalizować pod względem wydajności?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 24 Marca 2017, 22:54:50
To jest chyba statyczny podklad a nie skydome_clouds wiec ono faktycznie jest stale. Zmien wpis sky w scn i powinno byc dobrze.

Nawiasem mowiac swiatl slonca jest uwzgledniane nawet gdy jest ono ponizej horyzontu. W nocy widac taka cienka smuge :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 24 Marca 2017, 22:58:12
Dzis juz mam cisze nocna, zamknalem zabawki w szafie. Ale jutrzejsza noc bedzie nieprzespana. Tyle powiem ze swaital lokomotywy sa rewelacyjne. To taka subiektywna moja ocena.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 24 Marca 2017, 23:36:53
Poradziłem sobie. Exe z shaderami wygląda jak w załącznikach.
A ja nie mam tyle szczęścia co Ty :-( U mnie wygląda to tak: Obraz upstrzony migającą kaszką z pikseli. Ktoś coś wie, co nie tak?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 24 Marca 2017, 23:41:51
Prawie działa ;) Światła w kabinie nie palą, i po wyjściu na zewnątrz zauważyłem dziwną smugę światła ciągnącą się po horyzont i zależną od tego gdzie patrzę. Jakby trochę poruszała się z kamerą. Na światłach z aureolami są jakieś czarne plamki w środku. Na linii 053 noc zauważyłem mocne trzęsienie się kabiny i obrazu za oknem, nawet po włączeniu pauzy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 25 Marca 2017, 00:03:07
@CX MANIAK: WTF. nie mam pojęcia :(
@HTD: na światła w kabinie popatrzę później. Ta smuga to po prostu specular na trawie. Nie ma w modelach wpisanego dobrego specular, więc właczyłem na stałe żeby było widać że jest :p. Jakieś trzęsienia to na później, niezwiązane z shaderami.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Marca 2017, 02:12:46
W dzisiejszym uaktualnieniu nie ma niestety tak intrygujacych nowosci jak shadery ;)

- poprawiony brak uwzglednienia parametrow mgly. Nawiasem mowiac, po wprowadzeniu poprawki teoretycznie mozliwe byloby modyfikowanie parametrow w trakcie scenariusza, ale nie wiem czy cos w tym kierunku bylo robione. Tzn chyba Q dodawal cos takiego w swoich exe, ale czy to sie przyjelo, w postaci eventu albo czegos?

- a propos niedawnej dyskusji poeksperymentowalem troche z wyswietlaniem swiatel punktowych; ich wielkosc jest teraz modyfikowana przez odleglosc od obserwatora. Czyli swiatla umieszczone daleko beda troche mniejsze niz dotychczas. Oprocz tego jasnosc w nieco wiekszym stopniu zalezy od kata, pod jakim patrzymy na swiatlo

- z rzeczy niewidocznych (o ile cos sie nie spi...tolilo) to postepujaca unifikacja procedur renderujacych grafike, czyli zamiast dwoch odrebnych, podobnych funkcji (wskutek wprowadzania zmian tylko do jednej albo drugiej) mamy po czesci pojedyncze funkcje z minimalnymi roznicami tam, gdzie konieczne. Co ulatwia ogarniecie calego interesu na dluzsza mete.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 25 Marca 2017, 06:41:06
Nu, ng będzie jeszcze do poprawy. Najpierw masakryczne migotanie i ląduje w takiej pozycji. Ponadto jak przekręcę kamerę to trawa robi się czerwona. Integra Intela iCore gen 4.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 25 Marca 2017, 10:18:17
Nu, ng będzie jeszcze do poprawy. Najpierw masakryczne migotanie i ląduje w takiej pozycji. Ponadto jak przekręcę kamerę to trawa robi się czerwona. Integra Intela iCore gen 4.
Ale ja tam nic nie ruszałem w macierzach..

Zaczynam się obawiać że ten mix fixed pipeline w shaderach jest na tyle rzadki że po prostu są bugi w sterownikach :(

edit: możesz sprawdzić czy VBO/DL coś zmienia?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 25 Marca 2017, 11:40:05
Shadery od @Milek7: Wstępnie mogę napisać, u mnie odpala się prawidłowo. Nie mam różnicy między VBO i DL. Nie mam efektu jak u @CX Maniak. Wyświetlanie jest ładne, trochę inne niż jesteśmy przyzwyczajeni. Światła reflektorów lokomotywy ładnie oświetlają a smuga nie znika całymi trójkątami. Jak to bywa coś za coś. Na tej samej paczce różnica FPS na exe od @tmj a @Milek7 jest 3:1. Na Stacji Łódź Kaliska na starcie w kabinie mam 45 FPS, albo 15 FPS. Dodatkowo przy 15 fpsach okazało się, że pudło ET22 wraz z wycieraczką i lusterkiem wykonuje ruchy osobno w stosunku do kabiny. Wygląda tak, jakby zepsuł się "banan". Wiele obiektów ma błędne oświetlenie nocne, są za jasne mimo że stoją w ciemnościach, ale to wiadomo i znana jest przyczyna, wszystko przed nami.
@tmj, mgła się znalazła a punkty świetlne wydają się bardziej wiarygodnie wyglądać niż dotychczas. Na razie nie stwierdziłem czy coś się zepsuło.
Wysyp na scenariuszu linia61_towarowy1, wystarczy trochę polatać po scenerii. Logi i crashdump w załącznikach.
Nie stwierdziłem, dojechałem do końca i zwiedziłem scn latając w różne miejsca, nie wywaliło.
Prawie działa ;) Światła w kabinie nie palą, i po wyjściu na zewnątrz zauważyłem dziwną smugę światła ciągnącą się po horyzont i zależną od tego gdzie patrzę. Jakby trochę poruszała się z kamerą. Na światłach z aureolami są jakieś czarne plamki w środku. Na linii 054 noc zauważyłem mocne trzęsienie się kabiny i obrazu za oknem, nawet po włączeniu pauzy.
Szkoda, że nie ma załączników obrazkowych. To któryś z rzędu wpis o błędach mimo posiadania dość mocnego modelu karty graficznej. Dla mnie to zaskoczenie, posiadając GF9600GT chłodzonego pasywnie mam jedynie kłopot ze spadającymi FPS-ami na Kaliskiej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 25 Marca 2017, 11:56:52
Było trochę zabawy, bo nie miałem vcredista2015, a ten wymagał msiintallera4.5, no ale się udało.
Po załadowaniu symulacji, kilkanaście sekund miałem tylko skyboxa (nieshaderowy o ile wyczytałem), potem dopiero załadowało pojazd.

Po przejściu na vbo ustały dziwne kolorki, ale nadal miesza tekstury w kabinie i dopiero po czasie ładuje scenę. Na zewnątrz tekstury przydzielone poprawnie, ale oświetlenie kuleje. (shaderki2)

FPS na TD w trybie vbo (wysoki to mało wiarygodny): ostatnie tmj 205 fps (zbugowane światła, brak aureoli), ng++ 260 fps.
DL: 260 | 235 fps. Aureole działają na obu. Kolor zgłupiał dopiero gdy ai włączyło światło.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Robert83 w 25 Marca 2017, 12:56:54
A u mnie wygląda to tak jak na obrazku. Też czerwona trawa i w loko dużo żółtego.

Wersja EXE : eu07++ng

Log w załączeniu.

Karta Radeon R9 290
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 25 Marca 2017, 12:59:27
Podaj typ karty graficznej, seria sterownika, może log. Sam screen to jakby z fusów wróżyć.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Marca 2017, 13:01:38
Na mojej karcie w zasadzie wersja shaderowa wyswietla normalnie, z wyjatkiem brakujacych nie wiedziec czemu aureoli. Ale pod wzgledem wydajnosci faktycznie spadek jest duzy (co ciekawe, liczenie swiatel nie ma tutaj az tak wielkiego wplywu -- nawet po wymuszeniu w kodzie shadera limitu kalkulacji oswietlenia do samego slonca, spadek jest ciagle do ~1/3 wersji 'golej') @Milek, z ciekawosci jak wyglada wydajnosc u ciebie w wersji na bardziej normalnych shaderach, a nie tych mieszanych?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 25 Marca 2017, 13:48:24
Na mojej karcie w zasadzie wersja shaderowa wyswietla normalnie, z wyjatkiem brakujacych nie wiedziec czemu aureoli. Ale pod wzgledem wydajnosci faktycznie spadek jest duzy (co ciekawe, liczenie swiatel nie ma tutaj az tak wielkiego wplywu -- nawet po wymuszeniu w kodzie shadera limitu kalkulacji oswietlenia do samego slonca, spadek jest ciagle do ~1/3 wersji 'golej') @Milek, z ciekawosci jak wyglada wydajnosc u ciebie w wersji na bardziej normalnych shaderach, a nie tych mieszanych?
kaliska po załadowaniu w kabinie:
twoje zwykłe exe: 30fps
shadery na uniformach: 30fps
shadery na fixed pipeline: 10fps

:D
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 25 Marca 2017, 16:18:48
Chwila oddechu, to zapytam. Jak wygląda odpalanie C++ na linuksie? Postawiłem wczoraj Ubuntu 15.10 MATE, doinstalowałem co trzeba i mogę cieszyć się symulatorem w wersji "borlandowej". Załącznik:
http://eu07.pl/userfiles/1234/foto-zrzut_ekranu.png
Natomiast po zaznaczeniu exeka C++, nie mam żadnych widocznych oznak chęci odpalenia symulacji. Coś trzeba jeszcze doinstalować, czy za wcześnie na takie wycieczki. Linuksa nie znam, wczoraj dostałem płytkę i postawiłem nie wiedząc co do czego.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Tomnord15 w 25 Marca 2017, 18:44:00
Nie wiem czy robię co źle, ale pojawia się u mnie taki błąd jak na screenie, gdy próbuję użyć exe od @Milka. Wszystkie biblioteki mam. MSVC też oraz shadery. W załączeniu log.

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 25 Marca 2017, 18:53:41
Visual Studio 2015 masz?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Tomnord15 w 25 Marca 2017, 18:57:45
Mam zainstalowane. Jak i wcześniejsze wersje. Exe od @TMJ działa bez problemu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 25 Marca 2017, 19:35:10
zbyt stara karta graficzna.

a dla innych, poprawione shadery, ci mieli krzaki mogą przetestować jeszcze raz https://milek7.pl/.stuff/eu07exe/fixedpipeline25.zip
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 25 Marca 2017, 19:45:41
Bez zmian w obu trybach renderowania. Takie same artefakty.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 25 Marca 2017, 19:56:06
@Krzysiek626: Te czarne kwadraciki w środku aureoli było widać na wcześniejszych screenach, które wrzuciłeś, na nowych też są. Wydaje mi się, że to błąd samej tekstury aureoli.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 25 Marca 2017, 20:32:34
Co do aureoli - mi się osobiście nie podobają (dla mnie ten efekt jest przekombinowany) i poproszę możliwość ich całkowitego wyłączenia. Dziękuję ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 25 Marca 2017, 20:46:00
@Milek7, u mnie nowe działa jak poprzednio bez problemu. Załącznik wielkiej wagi, ale nie widzę innego wyjścia pokazania o czym mówimy. Pełny antyaliasing. Shadery od Milka. @Tomnord: GF6600, miałem tą kartę, przyzwoita była, dawała się uruchomić w trybie GF6900ultra z odblokowanymi wszystkimi potokami pixelshader i vertexshader. Tam był dobry czipset zablokowany programowo do niższej klasy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: szogun w 25 Marca 2017, 21:47:44
Nie mogę uruchomić nowego EXE - wysyp na nowszym sterowniku ruszyło, Milka nawet się nie uruchamia.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 25 Marca 2017, 21:49:35
to samo, za stara grafika
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Marca 2017, 21:56:11
@Krzysiek626: Te czarne kwadraciki w środku aureoli było widać na wcześniejszych screenach, które wrzuciłeś, na nowych też są. Wydaje mi się, że to błąd samej tekstury aureoli.
Te punkty to sa prawdopodobnie swiatla punktowe zdefiniowane w modelu, przy nieprawidlowym ustawieniu parametrow mniej wiecej tak wygladaja. Nie pamietam dokladnie, ale chyba trzeba je recznie konfigurowac przy renderowaniu, i moze shader podchodzi do tego inaczej, traktujac je jak reszte geometrii.

Co do aureoli - mi się osobiście nie podobają (dla mnie ten efekt jest przekombinowany) i poproszę możliwość ich całkowitego wyłączenia. Dziękuję ;)
Najlatwiej wylaczyc je chyba poprzez edycje tekstury lightglare w katalogu textures/fx -- ustaw alpha channel calkowicie czarny (albo kanaly rgb, powinno wyjsc na jedno) i bedzie sie renderowalo "nic".
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 25 Marca 2017, 23:16:31
a dla innych, poprawione shadery, ci mieli krzaki mogą przetestować jeszcze raz https://milek7.pl/.stuff/eu07exe/fixedpipeline25.zip
Pomogło, teraz uruchamia się normalnie. Dzięki Milek.
 Światełka fiu, fiu nie powiem miodzio. No niestety fps drastycznie spadł, analogicznie jak u kolegów. Po uruchomieniu TD mam około 100 z widoku z kabiny, na wersji @Tmj było ponad 200. Poza tym grafa mocno dostaje po uszach, po krótkiej chwili było 80 stopni i  wycie wentylatorów...Fakt, że moja GTX460 już dwa razy się piekła w piekarniku...
 Zaraz sobie odpalę jakiś nocny składzik na L053:-) Na starym exe unikałem nocnych scenerii, teraz dla odmiany z nowymi światełkami prawie że nie jeżdżę na dziennych...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Robert83 w 25 Marca 2017, 23:26:03
a dla innych, poprawione shadery, ci mieli krzaki mogą przetestować jeszcze raz https://milek7.pl/.stuff/eu07exe/fixedpipeline25.zip
U mnie niestety dalej jak było źle tak jest. Nie pomogło :(
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Marca 2017, 23:41:25
Ciekawostka, w trybie VBO na NG++ tak miedzy 20-ta i 5-ta rano teren jest oswietlony jak w dzien, ale tylko przy widoku z kabiny, w widoku zewnetrznym jest normalnie (zaladuj TD, wlacz debug mode przez shift + ctrl + f12, i przytrzymaj shift + f1 zeby popedzic zegar) U siebie tego nie obserwuje.

Wyjasnilo sie przy okazji czemu u Krzyska na zrzutach byly flary a u mnie nie -- bo sprawdzalem tylko na VBO, a wtedy chyba jeszcze nie bylo ich w kodzie dla tej wersji. W ustawieniu DL wyswietlaja sie normalnie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 25 Marca 2017, 23:51:17
Tyle, że ja poprzednio napisałem:
Shadery od @Milek7: Wstępnie mogę napisać, u mnie odpala się prawidłowo. Nie mam różnicy między VBO i DL.
ED:
Nie miałem racji. Sprawdziłem teraz i na wczorajszych bibliotekach z VBO nie było flary.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 26 Marca 2017, 00:12:27
 Witam po chwili:-)
Przejechałem kawałek po L053 na exe NG++. Na samym początku symulacji świeciły niektóre obiekty: roślinność, budynki, miejscowo podsypka. Co ciekawe gdy tylko zbliżyłem się do wyjazdu na szlak wszystko zgasło i powróciło do normy. Co jeszcze zauważyłem.
-Słabo widoczne z oddali światła komór sygnalizatorów. Gdy zbliżymy się do nich widać w środku czarny punkt, który wydaję się że zasłania soczewkę gdy się oddalimy.
-Mocno trzęsie scenerią, ale nie zawsze. Wygląda to tak jakby miało to związek z położeniem albo kamery, albo całej lokomotywy względem współrzędnych X,Y. Jedziemy po prostej jest stabilnie, wjeżdżamy na łuk zaczyna trząść, potem znów prosta, telepie obrazem dalej. Trzeba by się temu przyjrzeć.
 Co do parametrów:
Zaptaszkowałem w ramach eksperymentu VBO.
Fps maksymalnie skoczył u mnie na tej scenerii do 50-ciu na szlaku.   
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 26 Marca 2017, 01:02:40
Z tymi aureolami tylko 1 rzecz jest nie tak, bo ogólnie są super-hiper. One się pojawiają i znikają nagle, przynajmniej na NG. Przy zbliżaniu się do kąta, pod którym powinny być widoczne ich nieprzeźroczystość powinna rosnąć, tak żeby były całkowicie widoczne tylko jak kąt jest dokładnie w środku, przy zmianie kąta widzenia kamery powinny stopniowo zanikać. Wtedy efekt będzie naturalny.

Ogólnie widzę, że wersja z shaderami to wczesna alpha, ale idzie w bardzo dobrym kierunku. Oświetlenie kabiny (bez lampy) wygląda zadziwiająco dobrze. W nocnej misji na L053 i ET-42 jest niesamowity klimat. Wcześniej wnętrza kabiny nie było w ogóle widać bez zapalonego światła w środku, teraz ogólnie widać wnętrze kabin w nocy bez zapalonego światła, jak oświetla je światło z zewnątrz. W kiblu działa lampka oświetlająca przyrządy z góry i daje o wiele bardziej realistyczny efekt niż w wersji bez shaderów.

Z tym trzęsieniem i skakaniem to jakiś grubszy bug, też go obserwowałem na L053. Ta sceneria jest szczególna, bo wcześniej była jedyną, która nie działała mi w trybie VBO. Efektem było właśnie losowe miganie różnych obiektów. Czyli to nie shadery a bug w silniku który w nim był od zawsze.

W ogóle nie wiem po co są 2 wersje z VBO i bez VBO, jest to do czegoś potrzebne, czy nie byłoby prościej, jakby zdecydować się na jedną z opcji a drugą wywalić?

Aha, było już chyba zgłaszane, ale na wszelki wypadek potwierdzę, że na NG nie ma mgły.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Marca 2017, 01:18:24
W ogóle nie wiem po co są 2 wersje z VBO i bez VBO, jest to do czegoś potrzebne, czy nie byłoby prościej, jakby zdecydować się na jedną z opcji a drugą wywalić?
To chyba glownie pozostalosc z czasow minionych, kiedy Display Lists byly na kazdej normalnej karcie, a VBO weszlo dopiero potem (i troche producentom zajela implementacja) Czyli ktos dodal to jako opcje dla juz dzialajacej wersji pierwotnej, ale te sciezki nie byly rozwijane calkiem rownolegle. Powoli pod maska mniej wiecej zmierza to ku temu zeby wersja byla w zasadzie jedna, ale tak calkiem przelaczyc na szybko nie bardzo mozna, bo wersja "rozwojowa" czyli VBO ma braki ktore trzeba uzupelnic. A zeby uzupelnic te braki to trzeba je wyciagac z takich dosc zakreconych kawalkow pod DL gdzie czasem ciezko dojsc co autor mial na mysli (a i to co jest to wymagaloby tu i uwdzie poprawek)

edit: ale w kabinach pod shaderami to chyba dlatego jasniej jest, bo nieprawidlowo komponent specular (albo coos) jest uwzgledniany nawet jak slonce jest juz dawno ponizej horyzontu :)  stad bierze sie tez ta smuga o ktorej wspominaja niektorzy.  Latwiej to wylapac w trybie debug, gdzie zaznaczana jest aktualna pozycja slonca. W zalaczniku przyklad, slonce jest w tym momencie za "naszymi" plecami.  Chociaz to akurat glownie moja wina, bo w kodzie specular 'slonca' nie jest ustawiany razem z reszta elementow swiatla (bo technicznie rzecz biorac nie jest uzywany, a przynajmniej wczesniej nie byl ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 26 Marca 2017, 08:16:50
U mnie widać ruznice miedzy trybem DL a VBO. Na VBO mam jasne niebo i elementy terenu. Zle oteksturowane szyny (podsypka).

Exe 323b. Karta Vnidii gts450.

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 26 Marca 2017, 11:53:28
Włodku, nam chodziło o exe @Milek7 z tego postu: http://eu07.pl/forum/index.php/topic,28920.msg447090.html#msg447090 (http://eu07.pl/forum/index.php/topic,28920.msg447090.html#msg447090)
Na 323b też będzie różnica, ponieważ w nim jest nieruszone (niepoprawione, niedokończone) vbo od @Ra. Dlatego są tam takie same błędy jak w exe z oficjalnej PC. Exe od Milka ma wbudowane shadery i należy odpalić w trybie DisplayList.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 26 Marca 2017, 12:00:21

U mnie widać ruznice miedzy trybem DL a VBO. Na VBO mam jasne niebo i elementy terenu. Zle oteksturowane szyny (podsypka).

Exe 323b. Karta Vnidii gts450.

Witam
Na wersji @Tmj przy włączonym VBO mam podobnie z teksturami szyn. Z tym że jak dobrze pamiętam to VBO jest rozgrzebane i wyłączone chwilowo chyba. Natomiast na wersji @Milka bez VBO sygnalizatory u mnie mają nienaturalną barwę komór ( pomarańczowy świeci zjadliwie żółto, a zielony na turkusowo ) jedynie czerwony jest chyba ok. Ale za to widać je z daleka i świeci aureola. Przy włączonym brak aureoli, oraz światło soczewki dobrze widoczne dopiero z kilku, kilkunastu metrów. Za to barwy świateł są naturalne.
Pozdrawiam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 26 Marca 2017, 12:28:02
A exe milka mi nie dziala bo pomimo instalacji tych bibliotek to ciagle krzyczy ze brakuje jakis plikow. Exe od tmj dziala bez zazutu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 26 Marca 2017, 12:39:14
Bo tmj zaczął kompilować z wszystkimi zależnościami zaszytymi w exe, więc nie wymaga osobnych dll-i.
Ciekawostki przyrodnicze. Widoczne na screenie obrócenie widoku o 90 st. nie wpływa na poruszanie myszką (tzn. poruszam prawa - lewa to obraz przekręca się tak jak powinien w trybie nieobróconym). Po drugie ląduję poza kabiną. Po trzecie wychodzę F4 i dalej mam obrócony obraz, wracam do kabiny F4 i wraca do normalności.
Cztery: w trybie VBO jest tak samo. Piąte: w VBO mam 3-krotny skok FPS (z 50 do 150). Sześć: wszystko mam przepalone ;) ale to już było zgłaszane.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 26 Marca 2017, 12:51:38
Już działa poradziłem sobie.

Scren1 VBO efekt jak wyżej w exe tmj.

Kolejne 2 screny DisplayList

Dziwne zrodlo swiatla brak podświetlenia kabiny.

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Marca 2017, 13:43:49
Na wersji @Tmj przy włączonym VBO mam podobnie z teksturami szyn. Z tym że jak dobrze pamiętam to VBO jest rozgrzebane i wyłączone chwilowo chyba.
Czy moglbys sprawdzic, czy nadal masz ten problem na ostatnim exe? (130324) Byly tam robione poprawki pod tym wzgledem (obsluga jest tez ponownie wlaczona) i powinno byc teraz w miare normalnie, tzn podobnie jak w trybie DL. Przynajmniej jesli chodzi o tory, bo krzaki gdzie indziej sa nietkniete :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 26 Marca 2017, 14:15:09
Ja sprawdzałem na 170323b. Ok zaraz zobaczę.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 26 Marca 2017, 14:19:23
Nie widze roznic pomiędzy VBO a DL tak na szybko.

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 26 Marca 2017, 14:53:12
Nie ma różnić poza L053. Odpal scenariusz z wyjazdem o 3 z minutami. Chyba większość ma różnice. Na L053 obiekty świecą. Las świeci. Drzewa świecą. Budynki świecą. Same z siebie, nawet jak zgaszę lampy. Ten sam problem jest bez shaderów, i ten sam efekt mam na starej paczce z Borlandem.

To jest jeden i ten sam bug, nie ma co kombinować, odpalamy L053-night-towarowy-et42, jak jest VBO włączone - wszystko świeci, jak jest wyłączone - jest OK.
Co do tego słupa światła - to znów 1 bug. W następnej wersji Boziu daj go nie będzie już. I daj Boziu czarnego kwadratu ;) Co do FPS - rzeczywiście, nie zwróciłem uwagi, ale na NG mam gruby spadek, chociaż jakoś mało go widać. Może licznik źle liczy? Mam wrażenie, że wyświetlanie nie tnie ani trochę, jest całkiem płynne, a mam 30 FPS zamiast 60. Znaczy się nie wiem czy mam, licznik pokazuje 30FPS, a nie sprawdzałem innym licznikiem. Jak ktoś ma FRAPS-a u siebie to może sprawdzić czy FRAPS pokazuje mu tę samą ilość FPS co licznik exe. Co ciekawe, pokazane także 3x, a nie 1x co powinno mieć miejsce przy przekroczonym czasie renderowania klatki. Myślę, że trzeba wyluzować i poczekać na uporządkowanie silnika, z tego co chłopaki piszą tam jest stajnia Augiasza, ludzie o słabych nerwach nie powinni nawet zaglądać do tego kodu ;)

Tak na marginesie - teraz dopiero widzę jak ohydnie wyglądają te krążki światła od lamp na chodnikach. Przy starym oświetleniu tak nie raziły, bo wszystko wyglądało podobnie źle, teraz reszta wygląda coraz bardziej realistycznie a te lampy odstają jak nie wiem. Jestem zachwycony aureolami, ale jasnożółty kolor komory, która powinna być bardziej pomarańczowa jest nieco irytujący.

Aha, no i zostaje ten bug bodajże z buforem Z, że obiekty nie mogą się zdecydować który jest bliżej kamery i raz jeden widać, raz drugi. I znów, to było na Borlandzie, jest tak samo teraz, tylko bardziej widać, bo reszta dużo lepiej wygląda i odstające elementy biją po oczach. Ciekawe czy to jest w ogóle do ruszenia, czy tak zostanie. Jak przez moment nie trzęsie i nie miga (na niektórych sceneriach) to jest taki fajny klimat płynnej jazdy, można się wczuć.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Marca 2017, 15:32:10
Nie ma różnić poza L053. Odpal scenariusz z wyjazdem o 3 z minutami. Chyba większość ma różnice. Na L053 obiekty świecą. Las świeci. Drzewa świecą. Budynki świecą. Same z siebie, nawet jak zgaszę lampy. Ten sam problem jest bez shaderów, i ten sam efekt mam na starej paczce z Borlandem.
Czy masz ten efekt takze na 130324? Bo u mnie wyglada jak na zalaczniku...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 26 Marca 2017, 16:05:01
Kolory komor semaforow sa tak zdefiniowane w modelach, a nie w exe.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 26 Marca 2017, 16:40:46
U mnie l053 sluzba na et42 nic nie swieci żaden las poza tym co oswietla smuga. Gdzie ten las swieci? Ostatnie exe + vbo. Natomiast przypadkiem zauwazylem ze mam przezroczysty hasler podświetlony. Brak opacity w podświetleniu alfa.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Marca 2017, 16:56:19
Na poprzednich exe (i wersji Borlandowej) swiecace obiekty i teren faktycznie byly, ale wyglada na to, ze ujednolicenie kodu mialo tu korzystny efekt jeszcze zanim zaczalem szukac przyczyn :)  Co do bledu haslera to nie jestem pewien -- u mnie wyglada jak na zalaczniku. Jesli tak jest nieprawidlowo to byc moze nalezaloby sprawdzic model, bo alfa tekstury jest i funkcjonuje, na gornej czesci haslera jak i chyba pozostalych elementach.

edit: z ciekawosci zaladowalem tez na exe Borlandowym, i ten hasler wyglada identycznie, zarowno pod VBO jak i w wersji DL.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 26 Marca 2017, 17:02:13
U mnie, nic nie świeci na VBO w L053. Inna sprawa, że to sceneria dla samobójców, nic nie widać. Sprawdzałem ten sam scenariusz to @tmj i @HTD (chyba zmienię sobie nick). Co do haslera sprawdzę dopiero.
ED:
Hasler jakiś taki normalny, ta szybka brudna chyba i tyle. Załącznik z VBO. Na DL jest taki sam. Nie mam różnicy w FPS między VBO i DL.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 26 Marca 2017, 17:18:49
Odpaliłem l053 na 240317 z VBO i nic już nie świeci, ale część tekstur mam źle przydzielone.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Marca 2017, 17:24:48
Odpaliłem l053 na 240317 z VBO i nic już nie świeci, ale część tekstur mam źle przydzielone.
Ktore tekstury i gdzie? Bo przy tej ilosci ja sie nie podejmuje szukac recznie ;/
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 26 Marca 2017, 17:27:28
Wszędzie. Losowo, zwłaszcza w okolicach wczytania, ale dalej też. Kabina, pojazdy, teren, modele statyczne. Efekt podobny jak na screenach z exe shaderowego Milka.
Scenariusz l053-całkowo-tlk55250.

Sprawdziłem lżejszą l053-służba1 i problem jest tylko z dynamicami. Teren i modele oteksturowane poprawnie. Jakby po ntej tekturze w pamięci gubiło indeksy. Na DL nie mam czegoś takiego.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Marca 2017, 17:30:41
Hmm no to u siebie tego nie widze :< To jest na ktoryms konkretnym scenariuszu, czy w kazdym?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 26 Marca 2017, 17:41:41
Stele, moze masz jakies programy trzecie, ktore wyswietlaja FPS/robia screenshoty/nagrywaja/pokazuja obecnych na TS?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 26 Marca 2017, 17:43:06
Żadnych overlayów powłączanych.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: KubaPKP w 26 Marca 2017, 17:57:32
Mam podobny problem na ostatnio udostępnionych plikach exe.
Wcześniej symulator w ogóle się nie uruchamiał, wówczas ładowanie zatrzymywało się na taborze.
Uruchamiały się tylko lekkie scenerie. Kaliską udało mi się uruchomić zmniejszając wartość maxtexturesize w eu07.ini.

Reg. obowiązki 2.
Proszę usunąć białe połacie z obrazków.

Czekałem dwa tygodnie. Brak reakcji. Przyznaję ostrzeżenie.
Benek

Wybacz, jakiś czas temu naprawiłem już swój błąd.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 26 Marca 2017, 17:58:03
@tmj: Na ostatnim NG z shaderami i pamiętam że na Borlandowym exe też tak miałem. Tyle, że na Borlandowym to te obiekty się zapalały nagle przy dojechaniu do jakiegoś miejsca, a na NG ten efekt pokazywał się od razu po odpaleniu. Efekt podobny jak na Twoim screenie, tyle że świeciło się wszystko, nie tylko podsypka.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Marca 2017, 18:26:41
Gwoli scislosci, na moim screenie podsypka sie nie swieci, to jest swiatlo z wlaczonych reflektorow lokomotywy ;)

@Stele ile pamieci ma twoja karta graficzna?
@KubaPKP czy ten efekt wystepuje tylko w wersji VBO, czy takze dla wersji DL?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 26 Marca 2017, 19:23:34
1GB. Widzę, że mam skalowanie tekstur włączone. Może to coś bruździ.
Zgadłem, po wyłączeniu skalowania wszystko wyświetla poprawnie (o ile zmieści tekstury na ramie).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Marca 2017, 19:39:05
O, ciekawe. Jaki miales ustawiony rozmiar skalowania, ktory powodowal takie efekty? Czy to bylo przy paczce TGA czy DDS?

edit: niewazne, ustawilem 1024 i po zaladowaniu Kaliskiej pokazala sie sieczka jak na zrzutkach :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 26 Marca 2017, 19:49:31
Przy skalowaniu tekstur też tak mam, może nie tak drastycznie. Wspominałem o tym.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Marca 2017, 20:21:12
W duzym skrocie, mialem w kodzie bardzo glupi blad, ktory objawial sie tylko, gdy jedna lub wiecej tekstur sie nie zaladowala. W nowym uaktualnieniu powinno juz byc w porzadku, a przy okazji prawdopodobnie exe nie bedzie sie teraz gryzlo z programami overlay (to jest teoretyczne, bo nie mam pod reka nic oprocz fraps, wiec nie moge tego sprawdzic ;d

pozostale zmiany:

- wlaczylem sprzetowa kompresje tekstur, ktore kompresowane nie sa. Wplynie to w zasadzie tylko na paczke w wersji TGA, powinna byc teraz bardziej "ladowalna". Teoretycznie nie powinno byc efektow negatywnych, ale jak wiadomo teoria sobie, a praktyka sobie)
- w ramach koncertu zyczen, w przypadku bledow ladowania torow itp, oprocz wspolrzednych w logu bedzie takze podana nazwa problematycznego odcinka
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Piotr93 w 26 Marca 2017, 21:03:02
Nie wiem czy ja coś popsułem, ale dopiero pobrałem nowe exe i wszystko co potrzebne, oraz exe z dzisiaj. No i na TD słupy mam kolorowe.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Marca 2017, 21:12:37
Przyznam ze nie rozumiem, w jakim sensie kolorowe? Jesli chodzi o to, ze lewa strona slupa jest ciemniejsza, to jest dlatego, ze swiatlo sloneczne pada z prawej strony i oswietla jedna strone bardziej, zamiast uniwersalnie dookola jak poprzednio.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Piotr93 w 26 Marca 2017, 21:14:44
Tak, chodziło mi o ten błękit na słupie, jeżeli tak to ok.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Marca 2017, 21:16:07
Poziom blekitu bedzie prawdopodobnie predzej lub pozniej skorygowany, ale na ten moment to jest 'jak ma byc' :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 27 Marca 2017, 00:54:43
Potwierdzam poprawne działanie symulatora z nakładkami :)

EDIT: skoro na innych semaforach jest ok, a nawet komorach tej samej głowicy, to wnioskuje że jakiś problem zdefiniowaniem położenia światła może?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 27 Marca 2017, 14:03:20
Nie mam żadnych uwag do 260317. Objechałem kilka scenerii, nic złego się nie dzieje. Oczywiście nie wszystkie pojazdy jestem w stanie sprawdzić. Widzę zmianę na flarach i światłach, nie widzę teraz czarnych kropek a flary nie są przerysowane. Mam prośbę, od dawna przeszkadzało mi sterowanie ruchem kamery w kabinie pojazdu - góra/dół PageUp/PageDown, bo jest skokowo. Jeśli można to poproszę płynne przemieszczanie kamery tak jak jest to w poziomie i tak jak jest to w trybie frefly.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 27 Marca 2017, 14:54:08
Myslalem, ze w kabinie specjalnie jest tak skokowo, zeby jednym przycisnieciem przelaczac miedzy pozycja 'stojaca' i 'siedzaca'? Ale tak, jesli jest zapotrzebowanie to mozna to zmienic.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 27 Marca 2017, 15:22:32
No jakoś nie podnosiło mnie z krzesła;) Jeśli by tak miało być, to w pionie powinny być tylko dwie pozycje możliwe do ustawienia.
Zagubiła się poprawka od Grzesia Firlejczyka na błąd długiego składu Orlenu na Kaliskiej w Sieradzu. Wiesz co mam na myśli? Tam ST44 nie chce startować spod semafora. Dodałem dziś więcej wagonów w tym składzie i skład niestety nie rusza mimo s2. Jadę jeszcze raz, może to  przypadek.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 27 Marca 2017, 15:33:18
Zagubiła się poprawka od Grzesia Firlejczyka na błąd długiego składu Orlenu na Kaliskiej w Sieradzu. Wiesz co mam na myśli?
No raczej sie nie zgubily, bo ja pierwsze slysze ze cos takiego w ogole bylo :)  Nie ruszalem kodu skanowania itp, wiec byc moze nie jest to wlaczone do kodu, ale nawet nie wiem gdzie tego szukac, tutaj @Firleju musi pomoc.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Lorem w 27 Marca 2017, 16:30:14
Objeździłem trochę exe z shaderami. Ze znanych błędów powtórzyło się trzęsienie scenerii, bujanie kabiny osobno w stosunku do pudła. Świecenia obiektów nie stwierdziłem, poza błyszczącą składową specular pomimo kompletnej nocy. Obiekty oświetlają się z odpowiedniej strony w zależności od położenia słońca, ale ruchome światła lokomotyw oświetlają obiekty w swoim zasięgu ze wszystkich stron (czyli słońce powoduje powstanie cienia własnego, ale światło lokokmotywy nie). Chociaż też nie wiem, czy słońce oświetla poprawnie, bo jego ruch pod horyzontem też zmienia kierunkowe oświetlenie. Ale to chyba @tmj coś już pisał na ten temat.

Z nowych rzeczy: Na niektórych sceneriach (z tych, które sprawdzałem, to l053-night-towarowy-et22 oraz krzyzowa2) symulator uruchamia się z maksmalnie wysuniętą do przodu pozycją kamery w kabinie. Nie da się jej cofnąć, ruch przód-tył jest niemożliwy. Ponadto próba włączenia trybu debug kombinacją Ctr+Shift+F12 kończy się wysypem (crashdump w załączniku). Oba te błędy znikają, gdy wyjdzie się i wejdzie z powrotem do kabiny klawiszem F4. Dotyczy tylko exe ng.

Potestowałem jeszcze jak się ma nowe exe do ustawień VBO/DL na karcie nVidii GeForce 840M i zintegrowanej Intel HD Graphics 5500.
VBO: na nVidii wyświetla się dość dobrze, na Intelu wszysko jest nieco przepalone. Na obu kartach freespoty wyświetlają się jako czarna kropka, poza tym panel tekstowy pod F9 wyświetla "Last openGL error: 1282 (nieprawid,owa operacja)"
DL: na nVidii pełen sukces, poza wypisanymi wyżej błędami, na Intelu zaś sypią się kolory. Ale specular w nocy wyświetla się w kolorach odpowiednich. Starałem się to pokazać na screenach.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 27 Marca 2017, 17:22:18
Poprawki na skanowanie są tylko u mnie na kompie. Totalnie to rozgrzebałem a teraz jeszcze doszła reinstalka i na razie zbieram system po niej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 27 Marca 2017, 21:39:52
Sprawdzałem wersję 64 bitową 170326. Znalazłem ciekawostkę, na większych(?) stacjach gaśnie mi smuga. Zanotowałem w Sieradzu i Zduńskiej Woli. Na 32 bitowym tego nie mam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: RoboBatman w 27 Marca 2017, 21:44:59
@tmj/milek7: widzę, że słowo "shader" coraz częściej pojawia się na annałach tego wątku. Mam pytanie co do nich: czy gdyby (podkreślam: gdyby) faktycznie shader-y zostały zaimplementowane w exe do MaSzyny, to byłaby możliwość ich wyłączenia dla słabszych komputerów na przykład poprzez wpis poprzez odpowiedni plik tekstowy z konfiguracją czy raczej jest to nie realne? Albo dać to samo osobne exe tyle, że bez shaderów? Dziękuję z góry za odpowiedź.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 27 Marca 2017, 22:30:04
W przypadku wprowadzenia shaderow prawdopodobnie obecna wersja renderowania ciagle bedzie obecna jako opcja, ale warto zwrocic uwage, ze wersja z 'normalnymi' shaderami powinna pracowac z predkoscia porownywalna do obecnej wersji zwyklej, wiec chyba nie ma sie specjalnie czego obawiac.

Sprawdzałem wersję 64 bitową 170326. Znalazłem ciekawostkę, na większych(?) stacjach gaśnie mi smuga. Zanotowałem w Sieradzu i Zduńskiej Woli. Na 32 bitowym tego nie mam.
Tak na szybko, to nie obserwuje u siebie takiej roznicy. Czy jest szansa, ze masz te wersje w osobnych katalogach, i w pliku .ini ktorego uzywa wersja 64 bit nie ma wpisu dynamiclights ? W takiej sytuacji exe byloby ograniczone do domyslnych 3-ech zrodel swiatla, a to na duzych stacjach faktycznie moze byc malo i exe przydziela 'twoja' smuga innemu pojazdowi, ktory wg jego kalkulacji oswietla scene 'bardziej'.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 27 Marca 2017, 22:39:10
W takiej sytuacji nie mogę sobie darować, że nie sprawdziłem u siebie wszystkiego. Teraz nawet specjalnie pojechałem na 32 bitowym i oczywiście jest w porządku. Wpis miałem zrobiony, tylko ze przypisałem tam 1. Na pozostałych paczkach mam przypisane 5 lub 7.
Wpis poprawiłem, tym niemniej jeszcze jutro do wieczora to objadę. Chyba, że noc zaowocuje jaką nowością.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Lorem w 28 Marca 2017, 00:32:32
Problem dotyczy tylko exe w wersji 64bit. Na 32bit działa dobrze.

Sceneria calkowo_towarowy, wysypuje się zaraz po załadowaniu (w logu z exe @tmj ostatnią linijką jest Player Train init OK, w logu exe od @Milek jeszcze jakieś pojedyncze eventy się wyzwalają, patrz załączniki). Przy czym scena nie zdąża się wyświetlić, ekran ładowania się zabiela i jest okienko "Program MaSzyna przestał działać...". Crashdump nie generuje się.

Udało się ustalić, że problematyczny jest plik scenery/slimson/drogi3_os.scm, a dokładniej druga jego część, zawierająca wpisy node ... track road ... endtrack. Czyli coś nie tak z drogami, ogólnie mówiąc. Zastanawiające jest to, że wysyp występuje tylko w wersji 64bitowej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Marca 2017, 00:42:04
Jesli znajdziesz chwile, sprawdz z ciekawosci czy problem zniknie po wlaczeniu VBO? W kodzie tworzacym geometrie skrzyzowan dla display list jest blad ktory objawia sie w trybie 64-bit, ale tylko na niektorych sceneriach, wiec nie spieszylem sie za bardzo z wyszukaniem i poprawieniem, tym bardziej ze trudno rozeznac sie, co sie tam dzieje wiec strach tego tknac :d Planowalem to uporzadkowac podczas dalszej unifikacji metod renderowania.

edit: a w miedzyczasie, uaktualnienie; glownie modelu oswietlenia:
- dodana kalkulacja pozycji ksiezyca na podstawie daty i czasu w symulacji; w nocy ksiezyc przejmuje role (slabego) zrodla swiatla, o ile jest akurat ponad horyzontem
- kolor atmosfery wplywa na oswietlenie sceny bardziej o swicie i zmroku, mniej gdy slonce jest wysoko na niebie
- podobnie jest z samym sloncem; o swicie i zmierzchu kolor jest bardziej typowy dla tych godzin i zauwazalnie wplywa na kolorystyke chmur
- dodany parametr zachmurzenia sceny. Na chwile obecna jest to opcjonalny parameter typu float w sekcji atmo pliku .scn, o wartosci miedzy 0 i 1  Niebo 'zachmurzone' jest bardziej monochromatyczne, i redukuje udzial jaki w oswietleniu ma slonce -- swiatlo sceny jest rozlozone bardziej rownomiernie
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: ST44-003 w 28 Marca 2017, 09:38:10
Chciałem zapytać tylko, bo nie bardzo miałem czas w całości wątek śledzić. Wersja x86 to wersja 32bit? Bo x64 niekoniecznie chce ze mną współpracować, ale na x86 trochę pojeździłem i nie znalazłem na razie błędów.
Jedynie co to:
- pionowa linia od słońca do ziemii
- brak działania lampek od blokady drzwi i hamowania w ED72 mimo możliwości ich załączenia (Ctrl + Shift + S)
- często niektóre obiekty "gasną" za wcześnie mimo iż smuga jeszcze na nich się opiera (błąd modeli, np. peronów, ale zgłosić trzeba).

Ogólnie jestem pod wielkim wrażeniem. Kaliska odpalona na pendrajwie o przesyle danych 2.0, podpiętym do USB 3.0 wczytuje się równie szybko jak bezpośrednio zainstalowana na dysku. Plusy za FPS rzędu 50-60 ;].
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 28 Marca 2017, 09:55:01
Ja się z przepisywaniem całej tabeli chyba poddam. Zaczynam schodzić do poziomu, w którym nie wiem czemu niektóre rzeczy są porobione i jak to działa. Ale, żeby nie było, że nie ma żadnych efektów to do głównego kodu dorzucę parę zmian, tak żeby poprawić działanie skanowania i mierzenie odległości od poszczególnych elementów.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Lorem w 28 Marca 2017, 10:02:08
sprawdz z ciekawosci czy problem zniknie po wlaczeniu VBO?

Znika w takim sensie, że symulator się nie wysypuje. Ale po włączeniu VBO, na obu wersjach exe, skrzyżowania nie wyświetlają się. Na DL 64bit jak już pisałem jest wysyp, a na DL 32bit jest w porządku, jeśli nie liczyć drobnych prześwitów pomiędzy modelem skrzyżowania a resztą drogi.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Marca 2017, 12:17:05
Chciałem zapytać tylko, bo nie bardzo miałem czas w całości wątek śledzić. Wersja x86 to wersja 32bit? (..)

Jedynie co to:
- pionowa linia od słońca do ziemii
Tak, x86 to wersja 32-bit. Pionowa linia od slonca do ziemi to feature w trybie debug, zeby latwiej bylo znalezc gdzie wedlug exe slonce sie w danym momencie znajduje :)

Znika w takim sensie, że symulator się nie wysypuje. Ale po włączeniu VBO, na obu wersjach exe, skrzyżowania nie wyświetlają się.
Zgadza sie, bo Borlandowe exe nie ma obslugi skrzyzowan w trybie VBO (zatem nie ma ich takze wersja c++ bo jeszcze nie bylo tam nic ruszane) dlatego nie ma sie na czym wysypac ;d
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 28 Marca 2017, 17:26:44
nowe exe https://ci.appveyor.com/project/Milek7/maszyna/build/8/artifacts
zaktualizowane shadery https://milek7.pl/.stuff/eu07exe/fixedpipeline28.zip

praktycznie nic się nie zmieniło, tylko merge z tmj, być może działające oświetlenie kabiny, włączenie starych freespotów, i zmiany w wyliczaniu specular (teraz jest brany mnożnik diffuse * 0.3)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 28 Marca 2017, 17:46:29
@Milek7, nazwy exe od Ciebie są zawsze takie same. Brak rozróżnienia wydania i podziału 32/64 bity robi problemy przy ściąganiu do jednego katalogu i utrudnia archiwizowanie. Jeśli nie sprawi to trudności, wstawiaj jakieś znaczniki.
ED:
Po za wyszczególnionymi zapowiedziami faktycznie jest jak było. U mnie wersja 32 bity odpala się bez problemów. Światła (reflektory i szkła semaforów wyglądają jak w "borlandowym" exe, ale smuga oświetlenia z loka jest mniamniuśna. FPS na TD przy 16 krotnym wygładzaniu równy 46.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 28 Marca 2017, 20:10:44
Coś w wyświetlaniu linii było zmienione? Mam wrażenie, że lod słupów trakcyjnych (node line) znika w znacznie mniejszej odległości i walczy z meshem słupa.
Skoro były błędy w sortowaniu tabelki przy mało-idealnych sceneriach, to może spróbować wrócić do W4 z 481 gdzie sprawdzał opóźnienie i czekał dodatkowe 20 sec? W 482 to cofnąłem jako potencjalnie powodujące błędy, ale czy tak było to nadal nie wiem. To ze dwa wersy zakomentowane są. Testuję scenariusz z napiętym rozkładem i kierownik mi gwiżdże nim drzwi otworzę.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 28 Marca 2017, 20:12:44
Nie, nic tam nie było zmieniane. Tylko to może trochę inaczej wyglądać, bo obecnie na shaderach nie ma mgły.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 28 Marca 2017, 20:20:51
Niebo o godzinie 22:30 movelight 150.

Ten pomarańcz o 22? i gdzie ten księżyc? Na około patrze i nie widze za to idealnie w gorze jest czarna dziura.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 28 Marca 2017, 20:23:14
Ale jest okrutne przepalenie w światłach i cieniach. Bałtyk na starcie wygląda jak w załączniku. U @tmj, ten sam widok na drugim załączniku. Nie ma tego efektu.
Jeśli wyciągnąć tylko zalety jednej i drugiej dzisiejszej kompilacji - to jest malinowo.

ED:
Ja mam księżyc, zarówno u @tmj (3 załącznik) jak i u @Milek7 (4 załącznik). @Milek7, 22;30 księżyc (załącznik 5). Wszędzie bez VBO i pełny ekran.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 28 Marca 2017, 20:34:39
Tak na szybko: ZAJEFAJNE. Czyli: światła nocne urywają zad. Te korony wreszcie są takie jak być powinny, czyli pojawiają się i zanikają płynnie. Barwy i oświetlenie zewnętrzne - nie ma się do czego przyczepić - doskonałe, przynajmniej na 3 szybkie rzuty okiem.

Teraz sprawy formalne - mówisz, że zgrywacie swoje wersje? To jest do zgrania od @tmj ten licznik od zakresu rysowania. U mnie na Drawinowie zacięty na sztywno na 3x, tymczasem FPS mi spadł do 15. Ale, ja już wolę 15FPS z takimi efektami niż 60 bez nich ;) W końcu to nie symulator odrzutowca ;)

Na koniec bugi: ten snopek, ale to wiadomo. Nie ma mgły. Oświetlenie przyrządów nieco zbyt jaskrawe, do przepalenia (tarcza haslera w EP05 zrobiła się cytrynowo żółta z pomarańczowej). Za to oświetlenie kabin nigdy nie było lepiej wyregulowane. Idealnie, nic nie zmieniać.

Co tam jeszcze, nie wiem czy to kwestia zmian w silniku czy może samego pojazdu, ale w SN61 lampy są po prostu białe. W kiblu wcześniej widzałem taki fajny efekt, że lampy miały swoją żółtawą teksturę, ale jak się spojrzało pod kątem prostym to oślepiały przez efekt korony. W SN-61 tego nie ma ale to może kwestia jego modelu.

No i niestety to trzęsienie - odnotowałem je również na Całkowie i Drawinowie. Obraz trzęsie się w poziomie, to takie szybkie (ze 30Hz) ruchy całego obrazu w poziomie. Tak mniej więcej 1 do 2 piksli to lata. I nie wszędzie.

Zauważyłem też ciekawy efekt, przy wyjeżdżaniu z Drawinowa zrobiło się jakoś jasno w kabinie, jakby jakieś silne reflektory mi zaświeciły do środka.

Mam nadzieję, że kolejne wersje będą powstawać już na bazie tej z shaderami. Bo na stare światła migające to już nie mogę patrzeć, oczy mi łzawią ;) Zaraz będą screeny, mam 15 minut to zaraz porobię, żeby pokazać co z zegarami jest nie tak.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 28 Marca 2017, 20:40:47
Cytuj
...to takie szybkie (ze 30Hz) ruchy całego obrazu w poziomie.
Chyba 3hz. 30, nie jesteś w stanie zobaczyć swoim okiem. Natomiast potwierdzę to trzęsienie na wydaniu z 26 marca na Kaliskiej w Ostrowie Wielkopolskim.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 28 Marca 2017, 20:48:38
Exe tmj 170328. To tu zauważyłem te linie w bliższej niż zazwyczaj odległości. Scenariusz z testów Bałtyk EN57. Wysyp przy wjeździe w perony w Alakowicach. Pierwszy wysyp od dawna.

-----------
Exek shaderowy Milka. x86.
DL: Jest lepiej. Tekstury i diffuse poprawny. Po zapaleniu świateł pojazdu albo brak efektu albo rozświetla całą scenę.
VBO: To samo. Freespoty (kropka+aureola) białe niezależnie od koloru materiału w modelu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 28 Marca 2017, 21:04:48
Na obrazkach widać lekkie przepalenie przyrządów (w kibelku szczególnie, widać to też na tych pionowych dodatkowych zegarach od SN-61, z lewej części kabiny). Widać też z oddali kibelek z ładnymi koronami od świateł, niestety nie wszystkie lokomotywy mają ten efekt. Wydaje mi się, że w którejś wersji exe światła były nieco ciemniejsze (chodzi o teksturę lampy), przez co korony i efekt oślepiania wyglądał nieco lepiej.

Aha, jeszcze wskazówki od zegarów są czarne w SN61, ale nie tylko, bo w EP05 też.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Marca 2017, 21:30:19
Niebo o godzinie 22:30 movelight 150.

Ten pomarańcz o 22? i gdzie ten księżyc? Na około patrze i nie widze za to idealnie w gorze jest czarna dziura.
movelight 150 to w okolicach poczatku maja. Slonce zachodzi wtedy ok. 20, a o 22-ej jest ok 13-14 stopni ponizej horyzontu, podczas gdy ciemnosc zapada dopiero gdy slonce zejdzie 18 stopni ponizej horyzontu.

Ksiezyc jako taki nie jest jeszcze rysowany, na razie kalkulowana jest jego pozycja na podstawie kalendarza i godziny, i ta pozycja uzywana jest, by okreslic skad pada swiatlo, jesli jakies w ogole pada. Skalkulowana pozycje (zarowno ksiezyca jak i slonca) mozesz zobaczyc po wlaczeniu trybu debug. Przy movelight 150 i o 22-ej jest usytuowany jak na zalaczniku.

edit: ten ksiezyc u Krzyska to jest ze starego modelu nieba, razem ze sloncem ktore tez tam jest wszyte :)  sugerowalbym zamienic wpis w scenerii ze sky_dynamic_stratus.t3d na skydome_clouds.t3d bo inaczej niedlugo bedziesz mial na niebie dwa ksiezyce i dwa slonca ;d
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 28 Marca 2017, 21:40:45
L053 sluzba 3 noc. W okolicach Zernikow nagly wysyp dp windowsa.

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 28 Marca 2017, 21:51:31
Potwierdzam, w dzień przepalenie, na scenerii Zwierzyniec Transport - prawie całkiem biały ekran.

ALE przyjemna niespodzianka - tryb VBO (przynajmniej na wersji x64) działa całkowicie prawidłowo, przejechałem kawałek L053 i żadnych świecących obiektów nie uświadczyłem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Marca 2017, 22:00:51
Scenariusz z testów Bałtyk EN57. Wysyp przy wjeździe w perony w Alakowicach. Pierwszy wysyp od dawna.
Ten wysyp wyskakuje baaardzo rzadko przy skanowaniu torow (skan probuje czytac tor, ktorego nie ma bez sprawdzenia) na roznych sceneriach, ale do tej pory nic tam nie ruszalem, bo mialem nadzieje ze jak zrobisz zmiany w tabelce to sie samo naprawi ;o

Przy okazji, skoro z tej rewizji wyszla dolna czesc plecow, mialbys moze czas/checi zeby przyjrzec sie ewentualnej reorganizacji tego jak w ogole skonstruowane jest przechowywanie i obsluga torow, i zastepstwem eventow czyms bardziej strawnym? Pytam bo o ile dobrze rozumiem, masz pod tym wzgledem jakies doswiadczenia a ja nie =) A przydaloby sie to ogarnac, bo to jedna z rzeczy ktora powstrzymuje prace nad zapisem/odczytem scenerii z poziomu exe. Tzn technicznie rzecz biorac nie wstrzymuje, ale robiac zapis/odczyt najpierw wyszloby na to, ze po reorganizacji trzeba by go robic od nowa.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 28 Marca 2017, 22:15:42
Cytuj
edit: ten ksiezyc u Krzyska to jest ze starego modelu nieba, razem ze sloncem ktore tez tam jest wszyte :)  sugerowalbym zamienic wpis w scenerii ze sky_dynamic_stratus.t3d na skydome_clouds.t3d bo inaczej niedlugo bedziesz mial na niebie dwa ksiezyce i dwa slonca ;d
Screeny robiłem tak, aby tego drugiego księżyca nie było widać. ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 29 Marca 2017, 00:07:18
Witam.
 Uruchomiłem z ciekawości Kaliską na najnowszej wersji Exe od Milka. Światełka jak najbardziej na plus. Poświata komór semaforów również. Fps w Ostrowiu na poziomie 10 -20, na szlaku do 40-stu.
 Co do zauważonych problemów.
- Bardzo trzęsie obrazem w poziomie, a właściwie scenerią. Do tego stopnia że mam wrażenie jakbym przyjął pół litra na twarz. Obiekty w pewnych momentach widać podwójnie. Można dostać dosłownie oczopląsu. I tu znowu wydaje się jakby poziom tego zjawiska zależał od orientacji prowadzonego pojazdu względem osi X,Y scenerii.
-Wypalone kolory świecących obiektów.
Mam też dziwny przypadek braku poprawnego wyświetlania wskaźnika rozjazdu krzyżowego. Widać jedynie lewitujący czarny X.
Pozdrawiam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 29 Marca 2017, 04:39:27
OK, biorac pod uwage ze zbliza sie 1-szy kwietnia...

"To jest ksiezyc na miare naszych mozliwosci"

(nie, to tylko tekstura robocza)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Robert83 w 29 Marca 2017, 05:59:18
U mnie też już nie ma czerwonej trawy i artefaktów :) Jedynie też trzęsie kabiną na zakrętach w poziomie oraz wszystkie semafory na których świeci się zielone to u mnie jest kolor niebieski. Tak już od dłuższego czasu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 29 Marca 2017, 08:20:44
Czy dałoby radę zrobić coś, żeby dźwięk "runningnoise" miał głośność zależną od prędkości? Bardzo irytujące jest, że ten dźwięk startuje i kończy się odtwarzać nagle. Szczególnie dokuczliwe w EP05 / EP09. Dalej - zauważyłem, że ten dźwięk odtwarza się z głośnością niezależną od obecności w kabinie czy nawet odległości od składu. Wysiadam z kamerą, pociąg odjeżdża, a nadal słyszę dźwięk z pełną głośnością, nawet, jeśli pociągu już nawet nie widać.

Czy dałoby się dodać widok interfejsu z celownikiem na środku ekranu i współrzędnymi tego celownika wyświetlanymi cały czas (bez żadnych innych danych)? Oczywiście kierunek ustawienia kamery również na tym widoku byłby potrzebny.

Jak wyglądają plany połączenia różnych wersji exe? Czy jest szansa, że w najbliższej przyszłości znikną wersje DL / VBO z shaderami i bez? Do ostatniej wersji NG wersja VBO miała problemy z oświetleniem na niektórych sceneriach, szczególnie L053, zauważyłem, że ostatnia wersja chyba rozwiązała ten problem, za to na x64 połowa scenerii się wysypuje bez VBO. Skoro VBO już jakoś działa a DL się teraz sypie, może porzucić DL na dobre? Jeśli światła na shaderach działają już bardzo dobrze, nie mogą zostać? No tylko jeszcze efekt tego przepalenia został. Usunięcie go nie będzie trywialne, bo jakby po prostu tylko przyciemnić wszystko to będzie za ciemno w nocy. A chodzi w zasadzie o to, żeby tylko w dzień było ciemniej, a w nocy dokładnie tak jak jest. Z oświetleniem przyrządów nie tyle chodzi o to, żeby podświetlenie było ciemniejsze, ale żeby nie wchodziło w nienaturalne nasycenie (przepalenie). Jasność jest OK, ale coś nie tak jest kolorami i gammą.

Ostatnia sprawa to trzęsienie i miganie. To są 2 różne błędy. Pierwszy to błąd wersji z shaderami. Na moim sprzęcie trzęsienie jest bardzo szybkie, serio, jakby z 20-30FPS miało. Zawsze w poziomie i tylko w poziomie. Drugi błąd to trzęsienie i miganie obiektów. Trzęsienie widać na podsypkach, jakby na zmianę rysowały się 2 wersje podsypek nieco przesunięte. To zmienia się wolno, od 1 do kilku razy na sekundę. W niektórych miejscach efekt jest bardzo intensywny. To było w MaSzynie od zawsze, i podobno nie da się nigdy poprawić. Nie da się? Ale jest jeszcze druga wersja tego samego problemu jednakże jeszcze bardziej irytująca: ustalanie czy obiekt jest za czy przed innym. To powoduje, że niektóre obiekty pojawiają się i znikają raz do kilku razy na sekundę, albo zależnie od kąta patrzenia kamery. Stoję sobie na peronie i widzę jak miga budynek czy nawet kawałek górki. Jeśli kamera jest nieruchoma i obiekty są nieruchome - dlaczego poruszają się pomiędzy kolejnymi klatkami?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 29 Marca 2017, 08:58:27
@tmj, pomyliłeś mnie i Antka, ale spoko. Tory w tej chwili przechowywane są jako linked list. Tak samo eventy, a to wszystko przechowywane jest w globalnej linked list. Teoretycznie przy skanowaniu jest sprawdzane czy następny tor istnieje. Ale jeśli tor traci się jak już został przeskanowany to potem już niczego nie sprawdza przy samych obliczeniach na tabelce.
Z eventami to jest cięższa sprawa. Jakiekolwiek poważniejsze zmiany to będzie przejście na SCS lub cokolwiek innego. Do tego będzie trzeba przegrzebać AI, na czym obecnie się zawiesiłem (całe AI jest w TController::UpdateSituation).
Teoretycznie mogę zacząć robić specjalne buildy, ale to chyba, przy obecnym natężeniu prac, nie jest najlepszy pomysł.
Obecnie rozdzieliłem sprawdzanie torów od eventów i ograniczenia narzucane są osobno dla każdego typu (to już wcześniej było połowicznie zrobione). Takie podejście mocno koliduje z tym w jaki sposób AI współpracuje z tymi wartościami, np. nie sprawdza tabelki jeśli nie jest uruchomione, co też rzutuje na tabelkę jak kieruje człowiek i nie jedziemy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 29 Marca 2017, 12:22:30
Czy dałoby radę zrobić coś, żeby dźwięk "runningnoise" miał głośność zależną od prędkości? Bardzo irytujące jest, że ten dźwięk startuje i kończy się odtwarzać nagle...

...Czy dałoby się dodać widok interfejsu z celownikiem na środku ekranu i współrzędnymi tego celownika wyświetlanymi cały czas (bez żadnych innych danych)? Oczywiście kierunek ustawienia kamery również na tym widoku byłby potrzebny...
Źródła nareszcie są otwarte i szczerze mówiąc po Twoich zapowiedziach: http://eu07.pl/forum/index.php/topic,26398.msg393162.html#msg393162
spodziewałem się, że sam dorzucisz parę linijek kodu. 
Uzależnienie głośności od prędkości nie jest dobrym pomysłem, to rozwiązanie byłoby tylko połowiczne. Nie jestem akustykiem więc uproszczę, gdyby przyjąć ten dźwięk, że jest czystą sinusoidą, to powinien zmieniać też swą częstotliwość. A czystą sinusoidą nie jest, to problem jest skomplikowany i jak dla mnie ma mały priorytet. Wręcz jak dotąd nie zauważyłem że istnieje.
Celownik jest zbędny, strzelać nie mam zamiaru. Natomiast widziałem że jest możliwość wyświetlenia współrzędnych kamery razem z azymutem kierunku w którym patrzy.
Cytuj
Jak wyglądają plany połączenia różnych wersji exe? Czy jest szansa, że w najbliższej przyszłości znikną wersje DL / VBO z shaderami i bez? Do ostatniej wersji NG wersja VBO miała problemy z oświetleniem na niektórych sceneriach, szczególnie L053, zauważyłem, że ostatnia wersja chyba rozwiązała ten problem, za to na x64 połowa scenerii się wysypuje bez VBO. Skoro VBO już jakoś działa a DL się teraz sypie, może porzucić DL na dobre? Jeśli światła na shaderach działają już bardzo dobrze, nie mogą zostać? No tylko jeszcze efekt tego przepalenia został. Usunięcie go nie będzie trywialne, bo jakby po prostu tylko przyciemnić wszystko to będzie za ciemno w nocy. A chodzi w zasadzie o to, żeby tylko w dzień było ciemniej, a w nocy dokładnie tak jak jest. Z oświetleniem przyrządów nie tyle chodzi o to, żeby podświetlenie było ciemniejsze, ale żeby nie wchodziło w nienaturalne nasycenie (przepalenie). Jasność jest OK, ale coś nie tak jest kolorami i gammą.
Od końca. Jasność nie jest ok, przepalona jest cała sceneria i tylko w wersji NG. Światłą w shaderach działają bardzo dobrze, ale fps jest tragiczny dla kart starszych. Dlatego ostrożnie z porzucaniem czegokolwiek.
Cytuj
Ostatnia sprawa to trzęsienie i miganie. To są 2 różne błędy. Pierwszy to błąd wersji z shaderami. Na moim sprzęcie trzęsienie jest bardzo szybkie, serio, jakby z 20-30FPS miało. Zawsze w poziomie i tylko w poziomie. Drugi błąd to trzęsienie i miganie obiektów. Trzęsienie widać na podsypkach, jakby na zmianę rysowały się 2 wersje podsypek nieco przesunięte. To zmienia się wolno, od 1 do kilku razy na sekundę. W niektórych miejscach efekt jest bardzo intensywny. To było w MaSzynie od zawsze, i podobno nie da się nigdy poprawić. Nie da się? Ale jest jeszcze druga wersja tego samego problemu jednakże jeszcze bardziej irytująca: ustalanie czy obiekt jest za czy przed innym. To powoduje, że niektóre obiekty pojawiają się i znikają raz do kilku razy na sekundę, albo zależnie od kąta patrzenia kamery. Stoję sobie na peronie i widzę jak miga budynek czy nawet kawałek górki. Jeśli kamera jest nieruchoma i obiekty są nieruchome - dlaczego poruszają się pomiędzy kolejnymi klatkami?
Trzęsienie w poziomie nie jest niestety błędem wersji tylko z shaderami. Gdybyś miał słabsza kartę graficzną i zapakował 16 krotny antyaliasing, następnie odpalił Kaliską to miałbyś szansę zobaczyć jak trzepie scenerią (nie kabiną!) w Ostrowie Wielkopolskim na exe od @tmj. Do tego, człowiek nie jest w stanie ocenić wzrokowo skakanie 30hz, bo od 16 klatek masz postrzeganie płynnego ruchu, co wykorzystuje się w kinie. Przy 30 hz, powinieneś zobaczyć pływanie scenerii w poziomie, nie trzęsienie. Albo źle to oceniasz, albo masz jakiś zwierzęcy wzrok;)
Miganie podsypek, utworzyłem nowy wątek w tej sprawie, nie zabrałeś głosu...
Exe dla stojącego obrazu liczy co jakiś czas i za każdym razem wychodzi to liczenie inaczej (zaokrąglenia?), stąd zastany obraz miga.
Natomiast miganie budynków nigdy u mnie nie występowało, stąd jeśli takie coś zauważysz, bardzo proszę o zrobienie screena z jakiego miejsca to widać, podanie jaka sceneria/stacja. Spróbuje powtórzyć ten efekt.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 29 Marca 2017, 12:54:27
@tmj, pomyliłeś mnie i Antka, ale spoko.
A to sorry :) Wydawalo mi sie, ze to ty pisales o koniecznosci wywalenia eventow i zastapienia ich czyms praktyczniejszym, i ze robiles ku temu jakies przymiarki..?

Jak wyglądają plany połączenia różnych wersji exe? Czy jest szansa, że w najbliższej przyszłości znikną wersje DL / VBO z shaderami i bez? Do ostatniej wersji NG wersja VBO miała problemy z oświetleniem na niektórych sceneriach, szczególnie L053, zauważyłem, że ostatnia wersja chyba rozwiązała ten problem, za to na x64 połowa scenerii się wysypuje bez VBO. Skoro VBO już jakoś działa a DL się teraz sypie, może porzucić DL na dobre?
Wersja VBO nie wywala sie, bo nie ma w niej kodu ktory jest za to odpowiedzialny (tworzenie geometrii skrzyzowan drog) :d Ale ze dziur w drogach raczej zostawic nie mozna, to trzeba to bedzie ewentualnie zaimplementowac, i wtedy albo wersja VBO tez sie zacznie wysypywac, albo zrobi sie to porzadnie, z poprawieniem bledow, i wtedy niejako przy okazji wersja DL wysypywac sie przestanie. Sciezka VBO ciagle jeszcze ma pare rzeczy ktore wymagaja sprawdzenia (np trakcja generuje tez jakies dziwne fruwajace odpadki) wiec natychmiastowe przejscie wylacznie na nie byloby imo troche przedwczesnie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 29 Marca 2017, 13:06:42
No, mnie raczej chodziło, że pisałeś bezpośrednio pod postem Stele w pierwszej osobie liczby pojedynczej, a więc do niego, a treść była do mnie. Ja owszem pisałem, że się tym bawię.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 29 Marca 2017, 13:14:36
Masz racje, polaczylem w pospiechu dwie rzeczy, bo ten drugi paragraph byl do ciebie w zwiazku z zakonczeniem poprawiania skanowania itp, ale nie pomyslalem zeby zaadresowac prawidlowo, i tak wyszlo. Jak najbardziej chodzilo mi tam o ciebie :)

edit: ok, w dzisiejszym uaktualnieniu jest zaimplementowane rysowanie slonca i ksiezyca. Ksiezyc nie jest moze tak ladny jak w wersji testowej, ale bardziej zblizony do rzeczywistosci, cos za cos. Tutaj od razu zwracam uwage, ze niedawno byl now, wiec przy ustawieniu movelight 0 (czyli pobieraniu biezacej daty z zegara systemowego) przez najblizsze kilka dni w symulatorze w nocy nie bedzie za wiele do ogladania.

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 29 Marca 2017, 18:03:53
exe z gammą srgb https://ci.appveyor.com/project/Milek7/maszyna/build/9/artifacts
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 29 Marca 2017, 18:17:25
Jupi, księżyc. :) Te ciała niebieskie są "tak o" póki co, czy liczyłeś im szerokości kątowe? Słoneczko to kwestia dyskusyjna ile tam gwiazdy a ile poświaty, ale księżyc wydaje mi się dużo za duży. Albo ja źle policzyłem i się przyzwyczaiłem do małego.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 29 Marca 2017, 18:23:41
Technicznie rzecz biorac sa istotnie duzo za duze :)  Dla porownania wymiary 'realistyczne' maja uproszczone sfery ktore rysowane dodatkowo w trybie debug, ale faktyczne billboardy zrobilem wieksze, raz ze wzgledow 'artystycznych' a dwa, ze slonce do pewnego stopnia jest wieksze ze wzgledu na poswiate, a ksiezyc jest do tego mniej wiecej dopasowywany, bo ogladane z Ziemi oba ciala sa prawie identyczne.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 29 Marca 2017, 19:11:54
exe z gammą srgb https://ci.appveyor.com/project/Milek7/maszyna/build/9/artifacts (https://ci.appveyor.com/project/Milek7/maszyna/build/9/artifacts)
Jest lepiej.:) Dążył bym do osiągnięcia jak na pierwszym załączniku. Czoło Traxxa jest szczegółowe mimo jasnej powierzchni, wczorajsza kompilacja od @tmj. Załącznik drugi, to kompilacja z przed godziny od @Milek7. Tu Traxx na czole ma dość mizerny wygląd, szczegóły zostały wyżarte. Jak mówię, od wczoraj jest poprawa, do ideału jeszcze troszkę.
@tmj, księżyc jest miodzio, nawet taki wielki.
Cytuj
...sugerowalbym zamienic wpis w scenerii ze sky_dynamic_stratus.t3d na skydome_clouds.t3d bo inaczej niedlugo bedziesz mial na niebie dwa ksiezyce i dwa slonca ;d
Tu natrafiam na problem, po zamianie wpisu w pliku scn na TD, nie ładuje mi składu. Sceneria odpala się w trybie freefly. Może znów coś nie dopatrzyłem?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 29 Marca 2017, 19:23:31
Tu natrafiam na problem, po zamianie wpisu w pliku scn na TD, nie ładuje mi składu. Sceneria odpala się w trybie freefly. Może znów coś nie dopatrzyłem?
Trudno tak na slepo powiedziec, u mnie ten kawaled w td.scn wyglada tak:
sky skydome_clouds.t3d endsky

edit:
@Milek7 nie mam zadnej pewnosci, ale ta mieszana wersja z fixed pipeline moze robic korekte srgb we wlasnym zakresie. Zobacz z ciekawosci jak to bedzie wygladalo jesli ustawisz SRGB w teksturach tak jak masz teraz, ale wylaczysz hint SRGB dla ekranu glfw? Teoretycznie powinno wtedy skorygowac gamme tekstur do obliczen, a po obliczeniach poprawi sobie samo w ramach swojej 'fixed pipeline', moze?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 29 Marca 2017, 19:25:08
Tmj patrzyles na crushdumpa z l053 czemu wywalilo od tak sobie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Lorem w 29 Marca 2017, 19:25:35
Pierwsze spostrzeżenia z działania exe ng build 9 (srgb gamma). Na plus: z miernikami/białymi powierzchniami jest lepiej, dużo mniej przepalone w stosunku do poprzednich wersji. Wciąż jednak są trochę przepalone, w porównaniu chociażby do buildów @tmj. Na minus: w nocy nie robi się ciemno, ponadto kolor zmieniło tło pod obrazkiem ładowania, przez co jest wyraźne odcięcie między zieleniami.

Ogólnie wrażenie jest takie, że oświetlenie jest subtelniejsze. Kolory trochę mniej nasycone, cienie mniej ostre. Szyby mniej przezroczyste.



@tmj, księżyc ładny, ale dla mnie jednak dość mocno za duży. No i na żywo gołym okiem nieoświetlonej części zupełnie nie widać.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 29 Marca 2017, 19:46:42
Tmj patrzyles na crushdumpa z l053 czemu wywalilo od tak sobie.
Sprawdzalem, ale to cos nietypowego jest, pierwszy raz to widze I ciezko dojsc co konkretnie sie sypie. Masz tak za kazdym razem, czy to cos jednorazowego bylo?

No i na żywo gołym okiem nieoświetlonej części zupełnie nie widać.
Do pewnego stopnia zalezy to chyba od pozostalego oswietlenia; no i golym okiem takich rzeczy jak flary tez nie widac, a w symulatorze sa ;)  Czasem realism mozna troche nagiac, dla efektu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Robert83 w 29 Marca 2017, 20:39:18
Witam, w załączniku screeny z nocy - dlaczego mam całe niebo w bez chmur w jednym kolorze?

W .ini w sekcji Maszyna mam wpis : movelight 0

Na scenerii l053-sluzba-4-night po dojechaniu w perony z bocznego toru EP07 pośpieszny (zapętliło mi się audio "zgłaszam" i tak cały czas się powtarza i nie mogę tego wyłączyć.
Sceneria strasznie drży w poziomie przy wjazdach na inne tory

Mam najnowszą wersję od : @Milek7
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 29 Marca 2017, 20:47:18
edit:
@Milek7 nie mam zadnej pewnosci, ale ta mieszana wersja z fixed pipeline moze robic korekte srgb we wlasnym zakresie. Zobacz z ciekawosci jak to bedzie wygladalo jesli ustawisz SRGB w teksturach tak jak masz teraz, ale wylaczysz hint SRGB dla ekranu glfw? Teoretycznie powinno wtedy skorygowac gamme tekstur do obliczen, a po obliczeniach poprawi sobie samo w ramach swojej 'fixed pipeline', moze?
Najpierw tekstury są konwertowane z sRGB do liniowego RGB, później przy wyświetlaniu na framebuffer jest konwertowane spowrotem na sRGB. (czyli wracamy do tego co było, tylko chodzi o to żeby shadery oświetlenia operowały na liniowym RGB). Jak pominę końcową konwersję na sRGB to jest zdecydowanie za ciemno.

Jesteście pewni że to co jest na starym exe jest prawidłowe? Przy słonecznym dniu promienie odbite od jasnej blachy mogą nieźle razić, więc to lekkie przepalenie wydaje mi się całkowicie normalne.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 29 Marca 2017, 20:59:17
Najpierw tekstury są konwertowane z sRGB do liniowego RGB, później przy wyświetlaniu na framebuffer jest konwertowane spowrotem na sRGB. (czyli wracamy do tego co było, tylko chodzi o to żeby shadery oświetlenia operowały na liniowym RGB). Jak pominę końcową konwersję na sRGB to jest zdecydowanie za ciemno.
No wlasnie chodzi mi o to, czy konwersja w druga strone nie robi sie czasem dwa razy -- raz na karcie w ramach jej wlasnej emulacji fixed pipeline czy czego tam sobie uzywa, a drugi raz dodatkowo w ramach ustawienia SRGB dla bufora docelowego. Nie bardzo chce mi sie sciagac calosc i kompilowac tutaj zeby zobaczyc jak by to wygladalo bez ;/

Cytuj
Jesteście pewni że to co jest na starym exe jest prawidłowe? Przy słonecznym dniu promienie odbite od jasnej blachy mogą nieźle razić, więc to lekkie przepalenie wydaje mi się całkowicie normalne.
Moze tutaj tez mieszac wlaczony komponent specular, bo na zwyklym go nie ma, a to tez swoje daje. Tzn nie w sense ze w rezultacie jest zle, tylko inaczej.

edit
Sceneria strasznie drży w poziomie przy wjazdach na inne tory
Czekaj czekaj, drzy, czy w sense ze kamera idzie ostro w bok na rozjazdach itp? Bo jak to drugie to akurat "feature" jest, na kierujacego bardziej dzialaja sily przyspieszenia itp, a to sie akurat najbardzie na rozjazdach objawia.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 29 Marca 2017, 21:06:51
Zrobiłem jeszcze zrzut starego exe. Trzeba pamiętać, że ten "biały" kolor nie ma nic wspólnego z wizirem. To zawsze będzie pewien brudny odcień. Dodatkowo nie wydaje mi się konieczne oślepianie z ekranu który jest zwyczajnie tępy. Oko ludzkie ma możliwość akomodacji, w warunkach rzeczywistych przymykają się źrenice. Przy przepalonym ekranie nie pomogą już nawet okulary słoneczne. Trochę jak z łamaniem pantografu, jest w przyrodzie, ale w symulatorze nic nie przyniosło.
Parę osób już pisało o przepaleniu, pokaż może tą zbyt ciemną wersję z pominięciem końcowej konwersji na sRG.
Może jeszcze ktoś się wypowie.

 
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 29 Marca 2017, 21:19:14
https://milek7.pl/.stuff/eu07scr/ciemno.png
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Robert83 w 29 Marca 2017, 21:29:11
Cytuj
Czekaj czekaj, drzy, czy w sense ze kamera idzie ostro w bok na rozjazdach itp? Bo jak to drugie to akurat "feature" jest, na kierujacego bardziej dzialaja sily przyspieszenia itp, a to sie akurat najbardzie na rozjazdach objawia.

Właśnie to że idzie w bok jest super, ale ja mam też efekt drgania, nawet przy 10km/h. Wszystko widać podwójnie jak ktoś już pisał o tym w tym temacie :)

Moim zdaniem niebo w ng++ też jest za bardzo jasne :)

Moim zdaniem niebo od @tmj  tak właśnie powinno wyglądać ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 29 Marca 2017, 21:30:41
Z tego co widze, bez konwersji niebo wyglada jak trzeba, a modele sa zbyt ciemne. To by sie pokrywalo z tym co widze porownujac u siebie, niebo na ng++ jest sporo jasniejsze co widac dobrze w nocy (zalacznik)

Warto by tam chyba dodac glEnable/Disable(GL_FRAMEBUFFER_SRGB) na czas renderowania obiektow environment, jest szansa ze to wyprostuje przynajmniej czesc roznic.

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 29 Marca 2017, 21:33:07
A no tak, bo kolory nieba masz pewnie podane w sRGB, a to próbuje wziąć jako liniowe i przekonwertować jeszcze raz do sRGB.

(zaraz poprawię, chociaż subiektywnie patrząc to niebo o 13 to mi się wydaje że jest jaśniejsze, no ale teraz w nocy jest zbyt jasno)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 29 Marca 2017, 21:36:41
http://eu07.pl/userfiles/1234/foto-07or.PNG (http://eu07.pl/userfiles/1234/foto-07or.PNG)
Dla porównania ze starym exe wklejam taki sam zrzut. Z Twojego screena ciężko coś powiedzieć o światłach (mówię w sensie fotograficznym), ten przód Traxxa nie przypadkiem dałem jako przykład. U Ciebie jest spore nasycenie kolorów, tu szczególnie ciemnej zieleni, co daje poczucie przyciemnego światła.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 29 Marca 2017, 22:16:04
A tak a propos wielkosci ksiezyca, zaladowalem sobie linie 61 i zobaczylem to co w zalaczniku. Jak wam taki nie przeszkadzal, to nie chce nic slyszec o wielkosci nowego :P

(w nastepnym uaktualnieniu nowy ksiezyc bedzie troche mniejszy, ale tylko troche, bo lepiej chyba ewentualnie zmniejszyc go na teksturze jak sie komus bedzie koniecznie chcialo, a geometrie zostawic z zapasem, na ewentualny glow albo inne bajery)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 29 Marca 2017, 22:17:21
Ten właśnie mnie zmotywował do wrzucenia ruchomej kulki na niebo. ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 29 Marca 2017, 22:40:26
No dajcie ksiezyc o normalnej srednicy te 315kkm od ziemi - bedzie spokoj z wymiarami :-)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Lorem w 29 Marca 2017, 22:56:48
To jeszcze a propos księżyca - światło pochodzące od niego zanika skokowo - w jednej sekundzie jest, w następnej znika zupełnie. Widać to wyraźniej na exe od Milka (Mileka?), gdzie światło księżyca w ogóle jest bardzo intensywne. Zbyt intensywne, w przeciwieństwie do exe tmj, gdzie efekt jest bardzo subtelny. Tak czy inaczej skok jasności występuje na obu.

golym okiem takich rzeczy jak flary tez nie widac, a w symulatorze sa ;)  Czasem realism mozna troche nagiac, dla efektu.
No może i dla efektu... Ja sobie flarę przerobiłem na taką okrągłą aureolkę, bardziej naturalną. A przynajmniej chciałem, bo potem jak się zaczęły nakładać te tekstury dla dwóch komór semafora, to wyglądało to paskudnie. Podobnie zresztą podczas świtu/zmierzchu, gdy zmienia się widoczność tej tekstury, przez co spłaszcza się dynamika przezroczystości i zamiast rozmywać się delikatnym gradientem, to brzeg jest ostry. I zamiast subtelnej aureoli robiło się brzydkie kółko. (obecna tekstura zresztą cierpi na te same problemy, tylko ze względu na kształt flary jest to dużo mniej... rażące)
W każdym razie to by chyba tłumaczyło, czemu wolałbym naturalny księżyc :P A ten na ostatnim Milekowym exe akurat wyświetla się bardzo ładnie!
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 29 Marca 2017, 23:05:25
No dajcie ksiezyc o normalnej srednicy te 315kkm od ziemi - bedzie spokoj z wymiarami :-)
No dac prawdziwe wymiary to nie problem, tylko wtedy z lupa go bedziesz szukac :d

(w zalaczniku wersja obecna po malym zmniejszeniu, a to male kolko w srodku to wielkosc 'realistyczna')

edit:
W każdym razie to by chyba tłumaczyło, czemu wolałbym naturalny księżyc :P
Zaladuj moon.tga z katalogu textures/fx i zeskaluj poszczegolne wersje tak jak ci pasuje, nie zajmie chyba wiecej niz pare minut~

edit2:
aha, a miana jasnosci jest skokowa, bo na slonce i ksiezyc przydzielone jest jedno 'wspolne' zrodlo swiatla, i skok wystapi w momencie przelaczenia, gdy slonce schodzi ponizej horyzontu. Zdarza sie na tyle rzadko, ze bylo to bardziej praktycznie niz marnowanie swiatla, ktore mozna zamiast tego miec na lokomotywie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 29 Marca 2017, 23:10:20
Tym czasem ogarnąłem to przepalenie na exe od Milka7. Pogrzebałem w bibliotekach fixedpipeline jak radził i wyszło jak na załączniku. Jakieś sugestie?
ED:
To co poprawiłem wrzucam w załącznik. Rozpakować i folder shaders wrzucić do katalogu z symulatorem. Nadpisuje pliki, jak komuś zależy, niech zrobi kopię zapasową.
ED2:
Na tym co dałem w załączniku, powinno być nieco jaśniej niż na screenach.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Lorem w 30 Marca 2017, 00:01:59
Jest dobrze. Efekty wizualne (pod względem kolorystyki, jasności, braku przepaleń) bardzo zbliżone do exeków nie-shaderowych.

Co do szyb na ostatnim exe ng, szczególnie widać to, gdy jest ciemno i zapali się światło w kabinie. Fajnie, że wtedy widać gorzej otoczenie, ale czasami efekt jest dość... ekstremalny. Przykład - EP09.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 30 Marca 2017, 01:41:22
Pogrzebałem w bibliotekach fixedpipeline jak radził i wyszło jak na załączniku. Jakieś sugestie?
Jak juz chce ci sie bawic w edycje shaderow, to opcjonalnie mozesz jeszcze zmienic:
float outerCutoff = light.spotCosCutoff - 0.03;
float epsilon = light.spotCosCutoff - outerCutoff;
na
float outerCutoff = 0.991444f;
float innerCutoff = 0.999657f;
float epsilon = innerCutoff - outerCutoff;
(w exe c++ swiatla lokomotyw maja ustawiona na sztywno rozwarcie stozka swiatla na 7.5 stopnia w kazda strone, a wersja ng rysuje stozek, ktory ma 7.5 stopnia o maksymalnej jasnosci, a do tego nastepne 7.5 stopnia miekkiej krawedzi. Po tej zmianie swiatla powinny byc bardziej zblizone do wersji c++ tzn z miekkim przejsciem od jasnej 'osi' do ciemniejszych krawedzi, ale o maksymalnej szerokosci 7.5 stopni.

Zasieg swiatla tez jest inny, bo dla spotlight jest kontrolowany przez spot_exponent ktory nie jest uwzgledniony w obliczeniach, ale to juz na kiedy indziej, jesli w ogole).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 30 Marca 2017, 11:10:06
Zamieniłem linijki według podanego przykładu, stożek nieco się zawęził. Aktualizacja w załączniku. Do wypakowania w katalogu głównym. Czy można wierzchołek stożka uciąć, światło wychodzi teraz jakby ze sprzęgu?
Szyby w EP09 wyglądają u mnie inaczej, to pewnie w zależności od wpisów atmo i ligth.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 30 Marca 2017, 13:20:38
Czy można wierzchołek stożka uciąć, światło wychodzi teraz jakby ze sprzęgu?
Mozna ukryc, na kilka sposobow -- albo prymitywnie, wsuwajac swiatlo troche glebiej 'w lokomotywe'. Albo pol-prymitywnie, kalkulujac odpowiednio sile oswietlenia zaleznie od odleglosci od zrodla swiatla. Albo pojsc na calosc, i modulowac sile swiatla przypisana tekstura. Sklanialbym sie ku temu ostatniemu, bo to umozliwiloby tez takie efekty jak zmiana smugi w zaleznosci od zapalonej kombinacji swiatel, ale z tym warto sie bawic chyba dopiero gdy beda w exe shadery pracujace z pelna predkoscia, bez spowolnienia ktore mamy obecnie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: sawe w 30 Marca 2017, 16:57:39
Witam.
Od eu07++170301 nie można dopiąć loka do składu ( Shift+Insert). Nie wiem czy to jest jakiś błąd, czy służą do tego inne klawisze. Dodam, że AI nie ma z tym problemu.
Z góry dziękuję za odpowiedź.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 30 Marca 2017, 17:02:46
Zglaszasz blad w jakims wydaniu exe z przed miesiaca. Nie lepiej pobrac najnowsze exe?


Ed:
Chyba przeczytalem co drugie slowo w poscie @Sawe. Trzeba odespac zarwane noce;)
Prosze na bocznice.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 30 Marca 2017, 17:03:12
Sprobuj samym Insert, ktory po kazdym nacisnieciu powinien podlaczyc po kolei hak, przewody itp. Przy niektorych sprzegach sklad musi byc dobrze scisniety razem, zeby zaskoczylo, moze tego brakowalo?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: sawe w 30 Marca 2017, 17:20:55

Zglaszasz blad w jakims wydaniu exe z przed miesiaca. Nie lepiej pobrac najnowsze exe?

Od eu07++170301 do najnowszego jest tak samo. Wciśnięcie Shift+Insert czy tylko Insert skutkuje nagłym hamowaniem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 30 Marca 2017, 17:36:09
Postawilem na TD zestaw EP07 + kilka pasazerskich. Odlaczylem lokomotywe, odjechalem kawalek, cofnalem, docisnalem i wcisnalem Insert ( w widoku zewnetrznym, blisko sprzegu) polaczylo sie bez problemow. Shift + Insert nie jest obslugiwany, natomiast samo Insert dziala jak najbardziej.

Nie bardzo rozumiem ten kawalek o naglym hamowaniu, nie obserwuje u siebie niczego takiego. Opisz dokladniej okolicznosci jesli mozesz, czy brak laczenia wystepuje wszedzie, czy w jakiejs okreslonej sytuacji, na konkretnym scenariuszu itp?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: sawe w 30 Marca 2017, 18:16:42
Brak łączenia występuje wszędzie, na starszych exe to nie występuje. Korzystam z systemu win xp, być może dlatego, nie mam pojęcia.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 30 Marca 2017, 18:22:11
Brak łączenia występuje wszędzie, na starszych exe to nie występuje. Korzystam z systemu win xp, być może dlatego, nie mam pojęcia.
A jak zaladujesz sklad na TD i odlaczysz tam lokomotywe przez Delete na sprzegu, to polaczy z powrotem jak nacisniesz Insert, czy tez nie?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: sawe w 30 Marca 2017, 18:36:51
Odłącza dobrze, odjeżdżam kawałek, dojeżdżam, wciskam Insert i sprzęg nie chce zaskoczyć tylko słychać syk powietrza i lok zahamowany na ful.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 30 Marca 2017, 19:05:44
Brzmi raczej dziwnie, i u siebie tego nie obserwuje, wiec trudno bedzie dojsc przyczyny (tzn jesli wystepuje od poczatku marca to prawdopodobnie ma cos wspolnego z przejsciem na GLFW, ale jesli nikt inny tego nie ma, to juz nie jest takie proste)  Czy to jest na zwyklej klawiaturze z blokiem Ins, Del, Home, End itd, czy moze na jakims laptopowym wynalazku laczacym rozne funkcje?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: sawe w 30 Marca 2017, 19:22:05
Normalna klawiatura przy stacjonarce. Zainstaluję na nowo symulator i sprawdzę czy będzie dobrze.
Dziękuję serdecznie za odpowiedzi.
Dodam jeszcze, że AI dołącza się bez problemu, dotyczy to zarówno lokomotyw elektrycznych jak i spalinowych.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 30 Marca 2017, 19:28:14
Przydalby sie plik log.txt. Mozna by zobaczyc jak wyglada to wciskanie insertu w logowaniu. Jak dostane sie do komputera, to sprawdze laczenie sprzegow u siebie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: sawe w 30 Marca 2017, 20:37:30
Załączam log.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 30 Marca 2017, 21:29:37
Nie mam żadnych problemów z podłączaniem lokomotywy. Jedyne co przychodzi mi do głowy, to uszkodzenie klawisza insert, ale skoro na starych exe to działa... W załączniku log z uruchomienia TD. Powiem, tak: jestem zaskoczony brakiem logowania klawiszy w txt. Zwykle można było ocenić uruchamianie lokomotywy po sekwencji logowanych klawiszy. Trudno, u mnie jest ok i nie mam pojęcia co jest przyczyną.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 30 Marca 2017, 21:32:42
Obawiam sie ze log niestety nic nam nie da, bo jakis czas temu wycielismy informacje o wciskanych klawiszach (bo sie nikomu nie chcialo przerabiac na GLFW czegos, co wydawalo sie malo potrzebne), i teraz jest jak jest :d
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 30 Marca 2017, 21:34:00
Wciskane klawisze w logu to podstawa supportu przy "lokomotywa mi nie działa! Co zrobić???" o ile takowy umie załączyć log. ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 30 Marca 2017, 21:36:52
Moja wina, nie było to konieczne do działania to pominąłem :P
Możesz tam dodać, glfw ma nawet glfwGetKeyName. Ja już sobie obiecałem że nie będę dzisiaj włączał VMki z windowsem żeby mnie nie odciągało od innych rzeczy :D
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 30 Marca 2017, 21:38:41
No nie tylko twoja bo mi sie tez nie chcialo tego wszywac z powrotem ;>  Zobacze czy da sie cos tam wyprodukowac.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 30 Marca 2017, 21:54:32
Aha, jeszcze zapomniałem wspomnieć o ważnej rzeczy w obecnem sterowaniu na GLFW.
Z tego co widziałem w poprzednim kodzie to sterowanie było przypisane konkretnie do literek, czyli jak ktoś zmieni sobie układ klawiatury, to mapowanie przemieści się razem z literką na danym układzie. Obecnie mapowanie jest przypisane do konkretnych klawiszy na standardowej klawiaturze QWERTY, więc sterowanie jest niezależne od układu klawiatury.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 31 Marca 2017, 00:51:27
OK, przyczepilem z powrotem na szybko logowanie wcisnietych klawiszy. W sumie troche strata czasu, bo bralem sie akurat ze przepisanie sterowania, i za pare dni bedzie to wygladac inaczej, ale poki co jest :P

(w ramach premii jest tez obiecany troche mniejszy ksiezyc)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 31 Marca 2017, 09:24:31
Sekwencja klawiszy przy podczepianiu:
Key pressed: [F4]
Key pressed: [Num +]
Key pressed: [Num
Key pressed: [R]
Key pressed: [Num +]
Key pressed: [Insert]
Key pressed: [Insert]
Key pressed: [Insert]
Key pressed: [F4]
Key pressed: [D]
Key pressed: [Num +]
Key pressed: [F3]
EVENT ADDED TO QUEUE: tdo_rez_shp by ep07-426-ep
Key pressed: [F4]
EVENT LAUNCHED: tdo_rez_shp by ep07-426-ep
Type: PutValues
Na TD.scn, podczepianie siódemki, bez problemów.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 31 Marca 2017, 19:57:46
Tak nawiasem mowiac, w exe od dluzszego czasu jest aktywna obsluga drzwi odskokowo-przesuwnych, ale wagony 16x z paczki calosciowej z tego nie korzystaja (chyba, ze byla pozniej jakas aktualizacja) Po zmianie wpisu w .fiz na
DoorMaxShiftL=0.9 DoorMaxShiftR=0.9 DoorMaxShiftPlug=0.05 DoorOpenMethod=Plug
efekt jest jak na zalaczniku, zamiast wcinania sie w pudlo, jak ma to miejsce przy ustawieniach animacji przesuwnej z paczki.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 31 Marca 2017, 20:10:02
Rzeczywiście nie było dopisane. Dodałem do repo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 31 Marca 2017, 21:37:27
Blad na l053 się powtorzyl w tym samym miejscu. Może ktoś sprawdzić przejezdność? L053 sl3 za Rudawa a przed Zernikami wywali nagle do windowsa. Exe to najnowsze i to poprzednie od TMJ.

TMJ zajzyj co ci pokazuje. Ostatnie eventy to jakies przejazdowe. Może one cos powodują?

Type: UpdateValues - SetVelocity -1.000000 -1.000000
EVENT LAUNCHED: przejazd49_go2 by ep07-1008
Type: UpdateValues - SetVelocity -1.000000 -1.000000
EVENT LAUNCHED: przejazd49_rog1off by ep07-1008
EVENT LAUNCHED: przejazd49_rog2off by ep07-1008
Key pressed: [Num -]
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 31 Marca 2017, 22:25:23
Rzeczywiście nie było dopisane. Dodałem do repo.
Przecież było, jako ostatni wpis w drzwiach. Weź posprzątaj teraz.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mk1991 w 01 Kwietnia 2017, 13:34:07
Nie działa zawijanie programatora świateł. W Traksie można było kręcić w kółko i po dojściu do końca listy nie wraca na początek.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Kwietnia 2017, 14:20:23
Faktycznie, zgubil sie odczyt wartosci Wrap i jej podobnych; bedzie naprawione w nastepnym uaktualnieniu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mk1991 w 01 Kwietnia 2017, 14:39:36
Witam. Przyszedł czas na mnie. Po pierwsze. Mam wrażenie, że dźwięk sprężarki jest głośniejszy od tego samego w exekach borlandowych. Bardzo płynnie działa dźwięk nastawnika i bocznika. Mam za to problemy z nawigacją po widoku zewnętrznym i kamery w kabinie, kiedy działa mój czytnik ekranu. Jeśli go zresetuję, to wszystko wraca do normy. Coś takiego dzieje się na exe od @milek7.
Dalsze spostrzeżenia wkrótce.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Kwietnia 2017, 15:05:36
Blad na l053 się powtorzyl w tym samym miejscu. Może ktoś sprawdzić przejezdność? L053 sl3 za Rudawa a przed Zernikami wywali nagle do windowsa. Exe to najnowsze i to poprzednie od TMJ.

TMJ zajzyj co ci pokazuje. Ostatnie eventy to jakies przejazdowe. Może one cos powodują?
To raczej nie jest powiazane z eventami jako takimi, wysyp jest przy probie wygenerowania geometrii jakiegos tam toru, w trybie VBO.

Sam nie bardzo jestem w stanie to zweryfikowac, bo po uruchomieniu scenariusza stoje sobie w szopie i nic sie nie dzieje. Uruchomilem loka, gotowy do jazdy ale przez 10-15 min nie dostaje w ogole sygnalu manewrowego ani nic. Nie wiem czy tam cos trzeba jeszcze zrobic, ale troche to nieintuicyjne jest :d
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 01 Kwietnia 2017, 19:12:47
No wcisnąć jakieś Shift+1 czy coś. Poprawiałem to, w mojej wersji nie trzeba. Ale i tak na exe 330 u mnie nie działa. Wyjeżdżam z szopy, dojeżdżam do tej tarczy przed peronami i na tym koniec. Okazuje się, że AI, które miało podstawić wagony stoi jak głupie na starcie i nawet nie rusza. (Testowałem na wersji x64, VBO).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 03 Kwietnia 2017, 15:37:28
Pytanie w ramach grzebania w sterowaniu -- jak w rzeczywistosci wyglada obsluga lokomotywy w kontekscie pulpitow sterujacych? Tzn, powiedzmy ze w np. EU07 sa dwie kabiny, kazda ma swoj wlasny pulpit. I teraz jak lokomotywa "wie", ktory pulpit wziac pod uwage jesli chodzi o stan przelacznikow, nastawnikow itp? Czy od tego tez jest jakis przelacznik albo cos?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Kacper9 w 03 Kwietnia 2017, 16:24:32
Chyba po wyłączniku rozrządu. Przynajmniej tak widzę jeżdżąc w TD2.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 03 Kwietnia 2017, 20:51:05
Tak, po lewej stronie pulpitu w obu kabinach jest wyłącznik rozrządu, który dla przykładu w EU07 4E zamyka obwody: piasecznicy, rozrządu pantografów, cewki nn przekaźnika samoczynnego rozruchu (w rzeczywistości już niestosowanego), stycznika rozrządu AC1 (podanie zasilania na sterowanie m.in. stycznikami oporowymi i bocznikowania), załączenia wyłącznika szybkiego, wyłączenia wyłącznika szybkiego, rozrządu styczników ogrzewania pociągu, rozrządu styczników przetwornic, rozrządu styczników sprężarek, rozrządu styczników wentylatorów oporów rozruchowych, odblokowania przekaźników nadmiarowych ogrzewania pociągu i przetwornic, odblokowania przekaźników nadmiarowych silników sprężarek i wentylatorów oporników rozruchowych (na podstawie książki "Lokomotywy elektryczne serii EU06 i EU07"). Oryginalnie wyłącznik ten był przełączany za pomocą specjalnego klucza, który dało się wyciągnąć tylko w pozycji wyłączonej, co uniemożliwiało załączenie rozrządu z dwóch kabin jednocześnie (jak w przypadku nastawnika kierunku), ale obecnie w większości lokomotyw (o ile nie we wszystkich) klucz ten da się wyciągnąć także w pozycji załączonej wyłącznika. W części lokomotyw jest też zamontowane zwykłe pokrętło wyłącznika krzywkowego.
Jeśli np. w kabinie B ustawi się nastawnik kierunku w pozycję "w tył" i nastawnik jazdy na którąś pozycję, a następnie będzie się chciało prowadzić lokomotywę z kabiny A do przodu, można uzyskać ciekawy efekt, ale takie kombinacje to już zagłębianie się w obwody...
Edit: Możliwe nawet, że da się przejść na drugi układ z załączonym wysokim rozruchem w drugiej kabinie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 03 Kwietnia 2017, 21:28:30
Wrócę do testów. Postawiłem świeżo  WIN xp na kompie z AMD Sempron 3100 i kartą graficzną GF9500GT Wgrałem najnowsze sterowniki I oczywiście VC redist 2008, 2013 i 2015. System jest 32 bitowy i dysponuje 2,5GB pamięci ram DDR.
Oto wyniki. TD: 190 FPS, bez antyaliasingu, 75 FPS z antyaliasingiem x16.
Kaliska: 6FPS na dzień dobry po dopaleniu scenerii zaczynającej się w Kiblu (wiem że źle brzmi), bez anty aliasingu. Uznałem, że z antyaliasingiem nie będę tego odpalał. OpenGL3.3. Mimo niskiego FPSu, nie trzęsło w poziomie a jazda aczkolwiek poklatkowa, jest możliwa. EXE 170330. Włączone 5 źródeł światła w ini. Czeka mnie jeszcze odpałka na Milkowym exe co zaraz postaram się uczynić.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 03 Kwietnia 2017, 21:36:47
To jest jakby nie patrzec sprzet ~10 letni, wiec cudow specjalnie spodziewac sie nie mozna, ale 6 fps to troche nisko :)  Chociaz mozliwe, ze tutaj waskim gardlem jest ilosc pamieci, 9500GT mialy 0.5-1gb max czy cos kolo tego.
Z ciekawosci, jesli chce ci sie bawic, zobacz czy cos zmieni ograniczenie liczby zrodel swiatla do 3, i maksymalnego wymiaru tekstur do np 1024. A tak dla porownania, jak sobie w tej sytuacji radzi Borlandowe exe?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 03 Kwietnia 2017, 22:46:34
Na dzis tylko borlandowe,  wynik na TD bez wygladzania 60, z wygladzaniem x16 - 30fps. Skalowanie tekstur 1024, na borlandowym nie poprawilo wydajnosci wyswietlania. Podobne wyniki na TD uzyskalem na 170430, ale tu na TD skalowanie nie ma zbyt duzego sensu, bo tekstur jest malo. Kaliska przerobie jutro, nie ma zbyt juz czasu dzisiaj, ale checi sa.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: vikinq w 03 Kwietnia 2017, 22:58:36
U mnie na AMD Phenom X4 II b95 i Palit GT730 4GB większość scenerii to max 30 kl/s na ustawieniach x4 wygładzanie i rozdzielczości 1440x900 . Przy normalnym exe to jest stałe 60 kl/s. U mnie przy próbie uruchomienia jakiejkolwiek scenerii na Bałtyku od razu wysyp, a niektóre scenerie potrafią się wysypać w różnych miejscach.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 03 Kwietnia 2017, 23:31:15
U mnie na AMD Phenom X4 II b95 i Palit GT730 4GB większość scenerii to max 30 kl/s na ustawieniach x4 wygładzanie i rozdzielczości 1440x900 . Przy normalnym exe to jest stałe 60 kl/s. U mnie przy próbie uruchomienia jakiejkolwiek scenerii na Bałtyku od razu wysyp, a niektóre scenerie potrafią się wysypać w różnych miejscach.
Z tego co widze w logu to jest przy wersji NG, czyli z przejsciowymi shaderami; tutaj malo kto ma wiecej niz 30 fps :) Piszac normalne exe masz na mysli wersje Borlandowa z paczki calosciowej? Jesli tak, to jak u ciebie wyglada dzialanie wersji c++ bez shaderow? (do pobrania z pierwszego postu w watku http://eu07.pl/forum/index.php/topic,28920.0.html
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: vikinq w 04 Kwietnia 2017, 07:11:07
Bałtyk nadal wysypuje. Na TD klatki skaczą od 55 do max 57 przy takich samych ustawieniach jak napisałem. Uruchomiłem sobie linia 61 tlk-1, na starcie ponad 100 kl/s, ale jak chciałem podlecieć kamerą do Częstochowy osobowej wysyp. Potem jeszcze przetestuje dokładniej na innych sceneriach. Generalnie u mnie jest problem ze stabilnością. A pisząc o normalnym exe miałem oczywiście na myśli te z paczki całościowej.

Edit1 Uruchomiłem Kaliską, więc dość ciężką scenerie i jestem bardzo pozytywnie zaskoczony. Teraz jestem w drodze do Pabianic i na trasie klatki skaczą w granicach od 60 do nawet 80. Wciskając ctrl + strzałka jest problem z trzęsącym się składem i obiektami, a nawet księżycem, ale w jeździe to nie przeszkadza więc jest dobrze.

Edit2 Wszystko działa jak trzeba, klatki też na bardzo dobrym poziomie. Do Częstochowy Osobowej wjeżdżam normalnie bez wysypu. Zostaje tylko ten Bałtyk.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 04 Kwietnia 2017, 12:49:55
Zostaje tylko ten Bałtyk.
Z tego co widze w logu, to jest wersja 64-bit w trybie display list. Ta kombinacja ma na ta chwile problem z tworzeniem geometrii skrzyzowan. Dopoki nie zostanie to usuniete, lepsze efekty powinienies miec albo uzywajac wersji x86, albo wlaczajac w .ini tryb VBO.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: vikinq w 04 Kwietnia 2017, 14:44:43
Po włączeniu VBO wszystko śmiga aż miło.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 04 Kwietnia 2017, 15:04:06
Odpalilem Kaliska na gf9500 z ustalonym skalowaniem na 1024 i 3 zrodla swiatla. Po zaladowaniu w kabinie EN57 na ekranie zyskalem 30% wydajnosci, czili 9fps. Karta graficzna posiada 1gb pamieci. Nawet nie probowalem z antyaliasingiem. Natomiast mam klopot z exe od @Milka7, blad procedury wejscia w bibliotece mvcrt.dll. paczke przenioslem cala na pendraku z komputera do komputera, tu biblioteki musza byc ok. Jedynie pozostaje cos w systemie. Zainstalowane mam vs 2008, 2010, 2013, i 2015. System 32 bitowy.
ED:
Nie wiem czy takie dane mogą się przydać, zbadałem programem Dependency Walker exe C++NG. Wynik w załączniku, niestety nie potrafię wyciągnąć z tego pliku wniosków.
ED1:
Exe od @Milek7 nie akceptuje skalowania tekstur do wielkości 1024. Odpaliło się na standardowym 8192. Kaliska: nie całe 3FPS.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 05 Kwietnia 2017, 23:16:20
Ostatnich pare dni minelo na reorganizacji system kontrolowania pojazdow, a bardziej konkretnie, na odpieciu tego kontrolowania od zakodowanych na sztywno kombinacji klawiszy, itp. Przerobki sa jeszcze daleko w lesie i zaimplementowane czesciowo, ale docelowo powinno to pozwolic na
- (przywrocenie) definiowania klawiszy kontrolnych przez uzytkownika
- latwiejsza kontrole pojazdow przy uzyciu urzadzen innych niz klawiatura, i rownolegle do klawiatury
- latwiejsza implementacje w przyszlosci trybu multiplayer (dzieki wygodniejszemu przekazywaniu operacji wykonywanych przez uzytkownika itp)

w dzisiejszym uaktualnieniu do zaobserwowania, w ramach tych zmian:
- chodzenie w kabinie uzywa teraz tego samego kodu, co chodzenie na zewnatrz. w efekcie powinno byc nieco plynniej, a zmiany gora/dol sa tez mniej skokowe
- przeorganizowane troche klawisze obslugi hamulcow:
-- hamulec lokomotywy jest teraz w calosci na lewej kolumnie klawiatury numerycznej (7 zmniejszenie, 1 zwiekszenie, 4 odluzniacz)
-- hamulec pociagu jest podobnie na jednej kolumnie klawiatury numerycznej (9 zmniejszenie, 3 zwiekszenie, 6 pozycja jazdy)
-- poniewaz te dwie kolumny maja organizacje 'gorny klawisz = mniejsza sila hamowania, dolny klawisz = wieksza sila' kolumna srodkowa dziala teraz podobnie, tzn sila hamowania zwieksza sie idac po kolei klawiszami 8 -> 5 -> 2
- w ramach wspomnianej obslugi urzadzen innych niz klawiatura, symulator obsluguje tez gamepad. Jak na razie kontrola gamepadem jest tylko dla funkcji najbardziej podstawowych:
-- prawy drazek do rozgladania sie
-- lewy drazek ma dwie funkcje. W trybie podstawowym sluzy do chodzenia. Natomiast przy wcisnietym jednym z podstawowych klawiszy, sluzy do kontroli podstawowych urzadzen:
--- przycisk A + gora/dol: kontrola glownego nastawnike (gora: zwiekszenie, dol: zmniejszenie)
--- przycisk B + gora/dol: kontrola hamulca pociagu (dol: zwiekszenie sily hamowania, gora: zmniejszenie)
--- przycisk Y + gora/dol: hamulec lokomotywy (dol: zwiekszenie sily hamowania, gora: zmniejszenie)
--- przycisk X + gora/dol: nastawnik boczny (gora: zwiekszenie wartosci, dol: zmniejszenie)

"przetestowane" jak na razie tylko z kontrolerem z Xboxa, wiec przy innym gamepadzie lub joysticku efekt jest nieprzewidywalny. konfiguracji gamepada (na razie) nie ma, tak samo jak i zwyklej klawiatury. Ale kiedys(tm) bedzie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 05 Kwietnia 2017, 23:22:11
Gdzie wylądował odluźniacz (num6) i skrót klawiszowy do odcięcia (ctrl+num5)?
Unormowanie środkowej kolumny popieram, ale przenoszenie pozycji jazdy wprowadzi chaos. Bym nie ruszał do czasu wprowadzenia przypisywania klawiszy przez użytkownika.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 05 Kwietnia 2017, 23:23:22
Odluzniacz jest pod czworka (mowiac prosciej, klawisze 4 i 6 maje zamienione funkcje) a odciecie jest bez zmian gdzie bylo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 05 Kwietnia 2017, 23:35:51
Joystick Logitech Extreme3d Pro.
Brak kontroli nad kamerą. Ciągły obrót w dół. Miałem tak kiedyś w X-wingu Alliance ale nie pamiętam co na to poradziłem.
Sam joystick jest lewą gałką. W osi Z chyba mam którąś oś rozglądania, ale przy ciągłym obrocie ciężko powiedzieć. D-pad do kontroli kamery nie robi nic.
Odwrócona oś X i Y.
Przycisk 3 łapie mi jako X. Przycisk 4 jako Y.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 05 Kwietnia 2017, 23:45:07
Na dluzsza mete trzeba bedzie konfiguracje dac, tak jak i dla klawiatury. Na szybko mozna sobie podejrzec w panelu sterowania pod "game controllers" jest taka mala aplikacja ktora na zakladce Test wyswietla jak system widzi rozne funkcje joysticka itp. W tym momencie exe na sztywno czyta:
x axis/y axis jako lewy drazek
x rotation/y rotation jako prawy
i przyciski 1 2 3 4 jako A B X Y

edit: glupoty wypisuje. prawy drazek odczytuje 3 i 4 os dostepna na urzadzeniu, co sprawdza sie w przypadku kontrolera xboxa i (teoretycznie) starszych gamepadow, ale moze sie rozjechac na bardziej skomplikowanych joystickach i innych urzadzeniach, zwlaszcza starszych.

edit2: aha, zapomnialbym. Po zmianach w obsludze chodzenia mozna tez chodzic po kabinie przy wlaczonym AI, nie ma wiecej problemu ze jestesmy przyspawani do fotela i nie mozna sie np przesiasc na miejsce pomocnika :d
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 06 Kwietnia 2017, 13:39:11
Właściwie to nie ma jakiś rewolucyjnych zmian. Jedynie odluźniacz przeniesiony z 6 na 4 i pozycja "jazda" na 6. Mam uwagę co do latania po scenerii. Po wyjściu F4 latanie miało 3 prędkości w zależności od kombinacji klawiszy shift, ctrl, i strzałki.
[shift]+[strzałka]  -  Mała prędkość latania po scenerii.
[ctrl]+[strzałka]  -  Średnia prędkość latania po scenerii.
[shift]+[ctrl]+[strzałka]  -  Największa prędkość latania po scenerii.
W tej chwili z shiftem i strzałką mamy taką samą prędkość jak z ctrl i strzałką. Razem wszystkie trzy klawisze nie działają. Trzeba wrócić jak było, przelot na inną stację kamerą trwa teraz zbyt długo.
Chodzenie po kabinie bardzo ładne. Nie mam niestety żadnego manipulatora.:(
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 06 Kwietnia 2017, 13:58:25
shift + kierunek a ctrl + kierunek zdecydowanie maja inne predkosci poruszania (ctrl jest ok 3x szybszy niz shift, ktory jest ok 3x szybszy niz sam klawisz kierunku) Z tym, ze zwroc uwage ze na ta chwile trzeba komendy uaktywniac przez wcisniecie modyfikatora i klawisza w tej kolejnosci, jesli wcisniesz najpierw kierunek a potem shift albo ctrl, to "przyspieszenie" nie zaskoczy. To jest do ewentualnej poprawki.

shift + ctrl jako odrebna kombinacja jest w tej chwili wylaczony, glownie dlatego ze po zmianach dotychczasowy uklad oznaczal wprowadzenie 16 indywidualnych komend do samej obslugi poruszania i to w sytuacji gdy normalny uzytkownik rzadko kiedy w ogole wysiada z kabiny. Juz predzej zwieksze troche przyspieszenie w obecnych trybach, jesli bedzie zapotrzebowanie ;/
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 06 Kwietnia 2017, 14:08:06
Zdecydowanie daj przyśpieszenie (na zewnątrz), to kombinowanie z controlem i shiftem było diabelnie siermiężne, można się było łatwo zgubić.  Zwłaszcza przy próbach przelotu do następnej stacji ;) 2 prędkości powinny być, 1 chodzenie, 2 bieganie, bo czasem sobie wyjdę na dłuższym postoju gdzieś, a potem truchtam do kabiny żeby zdążyć przed rozkładem. Wiem, że nie trzeba, można od razu F4, ale dodatkowy realizm jest jak wracasz do kabiny z buta.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 06 Kwietnia 2017, 14:20:59
Chodzenie do odległych części scenerii jest podstawową funkcją sprawdzenia przyczyn błędów (wizja lokalna korków i utknięć pojazdów). Nie wiem jak przeciętny użytkownik z tego korzysta, ale ta ostatnia turbo prędkość musi pozostać gdzieś zaszyta dla pisarzy scenariuszy, budowniczych scenerii i osób testujących. Konstrukcja użycia tych klawiszy była dość przemyślana.
ED:
Zgadza się, że w dzisiejszej kompilacji prędkości mamy teraz dwie. Tyle, że ta szybsza jest zbyt wolna. Dotarcie do Sieradza gdzie tworzył się zator (to trzeba zobaczyć) z Radliczyc (tam nie dostawaliśmy "zielonego") przy obecnej prędkości jest zbyt długie i wnerwiające.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 06 Kwietnia 2017, 14:31:07
W takim razie moze zaaranzowac to tak, by przyspieszenie bylo duzo wieksze przy wlaczonym trybie debug? Wtedy pisarze itp moga sobie szybko skakac po scenerii, a normalnemu uzytkownikowi sie to nie placze.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 06 Kwietnia 2017, 14:48:23
To jest wyjście, szczególnie że można bez wyłączenia symulacji, przejść do trybu debug mode. Pewnie jeszcze ktoś zabierze głos w tej sprawie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 06 Kwietnia 2017, 18:20:38
Pochwalam szybkie fruwanie w debugu.
Ogarnąłem joystick. Oś 4 to przepustnica. Musi być na 50% i kamera nie lata. No ale jeździć się nie da. Oś Z mam bardzo czułą i przy jakiejkolwiek manipulacji kamera mi lata na boki. Wejście na pierwszą pozycję by zaskoczyły styczniki awykonalne. Przełączanie guzików między trybami działania wajchy nieintuicyjne. Może pod asynchrony, gdy będzie opcja konfiguracji by odpiąć od niego kamerę i zostawić sam zadajnik i hamulec pomocniczy oraz tempomat.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 06 Kwietnia 2017, 18:40:16
OK, w ramach eksperymentow ze sterowaniem:

- poruszanie sie ma tylko dwie predkosci, normalna (klawisze kursora) i "bieg" (shift + klawisze kursora)
- w trybie debug poruszanie jest przyspieszone: normalne odpowiada predkosci 'bieg' z trybu zwyklego, a bieg w trybie debug jest... szybszy.
(w kabinie zawsze poruszamy sie z predkoscia podstawowa, coby sie nie obijac o sciany)
- poruszanie przy uzyciu gamepada umozliwia plynne przejscie miedzy 'chodzeniem' i 'biegiem' w zaleznosci od stopnia wychylenia drazka

Przełączanie guzików między trybami działania wajchy nieintuicyjne.
Dla mnie sprawdza sie calkiem wygodnie, chociaz moze to byc kombinacja ukladu na gamepadzie -- zielony przycisk na srodku to 'gaz', czerwony po prawej to 'hamulec', wajcha do przodu to ogolnie 'szybciej' a do siebie 'wolniej'. Drugi rzad przyciskow w pewnym sensie duplikuje pierwszy tzn powyzej nastawnika sa boczniki, a powyzej hamulca pociagu jest hamulec lokomotywy. Dla skontrowania czulosci docelowo beda indywidualne ustawienia dla poszczegolnych urzadzen, na razie jest jedno uniwersalne, ale tez dostosowane do pada wiec tu sie sprawdza, ale juz gdzie indziej niekoniecznie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: dymus w 06 Kwietnia 2017, 20:51:29
Poruszanie sie po kabinie ok, szcególnie góra/dół :) Zmiana klawiszy przy hamulcu, początkowo trochę myliła, ale w gruncie rzeczy może ma jakiś sens. Zmiana prędkości poruszania kamery szybszy/wolny w normalny/debuge też ok.
Jedyna rzecz do której bym się doczepił to to że nie działa przyspieszenie od używania strzałki do shift+strzałka, chodzi o to że poruszając się, ale chcąc przyspieszyć, nie wystarczy wcisnąć shifta, tylko trzeba puścić strzałke (zatrzymać się), wcisnąć shifta+strzałkę i dopiero jest szybszy ruch, a co ciekawe przejście z szybszego na wolniejszy działa, bo po odpuszczeniu shifta przy przytrzymanej strzałce kamera zwalnia - to dotyczy i debuge i normalnego.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 06 Kwietnia 2017, 21:03:32
U mnie w kabinie B dziwnie dziala kran. Np nie dziala num4 inaczej sa pozycje kranu na klawiszach. W kab A jezt ok. Tak jakby lustrzane odbicie. Pod num6 jest jazda. Pod num2 jest to co powinno byc pid num8 a pod num8 to co pod num2. Odluzniacza brak. Dotyczy tylko samego kranu zasadniczego. Reszta ok.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: dymus w 06 Kwietnia 2017, 21:12:26
@EP08_015
[...]
- przeorganizowane troche klawisze obslugi hamulcow:
-- hamulec lokomotywy jest teraz w calosci na lewej kolumnie klawiatury numerycznej (7 zmniejszenie, 1 zwiekszenie, 4 odluzniacz)
-- hamulec pociagu jest podobnie na jednej kolumnie klawiatury numerycznej (9 zmniejszenie, 3 zwiekszenie, 6 pozycja jazdy)
-- poniewaz te dwie kolumny maja organizacje 'gorny klawisz = mniejsza sila hamowania, dolny klawisz = wieksza sila' kolumna srodkowa dziala teraz podobnie, tzn sila hamowania zwieksza sie idac po kolei klawiszami 8 -> 5 -> 2
- w ramach wspomnianej obslugi urzadzen innych niz klawiatura, symulator obsluguje tez gamepad. Jak na razie kontrola gamepadem jest tylko dla funkcji najbardziej podstawowych:
[...]
A uzupełniając pod 4 jest odluźniacz.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 06 Kwietnia 2017, 21:26:49
Jedyna rzecz do której bym się doczepił to to że nie działa przyspieszenie od używania strzałki do shift+strzałka, chodzi o to że poruszając się, ale chcąc przyspieszyć, nie wystarczy wcisnąć shifta, tylko trzeba puścić strzałke (zatrzymać się), wcisnąć shifta+strzałkę i dopiero jest szybszy ruch, a co ciekawe przejście z szybszego na wolniejszy działa, bo po odpuszczeniu shifta przy przytrzymanej strzałce kamera zwalnia - to dotyczy i debuge i normalnego.
To jest niestety konsekwencja zmiany metody obslugi/odczytu klawiatury, i tego jak ten odczyt jest realizowany przez system operacyjny/GLFW -- w duzym skrocie program bieze pod uwage tylko ostatnio nacisniety klawisz, czyli jesli wcisniemy strzalke a nastepnie shift, to z punktu widzenia exe jest to postrzegane jako "uzytkownik trzyma wcisniety shift" a nie "trzymany jest shift i cos tam jeszcze". W druga strone to dziala bo gdy puscisz shift to nadal trzymany jest kierunek, i to on jest rejestrowany/przekazywany, co jest odbierane jako normalna komenda poruszania.
Moze uda sie to poprawic organizujac sterowanie troche inaczej, ale to jest jeszcze do sprawdzenia.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 06 Kwietnia 2017, 21:29:26
Czy te nowe klawisze juz tak zostana? Czy to tylko tymczasowe rozwiazanie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 06 Kwietnia 2017, 21:38:29
W sensie te na klawiaturze numerycznej? Jesli nie bedzie zbyt wiele protestow to prawdopodobnie tak bo mysle ze ten uklad jest troche bardziej "konswekwentny" wiec latwiejszy do nauczenia dla 'swiezego' uzytkownika, ale docelowo bedzie tez mozliwosc zmiany co jest przypisane do czego, wiec jesli bardziej pasuje ci stary uklad to bedziesz go mogl sobie przywrocic.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 06 Kwietnia 2017, 22:46:31
  Przetestowałem właśnie ten nowy układ sterowania hamulcami na numerycznej, i w sumie dość łatwo się przestawić. Właściwie to teraz nawet bardziej intuicyjne to jest. Jak będzie możliwość jeszcze przypisania własnego układu klawiszy, to ja jestem jak najbardziej za.
Pozdrawiam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 06 Kwietnia 2017, 22:51:49
Da się przyzwyczaić. Nie jest zle. Przy okazji dla zainteresowanych w przypadku Knorra hamowanie na num2 i odcięcie na num5 jazda na num6. Reszta wg nowego schematu TMJ. TMJ a jak tam moje dzwieki? patrzyles już cos? Wiesz na Tamarze albo na ET21 tak nienaturalnie cicho jest.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 06 Kwietnia 2017, 23:50:21
Dzwieki dalej sa na liscie rzeczy do zrobienia :)  Chcialbym najpierw dokonczyc rozgrzebana przerobke sterowania i renderowania obiektow, bo ogarniecie tego umozliwi/ulatwi wprowadzenie paru fajnych rzeczy, w tym np. aktywacje elementow mysza (co przyda sie zarowno przy sterowaniu pojazdami jak i w edytorze sceny)

edit:
pytanie na szybko, jak polaczone sa w "prawdziwych" lokomotywach przelaczniki podnoszenia pantografow z pantografami? Tzn np EP07 ma w kabinach "Pantograf A" i "Pantograf B", czy przelacznik A jest spiety w obu kabinach z tym samym pantografem, czy sa odwrocone zaleznie od kabiny?
Pytam, bo exe ma schizofrenie i w jednym miejscu uwzglednia w ktorej kabinie jestesmy, ale w innym miejscu juz nie, i chcialbym to przy okazji uporzadkowac.

edit2:
glupich pytan ciag dalszy
w symulatorze oprocz przelacznika przetwornicy jest tez (np w EN57 i ED72) cos co sie nazywa "converteroff_sw", a na pulpicie opisane jest jako "Przetwornica glowna wylaczona i odblokowana". Jaka jest (w rzeczywistosci) funkcja tego przelacznika? W symulatorze wyglada na calkowicie kosmetyczny -- nie ma przypisanego zadnego klawisza i sprowadza sie do tego, ze jest ustawiany w pozycji 'zalaczona' gdy przetwornica jest wylaczona, i odwrotnie. Czy to tak ma byc?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: adamst w 08 Kwietnia 2017, 06:50:50
W kiblu przetwornicę załącza się i wyłącza przełącznikami impulsowymi. Dodatkowo przełącznik wyłączający służy jako odblok przekaźnika nadmiarowego przetwornicy. Przełącznik załączający zaś pełni dwie funkcje - załącza przekaźnik przerzutowy przetwornicy, oraz - gdy jest w pozycji załączonej - bocznikuje część uzwojenia prądowego przekaźnika nadmiarowego, podnosząc jego próg zadziałania. Dlatego w realu należy go trzymać w górze do pełnego rozruchu przetwornicy, inaczej może wyrzucić nadmiarowy, ponieważ prąd rozruchowy silnika jest większy niż normalny. Podczas uruchamiania z szafy funkcję tę pełni przycisk - aby załączyć przetwornicę z szafy należy trzymając wciśnięty ów przycisk ręcznie przełączyć przekaźnik przerzutowy przetwornicy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 08 Kwietnia 2017, 07:01:15
Przy okazji ponowny przejazd linia53 sluzba3 zakonczona pomyślnie ale na w trybie DL. W trybie VBO dalej się wywala w Zernikach. Logow nie daje gdyż TMJ wie o co chodzi.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 08 Kwietnia 2017, 13:59:07
W kiblu przetwornicę załącza się i wyłącza przełącznikami impulsowymi. Dodatkowo przełącznik wyłączający służy jako odblok przekaźnika nadmiarowego przetwornicy. Przełącznik załączający zaś pełni dwie funkcje - załącza przekaźnik przerzutowy przetwornicy, oraz - gdy jest w pozycji załączonej - bocznikuje część uzwojenia prądowego przekaźnika nadmiarowego, podnosząc jego próg zadziałania. Dlatego w realu należy go trzymać w górze do pełnego rozruchu przetwornicy, inaczej może wyrzucić nadmiarowy, ponieważ prąd rozruchowy silnika jest większy niż normalny. Podczas uruchamiania z szafy funkcję tę pełni przycisk - aby załączyć przetwornicę z szafy należy trzymając wciśnięty ów przycisk ręcznie przełączyć przekaźnik przerzutowy przetwornicy.
Czekaj czekaj, bo sie pogubilem :)  Sprobujmy lopatologicznie, skoro w kiblu sa dwa przelaczniki ('glowny' przelacznik przetwornicy i ten drugi) jak wygladaja w praktyce ustawienia dla ich obu, a) przed rozruchem albo po wylaczeniu, b) w trakcie uruchamiania przetwornicy i c) po wlaczeniu przetwornicy, w trakcie jazdy?

Jezeli dobrze rozumiem, to ten dodatkowy przelacznik powinien reagowac na "Ctrl + n: Odblokowanie przekaźnika nadmiarowego przetwornicy i ogrzewania"?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 08 Kwietnia 2017, 14:08:14
W fiz masz converter=impulse co ma włączać ten ficzer (Wiggle coś tam poprawiał niedawno w tym aspekcie, więc lepiej wziąć pliki z repo do testu).
Trzymanie shift+x animuje hebelek "zał przetwornicy", włącza przetwornicę i zwiększa prąd zadziałania nadmiarowego przetwornicy.
Puszczenie przywraca hebelek "zał przetwornicy do pozycji neutralnej i prąd zabezpieczenia do standardowego.
Trzymanie x animuje hebelek "wył przetwornicy", wyłącza przetwornicę i odblokowuje przekaźnik nadmiarowy przetwornicy.
Puszczenie przywraca hebelek "wył przetwornicy" do pozycji neutralnej.
Tak to zrozumiałem. Funkcja ctrl+n jest włączona do funkcji x i nic nie robi w tym przypadku. Ale tak jest dla en57 tylko i może pochodnych.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 08 Kwietnia 2017, 15:04:30
W EN57 i pochodnych sterowanie pantografami tez jest heblami impulsowymi, danie impulsu zasila na ten moment przewod wielokrotny odpowiadajacy za podnoszenie (przesterowanie elektrozaworu) czy to przednich, czy tylnych pantografow, opuszczenie przedniego badz awaryjne opuszczenie wszystkich grzybkiem na pulpicie. W stanie zasadniczym heble te sa zawsze wylaczone. Tak samo heble przetwornicy. W EN57, w których zamiast przetwornicy wirowej jest statyczna (elektroniczna), nie ma potrzeby trzymania dluzej przycisku zalaczania.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 08 Kwietnia 2017, 15:16:27
W fiz masz converter=impulse co ma włączać ten ficzer (Wiggle coś tam poprawiał niedawno w tym aspekcie, więc lepiej wziąć pliki z repo do testu).
Trzymanie shift+x animuje hebelek "zał przetwornicy", włącza przetwornicę i zwiększa prąd zadziałania nadmiarowego przetwornicy.
Puszczenie przywraca hebelek "zał przetwornicy do pozycji neutralnej i prąd zabezpieczenia do standardowego.
Trzymanie x animuje hebelek "wył przetwornicy", wyłącza przetwornicę i odblokowuje przekaźnik nadmiarowy przetwornicy.
Puszczenie przywraca hebelek "wył przetwornicy" do pozycji neutralnej.
Tak to zrozumiałem. Funkcja ctrl+n jest włączona do funkcji x i nic nie robi w tym przypadku. Ale tak jest dla en57 tylko i może pochodnych.
No ja wlasnie nie bardzo rozumiem jak to ma byc, bo w exe Borlandowym wlacznik przetwornicy zostaje w pozycji zal. i nigdzie nie wraca, a ten drugi jest praktycznie na stale w pozycji zal. i nie reaguje na nic ;/  Czyli zeby bylo prawidlowo, to oba przelaczniki powinny samoczynnie wracac do pozycji neutralnej, jesli nie sa trzymane? I co z przekaznikiem nadmiarowym, czy on jest faktycznie odblokowany tylko, gdy aktywujemy wylacznik i wylaczamy przetwornice, czy przeciwnie -- odblokowany jest gdy wylacznik jest w pozycji neutralnej, i przetwornica pracuje? Bo ta pierwsza opcja brzmi troche dziwnie ale ja sie nie znam :x

(to drugie pytanie to mniej wazne bo nie jestem pewien czy exe w ogole w chwili obecnej zwraca na to uwage, ale to tak na przyszlosc)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: matek123 w 08 Kwietnia 2017, 15:29:19
W tej chwili potrzebne jest stabilne exe, żeby się szykować do wydania paczki całościowej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 08 Kwietnia 2017, 15:34:11
Oba powinny samoczynnie wracac. Co do przetwornicy - oba stwierdzenia sa prawdziwe ;) Przetwornica zadziala, gdy nadmiarowy nie zadzialal i jest juz odblokowany. Jak jest zalaczona, to sila rzeczy zabezpieczenie nie zadzialalo i jest odblokowane. Jak dajemy odblok, to oprocz przywracania stanu przekaznika, wylaczamy ochraniane urzadzenie. Tak samo bedzie z WS, gdy w szafie damy odblok np. przekaznika roznicowego.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: adamst w 08 Kwietnia 2017, 15:38:29
Mylący może być opis "przetwornica wyłączona i odblokowana", co sugerowałoby, że jak hebel jest w dole, to nie jest odblokowana ;-) Ale to po prostu niezręczność opisu - chodzi tylko o funkcje tego przełącznika, który wyłącza, i odblokowuje, jeżeli jest co odblokowywać ;-)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 08 Kwietnia 2017, 18:51:28
Co do pantografów w lokomotywach, to zależy od typu, a nawet numeru lokomotywy. Siódemki 4E (do numeru 244) oryginalnie miały impulsowe podnoszenie obu pantografów hebelkiem i impulsowe opuszczanie obu pantografów czerwonym grzybkiem i ew. na ramie pneumatycznej można w takiej sytuacji odciąć dopływ powietrza do wybranego pantografu za pomocą zaworu. Z czasem niektóre z nich przerobiono na osobne starowanie pantografami za pomocą dwóch hebelków bistabilnych (przerabiając mniej lub bardziej układ hebelków na pulpicie i z reguły pozbywając się hebelka od wentylatorów oporów), a przycisk grzybkowy podpisano jako "rezerwa" lub wsadzono kontrolkę rezerwową bądź od ogrzewania kabiny. Siódemki 303E (od numeru 301) mają osobne sterowanie pantografami za pomocą dwóch hebelków. Co do kolejności dla dwóch kabin, to różnie jest w rzeczywistości jak i na dwóch różnych schematach jakie mam - wg. DTRki hebelek bliżej przednich okien kabiny zawsze podnosi pantograf nad kabiną, w której się znajduje. W ET41 do nr 84 włącznie sterowanie pantografami jest jak w EU07 4E lub przerobione jak wyżej opisałem, a w ET41 od nr 85 włącznie jest jak w EU07 303E. ET22 do nr 502 mają osobne podnoszenie i opuszczanie każdego pantografu z osobna (wg. schematu dwa hebelki impulsowe do podnoszenia i dwa przyciski grzybkowe do opuszczania w każdej kabinie, choć widziałem chyba kiedyś zdjęcie lub filmik z wersji z czterema hebelkami impulsowymi), z czego hebelek/przycisk podpisany jako "A" zawsze steruje pantografem nad kabiną A, a w ET22 od nr 503 jest po jednym hebelku bistabilnym na pantograf i tak samo jak we wcześniejszych numerach hebelek "A" zawsze steruje pantografem nad kabiną A, z czego żeby podnieść pantograf A z kabiny A musi być on opuszczony w kabinie B i żeby podnieść pantograf B z kabiny B musi być on opuszczony w kabinie A. Dodatkowo w każdej kabinie jest jeszcze trzeci hebelek bistabilny odcinający zasilanie elektrozaworów obu pantografów (musi być w pozycji załączonej, żeby dało się podnieść którykolwiek pantograf z danej kabiny plus dochodzi jeszcze wyłącznik rozrządu i wyłącznik samoczynny pantografów jak w każdej lokomotywie).

Kwestię starego typu sterowania w EU07 4E i ET41 do nr 84 można by rozwiązać tak, że będąc w kabinie klawisz "P" (podniesiony) zawsze podnosi pantografy, a klawisz "O" (opuszczony) zawsze opuszcza pantografy, natomiast będąc w przedziale maszynowym klawisze "P" i "O" odpowiadają za odcinanie zasilania pneumatycznego (zakręcenie zaworu na ramie pneumatycznej) kolejno pantografu przedniego i tylnego, a kombinacje "Shift"+"P" i "Shift"+"O" odpowiadają za załączenie zasilania pneumatycznego kolejno dla pantografu przedniego i tylnego, o ile taka zmiana nie wywoła zbytniego zamieszania wśród użytkowników i AI... Domyślnie mógłby być zasilany tylko pantograf B, żeby było na czym jechać w przypadku jego połamania.

Jeśli natomiast chodzi inne błędy w sterowaniu, to dość irytujący jest brak piaskowania w członie sterowanym ET41 (tylnym patrząc z punktu aktualnie prowadzonego). Dosyć często zdarza mi się wpadnięcie go w poślizg i co najmniej wyłączenie się WSa lub nawet uszkodzenie silników mimo piaskowania w członie sterującym (prowadzonym). Do tego cała masa innych błędów dla tego typu lokomotywy i kilka dotyczących też innych lokomotyw, ale to już mniej pilne i chyba zbytnie zagłębianie się w obwody na tym etapie. Dla zainteresowanych opisałem je kiedyś tutaj (http://eu07.pl/forum/index.php?issue=276.0).

PS.: Na koniec jako ciekawostkę odnośnie do sterowania pantografami dodam, że w ET41 od nr 85 i w EU07 303E mimo sterowania dwoma hebelkami od wyjazdu z fabryki blachy pulpitów pozostały te same i pierwszy od prawej hebelek w górnym rzędzie (na pulpicie poziomym) ma mocowanie za pomocą śrubek na odwrót, tzn. śrubki są przesunięte nieco na lewo od dźwigni hebelka, podczas gdy reszta hebelków ma te śrubki przesunięte nieco na prawo. Jest to pozostałość po hebelku impulsowym ze starego typu sterowania pantografami, który musiał być zamocowany odwrotnie (obrócony o 180st.) ze względu na swoją konstrukcję - możliwość zamocowania dodatkowych sprężyn odciągających tylko z jednej strony. Pozostaje pytanie, dlaczego od początku pozostałych hebelków nie montowano jak tego jednego?...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 08 Kwietnia 2017, 19:04:26
D: Czyli wychodzi na to, ze porzadnie sie tego nie zrobi bez ogolnego ogarniecia konfiguracji kabin i przyciskow, i takiego troche bardziej obiektowego podejscia do tematu. A wtedy zwolennicy realizmu beda sie mogli pobawic w skladanie konkretnych kabin "jak w realu". Tyle dobrego, ze na razie nie bede sie stresowal zeby to zrobic dokladnie. =)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 08 Kwietnia 2017, 19:39:02
Tak jak lubię realizm, tak mi się to wydaje troszkę zbyt skomplikowane. Sterowanie z klawiatury powinno być przede wszystkim spójne. Wiadomo, że klawiatura to nie rzeczywisty pulpit, bo każdy pulpit jest trochę inny, a klawiatury standardowe. Wydaje mi się, że ten sam klawisz w każdej lokomotywie powinien robić to samo, a jeśli nie może, to po prostu nie powinien działać. Sens by miało za to, żeby przy sterowaniu myszą (klikalne hebelki) jak najbardziej działało to jak w rzeczywistych lokomotywach, czyli zależnie od tego która kabina i która wersja loka. Tak samo bardzo szczegółowe opcje sterowania powinny być dostępne w API dla urządzeń zewnętrznych innych niż klawiatura.

Dla zachowania spójności - klawisz wciśnięty z shiftem zawsze włączał dany włącznik, bez shifta wyłączał. Jestem za tym, żeby tak zostało. Potem doszło mniej intuicyjne kręcenie przełącznikami obrotowymi, też z shiftem w jedną stronę, bez shifta w drugą. Ale jest w tym jakaś logika.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Lorem w 08 Kwietnia 2017, 20:01:01
Póki nie zaczniemy się bawić w symulacje obwodów, rozróżnienie można by zrobić na poziomie animacji (zresztą wydaje mi się, że w niektórych kabinach tak to działało). Czyli Shift+O/P zawsze podnosi odpowiadający pantograf, bez shifta zawsze go opuszcza, a na poziomie animacji albo przestawia się bistabilny hebelek, albo przełącza się chwilowy dla jednej kombinacji, a inny/grzybek dla klawisza bez shifta.
Swoją drogą, to byłby chyba dobry moment, żeby poprawić działanie niektórych przycisków, które reagują na przytrzymanie tak, jakby je wielokrotnie wcisnąć (o ile dobrze pamiętam ma tak między innymi odłączenie styczników liniowych pod L).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: KEKv_2 w 08 Kwietnia 2017, 22:25:17
Powitać
Nie wiem czy w dobrym wątku piszę ale mniejsza o to. Zauważyłem błąd w teksturze części pulpitu w  Ep09. Tekstura czuwaka w stanie "spoczynku" wygląda jak trawa a jak się czuwak uruchomi ma normalną teksturę, po jego zbiciu tekstura wraca z powrotem na trawę. VBO wyłączone.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 08 Kwietnia 2017, 22:45:38
Na borlandowym nie? Tam całą płytkę pod spodem ostro zdegenerowało.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 08 Kwietnia 2017, 23:09:15
Ja u siebie tego nie mam. Ani na borlandowym, ani na C++.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 08 Kwietnia 2017, 23:24:16
Tak jak lubię realizm, tak mi się to wydaje troszkę zbyt skomplikowane. Sterowanie z klawiatury powinno być przede wszystkim spójne.
Na szczescie to jest bardziej "problem" poprawnej wizualizacji, a nie sterowania. Tzn sterowanie bez wzgledu na wyposazenie jest takie samo (przynajmniej z klawiatury lub gamepada, klikanie na elementach to inna para kaloszy), chodzi tylko o to zeby byla mozliwosc definicji czy dany pojazd ma w kabinie przelaczniki impulsowe czy zwykle, czy obsluga urzadzenia jest jednym przelacznikiem albo kilkoma itp, i zeby sie to poprawnie rysowalo. To wszystko i tak raczej srednio/bardziej odlegla przyszlosc.

W miedzyczasie uaktualnienie z dalszym ciagiem porzadkow w sterowaniu:
- stan klawisza shift powinien byc teraz uwzgledniany 'normalnie' w trakcie ruchu, a nie tylko na poczatku
- podpiete pod nowy system kontroli: bateria, pantografy, wylacznik szybki, przetwornica i kompresor

"nowy system kontroli" oznacza miedzy innymi pewne uproszczenie w sterowaniu. Zamiast osobnych kombinacji dla wlaczania i wylaczania urzadzen, uzywany jest teraz ten sam klawisz, ktory przelacza urzadzenie z jednego stanu w drugi. Czyli jest pantograf jest opuszczony i wcisniemy O to sie podniesie, po kolejnym wcisnieciu O zostanie opuszczony, po kolejnym znowu podniesiony, itp. Docelowo zwalnia to duza kombinacje klawiszy, ktore moga byc wykorzystane do obslugi innych funkcji.

(ze 'znanych bledow' -- kabina nie odzwierciedla w tej chwili dokladnie stanu pociagu w przypadku przejscia do drugiej kabiny, lub gdy steruje AI; bedzie to zalatane po zakonczeniu prac)

Przy okazji porzadkow kible maja teraz poprawiona obsluge swoich 'impulsowych' przyciskow dla pantografow, przelacznikow przetwornicy i wylacznika szybkiego. Co do sprezarki to nie jestem pewien czy dla jej obslugi jest uzywany przelacznik impulsowy czy zwykly, wiec na razie uzywany jest zwykly. Jesli to jest zle, mozna latwo poprawic jak sie ktos doinformowany wypowie :d
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 09 Kwietnia 2017, 01:02:04
Wszystko ładnie działa. O ile w przełącznikach impulsowych to fajne, to w bistabilnych nie wiem jak się sprawdzi. W klikanej kabinie Q chyba też było lpm=wł ppm=wył. Szklanej kuli nie trzeba wy wróżyć masę wątków "jak ruszyć" w nowej paczce. ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: matek123 w 09 Kwietnia 2017, 08:09:13
masę wątków "jak ruszyć" w nowej paczce. ;)
Ustne ostrzeżenie, a jak nie pomoże, to WMMB.
Pomysł obsługi jednej kombinacji do włączania i wyłączania jednego urządzenia, podoba mi się. W trainzie wszystko oprócz hamulców, nastawnika i nastawnika kierunku, włącza i wyłącza się tym samym klawiszem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 09 Kwietnia 2017, 13:53:36
Na nowych exe nie działa mi et41_v2 wstawiony jako AI. Mimo wstawienia z V=0.1 lok się nie uruchamia. W errors.txt jest coś takiego:
Animations tag is missing from the .mmd file "dynamic\pkp\et41_v2\203e-a.mmd"
Animations tag is missing from the .mmd file "dynamic\pkp\et41_v2\203e-b.mmd"

Jak rozumiem fakt braku animacji powoduje, że lok nie ma prądu (bo nie podnoszą się pantografy)? Ktoś mądry jest w stanie te animacje dopisać?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 09 Kwietnia 2017, 13:59:44
Zrobione dawno temu. :) http://eu07.pl/daily/export/dynamic/pkp/et42_v2/
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 09 Kwietnia 2017, 14:11:42
Dzięki, działa.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 09 Kwietnia 2017, 15:02:14
Crashdump z dzisiaj. Ciężko nawet powiedzieć z czym to mogło być związane, bo nawet loka nie zdążyłem odpalić tylko latałem nad scenerią i robiłem screeny. Fajnie byłoby doczekać kiedyś exe, które nie będzie się sypać z nieznanego powodu...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 09 Kwietnia 2017, 15:13:06
170330 to stara d.. znaczy sie stare exe jest, troche ciezko sprawdzac jak sie zrodla w miedzyczasie zmieniaja. Z tego co moge zobaczyc to tam byla proba kopiowania albo odczytu ze zlym adresem, ale niestety nic wiecej. Jaka to byla sceneria?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 09 Kwietnia 2017, 15:30:31
Wiem, ale niestety jeszcze nie ściągnąłem najnowszej wersji. Sceneria ta, co zwykle, w razie potrzeby mogę później linka podrzucić.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: pat w 09 Kwietnia 2017, 15:39:22
Cześć. Z symulatorem (i koleją) rozpocząłem przygodę niedawno. Ale z własnego doświadczenia na temat UX/UI, mogę zaproponować by przyciski na klawiaturze były odpowiednikami przycisków/hebelków w lokomotywie. Co mam na mysli? Otóż weźmy za przykład lok EU07.
Na ostatnim exe wciśnięcie "m" raz odpowiada wciśnięciu przycisku załączenia wył. szybkiego a raz odpowiada wciśnięciu przycisku obok tj. wyłączenia wył. szybkiego. Jest to pewnego rodzaju uproszczenie - jeden przycisk na klawiaturze odpowiada dwóm w lokomotywie, a takiemu rozwiązaniu bliżej jest do gry niż symulatorowi. Bo skoro komputer decyduje za nas który przycisk wcisnąć, to dlaczego nie oddać mu całego sterowania? :)
Uważam, że projektując interfejs MaSzyny należałoby dążyć do jak największego zatarcia różnicy między klawiaturą a pulpitem w lokomotywie.
Moja propozycja sprowadza się do:
- hebelki i przyciski 2 stopniowe są obsługiwane przy pomocy klawisza lub klawisza + shift,
- "normalne" przyciski (grzybki) mają swoje pojedyncze odpowiedniki na klawiaturze.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 09 Kwietnia 2017, 15:39:38
Póki co nic się nie sypie, ale... uruchamianie loka zacząłem od wciśnięcia shft...:) Zmiany idą w bardzo dobrym kierunku. Widzę też, że część funkcji obsługiwanych w kabinie wyłączona została po wyjściu z lokomotywy. Też będzie się trzeba przyzwyczaić.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 09 Kwietnia 2017, 16:02:53
Widzę też, że część funkcji obsługiwanych w kabinie wyłączona została po wyjściu z lokomotywy. Też będzie się trzeba przyzwyczaić.
Na razie obejmuje to opcje przepiete pod nowy system, ale docelowo bedzie tak w calosci. W duzym skrocie, urzadzenia kabinowe obslugiwane sa gdy jestesmy w kabinie, po wyjsciu na zewnatrz aktywne sa operacje ktore mozna przeprowadzac na zewnatrz, czyli laczenie, rozlaczanie, ustawianie hamulcow na wagonach itp.

Jezeli bedzie zapotrzebowanie to mozna zostawic obsluge lokomotywy takze z zewnatrz np w trybie debug.

Cześć. Z symulatorem (i koleją) rozpocząłem przygodę niedawno. Ale z własnego doświadczenia na temat UX/UI, mogę zaproponować by przyciski na klawiaturze były odpowiednikami przycisków/hebelków w lokomotywie. Co mam na mysli? Otóż weźmy za przykład lok EU07.
Tutaj mamy problem poruszony kilka postow temu, tzn ze w rzeczywistosci nie ma czegos takiego jak uniwersalny zestaw urzadzen w kabinie EU07, bo co egzemplarz to moze byc inaczej. I teraz sa dwie 'szkoly' -- jedna grupa uzytkownikow bedzie chciala sterowania ujednoliconego, a druga grupa bedzie chciala powiazania klawiszy z konkretnymi przyciskami.

Pogodzic sie tego za bardzo nie da, dlatego sklaniam sie ku rozwiazaniu, by sterowanie z klawiatury bylo mozliwie proste, natomiast zwolennicy realizmu beda sobie mogli aktywowac recznie konkretne kontrolki po wprowadzeniu dodatkowej obslugi mysza.

Cytuj
"Bo skoro komputer decyduje za nas który przycisk wcisnąć, to dlaczego nie oddać mu całego sterowania? :)"
Tu poprawka: komputer moze sobie decyduje ktory przycisk wcisnac, ale decyzje o aktywacji danego urzadzenia podejmujesz ty, a nie on. On jedynie wykonuje to polecenie tak, jak ma to sens w danej kabinie i sytuacji. Wiec pytanie jest troche z gatunku "jesli sprzatacz decyduje sam jak machac mopem, to po co szef dzialu rozdzielajacy dyzury?" ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 09 Kwietnia 2017, 16:16:31
Kamery w widoku zewnętrznym nie zawsze działają. Wcześniej nie obserwowałem z tym problemów. Teraz często mnie nie przenosi do danej kamery i całe Drawinowo muszę lecieć.

170408. Po wczytaniu wszystkiego i wykonaniu eventu odcinka izolowanego symek zawiesza się na jakieś pół minuty. Jeszcze przetestuję na innych sceneriach potem.

I zapętlenie addvalues. Aktualne drawinowo od Ra: http://rainsted.com/warsztat/Drawinowo/drawinowo-170408.7z
Latam na nim od rana i pierwszy raz zawiesiło, więc nie jest to jednak często powtarzalne.
EVENT LAUNCHED: --wlo6-lch6
free     2.00    23.00 != * *     0.00
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 09 Kwietnia 2017, 16:46:21
Co do sprezarki to nie jestem pewien czy dla jej obslugi jest uzywany przelacznik impulsowy czy zwykly, wiec na razie uzywany jest zwykly. Jesli to jest zle, mozna latwo poprawic jak sie ktos doinformowany wypowie :d
Według schematu z "Vademecum" ma być zwykły (bistabilny), czyli jest dobrze.

"nowy system kontroli" oznacza miedzy innymi pewne uproszczenie w sterowaniu. Zamiast osobnych kombinacji dla wlaczania i wylaczania urzadzen, uzywany jest teraz ten sam klawisz, ktory przelacza urzadzenie z jednego stanu w drugi. Czyli jest pantograf jest opuszczony i wcisniemy O to sie podniesie, po kolejnym wcisnieciu O zostanie opuszczony, po kolejnym znowu podniesiony, itp.
Już teraz wiem, że będą z tym kłopoty w przypadku użycia PoKeys w pulpicie... Bywa czasami tak, że coś nie "zaskoczy" (jakiś chwilowy błąd komunikacji, przycięcie się symulacji itp.) i załączenie hebelka na pulpicie nie powoduje jego załączenia w MaSzynie. Wtedy trzeba taki hebelek wyłączyć i jeszcze raz załączyć. Po staremu podczas załączania hebelka PoKeys zawsze emuluje wciśnięcie klawisza z Shiftem (konkretna komenda na załączenie), a podczas wyłączania hebelka wciśnięcie klawisza bez Shiftu (konkretna komenda na wyłączenie). Po nowemu w takiej sytuacji dojdzie do tego, że hebelek na pulpicie zacznie działać przeciwnie do tego w MaSzynie. Chyba, że będzie można sobie w jakiś łatwy sposób skonfigurować dla PoKeys, że np. przejście pinu 4 w stan niski zawsze powoduje wyłączenie przetwornicy, a w stan wysoki załączenie przetwornicy i z kolei też odwrotnie dla dowolnego innego pinu, np. stan niski na pinie 5 załącza reflektor prawy, a stan wysoki na tym pinie wyłącza ten reflektor?

Ponadto moim zdaniem nawet przy zwykłej jeździe z klawiatury bywają takie sytuacje, że nie ma zbytnio czasu na oglądanie się czy jakiś hebelek jest załączony, czy wyłączony lub jest to po prostu niewygodne, a tak jak kliknę samo "C" bez Shiftu, to wiem, że na pewno nie zadziała mi przekaźnik nadmiarowy przetwornicy przy jej załączaniu (co swoją drogą też jest błędem...). W rzeczywistości takie rzeczy można sprawdzić na wyczucie ręką bez odrywania wzroku od szlaku (kiedy np. jedzie się w gęstej mgle i byłoby to zbyt ryzykowne).

Jezeli bedzie zapotrzebowanie to mozna zostawic obsluge lokomotywy takze z zewnatrz np w trybie debug.
Przydaje się podczas testowania zachowania lokomotywy w różnych sytuacjach i przy nagrywaniu różnego rodzaju filmików promujących symulator.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: pat w 09 Kwietnia 2017, 16:51:05
Tutaj mamy problem poruszony kilka postow temu, tzn ze w rzeczywistosci nie ma czegos takiego jak uniwersalny zestaw urzadzen w kabinie EU07, bo co egzemplarz to moze byc inaczej. I teraz sa dwie 'szkoly' -- jedna grupa uzytkownikow bedzie chciala sterowania ujednoliconego, a druga grupa bedzie chciala powiazania klawiszy z konkretnymi przyciskami.
Pogodzic sie tego za bardzo nie da, dlatego sklaniam sie ku rozwiazaniu, by sterowanie z klawiatury bylo mozliwie proste, natomiast zwolennicy realizmu beda sobie mogli aktywowac recznie konkretne kontrolki po wprowadzeniu dodatkowej obslugi mysza.

Uważam, że obecne (przed ostatnimi zmianami) podejście do sterowania jest czymś co sprawia, że MaSzyna jest tak dobrym symulatorem i należy bardzo uważać, by tego nie utracić. Głupi hebelek pantografu sprawia, że ma się uczucie podejmowanej decyzji i daje "symulatorowe" odczucia.
Jeżeli wszystkie lokomotywy w danej rodzinie czy serii będą zbyt podobne do siebie (chociażby w kwestii sterowania) to po mieć różne numery lokomotyw w symulatorze? To są pytania i wnioski, które nasuwają się mi.
Nie mam wiedzy potrzebnej by osądzić czy różnice w urządzeniach np. w EU07 byłyby poważnym problemem przy sterowaniu "bardziej realistycznym" (o ile można je tak nazwać), ale chętnie nawet z samej ciekawości bym je poznał :) Masz może pod ręką jakiś interesujący przykład?

Rozwiązaniem optymalnym może być oddanie wyboru w ręce użytkownika. Myśląc całkowicie samolubnie - nie mogę się doczekać obsługi urządzeń myszą :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 09 Kwietnia 2017, 16:52:44
Jezeli bedzie zapotrzebowanie to mozna zostawic obsluge lokomotywy takze z zewnatrz np w trybie debug.
Przydaje się podczas testowania zachowania lokomotywy w różnych sytuacjach i przy nagrywaniu różnego rodzaju filmików promujących symulator.
Dodatkowe wpisy w ini.txt. BajerMode 0              //1 włączenie bajerów.
Cytuj
Jeżeli wszystkie lokomotywy w danej rodzinie czy serii będą zbyt podobne do siebie (chociażby w kwestii sterowania) to po mieć różne numery lokomotyw w symulatorze? To są pytania i wnioski, które nasuwają się mi.
Aby można było wstawić w scenerię 30 siódemek i każda mijana, była inna.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: pat w 09 Kwietnia 2017, 17:02:12
Aby można było wstawić w scenerię 30 siódemek i każda mijana, była inna.

To jest oczywiście niepodważalna zaleta i nie neguję jej. Ale czy unikalność danego numeru nie jest warta podkreślenia przez fakt, że unikalny zestaw urządzeń w danej kabinie EU07 bedzie sterowany... unikalnie?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 09 Kwietnia 2017, 17:07:21
Tak, ale tylko oddać to można sterowaniem za pomocą myszy. Klawiatura się do tego nie nadaje.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 09 Kwietnia 2017, 18:14:49
Już teraz wiem, że będą z tym kłopoty w przypadku użycia PoKeys w pulpicie... Bywa czasami tak, że coś nie "zaskoczy" (jakiś chwilowy błąd komunikacji, przycięcie się symulacji itp.) i załączenie hebelka na pulpicie nie powoduje jego załączenia w MaSzynie. Wtedy trzeba taki hebelek wyłączyć i jeszcze raz załączyć. Po staremu podczas załączania hebelka PoKeys zawsze emuluje wciśnięcie klawisza z Shiftem (konkretna komenda na załączenie), a podczas wyłączania hebelka wciśnięcie klawisza bez Shiftu (konkretna komenda na wyłączenie). Po nowemu w takiej sytuacji dojdzie do tego, że hebelek na pulpicie zacznie działać przeciwnie do tego w MaSzynie. Chyba, że będzie można sobie w jakiś łatwy sposób skonfigurować dla PoKeys, że np. przejście pinu 4 w stan niski zawsze powoduje wyłączenie przetwornicy, a w stan wysoki załączenie przetwornicy i z kolei też odwrotnie dla dowolnego innego pinu, np. stan niski na pinie 5 załącza reflektor prawy, a stan wysoki na tym pinie wyłącza ten reflektor?
To jest cos, czym latwo moze zajac sie modul obslugi konsoli -- w duzym skrocie, moze on sobie trzymac 'stan' kontrolek pojazdu, i przekazywac komende zmiany stanu urzadzenia do kabiny tylko gdy ma to sens, tzn gdy ten stan wewnetrzny nie zgadza sie ze stanem zglaszanym przez konsole.

Jesli naprawde ktos sie uprze, to mozna dorobic obsluge wywolania konkretnych stanow, ale to raczej na pozniej, przy wprowadzaniu bardziej konkretnego trybu sieciowego. W miedzyczasie niech obecna wersja przejdzie troche testow, moze akurat sie spodoba ;)

Uważam, że obecne (przed ostatnimi zmianami) podejście do sterowania jest czymś co sprawia, że MaSzyna jest tak dobrym symulatorem i należy bardzo uważać, by tego nie utracić. Głupi hebelek pantografu sprawia, że ma się uczucie podejmowanej decyzji i daje "symulatorowe" odczucia.
Jeżeli wszystkie lokomotywy w danej rodzinie czy serii będą zbyt podobne do siebie (chociażby w kwestii sterowania) to po mieć różne numery lokomotyw w symulatorze? To są pytania i wnioski, które nasuwają się mi.
Tutaj warto chyba zwrocic uwage, ze wszystkie lokotywy w danej rodzinie/serii caly czas do tej pory byly identyczne pod wzgledem sterowania, to nie jest jakas nowosc wprowadzona przez zmiane schematu -- pantograf zawsze podnosiles przez shift-p a opuszczales przez p, bez wzgledu na to czy w danej lokomotywie byl przelacznik impulsowy, bistabilny albo jeszcze cos innego. Wylacznik szybki to wszedzie shift+m albo m, i niewazne ze w jednej lokomotywie bylo to kontrolowane impulsem z jednego przelacznika, a w innej przez dwa osobne przyciski... itp.

Od strony technicznej, gdyby chciec faktycznie symulowac wiernie obsluge kabiny, to rozwiazaniem bylby raczej tryb mieszany miedzy nowym i starym... ale wtedy z kolei pojawia sie problem ze nie kazdy da sobie gladko rade z aranzacja gdzie w jednej lokomotywie do obslugi np pantografu jest zawsze tylko klawisz p, a w innej to juz p i shift-p (co nam na marginesie praktycznie blokuje wykorzystanie tego shift-p do jakiejs innej funkcji)

Cytuj
Nie mam wiedzy potrzebnej by osądzić czy różnice w urządzeniach np. w EU07 byłyby poważnym problemem przy sterowaniu "bardziej realistycznym" (o ile można je tak nazwać), ale chętnie nawet z samej ciekawości bym je poznał :) Masz może pod ręką jakiś interesujący przykład?
Przyklady podal miko22 kilka postow wczesniej ( http://eu07.pl/forum/index.php/topic,28159.msg448445.html#msg448445 ), sama glupia obsluga pantografow moze byc na "dziesiec" roznych sposobow :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 09 Kwietnia 2017, 19:19:38
W EN57 sprezarka jest pod zwyklym heblem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 10 Kwietnia 2017, 20:39:32
Tak, ale tylko oddać to można sterowaniem za pomocą myszy. Klawiatura się do tego nie nadaje.

Właśnie chciałem to napisać ;) Z uwagą "albo pulpitu fizycznego". Ogólnie interfejs klawiaturowy użyty do sterowania z fizycznych pulpitów sprawdził się bardzo dobrze, ale troszkę w charakterze prowizorki. Byłoby chyba lepiej dla ludzi tworzących / rozwijających pulpity, gdyby dać im bardziej bezpośredni interface, czyli raczej komendy symulatora niż mapowane naciśnięcia klawiszy.
Nie można zapominać o tych urządzeniach, które są, dlatego "tryb kompatybilności" być musi, żeby te wspaniałe urządzenia nie przestały działać z nowymi wersjami. Postuluję jednak żeby nowe urządzenia miały interfejs kompletnie pomijający obsługę klawiatury. Zamiast tego możliwość wysłania "podnieś pantograf B" albo odczytania "czy przełącznik P123 jest włączony?". Tzn zamiast P123 być może nazwa funkcji jaką spełnia, jeśli jest to funkcja wspólna dla wielu pojazdów. Nazwy z numerkiem mogą mieć "uniwersale". Takie podejście mogłoby ułatwiać tworzenie realistycznego działania różnych wyłączników i przełączników bez specjalnego kombinowania. No i różne rodzaje sterowania byłyby niezależne od siebie. Tzn zmiany w układzie klawiatury nie powodowałyby żadnych zmian w obsłudze jakiegokolwiek podłączonego do MaSzyny pulpitu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 10 Kwietnia 2017, 21:13:45
Coś takiego zrobił @maciek001 i nawet działało to z dość prostym w obsłudze Arduino: http://eu07.pl/forum/index.php/topic,28460.0.html (opisane tam problemy udało się rozwiązać - jakby ktoś chciał, mam działającą na tamtym exe wersję kodu na Arduino). Steruje się nie emulując klawiaturę, a zmieniając wartości poszczególnych bitów/bajtów. Piny można sobie przypisać według własnego uznania z poziomu mikrokontrolera. Kwestia rozwinięcia o kolejne funkcje. Jedynie...:
Od exe eu07++170331 nie działa odbieranie informacji przez UART z zewnętrznego mikrokontrolera zrobione przez @maćka001 i dodane od exe eu07++170226, tzn. nie da się sterować nastawnikiem, hebelkami itd. Dodatkowo, jeśli dałoby zrobić tak, aby ta komunikacja działała również wtedy, kiedy exe jest oknem w tle (przy wyłączonej pauzie, gdy w tle), to z użyciem SCSa można by na jednym komputerze obsadzić dwie osoby - maszynistę sterującego jazdą pociągu z rzeczywistego pulpitu lokomotywy i dyżurnego sterującego ruchem z aktywnego okna SCSa na drugim monitorze. Dałoby się to zrobić? Właśnie kiedy chciałem to sprawdzić, zauważyłem powyższy błąd.
Nie sprawdzałem natomiast jeszcze działania kranów i mierników, ale raczej będzie działać. Jak jest obecnie, będę mógł sprawdzić dopiero w środę lub czwartek.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mar1294 w 10 Kwietnia 2017, 21:41:14
No ja się pogubiłem, i nie wiem co jest najnowsze by dobrze działało. Takie pytanie czy będzie coś zrobione z tym że składem trzęsie jak menelem po sporym nachlaniu się>< ? :D
Wątek przyklejony jest tylko do ogłoszeń deweloperów. Cała dyskusja tutaj. Przenoszę. @Stele.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 10 Kwietnia 2017, 22:00:39
Czy moze ktos sprawdzic i rozpedzic su46 do 120? Chodzi mi o to ze jadac z Janiszewa rozoedzilem sie do 120 na istatniej prostej i swiecila mi tylko jedna lampka od bocznikow. Czyzby lok nie wchodzil na boki czy w exe cos brakuje?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 10 Kwietnia 2017, 22:28:10
Postuluję jednak żeby nowe urządzenia miały interfejs kompletnie pomijający obsługę klawiatury. Zamiast tego możliwość wysłania "podnieś pantograf B" albo odczytania "czy przełącznik P123 jest włączony?".
No po zmianach w sterowaniu mniej wiecej tak to wlasnie wyglada, dla wszystkich urzadzen z klawiatura i mysza wlacznie -- czyli obiekt obslugujacy dane urzadzenie odczytuje i interpretuje sobie jego stan we wlasnym zakresie, i na tej podstawie wysyla ujednolicone komendy dla aktualnie obsadzonego pojazdu, mechanika albo symulacji jako takiej. A reszta exe nawet nie wie czy tych podlaczonych urzadzen jest jedno, czy kilka, i guzik ja to obchodzi.

Pewnym problemem moze byc podpiecie pod ten system obslugi biezacych pulpitow itp, bo tutaj trzeba takim urzadzeniem dysponowac zeby sprawdzic czy wszystko dziala. Z tego samego powodu jesli w danej chwili cos jest nie tak z obsluga kontrolerow to nie bardzo jestem w stanie to naprawic -- ta czesc kodu jest praktycznie w calosci oparta na kodzie ktory dostarczyl @maciek001 i ja tego nie ruszam :|

Takie pytanie czy będzie coś zrobione z tym że składem trzęsie jak menelem po sporym nachlaniu się>< ? :D
Zalezy, o ktorym trzesieniu tutaj mowa. W lokomotywie trzesie kamera na podstawie definicji bodajze w pliku mmd, tutaj zmian raczej nie przewiduje. Jesli chodzi o rzucanie obiektow widoczne na wiekszych sceneriach w pewnej odleglosci od srodka sceny, to tutaj plany co do pewnych eksperymentow sa, chociaz nie na zaraz juz, no i nie ma gwarancji ze zakoncza sie sukcesem.

edit: przy okazji w ramach glupich pytan. Dla pewnosci -- w rzeczywistosci przelaczniki czerwonych swiatel w kabinie kontroluja swiatla ktore zamontowane sa na tym wlasnie koncu lokomotywy, a nie na przeciwnym? Czyli zeby zapalic czerwone z tylu, trzeba przejsc do tylnej kabiny?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 10 Kwietnia 2017, 22:48:19
ta czesc kodu jest praktycznie w calosci oparta na kodzie ktory dostarczyl @maciek001 i ja tego nie ruszam :|
@maciek001 twierdzi, że nic wtedy nie ruszał, a jednak od ++170331 coś się popsuło...
Czyli zeby zapalic czerwone z tylu, trzeba przejsc do tylnej kabiny?
Dokładnie tak.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 10 Kwietnia 2017, 22:53:45
@maciek001 twierdzi, że nic wtedy nie ruszał, a jednak od ++170331 coś się popsuło...
Jest calkiem mozliwe ze np cos sie popsulo na moim koncu, przy laczeniu pull request od macka, i ja po prostu nie mam tego jak zauwazyc/zweryfikowac :) Byloby super gdyby maciek mogl sprawdzic, czy to co jest w biezacej githubowej wersji u mnie jest zgodne z tym, co ma u siebie, i dac znac jesli cos tam wyjdzie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 10 Kwietnia 2017, 23:42:45
Potwierdzam, że SU46 nie wchodzi wyżej jak na pierwszy bocznik. SU45 nie ma tego problemu co ciekawsze.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mk1991 w 11 Kwietnia 2017, 00:50:03
Ja z swojej strony nie jestem za przechodzeniem na sterowanie myszką. Niestety to wymaga pewnej ręki bardzo dobrego wzroku. A symulator ma być dla każdego, ja przynajmniej tak uważam. Ja na przykład jestem niewidomy i nie wchodzi w grę u mnie sterowanie czegokolwiek przy pomocy myszki. Robię dla symulatora to co mogę i co potrafię ale chciał bym jednak móc trochę pojeździć. Jeśli będziecie chcieli kiedyś przejść całkowicie na sterowanie myszką, to jednak postulował bym o to, żeby możliwe było wybranie sposobu kontroli. Maszyna nie wykorzystuje wszystkich możliwych skrótów klawiaturowych. Po za tym niektóre skróty mogą działać w odmienny sposób w zależności od kabiny, w której aktualnie się znajduję. To samo dotyczy maszynowni.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 11 Kwietnia 2017, 00:50:42
Potwierdzam, że SU46 nie wchodzi wyżej jak na pierwszy bocznik. SU45 nie ma tego problemu co ciekawsze.
W kodzie obslugi bocznikowania dla RelayType=46 byl blad. Zagadka: kto pierwszy znajdzie, jaki?
                    if ((MainCtrlPos > 9) && (ScndCtrlPos < ScndCtrlPosNo))
                        if ((ScndCtrlPos) % 2 == 0)
                            if ((MPTRelay[ScndCtrlPos].Iup > Im))
                                ++ScndCtrlPos;
                            else if ((MPTRelay[ScndCtrlPos - 1].Iup > Im) &&
                                     (MPTRelay[ScndCtrlPos].Iup < Vel))
                                ++ScndCtrlPos;

a swoja droga to SU45 ma chyba z kolei blad w .fiz, bo ma wpisany RelayType=0 mimo ze w kodzie exe jest specjalny wariant "45", ktory jak zgaduje ma obslugiwac ten wlasnie typ..?

(edit2: ustawilem na probe typ 45 dla SU45, ale w rezultacie nie wlacza bocznikow oprocz 1-ego stopnia, bo kod dla wariantu 45 dla stopnia 2-ego w gore oczekuje, ze dwa ostatnie parametry MotorParamTable podadza predkosc pojazdu przy ktorej nastepuje przelaczenie, a nie obroty. Czyli to chyba dla jakiegos innego pojazdu jest, albo .fiz dla SU45 wymaga wiecej korekt ;s

edit:
Jeśli będziecie chcieli kiedyś przejść całkowicie na sterowanie myszką, to jednak postulował bym o to, żeby możliwe było wybranie sposobu kontroli.
Tutaj nie ma obawy, w miare mozliwosci wszystkie funkcje beda dalej dostepne z klawiatury. Zmiana schematu sterowania jest miedzy innymi po to zeby "odzyskac" kombinacje dla obslugi ewentualnych dodatkowo wprowadzonych przelacznikow itp
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 11 Kwietnia 2017, 05:49:34
Czyli zmiana po stronie exe czy zmiana we .fiz obu pojazdow? zamieniajac parametr obrotow na predkosc.
Przy okazji pytanie do mechanikow, przy jakich szybkosciach nastepuje wbicie kolejnych bocznikow?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: jakubg1 w 11 Kwietnia 2017, 06:30:12
Zagadka: kto pierwszy znajdzie, jaki?
Wszystko było uzależnione od tego, czy aktualna pozycja nastawnika jest parzysta, zamiast zrobić to osobno.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 11 Kwietnia 2017, 06:54:06
Zagadka: kto pierwszy znajdzie, jaki?
Else powinno się tyczyć parzystości, a jest przyklejone do ostatniego ifa
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: adamst w 11 Kwietnia 2017, 07:39:46
Przy okazji pytanie do mechanikow, przy jakich szybkosciach nastepuje wbicie kolejnych bocznikow?

SU45:
II - powyżej 40km/h, III powyżej 50
SU46:
II i III - 40, IV - 50

Oprócz tego nastawnik musi być na pozycji 10 lub wyższej, i domyślnie - przy automatycznym sterowaniu - musi zostać osiągnięte maksymalne wzbudzenie prądnicy. Wtedy zostaje zwarty mikrostyk SWMx na regulatorze wzbudzenia, co załącza przekaźnik PZB1. Ten przekaźnik powoduje chwilowe odwzbudzenie prądnicy. Po osiągnięciu minimalnego wzbudzenia załącza się przekaźnik PWmin, który z kolei powoduje załączenie przekaźnika PZB2, a ten ostatni umożliwia załączenie odpowiedniego stycznika bocznikowania. Zwykle jeździ(ło) się z podpartym PZB2, co pomijało całą tę skomplikowaną sekwencję, i boki wchodziły uzależnione wyłącznie od pozycji nastawnika i prędkości.

Wyłączenie bocznikowania następuje przy spadku prędkości poniżej wartości podanych powyżej (powoduje to rozwarcie styków pomocniczych prędkościomierza), przy cofnięciu nastawnika na niższe pozycje, oraz gdy prąd trzeciego silnika trakcyjnego przekroczy próg zadziałania przekaźnika PB.

Przy cofaniu nastawnika na SU45 III bocznik wyłącza się poniżej 10 pozycji, II trzyma na pozycjach 7-9 i prędkości powyżej 50 km/h, I na pozycjach 7-9. Na SU46 IV zachowuje się tak jak III w 45, II i III zachowują się z grubsza podobnie do II w 45, i I tak samo w obu lokomotywach.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 11 Kwietnia 2017, 13:13:46
Wszystko było uzależnione od tego, czy aktualna pozycja nastawnika jest parzysta, zamiast zrobić to osobno.
Else powinno się tyczyć parzystości, a jest przyklejone do ostatniego ifa
Zgadza sie, i dlatego dobra praktyka sa klamry nawet dla pojedynczych instrukcji warunkowych ;)

(poprawka bedzie w nastepnym uaktualnieniu)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 11 Kwietnia 2017, 15:57:56
Tzn we fiz nic nie zmieniac? Exe wszystko rozwiaze? Bo jednak na 45 działa jak pisze Stel.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Balaclava w 11 Kwietnia 2017, 16:23:44
QueryParserComp był przepisywany na C++? Można go gdzieś znaleźć?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Tomaszek_Łódź w 11 Kwietnia 2017, 16:23:47
Nie działa podnoszenie pantografów.

Wiadomość przeniesiono do wątku dyskusyjno-testowego. Tamten wątek służy jedynie deweloperom - ogłoszenia, nowości, zmiany... | @macius5991
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 11 Kwietnia 2017, 17:26:34
Tzn we fiz nic nie zmieniac? Exe wszystko rozwiaze? Bo jednak na 45 działa jak pisze Stel.
exe to rozwiaze, mam to poprawione i teraz ladnie wchodzi do samego konca. 45 na biezacym exe dziala, bo ma wpisany taki najbardziej podstawowy schemat RelayType, zamiast specjalizowanego, i ten podstawowy krzaka nie mial.

Ale jakby ktos bardzo chcial, to moze sie pobawic dostosowaniem .fiz dla SU45 do specjalizowanego dla niej typu przekladni. Tzn wpisac jej RelayType=45 i w wierszach 1-3 MotorParamTable zamienic dwa ostatnie parametry, z wartosci biezacych na predkosci ktore podaje troche wyzej @adamst tzn chyba cos takiego
MotorParamTable:
0 20 100 3000 20.8 1340 1713
1 18.5 110 2700 25 40 40
2 17.2 135 2500 30 50 50
3 14.3 170 2000 48.5 1340 1713
END-MPT
(to bedzie dzialac dopiero od nastepnego uaktualnienia bo na ten moment tez jest zakrzaczone, ale opcja jest.

QueryParserComp był przepisywany na C++? Można go gdzieś znaleźć?
Nikomu sie nie chcialo przepisywac, w c++ jest wyciety i w calosci zastapiony przez cParser

edit: ok, male uaktualnienie

- naprawiona obsluga bocznikow dla RelayType 45 i 46

- podpiete pod nowy system kontroli obsluga drzwi i swiatel. wiaze sie to z pewnymi zmianami w obsludze swiatel:
-- swiatla glowne na obsadzonym koncu lokomotywy przelaczane sa klawiszami Y, U, I
-- swiatla czerwone na obsadzonym koncu lokomotywy przelaczane sa kombinacja Ctrl+Y i Ctrl+I
(jesli ktos sie uprze mozna wlaczyc naraz i jedne, i drugie, chociaz nie jest to chyba uzywane w praktyce)
-- aby przelaczyc swiatla na drugim koncu trzeba sie tam pofatygowac, co powinno ucieszyc zwolennikow realizmu :d

- w ramach koncertu zyczen, dodano obsluge dla wiecej niz jednego pliku logowania. Uaktywniana jest wpisem w .ini
multiplelogs yes
Jesli opcja jest aktywna, symulator zamiast plikow log.txt i errors.txt tworzy w katalogu logs odrebne pliki dla kazdego uruchomienia/scenariusza.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 11 Kwietnia 2017, 20:03:27
A co z obsluga swiatel w lokach jednokabinowych? gdzie był używany ctrl+shift? Co zmieniles ze nie mogę baterii wlaczyc?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 11 Kwietnia 2017, 20:10:00
Tam chyba tez sa podpiete dwie kabiny, tylko wyswietlaja to samo pomieszczenie?  Czyli wciskasz 'zmiana kabiny' zeby sie przeturlac na drugi fotel, i zalaczasz swiatla normalnie. Sprawdzajac na szybko 6dg wydaje sie to dzialac.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: szogun w 11 Kwietnia 2017, 20:11:51
W lokach które tego nie wymagają jest jeden model kabiny.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 11 Kwietnia 2017, 20:12:37
W SM42 jest jeden. I tam sa te wyłączniki swiatel na jednym pulpicie. Widze ze baterie teraz samym "j" się wlacza bez shiftu. Teraz nie mogę dizla zapalić. Co zmieniles w klawiszologi konkretnie?

Już widze shifta wylaczyles.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 11 Kwietnia 2017, 20:16:08
No tak, ta zmiana byla w poprzednim uaktualnieniu, i odnotowana:
Cytuj
Zamiast osobnych kombinacji dla wlaczania i wylaczania urzadzen, uzywany jest teraz ten sam klawisz, ktory przelacza urzadzenie z jednego stanu w drugi. Czyli jest pantograf jest opuszczony i wcisniemy O to sie podniesie, po kolejnym wcisnieciu O zostanie opuszczony, po kolejnym znowu podniesiony, itp. Docelowo zwalnia to duza kombinacje klawiszy, ktore moga byc wykorzystane do obslugi innych funkcji.
Czyli uruchomienie zamiast D, shift + J, Shift + O, shift + M itd to teraz D, J, O, M itd.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 11 Kwietnia 2017, 20:30:55
Czy możesz wystawić swoje fizyki do 46? U mnie nie działa bok w 46. Jeszcze będę kombinowal.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 11 Kwietnia 2017, 20:44:47
W zalaczniku, ale moje su46 jest standardowe, z paczki. Zarowno 45 jak i 46 wchodzi na wyzsze nastawienia powyzej 40-50 km/h, pod warunkiem ze nastawnik jest na pozycji 10 albo wyzszej, i moze to chwile potrwac.



Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 11 Kwietnia 2017, 20:59:00
Ok poszlo i u mnie. 4 bok wszedł dopiero po uzyskaniu 110km/h.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 11 Kwietnia 2017, 23:18:45
Rozkład jazdy we freefly zawsze jest wyświetlany dla pojazdu gracza. Wcześniej wyświetlało rozkład najbliższego dynamica, co pomagało w debugowaniu scenerii.
A jakby pokazywał rozkład dla pojazdu kontrolującego danego dynamica to już było by cudo. Można by śledzić rozkład siedząc w wagonie, co trochę by urozmaiciło jazdę w tym trybie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 11 Kwietnia 2017, 23:36:12
Rozkład jazdy we freefly zawsze jest wyświetlany dla pojazdu gracza. Wcześniej wyświetlało rozkład najbliższego dynamica, co pomagało w debugowaniu scenerii.
Nie widze tego u siebie. Zaladowalem Kaliska (start w kiblu), wysiadlem na peron, przedralowalem te 200-300m i pokazuje mi normalnie biezacy rozklad dla najblizszej lokomotywy.

edit: a nie, czekaj, przegapilem. Rozklad jest dla najblizszego, ale naglowek jest na sztywno dla kontrolowanego. Poprawi sie.

Dorobic wyswietlanie rozkladu dla wlasciciela zapewne da sie dorobic, przyjrze sie.

edit2: ok, poprawione; dodalem przy okazji wyswietlanie rozkladow takze dla pojazdow doczepionych do czegos co ma rozklad, bedzie w nastepnym uaktualnieniu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 12 Kwietnia 2017, 14:18:51
A mamy już możliwość wyświetlenia na ekranie pythona?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 12 Kwietnia 2017, 14:53:48
Wyswietlenia czego, rozkladu? Nie slyszalem nic o takim zapotrzebowaniu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 12 Kwietnia 2017, 14:57:15
Gadaliśmy o tym kiedyś z yB, ale że nikomu nie chciało się programować tabelki z rozkładem na ekranie, to również nikomu nie chciało się wyprowadzać go do pythona.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: matek123 w 12 Kwietnia 2017, 15:02:35
A czy na zasadzie 4 repla dałoby radę ogarnąć rozkład jazdy?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 12 Kwietnia 2017, 15:03:55
Gadaliśmy o tym kiedyś z yB, ale że nikomu nie chciało się programować tabelki z rozkładem na ekranie, to również nikomu nie chciało się wyprowadzać go do pythona.
aha :P W sumie wyprowadzic cos takiego jak nazwa nastepnej stacji itp nie byloby zbyt trudno, tylko pytanie na ile jest to rzeczywiscie potrzebne, tzn czy ktorys z istniejacych lub planowanych wyswietlaczy cos takiego pokazuje?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: matek123 w 12 Kwietnia 2017, 15:06:18
Któreś z EZT mają wyświetlany rozkład na komputerku.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 12 Kwietnia 2017, 15:20:08
Mam w zdjęciach z ekranem EN57a, ale przypisana jednostka w rozkładzie wskazuje na Elfa.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: matek123 w 12 Kwietnia 2017, 15:23:02
W ELFie jest rozkład przewijany na podstawie GPS przeskakuje ta zielona kropka.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 12 Kwietnia 2017, 15:52:24
Antek to zdjęcie było razem z fotkami na tekstury kabiny EN57AKŚ
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 12 Kwietnia 2017, 17:02:10
Jakie jeszcze relaytype exe obsluguje?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 12 Kwietnia 2017, 17:13:55
W mover ma zdefiniowane warianty 0, 1, 2, 41, 45, 46. 0-41 wygladaja tak:
(kod byl chyba automatycznie tlumaczony i mozna troche uprzatnac, ale poki dziala to sie nie chce)
                        case 0: {

                            if( ( Im <= ( MPTRelay[ ScndCtrlPos ].Iup * PosRatio ) ) && ( ScndCtrlPos < ScndCtrlPosNo ) )
                                ++ScndCtrlPos;
                            if( ( Im >= ( MPTRelay[ ScndCtrlPos ].Idown * PosRatio ) ) && ( ScndCtrlPos > 0 ) )
                                --ScndCtrlPos;
                            break;
                        }
                        case 1: {

                            if( ( MPTRelay[ ScndCtrlPos ].Iup < Vel ) && ( ScndCtrlPos < ScndCtrlPosNo ) )
                                ++ScndCtrlPos;
                            if( ( MPTRelay[ ScndCtrlPos ].Idown > Vel ) && ( ScndCtrlPos > 0 ) )
                                --ScndCtrlPos;
                            break;
                        }
                        case 2: {

                            if( ( MPTRelay[ ScndCtrlPos ].Iup < Vel ) && ( ScndCtrlPos < ScndCtrlPosNo ) && ( EnginePower < ( tmp * 0.99 ) ) )
                                ++ScndCtrlPos;
                            if( ( MPTRelay[ ScndCtrlPos ].Idown < Im ) && ( ScndCtrlPos > 0 ) )
                                --ScndCtrlPos;
                            break;
                        }
                        case 41:
                        {
                            if( ( MainCtrlPos == MainCtrlPosNo )
                             && ( tmpV * 3.6 > MPTRelay[ ScndCtrlPos ].Iup )
                             && ( ScndCtrlPos < ScndCtrlPosNo ) ) {
                                ++ScndCtrlPos;
                                enrot = enrot * 0.73;
                            }
                            if( ( Im > MPTRelay[ ScndCtrlPos ].Idown )
                                && ( ScndCtrlPos > 0 ) ) {
                                --ScndCtrlPos;
                            }
                            break;
                        }
PosRatio w wariancie 0 to stosunek biezacego stopnia nastawnikow glownego i bocznego do ogolnej ilosci pozycji dla tych nastawnikow. Wariant 1 przelacza na podstawie aktualnej predkosci, a wariant 2 podobnie jak 1, ale z uwzglednieniem mocy silnika w danej chwili, czy jakos tak. MPTRelay.Iup i .Idown to (zazwyczaj) ostatnie dwie wartosci w tabeli MotorParamTable w pliku fiz

edit: uaktualnienie na dzisiaj
- podpiete pod nowy system kontroli: czuwak i przelaczniki tylnych swiatel. Zeby sterowanie swiatlami nie platalo sie za bardzo w porownaniu z wersja borlandowa, do przelaczania tyllnych swiatel uzywany jest Ctrl + klawisz dla reflektorow (lub Ctrl + Shift + klawisz dla swiatel czerwonych) Dla swiatel przednich kombinacje to 'sam' klawisz dla reflektorow, i Shift + klawisz dla swiatel czerwonych. Efektem ubocznym jest tez ponowna mozliwosc zapalania swiatel koncowych 'zdalnie', przynajmniej na razie -- docelowo chce wprowadzic system, gdzie kazda kabina ma zdefiniowana kompletna liste przelacznikow ktore sa w niej zamontowane i ew. opcjonalny submodel 3d zwiazany z tym przelacznikiem, zamiast obecnej sytuacji w ktorej wymienione sa tylko przelaczniki z submodelami, a exe przyjmuje ze obecne sa wszystkie.

- w trybie debug komendy sterowania pojazdem sa (ponownie) przekazywane do pojazdu takze w czasie przebywania na zewnatrz

- drobne rozszerzenie funkjonalnosci czuwaka -- jesli zdefiniowany jest parameter "AwareMinSpeed" z wartoscia 0 to czuwak bedzie sie tez zalaczal na postoju, pod warunkiem ze nastawnik kierunku nie jest w pozycji neutralnej. Pozwala to na wierniejsze odwzorowanie zachowania lokomotyw takich jak SM42

- poprawione wyswietlanie rozkladu, bedzie on podany dla najblizszej lokomotywy, lub dla lokomotywy ciagnacej sklad, jesli najblizszy pojazd nie ma obsady wlasnej (nie wiem jak sie to zachowa przy jezdzie jako pasazer, ktos to bedzie musial sprawdzic)

- exe nie powinno sie wiecej wysypywac przy braku definicji dzwieku dla przelacznikow w kabinie itp

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 12 Kwietnia 2017, 21:14:45
Jeśli jesteś już przy przełącznikach, to może dałoby radę zrobić, żeby przełączniki mogły mieć dwa modele (do włączania i wyłączania). Wiem, że przetwornica itd tak ma, ale np. przełączniki drzwi, bo w nowych EZT są "impulsowe" do otwierania i zamykania, a także w starych kiblach mamy dwa pedały do dawania sygnału baczność.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 12 Kwietnia 2017, 21:21:14
Jak dojdzie do zmian w definicji kabiny, to chce tam przy okazji wcisnac informacje czy dany przelacznik jest impulsowy, bistabilny itp, bo przechowywanie tego w .fiz to troche nieporozumienie. Wtedy tez mozna pomyslec o dodaniu wariantow realizujacych tylko jedna funkcje zamiast dwufunkcyjnych, itp.

edit:
w dzisiejszym uaktualnieniu tylko male zmiany, ale powinno przypasc do gustu przynajmniej jednej osobie... :3

- podpiete pod nowy system kontroli: przelacznik wysokiego rozruchu / trybu manewrowego (klawisz f)
- przywrocone dzialanie dzwiekow hamulca dla kranow innych niz FV4a/FVel6

(gwoli wyjasnienia: istniejacy kod dzwieku hamulca dzialal, ale 1) wyliczany poziom glosnosci byl o wiele za niski i 2) dzwiek upuszczania powietrza z przewodu glownego wymaga dodatkowego wpisu w .mmd (airsound2) ktorego z reguly brakuje w starszym pojazdach. W najprostszej wersji mozna zduplikowac istniejacy wpis airsound tzn. dla np. 3e2.mmd ten kawalek konfiguracji powinien wygladac:
airsound: et21-hiss.wav 1000.0 -0.1
airsound2: et21-hiss.wav 1000.0 -0.1
warto tutaj zwrocic uwage, ze dzwieki dla "nowych" hamulcow maja glosnosc zdefiniowana parametrami 1000+ razy mniejszymi, czyli np 0.25, ale dla "starych" hamulcow zostawilem, przynajmniej na razie, wyzsze wartosci, dla zachowania 'zgodnosci wstecznej' z istniejacymi .mmd

Aha, wpisy airsound2 dla pojazdow ktorym ich brakuje bedzie musial zrobic ktos, komu zalezy na tym bardziej niz mnie :d
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: klimczok_mk w 14 Kwietnia 2017, 13:17:28
Wyłączenie baterii powinno powodować opuszczenie pantografów, oraz czy celowo zostały zamienione klawisze odluźniacza i przestawienia kranu hamulcowego w pozycje jazdy?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 14 Kwietnia 2017, 13:34:52
Celowo, w ramach porzadkow w sterowaniu: http://eu07.pl/forum/index.php/topic,28159.msg448243.html#msg448243
Z tego co widze pantografy nie opadaja tez w Borlandowym exe, wiec rozumiem ze to ma byc nowa funkcjonalnosc. A jak to w realu wyglada wtedy na pulpicie? Tzn czy przelaczniki same sie przestawiaja na pozycje off, czy pokazuja (nieprawidlowo) dalej stan podniesiony?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: matek123 w 14 Kwietnia 2017, 13:37:51
W realu hebelki same się nie ruszają.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 14 Kwietnia 2017, 13:41:41
@Klimczok:
1. A na którym exe tak było? Według mojej wiedzy ten warunek nigdy nie był spełniony.
2. Celowo były zamienione, co można przeczytać w changelogu przyklejonym w tym dziale, a także śledząc na bieżąco zmiany w exe.
Nie wiem co chcesz, pierwszego wynika, że to postulat. Co do drugiego, to proponuje stałe śledzenie zmian (to nie jedyna zmiana w obsłudze lokomotywy) i zachęcam do aktywnego przedstawiania uwag, skoro odpaliłeś exe.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 14 Kwietnia 2017, 13:45:05
Tak nawiasem mowiac, to dlaczego wlasciwie opadaja? Tzn rozumiem jesli do czegos tam jest potrzebne NN, ale jesli jest aktywna przetwornica itp to one nie korzystaja z tego ukladu?

Jak juz przy tym jestesmy, to jak pod tym wzgledem wyglada dzialanie kontrolek pulpitu? Bo tak jak jest teraz to swieca sie zawsze przy spelnionym warunku, co nie wydaje sie zbyt prawidlowe...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: jakubg1 w 14 Kwietnia 2017, 13:55:20
Na najnowszym exe nie działa żadna* sceneria i z żadnym pojazdem. Po załadowaniu słychać ciche tykanie, a okno symulatora zawiesza się i nic się nie da zrobić. Załączam log.
* - testowane tylko na TD
Możliwe że nie wykonałem jakiejś procedury, nie śledzę wątku na bieżąco.
PS. Ostatnie exe jakie testowałem (170330) chodzi bezproblemowo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 14 Kwietnia 2017, 14:03:06
Odczekaj z minutę. Od kilku wersji exe zawiesza mi się na kilkadziesiąt sekund na starcie. Słychać pierwszy dźwięk, zaskakują eventy odcinków izolowanych i nic więcej. Po minucie się odwiesza i działa dalej płynnie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 14 Kwietnia 2017, 14:08:54
Hmm przegapilem jakos ta wzmianke o takim zawieszaniu sie. W ramach szybkiego testu, sprawdzcie czy problem wystepuje nadal w wersji z tego zalacznika?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 14 Kwietnia 2017, 14:13:48
13s ładowania TD. ~25s na odwieszkę. Trzeba by zmierzyć czy coś się zmieniło, ale problem nadal jest.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: jakol112 w 14 Kwietnia 2017, 14:18:54
Tak nawiasem mowiac, to dlaczego wlasciwie opadaja? Tzn rozumiem jesli do czegos tam jest potrzebne NN, ale jesli jest aktywna przetwornica itp to one nie korzystaja z tego ukladu?
Z tego co wiem to krótko mówiąc wyłącznik baterii zabezpiecza cały obwód NN.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 14 Kwietnia 2017, 14:21:23
13s ładowania TD. ~25s na odwieszkę. Trzeba by zmierzyć czy coś się zmieniło, ale problem nadal jest.
Pomogloby, gdybys mogl wysledzic od ktorej konkretnie wersji pojawia sie problem. Myslalem ze to moze cos co wyskakuje przy braku gamepada, ale nie obserwuje tego u siebie po odpieciu, a 0330 bylo tak z piec uaktualnien temu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 14 Kwietnia 2017, 14:24:57
Na nvidii mialem taka zacinke raz. Odpalilem powtornie i minelo. Jednak faktycznie miedzy koncem ladowania a pokazaniem sie scenerii uplywa chwila. Ja tego nie zglaszalem, jakos mi nie dokuczylo. Wersja z 13 odpala sie jak pozostale od jakiegos czasu, poprawke b zerkne za jakies 30 minut. Jedyne co u mnie to nadal wywala losowo brak procedury wejscia w bibliotece msvcr. Czesciej wywala jak mam ustawione skalowanie tekstur na mniej niz 4096.
Z postulatow (koncert zyczen): po obejrzeniu filmu z Calkowa2, braklo mi spalin unoszacych sie na pojazdami. Mankamenty w postaci migania podsypek i trojkatow w swietle lamp lokomotywy w tym filmie wiadomo czemu sa.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: klimczok_mk w 14 Kwietnia 2017, 14:29:26
@Klimczok:
1. A na którym exe tak było? Według mojej wiedzy ten warunek nigdy nie był spełniony.
2. Celowo były zamienione, co można przeczytać w changelogu przyklejonym w tym dziale, a także śledząc na bieżąco zmiany w exe.
Nie wiem co chcesz, pierwszego wynika, że to postulat. Co do drugiego, to proponuje stałe śledzenie zmian (to nie jedyna zmiana w obsłudze lokomotywy) i zachęcam do aktywnego przedstawiania uwag, skoro odpaliłeś exe.
Nie napisałem że poprzednich exe tak było. To tylko było moje pytanie.
Na razie staram się wszystko sprawdzić. Jeżeli coś zauważę na pewno przedstawię swoje uwagi.
Dalej mam za słaby komputer na traxxa.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 14 Kwietnia 2017, 14:37:34
Z tego co widze pantografy nie opadaja tez w Borlandowym exe, wiec rozumiem ze to ma byc nowa funkcjonalnosc. A jak to w realu wyglada wtedy na pulpicie? Tzn czy przelaczniki same sie przestawiaja na pozycje off, czy pokazuja (nieprawidlowo) dalej stan podniesiony?
Elektrozawory pantografów zasilane są m.in. przez włącznik baterii i odpowiednie hebelki, więc w większości lokomotyw pantografy powinny opadać po wyłączeniu baterii, choć rzeczywiście w starym exe też to nie działało. Zostawać w górze powinny jedynie przy starym sterowaniu w EU07 4E i ET22 do nr 502 (tam są elektrozawory bistabilne z dodatkową cewką, którą trzeba zasilić, żaby pantograf(y) opadł(y), a z kolei nie ma możliwości ich opuszczenia z pulpitu przy wyłączonej baterii (i przetwornicy).
Tak nawiasem mowiac, to dlaczego wlasciwie opadaja? Tzn rozumiem jesli do czegos tam jest potrzebne NN, ale jesli jest aktywna przetwornica itp to one nie korzystaja z tego ukladu?
Kiedy wyłączy się baterię przy załączonych przetwornicach, to w ogóle nic się nie powinno stać poza tym, że wskazówka amperomierza opada wtedy do 0A, jeśli wcześniej pokazywała jakikolwiek prąd. Natomiast kiedy wyłączy się przetwornice przy już wyłączonej wcześniej baterii, to dzieje się coś takiego (https://www.youtube.com/watch?v=ig_S45WW110).
Jak juz przy tym jestesmy, to jak pod tym wzgledem wyglada dzialanie kontrolek pulpitu? Bo tak jak jest teraz to swieca sie zawsze przy spelnionym warunku, co nie wydaje sie zbyt prawidlowe...
W rzeczywistości żeby świeciły się kontrolki musi być załączona bateria (lub muszą pracować przetwornice - w każdym razie skądś musi być zasilanie). Dodatkowo niektóre kontrolki mają jeszcze inne uzależnienia (np. od wyłącznika rozrządu lub nastawnika kierunkowego, a niektóre jeszcze po kilka innych), ale tu znowu dużo zależy od konkretnej lokomotywy. Na pewno błędne jest natomiast uzależnienie kontrolki styczników liniowych od wyłącznika szybkiego i to, że kiedy wyłączy się WSa przy zaświeconej kontrolce wentylatorów oporów, nie da się jej wygasić, co powinno się stać po zejściu nastawnikiem jazdy do zera i też dopiero wtedy powinna zgasnąć kontrolka jazdy na oporach, jeśli świeciła się przed wyłączeniem WSa.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 14 Kwietnia 2017, 14:52:11
Jednak faktycznie miedzy koncem ladowania a pokazaniem sie scenerii uplywa chwila.
Tutaj warto zwrocic uwage, ze pasek postepu ladowania 'napelnia sie' po zakonczeniu ladowania scenerii, ale po tym nastepuje zaladowanie geometrii i tekstur dla wszystkich umieszczonych na scenerii pojazdow (plus kabina pojazdu prowadzonego) a to moze tez chwile potrwac, zwlaszcza przy pierwszym uruchomieniu. Ale to raczej cos innego niz to co ma u siebie Stele, chociaz co tam jest u niego, nie mam w tym momencie pojecia.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: klimczok_mk w 14 Kwietnia 2017, 14:57:18
Przy hamowaniu spotem (EN57-2xxx) gdy pojazdu już stoi hasler pokazuje przez chwilę jeszcze 20km/h i po chwili spada na 0km/h.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 14 Kwietnia 2017, 15:01:33
Ja to troszkę inaczej sprawdzam. Podczas ładowania scenerii wyjmuje na wierzch okno konsoli i czekam aż pojawi się koniec logu:Loading texture data from "dynamic\pkp\303e_v1\4e_1]podloga.dds"
Finished loading 3d model data from "dynamic\pkp\303e_v1\303e_1]kabina_a.e3d"
Player train init OK
Load time: 10 seconds
EVENT LAUNCHED: tdo_rez_shp by ep07-426-ep
Type: PutValues
Key pressed: [F10]
Key pressed: [Y]
W tym momencie na exe z 30 marca mam natychmiastowe pokazanie się okna symulacji co wygląda jak w załączniku.
Od 170405 mam zwiechę, krótka na TD zaledwie kilka, kilkanaście sekund, co pokazuje załącznik. Wydaje się że długo czekam na pokazanie się linijki: EVENT LAUNCHED: tdo_rez_shp by ep07-426-ep
Type: PutValues
Jak w załączniku 2.
ED:
Nie napisałem że poprzednich exe tak było. To tylko było moje pytanie.
Na razie staram się wszystko sprawdzić. Jeżeli coś zauważę na pewno przedstawię swoje uwagi.
Dalej mam za słaby komputer na traxxa.
Niby nie napisałeś, ale też nie napisałeś jasno, że to postulat.
Zachowanie haslera EN57-2xxx na exe z paczki i C++ u mnie jest takie samo. Przy czym może warto zauważyć, że mam tu średnio 120 FPS. Inna sprawa, że wskazówka w tej kabinie nie leży na 0.

ED2:
Exe170413b zwiecha jest i wydaje się większa niż na 170413.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 14 Kwietnia 2017, 16:28:55
OK, znalazlem gada. W kodzie "od zawsze" byl blad w resetowaniu wartosci zegara uzywanego do mierzenia uplywu czasu symulacji itp. W rezultacie przy pierwszym uruchomieniu niektore funkcje zamiast wykonac sie raz, wykonywaly sie po kilka-kilkanascie tysiecy razy. Dopoki pod ta petle podpieta byla tylko komunikacja z pulpitem przechodzilo to niezauwazone (bo pulpitem malo kto dysponuje) ale kiedy podczepilem tam takze uaktualnianie UI i pare roznych rzeczy, zaczelo to robic zauwazalna roznice :P
W zalaczonym uaktualnieniu powinno byc juz dobrze, ale prosze sprawdzic.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 14 Kwietnia 2017, 16:29:34
Potestowałem trochę ostatnie aktualizacje związane z nowymi przełącznikami i przyciskami. Zauważyłem, że w EN57 przyciski impulsowe przetwornicy działają bez zarzutów to znaczy, że w momencie włączania animuje się przełącznik włączający, a wyłączając przetwornicę, przełącznik wyłączający. Natomiast z pantografem jest problem, ponieważ przełącznik od podnoszenia, także opuszcza. W poprzednich exe  (tych przed nowymi przyciskami) było okej.

PS. Na laptopie sprawdziłem jeszcze jak ustawić sobie większe pole widzenia (czyli ctrl+scroll), i się miło zaskoczyłem bo działa "uszczypnięcie" panelu od myszki ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 14 Kwietnia 2017, 16:36:36
Natomiast z pantografem jest problem, ponieważ przełącznik od podnoszenia, także opuszcza. W poprzednich exe  (tych przed nowymi przyciskami) było okej.
Gwoli scislosci, w wersji Borlandowej tez bylo zle, bo tam sa przelaczniki bistabilne i do tego ten od opuszczania po uzyciu zostaje na stale w pozycji zalaczonej ;)  W wersji zmienionej nie ma jeszcze zaimplementowanej obslugi osobnego przycisku opuszczania, stad nieprawidlowe zachowanie.

Przy okazji, czy w EN57 tylny pantograph opuszczany jest tylko grzybkiem do opuszczania wszystkich pantografow? Bo nie widze do tego osobnego przelacznika, a rozumiem ze ten impulsowy do podnoszenia kontroluje tylko podnoszenie?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 14 Kwietnia 2017, 16:37:33
Na 170414 problem rozwiązany. Nie ma zawieszki. :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 14 Kwietnia 2017, 16:39:31
Natomiast z pantografem jest problem, ponieważ przełącznik od podnoszenia, także opuszcza. W poprzednich exe  (tych przed nowymi przyciskami) było okej.
Gwoli scislosci, w wersji Borlandowej tez bylo zle, bo tam sa przelaczniki bistabilne i do tego ten od opuszczania po uzyciu zostaje na stale w pozycji zalaczonej ;)  W wersji zmienionej nie ma jeszcze zaimplementowanej obslugi osobnego przycisku opuszczania, stad nieprawidlowe zachowanie.

Przy okazji, czy w EN57 tylny pantograph opuszczany jest tylko grzybkiem do opuszczania wszystkich pantografow? Bo nie widze do tego osobnego przelacznika, a rozumiem ze ten impulsowy do podnoszenia kontroluje tylko podnoszenie?

Ja na repo wrzucałem poprawkę. Wystarczyło w członie S dodać converter=impulse, panthograf=impulse i przełączniki działały bez problemu. Ten od podnoszenia wracał do pozycji po podniesieniu, a opuszczając prawidłowo animował się ten od opuszczania. Fakt, faktem, że było odwrócone stronami, że przód to tył tak jak napisałeś.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 14 Kwietnia 2017, 16:42:49
Wyłączenie baterii powinno powodować opuszczenie pantografów, oraz czy celowo zostały zamienione klawisze odluźniacza i przestawienia kranu hamulcowego w pozycje jazdy?

Niekoniecznie. Tak jak wspomiał @miko22, dopóki masz zasilanie z przetwornicy, wszystko chodzi. No i tak jak we wspomnianych 4E itd były osobne elektrozawory na podnoszenie i opuszczanie zaworów, tak samo jest w EN57. One zaczną stopniowo odrywać się od sieci dopiero wraz ze spadkiem ciśnienia w przewodzie zasilającym/obwodzie pantografów. Oczywiście gdy elektrozawory zostaną w takiej pozycji, po podpięciu przewodu zasilającego automatycznie pójdą w górę.

Przy okazji, czy w EN57 tylny pantograph opuszczany jest tylko grzybkiem do opuszczania wszystkich pantografow? Bo nie widze do tego osobnego przelacznika, a rozumiem ze ten impulsowy do podnoszenia kontroluje tylko podnoszenie?

Zgadza się.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 14 Kwietnia 2017, 16:57:04
Przy hamowaniu spotem (EN57-2xxx) gdy pojazdu już stoi hasler pokazuje przez chwilę jeszcze 20km/h i po chwili spada na 0km/h.
Na ile moge powiedziec to jest akurat normalne, w sense kod obslugi haslera ma tu celowo wpisana opozniona reakcje:
// skacze co sekunde - pol sekundy pomiar, pol sekundy ustawienie
(..)
// schodz powoli - niektore haslery to ze 4 sekundy potrafia stukac
to jest kod z 2003 i ja tutaj nic nie ruszalem :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 14 Kwietnia 2017, 16:59:57
Na 170414 problem rozwiązany. Nie ma zawieszki. :)
Potwierdzam, zawieszki brak.
Trochę science fiction @tmj, jak wygląda możliwość wytworzenia dymu, mógłbyś się odnieść? Oczywiście zdaje sobie sprawę, że nie teraz. QueuedEU kiedyś zrobił generator cząstek dymu i śniegu, ale wydajność tego była niska (wersja borlandowa).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 14 Kwietnia 2017, 17:16:09
Ewentualnie kiedys tak, ale w dosc dalszej przyszlosci -- systemy czasteczkowe wymagaja troche pracy, tak przy obsludze jak i przesylaniu uaktualnien do karty graficznej. Dobrym momentem zapewne bedzie tutaj robienie tego po zaimplementowaniu normalnych shaderow (zeby nie bylo takiego spadku wydajnosci jak na przejsciowych) a to z kolei moze nastapic po zakonczeniu unifikacji metod renderowania i (prawdopodobnie) wprowadzeniu obslugi materialow w miejsce obecnego definiowania pojedynczych tekstur.

W duzym skrocie w tym momencie ogolny plan jest nastepujacy:
faza 1
- skonczyc ogarnianie system kontroli, przynajmniej dla samego pojazdu
- skonczyc unifikacje systemow renderowania, poprawic przy okazji wysypy zwiazane z generowaniem geometrii w niektorych sytuacjach
- uporzadkowac nieco to, jak w tej chwili przechowywane i organizowane sa dane symulacji, glownie chodzi tu o redukcje bezposrednich wskaznikow do wszystkiego we wszystkim
faza 2 (bo zalezy od 1-ej)
- selekcja obiektow mysza -> umozliwi obsluga pojazdu mysza i edycje scenerii
- zapis stanu scenerii z poziomu symulatora, i ponowny odczyt -> niezbedne dla edycji scenerii z programu
- podpiecie normalnego interfejsu uzytkownika
- opcjonalnie, wprowadzenie shaderow, obsluga map normal/specular, shadow maps
- opcjonalnie, modul komunikacji sieciowej
faza 3 (bo zalezy od 2-ej)
- edycja scenerii z poziomu programu
- multiplayer

... a ile z tego wyjdzie, to juz inna para kaloszy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: klimczok_mk w 14 Kwietnia 2017, 21:25:44
Czy dzięki przepisaniu exe do c++ będą większe możliwości na rzeczywiste odwzorowanie sterowania pojazdów?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 14 Kwietnia 2017, 21:32:40
Samo przepisanie nie zmienia pod tym wzgledem nic, natomiast dalsza rozbudowa exe pod tym katem, jak najbardziej ;)  Przepisanie pozwala na uzycie bardziej wspolczesnych kompilatorow i dodatkowych elementow jezyka c++ co powinno ulatwic taka rozbudowe.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Piotr93 w 14 Kwietnia 2017, 22:17:07
Nie wiem czy to było poruszane, czy w SU45/46 dałoby radę przypisać przełącznik "grzania" tak aby n.p po wciśnięciu klawisza "H" ustawiał się w pozycji 1 po wciśnięciu drugiego razu na 2 pozycję, i tak aż do końca i powrót? Coś jak w trainz jest w kabinie Adama. (to tylko moja sugestia)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 14 Kwietnia 2017, 22:53:45
A ten przelacznik w Trainz to cos robi, czy tylko tak dla picu jest? Bo to dwie rozne rzeczy, a w exe z tego co widze na razie jest tylko implementacja ogrzewania pociagu (i w sumie chyba tez dla picu, ale nie przygladalem sie)

Ogolnie rzecz biorac to rozbudowa kabiny o dodatkowe elementy mialaby sens po ogarnieciu tego, jak kabiny sa zorganizowane i definiowane w exe, a to z kolei moze sie wiazac z przekonstruowaniem tego jak traktowane sa obwody i inne flaki w pojazdach. Na forum chyba wypowiadalo sie pare osob, ze to jest temat ktory ich interesuje.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 15 Kwietnia 2017, 00:10:59
Dobra, ale na obecną chwilę nie ma zbytnio sensu ogrzewanie pociągu, skoro ono nic nie robi po za dodaniem obrotów silnika w spalinówkach. Fajnie, że takie coś jest, bo dodaje realizmu. Ale np. jeśli byłby bardziej rozwinięty system pasażerów (co pokazywał Q, czyli wsiadanie itd) to mogłoby to działać tak jak w OMSI czyli Omnibussimulator, gdzie mamy temperaturę powietrza na zewnątrz i w środku pojazdu, która jest uzależniona od tego, czy ogrzewanie jest załączone, czy nie. Ale na obecną chwilę to jest tak właściwie tylko bajer który większego sensu nie ma. Natomiast sama kwestia przełączników, to fajnie jeśli dałoby się przełączyć o tyle pozycji ile w danym pojeździe jest. W niektórych np. światła mają kilka pozycji.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 15 Kwietnia 2017, 06:09:33
Myślenie maszynisty pociągu towarowego. Moim zdaniem wyłącznik ogrzewania, jak najbardziej powinien zostać. Spełnia on funkcję bezpieczeństwa i jest zakodowany w psychice maszynisty kiedy i jak ma go używać. Macie do wykorzystania jeszcze inne przyciski (rolety, drzwi, wiatraczki, okno) które spełniają już mniejszą rolę.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: MichałŁ w 15 Kwietnia 2017, 07:37:24
Ja tu trochę błądzę. Nie wiem jak naprawić problem z tan problem z pantografami w et41, które nie chcą się podnosić.
Znalazłem to:
Cytuj
Na nowych exe nie działa mi et41_v2 wstawiony jako AI. Mimo wstawienia z V=0.1 lok się nie uruchamia. W errors.txt jest coś takiego:
Kod: [Zaznacz]

Animations tag is missing from the .mmd file "dynamic\pkp\et41_v2\203e-a.mmd"
Animations tag is missing from the .mmd file "dynamic\pkp\et41_v2\203e-b.mmd"


Jak rozumiem fakt braku animacji powoduje, że lok nie ma prądu (bo nie podnoszą się pantografy)? Ktoś mądry jest w stanie te animacje dopisać?
i to
Cytuj
Zrobione dawno temu. :) http://eu07.pl/daily/export/dynamic/pkp/et42_v2/
Ale za bardzo nie wiem co z tym zrobić. Może ktoś pomoże.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: matek123 w 15 Kwietnia 2017, 07:40:45
To wina jednej linijki w mmd. Wystarczy jak zapiszesz te pliki u siebie i wkleisz do dynamic/pkp/et42_v2. Z mmd i txt może będziesz musiał kombinować z prawoklik i zapisz element docelowy jako.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: MichałŁ w 15 Kwietnia 2017, 08:41:37
Dobrze. Ale problem dotyczy nie et42 tylko et41. To muszę jakąś linijkę z mmd et42 zamienić z mmd et41?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: matek123 w 15 Kwietnia 2017, 08:43:56
Sorka, poranek wczesny. http://eu07.pl/daily/export/dynamic/pkp/et41_v2/ ten link, i mmd wrzucić do ET41_V2. (UWAGA: mamy w paczce ET41_V1 i V2)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: MichałŁ w 15 Kwietnia 2017, 08:50:36
Teraz jest dobrze. Cały czas się zastanawiałem jak to jest że problem jest w jamniku a naprawiać mam w rusie. Dziękuje za pomoc.

EDIT.
Teraz tak mając czas pojeździć na tym exe zauważyłem że kiedyś jesteśmy poza kabiną nie można sterować nastawnikiem hamulcem itp. Moim zadaniem to nie jest dobre rozwiązanie gdyż to uniemożliwia sprawne prowadzenie misji manewrowych. Moim zdaniem przynajmniej nastawnik jazdy kierunku hamulec dodatkowy i samoczynny powinien być możliwi do obsługi spoza kabiny.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 15 Kwietnia 2017, 11:12:34
Cytuj
Moim zadaniem to nie jest dobre rozwiązanie...
Też tak myślałem, szczególnie manewrowo3. Idąc tym tropem, z kabiny powinniśmy mieć możliwość podczepiania i odczepiania (insert/delete). Po dłuższym namyśle jednak nie jestem pewien. Mnie bardziej przemawia napisanie skryptu wirtualnego manewrowego, który obsługuje sprzęgi ograniczając nasze wysiadanie i wsiadanie do kabiny.
Wspomniane było, że możliwość sterowania po za pojazdem, pozostanie w debug mode.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: MichałŁ w 15 Kwietnia 2017, 11:24:54
Akurat tu mi nie chodzi o sprzęganie, bo to nawet w prawdziwym świecie musi robić maszynista. Ja mam na myśli to że w realu mam ustawiacza który mówi mi przez radio albo podaje sygnały ręczne kiedy dojeżdża się do składu albo przy zwrotnicach mając cały bat wagonów przed albo za sobą. Na starych exe wyskakiwało się z kabiny i było się takim wirtualnym ustawiaczem-maszynistą czyli sterowało się maszyną podczas dojeżdżania czy krzyżowania z perspektywy ustawiacza. Teraz jest to bardzo niewygodne lub nawet niewykonalne.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 15 Kwietnia 2017, 11:38:06
Chodzi nam dokładnie o to samo, tyle że nie dość sprecyzowałem o co mi chodzi.
Chcesz powiedzieć że jak mamy 17 wagonów na haku, to maszynista leci na koniec składu podpinać następne 4?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: MichałŁ w 15 Kwietnia 2017, 11:52:14
Na przetoku nie będzie spinał ani rozpinał. Ale kiedy zapina się lokomotywą pod sformowany skład to raczej będzie spinał się sam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 15 Kwietnia 2017, 12:42:52
Ja mam na myśli to że w realu mam ustawiacza który mówi mi przez radio albo podaje sygnały ręczne kiedy dojeżdża się do składu albo przy zwrotnicach mając cały bat wagonów przed albo za sobą. Na starych exe wyskakiwało się z kabiny i było się takim wirtualnym ustawiaczem-maszynistą czyli sterowało się maszyną podczas dojeżdżania czy krzyżowania z perspektywy ustawiacza. Teraz jest to bardzo niewygodne lub nawet niewykonalne.
Zgadzam się. Teraz bardzo ciężko dojeżdża się tymi przykładowymi 17 wagonami do 4 następnych, kiedy nie widać, ile jeszcze zostało do tych 4. Trzeba wyskakiwać z kabiny, lecieć do tego 17. wagonu, żeby sprawdzić, ile trzeba jeszcze podjechać, wskakiwać do kabiny, żeby ew. skorygować moc lokomotywy/prędkość, znowu lecieć na koniec składu itd. Na starszych exe można było być cały czas przy tym 17. wagonie i na bieżąco kontrolować parametry jazdy, żeby nie zatrzymać się 10m od następnego wagonu lub nie dobić do niego. To samo przy zatrzymywaniu się przy tarczach manewrowych czy zaraz za rozjazdami. Do tego moim zdaniem dużo wygodniejsze były stare prędkości latania po scenerii, bo w razie potrzeby można było szybko przelecieć na koniec składu ([Ctrl]+[strzałka] czy nawet przez chwilkę [Ctrl]+[Shift]+[strzałka] przy dłuższym składzie) i zmienić się chwilowo z maszynisty/manewrowego w ustawiacza, który jak napisał @MichałŁ, stałby tam w rzeczywistości i np. przez radio podawał, jaka jeszcze odległość została do następnego składu, pod który się podjeżdża.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Kwietnia 2017, 12:59:08
Biorac pod uwage, ze te wymagania sa dosc sytuacyjne i w calosci adresuje je debug mode, czy nie wystarczy zwykle przelaczenie shift+ctrl+f12 na czas tego manewru, i wylaczenie po fakcie? Wtedy i biegasz dookola skladu szybciej, i mozna sterowac bez potrzeby przebywania w kabinie.

A co do wlasciwego zaadresowania problem, to sklanialbym sie raczej w strone dodania takiego 'wirtualnego ustawiacza' ktory podaje do kabiny odleglosc konca skladu do najblizszego pojazdu. Zwlaszcza ze mozna takiego rowniez zastapic pomocnikiem/ustawiaczem 'prawdziwym' przy multiplayerze.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 15 Kwietnia 2017, 13:04:11
Praca manewrowa nie może wymagać debugmode. Szary gracz nie powinien musieć nawet wiedzieć o tym trybie. O ile prędkość lotu z shift+strzałka w trybie normalnym jest moim zdaniem wystarczająca, to kontrola numerycznej+kierunku z freefly powinna pozostać z tego względu. No albo "asystent parkowania". Może być póki co jako odległość do pojazdu na interfejsie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 15 Kwietnia 2017, 13:13:30
Nie twierdzę jak "ma być", tylko po prostu moim zdaniem akurat to było po staremu lepiej/wygodniej i nie zmniejszało zbytnio realizmu.
Może być póki co jako odległość do pojazdu na interfejsie.
Zawsze to coś, ale nie zapominaj o tarczach manewrowych i rozjazdach (kiedy np. nie ma Tm).

Edit:
A to to już mamy jako odległość do sygnału podane na diagnostyce.
Ok., cofam powyższe.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Kwietnia 2017, 13:20:12
Ale w przypadku rozjazdow i tarcz manewrowych to jak to wyglada w rzeczywistosci? Tez jest zawsze pomocnik dajacy sygnaly, czy jednak maszynista musi polegac na znajomosci dlugosci skladu i opierac sie na slupkach i/lub wyczuciu?

Pytam, bo nie jest to jakis straszny problem zeby sterowanie wlaczyc ponownie, ale chcialbym na ile to mozliwe mniej wiecej odwzorowac jak to sie 'naprawde' odbywa.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: adamst w 15 Kwietnia 2017, 13:20:21
A ten przelacznik w Trainz to cos robi, czy tylko tak dla picu jest?

Robi :-) Po pierwsze normalnie przełącza napięcie prądnicy ogrzewczej, i wpływa na sterowanie obrotami zgodnie z rzeczwistością. Ponadto mam zrobioną uproszczoną symulację obwodu grzewczego. Działa to w ten sposób, że każdy wagon w składzie stanowi dla obwodu ogrzewania obciążenie w postaci rezystancji 400Ω.  Tak więc licząc wagony obliczam sobie z wzoru na równoległe połączenie rezystancji rezystancję wypadkową. Mając to oraz napięcie ogrzewania, obliczam prąd i moc grzania, którą dodaję do obciążenia silnika spalinowego. Tak więc załączenie ogrzewania znacząco wpływa na charakterystykę trakcyjną.

Dodatkowo mam w kabinie jako "lampkę" kwitek z rozkazem uruchomienia ogrzewania, gdy zostanie zdefiniowana temperatura otoczenia poniżej 10 stopni.

To sztywne ograniczenie (każdy wagon=400Ω) wynika z tego, że nie mogę w prosty sposób odczytać typu wagonów i ich parametrów (wymagałoby to ujednolicenia skryptu w wagonach, co przy wielu twórcach wagonów i mnogości modeli wagonów będących w obiegu jest mało realne), za to łatwo mogę je policzyć.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 15 Kwietnia 2017, 13:23:08
A to to już mamy jako odległość do sygnału podane na diagnostyce.
Prywatnie jestem przeciwnikiem zmian w sterowaniu, aby tylko zmieniać czy na przyszłość. Raz na tydzień symka odpalam do jazdy i ostatnio to długo się drapałem po głowie jak światła ustawić. Duża literka on, mała literka off było najbardziej intuicyjnie dla przełączników bistabilnych i przy tym pozostanę.
We freefly jak najbardziej warto wyciszyć cała kabinę, ale blokada sterowania elementów kluczowych nie bardzo ma sens. W końcu nie opuszczamy pojazdu by pochodzić ludzikiem po mapie. Ciągle jesteśmy jego maszynistą i jeśli nie włączyliśmy AI (co blokuje kontrolę w trybie normalnym i tak), to raczej zrobiliśmy to dla ładnego widoczku kosztem realizmu albo właśnie dla widoczności przy manewrach i nie chcemy żonglować kamerami.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Robert83 w 15 Kwietnia 2017, 13:29:22
Też jestem tego zdania. Wcześniej było lepiej manewrować i zapinać wagony.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 15 Kwietnia 2017, 13:35:38
Prywatnie jestem przeciwnikiem zmian w sterowaniu, aby tylko zmieniać czy na przyszłość. [...] Duża literka on, mała literka off było najbardziej intuicyjnie dla przełączników bistabilnych i przy tym pozostanę.
Moim zdaniem też domyślnie mogłoby zostać po staremu, a przyszłościowo to np. wewnętrznie w exe odkleić sterowanie od samej klawiatury, żeby można było sterować też innymi urządzeniami oraz dodać możliwość własnej konfiguracji klawiszologii - wtedy każdy ustawi sobie według własnego uznania i po problemie... Choć podkreślam, że to tylko moje zdanie i nie chcę się sprzeczać.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Kwietnia 2017, 14:00:45
Duża literka on, mała literka off było najbardziej intuicyjnie dla przełączników bistabilnych i przy tym pozostanę.
Z jednej strony tak, ale z drugiej dzieki temu rozwiazaniu wszechobecne sa kombinacje typu shift+ctrl+klawisz co z intuicja ma malo wspolnego, i praktycznie zaczyna brakowac miejsc, pod ktore mozna podpiac ew. nowe funkcje. Przyznam sie, ze jezdzac do tej pory dobrej polowy funkcji nie uzywam w ogole nie dlatego ze nie chce, ale zwyczajnie nie pamietam pod jaka dziwna kombinacja zostalo cos umieszczone, a eksperymentowac w trakcie jazdy jest dosc trudno.

Też jestem tego zdania. Wcześniej było lepiej manewrować i zapinać wagony.
Ja bym tutaj powiedzial raczej, wczesniej bylo latwiej :) I zebysmy sie zle nie zrozumieli, tez uwazam ze to bylo wygodne. Ale wolalbym, by tego typu operacje odzwierciedlaly to, jak sa przeprowadzane w rzeczywistosci. Czyli jesli maszynista cos tam robi bez magicznego pomocnika i zdany/zdana jest na siebie bez magicznego latania po terenie i zdalnej obslugi lokomotywy, to robic to w ten sposob. Jesli jednak bedzie zapotrzebowanie by bylo 'tak jak przedtem' to mozna to zawsze przywrocic.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: ST44-003 w 15 Kwietnia 2017, 14:12:13
Będzie działać w najbliższym czasie "depaturesignal"?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Balaclava w 15 Kwietnia 2017, 14:24:28
Tak z innej beczki, to co jest przyczyną nagłego skoku między dźwiękiem uruchamiania silnika i pracy silnika w spalinówkach?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Kwietnia 2017, 14:57:36
Będzie działać w najbliższym czasie "depaturesignal"?
Przeciez dziala, jest pod klawiszem / jak bylo (tam przynajmniej, gdzie jest zdefiniowany czyli np EN57)  Zeby bylo smieszniej dziala nawet bez wlaczonej baterii/obwodow co nie wiem czy jest prawidlowe, ale to chyba nie o to w pytaniu chodzi :d

Tak z innej beczki, to co jest przyczyną nagłego skoku między dźwiękiem uruchamiania silnika i pracy silnika w spalinówkach?
Nie ruszalem dzwiekow, wiec nie wiem, ale prawdopodobnie roznica miedzy zdefiniowanym dzwiekiem uruchomienia, i pracy? Nie wiem czy exe robi tutaj przejscie z jednego do drugiego, czy po prostu przelacza na inny dzwiek.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 15 Kwietnia 2017, 15:00:09
Przełącza na inny dźwięk. Rozruch jest jednym samplem, praca drugim i to modulowanym zależnie od obrotów. Stąd skok.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: pol102 w 15 Kwietnia 2017, 15:54:23
Możliwe, że dałoby się to to zniwelować gdyby dźwięki były odtwarzane nie jeden po drugim, tylko na zasadzie miksu z narastaniem i opadaniem. Gdy dźwięk rozruchu się prawie kończy, rozpoczyna się dynamicznie narastający dźwięk pracującego silnika...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Carmelovy w 15 Kwietnia 2017, 16:14:11
Tak jak jest w Trainzie. :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: MichałŁ w 15 Kwietnia 2017, 16:33:24
Ale w przypadku rozjazdow i tarcz manewrowych to jak to wyglada w rzeczywistosci? Tez jest zawsze pomocnik dajacy sygnaly, czy jednak maszynista musi polegac na znajomosci dlugosci skladu i opierac sie na slupkach i/lub wyczuciu?

Pytam, bo nie jest to jakis straszny problem zeby sterowanie wlaczyc ponownie, ale chcialbym na ile to mozliwe mniej wiecej odwzorowac jak to sie 'naprawde' odbywa.
W realu to ustawiacz podaje przez radio lukę miedzy wagonami lub do interesującego nas punktu. Miarą tej odległości jest zwykle ilość wagonów.

Nie wiedziałem że w demugmode można jeździć po staremu zobaczymy jak to się spisuje.

EDIT
No i przetestowałem przetok na debugmode. Sterować idzie ale latanie po scenerii jest za szybkie ciężko trafić nad odpowiednia wajchę
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 16 Kwietnia 2017, 00:23:52
W dzisiejszym uaktualnieniu:

- podpiete pod nowy system kontroli: przekaznik samoczynnego rozruchu, aktywacja hamulca elektropneumatycznego, przelacznik ogrzewania, blokada drzwi, sygnal odjazdu

- dodana obsluga przycisku opuszczenia wszystkich pantografow (w kabinach wyposazonych w taki wihajster, czyli wpis pantalloff_sw w pliku .mmd z przypisanym sub-modelem), na ta chwile pod kombinacja Ctrl + P

- poprawiona nieco wizualizacja/obsluga pantografow w kiblach, tzn animacja przyciskow do obslugi pantografu przedniego, i ogolnie przyciski impulsowe dzialajace tylko w jedna strone, co znaczy ze nie da sie opuscic tylnego pantografu przyciskiem do podnoszenia

- na szybko/byle jak "poprawione" uzaleznienie dzialania kontrolek, wiekszosc powinna teraz dzialac gdy zalaczony jest akumulator lub przetwornica i ignorowac stan wylacznika szybkiego. Nie obejmuje to niestety kontrolek zrobionych "na opak" czyli takich, ktore w stanie wylaczonym udaja ze swieca, a po zalaczeniu udaja, ze gasna.

- dodana diagnostyka brakujacych sub-modeli przypisanych do urzadzen w kabinie. Bo niestety niektore pojazdy wygladaja tak:
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"
Failed to locate sub-model "odblprzeknadm" in 3d model "dynamic\pkp\en57-2000_v1\kabinaa.e3d"
Failed to locate sub-model "przetwwyl" in 3d model "dynamic\pkp\en57-2000_v1\kabinaa.e3d"
Failed to locate sub-model "omygod" in 3d model "dynamic\pkp\en57-2000_v1\kabinaa.e3d"
Failed to locate sub-model "telewizorzgasl" in 3d model "dynamic\pkp\en57-2000_v1\kabinaa.e3d"
Failed to locate sub-model "sygnodjazdu" in 3d model "dynamic\pkp\en57-2000_v1\kabinaa.e3d"
a ja potem siedze i sie zastanawiam czemu cos nie dziala :P

- tymczasowo przywrocona mozliwosc sterowania pojazdami w widoku zewnetrznym, takze w trybie zwyklym. Docelowo bedzie tutaj przelacznik w konfiguracji pozwalajacy sobie wybrac indywidualnie stopien masochizmu/realizmu, i kazdy bedzie mial tak, jak mu/jej wygodniej :d
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 16 Kwietnia 2017, 01:48:32
- na szybko/byle jak "poprawione" uzaleznienie dzialania kontrolek, wiekszosc powinna teraz dzialac gdy zalaczony jest akumulator lub przetwornica i ignorowac stan wylacznika szybkiego. Nie obejmuje to niestety kontrolek zrobionych "na opak" czyli takich, ktore w stanie wylaczonym udaja ze swieca, a po zalaczeniu udaja, ze gasna.
Nie działa, tzn. wyłączenie baterii przy działającej przetwornicy nadal powoduje wyłączenie wszystkiego. Przy okazji zauważyłem jeszcze inny błąd - kiedy przy starym systemie sterowania najpierw załączyło się hebelek przetwornicy, a dopiero później załączało się WSa, to przetwornica startowała dopiero po puszczeniu przycisku załączenia WSa (poprawnie - w rzeczywistości do puki trzyma się wciśnięty przycisk załączenia WSa, kiedy ten był wyłączony przed wciśnięciem przycisku, zamykają się tylko styki pomocnicze (jeden z nich zaświeca kontrolkę), a styk główny (podający zasilanie na obwód główny, w tym na przetwornicę), zamyka się dopiero po puszczeniu przycisku załączenia WSa), a teraz przetwornica startuje od razu po zaświeceniu się kontrolki. W ramach ciekawostek, przez takie "półzamknięcie" WSa w EU07 303E, ET41 od nr 85 i prawdopodobnie w ET22 można zrobić coś w rodzaju sterowania na zimno, tzn. kręcąc nastawnikiem jazdy styczniki liniowe, oporowe i bocznikowania zamykają się normalnie, a po puszczeniu przycisku załączenia WSa (zamknięcie styku głównego i zasilenie obwodu głównego z sieci) lokomotywa startuje od razu z aktualnej pozycji nastawnika (czyli tak, jak są ustawione styczniki).

Reszta rzeczy sprawdzając na szybko działa poprawnie. Natomiast jeszcze co do hebelków w EN57, to w rzeczywistości hebelek impulsowy od WSa służy tylko do jego załączania i nie ma bezpośredniej możliwość wyłączenia WSa jakimś dedykowanym hebelkiem czy przyciskiem, ale za to np. przez opuszczenie pantografów, ew. wyzwolenie któregoś z zabezpieczeń (przekaźniki nadmiarowe lub różnicowy).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 16 Kwietnia 2017, 02:04:05
Nie działa, tzn. wyłączenie baterii przy działającej przetwornicy nadal powoduje wyłączenie wszystkiego.
Ale w jakiej lokomotywie? Bo mozliwe ze tam jest swego rodzaju reakcja lancuchowa: wylaczenie baterii -> wylacza WS -> wylacza przetwornice i zostaje z niczym. Tak jest np w EU07, chociaz nie wiem na ile to jest prawidlowe.

Cytuj
Przy okazji zauważyłem jeszcze inny błąd - kiedy przy starym systemie sterowania najpierw załączyło się hebelek przetwornicy, a dopiero później załączało się WSa, to przetwornica startowała dopiero po puszczeniu przycisku załączenia WSa (poprawnie - w rzeczywistości do puki trzyma się wciśnięty przycisk załączenia WSa, kiedy ten był wyłączony przed wciśnięciem przycisku, zamykają się tylko styki pomocnicze (jeden z nich zaświeca kontrolkę), a styk główny (podający zasilanie na obwód główny, w tym na przetwornicę), zamyka się dopiero po puszczeniu przycisku załączenia WSa), a teraz przetwornica startuje od razu po zaświeceniu się kontrolki.
Aha, dobrze wiedziec. Zeby bylo smieszniej, to w wersji poczatkowej mniej wiecej tak bylo, ale zalozylem ze zalaczenie nastepuje przy zwarciu stykow a nie "po". Zobacze czy da sie tutaj zrobic to jak trzeba.

Cytuj
Reszta rzeczy sprawdzając na szybko działa poprawnie. Natomiast jeszcze co do hebelków w EN57, to w rzeczywistości hebelek impulsowy od WSa służy tylko do jego załączania i nie ma bezpośredniej możliwość wyłączenia WSa jakimś dedykowanym hebelkiem czy przyciskiem, ale za to np. przez opuszczenie pantografów, ew. wyzwolenie któregoś z zabezpieczeń (przekaźniki nadmiarowe lub różnicowy).
Przyznam ze zastanawialem sie jak przelacznik impulsowy robilby tutaj takze za wylacznik, a wychodzi na to ze odpowiedz brzmi "nie robi" :) OK, tez do poprawki.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 16 Kwietnia 2017, 02:14:11
Ale w jakiej lokomotywie? Bo mozliwe ze tam jest swego rodzaju reakcja lancuchowa: wylaczenie baterii -> wylacza WS -> wylacza przetwornice i zostaje z niczym. Tak jest np w EU07, chociaz nie wiem na ile to jest prawidlowe.
Sprawdzałem właśnie w EU07 i ET41. We wszystkich chyba lokomotywach jest tak, że włącznik baterii i przetwornica podają zasilanie na ten sam przewód. Na początku załączenie baterii potrzebne jest do uruchomienia lokomotywy, ale kiedy pracują już przetwornice, to jak pisałem wcześniej, wyłączenie baterii w rzeczywistości nie spowoduje nic oprócz opadnięcia wskazówki amperomierza NN na 0A (który i tak obecnie nie działa w MaSzynie). Dopiero po wyłączeniu przetwornic przy wyłączonej wcześniej baterii stanie się coś takiego (https://www.youtube.com/watch?v=ig_S45WW110).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Mariusz1970 w 16 Kwietnia 2017, 02:15:08
Co do wypisania braku submodeli, ja swego czasu napisalem tool, ale spolecznosc ignorowala tego typu bledy (jak rowniez wiele innych typow).  Jak czytam na SB, to twoje dzialanie w magiczny sposob (dla mnie nie zrozumialy), wplynie motywujaco na co najmniej 1 osob, aby posprzatac, co mnie bardzo cieszy :) , choc moze mu piorka opadna, jak zobaczy liczbe bledow :) (oby nie). Moj tool porownywal mmd z t3d/e3d.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 16 Kwietnia 2017, 02:47:47
Sprawdzałem właśnie w EU07 i ET41. We wszystkich chyba lokomotywach jest tak, że włącznik baterii i przetwornica podają zasilanie na ten sam przewód. Na początku załączenie baterii potrzebne jest do uruchomienia lokomotywy, ale kiedy pracują już przetwornice, to jak pisałem wcześniej, wyłączenie baterii w rzeczywistości nie spowoduje nic oprócz opadnięcia wskazówki amperomierza NN na 0A (który i tak obecnie nie działa w MaSzynie). Dopiero po wyłączeniu przetwornic przy wyłączonej wcześniej baterii stanie się coś takiego (https://www.youtube.com/watch?v=ig_S45WW110).
OK, dzieki za wyjasnienie sytuacji. Nie pamietam dokladnie, ale wydaje mi sie, ze jakis czas temu pytalem wlasnie czy wylaczenie baterii powinno powodowac odlaczanie WS tak jak to robi teraz, bo wydawalo mi sie to dosc dziwne, i padla odpowiedz ze tak jest prawidlowo, wiec nie ruszalem tego. Albo byc moze nie zrozumialem wlasciwie tego, co bylo powiedziane :)  W kazdym razie wyglada na to, ze jest to jeszcze jeden element do poprawki.

edit:
OK, w uaktualnieniu

- poprawka, przelacznik impulsowy nie wylacza raz zalaczonego wylacznika szybkiego

- poprawka, przy zalaczaniu wylacznika szybkiego przetwornica itp startuje dopiero po puszczeniu klawisza. czyli jesli ktos sie lubil bawic w zimny rozruch, moze bawic sie znowu

- poprawka, wylaczenie baterii przy wlaczonej przetwornicy w wiekszosci nie powoduje efektow ubocznym. Poza wylaczeniem reflektorow w kiblu, bo tutaj test jest robiony na podstawie stanu indywidualnego pojazdu, i dopoki sie tego nie ogarnie to exe nie zauwaza, ze w sasiednim czlonie chodzi sobie przetwornica

- dolaczona pod nowa kontrole zmiana predkosci dzialania hamulcow. Przy okazji jest nieco uproszczona: shift + B ustawia szybszy stopien pracy, a samo B wolniejszy, przechodzac w kolejnosci G -> O -> P -> P+Mg i odwrotnie, zaleznie od tego, jakie ustawienia obsluguje pojazd (na razie dziala tak tylko w pojezdzie, na zewnatrz jest po staremu)

- dodane wsparcie dla dedykowanego przycisku opuszczania tylnego pantografu, pantrearoff_sw do pary z juz istniejacym wylacznikiem pantografu przedniego. Przyciski takie sa wpisane np. w .mmd dla ET22-1078 (tyle ze zdefiniowane sub-modele nie istnieja, wiec w rezultacie pantografy mozna podniesc, ale juz nie opuscic, dopoki ktos nie naprawi t3d/e3d :P
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: RooteK w 16 Kwietnia 2017, 17:47:29
Jeżeli już jesteś przy rozszerzaniu sterowania i wyłączniku szybkim, dla ET22 można by wyprowadzić dodatkowo hebelek bistabilny załączający cewkę trzymającą WS, a na klawiszu "m" pozostawić przycisk impulsowy zasilający elektrozawór od zamykania WS-a.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 16 Kwietnia 2017, 17:53:11
Moge o tym pomyslec, jak mi ktos lopatologicznie wytlumaczy efekty takie aranzacji -- jaki jest w praktyce zauwazalny efekt takiego przelacznika trzymajacego WS (w stanie wylaczonym i zalaczonym) i jak to wplywa na funkcjonowanie tego przycisku impuslowego?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: RooteK w 16 Kwietnia 2017, 17:56:09
Najlepiej, gdyby wypowiedział się jakiś praktyk.

Z teorii działania wyłącznika szybkiego, cewka trzymająca powoduje, że po zamknięciu WS-a przyciskiem impulsowym jego zwora nie odpadnie, tylko pozostanie przyciągnięta - WS będzie trzymał. Bez zasilenia tej cewki WS powinien się rozłączyć po puszczeniu przycisku impulsowego (pod wpływem działania sprężyny).
Edit:
Dodatkowo, samo dociśnięcie zwory przez siłownik pneumatyczny zasilony przez elektrozawór przyciskiem impulsowym nie powoduje zamknięcia styków WS-a, tzw. pozycja przejściowa, dopiero po puszczeniu przycisku i cofnięciu się siłownika, o ile cewka trzymająca jest zasilona, następuje zamknięcie styków WS.

Edit2:
Sprawdziłem, że brakuje też kilku uzależnień. Aby cewka trzymająca mogla zostać zasilona, oprócz włączenia hebelka powinny być spełnione takie warunki jak: nastawniki jazdy w obu kabinach na pozycji "0", nastawnik kierunkowy na pozycji "naprzód".
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: MW w 16 Kwietnia 2017, 18:06:39

Wyrazy uszanowania dla wszystkich uczestników forum i sympatyków Maszyny.

Jak dotąd nie udzielałem się na forum, ale od prawie dziewięciu lat systematycznie śledzę rozwój symulatora i coś tam sobie dłubię w zaciszu domowym.

Chciałbym odnieść się do zagadnienia tekstur wymiennych w obiektach dynamic - temat był już poruszony w niniejszym wątku, ale bez wyraźnych konkluzji:
http://eu07.pl/forum/index.php/topic,28159.msg440046.html#msg440046
http://eu07.pl/forum/index.php/topic,28159.msg440054.html#msg440054

A. Po raz pierwszy tekstury wymienne pojawiły się od exe460 (tablice kierunkowe)
http://eu07.pl/forum/index.php/topic,26449.msg394653.html#msg394653

B. Pojawiła się również możliwość ustawienia 2-4 tekstur wymiennych w modelu dynamic
http://rainsted.com/pl/Symulator/MaSzyna/EU07.EXE_464
Nazwy poszczególnych tekstur powinny być tworzone poprzez dodanie przecinka i cyfry 1..4 do podanej we wpisie nazwy tekstury. Wymagane jest wpisanie krzyżyka # po nazwie modelu w MMD. Można użyć tego sposobu np. do modeli taboru w teksturą wymienną, rozdzieloną na kilka plików, w których znajdują się elementy specyficzne dla konkretnego egzemplarza taboru.

C. Autor powyższych rozwiązań rozważał także bardziej uniwersalny sposób przypisywania tekstur wymiennych do modeli, w którym nazwy poszczególnych tekstur nie byłyby wzajemnie uzależnione (jak to jest w sposobie powyższym).
http://eu07.pl/forum/index.php/topic,17095.msg394395.html#msg394395
Nazwy tekstur we wpisie dynamic miały być rozdzielone pionową kreską |. Chociaż nie znalazłem w dostępnej dokumentacji jawnego potwierdzenia wprowadzenia tego mechanizmu, to okazało się, że działa to od exe464 do exe478 włącznie (chociaż może w nie całkiem dopracowanej formie). Tu również wymagane jest wpisanie krzyżyka # po nazwie modelu w MMD. Zasady wpisów Map w plikach t3d są takie same jak w sposobie pierwszym.

Sposób z separacją tekstur kreską pionową zastosowałem np. do ustawiania wymiennych tekstur na modele kontenerów stanowiących ładunek platform. Chodzi w szczególności o kilka kontenerów (w tym różnych typów) ładowanych w różnych konfiguracjach na wagon. Każda konfiguracja stanowi osobny model ładunku (wpisany w plik .fiz platformy - do 17 wpisów). Zastosowanie tekstur wymiennych daje praktycznie nieograniczoną liczbę możliwych kombinacji załadowania.

W przytoczonym niżej przykładzie zastosowano zmodyfikowany model platformy Sgs. Tekstura wagonu została wpisana na stałe w modelu t3d (jest i tak tylko jedna dostępna). Wpisy tekstur (max. trzy pozycje) odnoszą się do kontenerów.

Przykłady wpisów:
node -1 0 sgs dynamic PKP\Sgs_v1 |k-22g_gatu1s|k-22g_rzdu1n|k-22g_hlxu1rw 412z_w 0 nobody 3 50 3kontenery22w enddynamic
node -1 0 sgs dynamic PKP\Sgs_v1 |k-22g_msku1s|k-22g_xinu1n 412z_w 0 nobody 3 40 2kontenery22-kw enddynamic
node -1 0 sgs dynamic PKP\Sgs_v1 |k-22g_eisu1z|k-42g_hdmu1c 412z_w 0 nobody 3 50 2kontenery42-22w enddynamic
node -1 0 sgs dynamic PKP\Sgs_v1 |k-22g_mscu1bz|k-45g_fciu1br 412z_w -1 nobody 3 50 2kontenery45-22w enddynamic
node -1 0 sgs dynamic PKP\Sgs_v1 |k-22g_dfsu1nz|k-4eg_gesu1n 412z_w 0 nobody 3 50 2kontenery4E-22w enddynamic

W załącznikach znajdują się obrazy dokumentujące działanie wcześniejszych oraz nowszych wersji exe dla powyższego przykładu.

Wydaje się, że wprowadzona została chyba dopiero faza wstępna opisanej funkcjonalności - stąd brak oficjalnego udokumentowania. Wynikają stąd też pewne niedociągnięcia: problemy z obsługą dwóch plików t3d (pojazd i ładunek) przy maksymalnej (4) liczbie tekstur, niespójność kolejności tekstur we wpisach dynamic i numerów we wpisach Map modeli t3d, itd.
Wszystkie tekstury muszą znajdować się w katalogu pojazdu, co powoduje konieczność mnożenia plików graficznych w przypadku stosowania takich samych tekstur w różnych modelach dynamic. Przydatna byłaby możliwość jakiejś obsługi ścieżek do plików z innych katalogów na poziomie wpisu dynamic. Od pewnego czasu symulator odczytuje już np. pliki rozkładów jazdy z podanymi ścieżkami we wpisach trainset.

Omawiany mechanizm tekstur wymiennych został utracony od exe479 i brak go również w exe c++.

O ile się nie mylę, rozważany był też inny sposób ustawiania tekstur wymiennych. Mianowicie w pozycji wpisu tekstury we wpisie  dynamic miałaby być umieszczana nazwa pliku .cfg. W takim pliku mogłaby być umieszczona lista tekstur oraz inne dane, np. lista submodeli wyłączonych w danej konfiguracji modelu z wczytywania itd. Każda nowa funkcjonalność w tym zakresie mogła by poszerzyć możliwości symulatora. Chociaż akurat dla omawianego przykładu z kontenerami trudno orzec czy byłoby to lepsze rozwiązanie (bez znajomości struktury postulowanych plików .cfg) -  być może liczba takich plików musiała by odpowiadać liczbie kombinacji tekstur.

Wspomniane mechanizmy tekstur wymiennych lub im podobne byłyby bardzo pożądane także dla modeli innych niż dynamic.

Z rzeczy marginalnych o charakterze estetycznym - mam prośbę o przywrócenia zamiany znaku podkreślenia na spację w numerze pociągu wyświetlanym z rozkładu (obecnie pod F2). Tak jest w exe borlandowym. Chodzi o numery z oznaczeniem rodzaju pociągu np. TMZEc_31582.


Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 16 Kwietnia 2017, 18:16:25
Lat temu ileś parser mmd przyjmował do wiadomości, że musi sięgać do innych katalogów (głównie nadrzędnych) poprzez użycie ścieżki względnej do pliku ze znakiem "..". Może tutaj to też zadziała?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 16 Kwietnia 2017, 19:36:08
Uzycie '..' zadziala, z tym ze tutaj jest haczyk: jesli podamy nazwe tekstury bez rozszerzenia, to exe zglupieje i obetnie wszystko od ostatniej kropki w elemencie .. do samego konca, zostawiajac cos co sie oczywiscie nie zaladuje. Jesli natomiast dodamy 'recznie' rozszerzenie (ktore i tak jest w trakcie ladowania obciete/zignorowane) to mozna robic cos takiego:
node -1 0 ET22-1078 dynamic PKP\ET22_V2 ../../../textures/test/201E-ZEZ-1078.dds 201E-ZEZ  0 headdriver 3 0 enddynamic
co spowoduje zaladowanie tekstury pojazdu nie z jego wlasnego katalogu, ale z podkatalogu 'test' umieszczonego w standardowym folderze 'textures'

Takie 'reczne' chodzenie po katalogach jest troche proszeniem sie o klopoty, niemniej jak na razie owszem, jest to jakies rozwiazanie :)

Na dluzsza mete, w zwiazku ze wprowadzaniem shaderow i byc moze takze dodatkowych tekstur z tym zwiazanych, organizacja moze sie zmienic i wygladac nastepujaco:

- plik t3d/e3d definiuje dla kazdego submodelu nazwe "materialu" np 'pudlo', 'szczegoly' czy co tam ktos sobie wymysli
- plik scenariusz definiuje polaczenie tych materialow z plikami definicji, czyli kontynuujac przyklad 'pudlo=et22-1078-pudlo.mat' 'szczegoly=et22szczegoly.mat' (nazewnictwo jest raczej dowolne, rownie dobrze mogloby byc 'pudlo=mojasuperhiperduperlokomotywazbananamiipomaranczami.mat')
- pliki .mat to pliki tekstowe, ktore definiuja konkretne tekstury wykorzystywane przez model/shader, np 'diffuse=et22-1078-pudlo.dds normal=et22-normal.dds'

i exe sobie takie cos sklada do kupy 'w druga strone', tzn przypisuje okreslona kombinacje tekstur dla poszczegolnych sub-modeli, bazujac na tym jaka kombinacja materialow zostala przypisana do konkretnego modelu. W ten sposob tekstury ktore da sie dzielic mozna dzielic, a jednoczesnie to co jest wymienne mozna wymieniac, i to bez limitow do ilus tam tekstur i wpisywania dziwnych petli w kodzie programu.

edit: co do obslugiwanych obecnie mechanizmow, o ile sie nie myle exe dalej obsluguje wersje z ",1 ,2 ,3" w nazwach tekstur. Wersja z pipe, "|" nie byla sprawdzana, bo nie wygladalo na to ze ktos z tego mechanizmu korzysta, ale skoro wychodzi ze tak, to zapewne da sie ja zaimplementowac ponownie, przyjrze sie.

edit2:
ok, poniewaz termin ewentualnych glebszych zmian jest delikatnie mowiac odlegly, tymczasowo przywrocilem do exe obsluge tekstur wymiennych rozdzielanych przez "|"  Nie bardzo moge sprawdzic czy na pewno zadzialaja jak trzeba, ale teoretycznie powinny. Nawiasem mowiac, przy podawaniu tekstur nie trzeba dawac znaku | na poczatku wpisu, wystarczy ze uzyte sa do rozdzielenia poszczegolnych nazw, czyli zamiast "|a|b|c" wystarczy "a|b|c"  Powinny tez dzialac w polaczeniu ze sztuczka opisana wyzej, nalezy tylko pamietac ze "instrukcje" zmiany katalogow musza byc powtorzone dla kazdej tekstury osobno.

poprawione jest tez wyswietlanie nazwy skladu, tzn bez podkreslen.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 17 Kwietnia 2017, 09:58:26
A u mnie kompletnie nic nie działa. Ani jedno exe :(
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 17 Kwietnia 2017, 10:04:23
Zainstaluj pakiety redystrybuacyjne. Bo wlasnie tego ci brakuje. Vcredist... Odpowiednie dla x32 i x64. W przypadku x64 biblioteki pythona. Wszystko w pierwszym poscie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: MW w 17 Kwietnia 2017, 10:42:22
Serdeczne dzięki za poprawki.

1. Tekstury wyświetlają się poprawnie.
2. Widzę też, że naprawiona została kolejność wyświetlania tekstur z listy – jest teraz zgodność z wpisami Map w t3d.
3. Numer z rozkładu wyświetla się prawidłowo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 17 Kwietnia 2017, 11:06:03
Dzięki za pomoc. Problem w tym, że nie mam pojęcia co dalej, po wypakowaniu. :(
Mój system jest 64-bitowy. Mam wypakowane pliki w folderze glew-2.0.0 |(jak na screenie poniżej).
Nie wiem jak je dalej wypakować i domyślam się, że instalować tylko vc_redist.x64?
Z góry dzięki za podpowiedź!
Wyskoczył mi przy nieudanej instalacji, poniższy kod:
[11A8:0CEC][2017-04-17T11:26:11]i001: Burn v3.7.3813.0, Windows v6.1 (Build 7601: Service Pack 1), path: C:\Users\Marko\Desktop\vc_redist.x64.exe, cmdline: '"C:\Users\Marko\Desktop\glew-2.0.0\bin\Release\x64\glew32.dll" -burn.unelevated BurnPipe.{29EA3275-3C24-48B7-A7AD-1277ADE0E689} {9B91F4B9-5993-4AC4-BABD-3D13B8C150CD} 3100'
[11A8:0CEC][2017-04-17T11:26:12]i000: Setting string variable 'WixBundleLog' to value 'C:\Users\Marko\AppData\Local\Temp\dd_vcredist_amd64_20170417112612.log'
[11A8:0CEC][2017-04-17T11:26:12]i000: Setting string variable 'WixBundleOriginalSource' to value 'C:\Users\Marko\Desktop\vc_redist.x64.exe'
[11A8:0CEC][2017-04-17T11:26:12]i000: Setting string variable 'WixBundleOriginalSourceFolder' to value 'C:\Users\Marko\Desktop\'
[11A8:0CEC][2017-04-17T11:26:12]i100: Detect begin, 10 packages
[11A8:0CEC][2017-04-17T11:26:12]i000: File search: windows_uCRT_DetectKey, did not find path: C:\Windows\system32\api-ms-win-crt-runtime-l1-1-0.dll
[11A8:0CEC][2017-04-17T11:26:12]i000: File search: windows_uCRT_DetectKeyExists, did not find path: C:\Windows\system32\api-ms-win-crt-runtime-l1-1-0.dll
[11A8:0CEC][2017-04-17T11:26:12]i000: Setting numeric variable 'windows_uCRT_DetectKeyExists' to value 0
[11A8:0CEC][2017-04-17T11:26:12]i052: Condition '(windows_uCRT_DetectKeyExists AND windows_uCRT_DetectKey >= v10.0.10137.0)' evaluates to false.
[11A8:0CEC][2017-04-17T11:26:12]i052: Condition '(windows_uCRT_DetectKeyExists AND windows_uCRT_DetectKey >= v10.0.10137.0)' evaluates to false.
[11A8:0CEC][2017-04-17T11:26:12]i052: Condition '(windows_uCRT_DetectKeyExists AND windows_uCRT_DetectKey >= v10.0.10137.0)' evaluates to false.
[11A8:0CEC][2017-04-17T11:26:12]i052: Condition '(windows_uCRT_DetectKeyExists AND windows_uCRT_DetectKey >= v10.0.10137.0)' evaluates to false.
[11A8:0CEC][2017-04-17T11:26:12]i052: Condition '(windows_uCRT_DetectKeyExists AND windows_uCRT_DetectKey >= v10.0.10137.0)' evaluates to false.
[11A8:0CEC][2017-04-17T11:26:12]i052: Condition '(windows_uCRT_DetectKeyExists AND windows_uCRT_DetectKey >= v10.0.10137.0)' evaluates to false.
[11A8:0CEC][2017-04-17T11:26:12]i052: Condition '(windows_uCRT_DetectKeyExists AND windows_uCRT_DetectKey >= v10.0.10137.0)' evaluates to false.
[11A8:0CEC][2017-04-17T11:26:12]i052: Condition '(windows_uCRT_DetectKeyExists AND windows_uCRT_DetectKey >= v10.0.10137.0)' evaluates to false.
[11A8:0CEC][2017-04-17T11:26:12]i101: Detected package: vcRuntimeMinimum_x64, state: Present, cached: Complete
[11A8:0CEC][2017-04-17T11:26:12]i101: Detected package: vcRuntimeAdditional_x64, state: Present, cached: Complete
[11A8:0CEC][2017-04-17T11:26:12]i101: Detected package: Windows81_x86, state: Absent, cached: None
[11A8:0CEC][2017-04-17T11:26:12]i101: Detected package: Windows81_x64, state: Absent, cached: None
[11A8:0CEC][2017-04-17T11:26:12]i101: Detected package: Windows8_x86, state: Absent, cached: None
[11A8:0CEC][2017-04-17T11:26:12]i101: Detected package: Windows8_x64, state: Absent, cached: None
[11A8:0CEC][2017-04-17T11:26:12]i101: Detected package: Windows7_MSU_x86, state: Absent, cached: None
[11A8:0CEC][2017-04-17T11:26:12]i101: Detected package: Windows7_MSU_x64, state: Absent, cached: Complete
[11A8:0CEC][2017-04-17T11:26:12]i101: Detected package: WindowsVista_MSU_x86, state: Absent, cached: None
[11A8:0CEC][2017-04-17T11:26:12]i101: Detected package: WindowsVista_MSU_x64, state: Absent, cached: None
[11A8:0CEC][2017-04-17T11:26:12]i052: Condition 'VersionNT64 >= v6.0 OR (VersionNT64 = v5.2 AND ServicePackLevel >= 1)' evaluates to true.
[11A8:0CEC][2017-04-17T11:26:12]i199: Detect complete, result: 0x0
[11A8:0CEC][2017-04-17T11:26:15]i200: Plan begin, 10 packages, action: Install
[11A8:0CEC][2017-04-17T11:26:15]i052: Condition '(VersionNT64)' evaluates to true.
[11A8:0CEC][2017-04-17T11:26:15]i052: Condition '(VersionNT64)' evaluates to true.
[11A8:0CEC][2017-04-17T11:26:15]i052: Condition 'VersionNT = v6.3 AND NOT VersionNT64' evaluates to false.
[11A8:0CEC][2017-04-17T11:26:15]w321: Skipping dependency registration on package with no dependency providers: Windows81_x86
[11A8:0CEC][2017-04-17T11:26:15]i052: Condition 'VersionNT = v6.3 AND VersionNT64' evaluates to false.
[11A8:0CEC][2017-04-17T11:26:15]w321: Skipping dependency registration on package with no dependency providers: Windows81_x64
[11A8:0CEC][2017-04-17T11:26:15]i052: Condition 'VersionNT = v6.2 AND NOT VersionNT64' evaluates to false.
[11A8:0CEC][2017-04-17T11:26:15]w321: Skipping dependency registration on package with no dependency providers: Windows8_x86
[11A8:0CEC][2017-04-17T11:26:15]i052: Condition 'VersionNT = v6.2 AND VersionNT64' evaluates to false.
[11A8:0CEC][2017-04-17T11:26:15]w321: Skipping dependency registration on package with no dependency providers: Windows8_x64
[11A8:0CEC][2017-04-17T11:26:15]i052: Condition 'VersionNT = v6.1 AND NOT VersionNT64' evaluates to false.
[11A8:0CEC][2017-04-17T11:26:15]w321: Skipping dependency registration on package with no dependency providers: Windows7_MSU_x86
[11A8:0CEC][2017-04-17T11:26:15]i052: Condition 'VersionNT = v6.1 AND VersionNT64' evaluates to true.
[11A8:0CEC][2017-04-17T11:26:15]w321: Skipping dependency registration on package with no dependency providers: Windows7_MSU_x64
[11A8:0CEC][2017-04-17T11:26:15]i052: Condition 'VersionNT = v6.0 AND NOT VersionNT64' evaluates to false.
[11A8:0CEC][2017-04-17T11:26:15]w321: Skipping dependency registration on package with no dependency providers: WindowsVista_MSU_x86
[11A8:0CEC][2017-04-17T11:26:15]i052: Condition 'VersionNT = v6.0 AND VersionNT64' evaluates to false.
[11A8:0CEC][2017-04-17T11:26:15]w321: Skipping dependency registration on package with no dependency providers: WindowsVista_MSU_x64
[11A8:0CEC][2017-04-17T11:26:15]i201: Planned package: vcRuntimeMinimum_x64, state: Present, default requested: Present, ba requested: Present, execute: None, rollback: None, cache: No, uncache: No, dependency: Register
[11A8:0CEC][2017-04-17T11:26:15]i201: Planned package: vcRuntimeAdditional_x64, state: Present, default requested: Present, ba requested: Present, execute: None, rollback: None, cache: No, uncache: No, dependency: Register
[11A8:0CEC][2017-04-17T11:26:15]i201: Planned package: Windows81_x86, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[11A8:0CEC][2017-04-17T11:26:15]i201: Planned package: Windows81_x64, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[11A8:0CEC][2017-04-17T11:26:15]i201: Planned package: Windows8_x86, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[11A8:0CEC][2017-04-17T11:26:15]i201: Planned package: Windows8_x64, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[11A8:0CEC][2017-04-17T11:26:15]i201: Planned package: Windows7_MSU_x86, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[11A8:0CEC][2017-04-17T11:26:15]i201: Planned package: Windows7_MSU_x64, state: Absent, default requested: Present, ba requested: Present, execute: Install, rollback: Uninstall, cache: No, uncache: No, dependency: None
[11A8:0CEC][2017-04-17T11:26:15]i201: Planned package: WindowsVista_MSU_x86, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[11A8:0CEC][2017-04-17T11:26:15]i201: Planned package: WindowsVista_MSU_x64, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[11A8:0CEC][2017-04-17T11:26:15]i299: Plan complete, result: 0x0
[11A8:0CEC][2017-04-17T11:26:15]i300: Apply begin
[0C1C:02C0][2017-04-17T11:26:16]i360: Creating a system restore point.
[0C1C:02C0][2017-04-17T11:26:51]i361: Created a system restore point.
[0C1C:02C0][2017-04-17T11:26:51]i370: Session begin, registration key: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{e46eca4f-393b-40df-9f49-076faf788d83}, options: 0x4, disable resume: No
[0C1C:02C0][2017-04-17T11:26:51]i320: Registering bundle dependency provider: {e46eca4f-393b-40df-9f49-076faf788d83}, version: 14.0.23026.0
[0C1C:02C0][2017-04-17T11:26:51]i371: Updating session, registration key: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{e46eca4f-393b-40df-9f49-076faf788d83}, resume: Active, restart initiated: No, disable resume: No
[0C1C:0B50][2017-04-17T11:26:52]i304: Verified existing payload: Windows7_MSU_x64 at path: C:\ProgramData\Package Cache\42D5BEC7DDFBD49E76467529CBC2868987BF8460\packages\Patch\x64\Windows6.1-KB2999226-x64.msu.
[0C1C:02C0][2017-04-17T11:26:52]i325: Registering dependency: {e46eca4f-393b-40df-9f49-076faf788d83} on package provider: Microsoft.VS.VC_RuntimeMinimumVSU_amd64,v14, package: vcRuntimeMinimum_x64
[0C1C:02C0][2017-04-17T11:26:52]i325: Registering dependency: {e46eca4f-393b-40df-9f49-076faf788d83} on package provider: Microsoft.VS.VC_RuntimeAdditionalVSU_amd64,v14, package: vcRuntimeAdditional_x64
[0C1C:02C0][2017-04-17T11:26:52]i301: Applying execute package: Windows7_MSU_x64, action: Install, path: C:\ProgramData\Package Cache\42D5BEC7DDFBD49E76467529CBC2868987BF8460\packages\Patch\x64\Windows6.1-KB2999226-x64.msu, arguments: '"C:\Windows\SysNative\wusa.exe" "C:\ProgramData\Package Cache\42D5BEC7DDFBD49E76467529CBC2868987BF8460\packages\Patch\x64\Windows6.1-KB2999226-x64.msu" /quiet /norestart'
[0C1C:02C0][2017-04-17T11:26:53]e000: Error 0x80070652: Failed to execute MSU package.
[11A8:0CEC][2017-04-17T11:26:53]e000: Error 0x80070652: Failed to configure per-machine MSU package.
[11A8:0CEC][2017-04-17T11:26:53]w348: Application requested retry of package: Windows7_MSU_x64, encountered error: 0x80070652. Retrying...
[0C1C:02C0][2017-04-17T11:26:56]i301: Applying execute package: Windows7_MSU_x64, action: Install, path: C:\ProgramData\Package Cache\42D5BEC7DDFBD49E76467529CBC2868987BF8460\packages\Patch\x64\Windows6.1-KB2999226-x64.msu, arguments: '"C:\Windows\SysNative\wusa.exe" "C:\ProgramData\Package Cache\42D5BEC7DDFBD49E76467529CBC2868987BF8460\packages\Patch\x64\Windows6.1-KB2999226-x64.msu" /quiet /norestart'
[0C1C:02C0][2017-04-17T11:26:56]e000: Error 0x80070652: Failed to execute MSU package.
[11A8:0CEC][2017-04-17T11:26:56]e000: Error 0x80070652: Failed to configure per-machine MSU package.
[11A8:0CEC][2017-04-17T11:26:56]w348: Application requested retry of package: Windows7_MSU_x64, encountered error: 0x80070652. Retrying...
[0C1C:02C0][2017-04-17T11:26:59]i301: Applying execute package: Windows7_MSU_x64, action: Install, path: C:\ProgramData\Package Cache\42D5BEC7DDFBD49E76467529CBC2868987BF8460\packages\Patch\x64\Windows6.1-KB2999226-x64.msu, arguments: '"C:\Windows\SysNative\wusa.exe" "C:\ProgramData\Package Cache\42D5BEC7DDFBD49E76467529CBC2868987BF8460\packages\Patch\x64\Windows6.1-KB2999226-x64.msu" /quiet /norestart'
[0C1C:02C0][2017-04-17T11:26:59]e000: Error 0x80070425: Failed to stop wusa service.
[0C1C:02C0][2017-04-17T11:26:59]e000: Error 0x80070652: Failed to execute MSU package.
[11A8:0CEC][2017-04-17T11:26:59]e000: Error 0x80070652: Failed to configure per-machine MSU package.
[11A8:0CEC][2017-04-17T11:26:59]w348: Application requested retry of package: Windows7_MSU_x64, encountered error: 0x80070652. Retrying...
[0C1C:02C0][2017-04-17T11:27:02]i301: Applying execute package: Windows7_MSU_x64, action: Install, path: C:\ProgramData\Package Cache\42D5BEC7DDFBD49E76467529CBC2868987BF8460\packages\Patch\x64\Windows6.1-KB2999226-x64.msu, arguments: '"C:\Windows\SysNative\wusa.exe" "C:\ProgramData\Package Cache\42D5BEC7DDFBD49E76467529CBC2868987BF8460\packages\Patch\x64\Windows6.1-KB2999226-x64.msu" /quiet /norestart'
[0C1C:02C0][2017-04-17T11:27:02]e000: Error 0x80070425: Failed to stop wusa service.
[0C1C:02C0][2017-04-17T11:27:02]e000: Error 0x80070652: Failed to execute MSU package.
[11A8:0CEC][2017-04-17T11:27:02]e000: Error 0x80070652: Failed to configure per-machine MSU package.
[11A8:0CEC][2017-04-17T11:27:02]i319: Applied execute package: Windows7_MSU_x64, result: 0x80070652, restart: None
[11A8:0CEC][2017-04-17T11:27:02]e000: Error 0x80070652: Failed to execute MSU package.
[0C1C:02C0][2017-04-17T11:27:02]i372: Session end, registration key: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{e46eca4f-393b-40df-9f49-076faf788d83}, resume: ARP, restart: None, disable resume: No
[0C1C:02C0][2017-04-17T11:27:02]i371: Updating session, registration key: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{e46eca4f-393b-40df-9f49-076faf788d83}, resume: ARP, restart initiated: No, disable resume: No
[11A8:0CEC][2017-04-17T11:27:02]i399: Apply complete, result: 0x80070652, restart: None, ba requested restart:  No
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 17 Kwietnia 2017, 11:33:30
Niektore biblioteki sa juz zaszyte w exe. Najwazniejsze jest  zainstalowanie vcredist. Te mozesz pobrac z watku changelog przyklejonym w dziale na warsztacie. Znajdziesz tam w moim poscie instalki bibliotek. Polecam zainstalowanie wszystkich trzech, to jest 2008, 2013 i 2015. Dodatkowo z postu @tmj pobierz katalog pythona, tak jak radzil @EP08-015 umiesc go w katalogu glownym maszyny.
Poszukaj tego dll w google i wrzuć do głównego folderu.
To nie jest dobra droga uzupelniania brakujacych bibliotek, system zawola nastepne i nastepna...
Ed: na takie dictum jak wkleiles nie wiem co powiedziec. Jaki system konkretnie masz, na pewno 64bity?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 17 Kwietnia 2017, 11:52:03
Windows7 Home Edition 64-bit. :(
Dziadostwo. Nie polecam.
Dzięki Krzysztof! Spróbuję dokonać instalki, za Twoją poradą.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Balaclava w 17 Kwietnia 2017, 14:03:43
To nie jest dobra droga uzupelniania brakujacych bibliotek, system zawola nastepne i nastepna...
I następnie w ten sam sposób można zainstalować kolejne, aż do rozwiązania problemu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 17 Kwietnia 2017, 15:09:18
Powodzenia, sciaganie visual studio razem z jego instalacja trwa krocej. Pamietaj, nie kazdy daje rade sprawnie poruszac sie wsrod mnostwa linkow na stronach zawierajacych potrzebne biblioteki. Nie polecam i tyle!
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 17 Kwietnia 2017, 15:15:51
Caly zestaw glew wybitnie nie jest potrzebny bo a) biblioteka jest od jakiegos czasu wszyta do exe i b) nawet gdyby nie byla, to potrzebny bylby tylko plik .dll  Reszta jest dla developerow.

Jezeli to system 64-bit to, jesli ktos chce sie bawic w wersje 64-bitowa, najprawdopodobniej potrzebne beda redist i instalacja 64-bitowej wersji python ze strony oficjalnej: https://www.python.org/ftp/python/2.7.13/python-2.7.13.amd64.msi
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 17 Kwietnia 2017, 17:08:58
Wielkie dzięki @tmj!
Ten ostatni link rozwiązał wszelkie problemy.
Jeżeli chodzi o testy ostatniego exe na x64, to jestem pod wrażeniem odgłosów zaworu H14K1. :)
Trochę mi się nie podoba przypisywanie funkcji wyłączników typu Z pod jeden klawisz, bo w przypadku Arduinowców, stanowi to problem. Moim sprzęcikiem, daleko nie zajadę.. :(
Co do klawiszowych, to będzie kwestia przyzwyczajenia. A jak się ten sposób sprawdza na Pokeys?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 17 Kwietnia 2017, 17:28:23
Trochę mi się nie podoba przypisywanie funkcji wyłączników typu Z pod jeden klawisz, bo w przypadku Arduinowców, stanowi to problem. Moim sprzęcikiem, daleko nie zajadę.. :(
Co do klawiszowych, to będzie kwestia przyzwyczajenia. A jak się ten sposób sprawdza na Pokeys?
Nie moge sie ustosunkowac, bo nie mam zielonego pojecia co lub kto to sa Arduinowcy :)  Co do Pokeys, na razie nie jest podlaczone pod nowy system, wiec powinno dzialac tak jak zawsze (minus uaktualnianie stanu przelacznikow, to jest do ogarniecia)  Przepiecie na nowy system nie powinno sprawic zbyt duzo klopotu, bylo to poruszone pare stron temu, i tam jest troche wiecej szczegolow: http://eu07.pl/forum/index.php/topic,28159.msg448581.html#msg448581
(na upartego mozna tez dodac stary schemat kontroli do nowego jesli rzeczywiscie okaze sie to konieczne, ale na razie sie powstrzymuje bo to jest duzo mechanicznego pisania i chcialbym najpierw zakonczyc organizacje jakiejs podstawowej funkcjonalnosci)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 17 Kwietnia 2017, 17:40:40
Arduinowcem jestem między innymi ja, ale spokojnie. Będę testował na klawiszach. Kran hamulca zasadniczego, mam podpięty pod potencjometr i niestety przy tych ustawieniach, nie jest w stanie odnieść się do pozycji, ale nic to. Tak jak napisałeś, testujemy tak jak jest.
Wydaje mi się, czy FPS skoczył ,,w górę" i to nieźle?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 17 Kwietnia 2017, 17:46:52
Jesli masz na mysli w porownaniu do wersji borlandowej to tak, jest teraz troche wydajniej ;d
W przypadku sterowania przez urzadzenia zewnetrzne, powinno to byc ulatwione w nowym systemie -- wystarczy dopisac modul tlumaczacy otrzymane sygnaly na 'uniwersalne' komunikaty dla glownej czesci symulatora, a reszte zalatwia juz exe. Tak jest zrealizowany niejako "dla przykladu" modul obslugi gamepada, jak juz wszystko bedzie dostatecznie ogarniete by pchnac uaktualnienie na githuba bedzie do wgladu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: RooteK w 17 Kwietnia 2017, 19:09:43
EU40, jeśli chodzi o Arduino to zamiast symulować klawiaturę lepiej wysyłać stan przełączników i nastawników po USB: http://eu07.pl/forum/index.php/topic,28460

Współpracowałem w tej kwestii z Maćkiem, jego kod można dokleić do aktualnego exe. Niestety ostatnio nie miałem czasu by dokończyć układy elektroniczne i dalej bawić się w kwestie programowe, ale prototypowo działało :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 17 Kwietnia 2017, 20:00:46
Nie da rady. Nie to, że nie brak chęci z naszych stron, tylko Maciek pracuje trochę na innym układzie (przynajmniej tak mi się wydaje). Ja mam malutką skrzyneczkę i to jeszcze zbudowaną na projekcie @Arq na Arduino Pro Micro.
Spokojnie. Na razie testujmy to co jest. Zawsze można posterować sobie poprzez myszkę na X-mouse button controls. ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 17 Kwietnia 2017, 20:02:10
Bałtyk en57 z testów. Asynchroniczny ezet unoffowy. Postój na peronie, zmieniłem okienko na czat, więc enterem niechcący zamknąłem okienko z błędem, a wydawało się inne niż zazwyczaj.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 17 Kwietnia 2017, 20:14:40
Ten .dmp jakis dziwny wyszedl, obcielo go albo cos i nie moge wczytac :/

edit: przy okazji, w ramach glupich pytan.
Tym razem nt. wylacznika stycznikow liniowych: jesli maszynista wcisnie przycisk tego wylacznika przy nastawniku w pozycji 0 i przytrzymujac go da nastawnik na pozycje 1, czy styczniki liniowe zalacza sie, czy pozostana rozlaczone?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 17 Kwietnia 2017, 21:49:20
Tym razem nt. wylacznika stycznikow liniowych: jesli maszynista wcisnie przycisk tego wylacznika przy nastawniku w pozycji 0 i przytrzymujac go da nastawnik na pozycje 1, czy styczniki liniowe zalacza sie, czy pozostana rozlaczone?
W rzeczywistości pozostaną rozłączone.
- przywrocone dzialanie dzwiekow hamulca dla kranow innych niz FV4a/FVel6
U mnie nie działa dźwięk kranu hamulca dodatkowego FD1. Przy okazji, jeśli już zajmujesz się zmianami w działaniu lokomotyw, to są też inne błędy w sterowaniu większości lokomotyw:
- zmiana położenia przełącznika rodzaju hamulca nie powinna emitować dźwięku syczenia - w rzeczywistości słychać jedynie bardzo ciche "pyknięcie" przesterowanego elektrozaworu, ale to nawet przy wyłączonych przetwornicach trzeba się wsłuchiwać, żeby to usłyszeć;
- brak możliwości użycia hamulca ręcznego - kombinacja [Ctrl] + [Num 1] i [Ctrl] + [Num 7] nie wpływa na komunikat "local brake" pod F3 ani nie powoduje hamowania;
- ogólnie nieprawidłowe działanie przekaźnika nadmiarowego przetwornic - podczas załączenia najpierw sprężarek i po nich przetwornic lub przy zbyt szybkim załączeniu sprężarek po przetwornicach powinny zadziałać nadmiarowe sprężarek, a nie przetwornic (przedstawione to jest na tym filmie (https://www.youtube.com/watch?v=u1nWGdV69FM)) - dotyczy tylko lokomotyw, w których sprężarki zasilane są z niskiego napięcia;
- brak konieczności odbloku przekaźnika różnicowego obwodu głównego po załączeniu baterii - w rzeczywistości po załączeniu baterii świeci się kontrolka od przekaźnika różnicowego, który uniemożliwia załączenie wyłącznika szybkiego i trzeba ten przekaźnik odblokować tym samym przyciskiem, co nadmiarowe silników;
- brak odwzorowania hamulca bezpieczeństwa (tzw. klapki Ackermana) - można podpiąć np. pod klawisz "E" jak "emergency brake" (tak było w którejś z pierwszych wersji MaSzyny) - powinien on powodować spuszczenie powietrza z przewodu głównego z prędkością nieco większą (jakieś 1,2 do 1,3 razy większą) niż przestawienie kranu hamulca w hamowanie nagłe;
- brak odwzorowania dźwięku automatycznego hamowania nagłego przez CA, SHP i radio-stop (wszystkie trzy powodują otwarcie tego samego zaworu na ramie pneumatycznej w przedziale maszynowym i w kabinie wyraźnie to słychać, co zostało przedstawione m.in. na tym filmie (https://youtu.be/CFqUm1oSLYI?t=1m27s)), prawdopodobnie podobny dźwięk, ale trochę głośniejszy jest przy użyciu wyżej wspomnianego hamulca bezpieczeństwa;
- brak odwzorowania wyłącznika ciśnieniowego czuwaka, który powinien wyłączać styczniki liniowe, gdy ciśnienie w przewodzie głównym spadnie poniżej 2,8bar;
- pantografy powinny zacząć opadać (a tym samym napięcie na woltomierzu WN spaść do 0V) dopiero po ok. 2-3s od przesterowania ich elektrozaworów (wyłączenia hebelków czy też spadku napięcia zasilającego po stronie NN).
Są to ważniejsze z błędów występujących w większości lokomotyw.

Zauważyłem też, że poprawiłeś nieco działanie woltomierza NN. Jeśli przy załączaniu przetwornic dodałbyś zwłokę czasową ok. 2s przed wzniesieniem się wskazówki na 110V i ok. 7-14s (w zależności od lokomotywy) przed opadnięciem wskazówki po wyłączeniu przetwornic, to działałby jeszcze zgodniej z rzeczywistością. Dodatkowo przy wyłączaniu przetwornic przy wyłączonej wcześniej baterii napięcie powinno po wspomnianych ok. 7-14s zacząć opadać powoli do zera, a nie od razu jak teraz. Wtedy wyłączanie się WSa i opadanie pantografów można by uzależnić od wskazań woltomierza, a nie od załączenia/wyłączenia baterii. WS wyłącza się przy ok. 50V, a pantografy opadają przy ok. 30V. Jeszcze raz przypominam film, na którym to wszystko ładnie widać: KLIK (https://www.youtube.com/watch?v=ig_S45WW110). Dodatkowo jeszcze taki film (https://www.youtube.com/watch?v=r79yWYeSyjE) z załączania i wyłączania przetwornic. Jak chcesz, to mogę Ci jeszcze podesłać link do filmu z ET41, gdzie po wyłączeniu przetwornic napięcie utrzymuje się tylko przez 7s.

Edit: Dodałem jeszcze jeden błąd.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 17 Kwietnia 2017, 22:32:27
U mnie nie działa dźwięk kranu hamulca dodatkowego FD1.
Hamulec lokomotywy na ta chwile nie wydaje dzwiekow wlasnie w lokomotywach z 'nowym' systemem hamulcow (czyli w praktyce te z FV4a/FVel6) ale tam jeszcze nie zagladalem :)

Cytuj
Zauważyłem też, że poprawiłeś nieco działanie woltomierza NN. Jeśli przy załączaniu przetwornic dodałbyś zwłokę czasową ok. 2s przed wzniesieniem się wskazówki na 110V i ok. 7-14s (w zależności od lokomotywy) przed opadnięciem wskazówki po wyłączeniu przetwornic, to działałby jeszcze zgodniej z rzeczywistością. Dodatkowo przy wyłączaniu przetwornic przy wyłączonej wcześniej baterii napięcie powinno po wspomnianych ok. 7-14s zacząć opadać powoli do zera, a nie od razu jak teraz.
Tutaj niestety niewiele da sie zrobic bez dokumentnego rozgrzebania tego, jak "skonstruowane" sa w symulacji pojazdy -- np. przetwornica jest symulowana tylko na poziomie "urzadzenie jest zalaczone/wylaczone" i tyle, nie ma tam 'faktycznego' silnika ani kalkulowanego wytwarzanego napiecia itp  To jest cos co chcialbym zrobic, bo tak jak zauwazyles stan obecny odbiega of rzeczywistosci, ale jest to kwestia odlegla, jesli w ogole (to sa zmiany na poziomie wprowadzenia nowego systemu hamulcow, czyli dosc zeby sie PTSD nabawic)

Ta lista istniejacych bledow jest bardzo przydatna, dzieki. Nie wiem na ile i jak szybko uda sie ja zastosowac i wprowadzic poprawki, ale bede ja mial w pamieci.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 17 Kwietnia 2017, 22:40:21
Przejechałem się Bałtykiem, zamieniając luzaka na SU45-225.
Na początku śmigała jak należy. Ładny, czysty obraz..
Rozumiem, że urządzenia czujności na chwilę obecną są wyłączone, bo nie działają w ogóle.
Problem pojawił się podczas napełnienia składu w Alakowicach. Na dzień dobry FPS spadł mi do 0,21!!!
Później jakoś rozbujałem do 60-ciu, i dopiero za przejazdem w Alakowicach FPS bujnął do 15-tu.
W Bałtyku spokojnie. Problem pojawił się na po Bałtyk Katedra. Tu ponownie nagły spadek FPS, jak w Alakowicach.
Obsługa hamulca mnie wnerwia i chyba się jednak nie przyzwyczaję..
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 17 Kwietnia 2017, 23:07:30
Rozumiem, że urządzenia czujności na chwilę obecną są wyłączone, bo nie działają w ogóle.
Urzadzenia czujnosci czyli czuwak/shp? Nie, powinny dzialac normalnie. Sprawdzilem przed chwila SU45 na Baltyku i nic jej nie brakowalo.
Co do spadku fps ciezko cos powiedziec przy zero informacji nt sprzetu itp.
edit:
zmiany w obsludze zblizaja sie do konca, wiec bedzie tez dodana mozliwosc przemapowania klawiszy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 18 Kwietnia 2017, 00:40:42
Pospieszny Wiliś - Janiszew, bez problemów. Urządzenia czujności działały prawidłowo na SU46-022.
Co do SU45-225, to na misji w Bałtyku lampki urządzeń czujności świeciły się tylko w trakcie załączenia baterii oraz w przypadku ich kontroli (przy czym dłuższe przytrzymanie nie powodowało spadku ciśnienia w PGH).
Miałem wówczas podpięte zapasowo Arduino i możliwe, że się coś pokiełbasiło.
Co do sprzętu jaki mam, to Intel(R) Core(TM)2 Duo CPU T9600 2,80GHz i 2GB RAMU, więc ,,jaj nie urywa".
-----------------------------------------------------------------------------------------------------------------------------
83202 na lini 53-ciej przejezdne bez problemu, co jest dla mnie szokiem, gdyż do tej pory przejazd ze względu na spadki FPS-u na moim kompie, stanowił nie mały wyczyn graniczący z cierpliwością. Teraz jestem święcie przekonany, że C ++ jest jedynym słusznym kierunkiem w którym podążamy.
Jazdę odbyłem na SU45-225 z 16-toma pulmanami, doznając jedynie 15 minut opóźnienia. ;)
Działanie urządzeń czujności - prawidłowe, tak więc na bank coś nie tak było u mnie.
Jedyna uwaga, jaką mam to rozkład jazdy, który od Sandomierza się nie aktualizował, pomimo dojazdów pod wskaźnik i akustycznych ,,odjazdów" kierpocia.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 18 Kwietnia 2017, 11:27:53
Żadna wersja l053 nie ma przypisanych W4. Odjazdy są indywidualnymi eventami staroświecko.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: jakol112 w 18 Kwietnia 2017, 12:01:32
@tmj a planujesz dodać sygnalizację oporów i SHP/CA na klawiaturę? Szczerze to mój pulpit się na tym opiera więc mi osobiście na tym zależy...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 18 Kwietnia 2017, 12:13:45
Zauważyłem też, że poprawiłeś nieco działanie woltomierza NN. Jeśli przy załączaniu przetwornic dodałbyś zwłokę czasową ok. 2s przed wzniesieniem się wskazówki na 110V i ok. 7-14s (w zależności od lokomotywy) przed opadnięciem wskazówki po wyłączeniu przetwornic, to działałby jeszcze zgodniej z rzeczywistością. Dodatkowo przy wyłączaniu przetwornic przy wyłączonej wcześniej baterii napięcie powinno po wspomnianych ok. 7-14s zacząć opadać powoli do zera, a nie od razu jak teraz.

Tylko kwestia jest taka, że obecnie coraz więcej jest różnych przeróbek i modyfikacji różnych pojazdów. I trzymanie każdej wersji sztywno w exe mija się z celem. To musi być w jakiś sposób wyprowadzone na zewnątrz. W takich EN57 też masz jedne stare przetwornice, ale też co raz więcej nowych, statycznych gdzie nie masz powyższego efektu. Inaczej też się załączają.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: matek123 w 18 Kwietnia 2017, 12:55:50
Już kiedyś Q testowo zrobił, że dla każdej tekstury osobne mmd i fiz można było zrobić.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 18 Kwietnia 2017, 13:08:50
Nie bardzo rozumiem. Jesli dla pojazdu jest zrobiony osobne .mmd i fiz z innymi parametrami, to chyba zwyczajnie mozna ten .mmd i .fiz podac w .scn, zamiast mieszac z exe?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 18 Kwietnia 2017, 13:53:20
Czy może ktoś sprawdzić czy wchodzą boczniki na najnowszym exe w pojazdach, gdzie bocznik jest w kole nastawnika? EP05 ET40
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 18 Kwietnia 2017, 14:12:03
@tmj a planujesz dodać sygnalizację oporów i SHP/CA na klawiaturę? Szczerze to mój pulpit się na tym opiera więc mi osobiście na tym zależy...
To tak jak i mój..
Parę postów wyżej Kolega @tmj wspomniał, że planuje nadpisywanie klawiszy, więc jest nadzieja i na lampki.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 18 Kwietnia 2017, 16:20:20
@tmj a planujesz dodać sygnalizację oporów i SHP/CA na klawiaturę? Szczerze to mój pulpit się na tym opiera więc mi osobiście na tym zależy...
To bylo wylaczone bo a) tam byl kawalek Borlandowy dla ktorego nie bylo bezposredniego odpowiednika i b) dziala to tylko pod Windows.  Jesli jest potrzebne moge sprobowac wlaczyc to z powrotem, chociaz za efekty nie recze.

edit: aha, a propos niedzialajacego czuwaka itp kilka postow wyzej -- warto pamietac ze te urzadzenia nie aktywuja sie przy wlaczonym trybie debug ;d (nie moj pomysl, tak juz bylo)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 18 Kwietnia 2017, 16:48:30
Właśnie ukończyłem jazdę na TLK Zwierzyniec. Misja przejezdna, ale znowu miałem problem z urządzeniami czujności. Ulotniło się w trakcie manewrów. Majsterkowałem Ctrl + T, E, R bo nie mogłem wyłączyć radiostopu. Może coś tym zabiegiem pochrzaniłem? Urządzenia czujności z powrotem działały poprawnie, po ponownym załączeniu baterii. Gdyby kto pytał, nie włączałem trybu debug..zresztą chyba nawet nie potrafię.
Później w trakcie jazdy, nie mogłem opuścić pantografów, zresztą wyłączniki Z działały w EP08 impulsowo. Było coś o tym parę ładnych postów temu.
Na manewrach miałem również problemy z hamulcem zasadniczym. Lokomotywa zaczęła dopiero hamować, po podłączeniu do składu.
Ten romantyczny odblask świateł jest bardzo realistyczny.
Cytuj
b) dziala to tylko pod Windows.  Jesli jest potrzebne moge sprobowac wlaczyc to z powrotem, chociaz za efekty nie recze.
khe...a większość z nas chyba na Windowsie jeździ.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 18 Kwietnia 2017, 17:08:25
'Szybki' przelacznik debug jest pod Shift+Ctrl+F12, wiec jest szansa ze sie przypadkowo uaktywni przy naciskaniu roznych rzeczy, chociaz mala :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 18 Kwietnia 2017, 18:09:00
No jakieś czary widocznie się dzieją, ale chyba domyślam się przyczyny. X- mouse button controls. Przy starcie nieraz chodzki-klocki się działy, jak użyłem 2 przycisków jednocześnie i shift inny klawisz zahaczył.
Drawinowo na EP09 - perfekcyjnie, bez najmniejszej uwagi. Rozkład również bez zastrzeżeń.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 18 Kwietnia 2017, 18:34:04
OK, myslalem ze da sie dzis zawinac zmiane obslugi do konca, ale wyszlo dwadziescia innych zapotrzebowan, wiec bedzie to musialo poczekac :P

w dzisiejszym uaktualnieniu:

- podpiete pod nowa kontrole: wylacznik stycznikow liniowych, przelaczniki oswietlenia przyrzadow, oswietlenia kabiny, przyciemnienia oswietlenia kabiny. Oswietlenie przyrzadow jest pod ; oswietlenie kabiny pod ' a przyciemnienie pod ctrl + ' (czyli prawie tak jak bylo, tylko zapalenie i przyciemnienie kabiny jest teraz w jednym miejscu)
tutaj uwaga: obsluga jest uzalezniona od obecnosci przyciskow/modeli w kabinie, bo na ten moment nie ma za bardzo innej mozliwosci sprawdzenia, czy pojazd posiada taka funkcje. Powiedzmy ze to taka... zacheta zeby wyposazyc modele w co trzeba.

- poprawki: usuniete syczenie przy przelaczaniu nastawy hamulca w pojezdzie, zalaczanie bocznikow w pojazdach gdzie stan bocznikow zalezy od polozenia nastawnika glownego

- eksperymentalnie: podlaczone ponownie dzialanie swiatel klawiatury dla sygnalizacji czuwaka/shp i jazdy na oporach

- eksperymentalnie: dla milosnikow krecenia wirtualnych filmow przez lunete, zwiekszona dokladnosc renderowania odleglych obiektow przy wlaczonym zoomie
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: szogun w 18 Kwietnia 2017, 19:48:19
- eksperymentalnie: dla milosnikow krecenia wirtualnych filmow przez lunete, zwiekszona dokladnosc renderowania odleglych obiektow przy wlaczonym zoomie
Sprawdziłem nie działa, fazy lod zmieniają się niezależnie od zooma :c
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 18 Kwietnia 2017, 19:49:42
Testy na EP05-23:
-boki chodzą tak jak trzeba;
-lampki SHP, czuwaka i oporów rozruchowych zapalają się i gasną, zgodnie z zasadą działania;
-podświetlenie przyrządów pomiarowych (;) działa;
-załączenie i wyłączenie oświetlenia kabiny (') działa;
-przełącznik hamulca bez syczenia - działa;
-przyciemnienie oświetlenia kabiny (ctrl + ') nie działa; :(
Na EU07:
-lampki SHP, czuwaka i oporów rozruchowych zapalają się i gasną, zgodnie z zasadą działania;
-podświetlenie przyrządów pomiarowych (;) działa;
-załączenie i wyłączenie oświetlenia kabiny (') działa;
-przełącznik hamulca bez syczenia - działa;
-przycisk wyłączenia styczników liniowych - działa;
-przyciemnienie oświetlenia kabiny (ctrl + ') działa; :)
Mogę mieć prośbę i poprosić o exe z pozycjami hamulca w starym układzie? Ta zamiana Num 6 z Num 4 i jeden ze stopni hamowania, eliminuje mi potencjometr przy testach? O ile oczywiście nie jest to problem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 18 Kwietnia 2017, 20:03:07
Testy na EP05-23:
-przyciemnienie oświetlenia kabiny (ctrl + ') nie działa; :(
No niestety, trzeba guzik dorobic (cablightdim_sw)

zoom jest pod srodkowym przyciskiem/kolkiem myszy. Jak sie wcisnie to sie powinien wlaczyc.

Sprawdziłem nie działa, fazy lod zmieniają się niezależnie od zooma :c
Zebysmy sie tutaj dobrze zrozumieli -- zoom po zmianach nie renderuje zawsze maksymalnej ilosci detali, fazy lod sa dalej uwzgledniane. Roznica polega na tym, ze jesli przedtem np. obserwator stal w odleglosci 500m i wlaczony byl 3x zoom, obiekt rysowany byl tak, jakby stal ~290m od obserwatora, a po zmianach tak, jakby stal w odleglosci ~170m  Jesli w modelu najwyzszy poziom detali jest skonfigurowany tak, by uaktywnial sie ponizej 50m to i tak sie nie zalapie, bo i nie ma specjalnie sensu zeby sie pojawial.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: matek123 w 18 Kwietnia 2017, 20:12:20
Dobrze rozumiem, że teraz mamy o jeden universal mniej do dyspozycji?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 18 Kwietnia 2017, 20:13:52
Nie, dlaczego?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: matek123 w 18 Kwietnia 2017, 21:46:08
Pozostaną 4  uniwersale, czy po nowemu ~8 jak dobrze liczę?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 18 Kwietnia 2017, 21:55:07
Na razie sa bez zmian 4 tak jak byly. Z tym ze trzeba by chyba pomyslec o jakims ujednoliceniu, bo tak jak jest to niemal kazdy "universal" jest obslugiwany/animowany w inny sposob i na sztywno.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 18 Kwietnia 2017, 22:50:26
Z tym uzależnieniem funkcji od istnienia przycisku to akurat bardzo dobre, bo np w EN57 przełącznika przyciemniania kabiny nie ma, a funkcja dotąd działała. Super. :)

EDIT.: Jeszcze zauważyłem taki mały błąd w EN57. Dodałeś to, że przycisk od wyłącznika szybkiego jest impulsowy i da nim się tylko załączyć wyłącznik szybki, ale nie wyłączyć, natomiast wyłącza on nadal w symulatorze przetwornicę.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 19 Kwietnia 2017, 18:45:20
Crashdump z nowego exe - odpaliłem, podziałało dłuższy czas w tle (ja nawet loka nie odpaliłem) i się wysypało. Misja zdawczyA_wil z Całkowa_v2 (ta z dwoma ST43 na przedzie). Nawiasem mówiąc czas podany w nazwie pliku jest oszukany o 2h do tyłu (160511 zamiast 180511).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 19 Kwietnia 2017, 21:53:42
Wywalilo kaliska z nieznanego powodu za Borszewicami. Do peronow się nawet nie dokulalem.

Najnowsze exe + trax.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 19 Kwietnia 2017, 22:13:54
To jeden z tych losowych wysypow w czasie skanowania torow itp. Nie bardzo wiem na ile kompletne sa zmiany, ktore @firleju ma w swojej galezi, ale jesli uda sie je podlaczyc, to moze pomoga :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 20 Kwietnia 2017, 07:44:29
Narazie niekompletne. Po dłuższej przerwie związanej z rowerem w serwisie dzisiaj znowu miałem chwilkę w pociągu. Mam problem z mergem najnowszych wersji z repo na moją gałąź i chyba będę musiał aż zresetować repo bo błędnych zabawach z git-em.
Jak się wciąga ten cruchdump to może zerknę gdzie się wywala i poprawię na szybko.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 20 Kwietnia 2017, 12:46:04
Wystarczy dwa razy kliknac, jak jest w systemie zainstalowany VS to otworzy i uruchomi debugger. Ale trzeba miec zrodla i pliki .pdb z tej konkretnej kompilacji, bo inaczej za wiele nie pokaze.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 20 Kwietnia 2017, 14:13:43
Znając życie wersja VS ma znaczenie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 20 Kwietnia 2017, 16:36:30
To jeszcze zapytam o to na ile skomplikowane by bylo zrobienie autosave badz save pid FX? Czy to wogule wykonalne jest na obecnym etapie? W razu nieoczekuwanego wysypu mozna by wczytac taki autosave i jechac dalej. Przydatne by bylo przy dlugich scenariuszach. Rozumie oczywiscie ze exe musialo by w jakims pliku zapusywac np co 10 minut stan pojazdow i urzadzen i czas symulacji.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 20 Kwietnia 2017, 18:00:32
Testowaliście może Bombardiery? U mnie ekrany są  białe i nie da się ich uruchomić. Wersja x64 bit.
Wybaczcie. Vista, na wersji x86.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 20 Kwietnia 2017, 18:03:02
Białe,czyli brak tekstury ale coś wysyła? A nie czarne tło wygaszonego, jak przy błędzie w skrypcie? W logu są jakieś błędy pythona?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 20 Kwietnia 2017, 18:07:50
Przepraszam. To było na x86 na Windows Vista. Nic mi nie wyskakiwało, ekrany były białe. Loga nie pobrałem, bo uruchomiłem kompa na chwilę. Mimo tego błędu, lok sterowałem bez problemu. No, tylko bez podglądu na monitory.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mk1991 w 20 Kwietnia 2017, 20:01:43
Witam. Mam jedno pytanie. Czy na exe c++ jest możliwe wstawianie kilku wersji runningnoise ponumerowanych i uzależnionych od zakresu prędkości z jakimi porusza się pojazd?
Z tego co słyszałem na borlandowym coś takiego jest.
Jeśli coś takiego jest to chciałbym umieścić taką możliwość w wagonie 111A_v2 i wagonie Bdhpumn.
Dysponuję odpowiednimi plikami runningnoise.
Tam w jednym z wpisów cyfrowych dla runningnoise wpisywało się prędkości graniczne.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 21 Kwietnia 2017, 04:10:45
W duzym uproszczeniu w exe c++ jest to samo co w borlandowym exe 481/482. Jak tam wyglada obsluga wielu runingnoise nie wiem, cos w tym kierunku robil swego czasu @Szociu w osobnej galezi, ale nie przygladalem sie jeszcze czy cos z tego weszlo do 'oficjalnej' wersji borlandowej i w konsekwencji do c++

To jeszcze zapytam o to na ile skomplikowane by bylo zrobienie autosave badz save pid FX? Czy to wogule wykonalne jest na obecnym etapie?
Sposob w jaki obecnie przechowywane sa obiekty w trakcie symulacji i odwolania miedzy nimi sa dosc zakrecone, co powoduje ze robienie teraz mozliwosci nagrywania byloby raz ze skomplikowane, dwa ze troche marnowaniem wysilku, bo aranzacje danych symulacji i tak chyba bedzie wygodniej przekonstruowac na potrzeby zapisu scenerii z poziomu exe itp , co wymusiloby przepisywanie kodu nagrywania/ladowania przynajmniej w pewnym stopniu od nowa.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 21 Kwietnia 2017, 06:23:58
EXE 170418 x64, VBO:

Dla ED72 nie działa wyłączanie WS i przetwornicy, tzn klawisze M i X. Włączanie działa, wyłączanie nie działa. Zapala się tam też czerwona lampka (nieopisana), którą wcześniej gasiło się klawiszem X, teraz w ogóle się nie da. (Żeby odtworzyć: włączyć WS i przetwornicę, wyłączyć i włączyć baterię). Przyciemnianie światła w kabinie nie działa. Działało prawidłowo w EU07, nie działa w ED72.

Oprócz tego na Kaliskiej podsypki torów nadal bardzo się trzęsą na boki, księżyc trzęsie się na boki i skład trzęsie się na boki jeśli uruchomi się widok lusterka podczas jazdy. Trzęsienie na boki widoczne tylko podczas jazdy. Nagły wysyp gdzieś między Zduńską Wolą a Pabianicami dla Włókniarza.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: matek123 w 21 Kwietnia 2017, 06:25:54
Żeby działało przyciemnienie, to musi być zdefiniowany przełącznik w kabinie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 21 Kwietnia 2017, 11:35:48
Natomiast jeszcze co do hebelków w EN57, to w rzeczywistości hebelek impulsowy od WSa służy tylko do jego załączania i nie ma bezpośredniej możliwość wyłączenia WSa jakimś dedykowanym hebelkiem czy przyciskiem, ale za to np. przez opuszczenie pantografów, ew. wyzwolenie któregoś z zabezpieczeń (przekaźniki nadmiarowe lub różnicowy).

Na calkiem sporej ilosci EN57 dajac odblok nadmiarowych, puszcza tez WS. Ale tez - nie na wszystkich ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 21 Kwietnia 2017, 12:31:45
Dla ED72 nie działa wyłączanie WS i przetwornicy, tzn klawisze M i X. Włączanie działa, wyłączanie nie działa. Zapala się tam też czerwona lampka (nieopisana), którą wcześniej gasiło się klawiszem X, teraz w ogóle się nie da. (Żeby odtworzyć: włączyć WS i przetwornicę, wyłączyć i włączyć baterię). Przyciemnianie światła w kabinie nie działa. Działało prawidłowo w EU07, nie działa w ED72.
Zgodnie z podanymi wczesniej w watku informacjami EN57 i pochodne nie maja bezposredniego wylacznika WS. Wylaczenie przetwornicy jak najbardziej dziala -- to slychac (dzwiek przetwornicy cichnie po ponownym nacisnieciu X) i widac (zapala sie lampka o ktorej piszesz, a wskaznik niskiego napiecia idzie nieco w dol, jesli bateria nie jest jeszcze w pelni naladowana. Lampka gasnie, jesli ponownie uruchomisz przetwornice klawiszem X) Chociaz swoja droga to w ED72 nie ma wylacznika i ktos musialby to poprawic:
Failed to locate sub-model "przetwwyl" in 3d model "dynamic\pkp\ed72_v1\kabina_a.e3d"

Trzesienie na boki niestety bedzie na razie miec miejsce, trzeba zrobic pare rzeczy zanim da sie sprobowac jakos to zmniejszyc.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 21 Kwietnia 2017, 13:19:19
A ja Ci jeszcze zgłaszałem ze owszem wyłącznie ws nie działa ale po kliknięciu m wyłącza przetwornice
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 21 Kwietnia 2017, 13:22:52
Pamietam, jest poprawione w 'nastepnym' uaktualnieniu, tylko jeszcze sie w watku nie znalazlo :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 21 Kwietnia 2017, 14:12:04
ED72, u mnie nie dziala p, kilka krotne wciskanie nie powoduje opuszczenia i podniesienia pantografu. Zwierzyniec.scn
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 21 Kwietnia 2017, 14:20:49
Podnoszenie pantografu dziala w ED72 postawionym na TD. Moze w scenariuszu jest brak powietrza w sprezarce pomocniczej, i trzeba podpompowac?

Opuszczanie nie dziala bo przycisk opuszczania obu pantografow nie istnieje:
Failed to locate sub-model "pantopuszcz" in 3d model "dynamic\pkp\ed72_v1\kabina_a.e3d"
a dedykowany przycisk opuszczania przedniego pantografu jest nie wiedziec czemu przypisany w .mmd do pantografu tylnego:
pantrearoff_sw: pantprzedniopuszcz rot -0.125 0 0.2
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 21 Kwietnia 2017, 14:29:18
Moze nie do konca opisalem. Podczas gdy p nie dziala, swobodnie moge operowac przyciskiem o. Czyli o opuszcza i podnosi patyki w tym samym czasie co p nie nie da rady wykonac. Przedni patyk pozostaje podniesiony.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 21 Kwietnia 2017, 14:49:11
Czyli technicznie rzecz biorac, wszystko dziala tak, jak zostalo zdefiniowane (pomijajac chwilowo, ze ta konfiguracja jest bledna)

- ED72 ma zdefiniowane przyciski impulsowe, wiec do podniesienia i opuszczenia kazdego pantografu musza byc dwa przyciski
- pantograph przedni ma zdefiniowany tylko przycisk podnoszenia -- podnoszenie dziala, opuszczania 'nie ma'
- pantograph tylny ma zdefiniowany przycisk podnoszenia i (blednie) opuszczenia -- podnoszenie dziala, opuszczanie dziala
- przycisk do opuszczenia obu pantografow wskazuje na nieistniejacy submodel -- opuszczenie obu pantografow nie dziala

(dodatkowo przycisk opuszczenia 'tylnego' (a tak naprawde przedniego) pantografu ma zle ustawione osie animacji, ale to widac dopiero w nowym uaktualnieniu ktorego jeszcze nie masz)

tl;dr: model kabiny i .mmd sa do poprawienia.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 21 Kwietnia 2017, 15:31:09
A to problem na Win Vista x86.
Monitory białe i nie da się ich włączyć.
Dołącze jeszcze zapisy z loga.
0: Wait_for_orders <-
1: Prepare_engine
2: Obey_train
3: Shunt
4: Wait_for_orders
--> JumpToFirstOrder
Orders for a25006:
0: Wait_for_orders
1: Prepare_engine <-
2: Obey_train
3: Shunt
4: Wait_for_orders
--> OrdersInit
------------------------------------------------------
init default physic values for a57603, [a4], []
LOAD FIZ FROM dynamic\road\a4\a4.fiz
CERROR: 0, SUCCES: true
check locomotive parameters...
Ready to depart
--> OrdersClear
New timetable for a57603:
--> OrdersClear
--> OrderPush
Orders for a57603:
0: Wait_for_orders <-
1: Prepare_engine
2: Wait_for_orders
--> OrderPush
Orders for a57603:
0: Wait_for_orders <-
1: Prepare_engine
2: Obey_train
3: Wait_for_orders
--> OrderPush
Orders for a57603:
0: Wait_for_orders <-
1: Prepare_engine
2: Obey_train
3: Shunt
4: Wait_for_orders
--> JumpToFirstOrder
Orders for a57603:
0: Wait_for_orders
1: Prepare_engine <-
2: Obey_train
3: Shunt
4: Wait_for_orders
--> OrdersInit
Ground init OK
Loading text format 3d model data from "models\skydome_stars.t3d"...
Clouds init
Loading binary format 3d model data from "models\cgskj_sunset083.e3d"...
Created texture object for "textures\sky\sky_sunset083.dds"
Loading texture data from "textures\sky\sky_sunset083.dds"
Finished loading 3d model data from "models\cgskj_sunset083.e3d"
Player train init: 146_226-6
Loading Python ...
Loading binary format 3d model data from "dynamic\pkp\e186_v2\kabina_a.e3d"...
Created texture object for "textures\tabor\smycz.tga"
Loading texture data from "textures\tabor\smycz.tga"
Created texture object for "textures\tabor\gasnica.tga"
Loading texture data from "textures\tabor\gasnica.tga"
Created texture object for "textures\tabor\naleczowianka.tga"
Loading texture data from "textures\tabor\naleczowianka.tga"
Created texture object for "dynamic\pkp\e186_v2\kabina_a.tga"
Loading texture data from "dynamic\pkp\e186_v2\kabina_a.tga"
Created texture object for "dynamic\pkp\e186_v2\kabina_b.tga"
Loading texture data from "dynamic\pkp\e186_v2\kabina_b.tga"
Created texture object for "dynamic\pkp\e186_v2\kabina_c.tga"
Loading texture data from "dynamic\pkp\e186_v2\kabina_c.tga"
Created texture object for "dynamic\pkp\e186_v2\ek1.tga"
Loading texture data from "dynamic\pkp\e186_v2\ek1.tga"
Finished loading 3d model data from "dynamic\pkp\e186_v2\kabina_a.e3d"
Failed to locate sub-model "cofanie_nastawnika" in 3d model "dynamic\pkp\e186_v2
\kabina_a.e3d"
Created python screen traxx_renderer on submodel wyswietlacz (683)
Player train init OK
Load time: 33 seconds
EVENT LAUNCHED: onstart_zacheta
Multiple passed
EVENT ADDED TO QUEUE: baltyk_p_ms2
EVENT ADDED TO QUEUE: start
EVENT LAUNCHED: baltyk_p_ms2
Multiple passed
EVENT ADDED TO QUEUE: baltyk_p_sem_ligh22
EVENT ADDED TO QUEUE: baltyk_p_sem_info_shunt25
EVENT LAUNCHED: baltyk_p_sem_ligh22
EVENT LAUNCHED: baltyk_p_sem_info_shunt25
Type: UpdateValues - ShuntVelocity 25.000000 0.000000
--> JumpToNextOrder
Orders for a17710:
0: Wait_for_orders
1: Prepare_engine
2: Obey_train <-
3: Shunt
4: Wait_for_orders
--> JumpToNextOrder
Orders for a18391:
0: Wait_for_orders
1: Prepare_engine
2: Obey_train <-
3: Shunt
4: Wait_for_orders
--> JumpToNextOrder
Orders for a13183:
0: Wait_for_orders
1: Prepare_engine
2: Obey_train <-
3: Shunt
4: Wait_for_orders
--> JumpToNextOrder
Orders for a57603:
0: Wait_for_orders
1: Prepare_engine
2: Obey_train <-
3: Shunt
4: Wait_for_orders
--> JumpToNextOrder
Orders for a25006:
0: Wait_for_orders
1: Prepare_engine
2: Obey_train <-
3: Shunt
4: Wait_for_orders
--> JumpToNextOrder
Orders for a48426:
0: Wait_for_orders
1: Prepare_engine
2: Obey_train <-
3: Shunt
4: Wait_for_orders
--> JumpToNextOrder
Orders for a25297:
0: Wait_for_orders
1: Prepare_engine
2: Obey_train <-
3: Shunt
4: Wait_for_orders
--> JumpToNextOrder
Orders for a42678:
0: Wait_for_orders
1: Prepare_engine
2: Obey_train <-
3: Shunt
4: Wait_for_orders
--> JumpToNextOrder
Orders for a17150:
0: Wait_for_orders
1: Prepare_engine
2: Obey_train <-
3: Shunt
4: Wait_for_orders
--> JumpToNextOrder
Orders for a36592:
0: Wait_for_orders
1: Prepare_engine
2: Obey_train <-
3: Shunt
4: Wait_for_orders
--> JumpToNextOrder
Orders for a54437:
0: Wait_for_orders
1: Prepare_engine
2: Obey_train <-
3: Shunt
4: Wait_for_orders
--> JumpToNextOrder
Orders for a47414:
0: Wait_for_orders
1: Prepare_engine
2: Obey_train <-
3: Shunt
4: Wait_for_orders
--> JumpToNextOrder
Orders for a55454:
0: Wait_for_orders
1: Prepare_engine
2: Obey_train <-
3: Shunt
4: Wait_for_orders
--> JumpToNextOrder
Orders for a26048:
0: Wait_for_orders
1: Prepare_engine
2: Obey_train <-
3: Shunt
4: Wait_for_orders
--> JumpToNextOrder
Orders for a51997:
0: Wait_for_orders
1: Prepare_engine
2: Obey_train <-
3: Shunt
4: Wait_for_orders
--> JumpToNextOrder
Orders for a50801:
0: Wait_for_orders
1: Prepare_engine
2: Obey_train <-
3: Shunt
4: Wait_for_orders
--> JumpToNextOrder
Orders for a59232:
0: Wait_for_orders
1: Prepare_engine
2: Obey_train <-
3: Shunt
4: Wait_for_orders
--> JumpToNextOrder
Orders for a17672:
0: Wait_for_orders
1: Prepare_engine
2: Obey_train <-
3: Shunt
4: Wait_for_orders
--> JumpToNextOrder
Orders for a13176:
0: Wait_for_orders
1: Prepare_engine
2: Obey_train <-
3: Shunt
4: Wait_for_orders
--> JumpToNextOrder
Orders for a6324:
0: Wait_for_orders
1: Prepare_engine
2: Obey_train <-
3: Shunt
4: Wait_for_orders
--> JumpToNextOrder
Orders for a10117:
0: Wait_for_orders
1: Prepare_engine
2: Obey_train <-
3: Shunt
4: Wait_for_orders
--> JumpToNextOrder
Orders for a27189:
0: Wait_for_orders
1: Prepare_engine
2: Obey_train <-
3: Shunt
4: Wait_for_orders
--> JumpToNextOrder
Orders for a43059:
0: Wait_for_orders
1: Prepare_engine
2: Obey_train <-
3: Shunt
4: Wait_for_orders
--> JumpToNextOrder
Orders for a15619:
0: Wait_for_orders
1: Prepare_engine
2: Obey_train <-
3: Shunt
4: Wait_for_orders
--> JumpToNextOrder
Orders for a23703:
0: Wait_for_orders
1: Prepare_engine
2: Obey_train <-
3: Shunt
4: Wait_for_orders
--> JumpToNextOrder
Orders for a19201:
0: Wait_for_orders
1: Prepare_engine
2: Obey_train <-
3: Shunt
4: Wait_for_orders
--> JumpToNextOrder
Orders for a19637:
0: Wait_for_orders
1: Prepare_engine
2: Obey_train <-
3: Shunt
4: Wait_for_orders
--> JumpToNextOrder
Orders for a10486:
0: Wait_for_orders
1: Prepare_engine
2: Obey_train <-
3: Shunt
4: Wait_for_orders
--> JumpToNextOrder
Orders for a18606:
0: Wait_for_orders
1: Prepare_engine
2: Obey_train <-
3: Shunt
4: Wait_for_orders
--> JumpToNextOrder
Orders for a57228:
0: Wait_for_orders
1: Prepare_engine
2: Obey_train <-
3: Shunt
4: Wait_for_orders

http://eu07.pl/userfiles/4746/foto-Bombrardier_na_Vista.jpg (http://eu07.pl/userfiles/4746/foto-Bombrardier_na_Vista.jpg)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 21 Kwietnia 2017, 15:40:12
A to problem na Win Vista x86.
Monitory białe i nie da się ich włączyć.
Dołącze jeszcze zapisy z loga.
Daj caly log i errors, zamiast bawic sie w wycinanie :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 21 Kwietnia 2017, 15:40:53
Dałem cały. Błąd mi nie wyskakuje. Jak możesz to wejdź na czat.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 21 Kwietnia 2017, 15:42:34
No raczej nie caly, bo caly log zaczyna sie od diagnostyki sprzetu itp ktorych tutaj nie widze.
A errors tez musi byc, bo tam sie pokazuje brakujacy submodel, wiec chocby dla podania tego zostalby stworzony.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 21 Kwietnia 2017, 15:51:37
O to biega?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 21 Kwietnia 2017, 15:52:31
Dokladnie; errors.txt tworzy sie w tym samym miejscu, to tak na przyszlosc ;)

edit: czyli tak, "karta graficzna" w tym komputerze to jest raczej pseudokarta wbudowana w chipset Intela sprzed 10 lat. Teoretycznie powinna byc zdolna wygenerowac tekstury wyswietlacza, bo nie ma tam zadnych specjalnych wymagan, ale jak widac teoria sobie, a praktyka sobie.

Jak to wyglada w przypadku wersji Borlandowej, czy wyswietlacze widac normalnie?

(tak na marginesie, 16x multisampling na tej konfiguracji to jest totalne przegiecie, ustaw tam w .ini raczej multisampling 1 albo jeszcze lepiej 0)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 21 Kwietnia 2017, 17:00:55
Na exe 1351 nie ma problemów.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 21 Kwietnia 2017, 17:04:53
Znaczy sie problem pewnie jest w ustawieniach dla generowanej tekstury (czyli generowanie mipmap itp, zeby nie wygladalo jak dolna czesc plecow)
Problem w tym ze ta "kartra graficzna" twierdzi ze ona takie generowanie obsluguje, wiec to moze byc jakis blad w jej sterowniku. I trzeba by recznie dopisywac poprawki do kodu dla jednego cholernego intela :P
Ten komputer to laptop jest, czy cos bardziej normalnego?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 21 Kwietnia 2017, 17:07:22
PC. Generalnie jaj nie urywa.
Bez przerwy przy starcie wyskakują jakieś informacje graficzne, ale nie błędy, tylko informacje.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 21 Kwietnia 2017, 17:15:59
To jak bedziesz mial okazje to zajrzyj mu do srodka, czy on tam czasem nie ma jakiejs normalnej karty graficznej ktorej nie ma wlaczonej :s
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 21 Kwietnia 2017, 17:36:29
Nagly wysyp miedzy ZWK a PAB to dlugi odcinek. Mi exeki wywalaly zwykle i teraz tez w okolicy Borszewic przed peronami. Tmj uwaza ze to blad skanowania i ze to wysyp losowy. Musi tam w torach byc cos co jest zle przez exe odbierane. Tmj przeszczep lusterka od Q. I ten dym. Dizle beda mialy wreszcie to Smoke.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 21 Kwietnia 2017, 19:29:04
EU07-150 (sceneria l053-sluzba-1-night), nie da się zapalić światła w kabinie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 21 Kwietnia 2017, 19:58:05
Model nie ma zdefiniowanego przelacznika oswietlenia kabiny.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: matek123 w 21 Kwietnia 2017, 20:12:59
@HTD, czytasz co się dzieje w wątku, czy tylko wypisujesz swoje obserwacje i zostawiasz je samopas?
[...]
w dzisiejszym uaktualnieniu:

- podpiete pod nowa kontrole: wylacznik stycznikow liniowych, przelaczniki oswietlenia przyrzadow, oswietlenia kabiny, przyciemnienia oswietlenia kabiny. Oswietlenie przyrzadow jest pod ; oswietlenie kabiny pod ' a przyciemnienie pod ctrl + ' (czyli prawie tak jak bylo, tylko zapalenie i przyciemnienie kabiny jest teraz w jednym miejscu)
tutaj uwaga: obsluga jest uzalezniona od obecnosci przyciskow/modeli w kabinie, bo na ten moment nie ma za bardzo innej mozliwosci sprawdzenia, czy pojazd posiada taka funkcje. Powiedzmy ze to taka... zacheta zeby wyposazyc modele w co trzeba.
[...]
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 21 Kwietnia 2017, 20:30:03
TMJ nie moglo by zostać po staremu? Teraz spora czesc taboru będzie okaleczona. Ta zmiana przyspazy dużo roboty o ile komukolwiek będzie się chciało to robic. Zostaw chociaż podstawowe osw kabiny po staremu.

Cala seria 4e nie ma zdefiniowanego w mmd cablight_sw: sw-oswietlenie-kabiny rot -0.2 0 0.2
cablightdim_sw: sw-przyc-kabiny rot -0.2 0 0.2

A także nie sa nazwane owe elementy w t3d kabin.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 21 Kwietnia 2017, 20:49:43
Po staremu na upartego moze pozostac wszystko, lacznie z exe :)

W tej chwili jest jak jest w duzej mierze zeby wlasnie wymusic, zeby komus chcialo sie ruszyc cztery litery i zrobic. Bo bez wymuszenia, skoro prowizorka dziala, to po co sie meczyc? (zeby nie bylo to zle zrozumiane, to nie jest pretensja albo cos. raczej obserwacja normalnego stan rzeczy; wiem bo tez tak mam)

Do pewnego stopnia jest tez tak poniewaz, jak wspomnialem, nie ma w exe mechanizmu zeby sprawdzic jakie urzadzenia sa dostepne w konkretnej kabinie (wszystko jest 'na sztywno' zdefiniowane jako obecne) Ale nawet gdy taki mechanizm zostanie byc moze wprowadzony, to i tak komus bedzie sie musialo chciec te kabiny opisac, bo samo sie nie zrobi.

Natomiast nie wykluczam ze docelowo obsluga bedzie odblokowana, a brak przyciskow itp bedzie jedynie generowal ostrzezenie. Ale to jest tylko "moze" wiec specjalnie prosze na to nie liczyc :d
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 21 Kwietnia 2017, 21:02:08
Dobra, jak to się da poprawić bez jakiś specjalnych narzędzi to chętnie poprawię, tylko co i jak poprawić? Jestem za tym, żeby exe działało raczej po nowemu i poprawić resztę, tylko nie wiem co i jak poprawiać.

Także: wysyp na tej samej l053-sluzba1-night (ET22-094), przed Żernikami, detale w logu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 21 Kwietnia 2017, 21:03:48
Z tego co widze uposledzenie niektorych funkcji nie odbiera mozliwosci zabawy symulatorem. Brak drobiazgow nie jest wiec krytyczny. Kiedys sie poprawi.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 21 Kwietnia 2017, 21:27:12
Te ostatnie exe jest bardziej felerne od poprzedniego numeru. Na poprzednim Kaliska dalo się objechać w kazda strone (albo miałem farta). Tym razem kilka kilometrow za OW wywalilo exe od tak sobie. TMJ może trzeba by się teraz bardziej skupic na stabilności? Kaliskiej nie da się ukonczyc poraz trzeci. Dzis były 2 proby ta druga wlasnie się zakonczyla.


HTD ostatnio na to pomoglo wylaczenie VBO. Teraz nawet to nie pomaga. Wywala dalej. Ja jezdze na DL.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 21 Kwietnia 2017, 21:43:39
Tym razem kilka kilometrow za OW wywalilo exe od tak sobie.
To jest ten glupi wysyp przy skanowaniu, w tym samym miejscu co zwykle (TableTraceRoute) Konkretne miejsce w zalaczniku, moze @firleju rozpozna czy to jest cos, co juz naprawil.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 21 Kwietnia 2017, 21:45:49
Ale zmieniales cos od ostatniego numeru? Czemu na numerze wcześniej tym bez bocznikow dalo się jezdzic? TZn wysypy zdarzaly się ale zadziej. Pamietasz motyw z l053 sl3? Meldowalem o regularnym wysypie przed Zernikami jadac z Debicy. Pozniej to ustalo bo mnowiles ze przyczyna lezy w VBO ze cos zle renderuje czy cos. Teraz mamy inny problem. Przy okazji potwierdzam to co mowil ktorys poprzednik ze podsypka strasznie miga i lata na wszystkie strony księżyc.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 21 Kwietnia 2017, 21:53:18
Nie, ja tam w ogole nigdy nic nie ruszalem. Na tym polega 'losowosc', blad wyskakuje okazjonalnie, zaleznie od tego jak sie rozwinie sytuacja na scenerii, a ona sie rozwija zaleznie od setki roznych rzeczy. Byloby duzo prosciej gdyby to wyskakiwalo zawsze w jakiejs konkretnej sytuacji.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 21 Kwietnia 2017, 23:44:59
Zostaw te hebelki jak są. "Mały sabotaż" to często jedyna opcja wymuszenia poprawienia błędów w paczce. Exe ładnie loguje w czym problem, trzeba usiąść i poprawiać.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: pol102 w 22 Kwietnia 2017, 00:48:55
Będe bronił @tmj. Jako pierwszy systematycznie punkt po punkcie nie leczy zachowawczo tylko naprawia problemy od podstaw. Włodek, może dobrze by było zamiast żądać protezowania pomóc w misji uzupełniania mmd o niezbędne definicje hebli i przycisków? Masz wiedzę na temat działania jednostek i ta wiedza jest bardzo potrzebna. Jak wyjdziemy z tego etapu, to naprawi się następny problem uniemożliwiający rozwój. Firlej rozgrzebał temat tabelki i jak sam gdzieś już pisał sprawa jest poważna i "gruuuba". Swoją drogą, @tmj da się ustawić pułapki coby przepatrzeć co wykrzacza tabelkę? Do wyłapywania i szukania powtarzalności bugów koniecznie ustawić multiplelogs yes, łatwiej szukać różnic...

Jak czytam o ficzerach typu lusterka i model cząsteczkowy na tym etapie prac, to nie wiem czy śmiać się czy płakać.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 22 Kwietnia 2017, 01:53:52
Swoją drogą, @tmj da się ustawić pułapki coby przepatrzeć co wykrzacza tabelkę?
W sumie od tego wlasnie jest crashdump, ale ten ktory generuje exe to jest wersja minimalna zeby latwo bylo doczepic do watku, wiec tam jest z reguly tylko punkt zaczepienia, a do porzadnego usuniecia musze juz to raczej wylapac u siebie i najlepiej w wersji exe skompilowanej specjalnie do debugowania.

Tak czy owak, w dzisiejszym uaktualnieniu:

- podpiete pod nowa kontrole: piasecznica i przyhamowanie poslizgowe, trabki, przelacznik radia, sygnalizacja hamowania czlonow DZT (shift+L), przelacznik zrodla dla wskaznikow pradu (w ET41, shift+Z), przyciemnianie reflektorow (ctrl+L), przyciski zerowania przekaznikow nadmiarowych, obsluga korka trojdrogowego i sprezarki pantografow. Czyli obsluga jest kompletna na jakies 90% i jest szansa ze przez weekend bedzie ogarnieta do konca razem z redefinicja klawiszy.

- poprawka: logi i pliki crashdump beda nagrywane z godzina lokalna w nazwie, zamiast UTC

- poprawki zgloszonych bledow w obsludze niektorych przelacznikow (interakcja wylacznika szybkiego z przetwornica i inne ktorych nie pamietam)

- pantografy nie opadaja wiecej automatycznie po odlaczeniu zrodel zasilania, a jedynie gdy cisnienie powietrza w instalacji spadnie ponizej dopuszczalnego poziomu.

- eksperymentalne: dodane 'wycieki' powietrza z poszczegolnych elementow systemu hamulcowego. Tymczasowo na minimalnym 'sztywnym' poziomie, docelowo konfigurowalne

- dodatkowa diagnostyka brakujacych urzadzen kabiny: dla czesci przyciskow w przypadku ich braku (takze przy braku definicji, a nie tylko bledzie ladowania) umieszczana jest o tym wzmianka w logu, w momencie nacisniecia kontrolujacego urzadzenie przycisku
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: pol102 w 22 Kwietnia 2017, 02:04:34
@tmj, jak się Firlej znajdzie to trzeba dopytać dokładnie na czym stanął bo być może problem już namierzył przed przepisywaniem tej porcji kodu.
Gdyby się okazało, że jednak nie znamy pochodzenia tego błędu to sugerowałbym rozbudować crashdump o naście nowych pozycji i takie właśnie exe wypuścić do testowania. crashdumpy przy multiplelogs się nie nadpisują?
Potrzeba też koniecznie uzupełnić changelog bo za chwilę poginiemy w tym co jest zrobione i co jeszcze zrobić trzeba. Koniecznie proszę o całą aktualną klawiszologię.

Pisałeś gdzieś w bugtrackerze o niedopasowaniu barwowym FreeSpotLight z kolorem tekstury... Jak to ustalić? Jaki tam jest zaimplementowany model  palety RGB?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 22 Kwietnia 2017, 02:13:44
Zmiany klawiszologii w stosunku do standardu sa juz wpisane w changelog, tego co jest tutaj na razie nie dopisuje bo pokrywa sie z tym co juz jest wpisane, a wymienianie tam poszczegolnych dodanych przelacznikow to raczej rozmienianie sie na drobne :)

roznica miedzy tekstura a spotlight jest niestety do sprawdzenia glownie na oko -- spotlight widoczny jest na wiekszych dystansach (400-500 metrow) a tekstura zaczyna byc wyraznie widoczna blizej, wiec to jest cos co najszybciej wychodzi w ruchu. Jesli nie widac na oko, to nie ma sie co przejmowac ;)  W tej chwili najbardziej zauwazalne sa 'zotle' swiatla semaforow, nic innego nie przychodzi mi na szybko do glowy.

edit: aha, a kolory sa o ile dobrze pamietam definiowane "normalnie", tzn wartosciami w zakresie 0-255 dla kazdej skladowej RGB
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: pol102 w 22 Kwietnia 2017, 02:19:53
(http://eu07.pl/userfiles/4269/priv-Clipboard01.png)
Punkt wyjścia już mamy :)

Generalnie podejrzewam, że problem tex<->FreeSpotLight może być trochę powszechniejszy...
http://planetpixelemporium.com/tutorialpages/light.html
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 22 Kwietnia 2017, 02:26:48
Normalnie nie powinien byc chyba dosc rozpowszechniony, bo przypisanie wartosci jest z punktu widzenia artysty/autora dosc proste -- zlapac za color picker w programie graficznym, kliknac w teksture wlaczonego swiatla/lampki (przy ustawieniu pobierania sredniej wartosci koloru z obszaru zamiast jednego piksela) i wpisac odczytana wartosc jako parameter dla spotlight. A ile ten kolor tekstury/swiatla ma wspolnego z rzeczywistoscia to juz inna para kaloszy ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: pol102 w 22 Kwietnia 2017, 02:35:06
A ile ten kolor tekstury/swiatla ma wspolnego z rzeczywistoscia to juz inna para kaloszy ;)
Sedno :D
Póki nie możemy swobodnie realizować oświetlenia (vide 30 świecących latarni drogowych w promieniu widzenia) o tyle nie robi to różnicy. W przeciwnym wypadku sprawa do rozważenia w prosty sposób:

Type: FreeSpotLight
Name: light_on00_TYPOPRAWY

Oprawy definiujemy globalnie osobno w jakimś pliku bo oprawa to de facto: typ źródła, kąt świecenia,promień świecenia, temp barwowa i strumień. Ale to taki offtopic.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 22 Kwietnia 2017, 02:39:59
Czemu se nie zrobicie kilupoziomowego debuggera funkcji? Na przyklad poziom 1 to logowanie samych naglowkow wykonywanych funkcji np.

WriteLog("bool TWorld::Render()");

Poziom 2 to  naglowki i zakonczeine zakonczenie funkcji czyli na koncu WriteLog("END"). Ntomiast poziom 3 to logowanie w roznych miejscach funkcji czyli poprostu numerki WriteLog("1") itd.
Moze troche mulic ale mysle ze warto takie cos wprowadzic.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 22 Kwietnia 2017, 06:56:50
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 (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ć).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 22 Kwietnia 2017, 08:10:30
To prawda. Obecnie na tym etapie nie moze byc tak ze za chwile polowa taboru bedzie unieruchomiona z powodu tego iz autorzy x lat temu nie brali pod uwage tego ze trzeba bedzie w kabinach zdefiniowac kazdy przycisk lampke lub przelacznik. Teraz pytanie kto tovwszystko zrobi? A zmiany sa duze. Wymagaja edycji mmd t3d kabin o byc moze korytarza oraz fiz, dodajac chodzby manualbrake. Tak ogromne zmiany z klawiatura wlacznie nie moga byc wydane jako path a jako pc 201x pod nowa nazwa. Trzeba by zebrac zespol do poprawek seria po serii. Dla przykladu cala seria 4e nie posiada ani definicji w mmd ani submodelu w t3d hebelkow od osw kabiny. Biorac dany pojazd na stol trzeba juz definitywnie wziasc pod uwage wszystko co tylko w kabinie moze dzialac. Nawet lampka od zzasilacza radia czy przelacznik od kuchenki.  Idealny temat dla kandydatow na devs. Tak przy okazji dodanie airsound i manualbrake do kilku plikow z knorrem przy mojej ilosci czasu jaki moge poswiecic obecnie, zajelo z testami ponad 4 dni. Czlowiek coraz starszy dzieci coraz wieksze obowiazki itp uniemozliwiaja juz developerke w takim zakresie jak jeszcze te 10 lat temu. Szkoda ze tak pozno taka akcja wyszla. No coz wydzial WPC ma co robic, w koncu od tego tez sa.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: matek123 w 22 Kwietnia 2017, 09:58:24
Testy kabin. Dla bezpieczeństwa arkusza odpowiedzi proszę udzielać za pomocą komentarzy. W miarę czasu będę przepisywać w tabelkę.

https://docs.google.com/spreadsheets/d/1dluBW6Ujq4FTkZGV9jUzhShxFbV2oK0n4MHwsSzPczU/edit?usp=sharing
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 22 Kwietnia 2017, 12:49:49
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?
To akurat nie ma nic wspolnego z modelem kabiny, ani ostatnimi zmianami -- w ED72 zeby zalaczyc przetwornice trzeba podniesc przedni pantograf, bo tylny jest na innym czlonie i sie nie udziela. Nie wiem na ile jest to poprawne, nie ja to pisalem.

Obecne zmiany w kontroli nie powinny przeszkadzac w podstawowej obsludze pojazdu, wlasnie miedzy innymi zeby nie wyszlo na to, ze polowy taboru nie mozna prowadzic. Poprzeczka jest, przynajmniej tymczasowo, powieszona wyzej tylko dla elementow co do ktorych nie ma pewnosci, ze sa w danym pojezdzie, i ktore nie sa niezbedne do jego pracy.

Cytuj
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.
No teraz jest zrobione wlasnie tak jak piszesz ze powinno byc :)  minus opcja klikniecia na przelaczniku, bo tego jeszcze nie ma.

Test czy dany model istnieje jest wykonywany poniewaz (jeszcze) nie ma mozliwosci konfiguracji co znajduje sie w danej kabinie, i to byla jedyna dostepna proteza. Ja to zreszta juz tutaj pare razy i calkiem niedawno wyjasnialem.

Cytuj
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?
Jesli to blad niezwiazany z exe, to jest do zglaszania takich rzeczy cale odrebne subforum, bugtracker paczki calosciowej -- http://eu07.pl/forum/index.php?project=2

Cytuj
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?
Sredni. To jest niejako 'efekt uboczny' ktory bedzie mozliwy do latwego wprowadzenia po zakonczeniu biezacych prac nad sterowaniem i kolejnego etapu ktorym jest ostateczne uporzadkowanie sciezek renderowania. Czyli to kwestia czasu moze nie najblizszego, ale kilku tygodni, zaleznie od tego jak szybko pojdzie porzadkowanie.

Cytuj
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.
Zachowania aut nie traktuje jako pilnego bledu, bo to ze samobojcy sobie przezynaja rogatki jak chca juz raczej zwieksza polski 'realizm' niz ma efekty negatywne :P  Czesc obecnych wysypow (te zwiazane z generowaniem geometrii) powinno sie dac usunac przy porzadkowaniu renderowania, ktore jest zaplanowane jako nastepne w kolejce. Trzesienie obrazu jest bardziej skomplikowane ale tez latwiej bedzie sprobowac cos z tym zrobic po uporzadkowaniu renderowania.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mk1991 w 22 Kwietnia 2017, 18:29:26
Nie wiem  czy ktoś o tym pisał, ale w ED72 i w EN57-2000 występuje zasadniczy problem. Nie działają trąbki. Innych jednostek jeszcze nie sprawdzałem pod tym kontem, ale nie waham się przypuszczać, że też problem będzie. Korzystam z najnowszego exe C++ 421.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mk1991 w 22 Kwietnia 2017, 18:46:16
Tak jak myślałem. Dla EN57 modele 6BAI, 6BAii i 6BAIV trąbki niema. Dla członów RB problem ten sam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mk1991 w 22 Kwietnia 2017, 18:52:57
Zajrzałem do mmd dla EN57 i już wiem o co chodzi. Niema wpisu dla pedałów syren w sekcji przełączników dla kabin.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 22 Kwietnia 2017, 18:53:58
Zgadza sie.
Key pressed: [A]
en57-1051ra received command: [hornlowactivate]
Horn button is missing, or wasn't defined
Nie ma pedalu, nie ma dzwieku.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 22 Kwietnia 2017, 20:26:33
Ja mogę w modelach to przerobić i zrobić te pedały, ale musiałbyś to w exe rozróżnić, żeby można było podpisać pod dwa submodele
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 22 Kwietnia 2017, 20:30:57
W tej chwili oba tony syreny sa obslugiwane przez jeden submodel animowany w zakresie -1 -> 0 -> 1  ale jesli zrobisz dwa osobne submodele animowane w zakresie 0-1  to dorobie obsluge dwoch osobnych przyciskow, odrebnie dla kazdego tonu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 22 Kwietnia 2017, 20:41:18
No ja to zrobię bez problemu w modelu kabiny, tylko czy dasz radę zrobić tak, żeby to wykorzystywało drugi model przy drugim tonie syreny. :D
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 22 Kwietnia 2017, 20:46:02
Dodam po prostu dwa przyciski do exe, i w .mmd przypisze sie kazdy pedal do jednego z nich, zamiast do wspoldzielonego tak jak to jest w pozostalych kabinach.

"Bedzie pan zadowoloooooonyyyyy"
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 22 Kwietnia 2017, 21:02:25
No dobra to w poniedziałek to zrobię także szykuj exe :D
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mk1991 w 22 Kwietnia 2017, 21:13:53
Poprawek będzie potrzebowała EP05. Tutaj też niema syreny.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: matek123 w 22 Kwietnia 2017, 21:25:16
Jak już przy syrenach jesteśmy, to SM42 i SM31 mają 3 sygnały. Syrena dźwignią 1 0 -1 i klakson grzybkiem. ET42 też potrzebuje 2 przycisków pod syrenę (obecnie ma jedną syrenę podpiętą pod odjazd).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mk1991 w 22 Kwietnia 2017, 21:27:52
Syren nie mają też lokomotywa EU05 i Drezyna dl2.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 22 Kwietnia 2017, 21:30:47
Jesli to nie problem, wrzuccie zgloszenia brakujacych elementow do bugtrackera, tak jak jest to w watku: http://eu07.pl/forum/index.php/topic,29047.msg450727.html#msg450727

A w miedzyczasie uaktualnienie.

- dodana obsluga konfiguracji klawiszy

na razie obejmuje tylko obsluge pojazdu, bo reszta nie jest jeszcze podpieta pod nowy system.
Przypisania klawiszy przechowywane sa w pliku "eu07_input-keyboard.ini" (plik tekstowy)
Kazda linia pliku definiuje jeden klawisz, np
pantographlowerall ctrl p // opuszczenie wszystkich pantografow
pierwsze slowo to nazwa komendy i tego nie ruszamy; nastepnie podany jest klawisz do ktorego ma byc przypisana, i opcjonalne modyfikatory shift i/lub ctrl  Komentarze tlumacza, ktora komenda jest do czego, zeby latwiej sie bylo polapac.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 22 Kwietnia 2017, 21:39:57
przelacznik radia,
Nie działa, tzn. po zadziałaniu radio-stopu nie ma możliwości zresetowania radia żadną z kombinacji [R], [Shift] i [Ctrl]. Po dawnemu radio wyłączało się przez [Ctrl]+[R] i załączało przez [Schift]+[R]. Jeśli jest to spowodowane brakiem zdefiniowanego w kabinie przycisku, to zadziałanie radio-stopu w jakimkolwiek pojeździe oznacza koniec każdego scenariusza. Sam sprawdziłem w ET41.
sygnalizacja hamowania czlonow DZT (shift+L),
Tzn.? Jeśli o to chodzi, to w ET41 jest kontrolka odhamowania tylnego członu i ta działa poprawnie bez wciskania czegokolwiek.
przelacznik zrodla dla wskaznikow pradu (w ET41, shift+Z),
Działa bistabilnie, a powinno działać impulsowo jak po staremu, bo to jest obsługiwane przyciskiem (na pulpicie obok przycisku odluźniacza hamulca).
przyciemnianie reflektorow (ctrl+L),
To samo co z oświetleniem kabiny - brak zdefiniowanych przełączników spowodował ponowny brak tej funkcji.
- poprawki zgloszonych bledow w obsludze niektorych przelacznikow (interakcja wylacznika szybkiego z przetwornica i inne ktorych nie pamietam)
Tak jak przetwornica, tak i silniki trakcyjne powinny dostawać zasilanie dopiero po puszczeniu przycisku załączenia WSa - obecnie da się od razu po zaświeceniu się jego kontrolki nie puszczając przycisku załączania. Przy starym sterowaniu błąd nie występował, bo załączając WSa z Shiftem nie dało się ruszyć nastawnikiem (co swoją drogą też było błędem, ale innym, który teraz przez przypadek udało się usunąć).
- pantografy nie opadaja wiecej automatycznie po odlaczeniu zrodel zasilania, a jedynie gdy cisnienie powietrza w instalacji spadnie ponizej dopuszczalnego poziomu.
Dlaczego z powrotem tak? W większości pojazdów pantografy powinny opadać po zaniku zasilania...
- eksperymentalne: dodane 'wycieki' powietrza z poszczegolnych elementow systemu hamulcowego. Tymczasowo na minimalnym 'sztywnym' poziomie, docelowo konfigurowalne
Jeśli chodzi o wagony osobowe widać dużą poprawę, ale w kwestii wagonów towarowych niewiele się zmieniło. ET41 + 40 Eaos-ów = załączanie sprężarki co ok. 93min. kiedy kran główny jest w pozycji jazdy i dodatkowy całkowicie zahamowany, podczas gdy w rzeczywistości w takiej sytuacji sprężarki potrafią załączać się nawet co 5min. i częściej.
Edit:
- dodana obsluga konfiguracji klawiszy
Świetne ;D Gdyby jeszcze tylko można było zdefiniować sobie osobne kombinacje dla załączania i wyłączania... ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: pol102 w 22 Kwietnia 2017, 22:26:27
Cytuj
Przypisania klawiszy przechowywane sa w pliku "eu07_input-keyboard.ini"

Skoro poszliśmy w tę dziwą stronę to należy napisać program z funkcją get_key ;)
Coś a'la
(http://emusite.pl/images/artykuly/dolphin/dol11.JPG)
Czyli lista hebli, przycisków, manipulatorów, obok pole gdzie klikamy (to aktywuje get_key).

Nie, nie ładujmy tego w przeładowane Rainsted.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 22 Kwietnia 2017, 22:55:56
Nie działa, tzn. po zadziałaniu radio-stopu nie ma możliwości zresetowania radia żadną z kombinacji [R], [Shift] i [Ctrl]. Po dawnemu radio wyłączało się przez [Ctrl]+[R] i załączało przez [Schift]+[R]. Jeśli jest to spowodowane brakiem zdefiniowanego w kabinie przycisku, to zadziałanie radio-stopu w jakimkolwiek pojeździe oznacza koniec każdego scenariusza. Sam sprawdziłem w ET41.
Zarowno wylaczenie jak ponowne zalaczenie to Ctrl + R. Na ile moge powiedziec dziala to tak, jak przedtem, i nie jest zwiazane z niemozliwoscia zresetowania radiostopu -- okazuje sie ze akurat ta funkcja nie dziala od dobrych kilku tygodni jesli nie dluzej, czyli takze ze starym sterowaniem (najstarsze exe jakie mam pod reka to 0330 i tam jest tak samo)  Biorac pod uwage ze przez ten czas nikt tego nie zauwazyl, jest to chyba 'feature' ktory nie jest wykorzystywany zbyt czesto ;o

Cytuj
Tzn.? Jeśli o to chodzi, to w ET41 jest kontrolka odhamowania tylnego członu i ta działa poprawnie bez wciskania czegokolwiek.
To jest chyba funkcja specjalnie dla ED72, uzycie jej tam wylacza/zalacza obsluge kontrolek ktore pokazuja stan hamowania.

Cytuj
Działa bistabilnie, a powinno działać impulsowo jak po staremu, bo to jest obsługiwane przyciskiem (na pulpicie obok przycisku odluźniacza hamulca).
(..)
Tak jak przetwornica, tak i silniki trakcyjne powinny dostawać zasilanie dopiero po puszczeniu przycisku załączenia WSa - obecnie da się od razu po zaświeceniu się jego kontrolki nie puszczając przycisku załączania
OK, pojdzie do poprawki

Cytuj
Dlaczego z powrotem tak? W większości pojazdów pantografy powinny opadać po zaniku zasilania...
Bo cos mi sie pokickalo, i nie wiedziec czemu wydalo mi sie ze zostaja w gorze tak dlugo jak w przewodzie jest dosc cisnienia zeby je tam trzymac :x

Cytuj
Jeśli chodzi o wagony osobowe widać dużą poprawę, ale w kwestii wagonów towarowych niewiele się zmieniło. ET41 + 40 Eaos-ów = załączanie sprężarki co ok. 93min. kiedy kran główny jest w pozycji jazdy i dodatkowy całkowicie zahamowany, podczas gdy w rzeczywistości w takiej sytuacji sprężarki potrafią załączać się nawet co 5min. i częściej.
Hmm u mnie wyglada to inaczej -- postawilem ET41 ze skladem 30 roznych wagonow towarowych jak na zalaczniku, odhamowalem sklad, zaciagnalem hamulec lokomotywy i sprezarka zalacza sie co 10-12 minut -- pompuje cisnienie do 8.5 (srodkowy odczyt PP na ekranie F3) i wlacza sie ponownie gdy cisnienie zejdzie do 7.5, podpompowuje znowu do 8.5, i tak w kolko. Podobnie zachowuje sie ET22 z tym samym skladem. Byc moze robie cos nie tak.

Cytuj
Świetne ;D Gdyby jeszcze tylko można było zdefiniować sobie osobne kombinacje dla załączania i wyłączania... ;)
Do tego trzeba bedzie dodac wiecej wariantow obslugi urzadzen, mniej wiecej po dwa na kazdy przycisk, a to duzo roboty jest :d Nie mowie ze na pewno nie, ale to nie jest wybitnie pasjonujaca perspektywa.

Skoro poszliśmy w tę dziwą stronę to należy napisać program z funkcją get_key ;)
Na razie bedzie jak jest, bo plan jest ze docelowo zamiast pisac dziwne zewnetrzne programy bedzie to wszyte w ustawienia w exe, tylko na razie nie ma tam jeszcze normalnego UI ktore by to moglo obsluzyc. :d
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: pol102 w 23 Kwietnia 2017, 02:15:00
Cytuj
Na razie bedzie jak jest, bo plan jest ze docelowo zamiast pisac dziwne zewnetrzne programy bedzie to wszyte w ustawienia w exe, tylko na razie nie ma tam jeszcze normalnego UI ktore by to moglo obsluzyc. :d

A jakąś namiastkę UI już masz? albo koncepcję?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 23 Kwietnia 2017, 03:08:10
Mam koncepcje wykorzystania jednego z gotowych rozwiazan na odpowiedniej licencji, bo to zbyt rozlegly temat by wymyslac kolo od nowa :>
(kandydatow jest kilku, ale jeszcze bez 100% pewnosci ktory sie zalapie)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: pol102 w 23 Kwietnia 2017, 04:22:26
@QuEuEdEu :D Jak to miałeś u siebie wymodzone?

@tmj, już byłem skłonny ściągać visuala i pomyśleć nad pomocą, ale odpuszczam :P Prościej napisać na tę chwilę coś na jednej formie z prostym parserem :D
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 23 Kwietnia 2017, 04:49:57
Chodzi o sterowanie mysza? Jezeli tak to jakos magicznie to bylo zrobione. Poszukam zamysl idei jak i tutorial ale nie wczesniej jak rano (wieczorem).
Dobra, w mysl 'co masz zrobic pozniej - zrob teraz', znalazlem listingi ale ztcp to czegos tu brakowalo. Tak czy inaczej mozna wyczytac zamysl funkcjonowania. Pomyslnej lektury zycze ;d.

http://q.matinf.pl/codesnippets/showcode.php?id=003
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 23 Kwietnia 2017, 06:53:45
Cytuj
Cytuj
Dlaczego z powrotem tak? W większości pojazdów pantografy powinny opadać po zaniku zasilania...
Bo cos mi sie pokickalo, i nie wiedziec czemu wydalo mi sie ze zostaja w gorze tak dlugo jak w przewodzie jest dosc cisnienia zeby je tam trzymac :x

No, bo jak juz zostalo napisane w tym watku - to zalezy od sprzetu ;) Trzeba to uzaleznic w fiz.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 23 Kwietnia 2017, 09:36:52
Ja tam jestem zadowolony z tego exe. Już pozmieniałem nazwy klawiszy hamowania i spokojnie mogę testować exe na moim pulpiciku. :) Bardzo dziękuję @tmj!
Chodzi o sterowanie mysza? Jezeli tak to jakos magicznie to bylo zrobione. Poszukam zamysl idei jak i tutorial ale nie wczesniej jak rano (wieczorem).
Bardzo dobre rozwiązanie to X-Mouse Button Controls. Sterowanie myszką jest nawet wygodniejsze niż z mojego pulpiciku.
Je zeli chcecie się dowiedzieć więcej jak to zrobić, to do mnie na pw. aby nie zaśmiecać wątku.Ustawienia Key nic Wam nie dadzą.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 23 Kwietnia 2017, 10:06:22
Tak bardziej informacyjnie dla innych: miałem problem z tym, że exe nie pozwalało mi sterować hamulcem w jakimkolwiek pojeździe. Okazuje się, że zmieniło się działanie feedbackmode 4 (Pokeys). W borlandowym brak podłączonego urządzenia sprawiał, że exe pomijało ustawienie trybu pracy i można było normalnie sterować przy pomocy klawiatury. Obecnie włączenie feedbackmode 4 (przy braku podłączonego Pokeys) powoduje zablokowanie ruszania zaworami hamulca.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: matek123 w 23 Kwietnia 2017, 10:07:20
Igorowi chodziło o mechanizm klikania myszką na przełączniki.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 23 Kwietnia 2017, 13:39:49
OK, male uaktualnienie:

- przywrocenie opadania pantografow przy braku zasilania

- przycisk wyswietlania pradu dla drugiego czlonu wraca samoczynnie

- zasilanie silnikow trakcyjnych nastepuje dopiero po puszczeniu wylacznika szybkiego (oprocz pojazdow z silnikiem diesla bo tam glupio to wygladalo; ale diesle i tak ktos by musial pewnie uporzadkowac, bo czesc obslugi jest wpasowana nieco na sile)

- obsluga odrebnych przyciskow aktywacji tonow syreny, hornlow_bt i hornhigh_bt Zalaczane sa tymi samymi klawiszami co zwykla dzwignia, to po prostu animacja dodatkowego obiektu w kabinie, jesli jest obecny. Tu uwaga: oba przyciski maja zakres animacji (0, 1) w odroznieniu od 'starej' dzwigni gdzie animacja niskiego tonu miala zakres (0, -1)

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 23 Kwietnia 2017, 13:45:32
Do Traksa, i pewnie czegoś jeszcze z nowinek, potrzebny jest trzeci manipulator do obu tonów syreny jednocześnie. W Traksie na pulpicie jest trójstabilny hebelek low/off/high oraz pedał dający ciśnienie na obie trąbki. Na klawiaturę ctrl+a?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 23 Kwietnia 2017, 13:52:01
Na klawiaturę ctrl+a?
Chyba tak. Mozna by to ctrl+a od razu wykorzystac do trzeciej trabki w tych pojazdach, ktore ja maja, ale to sie troche zakrecone robi. Moze lepiej bedzie sie wstrzymac do czasu uporzadkowania definicji kabiny (tzn kiedy definiowane beda tylko przyciski obecne w kabinie, a funkcje beda podpinane pod nie bezposrednio)

Dobra, w mysl 'co masz zrobic pozniej - zrob teraz', znalazlem listingi ale ztcp to czegos tu brakowalo. Tak czy inaczej mozna wyczytac zamysl funkcjonowania. Pomyslnej lektury zycze ;d.
http://q.matinf.pl/codesnippets/showcode.php?id=003
No mniej wiecej tak sie to wlasnie robi :)  Tylko chce najpierw miec ujednolicone renderowanie, zeby mozna bylo latwo wybierac 'tryb' rysowania, co przyda sie tez do innych rzeczy.

Tak nawiasem mowiac to ta siodemka na filmie troche bardziej rozbudowana jest ;o

edit:
a tak w ogole to po co ja sie z tym zajmuje; fizyka jest przetlumaczona, wiec w sumie wystarczy podczepic do exe co je Q wyprodukowal, i od razu bedzie kupa nowych features, a powinno chodzic szybciej niz na borlandzie :D
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 23 Kwietnia 2017, 14:47:45
No, bo jak juz zostalo napisane w tym watku - to zalezy od sprzetu ;) Trzeba to uzaleznic w fiz.
W większości jednak opadają, więc puki nie ma rozróżnienia na numery, we wszystkich może być jak w większości...
Zarowno wylaczenie jak ponowne zalaczenie to Ctrl + R. Na ile moge powiedziec dziala to tak, jak przedtem, i nie jest zwiazane z niemozliwoscia zresetowania radiostopu -- okazuje sie ze akurat ta funkcja nie dziala od dobrych kilku tygodni jesli nie dluzej, czyli takze ze starym sterowaniem (najstarsze exe jakie mam pod reka to 0330 i tam jest tak samo)  Biorac pod uwage ze przez ten czas nikt tego nie zauwazyl, jest to chyba 'feature' ktory nie jest wykorzystywany zbyt czesto ;o
Nie pamiętam który, ale jest chyba jakiś scenariusz, w którym radio-stop jest wyzwalany i później komunikat na radiu, że "ktoś się bawi radio-stopem" (czy coś w tym rodzaju), choć być może się mylę.
Hmm u mnie wyglada to inaczej -- postawilem ET41 ze skladem 30 roznych wagonow towarowych jak na zalaczniku, odhamowalem sklad, zaciagnalem hamulec lokomotywy i sprezarka zalacza sie co 10-12 minut -- pompuje cisnienie do 8.5 (srodkowy odczyt PP na ekranie F3) i wlacza sie ponownie gdy cisnienie zejdzie do 7.5, podpompowuje znowu do 8.5, i tak w kolko. Podobnie zachowuje sie ET22 z tym samym skladem. Byc moze robie cos nie tak.
Ok, mój błąd - jak zmieniałem wagony na towarowe w Rainsted, zapomniałem wybrać odpowiednie exe. U mnie sprężarki załączają się co ok. 13min. przy 40 wagonach. Jest więc duża poprawa, ale tak czy inaczej można by ten czas skrócić jeszcze o połowę, jeśli to nie problem, a przy dłuższym postoju będzie co robić - wyłączać przetwornice, żeby nie hałasowały i załączać co jakiś czas, żeby dopompować powietrza sprężarkami.
Do tego trzeba bedzie dodac wiecej wariantow obslugi urzadzen, mniej wiecej po dwa na kazdy przycisk, a to duzo roboty jest :d Nie mowie ze na pewno nie, ale to nie jest wybitnie pasjonujaca perspektywa.
Ok, ale tak jak pisałem, mogą być z tym problemy przy PoKeys, kiedy raz coś nie zaskoczy i jakiś hebelek na pulpicie zacznie działać w odwrotną stronę. Choć na razie jeszcze nie testowałem, więc się nie spieszy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 23 Kwietnia 2017, 14:58:48
Ok, mój błąd - jak zmieniałem wagony na towarowe w Rainsted, zapomniałem wybrać odpowiednie exe. U mnie sprężarki załączają się co ok. 13min. przy 40 wagonach. Jest więc duża poprawa, ale tak czy inaczej można by ten czas skrócić jeszcze o połowę, jeśli to nie problem, a przy dłuższym postoju będzie co robić - wyłączać przetwornice, żeby nie hałasowały i załączać co jakiś czas, żeby dopompować powietrza sprężarkami.
Skoro sie wstepnie sprawdzilo, to po trochu dojrzewam zeby predkosc wycieku powietrza wyprowadzic jako parametr do .fiz -- mozna wtedy dosc latwo zorganizowac sytuacje gdzie np. wagony towarowe ciekna szybciej (wskutek braku przegladow i wyposazenia w bardziej zapuszczonym stanie, o ile ma to sens) jak i w ogole wygodniej dopasowac parametry.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 23 Kwietnia 2017, 15:01:36
Ok, to super. Natomiast ostatnie poprawki działają. A tak przy okazji czy wprowadzenie sterowania za pomocą myszy umożliwi też w przyszłości ręczne przesterowywanie różnych przekaźników i styczników w szafach po ich wymodelowaniu i sprzęgnięciu z programem symulującym działanie obwodów oraz ich podpieranie i dokonywanie różnych połączeń/zmostkowań?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 23 Kwietnia 2017, 15:16:48
Skoro sie wstepnie sprawdzilo, to po trochu dojrzewam zeby predkosc wycieku powietrza wyprowadzic jako parametr do .fiz -- mozna wtedy dosc latwo zorganizowac sytuacje gdzie np. wagony towarowe ciekna szybciej (wskutek braku przegladow i wyposazenia w bardziej zapuszczonym stanie, o ile ma to sens) jak i w ogole wygodniej dopasowac parametry.
Prawdę mówiąc, to miało być w SPKSie od początku – dodałeś to jako zwykły Flow do atmosfery (0) z BrakeCyl, BrakeRes i CntrlRes?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 23 Kwietnia 2017, 15:24:42
W większości jednak opadają, więc puki nie ma rozróżnienia na numery, we wszystkich może być jak w większości...

Może w większości siódemek i ET22... Ale to jest niedopuszczalne we wszystkich EN57 i pochodnych.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 23 Kwietnia 2017, 15:29:21
dodałeś to jako zwykły Flow do atmosfery (0) z BrakeCyl, BrakeRes i CntrlRes?
Jeszcze prymitywniej, bo caly system hamulcow to w duzej mierze czarna magia (tzn nie of strony programowej, ale kalkulacji ;)  Minimalnie redukowane jest po prostu biezace cisnienie w PipePress, ScndPipePress i CompressedVolume, na poczatku funkcji kalkulujacych zachodzace w nich zmiany stanu. Zalozylem ze jesli sa wycieki, to wystepuja na 'stykach' miedzy tymi elementami.

edit:
A tak przy okazji czy wprowadzenie sterowania za pomocą myszy umożliwi też w przyszłości ręczne przesterowywanie różnych przekaźników i styczników w szafach po ich wymodelowaniu i sprzęgnięciu z programem symulującym działanie obwodów oraz ich podpieranie i dokonywanie różnych połączeń/zmostkowań?
Technicznie rzecz biorac nie wymaga to wprowadzenia sterowania mysza, "wystarczy" sama obecnosc elementow i komend dla ich obslugi. Ale to jest wybitnie nie moja dzialka, wprowadzeniem takich mechanizmow, sprzegniec itp musialby sie zajac ktos, kto w tym siedzi. Zdaje sie, ze byl tu nie az tak dawno watek na ten temat, musialbys szturchnac autora.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 23 Kwietnia 2017, 17:47:05
Kaliska pospieszny. Podmieniłem 424 na SU45, natomiast byka na sputnika. Po te scie radiostopu, nie mogłem uruchomić ET21. Wpadłem więc na pomysł zmiany loka na EU07-004, gdzie też uruchomiłem radio-stop. Również, jak w pozostałych nie mogłem goi skasować. Dopiero ponowne uruchomienie baterii pomogło. Wjeżdżam na Kaliską, a tu widzę, że SU45 wjeżdża śmiało ze składem od strony Chojen i bez rozłączenia się, jedzie dalej.
exex64.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: pat w 23 Kwietnia 2017, 18:08:16
Dzwieki hebelków powinny być słyszalne będąc poza kabiną?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 23 Kwietnia 2017, 18:14:32
Skoro jest mozliwosc ich przelaczania, to tak!
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 23 Kwietnia 2017, 18:15:54
Skoro nie jesteśmy kamerą w kabinie to nie! :D
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 23 Kwietnia 2017, 18:20:48
Jak jest cisza wokół i otwarte okno w kabinie, to tak! ;)

@tmj: Pewnie myślisz o tym wątku?: http://eu07.pl/forum/index.php/topic,28440.0.html Ja się tym zajmuję, a właściwie bardziej mój znajomy, który umie pisać programy (ja nie bardzo, tylko na mikrokontrolery ;) ) i właśnie pytam czy będzie techniczna możliwość wprowadzenia czegoś takiego, że np. kliknięcie LPM na przekaźnik/styk podpiera go w pozycji odciągniętej/rozwartej, a kliknięcie PPM podpiera w pozycji przyciągniętej/zwartej? Bo sam edytor obwodów w swoim oknie będzie to umożliwiał, tylko fajnie by było, żeby coś takiego dało się też robić na modelach aparatów w szafach lokomotywy, bo to jeszcze bardzie realistyczne od klikania na symbole elementów na dynamicznym schemacie...
Edit: ... a wtedy już niewiele brakuje do tego ;) :
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 23 Kwietnia 2017, 18:26:12
Skoro nie jesteśmy kamerą w kabinie to nie! :D
Masz na mysli pasazera na peronie. Jak jestem w debugmode i mam mozliwosc sterowania z zewnatrz, to chce slyszec co sie dzieje w kabinie. Potwierdzenie jako logiczne nastepstwo dzialania na klawiaturze. Widok z kamery w tym przypadku jest bez znaczenia, bo stwierdzenie "po za kabina" jest tozsame.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 24 Kwietnia 2017, 07:57:48
Firleju się znalazł, miał weekend walki z wkurzającymi żonę (i mnie też) mały wrednymi liczonymi w milionach owadami wyłażącymi nam ze ściany za kuchnią.
A odnośnie prac to wygląda jak problem z zawijaniem tabelki (iLast nie odnosi się do prawidłowego wpisu). Nie będę szukał bo zrobiłem to nie na macierzy C-style a na wektorze i troszkę inaczej sprawdzam skanowanie. Jest też szansa, że ta wywałka jest powodowana przez pojazd za skrzyżowaniem.

Mam zgłoszenie od użytkownika, że bardzo wydłużył się czas ładowania. Wrzucam dwa logi z pierwszego i drugiego. Podobno ładuje te same pliki t3d za każdy razem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 24 Kwietnia 2017, 11:13:18
T3d i TGA to paczka developerska, ładuje się znacząco dłużej. Mam wątpliwości czy standardowe exe dla użytkownika powinno wybitnie wspierać wczytywanie tych formatów. Dodatkowo wyłączone jest standardowe generowanie plików E3d przy wartości 7 w ini. Inna sprawa, że odnoszę wrażenie iż czas wczytywania e3d i dds, uległ wydłużeniu. Ale tu dokonam jeszcze porównań.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 24 Kwietnia 2017, 13:24:27
To chyba dwa razy ten sam log jest, bo i nazwa i czas ladowania zgadzaja sie co do joty :)
pliki t3d/tga rzeczywiscie beda sie ladowaly dluzej, ale chyba nawet developerzy nie dzialaja na co dzien z paczka w 100% w takim formacie, bo to nie ma wiekszego sensu?
edit:
porownalem czas ladowania tej samej scenerii (kaliska, start w kiblu) dla wersji obecnej i sprzed miesiaca, i nie widac zmian:
Starting MaSzyna rail vehicle simulator.
Release 16.0.1172.482 (executable: eu07-x86_170424.exe)
(..)
Player train init OK
Load time: 106 seconds

Starting MaSzyna rail vehicle simulator.
Release 16.0.1172.482 (executable: eu07-x86_170330.exe)
(..)
Player train init OK
Load time: 106 seconds

W obu przypadkach ladowanie 'na goraco', po wstepnym przebiegu zeby nie bylo roznic przy wczytywaniu z dysku.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 24 Kwietnia 2017, 13:42:29
Słynna Vista x 86.
Misja kaliska ,,Jaćwing" nawet nie ma siły zaskoczyć.
Wywala na ,,dzień dobry".
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 24 Kwietnia 2017, 13:52:04
Zobacz jesli mozesz czy w katalogu symulatora jest tez plik z "crashdump" w nazwie, i rozszerzeniem .dmp  Ale podejrzewam ze tam zwyczajnie brakuje pamieci karcie graficznej, z tego co pamietam to te wynalazki intela maja niewielka ilosc wlasna, i reszte probuja ciagnac z pamieci systemowej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 24 Kwietnia 2017, 13:58:18
Ustosunkuje się do wczytywania scenerii. Na DDS/E3D nie mam różnic/wydłużenia czasu. To o czym wspomniałem jest wynikiem dopisania sporej ilości taboru w jednej ze scenerii, w tym ciężki modeli o Queueda i w teksturach TGA. Rozmawiałem z autorem logów, który wyraził zrozumienie dla stanu rzeczy dotyczącego paczki developerskiej. Rozważyliśmy też możliwość poprawy tego stanu lokalnie na jego dysku.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mk1991 w 24 Kwietnia 2017, 14:01:07
Wrzucam drugi log. Być może się pomyliłem i wysłałem Firlejowi dwa razy to samo. To jest log z pierwszego uruchomienia.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 24 Kwietnia 2017, 14:29:56
Zobacz jesli mozesz czy w katalogu symulatora jest tez plik z "crashdump" w nazwie, i rozszerzeniem .dmp  Ale podejrzewam ze tam zwyczajnie brakuje pamieci karcie graficznej, z tego co pamietam to te wynalazki intela maja niewielka ilosc wlasna, i reszte probuja ciagnac z pamieci systemowej.
W piątek poprzednia wersja działała.. a pisałeś że praktycznie nic się poza przypisywaniem klawiszy nie zmieniło..
Ponownie na Vistę będę mógł zasiąść dopiero w środę.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 24 Kwietnia 2017, 14:49:57
Nie zmienilo sie, jesli chodzi o exe :)  Natomiast mozliwe, ze np w momencie tego ostatniego uruchamiania na komputerze dzialalo wiecej programow albo czegos tam, w porownaniu z piatkiem, i w rezultacie nie wystarczylo juz pamieci dla danych symulatora.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 24 Kwietnia 2017, 15:19:12
Różnica polega na tym, że podłączyłem Arduino, a to raczej nie obciążenie. Przyjmijmy jednak, że ma na to wpływ grafy. Aha! Ważne!. Wyskoczył mi problem Rainsted...ale treści nie pamiętam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 24 Kwietnia 2017, 15:38:02
No jesli ty nie pamietasz, to ja tym bardziej nie zgadne :x

Z innej beczki, male uaktualnienie:

- poprawka: blad odczytu parametru MaxBPMass z .fiz, wytropiony przez @youBy

- dodane do .fiz: parametr AirLeakRate w sekcji Brakes: definiuje predkosc wycieku powietrza z ukladu hamulcowego. Wartosc nominalna to 1.0 wiec np wartosc 1.5 spowoduje 50% szybszy wyciek. Tutaj uwaga: nie nalezy przesadzac ze zwiekszeniem parametru, bo wartosci rzedu 5+ moga doprowadzic do sytuacji gdzie sprezarka lokomotywy nie nadazy z produkcja. Przy standardowej wartosci 1.0 wycieki sa na poziomie zalaczania sprezarki co 5-15 min czasu symulacji, zaleznie od rodzaju i dlugosci skladu.

(zrodla powedrowaly na githuba, wiec do wgladu jest nowy system kontroli itp, dla piszacych moduly obslugi urzadzen zewnetrzych)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 24 Kwietnia 2017, 19:41:32
Ja się nie znam na wszystkich kabinach i pojazdach, jakby moja rola jest teraz ograniczona. Jeśli zaś brać pod uwagę stabilność, to x86 odpalałem kilkanaście razy, ukończyłem bez problemu Całkowo2 i Kaliską (w zasadzie jechało AI). Wycieki w osobowym urozmaicają prowadzenie, nie umiem ocenić realność tego zjawiska, z tego co piszą jest dobrze. Do zmienionego sterowania lokiem przyzwyczaiłem się szybko.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 24 Kwietnia 2017, 19:48:01
 No u mnie exe x64 wywala sie losowo bez przerwy. 2 numery wczesniej wysypow bylo mniej. Moze to przypadek. Kaliskiej ani razu nie ukonczylem od czasu naprawy w exe bocznikow.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 24 Kwietnia 2017, 20:16:56
Jeśli chodzi o wycieki powietrza, to jest świetnie. Zmiany wprowadzane do *.fiz też działają. Natomiast namieszało się trochę z WSem. Przy opuszczonych pantografach, a dokładniej przy braku napięcia zasilającego z sieci, jest teraz możliwość zaświecenia jego kontrolki przez wciśnięcie przycisku, co wcześniej nie było i nie powinno być możliwe. Ponadto kiedy już to się uda zrobić (zaświecić kontrolkę WSa przy braku napięcia z sieci), a później podniesie się pantografy, to pierwsza próba załączenia WSa nie wymaga teraz przytrzymania przez chwilę wciśniętego przycisku załączenia, ale WS "chwyta" od razu, nawet przy bardzo krótkim kliknięciu w "M". Do tego przy braku napięcia w sieci nie ma możliwości przełączenia hebelka przetwornicy, a w ukrotnionych lokomotywach sprężarki przestały załączać się i wyłączać równocześnie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 24 Kwietnia 2017, 21:59:22
Z tego co widze sprezarki nie chodza rowno bo aktywacja nastepuje bez wysylania komend do skladu, na podstawie poziomu cisnienia w ukladzie zasilajacym indywidualnego pojazdu/czlonu, a ten potrafi sie teraz ostro roznic. Pewnym rozwiazaniem jest polaczenie czlonow zoltym kablem, ktory synchronizuje poziom cisnienia w ukladzie zasilajacym czlonow. Jak to wyglada w rzeczywisosci, jesli chodzi o polaczenie i aktywacje sprezarek?

Pozostale bledy sa poprawione, beda w nastepnym uaktualnieniu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 24 Kwietnia 2017, 23:39:39
W rzeczywistości są od tego przewody sterowania wielokrotnego i w EU06, EU/EP07 i EP08 sprężarki pracują, jeśli zamknięte są styki wyłącznika ciśnieniowego w którejkolwiek z ukrotnionych lokomotyw, a w ET41 sprężarki pracują tylko wtedy, kiedy zamknięte są styki wyłączników ciśnieniowych w obu członach. Co do innych lokomotyw elektrycznych (np. ET22, ET21, EP09, EP03, EU20, 182), to sterowanie wielokrotne jest w nich teraz w ogóle mocno naciągnięte, bo nie mają one nawet gniazd do sterowania wielokrotnego, ale przynajmniej do puki nie ma multiplayera, to tak musi zostać, żeby dało się jechać dwiema naraz. Tak samo w rzeczywistości nie da się ukrotnić dwóch ET41 (w sensie łącznie czterech członów), bo też nie mają gniazd na czole. Dla EN57 i pochodnych niestety nie udało mi się znaleźć informacji na ten temat.* Jeśli chodzi o spalinowe, to tutaj też większość nie ma możliwości sterowania wielokrotnego. Z kolei w SM/SP/SU42 sprężarka pracuje bez przerwy, jeśli tylko uruchomiony jest silnik spalinowy, bo napędzana jest z wału korbowego bez żadnego sprzęgła rozłącznego. Jak jest w SP45 i SU46 będę wiedział najpóźniej w przyszłym tygodniu, bo właśnie zamówiłem sobie książkę ;) W każdym razie, jeśli już sterowanie wielokrotne jest w jakiejś elektrycznej, to albo pracują wszystkie sprężarki, albo żadna (pomijając możliwość wyłączania jakieś pojedynczej wyłącznikiem w szafce NN, ale to inna kwestia).

Przy okazji, jeśli byś mógł/miał chęci i czas, to jest jest jeszcze kilka innych błedów, a mianowicie jeśli teraz wyłączy się sprężarki hebelkiem przed osiągnięciem maksymalnego ciśnienia, to nie da się ich z powrotem załączyć, do puki ciśnienie nie spadnie do wartości samoczynnego załączenia sprężarek. Natomiast w rzeczywistości można sobie machać hebelkiem tam i z powrotem, a dopiero po osiągnięciu maksymalnego ciśnienia (po rzeczywistym zadziałaniu wyłącznika ciśnieniowego), trzeba czekać aż ono opadnie do ponownego załączenia. No i ustawienie w *.fiz parametru "MaxCP" na więcej niż 8.5 (co odpowiada nastawie wyłącznika ciśnieniowego) lub zwarcie wyłącznika ciśnieniowego sprężarek hebelkiem (którego też jeszcze nie ma ([Ctrl]+[C]?)) powinno powodować, że sprężarki pracują bez przerwy, a nadmiar powietrza, gdy ciśnienie w zbiornikach głównych jest większe nić 0,85MPa, jest wypuszczany do atmosfery przez zawór bezpieczeństwa. Błąd jest też przy sprężarce pantografów, bo w rzeczywistości, kiedy kurek przestawiony jest na zasilanie pantografów z niej, to nie ma możliwości ich samoczynnego zasilenia ze zbiorników głównych, nawet jeśli ciśnienie w nich przekroczy ciśnienie napompowane przez małą sprężarkę. Skutek jest taki, że kiedy po uruchomieniu lokomotywy zapomni się przestawić kurek z powrotem na zasilanie ze zbiorników głównych, pantografy po jakimś czasie opadną, bo powietrze z nich ucieknie na skutek nieszczelności. Teraz w MaSzynie jest natomiast jakiś magiczny zawór zwrotny, który przepuszcza powietrze ze ZG do zbiornika rozrządu z pominięciem tego kurka. Ale to tak na marginesie, jakbyś miał na to chwilę... ;)
Edit:
ale przynajmniej do puki nie ma multiplayera, to tak musi zostać, żeby dało się jechać dwiema naraz.
... albo zatrudniać do tego AI w trybie niedebugmode.
Edit2:
*Znalazłem sposób sterowania sprężarkami dla EW55 - styczniki sprężarek we wszystkich ukrotnionych zespołach sterowane są wyłącznikiem ciśnieniowym z zespołu pierwszego (sterującego). Najprawdopodobniej tak samo jest w EN57, EN71, ED72, pewnie też w EW58 i EW60.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 25 Kwietnia 2017, 00:19:36
Kojarzę, że przy wprowadzeniu kurka trójdrogowego do mastera, dobrze to działało. I jeśli nie przestawiliśmy go na zasilanie z ZG to ciśnienie w zbiorniku pomocniczym sobie spadało aż do opadnięcia pantografów.
Z pneumatyką są dziwa w pojazdach nieposiadających pneumatyki. Drezyny, samochody, tramwaj. Wszystko ma jakieś ciśnienia zainicjowane. Tramwaj nawet musiał "pompować sznurek" do podniesienia pantografu. ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 25 Kwietnia 2017, 00:49:17
*Znalazłem sposób sterowania sprężarkami dla EW55 - styczniki sprężarek we wszystkich ukrotnionych zespołach sterowane są wyłącznikiem ciśnieniowym z zespołu pierwszego (sterującego). Najprawdopodobniej tak samo jest w EN57, EN71, ED72, pewnie też w EW58 i EW60.

Zgadza się, o ile oczywiście nie przełączymy pakieciaka w szafie nn danej jednostki na rozrząd sprężarki z tablicy - ale  to jest wyjątek i póki nie ma jakiejś dokładniejszej możliwości ingerencji w obwody, to można zostawić że z pierwszego.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 25 Kwietnia 2017, 01:14:52
Witam.
 Czy coś się zmieniło w klawiszologii sterowania trąbkami EN57 na najnowszej kompilacji? W kiblu pod a/A żadnej reakcji.
 Druga sprawa, na linii 61 wersji Ra, wywaliło mnie właśnie do Windy ( exe 170424). Załączam plik crashdump, errors, oraz log. Zresztą na Całkowie V2 z cementem miałem to samo dwa razy pod rząd w tym samym miejscu.
Pozdrawiam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Kwietnia 2017, 02:51:53
Czy coś się zmieniło w klawiszologii sterowania trąbkami EN57 na najnowszej kompilacji? W kiblu pod a/A żadnej reakcji.
W logu jest wyjasnienie :)
Key pressed: [A]
en57-1051ra received command: [hornlowactivate]
Horn button is missing, or wasn't defined
@Wiggle siedzi nad dodaniem pedalow syren do kabiny, powinno przywrocic dzwiek jak skonczy.

Ten wysyp byl trafil sie przy generowaniu geometrii VBO dla toru, ale tor jest jakis dziwny, bo zerowej dlugosci. W scenerii sa takie dwa:
Bad geometry (zero length) for spline "kln_t31681g" at -2393.655000 276.037000 -1951.177000
Bad geometry (zero length) for spline "gn_t21x" at -14409.538000 256.128000 5100.738000
Sadzac po wspolrzednych, to jest ten drugi. Zobacze czy tu sie uda cos polepszyc przy unifikacji renderowania, ale to troche potrwa.

edit:
Przy okazji, jeśli byś mógł/miał chęci i czas, to jest jest jeszcze kilka innych błedów, a mianowicie jeśli teraz wyłączy się sprężarki hebelkiem przed osiągnięciem maksymalnego ciśnienia, to nie da się ich z powrotem załączyć, do puki ciśnienie nie spadnie do wartości samoczynnego załączenia sprężarek. Natomiast w rzeczywistości można sobie machać hebelkiem tam i z powrotem, a dopiero po osiągnięciu maksymalnego ciśnienia (po rzeczywistym zadziałaniu wyłącznika ciśnieniowego), trzeba czekać aż ono opadnie do ponownego załączenia.
To sie bierze z tego, ze w kodzie brak jest takiej rzeczy jak wylacznik cisnieniowy. Tzn jesli cisnienie dobije do gornej wartosci to sprezarka jest wylaczana, ale nie ma zadnego odnotowania faktu, ze wylaczenie nastapilo z powodu dojscia do limitu. Wiec sprezarka jest uruchamiana tylko ponizej wartosci minimalnej, bo inaczej przy zalaczonym przycisku chodzilaby praktycznie caly czas. Poprawienie zeby zachowywalo sie bardziej realistycznie nie powinno byc zbyt skomplikowane, przyjrze sie.

Jesli chodzi o zbiornik pantografow to nie widze u siebie magicznego napelniania -- tak dlugo jak korek trojdrogowy jest przelaczony (pozycja "|" na ekranie f3) cisnienie powoli sobie opada i pozostaje niezalezne od zbiornika glownego. Widac to na zalaczniku.

Co do sprezarek i sterowania uokrotnionego, jesli przy zalaczeniu jednej startuja wszystkie, co sie dzieje gdy jedna z nich dobije do limitu? Staje tylko ona, czy tez wszystkie?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 25 Kwietnia 2017, 10:45:10
Z tym zbiornikiem pantografów, to sprawdzę jeszcze raz, ale w ET41 miałem przebicie ze zbiorników głównych. Natomiast jeśli chodzi o wyłączanie sprężarek przy ukrotnieniu, to w EU06, EU/EP07 i EP08 muszą być rozwarte styki wyłączników ciśnieniowych we wszytkich lokomotywach, żeby sprężarki przestały pracować, w ET41 wystarczy, że rozewrze się styk jednego z dwóch wyłączników ciśnieniowych, a w EZTach sprężarki przestają pracować po rozwarciu styku wyłącznika ciśnieniowego w przednim (sterującym) EZT, ale w każdym przypadku zawsze wszystkie sprężarki załączają się i wyłączają w tym samym czasie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Kwietnia 2017, 13:11:41
Z tym zbiornikiem pantografów, to sprawdzę jeszcze raz, ale w ET41 miałem przebicie ze zbiorników głównych.
Z tego co widze w kodzie, to jest zachowanie specyficzne dla konfiguracji wieloczlonowych -- stan zbiornika pantografow jest wspoldzielony przez wszystkie czlony, a poniewaz czlon B ma swoj kurek ustawiony na polaczenie ze zbiornikiem glownym, w efekcie zbiornik pantografu w czlonie A tak jak i zbiornik w B sa pompowane sprezarka 'glowna' zalaczona w B (bo uruchamia sie ona razem ze sprezarka w A)
// przekazanie ciśnienia do sąsiedniego członu
// bo inaczej trzeba w obydwu członach przestawiać
// czy np. w ET40, ET41, ET42 pantografy członów mają połączenie pneumatyczne?
// Ra 2014-07: raczej nie - najpierw się załącza jeden człon, a potem można podnieść w drugim
Nie wiem, jak to powinno byc "realistycznie".
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 25 Kwietnia 2017, 14:51:37
W rzeczywistości nie ma przejścia pomiędzy zbiornikami pantografów dwóch członów. W praktyce wygląda to tak, że uruchamia się jeden człon i jego sprężarki główne pompują powietrze do zbiorników głównych obu członów i kiedy ciśnienie w ZG wzrośnie wystarczająco, pantografy na drugim członie same idą do góry (elektrozawory dostają zasilanie przewodem wielokrotnym w momencie podnoszenia pantografów na pierwszym członie powietrzem ze zbiornika pantografów), a można to poznać przez zaświecenie się kontrolki "wysokie napięcie II członu" na pulpicie (w miejscu, gdzie np. w EU07 jest kontrolka ogrzewania pociągu). Później wystarczy przestawić kurek trójdrogowy w pierwszym członie na zasilanie pantografów z ZG i w kabinie drugiego członu załączyć WSa lub (jeśli komuś się nie chce tam iść) można też wyłączyć i ponownie załączyć WSa w pierwszym członie, bo ponowne załączenie w pierwszym spowoduje też załączenie w drugim członie (powietrze już jest, napięcie z sieci też, więc warunki są spełnione plus oczywiście niezadziałane zabezpieczenia).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Kwietnia 2017, 15:30:15
OK, eksperymentalnie usunalem dzielenie powietrza miedzy zbiornikami i w efekcie wydaje sie to dzialac "tak jak powinno" tzn tak jak opisujesz, tylko jeszcze jedna rzecz, zebym nie musial tego dwa razy poprawiac: jesli zostawimy kurek trojdrogowy w czlonie A na pozycji sprezarki pomocniczej, i cisnienie zejdzie ponizej wymaganego minimum, czy aktywacja zabezpieczenia spowoduje wylaczenie napiecia i opadniecie pantrografow na obu czlonach, nawet jesli czlon B ma juz swoje patyki podniesione, i odpowiednie cisnienie ze zbiornika glownego?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 25 Kwietnia 2017, 16:31:55
Zadziałanie zabezpieczenia na jednym członie powoduje wyłączenie WSa tylko na tym jednym członie. Nie ma też tak, że pantografy opadają przez zadziałanie jakiegoś zabezpieczenia z powodu zbyt niskiego ciśnienia, ale z powodu tego, że ciśnienie w cylindrach pantografów jest zbyt małe, żeby utrzymać je w pozycji podniesionej. Ciąg przyczynowo skutkowy jest taki, że spadek ciśnienia powoduje po pierwsze opadnięcie pantografów, a po drugie chwilę przed tym zadziałanie wyłącznika ciśnieniowego pantografów, który to z reguły jako pierwsze zabezpieczenie w takiej sytuacji wyłącza wyłącznik szybki, ale zawsze tylko na konkretnym członie. Drugim zabezpieczeniem jest przekaźnik zanikowo-napięciowy, który wyłącza WSa w przypadku zaniku lub zbyt niskiego napięcia z sieci i jako że otwiera się (puszcza zworę) dopiero po oderwaniu się ślizgów pantografów od przewodu jezdnego (wspominana już też przeze mnie zwłoka czasowa między np. zamierzonym opuszczeniem pantografów a rozpoczęciem ich opadania dopiero po zmniejszeniu się ciśnienia w cylindrach napędowych), to dlatego w rzeczywistości ten przekaźnik działa z reguły dopiero jako drugi po wyłączniku ciśnieniowym pantografów. Tak samo z powodu braku piaskowania w tylnym członie dosyć często zdarza mi się na wystawach z pulpitem "rozbiegnięcie" silników w drugim członie przez jego poślizg i wtedy WS wyłącza się też tylko w tym członie. Jak się trochę pokombinuje, to da się nawet wyzwolić (mówię o MaSzynie) przekaźnik nadmiarowy przetwornicy w jednym członie, co też spowoduje wyłączenie WSa tylko w tym członie i jest to prawidłowe.
Wydaje mi się też, że wydajność sprężarki pantografów jest co najmniej 2-3 razy za duża, ale ja mam doświadczenie tylko z dwóch egzemplarzy lokomotyw, więc tutaj musieliby się wypowiedzieć maszyniści. Dla łatwego sprawdzenia na TD: Rainsted -> zakładka Składy -> Nastawy hamulca -> zaznaczyć "Q bez powietrza" (lokomotywa uruchomi się z 0MPa w ZG).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Mariusz1970 w 25 Kwietnia 2017, 16:53:36
Jesli chodzi o tory 0 dlugosci, to tutaj moja uwaga, ze ostroznie z nimi tj z usuwaniem nich. Jesli autor scenerii bedzie mial uklad torowoy, iz jeden switch styka sie bezporsednio z innym switchem, to wymagany jest tor pomiedzy nimi, nawet o zerowej dlugosci. Jesli tego toru nie bedzie, zrobi sie null track. Chociaz juz chyba w sceneriach, tego typu konstrukcji jest coraz mniej, jednak trzeba miec to na uwadze. Raczej watpie, aby w exe w tym wzgledzie Ra badz ktos inny, usunal ten wymog. Wiec w errors nie jest sytuacja jednoznaczna, bo wypisuje cos, co exe traktuje jako blad, a to akurat jest niezbedne. Dobrze byloby to w exe dla pewnosci sprawdzic (czy jeszcze jest ten wymog).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 25 Kwietnia 2017, 16:57:29
Potwierdzam, że było kiedyś coś takiego - jeżeli łączyło się rozjazd z rozjazdem, to (poprzez najechanie na to?) generował się nulltrack i wysypka.

PS. Niezłą masz pamięć :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 25 Kwietnia 2017, 17:04:02
Ja pamiętałem, że między rozjazdami należało wstawić odcinek toru, ale nie zerowy. Choćby centymetr. Wydawało mi się za to, że było narzędzie do znajdowania/usuwania zerowych wpisów torów i także duplikatów.Kto wie, czy te wysypy nie mają z tym coś wspólnego.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Kwietnia 2017, 17:35:38
Zerowych torow raczej nie bedzie sie usuwac, bo problem jest przy generowaniu geometrii do ich wizualizacji, a nie z samymi torami. Wiec tutaj spokojnie :)

Zadziałanie zabezpieczenia na jednym członie powoduje wyłączenie WSa tylko na tym jednym członie. Nie ma też tak, że pantografy opadają przez zadziałanie jakiegoś zabezpieczenia z powodu zbyt niskiego ciśnienia, ale z powodu tego, że ciśnienie w cylindrach pantografów jest zbyt małe, żeby utrzymać je w pozycji podniesionej. Ciąg przyczynowo skutkowy jest taki, że spadek ciśnienia powoduje po pierwsze opadnięcie pantografów, a po drugie chwilę przed tym zadziałanie wyłącznika ciśnieniowego pantografów, który to z reguły jako pierwsze zabezpieczenie w takiej sytuacji wyłącza wyłącznik szybki, ale zawsze tylko na konkretnym członie. Drugim zabezpieczeniem jest przekaźnik zanikowo-napięciowy, który wyłącza WSa w przypadku zaniku lub zbyt niskiego napięcia z sieci i jako że otwiera się (puszcza zworę) dopiero po oderwaniu się ślizgów pantografów od przewodu jezdnego (wspominana już też przeze mnie zwłoka czasowa między np. zamierzonym opuszczeniem pantografów a rozpoczęciem ich opadania dopiero po zmniejszeniu się ciśnienia w cylindrach napędowych), to dlatego w rzeczywistości ten przekaźnik działa z reguły dopiero jako drugi po wyłączniku ciśnieniowym pantografów.
W tej chwili (po zmianie zachowania pantografow zeby opadaly indywidualnie na pojezdzie) wyglada to tak, ze gdy w czlonie A zejdzie cisnienie w zbiorniku pantografu, patyki na tym czlonie opadaja, ale czlon pracuje dalej bo otrzymuje wysokie napiecie przewodami z czlonu B, w ktorym wszystko dziala. Jesli dobrze rozumiem, to przy opadnieciu patykow na A powinno tam wywalic WS (i tylko tam), bez wzgledu na to czy B jest ok czy nie?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 25 Kwietnia 2017, 18:00:47
Pamiętaj że ET42 i niektóre ET40 mają po jednym pantografie na człon, by nie zrobić czegoś nazbyt uniwersalnego. Podobnie wiele EZT ma zasilanie z jednego członu i WN na całym składzie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Mariusz1970 w 25 Kwietnia 2017, 18:48:36
Atapi, tak, po najechaniu. Krzysiek, bylo dokladnie tak, jak napisalem. Duplikaty nie maja tu znaczenia. Bylo rowniez narzedzie, ktore generowalo tory, nawet zerowe, jesli torow pomiedzy switchami nie bylo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 25 Kwietnia 2017, 18:51:45
Jesli dobrze rozumiem, to przy opadnieciu patykow na A powinno tam wywalic WS (i tylko tam), bez wzgledu na to czy B jest ok czy nie?
Tak, ale to trzeba uzależnić jeszcze o ustawionego pomiędzy członami sprzęgu. Jeśli nie ma pomiędzy członami ustawionego sprzęgu wysokiego napięcia ("+8"), to tak, bo tak jak pisze Stele, np. ET42 czy też ED72 mają ustawione takie sprzęgi pomiędzy członami, żeby właśnie było przejście wysokiego napięcia, ponieważ mają tylko po jednym pantografie na człon. W takich pojazdach pantograf może opaść, ale WS musi dalej trzymać.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Kwietnia 2017, 18:58:33
Zaraz, zaraz, bo ja juz sie gubic zaczynam :x  Czyli ok, jesli jest kabel wysokiego napiecia miedzy czlonami to WS trzyma nawet po opadnieciu. Czy to znaczy ze ET41 tez powinien trzymac w takiej sytuacji, czy w ich przypadku kalbi wysokiego napiecia sie nie stosuje? Bo ja sobie tutaj testuje z takim wlasnie zestawem spietym tymi kablami, ale nie pamietam czy tak juz bylo w scenariuszu, czy to zmienilem...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 25 Kwietnia 2017, 19:01:30
ET41 nie ma sprzęgu WN między członami
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 25 Kwietnia 2017, 19:02:09
Kable WN w sprzęgu pomiędzy członami ustawia się tylko w takich lokomotywach i EZT, które mają po jednym pantografie na człon. Jeśli są dwa pantografy na członie, to kabli/sprzęgu WN pomiędzy nimi nie można dawać, bo i w rzeczywistości ich nie ma w takich pojazdach.
Edit: youBy mnie ubiegł...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 25 Kwietnia 2017, 19:02:38
Mariusz, nie zaprzeczam temu co napisałeś, ale te tory między switchami było widać w STV a zerowych nie widać, a przynajmniej nie można je zaznaczyć. Ta moda na wstawianie zerowych niekoniecznie od początku była.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Mariusz1970 w 25 Kwietnia 2017, 19:09:19
STV, to inna bajka i nie mieszajmy. Natomiast to nie byla moda, tylko tak MUSI byc. Chcesz jeszcze 1000 postow napisac, zamiast sprawdzic? Wez dwie zwrotnice polacz tak, aby stykaly sie powiedzmy punktami p3 i raz bez tego toru, drugi raz z torem. Test w ciagu paru minut wyjasni jak jest.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 25 Kwietnia 2017, 19:18:52
Mariusz, nie zaprzeczam temu co napisałeś, ale ...
Tak 1000, nie podważam konieczności wstawiania odcinka między switchami. Ile razy mam to napisać? ;)
STV nie jest inna bajka, można właśnie było diagnozować braki w torach. Jak chcesz się dalej spierać, to zapraszam na PW lub telefon. ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Mariusz1970 w 25 Kwietnia 2017, 19:26:51
No inna bajka, bo jesli autor STV nie dal mozliwosci zaznaczania torow 0 to co z tego wynika dla dzialania symka? Natomiast mozesz napisac jeszcze pare razy, bo jakie masz stanowisko to nie wiem. piszesz, ze nie kwestionujesz, tego co ja napisalem o 0 dlugosci (bo t sie roznimy), pozniej jednak piszesz, ze wydaje Ci sie, ze tor musi miec niezerowa dlugosc. postaram sie w ciagu pol godziny wystawic testowa scenerie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Kwietnia 2017, 19:36:43
ET41 nie ma sprzęgu WN między członami
Hmm no to wylazi tutaj inny problem, bo w tej chwili przy podniesieniu pantografow 'recznie' na czlonie A pompowanie w ET41 zbiornika glownego w czlonie B dziala tylko w sytuacji gdy przetwornica i sprezarka czlonu B moga wystartowac dzieki zasilaniu przewodami WN, i generowac powietrze lokalnie. Jesli nie ma kabli WN to calosc musi byc napelniona sprezarka czlonu A (czyli tak jak "naprawde") ale tu z kolei bez podpiecia zoltych kabli powietrze nie przechodzi. Czy dobrze rozumiem, ze w rzeczywistosci to powietrze idzie jakims specyficznym wariantem tego, co w symulatorze jest traktowane jako 'sprzeg uokrotnienia) (+4) czy jeszcze jakos inaczej?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 25 Kwietnia 2017, 19:53:40
Bo te "żółte kable", czyli sprzęg "+32 Powietrze 8 atm" też mają być spięte pomiędzy członami, ponieważ łączą właśnie zbiorniki główne dwóch członów. Tak jest w rzeczywistości i tak ma być też ustawiony sprzęg w MaSzynie. Pomiędzy członami ET41 są w rzeczywistości w sumie trzy przewody pneumatyczne: ww. przewód zasilający prosto ze zbiorników głównych, przewód hamulcowy i przewód hamulca dodatkowego. Wszystkie one obecnie działają w MaSzynie. Ten żółty wykorzystuje się też do zasilania niektórych wagonów, które tego wymagają, bo jest też wyprowadzony na czole lokomotywy.
calosc musi byc napelniona sprezarka czlonu A
I tak jest prawidłowo. Ew. można sobie uruchamiać ręcznie dwa człony jednocześnie, ale tak chyba nikt nie robi ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Mariusz1970 w 25 Kwietnia 2017, 20:14:39
Wystawiam do testu.
Proszę przejechać  około 40m. Chodzi o odcinek  Sianowice  zwr 09 i11. Następnie zaremować tor, ktory ma zerową długość i sprawdzić ponownie. Mój test potwierdza to co napisalem (na zabytkowym exe 664). Kiedyś sprawdzałem jakiś już wysoki nr exe od Ra i było to samo.
prosze zwrócić uwagę, aby jechać w odpowiednią stronę.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Kwietnia 2017, 20:39:24
Bo te "żółte kable", czyli sprzęg "+32 Powietrze 8 atm" też mają być spięte pomiędzy członami, ponieważ łączą właśnie zbiorniki główne dwóch członów. Tak jest w rzeczywistości i tak ma być też ustawiony sprzęg w MaSzynie.
No zesz kobieta pracujaca....
Pytalem sie przeciez wlasnie wczoraj chyba
Cytuj
Pewnym rozwiazaniem jest polaczenie czlonow zoltym kablem, ktory synchronizuje poziom cisnienia w ukladzie zasilajacym czlonow. Jak to wyglada w rzeczywisosci, jesli chodzi o polaczenie i aktywacje sprezarek?
i dostalem w odpowiedzi
Cytuj
W rzeczywistości są od tego przewody sterowania wielokrotnego (..)
Rozumiem teraz, ze ta odpowiedz dotyczyla czegos innego (aktywacja sprezarek w ukladzie uokrotnionym) ale wyszlo nieporozumienie, bo wywnioskowalem z tego ze zoltego przewodu nie uzywaja :P

Na ile moge stwierdzic na szybko, przy spieciu zoltymi przewodami ET41 zachowuje sie jak trzeba, ale musze jeszcze sprawdzic pare pozostalych wariantow. Dla pewnosi, ET42 tez uzywa zoltego przewodu w polaczeniu czlonow? Bo ze uzywa tych od wysokiego napiecia to juz wiem ;d
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 25 Kwietnia 2017, 20:48:57
Przepraszam za nieporozumienie :/ Miałem wtedy na myśli, że połączenie tym żółtym przewodem nie jest wystarczającym rozwiązaniem, ale tak się skupiłem na sterowaniu sprężarkami, że w końcu tego nie napisałem... A co do ET42, to ogólnie między wszystkimi ukrotnionymi pojazdami musi być połączenie tym przewodem, więc w ET42 też.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: matek123 w 25 Kwietnia 2017, 21:09:18
Czy przy okazji da się dodać flagę przewodów hamulca dodatkowego? Występują na pewno w ET41.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 25 Kwietnia 2017, 21:19:51
Flagi nam się już kończą…;)
Na chwilę obecną przewód hamulca dodatkowego działą dla pojazdów Type=ET41 i Type=ET42 po połączeniu węży zasilających i przewodów sterowania wielokrotnego (razem +36).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Kwietnia 2017, 21:22:49
Przepraszam za nieporozumienie :/ Miałem wtedy na myśli, że połączenie tym żółtym przewodem nie jest wystarczającym rozwiązaniem, ale tak się skupiłem na sterowaniu sprężarkami, że w końcu tego nie napisałem... A co do ET42, to ogólnie między wszystkimi ukrotnionymi pojazdami musi być połączenie tym przewodem, więc w ET42 też.
Nic sie nie stalo, moglem sie dla pewnosci dopytac ;o  A propos dopytywania, jak wyglada w zestawach wieloczlonowych rozlaczanie wylacznika szybkiego w przypadku gdy pojazd ma wylaczona baterie i przetwornice? Tzn czy rozlaczenie nastepuje w calym skladzie, czy tylko w czlonie gdzie wylaczone sa urzadzenia?

A co do innych typow przewodow to faktycznie trzeba je bedzie chyba na bitset przerobic, albo przynajmniej doczepic nastepny bajt :s
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 25 Kwietnia 2017, 21:30:17
I dodać dla gracza możliwość ustawiania wybranych bitów podczas symulacji a nie kolejnych. Jak to działa obecnie, gdy w fiz zabroniony jest powiedzmy czwarty bit a piąty dozwolony, gdy tłuczemy insert?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Kwietnia 2017, 21:34:22
Na teraz to idzie po kolei hak, hamulec, zasilanie, ukrotnienie i mostek. Jesli pojazd ma ustawiona flage ze pozwala na takie polaczenie to laczy, a jak nie to olewa i probuje nastepny typ az mu sie lista skonczy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: fuji8 w 25 Kwietnia 2017, 21:37:00
Skoro jesteśmy przy ukrotnieniu, to zgłaszam że nie działa ukrotnienie w stonkach, mianowicie podłączyłem sp42 i sm42 krótkimi nosami do siebie i ni w sposób żeby przejść do drugiego loka.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 25 Kwietnia 2017, 21:37:42
To chyba wszystko powinno się łączyć poprawnie przy obecnym sposobie, jeśli nie ma błędów w dozwolonych flagach.
Stonki nie maja mostka, więc bardzo dobrze, że nie da się przejść. Tak ma być.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 25 Kwietnia 2017, 21:38:09
Poza ukrotnieniem daj mostek. Jakti nie maja mostka? A przez pomosty? Ups ok nie przejdzie nie ma dzrzwi z budki na pomost. Ale to jak ma w symku przejsc? Przez f5?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Kwietnia 2017, 21:39:35
No nie zadziala bo w .fiz jest
AllowedFlag=103
Czyli stonki pozwalaja podpiac tylko hak, hamulec, ukrotnienie, zasilanie i ogrzewanie (1+2+4+32+64)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: fuji8 w 25 Kwietnia 2017, 21:40:41
Jest mostek, ale skoro nie da się, ponieważ jedno i drugie nie ma mostka, to trzeba znaleźć rozwiązanie, aby można było dostać się do drugiego loka mimo to.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 25 Kwietnia 2017, 21:41:23
F5 nie łapie na nobody?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Kwietnia 2017, 21:43:09
No na upartego jesli potraktowac pomosty jako odpowiednik mostka to mozesz dodac +16 do .fiz w AllowedFlag i pojdzie.

edit:
F5 nie łapie na nobody?
Nie wiem o co chodzi :D ale F5 musi praktycznie stac w miejscu zeby sie zalapac, chyba ze jest wlaczony debug mode.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 25 Kwietnia 2017, 21:43:40
Nie lapie. A pizatym ai przejmuje loka z tylu. I w efekcie jest 2 mechanikow.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 25 Kwietnia 2017, 21:46:21
Tmj jesli pojazd jest jako nobody to nie da sie do niego wejsc. Nozna wejsc tylko do head i reardriver oraz passenger. Ale po przejsciu pijazd opuszczany jest z automatu obsadzany mechanikiem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 25 Kwietnia 2017, 21:46:43
No nikt nie zmienia pojazdu podczas jazdy ukrotnionej w biegu, zwłaszcza gdy trzeba się bujać na poręczach jak to stonkowatych.
Skoro nie łapie i są problemy, to raczej trzeba pomyśleć o wyjątkach dla pojazdów ukrotnionych, a nie wracać do prowizorycznych mostków. Po to ta blokada była, by nikt nie wpadał do wagonu od tłuczenia enda.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: pat w 25 Kwietnia 2017, 21:47:39
A czy przypadkiem ustawienie zaworu na odcięcie nie dezaktywuje AI?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 25 Kwietnia 2017, 21:52:15
Przy sprzęganiu dwóch aktywnych pojazdów. Wysiadka wstawia AI do opuszczanego zawsze niestety. Wadzi to też w scenariuszach gdzie opuszczamy skład przy przesiadce, bo ai go ponownie uruchomi.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 25 Kwietnia 2017, 21:52:36
jak wyglada w zestawach wieloczlonowych rozlaczanie wylacznika szybkiego w przypadku gdy pojazd ma wylaczona baterie i przetwornice? Tzn czy rozlaczenie nastepuje w calym skladzie, czy tylko w czlonie gdzie wylaczone sa urzadzenia?
W lokomotywach dwuczłonowych, to w ogóle powinno się załączać baterię osobno w każdym członie, bo tak jest w rzeczywistości, więc wyłączenie przetwornic i baterii w jednym członie powinno powodować wyłączenie WSa i innych urządzeń (w tym opadnięcie pantografów) też tylko w jednym członie. W EN57 z kolei bateria i jej włącznik znajdują się w członie Rb i zasilają urządzenia w całej jednostce, prawdopodobnie podobnie jest w innych EZT. Przetwornica jest też tylko jedna i umieszczona w wagonie silnikowym. Nie wiem natomiast ile jest przetwornic w EZT z dwoma wagonami silnikowymi (np. EN71, ED72), ale nawet jeśli są dwie, to w normalnych warunkach i tak pewnie sterowane tylko jednocześnie. W EZTach więc wyłączenie przetwornic(y) i baterii będzie powodowało wyłączenie wszystkich WSów (taki EN57 ma ich jakby 4 ;) ). Na ET41 natomiast jeszcze taka ciekawostka co do zasilania jednego członu z drugiego, ale bez możliwości podparcia stycznika SZ1 w drugim członie to nie będzie działać...:

Efekt daje taki, że przy odhamowanej lokomotywie w członie A w tym przypadku można by wyłączyć baterię i zasilanie dalej by było z członu B. Dokładniej jest to opisane w opisie pod filmem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 25 Kwietnia 2017, 22:26:01
Wydaje mi się, że mostki i możliwość przechodzenia między ukrotnionymi pojazdami działają inaczej, jeżeli pojazd jest wstawiany do scenerii od razu z ukrotnieniem i jeżeli jest dopiero łączony w trakcie misji. W pierwszym przypadku przy wpisach headdriver 55 w pierwszym pojeździe i nobody w drugim nie przypominam sobie problemów z przechodzeniem między lokami. Trzeba tylko pamiętać o SHIFT+W po przejściu, żeby zdezaktywować czuwak w drugim pojeździe. Ale faktycznie, jeżeli byśmy się rozpięli i próbowali potem spiąć ponownie to niestety to już raczej nie zadziała.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 25 Kwietnia 2017, 22:34:30
Trainset ignoruje blokady flag w fiz. Shift+W zostało wyłączone z dwa lata temu o ile wiem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 25 Kwietnia 2017, 22:49:44
Aktywacja czuwaka z [Shift]+[W] jest przeniesiona pod nastawnik kierunkowy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Kwietnia 2017, 23:46:53
OK, wysoce eksperymentalne uaktualnienie:

- poprawka, wylacznik szybki w lokomotywach elektrycznych da sie zamknac tylko przy doplywie pradu z sieci
(na marginesie, mozna by to latwo rozbudowac takze dla lokomotyw spalinowych itp, gdzie przyciski O i P sa dosc czesto przypisane do pompy paliwa i oleju itp. chociaz jak na razie to bylaby tylko "sztuka dla sztuki" bo tych elementow chyba nie ma symulowanych?)

- poprawka, przelacznikiem przetwornicy mozna sobie machac takze przy braku napiecia, chociaz oczywiscie nic to nie daje :d

- poprawka/eksperyment, zbiorniki powietrza dla pantografow w zestawach uokrotnionych sa od siebie niezalezne

- dodany pseudo wylacznik cisnieniowy: w praktyce oznacza to ze sprezarka mozna sie bawic do momentu osiagniecia 'cisnienia krytycznego', dopiero gdy to nastapi sprezarka przestaje pracowac dopoki cisnienie nie spadnie ponizej dopuszczalnego minimum

- poprawka/eksperyment, 'wylacznik cisnieniowy' pantografow otwiera wylacznik szybki tylko w czlonie w ktorym faktycznie spadlo cisnienie (oprocz EZT)

- poprawka/eksperyment, 'wylacznik cisnieniowy' pantografow nie wybije wylacznika szybkiego w czlonie ktory otrzymuje zasilanie kablem/sprzegiem wysokiego napiecia

- poprawka/eksperyment, wylaczenie baterii i przetwornicy powoduje otwarcie wylacznika szybkiego tylko w czlonie w ktorym mialo to miejsce (oprocz EZT)

- poprawka(?), reflektory itp dzialaja takze po odlaczeniu baterii, o ile pracuje przetwornica

Tutaj uwaga: symulator radzi sobie srednio z przechodzeniem miedzy czlonami, i lazenie miedzy nimi moze miec nieciekawe efekty uboczne w trakcie "prototypowego" rozruchu jednostek dwuczlonowych. Najbezpieczniej jest nie wchodzic do czlonu B dopoki cisnienie w ukladzie glownym nie osiagnie minimalnego poziomu dla podniesienia pantografow, i trzeba pamietac o wylaczenia sprezarki zanim sprobuje sie zalaczyc wylacznik szybki dla czlonu B, bo wczesniejsza aktywacja prztwornicy i sprezarki w czlonie A 'zdalnie' ustawia do pracy obie rowniez w czlonie B, wiec po zamknieciu wylacznika szybkiego ma szanse wyleciec nadmiarowy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 25 Kwietnia 2017, 23:50:31
W EN57 z kolei bateria i jej włącznik znajdują się w członie Rb i zasilają urządzenia w całej jednostce, prawdopodobnie podobnie jest w innych EZT. Przetwornica jest też tylko jedna i umieszczona w wagonie silnikowym. Nie wiem natomiast ile jest przetwornic w EZT z dwoma wagonami silnikowymi (np. EN71, ED72), ale nawet jeśli są dwie, to w normalnych warunkach i tak pewnie sterowane tylko jednocześnie. W EZTach więc wyłączenie przetwornic(y) i baterii będzie powodowało wyłączenie wszystkich WSów (taki EN57 ma ich jakby 4 ;) ).

Jeżeli mowa o oporowych EN57, to odłącznik baterii jest w szafie nn w wagonie silnikowym. Poza tym spotkać klasyczny WS złożony z czterech styczników to już graniczy z cudem (no dobra, przynajmniej w Warszawie). Przy okazji rewizji już od wielu lat wymieniane były na próżniowe (najczęściej DCU, rzadziej Secheron). Co do wyłączania WSa i definicji składu - jeżeli mowa o jednym EZT, no to wiadomo - wyłączenie przetwornicy i baterii powoduje wyłączenie WSa na tym ezecie, WS nie ma zasilania. Natomiast jeżeli skład to kilka ezetów i mowa o wyłączeniu przetwornicy i baterii w jednym z nich, to WS wyłączy się tylko w tym jednym.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 25 Kwietnia 2017, 23:57:15
No widzisz, w kwestii EN57 mam do dyspozycji tylko teorię z książek, dosyć przestarzałych, czyli tak, jak to było "fabrycznie"...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 26 Kwietnia 2017, 00:01:05
Ale tak jest od oryginalności (jeżeli o odłącznik baterii chodzi) :) Przy baterii akumulatorów są tylko bezpieczniki oraz (już też nie zawsze) przełącznik do ładowania z zewnątrz wraz z gniazdem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Kwietnia 2017, 00:23:37
Uaktualnienie do uaktualnienia, bo z rozpedu udalo mi sie ustwic w exe efekt dokladnie przeciwny do zamierzonego, tzn spadek cisnienia zamiast zrzucac patyki tylko w danym czlonie dla pojazdow innych niz EZT robil to dla wszystkich oprocz EZT ;/
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 26 Kwietnia 2017, 09:02:36
Ja tylko powiem jak idzie tabelka. Powoli udaje się dojść do ładu i składu z tym wszystkim. AI zaczyna powoli jeździć tak jak do tej pory. Jeszcze mam problem na zwrotnicach, ale muszę najpierw rozkminić w jaki sposób było to zrobione poprzednio bo cosik zmaściłem i teraz wykrywa mi mój własny pojazd na zwrotnicy jako obcy. Za to eventy wstępnie działają jak trzeba.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 26 Kwietnia 2017, 10:03:28
A mi na Viście już wszystko się wysypało. Kod wskazuje że to nie jest wina karty graficznej, tylko coś z pantografem.
----------------------------------------------------------------------------------------------------------------------------------------------------
Dobra! Mój błąd! Wgrałem MaSzynę jeszcze raz i gra i buczy. Uwaga nieaktualna!
----------------------------------------------------------------------------------------------------------------------------------------------------
A jednak wywala mnie na cegielskim w Kaliskiej.
Dostaję taki oto komunikat:
http://eu07.pl/userfiles/4746/foto-rainsted.jpg (http://eu07.pl/userfiles/4746/foto-rainsted.jpg)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 26 Kwietnia 2017, 11:46:01
Na karcie intela chcesz multisampling x16? Nie da rady. Chodzi mi o ten dłuższy plik log.txt
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 26 Kwietnia 2017, 12:13:41
Mój błąd. Zmieniłem jednak na x1 i nadal błąd wyskakuje.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Kwietnia 2017, 12:32:08
Dobra! Mój błąd! Wgrałem MaSzynę jeszcze raz i gra i buczy. Uwaga nieaktualna!
To w koncu jak jest, wyskakuje nadal blad, czy wszystko gra i buczy i to juz nieaktualne?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 26 Kwietnia 2017, 12:37:44
Znalezione w sieci:
Cytuj
Wycinek z supportu:

 "For more stable performance using a 32-bit version of windows vista, 7,8,8.1, or windows 10 operating system, we recommend activating the memory expansion function by running the Enable3GBMem_Vista_Win7_32bit.bat file in the game installation folder. Activating this function will..."

Probably fix the problem so lets get to it.
Podano również link. @tmj, odniesiesz się do tego?
http://www.appcrash.org/
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 26 Kwietnia 2017, 12:48:49
Całkowo v2 chodzi i to jak burza. Może to coś na tym cegielskim jest nie teges. Jak na razie tylko na tej misji wyskakuje błąd.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 26 Kwietnia 2017, 13:08:38
Z tego co widzę utyka na zaesach. Wywal kontrolnie te wagony z całej scenerii. Wiem że dużo roboty, ale... no ja bym spróbował.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 26 Kwietnia 2017, 13:21:18
Prawdopodobnie masz rację Krzysiu.
Pozmieniałem na razie tylko w starterze co nieco, ale nadał błąd. Tym razem Vista się wysiliła i dała mi taką informację:
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: matek123 w 26 Kwietnia 2017, 13:33:51
EU40, możesz sobie uruchomić bez cystern? Jak się odpali, to możesz skopiować ten skład na TD. Jak się wysypie, to mógłbyś wtedy przez rainsted wstawić?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Kwietnia 2017, 13:38:14
Znalezione w sieci:
Podano również link. @tmj, odniesiesz się do tego?
Z tego co mi mowi google to ten .bat jest specyficznie dla Blade & Soul. Maszynowe exe ma od dluzszego czasu wlaczona obsluge 3gb na systemach 32-bitowych, bo bez tego Kaliska i inne wieksze scenerie w wersji developerskiej na x86 w ogole nie wchodzily :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 26 Kwietnia 2017, 13:55:49
Nie wchodzi na kaliskiej tylko misja cegielski. Chyba duża racja z tymi beczkami.
Tylko że , gdy je wywaliłem, wraz w logu występowały.
Hmmm. Pokombinuję.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 26 Kwietnia 2017, 21:46:02
- poprawka, przelacznikiem przetwornicy mozna sobie machac takze przy braku napiecia, chociaz oczywiscie nic to nie daje :d
- poprawka/eksperyment, zbiorniki powietrza dla pantografow w zestawach uokrotnionych sa od siebie niezalezne
- dodany pseudo wylacznik cisnieniowy: w praktyce oznacza to ze sprezarka mozna sie bawic do momentu osiagniecia 'cisnienia krytycznego', dopiero gdy to nastapi sprezarka przestaje pracowac dopoki cisnienie nie spadnie ponizej dopuszczalnego minimum
- poprawka/eksperyment, 'wylacznik cisnieniowy' pantografow nie wybije wylacznika szybkiego w czlonie ktory otrzymuje zasilanie kablem/sprzegiem wysokiego napiecia
- poprawka(?), reflektory itp dzialaja takze po odlaczeniu baterii, o ile pracuje przetwornica
Te działają poprawnie. Teraz ładnie też widać różnicę w prędkości podnoszenia pantografów przy różnym ciśnieniu ich zasilania w obu członach (zał. 1.). Co do reflektorów, to taki sam efekt powinien być ogólnie dla wszystkich obwodów (w tym też oświetlenie przyrządów i kabiny), bo w rzeczywistości wyłącznik baterii i przetwornica podają napięcie na dokładnie ten sam przewód.
- poprawka, wylacznik szybki w lokomotywach elektrycznych da sie zamknac tylko przy doplywie pradu z sieci
To nie do końca, bo po opuszczeniu pantografów jeszcze przez kilka chwil da się zaświecić kontrolkę WSa. Tak samo kiedy zadziała nadmiarowy przetwornicy też da się zaświecić kontrolkę WSa, choć powinno to być (i kiedyś było) niemożliwe.
- poprawka/eksperyment, wylaczenie baterii i przetwornicy powoduje otwarcie wylacznika szybkiego tylko w czlonie w ktorym mialo to miejsce (oprocz EZT)
Nie ma możliwości wyłączenia i załączenia baterii tylko w jednym członie, więc nie mam jak tego sprawdzić.
- poprawka/eksperyment, 'wylacznik cisnieniowy' pantografow otwiera wylacznik szybki tylko w czlonie w ktorym faktycznie spadlo cisnienie (oprocz EZT)
Niestety, WS nadal otwiera się w obu członach (tak, sprawdzałem na exe "b").
Tutaj uwaga: symulator radzi sobie srednio z przechodzeniem miedzy czlonami, i lazenie miedzy nimi moze miec nieciekawe efekty uboczne w trakcie "prototypowego" rozruchu jednostek dwuczlonowych. Najbezpieczniej jest nie wchodzic do czlonu B dopoki cisnienie w ukladzie glownym nie osiagnie minimalnego poziomu dla podniesienia pantografow, i trzeba pamietac o wylaczenia sprezarki zanim sprobuje sie zalaczyc wylacznik szybki dla czlonu B, bo wczesniejsza aktywacja prztwornicy i sprezarki w czlonie A 'zdalnie' ustawia do pracy obie rowniez w czlonie B, wiec po zamknieciu wylacznika szybkiego ma szanse wyleciec nadmiarowy.
Potwierdzam całość. Natomiast zauważyłem jeszcze inny problem. Który parametr spod F3 pokazuje wartość ciśnienia w zbiornikach głównych? Myślałem, że ten podkreślony na czerwono (zał. 2.), ale wychodzi na to, że on pokazuje wartość ciśnienia w przewodzie głównym zasilającym (tym "żółtym"), co jak się okazało (widać po manometrze) nie jest równoznaczne z ciśnieniem w zbiornikach. Przy uruchamianiu ET41 z członu A jego sprężarki pompują powietrze tylko do jego zbiorników, więc wychodzi na to, że jest przelot powietrza ze zbiorników do przewodu, ale w drugą stronę (z przewodu głównego zasilającego do zbiorników głównych) już nie ma, choć powinien być. Widać to też po tym, że przy uruchamianiu sprężarki pracują dalej przez tak samo długi czas jak poprzednio, chociaż pracują tylko na jednym członie (jest ich o połowę mniej), więc napełnianie wszystkich zbiorników powinno im zająć raz więcej czasu. Do tego po załączeniu WSa, przetwornicy i hebelka sprężarek w członie B, sprężarki w nim uruchamiają się i dopiero pompują powietrze do zbiorników, które już właśnie powinny być napełnione z przewodu głównego zasilającego.

Jest jeszcze taki błąd, że kiedy pantograf opadnie z powodu zbyt niskiego ciśnienia i przejdzie się do przedziału maszynowego dopompować powietrza małą sprężarką lub przestawi kurek na zasilanie z ZG, to pantograf po zwiększeniu ciśnienia zasilania powinien z powrotem sam podnieść się do góry, a tak się nie dzieje. Trzeba go hebelkiem jakby opuścić i dopiero ponownie podnieść.

Edit: EZeTy dopiero sprawdzam...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 26 Kwietnia 2017, 22:10:19
eksperymentalnie wrzuciłem wersję z nowymi shaderami: http://eu07.pl/forum/index.php/topic,28920.msg451808.html#msg451808
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Kwietnia 2017, 22:29:11
Natomiast zauważyłem jeszcze inny problem. Który parametr spod F3 pokazuje wartość ciśnienia w zbiornikach głównych? Myślałem, że ten podkreślony na czerwono (zał. 2.), ale wychodzi na to, że on pokazuje wartość ciśnienia w przewodzie głównym
To w czerwonym kolku to jest cisnienie w zbiorniku pantografow dla danego pojazdu :)  Jesli miedzy liczba a napisem ZG jest znak "<" to oznacza kurek trojdrogowy w pozycji laczacej zbiornik pantografow z przewodem glownym, natomiast pionowa linia "|" oznacza ich rozdzielenie (powietrze bedzie dostarczane ze sprezarki pantografow)

Cisnienie w zbiorniku glownym jest podane na ekranie F1 dostepnym w debug mode. Wydaje mi sie ze powinno byc rowne z cisnieniem w przewodzie zasilajacym, ktory jest podany na ekranie F3 jako druga liczba w sekcji "PP:" w dolnej linii (pierwsza liczba w tej sekcji to cisnienie w przewodzie hamulcowym) Zapewne trzeba by pomyslec o umieszczeniu tej wartosci takze pod F3 zeby nie trzeba bylo przelaczac w te i we wte.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 26 Kwietnia 2017, 22:35:37
Myślałem, że ten podkreślony na czerwono (zał. 2.),
;) Tak jak napisałem, powietrze powinno przepływać nie tylko ze zbiorników głównych do przewodu głównego zasilającego, ale też w drugą stronę, a tak się nie dzieje.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Kwietnia 2017, 22:56:44
xD zapomnialem ze to mial byc drugi zalacznik. Tam faktycznie nie ma przeplywu, ale przygladajac sie blizej sa tam takze inne kwiatki; w duzym uproszczeniu symulacja nie uwzglednia kilku rzeczy dla nieobsadzonych czlonow i pojazdow uokrotnionych, bo ma powiedziane zeby zwracac uwage na pojazdy z obsada (ludzka albo AI) Nie wiem na ile da sie to na szybko rozplatac.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 26 Kwietnia 2017, 23:03:23
Odnośnie do EZTów:
- poprawka, przelacznikiem przetwornicy mozna sobie machac takze przy braku napiecia, chociaz oczywiscie nic to nie daje :d
- dodany pseudo wylacznik cisnieniowy: w praktyce oznacza to ze sprezarka mozna sie bawic do momentu osiagniecia 'cisnienia krytycznego', dopiero gdy to nastapi sprezarka przestaje pracowac dopoki cisnienie nie spadnie ponizej dopuszczalnego minimum
Działają.
- poprawka/eksperyment, zbiorniki powietrza dla pantografow w zestawach uokrotnionych sa od siebie niezalezne
- poprawka/eksperyment, 'wylacznik cisnieniowy' pantografow nie wybije wylacznika szybkiego w czlonie ktory otrzymuje zasilanie kablem/sprzegiem wysokiego napiecia
Nie ma możliwości sprawdzenia, bo zbiorniki pantografów nie wykazują kompletnie żadnych nieszczelności (ciśnienie nie maleje po odcięciu kurkiem od ZG).
- poprawka(?), reflektory itp dzialaja takze po odlaczeniu baterii, o ile pracuje przetwornica
Nie działa, tzn. reflektory jak i reszta oświetlenia gasną po wyłączeniu baterii przy załączonej przetwornicy. Dodatkowo w ED72 nie działa sprężarka.

Edit:
Co do załączania sprężarek w ukrotnionych SP/SU45 lub SU46, to tam w rzeczywistości sprężarki obydwu ukrotnionych lokomotyw sterowane są wyłącznikiem ciśnieniowym z lokomotywy sterującej (pierwszej), czyli tak jak w przypadku EZT i też albo pracują wszystkie, albo żadna.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 27 Kwietnia 2017, 00:00:43
Exek Milka x86 260417.
Msvc 2015 jest. Liby są. Nic nie tykałem od fixed pipeline który się "jakoś" uruchamiał. Teraz msvc error.
Mój error identyczny jak ten poniżej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 27 Kwietnia 2017, 00:13:58
Witam.
 U mnie również na exe ng++ Milka zonk. Windows uraczył mnie takim oto komunikatem:-)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 27 Kwietnia 2017, 01:56:21
Tak jak napisałem, powietrze powinno przepływać nie tylko ze zbiorników głównych do przewodu głównego, ale też w drugą stronę, a tak się nie dzieje.
Przepraszam, pomyliłem się nieco. Powinno być: "powietrze powinno przepływać nie tylko ze zbiorników głównych do przewodu głównego zasilającego (tego "żółtego"), ale też w drugą stronę"
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 27 Kwietnia 2017, 08:47:22
W każdym EZT zacina się syrena, nawet pomimo dopisania low i high. Dopisałem też normalnie do jednego przełącznika, żeby sprawdzić, czy normalnie w -1 0 1 będzie to samo i również się zacina i syrena trąbi cały czas.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 27 Kwietnia 2017, 09:23:15
EXE od @Milek7, zero komplikacji. Bardzo duży skok wydajności w porównaniu do wersji fixedpipeline. Załącznik z 16x antyaliasingiem. Nareszcie jest ciemno jak... powinno być. Tak jak napisał, wymagana regulacja świateł, także szerokości smugi i t.p.
Proszę o wyrozumiałość, daję screen bez kompresji, uważam że warto.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: pat w 27 Kwietnia 2017, 09:33:57
A u mnie wydajność spadła masakrycznie. Nawet 30 fps nie mam podczas gdy wcześniej było stabilne 100.
Wersja x64.
Log sypie błędami w ilości niepoliczalnej. Staram się go załączyć ale jest zbyt duży.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 27 Kwietnia 2017, 10:30:06
Log trzeba spakować rarem jak jest zbyt duży... Gdzie miałeś 100FPS? Póki co nie przydadzą się takie informacje z braku możliwości porównania do Twoich wcześniejszy osiągów.
ED:
Dodaje załączniki, odpalenie TD widok z kabiny i po za nią. dodaje także log.txt
W widoku zewnętrznym jest jakiś zonk (załącznik 3 i 4), główna smuga światła podąża za kamerą, powinna być prostopadła do czoła lokomotywy. W niedzielę dysponuje czasem, zerknę w biblioteki shaderów, z jakim efektem, to nie mam pojęcia.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 27 Kwietnia 2017, 13:14:09
W każdym EZT zacina się syrena, nawet pomimo dopisania low i high. Dopisałem też normalnie do jednego przełącznika, żeby sprawdzić, czy normalnie w -1 0 1 będzie to samo i również się zacina i syrena trąbi cały czas.
No troche dziwnie, zeby zacinala sie nawet ta zwykla, skoro w innych kabinach dziala normalnie. Czy moglbys wrzucic gdzies wersje z dodanymi pedalami? Bedzie mi latwiej sprawdzic co tam sie dzieje.

edit: wersja shaderowa chodzi u mnie bardzo ladnie, wydajnosc na poziomie wersji bez shaderow. Parametry rzeczywiscie jeszcze do ustawienia, no i ten specular dla terenu trzeba wylaczyc, bo smiesznie wyglada ;>
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 27 Kwietnia 2017, 14:11:53
Kilka obrazków:
1 i 2, widać różnicę przed lokomotywą z załączonymi światłami i be świateł.
3 i 4, widać różnicę przed lokomotywą i za nią z włączonymi światłami a następnie ten sam teren oświetlony jedynie światłem księżyca.
5, 6 i7, widać podobne zależności.
Wygląda na nieco za szeroką wiązkę światła, scena podobna do tej z uszkodzoną wersją VBO.
Wydajność jest identyczna (2, 3 FPS, to nie różnica), jak exe @tmj
8, ukończona Kaliska.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: pat w 27 Kwietnia 2017, 14:23:54
U mnie wszystkie scenerie poza TD powodują zawieszenie symulatora na najnowszym exe od @Milek7 - po załadowaniu mijają 3 sekundy a symulator zawiesza się (program nie odpowiada): http://i.imgur.com/jozTQLh.jpg
Log i errors w załączniku.

Na przyszłość - pliki graficzne również należy wrzucać w załącznik, z poszanowaniem regulaminu. | @macius5991
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 27 Kwietnia 2017, 15:23:25
@Milek7; Bałtyk, auta straciły swoje tekstury mimo, że na exe od @tmj są. Dodatkowo pojawia się tekstura, nie wiem czego. Ta sama paczka, nie ma możliwości aby czegoś brakowało, lub coś przybyło. Odpalane exe na zmianę Twoje i @tmj.
@pat: Załączniki na forum wklejamy inaczej niż na czatach, SB i IRCu. Należy to zrobić umieszczając jpg w załączniku tak jak log. Załączniki nie mogą zaginąć.
Z logu wynika, że masz dobry sprzęt, zawieszanie się w trakcie odpalania scenerii, świadczy o błędnie skonfigurowanych sterownikach grafiki, lub nieprawidłowych bibliotekach w systemie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 27 Kwietnia 2017, 15:43:40
Ta auta nie mają tekstury, są barwione materiałem. Może to tego wina.
To dziwne coś wygląda na zdegenerowany chodnik z kostki.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 27 Kwietnia 2017, 15:52:50
Zwykle pojazdy mam czarne z braku tekstury na exe od @milek7, ale że na obu exekach ta sama paczka, to brak tekstury nie jest przyczyną. Barwienie materiałem w tym przypadku do naprawy. Co do kostki, to tam nic takiego nie ma co by się mogło zdegenerować, przynajmniej ja to tak oceniam, badając te miejsca na exe od @tmj. Ten ostatni screen, to pojawienie się tej rozmytej linii jest też uzależnione od kąta patrzenia kamery. Miejsce, na prawo przed Alakowicami nad wodą i nad otaczającym gruntem. Przejazd jest ten pierwszy za Bałtykiem Miasto, jadąc do Alakowic.
Generalnie bardzo udana kompilacja, wygląda obiecująco pod względem wydajności i szybkości wczytywania. Dopieszczenie wyglądu oświetlenia, nie powinno tego popsuć.
ED:
A jednak porównanie siatek terenu daje do myślenia.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 27 Kwietnia 2017, 16:17:44
Kompletnie z innej beczki, czy ktos z majacych do czynienia z kodem orientuje sie, jak wlasciwie sa zorganizowane HVCouplers ?
double HVCouplers[2][2]; //przewod WN
wyglada to tak jakby pierwszy parametr definiowal czy to jest sprzeg przedni/tylny w danym pojezdzie, a drugi /chyba/ napiecie dochodzace z pojazdu doczepionego, o ile jakis jest [foo][0], lub napiecie 'wlasne' podawane na zewnatrz [foo][1] ... ale to zalozenie kompletnie sie nie sprawdza dla obroconych czlonow B (ktore pokazuja napiecie przychodzace z czlonu A na pozycji [foo][1], a wlasne na pozycji foo[0]) I teraz nie wiem, czy to jest blad przy podawaniu parametrow ktory trzeba poprawic, czy w tym szalenstwie jest jakas inna metoda do ktorej trzeba sie dostosowac?

(w kodzie jest pod tym wzgledem troche bajzel, bo w niektorych miejscach wyglada to tak, jakby probowal odczytywac na sztywno pozycje [foo][1] jako napiecie z zewnatrz, ale to sie rozmija z faktycznymi wartosciami jakie otrzymuja te zmienne, na podstawie stanu pojazdu wlasnego i sasiednich. Oprocz tego sa jakies dziwne kwiatki w stylu uzaleznienia HVCoupler[0] od stanu Coupler[1] i odwrotnie, zamiast dopasowania 0 do 0 i 1 do 1...)

edit:
I drugie glupie pytanie, tym razem z "rzeczywistosci": czy w EN57 i pochodnych jest cos takiego jak kurek trojdrogowy? Bo w exe jest to zakodowane tak, ze w przypadku EZT jest on traktowany jak nieistniejacy, mozna pompowac zbiornik pantografu bez jego przelaczenia, i nawet po 'odcieciu' zbiornika glownego powietrze z niego zasila zbiornik pantografu. A ja nie wiem jak ma byc :x
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 27 Kwietnia 2017, 16:35:35
@Stele lub @CX MANIAK:
Potrzeba mi loga z nowego exe: (nic więcej się nie zmieniło, tylko zapisywanie do loga w przypadku błędu shadera)
https://ci.appveyor.com/project/Milek7/maszyna/build/18/artifacts
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 27 Kwietnia 2017, 17:31:47
Log. Win XP x86. Coś się dużo wolniej uruchamiało i nawet okienko OGL zdążyło mignąć, ale to pewnie przez dodatkowe testy do logowania.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 27 Kwietnia 2017, 18:04:14
Wpis generujący efekt Bałtycki jest w pliku:
include baltyk/drogi_ra.scm endPo wyłączeniu tego pliku z wczytywania błędu nie ma. Dziwne, że u mnie na exe od @tmj, tego nie ma (załączniki).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 27 Kwietnia 2017, 18:15:42
Log. Win XP x86. Coś się dużo wolniej uruchamiało i nawet okienko OGL zdążyło mignąć, ale to pewnie przez dodatkowe testy do logowania.
sprawdź to https://milek7.pl/.stuff/eu07exe/uniformshaders27.zip
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 27 Kwietnia 2017, 18:17:23
Eu07++ng.exe nie wczytuje terenu z plików e3d, chociaż w logu żadnych informacji dlaczego, nie ma. A nie zauważyłem, aby ten problem był wymieniony w "znanych błędach", więc zgłaszam.
Cytuj
Finished loading 3d model data from "models\walbrzych_teren.e3d"
Loading binary format 3d model data from "models\zmigrod_teren.e3d"...
Finished loading 3d model data from "models\zmigrod_teren.e3d"
Loading binary format 3d model data from "models\jawsl_teren.e3d"...
Finished loading 3d model data from "models\jawsl_teren.e3d"
Loading binary format 3d model data from "models\strzelin_teren.e3d"...
Finished loading 3d model data from "models\strzelin_teren.e3d"
Loading binary format 3d model data from "models\opole_teren.e3d"...
Finished loading 3d model data from "models\opole_teren.e3d"
Loading binary format 3d model data from "models\legnica_teren.e3d"...
Finished loading 3d model data from "models\legnica_teren.e3d"
Loading binary format 3d model data from "models\malczyce_teren.e3d"...
Finished loading 3d model data from "models\malczyce_teren.e3d"
Loading binary format 3d model data from "models\olesnica_teren.e3d"...
Finished loading 3d model data from "models\olesnica_teren.e3d"
Loading binary format 3d model data from "models\glogow_teren.e3d"...
Finished loading 3d model data from "models\glogow_teren.e3d"
Loading binary format 3d model data from "models\ostrow_teren.e3d"...
Finished loading 3d model data from "models\ostrow_teren.e3d"

A po wyjściu z kabiny F4 i przeleceniu paru kilometrów exe się wysypało.
Windows Vista x64.
Log -> http://www.en57.pl/log.txt (http://www.en57.pl/log.txt)
Crushdump -> http://www.en57.pl/eu07++ng_crashdump_20170427_172431.dmp (http://www.en57.pl/eu07++ng_crashdump_20170427_172431.dmp)
no z ładowanie e3d nic się nie zmieniło, powinno działać. jaka to sceneria? i czy na exe tmj działa?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: adamst w 27 Kwietnia 2017, 18:23:13
Cytat: tmj
I drugie glupie pytanie, tym razem z "rzeczywistosci": czy w EN57 i pochodnych jest cos takiego jak kurek trojdrogowy? Bo w exe jest to zakodowane tak, ze w przypadku EZT jest on traktowany jak nieistniejacy, mozna pompowac zbiornik pantografu bez jego przelaczenia, i nawet po 'odcieciu' zbiornika glownego powietrze z niego zasila zbiornik pantografu. A ja nie wiem jak ma byc :x

O ile mi wiadomo EN57 ma zawór automatyczny - jeżeli ZG jest pusty to zbiornik pantografów jest od niego odcięty, i można go pompować małą sprężarką, a gdy ciśnienie w ZG, czy tam przewodzie zasilającym, przekroczy ciśnienie zadziałania zaworu, to przestawia się on na zasilanie zbiornika pantografów z głównej instalacji.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 27 Kwietnia 2017, 18:24:23
Z tym shaderem działa. :)
Dwa błędy zauważyłem na td:
1. Wewnątrz stożka światła pojawia się coś skierowanego do kamery.
2. Zepsute rysowanie sieci trakcyjnej. Większości przęseł brak. Na niektórych takie coś.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 27 Kwietnia 2017, 18:27:07
O ile mi wiadomo EN57 ma zawór automatyczny - jeżeli ZG jest pusty to zbiornik pantografów jest od niego odcięty, i można go pompować małą sprężarką, a gdy ciśnienie w ZG, czy tam przewodzie zasilającym, przekroczy ciśnienie zadziałania zaworu, to przestawia się on na zasilanie zbiornika pantografów z głównej instalacji.
Aha, to by sie zgadzalo z tym, jak jest teraz; zastanawialem sie tylko czy istnieje przy takiej aranzacji mozliwosc recznego 'odciecia' zbiornika pantografu od glownej instalacji, jesli z jakiegos powodu chcemy by zbiornik pantografu sie oproznil bez koniecznosci oprozniania w tym celu przewodu glownego (ktory by go w przeciwnym razie ciagle dopelnial)

edit:
2. Zepsute rysowanie sieci trakcyjnej. Większości przęseł brak. Na niektórych takie coś.
Te dziwne latajace kawalki to jest jedna z pozostalych do usuniecia przypadlosci w trybie VBO, na zwyklym exe tez to produkuje na TD :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 27 Kwietnia 2017, 20:34:37
@tmj łap link do mmd od en57 z tymi dopisanymi pedałami.
http://eu07.pl/userfiles/22657/priv-en57_v1.zip
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 27 Kwietnia 2017, 22:17:20
Log. Win XP x86. Coś się dużo wolniej uruchamiało i nawet okienko OGL zdążyło mignąć, ale to pewnie przez dodatkowe testy do logowania.
sprawdź to https://milek7.pl/.stuff/eu07exe/uniformshaders27.zip
U mnie na tych shaderach odpala przynajmniej na TD normalnie. Fps na poziomie od 100. Multisampling x16. Zaraz uruchomię coś większego:-) Co najciekawsze to nie występuje drżenie składu przy patrzeniu w " lusterka". Na exe Tmj jest to wyraźnie zauważalne.
Pozdrawiam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 27 Kwietnia 2017, 22:24:10
O ile mi wiadomo EN57 ma zawór automatyczny - jeżeli ZG jest pusty to zbiornik pantografów jest od niego odcięty, i można go pompować małą sprężarką, a gdy ciśnienie w ZG, czy tam przewodzie zasilającym, przekroczy ciśnienie zadziałania zaworu, to przestawia się on na zasilanie zbiornika pantografów z głównej instalacji.
Aha, to by sie zgadzalo z tym, jak jest teraz; zastanawialem sie tylko czy istnieje przy takiej aranzacji mozliwosc recznego 'odciecia' zbiornika pantografu od glownej instalacji, jesli z jakiegos powodu chcemy by zbiornik pantografu sie oproznil bez koniecznosci oprozniania w tym celu przewodu glownego (ktory by go w przeciwnym razie ciagle dopelnial)
Rzeczywiście, na schemacie jest zawór zwrotny od sprężarki pantografów do zbiornika pantografów i równolegle drugi zawór zwrotny od przewodu zasilającego do zbiornika pantografów bez żadnych kurków odcinających. Dopiero dalej za zbiornikiem są kurki, którymi można odciąć oba pantografy naraz lub jeden wybrany.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: pat w 27 Kwietnia 2017, 23:03:50
Zaktualizowałem wszystkie sterowniki i liby i nadal wszystkie scenerie poza td powodują zawias :X
Zauważyłem, że jeżeli uruchamiam scenerię z opcją "pauza na starcie" to do czasu odpauzowania nie dochodzi do zawieszenia się programu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 27 Kwietnia 2017, 23:14:43
Witam.
 Uruchomiłem Kaliską. Fps ok, cudów co prawda nie ma, ale na mojej pieczonej już trzy razy karcie nic więcej pewnie i tak nie wycisnę. Zauważyłem dziwny błąd w ET22, mianowicie zdwojone statyczne koło nastawnika, oraz rączkę zaworu hamulca dodatkowego. Edit. Jeszcze wskazówki manometrów. Wszystko widać na screenie.
 No i znowu był wysyp do Windy z komunikatem Runtime coś tam. Niestety szybko się pojawiło i znikło. Nie zdążyłem tego zafiksować. Załączam log i errors, crashdump nie wygenerował się.
Pozdrawiam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 27 Kwietnia 2017, 23:53:32
A to dziwne, u mnie jest wszystko w porządku i podobnego błędu na żadnej wersji nie miałem. Masz tak jeszcze w jakimś loku?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 28 Kwietnia 2017, 00:36:16
Jak na tę chwilę tylko na byku. Na siódemce i ET41 wszystko wydaje się być ok. Reszty nie testowałem jeszcze.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Kwietnia 2017, 01:49:04
Dzisiejsze uaktualnienie nie jest moze tak ekscytujace jak shadery, ale nie mozna miec wszystkiego :P

- poprawka, zbiornik pantografow w EZT napelnia sie i traci powietrze tak, jak powinien

- poprawka(?) zbiornik glowny mozna napelnic takze poprzez przewod zasilajacy sprezarka umieszczona w innym czlonie

- poprawka, w lokomotywach w ktorych pozycja pantografor kontrolowana jest przelacznikiem bistabilnym, pantografy podnosza sie samoczynnie po opadnieciu, jesli maja dostateczne cisnienie w zbiorniku pantografow

- poprawka(?) w okreslaniu stanu dostepnego zasilania przewodami WN, chociaz rownie dobrze moglem tutaj cos zepsuc :P

- ogolnie uporzadkowana nieco interakcje miedzy czlonami, przewodami zasilania, cisnieniem i pozycja pantografow itp:
-- w przypadku utraty cisnienia w zbiorniku pantografow jako pierwszy uruchamia sie wylacznik cisnieniowy (ponizej 350 kpa dla wiekszosci pojazdow, 250 kpa dla EZT), wysylajac sygnal otwarcia wylacznika szybkiego w danym czlonie (lub calym EZT). Otwarcie nie nastapi jesli czlon otrzymuje dostateczne napiecie kablami WN
-- jesli cisnienie spadnie dalej, nieco ponizej progu bezpieczenstwa, pantografy opadaja uruchamiajac przekaznik zanikowo-napieciowy, ktory rowniez otwiera wylacznik szybki w danym czlonie (lub calym EZT) o ile nie ma doprowadzonego pradu kablami WN

- rozbudowana nieco diagnostyka ekranu F3: dodany stan zbiornika glownego ("MT") oraz flagi stanu glownych urzadzen w danym czlonie (bateria, wylacznik szybki, pantografy, przetwornica, sprezarka)

- prawdopodobnie cos tam jeszcze, nie pamietam :x

edit:
@tmj łap link do mmd od en57 z tymi dopisanymi pedałami.
http://eu07.pl/userfiles/22657/priv-en57_v1.zip
Znalazl sie blad, glupi byl, jak zwykle (przez pomylke wlaczana byla syrena w pojezdzie obsadzonym, a wylaczana w kontrolowanym, a to przy EZTach dwie rozne rzeczy sa)

przy okazji, to te pedaly kreca sie w bok zamiast udawac ze je ktos przydeptuje, ale do tego trzeba chyba t3d poprawic :/
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 28 Kwietnia 2017, 14:49:44
Tak tak, animacja pedałów jeszcze koślawa, ale na sztywno to zrobiłem, żeby przetestować. :D

Edit. Wstawiłem EN57 na td i po odpaleniu ezt i przejechaniu jakichś 100 metrów skład zahamował tak, jakby radiostop zadziałał. Dorzucam log.

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: matek123 w 28 Kwietnia 2017, 15:12:11
A wszedłeś do kabiny na końcu jednostki? Może CA zadziałał.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 28 Kwietnia 2017, 15:15:59
Nie zadziałał, byłem. Do tego sprawdziłem jak działa to podnoszenie pantografów w przypadku przełączników bistabilnych. Mianowicie po przełączeniu przełącznika w pozycję opuszczone, nie opadają, lecz jak jeszcze raz nacisnę O lub P to się opuszczają bez problemu, lecz bez żadnej ingerencji w położenie przełącznika. W ET41 nie udało mi się podnieś pantografów wcale.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Kwietnia 2017, 15:19:44
No tam w logu na koncu jest naciskany do oporu Num 3 czyli zwiekszenie sily hamowania. To i nic dziwnego ze zahamowal ;o  A tak na serio to niestety ciezko powiedziec czy to naciskanie bylo juz po fakcie, czy przed.

ET41 dziala u mnie normalnie; zwroc moze uwage, czy w zbiorniku pantografow jest dostateczne cisnienie (3.5) bo moze startuje oprozniony?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 28 Kwietnia 2017, 15:24:47
Dzisiejsze uaktualnienie nie jest moze tak ekscytujace jak shadery, ale nie mozna miec wszystkiego :P
ciach/ciach
- prawdopodobnie cos tam jeszcze, nie pamietam :x
Przypomnę. Insert teraz działa do pięciu razy przy łączeniu taboru. W załączniku ciekawostka, jeśli w trainsecie wpisać wagonom 123 na sprzęgu, to po rozłączeniu i połączeniu ich mostki nie "splatają się", lecz układają jedn nad drugim.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 28 Kwietnia 2017, 15:30:17
No tam w logu na koncu jest naciskany do oporu Num 3 czyli zwiekszenie sily hamowania. To i nic dziwnego ze zahamowal ;o  A tak na serio to niestety ciezko powiedziec czy to naciskanie bylo juz po fakcie, czy przed.

ET41 dziala u mnie normalnie; zwroc moze uwage, czy w zbiorniku pantografow jest dostateczne cisnienie (3.5) bo moze startuje oprozniony?

Bo chciałem spróbować zahamować, żeby znów odhamować po tym jak sam zahamował, a zahamował samoistnie, przecież bym go nie zahamował i nie napisał, że sam zahamował. :P
Mam 4,09 w ET41 w zbiorniku pantografów.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Kwietnia 2017, 15:37:41
Ja nie podejrzewam ze sam hamowales, ale myslalem ze tam moglo cos dodatkowo funkcjonowac, jakis pulpit albo moze program tlumaczacy przyciski myszy na wcisniecia klawiszy itp. W zasadzie puszczalem po TD glownie autopilota i jemu kible nie stawaly, tak ze nie wiem. Zobacze czy uda mi sie to u siebie wywolac.

edit: ET41 dziala mi normalnie. Ale przypomnialo mi sie, sprawdz w errors czy tam nie ma informacji o brakujacym wpisie animations? Bo o ile dobrze pamietam ET41 w paczce calosciowej ma to zle podane i trzeba bylo recznie korygowac.

edit 2: EN57 prowadzony recznie jezdzi mi po TD normalnie i nie hamuje sam z siebie ;/
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 28 Kwietnia 2017, 15:56:22
@Wiggle: Prawidłowe pliki mmd i fiz ET41, można pobrać z repozytorium. @Stele wgrał poprawki.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 28 Kwietnia 2017, 16:47:52
@Wiggle: Prawidłowe pliki mmd i fiz ET41, można pobrać z repozytorium. @Stele wgrał poprawki.

A widzisz, a ja stawiałem MaSzynę na nowo i nie przegrałem tego z repo.

Ja nie podejrzewam ze sam hamowales, ale myslalem ze tam moglo cos dodatkowo funkcjonowac, jakis pulpit albo moze program tlumaczacy przyciski myszy na wcisniecia klawiszy itp. W zasadzie puszczalem po TD glownie autopilota i jemu kible nie stawaly, tak ze nie wiem. Zobacze czy uda mi sie to u siebie wywolac.

edit: ET41 dziala mi normalnie. Ale przypomnialo mi sie, sprawdz w errors czy tam nie ma informacji o brakujacym wpisie animations? Bo o ile dobrze pamietam ET41 w paczce calosciowej ma to zle podane i trzeba bylo recznie korygowac.

edit 2: EN57 prowadzony recznie jezdzi mi po TD normalnie i nie hamuje sam z siebie ;/

Wiesz co błąd jest jakiś randomowy i pojawia się u mnie raz na jakieś 10-20 uruchomień en57. Na starszych wersjach również to było, ale nie miałem czasu napisać o tym.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Kwietnia 2017, 18:33:48
Male uaktualnienie:

- poprawka, pantografy kontrolowane przelacznikami bistabilnymi powinny ponownie opuszczac sie normalnie

- poprawka, syreny w EZT powinny wylaczac sie normalnie

- drobna rozbudowa systemu przesylania komend w skladzie: mozna definiowac typ/kombinacje sprzegow wymagana do przeslania komendy do sasiednich pojazdow (na razie tylko na poziomie kodu exe)

- korzystajac z powyzszego, poprawione nieco zachowanie EZT w sytuacjach gdzie zachodzi automatyczne otwarcie wylacznika szybkiego -- przy skladach zlozonych z wiecej niz jednego zespolu, wylaczenie nastapi tylko w konkretnym zespole, a nie w calym pociagu (pod warunkiem ze czlony EZT sa spiete polaczeniem "stalym" +128)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 28 Kwietnia 2017, 18:43:26
250 kpa dla EZT

Dlaczego? W EN57 jest standardowe 3,5 atm dla rozwarcia PWR i 4,6 dla powtórnego zwierania.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Kwietnia 2017, 18:46:10
No ja sie nie znam a tak juz w exe bylo "od zawsze", wiec nie ruszalem:
            if( MoverParameters->PantPress < ( MoverParameters->TrainType == dt_EZT ? 2.5 : 3.5 ) ) {
                // 3.5 wg http://www.transportszynowy.pl/eu06-07pneumat.php
                // Ra 2013-12: Niebugocław mówi, że w EZT podnoszą się przy 2.5
Jesli to jest zle to moge zmienic :>
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 28 Kwietnia 2017, 18:49:02
No, co innego jest uruchamianie jednostki od zera przy jednoczesnym przekręceniu pakieciaka "Zwarcie PWR" (czyli mostkowanie zabezpieczenia), a co innego normalna praca ezeta :) Bez tego musiałby pompować małą sprężarką do 4,6 atm, co raczej trudno osiągnąć z różnych względów (no i ogółem - tego tak się nie robi, tylko właśnie z mostkowaniem). Jadąc przy 2.5 atm zdążyłbyś przepalić sieć, bo to jest taka wartość gdzie przy dobrych warunkach (nie w mróz) cylindry pantografów są w stanie przebić naciąg sprężyn. Także poproszę :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Kwietnia 2017, 18:56:12
Czyli co, ustawic zeby opadal na 3.5 atm tak jak dla pozostalych, a 'czujnik' sprawdzajacy czy zeszlo na tyle nisko uruchamia sie od 4.6 atm w gore?

(cisnienie opadania mozna chyba zdefiniowac w .fiz parametrem "MinPress" ale z tego co widze jest to praktycznie nie uzywane, a wartosc domyslna to cos ok 2.0)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 28 Kwietnia 2017, 19:16:10
- poprawka, zbiornik pantografow w EZT napelnia sie i traci powietrze tak, jak powinien
- poprawka(?) zbiornik glowny mozna napelnic takze poprzez przewod zasilajacy sprezarka umieszczona w innym czlonie
Działają.
- poprawka(?) w okreslaniu stanu dostepnego zasilania przewodami WN, chociaz rownie dobrze moglem tutaj cos zepsuc :P
Wydaje się działać dobrze.
- poprawka, w lokomotywach w ktorych pozycja pantografor kontrolowana jest przelacznikiem bistabilnym, pantografy podnosza sie samoczynnie po opadnieciu, jesli maja dostateczne cisnienie w zbiorniku pantografow
Z tym trochę przedobrzyłeś ;) Przy napełnianiu zbiornika pantografów po załączeniu baterii pantografy same się podnoszą od razu przy wzroście ciśnienia powyżej 0,35MPa w lokomotywach i 0,25MPa w EZT, mimo że podnoszenie nie jest załączone hebelkiem. Podnosić przy wzroście ciśnienia mają się tylko wtedy, kiedy wcześniej przełączy się hebelek na podnoszenie.
-- w przypadku utraty cisnienia w zbiorniku pantografow jako pierwszy uruchamia sie wylacznik cisnieniowy (ponizej 350 kpa dla wiekszosci pojazdow, 250 kpa dla EZT), wysylajac sygnal otwarcia wylacznika szybkiego w danym czlonie (lub calym EZT). Otwarcie nie nastapi jesli czlon otrzymuje dostateczne napiecie kablami WN
-- jesli cisnienie spadnie dalej, nieco ponizej progu bezpieczenstwa, pantografy opadaja uruchamiajac przekaznik zanikowo-napieciowy, ktory rowniez otwiera wylacznik szybki w danym czlonie (lub calym EZT) o ile nie ma doprowadzonego pradu kablami WN
Działa poza tym, że po wyłączeniu się WSa w jednym z członów, po przejściu do drugiego choć przetwornice pracują, da się jechać itd., to lampka WSa jest zgaszona. Trochę przeszkadza też tutaj jedna kombinacja od załączania i wyłączania WSa, bo przy próbie jego załączenia w członie, w którym nastąpiło wyłączenie, owszem załącza się, ale z kolei wyłącza się w drugim członie i tak można sobie przełączać na przemian w nieskończoność... Jedyne co można zrobić, to krótko nacisną "M", co spowoduje wyłączenie WSa i dopiero drugi raz przytrzymać wciśnięte "M", a wtedy załączy się w obu członach.

Ogólny wniosek jest taki, że już i tak jest bardzo dobrze i ciągle co raz to bardziej realistycznie, jeśli chodzi o uruchamianie lokomotyw, ale oprócz powyższego do zrobienia zostało jeszcze:
- możliwość załączania/wyłączania baterii tylko w członie/ukrotnionej lokomotywie, w której akurat się jest;
- zmniejszenie wydajności sprężarki pantografów do ok. 1/3 obecnej wydajności (ten parametr chyba akurat nie jest wyprowadzony do *.fiz jak w przypadku sprężarek głównych);
- niewyłączanie się sprężarki pantografów przy "podparciu jej stycznika" i wyjściu z przedziału maszynowego - teraz, kiedy wciśnie się [Shift]+[V], puści najpierw [Shift] i po tym puści [V] sprężarka dalej pracuje, co jest świetnym (choć przypuszczam zupełnie niezamierzonym) odwzorowaniem właśnie podparcia jej stycznika, ale niestety wyłącza się po opuszczeniu przedziału maszynowego;
- dodanie lampki sygnalizującej obecność wysokiego napięcia w drugim członie, żeby było wiadomo, kiedy jego pantografy zetknęły się z siecią i można w nim załączyć WS, przetwornice i sprężarki, aby szybciej dopompować powietrze do ZG;
- w lokomotywach dwuczłonowych odwrócone jest sterowanie pantografami w członie B - "P" podnosi/opuszcza tylne, a "O" przednie - powinno być odwrotnie;
- Edit: nadal brak synchronizacji w załączaniu i wyłączaniu sprężarek w ukrotnionych członach/lokomotywach, tzn. jeśli tylko sprężarka dostaje napięcie z przetwornicy, to ma pracować razem z innymi, a jeśli się wyłączają, to mają to robić wszystkie na raz (teraz kiedy napompuje się ciśnienie do ZG w jednym członie, a później uruchomi się drugi człon, to sprężarki w nim załączają się jeszcze na chwilkę).
Jak te rzeczy uda się zrobić, to ciężko o bardziej realistyczny proces uruchamiania bez odwzorowania obwodów i już nikt nie będzie mógł MaSzynie zarzucić, że uruchamianie jest mało realistyczne ;D A takie głosy się pojawiają przy okazji różnych porównań...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Kwietnia 2017, 19:29:04
Z tym trochę przedobrzyłeś ;) Przy napełnianiu zbiornika pantografów po załączeniu baterii pantografy same się podnoszą od razu przy wzroście ciśnienia powyżej 0,35MPa w lokomotywach i 0,25MPa w EZT, mimo że podnoszenie nie jest załączone hebelkiem. Podnosić przy wzroście ciśnienia mają się tylko wtedy, kiedy wcześniej przełączy się hebelek na podnoszenie.
Hmm nie obserwuje tego u siebie -- przy zalaczonej baterii i nietykanych przelacznikach moge sobie pompowac sprezarka do pelna, a patyki ani drgna. Widac to na zalaczniku. Byc moze przypadkiem zostal uruchomiony przelacznik pantografow? Jesli jest zalaczony, to w zaznaczonym na zalaczniku obszarze pojawia sie male litery "o" i "p" dla pantografow tylnego i przedniego.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 28 Kwietnia 2017, 19:29:47
Czyli co, ustawic zeby opadal na 3.5 atm tak jak dla pozostalych, a 'czujnik' sprawdzajacy czy zeszlo na tyle nisko uruchamia sie od 4.6 atm w gore?

(cisnienie opadania mozna chyba zdefiniowac w .fiz parametrem "MinPress" ale z tego co widze jest to praktycznie nie uzywane, a wartosc domyslna to cos ok 2.0)

W EN57 sam spadek ciśnienia w przewodzie zasilającym działa tylko na obwody pomocnicze (przetwornicę, ogrzewanie) - nie powoduje wyłączenia WSa. Pantograf zacznie opadać tak przy tych 2.5 atm, ale zabezpieczenie wyłączające przetwornicę i ogrzewanie zadziała przy 3.5. Ponowne załączenie ogrzewania i przetwornicy będzie możliwe po powrocie do 4.6 lub zmostkowaniu tego wyłącznika ciśnieniowego. WS puści dopiero, jak mu przekaźnik zanikowo - napięciowy wyłapie brak napięcia w sieci (czyli oderwanie się pantografu od sieci).

Natomiast sam w sobie zanik sterowania obwodem głównym (brak jazdy) powodowany będzie wyłącznikiem ciśnieniowym w obwodzie głównym (AWR), który ma takie same nastawy 3,5 - 4,6 atm.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 28 Kwietnia 2017, 19:45:11
Tutaj @tmj musisz sprawdzić jeszcze z różnymi konfiguracjami wstawiania na scenerie. Jeśli wstawimy na td zamiast ep07 to rzeczywiście nie podnoszą się pantografy same. Ale jeśli wstawimy na ten wolny tor gdzie skład startuje "napompowany" to się podnoszą.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Kwietnia 2017, 19:47:10
W EN57 sam spadek ciśnienia w przewodzie zasilającym działa tylko na obwody pomocnicze (przetwornicę, ogrzewanie) - nie powoduje wyłączenia WSa. Pantograf zacznie opadać tak przy tych 2.5 atm, ale zabezpieczenie wyłączające przetwornicę i ogrzewanie zadziała przy 3.5. Ponowne załączenie ogrzewania i przetwornicy będzie możliwe po powrocie do 4.6 lub zmostkowaniu tego wyłącznika ciśnieniowego.
A to nie jest niewygodne? Tzn jesli przy 3.5 wylacza przetwornice, to chyba nie pojdzie tez sprezarka, a bez sprezarki to troche ciezko dobic do 4.6.. no chyba ze sprezarka pojdzie tez z akumulatorow, ale tego akurat w symulatorze nie ma..? ;o
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 28 Kwietnia 2017, 19:50:54
Hmm nie obserwuje tego u siebie -- przy zalaczonej baterii i nietykanych przelacznikach moge sobie pompowac sprezarka do pelna, a patyki ani drgna. Widac to na zalaczniku. Byc moze przypadkiem zostal uruchomiony przelacznik pantografow? Jesli jest zalaczony, to w zaznaczonym na zalaczniku obszarze pojawia sie male litery "o" i "p" dla pantografow tylnego i przedniego.
Rzeczywiście, za każdym razem mam w tym miejscu "Bmop" tak w ET41 jak i w EU07, choć klawiszy "O" i "P" w ogóle nie tykam. Po przekroczeniu 0,35MPa zmienia się na "BmOP!" i patyki idą w górę. W załącznikach przykładowy log i errors. Uruchamiam z nastawą hamulca BQ, tzn. bez ciśnienia w zbiornikach głównych.
Dodałem też jeszcze jeden błąd do listy w poprzedniej wiadomości, który też już kiedyś zgłaszałem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Kwietnia 2017, 19:53:27
Czy masz moze u siebie w konfiguracji/pliku wstawienia pociagu wpis "pantstate" jako "ladunek" lokomotywy? O ile dobrze pamietam sluzy to wlasnie do "wymuszenia" konkretnego ustawienia pantografow na starcie.

(lub byc moze jest to cos, co jest wywolywane przez scenerie przy ustawieniu na konkretnym torze, tak jak pisze Wiggle? Niestety na sceneriach itp nie znam sie kompletnie, ktos musialby tutaj dac instrukcje jak cos takiego zduplikowac)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 28 Kwietnia 2017, 19:54:55
Pantograf zacznie opadać tak przy tych 2.5 atm

Zacytuje samego siebie, ale by doprecyzować - zacznie się odrywać przy 2.5. Żadne zawory się nie przesterują na opuszczanie. Ile będzie ciśnienia, tyle w górze będą patyki :P Jak będzie 1.8, to (strzelam z wartością - chodzi o efekt) pantograf będzie sobie tak wisiał w połowie między dachem a siecią ;)

A to nie jest niewygodne? Tzn jesli przy 3.5 wylacza przetwornice, to chyba nie pojdzie tez sprezarka, a bez sprezarki to troche ciezko dobic do 4.6.. no chyba ze sprezarka pojdzie tez z akumulatorow, ale tego akurat w symulatorze nie ma..? ;o

No jak już masz 3.5 to siłą rzeczy i tak coś jest tego przyczyną (usterka) - musisz się zatrzymać i pójść do silnikowego się spróbować uruchomić. Z reguły też i tak skład Ci zahamuje, bo w przewodzie głównym również już będzie poniżej 5 atm. To są już awaryjne sytuacje. Normalnie przecież w zasilającym cały czas ~ między 6 a 7 atm jest :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 28 Kwietnia 2017, 20:33:20
@tmj: Miałem prędkość początkową ustawioną na 0,1. Poprawiłem na 0,0 i działa, ale znalazłem coś innego. Jeśli podniesiony jest tylko jeden pantograf (obojętne który), to po przejściu do przedziału maszynowego obydwa same przestawiają się na podnoszenie. Co ciekawe, dzieje się to tylko w jednym członie (załącznik).

Edit: Przy okazji znalazłem błąd z hamulcami niewystępujący na exe borlandowym. Kiedy uruchamia się jakikolwiek pojazd bez powietrza (dopisek ".BQ" do numeru sprzęgu), przestają w nim działać hamulce, tzn. cylindry hamulcowe nie napełniają się przy spadku ciśnienia w przewodzie głównym. Dodatkowo po zahamowaniu lokomotywy hamulcem pomocniczym słychać jakieś syczenie, które ustaje dopiero po ruszeniu z miejsca.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Kwietnia 2017, 21:06:53
Natomiast sam w sobie zanik sterowania obwodem głównym (brak jazdy) powodowany będzie wyłącznikiem ciśnieniowym w obwodzie głównym (AWR), który ma takie same nastawy 3,5 - 4,6 atm.
Jesli moge, dla dodatkowego doprecyzowania, co dokladnie znaczy tutaj "zanik sterowania obwodem glownym"? Rozlaczenie WS, czy cos innego?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 28 Kwietnia 2017, 21:46:16
Powodem błędu z hamulcami jest prawdopodobnie samoczynnie załączający się przy starcie symulacji odluźniacz, który przez cały czas spuszcza powietrze z cylindrów. Wskazuje też na to samoczynne napełnianie przewodu głównego po przestawieniu kranu głównego w pozycję jazdy lub napełnienia, także wtedy, gdy ciśnienie w przewodzie głównym jest mniejsze niż 0,28MPa - normalnie trzeba w takiej sytuacji użyć właśnie odluźniacza. Dopiero po naciśnięciu [Num4] (odblokowaniu odluźniacza) hamulce działają poprawnie. Jeśli już, to pojazd powinien się uruchamiać z zerowym ciśnieniem w cylindrach, ale nie z zablokowanym w stanie załączonym odluźniaczem.

Edit: Swoją drogą, wyłączenie baterii przy niepracującej przetwornicy też powinno spuszczać powietrze z przewodu głównego jak przy samoczynnym hamowaniu CA, SHP, czy radio-stopu, bo traci wtedy zasilanie cewka tego samego elektrozaworu. Także przy uruchomieniu symulacji, kiedy lokomotywa ma wyłączoną baterię, powietrza w przewodzie głównym nie powinno być, bo wtedy też nie ma zasilania ten zawór i jest otwarty do atmosfery, ale przy tym już mogą się posypać scenariusze, w których np. długi skład towarowy musi ruszyć zaraz po uruchomieniu symulacji. Przy czymś takim wymagałby odhamowania od zera, co trochę trwa, ale to też jest do zrobienia "na kiedyś". Albo dodać jakiś dopisek do sprzęgu jak ".BQ", tylko że bez powietrza jedynie w przewodzie głównym?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 28 Kwietnia 2017, 21:56:39
Powodem błędu z hamulcami jest prawdopodobnie samoczynnie załączający się przy starcie symulacji odluźniacz, który przez cały czas spuszcza powietrze z cylindrów.
Ostatnio (nie pamięta od której wersji) coś syczy po wczytaniu scenerii, myślałem że to AI, bo często w debugmode odpalam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 28 Kwietnia 2017, 22:15:16
(...) ale przy tym już mogą się posypać scenariusze, w których np. długi skład towarowy musi ruszyć zaraz po uruchomieniu symulacji.

Jeśli skład musi ruszyć zaraz po uruchomieniu symulacji ustawia mu się prędkość początkową 0.1, inaczej nie może ruszyć natychmiast nawet na starym exe.
Pamiętam, że zaraz przed ukończeniem ostatniej paczki całościowej była jakaś zmiana, która powodowała, że nie dało rady podnieść patyków przed podpompowaniem sprężarką pomocniczą. Potem zostało to "poprawione", i jak dla mnie: szkoda. Wolałem wersję z prawdziwym "zimnym startem". W TD2 start jest bardzo uproszczony, ale ciśnienie w ZG jest zero i konieczne jest użycie odluźniacza żeby odhamować skład.

Ktoś tam na YT też narzekał, że w takim Trainz procedura uruchomienia takiej siódemki czy byka wygląda w miarę poważnie, a w MaSzynie jest uproszczona do bólu. Dlatego z tymi zaworami to jest bardzo cenna uwaga i warto to wdrożyć nawet jeśli ujawni to błędy w niektórych scenariuszach. Jak mówiłem, jak skład ma ruszyć od razu, to ma wpisaną prędkość 0.1, czyli jest "wstępnie uruchomiony", ma nabite ciśnienie w ZG i jest gotowy do odjazdu. Gorzej, jak ktoś założył, że powiedzmy skład ruszy w ciągu minuty, wtedy będzie problem, bo zgodnie z właściwym działaniem zaworów nie ma szans żeby w tym czasie ruszył. No i oczywiście do tego AI musi też potrafić prawidłowo wystartować zgodnie z poprawioną procedurą. Inna sprawa, że poprawienie takich błędów w scenariuszach jest (zgaduję) bardzo proste, wystarczy im po prostu ustawić prędkość początkową i po krzyku. Można to chyba nawet zrobić bezpiecznie dla wszystkich składów prowadzonych przez AI i raczej nie powinno się nic posypać specjalnie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 28 Kwietnia 2017, 22:27:21
W sumie racja. To jeszcze można by dodać konieczność odbloku przekaźnika różnicowego obwodu głównego po każdym załączeniu baterii (przy wyłączonej przetwornicy), bo bez tego w rzeczywistości nie da się załączyć WSa. A robi się to tym samym przyciskiem, co odblok nadmiarowych silników trakcyjnych. Jedynie trzeba by zaktualizować modele kabin lokomotyw (w zasadzie chyba wszystkich) o nową kontrolkę.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 28 Kwietnia 2017, 22:30:28
Gwarantuje ci, że wszystkie scenariusze dla użytkownika (te bez AI), zaraz przerobie na już uruchomione lokomotywy. Nie dlatego że jestem przeciwny uruchamiania na zimnej, tylko że wprowadzenie tego dla każdego scenariusza będzie samo w sobie nieprawdą. Przykład, drużyna trakcyjna na Łódź kaliska przejmuje Włókniarza do Gdyni, lok ze składem przyjeżdża ciepły! Owszem, można dać gdzieś takie pojazdy na torach postojowych, niech się ludziska tym pobawią. Mam też powody, aby uznać,  że takie udoskonalenie symulatora nie powinno zastępować właściwe szkolenia maszynistów (tych prawdziwych), to będzie pokusa, tania i darmowa. MaSzyna nie jest od tego. Za to spadnie biegusiem jej tak zwana "grywalność" ze względu na stopień skomplikowania.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 28 Kwietnia 2017, 22:37:25
Edit: Swoją drogą, wyłączenie baterii przy niepracującej przetwornicy też powinno spuszczać powietrze z przewodu głównego jak przy samoczynnym hamowaniu CA, SHP, czy radio-stopu, bo traci wtedy zasilanie cewka tego samego elektrozaworu.

Hehe, oprócz EN57* :D

*Tylko pojazdy serii 19xx mają tak jak opisane wyżej - przy braku zasilania otwiera się elektrozawór i robi się dziura w przewodzie głównym.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 28 Kwietnia 2017, 22:44:12
Pytanie: Jak exe traktuje ostatni przewód powietrzny (hamulcowy) z flagą 0 i 3? Teoretycznie ostatni sprzęg w składzie z "trójką" powinien wywołać dziurę w PG.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 28 Kwietnia 2017, 22:45:13
Nie twierdzę, że wszystkie scenariusze mają wymagać uruchamiania lokomotywy od zera, bo jest często jak piszesz, ale kilka takich może być, a jeśli tak, to sam proces może przecież być realistyczny. A co do obaw o użycie MaSzyny do szkoleń, to już od dawna jest używana i na to chyba niestety nic się nie poradzi (myślę o "symulatorze EN57" pewnej spółki w Lublinie - było kiedyś w Teleexpressie).
Teoretycznie ostatni sprzęg w składzie z "trójką" powinien wywołać dziurę w PG.
Obecnie nie wywołuje.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 28 Kwietnia 2017, 22:55:47
Chodzi mi o nadużywanie możliwości uruchamiania na zimno. Przyjąłbym stosunek 1/10, może 15 wykorzystania tej możliwości. Wiem, że 0, ani 3 na końcu składu nie wywołuje efektów, raczej mi chodziło, czy jest ze strony exe ten stan jakoś interpretowany a później olany, jeśli jest to ostatni wagon.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Kwietnia 2017, 23:16:30
Trochę przeszkadza też tutaj jedna kombinacja od załączania i wyłączania WSa, bo przy próbie jego załączenia w członie, w którym nastąpiło wyłączenie, owszem załącza się, ale z kolei wyłącza się w drugim członie i tak można sobie przełączać na przemian w nieskończoność... Jedyne co można zrobić, to krótko nacisną "M", co spowoduje wyłączenie WSa i dopiero drugi raz przytrzymać wciśnięte "M", a wtedy załączy się w obu członach.
To nie jest dokladnie tak :)
Sygnaly zalaczenia/wylaczenia sa generowane na podstawie stanu urzadzenia w obslugiwanej kabinie -- tzn jesli w czlonie A wylacznik szybki jest otwarty, to zamkniecie go przesle sygnal "zamknij WS" takze do czlonu B, a nie "przelacz WS". Jesli zamkniemy WS w czlonie A, zas w czlonie B juz byl zamkniety, to czlon B po prostu zignoruje komende.
Czyli w sytuacji gdzie jeden czlon jest wlaczony a drugi nie jest, to zeby wlaczyc ten drugi faktycznie trzeba na chwile wylaczyc i ponownie zalaczyc pierwszy, albo pofatygowac sie osobiscie do drugiego i zalaczyc 'recznie' stamtad.

Co do synchronizacji pracy sprezarek, chwilke to potrwa bo nie ma jeszcze w exe mechanizmow ktore pozwolilyby na realizacje czegos takiego i trzeba je dodac

Co do sterowania pantografami, tutaj jest chyba dosc duze poplatanie na styku exe, konfiguracji kabin i samych modeli t3d -- nie zdziwilbym sie gdyby np wyszlo ze tylny czlon ET41 ma zamienione miejscami pantografy w modelu albo cos rownie dziwnego. Rozplatac to ewentualnie trzeba, ale na szybko za wiele nie da sie zrobic.

edit:
Pytanie: Jak exe traktuje ostatni przewód powietrzny (hamulcowy) z flagą 0 i 3? Teoretycznie ostatni sprzęg w składzie z "trójką" powinien wywołać dziurę w PG.
Bez zagladania w kod, zgaduje ze typ sprzegu podany w pliku scn jedynie 'nadpisuje' typ polaczenia jaki moze byc uformowany, jesli za podanym pojazdem bedzie umieszczony jeszcze jeden. Czyli '3' znaczy jedynie "nastepny pojazd mozna spiac hakiem i przewodem hamulca", ale nie zostawia to jakiegos dyndajacego, otwartego przewodu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 29 Kwietnia 2017, 01:25:10
Rzeczywiście, trochę się zapędziłem z tym WSem. Sprawdziłem jeszcze raz na spokojnie i jest tak: kiedy w członie B jest załączony, a w A wyłączony i próbuje się go załączyć, to w momencie załączania w A, wyłącza się w B, a jak w A się już załączy, to i w B się z powrotem załącza. Załącz sobie najpierw WSa w obu członach, załącz przetwornice i spowoduj wyłączenie WSa w A (np. odetnij kurkiem zasilanie pantografów w A i przyspiesz czas aż opadną, a później dopompuj/połącz z powrotem z ZG). Będąc w A dalej będzie słychać pracujące przetwornice w B. Jak pantografy w A się podniosą, wciśnij i nie puszczaj "M". Będzie słychać, jak przetwornice w B się zatrzymują. Dopiero po puszczeniu "M" wystartują ponownie w obu członach, kiedy załączą się WSy. W rzeczywistości w B nie powinien się ani na chwilę wyłączyć WS przy czymś takim, bo od załączania i wyłączania są osobne przyciski. No ale to już są takie szczegóły, więc jak uważasz, tak zrób (albo i nie)...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 29 Kwietnia 2017, 02:00:46
To zatrzymywanie sie przetwornic/sprezarek to jest pozostalosc w kodzie zamykania wylacznika szybkiego. Nie moge sobie przypomniec czy byl jakis powod, zeby to zostawic, i byc moze po niedawnych zmianach mozna sie tego teraz pozbyc, sprawdze.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 29 Kwietnia 2017, 07:01:20
Mamy gdzieś aktualne .chk pojazdów z dynamic?
Mi pantografy nie opadają.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 29 Kwietnia 2017, 14:26:18
W dzisiejszym uaktualnieniu:

- poprawka, lampka wylacznika szybkiego powinna dokladniej odzwierciedlac stan obwodu glownego w danym czlonie/pojezdzie

- uporzadkowana nieco obsluga pantografow, pojazdy nie powinny sie juz mylic przy zmianie kabiny ktore pantografy sa zaznaczone do podniesienia/opuszczenia (ale swoja droga jest to temat do dalszego ogarniecia, zeby przelaczniki w kabinach mogly prawidlowo odzwierciedlac stan ustawiony w danej kabinie, oraz ktory klawisz kontroluje ktory pantograf itp)

- eksperyment: zamykanie wylacznika szybkiego nie wylacza chwilowo przetwornic i sprezarek w calym pociagu.

- eksperyment: jesli 'zablokujemy' sprezarke pantografow by dzialala bez trzymania klawisza, bedzie ona pracowac dalej takze po opuszczeniu pomieszczenia -- zatrzyma sie albo po osiagnieciu limitu 480 kpa, albo jesli pofatygujemy sie do maszynowego i zatrzymamy ja recznie, wciskajac i puszczajac, tym razem poprawnie, shift + V
(wydajnosc sprezarki bedzie zapewne nieco zmniejszona, ale na razie zostaje jak jest bo ulatwia to testy ;d

- poprawka(?) wplywu cisnienia pantografow itp na stan pojazdu:
-- przy zejsciu cisnienia ponizej zdefiniowanego minimum (parametr MinPress, domyslnie 3.5) jesli aktywny jest wylacznik cisnieniowy (aktywuje sie przy cisnieniu 460kpa) w wiekszosci pojazdow rozlaczony zostanie wylacznik szybki. W EZT rozlaczenie nie nastapi, natomiast wylaczona i zablokowana zostanie praca przetwornicy w danej jednostce (powinno byc tez ogrzewanie, ale tutaj trzeba wprowadzic dodatkowe modyfikacje) Blokada jest usuwana po dobiciu cisnienia do 460 kpa.
-- przy dalszym zejsciu cisnienia, na poziomie ~345kpa w wiekszosci pojazdow, ~245kpa dla EZT zaczynaja opadac pantografy i aktywuje sie przekaznik zanikowo-napieciowy, otwierajac wylacznik szybki
(w obu przypadkach wylacznik nie ma efektu jesli pojazd ma dodatkowe zrodlo zasilania w postaci aktywnego polaczenia WN)
(przy niskim cisnieniu pantografy opadaja zamiast 'wisiec' ze wzgledu na obecna konstrukcje ich animacji. Na ten moment nie wiem, jak latwo da sie to poprawic)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 29 Kwietnia 2017, 16:56:48
Tylko przydaloby sie cos ala pakieciak "Zwarcie PWR", coby moc sie uruchomic jednostka od zera ;) Chyba ze mala sprezarka magicznie bardzo wydajnie nabija ponad 4.6, no to niech tymczasowo bedzie :P
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 29 Kwietnia 2017, 16:59:35
Ja mam takie pytanko. Czy jest możliwość, że jeśli nie ma przełącznika przetwornicy i sprężarki to przycisk załączania WS'a załącza przetwornicę i sprężarkę? Tak jest w zmodernizowanych EN57 (tych co mają silniki asynchroniczne).
I fajnie byłoby takie coś wyprowadzić "na skróty".
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 29 Kwietnia 2017, 17:23:46
Tylko przydaloby sie cos ala pakieciak "Zwarcie PWR", coby moc sie uruchomic jednostka od zera ;) Chyba ze mala sprezarka magicznie bardzo wydajnie nabija ponad 4.6, no to niech tymczasowo bedzie :P
W tej chwili wyglada to tak, ze przekaznik cisnienia pantografow jest na starcie nieaktywny i aktywuje sie dopiero po osiagnieciu 4.6 atm, a dopoki sie on nie aktywuje, uklad ignoruje wartosci cisnienia ponizej progowej. Czyli w praktyce wyglada to tak, ze startujac 'na pusto' wystarczy napompowac nieco powyzej 2.5 atm, tak zeby patyki sie podniosly, i mozna wtedy zamknac wylacznik szybki, i uruchomic przetwornice i sprezarke glowna, ktora juz nabije ile trzeba. Czyli w pewnym sensie tak, jakby zwarcie PWR bylo wlaczone domyslnie (i usuwalo sie samoczynnie po dobiciu do 4.6) o ile dobrze rozumiem cala aranzacje?

edit:
Ja mam takie pytanko. Czy jest możliwość, że jeśli nie ma przełącznika przetwornicy i sprężarki to przycisk załączania WS'a załącza przetwornicę i sprężarkę? Tak jest w zmodernizowanych EN57 (tych co mają silniki asynchroniczne).
I fajnie byłoby takie coś wyprowadzić "na skróty".
Takie cos chyba dobrze byloby umiescic jako wariant w .fiz (podobnie jak jest np. sprezarka automatycznie polaczona z przetwornica) zeby to nie wyskoczylo samo z siebie w jakichs niedorobionych konfiguracjach, gdzie ktos nie zrobil wpisu przelacznika bo mu sie nie chcialo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 29 Kwietnia 2017, 17:36:57
Noo to warto to mieć na uwadze. W sumie racja, bo jak jakiś pojazd ma niedopisany przełącznik od przetwornicy to by była lipa.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 29 Kwietnia 2017, 18:16:11
- poprawka, lampka wylacznika szybkiego powinna dokladniej odzwierciedlac stan obwodu glownego w danym czlonie/pojezdzie
- uporzadkowana nieco obsluga pantografow, pojazdy nie powinny sie juz mylic przy zmianie kabiny ktore pantografy sa zaznaczone do podniesienia/opuszczenia (ale swoja droga jest to temat do dalszego ogarniecia, zeby przelaczniki w kabinach mogly prawidlowo odzwierciedlac stan ustawiony w danej kabinie, oraz ktory klawisz kontroluje ktory pantograf itp)
- eksperyment: zamykanie wylacznika szybkiego nie wylacza chwilowo przetwornic i sprezarek w calym pociagu.
- eksperyment: jesli 'zablokujemy' sprezarke pantografow by dzialala bez trzymania klawisza, bedzie ona pracowac dalej takze po opuszczeniu pomieszczenia -- zatrzyma sie albo po osiagnieciu limitu 480 kpa, albo jesli pofatygujemy sie do maszynowego i zatrzymamy ja recznie, wciskajac i puszczajac, tym razem poprawnie, shift + V
(wydajnosc sprezarki bedzie zapewne nieco zmniejszona, ale na razie zostaje jak jest bo ulatwia to testy ;d

- poprawka(?) wplywu cisnienia pantografow itp na stan pojazdu:
-- przy zejsciu cisnienia ponizej zdefiniowanego minimum (parametr MinPress, domyslnie 3.5) jesli aktywny jest wylacznik cisnieniowy (aktywuje sie przy cisnieniu 460kpa) w wiekszosci pojazdow rozlaczony zostanie wylacznik szybki. W EZT rozlaczenie nie nastapi, natomiast wylaczona i zablokowana zostanie praca przetwornicy w danej jednostce (powinno byc tez ogrzewanie, ale tutaj trzeba wprowadzic dodatkowe modyfikacje) Blokada jest usuwana po dobiciu cisnienia do 460 kpa.
-- przy dalszym zejsciu cisnienia, na poziomie ~345kpa w wiekszosci pojazdow, ~245kpa dla EZT zaczynaja opadac pantografy i aktywuje sie przekaznik zanikowo-napieciowy, otwierajac wylacznik szybki
(w obu przypadkach wylacznik nie ma efektu jesli pojazd ma dodatkowe zrodlo zasilania w postaci aktywnego polaczenia WN)
Wszystko działa :) Co do wydajności małej sprężarki, to racja, dobry pomysł żeby na razie zostawić, a później tak jak pisałem, trzeba by zmniejszyć gdzieś do 1/3 obecnej wydajności. Natomiast całkiem idealnie by było, gdyby przy takim jej zablokowaniu w ogóle się sama nie wyłączała, tylko pompowała bez przerwy, ale żeby ciśnienie nie rosło powyżej tych 0,48MPa. Chodzi o to, że w rzeczywistości podparcie stycznika (co jest bardzo częstą praktyką, bo nikomu się nie chce trzymać przez 2min. załączonego hebelka impulsowego ;) ), powoduje całkowite pominięcia wyłącznika ciśnieniowego, ponieważ przez jego styki zasilana jest cewka tego stycznika z hebelka, więc jeśli stycznik jest podparty, to jego styk główny jest cały czas zamknięty i sprężarka pompuje takie ciśnienie, jakie tylko da radę napompować, ale za to bez przerwy. Efekt jest taki, że po pierwsze ją słychać*, a po drugie ciśnienie powietrza zasilającego pantografy nie maleje. I jeszcze jeśli jest tak zablokowana, to powinna się wyłączyć przy wyłączonej przetwornicy i baterii, bo wtedy po prostu nie ma zasilania, a po załączeniu baterii z powrotem załączyć.

*Proponuję zmienić sobie w *.mmd lokomotyw dźwięk małej sprężarki na poniższy, bo jest duuużo bardziej realistyczny od obecnego. Aż się przyjemniej uruchamia lokomotywę ;)
small-compressor: en57_compressor_v1_start.wav,en57_compressor_v1.wav,en57_compressor_v1_stop.wav 200
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 29 Kwietnia 2017, 18:22:07
Natomiast całkiem idealnie by było, gdyby przy takim jej zablokowaniu w ogóle się sama nie wyłączała, tylko pompowała bez przerwy, ale żeby ciśnienie nie rosło powyżej tych 0,48MPa.
Zeby bylo smieszniej to tak przez chwile bylo, ale w kodzie oryginalnie byl wylacznik i myslalem ze tak jest poprawnie :)  Mozna to zmienic zeby sie nie wylaczala, chociaz moze to tez zalezy od konkretnego typu lokomotywy?

A propos dzwieku, to .mmd dla kibli nie maja zdefiniowanego dzwieku sprezarki pantografow dla srodkowgo czlonu, ktos musialby dodac, bo bez tego pompuje sie po cichu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 29 Kwietnia 2017, 18:28:55
Tzn. przy normalnym trzymaniu [Shift]+[V] będąc w przedziale maszynowym ma się wyłączyć przy 0,48MPa i dać ponownie załączyć dopiero po spadku poniżej 0,38MPa, ale za to przy "podparciu stycznika" (wciśnięcie [Shift]+[V], puszczenie najpierw [Shift] i później [V]) ma się dać załączyć przy każdym ciśnieniu i pracować bez przerwy (o ile załączona jest bateria lub przetwornica). Albo jak Ci wygodniej, to to puszczanie klawiszy w odwrotnej kolejności przy "podpieraniu" można zastąpić przez [Ctrl]+[V], także to już jak wolisz...

Edit: Wróć, [Ctrl]+[V] przestawia przecież kurek ;) W takim razie [Ctrl]+[Shift]+[V]? Wymagane do uruchomienia lokomotywy nie jest, więc może chyba mieć nieco bardziej skomplikowaną kombinację ;)
Albo normalne uruchomienie dać pod samo [V], jak było kiedyś, a z podparciem pod [Shift]+[V]...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 29 Kwietnia 2017, 18:40:39
Jak juz to zacznie dzialac, wlasciwie juz zaczelo, to dla takich jak ja trzeba zrobic instrukcje uruchamiania na zimno (jakas czeklista).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 29 Kwietnia 2017, 18:40:46
Ctrl+V jest teraz uzywany dla kontroli kurka trojdrogowego. To brzmi troche bardziej skomplikowanie, wiec na razie chyba zostawie po prostu jak jest -- exe nie ma za bardzo mozliwosci wykrycia ze "podparto stycznik" i nawet gdyby zaczac cos kombinowac to wylaczaloby sie przy przechodzeniu przez przedzial co czasami byloby pozadane, a czasami nie. Co najwyzej jak znajde chwile to dopisze blokade po osiagnieciu 4.8, bo w tej chwili nie ma.
(uzaleznienie od zasilania jest obecne ale z tego co widze uwzglednia tylko baterie i nie wylacza dzwieku. poprawi sie :d

edit:
Jak juz to zacznie dzialac, wlasciwie juz zaczelo, to dla takich jak ja trzeba zrobic instrukcje uruchamiania na zimno (jakas czeklista).
Uruchomienie jest bardzo podobne do startu 'normalnego, przynajmniej dla pojedynczych lokomotyw i EZT. Glowna roznica to taka, ze po zalaczeniu kierunku, baterii i zgaszeniu czuwaka idziemy sobie do przedzialu maszynowego (klawisz End), wlaczamy tam sobie ekran F3 zeby bylo wygodniej a nastepnie
* ctrl + V zeby przelaczyc kurek trojdrogowy na sprezarke pantografow (w EZT nie trzeba), przelaczenie jest widoczne w drugiej linii we wpisie "pant" jako "|ZG"
* wciskamy i przytrzymujemy shift + V az wartosc cisnienia pokazana dla zbiornika pantografow (wpis "pant" w drugiej linii ekranu F3) osiagnie wartosc 3.8-4.0
* wracamy do kabiny (klawisz Home) i konczymy normalnie rozruch
* trzeba pamietac by po napelnieniu sprezarka glowna przewodu zasilajacego do wartosci powyzej 3.5 udac sie ponownie do przedzialu maszynowego i przestawic kurek trojdrogowy na pozycje "<ZG", uzywajac ponownie ctrl + V. Inaczej cisnienie powoli zejdzie ze zbiornika, patyki opadna i trzeba bedzie rozruch zaczynac od poczatku :P
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 29 Kwietnia 2017, 21:21:16
Czyli w praktyce wyglada to tak, ze startujac 'na pusto' wystarczy napompowac nieco powyzej 2.5 atm, tak zeby patyki sie podniosly, i mozna wtedy zamknac wylacznik szybki, i uruchomic przetwornice i sprezarke glowna, ktora juz nabije ile trzeba. Czyli w pewnym sensie tak, jakby zwarcie PWR bylo wlaczone domyslnie (i usuwalo sie samoczynnie po dobiciu do 4.6)

No dobra, aktywuje się przy 4.8, spadnie do 3 i co? Jak rozumiem nie odpalę przetwornicy, tylko mogę wówczas jedynie pompować małą do 4.6?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 29 Kwietnia 2017, 21:42:41
No podobno jak w przewodzie spadnie tak nisko to i tak jakis wiekszy problem jest, a napraw w symulatorze jeszcze nie ma :)

(to raczej jest odrebny problem niz uruchamianie od zera, ale jesli jest jakies szczegolne zapotrzebowanie to mozna by dodac jakas kombinacje dla 'zwarcia pwr' tylko jak to sie konretnie objawia, usuwa 'blokade' na przetwornicy i pozwala ja wlaczyc takze przy nizszym cisnieniu?)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 29 Kwietnia 2017, 23:37:02
Znaczy no to jest proces uruchamiania się na nowo. Załóżmy, że ktoś celowo chciałby zobaczyć co się stanie gdy spadnie ciśnienie np... Zobaczy, że wyłączy mu się przetwornica i przez to nie załączy też sprężarki. Chciałby wrócić jednak do normalnej symulacji i pytam jakie ma opcje wtedy :P
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 30 Kwietnia 2017, 00:21:31
Witam.
 Albo ja coś sknociłem, albo na najnowszej wersji exe Tmj, w ET41 nie działa prawidłowo zawór rozrządczy hamulca. Do bodaj piątej pozycji kranu brak ciśnienia w cylindrach hamulcowych. Rośnie dopiero po daniu w nagłe. Zaraz sprawdzę inne loki.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 30 Kwietnia 2017, 00:24:45
Edit: Przy okazji znalazłem błąd z hamulcami niewystępujący na exe borlandowym. Kiedy uruchamia się jakikolwiek pojazd bez powietrza (dopisek ".BQ" do numeru sprzęgu), przestają w nim działać hamulce, tzn. cylindry hamulcowe nie napełniają się przy spadku ciśnienia w przewodzie głównym. Dodatkowo po zahamowaniu lokomotywy hamulcem pomocniczym słychać jakieś syczenie, które ustaje dopiero po ruszeniu z miejsca.
Powodem błędu z hamulcami jest prawdopodobnie samoczynnie załączający się przy starcie symulacji odluźniacz, który przez cały czas spuszcza powietrze z cylindrów. Wskazuje też na to samoczynne napełnianie przewodu głównego po przestawieniu kranu głównego w pozycję jazdy lub napełnienia, także wtedy, gdy ciśnienie w przewodzie głównym jest mniejsze niż 0,28MPa - normalnie trzeba w takiej sytuacji użyć właśnie odluźniacza. Dopiero po naciśnięciu [Num4] (odblokowaniu odluźniacza) hamulce działają poprawnie. Jeśli już, to pojazd powinien się uruchamiać z zerowym ciśnieniem w cylindrach, ale nie z zablokowanym w stanie załączonym odluźniaczem.
Ostatnio (nie pamięta od której wersji) coś syczy po wczytaniu scenerii, myślałem że to AI, bo często w debugmode odpalam.
Widać przy zwykłym uruchamianiu z powietrzem na starcie jest ten sam błąd. Ostatnimi czasy uruchamiam tylko bez powietrza, więc sam nie wykryłem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 30 Kwietnia 2017, 00:34:21
 Jak na mój gust to nie to. Odluźniacz działa normalnie. Na EP07 hamulce też opornie reagują. Dopiero gdy ciśnienie spadnie do ok 0,4 atm w PG, zaczyna rosnąć ciśnienie w cylindrach hamulcowych lokomotywy. Czy tak powinno być?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 30 Kwietnia 2017, 00:55:29
Nie potwierdzam. U mnie przy normalnym starcie (nie bez powietrza) wszystko działa prawidłowo. Sprawdziłem EP07-424 i ET41-001 (załączniki).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 30 Kwietnia 2017, 01:31:29
Znaczy no to jest proces uruchamiania się na nowo. Załóżmy, że ktoś celowo chciałby zobaczyć co się stanie gdy spadnie ciśnienie np... Zobaczy, że wyłączy mu się przetwornica i przez to nie załączy też sprężarki. Chciałby wrócić jednak do normalnej symulacji i pytam jakie ma opcje wtedy :P
No jak sie strasznie uprze to moze posadzic sobie kota na przycisku od sprezarki pantografow i ona powoli bo powoli, ale ostatecznie da rade napelnic. Ja tutaj zakladam ze ktos, kto nie wie co sie stanie zrobi rownie wielkie oczy jak przeczyta np. "ctrl+alt+del: zwarcie pwr" w dokumentacji, wiec umieszczenie takiej opcji akurat takiej osobie specjalnie nie pomoze ;> (z doswiadczenia pisze, bo do tej pory nie wiem co to wlasciwie znaczy pwr i awr, nie mowiac o szczegolach dzialania)

Niemniej zrobic mozna, dlatego zapytalem czy wyzerowanie flagi 'przetwornica zablokowana' co pozwoli ja w takiej sytuacji uruchomic przy nizszym cisnieniu odwzorowalo by w dostatecznym stopniu funkcje tego zwarcia, czy trzeba by kombinowac bardziej?

edit:
Witam.
 Albo ja coś sknociłem, albo na najnowszej wersji exe Tmj, w ET41 nie działa prawidłowo zawór rozrządczy hamulca. Do bodaj piątej pozycji kranu brak ciśnienia w cylindrach hamulcowych. Rośnie dopiero po daniu w nagłe. Zaraz sprawdzę inne loki.
U siebie tego nie widze -- mam sklad 30 wagonow towarowych, start normalnie napelniony, dalem mu chwile na zluzowanie hamulcow, rozpedzilem do 40 km/h i po ustawieniu na hamowanie wstepne num8 zaczal sie normalnie napelniac, jak w zalaczniku.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 30 Kwietnia 2017, 12:51:32
Chciałbym, aby ktoś też to sprawdził. Całkowo 2, scenariusz SU45-022. Po manewrach czekam na przyprowadzony skład, dostaje ms2, więc jadę i dopinam się do składu. Dostaje rozkład i na minutę przed odjazdem wciskam shift+2. kierpoć wydaje rozkaz odjazdu i... no możemy jechać, ale mam wrażenie że AI nie potrafi odhamować składu jeśli podepniemy się przewodem hamulcowym i jednocześnie przewodem zasilającym (klikamy na insert 3x). Lokomotywa co prawda rusza, ale wygląda, że AI nie potrafi do końca odhamować składu. AI zwiększa prąd aż do wywalenia nadmiarowego, załącza i znów tak samo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 30 Kwietnia 2017, 16:52:30
Nie moge sprawdzic bo mi tarcza nie daje sygnalu jazdy ;/ Do AI nie zagladalem, ale z tego co pamietam to chyba nie probuje ruszyc z miejsca dopoki cisnienie w hamulcach calego skladu nie zejdzie ponizej 0.4

edit:
a propos dziwnego zachowania w ukladzie hamulcowym.
@youBy znalazlem w UpdatePiprePressure() cos takiego:
        if( ( BrakeHandle == FV4a )
         && ( ( PipePress < 2.75 )
           && ( ( Hamulec->GetStatus() & b_rls ) == 0 ) )
         && ( BrakeSubsystem == ss_LSt )
         && ( TrainType != dt_EZT ) ) {
            temp = PipePress + 0.00001;
        }
        else {
            temp = ScndPipePress;
        }
W praktyce oznacza to, ze na niektorych lokomotywach jesli cisnienie w przewodzie hamulcowym jest ponizej 2.75 to nalezy wcisnac i trzymac odluzniacz dopoki nie nabije powyzej tej wartosci, bo inaczej przewod w ogole sie nie napelni, bez wzgledu na cisnienie w zbiorniku glownym/przewodzie zasilajacym. Czy to jest odwzorowanie jakiegos rzeczywistego mechanizmu, czy cos jest tutaj nie tak? o.O
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 30 Kwietnia 2017, 18:53:12
W praktyce oznacza to, ze na niektorych lokomotywach jesli cisnienie w przewodzie hamulcowym jest ponizej 2.75 to nalezy wcisnac i trzymac odluzniacz dopoki nie nabije powyzej tej wartosci, bo inaczej przewod w ogole sie nie napelni, bez wzgledu na cisnienie w zbiorniku glownym/przewodzie zasilajacym. Czy to jest odwzorowanie jakiegos rzeczywistego mechanizmu, czy cos jest tutaj nie tak? o.O
Tak, w rzeczywistości jest coś takiego jak zawór odcinający, który właśnie uniemożliwia samoczynne napełnienie przewodu hamulcowego przez kran (nawet w pozycji napełnienia), jeśli ciśnienie w przewodzie hamulcowym spadnie poniżej 0,28MPa. Chodzi o to, aby przy samoczynnym hamowaniu nagłym wywołanym przez zadziałanie czuwaka, SHP lub radio-stopu, kran nie pompował powietrza w przewód hamulcowy, który w takiej sytuacji jest połączony innym elektrozaworem z atmosferą i aby nie opóźniał tym hamowania w sytuacji niebezpiecznej. Żeby ponownie napełnić przewód hamulcowy, trzeba ustawić kran najlepiej w pozycję napełnienia i przytrzymać wciśnięty przycisk odluźniacza, który ponownie zasili wspomniany zawór odcinający umożliwiając napełnienie przewodu hamulcowego. Przycisk odluźniacza trzeba trzymać wciśnięty dotąd, aż ciśnienie w przewodzie hamulcowym wzrośnie powyżej 0,39MPa, co spowoduje zamknięcie styku wyłącznika ciśnieniowego czuwaka, który zbocznikuje styki przycisku odluźniacza i zawór odcinający pozostanie zasilony do następnego spadku ciśnienia w przewodzie hamulcowym poniżej 0,28MPa.
Problem z hamulcami jest natomiast taki, że przy nastawie hamulca "BQ" (start bez powietrza w ZG), lokomotywy startują z zablokowanym w stanie załączonym odluźniaczem, który bez przerwy spuszcza powietrze z cylindrów do momentu jego odblokowania przez wciśnięcie [Num4] i wtedy już hamulce działają poprawnie. Drugi efekt tego błędu jest taki, że nie ma sposobu działania opisanego powyżej, ponieważ przycisk odluźniacza jest jakby cały czas wciśnięty i przewód hamulcowy nawet z zerowego ciśnienia sam napełnia się po przestawieniu kranu w pozycję jazdy czy napełnienia.
Do tego z hamulcami jest jeszcze inny błąd "od zawsze". Użycie odluźniacza nie powinno powodować problemów z przyhamowaniem przy poślizgu i napełnianiem cylindrów przy normalnym hamowaniu przez spuszczanie powietrza z przewodu hamulcowego. Chodzi o to, że teraz kiedy użyje się odluźniacza, to przez jakiś czas po tym (już po puszczeniu jego przycisku) cylindry hamulcowe wcale lub bardzo opornie napełniają się podczas hamowania kranem głównym czy też podczas próby przyhamowania przeciwpoślizgowego.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: MichałŁ w 30 Kwietnia 2017, 19:00:28
Cytuj
Chodzi o to, że teraz kiedy użyje się odluźniacza, to przez jakiś czas po tym (już po puszczeniu jego przycisku) cylindry hamulcowe wcale lub bardzo opornie napełniają się podczas hamowania kranem głównym czy też podczas próby przyhamowania przeciwpoślizgowego.
A dzieje się tak dlatego, że maszynowy przeciwpoślizg jest zasilany ze zbiornika sterującego. W rzeczywistości jest zasilany ze zbiornika o stałym ciśnieniu 5 bar. Dlatego kiedy wyluzujemy lokomotywę czyli obniżymy ciśnienie w zbiorniku sterującym to nie ma wystarczającego ciśnienia do wysterowania hamulca przeciwpoślizgowego.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 30 Kwietnia 2017, 19:10:05
Problem z hamulcami jest natomiast taki, że przy nastawie hamulca "BQ" (start bez powietrza w ZG), lokomotywy startują z zablokowanym w stanie załączonym odluźniaczem, który bez przerwy spuszcza powietrze z cylindrów do momentu jego odblokowania przez wciśnięcie [Num4] i wtedy już hamulce działają poprawnie. Drugi efekt tego błędu jest taki, że nie ma sposobu działania opisanego powyżej, ponieważ przycisk odluźniacza jest jakby cały czas wciśnięty i przewód hamulcowy nawet z zerowego ciśnienia sam napełnia się po przestawieniu kranu w pozycję jazdy czy napełnienia.
No wlasnie ja ten efekt zauwazylem dopiero po usunieciu automatycznego zalaczenia rozluzniacza przy wpisie BQ, bo mi sie przewod przestal napelniac :>

Co do tego drugiegu bledu to tutaj pewnie musialby sie przyjrzec fachowiec, ja tam predzej cos zepsuje niz naprawie...

edit: aha, wiec zeby to naprawic trzeba by dodac do system dodatkowy zbiornik, ktory sie tym zajmuje?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 30 Kwietnia 2017, 19:58:36
a propos dziwnego zachowania w ukladzie hamulcowym.
@youBy znalazlem w UpdatePiprePressure() cos takiego:

W praktyce oznacza to, ze na niektorych lokomotywach jesli cisnienie w przewodzie hamulcowym jest ponizej 2.75 to nalezy wcisnac i trzymac odluzniacz dopoki nie nabije powyzej tej wartosci, bo inaczej przewod w ogole sie nie napelni, bez wzgledu na cisnienie w zbiorniku glownym/przewodzie zasilajacym. Czy to jest odwzorowanie jakiegos rzeczywistego mechanizmu, czy cos jest tutaj nie tak? o.O
Tak ma być – znaczy prawie. W rzeczywistości jest wyłącznik ciśnieniowy zasilania zaworu maszynisty (nie wiem, czy on też jednocześnie nie odcina zasilania styczników liniowych). Wyłącza się on poniżej 2,8 bar w PG (zawór nie ma zasilania), załącza się on powyżej 4,6 bar (zawór działa normalnie). Z racji różnych takich innych powodów pascalowych została zrobiona wersja bez histerezy. Trzeba tam dodać: zmienną bool (stan wyłącznika) oraz dwa ciśnienia wczytywane z fiza (BPPOn i BPPOff). Po ustawieniu absurdalnych wartości od razu uzyska się możliwość symlacji braku takiego wyłącznika.
Podobnie powinno być z wyłącznikiem ciśnieniowym na cylindrze – flaga + 2 wartości progowe. Obecnie działa to tak, że rozłącza zawsze powyżej 2 bar, a styczniki da się załączyć przy wejściu na 1 pozycję poniżej 1 bar. Zamiast tego powinno to być oparte na fladze.

Kompletnie z innej beczki, czy ktos z majacych do czynienia z kodem orientuje sie, jak wlasciwie sa zorganizowane HVCouplers ?
Mniej więcej – HVCouplers[sprzęg][parametr]. Sprzęg to numer sprzęgu, parametr=0 oznacza prąd, parametr=1 oznacza napięcie. ZTCP to napięcia są przesyłane wzdłuż składu "na krzyż" — napięcie odczytane z sąsiada 0 jest podawane na sprzęg 1.

Cytuj
Chodzi o to, że teraz kiedy użyje się odluźniacza, to przez jakiś czas po tym (już po puszczeniu jego przycisku) cylindry hamulcowe wcale lub bardzo opornie napełniają się podczas hamowania kranem głównym czy też podczas próby przyhamowania przeciwpoślizgowego.
A dzieje się tak dlatego, że maszynowy przeciwpoślizg jest zasilany ze zbiornika sterującego. W rzeczywistości jest zasilany ze zbiornika o stałym ciśnieniu 5 bar. Dlatego kiedy wyluzujemy lokomotywę czyli obniżymy ciśnienie w zbiorniku sterującym to nie ma wystarczającego ciśnienia do wysterowania hamulca przeciwpoślizgowego.
Nieprawda — maszynowy przeciwpoślizg jest zasilany ze zbiornika pomocniczego, a sam sygnał sterujący chyba z niczego. Sęk w tym, że odluźniacz odluźnia zbiornik sterujący do atmosfery zamiast wyrównać go z komorą wstępną zaworu rozrządczego. Stąd też na głównym przyrządzie rozrządczym pojawia się siła skierowana w dół, której sterowanie przyhamowaniem przeciwpoślizgowym nie jest w stanie przezwyciężyć. Teoretycznie powinno wystarczyć w kodzie (sorki, że wyjadę jeszcze z Pascalem) w funkcji TLSt.GetPF zrobić taki manewr (odkomentowanie dV1 i implsres, zmiana BCP na VVP):
if(BrakeStatus and b_rls=b_rls)then
   if(CVP<1*0)then
     BrakeStatus:=BrakeStatus and 247
   else
    begin           //008
     dV:=PF1(CVP,VVP,0.024)*dt;
     CntrlRes.Flow(+dV);
     dV1:=+dV; //minus potem jest
     ImplsRes.Flow(-dV1);
    end;
tylko miałem kiedyś wrażenie, że coś tu jest jeszcze nie tak :(
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 30 Kwietnia 2017, 20:08:01
Nie moge sprawdzic bo mi tarcza nie daje sygnalu jazdy ;/ Do AI nie zagladalem, ale z tego co pamietam to chyba nie probuje ruszyc z miejsca dopoki cisnienie w hamulcach calego skladu nie zejdzie ponizej 0.4
No niby nie powinna ruszyć, ale macha kołem aż do puszczenia wyłącznika szybkiego i powtarza to wielokrotnie, bez wyraźnego wzrostu prędkości. Spróbowałem pociągnąć sam, efekt jakbym ciągnął wór kartofli po ziemi. Pozostaje spróbować jazdy tylko z jednym przewodem powietrznym.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 30 Kwietnia 2017, 20:20:23
W rzeczywistości jest wyłącznik ciśnieniowy zasilania zaworu maszynisty (nie wiem, czy on też jednocześnie nie odcina zasilania styczników liniowych).
Tu by się coś przydało. Przy testowaniu wagonów wyszło, że przy pociągnięciu awaryjnego w wagonie, ai próbuje ciągnąć aż mu nadmiarowy wywali, a może i luzować, opóźniając zatrzymanie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 30 Kwietnia 2017, 20:25:39
Tak ma być – znaczy prawie. W rzeczywistości jest wyłącznik ciśnieniowy zasilania zaworu maszynisty (nie wiem, czy on też jednocześnie nie odcina zasilania styczników liniowych). Wyłącza się on poniżej 2,8 bar w PG (zawór nie ma zasilania), załącza się on powyżej 4,6 bar (zawór działa normalnie).
Wyłącznik, o którym piszesz (przynajmniej w EU07 i pochodnych) nazywa się wyłącznikiem ciśnieniowym czuwaka. Powinien załączać się przy ciśnieniu powyżej 3,9bar i tak, powinien też wyłączać styczniki liniowe w momencie rozłączenia styku poniżej 2,8bar - zgłoszenie jest w Bugtrackerze:
Cytat: Stele/miko22 link=issue=276.com915#com915 date=1476608869
- brak odwzorowania wyłącznika ciśnieniowego czuwaka, który powinien wyłączać styczniki liniowe, gdy ciśnienie w przewodzie głównym spadnie poniżej 2,8bar (to samo dla EU/EP07/08 i być może innych);
Jako ostatnie na liście: http://eu07.pl/forum/index.php?issue=276.0
Edit: Trochę więcej informacji do powyższego linku jest tutaj: http://eu07.pl/forum/index.php/topic,28316.msg427825.html#msg427825 Dopiero następnego dnia Stele utworzył zgłoszenie w Bugtrackerze na podstawie mojego postu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: MichałŁ w 30 Kwietnia 2017, 22:09:55
Cytuj
Nieprawda — maszynowy przeciwpoślizg jest zasilany ze zbiornika pomocniczego, a sam sygnał sterujący chyba z niczego.
A no to też wiele wyjaśnia.

Jeszcze wykryłem taki błąd podczas używania syreny zawór wydaje dźwięk hebelka. w rzeczywistości takie coś nie występuje.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 30 Kwietnia 2017, 22:57:20
MK1991 chwalił się kompletem dźwięków przełączników wszelakich do ET22, tak by motywować do dodania dedykowanych dźwięków do każdego z przełączników.
----------
Pojawiły się w błędach wpisy:
Scale of 0.0 defined for sub-model "pedaly" in 3d model "dynamic\pkp\ep05_v2\05]kabina_a.e3d". Forcing scale of 1.0 to prevent division by 0Dla sand_bt: pedaly mov 0 0 0 Czyli przełącznika-widmo. Do którego parametru się to odnosi? Da się zrobić jeszcze animację o zerowym zakresie?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Maja 2017, 14:54:53
Skala to pierwszy z trzech podawanych parametrow liczbowych. Technicznie rzecz biorac tam nigdy nie bylo animacji o zerowym zakresie -- podanie skali 0 powodowalo "wyliczenie" wartosci nieokreslonej co mialo efekt uboczny kompletnego rozsadzenia przelacznika od srodka. Jesli faktycznie jest zapotrzebowanie na animacje ktora nic nie animuje, moge dodac cos w stylu typu animacji "none" ktora nie robi nic (ale nie psuje kalkulacji stanu przelacznika) z tym, ze nie wiem czy ma to specjalnie sens -- rozumiem ze to jest uzywane jako prowizorka by 'na szybko' dodac przycisk, bez ustawienia mu prawidlowej animacji ktora powinien miec?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 01 Maja 2017, 14:56:29
Dokładnie. Można tam różnie dobrze dać jakiś mikroprzesunięcie w sumie.

I mamy wysyp. Drawinowo170417, en57akł.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Maja 2017, 16:36:25
Wysypalo sie gdzies w sterowniku graficznym ATI, i to tak brzydko ze nie ma zadnej informacji z ktorego miejsca w samym exe :<

A z innej beczki, drobne uaktualnienie:

- eksperymentalne, pojazdy z wpisami .BQ lub innymi wymuszajacymi oproznienie ukladu hamulcowego nie maja na starcie automatycznie zalacznonego odluzniacza

- poprawiona kalkulacja pradow i napiec z podlaczonych kabli WN, bo tak jak podejrzewalem, przy okazji naprawiania takze tutaj napsulem :d

- eksperymentalne, dodana poprawka od @youBy dla interakcji miedzy odluzniaczem i pozostalymi elementami ukladu hamulcowego

- wielkosc wycieku powietrza ze zbiornika pantografow zalezy od panujacego w nim cisnienia; w rezultacie napelnienie zbiornika do wyzszych wartosci moze potrwac nieco dluzej niz poprzednio
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 01 Maja 2017, 17:33:23
- eksperymentalne, pojazdy z wpisami .BQ lub innymi wymuszajacymi oproznienie ukladu hamulcowego nie maja na starcie automatycznie zalacznonego odluzniacza
- wielkosc wycieku powietrza ze zbiornika pantografow zalezy od panujacego w nim cisnienia; w rezultacie napelnienie zbiornika do wyzszych wartosci moze potrwac nieco dluzej niz poprzednio
Działa bardzo dobrze :)
- eksperymentalne, dodana poprawka od @youBy dla interakcji miedzy odluzniaczem i pozostalymi elementami ukladu hamulcowego
A to bardzo namieszało... Chyba zrobiło się jakieś połączenie z przewodem głównym. Odhamuj skład, zahamuj na [Num2], a później poluzuj na [Num8] albo odhamuj na [NumDel] i trzymaj wciśnięty odluźniacz - wskazówka manometru cylindrów leci na 0,7MPa :O
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 01 Maja 2017, 19:00:24
EN57 teraz bezpośrednio po starcie mi hamuje, testowane na td (ale nie startuje w miejscu eu07 tylko napompowany na torze obok).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Maja 2017, 19:17:53
Bede mogl to sprawdzic jesli mi podasz lopatologicznie co trzeba wpisac w td zeby wystartowac "na torze obok"  Sprobowalem postawic sklad na tor_st1 (co prawda oprozniony, i napelniony recznie) i jezdzi normalnie, bez hamowania.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 01 Maja 2017, 19:54:30
Łap mój plik td.scn
Myślałem, że to się stało, bo przypadkowo nacisnąłem num 4 ale jednak nie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 01 Maja 2017, 20:15:24
Jeśli chodzi o SU45, to
Nie moge sprawdzic bo mi tarcza nie daje sygnalu jazdy ;/ Do AI nie zagladalem, ale z tego co pamietam to chyba nie probuje ruszyc z miejsca dopoki cisnienie w hamulcach calego skladu nie zejdzie ponizej 0.4
aby nie szarpać się z tm21 odpal to:
calkowo_v2_osobA_jar.scnTrzeba dojechać w perony, stanąć przed W4 i włączyć AI. Jednak nie ma znaczenia czy łączymy jednym, czy dwoma wężami powietrznymi. Im więcej wagonów tym większe wariactwa wyczynia AI.
Na Całkowie 2 mam niestety od diabła wysypów, o ile na Kaliskiej jestem w stanie zawsze przejechać obie misje oficjalnie dostępne, to na nowym Całkowie mało kiedy udaje się dojechać do końca. Można by to ostatecznie rozwiązać na końcu prac... Tylko co jak się nie da? Po za tym testowanie określonych zachowań w środku jakiejś scenerii jest stresujące: czy nie wywali exeka wcześniej.  Jak daleko są prace stabilizujące wysypy, dla mnie to teraz priorytet?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Maja 2017, 21:36:21
Czy w tym scenariuszu na calkowo 2 musze cos dodatkowo kombinowac? Bo uruchomilem z domyslnym pociagiem, poczekalem na sygnal manewrowy, wlaczylem AI i ona sie elegancko dokulala do peronow, a o wlasciwej godzinie odjechala sobie jak trzeba. Tak samo regio z EU07 ktory stal tam zaparkowany i odjechal pare minut wczesniej, takze bez szarpania ani zadnych dziwnych wyczynow?

Co do wysypow trudno powiedziec, nie znajac przyczyn -- te, o ktorych wiem (z generowaniem geometrii skrzyzowan itp) przytrafiaja sie na poczatku scenariusza a nie w trakcie. W trakcie przytrafiaja sie bledy skanowania, ale te z kolei ciezko wylapac. Dobrze byloby, gdyby ktos mogl sprawdzic wersje z poprawkami @firleju, czy tam takich wysypow nie ma. Dodatkowo na calkowie sa chyba jakies dziwne konstrukcje, przy wlaczonym debug mode w logu pojawia sie masowo cos takiego:
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
eu07-133 dociskanie...
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on cal_most01:0 - cal_most05:1 connected to cal_most02:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
0! Coupler warning on cal_most05:0 - cal_most02:1 connected to cal_most04:1
1! Coupler warning on cal_most05:0 - cal_most02:1 connected to cal_most04:1
eu07-133 dociskanie...
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
0! Coupler warning on cal_most05:0 - cal_most02:1 connected to cal_most04:1
1! Coupler warning on cal_most05:0 - cal_most02:1 connected to cal_most04:1
0! Coupler warning on cal_most05:0 - cal_most02:1 connected to cal_most04:1
1! Coupler warning on cal_most05:0 - cal_most02:1 connected to cal_most04:1
1! Coupler warning on cal_most01:0 - cal_most05:1 connected to cal_most02:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on cal_most05:1 - cal_most02:1 connected to cal_most04:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on cal_most01:0 - cal_most05:1 connected to cal_most02:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on cal_most01:0 - cal_most05:1 connected to cal_most02:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on cal_most01:0 - cal_most05:1 connected to cal_most02:1
1! Coupler warning on cal_most01:0 - cal_most05:1 connected to cal_most02:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
eu07-133 dociskanie...
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on cal_most01:0 - cal_most05:1 connected to cal_most02:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on cal_most01:0 - cal_most05:1 connected to cal_most02:1
1! Coupler warning on cal_most01:0 - cal_most05:1 connected to cal_most02:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on cal_most01:0 - cal_most05:1 connected to cal_most02:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on cal_most01:0 - cal_most05:1 connected to cal_most02:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on cal_most01:0 - cal_most05:1 connected to cal_most02:1
1! Coupler warning on cal_most01:0 - cal_most05:1 connected to cal_most02:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on cal_most01:0 - cal_most05:1 connected to cal_most02:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on cal_most01:0 - cal_most05:1 connected to cal_most02:1
1! Coupler warning on cal_most01:0 - cal_most05:1 connected to cal_most02:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on cal_most01:0 - cal_most05:1 connected to cal_most02:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on cal_most01:0 - cal_most05:1 connected to cal_most02:1
0! Coupler warning on cal_most05:0 - cal_most02:1 connected to cal_most04:1
1! Coupler warning on cal_most05:0 - cal_most02:1 connected to cal_most04:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on cal_most01:0 - cal_most05:1 connected to cal_most02:1
1! Coupler warning on cal_most01:0 - cal_most05:1 connected to cal_most02:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on cal_most01:0 - cal_most05:1 connected to cal_most02:1
I diabli wiedza co to ma byc, albo nawet gdzie tego szukac na mapie -- ktos uzywa lokomotywy zeby skladac z kawalkow most? Co by to nie bylo, symulacji raczej sie to nie podoba ;/
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 01 Maja 2017, 21:45:40
Nie drażni Ciebie to machanie kołem do 2kA i zjeżdżanie do zera? Sprawdzę jutro na borlandowym exe. Proponuje, poczekać na odjazd z peronów. Także dołącz jeśli znajdziesz czas  jeszcze ze 4 wagoniki. Ten pospieszny jest ciężki.Co do EU07, to nie mam zastrzeżeń. Nie wiem skąd wziąć wersję z poprawkami @firleju, chętnie bym pojeździł na tej wersji. Przy lampkach, luzowaniu i syczeniu nie jestem w stanie pomóc.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 01 Maja 2017, 21:55:11
Auta nie mają sprzęgu i gdy się zderzają to w logu mamy takie coś. Zawsze tak było. Nie wiem czy w czymś to szkodzi. Poprawki hamulców i skanowania powinny tu częściowo pomóc, bo by się nie zderzały.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Niebugoclaw w 01 Maja 2017, 23:05:32
Przepraszam, jeżeli problem był już opisany na jednej z 75 stron, ale nie mam czasu, żeby każdą przejrzeć. Czy ktoś jeszcze spotkał się na wersji 64 bitowej z problemem ze smugami świateł? Mianowicie po załączeniu w porze nocnej reflektorów, oświetla się cała sceneria łącznie z kabiną, a nie tylko smuga przed lokomotywą.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Maja 2017, 23:08:05
Nie drażni Ciebie to machanie kołem do 2kA i zjeżdżanie do zera? Sprawdzę jutro na borlandowym exe. Proponuje, poczekać na odjazd z peronów. Także dołącz jeśli znajdziesz czas  jeszcze ze 4 wagoniki.
No rzucanie kolem w te i we wte bylo w exe "od zawsze" bo tak jest AI napisana. Na Borlandowym jest to samo i ja tego kijem nawet nie ruszalem, bo dopoki jezdzi i zatrzumje sie mniej wiecej jak trzeba to sa inne rzeczy ktore sa w gorszym stanie. Z tego co napisales poczatkowo to myslalem ze moze te ostatnie zmiany w hamulcach itp cos tam popsuly w takim stopniu ze AI przestalo jezdzic... ale doczepilem do tej SU dodatkowe wagoniki, spialem wszystko podwojnymi wezami i jeszcze dalem ogrzewanie i przejscia, i ona z tym jezdzi normalnie, tzn tak samo idiotycznie jak zawsze, ale jezdzi.

Przepraszam, jeżeli problem był już opisany na jednej z 75 stron, ale nie mam czasu, żeby każdą przejrzeć. Czy ktoś jeszcze spotkał się na wersji 64 bitowej z problemem ze smugami świateł? Mianowicie po załączeniu w porze nocnej reflektorów, oświetla się cała sceneria łącznie z kabiną, a nie tylko smuga przed lokomotywą.
Raczej sie z tym nie spotkalem; czy to jest na wersji "zwyklej' c++ czy na wersji ng++ z shaderami, od milka? I na jakiejs konkretnej scenerii i/lub ustawieniach, czy wszedzie? log.txt moglby moze troche pomoc, o ile to nie problem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Niebugoclaw w 01 Maja 2017, 23:25:17
Bez shaderów.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 01 Maja 2017, 23:34:22
W zasadzie co mozna chciec od glupiego AI. Zerkne jescze na borlandowe exe, to jedna z wiecej wymagajacych scenerii, dla porow ania wydajnosci. Zreszta exe z paczki tez potrafi sie wysypac z niewiadomych przyczyn.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Maja 2017, 23:37:14
Bez shaderów.
Hmm "karta graficzna" Intela wiec cudow sie tutaj specjalnie spodziewac nie mozna, ale to dosc dziwny efekt nawet jak na Intela :/  Zobacz moze, czy cos sie polepszy przy dodaniu do eu07.ini wpisu dynamiclights 7

edit:
Łap mój plik td.scn
Myślałem, że to się stało, bo przypadkowo nacisnąłem num 4 ale jednak nie.
W tym pliku .scn jest testowa modyfikacja en57 ktorej nie mam. Postawilem wiec zamiast niej na tym miejscu startowym zwykla 1051 z paczki calosciowej
node -1 0 EN57-1051ra dynamic PKP\EN57_V1 EN57-1051RA 6BAII 0 headdriver 247 50 Passengers enddynamic
node -1 0 EN57-1051s dynamic PKP\EN57_V1 EN57-1051S 6BSII 0 nobody 247 0 enddynamic
node -1 0 EN57-1051rb dynamic PKP\EN57_V1 EN57-1051RB 6BBII 0 nobody 39 50 Passengers enddynamic
I ten zestaw jezdzi calkiem normalnie, nie hamuje sam z siebie ani nic.

Z tego co widze w watku testowym ta wersja en57 z ledami nadpisuje istniejace pliki .fiz, wiec byc moze cos tam jest namieszane? Przyznam ze nie bardzo chce mi sie sluzyc pod tym wzgledem za doswiadczalna swinke morska :x
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Niebugoclaw w 02 Maja 2017, 00:14:40
@tmj grafikę mam GeForce'a 950. Spojrzałem teraz, na exe od milka problem nie występuje.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 02 Maja 2017, 00:19:40
Jesli masz GeForce to albo jest one wylaczona w biosie albo w ustawieniach w systemie operacyjnym, bo w logu jak byk zglasza sie wbudowany Intel :)
Gfx Renderer: Intel(R) HD Graphics 5500 Vendor: Intel OpenGL Version: 4.4.0 - Build 20.19.15.4549
(m.in dlatego najwygodniej wylaczyc intela w biosie, przestaje sie wcinac w najmniej odpowiednich momentach)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 02 Maja 2017, 14:08:34
Tym razem zająłem się 64 bitowym exe od @Milek7. Odpaliłem windows7 i od razu załadowałem Kaliską. Sceneria jest wymagająca i duża, stąd pierwsze co napiszę, nie wywaliło mnie. Dojechałem do Łodzi Kaliskiej, bez żadnych przeszkód. Zastrzeżenia są takie same jak do wersji 32 bitowej, a więc nienaturalność świateł, ich rozchwiana równowaga i to co wskazywałem na screenach dołączonych do oceny 32 bitowej wersji. Zalety, to oczywiście skok wydajności w stosunku do wersji fixedpipeline. Jak zwykle grzebałem w bibliotekach, ale tym razem zakres możliwości regulacji okazał się zbyt mały w stosunku do potrzeb. Natomiast exe sypie błędami tak, jakby spadła ulewa. Log ma 485mb a errors 480mb, jestem pod wrażeniem. Wycinek log.txt:
Bad geometry (shape estimation failed) for spline "sr08" at -24578.900000 2.549000 -4299.200000
Bad geometry (shape estimation failed) for spline "sr08" at -24578.900000 2.549000 -4299.200000
Bad geometry (shape estimation failed) for spline "str1" at -23746.800000 0.000000 -4629.200000
Bad geometry (shape estimation failed) for spline "str1" at -23746.800000 0.000000 -4629.200000
Bad geometry (shape estimation failed) for spline "str11" at 27883.300000 0.000000 -6652.300000
Bad geometry (shape estimation failed) for spline "str11" at 27883.300000 0.000000 -6652.300000
Bad geometry (shape estimation failed) for spline "str02" at 28360.000000 0.000000 -6025.000000
Bad geometry (shape estimation failed) for spline "str02" at 28360.000000 0.000000 -6025.000000
Bad geometry (shape estimation failed) for spline "str03" at 29555.100000 0.000000 -3157.500000
Bad geometry (shape estimation failed) for spline "str03" at 29555.100000 0.000000 -3157.500000
Bad geometry (shape estimation failed) for spline "str05" at 22778.200000 0.000000 -5417.500000
Bad geometry (shape estimation failed) for spline "str05" at
jak również w errors:
Bad geometry (shape estimation failed) for spline "sr08" at -24578.900000 2.549000 -4299.200000
Bad geometry (shape estimation failed) for spline "str1" at -23746.800000 0.000000 -4629.200000
Bad geometry (shape estimation failed) for spline "str1" at -23746.800000 0.000000 -4629.200000
Bad geometry (shape estimation failed) for spline "str11" at 27883.300000 0.000000 -6652.300000
Bad geometry (shape estimation failed) for spline "str11" at 27883
Załączam obydwa pliki i ostrzegam, że nie łatwo je otworzyć na słabym kompie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 02 Maja 2017, 19:32:43
@Milek7, przejechałem Całkowo 2 na najnowszej wersji 64 bitowej exe. Dojechałem bez wsypu do Jarkawek. Natomiast ciekawostka jest w załączniku, proszę zwrócić uwagę na wagę plików error i log. Sypie zapisami jak z poprzedniego postu, aż urosło do niebotycznej objętości. Po przelogowaniu sprawdzę czemu tych plików nie zauważyłem w wersji 32 bitowej.

@tmj, na Twojej 64 bitowej wersji ukończyłem Kaliską, misja zaczęta w EN57. Nie mam żadnych zauważalnych różnic, między wersją 32 i 64 bitową.

ED:
@Milek7, wersja 32 bitowa ostatniego C++NG.exe, nie sypie tymi błędami.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 02 Maja 2017, 22:22:57
Uaktualnienie, zanim znowu zapomne co do niego wsadzilem:

- komendy sterujace piasecznica sa teraz przesylane takze do pozostalych uokrotnionych czlonow/pojazdow. Swoja droga trzeba zebrac cala logike sterujaca piasecznica dla AI w jednym miejscu bo teraz sie gryzie sama ze soba, ale to kiedy indziej.

- poprawiona obsluga zmiany predkosci dzialania hamulca dla pojazdow uokrotnionych (exe odfajkowywalo sobie hamulec jako przestawiony w zmiennych movera, natomiast nie dotykalo samego hamulca, ktory zostawal bez zmian)

- poprawka, podobny blad z obsluga stanu hamulca, gdzie niektore flagi byly ustawiane w module pojazdu, ale nie w samym hamulcu

- przy okazji poprawione wyswietlanie flag stanu hamulca na ekranie F3. w rezultacie okazuje sie ze np AI uwielbia jezdzic z permanentnie wcisnietym odluzniaczem (chyba ze akurat probuje zahamowac)

- cofnieta tymczasowo poprawka interakcji odluzniacza z reszta systemu hamulcow, do czasu az komus uda sie wymyslic wersje bez efektow ubocznych :o

- pseudo "poprawka" na brak mozliwosci odjazdu spod W4 niektorymi nowoczesnymi lokomotywami, bo pasazerowie otwieraja sobie drzwi ale zamknac to juz im sie nie chce.

(puscilem dzisiaj AI w trase i mialem nadzieje ze moze uda sie wylapac jakies zrodlo wysypow co to tak mecza ludzi, ale exe zlosliwie mi sie nie wysypuje :/
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 02 Maja 2017, 23:03:19
Zapakowałem Całkowo osobowy z Jarkawek nocą. Wywaliło mnie po 10 minutach i na dziś mam dość. Niestety na XP nie generują się te wysypy. Natomiast mam inny problem, hamowanie zasadniczym SU45 + 3 wagony, manometr cylindrów lokomotywy stoi zawsze na 0. Tak ma być? Zahamowanie pomocniczym daje dopiero ciśnienie w cylindrach hamulcowych.
ED:
Koniec loga:
su45-079 received command: [trainbrakecharging]
Key pressed: [Num Del]
su45-079 received command: [trainbrakecharging]
Key pressed: [Num Del]
su45-079 received command: [trainbrakecharging]
Key pressed: [Num Del]
su45-079 received command: [trainbrakecharging]
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:1 connected to jan_wylotowka08:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
1! Coupler warning on jan_wylotowka06:0 - jan_wylotowka05:0 connected to jan_wylotowka04:1
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 02 Maja 2017, 23:47:32
Witam.
 Sprawdziłem na TD i u mnie suka ze składem Bhp hamuje normalnie. Załączam screen. Jednakże zgłaszałem podobny błąd wcześniej dotyczący ET41. Być może zdarza się on losowo? Tak jak wysypy. Całkowo2 raz chyba udało mi się przejechać do końca.
Pozdrawiam.
Edit: Uruchomiłem Kaliską i dość znacznie wzrósł Fps. W Ostrowie poniżej 45 nie spada.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 03 Maja 2017, 12:46:11
Z tego co zauwazylem, to w lokomotywie hamulec napelnia sie bardziej 'leniwie' na postoju niz w ruchu, ale to akurat chyba jest 'tak jak ma byc' W czasie jazdy raczej nie ma z tym problemow. Inna sprawa jest, ze o ile sie nie myle to hamowanie powinno byc realizowane przede wszystkim przez wagony a nie lokomotywe i miedzy innymi po to wlasnie jest odluzniacz. A w wagonach z tego co widze hamulce chodza normalnie. Tak wiec nie wiem czy tutaj jest problem, trzeba eksperta :o

Jesli poprawa fps jest w ostatnich uaktualnieniach, to zapewne dlatego ze tam jest teraz troche bardziej agresywna regulacja zasiegu widocznosci, po zgloszeniach ze fps mogl byc dosc niski. Wyglada na to ze dziala :)

Uruchomilem nocne Calkowo u siebie i exe co prawda sie nie wysypalo, ale dosc wczesnie zaczelo wyprawiac cuda na kiju, rozdymajac tabelki skanowania z 16 domyslnych do ponad 20 tys. pozycji, wiec nie zdziwilbym sie gdyby tam wlasnie byly problem. Sprobuje sie temu przyjrzec, moze uda sie tam przeszczepic wersje @firleju, a w najgorszym wypadku przynajmniej znalezc i usunac przyczyne.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 03 Maja 2017, 13:38:51
Jesli mamy wagony na haku, to wdrazajac hamowanie zasadnicze powinien nastapic wzrost cisnienia w cylindrach hamulcowych lokomotywy. Owszem, powinnismy hamowac tylko wagonami, stad po wdrozeniu zasadniczego hamowania powinnismy uzyc odluzniacza lokomotywy. Jesli odluzniacza nie uzyjemy, hamowac powinna takze lokomotywa a manometr w kabinie powinien pokazac jakies cisnienie, stosowne do pozycji kranu. W SU45 nie mam cisnienia w cylindrze lokomotywy, mimo braku uzycia odluzniacza przeze mnie. Jesli sie myle, prosze mnie poprawic.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 03 Maja 2017, 13:45:19
No tak jak sobie ogladam AI prowadzaca SU45 po Calkowie, to jej sie hamulec lokomotywy napelnia, wiec nie jest to cos uniwersalnego. Nie wiem, od czego moze (i/lub ma) to zalezec.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 03 Maja 2017, 13:49:59
A ja akurat nie sprawdzalem jak sobie radzi AI. Wczoraj sprawdzalem na dwoch paczkach 64 i 32 bity. Do wieczora zrobie jeszcze jakies proby.
ED:
ciach
 Sprawdziłem na TD i u mnie suka ze składem Bhp hamuje normalnie. Załączam screen. Jednakże zgłaszałem podobny błąd wcześniej dotyczący ET41. Być może zdarza się on losowo? Tak jak wysypy. ciach
Wyglada na to, ze masz racje. Wlasnie walkowalem wersje 32 bitowa i dzis cisnienie w cylindrze hamulcowym rosnie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 03 Maja 2017, 18:24:24
- komendy sterujace piasecznica sa teraz przesylane takze do pozostalych uokrotnionych czlonow/pojazdow. Swoja droga trzeba zebrac cala logike sterujaca piasecznica dla AI w jednym miejscu bo teraz sie gryzie sama ze soba, ale to kiedy indziej.
- poprawiona obsluga zmiany predkosci dzialania hamulca dla pojazdow uokrotnionych (exe odfajkowywalo sobie hamulec jako przestawiony w zmiennych movera, natomiast nie dotykalo samego hamulca, ktory zostawal bez zmian)
- poprawka, podobny blad z obsluga stanu hamulca, gdzie niektore flagi byly ustawiane w module pojazdu, ale nie w samym hamulcu
- przy okazji poprawione wyswietlanie flag stanu hamulca na ekranie F3. w rezultacie okazuje sie ze np AI uwielbia jezdzic z permanentnie wcisnietym odluzniaczem (chyba ze akurat probuje zahamowac)
- cofnieta tymczasowo poprawka interakcji odluzniacza z reszta systemu hamulcow, do czasu az komus uda sie wymyslic wersje bez efektow ubocznych :o
Działa, tzn. w kwestii odluźniacza nie ma błędów z "poprawki" i jednocześnie naprawiły się błędy występujące wcześniej, czyli działa teraz całkowicie poprawnie :) U mnie SU45 też hamuje normalnie, choć jakby lekko ociężale (nie wiem, tak mi się wydaje) - załącznik. Do tego od jakiegoś czasu przy zamykaniu exe normalnie przez F10 i Y wyskakuje mi błąd "Program MaSzyna EU07-424 przestał działać". Log, errors i crashdump w załącznikach.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 04 Maja 2017, 14:11:06
Okazyjnie wyskakujacy blad przy zamykaniu jest dosc stary/losowy, ale poniewaz to jest juz niejako "po ptakach" nie ma zbyt wysokiego priorytetu~

W dzisiejszym uaktualnieniu mamy cos innego, mianowicie probe ograniczenia problemow/wysypow przy skanowaniu.

Nie bardzo wiem czy wersja ktora u siebie zrobil @firleju jest ukonczona i dziala, dlatego tymczasowo zamiast ja przeszczepiac przerobilem istniejaca strukture tabeli na kontener stl. Powinno to zlikwidowac problem z 'zatykaniem' sie tabeli. Przy okazji znalazlo sie tez zrodlo okazjonalnych wysypow (dla zainteresowanych, borlandowe exe dosc optymistycznie zakladalo ze w tabeli zawsze jest przynajmniej jeden tor z ktorym mozna porownywac nowe dane, co w niektorych sytuacjach nie zawsze bylo prawda)

Na ile moge powiedziec zmiana nie usuwa problemu kierowcow-Polakow-samobojcow, bo nawet chociaz teraz czesciej widza signal stop, to samochody z jakiegos powodu wpadaja przy hamowaniu w magiczny poslizg. Dodatkowo jesli przed przejazdem jest juz jeden samochod, to 'zaslania' on przejazd dla nadjezdzajacych z tylu, i w rezultacie ci nadjezdzajacy z tylu wjezdzaja im w kuper. Tak ze tutaj jest jeszcze sporo do rozplatania i poprawienia, natomiast w miedzyczasie prosze o ile to mozliwe sprawdzic czy na nowym exe jest mniej wysypow, i czy nie wylazly przy okazji jakies nowe krzaki w skanowaniu, tzn czy AI widza swoje przystanki, semafory itp.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 04 Maja 2017, 18:32:39
Zobaczyłem autko na TD i jest trochę lepiej. Nie wywala wszystkiego z tabelki, ciągle coś skanuje, ale niestety przejazdy widzi setki metrów od siebie i co aktualizację tabelki odsuwa dalej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 04 Maja 2017, 18:38:06
To jak już przerabiane były przyciski otwierania i zamykania drzwi, to pozostało jeszcze coś zrobić z ich dźwiękami*. Bo przy przy zamykaniu odtwarzany jest dźwięk otwierania.

* - inna sprawa, że sam fakt bycia tych dźwięków jako kabinowe internaldata jest poronione i powinny być razem z brzęczykiem ostrzegawczym jako dźwięk zewnętrzny kolejnych wagonów.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 04 Maja 2017, 19:02:02
Ale z rok temu wywaliłem je do zewnętrznych. A osobne sample mają od zawsze. Nie wiem o czym piszesz. Wewnętrzne zostały skoro były gotowe, można tam hebelki podpiąć.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 04 Maja 2017, 19:12:40
A osobne sample mają od zawsze. Nie wiem o czym piszesz.

O tym, że przy przerabianiu sterowania na "bez shifta" odtwarza się tylko dźwięk otwierania. Dajemy raz < - otwierają się drzwi i jest ok. Dajemy drugi raz < - drzwi się zamykają, ale dźwięk jest otwierania. Chyba, że po podpięciu pod zewnętrzną sekcje to samo magicznie zadziała. Opisuję co się dzieje teraz, gdy jest w internaldata.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 04 Maja 2017, 19:16:43
Zobaczyłem autko na TD i jest trochę lepiej. Nie wywala wszystkiego z tabelki, ciągle coś skanuje, ale niestety przejazdy widzi setki metrów od siebie i co aktualizację tabelki odsuwa dalej.
To jest blad w .scm dla przejazdu, trzeba zamienic miejscami przej_1 i przej_2  Samochody dalej przecinaja szlabany, ale przynajmniej przestaja je gubic ;d

edit
O tym, że przy przerabianiu sterowania na "bez shifta" odtwarza się tylko dźwięk otwierania. Dajemy raz < - otwierają się drzwi i jest ok. Dajemy drugi raz < - drzwi się zamykają, ale dźwięk jest otwierania. Chyba, że po podpięciu pod zewnętrzną sekcje to samo magicznie zadziała. Opisuję co się dzieje teraz, gdy jest w internaldata.
Nie mam tego u siebie. EN57-1012 po pierwszym nacisnieciu (otwieranie) odgrywa zauwazalnie inny dzwiek niz przy nacisnieciu ktore zamyka juz otwarte drzwi. Czy jest szansa ze to blad w .mmd pojazdu ktory testujesz?
edit 2: nie czekaj, sprawdzilem i cos tu jest na rzeczy, przyjrze sie blizej.
edit3: faktycznie bylo skopane, poprawka jest w nastepnym uaktualnieniu
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 04 Maja 2017, 19:26:11
Okej, gdy dźwięk drzwi jest w sekcji sounds - odtwarza się prawie poprawnie. Prawie, bo traktuje to jako jedno źródło dźwięku a nie dwa i gdy operujemy obiema stronami drzwi, w danej chwili odtwarza się tylko raz, przy czym często odtwarza się drugi raz (jak skończy się pierwsza sekwencja dźwięku).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 04 Maja 2017, 19:28:45
To juz niestety jest ograniczenie zwiazane z podczepieniem wszystkich dzwiekow do kabiny, i tylko jednej "kopii" dla kazdego dzwieku -- tak samo jest z wszystkimi dzwiekami przelacznikow itp. To jest do zmiany kiedy przyjdzie czas na ogarniecie ogolnie organizacji dzwiekow (jesli przyjdzie)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 04 Maja 2017, 19:36:25
Przyznam, że wersja jednego dźwięku przerywanego i odtwarzanego na nowo gdy zachodzi potrzeba jest lepsza od wersji "odtworzę raz jeszcze, gdy skończę teraz" ;) Tak porównując stare exe i to odtwarzanie z sekcji sounds.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 04 Maja 2017, 20:07:50
Ale stare przeciez tez tak ma? Az zaladowalem kibla do Borlandowego zeby porownac i jest to samo. Jak skonczy odgrywac zamykanie jednych drzwi to zaczyna odgrywac zamkniecie drugich. Akurat pod wzgledem odtwarzania dzwiekow zmian nie bylo (poza blednym przypisaniem dzwieku otwarcia do zamkniecia)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 04 Maja 2017, 21:35:06
U mnie jak naciskam najpierw jedną stronę, a potem drugą (np. na zamykanie), to odtwarzany dźwięk zamykania pierwszej strony się przerywa i puszcza się od nowa dla drugiej strony drzwi - oczywiście w momencie wciśnięcia klawisza zamykającego tą drugą stronę. I zawsze tak było. Natomiast tutaj odtwarzanie się nie przerywa - odgrywa się dźwięk do końca i potem (w zależności od momentu naciśnięcia klawisza drugiej strony) albo jest cisza (drugi dźwięk nie odtwarza się), albo odtwarza się drugi raz całość.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 04 Maja 2017, 23:18:10
U mnie wyglada to, ze zalezy jak szybko zamkne drzwi jedne po drugich. Jesli poczekam 2-3 sekundy z zamknieciem drugich, to oba dzwieki beda odegrane jeden za drugi, zamiast sobie przerywac. Nie zagladalem do kodu dzwiekow, wiec nie wiem co tam sie dzieje.

Z innej beczki, poniewaz skanowanie wyglada na w miare naprawione, sprawdzilem co sie dzieje z samochodami, i wychodzi na to ze przy biezacej sile hamowania w plikach .fiz dla samochodow wpadaja one w poslizg gdy tylko kierowca wdepnie hamulec odrobine silniej niz 1/10 pelnej sily hamowania. Eksperymentalnie zmienilem wiec wpis MBF w .fiz dla poszczegolnych samochodow:
MBF=1.45 dla osobowych (masa wlasna 1-2 tony lub mniej)
MBF=2.75 dla srednich pojazdow (ok 5-7 ton, jelczostar itp)
MBF=4.75 dla ciezkich autobusow itp (powyzej 10 ton)
... i wszystko zaczelo ladnie hamowac tam, gdzie powinno. W pewnym sensie jest to prowizorka, bo lepiej byloby nauczyc AI by delikatniej operowalo hamulcem, i nie dusilo jeszcze mocniej kiedy wpadnie w poslizg, ale na razie nie ma nawet specjalizacji kierowania dla samochodow, wiec co dopiero mowic o takich szczegolach :d
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 04 Maja 2017, 23:36:53
Udalo mi się ukonczyc Kaliska na scenariuszu towarowym, jednak w ostatniej fazie zatrzymania, gdzie chciałem dac nawrotnik w tym by docisnąć i odczepić się, wywalilo exeka do windy.

Log:
EVENT ADDED TO QUEUE: przejazd34_zapetlaj by et22-811
EVENT ADDED TO QUEUE: przejazd34_otworz1 by et22-811
EVENT LAUNCHED: przejazd34_zapetlaj by et22-811
Multiple passed
EVENT ADDED TO QUEUE: przejazd34_otworz by et22-811
EVENT LAUNCHED: przejazd34_otworz1 by et22-811
Key pressed: [R]
et42-025-b received command: [reverserdecrease]
Key pressed: [R]
et42-025-b received command: [reverserdecrease]
Key pressed: [Num +]
et42-025-b received command: [mastercontrollerincrease]
Bad geometry (shape estimation failed) for spline "" at 28277.100000 0.380000 -6884.700000
Bad geometry (shape estimation failed) for spline "" at 28277.100000 0.380000 -6884.700000
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 05 Maja 2017, 07:36:17
Aaaa.... tak szybko robisz update-y, że nie nadążam z robieniem merge'ów. Ogólnie mam wstępnie działającą wersję, ale chciałbym najpierw ją przetestować na czymś aktualnym. Nie wrzucałem jeszcze na repo. Jak teraz zabawiłeś się tabelką to znowu będę miał zabawę z łączeniem kodu. Ehh...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 05 Maja 2017, 13:02:46
No do tej pory sie wlasnie wstrzymywalem zeby sie nie robily konflikty ale w koncu trzeba bylo to ruszyc :<  Ale z laczeniem nie powinno byc zbyt trudno, w wiekszosci to sa proste wymiany instrukcji petli na takie bez % itp, a nie ingerowanie w to jak ten kod dziala. Wrzuce na githuba dzisiaj troche pozniej tak jak to teraz wyglada, sam bedziesz mogl zobaczyc.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 05 Maja 2017, 13:25:25
Ja to zrobiłem na zwykłym wektorze. I właśnie było trzeba uważać, żeby nie usunąć przez przypadek ostatniego skanowanego toru. Trochę się też nabawiłem, żeby kod może nie uprościć, ale na pewno uporządkować. Za to zastanawia mnie czemu pojazdy nie wykrywają się na drogach wzajemnie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 05 Maja 2017, 13:47:06
@tmj, wydaje się, że twoje poprawki z 20170504 odniosły u mnie skutek. Nie mam wysypów na WINXP32bit. Po raz 3 udało mi się w Całkowie ukończyć jazdę. Natomiast samochody... Te zachowują się różnie, ale jest jakaś poprawa.
Nie wiem czy ta informacja ma jakieś znaczenie, ale: Wczoraj na WIN764bit pojeździłem na na tej samej paczce co na WINXP32bity używałem tego samego exe32 bit 20170502. Różnica jest taka, że na win7 wysypów nie mam wcale a na XP praktycznie tylko raz udało mi się zajechać dalej (cały czas ta sama nocna misja w Całkowo2 z Jarkawek).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 05 Maja 2017, 14:13:18
Ja to zrobiłem na zwykłym wektorze. I właśnie było trzeba uważać, żeby nie usunąć przez przypadek ostatniego skanowanego toru. Trochę się też nabawiłem, żeby kod może nie uprościć, ale na pewno uporządkować. Za to zastanawia mnie czemu pojazdy nie wykrywają się na drogach wzajemnie.
Z tego co obserwuje to wykrywaja sie -- wczoraj jechalem sobie przez Calkowo_v2 i przed zamknietym przejazdem ustawil sie elegancki sznurek chyba tak z szesciu samochodow. I nikt nikomu w kuper nie wjechal, ani nic takiego.

Natomiast samochody... Te zachowują się różnie, ale jest jakaś poprawa.
Jesli chodzi o samochody, to dla pelnej poprawy dzialania potrzebne sa tez, przynajmniej tymczasowo, zmiany parametru sily hamowania w ich plikach .fiz zeby nie wpadaly ciagle w poslizg.

W zalaczniku wersja, ktora mam w tej chwili u siebie -- wystarczy wypakowac do katalogu z symulatorem. Z tym ze uwaga, to jest wersja .fiz z paczki calosciowej, jesli na repo byly jakies uaktualnienia do tych plikow, to ich tam nie ma. (jesli sie komus chce, to moze tez zrobic zmiany recznie, podalem wielkosci parametru do zmiany troche wczesniej w watku)

edit:
male uaktualnienie

- poprawka, przy zamykaniu drzwi pojazdow odtwarzany jest wlasciwy dzwiek

- diagnostyka, tabelka predkosci wyswietla do 30-u pozycji zamiast poprzednich 16. Ekran F1 w trybie debug oprocz predkosci poda tez ostrzezenie "(!)" jesli egzaminowany pojazd jest w poslizgu

- poprawka, ostatni wykryty tor jest umieszczany w tabelce skanowania tylko raz, zamiast 'ile fabryka dala'
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: jakol112 w 05 Maja 2017, 14:55:13
Czy tylko u mnie brak zdefiniowanego submodelu łącznika w kabinie wyklucza użycie funkcji (np. w ED72 syrena i oświetlenie kabiny)? Czy ten błąd jest znany i czy tak ma być?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: jakubg1 w 05 Maja 2017, 15:00:28
Tak, znany, nie, nie ma tak być. Aktualnie tego typu błędy są poprawiane, a jest to skutek uboczny wprowadzenia nowego systemu sterowania.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 05 Maja 2017, 18:49:46
Te wszystkie funkcje które były dawniej możliwe do uzycia bez konieczności posiadania odpowiedniego submodelu, powinny być w dalszym ciągu możliwe do uruchomienia. A tymczasem w Et40 nie ma syreny. Czy możesz przywrocic przynajmniej te stare funkcjonalności tak jak były a tylko najnowsze wprowadzać z tym uzależnieniem? Przy okazji patrzyles na ostatni blad? Co to było i czemu wysypalo?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 05 Maja 2017, 18:58:22
Włodku, jak @tmj przywróci działanie funkcji bez submodelu, to nigdy tego nikt nie poprawi. W założeniach jest, aby nowe exe dodane było do następnej paczki całościowej, to oznacza także wprowadzenie poprawki w starych modelach. Kiedyś trzeba to zrobić.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 05 Maja 2017, 20:54:14
Wygląda, że udało się przenieść moje zmiany na wersję sprzed długiego weekendu. Ciekawy ile rzeczy tam się popsuło przy okazji ;) Już po samym simulation::time jestem pewien, że nie wszystko się nanosi tylko nie wiem czemu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 05 Maja 2017, 22:43:58
Pantografy - sterowanie, radio-stop. Bez zmian.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 06 Maja 2017, 14:09:13
Co znaczy "pantografy - sterowanie?"

Zmiany w dzisiejszym uaktualnieniu:

- diagnostyka, w ramach koncertu zyczen dodany opis parametrow dla asynchronow na ekranie F1 w trybie debug, dostarczony przez @youBy

- przycisk radia obslugiwany jest takze bez zdefiniowanego submodelu 3d, aby umozliwic wylaczenie ewentualnego radio-stopu. Jesli pojazd prowadzony przez uzytkownika otrzyma sygnal radio-stop, odpowiednia wzmianka pojawia sie w obszarze tekstow dla plikow dzwiekowych

- odrobine zmienione podejscie do rysowania nieba; w efekcie ksiezyc itp nie powinien juz miotac sie jak pijany zajac przy wiekszych sceneriach

(wydzielilem pliki tekstur itp do odrebnej paczki, bo calosc w wersji x64 zaczela przekraczac limit 1.5 mb)

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 07 Maja 2017, 02:16:10
W dzisiejszym uaktualnieniu nie ma zadnych zmian :o

zmienil sie natomiast kompilator, na vs2015. W zwiazku z tym w nowej kompilacji w porownaniu z poprzednimi moga miec miejsce zmiany w predkosci dzialania (teoretycznie na lepsze, w praktyce zobaczymy)  Oprocz tego zamiast* poprzedniego runtime 2013 do uruchomienia exe potrzebne bedzie runtime 2015 -- czyli to samo, ktorego uzywa exe of @Milek7, wiec powinno to troche uproscic sytuacje pod wzgledem instalacji itp.

*) pisze "zamiast" bo teoretycznie wszystko co jest wlaczone do exe wymaga 2015, wiec runtime 2013 nie powinien byc do niczego podczepiony, ale to wyjdzie w praniu
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 07 Maja 2017, 05:50:59
U mnie na x64 Win7 (już mi wszystko gra - winna była płytka 2GB RAM), wyskakuje brak pliku .dll.
exe/170507.
Jeżeli chodzi o kwestię pantografów, to chodzi mi o impulsowe ich działanie w lokach. Dodatkowo pantografy nie opuszczają się.
Czy przyczyną są nieaktualne .chk w moich pojazdach?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 07 Maja 2017, 09:28:09
Nie uzywamy juz plikow  .chk, raczej doczytaj tu w watku co zrobiono w sprawie sterowania patykami. Komunikat ze screena swiadczy o braku bibliotek visualstudio VC redist, stawiales nowy sytem operacyjny, czegos niedoinstalowales.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: MichałŁ w 07 Maja 2017, 09:56:42
Ja na win7 mam ten sam błąd na exe x86 170507. Exe x86 170506 chodzi prawidłowo.

Teraz sprawa druga.
Na czeskich elektrowozach jest wał kułakowy. W maszynie kiedy zejdziemy nastawnikiem jazdy na 0 od razu wyłącza nam obwód główny obojętnie od aktualnego położenia wału kułakowego.
W rzeczywistości prąd jest wyłączany dopiero kiedy wał kułakowy wróci do położenia 0.

Rzecz trzecia dotycząca ET40. W czeskich elektrowozach nastawnik jazdy po puszczeniu wraca dzięki sprężynom do aktualnego położenia wału kułakowego co jest wiernie zasymulowane w ET40 ale taki sposób przy sterowaniu z klawiatury jest trochę niewygodny. Czy można było by to zmienić tak jak to jest na innych czeskich elektrykach ?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 07 Maja 2017, 10:55:08
Potwierdzam, że i u mnie exe 506 działa prawidłowo. Poczekam na następne wydanie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: jakubg1 w 07 Maja 2017, 11:16:06
Na czeskich elektrowozach jest wał kułakowy. W maszynie kiedy zejdziemy nastawnikiem jazdy na 0 od razu wyłącza nam obwód główny obojętnie od aktualnego położenia wału kułakowego.
W rzeczywistości prąd jest wyłączany dopiero kiedy wał kułakowy wróci do położenia 0.
Ten problem próbowałem naprawić, prawdopodobnie da się to zrobić z poziomu plików fizyki. Chociaż jeszcze nie udało mi się tego zrobić, to podczas eksperymentów udało mi się "utworzyć" mechanizm blokowania PSR-u gdy prąd wzrośnie powyżej wartości 350A. W załączniku spakowane pliki, rozpakować do dynamic/pkp/et40_v1.
Tak z ciekawości, da się w takich lokomotywach "przerzucić" nastawnik o jedną pozycję do tyłu nie wymuszając kręcenia wału kułakowego przez czterdzieści ileś pozycji?

Rzecz trzecia dotycząca ET40. W czeskich elektrowozach nastawnik jazdy po puszczeniu wraca dzięki sprężynom do aktualnego położenia wału kułakowego co jest wiernie zasymulowane w ET40 ale taki sposób przy sterowaniu z klawiatury jest trochę niewygodny. Czy można było by to zmienić tak jak to jest na innych czeskich elektrykach ?
Jeśli chcesz zadać konkretną pozycję nastawnika podczas trzymania "plusa" naciśnij Shift.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 07 Maja 2017, 11:19:13
W EP05 się dało, jak pamiętam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 07 Maja 2017, 12:00:02
Pamietajcie ze po przekroczeniu fmax nastawnik byl blokowany mechanicznie i nie dalo sie go przekrecic dalej doputy prad nie opadl ponizej fmax. Co innego jazda pod gore. Ponadto bomby nie mialy nadmiarowych. Te funkcje spelniala wlasnie ta mechaniczna blokada. Na exe kursa80 to dzialalo wlasciwie ale po drodze ktos to pozmienial ze blokada nie zaskakuje. Lampka fmax jak sie zapalila to od razu blokowala nastawnik. Lampka przekroczenia fmax zapalala sie np kiedy bylismy na jakiejs pozycji a bylo pod gore i prad wzrosl.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 07 Maja 2017, 12:02:06
Skoro już wspominamy te czasy, to realne exe było to z paleniem oporów.
Wyszło na testy jakoś razem z EP40.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: piotrln w 07 Maja 2017, 12:36:36
Co jest tu nie tak?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: jakubg1 w 07 Maja 2017, 12:38:39
Czy aby na pewno to jest log który nie został poddany żadnym modyfikacjom?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 07 Maja 2017, 12:40:08
Pewnie wyskakuje mu od razu błąd, taki jak u mnie. Wówczas w logu nic nie będzie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: jakubg1 w 07 Maja 2017, 12:42:00
No to w takim razie podejrzewam jedną linijkę:
Unrecognized command: pogoda
Jaką scenerię odpalasz?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 07 Maja 2017, 12:52:18
Tak z ciekawości, da się w takich lokomotywach "przerzucić" nastawnik o jedną pozycję do tyłu nie wymuszając kręcenia wału kułakowego przez czterdzieści ileś pozycji?
Tak, one mają dwukierunkowy napęd wału kułakowego.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: piotrln w 07 Maja 2017, 12:55:47
Całkowov2 jarkawki noc, osobowy z Jarkawek do Janiszewa
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 07 Maja 2017, 12:58:42
Po pierwsze, komunikat u @EU40 świadczy o niekompletnych bibliotekach. @tmj użył nowego kompilatora i wymagana jest instalacja VCredist 2015, bez niej na win 7, aplikacja nie odpali. U mnie odpaliło się bez problemu w załączniku dowód.
Co jest tu nie tak?
To nie jest log z exe C++, wszelkie dyskusje na jego temat są tu zbędne.
Mój log jest w załączniku.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: piotrln w 07 Maja 2017, 13:03:04
A przecież mam nowe exe c++. To jak nie jest z tego?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 07 Maja 2017, 13:07:07
Co z tego że masz? Wycinek z Twojego logu:Starting MaSzyna rail vehicle simulator.
Release 16.0.1172.482 (executable: eu07.exe)
Online documentation and additional files on http://eu07.pl
To nie jest exe c++, pobierz to co ja dałem w załączniku, znajdziesz tam datę wydania exe. Uruchamiasz nadal stare exe z PC. Usuń log.txt, spróbuj odpalić jeszcze raz i zobacz czy utworzy się nowy. No i na końcu, my nie jesteśmy wróżkami, więc nie pytaj się co jest z logiem, jeśli są kłopoty to należy je opisać.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: jakubg1 w 07 Maja 2017, 13:11:48
Musisz zaznaczyć nowe EXE na liście po prawej w starterze.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: piotrln w 07 Maja 2017, 13:13:26
eu07-x86_170330 wybrałem  w trybie zaawansowanym. Chyba że nie czyta mi , ale ja niemam innego exe, bo to co mam eu07.exe to zmieniłem nazwe z któregos z C++ i wkleiłem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 07 Maja 2017, 13:13:33
Ten log owszem jest z nowego exe (z tym ze ze stara nazwa) :)  wersja c++ podaje na poczatku dane karty graficznej itp, wersja borlandowa rozpoczyna log od "starting maszyna..."

Co do nieuruchamiania sie, dla nowych wersji nalezy zainstalowac Visual C++ Redistributable for Visual Studio z microsoftu, do pobrania tutaj: https://www.microsoft.com/en-US/download/details.aspx?id=48145

Z tego co widze w logu, exe sie akurat uruchamia, ale w .scn jest wpis ktorego nie rozpoznaje, "pogoda" ktory zapewne psuje wczytywanie. Trzeba go usunac.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: piotrln w 07 Maja 2017, 13:18:37
Dałem z maszyny która uruchamia sie, ale przy uruchamianiu,wyskakuje ta pogoda.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 07 Maja 2017, 13:19:15
U mnie zadzialalo od razu to nowe exe bez doinstalowywania nowegovcredist..
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 07 Maja 2017, 13:24:56
eu07-x86_170330 wybrałem  w trybie zaawansowanym. Chyba że nie czyta mi , ale ja niemam innego exe, bo to co mam eu07.exe to zmieniłem nazwe z któregos z C++ i wkleiłem.
Dopatrzyłem się, że nie wykrywa gamepada, co nie jest możliwe na borlandowym. Jeśli nie edytował wpisów z pogodą to każdy scenariusz z Całkowa 2 uruchamia się bez problemu.
Log z uruchomienia Jarkawek noc w załączniku.
U mnie zadzialalo od razu to nowe exe bez doinstalowywania nowegovcredist..
No jak miałeś, to niepotrzebna była instalacja tego.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 07 Maja 2017, 13:26:03
Dałem z maszyny która uruchamia sie, ale przy uruchamianiu,wyskakuje ta pogoda.
No i bedzie wyskakiwac bo to jakis nieznany typ parametru jest, nie wiem skad go masz. Moze starter cos tam miesza jak mu w ustawieniach pogrzebiesz, ale ja za starter nie odpowiadam :d

U mnie zadzialalo od razu to nowe exe bez doinstalowywania nowegovcredist..
Mogles juz miec go zainstalowanego wczesniej, bo teraz wiele programow i gier tego wymaga, i instaluja automatycznie. Albo zainstalowales wczesniej zeby uruchomic wersje od Milka. tak czy owak jesli dziala, to dobrze ;>
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: piotrln w 07 Maja 2017, 13:28:04
Tu cos sie miesza
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 07 Maja 2017, 13:29:34
Tu masz errora.

pogoda słoneczna
zamien na

//pogoda słoneczna
Exe nie rozpoznaje polecenia "pogoda"
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 07 Maja 2017, 13:32:02
@tmj & @Krzysiek 626.
Macie jsk zwykle rację. Potrzebne było vcredit2015.
Zaraz sprawdzimy działanie ,,patyków".
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 07 Maja 2017, 13:34:32
@EU40, sposob funkcjonowania patykow zalezy od wpisu w pliku .fiz ktory moze opcjonalnie zdefiniowac typ przelacznikow jako impulsowe.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 07 Maja 2017, 13:39:58
I tak niestety robi. Dobrze działają na EU06.
@tmj masz może jeszcze tą ściągawkę na wpisy .chk?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: pinokio w 07 Maja 2017, 14:12:19
Exe 170507 działa bez problemów na windows10.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 07 Maja 2017, 14:22:23
I tak niestety robi. Dobrze działają na EU06.
@tmj masz może jeszcze tą ściągawkę na wpisy .chk?
Sposob dzialania przyciskow w .fiz definiuje sekcja "switches:"
Przykladowy wpis dla en57:
Switches: Pantograph=impulse Converter=impulse
(definicja odpowiednio, pantografow i przetwornicy)
Na ta chwile rozpoznawany i 'specjalnie' traktowany jest typ "impulse"  Wszystkie inne typy teoretycznie powinny byc obslugiwane jako bistabilne, chociaz exe moze sobie wykombinowac cos innego, jesli w kabinie zdefiniowane sa osobne przelaczniki do zalaczania i wylaczania urzadzenia.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: MichałŁ w 07 Maja 2017, 14:33:32
Cytuj
Tak z ciekawości, da się w takich lokomotywach "przerzucić" nastawnik o jedną pozycję do tyłu nie wymuszając kręcenia wału kułakowego przez czterdzieści ileś pozycji?
Cytuj
Tak, one mają dwukierunkowy napęd wału kułakowego.
Tu jeszcze filmik co pokazuje jak to pracuje w rzeczywistości


Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 07 Maja 2017, 21:04:34
Na nowym exe cały czas nie działa generowanie e3d terenu. W errors wpisuje na początek "Failed to load 3d model "models\slimson/calkowo_v2/calkowo_v2_teren.t3d", w katalogu models tworzy jakiś dziwny, pusty plik (0 kB długości) "calkowo_v2_teren.ted", wczytuje scenerię niby normalnie, ale jak dojdzie do zapisywania e3d (końcówka loga "saving e3d model..") to program się wywala. Crashdump w załączeniu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 08 Maja 2017, 22:34:43
konwersji modeli w ogole jeszcze nie ogladalem, bo jak dziala to z kolei jest placz ze tego co wyprodukuje nie da sie wczytac do starego exe :x

W dzisiejszym uaktualnieniu

- poprawiona logika uzywania przez pojazdy hamulca lokalnego -- w praktyce lokomotywy luzem nie powinny juz uzywac hamulca pociagu tylko dlatego, ze w poblizu znajduje sie inny pojazd, a samochody w podobnej sytuacji powinny hamowac lokalnym, zamiast nieistniejacym glownym

- usuniety blad obslugi 'niepelnych' skrzyzowan (zlozonych z trzech drog zamiast czterech), ktory powodowal wysyp wersji x64 w trybie Display List na wiekszosci scenerii. Wersja x64 powinna teraz ladowac te scenerie normalnie, bez potrzeby uzywania trybu VBO
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 09 Maja 2017, 07:48:31
Hmmm... mam nadzieję, że jak już połączę to co było w piątek na repo to następne zmiany pójdą już w miarę szybko. Może w końcu uda mi się nowe tabelki wrzucić do testu w tym tygodniu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 09 Maja 2017, 09:40:55
20170508. Używanie hamulca pomocniczego naprawiło łagodne podchodzenie do składu i wykonanie komendy shunt. Nadal w Drawinowie AI nie chce dojechać do składu mimo ms2 na tarczy (EP09-005, oblot we Włodowicach Zachodnich). Na 20170502 tej usterki nie było, jeśli zmiana  koncepcji w exe, to również należy zmienić koncepcję wykonania tych manewrów, być może także w innych sceneriach. Nadal AI ma kłopot z prędkością po ms2 i po sygnale zastępczym. W Bałtyku rozpędza się do 70km
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 09 Maja 2017, 09:54:31
Na screenie jest informacja, że na poprzednim semaforze miał 0 kiedy go mijał. To jest pewien błąd, gdyż nie aktualizuje sobie stanu semafora, który przerżnął. Poprawię to przy aktualizacji mojej wersji.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 09 Maja 2017, 10:06:28
Ja tego nie widzę (ale pewnie nie mam dostatecznej wiedzy), pierwszy w tabeli jest ms2 na Tm, zwykle w takim momencie AI nie ma problemu z ruszeniem. Będąc w lokomotywie nie stwierdzam przerżnięcia semafora. Natomiast pod ziemią jest tarcza Tm1, w tej chwili jednak nie badałem jej funkcji. Fakt taki, że teraz AI jedzie sporo dalej w tym torze niż poprzednio, daleko za tarczę Tm12.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 09 Maja 2017, 10:42:48
po sygnale zastępczym. W Bałtyku rozpędza się do 70km

Bo dostaje info od wskaźnika W5 (lineinfo), że wyjechało ze stacji. A to, że to jest niezgodne ze sztuką jazdy na Sz na blokadę samoczynną ;) Trzeba by było dorobić jakieś uwarunkowanie, że jeżeli jest w trybie jazdy pociągowej i Vmax ma zadane 20 0, to raczej jedzie na sbl na Sz/rozkaz i żeby granica przetaczania wówczas nie nadawała prędkości. Inna sprawa, że w samych inc semaforów mamy bałagan jeżeli chodzi o rozróżnianie i możliwości stosowania danego inca z SBL. Większość semaforów ma Vmax 40 na Sz i tylko te "wybrane", przerobione dla konkretnych potrzeb autora scenerii mają 20 km/h.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 09 Maja 2017, 11:14:54
Lineinfo kasuje informacje o prędkości z ostatniego semafora, ale to samo się robi jeśli przejedzie semafor za którym jest rozjazd i po zjeździe z niego nie znajdzie w drodze skanowania żadnego kolejnego. Przy sbl nie było to problemem, bo tam raczej nie występują  rozjazdy między kolejnymi semaforami ;) Szczerze powiedziawszy to jakoś nie zauważyłem, żeby po jeździe na Sz była utrzymywana jazda na widoczność tylko jedzie się normalnie.
Ja tego nie widzę (ale pewnie nie mam dostatecznej wiedzy), pierwszy w tabeli jest ms2 na Tm, zwykle w takim momencie AI nie ma problemu z ruszeniem. Będąc w lokomotywie nie stwierdzam przerżnięcia semafora. Natomiast pod ziemią jest tarcza Tm1, w tej chwili jednak nie badałem jej funkcji. Fakt taki, że teraz AI jedzie sporo dalej w tym torze niż poprzednio, daleko za tarczę Tm12.
Ważne jest to co było wcześniej, czyli czy widział jakieś semafor / tarczę i ją przejechał.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 09 Maja 2017, 11:30:59
Zdaje się, że przy wyłączonej baterii pantografy nie powinny się podnosić..
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 09 Maja 2017, 14:12:09
No wlasnie nie wiem jak to jest, teoretycznie mogloby wystarczyc ze jest cisnienie w sprezarce pantografow? Dobrze jakby sie ktos doswiadczony wypowiedzial :o
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 09 Maja 2017, 15:01:11
Jeżeli wyłączamy baterię, to nie ma możliwości podniesienia pantografów za pomocą wyłącznika elektrycznego na pulpicie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 09 Maja 2017, 16:00:41
Zgadza się. Nawet na tych sprzętach, które mają osobne elektrozawory na podnoszenie i opuszczanie - nie da się z pulpitu podnieść jak nie ma zasilania, zmienić ustawienia zaworu z pulpitu ;) Tylko ręcznie.

Gdy na wspomnianych sprzętach zostawiliśmy zawory otwarte i wówczas pojawił się zanik, bateria była wyłączona i siłą rzeczy wszystko przestało chodzić, w tym opadły po jakimś dłuższym czasie pantografy i w takim przypadku uruchamiamy sprzęt (pompując małą sprężarką), to gdy nie przesterowaliśmy ręcznie zaworów na pozycję zamkniętą - wówczas pantografy same będą się podnosić wraz ze wzrostem ciśnienia w obwodzie pantografów.

EDIT:

Lineinfo kasuje informacje o prędkości z ostatniego semafora, ale to samo się robi jeśli przejedzie semafor za którym jest rozjazd i po zjeździe z niego nie znajdzie w drodze skanowania żadnego kolejnego.

Kolejny (pierwszy odstępowy) może być przy ostatnim SBL w kierunku stacji, z której wyjeżdżamy. Jeżeli dziś 1300 metrów jest standardem drogi hamowania dla Vmax 160 km/h, to od wyjazdowego do pierwszego SBL może być coś ponad 1,5 km.

Cytuj
Szczerze powiedziawszy to jakoś nie zauważyłem, żeby po jeździe na Sz była utrzymywana jazda na widoczność tylko jedzie się normalnie.
Bo zależy, czy masz unieważnioną blokadę rozkazem ;) Ewentualnie często też są semafory wyjazdowe grupowe "wjazdowe na szlak" (na wysokości semafora wjazdowego), gdzie one mogą wskazywać sygnał zezwalający i to na nim musiałby być Sz (przy ważnej SBL), żeby była jazda na widoczność do pierwszego semafora blokady.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 09 Maja 2017, 16:26:36
W tym konkretnym przypadku: Jeśli w tabeli skanowania mam 25km/h (miga sygnał zastępczy), to AI tak powinno jechać. Nie rozpatrywałem tego pod względem przepisów, ani także zasadnością wpuszczenia EP08 na zajęty tor przez EP05 ze składem. Ten scenariusz był kiedyś krytykowany, stawiano tezę, że wjazd powinien być na tor wolny. Dopiero po tym fakcie, manewry na tor z zepsutym EP05.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 09 Maja 2017, 16:53:02
W tym konkretnym przypadku: Jeśli w tabeli skanowania mam 25km/h (miga sygnał zastępczy)

20 km/h*

Cytuj
stawiano tezę, że wjazd powinien być na tor wolny. Dopiero po tym fakcie, manewry na tor z zepsutym EP05.

Wcale tak nie musi być - formalnie trzeba pod semaforem się zatrzymać i dostać rozkaz pisemny "O" informujący o wjeździe na tor zajęty z Vmax 20 km/h. I tutaj trochę zamieszał autor scenerii (albo ktoś kto przerabiał), bo rozkaz w starterze można podejrzeć, ale on akurat jeżeli chodzi o taką jazdę powinien być wystawiony przez stację, na której taka jazda się odbywa. A więc żaden wydruk komputerowy z poprzedniej stacji.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 09 Maja 2017, 20:28:58
Chcę podsumować czy dobrze zrozumiałem:
1. Wyświetlenie Sz normalnie powoduje jazdę na widoczność, aż do następnego semafora (czyli jeśli nie ma SBL to do następnej stacji / posterunku odstępowego).
2. Jeśli nie ma być jazdy na widoczność to dyżurny ma podyktować rozkaz?

Od strony eventów w takim razie powinny być dwa różne Sz w incach semaforów. Exe rozpoznaje jazdę na widoczność poprzez nadanie wartości 1 = 0 i wartości 2 > 0. Normalnie nie powinno się stosować w incach drugiej wartości dla semaforów (exe jej nie sprawdza oprócz tego jednego przypadku).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 09 Maja 2017, 20:36:24
Na screenie jest informacja, że na poprzednim semaforze miał 0 kiedy go mijał. To jest pewien błąd, gdyż nie aktualizuje sobie stanu semafora, który przerżnął. Poprawię to przy aktualizacji mojej wersji.
Z tego co widze w debug to problem bierze sie stad, ze TableUpdate() wykrywa poprawnie pierwszy semafor z predkoscia dozwolona 25 km/h, a kiedy dochodzi do semafora ze znakiem stop jakies 500 m dalej, w rezultacie zwraca dla AI komende "manewruj z predkoscia docelowa 0", a AI robi sobie z tego "predkosc pozadana 0 km/h" i po prostu sie nie rusza.

Dowcip polega na tym, ze ta akurat czesc kodu jest nie ruszana, wiec nie mam pojecia czemu dzialalo to wczesniej :> kompiluje wersje ze starym skanowaniem zeby porownac co tam sie dzieje.

edit: porownana czesc jest faKtycznie taka sama, ale znalazl sie nowy kandydat na glupi krzak miesiaca. wiecej szczegolow po przerwie na reklamy
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 09 Maja 2017, 21:09:20
Chcę podsumować czy dobrze zrozumiałem:
1. Wyświetlenie Sz normalnie powoduje jazdę na widoczność

Jazda na widoczność do 20 km/h skupia się głównie w kontekście blokady samoczynnej. Wyświetlenie Sz na semaforze wyjazdowym (następny jest już semaforem SBL) jest już jazdą na widoczność. Natomiast w każdym innym przypadku - wyświetlenie Sz powoduje jazdę z V do 40 km/h.

Cytuj
(czyli jeśli nie ma SBL to do następnej stacji / posterunku odstępowego).

Nie, jeżeli nie wyjeżdżamy na SBL (albo SBL jest unieważniona), to przy Sz jedziemy wówczas 40 km/h do granicy posterunku, z którego wyjeżdżamy. Zazwyczaj granicą posterunku jest semafor wjazdowy i na jego wysokości możemy już jechać rozkładowo.

Cytuj
Jeśli nie ma być jazdy na widoczność to dyżurny ma podyktować rozkaz?

Przepisy określają kiedy i w jakich przypadkach jedzie się na blokadę (mimo jakichś tam jej usterek - np. nie więcej niż dwa semafory na blokadzie mogą wskazywać sygnał Stój). Jeżeli wymagane jest unieważnienie blokady, to oczywiście jest to przez rozkaz S i wówczas jeżeli już dostajemy Sz na wyjazdowym lub też mamy w rozkazie S polecenie pominięcia semafora wyjazdowego wskazującego sygnał stój, to jedziemy do granicy posterunku do 40 km/h. Z tym, że unieważnienie blokady to nie jest automatycznie Sz na wyjazdowym albo rozkaz na minięcie wyjazdowego. Bo często sytuacja jest taka, że da się podać semafor wyjazdowy. I wówczas mając rozkaz S z unieważnieniem blokady jedziemy normalnie na sygnał zezwalający.

Czyli podsumowując:

Sygnał zezwalający + czynna blokada (V sygnału i dalej wskazania blokady),
Sz + czynna blokada (do 20 km/h do pierwszego semafora SBL i dalej wskazania blokady),
Rozkaz na minięcie wyjazdowego + czynna blokada (do 20 km/h do pierwszego semafora SBL i dalej wskazania blokady),
Sygnał zezwalający + unieważniona blokada (V sygnału i od granicy posterunku Vmax),
Sz + unieważniona blokada (do 40 km/h do granicy posterunku i dalej Vmax),
Rozkaz na minięcie wyjazdowego + unieważniona blokada (do 40 km/h do granicy posterunku i dalej Vmax);
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 09 Maja 2017, 21:13:38
Tak też AI zachowuje się po zapodaniu SZ w Bałtyku. Do następnej zwrotnicy jedzie 40 a za nią do składu dokłada ile może aż do hamowania do składu. Tu nie pomogą żadne ekwilibrystyki z exe.Taki scenariusz trzeba inaczej napisać.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 09 Maja 2017, 22:37:25
OK, znalazla sie przyczyna blednego zachowania w Drawinowie.

Pod sceneria zakopana jest, przyrodzenie wie po co, tarcza manewrowa wdz_tmunvis1_sem_info wyswietlajaca predkosc 0.  AI probuje zatrzymac sie przed nia w odleglosci ok 5 m, ale poniewaz sygnal jest 10 m pod powierzchnia ziemi, w efekcie "przekracza" wyznaczona przez niego linie, i rejestruje "nakazana predkosc na ostatnim semaforze: 0 km/h" no i poslusznie stoi potem do swietej Nigdy.

(poprzednio AI zatrzymywalo sie przed tarcza, bo odleglosc kalkulowana byla tylko na plaszczyznie, bez uwzglednienia roznicy poziomow. Na upartego moge przywrocic poprzedni model kalkulacji, ale to z kolei moze miec negatywne efekty w sytuacjach gdzie faktycznie wystepuje spadek albo wzniesienie terenu, wiec nie wiem czy nalezy)

tl;dr: robic scenerie porzadnie, to beda dzialac porzadnie ;/
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 09 Maja 2017, 22:43:06
AI automatycznie zmienia kierunek po zatrzymaniu się pod tarczą (jakąkolwiek)? Czy tylko wtedy, gdy zeskanuje w drugą stronę sygnał zezwalający? I trzecie pytanie - zamiast tarczy nie lepiej zwykłe putvalues change_direction mu dać?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 09 Maja 2017, 22:44:39
Ja Tobie pisalem wczoraj o tej tarczy pod ziemia. To pewnie posypia sie inne manewry. Na Kaliskiej bylo co niemiara zakopanych tarcz a juz widze, ze po sciagnieciu wagonow sm42 nie wraca na swoje miejsce.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 09 Maja 2017, 22:48:15
Nie znam konkretnego przypadku Drawinowa co prawda, ale bardzo często sam umieszczam semafory pod ziemią z różnych względów. Przede wszystkim czasami mamy np. opuszczoną stację, na której trzeba posterować manewrami AI. Inaczej aniżeli z użyciem semaforów jest to ciężko zrobić, ale ponieważ dla gracza chcemy zachować klimat stacji opuszczonej (czy nawet bocznicy bez sygnalizacji) semafory trzeba schować. Podejrzewam, że jest też wiele innych przypadków, gdy semafory się najzwyczajniej w świecie przydają do sterowania ruchem, ale z pewnych względów nie chcemy ich ujawniać dla gracza.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 09 Maja 2017, 22:50:08
Tarcza musi być, by coś blokowało manewrujący skład. Można dać komórkę bez wizualizacji na poziomie toru, ale takie cudaki ułatwiają ogarniecie sytuacji z terenie i nigdy nie szkodziły, wiec trochę tego się narobiło. Czy komórki manewrowe trzymają poziom toru, też ciężko powiedzieć. Cel szczytny i rozumiem logikę zmiany, ale to posypie masę scenariuszy a jak wiadomo nie ma komu poprawiać.
Putvalues change_direction uniemożliwiłoby normalny przejazd po tym torze.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 09 Maja 2017, 22:51:13
Skoro to jest bardziej rozpowszechnione to trzeba bedzie chyba wrocic do poprzedniego sposobu wyznaczania odleglosci, bo raczej nikomu nie bedzie sie chcialo tego wszystkiego poprawiac :<  Moze jak bedzie edytor scenerii wbudowany itp to mozna bedzie wrocic do tematu.

Tez mi sie wydawalo ze change_direction mialoby wiecej sensu, ale ja sie nie znam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 09 Maja 2017, 22:57:42
Może najpierw przesunąć tą nieszczęsną tarczę i sprawdzić, czy to coś da? Przyczaję się na to jutro.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 09 Maja 2017, 23:14:07
Problem w tym ze jesli to jest rozpowszechnione w sceneriach, to przesuniecie jednej im nie pomoze ;o  Ze swojej strony wstawie okreslanie odleglosci stara metoda i zobacze czy zawroci.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 09 Maja 2017, 23:21:48
Przypadek tak gleboko wstawionej tarczy jest chyba odosobniony. Warto to wybadac chocby na przyszlosc. Ze dwa lata temu z podobnym manewrem walczylem na Kaliskiej. Tam byl byk dojezdzajacy do skladu po manewrach a sklad przyprowadzony przez innego loka. Inni to pamietaja jako pspieszny Jadzwing.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 10 Maja 2017, 01:35:12
Z tego co ogladam na Drawinowie, AI zatrzymuje sie w odleglosci 3-4m od slupka, wiec klopoty wyjda takze z semaforami zagrzebanymi na mniejszej glebokosci, w sumie moze ich wyjsc sporo. Podobno jedno z narzedzi ktore stworzyl @Mariusz1970 moze sobie z tym dosc latwo poradzic.

W miedzyczasie przywrocilem stara metode liczenia odleglosci, AI robi teraz manewry na Drawinowie bez zaciec. Oprocz tego poprawione jest zalaczanie pantografow przy wylaczonym zasilaniu (a raczej brak takiego zalaczania) chociaz nie jest idealnie -- przelacznik impulsowy uzyty przy wylaczonej baterii spowoduje tak samo jak bistabilny podniesienie pantografu gdy juz bateria zostanie zalaczona. Zeby zrobic wszystko dokladnie "jak trzeba" potrzebne beda najpierw zmiany w sposobie konfiguracji/obslugi kabin, ktore sa w kolejce do zrobienia, ale raczej nie na teraz.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 10 Maja 2017, 06:53:19
Który to skład na drawinowie robi takie kwiatki. Przetestuję sobie na swojej wersji.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 10 Maja 2017, 07:18:03
EP09-005, Drawinowo. Pierwszy skład na liście w Rainsted. Oblot po dotarciu do Włodowic Zachodnich.
ED:
Dwa ostatnie załączniki to zatrzymanie przed tarczą wyciągniętą z ziemi (była na poziomie -10m). AI zmieniło kabinę i podążyło do składu zgodnie z ms2 na tm12. Krótko mówiąc wyciągnięcie tarczy z ziemi rozwiązuje problem z manewrami w Drawinowe na 20170508. Zastanawiam się, jaka jest tolerancja ustawienia semafora/tarczy w stosunku do toru?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 10 Maja 2017, 09:21:53
A ja chciałem powrócić do problemu z Vistą.
Otóż jak to jest, że na exe_170424 kaliska, drawinowo mi działa, a na najnowszych już nie?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 10 Maja 2017, 09:27:46
Nie masz VCredist 2015 na Viście! Dałbyś jakiś log, a inne scenerie? Bo tak, to wiesz...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 10 Maja 2017, 09:30:02
Mam. Instalowałem.
Sorry w międzyczasie dołączyłem.
Bałtyk odpala.
Całkowo_orlen..
Powtórka z rozrywki. M62 nie mogę sterować nastawnikiem kierunkowym, nastawnikiem jazdy (działa jedynie wirtualnie).
W dodatku proszę zobaczyć semafory.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 10 Maja 2017, 09:57:45
W logu masz:
Player train init OK
Load time: 70 seconds
Coś mało masz w tej paczce, Kaliska ładuje się przynajmniej 300 sekund, wyłączałeś jakieś includy? Jeśli nie, to instalacja Kaliskie ma jakieś błędy.  Więcej pewnie zobaczę jak odpalę Kaliską u siebie, tymczasem mam na tapecie Drawinowo. M62 sprawdzałem wczoraj, Całkowo 2 zrobiłem misję z tym lokiem.
ED2:
EU40, załączony log nie jest z Kaliskiej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 10 Maja 2017, 10:44:44
Pierwszy jest z Kaliskiej, a drugi z Orlenu.
Ale jeszcze raz wysyłam w takim razie.
Nie działają też niektóre misje calowov2.
Z tego co zauważyłem, to wysypuje mi się przy inicjalizacji taboru.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 10 Maja 2017, 10:48:42
W dodatku proszę zobaczyć semafory.

W misji calkowo_orlen te semafory zawsze tak były i jazda odbywała tam się po uzyskaniu zgody przez radio.

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 10 Maja 2017, 13:48:02
Zastanawiam się, jaka jest tolerancja ustawienia semafora/tarczy w stosunku do toru?
Pomiar jest wykonywany od wspolrzednych sprzegu, do 'zrodlowego' punktu modelu ( w przypadku semaforow to jest zazwyczaj punkt, w ktorym wchodzi w ziemie)  Poniewaz koncowe hamowanie zaczyna sie przy ok 5-6 m od semafora a pojazd zatrzymuje sie na ~3m od niego, czasem mniej, przy pomiarze 'trojwymiarowym' problem najprawdopodobniej wystapi w sytuacjach gdzie sygnal zaglebiony jest na 3+ metry pod poziomem toru, moze nawet mniej.

edit:
@EU40, M62 wyswietla sie u mnie i obsluguje normalnie. Zobacz, czy moze przelaczenie z trybu VBO na Display List da jakis efekt, chociaz przy tej "karcie graficznej" szanse sa mizerne.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 10 Maja 2017, 14:22:18
Toteż zrobiłem pewne badania na okoliczność 20170508.Sprawa nie jest nowa, zmiany skanowania były także około 2014 i spowodowały znaczące problemy w wykonaniu eventów w budowanej Kaliskiej. Jak napisałem wcześniej, wyciągnięta na wierzch tarcza nie sprawia problemu. Wpis początkowy (niedziałający) tej tarczy to:
include ms2nbi.inc wdz_tmunvis1 37301 -10 13 0 tm1 end
//do wywalenia tarcza niewidzialna podziemna
Jak widać w komentarzu, ktoś wcześniej przewidział zaistniałą sytuację i opisał potrzebę jej likwidacji. Na poziomie -3 tarcza spełnia swe zadanie i manewry odbyły się zgodnie z planem, tak samo jak przy wpisie z 0 (poziom gruntu). Niestety przy poziomie -3 nadal wystaje ona ponad poziom gruntu pokazując całą głowicę. Aby schować całość dałem -5 i tu skończyła się możliwość wykonania manewrów przez AI. Następnym posunięciem było wstawienie karzełka z wpisem:
include ms2nbk.inc wdz_tmunvis1 37301 -1.5 13 0 tm1 end
Ten spełnił moje oczekiwania: został schowany pod trawnik przy podanych współrzędnych a AI dokonuje prawidłowych manewrów. W tej scenerii jest też niekonsekwencja, z drugiej strony peronów lokomotywa wykonuje identyczny manewr i obywa się bez podziemnego "czarodzieja", korzystając z wpisu line_info_s1. Nie mam pojęcia, które rozwiązanie jest najlepsze. Powrót do skanowania sprzed 2 maja, zastępowanie niedziałających tarcz line_info_s1, czy też poprawa pozycji "szamańskich" możliwości tarcz unvis.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 10 Maja 2017, 19:08:00
Ja mam rzutowanie i liczenie odległości zrobione zupełnie inaczej niż jest obecnie, więc tymczasowo lepiej wrócić do starego sposobu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 10 Maja 2017, 20:30:54
@tmj jeżeli chodzi o M62 to.. miałem wersję z testów a nie oficjalne wydanie. Przepraszam za zbędne zaniepokojenie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Mariusz1970 w 10 Maja 2017, 21:39:29
Podobno jedno z narzedzi ktore stworzyl @Mariusz1970 moze sobie z tym dosc latwo poradzic.
Jedna uwaga, owo narzedzie nie zidentyfikuje miejsc (semkow), gdzie teren jest w t3d/e3d. Ogolnie koncepcja terenu w t3d niebardzo mi pasuje. No chyba, ze ktos napisze odpowiednie narzedzia (rozne, rozniste do edycji, poprawek, itp.)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 10 Maja 2017, 21:56:40
Teren e3d zawsze ma odpowiednik na trójkątach do generowania przy zmianach. Istnieje tylko dla optymalizacji wczytywania. Jednak wyświetla się nieporównywalnie wydajniej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Mariusz1970 w 10 Maja 2017, 22:08:56
pierwszego zdania nie rozumiem, o drugim wiem i szkoda, ze caly teren we wszystkich sceneriach nie jest w zwiazku z tym w t3d.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 10 Maja 2017, 22:11:49
Masz scm(y) z node triangles z których wygenerowany był teren e3d. Można je odkomentować na potrzeby przeliczania wysokości. Przynajmniej Ja, Ra i Benek je zostawialiśmy w scn w komentarzach i dołączamy do paczek.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 10 Maja 2017, 22:15:25
Te zakomentowane scmy są jakoś opisane? Jeśli nie, to trzeba to zrobić przy najbliższej paczce, roboty niewiele a wygody więcej. Czym generowany jest docelowy plik e3d terenu?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 10 Maja 2017, 22:22:01
Exe konwertuje wszystkie node triangles z teksturą 24 bit nad wpisem terenu t3d do e3d. Na wiki Ra jest to opisane. Okomentowane to nie jest, ale o nazwach scm chyba idzie się domyśleć co jest czym.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 12 Maja 2017, 00:01:57
W dzisiejszym uaktualnieniu:

- dodane rysowanie skrzyzowan w trybie VBO

- ujednolicone funkcje generowania geometrii torow itp pomiedzy wersjami VBO i Display Lists

tutaj uwaga, istnieje teoretyczna mozliwosc, ze w ramach ujednolicania/upraszczania kodu ewentualnie wersja DL zostania usunieta. Dlatego prosze, jesli to mozliwe, o sprawdzenie czy wersja VBO nadaje sie w stanie obecnym do uzytku, i czy wystepuja jakies istotne roznice w porownaniu z wersja DL (po ostatnich zmianach powinno to juz w sumie na obu wersjach wygladac tak samo, ale gwarancji nie ma, to musi wyjsc w praniu)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 12 Maja 2017, 08:39:18
Bardzo wstępnie: Na wersji x86 nie mam uwag do VBO, nie widzę różnicy między tą wersją a DL. Natomiast mam uwagi co do prowadzenia przez AI w trakcji ukrotnionej 2x EP05. Patyki tych lokomotyw nie są prawidłowo ustawiane. Nie można opuścić przedniego pantografu drugiej w składzie lokomotywy (załącznik). Czy w tej wersji mamy stare skanowanie, na manewrach 2xEP05 przerżnęły mi tarczę manewrową? Ogólnie hamowanie składów prowadzonych przez EP05 budzi moje zastrzeżenia.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 12 Maja 2017, 14:35:34
Skanowanie jest takie jak bylo w wersji Borlandowej. Glupie pytanie, ale czy polaczyles te EP05 kablem uokrotnienia? Na TD taki zestaw u mnie obsluguje patyki tak, jak mozna tego oczekiwac, i hamuje na w4/sygnalach z solidnym zapasem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 12 Maja 2017, 14:36:45
Vista nie łyka. Borlander odpala.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 12 Maja 2017, 14:41:16
"Nie lyka" czego, ostatniego exe, trybu vbo, jakiegos konkretnego scenariusza? Co wlasciwie sie dzieje?
 Wrozka to ja niestety nie jestem, jakbym byl to gralbym w totka albo wystepowal w Polsacie, zamiast bawic sie w programowanie ;/
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 12 Maja 2017, 14:42:41
Jak najbardziej masz rację. Nie łyknęło drawinowa.
Poniższy log jest z odpalonego bałtyku. I tam jest dobrze.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 12 Maja 2017, 14:54:41
Hmm drawinowo ('biezaca' wersja z poprawkami Ra) u mnie dziala, ale tam jest prawie 500 mb tekstur, wiec moze zwyczajnie ci sie nie miesci. Czy tak samo jest na obu wersjach, VBO i DL, czy tylko na jednym? I co sie wlasciwie dzieje, wylatuje przy wczytywaniu, czy cos innego?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 12 Maja 2017, 15:18:58
To wina kompa. Tak jak napisałeś. Przy większych objętościowo misjach nie odpala. Drawinowo, kaliska.
Nie wiem czy jest sens na tym kompie testować.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 12 Maja 2017, 15:26:46
Pojeździłem dziś na 20170511x64. Nie mam żadnych uwag. Odpala scenerie, wykonuje manewry i najważniejsze, nie ma wysypów.
Brawo Ty. Ta optymistyczna opinia po 24 godzinach testowania, może gdyby intensywniej prać...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 12 Maja 2017, 15:29:29
Nie wiem czy jest sens na tym kompie testować.
Skoro duze scenerie nie wchodza to duzych scenerii pewnie nie ;>  Natomiast mniejsze i rozne elementy jak obsluga kabiny i inne takie zmiany ktore wchodza co jakis czas to jak najbardziej; im wiecej ludzi patrzy tym wieksza szansa ze czegos sie nie przegapi.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 12 Maja 2017, 17:34:52
To wina kompa. Tak jak napisałeś. Przy większych objętościowo misjach nie odpala. Drawinowo, kaliska.
Nie wiem czy jest sens na tym kompie testować.
Na Drawinowie jest masa składów dekoracyjnych na stacjach w osobnym scm. Wywal je, to będzie potrzebować 1/3 pamięci na tekstury.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 12 Maja 2017, 21:17:59
Cytuj
Ogólnie hamowanie składów prowadzonych przez EP05 budzi moje zastrzeżenia.

Krzysiu EP nie ma dynamicznego. A ten z kolei bardzo pomaga wyhamować z dużej predkosci. NA EP05 trzeba dużo wcześniej zacząć hamować.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 12 Maja 2017, 21:45:37
Ja, My, sobie poradzimy. Ból to ma AI, jak patrze co wyprawia, to głowa boli. Do rzeczy, hamuje i zbyt późno luzuje, więc często staje w polu. Tylko pozazdrościć.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 12 Maja 2017, 23:15:11
Na szybkości kilka smaczków z nowego exe i VBO:
- widoczne są jakieś dziwne trójkątne artefakty związane prawdopodobnie ze słupami trakcyjnymi (vbo_trojkaty);
- niewidoczna część tekstury ramienia słupa (vbo_slup);
- zanika część elektromagnesu SHP (vbo_shp);
- spodnia część torów ma teksturę, i to dziwnie ułożoną (vbo_tory)

Testy na TD, karta GeForce GTX 760/PCIe/SSE2, multisampling x16, VBO, maksymalny rozmiar tekstury 8192. Niestety nie mam teraz czasu odpalać Całkowa, więc ewentualne dalsze żale kiedy indziej ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 12 Maja 2017, 23:20:42
Tory od spodu faktycznie mają podsypkę jak na screenie. Na Drawinowie widziałem. Nie zgłosiłem, bo zapomniałem. Farfocle od słupa widzieliśmy wcześniej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 13 Maja 2017, 01:14:02
- widoczne są jakieś dziwne trójkątne artefakty związane prawdopodobnie ze słupami trakcyjnymi (vbo_trojkaty);
- niewidoczna część tekstury ramienia słupa (vbo_slup);
Te dwa sa najprawdopodobniej powiazane, tzn te farfocle to jest, z jakiegos powodu znieksztalcony, brakujacy kawalek slupa. Ten blad jest od 'dawna' i jest dziwny, bo z jakiegos powodu dotyka tylko slupa z krotka wersja poprzeczki, a tej z dluga nie. Podobnie z elektromagnesem shp -- nie wyswietla jednego boxa, gdyby tu byl szerszy blad w kodzie, powinno to chyba wplynac takze na inne modele. Tak czy owak przyjrze sie.

Trojkaty 'pod spodem' torow to nie tyle blad co optymalizacja -- zaoszczedza tak 10-20x ilosc odwolan do karty graficznej, a trojkatow w normalnych okolicznosciach nie widac, wiec raczej nie przeszkadzaja swoja obecnoscia (a kiedy kamera jest powyzej toru to nie renderuja sie w ogole)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 13 Maja 2017, 07:54:14
L053 sl3 Po minieciu nastawni w czasie manwerow zawieszka programu. Tryb VBO. Musialem wcisnąć pauze w tym momencie bo dziecko wstalo o po ponownym wcisnieciu escapa nastapilo to zawieszenie. Pliku DMP nie wygenerowal. Musialem zakillowac program.

Na DL wszystko ok misja zakonczona powodzeniem bez wysypu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: wołodyjowskiIC w 13 Maja 2017, 14:19:25
Przetestowałem EXE i mam taki problem, że nie wiem jak się włącza oświetlenie kabiny, a druga sprawa w którym pliku *fiz jest parametr decydujący o wycieku powietrza?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 13 Maja 2017, 17:07:27
Oswietlenie kabiny przelacza sie klawiszem ' (apostrof) o ile dana kabina jest wyposazona w odpowiedni przycisk. Wyciek powietrza udokumentowany jest w przyklejonym watku ze zmianami w exe
Cytuj
parametr AirLeakRate w sekcji Brakes: definiuje predkosc wycieku powietrza z ukladu hamulcowego

L053 sl3 Po minieciu nastawni w czasie manwerow zawieszka programu. Tryb VBO.
W dzisiejszym uaktualnieniu usuniety zostal dosc brzydki blad przy renderowaniu zwrotnic w trybie VBO (oprocz animowania zwrotnic funkcja potrafila takze wpisywac smieci gdzie tylko byla okazja, stad zgloszone latajace farfocle i braki elementow w innych obiektach)  Jesli mozesz, sprawdz czy na tej wersji problem wystepuje dalej?

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: wołodyjowskiIC w 13 Maja 2017, 17:48:59
Nie jestem w stanie nigdzie znaleźć tego parametru dla przykładu szukałem w pliku *fiz 4e, może coś ja źle zrozumiałem. Zgłaszam też błędy dotyczące działania EP08 np. po załączeniu baterii od razu podnoszą się pantografy albo nie działa oświetlenie kabiny.
Natomiast najnowsze EXE(tj.170513) cały czas mi blokuję Avast, więc na razie bazuję na EXE 170418.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 13 Maja 2017, 17:54:16
170418 jest juz nieaktualne. Zrob wyjatek dla exe, inaczej test nie ma sensu. Bledy zostaly poprawione od 18 kwietnia. Czesc bledow nie jest bledem, lecz zmiana koncepcji na obsluge pojazdow.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 13 Maja 2017, 18:06:59
Natomiast najnowsze EXE(tj.170513) cały czas mi blokuję Avast, więc na razie bazuję na EXE 170418.
Avast w biezacej wersji nadaje sie niestety tylko do tego zeby go zastrzelic za szopa i zakopac w ogrodzie :/  Zrezygnowalem ze swojego gdzies tak na poczatku roku, i system zaczal chodzic tak z 20% szybciej, a wbudowany Defender wypada w testach rownie dobrze.
Exe mozna dodac chyba do listy wyjatkow, zeby przestal sie ciskac -- zrodla sa publicznie dostepne, mozna sprawdzic ze nic zlosliwego tam nie ma, ewentualnie skompilowac sobie samemu.

edit:
Parametru wycieku nie znajdziesz w biezacych plikach .fiz bo jest on opcjonalny, i jesli nie wystepuje to exe przyjmuje dla wyciekow domyslna wartosc 1.0 tzn. predkosc/wielkosc "standardowa", dobrana na podstawie sprawozdan jaki powinien byc efekt w praktyce. Parametru uzywac powinno sie tylko by ta wartosc standardowa z jakiegos powodu zwiekszyc lub zmniejszyc.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: wołodyjowskiIC w 13 Maja 2017, 18:59:53
Uruchomiłem najnowsze EXE i dalej stwierdzam, że EP08 podnosi się pantograf wraz z załączaniem baterii i oświetlenie kabiny nie działa.
Cytuj
Parametru wycieku nie znajdziesz w biezacych plikach .fiz bo jest on opcjonalny, i jesli nie wystepuje

To jak zrobić by nie był opcjonalny?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 13 Maja 2017, 19:01:45
Ale dlaczego ma nie być opcjonalny? Zmienić by jego brak wysypywał exe i żmudnie dodawać parametr "1" do wszystkich kilkuset plików fiz. Tylko poco?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 13 Maja 2017, 19:10:57
Uruchomiłem najnowsze EXE i dalej stwierdzam, że EP08 podnosi się pantograf wraz z załączaniem baterii i oświetlenie kabiny nie działa.
Zwroc uwage, czy sceneria na ktorej masz ustawiony sklad nie konfiguruje stanu pantografow 'na wstepie', przez wpis w .scn -- na ekranie F3 w trzeciej linii po lewej stronie ekranu znajduje sie ciag znakow odzwierciedlajacych stan podstawowych elementow pojazdu. Jesli sa tam male litery "o" lub "p" to oznacza to, ze tylny lub przedni pantograf ma swoj przelacznik w pozycji 'podnies' i faktycznie podniesie sie on jak tylko dostarczone zostanie napiecie i cisnienie w zbiorniku.

Oswietlenie kabiny uzaleznione jest od obecnosci zdefiniowanego przelacznika. Jesli przelacznika brak, w logu i oknie konsoli pojawia sie odpowiednia uwaga wyjasniajaca to.

edit:
Cytuj
To jak zrobić by nie był opcjonalny?
Moze zle sie zrozumielismy -- wyciek sam w sobie nie jest opcjonalny, jest obecny dla wszystkich pojazdow, i nie wymaga zadnego wpisu do .fiz zeby byl aktywny. Opcjonalny wpis jedynie zwieksza lub zmniejsza jego wartosc, jesli domyslna jest z jakiegos powodu nieodpowiednia.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: wołodyjowskiIC w 13 Maja 2017, 21:25:53
Cytuj
Moze zle sie zrozumielismy -- wyciek sam w sobie nie jest opcjonalny, jest obecny dla wszystkich pojazdow, i nie wymaga zadnego wpisu do .fiz zeby byl aktywny. Opcjonalny wpis jedynie zwieksza lub zmniejsza jego wartosc, jesli domyslna jest z jakiegos powodu nieodpowiednia.
Faktycznie źle się zrozumieliśmy, bo mi chodziło, by był szybszy wyciek niż obecnie jest w symku, a teraz rozumiem, że bez ingerencji w plik *fiz i tak będzie szybszy ten wyciek, niż był dotychczas.
Co się tyczy EP08, to jutro spróbuję zrobić jak mówisz, bo dziś mam już dosyć wszelkich testów Maszyny;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 13 Maja 2017, 21:35:17
Farfocle zniknęły. Zapytam jeszcze, czy usunięta funkcja mogła mieć wpływ na źle rysujące się rozjazdy angielskie. Miałem taki przypadek, ale był jednorazowy więc nie zgłaszałem. Kilka rozjazdów było kompletnie rozjechanych.

Teraz sprawa podnoszenia patyków na EP08. Nie mamy żadnego konkretu, ani nazwy scenerii, ani trybu uruchomienia (debugmode?). Pozwoliłem sobie sprawdzić i napiszę, że w trybie normalnej symulacji lokomotywa EP08 uruchamiana na TD po podaniu załączenia baterii, przerzucenia nastawnika kierunku i zbicia czuwaka, nie podnosi patyków. Tak samo jest z flagową EP/EU/07. Jednak stwierdziłem, że w trybie debugmode kiedy na starcie mamy włączone AI, włączenie baterii skutkuje podniesieniem tylnego patyka, co jest oczywiste ze względu na podaną literkę o na ekranie pod F3. Nawet wyłączenie AI na starcie symulacji nie zmienia tego faktu. Kwestią oceny pozostaje, czy w trybie debugmode, powinniśmy dostawać na starcie włączone AI. Miałem już wcześniej na ten fakt zwrócić uwagę, często ten fakt przeszkadza. Szkoda, że nie podano okoliczności włączania/uruchamiania EP08.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 13 Maja 2017, 23:00:27
Farfocle zniknęły. Zapytam jeszcze, czy usunięta funkcja mogła mieć wpływ na źle rysujące się rozjazdy angielskie. Miałem taki przypadek, ale był jednorazowy więc nie zgłaszałem. Kilka rozjazdów było kompletnie rozjechanych.
Dosc trudno powiedziec, bo o ile siatki torow rowniez podpadaja pod "wpisywanie gdzie tylko okazja" to akurat rozjazdy sa odswiezane dosc czesto wiec wpisane smieci teoretycznie "poprawilyby sie". Natomiast swoja droga jakies bledy przy generowaniu anglikow faktycznie byly w starszych wersjach (najlatwiejsze do wylapania na Baltyku, idac w strone przeciwna do normalnego kierunku jazdy EP08 jest ich tam kilka niedaleko od punktu startu) ale po ostatnich ujednoliceniach/poprawkach to rowniez wydaje sie byc teraz w porzadku (jesli nie jest to prosze zglosic)

Jesli AI na starcie debugmode "ustawi" pantograf do podniesienia, to istotnie podniesie sie on nawet po przejeciu kontroli, bo stan przelacznikow nie jest zmieniany przy zmianie prowadzacego. Samego automatycznego uruchamiania AI nie ruszalem bo w Borlandowym "tak juz bylo" wiec zalozylem ze byl ku temu jakis sensowny powod ;>
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 14 Maja 2017, 07:17:00
Proponuje dopisac do ini.txt mozliwosc odlaczenia AI na starcie w debugmode. Domyslnie nalezy pozostawic wlaczone. Taka konfiguracja nie zmieni dotychczasowego uruchamiania, jednoczesnie doda mozliwosc wyboru.
Uszkodzone angliki pojawily sie na Kaliskiej idac w kierunku petli za torami postojowymi  dworca kaliskiego. Zniknelo tam kilka zwrotnic a w Ostrowie kawalek terenu. Wybryk byl jednorazowy przed usunieciem farfocli ze exe. Teraz po kilku jazdach nie stwierdzam dzialalnosci zlomiarzy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 14 Maja 2017, 09:05:11
U mnie swinka zachowuje się identycznie jak u Ciebie Krzysiu wiec nic więcej nie będę tu dopisywal. Jedyne co zauważam niekiedy na starcie to to, ze swinki jakby miały mniej powietrza a pszczolki więcej. Jeśli zbyt szybko damy kran hamulca w jazde i wciśniemy odluzniacz to na swince zaskutkuje tym ze będziemy zmuszeni uzyc malej sprężarki i dobic powietrza do podnoszenia patyków. Na pszczolce tego nie ma (303e). Przy okazji dopisałem sobie na każdej scn gdzie startujemy z szopy z hali uruchamianie bez powietrza. Dodaje to klimatu. Proponuje to uaktualnić w paczce. Tylko loki z torow postojowych spod chmurki zostawiłem sobie po staremu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: wołodyjowskiIC w 14 Maja 2017, 18:38:41
Dziś znów przetestowałem świnkę, tylko na innej scenerii i problem zniknął, natomiast mam uwagę do włączników pantografów, gdyż dziwnie odskakują w czasie podnoszenia patyków i dzieje się tak tylko na śwince.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 14 Maja 2017, 18:41:46
Dziś znów przetestowałem świnkę, tylko na innej scenerii i problem zniknął, natomiast mam uwagę do włączników pantografów, gdyż dziwnie odskakują w czasie podnoszenia patyków i dzieje się tak tylko na śwince.
Nie wiem co znaczy "dziwnie odskakuja", ale zachowanie przelacznikow zalezy od wpisu w .fiz dla danego pojazdu -- jesli przelacznik jest tam zdefiniowany jako impulsowy to po puszczeniu klawisza wraca samoczynnie do pozycji '0'.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: ST44-003 w 14 Maja 2017, 19:33:02
I to był błąd który miał być w EP08 zlikwidowany ze 2 lata temu...
Świniak nie ma hebelków odskokowych do pantografów. Nie ma też nawet grzybka do opuszczania. Co już z resztą kiedyś udowadnialiśmy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 14 Maja 2017, 19:44:08
No to jak sie nikomu nie chce przez dwa lata otworzyc pliku .fiz i usunac
Pantograph=impulse
z sekcji Switches: i zapisac plik, to ja juz na to nic nie poradze :o  To nie jest blad exe, ono robi dokladnie to, co mu autor .fiz kaze.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: wołodyjowskiIC w 14 Maja 2017, 20:41:16
I teraz wszystko gra;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 14 Maja 2017, 23:09:05
W dzisiejszym uaktualnieniu:

- ujednolicone generowanie drutow dla wersji VBO i DL. Druty wystepuja w kilku konfiguracjach (1, 2, 3 albo 4 przewody) wiec nie wiem czy udalo mi sie zweryfikowac renderowanie wszystkich kombinacji w wersji VBO ktora byla poprawiana. Jesli wyskoczy cos dziwnego w porownaniu z wersja DL prosze dac znac

- dodana opcja konfiguracyjna dla plikow .fiz ConverterStart w sekcji Cntrl: okreslajaca metode obslugi przetwornicy -- domyslnie (wartosc Manual) przetwornica sterowana jest recznie. Jesli wartosc parametru ustawiona jest na Automatic przetwornica wlacza sie automatycznie po zamknieciu wylacznika szybkiego.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 14 Maja 2017, 23:48:08
Przy wyjeździe z Lublińca w scenariuszu L61+L144_towarowy_1 wywaliło mi symka do pulpitu.
Ps. Przetwornica ładnie się załącza po włączeniu WS'a, dzięki ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Maja 2017, 13:52:30
Wysyp przytrafil sie gdzies przy alokacji pamieci przez systemowy Direct Sound, na tyle gleboko ze nie moge powiedziec co go spowodowalo. Byc moze cos jest tam nie tak z ktoryms z dzwiekow? Chociaz to juz raczej nie powinno powodowac wysypow :|  jesli sie powtorzy daj znac; probowalem to wywolac u siebie, ale na tym scenariuszu nawet sygnalu do startu nie dostaje (wersja z paczki)

W dzisiejszym uaktualnieniu:

- wyswietlanie stanu podlaczenia sieci trakcyjnej uwzglednia biezacy stan flagi trybu debug, zamiast jej stan na poczatku. Czyli wyswietlanie mozna do woli zalaczac/wylaczac, przelaczajac tryb debug w trakcie pracy symulatora

- poprawka, dzialanie kontrolek drugiego czlonu uzaleznione jest od stanu baterii i/lub przetwornicy czlonu obsadzonego, zamiast od stanu obwodu glownego

- dodana opcja dla .fiz: ConverterStartDelay w sekcji Cntrl: okreslajaca (w sekundach) opoznienie, z jakim uruchamia sie przetwornica po zamknieciu wylacznika szybkiego. wartosc domyslna to 0, czyli brak opoznienia.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 15 Maja 2017, 15:11:04
ConverterStartDelay zadziala przy ConverterStart ustawionym na manual (lub bez ConverterStart)?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Maja 2017, 15:16:22
Tak, opoznienie dziala tak samo dla wszystkich typow -- jesli przetwornica byla z jakiegos powodu wylaczona, to od momentu spelnienia warunkow dla zalaczenia do samego zalaczenia uplynie ConverterStartDelay sekund. W pewnym sensie mozna to traktowac jako (uproszczony) czas potrzebny na pelny rozruch urzadzen.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 15 Maja 2017, 20:16:54
Pojechałem sobie kawałek na nowym exe i zauważyłem, że czasami (nie wiem od czego to do końca zależy) nie animują się odpowiednio iglice rozjazdów np. pociąg jedzie na bok, a iglice były ustawione na wprost. Mam wrażenie, że problem ten występuje częściej w przypadku jazdy na rozjazd niż z rozjazdu. Druga sprawa - wydaje się, że przy wyświetlaniu VBO zintensyfikował się problem trzęsienia się kamery, szczególnie przy widoku z lusterek, aczkolwiek nie mam tutaj jakiś namacalnych dowodów, to bardziej wrażenie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 16 Maja 2017, 11:36:35
20170515: Jakby jeszcze lepsza wydajność w trybie VBO. Stacja Zduńska Wola, w dekoracji stoi EN57, człon RB wygląda jak w załącznikach. Wcześniej po wyjściu z kabiny ET42 (jechałem tym składem), sceneria rozsypała się w luźne kolorowe trójkąty, Wróciłem do kabiny odjechałem kilka kilometrów i postanowiłem odwiedzić to miejsce jeszcze raz, to co zastałem jest na obrazkach. Najpierw zastałem odwrócony człon jednostki. Za drugim razem zastałem "wszystko na głowie". W tym samej Zduńskiej woli AI zapętliło syrenę w ET42 w której siedziałem. Nie mogłem tego wyłączy. Zatrzymałem skład po wyłączeniu AI, opuściłem patyki, odłączyłem baterię. Dopiero przejście do maszynowni zatrzymało ten dźwięk. Uruchomiłem lokomotywę, pojechałem dalej, na razie bez przeszkód.
ED:
Wróciłem do ZDW jeszcze raz(3). Tyma razem zastałem wszystko poukładane (ostatni załącznik)... To wszystko za jednym uruchomieniem symulatora. Dojadę do końca i jeszcze raz wrócę.
Ed:
Nie wróciłem, wywaliło do windowsa bez żadnego komunikatu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 16 Maja 2017, 13:39:44
Wyglada to jak po trzesieniu ziemi :d  Czy to tylko zrzutki tak wygladaja, czy miales moze uruchomione dwie kopie symulatora naraz? Kaliska jest sama dosc ciezka, a latanie z kamera dookola dodatkowo doklada nieco wiecej pracy niz jazda normalna, bo widocznosc sektorow itp zmienia sie szybciej, wiec jesli sa tam jakies bledy w kodzie ktory zajmuje sie organizacja i przesylaniem danych do karty, pewnie latwiej to wylazi. U siebie niestety nie mam takich krzakow, ale moze jak przyjdzie do porzadkowania tego kawalka exe to uda sie cos tam naprawic.

edit:
Druga sprawa - wydaje się, że przy wyświetlaniu VBO zintensyfikował się problem trzęsienia się kamery, szczególnie przy widoku z lusterek, aczkolwiek nie mam tutaj jakiś namacalnych dowodów, to bardziej wrażenie.
To akurat najprawdopodobniej zludzenie -- trzesienie zalezy praktycznie w calosci od tego, jak daleko znajdujemy sie od punktu (0,0) w scenerii, wiec efekt bedzie sie roznil ze scenerii na scenerie, a nawet ze stacji na stacje na danej scenerii. Nie chce obiecywac ze da sie cos z tym zrobic, ale teoretycznie mozliwosc istnieje.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 16 Maja 2017, 13:52:14
Nie miałem odpalonych dwóch kopii symulatora. Kaliska jest zbyt ciężka na takie fanaberie. Pod F9 miałem komunikat: Error: za mało pamięci. Jadę jeszcze raz ten sam scenariusz, będzie wiadomo czy sytuacja jest powtarzalna.

Stojąc w Olechowie, drgań nieba (księżyca) i otoczenia nie miałem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 16 Maja 2017, 14:01:06
Aha :> blad pod F9 jest zglaszany przez openGL czyli posrednio karte graficzna i/lub system. Brak pamieci moze do pewnego stopnia wyjasnic sieczke -- w trybie VBO symulator wyrzuca z pamieci karty czesc 'nieuzywanych' danych, i probuje zaladowac je ponownie, gdy sa potrzebne do wyswietlenia. Wiec jesli tutaj wyskoczy brak miejsca to moga wystapic dziury w terenie, brakujace tory itp.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 16 Maja 2017, 17:11:43
Wygląda na to, że przypadek wyświetlenia dziwnych figur Rb, był przypadkowy. Nie udało się doprowadzić do takiego wyświetlania choć komunikat o pamięci, pojawił się przed wjazdem do Zduńskiej Woli. Załącznik z komunikatem, czego szukać jeśli mamy takie błędy jak na obrazkach, lub wysypy bez komunikatów. Warto obserwować ten ekran F9.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 16 Maja 2017, 18:07:59
Zapotrzebowanie na pamiec moze uda sie troche ograniczyc gdy kod bedzie juz w pelni ujednolicony i pozbedziemy sie odwolan do tekstur wpisywanych na sztywno do display lists, ale to jeszcze nie teraz.

W dzisiejszym uaktualnieniu:

- dalsze ujednolicanie kodu rysujacego; jesli pojawi sie cos dziwnego (w trybie VBO lub DL) prosze dac znac

- poprawka, w trybie VBO animacje zwrotnic nie powinny sie juz konczyc na jednej sztuce

- uporzadkowane nieco wersjonowanie exe -- w logu, na ekranie F9 i we wlasciwosciach pliku powinna byc teraz podawana wersja biezaca kompilacji, w formacie rok.miesiacdzien.system.rewizja 'system' to 86 lub 64 zaleznie od tego czy exe jest dla 32- lub 64-bitowych systemow operacyjnych. 'rewizja' z reguly nie bedzie sie zmieniac, rezerwowana jest na sytuacje gdyby tego samego dnia musiala wyjsc jakas super-pilna poprawka
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 16 Maja 2017, 18:28:44
Zapomnialem, ale nie ucieklo. ET42 wyje, zawsze od tego samego miejsca. Jadac z Olechowa z beczkami dojade bez problemu do Zdunskiej woli. Tam mamy s1 na semaforze G1/m. Stoimy kilka minut i dostajemy wyjazd, od tego momentu AI uruchamia ostre wycie. Efekt jest powtarzalny za kazdym razem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: jakubg1 w 16 Maja 2017, 18:32:33
Wycie syreny w ET42 sterowanej przez AI to efekt uboczny dwóch połączonych rzeczy:
1. Podpięcie drugiego tonu pod sygnał zamykania drzwi.
2. Błąd związany z nie wyłączaniem sygnału zamykania drzwi podczas jazdy przez AI (ten błąd jest też na borlandowych wersjach, tzw. "od zawsze").
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 16 Maja 2017, 18:40:49
To ciekawe czemu kible nie brzecza podczas jazdy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 16 Maja 2017, 18:42:07
Zamykanie drzwi na ET42 ze składem beczek, ciekawe. Opisałem mechanizm powstawania tego bo myślę, że rozwiązanie tkwi także w scenerii. Na Kaliskiej tym składem zatrzymujemy się kilkakrotnie przepuszczając wyprzedzające nas osobowe. Tylko na tym jednym semaforze AI usiłuje zamknąć drzwi bo widzi w4.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 16 Maja 2017, 18:43:59
No to w sumie mozna by to na szybko usunac wycinajac zapis o zdalnej kontroli drzwi z .fiz dla ET42, bo chyba i tak nie powinien tam byc (pomijam watpliwa inteligencje AI zalaczajacego ten sygnal i probujacej zamknac drzwi w skladzie czysto towarowym)
Swoja droga moge sprawdzic czemu sie nie wylacza, bo faktycznie w kiblach odtwarza tylko przez chwile.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 16 Maja 2017, 18:57:35
Tmj to byl patent wprowadzony na potrzeby dodatkowych mozliwosci by wykorzystac hebla z lampka i dzwiekiem. Przyznam ze przydalo by sie kilja takich uniwersali to by ten problem znikl. Jesli to z fiz sie wytnie to przestanie dzialac hebel sygnalizacji kontrolek w rusku a na potrzeby starszego exe takze i syrena. Pamuetajmy ze obowiazuje ciagle oficjalnie exe z paczki.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: jakol112 w 16 Maja 2017, 18:59:20
 Dodatkowo zapytam czy dodałeś ficzer z mechanikami zmieniającymi kabiny oraz zapytam o rozdzielenie dźwięku przycisku i hebelka.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 16 Maja 2017, 19:01:05
W rusku masz 2 przyciski. Shp i odluzniacz.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 16 Maja 2017, 19:05:40
Dodatkowo zapytam czy dodałeś ficzer z mechanikami zmieniającymi kabiny oraz zapytam o rozdzielenie dźwięku przycisku i hebelka.
Wyswietlanie figurki mechanika w kabinie 1 albo 2 zaleznie od ustawionego kierunku jest chyba od dosc dawna, czy chodzi o cos innego?
Rozdzialu dzwiekow na razie nie ma, wstepnie zaplanowane jest do wprowadzenia przy ogolnej przebudowie obslugi kabin bo wczesniej moga byc trudnosci z okresleniem kiedy wlasciwie uzywac ktorego dzwieku -- wyposazenie pojazdow moze byc rozne.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: jakol112 w 16 Maja 2017, 19:09:49
 Tak, chodzi o to tylko nie działa prawidłowo - albo wyświetla w obydwu kabinach albo w ogóle nie wyświetla.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 16 Maja 2017, 19:28:31
Nie obserwuje tego u siebie -- sprawdzam na 6dg i eksperymentalnej EP07, i obie wyswietlaja jedna i tylko jedna figure mechanika, umieszczona z przodu lub z tylu, zaleznie do ktorej kabiny przejde uzywajac Home/End. Byc moze cos jest nie tak z modelem, na ktorym widzisz inny efekt?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 17 Maja 2017, 13:56:24
Testując następne exe (VBO), nie ma właściwie nic szczególnego do dodania. Jak napisałeś wcześniej bolączki powinny ustąpić jeśli tylko karta graficzna będzie sprawnie wymieniać dane w swojej pamięci. Inaczej, zobaczymy ciekawe scenerie jak w dziale screeny/rotfl. Wszystkie błędne tekstury uzyskałem na Kaliskiej z komunikatem malo pamieci. Część nieprawidłowych tekstur potrafiła się wymienić na prawidłowe, jeśli tylko dostatecznie długo poczekałem. Porównuję teraz jak to się zachowa na DL, bo wcześniej nie miałem takich efektów.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 17 Maja 2017, 19:34:35
Na najnowszym exe z VBO nie działają mi smugi światła od reflektorów. Na exe 170515 wszystko było ok.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 17 Maja 2017, 19:36:51
Zgadza sie, wylaczylem przez pomylke, w dzisiejszym uaktualnieniu sa z powrotem, ale publikacja sie przeciagnela bo zaczalem grzebac gdzie nie trzeba :o
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 17 Maja 2017, 20:05:46
To jeszcze jedna rzecz, acz to chyba nie domena wyłącznie tego exe: po zmianie kabiny w lokomotywie nastawnik automatycznie mamy zawsze ustawiony na jazdę w przód. Niestety analogicznie nie jest dostosowywany kierunek skanowania torów, przez co jeżeli zmienimy kabinę i ruszymy do przodu bez gmerania przy ustawianiu kierunku, skanowanie cały czas będzie odbywało się do tyłu (mimo jazdy w przód). Ten problem jest także przyczyną nieotrzymywania rozkładu jazdy w misji pospwilA na Całkowie v2 po podpięciu się do wagonów, gdyż nasze wewnętrzne AI skanuje nie ten semafor, co potrzeba.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 17 Maja 2017, 20:10:04
O ile dobrze pamietam to kierunek skanowania powinien sie zmieniac automatycznie gdy kierunek jazdy nie zgadza sie z kierunkiem skanowania, co teoretycznie ma miejsce przy zmianie kabiny, bo kierunek zmienia sie wtedy na przeciwny. Ale chyba faktycznie tam cos nie dziala, sprawdze jak znajde chwile.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 17 Maja 2017, 20:19:26
Marudzenie mi dzisiaj dobrze wychodzi, więc jeszcze jedno. Jak już dostanę ten rozkład to pierwszą stację mam od razu podświetloną na zielono, mimo że do odjazdu są jeszcze 3 minuty. W efekcie nie dostaję też sygnału od kierownika.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 17 Maja 2017, 21:27:28
O ile dobrze pamietam to kierunek skanowania powinien sie zmieniac automatycznie gdy kierunek jazdy nie zgadza sie z kierunkiem skanowania, co teoretycznie ma miejsce przy zmianie kabiny, bo kierunek zmienia sie wtedy na przeciwny. Ale chyba faktycznie tam cos nie dziala, sprawdze jak znajde chwile.
No ale wywaliłeś ten warunek więc go nie ma :D
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mk1991 w 17 Maja 2017, 21:36:59
Witam. Mam poważny problem z exe C++ od kiedy uruchomiłem wszelkie możliwości logowania czynności systemu ze względu na bluescreeny jakie mi się zdarzały.
Crashdump w załączniku. Symulator nie chce się uruchomić,wywala do Windowsa, program przestał działać i koniec jazdy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 17 Maja 2017, 21:48:44
Wysyp ma miejsce gdzies w bibliotece systemu operacyjnego, niestety bez zadnych dodatkowych danych. Skoro problem wystapil po zalaczeniu logowania czynnosci systemu, moze ustapi po wylaczeniu tego logowania..?

No ale wywaliłeś ten warunek więc go nie ma :D
Tam ciagle jeden jest w TableCheck() myslalem ze wystarczy :o
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mk1991 w 17 Maja 2017, 21:51:20
W jaki sposób dostarczyć dodatkowych informacji?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 17 Maja 2017, 21:58:09
To niestety niezalezne od ciebie, informacje umieszczace sa w pliku crashdump na podstawie stanu programu w momencie wysypu, i akurat w tym wypadku dostepne jest niewiele, tzn brak jest informacji w ktorym konkretnie miejscu w exe wydarzyl sie wysyp.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mk1991 w 17 Maja 2017, 22:05:14
Jeśli jest to błąd bibliotek systemu, to czy mogło się skopać coś w Vizual studjo od Microsoft? Może podczas skanowania Combofixem coś się skopało?
Na ile coś takiego jest możliwe?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 17 Maja 2017, 22:08:05
Trudno powiedziec, ale warto dla pewnosci przeinstalowac paczki vc_redist i ewentualnie pythona. Chociaz szansa ze to cos zmieni jest dosc mizerna ;/
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mk1991 w 17 Maja 2017, 22:12:13
Oprócz uruchomienia logowań powiększyłem pamięć wirtualną do 32GB, czy ma to znaczenie? Uruchomienie pamięci wirtualnej? Wcześniej jej nie miałem uruchomionej i wszystko działało. Uruchomiłem ją z przyjacielem tylko po to, by skutecznie wyłapać ewentualny ekran śmierci.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 17 Maja 2017, 22:13:33
Nie, pamiec wirtualna w ogole dobrze iec wlaczona wiec to akurat nie powinno przeszkadzac. Chyba malo ktory PC ma ja wylaczona.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mk1991 w 17 Maja 2017, 22:19:01
W takim wypadku jedyne, co mi pozostaje, to jutro z przyjacielem zainstalować od nowa wszystkie wersje VC i rozpakować od nowa Pythona. To akurat mogę zrobić zaraz.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 18 Maja 2017, 01:24:29
W dzisiejszym uaktualnieniu:

- w ramach koncertu zyczen AI dostalo pozwolenie by przyspieszac nieco mniej lekliwie -- dopuszczalne przyspieszenie to 0.85 (z 0.5) w trybie 'leniwym' i 9.8 (z 0.9) w trybie 'agresywnym'. Kwestia otwarta jest czy nie spowoduje do klopotow ze skladami towarowymi, do sprawdzenia.

- AI zostalo nauczone ze jesli juz dajemy sygnal odjazdu, to wypada poczekac te pare sekund zanim trzasniemy drzwiami i ruszymy z miejsca

- poprawka, stacje w rozkladzie zaznaczane sa na zielono dopiero po uplynieciu czasu odjazdu

- poprawka, kierunek skanowania uaktualniany jest takze przy zmianie kabiny, bez potrzeby dodatkowego machania nastawnikiem kierunku

Marudzenie mi dzisiaj dobrze wychodzi, więc jeszcze jedno. Jak już dostanę ten rozkład to pierwszą stację mam od razu podświetloną na zielono, mimo że do odjazdu są jeszcze 3 minuty. W efekcie nie dostaję też sygnału od kierownika.
Dla porzadku, podswietlanie stacji na zielono nie ma nic wspolnego z sygnalem od kierownika, lub jego brakem, to jest zwykla kosmetyka :>  O ile dobrze pamietam to domyslnie do 'zaliczenia' przystanku i uruchomienia sygnalu itp wymagana jest obecnosc/postoj w odleglosci ponizej 50m, i np. pospwilA na calkowie v2 musi dociagnac kawalek to semafora, bo po doczepieniu jest zaparkowany ~70-80m od tabliczki
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 18 Maja 2017, 07:18:20
Cytuj
poprawka, stacje w rozkladzie zaznaczane sa na zielono dopiero po uplynieciu czasu odjazdu
Mnie zapalenie na zielono informowalo o prawidlowym zaliczeniu przystanku. Jesli nie ma to wplywu na podanie odjazdu to nalezy wrocic do tego.  Podswietlenie na zielono powinno zgasnac w momencie podania odjazdu. Moim zdaniem ta kosmetyka w dzisiejszym wydaniu zrobi zamieszanie. Prosze o rozwazenie uwagi.

ED:
Ukończyłem Kaliską na dzisiejszym exe. Wydaje mi się, że nadal wersja DL jest bardziej stabilna od VBO. Na DL nie mam żadnych problemów z pamięcią, teksturami czy wysypami. Na VBO wygląda tak, jakby dane były przesyłane z dużym opóźnieniem, stąd takie obrazki jak załączyłem wczoraj w dziale screeny/rotfl. Na DL nie mam komunikatu za malo pamieci, być może ten sposób wyświetlania jest wydajniejszy, lub jeśli nawet są prblemy to nie mamy informacji zwrotnych. Na DL pozwoliłem sobie odpalić drugą sesję równoległą do Kaliskiej: Bałtyk z dzisiejszej aktualizacji odpalił się bez problemu, po czym przeprowadziłem skład z torów postojowych na peron. Na tym skończyłem, zależało mi tylko na sprawdzeniu informacji o wysypywaniu się tej scenerii zaraz po uruchomienia.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mk1991 w 18 Maja 2017, 19:32:53
Mam pewien pomysł. Czy dało by się automatycznie tworzyć folder, w którym będą znajdowały się wszystkie raporty błędów .dmp? Ja zgromadziłem wszystkich raportów 28 i powoli zaczyna być tego dużo w folderze symulatora. Drugie moje pytanie, czy jest możliwość zgromadzenia wszystkich plików wykonywalnych EU07.exe w osobnym folderze i wskazanie ich do Rainsteda?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 18 Maja 2017, 19:41:09
Pliki wykonywalne można zgromadzić w innym folderze, ale nie można wskazać ich w rainsted do użycia. Był co prawda taki starter STV, ale to dawne dzieje. Za to polecam przenieść do osobnego folderu pliki .dmp, póki nie ma w exe wskazanego katalogu do ich umieszczania.Nie napisałeś czy udało się przywrócić uruchamianie C++.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 18 Maja 2017, 22:06:50
Dla porzadku, podswietlanie stacji na zielono nie ma nic wspolnego z sygnalem od kierownika, lub jego brakem, to jest zwykla kosmetyka :>  O ile dobrze pamietam to domyslnie do 'zaliczenia' przystanku i uruchomienia sygnalu itp wymagana jest obecnosc/postoj w odleglosci ponizej 50m, i np. pospwilA na calkowie v2 musi dociagnac kawalek to semafora, bo po doczepieniu jest zaparkowany ~70-80m od tabliczki
O, to jest cenna informacja, nie wiedziałem. Tylko w takim razie nie wiem, czy to można uznać za spójne z resztą sterowania, bo wydaje się logiczne, że warunek dla zaliczenia przystanku (podświetlenia na zielono) i sygnału kierownika powinien być ten sam. Inaczej zawsze będzie ryzyko, że jedno z drugim się rozjedzie. Inny przykład - w W4 masz wpisany peron 300 m, pociąg AI ma 100 m, zatrzymuje się zaraz na początku. AI w takim wypadku już nie rusza dalej, bo w swoim mniemaniu "zalicza" przystanek, ale sygnału od kierownika by już nie dostało.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 19 Maja 2017, 00:48:15
Mnie zapalenie na zielono informowalo o prawidlowym zaliczeniu przystanku. Jesli nie ma to wplywu na podanie odjazdu to nalezy wrocic do tego.  Podswietlenie na zielono powinno zgasnac w momencie podania odjazdu. Moim zdaniem ta kosmetyka w dzisiejszym wydaniu zrobi zamieszanie. Prosze o rozwazenie uwagi.
Tutaj zle sie chyba zrozumielismy :>  exe rowniez przed wprowadzeniem zmiany 'zapalalo' stacje na zielono dopiero po jej przewinieciu, tzn gdy rozklad przestawial sie na stacje nastepna, co nastepuje dopiero po minieciu czasu odjazdu. Poprawka dotyczy tylko zachowania na stacji poczatkowej, gdzie pod tym wzgledem moglo byc inaczej.

Podswietlanie w rozkladzie jest dosc prymitywna sztuczka, i nie jest "swiadome" czy pociag faktycznie stoi na stacji wymienionej w rozkladzie. Zmiana zachowania by aktualna stacja podswietlala sie gdy pociag faktycznie na niej stanie, i wracala do 'normy' po czasie odjazdu wymagaloby wiekszych zmian.

Jesli chodzi o stabilnosc itp, to przy trybie VBO jest ciagle dosc powazny i nie zlokalizowany blad, ktory poprzez wpisywanie danych nie tam gdzie trzeba prowadzi do wysypow i roznych innych efektow ubocznych. Niestety znalezienie gdzie dokladnie ma to miejsce bedzie najprawdopodobniej pracochlonne.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: pol102 w 19 Maja 2017, 00:52:04
Trzeba więcej pułapek postawić ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 19 Maja 2017, 21:01:05
Taa, chyba na pokemony ;d

bledy sie zlapaly, tzn znalazly. Byly "od zawsze" ale ukrywaly sie dosc dobrze w trybie DL, a VBO byl jaki byl. W dzisiejszym uaktualnieniu:

- poprawka, exe nie "optymizuje" juz zwrotnic do tego stopnia, ze zamiast utworzyc dla nich siatke 3d zaczyna wstawiac smieci gdzie popadnie

- poprawka, dzielenie krzywych na odcinki nie prowadzi juz okazjonalnie do psucia innych danych

nie wiem czy to usunie wszystkie dziwne efekty uboczne w trybie VBO, ale powinno pomoc przynajmniej na czesc z nich.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 19 Maja 2017, 21:04:53
20170517, spóźnione trochę.
Ostatnie trzy próby ukończenia jazdy beczkami na Kaliskiej (ET42) na VBO, kończyły się wysypem, zawsze w tym samym miejscu. Ale plus na wersji z 17 maja był taki, że nie mam komunikatów "za malo pamieci"
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 19 Maja 2017, 21:08:07
Jesli znajdziesz moment to sprawdz jak to pojdzie pod 519, powinno byc lepiej ;o
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Niebugoclaw w 20 Maja 2017, 14:06:32
Mam pytanie jak obecne exe C++ jest dostosowane do PoKeys55? Czy nadaje się ono do regularnego użytku do podłączonego pulpitu? Zauważyłem, że zaznaczeniu w Rainsted informacji zwrotnych do PoKeys, mamy w kabinie "symulację pijanego maszynisty", tzn. kamera lata w koło bez ingerencji myszki.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 20 Maja 2017, 14:20:20
Jakiekolwiek dostosowanie do elementow zewnetrznych wymaga dostepu do rzeczonych elementow, a ja takiego nie posiadam. O ile sie nie myle to pracuje nad tym @maciek001 chociaz nie wiem czy nad PoKeys, czy jakims innym wariantem.

Nie wiem tez dlaczego ekran mialby wirowac akurat z powodu podlaczenia PoKeys, bo tam nie ma chyba zadnej interakcji tego rodzaju. To moze zabrzmiec glupio, ale nie masz czasem podpietego do komputera gamepada, rzuconego gdzies na podloge/biurko do gory nogami, tak ze drazek zablokowany jest w jednym kierunku? Ewentualnie podpietego joysticka? Oba te urzadzenia sa teraz w pewnym stopniu obslugiwane, i wychylenia osi sa przekladane na ruch kamery.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Niebugoclaw w 20 Maja 2017, 14:22:18
Oprócz pulpitu i myszki nie mam nic podłączone. W załączeniu log.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 20 Maja 2017, 14:24:53
W rzeczonym logu:

Cytuj
Connected gamepad: Virtual Joystick

cos tam jest podpiete w systemie takiego, ze jest widziane/obslugiwane jak joystick. Byc moze jest to wlasnie pulpit, trudno powiedziec na odleglosc. Windows ma w panelu sterowania cos co sie nazywa 'kontrolery gier' (game controllers) byc moze to dziwne urzadzenie jest tam wymienione.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Niebugoclaw w 20 Maja 2017, 14:27:40
Tak, ten joystick to właśnie pulpit. Po odłączeniu USB ekran przestaje wirować.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 20 Maja 2017, 14:34:13
Hmm zapewne nastawniki albo cos podobnego sa przekazywane jako wychylenie osi. No to kiepsko. Pewnym prowizorycznym rozwiazaniem mogloby byc podlaczenie jakiegolwiek faktycznego gamepada/joysticka a nastepnie podpiecie pulpitu jako drugiego (tak, zeby pulpit wyladowal na liscie kontrolerow pozniej a exe bralo pod uwage tylko sygnaly rzeczywistego joysticka) Na troche dluzsza mete zapewne trzeba bedzie doinstalowac opcje w .ini zeby obsluge gamepada wylaczyc.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 20 Maja 2017, 14:53:26
Wczorajsza nocna i dzisiejsza jazda. AI przerżnęło o 3m. W okolicach Radliczyc wywaliło mnie ze znanym komunikatem. Przejadę się jeszcze na 64 bitach.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 20 Maja 2017, 15:16:27
Nie chcę krakać, ale jakiś czas temu grzecznie się spytałem czy są problemy z exe c➕➕ na Pokeys.
@Niebugocław, sprawdź nadpisane klawisze w key.ini. Prawdopodobnie nowe klucze funkcyjne powodują, że Pokeys wariuje.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 20 Maja 2017, 15:54:56
W okolicach Radliczyc wywaliło mnie ze znanym komunikatem.
Zaraz zaraz, komu znanym temu znanym :o  ktory to konkretnie komunikat byl, o braku pamieci czy cos innego?

Nie chcę krakać, ale jakiś czas temu grzecznie się spytałem czy są problemy z exe c➕➕ na Pokeys.
Jak juz kilkukrotnie wspomnialem nie mam dostepu do PoKeys ani zadnego tym podobnego urzadzenia, wiec nie jestem w stanie wykryc lub poprawic problemow w tym obszarze. Musi sie tym zajac osoba ktora taki dostep ma. Zrodla programu sa publicznie dostepne, a dostarczany kod jest dolaczany tak szybko jak jest to mozliwe.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 20 Maja 2017, 16:02:15
Niestety brak screena a pamięć dobra ale krótka. Pojadę jeszcze raz, jak wywali dam znać. Najpierw chce przejechać jeszcze raz na 64 bitowym exe. Pytanie istotnej wagi, czy bibliotekę python27.dll można w kompilować w exe? Istotne to z punktu widzenia składania paczki całościowej i uproszczenia instalacji exe 64 lub 32, w zależności od wyboru użytkownika.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 20 Maja 2017, 16:07:33
Pytanie istotnej wagi, czy bibliotekę python27.dll można w kompilować w exe?
Nie bardzo, python miesza w dosc szczegolny sposob. Natomiast pewna mozliwoscia jest wyrzucenie w ogole python27.dll z paczki, i zamiast tego instalacja przez uzytkownika jednej z 'oficjalnych' instalacji python (32- lub 64- bit albo obie) w sposob podobny do tego, jak instalowane sa pakiety vc_redist.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 20 Maja 2017, 16:10:21
Właśnie chcieliśmy uniknąć kolejnego wyboru i instalacji, przez użytkownika. Jest jak jest.
ED:
Na wersji 64 bitowej posypał się scenariusz, EU07-344 zatrzymała się 100m przed peronami w Kaliszu (w kierunku do Łodzi), skutek, brak możliwości ze Skalmierzyc towarowego w kierunku Łódź, nie odjechała ze Skalmierzyc także Sm42 z paroma wagonikami w kierunku na Ostrów, ja nie dostałem wjazdu do Skalmierzyc dla ET42-024 prowadzącej skład beczek. Beka wyszła.
Do tego momentu, nic nie wysypało.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 20 Maja 2017, 21:01:54
W dzisiejszym uaktualnieniu:

- korekta zalaczania sprezarki dla lokomotyw dwuczlonowych (ET41, 42): sprezarki zalaczaja sie tylko gdy moga uruchomic sie razem, tzn zadna nie jest blokowana przez wylacznik cisnieniowy (do pewnego stopnia jest to tylko proteza, bo nie obejmuje zachowania innych kombinacji ukrotnienia itp, ale na razie lepsza nic nic)

- korekta logiki wykrywania czy lokomotywa jedzie 'pusta' i powinna uzywac hamulca lokomotywy a nie glownego, dotyczylo lokomotyw dwuczlonowych (ET41, 42)

- dodany przelacznik w pliku .ini, input.gamepad kontrolujacy czy exe ma obslugiwac gamepad/joystick. Domyslnie zalaczone, moza wylaczyc poprzez wpis
input.gamepad no
powinno pomoc w przypadku konfiguracji z podlaczonym kontrolerem PoKeys (przynajmniej dopoki w exe nie ma pelnej konfiguracji dla gamepada)

- w ramach koncertu zyczen: AI nie wciska sie nieproszona na fotel mechanika w lokomotywie uzytkownika przy uruchomieniu w trybie debug
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 20 Maja 2017, 21:09:50
Edytowałem swój poprzedni post, nie zauważyłem że jest następny. Za AI, dziękuję.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 20 Maja 2017, 21:16:04
TMJ to poproszę jeszcze wyłącznik przetwornicy i sprężarki dla sekcji w której jedziemy (ET42).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 20 Maja 2017, 21:20:55
Czekaj, bo nie bardzo chwytam, jak ma to dzialac? Czy w ET42 jest osobny dedykowany przelacznik w kazdej kabinie dla przetwornicy przedniej/tylnej i sprezarki przedniej/tylnej? Czy jakos inaczej?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: hanys w 21 Maja 2017, 15:02:18
Na najnowszym załączonym exe czyli "eu07-x64_170520" np. w ET22 nie idzie później opuścić pantografów po podniesieniu. Nie działa w ET22 oświetlenie kabinowe poprzez kliknięcie w klawisz " ' ". Na chwilę obecną tyle z problemów, było tam tego więcej, ale nie pamiętam teraz co.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Sawi w 21 Maja 2017, 15:05:48
Z tego co czytałem to zmieniła się nieco klawiszologia i większość już nie potrzebuje Shiftów. Dorzuć loga dla pewności.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: hanys w 21 Maja 2017, 15:10:37
Wiem przecież. Z tego co zauważyłem to chyba wcale "Shifta" nie idzie użyć oprócz przeskoczenia do układów na elektrowozach.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 21 Maja 2017, 15:14:24
Oprocz zmian ktore wspomnial @Sawi o ile dobrze pamietam przynajmniej niektore ET22 maja zdefiniowane przelaczniki impulsowe pantografow, i brak im definicji przyciskow ktore te pantografy moglyby opuszczac. Tego typu braki wymagaja uporzadkowania plikow .mmd i/lub .fiz dla danego egzemplarza.

shift jest okazyjnie uzywany przy niektorych funkcjach -- zalaczanie sprezarki pantografow, przelaczniki sygnalow konca pociagu i ogolniej przy obsludze przelacznikow wielostopniowych (programatory swiatel, nastawa predkosci reakcji hamulca itp) gdzie shift + klawisz 'zwieksza' wartosc przelacznika, a sam klawisz ja zmniejsza.

edit:
bledy widac w pliku errors
Failed to locate sub-model "grzybpanta" in 3d model "dynamic\pkp\et22_v2\201e_3]kabina_a.e3d"
Failed to locate sub-model "grzybpantb" in 3d model "dynamic\pkp\et22_v2\201e_3]kabina_a.e3d"
grzybki przypisane do opuszczania poszczegolnych pantografow albo nie istnieja, albo nazywaja sie inaczej niz podano w konfiguracji.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Sawi w 21 Maja 2017, 15:17:30
Podejrzewam, że mało będzie chętnych do tego typu zabaw więc jak przybliż mi temat to się tym zajmę. Z doświadczenia wiem, że odkładanie coś na potem nie jest zbyt rozsądnym wyjściem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 21 Maja 2017, 15:23:10
Faktycznie, chetnych jest dosc malo :>  na bugtrackerze paczki calosciowej jest kilka zgloszen na temat poszczegolnych kabin i jest tez temat w dziale beta -- http://eu07.pl/forum/index.php/topic,29049.0.html w ktorym jest to dyskutowane troche ogolniej. Jesli potrzebne beda jakies dodatkowe informacje to krzycz~
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: hanys w 21 Maja 2017, 15:23:37
Testowałem teraz byka:
201E, 201E-P tylni pantograf idzie opuścić natomiast przedni już nie.
201E-W działa prawidłowo.
201E-RN, 201E-RW, 201E-ZEZ nie działa opuszczanie.
Trzeba było by teraz przelecieć cały tabor czy działa, dodatkowo np. w EU07 nie działa przyciemnianie/rozjaśnianie oświetlenia kabinowego.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 21 Maja 2017, 15:24:35
Rozbijajcie to na 1 mmd - 1 zgłoszenie i umieszczajcie w bugtrackerze paczki.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Sawi w 21 Maja 2017, 15:28:35
@tmj czyli teoretycznie braki i wszelkiego rodzaju niezgodności wypluwa w errorsie.txt tak?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 21 Maja 2017, 15:32:58
Wiekszosc laduje w errors, zgadza sie (te ktore wychodza przy ladowaniu kabiny)
Oprocz tego czesc przyciskow podstawowych jest obslugiwana nawet gdy przycisk nie jest zdefiniowany (zeby dalo sie w ogole takimi pojazdami jezdzic) w takim przypadku przy nacisnieciu przycisku dawana jest wzmianka w log.txt
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Sawi w 21 Maja 2017, 15:37:56
Ok no to trzeba będzie przejrzeć tabor, począwszy od siódemek a skończywszy na tamarach. Im mniej protez tym lepiej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 21 Maja 2017, 16:30:38
Tmj tak jak ci pisalem. Przelacznik jest czynny tylko na sekcji na ktorej jedziemy. Chodzi o to ze mech moze wylaczyc sprezarke i przeywornice na sekcji na ktorej jedzie. Chodzi o halas. To sa dedykowane hebelki. W tylnej sekcji zawsze dziala.  Prosze tez o wylacznik rozrzadu i stycz liniowych.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Tadek40 w 21 Maja 2017, 17:00:09
Witam. Wywala oto taki błąd przedstawiony na screenie. Wszystko próbowałem. Zainstalowałem potrzebne rzeczy itp. Wiecie z czym problem? Pozdrawiam. Używany EXE to wersja EXE 64bit.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 21 Maja 2017, 17:14:56
Tak, niewlasciwa biblioteka python27.dll musi byc taka na 64 bity.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 22 Maja 2017, 02:52:11
W dzisiejszym (wlasciwie wczorajszym) uaktualnieniu

- poprawki, mam nadzieje ostateczne, generowania torow/drog/skrzyzowan itp w trybie VBO. Tymczasowo zostawiam jeszcze w exe pulapki na pokemony, wiec jesli mozna prosze sprawdzic po zakonczeniu jazdy na scenerii, czy w pliku errors pojawily sie wpisy w rodzaju
Cytuj
Vertex buffer overflow (..)
lub
Cytuj
Vertex amount mismatch (..)
itp. I jesli tak, to dac znac.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 22 Maja 2017, 18:37:09
Tmj tak jak ci pisalem. Przelacznik jest czynny tylko na sekcji na ktorej jedziemy. Chodzi o to ze mech moze wylaczyc sprezarke i przeywornice na sekcji na ktorej jedzie. Chodzi o halas. To sa dedykowane hebelki. W tylnej sekcji zawsze dziala.  Prosze tez o wylacznik rozrzadu i stycz liniowych.
Wylacznika rozrzadu raczej na razie nie bedzie, bo nie ma w exe mechanizmow w ktore moznaby go wpiac (indywidualnie zapamietywany stan urzadzen dla poszczegolnych pulpitow/kabin, czy chocby obecnosc w pamieci wiecej niz jednej kabiny naraz) Bedzie musiala wystarczyc reszta:

- poprawka, wylacznik stycznikow liniowych w lokomotywach dwuczlonowych (ET41, 42) wplywa na stan obu czlonow zamiast tylko obsadzonego

- wylacznik stycznikow liniowych moze byc obslugiwany jako bistabilny, a nie tylko impulsowy jak dotychczas. Tryb bistabilny ustawia sie wpisem w pliku .fiz w sekcji Switches:
MotorConnectors=Toggle
przy braku wpisu przelacznik jest traktowany domyslnie jako impulsowy

- dodana obsluga przelacznikow przetwornicy i sprezarki, dzialajacych selektywnie dla obsadzonego czlonu. Kontrolowane domyslnie przez Shift-X (przetwornica) i Shift-X (sprezarka) Nazwy przyciskow w pliku .mmd to
converterlocal_sw
compressorlocal_sw
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 22 Maja 2017, 19:40:23
Wiem ze bylo by to chamskie z mojej strony ale zapytam takze czy jest mozliwe te elementy zastosowac do et21? Co prawda to nie 2czlon ale na pulpicie mozna heblami odlaczac dowolna sprezarke i przetwornice. A i B.  Mechanicy zalaczaja te tylne a przednie odlaczaja z uwagi na halas.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 22 Maja 2017, 19:42:36
Symulowana lokomotywa ma po jednym urządzeniu każdego typu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 22 Maja 2017, 19:50:49
Zgadza sie, jest tylko jedna na pojazd/czlon, wiec chyba czego takiego nie obsluzy.

Przy okazji, te nowe przelaczniki dzialaja w ten sposob, ze opcjonalnie wylacza urzadzenie w danym czlonie, ale zeby zadzialalo to musi byc zalaczony zarowno ten wylacznik 'lokalny' jak i 'glowny'. Czy tak jest poprawnie, czy do dzialania wystarczy ze zalaczony jest tylko jeden z nich?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 22 Maja 2017, 20:08:28
- korekta zalaczania sprezarki dla lokomotyw dwuczlonowych (ET41, 42): sprezarki zalaczaja sie tylko gdy moga uruchomic sie razem, tzn zadna nie jest blokowana przez wylacznik cisnieniowy (do pewnego stopnia jest to tylko proteza, bo nie obejmuje zachowania innych kombinacji ukrotnienia itp, ale na razie lepsza nic nic)
- poprawka, wylacznik stycznikow liniowych w lokomotywach dwuczlonowych (ET41, 42) wplywa na stan obu czlonow zamiast tylko obsadzonego
W obu powyższych przypadkach nie zauważyłem zmiany w porównaniu do wcześniejszych exe (testowałem na dzisiejszym).
- wylacznik stycznikow liniowych moze byc obslugiwany jako bistabilny, a nie tylko impulsowy jak dotychczas. Tryb bistabilny ustawia sie wpisem w pliku .fiz w sekcji Switches:
MotorConnectors=Toggle
przy braku wpisu przelacznik jest traktowany domyslnie jako impulsowy

- dodana obsluga przelacznikow przetwornicy i sprezarki, dzialajacych selektywnie dla obsadzonego czlonu. Kontrolowane domyslnie przez Shift-X (przetwornica) i Shift-X (sprezarka) Nazwy przyciskow w pliku .mmd to
converterlocal_sw
compressorlocal_sw
Działa prawidłowo. Zauważyłem natomiast inna dziwną rzecz - kiedy podczas mocnego hamowania samą lokomotywą, np. za pomocą hamulca ręcznego zaciągniętego do oporu (musi być wpis "ManualBrake=Yes" w *.fiz, żeby hamulec w ogóle działał), zablokują się w niej koła (z reguły już przy małej prędkości) i zacznie się wtedy piaskować, to pojawia się jakaś tajemnicza siła, która przy wciśniętym pedale piasecznicy rozpędza skład do ok. 17km/h i dopiero wtedy koła łapią przyczepność zaczynając się obracać i hamować. Jeśli puści się pedał piasecznicy przed zatrzymaniem i koła znów się zablokują, to ponownie można przyspieszać za pomocą tej darmowej energii ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 22 Maja 2017, 20:31:30
- korekta zalaczania sprezarki dla lokomotyw dwuczlonowych (ET41, 42): sprezarki zalaczaja sie tylko gdy moga uruchomic sie razem, tzn zadna nie jest blokowana przez wylacznik cisnieniowy (do pewnego stopnia jest to tylko proteza, bo nie obejmuje zachowania innych kombinacji ukrotnienia itp, ale na razie lepsza nic nic)
- poprawka, wylacznik stycznikow liniowych w lokomotywach dwuczlonowych (ET41, 42) wplywa na stan obu czlonow zamiast tylko obsadzonego
W obu powyższych przypadkach nie zauważyłem zmiany w porównaniu do wcześniejszych exe (testowałem na dzisiejszym).
Podejrzewam ze efekty latwiej jest zaobserwowac na ET42 niz ET41 (ze wzgledu na panel z kontrolkami dla obu czlonow osobno) W poprzednich wersjach exe jesli sprezarki w uokrotnieniu byly nastawione na prace automatyczna, to po aktywacji wylacznika cisnieniowego i spadku cisnienia, ponownie zalaczala sie tylko sprezarka w czlonie przednim -- aktualizacja czlonu drugiego nastepuje w programie juz po tym jak sprezarka w czlonie przednim zalacza sie i zwieksza nieco cisnienie w przewodzie, i w efekcie wylacznik cisnieniowy czlonu tylnego nigdy sie nie deaktywowal.

Wylacznik stycznikow liniowych w wersjach poprzednich ustawial tylko zmienne dla kontrolowanego czlonu, i signal nie byl przekazywany sasiadom -- w efekcie czlon tylny nie byl odlaczany i pracowal dalej. W ET41 nie bardzo to widac, bo jest tam tylko jedna kontrolka stycznikow (i nie dziala prawidlowo ale to juz inna historia) ale mozna to wylapac w dosc pokretny sposob -- po odhamowaniu i ustawieniu nastawnika na pozycje jazdy styczniki zamykaja sie, wciskamy wtedy wylacznik L, a nastepnie trzymajac go przelaczamy odczyt pradu przez shift-Z: dla pierwszego czlonu poprawnie wykaze 0, ale po przelaczeniu na wyswietlanie stanu drugiego czlonu miernik idzie w gore, bo czlon ciagle pcha :>

(tzn pchal, teraz powinno byc jak trzeba)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 22 Maja 2017, 21:18:22
Tmj na twoje pytanie ciezko mi odpowiedziec ale przegladajac zdjecie z kabin widze ze w obu sekcjach sa te heble wylaczone wiec wnioskuje ze maszyny sekcji tylnej zawsze pracuja. Mechanik zawsze wylacza w kabinie ktora opuszcza hebel rozrzadu a zalacza w przejmowanej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 22 Maja 2017, 21:29:05
Co do sprężarek, to jednak nadal jest jak było, co widać po prędkości napełniania zbiorników głównych - przy włączeniu hebelka sprężarek poniżej 0,75MPa w ZG napełniają się one wyraźnie szybciej, niż przy samoczynnym załączeniu sprężarek po spadku ciśnienia do 0,75MPa. Czasami nie wyłączają się też jednocześnie. Dużo łatwiej się testuje po podniesieniu wartości "MinCP" i "MaxCP" o np. 0,03Mpa w *.fiz jednego z członów).
A wyłącznik styczników liniowych łatwiej sprawdzać w inny sposób - przejść nastawnikiem na którąś pozycję dalej niż pierwsza (wystarczy już na drugą) tak, żeby pracowały oba człony i wtedy nacisnąć przycisk wyłączenia. Raz, że po wciśnięciu [Shift]+[Z] widać pobór prądu drugiego członu, a dwa, że kręcąc dalej nastawnikiem lokomotywa rozpędza się bez poboru prądu w pierwszym członie i robi to ociężalej niż normalnie, bo pracuje tylko jeden człon.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 22 Maja 2017, 21:43:39
A wyłącznik styczników liniowych łatwiej sprawdzać w inny sposób - przejść nastawnikiem na którąś pozycję dalej niż pierwsza (wystarczy już na drugą) tak, żeby pracowały oba człony i wtedy nacisnąć przycisk wyłączenia. Raz, że po wciśnięciu [Shift]+[Z] widać pobór prądu drugiego członu, a dwa, że kręcąc dalej nastawnikiem lokomotywa rozpędza się bez poboru prądu w pierwszym członie i robi to ociężalej niż normalnie, bo pracuje tylko jeden człon.
No zgadza sie, i ten wlasnie efekt zostal w dzisiejszym uaktualnieniu usuniety -- po wcisnieciu L odcina oba czlony zamiast tylk pierwszego, i miernik wykazuje ten sam stan (zero) tak dla pierwszego jak i drugiego, a lokomotywa zwalnia zamiast rozpedzac sie dalej.
Jesli u ciebie zachowanie jest inne, czy moglbys dla mojego swietego spokoju wcisnac f9 i zobaczyc, czy wystepuje to na wersji 17.522 a nie jakiejs starszej, ktora zaplatala sie przez pomylke?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 22 Maja 2017, 22:03:09
Ficzery wprowadzone i dzialaja dobrze. O to mi chodzilo. Zapraszam do testu (kto ma range BT). ET42 zawiera wszystkie dotad wprowadzone ficzery od TMJ.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 22 Maja 2017, 22:13:14
Tak, pod F9 jest napisane 17.522.64.0 Już nawet uruchamiam nie przez Rainsted, ale przez dwuklik na exe eu07-x64_170522. Zachowanie takie sprawdzałem na ET41 i dwóch EU07 - w obu przypadkach jest jak wcześniej opisałem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 22 Maja 2017, 22:18:09
Teraz mi dopiero przyszlo do glowy, czy czlony sa spiete sprzegiem 'stalym' czyli +128? W ten sposob exe wyszukuje druga 'polowke' i jesli brakuje takiego spiecia, to nie przekaze sygnalu. Technicznie rzecz biorac powinno tez sprawdzac przewodu uokrotnienia, ale to juz odpuscilem.
Testujac u siebie mam ET41 spiety sprzegiem 183, a ET42 przez 191, bo dochodza dodatkowo przewody wysokiego napiecia.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 22 Maja 2017, 22:29:04
Rzeczywiście, po dodaniu sprzęgu "+128" wyłącza liniowe w drugim członie ET41, ale ukrotnionej EU07 już nie. Lepiej by też było, gdyby zamiast na "+128" reagowało na "+4", bo "+128" nie widziałem chyba jeszcze nigdy w żadnym scenariuszu (nie twierdzę, że nie ma).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 22 Maja 2017, 22:50:23
Tak, efekt jest na razie ograniczony do ET 41/42, bo raz ze nie ma funkcji kontroli stycznikow w uakrotnieniu, a dwa ze nie wiem jak to dziala w rzeczywistosci, tzn czy sygnal jest podawany do innych pojazdow. Miedzy innymi dlatego test jest na sprzeg staly a nie uokrotnienie -- latwiej zrobic jeden czy dwa wpisy w scenariuszach, niz wykrywac co tak naprawde jest przyczepione na drugim koncu kabla.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 22 Maja 2017, 22:53:19
TMJ musisz wziasc jeszcze pod uwagę wazna kwestie. ET40/41 może dzialac w pojedynke. ET42 już nie. Żadna pojedyncza sekcja ET42 nie jest w stanie funkcjonować w pojedynke. Nie ma sterowania nie ma nic.

https://youtu.be/oiWXDd3OymM https://youtu.be/9_pEjR6dFvY Pod tym linkiem za godzine będzie maly filmik prezentujący ficzery dotyczące i wprowadzone do ET42. Min działanie wyłącznika SL. Obsluga hamulca recznego. Obsluga hamulca ED. Dzialanie wylacznikow pulpitu obecnie dostępnych i używanych (piasecznice, syreny, podhamowanie, sygnalizacja, obsluga przyciemnienia reflektorow itd.).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 22 Maja 2017, 22:55:12
W zasadzie mogłoby wyłączać w każdym ukrotnionym pojeździe, skoro same ukrotnienia i tak są mocno naciągane w większości pojazdów... Wtedy nie trzeba się martwić, co jest doczepione - jest sprzęg "+4", to wciśnięcie przycisku wyłączenia liniowych wyłącza je we wszystkich ukrotnionych pojazdach i tyle.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 22 Maja 2017, 23:18:03
TMJ musisz wziasc jeszcze pod uwagę wazna kwestie. ET40/41 może dzialac w pojedynke. ET42 już nie. Żadna pojedyncza sekcja ET42 nie jest w stanie funkcjonować w pojedynke. Nie ma sterowania nie ma nic.
No ok, ale to juz raczej jest rola autora scenerii zeby wstawic do niej kompletna ET42 a nie polowke. I jak zepnie na 128 to w polu rozpiac tego nie mozna, wiec bedzie jezdzic jak trzeba.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: wołodyjowskiIC w 23 Maja 2017, 13:17:14
Ja mam problem taki, że jak uruchamiam kaliską SM42 to pokazuję takie okno jak na załączniku.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 23 Maja 2017, 13:47:46
Trudno powiedziec, na oko nie widac tutaj nic specjalnie dziwnego. Czy Kaliska laduje ci sie w ogole, tzn czy uruchamiaja sie inne scenariusze oprocz tego jednego? Jesli nie, to moze byc zwyczajny brak dostatecznej ilosci pamieci - takie rzeczy jak przegladarka internetowa tez swoje tam pobieraja.
Nawiasem mowiac 515 to dosc stara wersja exe, chociaz nie pamietam czy byle w miedzyczasie zmiany ktore moglyby zrobic roznice w trybie DL.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 23 Maja 2017, 13:52:50
Mnie ten komunikat przytrafia się na Kaliskiej w scenariuszu ET42 z Olechowa. Także na VBO. Z tym, że wysyp następuje w okolicach Sieradza lub Zduńskiej Woli. U mnie dotyczy exe 201702520 i 21. Wcześniej udawało mi się kończyć ten scenariusz.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: wołodyjowskiIC w 23 Maja 2017, 14:12:36
Trudno powiedziec, na oko nie widac tutaj nic specjalnie dziwnego. Czy Kaliska laduje ci sie w ogole, tzn czy uruchamiaja sie inne scenariusze oprocz tego jednego? Jesli nie, to moze byc zwyczajny brak dostatecznej ilosci pamieci - takie rzeczy jak przegladarka internetowa tez swoje tam pobieraja.
Nawiasem mowiac 515 to dosc stara wersja exe, chociaz nie pamietam czy byle w miedzyczasie zmiany ktore moglyby zrobic roznice w trybie DL.
Inne scenariusze się uruchamiają prawidłowo, a testowałem na najnowszym EXE 522.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 23 Maja 2017, 14:24:31
ET42 niestety jezdzi u mnie normalnie do samego konca scenariusza. Chociaz dziwne ze problem pojawil sie teraz, bo w tych ostatnich wersjach byly raczej usuniete bledy ktore mogly cos takiego powodowac, a nie dodane ;/
Inne scenariusze się uruchamiają prawidłowo, a testowałem na najnowszym EXE 522.
Aha, dzieki, sprawdze. Zastanawiam sie teraz, czy ten wysyp (takze u @Krzyska) nie ma czegos wspolnego z jakim konkretnym, niestandardowym taborem. U siebie jezdze wlasciwie tylko na tym co jest w paczce oficjalnej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 23 Maja 2017, 14:36:12
Exeki testuje tylko na sceneriach zawartych w paczce. Do tego dochodzi Kaliska i ostatnie Całkowo. Tabor nieoficjalny, nawet jeśli coś tam mam, to wstawiam tylko na td. Staram się aby warunki były podobne do Twoich. ET42 jest z PC, tą od EP08-015 mam na innej paczce. W tym tygodniu mam mniej czasu na jazdy, mimo że siedzę przy komputerze i nie bardzo jest jak wydrążyć temat.
Nie wiem czy to jest odkrywcze, ale zauważyłem, że jeśli chcemy pojeździć na 64 bitowym systemie exekiem 32 bitowym, to moimo zainstalowanego VC2015/64bit woła biblioteki msvcr140.dll. Problem ustąpił po doinstalowaniu VC2015 w wersji 32 bitowej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: wołodyjowskiIC w 23 Maja 2017, 15:50:47
Robię podobnie jak @Krzysiek jeśli chodzi o najnowsze EXE. Sprawdzałem jeszcze w ten sposób, że wszystkie aplikacje, które mogłyby zabierać pamięć wyłączyłem, załączyłem samą kaliską i EXE po prostu się zawiesiło.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 23 Maja 2017, 16:55:21
Wrzucilem u siebie ten scenariusz i obawial sie ze zaladowal sie u mnie i uruchomil bez zadnych bledow :<
Dosc problematyczne jest, ze o ile dobrze rozumiem to przy wysypie nie generuje sie crashdump?
W ramach drobnego eksperymentu przerzucilem komunikat o bledzie przy alokacji pamieci do pliku errors. Dzialania to nie poprawi, ale moze da sie wyjasnic, czy przyczyna lezy tutaj, czy gdzies indziej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: hanys w 23 Maja 2017, 18:16:45
Nie wiem czy to prawidłowe posunięcie czy nie, ale problemem z tym opuszczaniem pantografów poruszany powyżej był wpis w .FIZ:
Cytuj
Switches: Pantograph=Impulse
Po jego usunięciu pantografy działają prawidłowo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 23 Maja 2017, 18:30:36
Zgadza sie, jesli urzadzenie (pantograf, sprezarka itp) jest zdefiniowany jako impulsowy, to pozwala tylko zalaczyc dane urzadzenie. Do wylaczenia musi byc tez zdefniowany drugi przycisk, dla pantografow jest to albo wylacznik konkretnego pantografu, albo wszystkich. Bez definicji wylaczyc urzadzenia sie nie da. Jest to zachowanie celowe bo niektore pojazdy niektorych wylacznikow nie maja, a exe nie wrozka i samo nie zgadnie co w ktorym ma byc.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: wołodyjowskiIC w 23 Maja 2017, 18:55:54
Może problemem jest mój komputer;) W każdym razie przetestowałem na tym EXE i załączam craschdumpa.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 23 Maja 2017, 23:21:11
Crashdump faktycznie cos znalazl :> ten konkretny wysyp mial miejsce w dosc prehistorycznym kodzie obslugujacym dzwiek, akurat u mnie nie wysypywal sie na tym ale najwidoczniej nie bylo to uniwersalne. Zrobilem korekte ktora teoretycznie moze pomoc, czy pomoze w praktyce trzeba sprawdzic.

oprocz tego w dzisiejszym uaktualnieniu:

- uruchomiona ponownie obsluga opcji -e3d, konwertujacej rekursywnie modele .t3d do formatu binarnego. Czy sama konwersja produkuje cokolwiek uzytecznego nie wiem, ale oficjalnie jest
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: wołodyjowskiIC w 24 Maja 2017, 17:23:16
Pobrałem tą wersję EXE i stwierdziłem, że np. drawinowo działa bez zarzutów, a kaliska cały czas nie. Nie chcę głowy za bardzo tym zawracać, ale intryguję mnie fakt, że zawsze kaliska działała zarówno na starym jak i na nowym EXE. Nie jestem pewien, ale może ma to związek z tym, że usunąłem poprzednie wersję EXE, a zostawiłem tylko te najnowsze i dwa najstarsze od eu07.exe, next4 i 517 do 523.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 24 Maja 2017, 17:29:40
Usuniecie starych exe raczej nie powinno miec efektu, bo uruchamia sie tylko jedno :>  jesli przy wysypach wyprodukuje sie kolejny crashdump to podrzuc go prosze, moze cos jeszcze sie znajdzie. Oprocz tego, jesli wyleci to sprawdzaj plik errors.txt -- jesli pojawi sie tam na samym koncu wzmianka w rodzaju "critical error" to znaczy, ze wysypem byl brak wolnej pamieci by pomiescic dane.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 24 Maja 2017, 18:23:28
Symulator wyszedł bez słowa komunikatu na ekranie, ale w logu pozostawił wiadomość.
EVENT LAUNCHED: sr11_wz2 by en57-14rb
EVENT LAUNCHED: sr12_wz2 by en57-14rb
EVENT LAUNCHED: sr003_wz2 by en57-14rb
EVENT LAUNCHED: sr004_wz2 by en57-14rb
Critical error, memory allocation failure: bad allocation
Wątpliwości nie pozostawia też errors.txt
EU07.EXE 17.524.86.0
Bad geometry (shape estimation failed) for spline "" at -17175.900000 0.200000 -6315.600000
Bad geometry (shape estimation failed) for spline "" at -17175.900000 0.200000 -6315.600000
.....ciach......
Critical error, memory allocation failure: bad allocation
ET42-014 na Kaliskiej.
Jakie są perspektywy poprawy zarządzania pamięcią?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Skif w 24 Maja 2017, 18:26:40
Niestety nie działa u mnie funkcja wyłączania sprężarki w przednim członie - testowane na scenerii testowej po ustawieniu lokomotywy ET42 (oczywiście 2 człony A i B) ze wszystkimi dostępnymi sprzęgami 255. Załączam log.txt. Wersja exe - eu07-x64_170524
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 24 Maja 2017, 18:48:17
Dla pewnosci, na jakiej wersji ET42 mialo to miejsce? Wersja z paczki nie ma niezbednych wpisow w .mmd ktore wykorzystuja nowe funkcje, wiec na niej faktycznie na razie nie bedzie to dzialac. Wersja aktualna nad ktora pracuje @EP08 jest chyba na razie tylko tylko w dziale betatestow.

Jakie są perspektywy poprawy zarządzania pamięcią?
Slabe, tzn. nowej pamieci raczej nie urodze, a to co jest gdzies pomiescic sie musi. Byc moze uda sie ewentualnie wprowadzic bardziej dynamiczna obsluge, jak ladowanie I zwalnianie sektorow w trakcie jazdy, ale to dosc odlegla przyszlosc.

Z ciekawosci, ile pamieci jest w tym komputerze ktory ci sie wysypuje? U siebie mam 8gb i to wydaje sie w zupelnosci wystarczac, a 2-4gb chyba nie kosztuje dzisiaj jakichs koszmarnych pieniedzy...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 24 Maja 2017, 18:58:54
Mam 4Gb ramu. Biorąc pod uwagę używanie winXP32 bitowego rozszerzenie ilości pamięci ma słabe rokowania. Do tego mam tylko 2 sloty po 2 Gb, co oznacza zakup 2x 4Gb. Następna przeciwność, to są to sloty ddr2 w kompie z 2008 roku. Zapytałem o to, bo jeszcze parę tygodni temu na tej samej scenerii kończyłem ten scenariusz bez większych problemów. Także na Kaliskie kończę scenariusze pośpiechami, a różnica jedynie taka, że jazda jest w przeciwnym kierunku. W tej chwili odpaliłem jazdę pospiesznym do Kaliskiego, zobaczymy jak się spisze.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 24 Maja 2017, 19:07:47
Do pewnego stopnia zuzycie moglo wzrosnac w trybie VBO, gdyz po naprawie bledow exe (probuje) alokowac i wykorzystywac pamiec "jak trzeba" zamiast pisac po czym popadnie a czesc danych pomijac. W tej sytuacji jakas tam opcja moze byc tryb DL ktory zuzycie ma troche inne, no chyba ze na nim tez sie wysypuje :/
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Skif w 24 Maja 2017, 19:08:22
Jeżeli chodzi o wersje to: ET42-025-A+ET42-025B. Swoją drogą, mam też drugie pytanie, ponieważ kiedyś, dawno temu poruszałem w wątku temat AI, a widzę, że modyfikujecie klawiszologie. Czy przewidujecie możliwość wyłączenia AI w składach, tak żeby po przełączeniu na inną lokomotywę AI samo się nie włączało, za pomocą jakiegoś klawisza?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 24 Maja 2017, 19:15:09
Ja tego ostatniego zdania nie rozumiem. Jeśli przechodzisz z jednego pojazdu do drugiego to AI włącza się w opuszczanym i wyłącza w tym pojeździe do którego wchodzisz. W przypadku kontynuacji jakiegoś scenariusza, nie może być inaczej.
@tmj, ja się ustosunkuje jak przejadę do końca pospiesznym na VBO i powtórzę obie na DL. Na pospiesznym mam po nad 160 tekstur więcej na ogólną ilość 2082 i 1919.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 24 Maja 2017, 19:15:28
Jeżeli chodzi o wersje to: ET42-025-A+ET42-025B. Swoją drogą, mam też drugie pytanie, ponieważ kiedyś, dawno temu poruszałem w wątku temat AI, a widzę, że modyfikujecie klawiszologie. Czy przewidujecie możliwość wyłączenia AI w składach, tak żeby po przełączeniu na inną lokomotywę AI samo się nie włączało, za pomocą jakiegoś klawisza?
Chodzilo mi raczej o to, czy pliki dla tych lokomotyw to oryginalna (stara) wersja, ktora jest w paczce calosciowej symulatora, czy tez moze wersja zmodyfikowana. Jesli ta pierwsza, to nowe funkcje nie beda na niej dzialac, przynajmniej do czasu wydania nastepnej paczki.
Zostawianie pociagu 'samego sobie' po zmianie jest na ten moment dosc problematyczne, ze wzgledu na to jak zorganizowana jest ich obsada of strony kodu programu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Skif w 24 Maja 2017, 19:22:58
Tak, to była paczka całościowa. Dzięki za pomoc :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mk1991 w 24 Maja 2017, 19:52:34
Witam. Rada jaką dostał Krzysiek pomogła tez mi. Wyłączyłem VBO i wszystko śmiga. Ja uważam tak jak mój kolega, który mi pomaga z moim komputerem, że symek ma poważne kłopoty z gospodarowaniem pamięcią.
Pozdrawiam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 24 Maja 2017, 19:56:47
To jeszcze potwierdź ile masz pamięci, o ile wiem masz jej 32 gb.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mk1991 w 24 Maja 2017, 20:00:06
Tak, mam 32GB DDR4 i 32GB wirtualnej a i tak to samo rozwiązanie pomogło.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: wołodyjowskiIC w 24 Maja 2017, 20:01:00
Tym razem nie wygenerował craschdump, a najlepsze, że tym razem żadne okno mi się nie pojawiało, tylko od razu symek gasł:( A więc załączam tylko errors txt. i faktycznie znalazłem tam wpis "critical error". Uruchamiane na najnowszym 524.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 24 Maja 2017, 22:00:11
Dla informacji: ukończyłem scenariusz w całości na Kaliskiej jadąc pospiesznym do Łodzi. Brak błędów w errors dotyczących pamięci.
Dziś przejadę jeszcze na DL tym ET42. Koło soboty będę dusił 64 bitowego WIN7 na VBO. On widzie nieco więcej ramu. Jeśli to wina VBO w zarządzaniu ramem, to DL musi w exe zostać. MK1991 opisuje podobne błędy, mając 32 gb. Nie wiem tylko jaką grafikę tam ma. Wołodyjowski też ma ten sam błąd.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mk1991 w 24 Maja 2017, 22:25:54
Służę informacją. NVIDIA GeForce GTX 940Mx.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 24 Maja 2017, 22:30:32
Wychodzi na to że Vramu masz 4 gb, przy czym szyna jest tylko 64 bitowa. Ja mam 512 mb pamięci vram, ale szynę już 256 bitów.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: wołodyjowskiIC w 24 Maja 2017, 23:26:49
Ja mam 3 gb Vramu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 25 Maja 2017, 05:48:17
Rozumiem obawy osob posiadajacych wiekowy sprzet, ale nie mozemy ciagle patrzec wstecz i skupiac sie na kompatybilnosci z komputerami sprzed dekady. Jezeli skalowanie maxtexturesize np. 512 nie zda egzaminu, to przykro mi bardzo, ale biorac pod uwage ficzery ktore z pewnoscia jeszcze beda dochodzic w przyszlosci, trzeba bedzie w sprzet zainwestowac. Moze nie nie wiadomo ile, ale zeby to bylo juz x64 z wieksza iloscia pamieci.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mk1991 w 25 Maja 2017, 06:09:37
Myślę,, że to nie jest problem jedynie ludzi z słabszym sprzętem. Pamięci ram mam tyle, że spokojnie starcza nawet na potężne projekty, które wykonuję w kombajnie muzycznym, nie korzystam z karty graficznej integrowanej z płytą główną a z dedykowanej. Procesor to czterordzeniowy Intel I7 600HQ. To nie jest słaba konfiguracja, a i tak miewam jak widać kłopoty i słabszych komputerów. Pamięć ram to jak powiedziałem wcześniej DDR4, więc nie słaba. Ja ciągle będę się upierał, że to problem gospodarki, jakim cudem w takim razie kiedy wyłączę totalnie pamięć wirtualną nic się nie dzieje? Robiłem testy z kolegą i kiedy uruchomi się pamięć wirtualną symulator prawie nie korzysta z DDR, a w każdym razie w o wiele mniejszym stopniu niż by mógł. Czy dało by się zaimplementować coś w rodzaju skanera podającego do exe ilość dostępnej pamięci ram, tak żeby możliwa była optymalizacja na bieżąco?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 25 Maja 2017, 07:51:11
Felerny scenariusz na DL ukonczylem bez zajakniecia ze strony sprzetu. Wczesniej slyszalem ze VBO powinno byc wydajniesze a na niektorych komputerach wlasnie ze szlabsza specyfikacja, moze dolozyc kilka klatek.  Od zawsze uzywalem DL, oswietlenie na VBO bylo nienaturalne a teraz okazuje sie pamieciozerne. Oczywiscie sprawdze skalowanie tekstur 512x512 bo to jest jakies wyjscie. @tmj, zapytam jeszcze, na jakim dysku masz plik wymiany, jaka jest jego wielkosc? Pytam, poniewaz mam wiecej przyciec na VBO.
Biorac pod uwage ostatnie doswiadczenia, DL bije na glowe VBO w niezawodnosci.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EU40 w 25 Maja 2017, 09:31:19
A ja mam takie jedno pytanie.
Dlaczego na c++ nie działają odluźniacze w wagonach po naciśnięciu odpowiedniego przycisku na klawiaturze numerycznej?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: joey w 25 Maja 2017, 10:13:49
Jeszcze w exe borlandowym sterowanie hamulcem wagonu zostalo zmienione na ctrl+num7 i ctrl+num1.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: wołodyjowskiIC w 25 Maja 2017, 14:29:43
Rozumiem obawy osob posiadajacych wiekowy sprzet, ale nie mozemy ciagle patrzec wstecz i skupiac sie na kompatybilnosci z komputerami sprzed dekady. Jezeli skalowanie maxtexturesize np. 512 nie zda egzaminu, to przykro mi bardzo, ale biorac pod uwage ficzery ktore z pewnoscia jeszcze beda dochodzic w przyszlosci, trzeba bedzie w sprzet zainwestowac. Moze nie nie wiadomo ile, ale zeby to bylo juz x64 z wieksza iloscia pamieci.
Problem w tym, że kaliska działała mi zawsze prawidłowo, zarówno na tym borlandowym EXE, jak i na 517, a teraz się zawiesza, i na borlandowym i na 517 i 524.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Maja 2017, 14:47:40
Jesli zaczela zawieszac sie takze na borlandowym, to przyczyna moze byc tutaj raczej uszkodzenie plikow lub, odpukac, klopoty natury sprzetowej (poluzowana/wadliwa kosc ram, zaczynajacy sie sypac dysk twardy itp)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: wołodyjowskiIC w 25 Maja 2017, 17:08:42
A teraz z innej beczki;) Uruchomiłem najnowsze EXE i nie mogę połączyć wagonów z lokomotywą, gdyż klawisz Insert nie działa, tylko od razu załącza nagły mimo, że mam wyłączony numlock.
Już sobie poradziłem:)
A wracając do dyskusji, testowałem na 524 linie 64 i wszystko działało w największym porządeczku, więc wnioskuję, że te 3 gb ramu na kaliską to za mało:(
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Maja 2017, 20:44:47
W dzisiejszym uaktualnieniu tylko jedna zmiana, natomiast, ze sie tak wyraze, jakosciowa :d

- zmiana w systemie wizualizacji -- jest ona teraz oparta na biezacej pozycji kamery, co w praktyce oznacza ze rendering ma praktycznie ta sama precyzje w kazdym punkcie mapy. Tym samym powinno zostac w wiekszosci wyeliminowany z-fighting i drgania (poza tymi, ktore biora sie z rzucania pudlem pojazdu

(tutaj uwaga, pod system nie jest (jeszcze) wlaczony teren z pliku .e3d wiec jesli scena wykorzystuje ten typ terenu, to z-fighting z podsypkami torow do pewnego stopnia bedzie ciagle obecny. Na sceneriach nie uzywajacych tego terenu powinno byc juz calkiem przyzwoicie)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 25 Maja 2017, 21:30:40
Exe z 24 maja x64. WIN7 64 bit. Dojechałem do końca ET42 z beczkami w trybie VBO. Żadnych błędów, ścinek i kłopotów. Zupełnie inna bajka niż na 32 bitowym winxp. Ten sam komputer, 512mb Vram i 4Gb ram. Bardzo szybko pracujesz, nie nadążam za aktualizacjami.
ED:
20170525; kamień milowy (jeden z wielu w tym roku), właśnie @tmj pozbył się migania podsypek na trawnikach, trzęsienia otoczenia (bardzo widoczne przy pchaniu składu na Kaliskiej w Ostrowie). Bardzo udana kompilacja. Polecam używać i zachwycać się.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Balaclava w 25 Maja 2017, 22:27:22
Może ktoś zarzucić linkiem do najbardziej aktualnego repozytorium? Tyle się tych branchy narobiło, że już nie wiem z którego korzystać. Poza tym, fajnie, że jedna z największych wad symka została rozwiązana. Napawa optymizmem i motywuje.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: DieselPower w 25 Maja 2017, 22:37:57
Na najnowszym exe x86 zauważyłem, że po zapaleniu prawego reflektora wnętrze minimalnie się podświetla. Wydaje mi się, że to może dotyczyć modelu niż exe. Z mniej ważnych rzeczy brakuje mi szybszego przesuwania kamery na zewnątrx z wciśniętym ctrl.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Maja 2017, 22:41:27
Dodatkowe przyspieszenie ruchu mozna uzyskac wlaczajac tryb debug, Shift+Ctrl+F12
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 25 Maja 2017, 23:13:44
20170525; kamień milowy (jeden z wielu w tym roku), właśnie @tmj pozbył się migania podsypek na trawnikach, trzęsienia otoczenia (bardzo widoczne przy pchaniu składu na Kaliskiej w Ostrowie). Bardzo udana kompilacja. Polecam używać i zachwycać się.
Mało powiedziane, te najnowsze exe to hit roku. Dokładnie na kaliskiej w Ostrowiu nic nie skacze, nie lata, bajka po prostu. Aż wręcz jakoś tak dziwnie się jedzie teraz... Ponadto FPS na poziomie do 70 w stacji. Chyba dobry duszek przysłał Cię @Tmj. Brawo!
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: kocio w 26 Maja 2017, 02:37:44
tmj-ku nie mam syren En-57 i Ed-7x. To się dzieje na najnowszych exe-kach. Wybacz styl. Acha exe, w którym działa syrena to 170418.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 26 Maja 2017, 08:05:02
Tak ma byc. Trzeba przystowwac kabiny tych pojazdow. Bylo kilka razy o tym pisane.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: pat w 26 Maja 2017, 08:53:06
Największa bolączka dla mnie czyli padaczkowe podsypki zniknely. :O Gratuluje.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 26 Maja 2017, 22:28:06
Czy jesteśmy jakoś zabezpieczeni w exe przed taką dwoistą informacją? Gdyby coś, to skanowanie pokazuje seminfo 0km/h, a na semaforze mamy co widać.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 26 Maja 2017, 22:36:39
Migotanie zniknęło - wielkie gratulacje. Zauważyłem za to inną rzecz, choć może i ten problem był wcześniej - mianowicie lokomotywy, które są obsadzone (headdriver), ale wyłączone wydają się z siebie jakiś dziwny dźwięk. Nie wiem co to jest, ale jest to dość denerwujące i przede wszystkim niezbyt pasuje do wyłączonej lokomotywy. Przykład - Całkowo v2, misja zdawczyA_cal - na stacji w Janiszewie stoi wygaszony ST43 ze składem gruszek, ale mimo to wydaje z siebie jakiś niezidentyfikowany dźwięk.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Maja 2017, 23:23:04
Sprawdzilem, wychodzi ze ten dzwiek to byl zapetlony start/stop dzwieku wpadania w poslizg, ktory bral sie z blednej kalkulacji -- sila hamowania 'zaciagnietych' hamulcow stojacego pojazdu przekraczala przyczepnosc, i w efekcie bez przerwy wpadal on w poslizg i 'wychodzil' z niego.
Ten sam efekt dotyczyl tez samochodow, ale kiedy go wczesniej zauwazylem odlozylem go do sprawdzenia na pozniej. 'Pozniej' przyszlo teraz, poprawka bedzie w nastepnym uaktualnieniu.

Czy jesteśmy jakoś zabezpieczeni w exe przed taką dwoistą informacją? Gdyby coś, to skanowanie pokazuje seminfo 0km/h, a na semaforze mamy co widać.
W normalnych warunkach uaktualnienie stanu semafora powinno nastapic po krotkim czasie (1-2 sek) od zmiany sygnalu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 27 Maja 2017, 11:55:06
Jakiś czas temu była aktualizacja inców semaforów, skracająca czas od wysłania sygnału do ustawienia wszystkich komórek i lampek. Gdzieś był przypadek, że w tą sekundę na wysterowanie coś się na przebieg kolizyjny ustawiało.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 27 Maja 2017, 14:13:42
Na początek napiszę, że skalowanie tekstur do 512x512 jest operacją pomagającą na problemy z pamięcią. Jednak niektóre tekstury po wczytaniu scenerii są białe (Kaliska). Taką teksturą przykładowo był Dworzec w Pabianicach i Łasku, ale było ich więcej. Druga sprawa, to niestety jakość widoków jakie oferuje skalowanie do tej wielkości. Właściwie po takim skalowaniu cofamy się do roku 2005. Kłopoty z pamięcią jak pisałem są na 32 bitowym windowsie XP. Nie ma tych kłopotów na 64 bitowym windows 7. Stąd decyzja o moim zaprzestaniu testów na winXP.
Życie zmusiło mnie do wyjęcia karty graficznej, więc niejako przy okazji odbyła się próba odpalenia symulatora na karcie graficznej zamontowanej na płycie głównej. Jest t czipset G31 i właściwie nie ma o czym pisać. C++ nie uruchamia się na tym wynalazku nie zostawiając nawet log.txt, czy errors.txt. Sterownik oczywiście najbardziej aktualny jak się da. Na moment miga tylko okienko konsoli, znikając bez śladu. Na grafice intela G31, można pojeździć na exe borlandowym z FPS wynoszącym 15 na Bałtyku.
Ponieważ dokonał się przełom w ostatnim wydaniu i pozbyliśmy się zmory migania tekstur, to może pora spytać co dalej? Czy zatrzymamy się na jakiś czas na tą wersją i wydamy pacza testowego?
Brak migania spowodował, że zaczęły przeszkadzać mi kolorowe druty w trybie debugmode.
Chciałbym też namówić @tmj, do dopisania siebie i @Milek7 jako autorów exe, mimo zmiany numeracji, do tej pory tego nie zrobiliście. Pełen szacun.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 27 Maja 2017, 16:25:37
Jesli wujek Google i ciocia Wikipedia nie klamia, to G31 obsluguje jednynie openGL do wersji 1.4, a od jakiego czasu exe zachciewa sie minimum wersji 1.5 (teoretycznie 1.4 jako najnizsze wymaganie mozna by przywrocic, ale nie wiem czy jest na to duze zapotrzebowanie)

Skalowanie tekstur jest na ten moment robione prymitywnie, i sprawdza sie przy teksturach kwadratowych (skalowanie wykonywane jest dla obu osi naraz) ale jesli tekstura jest silnie prostokatna to przy kilkukrotnym zmniejszeniu nastapi skalowanie do rozmiaru mniejszego niz dopuszczalny, i tekstura jest odrzucana jako wadliwa.

Co do dalszych prac -- unifikacja sciezek renderowania jest zrobiona na ~80%, do zakonczenia nie zostalo juz wiele. Zakonczenie powinno umozliwic/ulatwic kilka rzeczy -- spiecie tej wersji z wersja shaderowa @Milka w jedno exe, selekcje/obsluge elementow mysza i pare innych rzeczy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: loko w 28 Maja 2017, 01:20:16
Ostatnio znacznie rzadziej miałem możliwość testowania a wyszukiwarka nie wynalazła, więc nie wiem czy było zgłaszane. Przy misji pospwilB z Całkowo V2.0 jadąc SU46 nie ma płynnego przejścia syreny z tonu wysokiego do niskiego i odwrotnie, każdy ton działa oddzielnie. To samo dotyczy np. EU07. Ponadto cały czas nie mogę się przyzwyczaić do obsługi zaworu hamulca zespolonego na lokomotywach na EXE++ . Czy to już tak na stałe zostanie?   
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 28 Maja 2017, 08:55:59
Ostatnio znacznie rzadziej miałem możliwość testowania a wyszukiwarka nie wynalazła...
i dalej
Cytuj
... Ponadto cały czas nie mogę się przyzwyczaić do obsługi zaworu hamulca zespolonego na lokomotywach na EXE++ . Czy to już tak na stałe zostanie?   
W pierwszej części postu odpowiedziałeś sobie na zadane pytanie. Zostanie, ja na przykład zacząłem mieć problemy z obsługą starego exe, bo na nim już nie jeżdżę.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: przepioramarcin w 28 Maja 2017, 09:01:07
Po raz pierwszy na Kaliskiej wysypało mnie do windy: "Program Symulator Maszyna przestał działać".
I kolejny komunikat :"Sterownik Karty Graficznej przestał odpowiadać".
Błąd pojawia się w tym samym czasie. Czy zacznę od ZW czy od OW symulacja kończy się po kilkunastu minutach.
EXE x64 170525
Win 7 pro x64.
CPU AMD ATHLON 64 X 2 6000+
NVIDIA GEFORCE GTX 550 ti (1 GB RAM) sterownik 372.54
10 GB RAM DDR2
W Nowych Skalmierzycach mamy możliwość zwiedzania pociągiem fabryki od środka, ale ten błąd występował też u mnie na wcześniejszych exekach.
EDIT:
Nie udało mi się ustalić przyczyny wczorajszych wysypów.
Zaktualizowałem sterownik graficzny do najnowszego. Wczoraj nie pomogło.
Dzisiaj uruchomiłem Kaliską bez problemu (próby na różnych exe).
Potwierdzam na najnowszym exe lewitujące fragmenty modeli:
Przed Nowymi Skalmierzycami pojawia się jakiś fragment konstrukcji stalowej.
Podobnie przed ZW (misja ET22) z lewej u góry widać na niebie porządny kawał stali, który po chwili znika.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 28 Maja 2017, 10:56:57
Witam.
 Mnie wczoraj na kaliskiej podczas testowania exe spotkała przezabawna sytuacja. Po wyjeździe z Ostrowia pośpiesznym, zauważyłem że brakuje elementów metalowych wiaduktu kolejowego tuż za stacją. Ok, jakiś błąd pomyślałem, więc nastwanik na full, rozkładowe 100km/h i jadę dalej. W tem przed Nowymi Skalmierzycami nad czołem składu zmaterializował się ogromny obiekt, i niczym statek obcych leciał równo z pociagiem. Chwilę zajeło mi zidetyfikowanie tego UFO. Był to wspomniany brakujący wiadukt z Ostrowia, a właściwie jego stalowe elementy nośne. Nim zdążyłem przycisnąć klawisz "print screen", ów kawał żelastwa jak niespodziewanie się pojawił, tak znikł. Reszta misji przebiegła już bez większych niespodzianek. Tak sobie myślę, exe "zapomniało" wyświetlić ten element scenerii, a potem jakby chcialo naprawic swój błąd, narysowalo go w przypadkowym miejscu szlaku.
Exe najnowsze C++, win XP pro 32bit.
Pozdrawiam
Ps. Później złącze log txt.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Tomnord15 w 28 Maja 2017, 12:18:51
W najnowszym exe nie da się tworzyć w początkowej fazie plików tekstur mini na przykładzie tego wątku- http://eu07.pl/forum/index.php/topic,14288.msg344498.html#msg344498 (http://eu07.pl/forum/index.php/topic,14288.msg344498.html#msg344498)
Po wczytaniu scenerii mini i wciśnięciu 0 kamera nie wyśrodkowuje pozycji na ekranie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Maja 2017, 12:49:59
Ostatnio znacznie rzadziej miałem możliwość testowania a wyszukiwarka nie wynalazła, więc nie wiem czy było zgłaszane. Przy misji pospwilB z Całkowo V2.0 jadąc SU46 nie ma płynnego przejścia syreny z tonu wysokiego do niskiego i odwrotnie, każdy ton działa oddzielnie. To samo dotyczy np. EU07. Ponadto cały czas nie mogę się przyzwyczaić do obsługi zaworu hamulca zespolonego na lokomotywach na EXE++ . Czy to już tak na stałe zostanie?
Kazdy ton syreny jest pod odrebnym klawiszem (lub ich kombinacja) i aby byl rozpoznany trzeba wcisnac 'cala' kombinacje -- czyli jesli jest to shift+A to wcisnac trzeba i shift, i A razem; wcisniecie i przytrzymanie A i dodanie pozniej shift nie zadziala, tak samo jak trzymanie A i wcisniecie pozniej shift nie zacznie produkowac "AAAAA" np. w notatniku. Exe borlandowe dzialalo tutaj inaczej, bo kombinacje byly do funkcji przypisane 'na sztywno' i sprawdzane w inny sposob.

Pewnym rozwiazaniem mogloby byc tutaj przemapowanie klawiszy, np do A dla tonu wysokiego i S do niskiego -- odzwierciedlalo by to troche bardziej intuicyjnie ze kazdy ton jest odrebnym ustawieniem dzwigni (lub w EN57 i podobnych wrecz odrebnym pedalem)

Co do ustawien klawiszy hamulcow, of pewnego juz czasu powiazania miedzy funkcjami i kombinacjami klawiszy sa pobierane z pliku konfiguracyjnego, i uzytkownik moze je zmienic tak, jak mu/jej pasuje.

Mnie wczoraj na kaliskiej podczas testowania exe spotkała przezabawna sytuacja. Po wyjeździe z Ostrowia pośpiesznym, zauważyłem że brakuje elementów metalowych wiaduktu kolejowego tuż za stacją. Ok, jakiś błąd pomyślałem, więc nastwanik na full, rozkładowe 100km/h i jadę dalej. W tem przed Nowymi Skalmierzycami nad czołem składu zmaterializował się ogromny obiekt, i niczym statek obcych leciał równo z pociagiem. Chwilę zajeło mi zidetyfikowanie tego UFO. Był to wspomniany brakujący wiadukt z Ostrowia, a właściwie jego stalowe elementy nośne.
Tylko dla pewnosci, czy mialo to miejsce w trybie wyswietlania Display Lists? Jest tu faktycznie blad objawiajacy sie w ten sposob, chwilowo nie usuniety bo musze dojsc co go konkretnie powoduje :d W wersji VBO wyswietlanie wydaje sie byc poprawne.

edit:
NVIDIA GEFORCE GTX 550 ti (1 GB RAM) sterownik 372.54
Nie zebym spodziewal sie ze to zrobi jakas specjalna roznice, ale aktualny sterownik dla kart nvidii to 382.33. Wersja 372.54 ma juz blisko rok, warto by tutaj na wszelki wypadek uaktualnic.

edit2:
W najnowszym exe nie da się tworzyć w początkowej fazie plików tekstur mini na przykładzie tego wątku- http://eu07.pl/forum/index.php/topic,14288.msg344498.html#msg344498 (http://eu07.pl/forum/index.php/topic,14288.msg344498.html#msg344498)
Po wczytaniu scenerii mini i wciśnięciu 0 kamera nie wyśrodkowuje pozycji na ekranie.
Dosc dziwne ze dziala to (jesli dziala) na exe borlandowym, bo kod obslugi kamer jest ten sam. Przyczyna jest tutaj umieszczenie kamery w punkcie 0,0,0 -- exe na tej podstawie decyduje (dosc nietrafnie, imo, to jest do zmiany) ze taka definicje polozenia kamery nalezy zastapic biezaca pozycja, zamiast przesunac kamere do zdefiniowanego punktu.

Rozwiazaniem jest zmiana przynajmniej jednej wspolrzednej w pliku .scn na wartosc inna niz 0. Np tak:
camera 0 0 0.01 0 0 0 0 1 endcamera
z taka modyfikacja kamera powinna ustawiac sie juz 'jak trzeba'.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: loko w 28 Maja 2017, 15:22:34
To może warto się zastanowić nad tymi syrenami, gdyż moim zdaniem brak "płynnego" przejścia między tonami negatywnie wpływa na odzwierciedlenie rzeczywistości. Ponadto przecież w niektórych nowoczesnych pojazdach jest możliwość załączenie "mieszanego" sygnału przy użyciu przycisku nożnego. Co do zaworu hamulca to źle się wyraziłem, z ustawieniami klawiszy nie ma problemu, tylko miałem na myśli przestawianie rękojeści. Według mnie to nie ma tej płynności jak na starym Exe, tylko bardziej ociężale funkcjonuje zmiana pozycji hamowania.   
 
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: KubaPKP w 28 Maja 2017, 15:45:33
Witam.
 Mnie wczoraj na kaliskiej podczas testowania exe spotkała przezabawna sytuacja. Po wyjeździe z Ostrowia pośpiesznym, zauważyłem że brakuje elementów metalowych wiaduktu kolejowego tuż za stacją. Ok, jakiś błąd pomyślałem, więc nastwanik na full, rozkładowe 100km/h i jadę dalej. W tem przed Nowymi Skalmierzycami nad czołem składu zmaterializował się ogromny obiekt, i niczym statek obcych leciał równo z pociagiem. Chwilę zajeło mi zidetyfikowanie tego UFO. Był to wspomniany brakujący wiadukt z Ostrowia, a właściwie jego stalowe elementy nośne. Nim zdążyłem przycisnąć klawisz "print screen", ów kawał żelastwa jak niespodziewanie się pojawił, tak znikł. Reszta misji przebiegła już bez większych niespodzianek. Tak sobie myślę, exe "zapomniało" wyświetlić ten element scenerii, a potem jakby chcialo naprawic swój błąd, narysowalo go w przypadkowym miejscu szlaku.
U mnie wystąpiło dokładnie to samo. Póki co jestem przed Zduńską Wolą i symulacja przebiega poprawnie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: MR6 w 28 Maja 2017, 15:56:46
Podczas pojedynczego kliknięcia w przyciski odp. za  trąbke odtwarza sie zdublowanie dźwięk przedstawianego hebelka, jakbyśmy w ten przycisk klikali kilka razy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mk1991 w 28 Maja 2017, 16:01:05
Dzieje się tak, ponieważ trąbka zapewne jest zrobiona jako switch bistabilny. Trąbka w ogóle nie powinna mieć swojego dźwięku przełącznika, bo kłuci się z niektórymi dźwiękami syren np. w E186. A co do podwójnego tonu syreny w nowszych pojazdach, to odpowiada za to osobny pedał albo osobna dźwignia i jeszcze jedno, w takim wypadku musi być osobny dźwięk, ponieważ jeden i drugi ton rozpoczyna i kończy brzmieć w jednym momencie. W EN57 rzeczywiście są dwa pedały, które można wcisnąć jednocześnie, tutaj przydały by się dwa dźwięki, które mogą być mieszane.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Maja 2017, 20:16:02
To może warto się zastanowić nad tymi syrenami, gdyż moim zdaniem brak "płynnego" przejścia między tonami negatywnie wpływa na odzwierciedlenie rzeczywistości.
W rzeczywistosci w duzej liczbie lokomotyw ktore mamy w symulatorze syrena jest zalaczana dzwignia ktora ma jeden dzwiek na koncu wychylenia w jedna strone a drugi dzwiek na koncu wychylenia w druga strone. Fizycznie nie ma w takim ukladzie mozliwosci zalaczenia obu tonow naraz -- dzwignia umozliwia tylko albo-albo. Zas "plynne przejscie" w takim ukladzie wymaga przesuniecia dzwigni z pozycji A do pozycji neutralnej, a nastepnie do B.

Ja rozumiem ze komus moze byc latwiej przycisnac sam shift niz na ulamek sekundy podniesc wczesniej palec z klawisza i przylozyc go z powrotem, ale odzwierciedlania rzeczywistosci w to nie wplatujmy, bo z nia akurat ma to zero wspolnego. Dlatego miedzy innymi wydaje mi sie, ze zmiana domyslnych klawiszy tak zeby nie bylo miedzy nimi 'punktu wspolnego' bylaby tu sensowna.

(co do dzwieku wydawanego przy przelaczaniu to jest placeholder, bo na razie nie ma w exe przypisywania indywidualnych dzwiekow do poszczegolnych przelacznikow)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 28 Maja 2017, 21:31:52
W rzeczywistości są w większości starszych lokomotyw dwie takie dźwignie, więc kiedy maszynista jedzie z drugą osobą, to razem mogą podać dwa tony jednocześnie (jeden przestawia jedną dźwignię na ton wysoki, a drugi drugą na niski), a jeśli dźwignie są dostatecznie blisko siebie (jedna normalnie po stronie pomocnika, a druga przy manipulatorze radia), to nawet w pojedynkę można je obie naraz bez problemu przestawić. Taka ciekawostka, żiektóre ET41 i EU07 chyba też, również miały dodatkowy pedał (tzn. przycisk grzybkowy w podłodze po lewej stronie nastawnika), którym można było uruchomić oba tony syreny jednocześnie lub tylko jeden w zależności od wersji, co w połączeniu z dźwignią też dawało możliwość zatrąbienia oboma jednocześnie. Natomiast jeśli chodzi o płynne przejście z jednego tonu do drugiego, to taka dźwignia sama w sobie działa płynnie i można to zrobić szybko i... płynnie (już nawet pomijając to, że zaworki w tych dźwigniach często są na tyle zabrudzone, że domykają się powoli i nawet po puszczeniu gałki syrena stopniowo się wycisza zamiast zamilknąć natychmiast, ale to już jest uwzględnione w samych dźwiękach).
Jeśli z kolei o EN57 mowa (sterowanie osobnymi pedałami i możliwość jednoczesnego podania obu tonów w "normalnych" warunkach), to zrobiłem eksperyment i przeniosłem sobie sterowanie wysokim tonem pod samo [Z]. Efekt jest taki, że nie da się podać dwóch tonów jednocześnie, tzn. przy wciśniętym [A] wciśniecie w tym przypadku [Z] spowodowało wyciszenie tonu niskiego i słychać było tylko wysoki - tak samo na odwrót. Wniosek taki, że exe chyba nie obsługuje obu tonów jednocześnie, mimo niezależnego sterowania nimi z klawiatury.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Maja 2017, 21:42:16
Wniosek taki, że exe chyba nie obsługuje obu tonów jednocześnie, mimo niezależnego sterowania nimi z klawiatury.
Problem byl w tym, ze przy kombinacji shift+klawisz zachodzi mozliwosc 'zwarcia' sygnalu na stale (podobnie jak ma to miejsce przy obsludze sprezarki pantografow) jesli klawisze puszczone sa po kolei, zamiast razem. By to przynajmniej do pewnego stopnia ograniczyc wstawilem zasade ze zalaczenie jednego z sygnalow 'silowo' wylacza drugi, w przeciwnym razie byloby o wiele wiecej narzekan "syrena mi sie zacina" niz obecnie jest "musze wykonac dodatkowy ruch palcem".

Problem nie wystepuje gdy oba tony sa przypisane do klawiszy bez shifta, i w takiej sytuacji mozna by nawet pokusic sie o pozwolenie na odgrywanie obu naraz, ale na chwile obecna ustawienia domyslne przeniesione ze starego exe sa jakie sa.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 28 Maja 2017, 21:54:19
W sumie, jeśli zmiana była w sterowaniu kranem hamulca, to i sterowanie syrenami można by trochę zmienić. Wysoki ton dać np. pod samo [A], a niski pod samo [Z] (niewykorzystywane obecnie, jedynie z [Shift] i [Ctrl]). A, i przy okazji potwierdzam to, co napisał @loko:
Co do zaworu hamulca to źle się wyraziłem, z ustawieniami klawiszy nie ma problemu, tylko miałem na myśli przestawianie rękojeści. Według mnie to nie ma tej płynności jak na starym Exe, tylko bardziej ociężale funkcjonuje zmiana pozycji hamowania.   
Tzn. przy przytrzymaniu np. [Num3] lub [Num9] rączka zachowuje się jak litery w zwykłym polu tekstowym, czyli przeskakuje najpierw o troszkę, chwilę "czeka" w tej pozycji i dopiero przestawia się dalej już płynnie do czasu ponownego puszczenia i wciśnięcia klawisza. Kiedyś nie było tej przerwy w ruchu, tylko przez cały czas płynny ruch od samego momentu wciśnięcia klawisza. To samo jest z kranem pomocniczym.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Maja 2017, 22:05:40
Myslalem raczej o daniu A i S dla tonow, a ewentualnie uzyciu Z dla trzeciego tonu, dla lokomotyw ktore maja dodatkowy sygnal. Tak czy owak zapewne znajdzie sie to w ktoryms uaktualnieniu do przetestowania.

Co do opoznienia, faktycznie moze miec miejsce gdyz odczyt klawiatury opiera sie teraz na komunikatach przekazywanych przez system operacyjny, zamiast bezposredniego odczytu stanu klawiszy. U siebie opoznienie powtarzania mam zredukowane do minimum, wiec nie rzucilo mi sie w oczy, bo w tym ustawieniu roznica opoznienia miedzy pierwszym i powtorzonymi wcisnieciami jest minimalna, o ile w ogole wystepuje.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 28 Maja 2017, 22:07:49
Pod {S} są piasecznice.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Maja 2017, 22:11:44
Do przesuniecia pod shift-S, a przelaczenie blokady drzwi pod ctrl+S (nie wiem czemu blokada drzwi jest pod S, ale to juz inna historia)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 28 Maja 2017, 22:53:14
Zastanawiam sie, czy warto rozpatrywac umieszczanie funkcji pod klawiatura, skoro w przyszlosci zamierzamy sterowanie wykonywac mysza. Nie chce dokladnie roztrzasac tematu, kilka osob jest zainteresowanych sterowaniem klawiatura, bo z mysza nie poradza sobie, wiec tu trzeba ostroznie. Pelnia realizmu i swobody w realizacj, jak dla mnie tylko w obsludze mysza.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 28 Maja 2017, 23:21:29
Nie, nie, nie. To nie moze byc na zasadzie "mysz albo klawiatura". To w podstawowym stopniu musi byc sterowalne z klawiatury - mysz powinna byc opcjonalna.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: MR6 w 28 Maja 2017, 23:25:04
Najpierw sie nalezy skupic na tym zdublowanym dzwięku hebelków, a dopiero pozniej kombinowac z klawiszologią.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 28 Maja 2017, 23:31:21
Absolutnie nie mialem na mysli usuniecie klawiatury jako interfwjsu sterowania pojazdem. Powinna pozostac, nawet jesli sa ograniczenia w jej mozliwosciach uzycia. Chcialem raczej, aby juz nie mnozyc kobinacji klawiszowych funkcji.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Maja 2017, 23:32:44
Najpierw sie nalezy skupic na tym zdublowanym dzwięku hebelków, a dopiero pozniej kombinowac z klawiszologią.
Tutaj nie ma sie na czym skupiac -- sa dwa dzwieki, jeden odgrywany przy wcisnieciu klawisza i aktywacji przycisku/dzwigni/pedalu, i drugi po puszczeniu klawisza, gdy urzadzenie sterujace wraca do pozycji neutralnej. Na ten moment w obu przypadkach odtwarzany jest prowizorycznie ten sam efekt. Jak bedzie obsluga indywidualnych dzwiekow to sie podmieni na wlasciwe, i tyle.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 28 Maja 2017, 23:39:48
A dźwięk zewnętrzny syreny nie powinien zawierać pukania hebelka ani wysterowania zaworu pneumatycznego. To powinno być pod wewnętrznym dźwiękiem przełącznika. Będzie trzeba wydzielić, gdy będą definiowalne i tyle.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 28 Maja 2017, 23:46:29
Tylko dla pewnosci, czy mialo to miejsce w trybie wyswietlania Display Lists? Jest tu faktycznie blad objawiajacy sie w ten sposob, chwilowo nie usuniety bo musze dojsc co go konkretnie powoduje :d W wersji VBO wyswietlanie wydaje sie byc poprawne.
Witam.
Tak, dokładnie jest jak piszesz @Tmj, błąd powodujący lewitujący wiadukt pojawił się w wersji DL. Nie sprawdzałem co prawda jeszcze trybu VBO, ale zaraz postaram się przetestować.
Poniżej log txt ( spakowany w archiwum), oraz errors z tamtej służby.

Edit: Sprawdziłem przy włączonym VBO, błąd nie występuje.
 
Nie, nie, nie. To nie moze byc na zasadzie "mysz albo klawiatura". To w podstawowym stopniu musi byc sterowalne z klawiatury - mysz powinna byc opcjonalna.
  Klawiatura daję możliwość szybkiej reakcji na zmienne warunki jazdy. Hamowanie, luzowanie, przyśpieszanie. Gdyby teraz trzeba było by celować kursorem myszki w poszczególne nastawniki, krany hamulca, jazda byłaby bardzo nie wygodna. Jednakże z drugiej strony trzeba przyznać, że dość wygodnie operuje się myszką np. kranem hamulca. Ale gdy zajdzie potrzeba dania w nagłe, na klawiaturze wystarczy nacisnąć jeden klawisz. Reasumując- inne symulatory które znam, mają sterowanie zarówno przy pomocy klawiatury jak i myszy. I to jest chyba najlepsze rozwiązanie.
Pozdrawiam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 28 Maja 2017, 23:56:05
EN71 na C++ tak używa pantografów jak na załączonym obrazku. Nie wiem, czy było to zgłaszane, na wszelki wypadek pokazuję.
ED:
Przezroczystość na dolnym szkle semafora, jak w załączniku. Na DL.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Sawi w 29 Maja 2017, 00:50:47
Ta przezroczystość na tych soczewkach występuje tam już od jakiegoś czasu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 29 Maja 2017, 04:07:14
EN71 na C++ tak używa pantografów jak na załączonym obrazku. Nie wiem, czy było to zgłaszane, na wszelki wypadek pokazuję.
EN71 po zmontowaniu i oddaniu w rece AI jezdzi u mnie jak na zalaczniku (przod skierowany w lewo) Dla pewnosci, czy polaczyles czlony przewodami ukrotnienia? Bez nich sygnaly kontroli pantografow (ani zadne inne) nie przejdza poza pierwszy czlon silnikowy.

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 29 Maja 2017, 10:41:20
Ten sklad zestawiony jest w scenerii Quark wpisem w trainsecie. Sytuacja w najnowszym paczu. Nie sprawdzalem jego wpisu, zalozylem ze jest prawidlowy i trzyma biezace standardy. Wiem ze wpisy sprzegow mialy byc poprawiane. Zbyt pozno bylo aby przyszlo mi do glowy zerkniecie na sprzegi, dziekuje. Sprawdze po wlasciwym zestawieniu skladu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mk1991 w 29 Maja 2017, 11:32:23
Czy dało by się zrobić osobne wpisy dla dźwięków następujących przełączników?
Kurek odcięcia układu pneumatyki, kurek trujdrogowy, switch dla przedniego i tylniego pantografu, swith dla małej sprężarki, switch dla sprężarki, switch dla przetwornicy, switch dla piasecznicy, wyłącznik szybki, wyłączniki silników trakcyjnych, które sa pod [e]. Ma te i o wiele więcej innych dźwięków dla ET22 i na razie wszystko leży i czeka.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 29 Maja 2017, 17:12:33
EN71 na C++ tak używa pantografów jak na załączonym obrazku...
EN71 po zmontowaniu i oddaniu w rece AI jezdzi u mnie jak na zalaczniku ...
Będę dalej męczył, problem dokładnie wystąpił na Quarku, opisałem tu: http://eu07.pl/forum/index.php/topic,29179.msg455918.html#msg455918 (http://eu07.pl/forum/index.php/topic,29179.msg455918.html#msg455918)
Sytuacja jest specyficzna, ponieważ to EN71 startuje z takim wpisem (już po poprawce):
//$o -Skład na torze postojowym 2(2) w Skwarkach, ustawiony przodem do kozła.
node -1 0 EN71-005 dynamic PKP\EN57_V1 EN71-005RA 6BAII  0 nobody 247 0 enddynamic
node -1 0 EN71-005 dynamic PKP\EN57_V1 EN71-005SA 6BSII  0 nobody 247 0 enddynamic
node -1 0 EN71-005 dynamic PKP\EN57_V1 EN71-005SB 6BSII  0 nobody 247 0 enddynamic
node -1 0 EN71-005 dynamic PKP\EN57_V1 EN71-005RB 6BBII  0 reardriver 247 0 enddynamic
Oznacza to, że AI po aktywacji zmienia kabinę i wjeżdża w perony w Skwarkach, tyle że po zmianie kabiny, nie jest w stanie prawidłowo podnieść patyków, o czym informowałem. Owszem postawiony na TD ładnie podnosi patyki, do póki nie zmienimy kabiny. Ale to ma następne konsekwencje. Skład ten nie jest w stanie prawidłowo zatrzymywać się na W4 i S1 po zmianie kabiny przez AI i przez AI prowadzony. Pokazałem to w przytoczonym poście w powyższym linku. Aby potwierdzić, że błąd nie jest w scenerii zamieniłem miejscami EN71-005 i EN57-1012 w trainsecie, po czym odpaliłem symulacje. Nie dość, że patyki podniesione jak trzeba, to AI dojechało bez problemu z Koniewic do Skwarek EN71, jak również bezbłędnie poprowadziło EN57 ze Skwarek do Koniewic. Mijanka w Zatylu oczywiście poprawnie wykonana jak w załączniku.
Proszę o przyjrzenie się dokładnie jak AI radzi sobie ze sterowaniem nie tylko patykami, ale z sygnałami w4 i semaforów, po zmianie kabiny w EN71. To co mamy jest nie do przyjęcia i chyba pilne z powodu pacza. Podejrzewam, że podobnie jest z ED72
ED:
Błędne zatrzymanie na w4 i S1 w Zatylu przez EN71 - załącznik 2
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Sawi w 29 Maja 2017, 17:17:41
Ze wskaźnikami w4 problemy są nie od dziś. Jak kiedyś pisałem eventy do expressu to np świnka ładnie pod wskaźnik dociągała, ale za to kibel go przerzynał i podciągał pod semafor wyjazdowy. Przeważnie z tego co kojarzę miałem właśnie problemy w sterowaniu przez AI EZT.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 29 Maja 2017, 17:50:23
Nie u @Ra.
Są dwa problemy. Pierwszy to taki, że @Ra jak pisał ten scenariusz, to dopieścił tak, aby mu działało. Jakiś czas temu odkryłem, ze część Quarka się blokuje z niewiadomych przyczyn. Od czasu napisania przez @Ra skryptów sterowania, exe na które zostało to napisane zestarzało się i poszło do lamusa. Wypada więc poprawić co nieco.
Druga sprawa, że zamiana EN71 na EN57, dobitnie pokazuje, że te pojazdy nie zachowują się jednakowo dla takich samych warunków panujących w scenerii. To problem, którego przyczynę trzeba znaleźć i poprawić. Nie wiem na ilu sceneriach jest podobna konfiguracja EN71 i ED72, one też będą się sypać, jeśli AI zaczyna od zmiany kabiny.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 29 Maja 2017, 18:35:53
Tak przy okazji jak już jesteśmy przy ezetach i problemach z nimi związanych, to trzeba by było poprawić pewien drobny szczegół jeżeli chodzi o sterowanie hamulcem EP (a na asynchronach też MED). Jeżeli nie damy ukrotnienia między jednostkami, które jest jakby równoznaczne z połączeniem klawiatur, to bez tego EP nie powinno działać na dalszych ezetach. Tak samo jak nie działa teraz podnoszenie pantografów bez "ukrotnienia". O pierdołach typu "załączymy baterię w szafie tylko na jednym EN57/71" nawet nie wspominam :P
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 29 Maja 2017, 23:03:08
Z tego co widze w exe to przelacznik stanu EP kiedys byl przesylany przewodami ukrotnienia do dalszych czlonow, a potem obsluga tej komendy zostala z jakiegos zakomentowana i tak juz zostalo -- na ten moment przelacznik zmienia tylko stan czlonu w ktorym siedzi uzytkownik (a w pozostalych utrzymuje wartosc domyslna, tzn zalaczony)

Podejrzewam ze klopoty przy zestawach czteroczlonowych biora sie z tego, jak zorganizowana jest obsluga EZT -- w odroznieniu od pozostalych pojazdow w EZT jest rozroznienie miedzy pojazdem obsadzonym i kontrolowanym, i nie zdziwiloby mnie gdyby tam sie cos rozsypywalo w okreslonu ktory czlon jest tym kontrolowanym, przy zmianie kabin, jesli w zestawie jest wiecej niz jeden czlon silnikowy. Trzeba sie bedzie przyjrzec.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: ET22_RULZ w 30 Maja 2017, 17:30:23
Jak już przepisujecie exe na C++ to warto by było to dodać do renderera:
https://developer.oculus.com/documentation/pcsdk/latest/concepts/book-dg/
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 30 Maja 2017, 17:35:31
Jasne, tylko bedziesz musial zafundowac developerom zestaw sprzetu, zeby bylo na czym testowac, bo na slepo to sobie mozna ;s
(nawiasem mowiac VR to kiepska perspektywa gdy sterowanie odbywa sie na razie ciagle z klawiatury -- macanie na slepo w poszukiwaniu wlasciwych klawiszy skazane jest na porazke)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: ET22_RULZ w 30 Maja 2017, 17:37:47
Nie ma problemu, mogę testować :P
A co do macania klawiszy, to w symulatorach z 10-20 razy bardziej skomplikowaną klawiszologią niż w MaSzynie nie odnotowałem żadnych problemów. Jak ktoś potrafi pisać bez patrzenia na klawiaturę nie powinien mięc problemu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 30 Maja 2017, 17:48:29
Testowanie na odleglosc dobre jest do znajdowania bledow w implementacji ktore juz dziala, ale nie dla samej implementacji. Do czegos takiego trzeba miec sprzet pod reka, bo zdalna informacja w stylu "nie dziala" nie przydaje sie niestety do niczego; podobnie jak i sama developerka robiona metoda "skompiluj, wyslij, i czekaj na odzew" przy kazdej najmniejszej poprawce.
Jesli znajdzie sie programista ze sprzetem VR to on(a) moze to zrobic, ale inaczej nie ma sie niestety co na to nastawiac.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 30 Maja 2017, 23:00:43
Nadal są wątpliwości co do EN71, to jeszcze dam 5 screenów gdzie ewidentnie widać, że AI nie umie prowadzić tego pojazdu po zmianie kabiny.
1. Zaczynamy w kabinie Ra i włączamy AI, po jakimś czasie AI zmienia kabinę na Rb i jedzie w perony.
2. Po zmianie kabiny w widoku zewnętrznym widać że AI nie potrafi podnieść prawidłowo patyków. Tryb shunt.
3. Dojazd w perony AI przerzyna w4 o 2 metry.
4. Dostajemy rozkład jazdy, jesteśmy w trybie pociągowym, dane pojazdu na ekranie.
5. Przejmuje pojazd od AI i staram się zatrzymać przed w4. Szalenie trudne zadanie bo w zbiorniku i w PG mam powietrza jak na screenie.
6. W trybie pociągowym AI nadal jedzie na jednym patyku.
Teraz włączam AI aby odjechać z Zatyla i poczekać aż AI dojedzie do następnego przystanku.
7. AI nadal nie potrafi napompować powietrza do PG.
8. AI mimo W4 pruje nie hamując, nie ma czym?
9. W skanowaniu widać przerżnięty w4 i s1.
To już jest inne miejsce w tej scenerii (Mydelniczka). Mamy pociąg widmo.
Brak powietrza w PG jest ciekawy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 31 Maja 2017, 00:02:25
Po przyjrzeniu sie EN71 wyszlo na to, ze (przynajmniej na scenerii Quark) problem jest kombinacja czynnikow:
- na starcie symulacji AI startuje w czlonie Ra wylaczonego skladu, i siedzi tam przez ~pol godziny. W tym czasie ze skladu powolutku schodzi sobie powietrze
- AI jest 'obudzone' komenda zmiany kierunku i dostaje polecenie rozruchu.
- AI przechodzi do czlonu Rb, zalacza baterie i probuje podniesc pantografy.
- powietrze w ukladzie jest na zbyt niskim poziomie, AI udaje sie wiec do najblizszego czlonu silnikowego (Sb) i pompuje. pantograf na Sb podnosi sie i AI przeprowadza reszte rozruchu. Pantograf na Sa *nie* podnosi sie, poniewaz tutaj cisnienie powietrza jest ciagle zbyt niskie.
- poniewaz Sa nie ma zasilania, nie startuje tez sprezarka w czlonie Ra, zatem cisnienie w calym skladzie schodzi dalej, do ewentualnego zera

w zwiazku z tym pytanie do fachowcow: czy w EN71 miedzy czlonami Sa i Sb sa przeprowadzone kable wysokiego napiecia, czy kazdy z czlonow funkcjonuje osobno? zaleznie od odpowiedzi potrzebna bedzie inna metoda naprawy sytuacji.

edit: i glupie pytanie numer 2, czy wylacznik cisnieniowy pantografow uaktywnia sie tylko na podstawie cisnienia w zbiorniku pantografow, czy uwzglednia tez stan samego pantografu? tzn czy aktywacja i 'czuwanie' nastapi gdy tylko cisnienie w zbiorniku pantografow jest wystarczajaco wysokie, czy dopiero jesli cisnienie jest wystarczajaco wysokie *i* pantograf jest podniesiony?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 31 Maja 2017, 06:15:05
Między Sa i Sb nie ma połączenia WN, ale ponoć w Rb jest druga sprężarka. Nie wiem jak z połączeniem 110V między członami.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 31 Maja 2017, 06:18:35
Dopytam o innego EZT, chodzi o ED72. Ten tez ma 4 pudla, jak jest w tym przypadku?
Jesli w rb jest druga sprezarka, to powinna ona napelnic pg i zg w calym skladzie. Teraz to tak wyglada, jakby w ukladzie hamulcowym byla dziura.
Prosze tez o sprawdzenie odhamowania skladu i ruszenie w dalsza jazde EP09 z wagonami osobowymi, po uzyciu radiostopu. Mialem z tym wczoraj klopot, dobrze by bylo, aby ktos jeszcze potwierdzil lub zaprzeczyl. Sytuacja powtarza sie na L061 w skladzie pospieszny1 zarowno w wersji starej paczkowej, jak rowniez tej modyfikowanej przez @Ra. Ani ja, ani AI nie jest w stanie odjechac w takiej sytuacji.
ED:
Wstawiłem zamiast EN71 do Quarka ED72. Okazuje się że ten EZT daje radę i wykonuje polecenia AI, które radzi sobie ze sterowaniem tego składu. W załączniku prawidłowe zatrzymanie na W4 i prawidłowo podniesiony patyk. Skład ukończył jazdę bez problemów.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 31 Maja 2017, 10:04:07
edit: i glupie pytanie numer 2, czy wylacznik cisnieniowy pantografow uaktywnia sie tylko na podstawie cisnienia w zbiorniku pantografow, czy uwzglednia tez stan samego pantografu? tzn czy aktywacja i 'czuwanie' nastapi gdy tylko cisnienie w zbiorniku pantografow jest wystarczajaco wysokie, czy dopiero jesli cisnienie jest wystarczajaco wysokie *i* pantograf jest podniesiony?

Każdy pantograf ma swój PWR. Więc jeżeli jakikolwiek jest podniesiony, to przez niego idzie sygnał umożliwiający sterowanie obwodami pomocniczymi. Jeżeli żaden nie jest, to oczywiście nie załączymy, gdyż PWR jak słusznie podejrzewasz są za elektrozaworami, a więc elektrozawór musi być przesterowany na zasilanie pantografu. A to, czy ma z czego zasilać to jest inna bajka.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 31 Maja 2017, 14:28:50
Między Sa i Sb nie ma połączenia WN, ale ponoć w Rb jest druga sprężarka. Nie wiem jak z połączeniem 110V między członami.
Hm, czyli bardziej poprawnym odzwierciedleniem EN71, w porownaniu do tego co jest obecnie, byloby wstawienie w miejsce obecnego Rb, obroconego (przez -1 we wpisie trainset) Ra? Albo stworzenie odrebnego .fiz z wstawiona sprezarka?

Co do samego bledu, to wychodzi na to ze "winowajca" byla tu implementacja PWR -- a konkretnie, na starcie scenariusza sklady sa napompowane i na podstawie tego cisnienia PWR od razu sie uaktywnial. Gdy cisnienie spadlo, PWR sie zalaczal, co w EZT powoduje zablokowanie przetwornicy... a bez przetwornicy nie uruchamia sie kompresor, i kolko sie zamyka. Ten sam efekt wystepowal tez w EN57, ale tam AI ma do dyspozycji tylko jedna sprezarke pantografow, ktora po (dlugim) czasie prace nabijala dosc cisnienia by odblokowac PWR i wszystko zaczynalo chodzic.

We 'wczorajszym' uaktualnieniu:

- poprawka, zahamowane pojazdy stojace nieruchomo nie wpadaja wiecej w poslizg

- przywrocona funkcja borlandowego exe -- miedzy czlonami ze zdefiniowanym sprzegiem 'warsztatowym' polaczenia takie formowane sa automatycznie na etapie montazu skladow, nawet jesli ten typ sprzegu nie jest wymieniony w pliku .scn  (wprowadzone gdyz nadal sporo skladow nie ma tego sprzegu w scenariuszach, a bez niego moga dziac sie dziwne rzeczy)

- poprawka, dzialanie (aktywacja) PWR jest uzaleznione od obecnosci zrodla niskiego napiecia

(to jest nadal w pewnym stopniu uproszczenie, uzyte poniewaz exe nie symuluje samych zaworow pantografow, a jedynie stan przelacznikow sterujacych. Niemniej na dana chwile chyba sie sprawdza -- EN71 w swojej obecnej postaci, tzn ze sprzegiem WN i jedna sprezarka dzialaja, a jesli kiedys powstanie bardziej 'rzeczywista' wersja to rowniez powinna dzialac, bo w tym wypadku uruchomi sie i napompuje sklad sprezarka z czlonu Rb)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 31 Maja 2017, 16:44:05
EN71 nadal nie jest prawidłowo wybudzany. Nadal nie ma powietrza.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 31 Maja 2017, 17:38:25
Nie obserwuje tego u siebie. Po wybudzeniu AI pompuje i podnosi pantografy na czlonie Sb, nastepnie zalacza wylacznik szybki, przetwornice i sprezarka. Sprezarka w czlonie Ra zaczyna pracowac (litera 'C' w trzeciej linii ekranu F3 w sekcji po lewej stronie ekranu)  Po krotkim czasie dopompowuje dosc powietrza by podniosly sie pantografy na czlonie Sa. Po paru minutach, mniej wiecej gdy sklad dociaga do przystanku poczatkowego, uklad hamulcowy napelniony jest w calosci, i wszystkie urzadzenia pracuja.

Sprawdz prosze, czy procedura wyglada u ciebie tak samo. Jesli tak to pozniejszy brak powietrza musi byc spowodowany czyms innym. Dla pewnosci, nie nalezy usuwac przewodow WN miedzy czlonami silnikowymi, dopoki w EN71 jest tylko jedna sprezarka.

(swoja droga to AI nie powinno ruszac dopoki nie nabije cisnienia w przewodzie do wartosci nominalnej, ale boje sie tutaj cokolwiek ruszyc bo nie wiadomo ile scenariuszy to zepsuje)

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 31 Maja 2017, 17:48:25
Uzywasz sprzegu 255? Dodam, ze do tej pory uzywam 247, jak bylo gdzies opisane. Wczesniej 255/tez nie dalo rezultatu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 31 Maja 2017, 17:54:24
Nie modyfikowalem sprzegow, quarkmce2007.scn definiuje sklad jako
trainset none Skw_post22 40.0 0.0
//$o -Sk&sup3;ad na torze postojowym 2(2) w Skwarkach, ustawiony przodem do koz&sup3;a.
node -1 0 EN71-005ra dynamic pkp\en57_v1 en71-005ra 6baii 0 headdriver 55 0 enddynamic
node -1 0 EN71-005sa dynamic pkp\en57_v1 en71-005sa 6bsii 0 nobody 63 0 enddynamic
node -1 0 EN71-005sb dynamic pkp\en57_v1 en71-005sb 6bsii 0 nobody 55 0 enddynamic
node -1 0 EN71-005rb dynamic pkp\en57_v1 en71-005rb 6bbii 0 nobody 55 0 enddynamic
endtrainset
Exe automatycznie doklada +128 miedzy czlonami. Zeby bylo bardziej poprawnie powinna byc jeszcze +64 (ogrzewanie) ale jego obecnosc lub brak nie wplywa w tym wypadku na efekt koncowy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 31 Maja 2017, 17:56:30
To jak ja zapodalem 247, to co z tego wyszlo? Ok, ide sprawdzic i dam znac. Gdzies trzeba zapisac jakie sprzegi wpisywac w trainsecie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 31 Maja 2017, 18:00:37
247 to 55+128+64, wiec tutaj nie powinno robic roznicy, o ile nie polaczyles tez tym sprzegiem czlonow silnikowych. Znaczyloby to bowiem brak przekazywania wysokiego napiecia, i w takiej sytuacji nie jestem pewien czy przetwornica w sasiednim czlonie (a tym samym sprezarka) uruchomilyby sie, bo przewody ogrzewania sa uwzgledniane tylko czesciowo. Sprawdze to w miedzyczasie u siebie.

edit: aha, przyjrzalem sie tez temu EP09 na linii 61 i tutaj okazuje sie, ze faktycznie otrzymuje ona przez event emergency_brake czyli taki indywidualny radio-stop, ale dowcip w tym ze przynajmniej dla AI nie ma w kodzie jakiejs widocznej metody 'kasowania' tej flagi -- teoretycznie nalezy wylaczyc radio, ale AI nie ma nigdzie zadnych instrukcji, by to radio wylaczyc. Ani zadnej innej metody by zlikwidowac flage, ktora powoduje ciagle oproznianie przewodu. Czy ktorys z poprzednich exemajstrow orientuje sie, jaka miala byc tutaj, przynajmniej teoretycznie, procedura dla AI?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 31 Maja 2017, 18:25:19
Z tym radiostopem nie tylko AI ma problem. Tez nie umialem z tego wyjsc. Brak reakcji na ctrl+r.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 31 Maja 2017, 18:29:52
Ctrl+R powinno skasowac flage, ale oprocz tego trzeba jeszcze potem wcisnac odluzniacz zeby nabilo powietrza powyzej 250 kPa. Przejade sie dla pewnosci i sprawdze.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 31 Maja 2017, 20:55:19
EN71 ogarnięty. Startuje i pompuje i podnosi to co trzeba.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Czerwca 2017, 04:48:29
W dzisiejszym uaktualnieniu:

- po zatrzymaniu sygnalem radio-stop AI potrafi teraz skasowac otrzymany sygnal poprzez wylaczenie/zalaczenie radia, zamiast stac w polu i tylko dusic odluzniacz do usr... smierci

- poprawka, prawdopodobnie usuniete zapetlenie dodawania eventow. Pisze 'prawdopodobnie' bo byc moze w czasie weryfikacyjnych jazd po dokonaniu zmian mialem niezwykle szczescie i sklady na quarku przestaly stwarzac warunki, w ktorych zapetlenie wystepowalo. Jesli blad trafi sie ponownie, prosze krzyczec
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 01 Czerwca 2017, 07:11:10
Nie miałeś szczęścia tylko naprawiłeś EN71, który musiał być zepsuty żeby eventy się zapętlały ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 01 Czerwca 2017, 08:29:04
Jestesmy w stanie to sprawdzic. Trzeba wyjechac za zwrotnice w Zatylu, nawet zdrowym skladem i poczekac na ten z przeciwnej strony. Zrobie probe i dam znac. Inna sprawa, ze wczoraj trafilo mi sie zapetlenie juz na starcie symulacji. Lokalizacja zapetlenia to Mydelniczka.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 01 Czerwca 2017, 09:50:34
tmj, mógłbyś wrzucić commity na serwer? Wracam do świata żywych (moja ukochana małżonka kupiła mi 4 tomy Pana Lodowego Ogrodu na urodziny - potem narzekała, że męża w domu nie ma). Pytanie czy warto już zamknąć pull requesta na główne repo czy jeszcze nie?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 01 Czerwca 2017, 10:33:52
Wychodzi że nie ma błędów z zapętleniem. Stałem tam z 10 minut i nic...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 01 Czerwca 2017, 12:10:50
Jeszcze potestuję, bo zapętlenia zdarzały mi się też na Drawinowie, gdzie nie było żadnych aktywnych EZT. Wszędzie gdzie są blokady liniowe na licznikach pojazdów się z tym spotkałem. Na Quarku jest ich najwięcej i jest największy ruch, wiec najłatwiej tam na nie trafić.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 01 Czerwca 2017, 12:20:16
Protestujesz, a na jakim exe, na tym z dzisiejszej nocy? Ok, sprawdze. Jednak po ustapieniu zapetlenia w Quarku, nie ma powodu aby sadzic ze sa nadal gdzie indziej. Na ktorym skladzie miales te zapetlenia? Quarka testowalem jeszcze 5 razy wstawiajac niewlasciwie skonfigurowanego En71, zapetlenia nie uzyskalem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: MR6 w 01 Czerwca 2017, 12:55:22
Ponownie coś sie doczepiło do kamery, tym razem wewnętrznej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Czerwca 2017, 13:08:38
Nie miałeś szczęścia tylko naprawiłeś EN71, który musiał być zepsuty żeby eventy się zapętlały ;)
To nie calkiem tak, bo za eventy wzialem sie dopiero po EN71, i one na quarku z naprawionym 71 jak najbardziej jeszcze wystepowaly ;>

Zrodla podrzuce dzisiaj troche pozniej, bo co prawda blad na quarku moze byc zalatany, ale po dokladniejszym przyjrzeniu sie obsluga eventow jest ciagle skopana -- konkretnie, procedura ktora w teorii miala wsawiac nowy event przed jakims istniejacym wstawia go po tym istniejacym evencie; w efekcie powstaja sytuacje gdzie eventy wywolywane sa w niewlasciwej kolejnosci/czasie.

Ponownie coś sie doczepiło do kamery, tym razem wewnętrznej.
Jesli to w trybie display list, to prosze chwilowo ignorowac -- tryb DL jest do przerobki, ale czeka na pare komponentow ktore 'sie robia'.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: MR6 w 01 Czerwca 2017, 13:09:08
Otoz to gram na DL.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Czerwca 2017, 13:10:48
Jesli to nie problem to pojezdzij troche na VBO, bo kod VBO bedzie uzyty do 'naprawy' DL, wiec dosc wazne by sam byl sprawdzony I w porzadku ;>
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: MR6 w 01 Czerwca 2017, 15:04:02
Nie powinno byc możliwości zapalić na reflektorach jednocześnie zoltego i czerwonego swiatlełka.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Czerwca 2017, 15:12:08
To akurat chyba zalezy od typu zamontowanego przelacznika lub ich kombinacji (cos, czego exe na ta chwile jeszcze nie obsluguje) Pare razy widzialem kible szusujace z zapalonymi reflektorami i czerwonymi na tym samym koncu (bo nikomu sie nie chce latac z jednego konca skladu na drugi zeby przelaczac koncowki, wiec zostawiaja je zalaczone, albo ktos zwyczajnie zapomni) wiec fizyczna mozliwosc jak najbardziej isnieje.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: MR6 w 01 Czerwca 2017, 15:14:54
W siódemkach akurat nie aczkolwiek w stonkach jak najbardziej. Ale własnie mi tu o 07 chodzi.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Czerwca 2017, 15:18:08
No, z tego co widze to niektore siodemki tez maja indywidualne przelaczniki dla reflektorow i koncowek. Jesli wiec mechanik zalaczy oba przelaczniki dla tego samego swiatla to co sie stanie w takiej sytuacji, ktore sie zapali, a ktore zostanie olane?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: MR6 w 01 Czerwca 2017, 15:29:00
Coz ale my nie mamy kabin z takimi indywidualnymi przełącznikami.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Czerwca 2017, 16:12:14
Jak to nie mamy? "Flagowa" 424 ma wlasnie takie przelaczniki...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 01 Czerwca 2017, 16:47:57
Pare razy widzialem kible szusujace z zapalonymi reflektorami i czerwonymi na tym samym koncu (bo nikomu sie nie chce latac z jednego konca skladu na drugi zeby przelaczac koncowki, wiec zostawiaja je zalaczone, albo ktos zwyczajnie zapomni) wiec fizyczna mozliwosc jak najbardziej isnieje.

Jeżeli przez pojęcie "tym samym koncu" masz na myśli sygnały końca i dodatkowo sygnał oznaczający jazdę manewrową (i to na nowszych asynchronach tak od ~2013 roku), to akurat też po części wynika z wymuszania końcówek przez niektórych w tylnej kabinie. Szczególnie nabrało to znaczenia po skasowaniu AKMki przez SKMkę w Warszawie jakiś czas temu, gdy ten pierwszy robił reset i miał przez to ciemny tył. Po tym zdarzeniu dorobiono opcję, że wymuszone końcówki są jeszcze przez kilka dobrych minut zasilane z baterii nawet przy jej wyłączeniu. Efekt uboczny jest właśnie taki, że gdy na czole zapalimy białe manewrowe, z tyłu będzie i białe i wymuszone końcówki.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Czerwca 2017, 16:52:22
Nie, mialem na mysli ze autentycznie w kiblu zapalone byly reflektory do normalnej jazdy, a oprocz tego swiecily sie tez koncowki po tej samej stronie skladu. Nie bylo to na manewrach a kibel byl stary (do tego to dobre kilka lat temu bylo) Zakladam ze to raczej bylo roztargnienie, a nie celowa jazda po bandzie, niemniej mialo to miejsce :>
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: MR6 w 01 Czerwca 2017, 16:54:31
Zwracam honor. Jednak przykladowo taka kabina ic nie ma, więc w niej trzeba wylączyc takową opcje.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 01 Czerwca 2017, 17:13:24
Trzeba wejść głębiej, bo o ile dobrze pamiętam, tam jest pakieciak czerwone>off>białe. Teraz jak sobie ustawimy oba włączone, to wyjdzie nam pozycja na off. (Prawdopodobnie dwa kręciołki są do siebie przypisane w hierarchii.)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Czerwca 2017, 17:15:42
Przy obu wlaczonych chyba ustawia sie na 'zapalone biale' o ile dobrze pamietam. Tak czy owak trzeba bedzie dorobic wariant, ale to raczej przy ogolnym ogarnianiu definicji kabiny itp, czyli jeszcze nie na juz.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: matek123 w 01 Czerwca 2017, 22:11:17
Tu wychodzi, że każda kabina powinna mieć swój osobny skrypt dużo bardziej rozbudowany od mmd. Ale to chyba jeszcze nie pora na to.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mareczek w 01 Czerwca 2017, 23:31:17
Ciekawie wygląda kabina EP09 przy użyciu piasecznicy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 02 Czerwca 2017, 02:01:05
W dzisiejszym wczorajszym uaktualnieniu:

- eksperymentalnie, poprawki w sortowaniu i ogolnie obsludze dodawania eventow do listy; pisze "eksperymentalnie" bo nie ma pewnosci czy zmiana zachowania na takie, jakie powinno byc ale wskutek bledow nie bylo, nie wywola jakichs bledow w scenariuszach. Ale jak to mowia, jest tylko jeden sposob zeby sie przekonac.

edit: w ramach dalszych eksperymentow

- rozdzielone dzialanie przyciskow kontroli syreny, aktywacja tonu wysokiego nie wylacza niskiego, i odwrotnie. Aby uniknac blednego zapetlania sie dzwiekow aktywacja tonu wysokiego zostala przeniesiona domyslnie pod klawisz S (kontrola piasecznicy jest teraz domyslnie pod shift+S, a przelacznik blokady drzwi pod ctrl+S)

aktualne zrodla ida na githuba, wiec mozna je podlaczac do czego tam kto chce :d
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 02 Czerwca 2017, 21:44:30
Na kaliskiej mam dziwne kwiatki. Nigdy tu nie było mostu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 02 Czerwca 2017, 21:47:36
W trybie Display List beda takie kwiatki przez pare dni, dopoki nie skoncze unifikacji metod renderowania. W miedzyczasie lepiej jezdzic w trybie VBO jesli to mozliwe, tam tego nie ma (a przynajmniej nie powinno byc)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 02 Czerwca 2017, 21:51:43
No to był tryb vbo. WG nowego eu07.ini A nie chyba starter Ry podmienia wpisy. Teraz zaznaczyłem vbo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 02 Czerwca 2017, 21:53:05
Rainsted na defaultowych ustawieniach ma DL. Może nadpisywać ini. Tam trzeba zerknąć jak ktoś używa startera.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 02 Czerwca 2017, 21:55:31
Mozesz dla mojego swietego spokoju wcisnac f9 i sprawdzic tam, czy to na pewno bylo przy wlaczonym VBO? Bo latajacy most na DL wystepuje na pewno, ale na VBO raczej nie widzialem. I tak jak pisze Stele, czasami moze byc co innego niz sie mysli ze jest :>
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 02 Czerwca 2017, 21:59:20
Już lukam. Zapomnialem ze starter nadpisuje ten plik.

Dobra jest ok. Sory za alarm.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 02 Czerwca 2017, 23:30:48
Technicznie rzecz biorac jeszcze troche za wczesnie, ale raczej nie planuje  wiekszych zmian przez najblizsze pare dni, wiec moze wyjsc teraz zwlaszcza ze blad byl dosc powazny :d

- poprawka, zasieg skanowania nie jest ograniczony przez semafor z sygnalem S2
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 03 Czerwca 2017, 00:10:07
Witam.
 U mnie na exe 17.06.02, tryb VBO, sceneria kaliska. Rozstrzeliło w kosmos skład stojący jako dekoracja w Kaliszu ( ET22 plus 443V z piaskiem jak się nie mylę). Poza tym to samo spotkało na tej stacji czołową sekcję jamnika ( podmieniłem sobie składy). Ten błąd pojawił się po jakimś czasie,  po przełączeniu w debugmode. Gdy nadleciałem nad Kalisz, aby sprawdzić gdzie mi pośpiech i towarek utknął.
I kolejna ciekawostka, ukrotnione w ramach testu dwa EN71 i nagminnie druga jednostka wyłączała się. Pomagał dopiero dogłębny restart składu.
 Załączam screeny, log, errors.
Pozdrawiam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 03 Czerwca 2017, 00:34:28
Chyba kaliskiej nie skoncze. Wywalilo mi szybkiego i przetowrnice a teraz nie mogę zalaczyc przetwornicy i co za tym idzie tez sprężarki. Zeszlo powietrze i kicha. Mala sprezarke dobiłem w silnikowym ale nadal nie zalacze przetwornicy na kibelku. Jakis bug? czy ja czegos niewiem?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 03 Czerwca 2017, 00:44:39
Zapewne zalaczyl sie pwr, ktory w kiblu przy spadku cisnienia blokuje ponowne zalaczenie przetwornicy dopoki nie zostanie uaktywniony ponownie, tzn dopoki cisnienie w zbiorniku pantografow nie dojdzie do nie pamietam jakiej wartosci. Na ekranie F3 aktywacje mozna zobaczyc na identyfikatorach stanu pojazdu (stan jest osobny rowniez dla kazdego czlonu, najszybciej da sie sprawdzic podchodzac w widoku zewnetrznym do czlonu silnikowego)

B (bateria)
M (szybki)
o (pantograf przedni) (mala litera: ma byc podniesiony, duza litera: podniesiony i dostaje napiecie)
p (pantograf tylny) (j.w.)
* aktywowany wylacznik cisnieniowy pantografow lub ! zalaczony wylacznik cisnieniowy pantografow
X (przetwornica) (mala litera, wlacznik w pozycji zalaczona, duza litera: pracuje)
! (bezpiecznik nadmiarowy przetwornicy)
C (sprezarka) (jak dla przetwornicy)
! (aktywna blokada sprezarki)

w skrocie, pompuj mala sprezarka az do skutku :s

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 03 Czerwca 2017, 01:00:04
Tak wlasnie zrobiłem. W końcu zalapal. Ale 10 minut zlapalem. Z innych rzeczy podsypka nie miga ogolnie na kaliskiej 80fps i w zwyz u mnie jest.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: MR6 w 03 Czerwca 2017, 11:21:55
Na prośbę Krzysia sprawdziłem działanie rs u AI(linia 61-lubliniec), Ai ładnie odhamowało i ruszyło dalej, bez zarzutów.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 03 Czerwca 2017, 11:25:41
Dzieki, rozumiem ze jechales w trybie normalnym. W debugmode AI nie jest  wstanie odjechac.. Zapomnialem o tym, dziekuje. Teraz u mnie tez wszystkie sklady zbieraja sie po RS.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 05 Czerwca 2017, 00:18:06
Witam.
 Ponownie na kaliskiej miałem defragmentację wagonów, tym razem jadąc stonką z króciutkim towarkiem w kierunku Kalisza. Odwracam się i widzę ścianę z eaosów za sobą, po czym gdy chciałem przesiąść się na towarka który leciał z naprzeciwka (EU07 plus stonka), niespodziewanie wyrzuciło mnie do windy. W Errors taki oto ostatni wpis...Voltage loss: by en57-14s at -28295.43    0.08 -3028.95, time    0.21
Voltage loss: by eu07-465 at -60073.05    9.89 5623.40, time    0.20
Critical error, memory allocation failure: bad allocation"
Załączam errors, oraz log.
Pozdrawiam.
Ps. Byłbym zapomniał najważniejszego:
Windows XP SP3, 4Gb ramu, Exe najnowsze, tryb VBO.

 
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 05 Czerwca 2017, 01:44:09
W duzym skrocie tego typu defragmentacja to objaw, ze  karta graficzna i/lub system nie moze dostarczyc tyle pamieci, ile by chcial symulator. Na ten moment trudno powiedziec czy jest to blad gdzies w kodzie exe, czy tez ograniczenie windows XP -- poniewaz np @Krzysiek626 mial ten sam problem, ale jesli dobrze pamietam, to ustapil on po uruchomieniu symulatora na tym samym sprzecie, ale przy zainstalowanej nowszej wersji windows.

Kod graficzny exe przechodzi teraz pewne przerobki, wiec jesli blad byl po stronie exe to moze cos sie pod tym wzgledem poprawi, na razie jest jeszcze za wczesnie by mozna bylo powiedziec cos konkretniejszego.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 05 Czerwca 2017, 04:33:03
Ten blad pamieci tylko mam na VBO i XP. Ta sama ilosc pamieci. Z tego co pamietam malo jezdzilem na VBO, ale z poczatku konczylem zawsze Kaliska bez trudnosci. Owszem mialem wysypy ale nie tyle co zglaszal Wlodek.  Przy tej samej ilosci pamieci lepikej spisuje sie windows 7.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: bohunIC w 05 Czerwca 2017, 09:11:21
Kod graficzny exe przechodzi teraz pewne przerobki
O jakich przerobkach mowimy?

Przy okazji porusze cos co negatywnie wplywa na oprawe graficzna tj drzewa, ktore sa wyswietlane jako alpha w ukladzie X. Cienie klada sie na czesci/na jednej stronie textury i wyglada to bardzo zle, mysle ze wiecie o czym mowa. Pewnie jest prostrzy sposob jak edycja pliku inc?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 05 Czerwca 2017, 10:13:53
W duzym skrocie tego typu defragmentacja to objaw, ze  karta graficzna i/lub system nie moze dostarczyc tyle pamieci, ile by chcial symulator. Na ten moment trudno powiedziec czy jest to blad gdzies w kodzie exe, czy tez ograniczenie windows XP -- poniewaz np @Krzysiek626 mial ten sam problem, ale jesli dobrze pamietam, to ustapil on po uruchomieniu symulatora na tym samym sprzecie, ale przy zainstalowanej nowszej wersji windows.

Kod graficzny exe przechodzi teraz pewne przerobki, wiec jesli blad byl po stronie exe to moze cos sie pod tym wzgledem poprawi, na razie jest jeszcze za wczesnie by mozna bylo powiedziec cos konkretniejszego.
To by się zgadzało. Gdy jeździłem w trybie DL, takich błędów nie rejestrowałem. Zdarzały się co prawda sporadyczne wysypy, ale nic poza tym. No cóż, w końcu trzeba będzie kiedyś zainwestować w nowszy komputer. Rozbudowywanie/modernizacja obecnego sprzętu z uwagi ograniczenia plyty głównej nie ma sensu.
Pozdrawiam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: adamst w 05 Czerwca 2017, 12:00:36
Kod graficzny exe przechodzi teraz pewne przerobki
O jakich przerobkach mowimy?

Przy okazji porusze cos co negatywnie wplywa na oprawe graficzna tj drzewa, ktore sa wyswietlane jako alpha w ukladzie X. Cienie klada sie na czesci/na jednej stronie textury i wyglada to bardzo zle, mysle ze wiecie o czym mowa. Pewnie jest prostrzy sposob jak edycja pliku inc?

W trainzie radziliśmy sobie z tym w ten sposób, że się edytowało materiały w modelach drzewek wywalając im diffuse i specular, a zostawiając tylko ambient. Ale nie wiem, czy w Maszynowym modelu oświetlenia by to przeszło. Niestety to ogólna przypadłość drzewek "billboardowych" że brzydko reagują na światło kierunkowe.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 05 Czerwca 2017, 13:24:18
O jakich przerobkach mowimy?
Zakonczenie unifikacji kodu rysowania, czyli usuniecie dwoch odrebnych sciezek i danych dla wersji VBO i DL. Ulatwi/umozliwi to wprowadzenie dalszych modyfikacji (polaczenie z wersja shaderowa @Milka7 i inne)

Co do krzyzakowych drzew to jakie sa, kazdy widzi i tutaj trudno spodziewac sie rewelacji. Sztuczka z oswietleniem ambient byc moze ptroche by pomogla, ale ktos musialby ja przetestowac, bo ambient jest w symulatorze w zasadzie nieobslugiwany (tzn jest aktywny, ale ignoruje wartosci definiowane w .t3d) Chyba lepie byloby rozwazyc zastapienie obecnego include przez kombinacje prostego modelu 3d uzywanego na krotkich dystansach, przelaczanego na billboard na dystansach dalszych.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: bohunIC w 05 Czerwca 2017, 14:51:17
No mysle ze warto zaczac od malych szczegolow, bo to one rzutuja na caloksztalt.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 06 Czerwca 2017, 12:50:03
Prowadząc skład węglarek, okazało się, że nie jestem w stanie hamować klawiszami 3 i luzować 9, kran hamulca nie działa. Lokomotywa to ET21. Klawisze 2,5,8 działają (hamują).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 06 Czerwca 2017, 13:36:34
Sprawdzilem na szybko na TD, i klawisze wydaja sie dzialac normalnie. Nalezy zwrocic uwage, ze przy tej konfiguracji dzialaja glownie hamulce wagonow, trzeba wiec patrzec na poziom powietrza w przewodzie glownym (train pipe na ekranie F1)  Jesli jest on ponizej 500 kPa to hamowanie jest wdrazane -- mozna wyjsc z lokomotywy i sprawdzic stan hamulca w poszczegolnych wagonach na ekranie F3 (wartosc TrB w trzeciej linii, po lewej)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 06 Czerwca 2017, 13:44:31
@tmj. Zwierzyniec, skład z et21 przerżnąłem dwa razy s1. Owszem, jest w PG ciśnienie, ZG pełny. Zamykam kran (animacja poprawna) do końca a skład jedzie jak po lodzie. Zero ciśnienia w CH. Hamowanie klawiszami 2, 5, 8 działa, więc stawiam na działanie przycisku 3, a konkretnie jaki skutek wywołuje dla tej konfiguracji składu.
trainset rozklad tor_trasa_c_start 80.0 0.0
//trainset rozklad test_c 80.0 0.0
//$o Prowadzimy skład towarowy. Opis w dołączonym pliku HTML.
node -1 0 ET21-98 dynamic pkp\et21_v2 et21-98 3e2 0 headdriver 3.BP 0 enddynamic
node -1 0 5520372-3 dynamic pkp\eaos_v1 401w-50 401w 0.0 nobody 3.BP 0 enddynamic
node -1 0 5520372-3 dynamic pkp\eaos_v1 401w-62 401w 0.0 nobody 3.BP 0 enddynamic
node -1 0 5520372-3 dynamic pkp\eaos_v1 401w-34 401w 0.0 nobody 3.BP 0 enddynamic
node -1 0 5520372-3 dynamic pkp\eaos_v1 401w-23 401w 0.0 nobody 3.BP 0 enddynamic
node -1 0 a49562 dynamic pkp\424z_v1 res01 424z 0.0 nobody 3.BP 4 kontener40stop enddynamic
node -1 0 a7231 dynamic pkp\424z_v1 res01 424z 0.0 nobody 3.BP 4 kontener40stop enddynamic
node -1 0 a49562 dynamic pkp\424z_v1 res01 424z 0.0 nobody 3.BP 4 kontener40stop enddynamic
node -1 0 5051-503220-2 dynamic pkp\sis_v2 sis 426s 0.0 nobody 3.BP 0 enddynamic
node -1 0 5051-503220-2 dynamic pkp\sis_v2 sis 426s 0.0 nobody 3.BP 0 enddynamic
node -1 0 5051-503220-2 dynamic pkp\sis_v2 sis 426s 0.0 nobody 3.BP 0 enddynamic
node -1 0 5051-503220-2 dynamic pkp\sis_v2 sis 426s 0.0 nobody 3.BP 0 enddynamic
node -1 0 5051-503220-2 dynamic pkp\sis_v2 sis 426s 0.0 nobody 3.BP 0 enddynamic
node -1 0 5520372-0 dynamic pkp\gags_v2 gags01 401ka 0.0 nobody 3.BP 0 enddynamic
node -1 0 5520372-0 dynamic pkp\gags_v2 gags03 401ka 0.0 nobody 3.BP 0 enddynamic
node -1 0 5520372-0 dynamic pkp\gags_v2 gags01 401ka 0.0 nobody 3.BP 0 enddynamic
node -1 0 5520372-0 dynamic pkp\gags_v2 gags03 401ka 0.0 nobody 3.BP 0 enddynamic
node -1 0 a49562 dynamic pkp\424z_v1 res01 424z 0.0 nobody 3.BP 4 kontener40stop enddynamic
node -1 0 a7231 dynamic pkp\424z_v1 res01 424z 0.0 nobody 3.BP 4 kontener40stop enddynamic
node -1 0 a49562 dynamic pkp\424z_v1 res01 424z 0.0 nobody 3.BP 4 kontener40stop enddynamic
node -1 0 5520372-3 dynamic pkp\eaos_v1 401w-w2-n 401w 0.0 nobody 3.BP 0 enddynamic
node -1 0 5520372-3 dynamic pkp\eaos_v1 412w-22 412w 0.0 nobody 3.BP 0 enddynamic
node -1 0 5520372-3 dynamic pkp\eaos_v1 412w-34 412w 0.0 nobody 3.BP 0 enddynamic
node -1 0 5520372-3 dynamic pkp\eaos_v1 401w-w8-n 401w 0.0 nobody 0.BP 0 enddynamic
endtrainset
Powyżej skład którym jechałem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 06 Czerwca 2017, 14:29:18
Wkleilem tez sklad u siebie, i po rozpedzeniu do 50 km/h zaczalem hamowac klawiszem 3.  Pierwsze uruchomienie wymagalo zejscia kranem na pozycje 3, zapewne dlatego ze przed ruszeniem napelnialem przewod uderzeniowo i pewnie przedobrzylem. Po tym pierwszym hamowaniu i odhamowaniu skladu dalsze reakcje na hamulec nastepowaly juz w pozycji 1 (takze uzywajac klawisza 3)
(po dodatkowych testach, wyglada na to ze dosc czesto zeby 'ruszyc' napelnianie trzeba zejsc na pozycje 3, a nastepnie mozna redukowac nastawienie do 2 albo 1. Dziala to tak samo dla klawiszy 3+9 i 8/5/2 wiec zapewne jest to wynikiem charakterystyki hamulca. To nie moja branza, wiec nie wiem czy jest to zachowanie prawidlowe)

Nawiasem mowiac nie wiem czy tak skonfigurowany trainset jest w 100% poprawny, bo .BP nastawia czas reakcji hamulca na 'pociag pasazerski' a nie towarowy, nie jestem pewien jak to ustawienie jest obslugiwane w wagonach towarowych, jesli w ogole.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 06 Czerwca 2017, 14:49:49
Mam wyluzowany sklad, ruszam. Rozpedzam sie do 50km/h i robie hamowanie kontrolne przestawiajac kran hamulca klawiszem 3 na hamowanie zasadnicze. W tym momencie jest brak hamulca, cylindry nie napelniaja sie. 2,5,8 rozumiem jako przyciski/klawisze ustawiajace kran od razu w przypisanej im pozycji i to dziala, czemu przestawienie kranu trojka w hamowanie zasadnicze nie daje zadnego efektu procz animacji? 2 5 8 przestawia kran skokowo, ale 3 i 9 plynnie i powinno dzialac tak samo, niezaleznie od harakterystyki hamulca.
Nie wiem czemu sa takie wpisy do trainsetu. Mnie tez nie podobaja sie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 06 Czerwca 2017, 15:11:24
Przejechalem sie dla pewnosci pare razy, i z tego co widze 8/5/2 i 3/9 dzialaja identycznie, w sensie ustawienie hamulca w pozycji np. 2 zarowno przez wcisniecie "5" jak i 2x"3" ma ten sam efekt -- w wypadku tego akurat skladu ten efekt jest dosc czesto 'zaden', i zeby rozpoczac hamowanie trzeba rozpoczac od pozycji 3 (klawisz "2" lub 3x"3") a nastepnie mozna zejsc na pozycje nizsza jesli hamowanie ma byc bardziej delikatne.

(porownanie robilem schodzac na pozycje 'recznie' klawiszem "3", cofajac z powrotem na pozycje 0 i ponownie wchodzac na poprzednio ustawiona pozycje, uzywajac jednego ze skrotow 8/5/2. Rowniez stosujac ten sam process, ale w odwrotnej kolejnosci)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 06 Czerwca 2017, 15:25:21
Mam to rozumieć jako potwierdzenie błędu? Wejście kranem na pozycję 3 nie powinno się różnić w zależności od przyciskanego klawisza. Konkretnie chodzi czy jest co do poprawienia i gdzie? Wpis składu w trainsecie poprawie i sprawdzę sam.
ED:
Skład po przepisaniu sprzęgów hamulcowych nadal zachowuje się tak samo. Dobrze by było aby ktoś to obadał, może nie umiem tego trafnie opisać.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 06 Czerwca 2017, 16:07:36
Mam to rozumieć jako potwierdzenie błędu? Wejście kranem na pozycję 3 nie powinno się różnić w zależności od przyciskanego klawisza.
Nie, przeciwnie; z tego co obserwuje u siebie *nie ma* roznicy w zachowaniu, wejscie na pozycje klawiszem skrotu (8/5/2) lub przez przyciskanie klawiszy 3/9. Szczegolowo:
- wejscie z pozycji 0 na pozycje 1 klawiszem "8" lub poprzez jednokrotne wcisniecie klawisza "3" -- efekt taki sam
- wejscie z pozycji 0 na pozycje 2 klawiszem "5" lub poprzez dwukrotne wcisniecie klawisza "3" -- efekt taki sam
- wejscie z pozycji 0 na pozycje 3 klawiszem "2" lub poprzez trzykrotne wcisniecie klawisza "3" -- efekt taki sam
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 06 Czerwca 2017, 16:11:44
Tyle, że ja mam różnicę bo używając 2,5,8 mam hamowanie, a używanie 3 kończy się tylko animacją rączki kranu hamulca, bez hamowania. Dlatego proszę, aby jeszcze ktoś to sprawdził na exe 20170603.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Tomnord15 w 06 Czerwca 2017, 19:44:40
Przetestowałem na szybko ET21 że składem beczek i z pozycji jazdy trzy razy 3 na numerycznej i skład bez problemu hamuje. Exe najnowsze.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 06 Czerwca 2017, 19:56:41
A możesz to sprawdzić na Zwierzyńcu z ET21-98? Tam zamiast beczek są węglarki i platformy. To ważne dla mnie, dzięki.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 06 Czerwca 2017, 23:59:56
Krzysiu pamiętaj ze knorry maja odcięcie, a hamowanie nimi zdecydowanie jest inne od hamowania oerlikonem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 09 Czerwca 2017, 06:55:33
Z pola walki z tabelką ograniczeń to miałem nadzieję, że coś pójdzie bardziej do przodu, niestety praca mi nadepnęła. Coś tam jednak poruszyło się do przodu i znalazłem jeszcze niedostatki funkcji, które określają położenie eventu względem toru. Ale wygląda obiecująco. Włącznie z tym, że napisałem funkcję, która sprawdza cały rozkład jazdy kiedy trafi na stację poza kolejnością i przewija do niej jak coś.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Kermit w 12 Czerwca 2017, 23:27:12
x64 170603 [na 170417 to samo], TEM2, dzwiek turbo szaleje. http://www58.zippyshare.com/v/fkg7BNv9/file.html To 2/3 pozycja nastawnika, dodatkowo przy zjezdzie z ostatniej pozycji nastawnika do zera przy wylaczonym silniku i nawet bateriach slychac przez ulamek sekundy gwizd turbo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Maciej w 13 Czerwca 2017, 15:56:32
Znalazłem błąd dotyczący przezroczystości niektórych elementów na lokomotywach SP45. Manometry, amperomierze i woltomierze działają prawidłowo. Problem dotyczy mierników obrotów silnika, haslera oraz temperatury wody obwodu głównego i pomocniczego (widać to na screenie). Na sceneriach nocnych, po zapaleniu oświetlenia przyrządów, sprawa wygląda tak jakby tylko nakładane były tekstury z przezroczystością (czyli tekstury podświetlenia), zaś sama podstawa (czyli tekstury nieoświetlonych przyrządów) znikała, przez co powstaje taki problem. Jakiś czas temu zgłaszałem w innym wątku, że po zapaleniu oświetlenia na nowych haslerach na EU07 stawał się on przezroczysty (tylko w wersji t3d). Wtedy (na starym tradycyjnym exe) problem znikał po wygenerowaniu e3d. Na obecnej wersji nawet wygenerowanie e3d nie zmienia przezroczystości. Z tego wynika, że najprawdopodobniej problem podświetlenia SP45 jest taki sam jak na EU07. Pytanie tylko co jest przyczyną takiego działania? Jakiś błąd w modelu czy exe?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 13 Czerwca 2017, 16:18:07
Ktora to kabina? Obawiam sie, ze nie widze tego u siebie -- wyglada to jak na zalaczniku. Nie wiem czy wszystkie SP45 uzywaja tego samego modelu.

edit:
x64 170603 [na 170417 to samo], TEM2, dzwiek turbo szaleje. http://www58.zippyshare.com/v/fkg7BNv9/file.html To 2/3 pozycja nastawnika, dodatkowo przy zjezdzie z ostatniej pozycji nastawnika do zera przy wylaczonym silniku i nawet bateriach slychac przez ulamek sekundy gwizd turbo.
Na ile moge na szybko powiedziec, to samo ma miejsce w exe Borlandowym -- modulacja jest chyba uzalezniona od pozycji nastawnika i/lub obrotow i efekt jaki jest, taki jest. Niestety nie mam zielonego pojecia jakie powinno byc tutaj zachowanie poprawne. Jesli ktos potrafi to mozliwie szczegolowo/jasno opisac to bedzie mozna pomyslec o poprawianiu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Mariusz1970 w 13 Czerwca 2017, 16:28:59
Musicie sie rowniez dogadac, czy t3d, e3d i jesli e3d z ktorego exe konwertowane.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 13 Czerwca 2017, 16:38:27
Krótka piłka, model załadowany jako t3d na 20170603. widać jak na screenie. W załączniku log i errors.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Maciej w 13 Czerwca 2017, 16:40:32
@tmj masz prawidłowo, bo zapewne wczytałeś z modelu e3d (załączonego do wydanej oficjalnie paczki), który z tego co się domyślam został wygenerowany na tradycyjnym, starym exe, w związku z czym problem nie jest widoczny. Usuń sobie z folderu z SP45 modele w wersji e3d i zostaw t3d. Wtedy zobaczysz problem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 13 Czerwca 2017, 16:47:44
Czyli najprawdopodobniej cos jest namieszane przy sortowaniu/generowaniu e3d, @Stele mial tez wczesniej problem przy generowaniu semaforow. Trzeba bedzie sprawdzic, chociaz jesli modele wygenerowane starym exe wyswietlaja sie poprawnie, priorytet jest dosc niski ;d
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 13 Czerwca 2017, 16:51:06
A co z t3d? W sumie to zawsze była developerska paczka, powinna generować poprawnie przezroczystości.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Maciej w 13 Czerwca 2017, 16:53:09
Moim zdaniem to nie jest problem w sortowaniu/generowaniu e3d, tylko raczej jakiś problem z t3d. T3d jest jednak podstawowym plikiem, z którego generowany jest e3d. Stare exe być może pomijało przezroczystości przy generowaniu czy coś, w związku z czym wyświetlało się poprawnie. Więc wydaje mi się, że skoro e3d pokazuje tak samo jak t3d, to nie w tym leży problem. Albo coś jest nie tak z modelem (kolejność submodeli albo coś innego?), albo coś nie tak z exe. Mi osobiście wydaje się, że coś jest źle w modelu t3d, skoro np. w SU45 wszystko działa prawidłowo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: MR6 w 13 Czerwca 2017, 16:57:01
Kabina jest oparta na tej od SU45, w miernikach nie było nic zmienianie( oprócz tego problemu z zerami), nie mam pojęcia co może być przyczyną zwłaszcza ze na borlandzie działa bez zarzutu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 13 Czerwca 2017, 16:58:28
Moim zdaniem to nie jest problem w sortowaniu/generowaniu e3d, tylko raczej jakiś problem z t3d.
Zeby to zweryfikowac ktos musialby "recznie" porownac strukture t3d dla obu plikow. Zdaje sie ze w starterze sa jakies narzedzia ktore moga w tym pomoc, ale moj kontakt i znajomosc startera jest minimalna.

Wstepnie duzo prostsze imo byloby skasowanie .e3d dla SU45 i sprawdzenie, co sie stanie gdy jego .t3d zaladowany zostanie do nowego exe.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Maciej w 13 Czerwca 2017, 17:02:03
SU45 wczytana na nowym exe z t3d działa prawidłowo. Z SP45 jest problem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 13 Czerwca 2017, 17:05:25
Czyli jednak weryfikacje trzeba by zrobic, jesli ktos chce sie podjac ;/  (mozliwe ze zmieniona zostala przypadkowo lub celowo hierarchia submodeli, ale na slepo nie ma co zbytnio spekulowac)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 13 Czerwca 2017, 17:05:43
Wstepnie duzo prostsze imo byloby skasowanie .e3d dla SU45 i sprawdzenie, co sie stanie gdy jego .t3d zaladowany zostanie do nowego exe.
Ja to zrobiłem za nim napisałeś. No przecież opisałem i dałem screena z wczytania pliku t3d na nowym exe i jest źle. Wygenerowałem nowe e3d za pomocą 20170603 i też jest źle. To samo t3d na borlandzie wczytuje się poprawnie i poprawnie generuje na borlandzie e3d, które notabene wczytują się poprawnie do 20170603.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Maciej w 13 Czerwca 2017, 17:07:07
Krzysiek, ale Ty dałeś screena z SP45, a teraz mówimy o SU45.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 13 Czerwca 2017, 17:07:57
No przecież opisałem i dałem screena z wczytania pliku t3d na nowym exe i jest źle.
Krzysiu, ale mi chodzilo o to, czy zle bedzie takze przy ladowaniu t3d dla SU45, nie SP45 :) z tego co pisze @Maciej to nie, wiec byc moze rzeczywiscie jakas roznica miedzy tymi dwoma .t3d jest.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: matek123 w 13 Czerwca 2017, 18:08:43
Różnią się. Opaticy jest takie samo. W kabinie były ręcznie podmienione niektóre submodele jak ten o odpowiadający za podświetlenie dwóch mierników tych najbardziej po lewej. Podświetlenia haslera nie tykałem, a też są cyrki.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Maciej w 13 Czerwca 2017, 18:24:22
Z podświetleniem haslera cyrki są też na siódemkach i ósemkach, czyli tam gdzie zostały podmienione na nowe (autorstwa @TZs). Przyczyna będzie prawdopodobnie ta sama co w przypadku mierników na SP45. Tylko pytanie jaka to przyczyna.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 13 Czerwca 2017, 18:48:47
Opacity 100 zamienic na opacity 0.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Maciej w 13 Czerwca 2017, 19:00:05
To nie to. Sprawdziłem kilka rzeczy i doszedłem do wniosku, że na 100% znika podstawowa tekstura, czyli przykładowo w przypadku haslera znika jego tarcza, a zamiast niej pojawia się tylko przezroczyste podświetlenie. Teraz pytanie do tych, którzy znają się na modelach: dlaczego tak się może dziać?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: szogun w 13 Czerwca 2017, 19:00:58
Bo C+ źle interpretuje opacity, wygeneruj e3d na borlandowym i będzie ok.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 13 Czerwca 2017, 19:02:10
A jaka jest ich kolejność w modelu? Tło musi się rysować przed podświetleniem. Tylko dlaczego teraz się to gorzej sortuje?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Mariusz1970 w 13 Czerwca 2017, 19:03:09
Podpiete pod tego samego rodzica z sufiksem _on _off lub jeden do _on, drugi do _off ?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Maciej w 13 Czerwca 2017, 19:09:18
Wina tekstur. Podmieniłem sobie z ciekawości plik kabina1.tga w folderze z SP45 na tą z SU45. Mierniki obrotów i temperatury wody wyświetlają się teraz prawidłowo.

EDIT: Powodem błędnego wyświetlania był zbędny kanał alfa na teksturach niepodświetlonych mierników i haslera.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 13 Czerwca 2017, 19:39:51
Mi nawet do glowy nie przyszlo ze ktos by dodal alfe, bo jak nie trzeba to po co ;/

(exe sprawdza wystepowanie alfy, i jesli ja znajdzie to model z taka tekstura jest przesuwany do fazy obiektow przezroczystych; czyli jak jest tarcza i podswietlenie to podswietlenie moze byc rysowane wczesniej, a tarcze juz wtedy sobie odpuszcza bo mu wychodzi ze jest pod spodem czyli z punktu widzenia renderera niewidoczne)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 13 Czerwca 2017, 19:44:38
@tmj wspominał o karzełkach, też trzeba sprawdzić co tam się dzieje. Mam wrażenie, że nie na wszystkich było źle.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Maciej w 13 Czerwca 2017, 19:45:59
W SP45 alfa była bez sensu, zaś z tego co widzę to w przypadku haslerów od @TZs alfa była użyta do cyferek od liczenia kilometrów, ale chyba jak ją usunę to nic złego się nie stanie?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: matek123 w 13 Czerwca 2017, 20:31:22
Mi się wydaje, że jest wycięcie na licznik. Za parę minut podejrzę model tarczy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 14 Czerwca 2017, 07:09:36
Wygląda, że trzeba by zrobić sprawdzanie czy dany submodel ma przeznaczenie na wyświetlanie alfy i dopiero wtedy sprawdzenie czy tekstura ma alfę.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 14 Czerwca 2017, 10:09:01
No to od tego był parametr opacity. Z setką ma mieć alfa testa i być rysowany wcześniej, z zerem ma mieć alfa blenda i być rysowany później. Reszta zgodnie z kolejnością w modelu. TMJ, zmieniałeś tu coś?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 14 Czerwca 2017, 13:32:40
Opacity jako parametr wystepuje tylko w t3d, do e3d z jakiegos powodu nie jest przenoszony. Nie wiem kto tak ustalil i czemu, ale efektem ubocznym jest ze przy ladowaniu e3d exe musi polegac na wygenerowanych flagach przezroczystosci, i o ile dobrze pamietam sprawilo to gdzies tam w polowie watku problem. Zobacze czy uda sie tutaj cos wyprostowac, o ile znowu nie wywola problemow ;/
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Maciej w 14 Czerwca 2017, 15:32:25
A nie można zrobić takiej możliwości, żeby były wyświetlana dwa obiekty z przezroczystością? W sensie, że jeśli tekstura podstawowa (czyli np. niepodświetlony hasler) ma alfę oraz tekstura podświetlenia ma alfę, to i tak obie się wyświetlą. Bo spojrzałem na te haslery od @TZs i widzę, że gdybym usunął alfę z niepodświetlonego haslera, to po załączeniu podświetlenia, cyfry od licznika kilometrów nie będą widoczne przez, to że nie będą oświetlone.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 14 Czerwca 2017, 15:36:55
Wyswietlanie wielu obiektow z przezroczystoscia jest mozliwe, ale wymaga to ich posortowania by byly rysowane w kolejnosci od tych polozonych najdalej, do tych polozonych najblizej. Nie wiem jak exe robi to w tej chwili, nie zagladalem, ale jesli np kabina jest zrobiona na leniwca tzn oba submodele maja 'zakotwiczenie' w tym samym miejscu, to exe nie jest wrozka i w takiej sytuacji szansa, ze obiekty zostana ustawione w kolejnosci wlasciwej jest jak rzut moneta, czyli 50:50
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Maciej w 14 Czerwca 2017, 15:40:49
Czyli w jaki sposób można by rozwiązać problem podświetlenia tych haslerów? Bo tekstura podstawowa ma alfę (a jej brak spowodowałby, że na sceneriach nocnych ilość przejechanych kilometrów nie byłaby widoczna) i tekstura podświetlenia także.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 14 Czerwca 2017, 15:45:10
Nie bardzo rozumiem dlaczego tekstura podstawowa ma alfe, zamiast miec wycieta dziure tam gdzie jest miernik kilometrow. Pomijajac ten element, zobacze czy uda sie cos zrobic w exe zeby uporzadkowac tutaj zachowanie bez popsucia przy okazji czegos innego.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Maciej w 14 Czerwca 2017, 15:51:22
Na tej podstawowej teksturze alfa jest użyta do cyfr, co widać na screenie. Dzięki temu w nocy po zapaleniu oświetlenia, cyfry są podświetlone. Gdyby alfy nie było, cyfry byłyby ciemne i nie dałoby się ich odczytać (tak jest np. na ET21).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Czerwca 2017, 03:37:11
W dzisiejszym/wczorajszym uaktualnieniu:

- doprowadzona w wiekszosci do konca unifikacja sciezek renderowania, tzn zarowno wersja VBO jak i DL uzywa tego samego kodu. Efektem ubocznym jest drobny (~10%) spadek wydajnosci w trybie DL, i podobny wzrost wydajnosci w trybie VBO.  Wymiana nie jest calkowicie ukonczona, pozostaly:
-- wyrzucanie z pamieci nieuzywanych zasobow (sektorow ktore przejechalismy i nie sa juz wyswietlane itp) w zwiazku z czym tymczasowo moze miec miejsce wieksze zapotrzebowanie na pamiec
-- eksport modeli w formacie t3d do format binarnego e3d
-- optymalizacja danych terenu, konwersja binarnego modelu terenu do schematu niezaleznego od wspolrzednych 'geograficznych'

powyzsza wymiana, jesli wszystko poszlo dobrze, powinna byc niezauwazalna. Zeby wiec nie bylo calkiem nudno...

- usuniety zostal stary limit zasiegu rysowania -- do tej pory mimo 'mnoznika zasiegu' zakres widocznosci ograniczony byl "na sztywno" do okregu o promieniu 2km. Po usunieciu tego limitu teren i obiekty maja teoretyczny zasieg widzialnosci 7.5 km (z tym, ze uwzgledniane sa tez limity definiowane przez pliki .scn i pliki modeli; jesli model ma zdefiniowana widocznosc do 1km to przy maksymalnym mnozniku widzialny bedzie do 3km, nie 7.5)

- drobne poprawki w obsludze przezroczystosci przy wczytywaniu plikow e3d i t3d. powinny pomoc przy zgloszonych ostatnio bledach, ale rownie dobrze cos moglo sie przy okazji zepsuc co wyjdzie dopiero w praniu

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Sawi w 15 Czerwca 2017, 08:18:49
Potwierdzam na wersji z 14 czerwca problem z podświetleniem w SP45 mano i haslera nie występuje.
EDIT:
Jednak przy okazji coś się też zepsuło po drodze, bo np pantografy w zezie na torze doświadczalnym rozjeżdżają się na starcie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Maciej w 15 Czerwca 2017, 11:30:34
Łamanie patyków można sobie przecież wyłączyć. Po co wywalać z exe i cofać się z rozwojem. Odnośnie tego, co @Sawi pisze, to rzeczywiście na samym starcie patyki się łamią. Włączyłem sobie też jakąś siódemkę i tam również patyki się połamały. Przezroczystości działają poprawnie :).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Czerwca 2017, 12:51:47
Hmm to dziwne, mam u siebie w .ini wlaczone wszystkie ustawienia trakcji na "yes", i lamanie nie wystepuje. Czy moze ktos wkleic swoja konfiguracje .ini przy ktorej sie rozjezdzaja?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 15 Czerwca 2017, 13:08:27
Problem występuje gdy ładujesz na tym exe z t3d. Wygenerowałem e3d exekiem 520 z repo i nic się na nowym nie rozsypało.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Czerwca 2017, 14:36:42
O faktycznie, nie sprawdzalem z t3d wiec przoczylem. W dzisiejszym uaktualnieniu:

- poprawka ladowania modeli t3d. dosc eksperymentalna, wiec jest szansa ze oprocz naprawienia pantografow cos tam popsula, ale to wyjdzie w praniu
- przy okazji poprawka, teoretycznie powinna zmniejszyc/zlikwidowac okazjonalne miganie ekranow opartych na pythonie

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Sawi w 15 Czerwca 2017, 18:15:21
Jeszcze to nie to. Teraz dosłownie w w/w byku zezie pantografy wciąga do środka.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Maciej w 15 Czerwca 2017, 18:47:15
Pantografy działają prawidłowo, gdy wczytuje się je z t3d. Po wczytaniu z e3d wciąga je do środka (w sensie znika jakby część pantografu).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Czerwca 2017, 18:54:29
Wczytywanie zarowno .t3d jak i .e3d dziala u mnie na ostatniej wersji poprawnie. e3d jest z paczki calosciowej, byc moze to ktore macie u siebie bylo wygenerowane przez ktoras z wczesniejszych wersji c++ i nie jest zbudowane prawidlowo. Przyjrze sie przy przywracaniu eksportu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Maciej w 15 Czerwca 2017, 18:55:18
Ja mam e3d wygenerowane najnowszą wersją exe.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Czerwca 2017, 18:58:16
Najnowsza (615, rowniez 614) wersja exe nie generuje e3d, wiec jest to zwyczajnie niemozliwe :>
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Maciej w 15 Czerwca 2017, 19:01:41
Dobra, cofam. Przy convertmodels 0 wszystko działa jak należy, a po zmienieniu na convertmodels 135 powstaje ten błąd.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Czerwca 2017, 20:21:56
Przy wlaczonej konwersji faktycznie glupieje, bo konwersji chwilowo nie ma. Powinno sie wyprostowac w nastepnym uaktualnieniu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Sawi w 15 Czerwca 2017, 20:33:10
Dla jasności oczywiście dzieje się tak przy parametrze 135.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Czerwca 2017, 23:39:35
W dzisiejszym uaktualnieniu:

- przywrocony eksport do format binarnego e3d (oprocz modelu terenu, bo to przypadek specjalny i wymaga paru dodatkowych zmian) przy okazji powinny byc tez usuniete wczesniej zgloszone bledy animacji pantografow itp.

(nie wykluczam ze w eksporcie kryja sie jakies krzaki, bo cos za latwo poszlo. jak zwykle wyjdzie w praniu)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mareczek w 17 Czerwca 2017, 00:47:10
Chyba wina ostatniego exe, poznikały szkiełka z semaforów kształtowych. Parę dni temu było jeszcze wszystko ok.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 17 Czerwca 2017, 03:28:53
Na exe c++ szybka wczesniej byla wyswietlana bo exe ignorowalo dostarczone flagi, i traktowalo element jako polprzezroczysty na podstawie obecnosci alfy w teksturze... ale ta metoda prowadzila do blednego wyswietlania wskaznikow w kabinie SP45 pare stron do tylu. Wnioskujac z komentarzy w kodzie i z patch notes, dla polprzezroczystosci element powinien miec zarowno Opacity 0 jak i tektsure z alfa. I taka tez zmiana/poprawka zostala wprowadzona. Technicznie rzecz biorac, exe robi to, co mu "dyktuje" model t3d. Szybki pojawiaja sie, gdy w modelu .t3d zmienimy parametr Opacity dla ich submodeli do wartosci 0

Dowcip w tym, ze exe Borlandowe rowniez wyswietla szybki mimo "blednie" zdefiniowanego modelu .t3d z Opacity 100. Wie ktos moze, dlaczego?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mareczek w 17 Czerwca 2017, 13:28:37
Poprawiłem Opacity na 0, dalej nie ma szkiełek - np. models/pkp/sk12krat.t3d
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 17 Czerwca 2017, 13:54:00
tmj: może przyjdziesz na mattermosta? http://eu07.pl/forum/index.php/topic,28919.msg458144.html#msg458144
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 17 Czerwca 2017, 14:05:13
U mnie tez ten problem wystepuje. Brak szkiełek. To samo w tarczach ostrzegawczych i manewrowych. Wszedzie na kształtach brak szkiełek.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 17 Czerwca 2017, 14:39:55
Poprawiłem Opacity na 0, dalej nie ma szkiełek - np. models/pkp/sk12krat.t3d
Dziwne, u mnie po ustawieniu Opacity 0 pojawily sie. Nie masz przypadkiem ciagle w katalogu starego pliku .e3d? Jesli tak, to exe bedzie go ladowac, ignorujac poprawiony t3d.

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 17 Czerwca 2017, 15:01:42
Tylko górne szkiełko nie powinno być kwadratowe (zresztą widać że tektura przy górnym ramieniu wchodzi na drugie szkiełko).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 17 Czerwca 2017, 15:37:53
Szklo jest okragle. Kwadratowe jest pudelko zawieszone za przeslona :>

edit:
swoja droga, warto by chyba dodac cos takiego jak mozliwosc recznego wymuszenia renderowania obiektu zarowno w fazie przezroczystej jak i nieprzezroczystej, np definiujac Opacity 50
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 17 Czerwca 2017, 17:09:44
Jak kompiluje sobie exe 0612 to na DisplayList po wciśnięciu F12 mam crasha gdzieś w ntdll.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 17 Czerwca 2017, 17:28:21
Znaczy sie jak dasz F12 i quit, juz na wyjsciu? To mu sie czasem trafia bo watek pythona probuje pisac do logu a potem wychodzi zanim przekaze komunikat, ale ze to na wyjsciu jest to nie bylo specjalnie parcia zeby to poprawiac. Zdarza sie dosc losowo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 17 Czerwca 2017, 18:11:44
Nie, odpalam i daje F12 i w momencie naciśnięcia mam crasha.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 17 Czerwca 2017, 18:24:44
Jesli to jest przy uruchomieniu z VS, to F12 wymusza przerwanie, ale jesli przy zwyklym uruchomieniu to nie wiem, u mnie tego nie ma ;/
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 17 Czerwca 2017, 19:28:44
Z VS. Nawet nie wiedziałem, że tam jest przerwanie wymuszane.
Za to mam coś takiego, że startuję na Quarku w SM31 i cała sceneria jest ciemna. Daje Shift+Q odpala AI, odpala oświetlenie kabiny i cała sceneria się rozświetla. Na DL.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 17 Czerwca 2017, 22:23:22
Trzeba wszystkie ksztalty zaktualizowac z tym opacity.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 17 Czerwca 2017, 22:55:47
tmj: no to wrzucaj te zaktualizowane źródła
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 18 Czerwca 2017, 01:26:59
Poszlo; brakuje jeszcze paru rzeczy, ale w innych miejscach, nie powinno przeszkadzac przy shaderach

W dzisiejszym uaktualnieniu:

- eksperymentalnie uruchomiona obsluga parametru grubosci linii definiowanych w t3d/scn. Niektore obiekty/linie maja grubosc linii zdefiniowana dosc swobodnie, wiec moze sie zdarzyc ze teraz cos tam w scenie bedzie wygladac dziwnie, i wymagac poprawek.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 18 Czerwca 2017, 11:11:32
Na calkowie niezbyt fajny efekt linii wyszedł po tym uaktualnieniu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 18 Czerwca 2017, 14:45:26
Czy moze ktos wystawic cala ksztaltowke w t3d gdzies?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 18 Czerwca 2017, 19:13:09
Na calkowie niezbyt fajny efekt linii wyszedł po tym uaktualnieniu.
Poziome linie sa problematyczne, bo grubosc/przezroczystosc itp sa kalkulowana na podstawie pozycji punktu srodkowego odcinka. W dzisiejszym uaktualnieniu powinno to byc do pewnego stopnia poprawione, chociaz idealnie raczej nie bedzie. No i dodatkowo jest problem, ze do tej pory grubosc linii w sceneriach byla ustawiana "na slepo" wiec niektore moga byc zbyt grube teraz gdy szerokosc jest faktycznie wizualizowana.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mareczek w 18 Czerwca 2017, 19:28:22
To teraz zniknęły wszystkie drzewa. A przynajmniej w Całkowie v2 nie znalazłem ani jednego w Wilisiu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 18 Czerwca 2017, 19:58:47
No tak mi sie cos wydawalo ze na Calkowie v2 dziwnie lyso jest, i nie moglem dojsc czego brakuje :x

(drzewa i inne trojkaty rysowane przy uzyciu zwyklego alpha test zostaly przesuniete tam gdzie byc powinny, tzn do fazy rysowania obiektow nieprzezroczystych. Ale exe ma tez cos takiego, ze przy przypisanym modelu terenu pomija ladowanie nieprzezroczystych trojkatow... no i drzewa szly na drzewo. Eskperymentalnie wlaczylem ladowanie trojkatow nawet przy wstawionym modelu terenu, z tym ze potencjalnie moze to cos zepsuc gdzie indziej, co wyjdzie w testach)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 18 Czerwca 2017, 20:12:24
Ta blokada była głównie po to, by generowaniu binarnego terenu nie trzeba było komentować tekstowego, ale i tak się go komentuje chyba wszędzie. A czy będzie ładował czy nie. Kwestia posortowania includów w głównym scn.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 18 Czerwca 2017, 20:45:54
W praniu się skurczyło, na razie to w załączniku na DL. Całkowo 2, pierwsza misja.
ED:
Załącznik 71 to z poprawnym wyświetlaniem drzew.
Załącznik 72 z wygryzionym trójkątem.
Wszystkie drzewa na scenerii mają ten sam brak.
Błąd występuje na DL i na VBO
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 18 Czerwca 2017, 22:23:39
No niestety u siebie tego nie doswiadczam ;/   jesli znajdziesz jutro chwile, czy mozesz sprawdzic czy to wygryzienie wystepuje tez na wersji 615?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 18 Czerwca 2017, 23:06:06
Gdzie szukac tych drzew wygryzionych? U siebie nie widze. Calkowov2 pierwszy scenariusz.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 18 Czerwca 2017, 23:10:56
U @Krzyska sa wszedzie, jesli nie widzisz ich na starcie tzn ze tak jak i u mnie wyswietla sie u ciebie w porzadku. Czemu u Krzyska jest inaczej nie wiem, chociaz widzialem chyba u siebie podobna blad na innym obiekcie, wiec moze uda sie go wylapac.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 19 Czerwca 2017, 10:06:03
Pierwszy i drugi załącznik odpowiada jak kształtuje się geometria uszkodzonego drzewa. Jeśli zrobić oblot kamerą wokół pnia, to uszkodzenie zawsze pojawia się z lewej strony, zawsze w obu płaszczyznach i tylko na C++ od 20170615. Do tej paczki, z racji najczęstszego jej używania doinstalowywałem różne scenerie i inne dodatki. Ponieważ na innej paczce, z paczem na 2017 rok, błąd się nie pojawił porównałem pliki .inc tych konkretnych drzew. Co wyszło, widać w załączniku trzecim. U góry widzimy poprawnie działający .inc, na dole ten felerny. Ten felerny mam od 13 marca (od daty rozpakowania paczki, i widzę, że był modyfikowany 13 czerwca (niestety nie jestem teraz w stanie ustalić co było tego przyczyną). Nie wiem jeszcze czym. Mimo to pytanie jest takie, czemu na exekach z przed 15 czerwca plik ten nie powoduje komplikacji.

Teoretycznie plik ten nie wziął się znikąd, więc u kogoś powinien ten błąd z drzewkami się pojawić, jeśli nie dziś... to kto wie kiedy.
Podmiana na plik z innej paczki, na ten moment u mnie rozwiązała problem.
ED:
Plik został nadpisany po doinstalowaniu sceneri L546, śledztwo przyniosło efekt.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 19 Czerwca 2017, 10:57:23
Przyczyna odmiennego wyswietlania na 615 zmienionego .inc jest bledna obsluga triangle_strip w tej wersji -- standardowa wersja tree.inc uzywa "zwyklych" trojkatow ktore sa wyswietlane poprawnie, dlatego tez blad nie wystepuje przy standardowej konfiguracji.

Obsluga jest naprawiona w nastepnym uaktualnieniu, z tym ze poniewaz blad nie jest zbyt powazny publikacja bedzie troche pozniej, po dodaniu paru innych rzeczy ktore sa w praniu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 19 Czerwca 2017, 11:08:29
U mnie powoli prace do przodu. Tabelka w miarę działa, tylko są takie drobne problemy jak źle działająca jazda do tyłu ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 19 Czerwca 2017, 12:00:58
Śledztwo numer 2 - niepowodzenie.
Przerobiłem plik z drutami na to co poniżej. Użyłem // do usunięcia proponowanych wpisów. Przedstawiłem dwa pierwsze i dwa ostatnie line strip (plik jest zbyt długi i nudny do przedstawienia w całości).
node -1 0 line0_1 line_strip 0 0 0 8
48.4044 6.805 -228.035
48.51357 6.8069 -231.5699
48.62274 6.8088 -235.1048
48.73191 6.8107 -238.6397
48.84108 6.8126 -242.1746
48.95025 6.8145 -245.7095
49.05942 6.8164 -249.2444
49.16859 6.8183 -252.7793
49.27776 6.8202 -256.3142
49.38693 6.8221 -259.8491
49.4961 6.824 -263.384
//endline

//node -1 0 line0_2 line_strip 0 0 0 8
48.2564 6.756 -228.131
48.36497 6.7584 -231.6473
48.47354 6.7608 -235.1636
48.58211 6.7632 -238.6799
48.69068 6.7656 -242.1962
48.79925 6.768 -245.7125
48.90782 6.7704 -249.2288
49.01639 6.7728 -252.7451
49.12496 6.7752 -256.2614
49.23353 6.7776 -259.7777
49.3421 6.78 -263.294
//endline

............


//node -1 0 line1315_-3 line_strip 0 0 0 8
21020.33 6.739 18206.437
21024.1854 6.62573731061 18207.1858
21028.0408 6.52439360162 18207.9346
21031.8962 6.44572114061 18208.6834
21035.7516 6.39825297542 18209.4322
21039.607 6.38746766 18210.181
21043.4624 6.41525297542 18210.9298
21047.3178 6.47972114061 18211.6786
21051.1732 6.57539360162 18212.4274
21055.0286 6.69373731061 18213.1762
21058.884 6.824 18213.925
//endline

//node -1 0 line1315_-4 line_strip 0 0 0 8
21020.354 6.681 18206.293
21024.2096 6.58223007291 18207.0414
21028.0652 6.49409751543 18207.7898
21031.9208 6.42619843732 18208.5382
21035.7764 6.3861483544 18209.2866
21039.632 6.37883672882 18210.035
21043.4876 6.4059483544 18210.7834
21047.3432 6.46579843732 18211.5318
21051.1988 6.55349751543 18212.2802
21055.0544 6.66143007291 18213.0286
21058.91 6.78 18213.777
endline
Niestety nie przyniosło to żadnych pozytywnych skutków (załącznik). Brak wyświetlania drutów. Są jakieś pomysły, może coś źle zrozumiałem ze wczorajszej dyskusji?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Mariusz1970 w 19 Czerwca 2017, 12:12:45
Krzysiek, jest ok. Eksperyment mial na celu sprawdzenie tylko, czy line_strip ma limit, po przekroczeniu ktorego, wywala do windowsa. Kiedys taki limit byl. Wyswietlanie drutow (a w zasadzie jego brak) w tym ekperymencie, to inna para kaloszy. Reasumujac, tmj mial racje, ze limitu nie ma.
Dzieki Krzysiek za testy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 19 Czerwca 2017, 13:33:31
Z tego co widze duza liczba drutow w tym pliku ma wspolrzedne
21020.354 6.681 18206
Przy ladowaniu exe wylicza punkt centralny komorki na podstawie wspolrzednych geometrii ktora jest do niej wrzucana, i na tej podstawie przypisuje geometrie do sektora. W tym wypadku wiec cala paczka zostanie umieszczona w sektorze o wspolrzednych mniej wiecej [20000, 18000], i nie beda one widoczne dopoki kamera nie znajdzie sie w odleglosci 2-3 km od tego sektora. Musialbyc pofatygowac sie 'na piechote' w tamtym kierunku lub alternatywnie wstawic caly wpisy w klamre
origin -21000 0 -18200
...
endorigin
co powinno spowodowac przesuniecie drutow do sektora centralnego i po zaimportowaniu np do TD gdzie startujesz w okolicy punktu [0, 0] powinny byc widoczne.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 19 Czerwca 2017, 14:14:37
Wstawiony plik do TD spięty w klamrę pokazał się na scenerii, ale tylko w wersji niemodyfikowanej. Z wersji zakomentowanej drutów nie ma. Za to ciekawostką jest czemu niektóre części przęseł są "chude" a inne "grubsze"? "Grubość zależna jest od pozycji kamery.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 19 Czerwca 2017, 14:22:08
Grubosc przesla jest jednolita (tyle samo pikseli) na calej dlugosci, wiec uwzgledniajac perspektywe mozg interpretuje to jako zwiekszenie grubosci dla fragmentow polozonych dalej, zwlaszcza ze druty tam zbiegaja sie i to co wczesniej dosc wyraznie widac jako kilka indywidualnych przewodow zaczyna wygladac jak jeden grubszy kabel.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Balaclava w 21 Czerwca 2017, 20:41:52
U mnie jest coś skopane z rozjazdami. Chciałem przejechać sobie Kaliską (towar Ostrów -> Łódź) i towarowy1 na L61 od @Ra. W obu przypadkach zostałem skierowany na zły przebieg. Na Kaliskiej najechałem na tył osobowego, który stanął sobie na szlaku, na L61 dostałem wyjazd z Herbów, ale zamiast dostać przebieg na Stradom, to wypuściło mnie na południe. Wersja exe najnowsza, 32bit.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 21 Czerwca 2017, 23:48:55
Pamietasz moze troche dokladniej, gdzie mialo to miejsce na Kaliskiej? Ten scenariusz jest dosc dlugi, uruchomilem go u siebie, ale do Kalisza nic nadzwyczajnego sie nie wydarzylo. Czy ktos jeszcze doswiadczyl podobnej sytuacji? (albo nie doswiadczyl; u siebie do tej pory raczej nic takiego nie zauwazylem...)

W miedzyczasie, uaktualnienie:

- poprawka wyswietlania obiektow terenu zbudowanych z triangle_strip

- eksperymentalnie, wprowadzone laczenie trojkatow terenu w grupy o wspolnej teksturze/kolorze. w uproszczeniu, jest to odpowiednik generowania terenu .e3d, tylko nie zapisuje zadnego pliku, i dziala takze dla scenerii ktore z modelu terenu e3d nie korzystaja. Efekt jest dosc... interesujacy; dla przykladu:

Kaliska (start w kiblu), draw range x 3
- wersja 618: 60.0 FPS
- wersja 621: 96.5 FPS

Calkowo (niebezpieczny pociag) draw range x 3
- wersja 618: 90.5 FPS
- wersja 621: 175 FPS

na ile moge powiedziec nic sie przy rysowaniu tym razem nie zgubilo, ale jesli ktos zauwazy braki, prosze krzyczec.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 22 Czerwca 2017, 06:23:57
Co do L061, sceneria nie jest skonczona i sa problemy z przejezdnoscia. O tym informowalem w watku o paczu 2017. Na Kaliskiej nie mialem takich przygod, zwykle po skonczeniu jazdy ogladam calosc scenerii, czy wszystkie sklady dojechaly do celu. Tak czy owak, przejade sie tym skladem opisanym w poscie i dam znac co z tego wyniknelo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 22 Czerwca 2017, 07:49:40
Czyli robienie terenu w osobnych modelach przestało mieć teraz sens. No i dobrze.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Balaclava w 22 Czerwca 2017, 08:22:29
Na kaliskiej był to wyjazd z Ostrowa na podg. Stary Staw. Wydaje mi się, że droga była dobrze ułożona, ale tak jak mówiłem pasażerski zatrzymał się na szlaku i blokował wyjazd.

A na nowym exeku takie kwiatki dzieją się z nasypami z Rainsteda. One są eksportowane właśnie jako triangle-strip. Jednak nie (pomyliło mi się z szyciami poprzecznych), jest to zwykły node triangles, tylko ma więcej wierzchołków.
node -1 0 300 triangles material ambient: 104 104 104 diffuse: 208 208 208 specular: 146 146 146 endmaterial grass
-1047.29 223.365 -3533.733 -0.692 0.72 -0.061 -41.891611 141.349316 end
-1056.793 222.664 -3632.909 -0.692 0.72 -0.061 -42.271704 145.316343 end
-1057.535 221.941 -3632.807 -0.692 0.72 -0.061 -42.301413 145.312275 end
-1047.29 223.365 -3533.733 -0.704 0.708 -0.063 -41.891611 141.349316 end
-1057.535 221.941 -3632.807 -0.704 0.708 -0.063 -42.301413 145.312275 end
-1048.029 222.62 -3533.604 -0.704 0.708 -0.063 -41.921155 141.344164 end
-1048.029 222.62 -3533.604 -0.001 1 0.007 -41.921155 141.344164 end
-1057.535 221.941 -3632.807 -0.001 1 0.007 -42.301413 145.312275 end
-1057.932 221.941 -3632.753 -0.001 1 0.007 -42.317265 145.310103 end
-1048.029 222.62 -3533.604 -0.001 1 0.007 -41.921155 141.344164 end
-1057.932 221.941 -3632.753 -0.001 1 0.007 -42.317265 145.310103 end
-1048.423 222.62 -3533.535 -0.001 1 0.007 -41.936917 141.341415 end
-1048.423 222.62 -3533.535 0.552 0.832 0.059 -41.936917 141.341415 end
-1057.932 221.941 -3632.753 0.552 0.832 0.059 -42.317265 145.310103 end
-1058.675 222.441 -3632.651 0.552 0.832 0.059 -42.346987 145.30603 end
-1048.423 222.62 -3533.535 0.552 0.831 0.059 -41.936917 141.341415 end
-1058.675 222.441 -3632.651 0.552 0.831 0.059 -42.346987 145.30603 end
-1049.162 223.12 -3533.406 0.552 0.831 0.059 -41.966471 141.336259 end
-1049.162 223.12 -3533.406 -0.001 1 0.007 -41.966471 141.336259 end
-1058.675 222.441 -3632.651 -0.001 1 0.007 -42.346987 145.30603 end
-1059.665 222.441 -3632.515 -0.001 1 0.007 -42.386617 145.300599 end
-1049.162 223.12 -3533.406 -0.001 1 0.007 -41.966471 141.336259 end
-1059.665 222.441 -3632.515 -0.001 1 0.007 -42.386617 145.300599 end
-1050.147 223.12 -3533.235 -0.001 1 0.007 -42.005876 141.329386 end
-1050.147 223.12 -3533.235 0.552 0.832 0.059 -42.005876 141.329386 end
-1059.665 222.441 -3632.515 0.552 0.832 0.059 -42.386617 145.300599 end
-1066.012 226.711 -3631.645 0.552 0.832 0.059 -42.640484 145.265811 end
-1050.147 223.12 -3533.235 0.552 0.831 0.059 -42.005876 141.329386 end
-1066.012 226.711 -3631.645 0.552 0.831 0.059 -42.640484 145.265811 end
-1055.305 226.611 -3532.335 0.552 0.831 0.059 -42.2122 141.293395 end
-1055.305 226.611 -3532.335 0.000 1 -0.001 -42.2122 141.293395 end
-1066.012 226.711 -3631.645 0.000 1 -0.001 -42.640484 145.265811 end
-1087.269 226.711 -3628.732 0.000 1 -0.001 -43.490778 145.149291 end
-1055.305 226.611 -3532.335 0.000 1 -0.001 -42.2122 141.293395 end
-1087.269 226.711 -3628.732 0.000 1 -0.001 -43.490778 145.149291 end
-1062.65 226.611 -3531.054 0.000 1 -0.001 -42.506004 141.242145 end
-1062.65 226.611 -3531.054 -0.54 0.83 -0.137 -42.506004 141.242145 end
-1087.269 226.711 -3628.732 -0.54 0.83 -0.137 -43.490778 145.149291 end
-1090.183 224.75 -3628.333 -0.54 0.83 -0.137 -43.607329 145.13332 end
-1062.65 226.611 -3531.054 -0.539 0.831 -0.137 -42.506004 141.242145 end
-1090.183 224.75 -3628.333 -0.539 0.831 -0.137 -43.607329 145.13332 end
-1065.021 225.006 -3530.64 -0.539 0.831 -0.137 -42.600852 141.2256 end
-1065.021 225.006 -3530.64 0.000 1 0.003 -42.600852 141.2256 end
-1090.183 224.75 -3628.333 0.000 1 0.003 -43.607329 145.13332 end
-1091.174 224.75 -3628.197 0.000 1 0.003 -43.646958 145.127889 end
-1065.021 225.006 -3530.64 0.000 1 0.002 -42.600852 141.2256 end
-1091.174 224.75 -3628.197 0.000 1 0.002 -43.646958 145.127889 end
-1066.006 225.006 -3530.468 0.000 1 0.002 -42.640257 141.218726 end
-1066.006 225.006 -3530.468 -0.54 0.83 -0.137 -42.640257 141.218726 end
-1091.174 224.75 -3628.197 -0.54 0.83 -0.137 -43.646958 145.127889 end
-1091.917 224.25 -3628.095 -0.54 0.83 -0.137 -43.67668 145.123816 end
-1066.006 225.006 -3530.468 -0.539 0.831 -0.137 -42.640257 141.218726 end
-1091.917 224.25 -3628.095 -0.539 0.831 -0.137 -43.67668 145.123816 end
-1066.745 224.506 -3530.339 -0.539 0.831 -0.137 -42.66981 141.213571 end
-1066.745 224.506 -3530.339 0.000 1 0.003 -42.66981 141.213571 end
-1091.917 224.25 -3628.095 0.000 1 0.003 -43.67668 145.123816 end
-1092.313 224.25 -3628.041 0.000 1 0.003 -43.692532 145.121644 end
-1066.745 224.506 -3530.339 0.000 1 0.002 -42.66981 141.213571 end
-1092.313 224.25 -3628.041 0.000 1 0.002 -43.692532 145.121644 end
-1067.139 224.506 -3530.271 0.000 1 0.002 -42.685572 141.210822 end
-1067.139 224.506 -3530.271 0.674 0.717 0.176 -42.685572 141.210822 end
-1092.313 224.25 -3628.041 0.674 0.717 0.176 -43.692532 145.121644 end
-1093.056 224.974 -3627.939 0.674 0.717 0.176 -43.722246 145.117568 end
-1067.139 224.506 -3530.271 0.683 0.708 0.178 -42.685572 141.210822 end
-1093.056 224.974 -3627.939 0.683 0.708 0.178 -43.722246 145.117568 end
-1067.878 225.251 -3530.142 0.683 0.708 0.178 -42.715132 141.205664
endtri


Tu akurat brakuje całego nasypu, ale w niektórych miejscach obcina np. tylko zbocza wykopu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 22 Czerwca 2017, 13:27:50
Wrzucilem ten wpis na probe do TD, ale tutaj pojawia sie normalnie. Czy jest dostepna jakas sceneria, na ktorej pojawia sie to "w naturze"?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Balaclava w 22 Czerwca 2017, 13:39:00
Być może coś się mi w scenerii skaszaniło. Bo oglądałem na L61 u @Ra i wszystko w porządku tam jest.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 22 Czerwca 2017, 15:16:24
tmj: może przyjdziesz na mattermosta? http://eu07.pl/forum/index.php/topic,28919.msg458144.html#msg458144

Niereformowalny? :D
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 22 Czerwca 2017, 15:20:45
Na kaliskiej dojechałem do końca tym towarowym. Zresztą pospieszny dojeżdża bez problemu jak go uruchomię do samej kaliskiej jako AI. FPS poszybował w górę w niemożliwy do wyobrażenia sposób. Mam coś z lampkami SHP w ET22, dostały jakiś zieony kolor, ale muszę to jeszcze sprawdzić.
ED:
Mam takie pytanie, przy próbach skalowania tekstur do jakiejś tam wartości wyszło, że niektóre nie chcą się przeskalować. Taka tekstura nie wyświetla się. Przykład: W załączniku tekstura budynku dworca w Zduńskiej Woli, przy zaznaczeniu skalowania do 512 ta tekstura, przestaje się wyświetlać. Na Kaliskiej takich DDSów jest więcej. Nie sprawdzałem jak sprawa wygląda na TGA. Można to jakoś wyjaśnić, czy można to naprawić?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 22 Czerwca 2017, 18:23:13
Czyli robienie terenu w osobnych modelach przestało mieć teraz sens. No i dobrze.
Do pewnego stopnia teren jako model ciagle ma zalete duzo szybszego wczytywania, czyli nie jest tak calkiem bezuzyteczny. Z drugiej strony teren w formie modelu nie jest jeszcze dostosowany do nowego trybu renderowania, wiec w porownaniu z reszta moze nadal nieco migac.

Nie jestem pewien czy warto inwestowac w tym momencie w poprawki obslugi modelu terenu, bo docelowo po wprowadzeniu zapisu/ladowania calosc sceny bedzie obslugiwana w formie binarnej, niejako zastepujac ta opcje podejsciem "automatycznym" do tematu.

Niereformowalny? :D
Cytujac klasyka, "Nie lubie, nie lubie" :d

(zajrze pozniej ale raczej nie dzisiaj bo nie bardzo czas mam)

Mam takie pytanie, przy próbach skalowania tekstur do jakiejś tam wartości wyszło, że niektóre nie chcą się przeskalować. Taka tekstura nie wyświetla się. Przykład: W załączniku tekstura budynku dworca w Zduńskiej Woli, przy zaznaczeniu skalowania do 512 ta tekstura, przestaje się wyświetlać. Na Kaliskiej takich DDSów jest więcej. Nie sprawdzałem jak sprawa wygląda na TGA. Można to jakoś wyjaśnić, czy można to naprawić?
Wyjasnienie jest w logu :)

Texture size exceeds specified limits, skipping mipmap level
Texture "textures\stacje\dworzeczdunskawola.dds" has no mipmaps which can fit currently set texture size limits.

wyjasnienie: exe oczekuje, dosc optymistycznie, ze pliki .dds beda mialy wygenerowane mipmapy tzn mniejsze wersje tekstury uzywane przez karte graficzna w dalszej odleglosci. Dlatego tez przy ladowaniu nie skaluje tekstur .dds "recznie" ale po prostu odrzuca zbyt duze mip-mapy. Jesli wiec tekstura .dds nie ma mipmap, to po odrzuceniu zbyt duzego wariantu "glownego" nie zostaje nic.

Pliki .tga nie maja mipmap i skalowane sa "recznie", wiec dla nich ten efekt nie wystepuje.

Co do naprawy, wypadaloby gdyby wszystkie tekstury .dds mialy swoje kompletne mipmapy, ale podejrzewam ze raczej nikomu nie bedzie sie chcialo tego ogarnac ;/
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 22 Czerwca 2017, 18:30:38
Teraz jak ogarnąłem texturetoola, to można poświęcić te kilka godzin procesora i wygenerować wszystkie dds od zera. Kwestia wydania kaliskiej (czyli posortowania tematycznego nowych obiektów przed wrzutką na repo).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 23 Czerwca 2017, 08:36:43
Wrzucilem ten wpis na probe do TD, ale tutaj pojawia sie normalnie. Czy jest dostepna jakas sceneria, na ktorej pojawia sie to "w naturze"?
Ale to nie jest wpis tego samego terenu jak na zrzucie wyżej. Tamten ma cały nasyp, tutaj jest tylko podsypka toru.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 23 Czerwca 2017, 12:53:58
Na ile moge powiedziec to przekroj tego kawalka jest identyczny z tym, ktorego brakuje na zrzucie z ekranu. Tak czy owak skoro na scenerii "oficjalnej" of Ra jest w porzadku, dopoki nie wystapi gdzies lub u kogos jeszcze, zakladam ze to jakis krzak lokalny. Jesli sytuacja sie zmieni, mozna myslec o dokladniejszym rozgrzebaniu tematu :>

edit: w dzisiejszym uaktualnieniu

- wstepna wersja indywidualnego oswietlenia dla sekcji modelu uproszczonego wnetrza. Submodele z nazwami w formacie corridorXX lub korytarzXX (gdzie XX to liczba of 00 do 99, czyli np korytarz00) sa klasyfikowane jako korytarze/przedsionki. Submodele z nazwami w formacie compartmentXX lub przedzialXX sa klasyfikowane jako przedzialy. Oswietlenie w sekcji jest zalaczane gdy spelnione sa wszystkie ponizsze warunki:
-- na zewnatrz jest dostatecznie ciemno (definiowane jak dotychczas parametrem self illum)
-- pojazd jest w skladzie z pojazdem prowadzacym, ktory ma zalaczony akumulator (co jest uproszczona metoda sprawdzenia, czy pojazd prowadzacy jest aktywny)
-- dla przedzialow oswietlenie zalaczane jest z 75% szansa, okreslana w momencie spelnienia poprzednich warunkow, dla korytarzy oswietlenie zalaczane jest z szansa 100%

w praktyce oznacza to, ze wagony oswietlane sa (z drobnymi roznicami) tylko gdy znajduja sie w aktywnym skladzie, a po odstawieniu na bocznice swiatla sa gaszone. Na ta chwile jedyne wagony dostosowane do nowej funkcji to 11Xa_v2
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Sawi w 24 Czerwca 2017, 01:24:24
Nie zapominaj też o wagonach serii 16xa :).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 24 Czerwca 2017, 10:09:30
Tylko nowe 111a mają odpowiednie nazwy, bo były robione już jako królik doświadczalny pod ten ficzer. Reszta wagonów z wnętrzem to bezprzedziałówki, więc wystarczy im nazwać co trzeba jako korytarz.
TMJ, co robić z ludzikami? Jak ich przywiązywać do danego przedziału? Jako potomny działa? Czy nie ma jeszcze tego ficzeru? Po testach stwierdzam, że ładunek nie jest nijak obsługiwany póki co.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Sawi w 24 Czerwca 2017, 12:06:20
Chyba, że tak. W takim razie przepraszam za zamieszanie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 24 Czerwca 2017, 13:02:10
TMJ, co robić z ludzikami? Jak ich przywiązywać do danego przedziału? Jako potomny działa? Czy nie ma jeszcze tego ficzeru? Po testach stwierdzam, że ładunek nie jest nijak obsługiwany póki co.
No, jakby byl ladunek do 111 to by sie zrobilo, a tak to mi umknelo ;d Zastanawiam sie jak to zorganizowac zeby nie bylo zbyt trudno i dla autorow modeli i dla piszacych exe. Moze model ladunku podobnie podzielic na sekcje odpowiadajace nazwa pomieszczeniu, w ktorym sie znajduja? Czyli figurki w przedzial02 to submodel ladunku, z nazwa przedzial02, itp?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Sawi w 24 Czerwca 2017, 13:15:39
Ja bym to bardziej widział jako pasażerowie ponumerowani odpowiednim przedziałem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 24 Czerwca 2017, 13:27:40
Tylko figurek może być wiele do jednego przedziału i przez różne tekstury muszą mieć oddzielne siatki. Dałoby się zrobić by obiekt nadrzędny o kluczowej nazwie kontrolował wszystkie swoje potomne? Wtedy ta szybę klopa by się dało jako potomny korytarza a ludziki jako potomne przedziału.

Tak mi przeszło przez głowę, że można by myśleć o rozwinięciu t3d/e3d o material id, czy od razu o przywiązywanie wierzchołka do iluś kości (trzeba by poczytać jaki jest standard w silnikach) z wagą z myślą o animacjach. Tylko to by wymagało mózga od edytorów by skrypty dostosował. Wtedy by się wszystko dało jako jedną siatkę z multimateriałem i też konwersja z trainza/mstsa/omsi czy kto tam co chce by się drastycznie uprościła.

W końcu odważyłem się przetestować machajkę. Działa tak samo jak na borlandzie. :) Mega topornie i frajdy wiele nie daje, ale działa.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 24 Czerwca 2017, 13:58:01
Ja bym to bardziej widział jako pasażerowie ponumerowani odpowiednim przedziałem.
Nie bardzo rozumiem co to znaczy xD czy moglbys dac jakis prosty przyklad jak by to wygladalo w praktyce?

Tylko figurek może być wiele do jednego przedziału i przez różne tekstury muszą mieć oddzielne siatki. Dałoby się zrobić by obiekt nadrzędny o kluczowej nazwie kontrolował wszystkie swoje potomne? Wtedy ta szybę klopa by się dało jako potomny korytarza a ludziki jako potomne przedziału.
W sumie daloby sie, troche to skomplikuje obsluge ale nie powinno byc duzo wolniej. Z tym ze pasazerowie i tak beda chyba w osobnym modelu ladunku, a nie w 'glownym' low poly?

Cytuj
Tak mi przeszło przez głowę, że można by myśleć o rozwinięciu t3d/e3d o material id, czy od razu o przywiązywanie wierzchołka do iluś kości (trzeba by poczytać jaki jest standard w silnikach) z wagą z myślą o animacjach. Tylko to by wymagało mózga od edytorów by skrypty dostosował. Wtedy by się wszystko dało jako jedną siatkę z multimateriałem i też konwersja z trainza/mstsa/omsi czy kto tam co chce by się drastycznie uprościła.
Wprowadzenie materialow (w sensie "diffuse map", "diffuse + normal" itd) przyda sie po zaadoptowaniu shaderow, natomiast obsluga multimaterialow itp to raczej powinna byc robiona przez skrypt eksportujacy -- tzn na poziomie exe to i tak trzeba taka 'jedna siatke' rozbijac na submodele o wspolnej teksturze, kolorach itp jak dotychczas, i technicznie nic nie stoi na przeszkodzie by tego podzialu dokonywal wlasnie skrypt eksportujacy, w momencie eksportu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 24 Czerwca 2017, 14:32:40
Aha. Myślałem, że OGL to łyka, skoro jest powszechnie stosowane w grach. No to nie ma co, bo byłaby to sztuka dla sztuki.

Ludziki raczej zostawiamy jako ładunek. Były nim od zawsze, jeszcze przed jakąkolwiek wizualizacją.
Może by im też dać kluczowe nazwy i wyświetlać tylko pierwsze n, zależnie od zadanej ilości ładunku? Teraz ilość ludzi wpływa tylko na masę wagonu. Tu też rodzic musi kontrolować potomne, bo niektóre ludki maja włosy/gazetę w osobnym submodelu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mareczek w 25 Czerwca 2017, 18:30:26
W ET22 po podniesieniu pierwszego patyka (p), nie można go opuścić, niezależnie z której kabiny. Wpisane do zeszytu ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Sawi w 25 Czerwca 2017, 18:46:25
Tak wiem błąd znany i poprawiony w 201e i 201e_p. Poprawki ukażą się w patchu. Pozostały mi do poprawienia pozostałe byki.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: szogun w 25 Czerwca 2017, 19:21:29
Na ostatnim exe wywala mi błąd Open GL, brak pamięci, gdzie na 170603 ta sama sceneria działa bez zarzutu. Az tak się wymagania zmieniły?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 25 Czerwca 2017, 19:24:46
Do tej pory jeździłeś na Display List i nie wywalało?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Sawi w 25 Czerwca 2017, 19:28:26
Minimum z tego co czytałem to wersja 1.5 Open GL, a ty masz ile?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Czerwca 2017, 19:48:18
Na ostatnim exe wywala mi błąd Open GL, brak pamięci, gdzie na 170603 ta sama sceneria działa bez zarzutu. Az tak się wymagania zmieniły?
Jaki blad, taki moze?
openGL error: out of memory; failed to create a geometry buffer
jesli tak, to roznica polega raczej na tym, ze stare exe w ogole nie sprawdzalo czy taki blad wystapil i pchalo dane do karty bez wzgledu czy bylo tam miejsce czy nie. Stad braly sie miedzy innymi te dziwne rozjechane pojazdy na wiekszych sceneriach itp ktore sie czasami ludziom pokazywaly.

w dzisiejszym uaktualnieniu:

- oswietlenie przedzialow zaimplementowane w poprzednim release obejmuje teraz takze submodele przywiazane do danych przedzialow (czyli np jesli dla szyby wc jest ustawiony przedzial00 jako parent, to bedzie ona oswietlana, lub nie, razem z tym korytarzem) Oswietlenie jest rowniez przypisywane do elementow ladunku o tej samej nazwie, i przyczepionych do nich submodeli (oswietlenie ladunku jest 100% eksperymentalnie, bo nie mam na czym tego przetestowac)

- przywrocone/przepisane zwalnianie pamieci karty graficznej przez modele itp ktore nie sa wyswietlane przez jakis czas. Do pewnego stopnia moze pomoc przy bledach braku pamieci. Z drugiej strony byc moze pojawia sie z powodu takiego zonglowania zasobami bledy w wyswietlaniu, wiec jesli cos takiego wystapi, prosze zglaszac.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 25 Czerwca 2017, 19:57:22
Z cyklu niezbadane drogi w exe: po odpaleniu Całkowa_v2 na starcie mam pokaz klatek przy FPS rzędu 20 przy draw range x1.3, a jak nacisnę np. D to nagle exe odżywa i dolatuje do FPS rzędu 70 przy draw range x3.0. O co tu chodzi? Sprawdziłem exe++ 170603 i tam wszystko jest ok, na 170618 już nie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Czerwca 2017, 20:07:50
Tak jest na wszystkich exe, z Borlandowymi wlacznie -- z jakiegos powodu w niektorych sytuacjach symulacja na starcie jest wyjatkowo powolna dopoki nie przestawi sie nastawnika kierunku. Poniewaz wystepuje to tylko na starcie (bo kierunek ustawia sie dosc szybko) nie bylo do tej pory dostatecznego parcia na szklo by sprawdzic czemu wlasciwie tak sie dzieje :>
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 25 Czerwca 2017, 20:13:27
Lata temu trzeba było zatrąbić, żeby fpsy podskoczyły
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 25 Czerwca 2017, 20:17:13
Sprawdziłem z ciekawości i faktycznie taki efekt jest też na exe 170603, tyle że teraz nabrał mocy. Na exe 170603 na starcie mam 45 FPS, więc potem wzrost FPS jest niezauważalny. Na exe 170625 na starcie jest jednak już tylko 15-20 FPS, co jest już mocno widoczne.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Czerwca 2017, 22:08:35
Lata temu trzeba było zatrąbić, żeby fpsy podskoczyły
Dziala dalej :>  wyglada na to ze 'odtyka sie' po odtworzeniu jakiegos dzwieku, czyli byc moze tam nalezaloby zajrzec.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 26 Czerwca 2017, 06:59:28
Nie jestem pewien ale chyba znalazłem ciekawy błąd, który powoduje, że pojazd nie zawsze zajmuje tor pierwszym wózkiem. Jest to związane z ustawianiem flagi iAxleFirst w DynObj przy wstawianiu obróconych pojazdów. Może ktoś sprawdzić?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: MR6 w 26 Czerwca 2017, 11:20:34
Podczas pauzy przy próbie wejscia kamerą do kabiny z kamery zewnętrznej przenosi na pod wózki, jak wyłączymy pauze kamera wraca do kabiny. Da się to poprawic?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 26 Czerwca 2017, 11:23:45
A jaka lokomotywa? Jadę właśnie na kaliskiej ET42 i nic takiego nie zauważyłem (teraz sprawdziłem), EXE z wczoraj.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: MR6 w 26 Czerwca 2017, 11:26:54
Ep07,eu07, najnowsze exe.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Szperacz w 26 Czerwca 2017, 11:37:24
Potwierdzam, na pauzie ląduje się pod lokomotywą przy próbie powrotu do wewnętrznej kamery (choć to trzeciorzędny problem).

Również slow motion na starcie (na kompie-smoku); do tej pory czekałem minutę-dwie aż wróci do poziomu 60 fps myśląc, że to sceneria się ładuje (albo co). Spróbuję zatrąbić :)

I potwierdzam piękną poprawę fpsów przy którymś z poprzednich exe (na całkowie 2 potrafiło spaść do 40, teraz jest 60 z vsyncem na 4k + solidne AA).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mk1991 w 26 Czerwca 2017, 11:48:19
Witam. Ja zauważyłem coś innego. Od kiedy pojawiła się możliwość rozdzielenia trąbek na dwa osobne klawisze blokuje się dźwięk syreny pod kiedy jesteśmy zmuszeni zaraz po podaniu RP1 użyć piasecznicy. Dźwięk można zatrzymać ponownie wciskając s. Druga rzecz, nie wszędzie powinna być uruchomiona opcja rozdzielonej syreny. Z tego co wiem, to taka możliwość na pewno występuje na jednostkach EN57, EN71, ED72. Na lokomotywach EU07, ET22 i innych mamy wajchę, która coś takiego uniemożliwia. Uważam, że dobrze by było rozdzielić to jakoś, na przykład w pliku .fiz danego pojazdu w sekcji switches. Jeszcze jedno. W lokomotywie EP09 niema czegoś takiego jak kurek truj drogowy, więc opcja przestawiania tego kurka powinna być nieaktywna.
Pozdrawiam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Czerwca 2017, 13:51:34
Witam. Ja zauważyłem coś innego. Od kiedy pojawiła się możliwość rozdzielenia trąbek na dwa osobne klawisze blokuje się dźwięk syreny pod kiedy jesteśmy zmuszeni zaraz po podaniu RP1 użyć piasecznicy. Dźwięk można zatrzymać ponownie wciskając s. Druga rzecz, nie wszędzie powinna być uruchomiona opcja rozdzielonej syreny. Z tego co wiem, to taka możliwość na pewno występuje na jednostkach EN57, EN71, ED72. Na lokomotywach EU07, ET22 i innych mamy wajchę, która coś takiego uniemożliwia. Uważam, że dobrze by było rozdzielić to jakoś, na przykład w pliku .fiz danego pojazdu w sekcji switches. Jeszcze jedno. W lokomotywie EP09 niema czegoś takiego jak kurek truj drogowy, więc opcja przestawiania tego kurka powinna być nieaktywna.
Blokowanie dzwieku ma miejsce ze wzgledu na to, jak system operacyjny przekazuje wcisniecia i zwolnienie klawiszy do aplikacji, miedzy innymi dlatego poprzednio bylo tutaj stosowane wymuszone wylaczenie jednego dzwieku przy aktywacji drugiego. Na ta chwile nie ma mozliwosci definiowania elementow wyposazenia takich jak typ przelacznika dzwieku, lub obecnosc zaworu trojdrogowego. Po wprowadzeniu ich bedzie mozna pomyslec o lepszym dopasowaniu konfiguracji do konkretnych typow pojazdow.

W dzisiejszym uaktualnieniu:

- poprawka, eksportowanie modeli do format e3d nie powinno sie juz rozsypywac w przypadku wystapienia w modelu nieprawidlowych trojkatow

- pseudo-poprawka, symulator powinien (w wiekszosci przypadkow) pracowac od poczatku z normalna predkoscia

- w ramach dyskusji w watku o wymianie ekranow ladowania, oprocz dotychczasowych ekranow z kwadratowych tekstur symulator przyjmuje takze ekrany nieprostokatne. Ekrany skalowane sa do wysokosci okna program, widocznosc (lub nie) bocznych krawedzi zalezy od stosunku proporcji ilustracji do proporcji okna symulatora.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: MR6 w 26 Czerwca 2017, 14:14:03
Tmj a ta kamera na pauzie?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Czerwca 2017, 14:26:57
Nie ruszalem na razie, bo to jest raczej trzeciorzedny problem (bierze sie z tego ze ruch kamery w kabinie jest realizowany ze stalym krokiem, by utrzymac ten sam poziom rzucania kamera niezaleznie od FPS, i przy wlaczonej pauzie aktualizacja pozycji kamery nie nastepuje) Zrobie gdy mnie to dostatecznie zirytuje, albo nie bedzie nic pilniejszego na talerzu :d
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 26 Czerwca 2017, 14:35:28
Przejechałem kilkakrotnie Kaliską na dwóch komputerach, także Bałtyk na 625. Wniosek jest taki, że pamięć jest poprawnie wykorzystywana i brak już jest z tego tytułu wysypów. Brawo. Co ciekawe, bo tu usiadłem ze zdumienia, na intelu I5 12Gb ram i NV720 z WIN10, Kaliska wczytała się w ciągu 2,5 minuty.
Created texture object for "dynamic\pkp\en57_v1\dioda_on.dds"
Loading texture data from "dynamic\pkp\en57_v1\dioda_on.dds"
Finished loading 3d model data from "dynamic\pkp\en57_v1\kabina_en57iia.e3d"
Player train init OK Load time: 148 seconds
EVENT LAUNCHED: onstart_kibel_bor_losuj Multiple passed
EVENT ADDED TO QUEUE: losuj_kibel_bor Eventlauncher cegielski_wjazd_dozwk
EVENT ADDED TO QUEUE: cegielski_wjazd_zwk
Opisywany laptop posiada także kartę zintegrowaną intela, bez problemu obsługuje symulator z nieco niższym FPS niż na NV720.
Wracając do PCeta, na WINXP32 bez problemu ukończyłem Kaliską i nie miałem żadnych kłopotów z wyświetlaniem elementów scenerii (VBO) Tu ciekawostka, bo na żadnym z komputerów nie miałem zaniżonego FPS na starcie symulacji. Może zależy to od lokalnych warunków sprzętowych. Wzrost FPS jest, ale tu trzeba stwierdzić także płynność działania, co nie zawsze miało miejsce nawet przy jego bardzo wysokim poziomie.
Kamera na pauzie, to dość normalna przypadłość. Skoro to pauza to F4 nie powinien działać, prawda? Ale skoro wysadza nas z kabiny to przy powrocie do niej lądujemy na szynach, bo skoro pauza to exe nie pracuje i nie policzy prawidłowej pozycji kamery.
Potwierdzam tą przypadłość. Pytanie czy przy pauzie powinniśmy być wysadzani z kabiny?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Czerwca 2017, 15:36:22
Co ciekawe, bo tu usiadłem ze zdumienia, na intelu I5 12Gb ram i NV720 z WIN10, Kaliska wczytała się w ciągu 2,5 minuty.
Ale to w sensie ze zle czy dobrze :o  bo u mnie Kaliska wczytuje sie 90-120 sekund, w zaleznosci czy to start "na zimno" czy kolejne wczytanie.

Przy wyjsciu z kabiny przez F4 przestawienie kamery na zewnatrz dziala, bo jest obslugiwane przez inna czesc kodu. Tutaj akurat imo jest to korzystne, bo czesto pauza jest wykorzystywana podczas chodzenia po scenerii, i to chyba nie powinno byc blokowane.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 26 Czerwca 2017, 16:19:32
Oczywiście wydźwięk mojej wypowiedzi należy odebrać pozytywnie. Na stacjonarnym ma czas około 330 sec, co daje 6,5 minuty. Jeśli zaś chodzi o pauzę, to oczywiście nie należy blokować chodzenia po scenerii, raczej miałem na myśli, że to taka uroda symulatora i należy się z tym pogodzić. Lądowanie pod lokiem jakkolwiek dziwne to na symulację wpływu nie ma. Jeśli uda się kamerę usadzić na fotelu, tylko przyklasnę. Jeśli nie, nie będę płakać.
PS, zrobię restart kompa, przy czym wyjmę połowę pamięci, ciekawe czy exe się wysypie po wczytaniu kaliskiej?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 26 Czerwca 2017, 20:22:20
Odpalam sobie Kaliską, ładnie się wczytuje, ujeżdżam z rozbiegu (bo tak zdefiniowany jest skład na początku) kilka metrów i regularnie jest wysypka. Co tu się stało? :P

Obalam mit o braku wysypów, ha!
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Czerwca 2017, 20:48:24
Sprawdz jesli mozesz errors.txt  Wysyp spowodowal niezidentyfikowany dynamic w lokacji (-83594, 0.4, 19460) ktoremu z jakiegos powodu brakowalo modelu 3d, co jest wydarzeniem ktore exe --przyznaje, nadmiernie optymistycznie-- zaklada nie powinno sie przytrafic :d
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 26 Czerwca 2017, 20:52:03
Oj tam, przejechałem kolejny raz. Teraz zostawiłem tylko 2Gb pamięci ram i ukończyłem jazdę pospiesznym z Ostrowa do Łodzi, po drodze nie napotykając nic dziwnego. Wyjęcie pamięci natomiast spowodowało przedłużenie czasu ładowania z 330 do po nad 700 sekund ładowania scenerii i 10% spadek FPS. W załączniku log z jazdy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 26 Czerwca 2017, 20:58:19
Sprawdz jesli mozesz errors.txt  Wysyp spowodowal niezidentyfikowany dynamic w lokacji (-83594, 0.4, 19460) ktoremu z jakiegos powodu brakowalo modelu 3d, co jest wydarzeniem ktore exe --przyznaje, nadmiernie optymistycznie-- zaklada nie powinno sie przytrafic :d

Z taboru braknie mu jedynie ładunków (i pasażerów) oraz paru submodeli.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 26 Czerwca 2017, 21:02:28
Dołożę i swój errors, tymi ładunkami troszkę zdziwiony jestem, wydaje mi się, że tego nie było. Wygląda jakby exe wołało modelu nawet w przypadku cystern, co przecież nie jest możliwe. Ale ja się nie znam i wymądrzam.
Dopiszę że jechałem bez skalowania tekstur 8192 i jestem z tego faktu bardzo zadowolony.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Czerwca 2017, 21:10:50
No ten brak modelu znikad sie nie wzial, wiec cos tam jest nie tak, chociaz byc moze nie laduje w logu. Masz tam moze wpis o braku animations? Zwyczajnie moze brakowac calego pliku .mmd co jest wydarzeniem ktore z jakiegos powodu nie bylo uwazane za dosc istotne by je umiescic w zgloszeniach bledow.

edit:
Animations tag is missing from the .mmd file "dynamic\pkp\et41_v1\203e-a.mmd"
Animations tag is missing from the .mmd file "dynamic\pkp\et41_v1\203e-b.mmd"
sprawdz czy .mmd dla et41 czasem nie poszly sobie na przechadzke.

Oj tam, przejechałem kolejny raz. Teraz zostawiłem tylko 2Gb pamięci ram i ukończyłem jazdę pospiesznym z Ostrowa do Łodzi, po drodze nie napotykając nic dziwnego. Wyjęcie pamięci natomiast spowodowało przedłużenie czasu ładowania z 330 do po nad 700 sekund ładowania scenerii i 10% spadek FPS. W załączniku log z jazdy.
To juz zakrawa na znecanie sie nad exe :>  przyznam ze jestem zaskoczony, Kaliska sama w sobie po zaladowaniu zajmuje kolo 2 gb  Manager pamieci wirtualnej musial sie tam troche napocic.

edit 2:
Dołożę i swój errors, tymi ładunkami troszkę zdziwiony jestem, wydaje mi się, że tego nie było. Wygląda jakby exe wołało modelu nawet w przypadku cystern, co przecież nie jest możliwe. Ale ja się nie znam i wymądrzam.
To dlatego ze exe jest glupie i zawsze probuje zaladowac potencjalny model zdefiniowanego dla danego pojazdu ladunku. Idea, ze jakis konkretny ladunek jest plynem w srodku zamknietej cysterny to cos nie na jego maly mozdzek ;o
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 26 Czerwca 2017, 21:18:24
MMD są na miejscu. Świeże z repozytorium.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 26 Czerwca 2017, 21:22:13
No właśnie, z repozytorium. Ja mam stare. Ostatnio na repo były wgrywane porządkowane mmd, nie ma gwarancji, że coś się nie rozjechało. Jutro odpoczynek od testów, więc nie będzie znęcenia, ale to tylko przerwa na oddech.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 26 Czerwca 2017, 21:23:16
A pobierz sobie to jedno (robiąc kopie starego rzecz jasna) i odpal Kaliską 72162.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Czerwca 2017, 21:32:10
MMD są na miejscu. Świeże z repozytorium.
Na 100% cos jest nie tak z odczytem tych .mmd, bo gdyby exe te pliki znajdowalo, nie pojawilby sie zapis o braku animations ktore w tym .mmd przeciez sa jak wol i tam gdzie trzeba.

(w nastepnym uaktualnieniu bedzie troche rozbudowana diagnostyka pod tym wzgledem, a brak modelu bedzie ignorowany zamiast powodowac wysyp)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 26 Czerwca 2017, 21:33:40
Pobrałem z repo mmd, odpalam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Sawi w 26 Czerwca 2017, 21:40:05
Ciekawe bo podobny przypadek:
http://eu07.pl/forum/index.php/topic,29175.msg459357.html#msg459357
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Czerwca 2017, 21:45:02
Tutaj akurat jest podobny objaw, ale przyczyna nieco inna :>   Technicznie rzecz biorac ten blad z zalozenia zglaszany jest gdy w pliku .mmd nie wystapila definicja ilosci animacji w modelu. W tym konkretnym wypadku definicja nie wystapila chyba dlatego ze exe w ogole nie udalo sie zaladowac .mmd (i tym samym nie ma tez definicji modelu pudla, wnetrza itp a nie tylko wpisu animations) Czyli w "normalnych" warunkach ten blad moze wyskoczyc takze gdy .mmd wystepuje --najczesciej przy starych .mmd ktore tego wpisu miec nie musialy-- i efekt nie jest wtedy tak drastyczny.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 26 Czerwca 2017, 21:54:18
Na mmd tych z repozytorium, wysypało mi Kaliską. Trzeba to zerknąć na jakiejś innej scenerii, konkretnie z tym lokiem.
Errors w załączniku 1 z kaliskiej.
ED:
Sprawdziłem na TD wysyp za każdym razem po wstawieniu ET41-092, w załączniku errors i log z TD.
Wysyp jest tylko na nowych plikach mmd z repo.
PS, nie wina exe. To na ten moment jest niezatapialne.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 26 Czerwca 2017, 22:13:08
Mmd były w utf8. Przeformatowałem na ansi i et41_v1 się na TD wczytało bez problemu na exe 626. Kusi mnie cofka tych zmian mmd. Trzeba Piotra zagonić do sprawdzenia formatu każdego z plików teraz. :/
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Czerwca 2017, 22:14:10
Wrzucilem u siebie i sie wyjasnilo. Ktos zapisal plik w formacie utf-8, programem ktory zaznacza ten tryb kodowania specjalnym znakiem BOM na poczatku pliku (znacznik jest o ile dobrze pamietam opcjonalny) Rezultat jest taki ze exe nie rozpoznaje wpisu "models:" i pomija cala ta sekcje.

Poprawka "na szybko" to zapisac plik .mmd np Notatnikiem z kodowaniem ustawionym na ANSI, lub dodac na poczatku pusta linie albo chocby spacje.

edit: Stele byl szybszy
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 26 Czerwca 2017, 22:24:09
To doszliśmy do tego wszyscy w jednym czasie :P Ważne, że się wyjaśniło.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 27 Czerwca 2017, 03:18:42
Dorzucilem na wszelki wypadek do exe rozpoznawanie tagu models: "wzbogaconego" o BOM utf8. Jesli sama zawartosc pliku jest w zwyklym ascii to powinno wystarczyc, a odpadnie koniecznosc sprawdzania i/lub poprawiania x plikow.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 27 Czerwca 2017, 06:55:34
Mnie  to całe utf wkurza. Np. w pythonie masz możliwość wymuszenia otwarcia pliku w utf, ale co z tego jeśli z tekstu nie są usuwane znaczniki utf i musisz właśnie uwzględniać je tak ja tutaj.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Piotr93 w 27 Czerwca 2017, 08:05:03
Mmd były w utf8. Przeformatowałem na ansi i et41_v1 się na TD wczytało bez problemu na exe 626. Kusi mnie cofka tych zmian mmd. Trzeba Piotra zagonić do sprawdzenia formatu każdego z plików teraz. :/
Już zabieram się do roboty, sprawdzę każde mmd i zapiszę ponownie do ansi. Pliki mmd które są w teście od dźwięków Krystiana już są naprawione i mają prawidłowe kodowanie. W ciągu dnia powinieneś mieć naprawione wszystkie mmd. Edit, @Krzysiek kazał się wstrzymać, gdyż mam poczekać na decyzję @tmj. Więc czekam, jeżeli nie to poprawię kodowanie, dla mnie to nie problem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 27 Czerwca 2017, 09:15:15
Prosiłem o powstrzymanie się, bo jeśli można uniknąć jakiejś roboty, to czemu nie? Takie hurtowe poprawki należy robić w tandemie. Jedna osoba poprawia, a druga na bieżąco sprawdza na TD po jednej sztuce pojazdu. Od ręki wyszłoby że coś jest nie tak.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 27 Czerwca 2017, 10:38:04
Milek wczoraj sprawdził automatem i oprócz et41_v1 znalazł tylko człon b et41_v2, więc zakładami, że reszta jest dobrze. A jak exe będzie to łykać, to już kompletnie nie ma sprawy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Piotr93 w 27 Czerwca 2017, 11:11:53
Jeżeli tak to ok. Czekam na decyzję jak będzie wszystko dobrze to jak mówisz Antek to zostawiamy, bo u mnie mam sam te mmd, ale nie sprawdzałem ET41 ale inne pojazdy normalnie jeździłem na exe z patcha.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Mariusz1970 w 27 Czerwca 2017, 14:51:36
Moim zdaniem lepiej aby UTF byl tylko w wyjatkach a nie stal sie regula albo dowolna dowolnoscia. Dobrze, ze exe to przelknie, ale nie zapominajmy o narzedziach moich i nie tylko moich jak rowniez ewentualnych czyis przyszlych. Nie wiem jak one sie zachowaja (np. wyciagnij_pliki.exe - ono tez czyta *.mmd). Firlej napisal, ze cos tam z pytonem sie miesza. Ogolnie starajmy sie trzymac jednego. Nawiasem mowiac, na chacie juz pisalem, iz do hurtowych zmian, reczna robota sie nie nadaje.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Balaclava w 28 Czerwca 2017, 18:11:17
Może to tylko złudzenie, ale wydaje mi się że na nowym exe łuki są bardziej kanciaste.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Tomnord15 w 28 Czerwca 2017, 18:27:52
To nie jest złudzenie. Od razu zauważyłem to po przejściu na exe C++.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Czerwca 2017, 19:15:26
Minimalna dlugosc segmentu toru jest ograniczona do co najmniej 2 metrow, ale to nie jest jakas specjalna nowosc, uzywana jest chyba od paru miesiecy. O ile dobrze pamietam, w kodzie generujacym geometrie toru sa tez podobno jakies bledy ktore Ra poprawil u siebie, a ktore powoduja ze tor jest w jakims tam stopniu skrzywiony, mozliwe ze rzuca sie to w oczy bardziej przy mniejszej ilosci segmentow.

Z innej beczki, w dzisiejszym uaktualnieniu:

- poprawka, exe nie wysypuje sie przy braku modelu 3d dla pojazdu (pojazdy bez modeli nie sa jednak w 100% sprawne, bo np lokomotywy elektryczne musza miec model pudla z animowanymi pantografami zeby sie podpiac do sieci i gdziekolwiek pojechac)

- minimalnie ulepszona obsluga plikow .mmd w formacie utf8 (i tylko .mmd, inne pliki konfiguracyjne w formacie utf8 potencjalnie dalej moga sprawiac problemy)

- eksperymentalne, aktywowana obsluga parametru sily odblaskow swiatla (specular highlights) dla modeli 3d. Temat dosc skomplikowany, wiec tutaj kilka uwag:
-- poniewaz parametr poprzednio obslugiwany nie byl, wiekszosc modeli ma go ustawiony na cos w stylu (150, 150, 150) wartosc ta jest zazwyczaj zbyt wysoka dla materialow innych niz takie, ktore swiatlo odbijaja doskonale (szyby, wypolerowany metal)  W zwiazku z tym domyslnie exe modyfikuje podana wartosc parametru specular do 25% wartosci dla geometrii nieprzezroczystej, i 150% podanej wartosci dla geometrii polprzezroczystej, ktora w zalozeniu powinny byc wylacznie szyby itp. Mechanizm skalowania kontrolowany jest wpisem w ini
scalespeculars (yes)/no
Docelowo modele powinny miec prawidlowo dobrane i zdefiniowane wartosci parametru, i przelacznik skalowania bedzie mozna usunac. Realistycznie mniej wiecej tak na swietej Nigdy.
-- obsluga odblaskow to dodatkowa praca dla karty graficznej, dlatego zeby nie przesadzac na ten moment wlaczona jest tylko dla pojazdow. W wersji shaderowej zapewne bedzie jej mozna uzywac dla wszystkich obiektow, tak jak jest to robione w wersji @Milka7
-- kalkulacja odblaskow jest wyjatkowo wrazliwa na obecnosc wektorow normalnych o dlugosci innej niz jednostkowa, a takich wektorow jest w obecnych modelach mnostwo, glownie za sprawa skalowania w macierzach transformacji sub-modeli. Exe radzi sobie z tym wymuszajac na openGL gdzie trzeba przeliczenie dlugosci wektorow normalnych, ale dla lepszej wydajnosci nalezaloby raczej poprawic modele. Dla zachety napotkane w modelach bledy tej natury sa umieszczane w logu
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 28 Czerwca 2017, 20:18:43
Marnie to wygląda bez fragment shadera. Widać geometrię, jakby nie liczył dobrze normalnych na podstawie grup wygładzania.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 28 Czerwca 2017, 20:25:51
możesz to pchnąć na githuba?
i chodź na mattermosta
dochodzę do końca z mergowaniem zmian, więc dziś/jutro powinno być nowe shaderowe exe.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 28 Czerwca 2017, 21:03:51
Efekty dość ciekawe, w ciągu całego dnia oświetlenie ładnie rozkłada się po powierzchni odbijając część światła. Skrajnie wygląda przekomicznie (załącznik). Efekt zależny od kąta patrzenia na płaszczyznę, największy przy obserwacji pod kątem prostym. Jeśli jedyna forma doprowadzenia tego do stanu tiptop jest edycja t3d, to czas zacząć robić nowe modele. Edycja starych to tak do 2031r.  Mógłbym ze względu na posiadany czas przerobić jedną siódemkę, ale nie mam pojęcia co wpisać w miejsce edytowanych parametrów.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 28 Czerwca 2017, 21:11:05
Trzeba zacząć od ustalenia wartości dla różnych materiałów (pewnie jest gdzieś gotowiec w sieci), a potem napisać i puścić automat ustawiający wszystko na dość niskie. Specular albo jest ustawiony na 150 (domyślne z 3ds maxa) albo na 255 (tak jak diffuse). Proszę też o mnożnik wyprowadzony do ini, bo z mnożnikami po stronie exe, nigdy tego nie ustawimy z sensem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Czerwca 2017, 21:34:24
Efekty dość ciekawe, w ciągu całego dnia oświetlenie ładnie rozkłada się po powierzchni odbijając część światła. Skrajnie wygląda przekomicznie (załącznik).
Hmm, dales przypadkiem do opcji scalespeculars no ? Bez tego ustawienia u mnie wyglada to zdecydowanie mniej drastycznie (w zalaczniku efekt 'maksymalny')

Marnie to wygląda bez fragment shadera. Widać geometrię, jakby nie liczył dobrze normalnych na podstawie grup wygładzania.
Jakosc normalnych zalezy w duzej mierze od jakosci modelu zrodlowego, a z tymi bywa roznie. Jesli w logu pojawia sie wpisy w stylu
Bad model: non-unit normal vector(s) encountered during sub-model geometry deserialization
Bad model: transformation matrix for sub-model (..)
to mozna spodziewac sie wszystkiego.

Nie widze specjalnie sensu wyprowadzania mnoznika do ini -- mnoznik jest tylko proteza by to, co jest w starych modelach wygladalo w miare sensownie. Wartosci dla nowych powinny byc dopasowywane z mnoznikiem wylaczonym, czyli w trybie scalespeculars no w ktorym exe wyswietla to co dostaje, bez skalowania.

(zrodla poszly do gita)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 28 Czerwca 2017, 21:46:33
A, czyli już jest. O to scalespeculars no właśnie mi chodziło. Nie przeczytałem ze zrozumieniem.
Masakra ze skalowaniem będzie. Walczę z tym od dawna, ale bez bardziej zautomatyzowanego toola niż rainsted sobie nie wyobrażam tego.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Sawi w 28 Czerwca 2017, 21:51:04
Widzę dochodzimy już do pewnego etapu, że prowizorki zaczynają przeszkadzać i dobrze. Jedyne co przeraża to kolejne poprawki, ale to było pewne iż się tego nie uniknie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 28 Czerwca 2017, 23:17:48
@tmj, przekleilem caly wpis do ini tak jak go podales. Nie zrozumialem jak mozna regulowac nim sile tego efektu. Natomiast nie sprawdzilem jak zachowuje sie oswietlenie bez tego wpisu. Efekt jest silnie zalezny od polozenia zrodla swiatla, malo bylo czasu na eksperymenty. CDN.
Ps: Mam w glowie poukladane, ze szadery spodziewamy sie od @Milek7, czy to sie nie bedzie gryzlo? Druga sprawa, parametry specular (moze takze inne) juz dawaly znac o sobie w exekach z fixedpipeline. Czy dobrze rozumiem ze z szaderami moze byc podobnie?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Czerwca 2017, 23:36:47
Moja wina, podalem ten parametr w takiej formie ze latwo sie pomylic. Wpis moze byc
scalespeculars yes
co jest wartoscia domyslna i powoduje skalowanie rozblyskow, albo
scalespeculars no
co skalowanie wylacza. Jesli wkleiles calosc to exe nie rozpoznalo parametru, co zwyczajowo traktowane jest jako "no" (zazwyczaj ma to sens, ale moze nie w tym konkretnym przypadku, przynajmniej dopoki domyslne jest ustawienie przeciwne :d

exe Milka ma ten sam efekt, tylko zrobiony na shaderach czyli ladniej, wiec tez powinno skorzystac na ogarnieciu tego parametru w modelach.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 28 Czerwca 2017, 23:44:53
No i tak probowalem, wklejenie samego yes nic na poczatku nie dalo, mialem zle ustawiona kamere i zrodlo swiatla w samo poludnie. Oblecialem sklad i nic. Dopiero jak wkleilem calosc linijki, i przesunalem sloneczko, zatrybilo. Zadnej winy nie widze, nie widze tez w logu wpisanych Waszych nickow, a to juz jak najbardziej odpowiednia pora.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 29 Czerwca 2017, 00:10:18
Witam.
 U mnie również na początku wyszły kwiatki, czyli totalne przepalenie oświetlanych słońcem powierzchni. Jednak po dodaniu wpisu "yes" w linijkę komendy "scalespeculars" zaczęło wszystko w miarę sensownie wyglądać. Rzeczywiście shadery bardzo pomogą tu wizualnie, ale jednocześnie do pełni szczęścia przydałyby się chyba aktywne cienie, gdyż obecnie jak się nie mylę, exe odbija światło również od obiektów pozostających naturalnie w miejscach zacienionych, jak chociażby osie wagonów, kwadratowe zresztą. I trochę razi ten rząd prostokątów połyskujących pod składem. Ale generalnie efekt jest pozytywny.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 29 Czerwca 2017, 00:21:20
I trochę razi ten rząd prostokątów połyskujących pod składem.
Jesli prostokaty o ktorych mowa to sztuczne cienie, to exe probuje je rozpoznac po nazwie -- jesli submodel ma nazwe "cien" to rozblyski dla niego ustawiane sa na 0.  Zapewne nie wylapie to niestety wszystkich modeli, ale na szybko nie przyszedl mi do glowy lepszy i w miare prosty sposob jak je rozpoznac

(byc moze po nazwie tekstury jesli wszystkie pojazdy uzywaja tej samej? Nie sprawdzilem tego)

Co do cieni dynamicznych to wprowadzane zmiany krok po kroku przyblizaja nas do mozliwosci ich zaimplementowania, chociaz w przypadku exe standardowego nie ma specjalnie gwarancji ze uda sie je uruchomic, a jesli juz to szalu raczej nie bedzie. Natomiast z exe shaderowym, kto wie, tutaj moze byc calkiem niezle.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: pol102 w 29 Czerwca 2017, 02:01:54
Trzeba zacząć od ustalenia wartości dla różnych materiałów (pewnie jest gdzieś gotowiec w sieci), a potem napisać i puścić automat ustawiający wszystko na dość niskie. Specular albo jest ustawiony na 150 (domyślne z 3ds maxa) albo na 255 (tak jak diffuse). Proszę też o mnożnik wyprowadzony do ini, bo z mnożnikami po stronie exe, nigdy tego nie ustawimy z sensem.
O tym mowa:
https://seblagarde.wordpress.com/2012/04/30/dontnod-specular-and-glossiness-chart/
?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 29 Czerwca 2017, 07:02:41
Znalazłem miłego bug-a:
Ground.cpp, linijka koło 211. InitNormals. glm::normalize nie sprawdza czy przypadkiem nie próbuje znormalizować zerowego wektora. Jeśli mu się taki trafi to crash.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 29 Czerwca 2017, 07:10:00
A jeszcze odnośnie specular: to chyba lepiej by było trzymać to w materiale, a nie w modelu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 29 Czerwca 2017, 07:27:07
Jest nieźle, całkowite odbicie jakie udało mi się uzyskać jest do przyjęcia (załącznik). Zobaczymy czy w praniu nie wyjdą jakieś śmiesznie poustawiane modele.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 29 Czerwca 2017, 13:00:51
A jeszcze odnośnie specular: to chyba lepiej by było trzymać to w materiale, a nie w modelu.
No na ten moment praktycznie cala definicja materialu (oprocz ew. tekstury dla replacable) jest wszyta w t3d do definicji danego submodelu, wiec to wychodzi na jedno. Specular jest trzymany w tym samym miejscu gdzie diffuse, emission, self-illum itp.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 29 Czerwca 2017, 14:27:17
Zmergowałem moje shaderowe exe ze zmianami tmj.
Póki co mgła jest na sztywno ustawiona w kodzie i nie reaguje na ustawienia w scenerii. Do tej pory używana była mgła liniowa która jest dosyć nierealistyczna, więc proponuję żeby zmienić na mgłę w rodzaju e^odległość*gęstość. Obecnie właśnie tak jest zaimplementowany shader. Dodatkowo w prosty sposób udawany jest efekt rozpraszania światła, jeżeli słońce jest nisko nad horyzontem to mgła jest barwiona na kolor światła.

do pobrania stąd: https://ci.appveyor.com/project/Milek7/maszyna/build/artifacts
należy pobrać również shaders.zip i wypakować do katalogu shaders
oprócz standardowych bibliotek (https://milek7.pl/.stuff/eu07exe/libs32.zip https://milek7.pl/.stuff/eu07exe/libs64.zip) potrzebny jest też runtime MSVC2017.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 29 Czerwca 2017, 15:55:47
Póki co mgła jest na sztywno ustawiona w kodzie i nie reaguje na ustawienia w scenerii. Do tej pory używana była mgła liniowa która jest dosyć nierealistyczna, więc proponuję żeby zmienić na mgłę w rodzaju e^odległość*gęstość.
Z mgla liniowa pozegnalismy sie juz dawno temu :> Uzywany jest standardowy tryb mgly dla 'starego' openGL, GL_EXP:
f = e^-(density * z)
czyli chyba akurat to samo, co stosuje shader.

(gestosc mgly dopasowywana jest do gornego zakresu definiowanego przez scenerie, domyslnie 2 km)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 29 Czerwca 2017, 18:09:12
Milek7, po pobraniu exe i shaderow odpalilem TD. Bardzo slaba smuga, oswietla tylko slupy trakcji i czesc semaforow. Dziwne jest to, ze napisales o ptrzebie VC 2017, czego nie mam, a exek uruchomil sie. Pytanie do Ciebie, czy przejechales jakas dluzsza scenerie? Proba na kaliskiej skonczyla sie wywaleniem do windowsa, czego juz dawno nie doswiadczylem. Plik errors okazal sie taki ciezki, ze nie dal sie otworzyc i potrzebny byl reset kompa, bo nawet nie mozna bylo uruchomic menedzera zadan. Do momentu wywalenia exeka, mialem dziwne oswietlenie roslinnosci. Wiecej napisze jak uda sie ustalic co jest w errors.
ED:
W załączniku dodaje plik errors.
Bad model: transformation matrix for sub-model "Knob" imposes geometry scaling (factor: 0.84)
Bad model: transformation matrix for sub-model "zbijacz" imposes geometry scaling (factor: 0.84)
Bad model: transformation matrix for sub-model "styczniki" imposes geometry scaling (factor: 0.84)
Bad model: transformation matrix for sub-model "sw-hamulec" imposes geometry scaling (factor: 1.05)
Bad model: transformation matrix for sub-model "Bocznik" imposes geometry scaling (factor: 0.84)
Bad model: transformation matrix for sub-model "nawrotnik" imposes geometry scaling (factor: 0.84)
Bad model: transformation matrix for sub-model "zasadniczy" imposes geometry scaling (factor: 0.84)
Odpalenie Kaliskiej za każdym razem powoduje, że prędzej czy później zostaje mi tylko twardy reset. Spróbuje jeszcze jakiś Bałtyk i na dziś kończy się cierpliwość.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 29 Czerwca 2017, 19:19:39
Miałem w ini ustawione skalowanie tekstur do 1024. Wysypało z alokacją pamięci w logu przy pierwszej teksturze bez mipmapy.
Usunąłem skalowanie i się uruchomiło.
Po załadowaniu symulacji w logu "openGL error: out of memory; failed to create a geometry buffer". Na TD, więc nawet na moim złomie powinno mu wystarczyć. Wyświetliło się jednak względnie dobrze. Jedyne co zauważyłem, to brak przewodów sieci trakcyjnej.
A, i log się wygenerował pusty, ale tak miałem ostatnio i na exe tmj.
Światło mam takie samo jak K626. Widać stożek na ziemi, ale z kabiny oświetlenie torów jest tak mikre, że mogłoby go nie być.
Coś w kręceniu słońcem się zepsuło. Nigdy nie robi się naprawdę ciemno a o drugiej w nocy pojawia się jutrzenka. Dzień polarny prawie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 29 Czerwca 2017, 19:30:22
Chwila jazdy na TD Około 15 minut i załącznik jak wygląda oświetlenie toru. Wydłużone ładowanie i spadek FPS. Dodatkowo w załączniku log i errors z TD. Jak dotąd nie udało się uruchomić Bałtyku. Doinstalowałem VC2017
ED:
Odpaliłem Kaliską, ale nie dojechałem do końca. W errors i logu pojawiły się tysiącami takie linijki:
Bad model: transformation matrix for sub-model "fspot02" imposes geometry scaling (factor: -1.00)
Bad model: transformation matrix for sub-model "fspot01" imposes geometry scaling (factor: -1.00)
Bad model: transformation matrix for sub-model "wspornik" imposes geometry scaling (factor: -1.00)
Bad model: transformation matrix for sub-model "fspot02" imposes geometry scaling (factor: -1.00)
I dalej w tym stylu:
Bad geometry (shape estimation failed) for spline "" at 16109.200000 0.000000 720.860000
Bad geometry (shape estimation failed) for spline "str07" at 16109.200000 0.000000 720.860000
Bad geometry (shape estimation failed) for spline "sr08" at -24578.900000 2.549000 -4299.200000
Bad geometry (shape estimation failed) for spline "sr08" at -24578.900000 2.549000 -4299.200000
Bad geometry (shape estimation failed) for spline "" at -23742.900000 0.000000 -4620.000000
Bad geometry (shape estimation failed) for spline "" at -23742.900000 0.000000 -4620.000000
Bad geometry (shape estimation failed) for spline "" at 27883.300000 0.000000 -6652.300000
Bad geometry (shape estimation failed) for spline "" at 27883.300000 0.000000 -6652.300000
Bad geometry (shape estimation failed) for spline "str02" at 28360.000000 0.000000 -6025.000000
Bad geometry (shape estimation failed) for spline "str02" at 28360.000000 0.000000 -6025.000000
Bad geometry (shape estimation failed) for spline "str03" at 29555.100000 0.000000 -3157.500000
Bad geometry (shape estimation failed) for spline "" at 29565.100000 0.000000 -3156.300000
Bad geometry (shape estimation failed) for spline "str05" at 22778.200000 0.000000 -5417.500000
Bad geometry (shape estimation failed) for spline "" at 22778.200000 0.000000 -5407.500000
Bad geometry (shape estimation failed) for spline "" at 17147.600000 0.000000 322.890000
Bad geometry (shape estimation failed) for spline "str06" at 17147.600000 0.000000 322.890000
Bad geometry (shape estimation failed) for spline "" at 16109.200000 0.000000 720.860000
Bad geometry (shape estimation failed) for spline "str07" at 16109.200000 0.000000 720.860000
Dojechałem zaledwie do Bolszewic i ja zobaczyłem co się dzieje w konsoli, to wyszedłem z symulacji. Jedna wcześnie wyłapałem jeszcze dwa błędy, w byku nie mam świateł, tylko jakieś freespoty (załącznik) i oświetlenie terenu jest jakby to napisać - nierealne. O 0.30 niby całkiem ciemno a światło rozstrzelone są na lewo i prawo po okolicznej roślinności. Brak oświetlenia podsypki i terenu (załącznik) Gigabajtowych errors i logów nie ma co wklejać.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 29 Czerwca 2017, 21:14:49
A ja głupieję. Testuje exe 0628 i idzie. Biorę wrzucam pliki 1:1 na moje repo, kompiluje i mam crasha przy InitNormals. Narzucam mój projekt na repo tmj, nie mogę skompilować. Wziąć się pochlastać.
Udało się skompilować na tmj. Idzie na release, na debug się sypie. Już nie mam siły, żeby szukać dlaczego.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 29 Czerwca 2017, 21:33:42
:o moze cos nie tak z plikami w /ref? U siebie mam glm w wersji 0.9.8.3 chociaz chyba nie powinno to robic roznicy.

edit: wrzucilem caly ref tutaj: http://eu07.pl/userfiles/24014/priv-ref.7z  Zobacz czy uda ci sie skompilowac moja wersje jak wrzucisz to do foldera ze zrodlami/projektem.

edit2: debug ma dodane asserty, wiec pewnie wylatuje na nich. jak dasz mu break to powinien podac co mu nie pasuje :>
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 29 Czerwca 2017, 21:47:08
Bałtyk uruchamiam bez problemu na 170628, natomiast na ostatnim NG mam tak jak w załączniku, ciekawie kończy się log.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 29 Czerwca 2017, 22:35:02
Witam.
Uruchomiłem próbnie na exe Milka TD ze składem EN57. Cóż tak jak pisał Krzysiek, oświetlenie nijakie. Zauważyłem że smuga nie nasila się wraz z włączaniem kolejnych reflektorów. Być może tu tkwi problem. Poza tym martwy hasler, oraz manometry. FPS na poziomie 87 kl/s. Zaraz spróbuje uruchomić coś cięższego...
Pozdrawiam.
Edit: Próba uruchomienia L053-day TLK, zakończona wyrzuceniem do windy, w logu jak i errors taki oto ostatni wpis:
Cytuj
Critical error, memory allocation failure: bad allocation
W załączniku log.txt, oraz plik errors
Edit 2:
Udało się uruchomić Zwierzyniec SM42, niestety symulacja zawiesiła się po wykonaniu manewrów. Nie otrzymałem wyjazdu...
 Próba uruchomienia Bałtyku zakończona po wczytaniu scenerii zamrożeniem obrazu. Tak samo w przypadku Kaliskiej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 30 Czerwca 2017, 06:59:29
Ja mam glm 0.9.8.4. Wyrzuca gdyż debug ma ustawioną flagę fp:except. A wyrzuca błąd floating point exceptions. Poprawiłem to w kodzie po prostu i teraz chodzi na obu wersjach.
Gorzej, że na mojej wersji wywala mi na assercie ttrack == nullptr przy czym ttrack nie jest null i to jest dziwne. Ale to było na wersji 0626, a nie sprawdzałem jeszcze na zmergowanej 0628.

Co do normalizacji to użyłem czegoś takiego:
auto c = glm::cross(v1,v2);
n1 = glm::length(c) != 0 ? glm::normalize(c) : glm::vec3()
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 30 Czerwca 2017, 07:46:49
Ponieważ nie udało się uruchomić scenerii Bałtyk, to w załączniku przedstawiam porównanie końcówki logów z uruchamiania tej scenerii na obydwu ostatnich C++NG. Wykonanie porównanie nie jest łatwe ze względu na nazwy plików exe. Te nie są zróżnicowane i trzeba ręcznie edytować ich wersje dla trzymania w głównym katalogu, szkoda bo to Milku7 szalenie ułatwia wykonanie porównań a Tobie nie powinno sprawić trudności przypisanie unikalnej nazwy pliku. Dodatkowy fakt, to brak spakowania exeka co utrudnia również pewne czynności związane z dystrybucją, ściąganiem z sieci i t.p. czynnością. Nie jest to może wielki problem natury technicznej, bardziej porządkowy. Jednakże ważny, bo exe się sypie i nie da się tego użytkować. Ważny bo czynności do wykonania porównań, jak również archiwizacja przyprawia o dodatkowe trudności i stres. Tym niemniej wykonałem porównanie C++NG z dnia 27 kwietnia i C++NG z dnia 29 czerwca i wyszło jak w załączniku. Po lewej mamy exe z 29-06 po prawej exe z 27-04. Wynika z tego, że log urywa się a wczytywanie wysypuje na ostatniej Twojej kompilacji. Tu nie jestem w stanie interpretować logu.
Dodatkowy stres wprowadzają linijki:
Bad model: transformation matrix for sub-model "Fspot02" imposes geometry scaling (factor: 3.63)
Bad model: transformation matrix for sub-model "mocowanie2" imposes geometry scaling (factor: 0.93)
Bad model: transformation matrix for sub-model "mocowanie1" imposes geometry scaling (factor: 0.93)
Bad model: transformation matrix for sub-model "mocowanie2" imposes geometry scaling (factor: 0.90)
Bad model: transformation matrix for sub-model "mocowanie1" imposes geometry scaling (factor: 0.90)
Bad model: transformation matrix for sub-model "mocowanie2" imposes geometry scaling (factor: 0.90)
Bad model: transformation matrix for sub-model "mocowanie1" imposes geometry scaling (factor: 0.90)
Powyższe zgłaszają przynajmniej 3 osoby z Windowsem.  Poniższe przynajmniej 2
Bad geometry (shape estimation failed) for spline "str07" at 16109.200000 0.000000 720.860000
Bad geometry (shape estimation failed) for spline "sr08" at -24578.900000 2.549000 -4299.200000
Bad geometry (shape estimation failed) for spline "sr08" at -24578.900000 2.549000 -4299.200000
Bad geometry (shape estimation failed) for spline "" at -23742.900000 0.000000 -4620.000000
Zgłaszałem to jeszcze w poprzednim wydaniu NG.
Piszesz, że u Ciebie tego nie ma, ok a co z nami? Stres dla testującego, bo jest ich tysiące i przede wszystkim stres dla sprzętu.
Ten błąd u @CXManiak:
Critical error, memory allocation failure: bad allocation
Nie powinien wystąpić, bo @tmj poprawił wczytywanie danych do pamięci. i u mnie na jego exe, przestał być problemem.
Bałtyk sypie się zarówno w DL jak i na VBO.

Propozycja.
1. Czy jest możliwość podesłania źródeł @Milkek7 do kolego @tmj i wykonanie przez niego kompilacji?
Dotyczy także źródeł pisanych przez @firlejczyka, skoro i tu pojawiły się jakieś problemy.

2. Po uruchomieniu Bałtyku program próbuje wykonać jakąś czynność na której jest wysyp. Zauważalnym brakiem na starcie Bałtyku jest brak odtworzenia komunikatu spikera, proszę o sprawdzenie poprawności wykonania eventów dźwiękowych w środowisku Windows.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 30 Czerwca 2017, 09:59:15
Krzyśku, ja wykryłem błąd, który występuje także u tmj, ale tylko w wersjach debug. W wersjach release, które idą do testów ogólnych, ten błąd się nie ujawni ze względu na ustawienia kompilatora. Gdyby nie takie ustawienie już dawno ten błąd by został wykryty.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: pol102 w 30 Czerwca 2017, 11:31:23
Cytuj
Zgłaszałem to jeszcze w poprzednim wydaniu NG.
Piszesz, że u Ciebie tego nie ma, ok a co z nami? Stres dla testującego, bo jest ich tysiące i przede wszystkim stres dla sprzętu.


Cytuj
Standardowa odpowiedź administratora (SOA) – grupa wyrażeń będących najczęstszymi reakcjami administratorów na zgłaszane im problemy.

Najczęściej używanym i najszerzej rozumianym skrótem jest SOA #1, czyli Standardowa Odpowiedź Administratora nr 1: „u mnie działa”[1]. Ma znaczenie pejoratywne, ale i żartobliwe. Wyraża niechęć administratora do podjęcia naprawy[2] oraz sugestię, że problem leży po stronie użytkownika lub wynika z jego błędu.

Jakieś podobieństwo?
Zwroty SOA są najczęściej używane na forach dyskusyjnych, grupach dyskusyjnych oraz kanałach IRC, głównie o tematyce informatycznej, a także na serwerach gier i głosowych (jak np. TeamSpeak 3).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 30 Czerwca 2017, 11:45:04
Piszesz, że u Ciebie tego nie ma, ok a co z nami?
No nie wiem, bo jak nie występuje u mnie to nie bardzo mam pomysł jak to naprawić. Jakieś crashdumpy się może generują?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 30 Czerwca 2017, 12:29:18
Na windows xp crashdumpy nie chcą się generować. Przed chwilą na Kaliskiej miałem:
.....ciach
Bad geometry (shape estimation failed) for spline "str05" at 22778.200000 0.000000 -5417.500000
Bad geometry (shape estimation failed) for spline "" at 17147.600000 0.000000 322.890000
Bad geometry (shape estimation failed) for spline "str06" at 17147.600000 0.000000 322.890000
Bad geometry (shape estimation failed) for spline "" at 16109.200000 0.000000 720.860000
Bad geometry (shape estimation failed) for spline "str07" at 16109.200000 0.000000 720.860000
Critical error, memory allocation failure: bad allocation
Jesli mergowanie było z ostatnim exe @tmj, to na tym ostatnim exe nie wychodziło już do windowsa, nawet po pozostawieniu tylko 2GB pamięci ram na płycie głównej. Musiało się coś popsuć przy dopisaniu oświetlenia, lub nie były to ostatnie źródła.
Wcześniej miałem ciekawostkę w postaci UFO na Drawinowie (załącznik). Ta kula jest za każdym odpaleniem scenerii obojętne czy na VBO, czy na DL. Scenariusz Drawinowa na którym to występuje, to jazda ET22-256 (trzecia od góry w okienku rainsted).
Dodatkowo muszę napisać, iż przyczyną występowania strumienia światła podążającego za kamerą były biblioteki shaderów. Po podmianie ten strumień występuje lub nie, na starszym i na ostatnim C++NG.
Za chwilę przeloguje się na 64 bitowy system i sprawdzę jak to jest na win7.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 30 Czerwca 2017, 13:34:25
Dodatkowy stres wprowadzają linijki:
Bad model: transformation matrix for sub-model "Fspot02" imposes geometry scaling (factor: 3.63)
Bad model: transformation matrix for sub-model "mocowanie2" imposes geometry scaling (factor: 0.93)
Bad model: transformation matrix for sub-model "mocowanie1" imposes geometry scaling (factor: 0.93)
Bad model: transformation matrix for sub-model "mocowanie2" imposes geometry scaling (factor: 0.90)
Bad model: transformation matrix for sub-model "mocowanie1" imposes geometry scaling (factor: 0.90)
Bad model: transformation matrix for sub-model "mocowanie2" imposes geometry scaling (factor: 0.90)
Bad model: transformation matrix for sub-model "mocowanie1" imposes geometry scaling (factor: 0.90)
Te komunikaty wystepuja rowniez na "zwyklym" exe, jest to informacja ze dany model 3d ma w swoich transformacjach skalowanie elementow, ktore moze negatywnie wplynac na kalkulacje oswietlenia specular. W zalozeniu powinny wywolywac stress tylko u autorow modeli, zachecajac ich do wprowadzenia poprawek ;>

Natomiast "Bad geometry (shape estimation failed)" wystepujace w duzych ilosciach to juz roznica w zachowaniu, i raczej nie powinny wystepowac. Cos tam moze byc nie tak przy procedurze dzielenia krzywych na segmenty, lub pobocznych.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 30 Czerwca 2017, 13:57:44
Te komunikaty wystepuja rowniez na "zwyklym" exe, jest to informacja ze dany model 3d ma w swoich transformacjach skalowanie elementow, ktore moze negatywnie wplynac na kalkulacje oswietlenia specular. W zalozeniu powinny wywolywac stress tylko u autorow modeli, zachecajac ich do wprowadzenia poprawek ;>
Co jest chyba zbędnym ostrzeżeniem w shaderowym exe, bo normalne mnożą sie przez glm::mat3(glm::transpose(glm::inverse(modelview)))
Wywalę to przy następnym buildzie
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 30 Czerwca 2017, 14:05:26
Mnozenie przez inverse nie pomoze niestety przy wszystkich przypadkach, bo czesc submodeli uzywa niejednolitego skalowania (inverse ma poprawny efekt tylko gdy wektor jest skalowany tak samo wzdluz wszystkich osi)  Trzeba robic pelne normalize() a to niestety kosztuje :<
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 30 Czerwca 2017, 14:21:11
hmm, czyli ten opis jest błędny? http://www.lighthouse3d.com/tutorials/glsl-12-tutorial/the-normal-matrix/
To się robi tylko raz na submodel więc myślę że wydajność nie powinna być bardzo zła, ale później porównam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 30 Czerwca 2017, 14:38:25
Tymczasem na windows 7 mam odwrotną sytuację. Exe C++NG 64bity uruchamia Bałtyk! Za to nie chce uruchomić Kaliskiej, całość się wczytuje do końca, ale niestety po kilku sekundach następuje wysyp. Tutaj mam niejaki sukces, bo w tym przypadku zapisuje się crashdump (w załączniku 2 takie pliki, do porównania czy przyczyna jest ta sama). Także w wersji 64 bitowej na Drawinowie mam niezidentyfikowaną kulę co pokazałem kilka postów wcześniej w załączniku.
Tak jak w przypadku x86 i tu nie musiałem instalować vc 2017, exe dało się uruchomić i przejechałem cały Bałtyk. Instalacja VC 2017 jednak przeprowadziłem, mimo to wysyp z kaliską. Zostało na x64 systemie, przetestować paczkę testowaną na x86. Chętnie poznam co ciekawego jest w załącznikach.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 30 Czerwca 2017, 14:58:29
hmm, czyli ten opis jest błędny? http://www.lighthouse3d.com/tutorials/glsl-12-tutorial/the-normal-matrix/
To się robi tylko raz na submodel więc myślę że wydajność nie powinna być bardzo zła, ale później porównam.
aa nie przyjrzalem sie dokladniej, zobaczylem inverse( modelview ) i wydalo mi sie, ze tam sie robi to samo co przy GL_RESCALE_NORMAL :o  nie, w tej postaci powinno byc ok.

edit: aha, jesli chodzi o oswietlenie w nocy, to warto pamietac ze "taki mamy klimat", a dokladniej, to o tej porze roku slonce wylazi juz ok. 3-ej nad ranem i juz krotko po polnocy zaczyna szarzec. Mam to samo za oknem jak posiedze w nocy troche dluzej :>  Do testowania oswietlenia bardziej ciemnej nocy trzeba podac bardziej odpowiedni wpis dla parametry movelight w .ini i/lub scenerii.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 30 Czerwca 2017, 15:04:02
Tymczasem na windows 7 mam odwrotną sytuację. Exe C++NG 64bity uruchamia Bałtyk! Za to nie chce uruchomić Kaliskiej, całość się wczytuje do końca, ale niestety po kilku sekundach następuje wysyp. Tutaj mam niejaki sukces, bo w tym przypadku zapisuje się crashdump (w załączniku 2 takie pliki, do porównania czy przyczyna jest ta sama). Także w wersji 64 bitowej na Drawinowie mam niezidentyfikowaną kulę co pokazałem kilka postów wcześniej w załączniku.
Tak jak w przypadku x86 i tu nie musiałem instalować vc 2017, exe dało się uruchomić i przejechałem cały Bałtyk. Instalacja VC 2017 jednak przeprowadziłem, mimo to wysyp z kaliską. Zostało na x64 systemie, przetestować paczkę testowaną na x86. Chętnie poznam co ciekawego jest w załącznikach.
Wysyp w sterowniku opengl. No nic, jak się pozbędę brzydkich połączeń starego opengl z nowym to może przejdzie, bo teraz to ciężko znaleźć co to konkretnie powoduje.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 30 Czerwca 2017, 15:10:14
Zwroc uwage ze sterownik chodzi sobie w osobnym watku, w VS warto wtedy przerzucic recznie debugger na "Main Thread", pomaga wylapac co mniej wiecej moze to powodowac. No chyba ze juz to robisz a i tak ciezko znalezc.

edit: z ciekawostek, wersja shaderowa na td chodzi u mnie ~15% szybciej niz zwykla :>

edit2: co do mizernego oswietlenia torow itp, sprawdz czy jest prawidlowo uwzgledniany skladnik ambient reflektorow -- tory w symulatorze maja nieciekawie ustawiane wektory normalne, i w rezultacie lapia w zasadzie tylko ambient.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 30 Czerwca 2017, 17:33:53
Witam.
  @Tmj, jeżeli chodzi o oświetlenie torów w exe NG++, to wygląda to tak że zapalanie kolejnych reflektorów nic nie daje. Generują tyle samo światła bez różnicy na ich ilość. Poza tym widać wyraźnie że oświetlają otoczonie również podczas symkowego dnia. A jak pamiętam wyeliminowaleś to w swoich kompilacjach już jakiś czas temu.
 Pozdrawiam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: szogun w 30 Czerwca 2017, 19:21:50
Zauważyłem dziś dziwną rzecz na C++, mianowicie niektóre submodele źle interpretowały smooth i wychodzi mozajka, po wczytaniu e3d wygenerowanego na borlandzie jest tak jak być powinno.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 30 Czerwca 2017, 19:35:25
Wiele grzybków w EP09 nie złapało mi teraz wygładzania, a wcześniej nie przypominam sobie, by były z tym problemy. Ten fragment t3d nie był dotykany.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: szogun w 30 Czerwca 2017, 20:05:50
No cóż, do czasu znalezienia przyczyny trzeba generować na borlandzie pamiętając aby nowe przełączniki miały anim: true.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 30 Czerwca 2017, 21:21:01
Zgloszenie "niektore submodele" jest mniej wiecej tak samo przydatne jak stwierdzenie "cos jest nie tak" ;/

Wsliznal sie glupi blad przy kalkulacji wektorow normalnych dla wierzcholkow, w tej wersji powinno byc juz dobrze. Oprocz tego dodane przy okazji:

- obsluga dodatkowych typow przyciskow, pantselected_sw: i pantselectedoff_sw: podnoszacych/opuszczajacych pantografy wybrane przy pomocy odrebnego przelacznika/zaworu. Wspomniany odrebny przelacznik nie jest jeszcze zaimplementowany, tymczasowo obsluga kabiny z nowym typem przyciskow odbywa sie uzywajac standardowych kombinacji klawiszy obslugi pantografow.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 30 Czerwca 2017, 22:44:37
wstawiam sobie do opengl_renderer::Init, na koniec, takie dwie bardzo niewinne linijki:
GLuint WTF;
glGenTextures(1, &WTF);
Tworzy obiekt tekstury, zapisuje do WTF, jakiekolwiek skutki uboczne są po prostu nie możliwe.
haha, NIE.

@tmj: masz pomysł o co tu może chodzić? chociaż nie zdziwłbym się jakby u ciebie było dobrze.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 30 Czerwca 2017, 23:19:25
Nie, u mnie tez to jest xD  w texture_manager::bind() jest blad, zamiast zapamietywac ostatnio ustawiony handle zapamietuje id tekstury powiazanej z handle, i w skrocie porownuje dwie rozne rzeczy decydujac czy nalezy zmienic teksture, czy nie. Wylazi to tylko wtedy gdy id i handle maja rozne wartosci, co sie z reguly nie zdarza. @AtapiCL mial to kiedys u siebie dzieki programowi overlay, to jest taka powtorka z rozrywki :>

zmien linie 818 w texture.cpp na
m_activetexture = Texture;
i bedzie dobrze.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 01 Lipca 2017, 07:32:02
Kompilacja z dzisiejszej nocy przyniosła poprawę, Bałtyk odpalony i przejechany bez problemów (xp 32 bitowe). Tyle na gorąco. Na zimno, UFO nadal jest. W załączniku widać jak otacza ET22 i jest tak na każdym modelu tej lokomotywy. Obraz zarejestrowałem po wyjściu z kabiny w debug mode kursorami na dość sporą jak widać odległość. Ta bańka podąża za lokomotywą nie odstępując jej na krok. Fatamorgana przesuwa się nieco obok loka, jeśli z kabiny wyskoczymy za pomocą F4.
Z uwag, do poprawy oświetlenie terenu w tym podsypki. Brak oświetlenia słupów stalowych. Za szeroki kąt oświetlenia po bokach. Tyle na szybko. Ogólnie znaczna poprawa do poprzedniej wersji.
Więcej jak sprawdzę zarządzanie pamięcią i system 64 bitowy.
ED:
Dodałem załącznik. Powyższe co napisałem dotyczy kompilacji nocnej od @Milek7.
Wsliznal sie glupi blad przy kalkulacji wektorow normalnych dla wierzcholkow, w tej wersji powinno byc juz dobrze.
Można wiedzieć, czym się objawiał?

ED2:
Nadal nie ma poprawy w dysponowaniu pamięcią, jak napisał @tmj, mamy powtórkę z rozrywki. W załączniku efekty powtarzalnie uzyskane z kaliskiej (2 screeny).Trzeci, pół elektrowozu i skład widmo bez wyświetlonego modelu. Czwarty, skład bez loka z przeciwnej strony. a także log i errors. Scenerię usiłowałem przejechać 2 razy, efekt ten sam. Za drugim razem końcówka log.txt wygląda tak:
openGL error: out of memory; failed to create a geometry buffer
openGL error: out of memory; failed to create a geometry buffer
openGL error: out of memory; failed to create a geometry buffer
openGL error: out of memory; failed to create a geometry buffer
openGL error: out of memory; failed to create a geometry buffer
openGL error: out of memory; failed to create a geometry buffer
Critical error, memory allocation failure: bad allocation
a errors.txt
openGL error: out of memory; failed to create a geometry buffer
openGL error: out of memory; failed to create a geometry buffer
openGL error: out of memory; failed to create a geometry buffer
openGL error: out of memory; failed to create a geometry buffer
openGL error: out of memory; failed to create a geometry buffer
Zniknęły natomiast linijki w stylu:
Bad geometry (shape estimation failed) for spline "str05" at 22778.200000 0.000000 -5417.500000
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: MW w 01 Lipca 2017, 11:26:12

Błędy zauważone w działaniu wersji EU07++NG (warianty z shaderami), testowanych na następującym sprzęcie:
CPU - Intel Core2 Quad Q8200 2.33 GHz; RAM 4 GB; NVidia GeForce 9600 GT; Windows Vista SP2 32 bit.

A. Wersje eu07++ng  170427 i 170629

Według zamieszczonej informacji te warianty programu wymagają OpenGL w wersji >= 3.2.
W moim przypadku program natychmiast po uruchomieniu kończy działanie z komunikatem w log.txt o niedostatecznej wersji OpenGL.

Wykrywana jest wersja 2.1.2, chociaż we wszystkich dotychczasowych wariantach exe (także NG do 170329 włącznie) rozpoznawana jest wersja OpenGL 3.3.0. Również program testowy Everest wykrywa wersję OpenGL 3.3.0.

O ile dobrze pamiętam, niektórzy Koledzy zamieszczali logi z testów omawianych wersji exe, wygenerowane dla konfiguracji z taką samą kartą graficzną (GeForce 9600 GT) i tam wykrywany był OpenGL 3.3.0. Nie kojarzę teraz, czy testy te dotyczyły wariantu 32 czy 64 bitowego. Mój system jest 32 bitowy. Wszystkie wymagane msvc i biblioteki mam zainstalowane.

Co może być przyczyną tego problemu?

W załączeniu plik log.txt z wersji eu07++ng 170629 i dla porównania początek pliku log.txt wersji eu07-x86_170626.

B. Wersje do eu07++ng170329 włącznie

Ponieważ z powyższych względów nie mam możliwości testowania wersji najnowszych, wymienię niektóre błędy zauważone w poprzednich wariantach exe NG. Być może zostało to naprawione, ale nie mogę tego sprawdzić.

1. W trybie debugmode program przerywa działanie (typowy komunikat windows) zaraz po załadowaniu kabiny w przypadku rozpoczęcia symulacji w pojeździe z wpisaną prędkością początkową większą od zera.
Takie zachowanie programu jest dominujące – chociaż bardzo rzadko zdarza się, że w tych warunkach program jednak zadziała (i to raczej zaraz po uruchomieniu komputera).
Po wyzerowaniu prędkości początkowej w trainset program uruchamia się.

Błąd ten nie występuje w trybie normalnym.

2. Nieoteksturowane elementy modeli nie są wyświetlane (znikają) - zarówno w trybie normalnym, jak i debugmode. Zdaje się, że było to już poruszane dla przypadku samochodów. Tu dla porządku potwierdzam to dla modeli statycznych.

Powyższe błędy nie są uzależnione od scenerii.

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Lipca 2017, 12:01:34
Na zimno, UFO nadal jest. W załączniku widać jak otacza ET22 i jest tak na każdym modelu tej lokomotywy. Obraz zarejestrowałem po wyjściu z kabiny w debug mode kursorami na dość sporą jak widać odległość. Ta bańka podąża za lokomotywą nie odstępując jej na krok. Fatamorgana przesuwa się nieco obok loka, jeśli z kabiny wyskoczymy za pomocą F4.
Ta banka pojawia sie tylko gdy zalaczony jest debug mode, podejrzewam ze to sa wywolania funkcji zaznaczajacych pozycje ksiezyca i slonca (funkcje render() w cSun/cMoon) gryzace sie z aktywnym shaderem, albo cos w tym stylu.

Cytuj
Można wiedzieć, czym się objawiał?
Na niektorych zaokraglonych powierzchniach (grzybki w kabinie itp) mogly pojawic sie dosc wyrazne roznice cieniowania sasiednich trojkatow.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 01 Lipca 2017, 12:28:49

Błędy zauważone w działaniu wersji EU07++NG (warianty z shaderami), testowanych na następującym sprzęcie:
CPU - Intel Core2 Quad Q8200 2.33 GHz; RAM 4 GB; NVidia GeForce 9600 GT; Windows Vista SP2 32 bit.

A. Wersje eu07++ng  170427 i 170629

Według zamieszczonej informacji te warianty programu wymagają OpenGL w wersji >= 3.2.
W moim przypadku program natychmiast po uruchomieniu kończy działanie z komunikatem w log.txt o niedostatecznej wersji OpenGL.

Wykrywana jest wersja 2.1.2, chociaż we wszystkich dotychczasowych wariantach exe (także NG do 170329 włącznie) rozpoznawana jest wersja OpenGL 3.3.0. Również program testowy Everest wykrywa wersję OpenGL 3.3.0.

O ile dobrze pamiętam, niektórzy Koledzy zamieszczali logi z testów omawianych wersji exe, wygenerowane dla konfiguracji z taką samą kartą graficzną (GeForce 9600 GT) i tam wykrywany był OpenGL 3.3.0. Nie kojarzę teraz, czy testy te dotyczyły wariantu 32 czy 64 bitowego. Mój system jest 32 bitowy. Wszystkie wymagane msvc i biblioteki mam zainstalowane.
Co może być przyczyną tego problemu?
Taki log z dzisiejszej jazdy i takiej samej grafiki (kawałek).
Gfx Renderer: GeForce 9600 GT/PCIe/SSE2 Vendor: NVIDIA Corporation OpenGL Version: 3.3.0
Supported extensions:GL_ARB_arrays_of_arrays GL_ARB_base_instance GL_ARB_blend_func_extended GL_ARB_clear_buffer_object GL_ARB_color_buffer_float GL_ARB_compatibility GL_ARB_compressed_texture_pixel_storage GL_ARB_conservative_depth GL_ARB_copy_buffer GL_ARB_copy_image GL_ARB_debug_output GL_ARB_depth_buffer_float GL_ARB_depth_clamp GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_draw_elements_base_vertex GL_ARB_draw_instanced GL_ARB_enhanced_layouts GL_ARB_ES2_compatibility GL_ARB_ES3_compatibility GL_ARB_explicit_attrib_location GL_ARB_explicit_uniform_location GL_ARB_fragment_coord_conventions GL_ARB_fragment_layer_viewport GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_framebuffer_no_attachments GL_ARB_framebuffer_object GL_ARB_framebuffer_sRGB GL_ARB_geometry_shader4 GL_ARB_get_program_binary GL_ARB_half_float_pixel GL_ARB_half_float_vertex GL_ARB_imaging GL_ARB_instanced_arrays GL_ARB_internalformat_query GL_ARB_internalformat_query2 GL_ARB_invalidate_subdata GL_ARB_map_buffer_alignment GL_ARB_map_buffer_range GL_ARB_multi_bind GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_occlusion_query2 GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_program_interface_query GL_ARB_provoking_vertex GL_ARB_robust_buffer_access_behavior GL_ARB_robustness GL_ARB_sampler_objects GL_ARB_seamless_cube_map GL_ARB_separate_shader_objects GL_ARB_shader_bit_encoding GL_ARB_shader_objects GL_ARB_shader_texture_lod GL_ARB_shading_language_100 GL_ARB_shading_language_420pack GL_ARB_shading_language_include GL_ARB_shading_language_packing GL_ARB_shadow GL_ARB_stencil_texturing GL_ARB_sync GL_ARB_texture_border_clamp GL_ARB_texture_buffer_object GL_ARB_texture_buffer_range GL_ARB_texture_compression GL_ARB_texture_compression_rgtc GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_float GL_ARB_texture_mirror_clamp_to_edge GL_ARB_texture_mirrored_repeat GL_ARB_texture_multisample GL_ARB_texture_non_power_of_two GL_ARB_texture_query_levels GL_ARB_texture_rectangle GL_ARB_texture_rg GL_ARB_texture_rgb10_a2ui GL_ARB_texture_stencil8 GL_ARB_texture_storage GL_ARB_texture_storage_multisample GL_ARB_texture_swizzle GL_ARB_texture_view GL_ARB_timer_query GL_ARB_transpose_matrix GL_ARB_uniform_buffer_object GL_ARB_vertex_array_bgra GL_ARB_vertex_array_object GL_ARB_vertex_attrib_binding GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_vertex_type_10f_11f_11f_rev GL_ARB_vertex_type_2_10_10_10_rev GL_ARB_viewport_array GL_ARB_window_pos GL_ATI_draw_buffers GL_ATI_texture_float GL_ATI_texture_mirror_once GL_S3_s3tc GL_EXT_texture_env_add GL_EXT_abgr GL_EXT_bgra GL_EXT_bindable_uniform GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_compiled_vertex_array GL_EXT_Cg_shader GL_EXT_depth_bounds_test GL_EXT_direct_state_access GL_EXT_draw_buffers2 GL_EXT_draw_instanced GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXTX_framebuffer_mixed_formats GL_EXT_framebuffer_multisample_blit_scaled GL_EXT_framebuffer_object GL_EXT_framebuffer_sRGB GL_EXT_geometry_shader4 GL_EXT_gpu_program_parameters GL_EXT_gpu_shader4 GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil GL_EXT_packed_float GL_EXT_packed_pixels GL_EXT_pixel_buffer_object GL_EXT_point_parameters GL_EXT_provoking_vertex GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_shader_objects GL_EXT_separate_specular_color GL_EXT_shader_integer_mix GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_texture3D GL_EXT_texture_array GL_EXT_texture_buffer_object GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_latc GL_EXT_texture_compression_rgtc GL_EXT_texture_compression_s3tc GL_EXT_texture_cube_map GL_EXT_texture_edge_clamp GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_integer GL_EXT_texture_lod GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_shared_exponent GL_EXT_texture_sRGB GL_EXT_texture_sRGB_decode GL_EXT_texture_storage GL_EXT_texture_swizzle GL_EXT_timer_query GL_EXT_vertex_array GL_EXT_vertex_array_bgra GL_EXT_import_sync_object GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_KHR_debug GL_KTX_buffer_region GL_NV_blend_square GL_NV_conditional_render GL_NV_copy_depth_to_color GL_NV_copy_image GL_NV_depth_buffer_float GL_NV_depth_clamp GL_NV_ES1_1_compatibility GL_NV_explicit_multisample GL_NV_fence GL_NV_float_buffer GL_NV_fog_distance GL_NV_fragment_program GL_NV_fragment_program_option GL_NV_fragment_program2 GL_NV_framebuffer_multisample_coverage GL_NV_geometry_shader4 GL_NV_gpu_program4 GL_NV_half_float GL_NV_light_max_exponent GL_NV_multisample_coverage GL_NV_multisample_filter_hint GL_NV_occlusion_query GL_NV_packed_depth_stencil GL_NV_parameter_buffer_object GL_NV_parameter_buffer_object2 GL_NV_path_rendering GL_NV_pixel_data_range GL_NV_point_sprite GL_NV_primitive_restart GL_NV_register_combiners GL_NV_register_combiners2 GL_NV_shader_buffer_load GL_NV_texgen_reflection GL_NV_texture_barrier GL_NV_texture_compression_vtc GL_NV_texture_env_combine4 GL_NV_texture_expand_normal GL_NV_texture_multisample GL_NV_texture_rectangle GL_NV_texture_shader GL_NV_texture_shader2 GL_NV_texture_shader3 GL_NV_transform_feedback GL_NV_vertex_array_range GL_NV_vertex_array_range2 GL_NV_vertex_buffer_unified_memory GL_NV_vertex_program GL_NV_vertex_program1_1 GL_NV_vertex_program2 GL_NV_vertex_program2_option GL_NV_vertex_program3 GL_NVX_conditional_render GL_NVX_gpu_memory_info GL_SGIS_generate_mipmap GL_SGIS_texture_lod GL_SGIX_depth_texture GL_SGIX_shadow GL_SUN_slice_accum GL_WIN_swap_hint WGL_EXT_swap_control
Texture sizes capped at 8192 pixels
loading shader lighting.vert ..done.
loading shader blinnphong.frag ..done.
Loading common gfx data...
Created texture object for "textures\fx\lightglare.tga"
Loading texture data from "textures\fx\lightglare.tga"
Created texture object for "textures\fx\sun.tga"
Loading texture data from "textures\fx\sun.tga"
Created texture object for "textures\fx\moon.tga"
Loading texture data from "textures\fx\moon.tga"
...gfx data pre-loading done
Display Lists font used
Font init OK
No gamepad detected

Starting MaSzyna rail vehicle simulator (release: NG)
For online documentation and additional files refer to: http://eu07.pl
Created texture object for "textures\logo.bmp"
Loading texture data from "textures\logo.bmp"
Sound Init OK
Models init OK
Ground init
Może trzeba zaktualizować sterownik?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 01 Lipca 2017, 12:41:10
@MW: hmm, bardzo dziwne. nie ma w sterowniku jakiś dziwnych profili poustawianych?
Sprawdzałeś wersję VS2017 czy nocną VS2015?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 01 Lipca 2017, 13:28:23
@tmj, exe jak zwykle coraz lepsze. Jednak zarejestrowałem dni otwarte kolei, mechanik pokazał wszystko co miał, jak na dłoni. Załącznik. Jednak exe 20170630 mimo takiego pliku errors:
.......
openGL error: out of memory; failed to create a geometry buffer
openGL error: out of memory; failed to create a geometry buffer
openGL error: out of memory; failed to create a geometry buffer
openGL error: out of memory; failed to create a geometry buffer
Critical error, memory allocation failure: bad allocation
nie wychodzi do windowsa.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Lipca 2017, 14:08:10
No niestety, jesli zabraknie pamieci na dane obiektow 3d to exe nie urodzi ;o Zastanawiam sie, czy nie warto by wprowadzic takze usuwania z pamieci karty graficznej nieuzywanych tekstur (po ujednoliceniu kodu jest to calkiem mozliwe) ale trzeba by tutaj troche poeksperymentowac.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: MW w 01 Lipca 2017, 14:55:46
Odnośnie błędów w wersjach exe NG na NVidia GeForce 9600 GT.
Rzeczywiście pomógł nowszy sterownik. W miejsce dotychczasowego 9.18.13.1106 z dn. 2013.01.18 zainstalowałem wersję 9.1813.3221 z dn. 2013.12.19. Niemniej nadal nie rozumiem, dlaczego różne wersje exe tak odmiennie rozpoznają  wersję OpenGL karty graficznej.

Po szybkim teście na najnowszych wersjach NG nie potwierdzam zgłoszonego poprzednio wysypywania się programu w debugmode po rozpoczęciu symulacji w jadącym pojeździe. Różnica w stosunku do starszych wersji exe jest chyba taka, że poprzednio AI obejmowało pojazd od razu po rozpoczęciu symulacji, a teraz dopiero po Shift+Q.

Natomiast modele bez tekstury wyświetlają się na czarno, pomimo ustawienia w .t3d parametrów diffuse i ambient na wartości maksymalne (255 255 255). To ostatnie też było testowane w debugmode.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 01 Lipca 2017, 16:21:30
No niestety, jesli zabraknie pamieci na dane obiektow 3d to exe nie urodzi ;o Zastanawiam sie, czy nie warto by wprowadzic takze usuwania z pamieci karty graficznej nieuzywanych tekstur (po ujednoliceniu kodu jest to calkiem mozliwe) ale trzeba by tutaj troche poeksperymentowac.
Nie bedzie wyjscia. Duza czesc systemow operacyjnych to systemy 32 bitowe, a te obsluguja max do 3,25gb pamieci. Biorac pod uwage, ze Kaliska jest najbardziej stresujaca dobrze bedzie umozliwic jej uzytkowanie z ta iloscia pamieci. Zastanawia mnie jednak fakt, jak pamietasz objechalem ta scenerie w jedna i druga strone majac jedynie w komputerze 2gb pamieci, skad nagle taki regres, czy zapotrzebowanie? Z tego co widze symulacja wylieciala nie zajmujac nawet polowy swapa.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 01 Lipca 2017, 16:21:36
To z modelami bez tekstury to wiem, kiedyś poprawię. Trzeba dodać jeszcze specjalnego shadera na kolorowane obiekty, bo musi być inny od tych na tekstury.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 01 Lipca 2017, 16:43:01
Uruchomienie EN57 o numerze powyżej 2003 powinno odbywać się w następujący sposób:
[...]
d) po podniesieniu pantografów odczekać ok. 30s aż zapali się lampka sygnalizacyjna ws gotowy do załączenia, po zapaleniu się lampki załączyć wyłącznik szybki[...]
e) załączyć przetwornicę statyczną wyłącznikiem dźwigienkowym przetwornica główna załączona. Ponieważ wzbudzenie przetwornicy trwa ok. 30s należy odczekać na zgaśnięcie czerwonej lampki sygnalizacyjnej Przetwornica wyłączona

@tmj da radę takie coś wprowadzić?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 01 Lipca 2017, 16:54:26
A ja nie wiem, czy to opóźnienie już nie jest możliwe do wpisania w Fiz. Poszukaj w changelogu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 01 Lipca 2017, 17:03:19
Rzeczywiście Krzysiu, sam o to prosiłem przecież wtedy do EN57AL. A co z opóźnieniem wyłącznika szybkiego? Dałoby radę coś zrobić?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 01 Lipca 2017, 18:07:28
W praktyce WS DCU dają gotowość prawie że od razu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 01 Lipca 2017, 20:49:06
...
Rzeczywiście pomógł nowszy sterownik. W miejsce dotychczasowego 9.18.13.1106 z dn. 2013.01.18 zainstalowałem wersję 9.1813.3221 z dn. 2013.12.29
Natomiast modele bez tekstury wyświetlają się na czarno, pomimo ustawienia w .t3d parametrów diffuse i ambient na wartości maksymalne (255 255 255). To ostatnie też było testowane w debugmode....
 AI obejmowało pojazd od razu po rozpoczęciu symulacji, a teraz dopiero po Shift+Q.
Nie wiem jak szukałeś, ale ostatni sterownik do Visty 32 bitowej masz tu http://www.nvidia.pl/download/driverResults.aspx/112613/pl
Jest z 14 grudnia 2016r.
@Milek7 odpowiedział czemu brak tekstury skutkuje czarnym kolorem pojazdu, to znany temat.
AI faktycznie przestało obejmować skład we władanie na starcie w debug mode. W pewnych sytuacjach, przeszkadzało to testować poprawne wykonywanie czynności przy sprawdzaniu uruchamiania pojazdu od zera.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 01 Lipca 2017, 21:10:12
W praktyce WS DCU dają gotowość prawie że od razu.

A z przetwornicą jak to wygląda?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 01 Lipca 2017, 21:44:34
mam zagadkę, może ktoś ma pomysł
Shadow mapa jest renderowana z projekcją depthproj i macierzą depthcam. Do GL jako modelview jest przesyłana tylko obrót depthcam, czyli mat3(depthcam).
To samo ze światem, renderowany jest z projekcją perspective i macierzą worldcamera. Do GL jako modelview jest przesyłany tylko obrót worldcamera, czyli mat3(worldcamera)
Teraz: przez jaki macierz trzeba przemnożyć (mat3(worldcamera) * wierzchołek) żeby powstały współrzędna wierzchołka widziana przez światło?
    glm::mat4 depthproj = glm::ortho(-10.0f, 10.0f, -10.0f, 10.0f, 0.1f, 100.0f);
glm::vec3 playerpos = glm::vec3(World.Camera.Pos.x, World.Camera.Pos.y, World.Camera.Pos.z);
glm::vec3 shadoweye = playerpos - Global::daylight.direction * 50.0f;
Global::SetCameraPosition(Math3D::vector3(shadoweye));
    glm::mat4 depthcam = glm::lookAt(shadoweye,
playerpos,
            glm::vec3(0.0f, 1.0f, 0.0f));
    m_camera.update_frustum(depthproj, depthcam);
    glMatrixMode(GL_PROJECTION);
    glLoadMatrixf(glm::value_ptr(depthproj));
    glMatrixMode(GL_MODELVIEW);
    glMultMatrixf(glm::value_ptr(glm::mat4(glm::mat3(depthcam))));

    glm::mat4 perspective = glm::perspective(
        glm::radians(Global::FieldOfView / Global::ZoomFactor),
        std::max( 1.0f, (float)Global::ScreenWidth ) / std::max( 1.0f, (float)Global::ScreenHeight ),
        0.1f * Global::ZoomFactor,
        m_drawrange * Global::fDistanceFactor );
glm::dmat4 worldcamera;
World.Camera.SetMatrix( worldcamera );
m_camera.update_frustum( OpenGLMatrices.data( GL_PROJECTION ), worldcamera);
glMatrixMode(GL_PROJECTION);
glLoadMatrixf(glm::value_ptr(perspective));
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
glMultMatrixd( glm::value_ptr( glm::dmat4( glm::dmat3(worldcamera))));

Próbowałem już różne kombinacje, m. in. tak, ale nie mogę trafić.
glm::vec3 transdiff = glm::vec3(worldcamera[3]) - glm::vec3(depthcam[3]);
glm::mat3 rotdiff = glm::mat3(worldcamera) * glm::mat3(depthcam);
glm::mat4 lv = depthproj * glm::translate(glm::mat4(rotdiff), transdiff);
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 01 Lipca 2017, 22:01:32
Tytułem uzupełnienia testów. Obie wersje exeka @tnj i od @Milek7 poprawnie wczytują scenerie na 64 bitowym windowsie. Obie 64 bitowe wersje exeków nie wywlają błędów z pamięcią (brakiem). Exe Milkowe przestało sypać masowymi wpisami do log i errors.txt. Nie mam błędów w wyświetlaniu tekstur i modeli. Mimo anosu @tmj o wyższym fps na exe Milka, nie potwierdzę, kaliska ma kilka FPSów mniej niż na exe od @tmj, szczególnie, gdy ich poziom oscyluje w granicach 30.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: MW w 01 Lipca 2017, 22:10:33
@Krzysiek626: dzięki za link - zainstalowałem pierwszy napotkany sterownik, nowszy od dotychczasowego, celem sprawdzenia czy to w ogóle pomoże. Rzucającym się w oczy problemem była rozbieżność w odczytaniu wersji OpenGL  przez różne warianty exe , tym bardziej, że inne niezależne narzędzia testujące pokazywały 3.3.0.  Co do zmian w obejmowaniu składu przez AI w trybie debug, to wiedziałem o tym. W poprzednim poście nawiązałem do tego, bo być może wysypy wersji NG miały przyczynę w jakimś konflikcie przy jednoczesnym inicjowaniu sceny i aktywacji AI (?)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Lipca 2017, 23:33:29
Próbowałem już różne kombinacje, m. in. tak, ale nie mogę trafić.
glm::vec3 transdiff = glm::vec3(worldcamera[3]) - glm::vec3(depthcam[3]);
glm::mat3 rotdiff = glm::mat3(worldcamera) * glm::mat3(depthcam);
glm::mat4 lv = depthproj * glm::translate(glm::mat4(rotdiff), transdiff);
O ile dobrze pamietam to roznica obrotow dwoch macierzy to R1^-1 * R2, czyli na jednej z nich musi byc zrobiony inverse. Zwykle mnozenie da sume obrotow, nie roznice.

A co z opóźnieniem wyłącznika szybkiego? Dałoby radę coś zrobić?
Teoretycznie mozna, ale jesli w praktyce wyglada to tak, jak mowi @AtapiCl to nie wiem czy warto ;o

W dzisiejszym uaktualnieniu:

- eksperymentalnie, wrzucanie tekstur do karty graficznej wykonywane jest dopiero gdy tekstura jest potrzebna do narysowania sceny, a tekstury przez dluzszy czas nie uzywane przenoszone sa do czasu ponownego uzycia do pamieci zasadniczej. Efektem pozytywnym jest zmniejszenie uzycia pamieci vram, wiec jest szansa ze nie zabraknie jej zbyt szybko na wyswietlanie modeli. Efektem niepozytywnym natomiast moze byc okazjonalne przyciecie w renderowaniu, w czasie gdy dane tekstur przesylane sa miedzy karta i pamiecia zasadnicza (aby to wyeliminowac przydalaby sie obsluga tekstur na osobnym watku, ale tak dobrze jeszcze nie jest)

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 02 Lipca 2017, 00:59:21
Teoretycznie mozna, ale jesli w praktyce wyglada to tak, jak mowi @AtapiCl to nie wiem czy warto ;o

Może być jako opcja, wszak kilka sprzętów (w tym starsze turboklopy) tak ma.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 02 Lipca 2017, 13:15:57
Shaderowy build z cieniami wysypuje sie zaraz po zaladowaniu sceny :<
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 02 Lipca 2017, 13:47:34
Meh, zapomniałem że na appveyor się robią buildy bez symboli, sprawdź teraz. Przy okazji cofnąłem vs2017 bo to główny podejrzany w sprawie ostatnich crashy.
A, i zauważyłeś że branch nazywa się shadowdupa, czyli nie ma cieni tylko jakieś krzaczki? :P
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 02 Lipca 2017, 14:35:11
Zauwazylem nazwe, ale nie wiedzialem ze jest znaczaca ;>
Sypie sie tak samo, ale moze nowy crashdump bedzie przydatniejszy, zalaczam.

Co do smieci, nie wiem czy to o to chodzi, ale zobacz do tutoriala tutaj jesli jeszcze go nie widziales: http://www.opengl-tutorial.org/intermediate-tutorials/tutorial-16-shadow-mapping/ jest tam pokazanych kilka rzeczy o ktorych trzeba pamietac, i sposoby radzenia sobie z najczestszymi bledami.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 02 Lipca 2017, 15:50:48
Sypało się bo nie przewidziałem że renderowanie otoczenia może chcieć renderować submodele. Widocznie mamy jakieś inne TD.

Dalej jest problem z tą macierzą, próbuję od kilku godzin na wszystkie możliwości i już mi się skończyły pomysły.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 02 Lipca 2017, 17:25:18
Ciekawostka, to co jest wydaje sie do pewnego stopnia dzialac, ale tylko gdy kamera jest w okolicach punktu 0,0 a cien jest przywiazany na sztywno do kamery.

Co do macierzy, teoretycznie to co nalezy zrobic to 'cofnac' dany piksel z 'camera space' do 'world space', a nastepnie przeliczyc z 'world space' na 'light space' przepuszczajac wspolrzedne przez 'light view' i 'light projection'. Czyli

texcoord = (coord scale) * (light projection) * (light view) * (camera view)^-1

ale tutaj moze to chyba byc bardziej skomplikowane, bo przy renderowaniu wzgledem obserwatora 'world space' jest rozne dla kamery i dla swiatla, i byc moze trzeba to uwzglednic.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 02 Lipca 2017, 18:02:14
W dzisiejszym uaktualnieniu:
- eksperymentalnie, wrzucanie tekstur do karty graficznej wykonywane jest dopiero gdy tekstura jest potrzebna do narysowania sceny, a tekstury przez dluzszy czas nie uzywane przenoszone sa do czasu ponownego uzycia do pamieci zasadniczej. Efektem pozytywnym jest zmniejszenie uzycia pamieci vram, wiec jest szansa ze nie zabraknie jej zbyt szybko na wyswietlanie modeli. Efektem niepozytywnym natomiast moze byc okazjonalne przyciecie w renderowaniu, w czasie gdy dane tekstur przesylane sa miedzy karta i pamiecia zasadnicza (aby to wyeliminowac przydalaby sie obsluga tekstur na osobnym watku, ale tak dobrze jeszcze nie jest)
Jest dobrze, nawet jednego komunikatu nie było o braku pamięci. Vram wypełnia się u mnie maksymalnie do 200mb. ładuje około 1/4 całości tekstur z Kaliskiej. Nie mam przycięć, raczej mam efekt... odwrotny, coś na kształt chwilowego przyspieszenia (szarpnięcia?), ledwo zauważalne. W załączniku errors. Nie chce mi się wyciągać pamięci z komputera dla sprawdzenia jak pójdzie na 2Gb ramu, może kiedyś.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 02 Lipca 2017, 19:07:57
Nie mam przycięć, raczej mam efekt... odwrotny, coś na kształt chwilowego przyspieszenia (szarpnięcia?), ledwo zauważalne.
To jest najprawdopodobniej ten efekt o ktorym pisalem, tylko inaczej odbierany :>  przy przesylaniu tekstur rysowanie jest na moment pauzowane, a po zakonczeniu operacji symulator "nadrabia" przesuwajac kamere o nieco wiekszy dystans niz do tej pory. Byc moze da sie ten efekt w ten czy inny sposob zmniejszyc, ale to pozniej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 02 Lipca 2017, 20:54:10
Ciekawostka, to co jest wydaje sie do pewnego stopnia dzialac, ale tylko gdy kamera jest w okolicach punktu 0,0 a cien jest przywiazany na sztywno do kamery.

Co do macierzy, teoretycznie to co nalezy zrobic to 'cofnac' dany piksel z 'camera space' do 'world space', a nastepnie przeliczyc z 'world space' na 'light space' przepuszczajac wspolrzedne przez 'light view' i 'light projection'. Czyli

texcoord = (coord scale) * (light projection) * (light view) * (camera view)^-1

ale tutaj moze to chyba byc bardziej skomplikowane, bo przy renderowaniu wzgledem obserwatora 'world space' jest rozne dla kamery i dla swiatla, i byc moze trzeba to uwzglednic.
Ustawiłem narazie środek worldspace na 0,0,0 (przez Global::SetCameraPosition) i przesyłam do opengl całe macierze kamery, nie tylko mat3 z nich. Zepsuł się skydome, ale to teraz nieistotne.
Teraz jest: texcoord = (vec4(wierzchołek modelu, 1.0) * (light projection * light camera) * inverse(modelview obiektu)) * 0.5 + 0.5
Tak miałeś na myśli czy coś pokręciłem z kolejnością działań?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 02 Lipca 2017, 21:31:32
Nie jestem pewien, chyba tak xD
Jest jeszcze jedna rzecz do sprawdzenia -- zobacz co konkretnie renderuje sie w shadowmap, tzn jak ona wyglada, bo domyslnie wszystkie przesuniecia obiektow robione sa 'na sztywno' wzgledem kamery w scenie, wiec tam sie moze cos ostro rozjezdzac i efekt jest jaki jest, bo mapa nie jest prawidlowa.
Pchnalem na gita wersje gdzie jest to zmienione na kalkulacje wzgledem pozycji definiowanej w Render() modulu rysujacego, moze ci sie to na cos przyda.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: szogun w 02 Lipca 2017, 21:33:02
Na moim truchle wydaje się być git na ostatniej wersji od tmj, kaliska co prawda zlagowala mi się na amen na wejściu, ale to pewnie dlatego że w przypływie geniuszu zostawiłem multiasampling x16. Wywaliło błąd braku pamięci w pewnym momencie ale symulator działa, i to nawet płynnie - w zwk 25-30 fps przy 1680x1050 co niedawno było nie do pomyślenia dla mnie, czasem zetnie ale tragedii nie ma. Na razie błędów w wyświetlaniu brak. No i czas ładowania poniżej 7 minut, na borlandzie nieraz do 15 albo więcej dochodziło :d
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 02 Lipca 2017, 21:41:59
Nie jestem pewien, chyba tak xD
Jest jeszcze jedna rzecz do sprawdzenia -- zobacz co konkretnie renderuje sie w shadowmap, tzn jak ona wyglada, bo domyslnie wszystkie przesuniecia obiektow robione sa 'na sztywno' wzgledem kamery w scenie, wiec tam sie moze cos ostro rozjezdzac i efekt jest jaki jest, bo mapa nie jest prawidlowa.
Pchnalem na gita wersje gdzie jest to zmienione na kalkulacje wzgledem pozycji definiowanej w Render() modulu rysujacego, moze ci sie to na cos przyda.
Shadowmapa wygląda ok, tutaj jak kamera jest w kabinie: https://milek7.pl/.stuff/shadowmap.png
chodź na mattermost
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Tomnord15 w 02 Lipca 2017, 22:53:12
Ostatnie exe od @Tmj przynosi duży wzrost wydajności dla starszych komputerów. Wzrost fps na Drawinowie ponad 100 procent.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 02 Lipca 2017, 23:28:32
działa!
jutro jeszcze wprowadzę poprawki i wrzucę nowe exe
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 02 Lipca 2017, 23:31:45
Z jednej strony super ze dziala, z drugiej strony gdyby teraz nawet udalo sie dorzucic cienie do wersji bez shaderow to zamiast zachwytow bedzie tylko "eee tam, na shaderowej wyglada lepiej" ;d
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 03 Lipca 2017, 00:53:55
Muszę odkurzyć gpu i skoczyć po bekon. :) Coś zmieniałeś przy renderowaniu drutów? Na poprzednich wersjach ich nie miałem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 03 Lipca 2017, 07:10:06
@Milek, zauważyłeś że cień od trakcji urywa Ci się na lewym przęśle na zrzucie, który dałeś?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Balaclava w 03 Lipca 2017, 08:54:53
Czy w przypadku tekstur z alfą światło przechodzi przez przezroczysty fragment tekstury?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: pol102 w 03 Lipca 2017, 11:21:29
@Milek, zauważyłeś że cień od trakcji urywa Ci się na lewym przęśle na zrzucie, który dałeś?
Ciekawe co będzie się działo w dziurawych modelach :D
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 03 Lipca 2017, 11:36:08
Proponuje nie martwić się na zapas. Przecież pilnowano aby modele dziurawe nie były.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 03 Lipca 2017, 12:44:35
@Milek, zauważyłeś że cień od trakcji urywa Ci się na lewym przęśle na zrzucie, który dałeś?
Shadowmapa się skończyła. Trzeba będzie CSM zrobić, bo teraz żeby shadowmapa na 200m sensownie wyglądała to potrzeba teksturę 8K.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 03 Lipca 2017, 14:04:10
Exe 701. Wysyp na init normals. L053-towarowy-et22. Paczka 17.06 z testów.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 03 Lipca 2017, 14:24:19
Dzwiek "wjazd_podany" umieszczony jest w scenerii na pozycji o wspolrzednych (-12325, 303392) a mapa ma maksymalnie tylko 250 km w kazda strone ;/
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 03 Lipca 2017, 14:49:20
Drobny błąd w sztuce.

PS: Chodź na mattermosta ;>
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: DjSon231 w 03 Lipca 2017, 15:06:29
Włączam najnowsze exe od @tmj z bibliotekami i wyłącza się na pythonie.
Patch 16.08, sceneria testowa.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 03 Lipca 2017, 15:20:17
nowe exe: https://ci.appveyor.com/project/Milek7/maszyna/build/30/artifacts
ściągnąć odpowiednie exe i paczkę z shaderami

Jest nowy fajowy ficzer, CIENIE. Konfiguruje się je parametrem shadowtune:
shadowtune <rozdzielczość> <promień projekcji> <głębokość projekcji> <odległość od obserwatora>Gdzie: <rozdzielczość> - szerokość i wysokość tekstury na jaką renderuje się shadowmapa. żeby miało przyzwoitą jakość to ja sobie ustawiam 4096. (to zajmuje sporo vramu, np. 2048 to 16MiB, 4096 to 64MiB, 8192 to 256MiB)
<promień projekcji> - jak szeroka ma być projekcja przez którą rzucane jest światło. poza obszarem projekcji cienie nie są rzucane. oczywiście żeby zwiększyć projekcję bez utraty jakości należy też zwiększyć rozdzielczość shadowmapy. ja ustawiłem sobie na 250
<głębokość projekcji> - tutaj można sobie ustawić dużo, jednym ograniczeniem jest dokładność shadowmapy czyli 32bitowego floata. jeżeli będzie za mało to obiekty które są niżej nie będą rzucać cienia, widoczne przy wylatywaniu kamerą w górę. ja ustawiam na 400.
<odległość od obserwatora> - odległość punktu projekcji światła od obserwatora w kierunku słońca. jeżeli jest za mało to obiekty które są niżej nie będą rzucać cienia, a przy wysokich kątach padania światła projekcja będzie się wrzynać w teren i ograniczać efektywny promień projekcji. żeby miało sens to musi być mniejsze od głębokości projekcji, ja ustawiam na 300

Nie zmieniałem nic innego w rendererze, więc takie bugi jakie były to zostały. Dodany jest tylko prosty opisany powyżej shadowmapping z wieloma wadami:
- kabina nie rzuca cienia (na to będzie trzeba osobną shadowmapę, z małym zasięgiem żeby była dobra jakość i bez PCF żeby nie było rozmycia)
- tylko oświetlenie dzienne rzuca cień, światła lokomotywy bez zmian
- nie ma CSM, więc żeby była dobra jakość z bliska to trzeba podkręcać rozdzielczość shadowmapy, jednocześnie niepotrzebnie zwiększając rozdzielczość gdzieś heń daleko.
- półprzeźroczyste tekstury zachowują się tak jakby były całkowicie przeźroczyste (do tego trzeba dorzucić drugi kanał do shadowmapy, nie wiem czy jest taka potrzeba?)

Jak ktoś chce to niech się bawi, a ja robię sobię przerwę na dwa tygodnie, później wrócę do poprawiania cieni i naprawy renderera.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Balaclava w 03 Lipca 2017, 15:46:15
Bardzo pozytywne wrażenia wizualne. Modele są ładniej oświetlone i prezentują się lepiej, niż bez shaderów, ale cień przez nie rzucany jest nieco przesunięty względem nich. Do ini wklepałem takie ustawienia, jakie podałeś.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 03 Lipca 2017, 15:54:37
To kwestia ustawienia biasa, jest w shaders/blinnphong.frag linia 45:
float bias = clamp(0.0025*tan(acos(clamp(dot(f_normal, -lights[0].dir), 0.0, 1.0))), 0, 0.01);Spróbuj zmniejszyć to 0.0025, np. do 0.0005, ale jak przecholujesz to zaczną się robić takie dziwne wzorki.

PS: jak już jesteśmy przy shaderach, to jakby ktoś chciał mieć mniej rozmazane cienie to można zakomentować linie 51-56 i odkomentować 48. Tylko wtedy przy niskich rozdzielczościach shadowmapy będzie widać teksele.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 03 Lipca 2017, 17:15:36
Jesli znajdziesz chwile, zobacz czy efekt nie bedzie lepszy jesli przy liczeniu shadowmapy renderer wywola tylko funkcje Render() a odpusci sobie Render_Alpha()  Do generowania cieni powinien wystarczyc alpha test w fazie nieprzezroczystych, i raz ze powinno byc troche szybciej, a dwa moze znikna dziwne element przy niektorych starych wagonach (wyglada to jakby plaszczyzny "sztucznych cieni" wcinaly sie tam do testu)

edit:
Włączam najnowsze exe od @tmj z bibliotekami i wyłącza się na pythonie.
Patch 16.08, sceneria testowa.
A jak to wyglada na wersji 32bit i/lub na starszych kompilacjach? Uruchamia sie, czy tez wylacza? Bo moze cos sie sypnelo z instalacja Pythona jakos bardziej uniwersalnie...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 03 Lipca 2017, 17:47:34
A w Render_Alpha to nie są przypadkiem renderowane tekturowe drzewka i ściany lasów?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 03 Lipca 2017, 17:53:16
Na 95% nie, chyba praktycznie wszystkie elementy budowane z luznych trojkatow sa robione ze zwyklym alpha test, bo inaczej wychodzily glupoty z braku sortowania itp. Zeby bylo smieszniej to do niedawna *byly* wstawione do renderowania przezroczystych, i przy renderowaniu kazdego indywidualnie wylaczany byl blending, tylko po to zeby go zaraz wlaczyc na nowo, i znowu wylaczyc, i wlaczyc, itp.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 03 Lipca 2017, 18:55:11
A, no to zaraz sprawdzę. Ale to co właściwie jest w Render_Alpha?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 03 Lipca 2017, 19:15:25
Elementy z ustawionym opacity 0 i z tekstura z alfa, czyli glownie szyby w pojazdach, cienie pod pojazdami, flary dla swiatel itp. Rowniez druty trakcji ktore w shadowmapie i tak wyjda rozmyte (jesli w ogole je wylapie) wiec strata niewielka~
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 03 Lipca 2017, 19:26:33
e, to jednak zostawię. rozmyte, ale według mnie i tak nieźle wyglądają
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: ST44-003 w 03 Lipca 2017, 19:53:26
Dobra, to co zepsułem?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mareczek w 03 Lipca 2017, 20:00:49
Co mi rzuciło, to cień druta jezdnego widać w kabinie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 03 Lipca 2017, 20:04:28
Dobra, to co zepsułem?
Potrzeba paczkę z dodatkowymi bibliotekami: 32bit: https://milek7.pl/.stuff/eu07exe/libs32.zip 64bit: https://milek7.pl/.stuff/eu07exe/libs64.zip
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 03 Lipca 2017, 20:05:50
Co mi rzuciło, to cień druta jezdnego widać w kabinie.
Tak, bo shadowmapa renderuje się z front cullingiem to kabina nie jest zasłaniana przez model. Będzie tak jak ma być dopiero jak się zrobi shadowmapę dla kabiny.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: ST44-003 w 03 Lipca 2017, 20:09:45
Działa, dziękuję za informacje (rzadko mam okazję zaglądać do tematu, a dziennie stron przyrasta przynajmniej o 3-4). Gdzie zatem szukać wpisów dla cieni, żeby zwiększyć ich widoczność? W ini czy po bibliotekach?

EDIT: Odpaliłem bezproblemowo na exe_64 bit klasyczne całkowo. Myślę, że screen mówi sam za siebie. Ogólnie 4ropiętrowy opad szczeny :D. Dla porównania z klasycznym exe.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Mariusz1970 w 03 Lipca 2017, 20:34:43
Przy okazji zamieszczenia screenu przez ST, podniescie ludka, bo wtopil sie z wrazenia w peron :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 03 Lipca 2017, 20:36:17
jakby ktoś jeszcze miał problem z brakiem trakcji: https://ci.appveyor.com/project/Milek7/maszyna/build/33/artifacts
wywaliłem też narazie diffuse i specular od księżyca żeby nie było brzydkiego przeskoku jak zachodzi słońce
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: ST44-003 w 03 Lipca 2017, 20:45:32
Chłopaki, naprawdę szacun za robotę. Po wstępnych testach na lapku z i5 2,2 GHz, Geforce 920M 4Gb i pamięcią 8 Gb dla Całkowa mam 45 FPS od jazdy ze stacji do najbardziej zadrzewionego terenu. Teraz czas na kaliską, ale boje się, że będę miał tutaj piekarnik. Podobnie jak na Wiedźminie 2. :D
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: DjSon231 w 03 Lipca 2017, 21:01:13
A jak to wyglada na wersji 32bit i/lub na starszych kompilacjach? Uruchamia sie, czy tez wylacza? Bo moze cos sie sypnelo z instalacja Pythona jakos bardziej uniwersalnie...

Pomimo wzięcia bibliotek 32-bitowych, problem nadal występuje. Jak będę się przenosić na 17.05 to wyczyszczę paczkę z MaSzyną i zobaczę, jak to będzie wyglądało.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 03 Lipca 2017, 21:24:10
Kaliska niestety po krotkiej chwili u mnie umiera (dump w zalaczniku) natomiast inne scenerie ktore na szybko sprawdzilem (linia 61, calkowo v2) dzialaja i wygladaja bardzo przyzwoicie, z mapa 4k. Sprawdze jeszcze czy uciagnie 8k czy sie skicha :>

edit: chyba posypal sie rendering na wersji 32. poprzednie do 31 wlacznie sa w porzadku, 32 wyswietla sieczke z niewlasciwie nalozonymi teksturami.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Cesky Kretek w 03 Lipca 2017, 21:43:52
EDIT: Odpaliłem bezproblemowo na exe_64 bit klasyczne całkowo. Myślę, że screen mówi sam za siebie. Ogólnie 4ropiętrowy opad szczeny :D. Dla porównania z klasycznym exe.
Że tak zarzucę klasykiem:

"Muszę iść do sąsiada niżej po szczękę." ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Balaclava w 03 Lipca 2017, 21:55:59
Sąsiad za te szczęki w piwnicy mógłby okup brać...
Na pierwszy rzut oka - wygląda jak zdjęcie, jeszcze gdyby były podsypki z alfą po bokach, to szczęki trzeba by było z łopatą szukać :D
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 03 Lipca 2017, 22:01:21
Cieeeeeenieeeeee <ślini się>
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: MW w 03 Lipca 2017, 22:04:41
Na pierwszej dzisiejszej 32 bitowej wersji NG nie widać żadnego efektu cieni. Druga wersja pokazuje tylko cienie od trakcji. Ponadto zdarzył się incydent z  „sieczką” zamiast tekstur. Testowane na NVidia GeForce 9600 GT (sterowniki najnowsze).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 03 Lipca 2017, 22:12:46
@tmj: na 33 jakaś poprawa?
@MW: to podobnie jak u k626, nie pasuje sterownikowi shader dla shadowmapy, będziemy debugować jak wrócę za tydzień-dwa.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 03 Lipca 2017, 22:14:34
To ja zobaczę to we wrześniu Od 15 mam szlaban na kompa. Po za tym jestem dumny, blady i pełen satysfakcji.
Załącznik, craszdump z kaliskiej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 03 Lipca 2017, 23:22:26
Witam.
 Mimo moich obaw najnowsze exe Milka wersja 32 bit działa u mnie jak na razie bez problemów. Tak jak koledzy szukam szczęki po mieszkaniu. Chwilami nie wygląda to na symulację, a na film nagrany z kabiny. Co ciekawe mój stary gruchot działa całkiem dobrze, chociaż wentylatory wyją jak psy. Na linii 61 wersji Ra, 45 Fps w stacjach. Najgorsze jest to że teraz widać wszelkie babole w sceneriach, obraz jest tak wyrazisty. Gdy poprzednio wszystko było szare, nie miało to wielkiego znaczenia, przynajmniej dla mnie. Na zakończenie pozwolę sobie na opinię, że doszliśmy do momentu w którym dogoniliśmy TD2 pod względem grafiki, a nawet śmiem twierdzić że jest lepiej. W Maszynie większość to przecież foto tekstury. Spróbuje uruchomić jeszcze Całkowo V2. Jak się uda, grafika na pewno będzie bajeczna.
Pozdrawiam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: pat w 03 Lipca 2017, 23:33:48
Mam taki problem na ostatniej wersji z cieniami. 64bit. Kilka minut po uruchomieniu znika cały teren oraz pojawia się komunikat nieprawidłowa operacja przy OpenGL.
Po dluzszej jezdzie doprowadzilem do crasha.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mareczek w 03 Lipca 2017, 23:47:31
Mi w końcu zeszły FPS poniżej 60 :) W Sandomierzu mam 30, przy kilku stojących składach. Oczywiście multiasampling wyciągnięty na max., tj 16. Domyślne ustawienia NVidii też na bardzo wysokich ustawieniach. Teraz można się bawić! ;)

1) W scenerii nocnej chyba mamy pełnię księżyca. Kabina zbyt mocno rozświetlona.
2) Coś się popsuło z dźwiękami. Po puszczeniu klawisza, np. trąbki, dźwięk zakończenia trąbienia jest odtwarzany nie do końca - ucina się.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 03 Lipca 2017, 23:54:41
@tmj: na 33 jakaś poprawa?
Sieczka zniknela, ale F8 pokazuje "invalid operation" ktorej nie ma na 30, wiec cos tam sie wywoluje ze zla konfiguracja i/lub parametrami w najnowszej wersji.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 04 Lipca 2017, 00:53:17
Witam ponownie.
 Testowanie exe wersji Milka ciąg dalszy. Całkowo V2 uruchomione, Fps na poziomie 30 kl/s. Kaliska również działa, w Ostrowiu najniżej 16 fps, na szlaku oscyluje w okolicy 40. Myślę że to przyzwoity wynik zważywszy na wiekowy sprzęt który posiadam, i smażoną już trzy krotnie grafikę. Popracować trzeba na pewno przy światłach lokomotyw, które równie mocno oświetlają scenerię w dzień. Jest na to sposób- nie włączać reflektorów w prowadzonym pojeździe. Następnie, ale to drobiazg zauważyłem brak strzałek w lataniach rozjazdu krzyżowego. Kończę na dziś trzeba iść spać, tylko jak tu teraz spać przy takiej grafice !?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 04 Lipca 2017, 06:29:37
To teraz tmj to doklepuj do swojego exeka. W zasadzie czemu wy oddzielne exeki robicie? Chyba ze to cos w stylu podzialu roboty.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Balaclava w 04 Lipca 2017, 06:32:33
Mi Rainsted nie chce zmieniać pogody na exe shaderowym. A w wyniku zainstalowania jego i bibliotek przestały działać inne exeki. Wypluwają błąd 0x00000007b "Aplikacja nie została właściwie zainicjowana".
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Sawi w 04 Lipca 2017, 06:35:30
Upewnij się czy na pewno pobrałeś brakujące biblioteki.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Balaclava w 04 Lipca 2017, 06:55:01
Tak, z przypiętego wątku z changelogiem. Vcredisty też wszystkie mam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 04 Lipca 2017, 08:07:43
Exe C++NG, potrzebuje dodatkowo jedynie bibliotek w katalogu shaders. Byc moze nadpisales ostatnie, nie robiac kopii zapasowych wersji. W kazdym wydaniu exe przez @Milek7 te biblioteki sa nieco inne. Ja mam zrobione 4 testowe paczki, po 2 na system operacyjny 32 i 64 bity. Na jednej w kazdym systemie testuje exeki od @tmj, na drugiej od/@Milek7. Mam jeszcze 2 paczki z ostatnim paczem 2017 i wielka paczke do testowania nowych tekstur i modeli. O paczkach z svna nie ma co pisac, one sluza jako bank plikow. Zycie testera nie jest latwe, potrzebne jest mnostwo czasu, mnostwo przestrzeni dyskowej i mnostwo pradu.
@tmj: na 33 jakaś poprawa?
Sieczka zniknela, ale F8 pokazuje "invalid operation" ktorej nie ma na 30, wiec cos tam sie wywoluje ze zla konfiguracja i/lub parametrami w najnowszej wersji.
Mam sieczke na kaliskiej, widoki sa kosmiczne. Cale stada statkow kosmicznych. Czesto wywala sie dajac crshdumpa. Na obu wersjach x86 i x64 zachowanie jest identyczne. Do tego brak cieni jesli nie liczyc tych od drutow. Karta graficzna gf 9600 gt do tej pory sprawdzAla sie bezproblemowo. Mam takie same informacje pod F8 jak @tmj. Exe NG nie toleruje zmniejszenie skalowania tekstur nizej niz 4096. Wywala blad mipmapy i wychodzi do windows.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 04 Lipca 2017, 08:19:21
@Krzysiek, spróbuj wyłączyć w starterze VBO, u mnie na początku też była czasem sieczka w obrazie. W trybie DL działa poprawnie.
Pozdrawiam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: trus w 04 Lipca 2017, 10:40:48
Cytuj
Jest nowy fajowy ficzer, CIENIE. Konfiguruje się je parametrem shadowtune:
Kod: [Zaznacz]
shadowtune <rozdzielczość> <promień projekcji> <głębokość projekcji> <odległość od obserwatora>
Gdzie ten parametr wpisać ? U mnie na win32 nie ma żadnych cieni.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 04 Lipca 2017, 10:55:09
Do EU07.ini, ale wartości podane przez Milka są ustawiane domyślnie przy jego braku, więc bez wpisu powinieneś mieć efekt identyczny jak na jego screenach.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 04 Lipca 2017, 10:57:54
@Krzysiek, spróbuj wyłączyć w starterze VBO, u mnie na początku też była czasem sieczka w obrazie. W trybie DL działa poprawnie.
Pozdrawiam.
U mnie nie ma znaczenia czy DL czy VBO Mam jak na screenach.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Cesky Kretek w 04 Lipca 2017, 11:18:08
@Krzysiek, spróbuj wyłączyć w starterze VBO, u mnie na początku też była czasem sieczka w obrazie. W trybie DL działa poprawnie.
Pozdrawiam.
U mnie nie ma znaczenia czy DL czy VBO Mam jak na screenach.
Na miniaturkach wygląda jakbyś po lodowcu jeździł. ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 04 Lipca 2017, 11:19:50
Bałtyk Zima? To są obrazki z Bałtyku, więc może morze zamarzło.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: pat w 04 Lipca 2017, 15:24:19
Mam podobnie jak Krzysztof, bez znaczenia czy DL czy VBO. Jedyna różnica jest taka, żę na VBO fps'y nie przekraczają 25, przy czym dla porównania na tej samej stacji na tej samej sceneri na DL mam ponad 60.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: jakol112 w 04 Lipca 2017, 16:12:20
Tylko u mnie obiekty nie rzucają cieni na ziemię? Czy tylko ja mam 5FPS (przy exe tmj mam 59)?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: pat w 04 Lipca 2017, 16:14:31
@jakol112, probowales wylaczyć tryb VBO? u mnie fpsy na wersji "cieniowej" też były marne, ale po wyłączeniu już jest tak samo jak na exe od tmj.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: ST44-003 w 04 Lipca 2017, 17:46:06
Ja zaś mam pytanie o światła, a raczej ich efekt. Dlaczego zapalone światła robią taką kosmiczną różnice (chodzi mi o to, że użycie jednego reflektora robi zmiany widoczne nawet w pełny dzień)?
Screen pierwszy, otoczenie bez zapalonych świateł, screen drugi z zapalonymi światłami.

Przekroczona waga załącznika. @Stele
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 04 Lipca 2017, 18:00:26
Prosta sprawa, to sa dopiero testy. Exe nie jest skonczone. Jak widze rowniez nie masz cienia. A w sumie, to nie bardzo wiem o ktore exe Tobie chodzi.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: ST44-003 w 04 Lipca 2017, 18:07:16
Chodzi o najnowszą wersję exe "ng". Wywaliłem z ini wpis "shadowtune", więc teraz efekt jest dużo lepszy.
Ale ok, światła do poprawki. Za to "Całkowo_IR" o poranku wygląda jak poniżej ;).
Załączone VBO i multisampling x8.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: pat w 04 Lipca 2017, 19:37:06
@ST44-003 jaką posiadasz kartę pamięci? A konkretnie ilość pamięci na karcie? Ja na 1gb mam odyseję kosmiczną na exe "ng".
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: matfre96 w 04 Lipca 2017, 20:04:05
Na exe NG+ urywają się dźwięki syren pod koniec.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 05 Lipca 2017, 00:48:40
Witam ponownie.
 Przetestowałem dzisiaj sporo scenerii z różnymi ustawieniami i nie udało mi się wywołać sieczki w obrazie która występuje u kolegów. Pomimo iż miałem przebłyski tego zjawiska wczoraj. Włączyłem nawet z powrotem tryb VBO i nic. Powolutku zwiększam sobie rozdzielczość shadowmapy, i czekam przy jakiej wartości zaczną się problemy. Jak na razie przy 4096 jest ok. Zauważyłem że najwięcej FPS kradną skupiska drzew, a właściwie ich cienie. Nawet duża ilość torów, pojazdów na stacjach, nie jest tak FPS-o żerna jak roślinność. Poniżej dwa zrzuty ekranu z L053, tak to mniej więcej u mnie wygląda. Multisampling ustawiony na x16, rozdzielczość 1280x1024, wersja 32 bit.
Pozdrawiam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: pat w 05 Lipca 2017, 08:15:48
Zainstalowałem na czysto Maszynę + pacze, tym razem 32 bitową i problem kosmicznych artefaktów przestał istnieć. Tymczasem na wersji 64bit problem nadal występuje. Może w tym jest pies pogrzebany?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: gravition w 05 Lipca 2017, 08:27:47
A ja mam pytanie, czy jest możliwe przywrócenie działania kranu hamulca takie jak jest w patchu 16.08? W patchu 17.06 kran hamulca po wciśnięciu i przytrzymaniu klawisza num3 najpierw wykonuje skok, potem jest mała przerwa i dopiero po tej przerwie kran idzie dalej, jest to szalenie irytujące i powoduje duży problem z precyzyjnym hamowaniem, prosiłbym o wzięcie tego pod uwagę
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Piotr93 w 05 Lipca 2017, 08:34:19
Otwórz edytorem tekstu typu notatnik plik w głównym folderze z maszyną "eu07_input-keyboard" i zmień sobie, odszukaj numerację od hamulców czyli:
Cytuj
trainbrakeincrease num_3 // zwiekszenie stopnia hamowania zaworu maszynisty
trainbrakedecrease num_9 // zmniejszenie stopnia hamowania zaworu maszynisty
trainbrakecharging num_. // napelnianie uderzeniowe przewodu glownego
trainbrakerelease num_4 // ustawienie zaworu maszynisty w pozycji jazdy
trainbrakefirstservice num_2 // pozycja pierwszego stopnia hamowania
trainbrakeservice num_5 // pozycja hamowanie pelnego
trainbrakefullservice num_8 // pozycja hamowania uzupelniajacego
trainbrakeemergency num_0 // hamowanie nagle
I pozmieniaj sobie cyferki. P.S. Ten wpis powyżej jest oparty na starych ustawieniach o takich jakich opisujesz.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 05 Lipca 2017, 09:47:24
Piotr, koledze chyba nie chodzi o zmiane cyferki i przypisanej jej funkcji. Tu chodzi o plynnosc dzialania, ktora pod innym klawiszem zostanie ta sama. Mysle, ze do tego mozna sie przyzwyczaic, po za tym z ktorej pozycji hamulca @gravition hamuje. Ja przy zmianie sposobu sterowania kranu, nawet tego nie zauwazylem co opisal.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 05 Lipca 2017, 09:50:18
A ja mam pytanie, czy jest możliwe przywrócenie działania kranu hamulca takie jak jest w patchu 16.08? W patchu 17.06 kran hamulca po wciśnięciu i przytrzymaniu klawisza num3 najpierw wykonuje skok, potem jest mała przerwa i dopiero po tej przerwie kran idzie dalej, jest to szalenie irytujące i powoduje duży problem z precyzyjnym hamowaniem, prosiłbym o wzięcie tego pod uwagę
Problemem jest zmiana obsługi klawiszy. Inaczej się nie da, jeśli mają być mapowalne. Poszukaj w systemie operacyjnym opcji powtarzania. Może jest ustawialny czas przytrzymania, kiedy ci łapie jako jedno kliknięcie, a kiedy jako przytrzymanie, bo to o to się rozchodzi. Wciśnij sobie dowolny klawisz w edytorze tekstu. Pojawi się jeden znak i dopiero po 30-40ms złapie, że ciągle go trzymasz. W Win XP jest to jako opóźnienie powtarzania znaku w opcjach klawiatury. Ustawienie na minimalne, zmniejsza ten czas do 10-15ms.
Warto obadać jak jest na innych systemach i dodać do do FAQ, bo temat powraca.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 05 Lipca 2017, 10:28:51
Jest drugi problem jesli juz o tym rozmawiamy, przytrzymanie shift+ strzalki wywoluje u mnie komunikat o konfiguracji dlugiego przytrzymania klawiszy. To jest irytujace przy lataniu po scenerii. Robie to dosc czesto z racji testow na exeku i nie tylko. Windows nie powinien sie wtracac do tego ( xp i win7 ).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 05 Lipca 2017, 11:08:43
Zobacz w opcjach ułatwienia dostępu. Klawisze trwałe/klawisze filtru. Powyłączałem to lata temu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Piotr93 w 05 Lipca 2017, 11:11:00
Czyżby o to chodziło? Windows 7.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 05 Lipca 2017, 11:34:50
Niekoniecznie, teraz reaguje na eventy z systemu, ale można zrobić tak żeby po pierwszym wciśnięciu później obliczało powtórzenia samo. Ale to niech lepiej tmj robi bo on ostatnio grzebał w sterowaniu :P.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Balaclava w 05 Lipca 2017, 12:21:08
Przejechałem sobie fragment Całkowa v2. Zaszalałem, bo ustawiłem sobie największy możliwy rozmiar shadowmapy. Oto błędy, jakie znalazłem.
1. Obiekty, które nie posiadają tekstury, a są barwione materiałem (jak np. samochody) są całe czarne.
2. Pojawiają się taki poziome paski, ale tylko wtedy, gdy zachodzi sytuacja taka, jak na kolejnym załączniku
3. Czyli popsute wektory normalne trajektorii
4. Trzeba by przeprogramować rysowanie chodników tak, żeby rysowało krawężnik z drugiej strony. Poprzednio nie było to aż tak widoczne, ale cienie to bardzo demaskują.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: bohunIC w 05 Lipca 2017, 21:00:40
U mnie zero problemow. FPS ponad 100 i cienie jak najbardziej okej. Testowane na Nvidia GTX 780. Exe NG 64bit. Mysle ze wczesniejsze problemy moga byc zwiazane z wydajnoscia Gstarszych kart?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 06 Lipca 2017, 00:10:04
@tmj: na 33 jakaś poprawa?
@MW: to podobnie jak u k626, nie pasuje sterownikowi shader dla shadowmapy, będziemy debugować jak wrócę za tydzień-dwa.
Na 33 nie mam sieczki, ale z cieniami jest cienko. Tylko druty znajduję jako cień, inne obiekty ładnie się błyszczą ale cienia nie dają.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 06 Lipca 2017, 09:30:03
Witam.
 Dzisiaj natrafiłem podczas kolejnych testów exe Milka 32bit na problemy z ET41. W wersji V2 nie daję się uruchomić loka "na zimno", a w wersji V1 nieprawidłowo reagują patyki, po próbie opuszczenia przednich, opadają obydwa w pierwszym członie, poza tym nie działają amperomierze. Mógłby ktoś sprawdzić u siebie.
 Pozdrawiam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 06 Lipca 2017, 18:42:04
Witam, mam pytanie-nie chcialem zasmiecac forum. Pliki z folderu Shaders wypakowywujemy do kat glownego Maszyny? Z gory dzikuje.
Do folderu shaders w głównym katalogu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 06 Lipca 2017, 21:20:26
Wy bedziecie razem z tmj te exeki pozniej jakos laczyc? Zastanawialem sie czemu was dwoje i kazdy swoje exe klepie.

jak pozbędę się bugów z shaderowego exe to pewnie tak.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 06 Lipca 2017, 22:04:27
@Milek wyłapywać i wypisywać błędy zauważone w Twoim exe, czy wiesz co jest nie tak. Znalazłem kilka bugów które @Tmj usunął w swojej wersji już jakiś czas temu. Na przykład opisywany problem w ET41-V2. W kilku pojazdach nie działają też wskaźniki. I jest kilka problemów związanych z grafiką. Na przykład nie kompletne latarnie rozjazdów krzyżowych.
Pozdrawiam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 07 Lipca 2017, 07:57:07
Dokopałem się do tego czemu czasami tabelka nie widzi semafora za W4. To jest związane ze sposobem przypisania eventów, które stoją przy tym samym torze oraz jak kod przypisuje odległość od semafora w pierwszym kroku. Wystarczy, że W4 blokuje skanowanie toru ale stoi przy torze do którego jest dowiązany semafor. AI zajmuje tor do którego dowiązany jest semafor a po zejściu W4 następuje dalsze skanowanie. Skanowanie prawidłowo odbywa się od toru do którego jest przypisany W4, przechodzi na następny tor, wykrywa semafor i wpisuje go do tabelki z odległością początku toru. Toru na który AI już wjechało i minęło jego początek. Po skanowaniu jest uruchamiana funkcja czyszcząca, która usuwa semafor jako minięty. Dopiero w następnym przebiegu jest ustalana prawidłowa odległość od eventów dopiero nadanych.

Tmj, nie poprawiaj tego teraz gdyż przenoszę niektóre zmiany z mojej pokręconej wersji na aktualną tabelkę (na vectorze). Tam to jest rozwiązane.

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 07 Lipca 2017, 09:47:03
@Milek wyłapywać i wypisywać błędy zauważone w Twoim exe, czy wiesz co jest nie tak. Znalazłem kilka bugów które @Tmj usunął w swojej wersji już jakiś czas temu. Na przykład opisywany problem w ET41-V2. W kilku pojazdach nie działają też wskaźniki. I jest kilka problemów związanych z grafiką. Na przykład nie kompletne latarnie rozjazdów krzyżowych.
Pozdrawiam.
nie zgłaszajcie narazie więcej, renderer i tak idzie to refaktoryzacj
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 07 Lipca 2017, 19:23:33
Próbowałem odpalić Milkowe exe, ale program się zamyka i w logu zostaje tylko: "loading shader shadowmap.vert ..cannot read shader shadowmap.vert". W bibliotece z shaderami tego nie ma, skąd mam to wytrzasnąć?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 07 Lipca 2017, 19:35:57
Z tego samego miejsca co exe.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 07 Lipca 2017, 20:58:33
https://ci.appveyor.com/project/Milek7/maszyna/build/30/artifacts

Zawartość shaders wypakować do katalogu /shaders/
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mareczek w 07 Lipca 2017, 22:08:54
Dwa screeny z Całkowa v2.
O dziwo autobusy miały tekstury.

PS. Jeszcze miałem napisać o dziwnym zachowaniu FPS, ale skoro Milek piszę o pracach, to na razie nie będę się rozpisywał.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Balaclava w 07 Lipca 2017, 22:20:44
Z tymi autami to jest tak, że one nie mają tekstur, tylko są pokolorowane materiałem z 3D Maxa i dlatego są czarne. A ten pierwszy problem na borlandowym exe chyba też występuje.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: DjSon231 w 08 Lipca 2017, 01:44:35
Na 17.06 działają exe'ki od @tmj oraz @Milek7. Wystarczyło wypakować folder python64 z bin_x64 do głównego folderu z MaSzyną.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 08 Lipca 2017, 09:22:50
To nie jest dokladna informacja. Tobie wystarczyly te biblioteki a innym bedzie potrzebna instalacja pelna pythona i inne. Ostatnie exe od milka potrzebuje bibliotek do shaderow razem z mapa, czego w paczce 1706 nie ma. Do pobrania ze wskazanej strony przez @Atapiego.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 09 Lipca 2017, 01:10:47
Troche to potrwalo, ale w dzisiejszym uaktualnieniu mamy w exe nastepny feature, a wlasciwie poltora:

- wprowadzona obsluga urzadzen kabiny przy uzyciu myszy. Do przelaczenia trybu pracy uzywany jest klawisz Alt. W trybie obslugi mysza kamera pozostaje nieruchoma a zamiast niej porusza sie kursor, ktorym mozna aktywowac urzadzenia. Dla wiekszosci urzadzen do aktywacji sluzy lewy przycisk, w przypadku urzadzen jak nastawnik, hamulec lub wielopozycyjne pokretla lewy przycisk przestawia urzadzenie 'do przodu' zas prawy 'do tylu'.
-- w standardowym trybie pracy symulatora kursor myszy podswietla jedynie urzadzenia zdefiniowane w pliku .mmd, podajac ich ujednolicone nazwy. W trybie debug podswietlane sa wszystkie czesci kabiny, a zamiast nazw ujednoliconych wyswietlane sa nazwy submodeli. W zalozeniu powinno to pozwolic na latwiejsze wylapywanie jak nazywa sie dany element, dla osob zainteresowanych rozbudowa plikow .mmd o nowe przyciski itp.

- wspomniane "pol" feature to dodatkowa funkcjonalnosc wprowadzona przy okazji w trybie ruch poza kabina pojazdu -- w trybie tym, gdy wlaczony jest debug mode i aktywowany zostanie tryb obslugi mysza, symulator wyswietla nazwe obiektu scenerii wskazanego mysza, o ile dany obiekt ma nazwe zdefiniowana w pliku .scn W zalozeniu pozwala to na latwe i szybkie okreslenie pod jaka nazwa w pliku scenerii zostal umieszczony dany tor, semafor itp, co moze sie przydac przy testowaniu lub budowie.

oprocz tego:

- dodane automatyczne wykrywanie, odrzucanie i zglaszanie nieprawidlowych trojkatow definiowanych w plikach scenerii

- dodana automatyczna korekta parametrow uv dla obiektow z wlaczonym zawijaniem tekstur, co powinno wyeliminowac bledy w wyswietlaniu tychze

- poprawka, symulator powinien teraz odrzucac (i zglaszac) obiekty umieszczone poza granicami mapy, zamiast wysypywac sie na tym
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: DjSon231 w 09 Lipca 2017, 01:18:28
Wydaje mi się, że dodanie sterowania myszą za bardzo nas zbliża do trainza. Nie chcemy chyba mieć dwóch prawie identycznych symulatorów. To jest tylko moja opinia.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: dymus w 09 Lipca 2017, 01:24:48
Może, ale dodatkowe sterowanie myszą będzie rozszerzać możliwosci od banalnych otwieranych szafek, dodatkowych przełączników (dla których nie było miejsca na klawiaturze), poprzez nawet ustawianie ważnych danych (np. wprwadzanie kiedyś do kabin elementów komputera, do wpisywania długości składu na tempomat czy innych tego typu rzeczy). Poza tym w samych założeniach oraz historii MaSzyna i Trainz będą się zawsze różnić.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Sawi w 09 Lipca 2017, 07:23:26
Mało tego będzie też można zasymulować procedury uruchamiania lokomotyw. Nie raz już czytałem wiele komentarzy w których własnie to głównie przeszkadzało niektórym użytkownikom.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 09 Lipca 2017, 08:33:52
Wydaje mi się, że dodanie sterowania myszą za bardzo nas zbliża do trainza. Nie chcemy chyba mieć dwóch prawie identycznych symulatorów. To jest tylko moja opinia.
  Przecież @Tmj pisał wyraźnie w planie prac nad exe, że uruchomienie sterowania myszką, jest jednym z warunków dodania w przyszłości możliwości edycji scenerii z poziomu symulatora. O innych aspektach wspomnieli koledzy wcześniej. Trainzowi do Maszyny daleko. Szczególnie pod względem fizyki ruchu pojazdów. Graficznie też.
Pozdrawiam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: pat w 09 Lipca 2017, 09:00:18
SM42-260, najnowsze exe.
Po użyciu przełącznika "OŚWIETLENIE BUDKI MASZYNISTY" zapala się światło a przełącznik znika.
Log mówi tylko tyle
sp42-260 received command: [interiorlighttoggle]

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Irek_Wd w 09 Lipca 2017, 09:37:11
Trzeba też wygładzić i zakokrąglić krawędzie rozmytych tekstur świateł semaforów i tarcz. Nie wygląda to za ładnie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: ST44-003 w 09 Lipca 2017, 12:29:52
Ja tutaj widzę naprawdę niezły potencjał użycia myszy. Dzięki temu można już symulować odbloki wszystkich nadmiarów w siódemce, czy nawet przy podłączaniu się na zewnątrz samemu węże podpinać w dowolnej kolejności.
@tmj, trzeba zatem teraz do exe dodać nowe komendy od nowych przełączników, cieszysz się? :D
Pierwsze od czego bym zaczął modyfikację sterowania lokomotywami to dodanie rozrządu do kabin. Dzięki myszy podniesie nam się realizm uruchamiania pojazdów.
Ficzer moim zdaniem działa w porządku. Zostawił bym go w takiej funkcjonalności bo w takiej zdaje egzamin. Jedynie co to przeniósł bym sterowanie zoomem na kółko od myszy, to ułatwi trafianie w konkretny przełącznik :).
Jedyne z czym ma problem "mysza" to przełączniki które uaktywniają się przy użyciu klawisza "shift + coś". Tak jest np. w EP09 i hamulcem postojowym czy zapalaniem podświetlenia ampero i mano.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Balaclava w 09 Lipca 2017, 12:42:58
Pewien pan dość często śmiał się z MaSzyny na fanpage facebookowym, że nie ma "klikalnego kokpitu", a grafika wygląda jak z epoki kamienia. Ciekawe do czego teraz się będzie przyczepiał :P
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: ST44-003 w 09 Lipca 2017, 12:56:44
Czy ja widzę tu także wprowadzenie "połysku" na modelach? :O
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: pinokio w 09 Lipca 2017, 13:09:31
 Świetna sprawa z myszką, teraz trzeba wiedzieć gdzie są odpowiednie przełączniki a nie tylko klikać klawiaturą.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 09 Lipca 2017, 13:14:53
Ficzer moim zdaniem działa w porządku. Zostawił bym go w takiej funkcjonalności bo w takiej zdaje egzamin. Jedynie co to przeniósł bym sterowanie zoomem na kółko od myszy, to ułatwi trafianie w konkretny przełącznik :).
Jedyne z czym ma problem "mysza" to przełączniki które uaktywniają się przy użyciu klawisza "shift + coś". Tak jest np. w EP09 i hamulcem postojowym czy zapalaniem podświetlenia ampero i mano.
W trybie obslugi mysza zoom jest 'zamrozony' wiec mozna radzic sobie troszke inaczej:
- w trybie zwyklym, wciskamy zoom i celujemy w pulpit, jesli jest za daleko
- wciskamy Alt by przejsc do trybu obslugi mysza.
- biezacy zoom jest 'zamrozony', mozemy puscic srodkowy przycisk i spokojnie celowac/klikac w wprzyciski
- po wylaczeniu trybu myszy ponownym wcisnieciem Alt zoom 'zwija sie' do standardowego poziomu automatycznie

przycisk podswietlania urzadzen jest jednym z kilku, ktore na ten moment nie sa obslugiwane przez mysz -- glownie dlatego ze zastanawiam sie, czy nie wprowadzic dedykowanego przycisku "oswietlenie przyrzadow" w .mmd by wyprostowac biezaca prowizorke z uniwersalem, ale nie wiem czy komus bedzie sie chcialo poprawiac pliki lokomotyw (choc teoretycznie poprawka to tylko jednorazowa operacja 'find&replace in files' w np. Notepad++ ;d

SM42-260, najnowsze exe.
Po użyciu przełącznika "OŚWIETLENIE BUDKI MASZYNISTY" zapala się światło a przełącznik znika.
Przelacznik ten animuje sie u mnie normalnie, ale nie pamietam czy nie robilem jakichs poprawek .mmd recznie. Sprawdz moze, czy w pliku errors jest jakas wzmianka o blednej wartosci skali dla submodelu?

edit:
Czy ja widzę tu także wprowadzenie "połysku" na modelach? :O
Tak, pojawilo sie kilka uaktualnien temu :>
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: dymus w 09 Lipca 2017, 18:54:39
Wersja 170708 zauważyłem coś takiego że amperomierze, jeśli zwiększa się prad na kolejnych pozycjach, to wskazówka najpierw normalnie się zachowuje (zwiększa się wskazanie prądu) ale następnie jest taki wyraźny skok wskazówki, w zasadzie takie drgnięcie w dórę, po czym wraca w dół, tam gdzie powinno być wskazanie. Ten sam efekt występuje przy zmniejszaniu prądu, jest zwykły spadek pradu jak zwykle, a następnie skok tym razem w dół, tak samo jak wcześniej, takie drgnięcie wskazówki. Coś takiego wcześniej nigdy nie występowało, a jest to widoczny efekt.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 09 Lipca 2017, 20:32:58
Troche to potrwalo, ale w dzisiejszym uaktualnieniu mamy w exe nastepny feature, a wlasciwie poltora:
- wprowadzona obsluga urzadzen kabiny przy uzyciu myszy...
ciach
Oniemiałem, takie rzeczy tylko w MaSzynie. Jestem pod wrażeniem i brak mi słów...
Mam jednak dwie uwagi; bardzo wolny ruch kołem nastawnika. Zjechanie do zera zajmuje bardzo dużo czasu, ale także dodawanie pozycji jest powolne, choć tu jakiejś potrzeby wielkiej nie ma. Może dodać do shift+ppm jako przyspieszacz tak jak w obsłudze klawiaturowej, Zjechanie do zera trwa ułamek sekundy. Druga sprawa, dość trudna obsługa kranu hamulca, za pierwszym razem przerżnąłem kilka s1. Zastanowił bym się nad zmianą lpm - hamowanie, ppm - luzowanie, jakoś intuicyjnie spodziewałem się takiej konfiguracji. Duży problemem, jest sięganie do potrzebnego przycisku, ze względu na zamrożenie kamery w trybie "myszowatym". Tak czy owak na plus, mimo, że do tej pory nie widziałem takiej obsługi MaSzyny.
Rewelacyjne podświetlanie nazw modeli w trybie debug mode przy pokazywaniu myszą.
Umarł Król, niech żyje Król.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mk1991 w 09 Lipca 2017, 21:01:53
Witam. Mam dwa pytania. Czy będzie możliwość zablokowania sobie sterowania myszą? Tak by przypadkowo sobie nie kliknąć skrótu i się nie zdezorientować? Podejrzewam, że teraz będzie możliwe włożenie klikalnych wszystkich możliwych przełączników. Czy za tym będzie mogła iść klawiszologia podzielona na sekcje zależne od miejsca, w którym się znajduję. Można przecież zrobić tak, że ten sam skrót w kabinie robi co innego kiedy zastosuje się go w przedziale maszynowym. Z tego co doczytałem docelowo plik skrótów klawiszowych ma zniknąć i być umieszczonym w exe, czy była by możliwość wpisu w EU07.ini komendy zezwalającej na korzystanie z własnego zewnętrznego pliku skrótów?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 09 Lipca 2017, 21:18:42
A może elementy wielopozycyjne jak nastawniki czy krany hamulców mogłyby reagować nie na kliknięcia, ale na "chwycenie" (wciśnięcie i przytrzymanie LPM) i przesunięcie myszy w górę lub w dół? Tylko np. dodawanie pozycji nastawnika jazdy musiałoby być ruchem w górę, a nastawnika bocznikowania ruchem w dół (do siebie w rzeczywistości). Wydaje mi się, że byłoby wygodniejsze, ale to tylko moje zdanie. Poza tym działa to świetnie :)
PS.: Wprowadzenie sterowania myszą mnie też do czegoś zmotywowało, ale o tym w swoim czasie...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mareczek w 09 Lipca 2017, 23:06:46
Wersja 170708 zauważyłem coś takiego że amperomierze, jeśli zwiększa się prad na kolejnych pozycjach, to wskazówka najpierw normalnie się zachowuje (zwiększa się wskazanie prądu) ale następnie jest taki wyraźny skok wskazówki, w zasadzie takie drgnięcie w dórę, po czym wraca w dół, tam gdzie powinno być wskazanie. Ten sam efekt występuje przy zmniejszaniu prądu, jest zwykły spadek pradu jak zwykle, a następnie skok tym razem w dół, tak samo jak wcześniej, takie drgnięcie wskazówki. Coś takiego wcześniej nigdy nie występowało, a jest to widoczny efekt.
Zauważyłem to samo we wcześniejsze wersji. Filmik z sytuacją:
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 09 Lipca 2017, 23:24:50
Witam.
 Dopiero teraz miałem czas na testy exe @Tmj z zaimplementowaną obsługą myszką. Działa jak najbardziej. Podobnie jak Krzysiek, intuicyjnie spodziewałem się odwrotnego sterowania kranem hamulca. Czy zamrożony obraz podczas przełączania w tryb myszki jest tylko chwilowo czy tak zostanie? Najlepiej byłoby gdyby jednak była możliwość ruchu kamery dół-góra, lewo-prawo. Nie wiem jak to wygląda od strony kodu, ale chyba najlepiej sprawdziłoby się sterownie kamerą po naciśnięciu i przytrzymaniu LPM, lub PPM, w obszarze w którym nie ma żadnych aktywnych włączników itp. Albo wprowadzić obsługę urządzeń za pomocą tylko jednego przycisku myszki, a drugiemu wtedy przypisać ruch kamery. Wtedy trzeba by zastosować sterowanie kranem hamulca, nastawnikiem i nawrotnikiem nie poprzez klikanie, a przeciągnięcie w żądanym kierunku.
To na tyle moich wywodów.
Pozdrawiam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 09 Lipca 2017, 23:34:15
Kaliska zaliczona na najnowszym exe. Zauwazylem zrywy grafiki na ułamek sekundy jak się cos nowego w terenie pojawia. Bledow w wyświetlaniu grafiki nie stwierdzam bądź nie zauwazylem. Kaliska na szlaku około 80 fps na stacjach około 30- 45 fps. MOtyw klikania mysza rewelacyjny, jednak niestety element animowany musi "wklepany" w exe. Nie da się animować czyms, co nie jest zdefiniowane. Czy dalo by się z poziomu mmd wprowadzić animacje elementow? Okna szafki drzewi itp. Oraz zapalac pseudo oświetlenia typu osw rozkładu itp.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 10 Lipca 2017, 00:11:08
Wlodek, bardzo gonisz do przodu. Trzeba przemyslec to co teraz mamy, a to co proponujesz dorabiac sukcesywnie. Zryw grafiki jest zludzeniem z powodu przerzucania danych z pamieci karty graficznej w trakcie symulacji. Jest zludzeniem "bo chwile wczesniej nastepuje przyciecie i exe przesuwa symulacje o jego spoznony fragment".
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 10 Lipca 2017, 00:54:22
W dzisiejszym uaktualnieniu:

- po wcisnieciu przycisku myszy komendy powtarzane sa z wieksza czestotliwoscia, w efekcie urzadzenia jak nastawnik czy hamulec obslugiwane sa szybciej. Dodatkowo dla urzadzen tych uwzgledniane jest wcisniecie klawisza Shift

- w trybie obslugi mysza wcisniecie prawego przycisku myszy na nieaktywnym obszarze pozwala na obrot kamera, dopoki przycisk pozostaje wcisniety

- klawisze obslugi hamulcow maja teraz odwrocona funkcje (lewy przycisk zwieksza hamowanie, prawy zmniejsza)  Oryginalnie zamyslem bylo, ze lewy przycisk "zwieksza predkosc" pojazdu a prawy ja zmniejsza, ale w praktyce faktycznie jest to malo intuicyjne

- sterowanie mysza moze byc zablokowane wpisem w ini
mousecontrol no
(wartosc domyslna to mousecontrol yes czyli domyslnie mysz jest obslugiwana i nie wymaga dodatkowych wpisow)

Podejrzewam, że teraz będzie możliwe włożenie klikalnych wszystkich możliwych przełączników. Czy za tym będzie mogła iść klawiszologia podzielona na sekcje zależne od miejsca, w którym się znajduję. Można przecież zrobić tak, że ten sam skrót w kabinie robi co innego kiedy zastosuje się go w przedziale maszynowym. Z tego co doczytałem docelowo plik skrótów klawiszowych ma zniknąć i być umieszczonym w exe, czy była by możliwość wpisu w EU07.ini komendy zezwalającej na korzystanie z własnego zewnętrznego pliku skrótów?
Klawiszologia zalezna od pomieszczenia w ktorym sie znajdujemy jest w planach, chociaz dopiero po przeorganizowaniu definicji i obslugi kabin w ogole. Co do skrotow, to plan jest taki, ze skroty bedzie mozna definiowac z poziomu exe, natomiast nie oznacza to eliminacji pliku skrotow -- w pliku docelowo zapisywana jest, i z niego tez ladowana jest konfiguracja, wiec nie zniknie on, i bedzie go mozna nadal modyfikowac 'recznie' jesli tak jest wygodniej.

Zauważyłem to samo we wcześniejsze wersji. Filmik z sytuacją:
To prawdopodobnie efekt drobnej optymalizacji wprowadzonej jakis czas temu. Zmniejszylem jej czulosc, jesli efekt dalej wystepuje, prosze krzyczec.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mareczek w 10 Lipca 2017, 01:19:18
Zauważyłem to samo we wcześniejsze wersji. Filmik z sytuacją:
To prawdopodobnie efekt drobnej optymalizacji wprowadzonej jakis czas temu. Zmniejszylem jej czulosc, jesli efekt dalej wystepuje, prosze krzyczec.
"Much better, thank you Aziz"
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 10 Lipca 2017, 11:03:21
Cytuj
W dzisiejszym uaktualnieniu:...
nastawnik czy hamulec obslugiwane sa szybciej. Dodatkowo dla urzadzen tych uwzgledniane jest wcisniecie klawisza Shift....
Mam wrażenie, że sam miałeś to w planach. :) Czas reakcji tak szybki, że aż nieprawdopodobny.
LPM i PPM pomyślany był logicznie, po stwierdzeniu że nie jest intuicyjnie, zastanawiałem się nad Twoim wyborem. Wyszło mi to napisałeś, jako logiczne następstwo. Jednak zmiana przycisku między zejściem nastawnika do zera a rozpoczęciem hamowania jest wyzwaniem.
Bardzo fajna decyzja wprowadzenia blokady do ini, uniemożliwia "niechcące" zmiany sterowania dla osób z problemem obsługi. Co do wyeliminowania pliku skrótów, to tak wynikało z wcześniejszych deklaracjo o jego tymczasowości.
Wcześniejszy mój post: 20,30 - odpowiedź 00,54, czas reakcji 4,5 godziny.
Off; Na zmiany zgodne z oczekiwaniami wielu użytkowników, nie tylko garstki deweloperów czekaliśmy kilka lat.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 10 Lipca 2017, 20:03:28
Obsługa wyłączników - super. Sterowanie kranem hamulca w ten sposób - nie bardzo.  Jak pociąg jedzie szybko, to kabiną buja i jest problem z przesuwaniem się punktu na którym ma być kursor, żeby to działało. Do tego - to działa za wolno albo za szybko, w zależności od sytuacji. O hamowaniu awaryjnym czy nawet przyśpieszonym nie ma mowy. Do tego po prostu niewygodne i tyle.

A co gdyby tak wprowadzić obsługę rolki? Rolka od siebie - zwiększanie mocy (zwiększanie hamowania), do siebie zmniejszanie. To miałoby sens i umożliwiałoby płynną, intuicyjną obsługę. Dodatkowo większość rolek ma wyczuwalny "klik" przy dawaniu impulsu. 1 "ząbek" rolki dawałby jeden "ząbek" nastawnika. A najlepiej - gdyby wystarczyło kliknąć na kran albo nastawnik, a od tej pory rolka myszy obsługiwałaby ten element. Jakiś klawisz (może alt, można sobie wcisnąć 2 razy żeby nie wyłączać sterowania myszą, mógłby kasować obsługę elementu rolką myszy). Obsługa kranu i nastawnika przyciskami myszy jest zdecydowanie mniej użyteczna czy wygodna niż obsługa z klawiatury.

Inny sposób - trzymam przycisk wciśnięty i od siebie zwiększam, do siebie zmniejszam nastawę. Dopóki nie puszczam przycisku - regulacja jest wybrana. To zapobiegałoby sytuacji, że kursor mi zjedzie jak bujnie kabiną. Dodatkowo regulacja położeniem myszy jest daleko bardziej precyzyjna i szybkość regulacji zależy od szybkości wykonania gestu.

Co do obsługi przycisków w kabinie - tu się wszystkiego od razu nie da, ale fajnie byłoby zerżnąć z TD2 otwieraną klapkę w siódemce do włączania baterii ;) No i rozrząd dołożyć, ale to pewnie więcej zabawy. W testowanej 424 nie działały przyciski do świateł wewnętrznych. Tzn. nie działały z myszy, bo z klawiatury dało się włączać oświetlenie przyrządów i kabiny bez problemu.

Na marginesie: zmartwiło mnie zacinanie tej wersji exe w porównaniu z przykładowo 170603. Po prostu od czasu do czasu symulacja zwyczajnie zacina, zatrzymuje się na chwilę. Nawet na TD.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 10 Lipca 2017, 20:24:20
Nie widze rolki w takim uzytkowaniu. Nawet jak masz sterowanie mysza, to nadal uzyc mozna klawiatury, wiec wprowadzanie rolki nie spelni oczekiwan. Docelowo mysz powinna miec dwie rolki bo elementow obrotowych jest wiecej. Wymienienie tylko kranu hamulca jest dziwne, przeciez jak buja trudnosc w trafieni jest taka sam dla odluzniacza, czuwaka czy innego sprzetu. Co do zacinania, masz ewidentnie cos z ustawieniami komputera. Od kilku dni katuje bez pliku wymiany i nie mam zadnych przyciec. Na wylaczonym swapie wystacza mi 3,25 gb pamieci ram w winxp x86.
Skrot klawiszowy alt+ tab - przelaczanie okien w windows, powoduje przelacznie sterowania klawiatura/mysz. Mozna sie zastanowic nad ominieciem tego.
Mam dalszy wzrost fps na Kaliskiej, brak wysypow.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 10 Lipca 2017, 20:57:37
Inny sposób - trzymam przycisk wciśnięty i od siebie zwiększam, do siebie zmniejszam nastawę. Dopóki nie puszczam przycisku - regulacja jest wybrana. To zapobiegałoby sytuacji, że kursor mi zjedzie jak bujnie kabiną.
Zapewne nie zwrociles uwagi, ale po aktywacji urzadzenia kliknieciem tak dlugo jak przycisk jest wcisniety nie ma znaczenia czy kursor ci "zjedzie" -- aktywacja jest kontyuowana dopoki nie puscisz przycisku :>

Prawdopodobnie mozna pomyslec o czyms w stylu regulacji predkosci operowania urzadzeniem na podstawie np odsuniecia myszy w pionie od punktu w ktorym nastapilo klikniecie, zobacze jak to sie sprawdzi.

Obsluga swiatel kabiny powinna dzialac, natomiast na ten moment nieobslugiwane sa urzadzenia "uniwersalne" pod ktore podpada oswietlenie przyrzadow. Bedzie dodane.

[qoute]Na marginesie: zmartwiło mnie zacinanie tej wersji exe w porównaniu z przykładowo 170603. Po prostu od czasu do czasu symulacja zwyczajnie zacina, zatrzymuje się na chwilę. Nawet na TD.
[/quote]
Przyciecie wiaze sie z tym, ze tekstury sa teraz wrzucane do pamieci karty graficznej dopiero w momencie gdy sa faktycznie potrzebne, zamiast z gory jak poprzednio. Tak wiec faktycznie moze to nastapic nawet na TD gdy mamy tam dlugi sklad, i spojrzymy sobie po raz pierwszy w kierunku kilku(nastu) wagonow, kazdy z innymi teksturami. Ewentualnie sie to wyprostuje, ale jeszcze nie teraz.

W miedzyczasie, male uaktualnienie:

- sprezarka w pojazdach typu DieselEngine, skonfigurowana jako spieta z silnikiem, startuje automatycznie bez potrzeby recznego zalaczania, a jej wydajnosc uzalezniona jest od obrotow silnika

- drobna zmiana obslugi ekranu ladowania, w przygotowaniu do szykujacych sie zmian tychze

Plus, z zupelnie innej beczki:

na ta chwile podpisy urzadzen kontrolowanych mysza sa w jezyku angielskim. Dla wprowadzenia wersji polskiej przydaloby sie bardzo, gdyby wypowiedzialy sie osoby znajace sie na terminologii, zeby potem nie bylo ze cos nie nazywa sie jak powinno :P

lista urzadzen jest nastepujaca:
    { "mainctrl:", "master controller" },
    { "scndctrl:", "second controller" },
    { "dirkey:" , "reverser" },
    { "brakectrl:", "train brake" },
    { "localbrake:", "independent brake" },
    { "manualbrake:", "manual brake" },
    { "brakeprofile_sw:", "brake acting speed" },
    { "brakeprofileg_sw:", "brake acting speed: cargo" },
    { "brakeprofiler_sw:", "brake acting speed: rapid" },
    { "maxcurrent_sw:", "motor overload relay threshold" },
    { "main_off_bt:", "line breaker" },
    { "main_on_bt:", "line breaker" },
    { "security_reset_bt:", "alerter" },
    { "releaser_bt:", "independent brake releaser" },
    { "sand_bt:", "sandbox" },
    { "antislip_bt:", "wheelspin brake" },
    { "horn_bt:", "horn" },
    { "hornlow_bt:", "low tone horn" },
    { "hornhigh_bt:", "high tone horn" },
    { "fuse_bt:", "motor overload relay reset" },
    { "converterfuse_bt:", "converter overload relay reset" },
    { "stlinoff_bt:", "motor connectors" },
    { "door_left_sw:", "left door" },
    { "door_right_sw:", "right door" },
    { "departure_signal_bt:", "departure signal" },
    { "upperlight_sw:", "upper headlight" },
    { "leftlight_sw:", "left headlight" },
    { "rightlight_sw:", "right headlight" },
    { "dimheadlights_sw:", "headlights dimmer" },
    { "leftend_sw:", "left marker light" },
    { "rightend_sw:", "right marker light" },
    { "lights_sw:", "light pattern" },
    { "rearupperlight_sw:", "rear upper headlight" },
    { "rearleftlight_sw:", "rear left headlight" },
    { "rearrightlight_sw:", "rear right headlight" },
    { "rearleftend_sw:", "rear left marker light" },
    { "rearrightend_sw:",  "rear right marker light" },
    { "compressor_sw:", "compressor" },
    { "compressorlocal_sw:", "local compressor" },
    { "converter_sw:", "converter" },
    { "converterlocal_sw:", "local converter" },
    { "converteroff_sw:", "converter" },
    { "main_sw:", "line breaker" },
    { "radio_sw:", "radio" },
    { "pantfront_sw:", "front pantograph" },
    { "pantrear_sw:", "rear pantograph" },
    { "pantfrontoff_sw:", "front pantograph" },
    { "pantrearoff_sw:", "rear pantograph" },
    { "pantalloff_sw:", "all pantographs" },
    { "pantselected_sw:", "selected pantograph" },
    { "pantselectedoff_sw:", "selected pantograph" },
    { "trainheating_sw:", "heating" },
    { "signalling_sw:", "braking indicator" },
    { "door_signalling_sw:", "door locking" },
    { "nextcurrent_sw:", "current indicator source" },
    { "cablight_sw:", "interior light" },
    { "cablightdim_sw:", "interior light dimmer" },
    { "battery_sw:", "battery" }
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 10 Lipca 2017, 20:58:30
tmj: powinno być ustawienie w ini do gc tekstur, bo jak ktoś ma wystarczająco vramu to robi więcej szkody niż pożytku.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 10 Lipca 2017, 21:02:48
W sumie mozna dac, na pewno prostsze od asynchronicznego uploadu i jedno drugiemu nie przeszkodzi. Dodam do listy, powinno sie zmiescic w nastepnej wersji.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 10 Lipca 2017, 23:45:26
lista urzadzen jest nastepujaca:

Tak na szybko, ale przyznam że z niektórymi bez wiedzy jak to jest zaszyte w exe to ciężko odgadnąć "co autor miał na myśli".

    { "mainctrl:", "master controller" }, //nastawnik jazdy
    { "scndctrl:", "second controller" }, //dzwignia bocznikowania
    { "dirkey:" , "reverser" }, //nastawnik kierunkowy
    { "brakectrl:", "train brake" }, //zawor hamulca zespolonego
    { "localbrake:", "independent brake" }, //zawor hamulca dodatkowego
    { "manualbrake:", "manual brake" }, //hamulec reczny
    { "brakeprofile_sw:", "brake acting speed" }, //nastawa hamulca (domniemam po braku opisow nizej, ze moze chodzic tu o nastawe hamulca P: osobowy)
    { "brakeprofileg_sw:", "brake acting speed: cargo" }, //nastawa hamulca G: towarowy
    { "brakeprofiler_sw:", "brake acting speed: rapid" }, //nastawa hamulca R: rapid
    { "maxcurrent_sw:", "motor overload relay threshold" }, //przelacznik pradu rozruchu
    { "main_off_bt:", "line breaker" }, //wylacznik szybki wylaczony
    { "main_on_bt:", "line breaker" }, //wylacznik szybki zalaczony
    { "security_reset_bt:", "alerter" }, //przycisk czuwaka / shp (przy czym dla traxxow i pochodnych trzeba to rozdzielic - jednym nie zbijemy drugiego i odwrotnie)
    { "releaser_bt:", "independent brake releaser" }, //odluzniacz
    { "sand_bt:", "sandbox" }, //piasecznica
    { "antislip_bt:", "wheelspin brake" }, //przeciwposlizg
    { "horn_bt:", "horn" }, //syrena
    { "hornlow_bt:", "low tone horn" }, //syrena niskotonowa
    { "hornhigh_bt:", "high tone horn" }, //syrena wysokotonowa
    { "fuse_bt:", "motor overload relay reset" }, //odblok przekaznika nadmiarowego silnikow trakcyjnych
    { "converterfuse_bt:", "converter overload relay reset" }, //odblok przekaznika nadmiarowego przetwornicy glownej
    { "stlinoff_bt:", "motor connectors" }, //styczniki liniowe
    { "door_left_sw:", "left door" }, //drzwi lewe
    { "door_right_sw:", "right door" }, //drzwi prawe
    { "departure_signal_bt:", "departure signal" }, //sygnal odjazdu
    { "upperlight_sw:", "upper headlight" }, //reflektor gorny
    { "leftlight_sw:", "left headlight" }, //reflektor lewy
    { "rightlight_sw:", "right headlight" }, //reflektor prawy
    { "dimheadlights_sw:", "headlights dimmer" }, //przyciemnienie reflektorow
    { "leftend_sw:", "left marker light" }, //reflektor lewy czerowny
    { "rightend_sw:", "right marker light" }, //reflektor prawy czerwony
    { "lights_sw:", "light pattern" }, //przelacznik swiatel (programator)?
    { "rearupperlight_sw:", "rear upper headlight" }, //to samo co poprzednio, tylko rozdzielone na inna kabine
    { "rearleftlight_sw:", "rear left headlight" },
    { "rearrightlight_sw:", "rear right headlight" },
    { "rearleftend_sw:", "rear left marker light" },
    { "rearrightend_sw:",  "rear right marker light" },
    { "compressor_sw:", "compressor" }, //sprezarka glowna
    { "compressorlocal_sw:", "local compressor" }, //sprezarka (w czlonie sterujacym ET42)
    { "converter_sw:", "converter" }, //przetwornica glowna
    { "converterlocal_sw:", "local converter" }, //przetwornica (w czlonie sterujacym ET42)
    { "converteroff_sw:", "converter" }, //wylaczenie przetwornicy glownej (zalezy od taboru, bywa ze razem jest z odblokiem)
    { "main_sw:", "line breaker" }, //wylacznik szybki
    { "radio_sw:", "radio" }, //radiotelefon
    { "pantfront_sw:", "front pantograph" }, //pantograf przedni
    { "pantrear_sw:", "rear pantograph" }, //pantograf tylny
    { "pantfrontoff_sw:", "front pantograph" }, //pantograf przedni opuszczony
    { "pantrearoff_sw:", "rear pantograph" }, //pantograf tylny opuszczony
    { "pantalloff_sw:", "all pantographs" }, //wszystkie pantografy opuszczone
    { "pantselected_sw:", "selected pantograph" }, //wybrany pantograf ?
    { "pantselectedoff_sw:", "selected pantograph" }, //wybrany pantograf opuszczony ?
    { "trainheating_sw:", "heating" }, //ogrzewanie pociagu (w en57 powinno byc ogrzewanie przedzialow pasazerskich, a osobno powinien tez byc hebel od ogrzewania kabin)
    { "signalling_sw:", "braking indicator" }, //lampka "hamowanie ostatniego wagonu" ED72
    { "door_signalling_sw:", "door locking" }, // blokada drzwi
    { "nextcurrent_sw:", "current indicator source" }, // amperomierz drugiego czlonu ET41
    { "cablight_sw:", "interior light" }, //oswietlenie kabiny
    { "cablightdim_sw:", "interior light dimmer" }, //przyciemnienie oswietlenia kabiny
    { "battery_sw:", "battery" } //bateria akumulatorow
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 10 Lipca 2017, 23:51:47
Rozdzielić czuwak od shp próbowałem i poległem. Częściowo dlatego, że uparłem się na alt+space. Zgłoszenie wisi gdzieś w bugtrackerze.

{ "compressorlocal_sw:", "local compressor" }, //sprezarka pantografow
{ "converterlocal_sw:", "local converter" }, //czyzby przetwornica oswietleniowa w starych en57?
To maszyny członu sterującego dla ET42.
{ "trainheating_sw:", "heating" }, //ogrzewanie pociagu (w en57 powinno byc ogrzewanie przedzialow pasazerskich, a osobno powinien tez byc hebel od ogrzewania kabin)To to większość lokomotyw ma. Plus ogrzewanie nóg, szyby, itp. Bez LD nie ma co się w obciążanie obwodu nn bawić raczej.
{ "signalling_sw:", "braking indicator" }, //manometrySygnalizacja hamowania drugiego EZT (ED72)
{ "door_signalling_sw:", "door locking" }, // ?Sygnalizacja blokady drzwi (ED72, EN57-2000)
{ "nextcurrent_sw:", "current indicator source" }, //?Pokazywanie prądu drugiego członu (ET41)

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mk1991 w 11 Lipca 2017, 00:00:07
Ja przy tworzeniu dźwięków zauważyłem potrzebę rozdzielenia pośrednich pozycji nastawnika jazdy i bocznikowania od krańcowych z tym, że dźwięk pozycji końcowych uaktywniał by się zależnie od tego w którą stronę kręcimy nastawnikiem jazdy czy manipulujemy bocznikami. Pierwsza pozycja tu i tu była by zawsze odtwarzana przez próbkę dźwięku nastawy pośredniej, końcowa pozycja i w górę i w dół była by realizowana przez dźwięk nastawy końcowej. Chodzi mi o to dosadne walnięcie przy końcu kręcenia kołem i bocznikowania. Tego nie mamy, a to jest bardzo słyszalne.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 11 Lipca 2017, 00:03:13
{ "compressorlocal_sw:", "local compressor" }, //sprezarka pantografow
{ "converterlocal_sw:", "local converter" }, //czyzby przetwornica oswietleniowa w starych en57?
To maszyny członu sterującego dla ET42.

Ok.

Cytuj
{ "trainheating_sw:", "heating" }, //ogrzewanie pociagu (w en57 powinno byc ogrzewanie przedzialow pasazerskich, a osobno powinien tez byc hebel od ogrzewania kabin)To to większość lokomotyw ma. Plus ogrzewanie nóg, szyby, itp. Bez LD nie ma co się w obciążanie obwodu nn bawić raczej.

Akurat pisząc o kabinowych miałem na myśli ogół pojazdów, a nie że w EN57. W sensie, że w tym opisie nie ma hebla dla kabinowego grzania ;)

Cytuj
{ "signalling_sw:", "braking indicator" }, //manometrySygnalizacja hamowania drugiego EZT (ED72)
Ok. Już dopatrzyłem.

Cytuj
{ "door_signalling_sw:", "door locking" }, // ?Sygnalizacja blokady drzwi (ED72, EN57-2000)

Teraz to już wszystkie pojazdy muszą mieć bezwzględnie blokadę drzwi. Nawet stare EN57 i one sygnalizację też mają.

Cytuj
{ "nextcurrent_sw:", "current indicator source" }, //?Pokazywanie prądu drugiego członu (ET41)
Ok.

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Lorem w 11 Lipca 2017, 10:19:15
Kilka tygodni mnie nie było i pojawiło się sterowanie myszą. Cóż za pozytywny szok.

Z tym sterowaniem myszą zauważyłem jeden problem. Mysz reaguje tylko na submodel wpisany w mmd. Objawia się to tym, że - na przykładzie 303e-tv - aby obrócić nastawnikiem, trzeba trafić myszą w jego podstawę, czyli nastawnikpodst. Gdy spróbować "chwycić" za samo koło, czyli kolo_nast - reakcji nie ma. Podobnie z kranem hamulca - trzeba wycelować w tę płaską część (zasadniczy), chwycenie za kapturek lub rączkę nie działa (odpowiednio glowka i raczkakranu).
Wydaje mi się, że trzeba by było, aby mysz łapała submodel wpisany w mmd wraz z całym jego poddrzewem, które animuje się razem z nim.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: matek123 w 11 Lipca 2017, 11:35:24
Wydaje mi się, że można zrobić "niewidzialne" bryły stanowiące obrys nastawnika i rączek kranów, żeby łatwiej było sterować. Ale niech @Tmj się wypowie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 11 Lipca 2017, 12:40:09
Wydaje mi się, że trzeba by było, aby mysz łapała submodel wpisany w mmd wraz z całym jego poddrzewem, które animuje się razem z nim.
To raczej kwestia poprawnej budowy modeli -- bryly tworzace logiczny element powinny byc scalone w jeden obiekt, rowniez dla poprawy wydajnosci.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 11 Lipca 2017, 13:03:53
Zazwyczaj jest to wymuszone użyciem wielu tekstur na nastawnik/kran.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: dymus w 11 Lipca 2017, 13:06:00
Prawda, tylko logika tworzenia nastawników np. w siódemkach to że inne tex podstawy inna nastawnika, to samo kran hamulca, rączka inna tex, główka inna środek jeszcze inna. Kiedyś po prostu był taki styl/moda czy coś?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 11 Lipca 2017, 13:26:19
Zazwyczaj jest to wymuszone użyciem wielu tekstur na nastawnik/kran.
Nie wymuszone, bo nikt autora do uzycia wielu tekstur zamiast polaczyc je w jedna nie zmuszal. To konsekwencja lenistwa jest, i tyle ;P

(troche bardziej serio to zakladam, ze kiedys wydawalo sie ze lepiej miec np 10 malych tekstur niz 2 troche wieksze, ale to i wtedy, i teraz nie byla prawda... a efekty zostaly)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: RoboBatman w 11 Lipca 2017, 13:29:53
Chcę zgłosić usterkę w najnowszym exe z dnia 10 lipca 2017, polegającą na tym, że nie działa testowanie CA poprzez wciśnięcie go na dłuższy czas w trybie obsługi myszą w lokomotywie EU07-15xx. W trybie obsługi klawiaturowej, wciska się spację i po paru sekundach testowanie CA objawia sie migającym czerwonym światełkiem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 11 Lipca 2017, 13:32:46
Z tego co sprawdzalem to u mnie dziala, ale reakcja pojawia sie przy trzymaniu przycisku przez okres nieco dluzszy, niz z klawiatury?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: RoboBatman w 11 Lipca 2017, 13:40:21
Teraz po twojej sugestii "przez okres nieco dłuższy niż z klawiatury" działa, ale zawsze zdawało mi się, że nie powinno być tak dużej zwłoki w testowaniu światełek.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 11 Lipca 2017, 13:47:15
Predkosc dzialania nie jest w tej chwili ujednolicona, bo zalezy od predkosci powtarzania komendy a ta jest nieco mniejsza dla myszy. Wczesniej gdy byla tylko klawiatura nie przeszkadzalo to, ale teraz jest do ogarniecia.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: matek123 w 11 Lipca 2017, 15:56:06
@Tmj, czy jest szansa na dodanie obsługi pakiecików 3 pozycyjnych? Końcówka - 0 - białe. Przydałoby się to do niektórych siódemek. Coś na zasadzie jak teraz syrena działa.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 11 Lipca 2017, 16:12:30
Jest w planach, przy okazji reorganizacji obslugi kabin, kiedy juz do tego dojdzie. Moze troche wczesniej, zobaczymy, bo plany na razie nie sa zbyt konkretne.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 11 Lipca 2017, 16:13:39
Nie widze rolki w takim uzytkowaniu. Nawet jak masz sterowanie mysza, to nadal uzyc mozna klawiatury, wiec wprowadzanie rolki nie spelni oczekiwan.
Zupełnie nie rozumiem. Co ma klawiatura do sterowania myszą? Sterowanie klawiaturą jest OK.
Sterowanie myszą jest zbyt nieprecyzyjne. Stała prędkość regulacji po prostu nie nadaje się do sterowania kranem i nastawnikiem. Te elementy raz regulujesz bardzo szybko, raz delikatnie, zależnie od potrzeby. Sterowanie klawiaturą jest tu idealne. Sterowanie myszą nie, dlatego myślę, że obsługa rolki mogłaby pomóc.

Docelowo mysz powinna miec dwie rolki bo elementow obrotowych jest wiecej.
Pomyślałem o tym: wystarczy jedna rolka. Klikasz element - tym samym przypisujesz sterowanie rolką do niego. Kliknąłeś nastawnik, od teraz kręcenie rolką steruje nastawnikiem. Kliknąłeś hamulec pomocniczy, od teraz rolka myszy steruje nastawą kranu hamulca pomocniczego.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 11 Lipca 2017, 16:24:03
Stała prędkość regulacji po prostu nie nadaje się do sterowania kranem i nastawnikiem. Te elementy raz regulujesz bardzo szybko, raz delikatnie, zależnie od potrzeby. Sterowanie klawiaturą jest tu idealne. Sterowanie myszą nie, dlatego myślę, że obsługa rolki mogłaby pomóc.
W kwestii formalnej -- sterowanie nastawnikiem i kranem z klawiatury rowniez odbywa sie ze stala predkoscia. Nie bardzo widze dlaczego wcisniecie '+' lub '-' na klawiaturze zeby krecic nastawnikiem jest idealne, ale wcisniecie lewego/prawego przycisku myszy by tak samo krecic tym nastawnikiem, to juz nie ;>  To samo dotyczy kranu, chociaz tutaj zdaje sobie sprawe ze roznice robia dodatkowe 'skroty' dla konkretnych pozycji hamowania.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: bohunIC w 11 Lipca 2017, 16:30:34
Z ciekawosci zadam pytanie, bo widze dwa fronty prac, czy oba exe zostana polaczone w jedno?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 11 Lipca 2017, 16:31:03
Cytuj
Te elementy raz regulujesz bardzo szybko, raz delikatnie, zależnie od potrzeby...
To miałem na myśli, dlatego napisałem, że w trakcie sterowania myszą działa też sterowanie klawiaturą. I to klawiaturą należy się posługiwać kręcąc kranem i kołem nastawnika. Także nic innego nie mamy na myśli.  Za to jeśli się uda doprecyzować działanie kursora i sterowanych elementów, a także prędkości powtarzania, to jeszcze lepiej.
Taka dygresja ode mnie: Lokomotywy powinny dać się uruchomić z klawiatury bez użycia myszy (jako alternatywa). Całkowitego przejścia na mysz nie widzę, są niepełnosprawni w śród nas, którzy z tym sposobem sterowania nie poradzą sobie. Nie chodzi czy coś jest idealne, tylko czy się sprawdzi dla wszystkich.
Z ciekawosci zadam pytanie, bo widze dwa fronty prac, czy oba exe zostana polaczone w jedno?
Nie ma dwóch frontów prac. @Milek7 wprowadza swoje zmiany na źródłach od @tmj. Pracują na jeden wynik.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 11 Lipca 2017, 16:39:59
To samo dotyczy kranu, chociaz tutaj zdaje sobie sprawe ze roznice robia dodatkowe 'skroty' dla konkretnych pozycji hamowania.
Hmm, dziwne, za moich czasów zawór FV4a działał bezstopniowo - pozycja płynnie zmieniała się w zakresie od -1 do 6 w miarę trzymania klawisza Num 3 i Num 9.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Sawi w 11 Lipca 2017, 16:41:20
Krzysiu dlatego właśnie @tmj dodał ten wpis do ini by sobie każdy mógł indywidualnie sam wybrać.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 11 Lipca 2017, 16:46:39
Hmm, dziwne, za moich czasów zawór FV4a działał bezstopniowo - pozycja płynnie zmieniała się w zakresie od -1 do 6 w miarę trzymania klawisza Num 3 i Num 9.
Nadal tak dziala :>  ale dodatkowo jest przeskok do konkretnych polozen pod 8/5/2 co jest czesto szybsze niz wcisniecie 3/9 i czekanie az sie przesunie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 11 Lipca 2017, 17:00:56
Taka dygresja ode mnie: Lokomotywy powinny dać się uruchomić z klawiatury bez użycia myszy (jako alternatywa). Całkowitego przejścia na mysz nie widzę, są niepełnosprawni w śród nas, którzy z tym sposobem sterowania nie poradzą sobie. Nie chodzi czy coś jest idealne, tylko czy się sprawdzi dla wszystkich.
Racja, więc jeśli zostanie dodane coś ważnego przy uruchamianiu lokomotywy (np. wyłącznik rozrządu, bez którego w rzeczywistości nie podniesie się nawet pantografów), to i tak musi mieć przypisany jakiś skrót klawiaturowy. Chyba o to chodziło @Sawi, a nie o samą możliwość wyłączenia sterowania myszą, żeby sobie przypadkiem "Altu" nie wcisnąć.

Edit:
    { "brakeprofile_sw:", "brake acting speed" }, //nastawa hamulca (domniemam po braku opisow nizej, ze moze chodzic tu o nastawe hamulca P: osobowy)
    { "brakeprofileg_sw:", "brake acting speed: cargo" }, //nastawa hamulca G: towarowy
    { "brakeprofiler_sw:", "brake acting speed: rapid" }, //nastawa hamulca R: rapid
Przypuszczam, że chodzi tu po prostu o "przełącznik nastawy hamulca" jaki jest np. w EU07, gdzie jest jeden pakieciak do trzech nastaw, a w niektórych lokomotywach (np. SU45, SU46) są hebelki osobno od nastawy towarowej i osobno od pospiesznej podpisanej jako "hamowanie dwustopniowe" (te dwie linijki niżej).
    { "antislip_bt:", "wheelspin brake" }, //przeciwposlizg
    { "stlinoff_bt:", "motor connectors" }, //styczniki liniowe
Tu bym dał odpowiednio "przyhamowanie przy poślizgu" i "wyłączenie styczników liniowych", ale to akurat taki szczegół.
    { "rearupperlight_sw:", "rear upper headlight" }, //to samo co poprzednio, tylko rozdzielone na inna kabine
    { "rearleftlight_sw:", "rear left headlight" },
    { "rearrightlight_sw:", "rear right headlight" },
    { "rearleftend_sw:", "rear left marker light" },
    { "rearrightend_sw:",  "rear right marker light" },
A tu pewnie chodzi nie tyle o drugą kabinę, co o reflektory tylne jak np. w SM42, gdzie wszystkimi steruje się z jednego pulpitu, więc mogłoby być np. kolejno: "reflektor górny tył", "reflektor lewy tył", "reflektor prawy tył", "sygnał czerwony lewy tył" i "sygnał czerwony prawy tył".
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 12 Lipca 2017, 01:16:25
Krzysiu dlatego właśnie @tmj dodał ten wpis do ini by sobie każdy mógł indywidualnie sam wybrać.
Dodanie tego do ini miało zapobiec nieumyślnym przełączeniom na prośbę MK1991, co zresztą popieram. Natomiast nie rozwiązuje to sprawy gdybyśmy chcieli jednak część włączników zostawić tylko do obsługi myszą (przedział maszynowy z uruchomieniem od zera). Jedna opcja to tak jak napisał @miko22. Druga opcja w takiej sytuacji, to wspomożenie obsługi przez AI, gdzie automat zastąpi nas po części w uruchomieniu lokomotywy (włączenie potrzebnych urządzeń do rozpoczęcia jazdy).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Irek_Wd w 12 Lipca 2017, 12:30:53
Nie wiem, czy poświaty semaforów i tarcz tak mają wyglądać. Z daleka to jeszcze pół biedy, ale z bliska wygląda to fatalnie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 12 Lipca 2017, 12:38:27
Loading common gfx data...
Texture file missing: "fx\lightglare"
Texture file missing: "fx\sun"
Texture file missing: "fx\moon"
Nie masz paczki z assetami. EU07-data w wątku przyklejonym.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Irek_Wd w 12 Lipca 2017, 12:56:12
Co ciekawe mam aktualnego Visual C++. A o jakie dokładnie Bassety chodzi i w jakim przyklejonym wątku ich szukać? Nadal nie wiem. Ok. Już nieaktualne.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 12 Lipca 2017, 18:10:51
W dzisiejszym uaktualnieniu troche ulepszymy, troche spie..my:

- operowanie mysza elementami takimi jak nastawnik i hamulec odbywa sie teraz ze zmienna predkoscia: po wcisnieciu przycisku obslugi zmiana stanu urzadzenia odbywa sie tym szybciej, im dalej odsuniemy mysz od punktu w ktorym byla w momencie wcisniecia (kierunke przesuniecia nie ma znaczenia, moze byc w gore, w bok, jak komu wygodniej)

- uwzglednione w obsludze mysza: przelacznik oswietlenia urzadzen, i "uniwersale" Tutaj uwaga, bo zaszly przy okazji pewne zmiany:

- liczba elementow typu "universal" zostala zwiekszona do 10. Definiowane sa w pliku .mmd jak dotychczas wpisami "universal0:", "universal1:" itp. az do "universal9:" Obsluga tych elementow zostala zunifikowana uproszczona do przelaczania miedzy dwoma stanami, i wywolywana jest za posrednictwem myszy, lub klawiszami 0-9 W zalozeniu daje to mozliwosc wprowadzenia pewnej liczby elementow "ozdobnych" typu drzwi, drzwi do szaf, okna itp ktore otwiera sie i zamyka, bez dalszych efektow ubocznych

- uwaga w zwiazku z powyzsza zmiana: oswietlenie urzadzen zostalo "awansowane" z dotychczasowego "universal3" na dedykowany element kabiny. Definiowane jest teraz wpisem
instrumentlight_sw:
a element 'oswietlajacy' ma definicje podobnie zmieniona na
i-instrumentlight:
i-instrumentlight_M:
i-instrumentlight_C:
zaleznie od typu zasilania. Znaczy to niestety, ze do zmiany sa istniejace .mmd chociaz powinno tutaj wystarczyc zwykle "zamien w plikach" tekstu "universal3" na "instrumentlight" wiec jest nadzieja ze da sie to zrobic bez wiekszego bolu.

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 12 Lipca 2017, 19:07:12
Rev 1892. Wszystko oprócz kibli, które miałem testowymi Wiggla nadpisane.

Drobny bug z klikanymi heblami wyszedł. Jeśli pojazd ma pantografy impulsowe, podniesione do góry, kliknięcie hebla "pantograf podnieś" opuszcza je i animuje hebel "pantograf opuść".
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Bachus_MK w 12 Lipca 2017, 19:45:28
Czy nowe pliki .mmd będą dostępne w jutrzejszym patchu różnicowym? Czy tak to działa, dobrze to rozumiem? Jeśli nie, to nie ma problemu, dostosuję sobie we własnym zakresie, tylko chciałem zapytać.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 12 Lipca 2017, 19:48:06
Drobny bug z klikanymi heblami wyszedł. Jeśli pojazd ma pantografy impulsowe, podniesione do góry, kliknięcie hebla "pantograf podnieś" opuszcza je i animuje hebel "pantograf opuść".
To ograniczenie obecnego modelu sterowania -- nie ma indywidualnych komend do opuszczenia/podniesienia pantrografow, wiec obsluga jest taka sama jak przy wcisnieciu skrotu klawiszowego, tzn. klikniecie na ktorejkolwiek kontrolce jest traktowane jako komenda "przelacz pantograf" i dobierana jest animacja przelacznikow na podstawie stanu i konfiguracji.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 12 Lipca 2017, 20:12:39
Cytuj
Czy nowe pliki .mmd będą dostępne w jutrzejszym patchu różnicowym? Czy tak to działa, dobrze to rozumiem? Jeśli nie, to nie ma problemu, dostosuję sobie we własnym zakresie, tylko chciałem zapytać.
Tak, będzie w jutrzejszym różnicowym, już jest na repo Milka i będzie w kolejnej rewizji patcha. Klopy też zrobiłem póki co.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Bachus_MK w 12 Lipca 2017, 20:17:48
Rozumiem, dzięki za info.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 14 Lipca 2017, 03:14:54
Pytanie do szerokiej bazy uzytkownikow,

co jakis czas pojawialy sie sugestie rozbudowania systemu dzwiekow dla przelacznikow w kabinie, poczawszy od rozdzielenia dzwiekow dla przelacznikow i przyciskow, a konczac na rzeczach nieco bardziej zaawansowanych jak...

Ja przy tworzeniu dźwięków zauważyłem potrzebę rozdzielenia pośrednich pozycji nastawnika jazdy i bocznikowania od krańcowych z tym, że dźwięk pozycji końcowych uaktywniał by się zależnie od tego w którą stronę kręcimy nastawnikiem jazdy czy manipulujemy bocznikami. Pierwsza pozycja tu i tu była by zawsze odtwarzana przez próbkę dźwięku nastawy pośredniej, końcowa pozycja i w górę i w dół była by realizowana przez dźwięk nastawy końcowej. Chodzi mi o to dosadne walnięcie przy końcu kręcenia kołem i bocznikowania. Tego nie mamy, a to jest bardzo słyszalne.

Po pogrzebaniu troche w exe rozbudowalem w zwiazku z tym nieco mozliwosc definiowania kontrolek kabiny w pliku .mmd  Wyglada to teraz tak, ze dla kazdego przycisku osobno mozna zdefiniowac szereg indywidualnych dzwiekow: dzwiek odgrywany gdy kontrolka przesuwana jest na pozycje nastepna, dzwiek odgrywany gdy przesuniecie nastepuje na pozycje poprzednia, jak rowniez definicje dzwiekow odgrywanych na konkretnych pozycjach danego urzadzenia (przy czym te ostatnie maja wyzszy priorytet)

W zwiazku z ta zmiana, najprosciej byloby wylaczyc obsluge dotychczasowych dzwiekow przelacznikow, nastawnikow itp, ale znaczyloby to, ze kabiny sa pod tym wzgledem "nieme" do czasu az ktos sie pofatyguje przypiac dzwieki do przyciskow w poszczegolnych .mmd  Co naturalnie ma dosc mizerne szanse powodzenia. Dlatego tez pytanie jest nastepujace: czy byloby to rozwiazanie akceptowalne, czy tez nalezy tu szukac jakiejs protezy na "czas przejsciowy"?

(pytam oczywiscie z lenistwa)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mk1991 w 14 Lipca 2017, 03:25:29
Ja z swojej strony deklaruję załatanie kabin które posiadamy dźwiękami jeśli tylko otrzymam odpowiednie instrukcje co do wpisów w .mmd. Do niektórych lokomotyw wiele dźwięków już posiadam, z resztą są one zamieszczone w dziale dla deweloperów. Dysponuję tymi dźwiękami o których pisałeś @tmj, oraz dźwiękami dla przełączników przetwornic, sprężarek itp. dla EU07 i ET22. Znajdzie się też coś dla EP09. Dla lokomotyw, których dźwięków sam nie mam, ale są ich różne wersje w folderze, mogę dopasować dźwięki. Potrzebuję jedynie tak jak napisałem wyżej instrukcji co do wpisów.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: jakubg1 w 14 Lipca 2017, 14:16:03
... czy tez nalezy tu szukac jakiejs protezy na "czas przejsciowy"?
Żeby obecne kabiny nie stały się "nieme", jak to określiłeś, to w EXE można zastosować protezę. Polegała by ona na tym, że tymczasowo obsługiwane by były oba rodzaje manipulacji dźwiękami (jeden co jest obecnie, drugi z rozbudowanymi pozycjami nastawnika itd.), a następnie parser w *.mmd sprawdzałby, czy w tym pliku jest jakiś wpis "nowej generacji". Jeśli go by nie było, obsługa przełączana by była na stary system, jeśli by natomiast był, to obsługa byłaby na nowym systemie.
Dosyć niejasno to opisałem, toteż można krytykować moją wypowiedź. Mimo to może ktoś coś zrozumie z mojego bełkotu i oceni, czy można wprowadzić taką protezę (którą można by było później łatwo usunąć), czy też ktoś ma lepszy pomysł.
Pozdrawiam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mk1991 w 14 Lipca 2017, 14:58:08
Myślę, że na chwilę obecną nie było by to złe. Jedno co bym zmienił, to wpis z pliku fiz zamiast w mmd. Można by wtedy zrobić dźwięki do tego co się da, zaznaczyć to w pliku fiz i sukcesywnie ożywiać resztę.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: jakol112 w 14 Lipca 2017, 15:33:53
Chyba wpis w mmd byłby znacznie lepszy. Inne dźwięki do różnych kabin - zmodernizowanych, starego typu, po naprawach.
P.S. Posiadam gołe przyciski typu N (grzybki i kryte) oraz przełączniki typu Z, włącznik baterii WIS-63 i przełącznik pakietowy (przełączanie nastaw hamulca itd). Jeśli jest potrzeba to mogę nagrać dźwięki wszystkich ww aparatów.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mk1991 w 14 Lipca 2017, 16:19:07
dźwięki możesz nagrać chętnie je przystosuję. Prosił bym tylko, żeby był to plik audio i potrzebna była by zapowiedź dla każdego dźwięku, tak bym wiedział jak nazywać poszczególne próbki.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 14 Lipca 2017, 16:26:22
Skoro @mk1991 zadeklarowal pomoc, na razie wytne stara obsluge i zobaczymy co bedzie ;p

w dzisiejszym uaktualnieniu:

- poprawka, wielokrotne przechodzenie miedzy kabinami/pojazdami nie powinno dluzej prowadzic do wysypow

- poprawka, przejscie do innej kabiny deaktywuje automatycznie czuwak w opuszczanym pomieszczeniu; powinno wyeliminowac sytuacje gdzie po przejsciu z jednego pojazdu do innego (np miedzy czlonami lokomotyw wieloczlonowych) pozostawal ciagle dzialajacy czuwak w opuszczonym czlonie, bezustannie aktywujac hamowanie awaryjne

- diagnostyka, dodane na ekranie F3 informacje o aktualnej sile hamowania pojazdu (Fb) i wspolczynniku tarcia dla biezacego odcinka toru (Fr)

- ficzer, rozszerzona obsluga definiowania dzwiekow aktywacji urzadzen w kabinie pojazdu:

dotychczasowa skladnia parametrow dla przyciskow wygladala np tak:
mainctrl: nastawnikpodst rot -0.02 0.0 0.15

nowa skladnia wyglada tak:
mainctrl: { nastawnikpodst rot -0.02 0.0 0.15 soundinc: nastawnikdoprzodu.wav, sounddec: nastawnikdotylu.wav, sound17: nastawnikpozycja17.wav }
(parametry zamkniete sa w klamry w ramach upodabniania do formatu yaml. potrzebne sa jesli dodajemy przelacznikom nowe parametry poniewaz liczba tych parametrow jest dosc dowolna, i podejscie takie ulatwia prace parserowi)

parametry dzwieku podawane sa w formacie klucz: nazwadzwieku.wav
rozpoznawane klucze to:
- soundinc: dzwiek odgrywany gdy urzadzenie przestawiane jest na pozycje 'nastepna' czyli np przestawienie nastawnika do przodu, zalaczenie przycisku, otwarcie szafki itp
- sounddec: dzwiek odgrywany gdy urzadzenie przestawiane jest na pozycje 'poprzednia' czyli np przestawienie nastawnika do tylu, puszczenie grzyba, zamkniecie okna itp.
- soundX: dzwiek odgrywany gdy urzadzenie ustawione jest na konkretna pozycje X wiekszosc przyciskow ma tylko dwie pozycje, "0" i "1" ale np nastawniki maja tyle pozycji, ile pozycji ma nastawnik Ilosc wpisow soundX dla danego elementu jest w zasadzie dowolna
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mk1991 w 14 Lipca 2017, 16:53:49
W obecnej sytuacji bardzo łatwo możemy zrobić joystick, wystarczy wstawić dźwięk na uruchomienie manipulacji joystickiem i puszczenie joysticka. Przydało by się to dla pojazdów z rozruchem impulsowym. Na początek przejrzę to co mam zrobione i wstawię do tego co jest w mmd. Jednocześnie proszę wszystkich, którzy mają zrobione pulpity do konkretnych pojazdów o materiały. Potrzebne będzie wszystko co jest możliwe do nagrania. Maszynistów, którzy są na forum proszę bardzo o nagrania różnych szafek okien żaluzji, podejrzewam, że teraz nawet uniwersale mogą mieć dźwięki. Potrzebne są też dźwięki dźwigni syren dla wszystkich pojazdów, bo tego nie mam w nagraniach.
PS. Potrzebujemy też dźwięku drzwi lokomotyw, ponieważ niektóre z naszych pojazdów mają taką możliwość. Potrzebne będzie też nagranie nastawnika kierunku w EN57 dla obu pozycji jazdy, pozycji neutralnej i pozycji jazdy w tył.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 14 Lipca 2017, 17:00:56
podejrzewam, że teraz nawet uniwersale mogą mieć dźwięki.
Zgadza sie :>
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 14 Lipca 2017, 17:03:56
Potrzebne będzie też nagranie nastawnika kierunku w EN57 dla obu pozycji jazdy, pozycji neutralnej i pozycji jazdy w tył.

On w kazdej pozycji brzmi tak samo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mk1991 w 14 Lipca 2017, 17:19:23
Mam jedno pytanie. Czy jeśli nie uda mi się zebrać wszystkich pozycji nastawnika jazdy, to muszę wpisywać dla wszystkich ten sam dźwięk nastawy pośredniej, bo inaczej będzie milczał, czy będzie odgrywana pozycja pośrednia zadana dla pozycji w górę i w dół? Oczywiście najprościej było by zebrać wszystkie pośrednie pozycje, a jako soundinc  i sounddec dać te zdecydowane uderzenia.
PS. W następnym poście dam wskazówki dla tych, którzy nagrywają telefonami z systemami Android i Ioes co do zalecanego oprogramowania. Napiszę też jak nagrać żeby nie było większych kłopotów z obróbką.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 14 Lipca 2017, 17:26:29
W wersji podstawowej wystarczy tylko soundinc: i sounddec: ktore sa odgrywane dla kazdej pozycji, o ile ta pozycja nie ma konkretnego wpisu soundX. Czyli uzywajac tego zapytania sprzed kilku dni, dla nastawnika najprosciej zrobic wpis np
soundinc: normalny.wav, sounddec: normalny.wav, sound0: koncowy.wav, sound43: koncowy.wav
i na EU07 odegra to standardowy dzwiek przy kreceniu kolem, a koncowy przy dojsciu na poczatek/koniec.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 14 Lipca 2017, 18:18:00
@tmj, a czy jest też możliwość dodania dźwięku do typowej lampki sygnalizacyjnej? Mam tu na myśli głównie lampki czuwaka, przy których miganiu wyraźnie słyszalne jest charakterystyczne "cykanie" przekaźnika w skrzynce czuwaka (w EU07 i podobnych na tylnej ścianie kabiny zaraz za plecami maszynisty).
@mk1991 - w przyszłym tygodniu ponagrywam Ci dźwięki wszystkiego co jest w pulpicie ET41. Do zastosowania też w innych lokomotywach. Pisałeś natomiast o zapowiedziach dźwięków, tzn. przed każdym dźwiękiem mam na tym samym nagraniu powiedzieć, czego ono dotyczy?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mk1991 w 14 Lipca 2017, 18:18:29
Tak na próbę zrobiłem wpisy dla przełączników przetwornicy, sprężarki i pantografów dla ET22.
compressor_sw: { sw-sprezarka rot 0.2 0 0.2 soundinc: 20786_ET22_switch_compressor.wav, sounddec: 20786_ET22_switch_compressor.wav }
converter_sw: { sw-przetwornica rot 0.2 0 0.2 soundinc: 20786_ET22_switch_converter.wav, sounddec: 20786_ET22_switch_converter.wav }
pantfront_sw: { sw-pant1 rot 0.2 0 0.2 soundinc: 20786_ET22_panto_switch.wav, sounddec: 20786_ET22_panto_up_switch2.wav }
pantfrontoff_sw: { grzybpanta mov -0.003 0 0.2 soundinc: 20786_ET22_switch_panto_down.wav, sounddec: 20786_ET22_switch_panto_down.wav }
pantrear_sw: { sw-pant2 rot 0.2 0 0.2  soundinc: 20786_ET22_panto_switch.wav, sounddec: 20786_ET22_panto_up_switch2.wav }
pantrearoff_sw: { grzybpantb mov -0.003 0 0.2 soundinc: 20786_ET22_switch_panto_down.wav, sounddec: 20786_ET22_switch_panto_down.wav }

Pytanie czego dotyczą podwójne wpisy dla pantografów? Pytam, żeby dobrze to opracować. Czy jest jakaś różnica wpisu przełączników bistabilnych od normalnych?
PS. Tak chodzi o to, bym wiedział jaki przełącznik czy inny element nagrywasz. do nagrania smartfonem zalecam program Auphonic. Najlepiej wybrać dolny mikrofon, bo najlepiej przenosi. Podczas nagrywania dobrze by było żeby zachować ciszę i nie manipulować przy rejestratorze. Najlepiej trzymać go o ile to możliwe w nieruchomej ręce. Dobrze by było nie mieć na sobie szeleszczącej odzieży, tak aby nic nie przeszkadzało. Dźwięki takie jak grzybki, nastawnik, bocznik, nawrotnik nagrywać bez pośpiechu tak bym miał zapas czasu do wycinania.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 14 Lipca 2017, 18:26:40
Ok, nagram kilka rzeczy, prześlę Ci na PW i jak uznasz, że może być, to nagram resztę. Ale tak jak pisałem, dopiero w przyszłym tygodniu będę miał warunki do nagrywania.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mk1991 w 14 Lipca 2017, 18:31:40
Dobrze. Na razie dla próby udźwiękawiam byka i siódemki. Przy okazji dokonuję poprawek edycyjnych w dźwiękach. Inna rzecz, że do puki jest to w fazie opracowywania dźwiękowego, dobrze by było zrobić przełączanie się po między trybami zaawansowanego udźwiękowienia i podstawowego tak żeby inni mogli spokojnie testować inne usprawnienia exe.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: jakol112 w 14 Lipca 2017, 20:03:14
 Hmmm no cośtam nagrałem... Nie wiem czy dobrze - niech wypowiedzą się dźwiękowcy. Myślę, że coś się z tego wyskubie.

http://eu07.pl/userfiles/21101/priv-laczniki.7z
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 14 Lipca 2017, 21:11:03
Czy przy okazji byłaby możliwość dodania dźwięku przejścia między określonymi pozycjami?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 14 Lipca 2017, 21:54:47
To ja z innej beczki (w ramach koncertu życzeń): może drugi format dźwięków niż tylko wav? Przy tej liczbie możliwości zaczniemy wielkością repo doganiać tekstury.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: jakubg1 w 14 Lipca 2017, 22:04:23
Ja twierdzę, że nie trzeba drugiego formatu dźwięków. Idźmy w stronę "jeden typ, jeden format". Tak jak wszystkie tekstury to *.dds (dla deweloperów *.tga), tak wszystkie dźwięki to *.wav. Nie róbmy bajzelu, a darmowych konwerterów z praktycznie każdego pliku audio do formatu *.wav jest przecież pełno.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 14 Lipca 2017, 22:05:30
Dobra wiadomość jest taka, że symulator zmieści się jeszcze na każdy dostępny w sprzedaży twardy dysk i je4szcze trochę miejsca zostanie.Problem w tym, że mało kto wykorzystuje całą paletę tekstur i dźwięków. O ile tekstury są unikalne, to dźwięki bywają wnerwiające. Kiedyś ktoś wgrał dźwięk sm42 z brzęczącą szybą i musiało być tak we wszystkich.
Na przekór, jestem za zmianą formatu dźwięków z wav na inny.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 14 Lipca 2017, 22:08:22
Tyle, ze mowa o wav. Wav, ktore jest nieskompresowane to raz. Wav, ktore tez na chwile obecna musi miec bardzo okrojone parametry, przez co traci sie na dzwieku.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 14 Lipca 2017, 22:15:43
Jakikolwiek format podpadający pod PCM, problem będzie przy obróbce tak jak z dds, jednak efekty powinny być lepsze.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 14 Lipca 2017, 23:27:20
pantfront_sw: { sw-pant1 rot 0.2 0 0.2 soundinc: 20786_ET22_panto_switch.wav, sounddec: 20786_ET22_panto_up_switch2.wav }
pantfrontoff_sw: { grzybpanta mov -0.003 0 0.2 soundinc: 20786_ET22_switch_panto_down.wav, sounddec: 20786_ET22_switch_panto_down.wav }
pantrear_sw: { sw-pant2 rot 0.2 0 0.2  soundinc: 20786_ET22_panto_switch.wav, sounddec: 20786_ET22_panto_up_switch2.wav }
pantrearoff_sw: { grzybpantb mov -0.003 0 0.2 soundinc: 20786_ET22_switch_panto_down.wav, sounddec: 20786_ET22_switch_panto_down.wav }

Pytanie czego dotyczą podwójne wpisy dla pantografów? Pytam, żeby dobrze to opracować. Czy jest jakaś różnica wpisu przełączników bistabilnych od normalnych?
Przelaczniki pantfront_sw: i pantrear_sw: moga wystepowac w .mmd samodzielnie, i wtedy generalnie funkcjonuja jako bistabilne. Natomiast gdy sa zdefiniowane jako impulsowe, to prztykniecie nimi jedynie podnosi pantografy, a do opuszczenia sluza wtedy dodane do .mmd odpowiadajace im przelaczniki z koncowka off

(nawiasem mowiac definicja przyciskow jako impulsowe tez jest do przeniesienia do wpisow dla indywidualnych przyciskow, ale to na pozniej)

@tmj, a czy jest też możliwość dodania dźwięku do typowej lampki sygnalizacyjnej?
Mozliwosc jest zawsze, tylko komus musi sie chciec ;>  na 100% nie zagwarantuje, bo nigdy nie wiadomo czy cos w kodzie nie jest namieszane, ale teoretycznie powinno sie dac.

Czy przy okazji byłaby możliwość dodania dźwięku przejścia między określonymi pozycjami?
Ale w jakim sensie? Obecnie dzwiek jest odgrywany w momencie, gdy zostanie ustawiona pozycja inna niz biezaca, czyli technicznie rzecz biorac wlasnie w momencie przejscia. wpis soundX pozwala zatem zdefiniowac dzwiek odgrywany w momencie wchodzenia na pozycje X, chociaz bez wzgledu na kierunek tego 'wejscia' i pozycje poczatkowa.

To ja z innej beczki (w ramach koncertu życzeń): może drugi format dźwięków niż tylko wav? Przy tej liczbie możliwości zaczniemy wielkością repo doganiać tekstury.
Na dzwiekach nie znam sie kompletnie ;d  mam slaba nadzieje ze openAL obsluguje inne formaty, ale nie przygladalem sie mu jeszcze. Alternatywnie zapewne mozna by przytulic jakies middleware do konwersji z np. mp3 lub ogg
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 14 Lipca 2017, 23:28:58
Jakikolwiek format podpadający pod PCM, problem będzie przy obróbce tak jak z dds, jednak efekty powinny być lepsze.

Ale dźwięków raz zrobionych nie konwertujesz potem x razy. To nie są tekstury.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mareczek w 14 Lipca 2017, 23:31:18
Raz działa 6Dg, raz nie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 14 Lipca 2017, 23:40:13
Na dzwiekach nie znam sie kompletnie ;d  mam slaba nadzieje ze openAL obsluguje inne formaty, ale nie przygladalem sie mu jeszcze. Alternatywnie zapewne mozna by przytulic jakies middleware do konwersji z np. mp3 lub ogg
OpenAL się tym nie zajmuje, tylko mu wciskasz bufor w PCM. Zastanawiałem się nad http://www.mega-nerd.com/libsndfile/ bo ma bardzo proste API i potrafi FLAC i Vorbis. Żeby obsługiwać wszystko i zlew kuchenny to można libavformat i libavcodec, ale na to trzeba pisać kilkadziesiąt linijek. (dużo kodu do inicjalizacji, samemu trzeba przepychać dane z demuxera do dekodera)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Lipca 2017, 00:17:34
Raz działa 6Dg, raz nie.
Ten wysyp jest w bibliotece pythona wiec trudno stwierdzic, co konkretnie sie przytrafilo. Nawiasem mowiac biblioteka python27.dll ktora masz u siebie jest starsza niz ta zalecana do exe -- warto byc moze zmienic nazwe pliku na inna lub wrecz go skasowac, a zamiast tego zainstaluj standardowy pakiet pythona 2.7.13, powinien byc link do instalatora w watku changelog
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mareczek w 15 Lipca 2017, 10:09:59
Dzięki @tmj, pomogło.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 15 Lipca 2017, 13:30:08
@tmj takie pytanko, dałoby radę rozdzielić przyciski otwierania drzwi tak jak to zrobiłeś z pantografami? Bo większość ezt po modernizacji ma osobne przyciski do otwierania i zamykania drzwi. :D
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 16 Lipca 2017, 01:40:14
W dzisiejszym uaktualnieniu, w ramach koncertu zyczen:

- dzwieki moga byc tez przypisane do kontrolek. Skladnia jest taka sama jak dla przelacznikow, z tym ze poniewaz kontrolki maja tylko stan zalaczony i wylaczony, rozpoznawane sa tylko klucze soundinc: i sounddec:

- przelaczniki ktore nie maja zdefiniowanych wlasnych dzwiekow odtwarzaja dzwieki 'standardowe' definiowana dotychczasowa metoda
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: ST44-003 w 16 Lipca 2017, 17:59:59
To jeszcze ja bym miał 2 pobożne życzenia:
- skoro jest działający wpis i hebelek od zał/wyłączania baterii, może dodać też działający rozrząd?
- dałoby się dodać także wpis od zał/wyłączania z hebelka wentylatory oporów dla EU07 (4E)? W zasadzie dla każdej z lokomotyw elektrycznych? :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: SM40 w 16 Lipca 2017, 18:29:56
W trybie sterowania myszą WS załącza się od delikatnego wciśnięcia przycisku a powinien wymagać przytrzymania, poza tym można nacisnąć tylko jeden przycisk w zależności od stanu WS a w rzeczywistości można nacisnąć wyłączenie gdy jest wyłączony i na odwrót.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 16 Lipca 2017, 18:45:31
To ja poprosze lampke os wyl szyb 3 wagonu pod sn61. Obecnie mamy 2. A klucz rozrzadu w ep08-001 mam w swojej kabinie. Po ewentualnym wprowadzeniu mozna uruchomic.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: DjSon231 w 16 Lipca 2017, 19:04:25
Znalazłem trzy błędy (jeden niepotwierdzony, pierwszy):
- w 170710 był problem z bocznikowaniem w SP42 (nie wiem czy wszędzie). Na nie odpalonej lokomotywie można było ciągle załączać bocznikowanie, które nie robiło nic (nawet nie pokazywało się po lewej w napisach), ale odtwarzało dźwięk. Problem zniknął po jej odpaleniu. Teraz w ogóle nie słychać bocznikowania w SP42, a wygląda na to, że załącza.
- kran hamulca zespolonego oraz lokomotywy się nie rusza (kiedy ruszam NUM 9 oraz NUM 6 i NUM 1, oraz NUM 9) również w SP42, nie wiem jak w innych.
- wciśnięcie klawisza ALT, zejście do pulpitu i włączenie MaSzyny ponownie skutkuje pokazywaniem się wszystkich nazw podmodeli, a nawet torów (wyjdę na F4, najadę kursorem na tor, to mi jego nazwe pokaże).

Wszystko na 64 bitach.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 16 Lipca 2017, 19:29:02
- SP42 nie ma w pliku .mmd zdefiniowanego dzwieku dzwigni bocznikowania, jest tylko dzwiek dla nastawnika glownego (wpis ctrl:) Stare exe uzywalo w takiej sytuacji dzwieku nastawnika glownego, nowe po zmianach uzywa tylko zdefiniowanych wpisow
- krany SP42 ruszaja sie u mnie, testowane na wersji z repo sprzed kilku dni. zerknij czy nie masz u siebie wpisu w errors.txt o brakujacych submodelach, lub czegos podobnego?
- to chyba raczej nie blad a celowo wprowadzony ficzer; podswietlanie nazw wszystkich submodeli i zdefiniowanych elementow scenerii jest wykonywane w trybie debug, po zalaczeniu kontroli mysza (wykonywanego klawiszem Alt)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mareczek w 17 Lipca 2017, 20:48:11
1) Nie działa podświetlenie zegarów. Zawsze działało pod ";", nawet w ini tak jest, a w kabinie bez zmian. Testowane na EU07
2) Powolutku idąc hamulcem w uderzeniowe, zanim przekręci się kran, powietrze już idzie w układ. Efekt może być taki że kran nawet nie drgnie, a przewód popełniamy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: jakol112 w 17 Lipca 2017, 21:01:49
Marku, podświetlenie ma zmieniony wpis w mmd. Był universal3, teraz jest instrumentlight_sw. W patchu 17.07 mmd są już zedytowane.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 17 Lipca 2017, 21:07:41
1) Nie działa podświetlenie zegarów. Zawsze działało pod ";", nawet w ini tak jest, a w kabinie bez zmian. Testowane na EU07
2) Powolutku idąc hamulcem w uderzeniowe, zanim przekręci się kran, powietrze już idzie w układ. Efekt może być taki że kran nawet nie drgnie, a przewód popełniamy.
Wpis podswietlenia zmienil sie niedawno, przetestuj jesli moze na uaktualnionych .mmd zalaczonych do paczki patch 17.07, w tescie dodatkow. Punkt 2 jest poprawiony w nastepnym uaktualnieniu.

edit:
w dzisiejszym uaktualnieniu drobne poprawki,

- poprawka, animacja elementow kabiny powinna ponownie byc plynna

- poprawka, skalowanie rozblyskow nie powinno sie gubic w niektorych sytuacjach

(poza tym wersja 17.717 wyglada duzo lepiej jako kandydat dla paczki calosciowej ;p
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 21 Lipca 2017, 20:42:56
Ja mam pytanie odnośnie uniwersali. Wczesniej dlugosc przytrzymywania przycisku powodowalo stopniowa animacje. Teraz jest jakby stan on i off co w przypadku okna wygląda to na otwarte/zamknięte. Nie da się zrobić tej przysłowiowej szczelinki. Czy to już tak zostanie? A co do zmiany uniwersal3 na ten nowy wpis, to jak sobie popatrze na ilość plikow mmd do zmiany to az się odechciewa. Przydalby się automat. Nie można było zostawić kompatybilności wstecznej, co dla nowego taboru można by było wykorzystać jako dodatkowe oświetlenie czegostam np. rozkładu jazdy, a w starym taborze było by to używane do tego co obecnie?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Sawi w 21 Lipca 2017, 20:56:37
Epek musimy przestać brnąc dalej w kolejne protezy, bo w końcu to się tak pokićka, że odkręcenie tego będzie wymagało sporo czasu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 21 Lipca 2017, 21:02:43
No ale do rozkładu jazdy nie mamy nic. Mamy rozkład albo jakiś dodatkowy ekran itd. Uniwersale mogly by mieć opcjonalnie podpięte lampki do każdego. Nie koniecznie używane. Jakies panele tablic kierunkowych itd. W zasadzie to poszerza się możliwości dzięki temu. A przy okazji w mało znaczącym taborze sluzylo by do zalaczenia tego osw przyrzadow tylko nastapila by zmiana klawisza.

Postuluje by do każdego uniwersalx dopisać stan lampki i-uniwersalx. Jeśli takowa lampke uzależnimy w chierarchi do lampki np. ws albo baterii, to jej stan będzie wyświetlany tylko jeśli lampka w chierarchi wyzsza będzie swiecic. Każdy taki bajerek jak dodatkowe uniwersale z lampka, umozliwia zrobienie bajerów w np. wnętrzach wagonow typu lampki do czytania itd... Zauwaz ze często używano lampki od drzwi kibelkowych a to wprowadzalo bałagan. Także i tu by zrobil się porządek dzięki temu rozwiązaniu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 21 Lipca 2017, 23:47:17
Ja mam pytanie odnośnie uniwersali. Wczesniej dlugosc przytrzymywania przycisku powodowalo stopniowa animacje. Teraz jest jakby stan on i off co w przypadku okna wygląda to na otwarte/zamknięte. Nie da się zrobić tej przysłowiowej szczelinki. Czy to już tak zostanie?
Raczej tak, zakladam ze przeznaczeniem uniwersali sa elementy w stylu drzwi do szaf, drzwi miedzy przedzialami, generalnie rzeczy ktore dodaja troche 'smaku' ale bez koniecznosci manualnego ciagania mysza po ekranie gdy trzeba takie ustrojstwo otworzyc/zamknac.

Co do zmiany z uniwersal 3, to wszystkie .mmd mozna poprawic zwyklym jednorazowym "zastap w plikach" np uzywajac Notepad++ i zamieniajac "universal3" na "instrumentlight" Najnowsza paczka calosciowa ma juz .mmd dostosowane w ten sposob.

Podlaczanie lampek do universali nie bardzo mi sie usmiecha, bo to powoduje dokladnie ten sam balagan ktory staralem sie usunac -- przy takiej aranzacji ktos zrobi sobie oswietlenie rozkladu pod universal1, ktos inny pod 5, ktos inny pod 0 a uzytkownik ma wtedy pamietac/zgadywac co jest gdzie, gdy zamiast tego powinien byc po prostu dedykowany standardowy przycisk "oswietlenie rozkladu" i polaczona z nim lampka.

Tak czy owak, tymczasem male uaktualnienie:

- poprawka, animacje umieszczonej w scenerii odleglej obrotnicy nie powinny wysypywac symulatora

- poprawka, wykrywanie zdegenerowanych trojkatow geometrii powinno wychwytuwac teraz wszystkie przypadki

- eksperymentalne, zwiekszona nieco wielkosc odleglych punktow swietlnych
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 24 Lipca 2017, 14:29:47
Da się coś zrobić, żeby dźwięk "fadesound:" w sekcji "internaldata:" był słyszalny tylko w jednym członie lokomotywy dwuczłonowej? Wstawiłem go do *.mmd członu A, ale w członie B też go słychać. Chodzi o dźwięk zegara w Haslerze rejestrującym w kabinie A.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mareczek w 24 Lipca 2017, 14:51:42
To jeszcze dorzucę, że w siódemce kręcąc szybko kołem, słychać każdy wchodzący stycznik niczym kosiarka. Może tak być powinno, ale dźwięk każdego stycznika nie powinien być ucinany z powodu odtworzenia kolejnego.
Na filmie tmechatronika dobrze słychać efekt końcowy - https://youtu.be/ky45FP9ej7M?t=2m13s
W ET22 te styczniki wchodzą trochę wolniej, dłużej odtwarzany jest dźwięk stycznika, więc lepiej to brzmi. W siódemkach wcześniej też tak było (ale nie wiem czy poprawna jest stara wersja wchodzenia styczników, czyli wolniejsza, czy obecna szybsza).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 24 Lipca 2017, 14:53:19
Da się coś zrobić, żeby dźwięk "fadesound:" w sekcji "internaldata:" był słyszalny tylko w jednym członie lokomotywy dwuczłonowej? Wstawiłem go do *.mmd członu A, ale w członie B też go słychać. Chodzi o dźwięk zegara w Haslerze rejestrującym w kabinie A.
Teoretycznie nie powinno być. Jeszcze z czasów borlanda jest to bug, dźwięk fadesounda nie jest odświeżany przy zmianie pojazdu. Bardzo mnie raziło w wagonach, gdzie jest pod niego podpięta przetwornica.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 24 Lipca 2017, 15:31:04
Znalazłem taki wpis w EN57 i chciałem wykorzystać w ET41, bo z @mk1991 robimy teraz dźwięki wszystkiego po kolei z osobna... A jest jakiś inny sposób na stałe odtwarzanie dźwięku, ale żeby się odświeżał przy zmianie pojazdu?
Przy okazji jeszcze drugie pytanie: jak przypisać dźwięk do pozycji napełnienia albo odcięcia w kranie hamulca? Jak daję wpis np. dla odcięcia "sound-2:" (bo "0" to pozycja jazdy), to odtwarza się tylko "sounddec:" przy wchodzeniu w odcięcie.

EDIT: Jeszcze jest taki problem, że dźwięk dla poszczególnych pozycji kranu odtwarza się od połowicznych wartości danych pozycji zamiast tylko w tych konkretnych pozycjach, przez co strasznie dziwnie to brzmi.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mk1991 w 24 Lipca 2017, 16:10:08
Mnie zastanawia jak ugryźć dźwiękowo joystick Traxxa. Mam dźwięk dla wychodzenia z zera i dochodzenia do zera. Stworzyłem na razie mini pliki z ciszą dla zapełnienia soundinc i sounddec, ale to chyba nie wyjście. Najlepiej będzie go zrobić jako hebel bistabilny, przynajmniej dźwiękowo. Wtedy mógł bym dać jako soundinc i sounddec te dwa dźwięki. Tak na razie. Za niedługi czas włoży się do testów udźwiękowienie dla ET41 i wtedy będzie można przyjrzeć się dokładniej temu jak to wszystko działa. Na pewno kłopoty są z kranem hamulca. Wychodzą totalne dziwy. Z tego co wiem, to numeracja pozycji idzie od -2 co oznacza odcięcie, przez -1 napełnianie udeżeniowe, 0 jazda, 1 hamowanie wstępne, 2 hamowanie pełne I stopnia, 3 hamowanie pełne II stopnia do 4 hamowanie nagłe. Z tym, że to nie chce za chiny działać.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 24 Lipca 2017, 17:18:10
Ale to jest prawda tylko dla FV4a. Dla innych kranów są inne pozycje krańcowe. Pozycja zero oznacza jedynie neutralna. Jak przepisywałem krany to się nieźle namordowałem z tym, ale teraz liczysz pozycje od 0. Dla każdego rodzaju kranu będzie trzeba to inaczej liczyć.

Kto chce potestować trzecią gałąź? Zmieniona tabelka prędkości: np nie powinno być już błędów na kaliskiej gdzie gagar miał za długi skład.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Lipca 2017, 03:15:13
Przy okazji jeszcze drugie pytanie: jak przypisać dźwięk do pozycji napełnienia albo odcięcia w kranie hamulca? Jak daję wpis np. dla odcięcia "sound-2:" (bo "0" to pozycja jazdy), to odtwarza się tylko "sounddec:" przy wchodzeniu w odcięcie.

EDIT: Jeszcze jest taki problem, że dźwięk dla poszczególnych pozycji kranu odtwarza się od połowicznych wartości danych pozycji zamiast tylko w tych konkretnych pozycjach, przez co strasznie dziwnie to brzmi.
To sa 'bledy i wypaczenia' w exe, bo przy dodawaniu funcjonalnosci bazowalem na nastawniku itp, i zupelnie wypadlo mi z pamieci ze hamulec zaczyna sie od pozycji ujemnych, i ze zmienia sie 'ze skokiem mniejszym niz 1. Pojdzie do poprawki.

A tymczasem w dzisiejszym uaktualnieniu:

- feature, dynamiczne cienie rzucane przez slonce.

"jezu, ale po co?"
"bo moglem"

(przyznam, ze tego czy da sie to exe doprowadzic do stanu przy ktorym mozna by to zaimplementowac, na starym openGL a nie shaderach, ciekaw bylem od poczatku grzebania w kodzie. Wychodzi na to ze owszem, mozna. Szalu oczywiscie nie ma, niemniej wizualna roznica jest)

poniewaz ficzer korzysta z funkcji renderowania do bufora ktore nie sa w standardzie 1.5, domyslnie nie jest aktywny. Aktywacje wykonujemy wpisem w .ini
shadows yes
Jesli aktywacja sie nie powiedzie bedzie wzmianka w logu, a symulator przelaczy sie samodzielnie na stare, nudne rysowanie bez cieni.
Do definiowania dodatkowych parametrow uzywany jest wprowadzony przez Milka7 parameter shadowtune chociaz uzywany obecnie jest tylko pierwszy parameter (wielkosc mapy cieni, decydujaca a jakosci efektu)

cienie dzialaja "na 90%" poniewaz w niektorych lokacjach potrafia sobie zniknac, z przyczyn na razie nieustalonych. Ale lepsze 90% nic nic ;d
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: ST44-003 w 25 Lipca 2017, 08:15:40
Można jakiegoś screena prosić jak to wygląda obecnie? Ciekawość mnie zżera, a tu jeszcze 8 godzin pracy :D
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 25 Lipca 2017, 08:53:50
Tobie zostalo 8 godzin, a mnie zostalo czekania do 18 sierpnia. Jestem daleko od domu i komputera z symulatorem. Mam jeszcze dylemat, bo nie wiem jak napisac, to co od lat uwazalem za mozliwe a przeciez byl tak straszny opor przed podjeciem chocby proby realizacji tych ficzerow. Skoro mamy juz ten etap, to dedykuje je wszystkim niechetnym oportunistom i niedowiarkom, ktorzy wczesniej niedopuszczali mozliwosci zmiany sposobu wspolpracy, wlacznie z publikacja zrodel.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: pat w 25 Lipca 2017, 09:33:51
U mnie wygląda to tak. Co poszło nie tak?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Tomnord15 w 25 Lipca 2017, 11:12:26
U mnie w trybie Display Lists jest to samo, na VBO jest dobrze. Z tym że na starszych komputerach spadek fps jest znaczny.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Maniakunitra1 w 25 Lipca 2017, 12:05:59
U mnie dokładnie tak samo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Lipca 2017, 14:10:26
U mnie wygląda to tak. Co poszło nie tak?
Zupelnie zapomnialem sprawdzic tryb DL i sie przesliznelo :>  to jest niedopatrzenie w kodzie, do czasu nastepnego uaktualnienia jesli to nie problem uzyj trybu VBO. Powinno byc ogarniete dzisiaj nieco pozniej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: RooteK w 25 Lipca 2017, 15:58:17
Po wciśnięciu i przytrzymaniu PPM efekt jak w załączniku, czyli zamiast normalnych cieni pojawia się jeden wielki.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 25 Lipca 2017, 17:29:36
Maly filmik. Jakis cien porusza się wraz z kamera powtarzalny poprzeczny na torze 6:41.

Cienie dziwnie migaja. Zreszta filmik (wrzuci się za pol godzinki) pokazuje co i jak.

Cienie pikselozowate strasznie. Co to za parametr shadowtune i jak go uzywac?

https://youtu.be/fs59s5xSD4Q
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Lipca 2017, 18:48:28
Jest nowy fajowy ficzer, CIENIE. Konfiguruje się je parametrem shadowtune:
shadowtune <rozdzielczość> <promień projekcji> <głębokość projekcji> <odległość od obserwatora>Gdzie: <rozdzielczość> - szerokość i wysokość tekstury na jaką renderuje się shadowmapa. żeby miało przyzwoitą jakość to ja sobie ustawiam 4096. (to zajmuje sporo vramu, np. 2048 to 16MiB, 4096 to 64MiB, 8192 to 256MiB)
(reszte parametrow pomijam bo w wersji nieshaderowej nie sa, przynajmnien na razie uzywane. wartosc domyslna wpisu to:
shadowtune 2048, 200, 150, 100

W dzisiejszym uaktualnieniu:

- poprawka, przywrocone teksturowanie w trybie Display List

- poprawka, trzymanie w kabinie prawego przycisku nie prowadzi do blednej kalkulacji cieni

- eksperymentalnie: tory nie rzucaja cieni (bo nie wyglada to ciekawie)

- poprawka, dzwieki urzadzen w kabinie mozna tez definiowac dla pozycji ujemnych

- poprawka, dzwieki zdefiniowane dla konkretnych pozycji odtwarzane sa tylko dokladnie w tych pozycjach, a nie przy wartosciach posrednich
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 25 Lipca 2017, 19:08:39
Jeszcze zapytam czy skoro widac jak slonce odbija sie np od dachu loka to czy da sie zrobic by odbijalo sie od blyszczacych glowek szyn jadac pod slonce o zachodzie? I kolejne pytanie czy reflektory jako zrodla swiatla takze generuja cienie?  I co z cieniami zucanymi do wewnatrz kabiny np przez drzewa itp? Czy sa te elementy w planie ma przyszlosc?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Lipca 2017, 19:16:07
Teoretycznie tak, ale wymagaloby to poprawek generowania geometrii torow (jesli dobrze pamietam to w tej chwili jest uproszczona, bez poprawnego ustawienia wektorow normalnych ktore sa potrzebne do kalkulacji oswietlenia, w tym rozblyskow)

Reflektory nie rzucaja cieni, bo kazde swiatlo zzera duzo mocy obliczeniowej; wieksza ich ilosc wymagalaby zmiany w podstawowym sposobie dzialania silnika graficznego. Co do oswietlenia wnetrza kabiny, na razie nie jest realizowane przede wszystkim dlatego, ze duza ilosc pojazdow nie ma przezroczystych okien, i w takiej sytuacji cala kabina bylaby zaciemniona.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 25 Lipca 2017, 19:32:11
- poprawka, dzwieki urzadzen w kabinie mozna tez definiowac dla pozycji ujemnych
- poprawka, dzwieki zdefiniowane dla konkretnych pozycji odtwarzane sa tylko dokladnie w tych pozycjach, a nie przy wartosciach posrednich
Pierwsze działa. Drugie: teraz przy przestawianiu kranu klawiszami [Num3] i [Num9] dźwięki nie odtwarzają się wcale zawsze (nawet w konkretnych pozycjach według parametru "HamZ" pod F3), a zawsze odtwarzają się tylko przy użyciu klawiszy skrótowych dla poszczególnych pozycji.
A co z tym "fadesound:"? Jeśli byłaby możliwość, to przydałby się dźwięk odtwarzany stale w kabinie A. Dodatkowo czy jest możliwość przypisania jakimś wpisem dźwięku do elementów bez animacji jak np. włącznik baterii lub radia? Poza wyżej wymienionymi, każdy element w ET41 ma już przypisany swój własny unikalny dźwięk :) Są nawet różne zależnie od członu, bo wszystko nagrywałem po trzy razy, żeby było z czego wybierać. Aha, cienie się u mnie nie wyświetlają ani w trybie DL, ani w VBO: w *.ini mam wpis "shadows yes", system Windows 7 - log z trybu DL w załączniku.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Kermit w 25 Lipca 2017, 19:33:52
Fadesound by sie przydaly w sumie pare, bo przeciez jest i brzeczenie zasilacza radiotelefonu i cykanie zegarynki w haslerze.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: RooteK w 25 Lipca 2017, 20:03:46
Fadesound by sie przydaly w sumie pare, bo przeciez jest i brzeczenie zasilacza radiotelefonu i cykanie zegarynki w haslerze.

Tylko takie brzęczenie zasilacza to lepiej podciągnąć jako osobny dźwięk związany na przyszłość z jego obsługą.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 25 Lipca 2017, 20:12:24
Tym bardziej, że jest zależny od aktualnego "stanu" radia, tzn. nieraz jest tak, że jak manipulator jest wyłączony, to przetwornica w zasilaczu robi sobie powoli "cyk --- cyk --- cyk...", jak się załączy manipulator, to robi już "cyk cyk cyk cyk cyk...", a jak coś nadaje albo odbiera, to jest już "ckckckckckckckc" ;) To przez zwiększone zapotrzebowanie na prąd musi chyba częściej podbijać napięcie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Lipca 2017, 20:16:36
Drugie: teraz przy przestawianiu kranu klawiszami [Num3] i [Num9] dźwięki nie odtwarzają się wcale zawsze (nawet w konkretnych pozycjach według parametru "HamZ" pod F3), a zawsze odtwarzają się tylko przy użyciu klawiszy skrótowych dla poszczególnych pozycji.
Byc moze nie zrozumialem o co chodzi, ale po poprawkach hamulec powinien odtwarzac np dzwiek zdefiniowany jako sound1 w momencie wejscia dokladnie na pozycje 1 itp. Przywiazalem u siebie dzwiek do pozycji 1, inny do pozycji 2, i odtwarzaly sie one przy manipulacji klawiszami 3/9, w chwili wejscia na te pozycje.

Cytuj
A co z tym "fadesound:"? Jeśli byłaby możliwość, to przydałby się dźwięk odtwarzany stale w kabinie A. Dodatkowo czy jest możliwość przypisania jakimś wpisem dźwięku do elementów bez animacji jak np. włącznik baterii lub radia? Poza wyżej wymienionymi, każdy element w ET41 ma już przypisany swój własny unikalny dźwięk :) Są nawet różne zależnie od członu, bo wszystko nagrywałem po trzy razy, żeby było z czego wybierać.
Na 100% nie jestem pewien bez zagladania, ale chyba mozna zdefiniowac takie przelaczniki w .mmd, wskazac im nieistniejacy submodel i przypisac im dzwieki jak kazdemu innemu, dzwieki beda sie (chyba) odtwarzac nawed gdy modelu brak. Co do fadesound: na razie nie mam zadnej konkretnej koncepcji, bo w kolejce byly inne rzeczy :>

Cytuj
Aha, cienie się u mnie nie wyświetlają ani w trybie DL, ani w VBO: w *.ini mam wpis "shadows yes", system Windows 7 - log z trybu DL w załączniku.
Texture file missing: "fx\reflections"
Pobierz i wypakuj do katalogu symulatora takze zalacznik z plikami danych, z ostatniego uaktualnienia.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mk1991 w 25 Lipca 2017, 20:47:46
Z mojego doświadczenia wynika, ze co nie istnieje, nie jest brane pod uwagę. Też tak myślałem, wstawiłem wpis dla włącznika baterii i nie działa. Na tej samej zasadzie w kabinie ET41_V1 nie ma zrobionej piasecznicy .
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 25 Lipca 2017, 20:51:07
Poprawka - w ET41_v2 nie działa piasecznica. Zgłoszenie jest od jakiegoś czasu w Bugtrackerze. W v1 nie działa kilka innych rzeczy (oświetlenie i przyciemnienie kabiny, hebelek przyciemnienia reflektorów gdzieś odlatuje itd., ale to nie ten temat).

EDIT: A co do nieistniejących submodeli, to jedynym sposobem jest przypisanie funkcji do submodelu innej funkcji, tylko wtedy nie animuje się on prawidłowo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 25 Lipca 2017, 21:30:35
Kolejne moje pytanie. Jaki element zuca cien na sciane piętrusa? Podczas ruchu kamery ten cien szarpie się i plywa. Efekt poszartpanego cienia widać na screnie. Sceneria TD. Czy u innych tez to wystepuje? Cien jest poszarpany u spodu i u góry.

https://youtu.be/Q6tuBSK2QcM
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Lipca 2017, 21:34:25
Z mojego doświadczenia wynika, ze co nie istnieje, nie jest brane pod uwagę. Też tak myślałem, wstawiłem wpis dla włącznika baterii i nie działa. Na tej samej zasadzie w kabinie ET41_V1 nie ma zrobionej piasecznicy .
U mnie dziala(tm)
battery_sw: { none mov 0 0 0 soundinc: couplerattach.wav }
po zalaczeniu baterii odgrywany jest zdefiniowany dzwiek. To moze nie zadzialac dla wszystkich przelacznikow, bo funkcjonowanie niektorych jest powiazane z istniem submodelu (jako prymitywny sposob okreslenia, czy dane urzadzenie w kabinie w ogole wystepuje) ale dla urzadzen "podstawowych" tzn takich ktore potrzebne sa do uruchomienia i jazdy, a nie bajery w stylu swiatel w kabinie, ustawienie wartosci, i w konsekwencji odgrywanie dzwieku, nastapi normalnie.

edit:
Kolejne poje pytanie. Jaki element zuca cien na sciane piętrusa? Podczas ruchu kamery ten cien szarpie się i plywa. Efekt poszartpanego cienia widać na screnie.
To jest po prostu zacieniona strona wagonu (po pozostalych cieniach widac, ze slonce znajduje sie po drugiej stronie) Inaczej mowiac, elementem rzucajacym cien na sciane wagonu jest tutaj sam wagon.  Rzeczywiscie, ze wzgledu na rozdzielczosc mapy i obszar ktory jest cieniowany rozdzielczosc jest, jaka jest; efekt jest dodatkowo gorszy gdy niejako 'patrzymy pod swiatlo'.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 25 Lipca 2017, 21:45:23
Coi można zrobić by do maxa wygladzic krawędzie cieni? Trzeba przyznać ze to mocno psuje zamierzony efekt.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 25 Lipca 2017, 22:03:25
Podbić rozdzielczość shadowmapy do maksymalnej rozdzielczości obsługiwanej przez twoją GPU. Tyko zajmie ona wtedy kilkaset MB vramu i będzie się tworzyć wykładniczo dłużej. Na exe shaderowym jest lepiej i będzie jeszcze lepiej, gdy rozdzielczość będzie zależna od odległości od kamery.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 25 Lipca 2017, 22:11:32
No tak tylko wtedy strasznie przycina pomimo ze fps jest rzedu 30 do 40 na kaliskiej. Na ulamki sekund zrywa.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: trus w 25 Lipca 2017, 22:14:41
U mnie nie ma cieni. Ktoś coś poradzi?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mareczek w 25 Lipca 2017, 22:24:24
Musisz zrobić dwa wpisy do eu07.ini. Przykładowo
shadows yes
shadowtune 2048, 200, 150, 100

Ja od siebie dorzucę taki filmik. Zachowanie cieni przy ruszaniu kamerą zewnętrzną. Ponadto dalej widać spore schodkowanie, a parametry podciągnąłem znacznie w górę.

shadowtune 16384, 500, 300, 200
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Lipca 2017, 22:26:05
Coi można zrobić by do maxa wygladzic krawędzie cieni? Trzeba przyznać ze to mocno psuje zamierzony efekt.
To niestety techniczne ograniczenie ktorego w exe bez shaderow raczej sie nie przeskoczy. Tzn do pewnego stopnia mozna to kontrolowac, albo zwiekszajac wielkosc mapy albo zmniejszajac obszar, na ktorym generowane sa cienie, bo moze byc 'albo duzo, albo dobrze'. Dla przykladu, w zalaczniku widac jak to wyglada przy zredukowaniu obszaru 5x  Cienie owszem, sa ostre, do tego stopnia ze zaczyna byc widac braki w modelu, ale z drugiej strony zasieg jest na tyle krotki, ze na lokomotywie cieni juz nie ma.

Jak nie zapomne to podlacze pokrywany obszar do parametrow shadowtune wiec bedzie mozna sobie bardziej indywidualnie dopasowac co kto woli, jakosc czy zasieg.

edit:
jako ciekawostka, zalacznik numer 2. przy skrajnie zredukowanym (1-2 wagony) zasiegu robia sie nawet cienie poreczy i wycieraczek na szybie ;d
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: dymus w 25 Lipca 2017, 22:52:14
Exe ostatnie. Wygąda tak że kabina czytana z .t3d - przynajmniej dla kilku kabin - (paczka np. z repo) wygląda tak poszarpana (screeny), czytana z wygenerowanych świeżo .e3d dla tego samego modelu wygląda ok, to tak na marginesie - bo sprawa raczej dotyczy paczek dla twórców niż użytkowej dds - nie wiem czy tak powinno być, bo w założeniu z paczki t3d powinno też działać dobrze ;) Więc ogólnie nie jest to problem raczej, ale taką rzecz widzę.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: szogun w 25 Lipca 2017, 22:59:58
Zdecydowanie dla sprzętów świeżych, działało mi maksymalnie na 2048 przy 17 FPS na TD, gdzie przy multiasamplingu x16 jest ~120 :D
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: jakol112 w 25 Lipca 2017, 23:21:41
A z ciekawości - co z cieniami w kabinach? Możliwe to?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 26 Lipca 2017, 01:42:17
Witam.
 Porównałem sobie efekt cieni, miedzy exe @Tmj, a ostatnią wersją Milka na shaderach. Jedne jak i drugie exe generuje je jak powinno. Jak dla mnie jednak wersja Milka7 wygląda lepiej, cienie nie schodkują podczas ruchu, krawędzie są ładnie rozmyte, a różnica w wydajności pomiędzy nimi nie jest zbyt duża ( na korzyść wersji @Tmj). Tu raczej niestety, albo stety od tych nieszczęsnych shaderów nie da się uciec, chcąc mieć ładną grafikę w symulatorze. Chyba że jest inny sposób.
 Co do spadku Fps, takie wodotryski pożerają sporo zasobów. Gdyby dodać do tego jeszcze efekty cząsteczkowe, na niektórych sprzętach pokaz klatek byłby pewny.
 Wypowiem się także na temat cieni w kabinie podczas jazdy. Według mnie jest to bardziej urealnienie niż wada. Oczywiście najlepiej byłoby, gdyby światło i cienie wpadały jedynie przez szyby. W tym przypadku dość irytujące jest podświetlanie kabin przez ściany. 
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Cesky Kretek w 26 Lipca 2017, 01:54:31
TD:
eu07++ng.exe - 145 FPS (+ duże ciemności, nie śledziłem w całości wątku więc może trzeba jakiś parametr atmo zmienić)
eu07-x64_170725.exe - 293 FPS

i7 3770, DDR3 8GB 1600MHz, GTX660 OC 2GB DDR5, HDD 7200, Win7 Pro 64-bit.
(otwierane w oknie, 1600x900, w opcjach NVidii wszystko dot. jakości na max)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 26 Lipca 2017, 02:20:33
U mnie ta różnica nie jest aż tak wielka, ok 15-20 Fps. Prawdopodobnie co komputer to inny wynik będzie. 
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siwydym w 26 Lipca 2017, 07:23:08
U mnie na C++ z 60FPS przy starej wersji na nowej obecnie różnie zależy od scenerii od 100 do 200FPS
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: jakol112 w 26 Lipca 2017, 11:40:09
Zauważyłem błąd, jednakże nie wiem czy występuje on tylko u mnie. Po pewnym czasie jazy cienie po prostu się wyłączają. Czym może być to spowodowane?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Lipca 2017, 13:32:08
Zapewne jest to wspomniany przy publikacji blad -- w niektorych lokacjach cienie z jakiegos nieustalonego jeszcze powodu nie wyswietlaja sie.

W dzisiejszym uaktualnieniu:

- poprawka, dzwieki urzadzen w kabinie powinny byc odtwarzane na wszystkich zdefiniowanych pozycjach

- poprawka, usuwanie zdegenerowanych trojkatow ostrozniej wybiera geometrie do usuniecia

- zasieg generowania cieni (a tym samym, takze ich jakosc) jest teraz kontrolowana przez parametr shadowtune (przez trzeci z parametrow)  Wartosc domyslna to 1250
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: jakol112 w 26 Lipca 2017, 13:38:10
@tmj w trosce o użytkowników niebędących na bierząco z exe prosiłbym o dodanie tu archiwum eu07-data.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: DieselPower w 26 Lipca 2017, 15:00:31
Na ustawieniach z załącznika przy shadowtune 8192, 500, 500, 500 na Całkowo Towarowy mam między 55 a 60 FPS.
Zauważyłem jeden problem - z kabiny wszystkie cienie wyświetlają się prawidłowo; natomiast po przejściu do kamery zewnętrznej są miejsca, gdzie cieni nie ma (pojawiają się dopiero po przesunięciu kamery, po powrocie do tego samego miejsca nagle znikają). Testowane na i5-3470 + GTX1050.

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mareczek w 26 Lipca 2017, 19:36:34
Mi się trafił na niebie jakiś nieokreślony obiekt. Księżyc i słońce było na swoim miejscu.
Ustawienia kolegi DieselPower w wcześniejszego postu, sceneria l053_calkowo-tlk55250

I też się zgodzę, że wersja @Milek7 bardziej przypadła do gustu, szczególnie przez wygładzenie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Lipca 2017, 20:31:07
Zajrzyj do log/errors czy nie ma tam komunikatu o jakiejs brakujacej teksturze.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mareczek w 26 Lipca 2017, 22:50:44
Tam jest bardzo dużo missingów...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Lipca 2017, 23:18:49
Texture file missing: "sky\moon"
Texture file missing: "sky\sun"
Wyglada na to ze tam jest dodatkowo jakies drugie niebo zainstalowane albo cos, a to latajace cos to jest geometria ktora normalnie udaje slonce albo ksiezyc. Sceneria prosto z Gwiezdnych Wojen, tylko piachu na pustynie nie dowiezli.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 26 Lipca 2017, 23:47:29
Scenery sky definition
sky_dynamic_stratus.t3d
To jakaś stara sceneria, niewchodząca w skład 17.07. To niebo i używane przez nie składowe są usuwane przy instalacji aktualizacji, jako kolidujące z nowymi efektami.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Lipca 2017, 23:56:56
W "jutrzejszym" uaktualnieniu:

- poprawka, cienie nie powinny znikac w niektorych lokacjach (w normalnych warunkach; do normalnych warunkow nie zaliczam przesuniecia kamery kilkaset metrow w gore, przynajmniej na razie)

- eksperymentalnie, na potrzeby kalkulacji cieni geometria terenu z przyleglosciami traktowana jest jako dwustronna; pozwala to "pasom lasu" generowac cienie zamiast przepuszczac swiatlo z braku 'tylnej' scianki.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mareczek w 27 Lipca 2017, 07:44:29
Scenery sky definition
sky_dynamic_stratus.t3d
To jakaś stara sceneria, niewchodząca w skład 17.07.
Akurat sceneria jest świeża, bo z czerwca 2016 r. No ale widać z babolem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 27 Lipca 2017, 09:40:11
- eksperymentalnie, na potrzeby kalkulacji cieni geometria terenu z przyleglosciami traktowana jest jako dwustronna; pozwala to "pasom lasu" generowac cienie zamiast przepuszczac swiatlo z braku 'tylnej' scianki.
U milka Cała kalkulacja cieni nie jest robiona od tyłu?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Maniakunitra1 w 27 Lipca 2017, 10:49:12
A ja mam taki problem, że EP07-1066 na linii 61 odmówił posłuszeństwa. Przez przypadek wyłączyłem wyłącznik szybki, po tym incydencie wyłączyłem sprężarkę, przetwornice i klikam magiczne M. I co ? Zapala się lampka, po puszczeniu klawisza gaśnie. Awaria ? ;) Jeszcze nigdy mi się to nie zdarzyło.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 27 Lipca 2017, 15:02:36
U milka Cała kalkulacja cieni nie jest robiona od tyłu?
Tak, usuwanie przy renderowaniu cieni przednich scianek zamiast tylnych to czesto stosowana sztuczka, ale sprawdza sie glownie przy modelach tworzacych zamknieta calosc. Chce sprawdzic jak to bedzie wygladac w roznych konfiguracjach.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 28 Lipca 2017, 06:19:54
Tak to wyglada u mnie. I tak efekt niezwykly. Tyle lat na to czekalismy. Popatrzylem jak to wyglada z perspektywy pasazera. I o to efekt. Brawo Tmj brawo Milek7.
https://youtu.be/YcBnQ8ReTC0
https://youtu.be/E0-X6piIqHQ
https://youtu.be/drkF2y3LCxs

A tu kiedy jest zachod i slonce od tylu https://youtu.be/5N5DORHPOvM

Przy okacji ktos ma sprawdzone ustawienia shadowtune? U mnie jest jak jest przy rozdzialce 4092 jako powierzchni mapy.
Nie patrzcie na stare chlodnie. To taki sposob na nasmiewanie sie z firmy w ktorej jestesmy niewolnikami.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 28 Lipca 2017, 12:08:07
Witam.
 Na najnowszym exe, cienie wyglądają o wiele lepiej. Schodkowanie nie jest już tak duże jak poprzednio. @Tmj, planujesz włączyć do swojej gałęzi exe shadery? Czy spróbujesz wyciągnąć graficznie ile się da z obecnej wersji? Zauważyłem że starasz się maksymalnie optymalizować kod, aby zapewnić dobrą wydajność, wraz z ulepszaniem grafiki. To bardzo dobre rozwiązanie, często pomijane niestety w projektach. Brawo!
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Lipca 2017, 14:40:02
@Tmj, planujesz włączyć do swojej gałęzi exe shadery? Czy spróbujesz wyciągnąć graficznie ile się da z obecnej wersji?
W zalozeniu jest ze w obecnej wersji do wprowadzenia sa dwa ostatnie elementy -- bardziej 'inteligentny' dobor cieniowanego obszaru, co powinno poprawic jakosc przy tych samych parametrach, i obsluga definiowania 'materialu' czyli zestawu tekstur/parametrow w miejsce dotychczasowej pojedynczej tekstury. Taki kod posluzy za 'baze' wersji rozwojowej z wlaczonymi shaderami autorstwa Milka7. Tym sposobem na starszym sprzecie powinno to wygladac w miare przyzwoicie, a na lepszym bedzie moglo wygladac lepiej ;d
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Michal1983 w 29 Lipca 2017, 16:37:15
U mnie w ogóle przestało się eu07.exe uruchamiać. Pojawi się na chwile w procesach a potem znika.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 29 Lipca 2017, 23:41:34
log.txt i errors.txt byloby przydatne. I jakies szczegoly, np od kiedy przestalo sie uruchamiac, a co uruchamialo sie do tej pory. Takze sprawdzenie czy w katalogu symulatora pojawia sie plik z "crashdump" w nazwie, i jesli tak, to rowniez zalaczenie go do zgloszenia.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 31 Lipca 2017, 11:21:15
@Tmj czy dałoby radę przywrócić funkcję ręcznego luzowania hamulca pneumatycznego w wagonach z osobna? Kiedyś ten ficzer zaimplementował bodajże Ra, działało to jak mnie pamięć nie myli po nadleceniu nad wagon i wciśnięciu Shift+6. Powodowało to wypuszczenie powietrza z cylindrów hamulcowych, niezależnie od ciśnienia panującego w PG. Jest to przydatne, gdy porwiemy na przykład skład, ale nie tylko. Ostatnio jechałem z kilkoma bohunami na końcu, i jeden z nich się zbugował. Wypuścił powietrze z PG i koniec jazdy. Odciąć go od hamulca zespolonego pociągu mogłem owszem, ale odhamować nie było już jak... Musiałem zostawić biedaka na szlaku...
Pozdrawiam.
Ps. Chyba że funkcja działa, tylko klawiszologia uległa zmianie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 31 Lipca 2017, 12:03:32
Było na num6. Jeśli jest tak samo jak w lokomotywie, to powinno być pod num4 w widoku zewnętrznym.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 31 Lipca 2017, 13:03:00
Zrobiłem dzisiaj przerzucenie zmian @tmj ja mastera na repo głównym na githubie i zsynchronizowałem zmiany z gitem na eu07.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 31 Lipca 2017, 14:25:14
Było na num6. Jeśli jest tak samo jak w lokomotywie, to powinno być pod num4 w widoku zewnętrznym.
Tak, funkcja jest bez zmian tylko jest teraz pod Num4, tak jak odluzniacz w kabinie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 31 Lipca 2017, 22:21:45
Witam.
 Sprawdziłem jeszcze raz na TD, exe najnowsze. Niestety Num4 poszczególnych wagonów nie luzuje. Działa tylko na pojazd który obsadzamy. Właśnie dlatego pytam o tę funkcje, wcześniej sprawdziłem wszelkie kombinacje klawiszy, jakie mi do głowy przyszły. Byłbym zapomniał, działa tylko sterowanie hamulcem ręcznym mechanicznym ( Ctrl+1 zahamowany, Ctrl+7 odhamowany).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 31 Lipca 2017, 22:41:22
Zapomnialem, ta funkcja dzialala kiedy po zmianach sterowania w widoku zewnetrznym nie bylo sterowania pojazdem obsadzonym. Poniewaz zgloszono zapotrzebowanie by w widoku z zewnatrz komendy byly nadal przekazywane do pojazdu obsadzonego, teraz sa, lacznie z odluzniaczem. Mam watpliwosci czy przy stanie obecnym jest duzy sens w kolejnej zmianie, bo znajac zycie natychmiast komus zacznie z kolei przeszkadzac ze nie moze 'zdalnie' odluznic lokomotywy bez oddalenia sie na min.50 metrow od wagonow? ;s
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 31 Lipca 2017, 22:47:49
ze nie moze 'zdalnie' odluznic lokomotywy bez oddalenia sie na min.50 metrow od wagonow? ;s
Ale tak to właśnie kiedyś działało... Tylko nie wiem, jaka to konkretnie musiała być odległość, żeby odluźniacz działał na najbliższy, a nie obsadzony akurat pojazd.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 31 Lipca 2017, 23:16:30
@Tmj, może to rozwiązać w ten sposób że Num4 luzuje pojazd obsadzony, a np. Ctrl+Num4 luzuje wagon nad/przy którym jesteśmy. Nie wiem jak innym kolegom, ale mi osobiście tej funkcji jest brak. Kilkukrotnie zmuszony byłem zamknąć symulator ze względu na niemożność odhamowania samych wagonów. W realu też jest to praktykowane przecież. Możesz ręcznie wyluzować każdy wagon z osobna w pociągu.
Pozdrawiam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Sierpnia 2017, 03:04:07
Bez sprawdzenia nie jestem pewien czy czasem pod ctrl + num4/6 nie ma jakichs starych jeszcze nie podpietych funkcji, ale tak czy owak mozna pomyslec.

Tymczasem, w dzisiejszym uaktualnieniu:

- zmiany w kodzie dobierajacym ustawienie kamery dla generowania cieni, powinno poprawic nieco ich jakosc chociaz bez szczegolnej rewelacji. W zwiazku ze zmianami nieco inne jest tez znaczenie parametru zasiegu w ustawieniach shadowtune -- o ile poprzednio wartoscia domyslna bylo tutaj 1250, w nowej wersji mniej wiecej ten sam efekt uzyskuje sie z nowa wartoscia domyslna 250.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 01 Sierpnia 2017, 20:37:12
U mnie fps spadl z 40 do okolo 8.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Sierpnia 2017, 21:09:50
Wszedzie, czy na jakiejs okreslonej scenerii? Zobacz, czy cos sie poprawi po zmniejszeniu wielkosci tekstury cieni w parametrze shadowtune. Przy duzej wartosci ilosc przesylanych danych moze przekroczyc mozliwosci sprzetu, i przestaje nadazac.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: DjSon231 w 01 Sierpnia 2017, 21:21:09
-- o ile poprzednio wartoscia domyslna bylo tutaj 1250, w nowej wersji mniej wiecej ten sam efekt uzyskuje sie z nowa wartoscia domyslna 250.

Musisz zmniejszyć parametry shadowtune, bo tmj zmniejszył wartości domyślne.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Sierpnia 2017, 21:25:52
Dla ulatwienia, wartosci domyslne dla parametru teraz to
Cytuj
shadowtune 2048 250 250 500
z czego praktyczne znaczenie maja te pogrubione -- pierwszy to wielkosc mapy, a drugi to zasieg rzucania cieni.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 02 Sierpnia 2017, 11:28:46
Witam.
U mnie przy parametrach shadowtune 8192 250 400 300, przy domyślnym składzie na TD, maksymalnie mam do 100 Fps :-(
 Exe C++ 170731, grafika GTX 460, 4 Gb ramu, procesor Intel E7200. Rozdziałka1280x1024, multiasampling x16.
Pozdrawiam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 02 Sierpnia 2017, 15:04:12
A jak wyglada FPS po zmianie wielkosci mapy do 4096?
Wielkosc 8192 oznacza, ze sama mapa cieni zajmuje ~250mb, i karta graficzna moze zwyczajnie przestac sie wyrabiac, co objawi sie znacznym spadkiem wydajnosci.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Pablo w 02 Sierpnia 2017, 17:28:31
Witam. Panowie przepraszam, że trochę nie na temat. Chciałem też przetestować te cienie i pobrałem dwa pliki parę postów wyżej exe:
1 * eu07-x64_170731.rar i
2 * eu07-data.rar .
Wypakowałem oba pliki do głównego folderu, odpaliłem rainsted i nie ma cieni, ani żadnych parametrów do ich ustawienia np:
shadowtune o którym się tu piszę. Win 7 64bit, Gtx 960. 1920x1200
Napiszcie proszę. Czy ja coś nie tak zrobiłem z instalką, że nie widać tych cieni i brak parametrów w ustawieniach. Wypakowywałem na wersję 17.07.127.
Jeszcze raz sorry, że nie w tym dziale i dzięki za ew. poradę.:) 
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: dymus w 02 Sierpnia 2017, 17:42:15
http://eu07.pl/forum/index.php/topic,29410.msg465803.html#msg465803
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Pablo w 02 Sierpnia 2017, 17:53:58
Dzięki za linka. Wielkie dzięki:)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 02 Sierpnia 2017, 18:38:38
No na kaliskiej w zwk. Wvzesniej bylo tsm okolo 20 fps na szlaku i 60 bywalo. Tetaz wartosci przez polowe. I jeszcze jedna rzecz. Okolo 18 przed 19 (movelight 0) widac jeszcze slonce zachodzsce tzn czesc korony slonca a cienie zucane sa juz jakby od ksiezyca ktory z pewnoscia jeszcze nie powinien zucac cieni nawet poznym wieczorem. Piwinien byc etap przejsciowy az do zaciemnienia prawie calkowitego. Ksiezyc zuca cien tylko po ciemku i bez chmurek na niebie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 02 Sierpnia 2017, 20:25:41
Czekaj, troche bardziej metodycznie.
Czy te 20/60 fps na Kaliskiej to bylo na poprzedniej wersji z cieniami (170727) czy na jeszcze wczesniejszych, bez cieni?
Jesli z cieniami, to przy jakich parametrach wpisu shadowtune?
Wydajnosc w wersji obecnej, czy to jest przy zmienionym wpisie shadowtune, czy taki sam jak poprzednio?

Co do cieni slonca/ksiezyca, tutaj jest ograniczenie w obecnym modelu. Mamy tylko jedno 'aktywne' zrodlo swiatla, wybierane na podstawie tego, ktore z nich jest w danym momencie silniejsze. Troche mozna tutaj pooszukiwac przy doborze parametrow, zobaczymy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 03 Sierpnia 2017, 06:21:05
Zdecydowanie zachodzace słońce rzuca wiecej światła niż księżyc tym bardziej, że jest widno. Fps spadł mi o połowę od czasu wprowadzenia cieni. Zmiana mapy na 1024 i tego drugiego na 250 niewiele pomoglo. Po zmianie tych wpisow fps wzrosl o moze 2 do 3 w zwk. Mierze w jednym miejscu by miec porównanie. Jednocyfrowy fps w Ow.
Komp stary ale dawał rade. Proc i3 8gb ram karta gf gts450. Win 10 x64.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 03 Sierpnia 2017, 15:02:21
Aa jesli to zmiana po wprowadzeniu cieni w ogole to juz mniej dziwne; spory spadek wydajnosci jest tutaj nieunikniony, zazwyczaj bedzie to w granicach ~30% ale na slabszym sprzecie jesli przekroczy mozliwosci karty graficznej to bedzie gorzej. Mozna sprobowac takze redukcji zakresu, np do poziomu:
Cytuj
shadowtune 1024 250 50 500
ale jesli i to nie pomoze to pozostaje tylko je wylaczyc
Cytuj
shadows no
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 03 Sierpnia 2017, 23:35:23
A jak wyglada FPS po zmianie wielkosci mapy do 4096?
Wielkosc 8192 oznacza, ze sama mapa cieni zajmuje ~250mb, i karta graficzna moze zwyczajnie przestac sie wyrabiac, co objawi sie znacznym spadkiem wydajnosci.
Witam.
 Dopiero dzisiaj miałem chwilkę czasu na dalsze testy, a więc... Po zmianie rozmiaru shadowmapy z 8192 na 4096 Fps znacząco podskoczył ( wpis u mnie ma obecnie taką postać 4096 250 400 500), czy można tu jeszcze coś zmienić? Wydajność na TD wynosi teraz ok 160 kl/s. Ale prawdziwym sprawdzianem było uruchomienie jakże by inaczej Kaliskiej i jazda po Ostrowie Wlkp. Na stacji wynik średni to 40-60, szlak ok 80. Przy okazji, genialnie są widoczne teraz światła semaforów, szczególnie w porze nocnej. Oto chodziło właśnie!
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 04 Sierpnia 2017, 00:54:50
wpis u mnie ma obecnie taką postać 4096 250 400 500), czy można tu jeszcze coś zmienić?
Zasieg (przedostatni parametr) mozna chyba dosc bezpiecznie zredukowac do ok. 300, z tego co widze na sceneriach jest to wystarczajaco daleko by 'pojawianie sie' cieni nie rzucalo sie w oczy, a zmniejszony obszar oznacza troche lepsza jakosc i wydajnosc.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 04 Sierpnia 2017, 09:12:23
Witam.
 Zasięg zmniejszyłem próbnie do 300, nie jest źle. Jednak widać wyraźnie cienie pojawiające się w oddali na ścianach wysokich budynków. @Tmj, zauważyłem że wyłączyłeś przenikanie cieni do kabin. Trochę szkoda w sumie...Dodawało to klimatu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 04 Sierpnia 2017, 20:33:16
Nowa wersja odgałęzienia od tabelki prędkości. Bazuje na wersji 20170725. Pliki w changelogu. Jak tylko tmj wrzuci coś na ruszt (repo) to zaktualizuje podstawę.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: ST44-003 w 04 Sierpnia 2017, 21:50:02
Trochę jestem do tyłu z niektórymi wersjami i datami, ale u mnie wciąż jest taki efekt jak na screenie. Jakie jest na to panaceum?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 04 Sierpnia 2017, 22:01:03
Panaceum jako takiego nie ma, jakosc efektu zalezy od wielkosci mapy cieni, i pokrytego nia obszaru. Np przy wpisie
shadowtune 4096 250 100 500
efekt jest jak na zalaczniku, ale zakresu starcza na pokrycie ~4 wagonow. Po zmianie na
shadowtune 4096 250 300 500
jakosc spada, jak na zalaczniku 2, ale zasieg wzrasta 3-krotnie. Zmniejszenie rozdzielczosci mapy (1szy parameter) ma rowniez (negatywny) wplyw na jakosc, ale mniej obciaza karte graficzna. Tak wiec trzeba sobie wybrac indywidualnie kombinacje zasiegu/jakosci ktora jest najbardziej odpowiednia. Ogolnie jakosc lepsza jest w wersji shaderowej Milka7, gdzie jest wiecej mozliwosci jesli chodzi o wygladzanie cieni itp.

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 05 Sierpnia 2017, 07:04:59
Czemu nie mozna tego od milka polaczyc z twoim? I potem udoskonalac jedna podstawe.