eu07/maszyna
17
0
Fork 0
mirror of https://github.com/MaSzyna-EU07/maszyna.git synced 2026-10-17 00:29:19 +02:00
Code Issues 150 Wiki Activity

Przygotowanie exe pod środowisko testowe #541

New Issue
Open
opened 2026-09-30 19:02:28 +02:00 by jakubg1 · 2 comments
jakubg1 commented 2026-09-30 19:02:28 +02:00
Owner
Copy Link

Zgodnie z #509 chcę już mniej więcej omówić jak środowisko testów automatycznych by mogło wyglądać.

Celem jest możliwość uruchomienia MaSzyny z konkretną scenerią jako ghostview, z nullrendererem i argumentem w commandline, np. --test, który by przetestował scenerię i zwrócił wynik jako statuscode.

Kilka spostrzeżeń:

Wynik testu

  • Na 99% wynikiem testu będzie pozycja pojazdu, natomiast raczej nie wystarczy wywołanie eventu wpuszczonego w tor, bo test może się zaliczyć podczas gdy pociąg AI za chwilę na 100% przewaliłby S1. Może hybryda eventu zaliczenia + wszystkie pociągi stoją będzie wystarczające?
  • Przejechanie S1 jest chyba logowane, więc taka sytuacja automatycznie zakończyłaby scenariusz testowy niepowodzeniem.
  • Jeżeli test trwa zbyt długo, to powinien zostać przerwany z negatywnym wynikiem. Można spróbować kombinację warunków:
    • żaden pojazd się nie porusza
    • żaden pociąg AI nie ma nic w tabelce rozkazów
    • kolejka eventów jest pusta
  • Problemem mogą być nic nie robiące eventlaunchery albo pociągi AI nic nie robiące sobie z faktu posiadania jakiejś komendy, której nie potrafią wykonać. Na takie sytuacje pomoże chyba tylko watchdog albo limit czasu symulacji do np. 1 godziny w grze.
  • W przyszłości jeżeli mielibyśmy bardziej rozbudowane testy, które np. dopuszczają przejechanie S1, można by się pobawić wpisem takim jak:
testconfig
fail_if_stop_overran yes
no_movement_before_pass yes
endtestconfig

albo nieco prościej, używając istniejącego mechanizmu configów:

config
test.fail_if_stop_overran yes
test.no_movement_before_pass yes
endconfig

Stabilność

MaSzyna działa różnie na różnym sprzęcie, i czasem kilkukrotne uruchomienie tego samego scenariusza może dać różny rezultat (co swoją drogą warto poprawić jeżeli tak jest, kroków fizyki chyba zawsze się wywołuje 100 na sekundę). Testy raczej chcemy żeby były deterministyczne i trwały jak najkrócej, więc proponuję prostą pętlę która najszybciej jak to umie wykonuje stałe kroki symulacji bez zważania na czas rzeczywisty.
Proponuję emulowanie działania w 30fps i fizykę w 100Hz, bo im mniej dokładna fizyka tym mniejsza dokładność i tym samym mniejszy margines błędu.
Nie wiem czy uruchamianie exe z nullrendererem pomija nieistotne elementy takie jak wczytywanie tekstur. Nie powinny one być ładowane w trybie testów integracyjnych. Modele 3D chyba być muszą, bo są mierzone do uzyskania niektórych parametrów fizyki. Poprawcie mnie jak się mylę.

Zakres prac (po stronie EXE) dla minimalnego nakładu pracy do rozwinięcia później

  • Dodanie nowego memcella __test.result
    • Wpisanie do niego wartości num1 spowoduje wyłączenie się symulatora, wpisanie 0 oznacza porażkę, 1 sukces, inne wartości ignorowane
    • Przykład: event test_pass PutValues 0 __test.result 0 0 0 * 1 * endevent
  • Dodanie commandline argumentu --test który uruchomi tryb testów integracyjnych. W tym trybie:
    • parametr -s jest wymagany
    • parametr -v jest ignorowany
    • renderer jest bezwarunkowo ustawiany na nullrenderer
    • tekstury przestają być wczytywane
    • emulowane jest 30fps w 100Hz fizyki w ścisłej pętli bez akceptowania inputów z zewnątrz
    • program zwraca wynik testu w formie statuscode
    • przejechanie S1 automatycznie kończy symulację z wynikiem negatywnym

