Sprint 2 / Team B2

[ral2bp]

Ütközés detekció és mozgásállapot-változás szimuláció

• Input: Világmodell
• Output: Az ütközések detektálása, objektumtípus függőség, új mozgásállapot minden mozgó, ütköző objektumnak
• Challenge: Nem túltolni - keep it simple.

Definition of Done:

• [x] Mozgó objektumok érintkezésének pozíció és dimenzióhelyes detekciója és kommunikációja megvalósult
• [x] Mozgó és statikus objektumok érintkezésének pozíció és dimenzóhelyes detekciója és kommunikációja megvalósult
• [ ] Az objektumok mozgásállapota az energiamegmaradás törvényeinek megfelelően változik (gyorsul, lassul, irányt vált, megáll)
• [x] Az objektumok sérülnek, megsemmisülnek, amennyiben túl nagy energiával ütköznek
• [x] A játék véget ér, ha gyalogost gázolunk
• [x] A játék véget ér, ha a játékos ütközés következtében mozgásképtelenné válik (sebessége 0-ra csökken, vagy megsemmisül)

Megjegyzések

• Az NPC - NPC ütközés nem fontos, tehát NPC autó ha átmegy a gyalogoson nem kell, hogy kiváltson különösebb reakciót
• Ugyanígy az NPC - tereptárgy ütközés sem túl magas prioritású, ugyanis ha az NPC jól van szkriptelve, nem fog letérni az útról és nekimenni a fának

[Horti94]

@ravaszla szeretnénk megkérdezni, hogy a feladatunkat hogyan tudjuk tesztelni/megnézni mit produkál futás közben? A mostani master branch-en teljesen szét van esve minden hetek óta és használhatatlan, így nem tudunk merge-elni, anélkül meg a számunkra nélkülözhetetlen funkciók nem elérhetőek!

[pintergreg]

@Horti94 Ti vagytok a vizualizáció, nem nálatok esik szét a rajzolás? Erről beszéltünk a múltkor, valaki felvetette, hogy kétszer van negálva a (?) forgatási szög, már nem tudom mi. Az illetékes csapat hevesen helyeselt és abban maradtunk, hogy ezt pikk-pakk meg lehet oldani.

[Horti94]

@pintergreg Eredetileg valóban volt egy olyan probléma, hogy egyik csapat sem negálta a forgatási szöget ezért rosszul volt kirajzolva a pálya. Ezt megoldottuk, a masteren még be is mutattuk az órán is, hogy működik ez a 2 soros fix, azonban a TeamB3 - Rebased mozgás #157 mergelése óta semmit nem érnek a mi fixeink, minden szét van esve és valamiért mi ezen nem is tudunk változtatni. Erre @ravaszla is írt nekik kommentet, hogy náluk van a probléma, de ahogy látjuk megoldás nem született még.

[pintergreg]

@Horti94 Ebben nem voltam up-to-date, elnézést. Megpróbálhattok futni egy debug kört hátha meglelitek a hiba okát. Én ma ebben a kérdésben többet nem tudok mondani.

ping @SzFMV2018-Osz/team-b3

[dezsi96]

@Horti94 Ezt a B4-es csapat csinálta

ping @SzFMV2018-Osz/team-b4

[Horti94]

akkor bocsi, valamit félre néztem, hogy kié a branch! :)

[ravaszla]

A pálya masteren szétesik, a develop branchen normálisan néz ki. Az ütközésdetekcióhoz szükséges információ nem jutott el a csapathoz, így demonstrálható ütközés nincs.

[Horti94]

Szeretnénk megkérdezni, hogy mi mit tehetünk, hogy az ütközés tesztelhető legyen? Sajnos hiába beszéltünk az érintett csapatokkal írásban és személyesen, nem történt előrehaladás. A számunkra szükséges mezők bevezetéséről a B1 gondoskodott, viszont a megfelelő információk eléréséhez az ő munkájuk sajnos nem elég. Valamint a szétesés is többször lett jelezve a B4 felé, hogy arra kérnénk fixet (Te is írtad nekik, és mi is) mégsem történt változás. Hogyan tudnánk abban segíteni, hogy ez mégis megtörténjen?

[bex1111]

Sziasztok!

Szerintem a @SzFMV2018-Osz/team-b4 a legkevésbbé sem fellelős a megjelenítésért. Mi csak beköttötük a dolgokat a masterren lévő kódba és ennyi. De ha már bele keveredtünk segítünk szívesen. Bár hangsúlyozom mi csak felül írjuk a koordinátákat kb., meg kirakunk egy két dolgot a buszra. Mi nem ismerjük a megjelenítő csapat kódját azt nekik kéne kitúrni miért esik szét. És ha megmondják, hogy valamit mi írunk át ami nem szabadna természetesen kijavítjuk.

[pintergreg]

Az a helyzet, hogy a @SzFMV2018-Osz/team-b1 branch-e (TeamB1) hibátlan. A @SzFMV2018-Osz/team-b2 -é (TeamB2) valami kőkori verzióban van, semmilyen pályarajzolás nincs rajta. A TeamB2-Develop megint csak szét van esve. És nem az a gond, hogy Laci szinkronizált, mert revertálás után is szét volt még esve (ez nem lett push-olva ha jól tudom).

Valójában fölösleges egymásra mutogatni szerintem, mert majdnem mindegy már ki volt. Szerintem lassan nagyobb meló kideríteni, hogy melyik commitnál ment el mint megoldani. A B1-ből kell nyitni a masterbe egy PR-t, de úgy, hogy az ütközésfeloldást a B1 és minimum a B2 közösen alkotja meg, mivel a B2 felelt eredetileg a rajzolásért.

