Un nuovo Rom Manager? Forse...

[Nikoh]

Salve a tutti, un pò per studio, per approfondire le mie competenze nella programmazione, un pò perché non sopporto più che non ci sia un rom manager nativo linux ed infine perché avrei tante idee per arricchirlo, come ad esempio un p2p per il completamento dei romset, vorrei provare a realizzare un rom manager, per ora potremmo chiamarlo Romix.
Come suggerito da @motoschifo apro questo nuovo post per vedere un pò chi avrebbe voglia di aiutare, anche solo ragionando insieme perché ad oggi le cose "non stanno molto bene" nel senso che esistono moltissimi formati di questi file descrittivi, alcuni desueti ed altri più nuovi, tutti più o meno efficienti ma che richiedono scanner diversi, cioè algoritmi di parsing differenti, il che complica parecchio il software e lo rende molto meno stabile.
Un approccio monolitico sarebbe sicuramente migliore ma non credo sia possibile.
Io ci sto già lavorando da qualche giorno, attendo feedbacks

[pucci]

perchè dici che ci sono molti formati di file descrittivi? praticamente tutti i file dat usati dai rom manager si basano ancora sugli standard creati da logiqx
l'unica cosa che nei dat molto vecchi (ormai praticamente non usati) erano dei file di testo mentre ora sono praticamente tutti XML ma che si basano sempre sugli standard di logiqx

[Nikoh]

perchè dici che ci sono molti formati di file descrittivi? praticamente tutti i file dat usati dai rom manager si basano ancora sugli standard creati da logiqx
l'unica cosa che nei dat molto vecchi (ormai praticamente non usati) erano dei file di testo mentre ora sono praticamente tutti XML ma che si basano sempre sugli standard di logiqx

Eh magari....
A prima vista potrebbe sembrare ma non è così, i dat no-intro ad esempio hanno una costruzione diversa da quelli per mame che a loro volta potrebbe averla diversa da quelli per FinalBurn.
No-intro ha introdotto (sacrosanto aggiungerei) un id per sistema per cui nell'header ad esempio c'è l'id 46 che rappresenta il GameBoy; questo soltanto nella release standard dat mentre ad esempio nella versione P/C non c'è quidi il sistema viene identificato esclusivamente tramite il campo di testo "name".
Alcuni dat per mame utilizzano il tag "machine" al posto di "game"
Etc.
Etc.
Etc.

Per carità tutto gestibile, ma come ho detto è impossibile avere uno scanner monolitico.

[motoschifo]

perchè dici che ci sono molti formati di file descrittivi? praticamente tutti i file dat usati dai rom manager si basano ancora sugli standard creati da logiqx
l'unica cosa che nei dat molto vecchi (ormai praticamente non usati) erano dei file di testo mentre ora sono praticamente tutti XML ma che si basano sempre sugli standard di logiqx

Come scritto sopra, apparentemente sono file uguali ma in realtà esistono regole ed eccezioni.
Io ad esempio lavorando i file xml del Mame, trovo spesso modifiche (magari piccole) che però invaliderebbero qualunque statistica o scanner, dato che non erano previsti.
Senza contare sconvolgimenti in termini di nomi dei nodi o degli attributi.
Considera che confronto la struttura di ogni release con quella precedente, tutti i mesi, proprio per evitare problemi al sito o per apportare modifiche. In questi anni credo di aver ritoccato la logica una ventina di volte circa, alcune cose piccole ma altre più importanti. In fase di export, gestisco tutte queste casistiche per poter esportare un set compatibile con la versione selezionata.

La mia risposta comunque andava oltre la definizione, nel senso che "dat" o "xml" sono file che permettono di astrarre dai valori memorizzati e quindi l'interoperabilità tra due software (es. il Mame e il mio sito). Il vero problema è che non esiste un documento, incluso nell'xml, con la descrizione di tutte le regole necessarie per poter gestire il file.
Il team del Mame ha messo la documentazione minima come header, ma ci sono tante cose che non ha mai spiegato ed anche quando facevo domande qui o sul loro github ricevevo risposte vaghe, proprio perchè parliamo di tanti programmatori diversi in tempi diversi, quindi alcune cose sono lì per convenzione mentre altre modificate decenni dopo.

Per esempio io avrei introdotto una regola secondo me basilare: mai cambiare la chiave del dato (il nome del romset). Quel nome è una chiave univoca, eventuali dati descrittivi andrebbero messi altrove (es. un attributo "id" ed un attributo "common-name" o qualcosa di simile).

[Gothrek]

Al momento mi estraneo dal progetto, ho un impegno con @AntoPISA che devo assolutamente chiudere per gestire i dat del mame e dei suoi aggiornamenti del progetto snaps per cui non riesco a condividere.
Per quanto mi riguarda AntoPisa aveva già tracciato una strada che ho ripreso per il mio scraper/rom manager, ossia id univoco per rom.
Per quanto riguarda il mame, l'id è un numero consecutivo del sistema nell'ordine in cui nelle versioni del mame è stato aggiunto.

Per quanto riguarda gli altri sistemi il mio rommanager (non so se sei andato a guardarlo come scrissi su un altro topic) li gestisce con un id sistema (recuperato da screenscraper) e il suo md5, che in generale è univoco ed è gestito dal dat di NoIntro.

[Nikoh]