Nadmienię, że do uruchomienia testów lokalnie potrzebna jest również prosta sceneria do testów (duh), a do uruchomienia testów z github api trzeba jakiejś czarnej magii, ale przynajmniej pobranego repo choćby i być może w okrojonej formie (np. bez tekstur, dźwięków czy modeli otoczenia).

Pytania, propozycje - piszcie śmiało.

Zgodnie z #509 chcę już mniej więcej omówić jak środowisko testów automatycznych by mogło wyglądać. Celem jest możliwość uruchomienia MaSzyny z konkretną scenerią jako ghostview, z nullrendererem i argumentem w commandline, np. `--test`, który by przetestował scenerię i zwrócił wynik jako statuscode. Kilka spostrzeżeń: ### Wynik testu - Na 99% wynikiem testu będzie pozycja pojazdu, natomiast raczej nie wystarczy wywołanie eventu wpuszczonego w tor, bo test może się zaliczyć podczas gdy pociąg AI za chwilę na 100% przewaliłby S1. Może hybryda eventu zaliczenia + wszystkie pociągi stoją będzie wystarczające? - Przejechanie S1 jest chyba logowane, więc taka sytuacja automatycznie zakończyłaby scenariusz testowy niepowodzeniem. - Jeżeli test trwa zbyt długo, to powinien zostać przerwany z negatywnym wynikiem. Można spróbować kombinację warunków: - żaden pojazd się nie porusza - żaden pociąg AI nie ma nic w tabelce rozkazów - kolejka eventów jest pusta - Problemem mogą być nic nie robiące eventlaunchery albo pociągi AI nic nie robiące sobie z faktu posiadania jakiejś komendy, której nie potrafią wykonać. Na takie sytuacje pomoże chyba tylko watchdog albo limit czasu symulacji do np. 1 godziny w grze. - W przyszłości jeżeli mielibyśmy bardziej rozbudowane testy, które np. dopuszczają przejechanie S1, można by się pobawić wpisem takim jak: ``` testconfig fail_if_stop_overran yes no_movement_before_pass yes endtestconfig ``` albo nieco prościej, używając istniejącego mechanizmu configów: ``` config test.fail_if_stop_overran yes test.no_movement_before_pass yes endconfig ``` ### Stabilność MaSzyna działa różnie na różnym sprzęcie, i czasem kilkukrotne uruchomienie tego samego scenariusza może dać różny rezultat (co swoją drogą warto poprawić jeżeli tak jest, kroków fizyki chyba zawsze się wywołuje 100 na sekundę). Testy raczej chcemy żeby były deterministyczne i trwały jak najkrócej, więc proponuję prostą pętlę która najszybciej jak to umie wykonuje stałe kroki symulacji bez zważania na czas rzeczywisty. Proponuję emulowanie działania w 30fps i fizykę w 100Hz, bo im mniej dokładna fizyka tym mniejsza dokładność i tym samym mniejszy margines błędu. Nie wiem czy uruchamianie exe z nullrendererem pomija nieistotne elementy takie jak wczytywanie tekstur. Nie powinny one być ładowane w trybie testów integracyjnych. Modele 3D chyba być muszą, bo są mierzone do uzyskania niektórych parametrów fizyki. Poprawcie mnie jak się mylę. ### Zakres prac (po stronie EXE) dla minimalnego nakładu pracy do rozwinięcia później - Dodanie nowego memcella `__test.result` - Wpisanie do niego wartości num1 spowoduje wyłączenie się symulatora, wpisanie `0` oznacza porażkę, `1` sukces, inne wartości ignorowane - Przykład: `event test_pass PutValues 0 __test.result 0 0 0 * 1 * endevent` - Dodanie commandline argumentu `--test` który uruchomi tryb testów integracyjnych. W tym trybie: - parametr `-s` jest wymagany - parametr `-v` jest ignorowany - renderer jest bezwarunkowo ustawiany na `nullrenderer` - tekstury przestają być wczytywane - emulowane jest 30fps w 100Hz fizyki w ścisłej pętli bez akceptowania inputów z zewnątrz - program zwraca wynik testu w formie statuscode - przejechanie S1 automatycznie kończy symulację z wynikiem negatywnym Nadmienię, że do uruchomienia testów lokalnie potrzebna jest również prosta sceneria do testów (duh), a do uruchomienia testów z github api trzeba jakiejś czarnej magii, ale przynajmniej pobranego repo choćby i być może w okrojonej formie (np. bez tekstur, dźwięków czy modeli otoczenia). Pytania, propozycje - piszcie śmiało.
jakubg1 added the featureexe/rozgrywka!important labels 2026-09-30 19:02:28 +02:00
danniel commented 2026-09-30 22:41:19 +02:00
Member
Copy Link

