[CICLO 17] Storia 2

[Jocchan]

Storia: Fare in modo che, finchè il tasto per la dinamite rimane premuto, vengano mostrati a ciclo continuo i frame con lo zero e il display vuoto ogni 0.5 secondi, ed il gioco switchi ogni 1.5 secondi tra le due modalità di esplosione presenti (normale o a croce, come in figura), evidenziando in maniera coerente il contenuto delle caselle circostanti.
Ogni volta che avviene un’esplosione, ed ogni volta che viene aggiornato lo stato delle stone, verrà aggiornato anche lo stato dei display dei candelotti di dinamite presenti.
Infine, tenere premuto il tasto per la dinamite per oltre 5 secondi farà esplodere automaticamente il candelotto nella modalità normale. Questo evento sarà sottolineato da una velocità sempre maggiore dell’animazione, la cui durata dei frame sarà ridotta di 90 millisecondi ogni secondo che passa, con un valore minimo fissato a 50ms.
Tutti i valori numerici indicati nella storia devono essere modificabili in GameConfig.

http://lnx.rc6.it/diamonds/varie/schema_tnt.jpg

Punti cardine da tenere a mente durante i lavori:

* Mai fare a gara a chi finisce il task per primo, meglio procedere con calma, altrimenti perderemo molto più tempo in seguito
* Evitiamo di complicarci la vita, esiste di certo una soluzione più semplice di quella che abbiamo pensato di implementare
* MAI aggiungere elementi non richiesti esplicitamente dai task: se mai serviranno, se ne parlerà nelle prossime storie
* Comunichiamo il più possibile, se qualcosa nelle specifiche non è chiaro discutiamone tutti i dettagli fino ad eliminare ogni dubbio, anche il più insignificante
* Postare sempre la test list PRIMA di mettere mano al codice

[VICIUS]

Task:
17.2.1: ^TiGeRShArK^ + ??:
Aggiungere l'animazione del candelotto quando si preme il tasto per farla esplodere. I frame da riprodurre in ciclo continuo sono gli ultimi du, il 7 e il numero 8. Il delay tra un frame e l'altro deve essere controllabile da GameConfig e di default deve essere di 500 ms.

17.2.2: thebol: completato
Attivare la dinamite e il tasto per l'esplosione dei candelotti solo quando si seleziona nel menu l'Advanced Mode.

17.2.3:
Quando un candelotto viene cancellato il numero presente sopra a quelli ancora presenti nella griglia devono essere aggiornati e deve essere riabilitata l'estrazione dei candelotti.

17.2.x:
Una volta terminati i task della storia 1

ciao ;)

[jappilas]

Task: 17.2.x:
Una volta terminati i task della storia 1

meglio così, troppi task tutti insieme farebbero ripetere quanto successo con la 16.3 ;)

però ehm dettagli sulla storia 17.1 non ne ho ancora visti... :D

[fek]

Importante: quando un dettaglio del task non e' chiaro, domandate spiegazioni sul forum. La comunicazione e' fondamentale per risolvere i problemi che abbiamo avuto negl'ultimi cicli.

17.2.1 da fare in pair.

[Bonfo]

Vorrei chiedere una cosa.
Lavorando sul refactoring mi sono un po' perso i task delle altre storie, ma mi sembra che qui manchino alcuni task non completati nelle storie del ciclo 16. :confused:

[Jocchan]

Vorrei chiedere una cosa.
Lavorando sul refactoring mi sono un po' perso i task delle altre storie, ma mi sembra che qui manchino alcuni task non completati nelle storie del ciclo 16. :confused:

Quelli che vedi sono quelli del ciclo 16 :)
Ce ne sono altri due, ma per quelli meglio prima fare un pò di refactoring.

[^TiGeRShArK^]

ok..
io mi offrirei per il pair del task 1.
Un'altra domanda che mi è venuta in mente.....
ma la dynamite + vecchia è già memorizzata in qualche posto o bisogna scorrersi tutte le dynamite presenti sulla griglia per trovarla (nel caso in cui non sia nella gemspair che sta cadendo)?
EDIT: ci sono solo la sera x il pair.....

[jappilas]

ok..
io mi offrirei per il pair del task 1.
Un'altra domanda che mi è venuta in mente.....
ma la dynamite + vecchia è già memorizzata in qualche posto o bisogna scorrersi tutte le dynamite presenti sulla griglia per trovarla (nel caso in cui non sia nella gemspair che sta cadendo)?
EDIT: ci sono solo la sera x il pair.....
l' implementazione dovrebbe essere libera, però:
personalmente vedrei bene una piccola coda (size lockata a 3) di soli riferimenti a celle, che saranno le dinamiti in ordine di successione ed esplosione ;)
non è escluso una cosa del genere venga implementata direttamente durante un refactoring di dynamite (magari per il task 17,1,2 nel caso lo assumessio io... sto valutando )

