[CICLO 15] Storia 2

[fek]

Originariamente inviato da thebol

mmm

percui generiamo anche gli eventi tipo Crush(possono essere a catena) nel log?

Direi di si'. Come dice cionci, tu serializzi l'output della macchina a stati, non il suo input. E la cosa e' comodissima. Immagina di avere un bug al turno 200, tu fai il playback fino al turno 199, poi lanci la macchina a stati con gl'input giusti e vedi come si comporta. Se si comporta "male", scrivi le assert che lo verificano e poi fai passare il test correggendo la macchina a stati. Ma nota che anche dopo le modifiche della macchina a stati, il log riproduce sempre e comunque la stessa configurazione perche' lo hai disaccoppiato dalla macchina a stati stessa.

Fare questo e' esattamente il requisito del task, e' il motivo per il quale abbiamo quel task.

[Jocchan]

Originariamente inviato da fek

Appena Joc lo conferma, questo diventa un bug e va risolto. Approposito, dobbiamo tenere aggiornato l'elenco dei bug e Joc deve produrre ogni tanto una storia per correggerli.

Questo sembra verificarsi indipendentemente da InputRate.
E' un bug perchè potrebbe crearci problemi con l'online.

[fek]

Originariamente inviato da Jocchan

Questo sembra verificarsi indipendentemente da InputRate.
E' un bug perchè potrebbe crearci problemi con l'online.

Ok, va aggiunto alla lista dei bug e corretto. Puoi valutare il fix di cionci?

[Jocchan]

Originariamente inviato da fek

Ok, va aggiunto alla lista dei bug e corretto. Puoi valutare il fix di cionci?

L'ho già fatto, e il bug resta. Basta fare più prove e si presenta comunque, dopo più o meno lo stesso numero di coppie create.

[cionci]

Originariamente inviato da Jocchan

L'ho già fatto, e il bug resta. Basta fare più prove e si presenta comunque, dopo più o meno lo stesso numero di coppie create.

Il fix non è diminuire InputRate... Sono due o tre righe di codice... Comunque hai un PVT...

[Jocchan]

Originariamente inviato da cionci

Il fix non è diminuire InputRate... Sono due o tre righe di codice... Comunque hai un PVT...

Errore mio. Provo stasera e vediamo

[thebol]

Originariamente inviato da fek

Direi di si'. Come dice cionci, tu serializzi l'output della macchina a stati, non il suo input. E la cosa e' comodissima. Immagina di avere un bug al turno 200, tu fai il playback fino al turno 199, poi lanci la macchina a stati con gl'input giusti e vedi come si comporta. Se si comporta "male", scrivi le assert che lo verificano e poi fai passare il test correggendo la macchina a stati. Ma nota che anche dopo le modifiche della macchina a stati, il log riproduce sempre e comunque la stessa configurazione perche' lo hai disaccoppiato dalla macchina a stati stessa.

Fare questo e' esattamente il requisito del task, e' il motivo per il quale abbiamo quel task.

ci ho messo un po a metabolizzarla, ma ora l'idea mi piace

ho solo un dubbio pero.

non rischiamo di avere un log troppo slegato dal timer?

in una situazione in cui o manca un evento o ne abbiamo uno di troppo, ma non sapremmo perche manca quell'evento(anche se questa è una cosa legata al debugging in realtime), se il problema fosse il timming non riusciremmo a saperlo.

Invece con un timer, da poter avanzare a piacimento(come si fa adesso nei test) si ricreerebbe l'esatta situazione di gioco normale)

[cionci]

Originariamente inviato da thebol

