View Full Version : BUGLIST - Bughunters' Official Thread
Fino a domenica sera non ho tempo di mettere mano a DC. Per ora reverto il commit e mi tengo il file modificato in locale. Quando finisco il test poi lo rimetto sul server.
Perfetto :)
In mia opinione sarebbe da mockare i due playfield per evitare di andare a testare troppo in profondita`.
Tentando di rifattorizzare il GameOverState mi sono accorto di quanto confusionali e profondi siano i test (non parlo solo di GameOver)
Abbiamo un volontario!
In mia opinione sarebbe da mockare i due playfield per evitare di andare a testare troppo in profondita`.
Tentando di rifattorizzare il GameOverState mi sono accorto di quanto confusionali e profondi siano i test (non parlo solo di GameOver)
il problema di mockare, e che se un oggetto viene creato dentro a un altro, si fa fatica. A meno che di passare una factory di factory(che sa un po di cattedralismo), esporre dei setter (a la spring, Inversion of controll, Dependency injection o come lo volete chiamare) o un costruttore che accetta gli oggetti che altrimenti verrebbero creati all'interno(sempre a la spring)
Infatti non era propriamente un bug, ma una situazione "particolare" che gestiremo correttamente quando introdurremo i pareggi.
secondo me è giusto come funzionava prima allora.
playFieldOne.update(loopTimestamp);
playFieldTwo.update(loopTimestamp);
checkAndShowGameOverMessage(playFieldOne, playFieldTwo);
checkAndShowGameOverMessage(playFieldTwo, playFieldOne);
in questa situazione, in caso di pareggio, dovrebbero avere entrambi il gamaOver a video. Naturalmente da testare.
secondo me è giusto come funzionava prima allora.
playFieldOne.update(loopTimestamp);
playFieldTwo.update(loopTimestamp);
checkAndShowGameOverMessage(playFieldOne, playFieldTwo);
checkAndShowGameOverMessage(playFieldTwo, playFieldOne);
in questa situazione, in caso di pareggio, dovrebbero avere entrambi il gamaOver a video. Naturalmente da testare.
Beh, è una cosa un pò sottile in effetti.
Il punto è che al momento non esiste ancora un concetto di pareggio, quindi sarebbe tecnicamente un "bug".
Ma il pareggio lo aggiungeremo (anche se in maniera leggermente diversa), quindi per questo gli era stato assegnato il livello D: per ignorarlo al momento e poi trattarlo quando sarà il caso ;)
bug:
le morphingGem quando si tranformano in gemma, non sono droppate(hanno isFalling == true)
testo e committo il bugfix a breve
ps.anche le stone quando si trasformano in morphing, nn sono droppate, ma questo nn crea problemi perchè nel periodo in qui esistono, non viene fatta nessuna operazione(finche non vengono trasformate in gemma)
ps.anche le stone quando si trasformano in morphing, nn sono droppate, ma questo nn crea problemi perchè nel periodo in qui esistono, non viene fatta nessuna operazione(finche non vengono trasformate in gemma)
Ma se si cancellasse qualcosa sotto di loro resterebbero sospese?
Ma se si cancellasse qualcosa sotto di loro resterebbero sospese?
no, come nn succede per tutte le altre gemme.
isFalling dovrebbe essere true solo per le gemme della gemsPair
ps. ho modificato il bugfix
jappilas
27-03-2008, 13:53
piccolo bug visivo in game notato ora
l' effetto "flare" delle gemme ( quelle in griglia come delle gem pair ) è ripetuto continuamente senza delay, con un effetto "lampeggiante della polizia" (che se non compromette il gameplay, è alla lunga fastidioso)
piccolo bug visivo in game notato ora
l' effetto "flare" delle gemme ( quelle in griglia come delle gem pair ) è ripetuto continuamente senza delay, con un effetto "lampeggiante della polizia" (che se non compromette il gameplay, è alla lunga fastidioso)
si può fixare aumentando il GemAnimationUpdateRate da GameConfig
jappilas
27-03-2008, 21:32
si può fixare aumentando il GemAnimationUpdateRate da GameConfignon risolve, si distanzia solo l' aggiornamento dei frame degli sprite con un effetto ancora peggiore - la cosa strana è che è presente un valore GemAnimationDelay, settato a 3500, ma apparentemente non è usato
PS: come mai UpdateRate è stato modificato da 10 a 15 millisecondi?
11) B - Quando una flashing gem cancella un chest, le stone adiacenti NON devono essere cancellate. L'unico modo per cancellare una stone deve essere mediante una crush vicina causata da un chest.
???
Puoi spiegare meglio il bug?
PS: come mai UpdateRate è stato modificato da 10 a 15 millisecondi?
per rallentare il gioco(in particolare la gravità, che sotto 1 nn poteva andare)
ps. trovato il bug
public DroppableFactory(Environment environment)
{
setupDropSound(environment);
environment.getEngine();
this.environment = environment;
gemAnimationUpdateRate = environment.getConfig().getInteger("GemAnimationUpdateRate");
gemAnimationDelay = environment.getConfig().getInteger("GemAnimationUpdateRate");
}
come delay è stato settato l'updateRate
jappilas
27-03-2008, 21:48
ps. trovato il bug
come delay è stato settato l'updateRatebene :)
per rallentare il gioco(in particolare la gravità, che sotto 1 nn poteva andare)meno bene, mi pareva che alla fine si fosse trovata una soluzione più elegante al problema della gravità :|
la cosa strana è che è presente un valore GemAnimationDelay, settato a 3500, ma apparentemente non è usato
Prima veniva usato. Sarà stato qualche refactoring degli ultimi giorni.
GemAnimationUpdateRate è buono così com'è ;)
???
Puoi spiegare meglio il bug?
In pratica, se una flashing cancella un chest le eventuali stone adiacenti - a causa della cancellazione del chest - vengono anch'esse cancellate (come se fosse stato il chest a scatenare la cancellazione, mentre ne è solo una "vittima").
bug fixato e committato
Ottimo ;)
In pratica, se una flashing cancella un chest le eventuali stone adiacenti - a causa della cancellazione del chest - vengono anch'esse cancellate (come se fosse stato il chest a scatenare la cancellazione, mentre ne è solo una "vittima").
ora come ora una flash individua il colore da esaminare, e poi cancella tutte le droppable in griglia di quel coloro.
Deduco che il comportamento sia errato.
Il comportamento corretto l'ho capito così:
la flash trova il colore da cancellare.
cerco tutte le gem, bigGem, chest di quel colore.
cerco tutte le stone(del colore da cancellare) vicine a una gemma(e a una bigGem) trovate nel passo precedente
cancello le stone trovate
cancello le bigGem, gem, chest trovate
ok?
ora come ora una flash individua il colore da esaminare, e poi cancella tutte le droppable in griglia di quel coloro.
Deduco che il comportamento sia errato.
Il comportamento corretto l'ho capito così:
la flash trova il colore da cancellare.
cerco tutte le gem, bigGem, chest di quel colore.
cerco tutte le stone(del colore da cancellare) vicine a una gemma(e a una bigGem) trovate nel passo precedente
cancello le stone trovate
cancello le bigGem, gem, chest trovate
ok?
No no no, è proprio quello il bug... nessuna stone deve venire cancellata. Solo chest, gem e bigGem.
Ed è quello che più o meno avviene, se non fosse che quando viene cancellato un chest il gioco scazza e crede sia stato il chest ad avviare la cancellazione, e quindi cancella eventuali stone vicine (che invece devono restare tutte quante).
No no no, è proprio quello il bug... nessuna stone deve venire cancellata. Solo chest, gem e bigGem.
Ed è quello che più o meno avviene, se non fosse che quando viene cancellato un chest il gioco scazza e crede sia stato il chest ad avviare la cancellazione, e quindi cancella eventuali stone vicine (che invece devono restare tutte quante).
nn ho il tempo di guardare il codice, ma mi sembra che cancelli tutte le stone di quel colore, a prescindere di dove siano.
quando o tempo cambio il comportamento, facendo cancellare solo gem, biggem e chest.
Visto che era ancora libero ho fissato io, ora il bug 11 non si presenta più, questo il test relativo:
public void testStoneNotCrushingWithFlashingGem()
{
insertAndUpdate(createStone(DIAMOND), 13, 3);
insertAndUpdate(createGem(DIAMOND), 13, 4);
insertAndUpdate(createFlashingGem(), 13, 5);
grid.updateCrushes(scoreCalculator, null);
assertEquals("Stone must not crush", 1, grid.getNumberOfDroppables());
}
Per correggerlo ho fatto in questo modo: il metodo getColor() ora restituisce NO_COLOR per le Stone, e ho aggiunto un metodo getHiddenColor() che restituisce il colore "nascosto" della Stone.
In questo modo le Stone non vengono cancellate dalla Flashing Gem, che utilizza l'iterazione RemoveByColor.
Grazie al nuovo metodo ho poi potuto cancellare il metodo getColorSamplerForCrush() riscrivendo i metodi di ricerca del colore da cancellare dalla Flashing in termini, appunto, di colore e non di droppable.
Prenoto inoltre il bug 16, dovrei riuscire a risolverlo senza grossi problemi entro domani.
Riassumendo: BUG 11 FIXED, alla revisione 2925
ps: ho notato che esiste ancora un "isChest", in ChestDroppableType...
Si riesce ad avere una descrizione piu` dettagliata del bug 6?
jappilas
30-03-2008, 15:38
questi test passano tutti come conseguenza del refactoring della crush di Stone
public void testStoneCrushingWithChestOfDifferentColorOnTheRightCrushing()
{
insertAndUpdate(createStone(RUBY), 13, 3);
insertAndUpdate(createChest(DIAMOND), 13, 4);
insertAndUpdate(createGem(DIAMOND), 13, 5);
grid.updateCrushes(scoreCalculator, stoneCalculator);
assertEquals(0, grid.getNumberOfDroppables());
}
public void testStoneCrushingWithChestOfSameColorOnTheRightCrushing()
{
insertAndUpdate(createStone(DIAMOND), 13, 3);
insertAndUpdate(createChest(DIAMOND), 13, 4);
insertAndUpdate(createGem(DIAMOND), 13, 5);
grid.updateCrushes(scoreCalculator, stoneCalculator);
assertEquals(0, grid.getNumberOfDroppables());
}
public void testStoneCrushingWithChestOfDifferentColorOnTheLeftCrushing()
{
insertAndUpdate(createStone(RUBY), 13, 5);
insertAndUpdate(createChest(DIAMOND), 13, 4);
insertAndUpdate(createGem(DIAMOND), 13, 3);
grid.updateCrushes(scoreCalculator, stoneCalculator);
assertEquals(0, grid.getNumberOfDroppables());
}
public void testStoneCrushingWithChestOfSameColorOnTheLeftCrushing()
{
insertAndUpdate(createStone(DIAMOND), 13, 5);
insertAndUpdate(createChest(DIAMOND), 13, 4);
insertAndUpdate(createGem(DIAMOND), 13, 3);
grid.updateCrushes(scoreCalculator, stoneCalculator);
assertEquals(0, grid.getNumberOfDroppables());
}
quindi il bug 16 si può considerare FIXED ;)
Ottimo!
Il bug 6 l'aveva trovato Jappilas.
Si presenta ancora?
Mi si è presentato giusto ieri mentre mettevo mano all'altro, ma sinceramente non ho capito come si sia generato. Proverò a riprodurlo, ma non la vedo facile al momento...
Non potrebbe essere per le due diverse implementazioni di moveDown?
Il bug 6, unico superstite del gruppetto, si è presentato a BD:
BlueDragon scrive:
forse una flashinggem+chest, ma non ci giurerei
la prima volta non ero nemmeno sicuro che fosse dopo la flashing, ma magari una gempair dopo
al secondo giro invece sono sicuro che è capitato dopo l'effetto cancellazione della flashing
mi è capitato due volte nella stessa partita poco fa
Il che potrebbe restringere un pò il campo sulla causa del bug.
jappilas
25-05-2008, 18:08
poco fa ( dopo update alla build 2973) ho constatato che alla pressione delle frecce di sinistra / destra, la gempair in caduta effettua uno spostamento non orizzontale ma diagonale (a occhio inclinato di 45 gradi, il salto verticale sembra circa pari alla larghezza di una cella)
jappilas
25-05-2008, 19:56
avviando il gioco in Versus Mode, premendo una volta giù e poi invio, il gioco si blocca - viene eseguita la menu action netplay con annessa attesa sul socket
il che vuol dire che il menu continua a ricevere e gestire gli eventi da tastiera (selezionando le menu action ed eseguendole) anche dopo essere terminato ( in effetti nella AbstractKeyboard i listeners vengono solo aggiunti, non sostituiti :O)
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.