[thebol]

l' implementazione dovrebbe essere libera, però:
personalmente vedrei bene una piccola coda (size lockata a 3) di soli riferimenti a celle, che saranno le dinamiti in ordine di successione ed esplosione ;)
non è escluso una cosa del genere venga implementata direttamente durante un refactoring di dynamite (magari per il task 17,1,2 nel caso lo assumessio io... sto valutando )

questo è una duplicazione, perche bisogna gestire questa lista in estrazione(nella gemQueue) e nella eliminazione.

però è dannatamente comoda, rispetto a scorrersi ogni volta tutta la griglia.

Fra l'altro un meccanismo simile si potrebbe fare per le flash, le stone, e i chest.

è un maledetto trade-off :|

[fek]

l' implementazione dovrebbe essere libera, però:
personalmente vedrei bene una piccola coda (size lockata a 3) di soli riferimenti a celle, che saranno le dinamiti in ordine di successione ed esplosione ;)
non è escluso una cosa del genere venga implementata direttamente durante un refactoring di dynamite (magari per il task 17,1,2 nel caso lo assumessio io... sto valutando )

No, keep it simple. Prima l'implementazione piu' banale e poi si rifattorizza.

[jappilas]

No, keep it simple. Prima l'implementazione piu' banale e poi si rifattorizza.
posso chiedere una cosa... c'è una volta che qualche mia idea di design sia considerata valida? :D

[fek]

posso chiedere una cosa... c'è una volta che qualche mia idea di design sia considerata valida? :D

Si', quelle semplici che escono dal codice :D

[^TiGeRShArK^]

ok..
io mi offrirei per il pair del task 1.
Un'altra domanda che mi è venuta in mente.....
ma la dynamite + vecchia è già memorizzata in qualche posto o bisogna scorrersi tutte le dynamite presenti sulla griglia per trovarla (nel caso in cui non sia nella gemspair che sta cadendo)?
EDIT: ci sono solo la sera x il pair.....
:fiufiu:
me lo devo fare da solo il pair? :p

[VICIUS]

:fiufiu:
me lo devo fare da solo il pair? :p
Su dai non fate i timidi. Non lasciate Tigershark da solo. :)
Jappilas tu che "adori" la dinamite non ti va di fare un pair?

ciao ;)

[Ufo13]

tiger intanto potresti cominciare con il refactoring delle Dynamite? :)

[jappilas]

Jappilas tu che "adori" la dinamite non ti va di fare un pair?

"adoro" e' una parola grossa :D
avevo una mezza idea di mettermi al lavoro una volta terminato il 17.1.1 e assestato il codice :stordita: :p
ok quando (ora sono @work in lab e non ho sottomano eclipse)?

[fek]

Chi si prende il 2 e il 3? Il 2 non ha dipendenze.

[thebol]

prendo il 2.

spero di finirlo entro domani sera, che poi parto per londra =)
(domani sono a casa, percui ho tempo)

[fek]

prendo il 2.

spero di finirlo entro domani sera, che poi parto per londra =)
(domani sono a casa, percui ho tempo)

Quanto resti a Londra? Mandami il tuo num di telefono in PM che questo fine settimana dovrei essere nella City, e magari beviamo una birra assieme :)

[Ufo13]

Quanto resti a Londra? Mandami il tuo num di telefono in PM che questo fine settimana dovrei essere nella City, e magari beviamo una birra assieme :)

Sempre con ste birre :D

[thebol]

Quanto resti a Londra? Mandami il tuo num di telefono in PM che questo fine settimana dovrei essere nella City, e magari beviamo una birra assieme :)

fino a domenica sera(con la morosa...ma se mi vieta di beccarti la fucilo :asd: )

[jappilas]

OT
Sempre con ste birre :D
e pensare che io devo limitarmi al caffe' + acqua gasata ;_;
/OT

[Elentari]

fino a domenica sera(con la morosa...ma se mi vieta di beccarti la fucilo :asd: )

L'altra morosa non sapeva neanche che fek ha in previsione di andare a londra nel fine settimana.. vedi un po' tu :rolleyes:

Io e la tua ragazza potremmo andarcene a fare un giro per negozi a sto punto :cool:

[fek]

Oki, scusate per l'OT :)

[^TiGeRShArK^]