Sőt, nem is kell nyitni, mert a #197 már létezik. 6 fájlban van ütközés. A Main.java meglehetősen egyszerűnek tűnik. A Utils.java sem tűnik bonyolultnak, mindent meg kéne tartani IMHO. A CourseDisplay esetében viszont már nem merek dönteni a verziók között. Debuggoljátok ki melyik jó (hint a B1-nél működik, de akkor is valaki nézze át, preferáltan a B2-ből). Dashboard triviális. A WorldObjectet a B1 tudja eldönteni, az AutomatedCar-ról megint ötletem sincs.

[pintergreg]

Kiegészítés: az AutomatedCar esetében lehet konzultálni kell a B4-el, mivel az autót ők mozgatják. Mármint az ütközés feloldás végett.

[porkolabgergo]

Ha valamikor mostanában össze tudunk hozni egy közös ütközés feloldást, én b1 részéről szívesen segítek bármiben, szóljatok.. Átnézem a #197-es PR-t és amit tudok azt megpróbálok megoldani.

[porkolabgergo]

Megnéztem, a CourseDisplay.java és a Dashboard.java classokat valaki nézze át, a másik 4 osztályba csak ilyen sorbeszúrásos szerencsétlenkedést dob ki ütközésnek, ami 1 perc alatt orvosolható. @pintergreg ha rámentem https://github.com/SzFMV2018-Osz/AutomatedCar-B/pull/197/conflicts erre, akkor itt tudom úgy módosítani, hogy el is mentse valahogy? Elvileg kijavítottam az első 4 osztályban lévő conflictokat, de nem igazán tudtam elmenteni.

[Horti94]

Sajnos ez a revert nem igazán jött össze úgy, ahogy meg lett beszélve! Mint említettük a B4 Sprint1-es kódjával volt a baj, nem a Sprint2-essel (mindenesetre arra ment a revert az biztos), innentől kezdve persze hogy szétesik a megjelenítés továbbra is, ebben nincs semmi meglepő! Mi nem lett pusholva egyébként?

Korábbi kommentben jeleztünk, ez a sprint alatt, hogy pontosan melyik pull request után romlott el a master, mely után nem tudtuk javítani már a hibát semmi módon és ti is pingeltetek oda, hogy javítsa ki ezt az adott csapat! Ez nem ujjal mutogatás, hanem egy egyszerű kérés, melyre nem jött egészen máig válasz.

Amennyiben nem probléma, hogy belenyúlunk más feladatába, akkor természetesen megpróbáljuk javítani a hibákat, eddig azért nem tettük ezt, az első ilyen alkalommal azt mondtátok, hogy azt a conflictok miatt ezt nem tehetjük meg és töröljük.

Mi soha nem mondtuk egy szóval sem hogy a B1 branch-ében lenne bármi hiba is, sőt mi írtuk is, hogy ők segítségünkre voltak és mindent meg is kaptunk tőlük, amit kértünk.

B1 kapott tőlünk egy működő verziót a vizualizációból, hogy ők is tudjanak dolgozni, így az megvolt egészen eddig. A közös munka már folyamatban van több hete.

[Horti94]

@SzFMV2018-Osz/team-b4 Valóban nem nyúltatok bele a vizualizációba ezt elismerjük, de a WorldObject-et valamiért átírtátok... A rotation értéke alapvetően radiánban van, viszont ha kifejtitek, hogy ezt miért kellett így megvalósítani, akkor természetesen alkalmazkodunk hozzátok és igyekszünk átalakítani a teljes vizualizációt. Commit hash: a2812ca1

[pintergreg]

@porkolabgergo Nem fogja engedni szerintem, mert protected a branch. Vagy megmondod tételesen, hogy mit kell megtartani (nem épp elegáns) és megcsinálom én, vagy megcsinálod lokálisan (persze ez még mindig nem lesz elég, mert nem tudod majd pusholni, csak ha egy külön branchre teszed ami megint körülményes). Ezért most átmenetileg levettem a TeamB1-ről a védelmet.

@Horti94 Én úgy tudom Laci próbált lokálisan egy revertet, kipróbálta, nem működött továbbra sem és nem pusholta.

Köszi, hogy megkerested a hiba okát, a vizualizációt nem kell átalakítani, ha a @SzFMV2018-Osz/team-b4 -nek kell a módosított érték, akkor felvesznek rá úgy új metódust getRadianRotation névvel vagy valami. Ez tipikusan az amit a PR templateben „breaking changes”-nek hívok...

A PR üzenet tételes kitöltésének az volna a célja, hogy egyértelműen látszódjon, hogy mit fog eredményezni az elfogadása. Persze ez is akkor működik igazán ha az issue-k kellően ki vannak fejtve és a teljes fejlesztés részletesen dokumentált. Tudom, hogy ez abban a formában, ahogy pl. a templateben várom egy ideális világot feltételez, de a célja az volna, hogy az igény kialakuljon arra, hogy a munka követve legyen. Egyébként egyre több az olyan PR, amelyben van felsorolás a változásokról, szóval talán alakul. :smile:

Mindez azért tud nagyon szép lenni, mert sokszor az ember nem is gondol bele, hogy egy módosítás hol eredményezhet törést. Koncepcionálisan erre lennének jók a unit tesztek, csak az ilyen grafika pont nem az a terület amit egykönnyen unit tesztelni lehet. Az ilyen szemre látszik, hogy mi van tipikusan rosszul tesztelhető, bár ha a getRotation-ra lenne teszt, akkor kibukott volna. Csak ekkor meg az merül fel, hogy egy hülye getter-re minek írjon az ember unit tesztet, amikor semmi egyebet nem tesz mint visszaadja az adott értéket... (feltéve, hogy tényleg nem tesz semmi egyebet. :stuck_out_tongue:)

Ez az egész helyzet esettanulmánynak jó, amiből lehet tanulni.