Invece con un timer, da poter avanzare a piacimento(come si fa adesso nei test, si ricreerebbe l'esatta situazione di gioco normale)

Ovviamente NON DEVE mancare un evento...

[Bonfo]

Ragazzi...questo log mi sta facendo impazzire.
Ho capito a cosa servirebbe....ma a me

Allora:
- il log deve fornire i dati che permettano di capire che è successo nel gioco.
- deve essere possibile ripetere le azioni senza il concetto di tempo, ovvero non bisogna aspettare 2 min per il test, ma con il concetto di ordine, quindi di poter andare in un punto qualunque del log.

A questo punto mi verrebbe da dire che il vero log è l'elenco delle posizioni, dei tipi e dei colori di tutti gli oggetti in grid...oltre all'insieme dei tasti premuti.
Questo permetterebbe di capire cosa fa l'utente e come le griglie rispondono.

Bene...per me questa idea è follia pura!!!!

Quindi mi chiedo...cosa mi sono perso per strada??

[thebol]

Originariamente inviato da cionci

Ovviamente NON DEVE mancare un evento...

è quello il bug

[cionci]

Originariamente inviato da Bonfo

A questo punto mi verrebbe da dire che il vero log è l'elenco delle posizioni, dei tipi e dei colori di tutti gli oggetti in grid...oltre all'insieme dei tasti premuti.
Questo permetterebbe di capire cosa fa l'utente e come le griglie rispondono.

Non proprio... Esce la gems pair X-Y.... La gems pair X-Y va a cadere alle coordinate (3, 4), (2, 4)...

Le varie GemsPair si sommano...accumulandosi sul fondo della griglia...

Avviene un crush che elimina le gemme (3, 4), (3, 5), (3, 6)...e così via...

[fek]

Originariamente inviato da Bonfo

Ragazzi...questo log mi sta facendo impazzire.
Ho capito a cosa servirebbe....ma a me

Allora:
- il log deve fornire i dati che permettano di capire che è successo nel gioco.
- deve essere possibile ripetere le azioni senza il concetto di tempo, ovvero non bisogna aspettare 2 min per il test, ma con il concetto di ordine, quindi di poter andare in un punto qualunque del log.

A questo punto mi verrebbe da dire che il vero log è l'elenco delle posizioni, dei tipi e dei colori di tutti gli oggetti in grid...oltre all'insieme dei tasti premuti.
Questo permetterebbe di capire cosa fa l'utente e come le griglie rispondono.

Bene...per me questa idea è follia pura!!!!

Quindi mi chiedo...cosa mi sono perso per strada??

Ok, implementa questo. Se funziona, il problema dov'e'?

Keep It Simple.

[Jocchan]

Cionci, l'exe che mi hai mandato non mi funzia.
Credo sia un problema di path, visto che un messaggio di errore di windows dice che non ho i diritti per accedere alla periferica specificata.

[Jocchan]

Finalmente sono riuscito a provare il fix di Cionci, e va che è una meraviglia.
Dopo diverse prove, ho l'impressione che il gioco renda al meglio con InputRate settato a 40.

[fek]

Allora possiamo proseguire con il refactoring di cionci.

[thebol]

ricapitolando sul playback del log...che se fa?

volendo proseguire con il loggare tutti gli eventi per poi riprodurli, direi che la prima cosa da fare è individuare tutti gli eventi e loggarli.


anche se dopo averci pensato oggi, quest'idea del riproddurre solo gli stati non mi convince, preferirei un playback legato al timer...

[fek]

Si', il primo passo e' individuare tutti gli eventi e loggarli. Il playback slegato dal timer e' un requisito del task, quindi va fatto cosi'.

[thebol]

ci sto lavorando su, e ho notato che il gemspair.update, era nell'update di gridcontroller. Per evitare di doverla loggare, l'ho spostata in gemsundercontrollState. Qua fallivano dei test, ma è bastato togliere un update in waitstateBeforenewgemspair quando ritorna gemsundercontrollState.

Solo che ora mi fallisce il famigerato testAllTexutresLoadBeforeStartPlaying!
mi restituisce 46 invece che 45


ps. mi pare di aver capito che è quel problema sull'ordine dei test eseguiti...
ho fatto revert per nulla

[Bonfo]

Questi update a "casaccio" negli State devono essere messi a posto

[thebol]

Originariamente inviato da Bonfo

Questi update a "casaccio" negli State devono essere messi a posto

avevo pensato a un sistema per risolvere un po la cosa...
mettere un metodo isUpdatable e setUpdatable.

nell'update di gridController ce un

while (state.isupdatable())
{
      state = state.update;
}
state.setUpdatable();

gli stati quando restituiscono uno stato settano se deve essere eseguito subito o no.

Centralizzi la chiamata della state.update, ma non so se sia vantaggioso farlo.