tiger intanto potresti cominciare con il refactoring delle Dynamite? :)
ehm...
ke refactoring dovrei fare ke mi sfugge? :stordita:

[Ufo13]

- Consolidare le responsabilita' di Dynamite al momento sparse in piu' classi

La classe Dynamite secondo me necessita di un po' di refactoring per renderne più chiaro il funzionamento inoltre non trovo bello come è stata implementata all'interno di GemQueue...

[thebol]

ho forse trovato un comportamento non desiderato..

ora come ora in randomDroppableFactory, una sequenza dinamite, flash, dinamite è impossibile.

Questo perche alla prima estrazione verrebbe settato lastExtractionisDynamite = true.

Nelle seconda verrebbe settato lastExtractionisFlash = true, ma lastExtractionisDynamite non verrebbe modificato..percui alla terza estrazione una dinamite non verrebbe estratta.

Visto che sto lavorando su randomDroppableFactory, lascio intatto questo comportamento o rendo possibilte dyna-flash-dyna?

[Jocchan]

ho forse trovato un comportamento non desiderato..

ora come ora in randomDroppableFactory, una sequenza dinamite, flash, dinamite è impossibile.

Questo perche alla prima estrazione verrebbe settato lastExtractionisDynamite = true.

Nelle seconda verrebbe settato lastExtractionisFlash = true, ma lastExtractionisDynamite non verrebbe modificato..percui alla terza estrazione una dinamite non verrebbe estratta.

Visto che sto lavorando su randomDroppableFactory, lascio intatto questo comportamento o rendo possibilte dyna-flash-dyna?

Direi di rimuoverlo. Aiuta a ridurre l'occorrenza della dinamite (che effettivamente va ridotta), ma non lo fa in maniera diretta ed intellegibile.

[thebol]

sono a buon punto :)
ho esteso randomDroppableFactory, in modo che la classe base non gestisca le dinamiti mentre la classe figlia si.

Poi ho aggiunto un metodo create e un metodo createAdvance in gemQueue, che creano appunto la codo usando o la randomDroppableFactory oppure la advancedRandomDroppableFactory, e ho fatto una cosa simile in gridController.

Ho duplicato i test du randomDroppableFactory e gemQueue, in modo da testare entrambe le versioni.

ora ho il problema che non so come testare in gameLoop il fatto che gridController sia advanced o no...

...

aggiunto l'abilitazio del tasto per la dinamite e testata, ma non ho ancora trovato il modo di testare il non inserimento/inserimento di dinamiti in gameLoop...

[thebol]

ho fatto, solo che sembra che svn sia giu :|
e io parto fra mezz'ora :|


ps.
fatto =D
non avevo condiviso la connesione a pagamento percui il portatile non vedeva internet..

[^TiGeRShArK^]

La classe Dynamite secondo me necessita di un po' di refactoring per renderne più chiaro il funzionamento inoltre non trovo bello come è stata implementata all'interno di GemQueue...
ok...
ora do un okkiata al codice e domani vedo di farlo :p
ma x il pair non si offre nessuno ??? :cry:
non mangio nessuno io! :cry:

[jappilas]

ok...
ora do un okkiata al codice e domani vedo di farlo :p
ma x il pair non si offre nessuno ??? :cry:
non mangio nessuno io! :cry:
io sarei disposto.... :stordita:
la sera fino a mezzanotte di solito (subito dopo da me scatta il coprifuoco informatico :D :p )
... però non ti arrabbiare se ci sto un po' a trovare il punto dove modificare il codice e concepire il codice più semplice :fagiano:

[fek]

Siamo a venerdi' e mancano da assegnare i task 2) e 3). Fatevi sotto per favore. Stiamo veramente procedendo a rilento ora.

[^TiGeRShArK^]

stasera io e jappilas dovremmo fare il pair...sperando di finire prima del coprifuoco informatico :D

[jappilas]

devo andare a fare spesa, finiamo appena torno ... :stordita:
edit: available and ready (fino all' ora di pranzo) :)

[VICIUS]

Il task 1 è quasi finito giusto?
Su forsa che il 3 non dovrebbe essere difficile. Chi se lo vuole prendere cosi passiamo anche agli altri.

ciao ;)

[jappilas]

Il task 1 è quasi finito giusto?
Su forsa che il 3 non dovrebbe essere difficile. Chi se lo vuole prendere cosi passiamo anche agli altri.

ciao ;)
dopo 5 secondi la dinamite smette di lampeggiare e resta in attesa del rilascio del tasto , ma se l' esplosione automatica allo scadere del timeout è yagni per il task 1, allora è quasi finito ;)