Na 99% wynikiem testu będzie pozycja pojazdu, natomiast raczej nie wystarczy wywołanie eventu wpuszczonego w tor, bo test może się zaliczyć podczas gdy pociąg AI za chwilę na 100% przewaliłby S1. Może hybryda eventu zaliczenia + wszystkie pociągi stoją będzie wystarczające?

Możemy zrobić event0 na odcinku którego długość będzie buforem dokładności.

Przejechanie S1 jest chyba logowane, więc taka sytuacja automatycznie zakończyłaby scenariusz testowy niepowodzeniem.
Nie jest ale można ogarnąć w kodzie

Jeżeli test trwa zbyt długo, to powinien zostać przerwany z negatywnym wynikiem. Można spróbować kombinację warunków:
żaden pojazd się nie porusza
żaden pociąg AI nie ma nic w tabelce rozkazów
kolejka eventów jest pusta

Można rozpisać w watchdogu, że zakładamy pojawienie się logu wyzwolenia eventu x przez pojazd y w sekundzie a +- b - wtedy widać czy coś się opóźnia na bieżąco - tak trzeba w trybie testowym zapisywać czas z naliczonych kroków

Tutaj płynnie przechodzę do pomysłu że watchdog powinien być jakimś odrębnym programikiem (nawet w pythonie) co analizuje m.in. zużycie ramu procesu maszyny, ew kod zakończenia + stderr, no i analizowałby log.txt względem założeń.

_Na 99% wynikiem testu będzie pozycja pojazdu, natomiast raczej nie wystarczy wywołanie eventu wpuszczonego w tor, bo test może się zaliczyć podczas gdy pociąg AI za chwilę na 100% przewaliłby S1. Może hybryda eventu zaliczenia + wszystkie pociągi stoją będzie wystarczające?_ Możemy zrobić event0 na odcinku którego długość będzie buforem dokładności. _Przejechanie S1 jest chyba logowane, więc taka sytuacja automatycznie zakończyłaby scenariusz testowy niepowodzeniem._ Nie jest ale można ogarnąć w kodzie _Jeżeli test trwa zbyt długo, to powinien zostać przerwany z negatywnym wynikiem. Można spróbować kombinację warunków: żaden pojazd się nie porusza żaden pociąg AI nie ma nic w tabelce rozkazów kolejka eventów jest pusta_ Można rozpisać w watchdogu, że zakładamy pojawienie się logu wyzwolenia eventu x przez pojazd y w sekundzie a +- b - wtedy widać czy coś się opóźnia na bieżąco - tak trzeba w trybie testowym zapisywać czas z naliczonych kroków Tutaj płynnie przechodzę do pomysłu że watchdog powinien być jakimś odrębnym programikiem (nawet w pythonie) co analizuje m.in. zużycie ramu procesu maszyny, ew kod zakończenia + stderr, no i analizowałby log.txt względem założeń.
jakubg1 commented 2026-09-30 22:45:08 +02:00
Author
Owner
Copy Link

