Closed flavio-a closed 3 years ago
Lo vorremmo fare davvero? Lo sai che poi l'utenza non è in grado di aggiornare autonomamente, vero?
Nel caso la risposta sia sì, mi piace l'idea del code generator. Un po' meno pratica sul lungo termine, ma se scriviamo il generator in lua (e sì, lo scriviamo in lua), ci vuole poco ad adattarlo a modulo.
1) USUM e LGPE li ho fatti io a partire dai dati presi dalle ROM. Questo semplificherebbe notevolmente quel lavoro 2) l'utenza può comunque segnalarlo nella pagina di discussione, per esempio (ci mettiamo un bel commento "se hai notato un errore non puoi correggerlo tu, ma puoi segnalarlo nella pagina di discussione"). Dubito che uno che ha avuto lo sbatti di provare a correggere si faccia fermare dal fatto che deve scrivere nella discussione.
Comunque la tua è una buona obiezione, sentiamo gli altri.
ma tanto nella maggior parte dei casi chi vede un errore non si mette a correggerlo anche se potesse e lo segnala sul forum/da altre parti, quindi secondo me non è un problema così grosso
Gli altri si sono espressi (su Telegram) e direi che il modulo si fa. Possiamo riprendere con le robe tecniche.
Ora spiegami cosa intendi per "adattarlo a modulo". Se facciamo calcolare la relazione inversa ad un modulo dinamicamente perdiamo l'utilità di generarlo staticamente (tanto sarebbe comunque eseguito una sola volta a pagina perché mw.loaddata)
Allora. Il code generator in lua è una roba tipo
learnlist = {}
for moveIndex, pokes in pairs(movelist) do
for poke in ipairs(pokes) do
table.insert(learnlist[poke], moveIndex)
end
end
print('learnlist = {}')
for poke, moves in pairs(learnlist) do
print(table.concat{'learnlist[', poke,
'] = {', mw.text.concat(moves, ', ', ''), '}')
end
Togliendo l'ultimo for hai il modulo dimanico
Quindi il code generator ti è piaciuto. Secondo me non possiamo metterlo come modulo per ragioni di efficienza ma possiamo provare. Alla peggio se esplode qualcosa lo cambiamo con la versione statica.
Non hai capito una mazza.
Il code generator lo usiamo per generare il modulo staticamente. Il code generator gira sulle nostre macchine. Se è troppo una palla generare il modulo staticamente, togliamo il for e hai il modulo generato dinamicamente.
@davla Avevo capito (era la mia proposta farlo statico), solo che quando hai proposto di farlo dinamico la mia obiezione è stata che rischia di essere troppo pesante. Quindi proponevo di provarlo (quello dinamico) per vedere le prestazioni perché se sorprendentemente fossero buone potremmo tenerlo. Tanto come hai osservato cambiare da uno all'altro è questione di commentare due righe.
Sono molto scettico sulle prestazioni, ma se la prova la smazzi tu a me va bene
Lavorando a questa issue ho riscontrato il seguente problema: ci sono alcune mosse apprese tramite accoppiamento che cambiano i genitori tra giochi della stessa generazione. Il motivo è che vengono introdotti nuovi tutor, ma il punto è che i genitori cambiano completamente. Esempio: Bodyguard per Geodude in sesta gen. Al momento questa cosa viene mostrata correttamente nelle pagine delle mosse (vedi link prima), ma nelle pagine dei Pokémon non viene cagata neanche di striscio (es). Una possibile soluzione è fare una roba stile learnlist per livello, in cui la prima colonna è doppia e si uniscono quando i genitori sono uguali in entrambi i giochi, ma volevo sentire la vostra.
PS: ma la cosa dei genitori non è un po' fuorviante? Cioè, mettendo queste liste mi viene il sospetto che la gente poi pensi che un Pokémon può imparare una certa mossa uovo solo da quei genitori lì. Forse andrebbe specificata un po' meglio questa cosa.
@flavio-a Perché? Non è così?
Ecco, fantastico. No, l'elenco di genitori è un aiuto a chi vuole fare breeding perché indica quei Pokémon a cui è "facile" far imparare la mossa che vuoi passare al nascituro. In realtà ogni Pokémon che conosce la mossa ad ha un gruppo uova in comune è un possibile genitore per trasmettere la mossa, come poi viene detto nella pagina delle mosse uovo (esempio scemo: i Pokémon della stessa specie, che non vengono mai elencati). Mettere l'elenco completo dei genitori secondo me è inutile perché a quel punto uno va a vedere nella pagina della mossa chi la impara e interseca con i gruppi uova, il nostro elenco è un lavoro molto più interessante perché invece capire se per esempio devi fare una catena di accoppiamenti per forza oppure sapere che c'è un Pokémon di cui ti eri dimenticato che ha lo stesso gruppo uova e la impara tramite Insegnamosse non è così ovvio da fare a mano.
Memo: prima di chiudere questa issue c'è da aggiornare https://wiki.pokemoncentral.it/Meta:Progetto_mosse_e_abilit%C3%A0/Mosse
Punto della sitauzione. Al momento i learnlist (pagine dei Pokémon) sono completamente automatici salvo per gli eventi e per LGPE, e mi sembra un risultato più che sufficiente. I movelist (pagine delle mosse) invece sono una nota più dolente. Dato che non ci sono i dati di LGPE non sono completamente automatici ma hanno bisogno di sapere appunto le cose di LGPE. Al momento la chiamata (si fa con il render) richiede di indicargli gli ndex dei Pokémon che imparano la mossa (e questi sono ancora da aggiornare a mano nelle pagine) ed eventualmente i dati di LGPE. Non è proprio il massimo, ma per ora abbiamo questo.
Nota a margine: elenco dei genitori. Come detto prima l'elenco dei genitori è un punto delicato. Serebii per esempio nella pagina principale dice solo che un Pokémon può imparare una mossa via breed, e poi ha una sottopagina in cui per ogni mossa ci sono i Pokémon compatibili divisi per metodo di apprendimento (livello, MT, breed, ...). Bulba invece ha scelto di non mettere nessun elenco nelle pagine delle mosse e lasciarlo solo nelle pagine dei Pokémon. Boh, discuss.
Scrivo anche qui: purtroppo il progetto è stato dichiarato fallito, almeno per ora. Tengo questa issue per ricordarmi che devo annullare tutto (che detto così sembra facile, ma prima devo sistemare le pagine dei Pokémon visto che stanno usando tutta 'sta roba)
Segue discussione tecnica, se non siete interessati ignorate. @davla tu non puoi ignorare.
Descrizione
Dall'ottava generazione come dice vorremmo spostare i learnlist/movelist in modulo dati. Maze, avevi proposto qualcosa? Voglio usare quest'issue prima per tracciare le specifiche, poi come memo per implementarle, e vorrei fare il tutto prima dell'uscita di SpSc (anche rimanderei l'implementazione all'estate).
Primo problema: come strutturare il modulo dati. Se lo facciamo "diritto" per uno viene reversed per l'altro. Il timore è che per il reversed risulti troppo lento. Per ora non mi sono venute idee su come strutturare il modulo, però non ci ho ancora pensato molto. Se non troviamo una soluzione per il reverse io metterei veloce il movelist perché il learnlist non ha mai troppe entry (a differenza del movelist). Un'altra idea è quella di avere due moduli dati, uno costruito dall'altro staticamente.