[VICIUS]

dopo 5 secondi la dinamite smette di lampeggiare e resta in attesa del rilascio del tasto , ma se l' esplosione automatica allo scadere del timeout è yagni per il task 1, allora è quasi finito ;)
Questo pomeriggio ne ho parlato con Jocchan e abbiamo deciso che per ora non serve. Fa parte di uno dei prossimi task quindi anche questo è finito. Volete smazzarvi anche il terzo?

ciao ;)

[jappilas]

Secondo me il terzo task è a sua volta composto di svariati sottotask, per adesso prendo in considerazione l' update dei numeri delle dynamites residue
Test aggiunto al testBlowDynamiteAction
public void testDynamiteFramesUpdatedAfterBlowAction()
{
Dynamite olderDynamite = createDynamite();
olderDynamite.getAnimatedObject().createAnimationSequence(0);
olderDynamite.getAnimatedObject().setCurrentFrame(2);

Dynamite newerDynamite = createDynamite();
newerDynamite.getAnimatedObject().createAnimationSequence(0);
newerDynamite.getAnimatedObject().setCurrentFrame(1);

insertAndUpdate(olderDynamite, 13, 2);
insertAndUpdate(newerDynamite, 13, 1);

grid.forEachDroppable(blowDynamiteAction);

assertEquals("The newer Dynamite is showing the wrong frame", 2, newerDynamite.getAnimatedObject().getCurrentFrame());
}
Codice aggiunto alla BlowDynamiteAction in luogo di un singolo if
int frame = gem.getAnimatedObject().getCurrentFrame();

if (frame == 0)
{
gem.getAnimatedObject().setCurrentFrame(1);
return;
}
if (frame == 1)
{
gem.getAnimatedObject().setCurrentFrame(2);
return;
}
Questa stesura del test e del codice passa
Però ehm, giocando, noto un problema grosso: dopo un' esplosione i numeri vengono aggiornati ma la prossima dinamite che arriva con una successiva gempair (quindi la riattivazione della estrazione in realtà è già stata implementata? :stordita: ) ha il numero che avrebbe avuto se l' esplosione non fosse avvenuta, che è 1 nel caso sia la quarta dall' inizio della partita
il che ha il particolare effetto collaterale di cancellare due dinamiti alla successiva esecuzione di BlowDynamiteAction...
ora, mi servirebbe un metodo e un test per testare e modificare il frame anche delle dynamites nella gemqueue...

in alternativa posso iniziare il cosiddetto refactoring ab initio delle dynamites, ADESSO... :D

[VICIUS]

in alternativa posso iniziare il cosiddetto refactoring ab initio delle dynamites, ADESSO... :D
Il refactoring di Dynamite è una task della storia 1 (l'ultimo rimasto). Una volta finito questo potete andare nel thread apposta e prenotarvi ma ora concentratevi su questo task e non pensate al refactoring.

ciao ;)

[^TiGeRShArK^]

io potrei dare una mano a jappilas x il refactoring domani sera xkè sono appena tornato e ora sto uscendo di nuovo :p

[jappilas]

stavo pensando ... la soluzione in apparenza più semplice al momento dovrebbe essere aggiungere a gemqueue una funzione del genere
public void updateDynamitesInQueue()
{
DynamiteCountAction action = new DynamiteCountAction();
grid.forEachDroppable(action);
int numDynamites = action.getNumOfDynamite();

for(Droppable droppable : queue)
{
if (droppable.getGridObject().getType().isDynamite())
{
droppable.getAnimatedObject().setCurrentFrame(2 - (numDynamites % 3));
numDynamites++;
}
}
}per poi chiamarlla da gridcontroller subito dopo la blowDynamiteAction
però ehm, dal momento che gemqueue è una sottoclasse di DroppableGenerator e il gridController passa (giustamente) per l' interfaccia , come si può fare ad accedervi? :fagiano:

[VICIUS]

[...]blowDynamiteAction
però ehm, dal momento che gemqueue è una sottoclasse di DroppableGenerator e il gridController passa (giustamente) per l' interfaccia , come si può fare ad accedervi? :fagiano:
Non puoi aggiungere la funzione come prima cosa della extract?

ciao ;)

[thebol]

Non puoi aggiungere la funzione come prima cosa della extract?

ciao ;)

in teoria si, però non verrebbe aggioranta subito la texture nel nextGemBox(in griglia ci arriverebbe col numero giusto)

[VICIUS]

