Compatibility list

Aperto da Clomax, Maggio 08, 2006, 18:12:48

Discussione precedente - Discussione successiva

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]

Citazionepublic 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.
13:18:06 Roberto intanto
13:18:07 Roberto inizia col descrivermi
13:18:14 Roberto con dovizia di particolari
13:18:15 me ho appena mandato 5 euri ai processati del g8
13:18:20 Roberto il tuo pene

mog_tom

Sia più preciso! una lista puntata!

-screenshot (ok)
-compatibilità (sarebbe meglio menzionare quali emulatori danno troppi problemi)
-goodname (no problemo)
13:18:06 Roberto intanto
13:18:07 Roberto inizia col descrivermi
13:18:14 Roberto con dovizia di particolari
13:18:15 me ho appena mandato 5 euri ai processati del g8
13:18:20 Roberto il tuo pene

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. :P

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).

Citazione-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.

CitazioneDirei 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?

Citazionecommenti/voti, ma anche no

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

Gemini

Citazionegood 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. :P
Spreco di spazio alla grande. Te l'ottimizzazione non sai manco dove sta di casa. ._.

Citazioneexe 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

CitazioneSempre 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

Citazionedue 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.

Citazionesi, è 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.

Citazioneche ieri mi sono inculato molto volentieri :w00t:
Aspetta e spera che mi inculi, maniaco dell'apparato anale. ._.

Clomax

CitazioneDirei 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

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

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


ecco come utilizzare la classe patches

$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

$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 :P

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. :D

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

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

cosa?!

yuumeikai

Citazioneappena 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:  
sito ufficiale: _Psyco_Homepage
E-mail: fera.82@libero.it