@motoschifo @Gothrek inserire un id univoco persistente è ovviamente l'unica strada, come infatti ha fatto il team di no-intro; loro forniscono anche un dat compatibile/simile a quello mame ma il loro dat standard prevede un id, ed anche il campo cloneof di mame lo hanno modificato in cloneofid.
Anyway, prima di tutto occorre realizzare uno scanner che più o meno riesca ad "acchiappare" i dati almeno dagli ultimi formati mame, finalburn, no-intro e redump credo, dopodiché si formatteranno i dati in un nuovo standard che vorrei chiamare unidat e per il quale vorrei usare il formato json.
@motoschifo potremmo prevedere una sorta di integrazione tra i dati in tuo possesso ed il mio software ad esempio per avere una corretta gestione di lingue e region tramite hash senza dover ricorrere al nomefile?

[Nikoh]

Per quanto riguarda gli altri sistemi il mio rommanager (non so se sei andato a guardarlo come scrissi su un altro topic) li gestisce con un id sistema (recuperato da screenscraper) e il suo md5, che in generale è univoco ed è gestito dal dat di NoIntro.

Ho visto degli screenshots, non sono potuto andare oltre perché solo Windows mi sembra?!

[Gothrek]

Per quanto riguarda gli altri sistemi il mio rommanager (non so se sei andato a guardarlo come scrissi su un altro topic) li gestisce con un id sistema (recuperato da screenscraper) e il suo md5, che in generale è univoco ed è gestito dal dat di NoIntro.

Ho visto degli screenshots, non sono potuto andare oltre perché solo Windows mi sembra?!

confermo si.

Mi spiace non esserti utile in questo "momento storico" ma ho delle attività pendenti che per correttezza devo riuscire a chiudere altrimenti il povero AntoPisa mi uccide (giustamente)

[pucci]

perchè dici che ci sono molti formati di file descrittivi? praticamente tutti i file dat usati dai rom manager si basano ancora sugli standard creati da logiqx
l'unica cosa che nei dat molto vecchi (ormai praticamente non usati) erano dei file di testo mentre ora sono praticamente tutti XML ma che si basano sempre sugli standard di logiqx

Eh magari....
A prima vista potrebbe sembrare ma non è così, i dat no-intro ad esempio hanno una costruzione diversa da quelli per mame che a loro volta potrebbe averla diversa da quelli per FinalBurn.
No-intro ha introdotto (sacrosanto aggiungerei) un id per sistema per cui nell'header ad esempio c'è l'id 46 che rappresenta il GameBoy; questo soltanto nella release standard dat mentre ad esempio nella versione P/C non c'è quidi il sistema viene identificato esclusivamente tramite il campo di testo "name".
Alcuni dat per mame utilizzano il tag "machine" al posto di "game"
Etc.
Etc.
Etc.

Per carità tutto gestibile, ma come ho detto è impossibile avere uno scanner monolitico.

I dat MAME con tag Game sono quelli vecchi prima della fusione MAME e MESS. Quindi tutto normale

Il fatto che i dat nointro abbiano l'ID è una scelta loro.

Se vuoi uniformare tutto il problema non sta nello schema dei dat (che tra l'altro essendo XML sono espandibili), ma nel fatto che i gruppi di 'datter' sono diversi e seguono principi diversi

La struttura per quello che vuoi tu esiste già, quello che manca è la mentalità di chi lavora i dat

[motoschifo]

@motoschifo @Gothrek inserire un id univoco persistente è ovviamente l'unica strada, come infatti ha fatto il team di no-intro; loro forniscono anche un dat compatibile/simile a quello mame ma il loro dat standard prevede un id, ed anche il campo cloneof di mame lo hanno modificato in cloneofid.
Anyway, prima di tutto occorre realizzare uno scanner che più o meno riesca ad "acchiappare" i dati almeno dagli ultimi formati mame, finalburn, no-intro e redump credo, dopodiché si formatteranno i dati in un nuovo standard che vorrei chiamare unidat e per il quale vorrei usare il formato json.
@motoschifo potremmo prevedere una sorta di integrazione tra i dati in tuo possesso ed il mio software ad esempio per avere una corretta gestione di lingue e region tramite hash senza dover ricorrere al nomefile?

Confermo che la strada dell'id univoco è l'unica percorribile, anche io internamente al mio db ne ho uno ma non ha significato se non essere univoco all'interno della tabella.
Tempo fa avevo iniziato a considerare di farlo anche io, ma purtroppo le cose sono troppo complesse al momento per poterlo implementare.
Infatti sul sito esistono tutte le versioni, ogni cambiamento in avanti non ha la possibilità di tornare indietro in caso di errori. Ed è questo il vero problema.
Vuol dire che prima di un eventuale aggiornamento alla nuova release, si dovrebbe prima di tutto condurre un'indagine su TUTTI i giochi per capire se sono stati cambiati, poi successivamente al termine (giorni dopo) iniziare l'aggiornamento del sito e assegnare nuovi id (tutte le risorse collegate al vecchio id non sarebbero più visibili sul nuovo id).
Dato che sono operazioni a senso unico, in caso di errori si avrebbero ripercussioni enormi sul resto dei dati e il database perderebbe integrità.
Per es. se un gioco è diverso ma non è stato portato ad un nuovo id, a quel punto la separazione andrebbe fatta manualmente e coinvolgerebbe molti collegamenti (oltre ad essere un lavoro delicatissimo).
Non escludo di farlo in futuro, oggi però non riesco.

Vedo invece più pratico assegnare quell'id al gioco, così da riconoscerlo (come il gamebase-id), o trasformare questo id in romset+release (es. mslug.261).
Altra cosa da considerare: tutto ciò che è fuori da questi ragionamenti, non ragiona per versione quindi per loro esiste mslug (ed è per quel motivo che la chiave primaria non va mai cambiata, specialmente se poi la comunichi all'esterno).