in teoria si, però non verrebbe aggioranta subito la texture nel nextGemBox(in griglia ci arriverebbe col numero giusto)
Mettendo quella funzione anche in getGemAt() sembra filare tutto liscio. Ammetto pero di non aver fatto partire i test :)
Oltretutto non è necessario aggiornare tutte le volte. In entrambe le funzioni basta controllare se il droppable da ritornare è una dinamite.

ciao ;)

[71104]

[...] Codice aggiunto alla BlowDynamiteAction in luogo di un singolo if
int frame = gem.getAnimatedObject().getCurrentFrame();

if (frame == 0)
{
gem.getAnimatedObject().setCurrentFrame(1);
return;
}
if (frame == 1)
{
gem.getAnimatedObject().setCurrentFrame(2);
return;
}
Questa stesura del test e del codice passa
solo una cosa jappi: KISS, e tu non lo stai facendo :D
il tuo codice si riduce tranquillamente così:

int frame = gem.getAnimatedObject().getCurrentFrame();

if (frame < 2)
{
gem.getAnimatedObject().setCurrentFrame(frame + 1);
return;
}

[jappilas]

solo una cosa jappi: KISS, e tu non lo stai facendo :D
il tuo codice si riduce tranquillamente così:

int frame = gem.getAnimatedObject().getCurrentFrame();

if (frame < 2)
{
gem.getAnimatedObject().setCurrentFrame(frame + 1);
return;
}

hai ragione, ma tieni conto che
- quel codice era provvisorio ;)
- se per un puro caso qualcuno spostasse la corrispondenza "indice frame - numeri" da "inversa" (0 - "3", 1 - "2", 2 - "1", 3 - "0" ecc ) com' è ora a "diretta" ( indice 0 - "0" sul display ecc) , setCurrentFrame(frame + 1) non funzionerebbe - bisognerebbe o cambiare gli indici numerici statici o pensarci su un secondo per poi capire di dover usare una sottrazione :D

[71104]

scusa ma vorrebbe dire che devono cambiare le textures... secondo me puoi anche dare per scontato che il materiale fornito da Jocchan non cambi mai a meno che lui stesso non specifichi che si tratta di roba temporanea; non possono essere queste piccolezze ad influenzare le tue scelte di design :D

[71104]

per il task 3 ho analizzato la situazione e urge un refactoring, anzi proprio un'aggiunta: attualmente per eseguire una action sulla dinamite le varie action definite eseguono un cast (nausa...): il metodo di una action riceve come parametro un'istanza di Droppable, e le actions della dinamite lo castano a Dynamite solo se getType().isDynamite() ritorna true... NIENTE DI PIU' SCHIFOSO!!! :D :D :D
non solo usa getType ma usa pure un cast... gli inventori del Java si saranno scavati apposta la tomba per rivoltarcisi dentro :D

d'accordo soluzioni semplici, ma l'eleganza di design viene prima di tutto; questo non è design, i cast sono hack! ora riflettiamo, come si può fare per eseguire un metodo presente solo in Dynamite e assente in Droppable, posto che non è elegante metterlo anche in Droppable e darne un'implementazione vuota per tutte le classi derivate? c'è poco da fare, GridController deve tenere una array degli oggetti Dynamite inseriti finora; l'array chiaramente sarebbe di tre locazioni, e la cosa forse eliminerebbe l'attuale contatore che limita i candelotti.

siete d'accordo con questo refactoring, ovvero usare nel GridController un array di 3 Dynamite?

ha a che fare col task 3 perché per il task 3 la prima cosa che mi era venuta in mente era aggiungere una action che aggiornasse i numeri, e così sono andato a vedere come funzionavano le altre actions che agiscono sulla dinamite...

[jappilas]

scusa ma vorrebbe dire che devono cambiare le textures... secondo me puoi anche dare per scontato che il materiale fornito da Jocchan non cambi mai a meno che lui stesso non specifichi che si tratta di roba temporanea; non possono essere queste piccolezze ad influenzare le tue scelte di design :D
no, semplicemente , come anche ufo mi diceva, ritenevo che chiamare createAnimationSequence () non fosse il modo più pulito per inizializzare il set di frame del candelotto
in un eventuale refactoring l' avrei sotituita con 5 addFrame in un ordine più logico (partendo dal frame con lo 0) ;)
ma se non è "affar mio" lascio tutto come sta;)

[jappilas]

per il task 3 ho analizzato la situazione e urge un refactoring, anzi proprio un'aggiunta: attualmente per eseguire una action sulla dinamite le varie action definite eseguono un cast (nausa...): il metodo di una action riceve come parametro un'istanza di Droppable, e le actions della dinamite lo castano a Dynamite solo se getType().isDynamite() ritorna true... NIENTE DI PIU' SCHIFOSO!!! :D :D :D
non solo usa getType ma usa pure un cast... gli inventori del Java si saranno scavati apposta la tomba per rivoltarcisi dentro :D
io ho usato la action e il cast solo perchè nel resto del codice era già usato questo metodo, ma non è che piacesse nemmeno a me se ti ricordi... :stordita:

d'accordo soluzioni semplici, ma l'eleganza di design viene prima di tutto; questo non è design, i cast sono hack! ora riflettiamo, come si può fare per eseguire un metodo presente solo in Dynamite e assente in Droppable, posto che non è elegante metterlo anche in Droppable e darne un'implementazione vuota per tutte le classi derivate? c'è poco da fare, GridController deve tenere una array degli oggetti Dynamite inseriti finora; l'array chiaramente sarebbe di tre locazioni, e la cosa forse eliminerebbe l'attuale contatore che limita i candelotti.

siete d'accordo con questo refactoring, ovvero usare nel GridController un array di 3 Dynamite?

secondo te cos'è che vado dicendo da un mese? :D
ma più che un array ad accesso diretto una coda di 3 elementi -> quindi anche sequenziazione "quasi gratis" :D

[71104]

:wtf:

jappi, ti sto riscoprendo :D

dovrei ascoltarti meglio quando cerchi di dirmi qualcosa su MSN e io cambio sempre discorso virando sulle gnocche :D :D :D

vada per la coda allora, giustissimamente; gli altri che ne pensano?

[Ufo13]

ha a che fare col task 3 perché per il task 3 la prima cosa che mi era venuta in mente era aggiungere una action che aggiornasse i numeri, e così sono andato a vedere come funzionavano le altre actions che agiscono sulla dinamite...


Sì direi che è da fare :)

[Jocchan]

- se per un puro caso qualcuno spostasse la corrispondenza "indice frame - numeri" da "inversa" (0 - "3", 1 - "2", 2 - "1", 3 - "0" ecc ) com' è ora a "diretta" ( indice 0 - "0" sul display ecc) , setCurrentFrame(frame + 1) non funzionerebbe

Totalmente YAGNI :D
Non dobbiamo pensare al codice con l'idea che qualcuno potrebbe alzarsi un giorno e rivoluzionare tutto, o non finiremo mai ;)

[jappilas]

Totalmente YAGNI :D
Non dobbiamo pensare al codice con l'idea che qualcuno potrebbe alzarsi un giorno e rivoluzionare tutto, o non finiremo mai ;)
hai ragione
ma sai cosa? io ho fatto molta confusione per molto tempo mentre scrivevo codice per settare i frame o ricontrollavo test che asserivano il valore del frame corrente, perchè la numerazione "inversa" da 3 a blank non mi appariva per nulla intuitiva ed era anzi la prima cosa che pensavo di modificare in un eventuale refactoring a vantaggio della leggibilità del codice e con l' intenzione di evitare a chi subentrasse nel progetto ora (*), la fatica che ho dovuto fare io

(*) OT: forse riesco a convincere nuova forza lavoro a partecipare... se vedete aggirarsi per il forum un certo zak... :D

[71104]

test list 17.2.3

test per testare il comportamento di BlowDynamiteAction subito dopo un'esplosione:


- testare che BlowDynamiteAction non cambi i frames dei candelotti se non è avvenuta l'esplosione
- testare che BlowDynamiteAction aggiorni i frames ad esplosione avvenuta:
- testare il corretto cambiamento dei frames dopo che è esplosa la prima di 3 dinamiti
- testare il corretto cambiamento dei frames dopo che è esplosa la seconda


EDIT: ehm, scusate ma il task è già fatto... :|

ma perché non era prenotato...? :|

[thebol]

test list 17.2.3

test per testare il comportamento di BlowDynamiteAction subito dopo un'esplosione:


- testare che BlowDynamiteAction non cambi i frames dei candelotti se non è avvenuta l'esplosione
- testare che BlowDynamiteAction aggiorni i frames ad esplosione avvenuta:
- testare il corretto cambiamento dei frames dopo che è esplosa la prima di 3 dinamiti
- testare il corretto cambiamento dei frames dopo che è esplosa la seconda


EDIT: ehm, scusate ma il task è già fatto... :|

ma perché non era prenotato...? :|

e la stessa cosa che stavo pensando anche io...infatti oggi l'avevo gia visto funzionante


btw, il codice incriminato e quello di japillas modificato da te :asd:

[71104]

embe' ammecojoni, e ora io che faccio che avevo promesso che avrei fatto un task e invece non ce ne sono :|

