Compatibility list

[Clomax]

Il primo passo verso le schede dettagliate delle traduzioni è stato compiuto. Il resto è solo copia e incolla. E così ci/vi/non ci/non vi toccherà popolare l'archivio di romhacking.it con informazioni di vario genre. Sulla falsariga di romhacking.net tutto ciò che può riverlarsi informazione utile per gli utenti andrà nella scheda della patch. E così vecchie versioni della patch, separazione patch testo e filmati (idea di gem), schreeshots, compatibily list, piccola recensione, materiale vario (tbl, tool e quant'altro) renderanno romhacking.it più di un semplice archivio.

L'utopia: Far accedere ad ognuno alle proprie pagine consentendogli di modificarle. Staremo a vedere quanto tempo ho disposizione. Al momento la richiesta è la seguente:

schreenshots e lista di compatibilità (goodname (snes, genesis, gbc, gba, n64...), release list (gba, ds, psp), md5, exe (psx e ps2)) per le patch prodotte da voi. se potete, se volete.



997 = Castlevania Aria of Sorrow [Evrain]
245 = Breath of Fire [GeO]

public function getCompatibility($stndrd)
   {
   $query="SELECT $stndrd FROM patch_compatibility WHERE id_patch='$this->id_patch'";
   $result = mysql_query($query)
    or die($fail);
   while($valori = mysql_fetch_array($result))
    {
    if ($valori[$stndrd]!=null)
     $stringa = $stringa." ".$valori[$stndrd];
    }
   return $stringa;
   }

<b>Compatibilità: </b><br />
        <?php
        if (($patch->getCompatibility("good"))!=null) echo "Good: ".($patch->getCompatibility("good"))."<br />";
        if (($patch->getCompatibility("rl"))!=null) echo "Release List: ".($patch->getCompatibility("rl"));
        ?>

[mog_tom]

Direi anche counter dei download e commenti/voti, ma anche no.

[mog_tom]

Sia più preciso! una lista puntata!

-screenshot (ok)
-compatibilità (sarebbe meglio menzionare quali emulatori danno troppi problemi)
-goodname (no problemo)

[Gemini]

Ma quando parliamo su msn leggi un minimo di quello che scrivo? Good e RL potevano essere benissimo messe come un campo unico, così come anche l'exe Psx/Ps2. ._.

[Clomax]

good e rl non andavano bene come campo unico. goodgba esiste. preferisco più campi perchè gli altri saranno md5 e cose simili. inoltre è più chiaro. se la tua risposta è: sti cazzi del goodgba tanto tutti usano la rl allora la risposta sarà che non è una ragione valida.

exe psx e ps2 andranno nella colonna exe. inoltre avendo campi diversi è possibile effettuare dei check. come ad esempio il cmapo per l'unica patch per gamecube: gc_serial (12 caratteri in un formato standard, molto facile fargli il check sia a livello di db che a livello di programmazione).

-compatibilità (sarebbe meglio menzionare quali emulatori danno troppi problemi)

per compatibilità intendo
romset, release list e modi per identificare univocamente un gioco. purtroppo gestire gli emulatori è un gran bel casino. tuttavia si può creare un campo commenti per eventuali compatibilità con gli emulatori. nella patch di secret of mana dei sadnes ci andrebbe un commentino sul fatto che con lo snes9x non vengono visualizzate le lettere al momento degli inserimenti dei nomi.

Direi anche counter dei download

è già presente nella versione beta. nel db ogni patch ha un campo click che si incrementa, però, nello stile emuita: ogni click = +1. andrebbe fatto qualcosa di più elaborato stile planetemu: memorizzazione dell'ip che duri h24 con relativo riconoscimento. ma qui bisognerebbe discutere: sessione? coockie (mai nella vita)? database?

commenti/voti, ma anche no

si, è una cosa alla quale avevo pensato. ma per dare un voto servirebbe essere isrcitti al forum...

[Gemini]

good e rl non andavano bene come campo unico. goodgba esiste. preferisco più campi perchè gli altri saranno md5 e cose simili. inoltre è più chiaro. se la tua risposta è: sti cazzi del goodgba tanto tutti usano la rl allora la risposta sarà che non è una ragione valida.