Możemy zrobić event0 na odcinku którego długość będzie buforem dokładności.

Dokładnie tak pomyślałem. Zgadzam się.

Nie jest ale można ogarnąć w kodzie

Zgadza się

Można rozpisać w watchdogu, że zakładamy pojawienie się logu wyzwolenia eventu x przez pojazd y w sekundzie a +- b - wtedy widać czy coś się opóźnia na bieżąco - tak trzeba w trybie testowym zapisywać czas z naliczonych kroków

Tutaj płynnie przechodzę do pomysłu że watchdog powinien być jakimś odrębnym programikiem (nawet w pythonie) co analizuje m.in. zużycie ramu procesu maszyny, ew kod zakończenia + stderr, no i analizowałby log.txt względem założeń.

Analiza pliku log.txt nie jest złym pomysłem. Ale to już nie po stronie exe, do implementacji flow/CI testów jeszcze dojdziemy :)
Natomiast zapisywanie checkpointów to już wyższa szkoła jazdy. Da się zrobić :P

> Możemy zrobić event0 na odcinku którego długość będzie buforem dokładności. Dokładnie tak pomyślałem. Zgadzam się. > Nie jest ale można ogarnąć w kodzie Zgadza się > Można rozpisać w watchdogu, że zakładamy pojawienie się logu wyzwolenia eventu x przez pojazd y w sekundzie a +- b - wtedy widać czy coś się opóźnia na bieżąco - tak trzeba w trybie testowym zapisywać czas z naliczonych kroków > > Tutaj płynnie przechodzę do pomysłu że watchdog powinien być jakimś odrębnym programikiem (nawet w pythonie) co analizuje m.in. zużycie ramu procesu maszyny, ew kod zakończenia + stderr, no i analizowałby log.txt względem założeń. Analiza pliku log.txt nie jest złym pomysłem. Ale to już nie po stronie exe, do implementacji flow/CI testów jeszcze dojdziemy :) Natomiast zapisywanie checkpointów to już wyższa szkoła jazdy. Da się zrobić :P
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
!important
Do oznaczania ważnych kwestii
 błąd
Błąd w symulatorze
 cleanup
Usuwanie zawartości lub funkcjonalności, porządki
 duplikat
Ten błąd był już zgłoszony
 exe/edytor
Exe - sprawy dotyczące edytora
 exe/fizyka
Exe - fizyka jazdy lub obsługa pojazdu
 exe/renderer
Exe - sprawy dotyczące renderera
 exe/rozgrywka
Exe - dotyczące stanów symulatora, ogólnotechniczne
 feature
propozycja usprawnienia/nowości
 odrzucone
Ten wątek nie będzie prowadzony dalej
 repo/dzwieki
Dotyczy dźwięków w symulatorze
 repo/model
Dotyczy modelu pojazdu/otoczenia
 repo/ogólne
Repo - sprawy ogólne
 repo/pojazdy
Dotyczy plików pojazdów - mmd/fiz/textures.txt - innych rzeczy pojazdowych nie kwalifikujących się do modlei/dzwiekow/tekstur
 repo/python
Dotyczy skryptów pythonowych
 repo/scenariusze
Dotyczy scenariuszy
 repo/scenerie
Dotyczy scenerii
 repo/tekstury
Dotyczy tekstur
 www/forum
Dotyczy forum
 www/git
Dotyczy portalu zgłoszeń
 www/strona-glowna
Dotyczy strony głównej eu07.pl
 www/upload
Dotyczy uploadu
 www/wiki
Dotyczy wiki.eu07.pl
No Label !important exe/rozgrywka feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
daniu danniel DieselPower DzordZ fuji8 Hirek Iwan-XXI jakubg1 Kermit Kogut macius5991 MichauSto MiloszDorsz spot57 Turbokibel x_Zielu
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: eu07/maszyna#541
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?