:cry:

[thebol]

embe' ammecojoni, e ora io che faccio che avevo promesso che avrei fatto un task e invece non ce ne sono :|

:cry:

l'hai gia fatto implicitamente :asd:


ps.cmq ce ancora un bug(o tiger non l'ha ancora implementato, non zo), sull'esplosione della gemma.

Premendo il tasto per l'esplosione, la dinamite lampeggia correttamente, ma passato il timeOut non esplode, ma si blocca soltanto aspettando il rilascio.

[^TiGeRShArK^]

l'hai gia fatto implicitamente :asd:


ps.cmq ce ancora un bug(o tiger non l'ha ancora implementato, non zo), sull'esplosione della gemma.

Premendo il tasto per l'esplosione, la dinamite lampeggia correttamente, ma passato il timeOut non esplode, ma si blocca soltanto aspettando il rilascio.
visto ora...:sob:
vedo se riesco a metterlo a posto domani... :cry:

:muro::muro::muro::muro::muro::muro:

[Jocchan]

Ho trovato un piccolo bug di visualizzazione, che probabilmente verrà risolto con i refactoring di questi giorni.
Quando si tiene premuto il tasto dell'esplosione, e viene mostrata l'animazione che alterna lo zero ed il frame vuoto nel candelotto, se nel frattempo viene droppata una gemma per un istante si vede il frame con l'1.
Nulla di trascendentale, ma è bene esserne a conoscenza (così come il fatto che, dopo la cancellazione della dinamite, le gemme cadono per riempire la casella vuota solo nel turno successivo) ;)

Per il resto, la dinamite inizia a rendere davvero bene l'idea :)

[^TiGeRShArK^]

Ho trovato un piccolo bug di visualizzazione, che probabilmente verrà risolto con i refactoring di questi giorni.
Quando si tiene premuto il tasto dell'esplosione, e viene mostrata l'animazione che alterna lo zero ed il frame vuoto nel candelotto, se nel frattempo viene droppata una gemma per un istante si vede il frame con l'1.
Nulla di trascendentale, ma è bene esserne a conoscenza (così come il fatto che, dopo la cancellazione della dinamite, le gemme cadono per riempire la casella vuota solo nel turno successivo) ;)

Per il resto, la dinamite inizia a rendere davvero bene l'idea :)
infatti era quello il bug ke avevo visto ieri sera.. :fiufiu:
in effetti non sono sicuro se dipende dal task o dal refactoring.. :mbe:
quando torno stasera vedo se riesco a capirci qualkosa :p

[thebol]

Ho trovato un piccolo bug di visualizzazione, che probabilmente verrà risolto con i refactoring di questi giorni.
Quando si tiene premuto il tasto dell'esplosione, e viene mostrata l'animazione che alterna lo zero ed il frame vuoto nel candelotto, se nel frattempo viene droppata una gemma per un istante si vede il frame con l'1.
Nulla di trascendentale, ma è bene esserne a conoscenza (così come il fatto che, dopo la cancellazione della dinamite, le gemme cadono per riempire la casella vuota solo nel turno successivo) ;)

Per il resto, la dinamite inizia a rendere davvero bene l'idea :)

per il fatto che cadono nel turno successivo ci sto lavorando io con l'altro refactoring

[^TiGeRShArK^]

kakkio non riesco a riprodurre il bug nei test...:sob:
qualcuno ha idea di dove sbaglio per simulare il drop del pair corrente.....
qua c'è la parte importante del codice ke ho scritto per il test:

controller.getGemsPair().getPivot().getFallingObject().drop();
controller.getGemsPair().getSlave().getFallingObject().drop();
while(grid.droppedGemCanMoveDown())
{
grid.updateFalls();
}
controller.update(environment.getTimer().getTime());
environment.getTimer().advance(dynamiteFrameUpdateRate + 1);
grid.updateDroppableAnimations(environment.getTimer().getTime());

assertEquals("Dynamite is not showing the correct frame in animation", 3, dynamite.getAnimatedObject().getCurrentFrame());

il test continua a passare scritto in questo modo... :muro:
ho provato anche a mettere controller.update tra il timer.advance e grid.updateDroppableAnimations o a inserire anche un altro gemsPair nel caso il bug si presentasse con la nuova inserzione e non con il droppaggio.....
cosa sto sbagliando che mi sfugge? :fagiano:

[^TiGeRShArK^]

'orka troia.....
vado a letto...
non sono riuscito a farlo fallire neanche muovendo la gemma nell'ultima riga direttamente con il metodo getCell.setRow() come suggerito da ufo e inserendo una nuova gemsPair...:muro:
il codice sul mio pc è attualmente così