Spreco di spazio alla grande. Te l'ottimizzazione non sai manco dove sta di casa. ._.

exe psx e ps2 andranno nella colonna exe. inoltre avendo campi diversi è possibile effettuare dei check. come ad esempio il cmapo per l'unica patch per gamecube: gc_serial (12 caratteri in un formato standard, molto facile fargli il check sia a livello di db che a livello di programmazione).

Altro spreco di spazio senza limiti. Vergogna. .-. Non ci voleva una mazza a fare un campo che definisse la console (una bella INT(1)), da cui ricavare il metodo per stampare una scheda diversa tra una piattaforma e l'altra. Doppia vergogna. -.-

[yuumeikai]

Sempre a polemizzare e mai a dare seriamente una mano o porre una soluzione.
Per quanto detto, comunque, concordo con Clomax per le varie divisione dei field.

[Gemini]

Sempre a polemizzare e mai a dare seriamente una mano o porre una soluzione.
Per quanto detto, comunque, concordo con Clomax per le varie divisione dei field.

E l'idea dei nomi degli exe Psx/Ps2 secondo te da dove salta fuori?  B)
Ad ogni modo, ho già proposto la mia idea su come ottimizzare lo spazio (è ridondante avere due campi che svolgono praticamente la stessa funzione, tipo Good e EXE), per cui ridurre anche i tempi delle query. Più di così non saprei che inventarmi. E come disse Gigi Sabani durante gli spot della Garelli: Ma cosa volete di più? IL SANGUE!? xD

[Clomax]

due campi che svolgono praticamente la stessa funzione, tipo Good e EXE

si, è una cosa attuabile. ma per scegliere quale tra good ed exe segnalare bisogna capire il nome della console. il che significa lanciare il metodo appropriato della classe patch. insomma la coperta o è troppo lunga o è troppo corta. a prescindere da ciò (se ne riparlerà al momento delle ottimizzazioni, al momento vediamo di far funzionare tutto) c'è un altro dubbio da risolvere: come gestire la sezione downloads traduzioni.

due possibilità:

lo script effettua la query e tramite un ciclo crea tanti oggetti quante sono le patch (il che sarebbe quasi ottimale se lil garbage collectr del php (se si chiama così) funzioni come java ed elimini la classe creata senza bisogno di un distruttore. una volta creato (nel ciclo) l'oggetto vengono richiamati i metodi e lo script li mette assieme per creare la riga nome, versione, percentuale, readme, autore che conosciamo.

lo script manda al costruttore della classe una serie di vincoli via stringa che si andarnno ad accodare ad una query nel costruttore stesso (questo consentirà un motore di ricerca piuttosto cazzuto) e il costruttore effettua la query. grazie ad un iteratore (dea non confondere con l'interfaccia Iterator di java) lo scipr itererà sull'oggetto contenente la maxi query consentendogli di scandire le righe e visualizzarle.

al momenhto la soluzione adottata è la prima e SENZA DISTRUTTORE. una fetecchia tremenda. ma vorrei cambiare in corsa. alla fine la seconda ipotesi mi sembra abbordabile. tanto alla fine la query deve tirarsi fuori quella benedetta riga.

nel secondo caso l'oggetto da creare sarebbe lo stesso, basta che il vincolo passato al costruttore sia l'id della patch (quest'idea  :idea:  mi è venuta in mente subito). faccio notare la cosa a quel gran minchione di gemmo (che ieri mi sono inculato molto volentieri  :w00t: e aspetto vostre opinioni).

[Gemini]

Direi che l'idea di creare un oggetto per ogni entrata della tabella sarebbe l'idea migliore, dato che si avvicina al metodo classico di query SQL e non dovrebbe comportare troppi sforzi a livello di esecuzione.

si, è una cosa attuabile. ma per scegliere quale tra good ed exe segnalare bisogna capire il nome della console. il che significa lanciare il metodo appropriato della classe patch. insomma la coperta o è troppo lunga o è troppo corta.

E che avrebbe che non va questa coperta? Basta mettere un campo apposito e buona notte, si accorpano tutte le tabelle con quel valore in comune.

che ieri mi sono inculato molto volentieri :w00t:

Aspetta e spera che mi inculi, maniaco dell'apparato anale. ._.

[Clomax]

Direi che l'idea di creare un oggetto per ogni entrata della tabella sarebbe l'idea migliore

stasera ci ho lavoricchiato ed ecco cosa ne è venuto fuori:

costruttore

Codice Seleziona Espandi

public function __construct ($stringa)
  {
  $query = "SELECT * FROM gestione_link, gestione_traduzioni, gestione_console, gestione_vg ".$stringa;
  //echo $query;
        $this->result = mysql_query($query)
   or die($fail);
  $this->card = mysql_num_rows($this->result);
  $this->valori = mysql_fetch_array($this->result);
  }


iteratore

Codice Seleziona Espandi

 public function iteratore()
  {
  return ($this->valori = mysql_fetch_array($this->result));
  }


ecco come utilizzare la classe patches

Codice Seleziona Espandi

$patches = new patches($stringa);
do
  {
  echo $patches->getRow();
  }
 while ($patches->iteratore());


a funzionare funziona tutto. il modulo di ricerca lo miglioro domani ma grazie a

Codice Seleziona Espandi

$this->card = mysql_num_rows($this->result);

 public function getCard()
  {
  return ($this->card);
  }


ci sarà una funzionalità in più. sono soddisfatto dell'idea. l'intera clausola WHERE come parametro del costruttore. buono per una singola patch (where sull'id) e su query impostate da moduli di ricerca ANCHE complessi.

bene, bene

cmq per la sezione download_traduzioni ci sarà un oggetto per ogni tabella. in ogni caso mi studio il comportamento di __destruct() per ottimizzare la memoria.

n.b. ho intenzione di implementare la feature suggerita dal RICCHIONE definitivo. chiunque abbia idee le esponga. appena si raggiungerà un livello di decenza metterò a disposizione l'intero codice del sitozzo.

n.b. 2 sul server gira la versione 4 di php che non supporta i modificatori di accesso per le variabili di istanza e metodi (al contrario di php5). sfancularli e piazzare un VAR nelle variabili non è troppo difficile.

a parte il motore e il resto il vero problema rimane la grafica. come esportare gli script da una grafica all'altra. dopo aver lavorato su questo la gfx potrà anche essere dinamica.

il dinamismo di clomaxRGB (tre fogli di stile) non è stato possibile. il motivo è uno solo: bordercolor=\"#0068ae\". non è possibile ricreare via css lo stile attuale di clomax dominion.

[mentz]

Ma se ti passo un file txt o xls con tutta la lista (appena lo faccio)?

[Clomax]

Ma se ti passo un file txt o xls con tutta la lista (appena lo faccio)?

cosa?!

[yuumeikai]

appena si raggiungerà un livello di decenza metterò a disposizione l'intero codice del sitozzo.

[...]

a parte il motore e il resto il vero problema rimane la grafica. come esportare gli script da una grafica all'altra. dopo aver lavorato su questo la gfx potrà anche essere dinamica.

Rendere disponibile il codice del sito significa anche renderlo visibile ad una utenza poco affidabile. Tramite bug nascosti nel codice potremmo perdere, quel poco che abbiamo, in sicurezza (e non dico altro sennò ci facciamo tutti quattro risate  :rolleyes: ). Magari non è il nostro caso, visto che si tratterebbe di routine di ricerca, ma con i database non c'è mai da stare allegri.

Per la gfx del sito, io sono più che pronto. L'ho completata da tempo e aspetta solo di prendere vita grazie alla sua controparte tecnica.

[Psyco]

Ottima idea ragazzi, una ventata di aria fresca!
Sarò certamente del gruppo a dare una mano.

Unica cosa: sto lavorando alacremente sulla codice della mia nuova _Psyco_ Homepage che sta diventando così come la volevo ^^.
Oltretutto, come se non bastasse, ho riaperto il mio "cantiere" dopo più di un anno e mezzo di stop, perciò se avrete pazienza, la mia quota di traduzioni, con tutti gli extra che ci stanno dietro, la farò tranquillamente io.
 :saluto: