sajmon313 - 24-12-2009, 16:46 Temat postu: Eksperyment - Dziwne wyniki Zrobiłem dziś eksperyment dot. szybkości różnych obiektów. Oto wyniki: wszystkie prędkości podaję w m/s, zakres błędu: +- 0,2 m/s wszystkie obiekty poruszające się po ziemi korzystały z 1 programu, a wszystkie latające z 2 programu, więc nie ma ryzyka błędu spowodowanego różnicom w programach 1) Na płaskim terenie
Wniosek jest jeden: lepiej latać. Powyższe wyniki są w miarę normalne, ale dalej jest już conajmniej dziwnie. 2) pod górkę, Pitch= 21,8 (Z oznacza że utrzymuje pozycje - nie zsuwa sie po zatrzymaniu). Latające nie brały udziału
Można zauważyć, że mrówka, pająk i robal poruszają się szybciej pod górkę niż na płaskim terenie! Ale już LeggedGrabber nie. 3) pod górkę, Pitch= 38 (Z jak poprzednio, N - nie może podejść)
Obcy jeszcze bardziej przyspieszają! Ale roboty zachowują się normalnie (na razie). WheeledGrabber i WingedGrabber nie mogą podjechać pod tą górkę. 4) pod górkę, Pitch= ~60 (Z, N jak poprzednio)
Pająk i Mrówka wreszcie zaczęły zwalniać, Robal bardzo przyspieszył, ale najważniejsze: WheeledGrabber i WingedGrabber mogą podjechać pod górkę pitch=60, a pod pitch=38 nie mogą !? Bardzo dziwne. W testach wykorzystałem relief21 dostępny standardowo w colobocie. C ruels! - 24-12-2009, 17:35 Na każdej mapie/reliefie wyniki będą nieco inne.Chyba wziąłeś to pod uwagę? Berserker - 24-12-2009, 17:50 Moge sie zapytac, w jaki sposob mierzyles predkosc? Kiedys mierzylem i wynik zalezal od tego jaka jednostke czasu wzialem. Tech? WTF is that? FE4R - 24-12-2009, 17:55 A co, na każdej mapie pitch równy tyle samo znaczy coś innego? 
Jest taki bug w grze; jest również w temacie Ciekawostki - robot na kołach potrafi podjechać pod pionową ścianę, nawet robot na nogach tak nie potrafi. Dziwne, nieprawdaż? To samo zauważyłem, gdy chciałem WingedGrabberem zabrać PowerCell ze ściany o nachyleniu większym niż 45 stopni. Aha, i jeszcze jedno - czy mógłbyś mi na PW przesłać program, który wykorzystałeś do testowania prędkości? EDIT:
Wyobraź sobie, że dystans przebyty w 0.1 sekundy będzie 10 mniejszy niż przebyty przez 1 sekundę... Jeśli chcesz mieć w m/s trzeba przemnożyć dystans przez 10. A Tech to inżynier - widoczny w środku Centrum Kontroli Misji w Houston oraz na końcu Kampanii. Berserker - 24-12-2009, 18:24
Ja nie licze dystansu, tylko predkosc przy maksymalnej mocy obu silnikow. teoretycznie ona powinna byc taka sama niezaleznie od kroku czasowego. Ale przy kroku czasowym wynoszacym 0.01 sekundy predkosc osy wychodzila mi 50-80 m/s sajmon313 - 24-12-2009, 19:36
Generalnie wykorzystywałem ten program:
ale na płaskiej powierzchni było bez if (co nic nie zmienia, ale później musiałem dodać) natomiast dla latających:
to L albo S przed category po to, żeby było wiadomo czy lata czy nie. Wynik distance jest w (metrach colobotowych)*10 bo 10s, więc
jest w metrach na sekundę.
Czym dłuższy czas pomiaru tym większa dokładność. Mój eksperyment powtarzałem kilka razy i czasami wychodziły troszkę inne wyniki (stąd na początku pierwszego posta napisałem +-0,02 bo w takich granicach się zmieniało). Berserker - 24-12-2009, 22:27 A, znalazlem jeden blad! 
Roboty, zwlaszcza latajace, troche sie rozpedzaja. Ty zaczynasz pomiar predkosci odrazu bez rozpedzania sie. Moze to w niewielkim stopniu wplynac na pomiar. Niby sie czepiam, ale takie drobnostki moga byc zrodlem anomalii zwiazanymi z lazeniem mrowek. sajmon313 - 24-12-2009, 22:48
Słuszna uwaga. Do końca roku powtórze wszystkie testy, ale dodam wait(5) przed pomiarem pierwszej pozycji. btw. mrówki nie są latające 
Berserker - 24-12-2009, 23:22 Dlatego napisalem 'lazeniem' 
Chodzilo mi o fakt, ze mrowki szybciej chodza po powierzchniach pochylych 
FE4R - 25-12-2009, 13:48
Masz na myśli czas eksperymentu czy wartość, którą wstawiasz w wait();? Bo jeśli to drugie - to nie. Im mniejszą wartość dasz, tym dokładniej wychodzi.
A jak liczysz prędkość bez liczenia jaki dystans przebył robot? Berserker - 25-12-2009, 14:19
Zdecyduj sie czego sie czepiasz. Najpierw probujesz mnie przekonac, ze ja otrzymalem dystans przebyty przez robota (jakbym nie umial predkosci liczyc). Teraz sie mnie czepiasz, ze licze predkosc bez dystansu. Dystansu nie licze, dystans mam podany
Podstawowa definicja ruchu jednostajnego: predkosc jest jednakowa w kazdym momencie ruchu. Niewazne, czy dasz 0.01s czy 100s, przebyta droga w tym czasie po podzieleniu przez ten czas da nam zawsze jednakowa predkosc. A teraz ciekawostka: Predkosc osy liczona przy kroku czasowym wynoszacym 2s: Za pomoca wait() wynosi ~12.5m/s Za pomoca abstime() wynosi ~9.5m/s Niby mala roznica. A teraz przy kroku czasowym wynoszacym 0.01s: Za pomoca wait() ~40m/s - O_O Za pomoca abstime() ~0.45m/s - Q__Q Wychodzi na to, ze nie da sie porzadnie zmierzyc predkosci chwilowej. sajmon313 - 25-12-2009, 14:47
ale jak w ten sposób zmierzyłeś dokładnie prędkość? Sam napisałeś wcześniej że roboty latające chwilę się rozpędzają... [ Dodano: 25-12-2009, 16:41 ] No więc wziąłem poprawkę na rozpędzanie się, ale obcy nadal są szybsi pod górkę. I dodatkowo przetestowałem więcej robotów. Prędkości: PhazerShooter, Shielder, Recycler i Thumper są dokładnie takie same, więc będę pisał tylko dla PhazerShooter. Subber ma prędkość taką samą jak TrackedGrabber. Zawsze myślałem że Me = Tech (poza czapką z daszkiem), ale okazało sie że nie: 1) Płaski teren
2) Pitch = 21 (Z - nie zsuwa się po zatzrymaniu)
3) Pitch = 38 (N - nie może podejść)
Me jest szybszy na płaskim, ale gdzie Me nie może, tam Tech podejdzie
4) Pitch = 60 Tu jak zwykle wyszły dziwne rzeczy:
Do klubu dziwnie zachowujących się obiektów dołączył Me. I nadal zostaje przy twierdzeniu, że czym dłuższy czas pomiaru tym dokładniejszy wynik, Poniżej uzasadnienie: Przypuśćmy, że chcemy zmierzyć prędkość dla bardzo małego odcinka czasu. (np. 0.01s) W colobocie pozycja podawana jest z dokładnością do 2 miejsc po przecinku. Więc robot musi poruszać się w ten sposób:
Oczywiście można zmienić żeby przesuwał się z większą dokładnością, ale nigdy nie będzie to płynne przesunięcie. Więc jeżeli zmierzysz tą prędkość akurat w czasie gdy zmienia położenie, to wyjdzie ogromna prędkość, a jak zmierzysz w czasie czekania to wyjdzie bardzo mała. Przez dłuższy czas pomiaru uśredniamy wynik: dla moich 10 sekund pomiaru wahania wynosiły 0,02m/s, przy 100 sekundach byłyby 10 razy mniejsze Berserker - 25-12-2009, 16:58 @up Ja za pomoca petli robie tak, ze otrzymuje co jakis czas pomiar i po prostu licze srednia.
sajmon313 - 25-12-2009, 17:30
Błędy: jet(1) w pętli - dlaczego lecisz w górę? jak już tak chcesz to zastosuj distance2d. po co wait w dwóch miejscach? Dowiesz się, dlaczego robisz to źle, jak zmienisz message na:
U mnie pokazuje: 4-6 s! a jak usunąłem jet(1) z pętli i tylko dałem żeby an początku przez 2 sekundy zwiększał wysokość, to 2-3s Wniosek: wykonanie instrukcji która nie porusza robotem też zabiera trochę czasu. adiblol - 25-12-2009, 18:57 Jak dokładnie policzyć?
Można też zrobić kilka pomiarów (np. co sekundę) i średnią wyliczyć... A tak w ogóle to abstime() ssie bo jak się przerwie grę przez wyjście do menu to on NADAL LICZY (WTF?). FE4R - 25-12-2009, 21:08
Czepiać to się można na ściance wspinaczkowej. Po prostu nie rozumiem, jakiego Ty programu używasz, że wszystko tak niezrozumiale liczysz.
Robot, szczególnie latający nie porusza się ruchem jednostajnym, jak to sam zauważyłeś. Prędkość nie jest taka sama; tak jak wcześniej - robot latający będzie miał zmienną prędkość, szczególnie przy opadaniu / wznoszeniu. To samo tyczy się robotów naziemnych przy zmiennym 'pitch'. Chodziło mi o to, że jeśli w wait(); wpiszesz 10, dostaniesz wynik po 10 sekundach. Gdy wpiszesz 0.1 sekundy - dostaniesz więcej wyników i możesz uchwycić np. maksymalną prędkość robota latającego (wyniosło chyba 20-21 m/s).
W końcu nie planujemy wyprawy w kosmos, ale sprawdzamy prędkość robotów w prostej gierce.
Przecież gdy robot się wznosi, to chyba nazwiesz to prędkością, prawda? Berserker - 25-12-2009, 21:20
To jest program dla osy - mam nadzieje, ze wyjasnilem wszystko?
To nie znaczy, ze wahania beda wynosily ponad 10m/s.
Albo te zmiany sa az tak krotkotrwale, ze nie da sie ich zauwazyc w czasie normalnej gry, albo potrzebuje mocniejsze okulary (cholerna okulista!).
Ja wole predkosc w poziomie, ma wieksze zastosowanie w programach do celowania. sajmon313 - 26-12-2009, 00:29
No więc chodzi o prędkość w poziomie, bo: 1) żeby można było ją porównać z prędkoścą obiektów naziemnych 2) przydaje się w celowaniu 3) większość map w colobocie mo bardzo niskie ograniczenie wysokości lotu (ok. 100m), a w poziomie jest ponad 700m (od końca do końca mapy). A jeszcze w kwestii technicznej: Czy roboty latające mają osobny silnik do jet(), a osobny do motor() ? Eksperyment wyglądasłby tak: zmierzyć distance2d w czasie gdy na jakiejś wysokości leci z motor(1,1); oraz zmierzyć distance2d w czasie gdy będzie lecieć z motor(1,1) i jet(1). I jeszcze jedna kwestia techniczna: Czy wiatr na pewno nie wpływa na prędkość robotów latających? FE4R - 26-12-2009, 00:45
Lecz, gdy chcesz to wykorzystać do programów przeciwko obcym, to jest pewien problem, gdyż średni altitude osy to 7.88 metra nad powierzchnią (zakładając, że cały czas leci na jet(1);). Jeśli z wyższego punktu zleci do doliny, to będzie znacznie szybsza, co tyczy się też opadających robotów (u mnie prędkość wzrosła od 14 m/s do 22 m/s). A tak na marginesie to chyba nie potrzeba wiedzieć aż tylu stałych (średnich?), aby zestrzelić osę z Epsitecowskim programem.
Tak.
Nie. dasdads - 01-03-2010, 17:14 wyjasniam o co może chodzic: po pierwsze primo-ultimo pomiar (funkcje i linkjki) np. x=this.position\dist=distance(position,start)/ zajmuje troche czasu, proponuje zmieżyć ile (wpisując w program cala i jedynie sekwencje pomiaru czasu, jesli wyjdzie 0 to sie myle, ale raczej nie wyjdzie po grudo secundo jeśli nie wyjdzie 0 to ważne jest co sprawdzisz pierwsze czas czy odległość, proponuje podczas ruchu jedynie zdjąć pomiary, a dopiero po zatrzymaniu przeliczyc, gdyż to tesz może zafałszowaćpomiar (chyba) po trzecie tetrio jak postawiłeś techników, niszczonc houston czy przez /// produce(position,0,?Tech?,"");/// ?? ty robiłeś mape, czy robiłeś to podczas misji/swobodnej gry? //moja sugestia// proponuje sprawdzić czy niesienie ładunku/rodzaj ogniwa i ładuku wpływa na prędkość |