public void testCorrectFrameAfterNextDrop()
{
Dynamite dynamite = (Dynamite)gemFactory.createDynamite();

dynamite.activate();

grid.insertDroppable(dynamite, 13, 2);

grid.updateDroppableAnimations(environment.getTimer().getTime());

environment.getTimer().advance(dynamiteFrameUpdateRate + 1);
grid.updateDroppableAnimations(environment.getTimer().getTime());

assertEquals("Dynamite is not showing the correct frame in animation", 3, dynamite.getAnimatedObject().getCurrentFrame());

environment.getTimer().advance(dynamiteFrameUpdateRate + 1);
grid.updateDroppableAnimations(environment.getTimer().getTime());

assertEquals("Dynamite is not showing the correct frame in animation", 4, dynamite.getAnimatedObject().getCurrentFrame());


controller.getGemsPair().getPivot().getCell().setColumn(1);
controller.getGemsPair().getPivot().getCell().setRow(13);
controller.getGemsPair().getSlave().getCell().setColumn(1);
controller.getGemsPair().getSlave().getCell().setRow(12);

environment.getTimer().advance(dynamiteFrameUpdateRate + 1);

while(controller.getGrid().getDroppableAt(13, 1).getMovingDownObject().canMoveDown(controller.getGrid()))
{
controller.update(environment.getTimer().getTime());
}

controller.insertNewGemsPair();

grid.updateDroppableAnimations(environment.getTimer().getTime());

assertEquals("Dynamite is not showing the correct frame in animation", 3, dynamite.getAnimatedObject().getCurrentFrame());
}

tra l'altro ho scoperto una cosa inquietante... :mbe:
Se dopo aver inserito il nuovo gemspair sposto una delle due gemme alla posizione 13, 1 non da alcun errore, eppure la gemma va a finire nella posizione occupata dall'altra gemma :mbe:
è normale che accada ciò? :fagiano:
e la prima gemma è sicuramente in quella posizione come testimoniano le stampe che ho inserito nel codice... :confused:
boh.... vado a dormire ke non capisco + una mazza ... :muro:

[^TiGeRShArK^]

posto l'ultima versione completa del test ke ho usato per cercare di far ripresentare il bug di cui sopra....e ke ovviamente ancora non funge....:muro:
se qualcuno ha qualche idea e vuole provare a risolvere il bug almeno non parte da zero.....
Io praticamente non avrò + tempo fino al 27 giugno neanke x respirare, anke se spero nelle prox settimane di risucire a fare almeno qualcosina x diamonds.

public void testCorrectFrameAfterNextDrop()
{
Dynamite dynamite = (Dynamite)gemFactory.createDynamite();

dynamite.activate();

grid.insertDroppable(dynamite, 13, 2);

grid.updateDroppableAnimations(environment.getTimer().getTime());

environment.getTimer().advance(dynamiteFrameUpdateRate + 1);
grid.updateDroppableAnimations(environment.getTimer().getTime());

assertEquals("Dynamite is not showing the correct frame in animation", 3, dynamite.getAnimatedObject().getCurrentFrame());

environment.getTimer().advance(dynamiteFrameUpdateRate + 1);
grid.updateDroppableAnimations(environment.getTimer().getTime());

assertEquals("Dynamite is not showing the correct frame in animation", 4, dynamite.getAnimatedObject().getCurrentFrame());


controller.getGemsPair().getPivot().getCell().setColumn(1);
controller.getGemsPair().getPivot().getCell().setRow(13);
controller.getGemsPair().getSlave().getCell().setColumn(1);
controller.getGemsPair().getSlave().getCell().setRow(12);

controller.getGemsPair().getPivot().getFallingObject().drop();
controller.getGemsPair().getSlave().getFallingObject().drop();

environment.getTimer().advance(dynamiteFrameUpdateRate + 1);

controller.update(environment.getTimer().getTime());


controller.insertNewGemsPair();

grid.updateDroppableAnimations(environment.getTimer().getTime());

assertEquals("Dynamite is not showing the correct frame in animation", 3, dynamite.getAnimatedObject().getCurrentFrame());
}

[fek]

Mi fate un aggiornamento dello stato dei task cosi' possiamo portarli nel prossimo Ciclo?

[thebol]

Mi fate un aggiornamento dello stato dei task cosi' possiamo portarli nel prossimo Ciclo?

a memoria mi sembra manchi solo l'esplosione della dinamite in caso scada il timeout della dinamite lampeggiante(quello di cui parlava tiger)