Gestione dei contenuti: informazioni e diagramma.

Gjon ha postato qui
http://isiforums.net/f/showthread.php/1355-Managing-Content-for-rFactor-2

un diagramma semplice e intuitivo che mostra il modo in cui funziona in rF2 la gestione dei contenuti.



Gjon scrive:

Il diagramma offre una vista generale su come i contenuti sono gestiti dal sistema di rFactor2, per la modalità offline e per quella online.

I Components sono vetture, piste, suoni, UI, HUD, livree, showrooms, in forma completa.
Un singolo circuito è un esempio di componente.
Usare All Cars and Tracks, disponibile in modalità single player, consente di guidare qualsiasi vettura installata su qualsiasi pista, per esempio quella appena scaricata e installata.

Le Race Series (o Mods) sono composte da un gruppo di componenti, che abbiano almeno una vettura e una pista.
Ogni mod ha una sua propria Mod ID e può essere testata online dal modding team quando è in sviluppo.
Una volta che la mod è completata, una "submit ID" viene generata e mandata al matchmaker.
Una volta che la mod ha la sua ID pubblica, diventa disponibile per l'intera comunità online ed è "versione controllata" in modo da eliminare problemi di mismatch.

Le mods possono essere create completamente da zero o combinando componenti creati da altri.
Una mod può contenere "componenti virtuali", ovvero puntare su componenti esistenti senza includerli fisicamente.
Questo riduce copie inutili degli stessi componenti.
Un utente che scarica una mod contenente componenti virtuali non potrà installarla nel caso questi componenti non siano già installati.
Un log di errore informerà l'utente su ogni componente virtuale mancante.

 

Mi sembra di capire che ogni mod ha le sue auto e le sue piste, almeno in multy, spero che si possa cmq girare su tutte le piste con tutte le auto....

 

Offline sarà possibile in automatico, tramite All Cars and Tracks.

Online sarà possibile aggiungere componenti, anche virtuali, in modo da creare in ogni mod liste sempre più ampie di tracciati.

Forse qualcuno ricorderà quando dicevo che il sistema di packaging avrebbe richiesto una discussione interna alla comunità internazionale così da trovare il modo più efficace per utilizzare al meglio il sistema di rF2.
Adesso, con gli elementi postati da Gjon, capite a cosa mi riferivo.

C'è da aggiungere che, fermo restando l'idea generale del sistema, la open beta serve principalmente ad ascoltare i modder (e in un secondo momento league admins e utenti comuni) in modo da ampliare, rendere sempre più flessibile ed ottimizzare il sistema di packaging.

Personalmente, per esempio, non avrei niente in contrario se le mod di F1, per dire, andassero a raccogliere le vere piste della stagione più poche altre, o se le mod storiche contenessero solo piste nei layout storici, ma questa è solo la mia opinione personale.

La comunità, nel suo insieme, dovà trovare il modo di ottimizzare il modo di mettere insieme vetture e piste e sono certo che ci riuscirà benissimo.

 

Qui Gjon aggiunge alcune precisazioni
http://isiforums.net/f/showthread.p...nt-for-rFactor-2?p=19306&viewfull=1#post19306

Dice:

Una ModID dovrebbe essere utilizzata quando qualcuno desidera creare una mod (con almeno una vettura e almeno una pista) che sarà hostata online e utilizzata da altri.
Non è necessaria se qualcuno crea nuovi contenuti per se stesso o altri da utilizzare in single player.

Una ModID è creata da qualcuno con un valido account online ed è assegnata a quella persona.
Una volta che la mod è pronta per il rilascio pubblico, dovrà esserle assegnata una versione e una SubmitID.
Queste azioni hanno il risulato di identificare la mod in modo tale che conflitti sul suo nome non potranno accadere.

Se ci fossero problemi con una mod, l'assegnatario della ModID potrà essere contattato nel tentativo di risolvere il problema.
La crittazione provvista per rF sarà ancora disponibile ed è una feature che speriamo di rendere più avanzata nel proseguo di rF2.

 

Grazie mille per le traduzioni

 

Nuove precisazioni da parte di Gjon
http://isiforums.net/f/showthread.p...nt-for-rFactor-2?p=19378&viewfull=1#post19378

Non c'è niente nel nuovo sistema che possa rendere più semplice distribuire contenuti rubati come fossero propri.
Non c'è niente che renda più difficile proteggere una mod.

Dato che adesso ci sono acconti online persistenti (diciamo unici e legati alla licenza) c'è sempre la possibilità di bannare gli utenti scorretti o impedire loro di creare ModID.

In modalità single player All Cars and All Tracks consentirà di gareggiare qualsiasi cosa in ognidove.
In multiplayer d'altra parte sarà necessario definire i contenuti della mod in modo che, prima qualcuno tenti di entrare in un server, il sistema possa determinare se l'utente ha i contenuti richiesti.
Questo avviene tramite ModID e SubmitID.
La creazione, l'hosting e la manutenzione delle mod continuerà a rimanere nelle mani dei modders.
Le mod non passano da ISI e ISI non valuta, giudica o testa le mod

 

http://isiforums.net/f/showthread.p...nt-for-rFactor-2?p=19382&viewfull=1#post19382

Sarà possibile creare car packs come in rF, ma questi saranno componenti.
Se non viene specificato su quali piste il car pack può gareggiare, non ci sarà modo di determinare che, chi vuole entrare nel server ha le piste, abbia installate le piste del server.

Una SubmitID basicamente ti dice che la mod è pronta per il rilascio rendendola aperta a chiunque.
Mentre stai ancora lavorando sulla mod, questa è considerata in sviluppo ed esiste un modo particolare per consentire, esclusivamente al modding team, di testare online.
Fino a che la mod è in modalità sviluppo, non verrà vista nella lista dei server

 

A me mi paice assai.

Quale procedura è prevista nel caso di utilizzo di contenuti per i quali non si ha il permesso del creatore?

Immagino che il modder "vittima" dovrà comunicare ad ISI l'episodio. E poi cosa succede?

 

http://isiforums.net/f/showthread.p...nt-for-rFactor-2?p=19383&viewfull=1#post19383

Per rendere effettive delle modifiche ad una mod, sarà necessario creare una update o una nuova mod, che può contenere solo i files modificati (e/o aggiunti) e puntare sulla mod originale per i files invariati.
Questa potrebbe essere una mod con componenti virtuali

 

http://isiforums.net/f/showthread.p...nt-for-rFactor-2?p=19384&viewfull=1#post19384


Come amministratore di lega, dovrai creare una nuova mod con le vetture e le piste necessarie.
Questo può essere fatto tramite files fisicamente installati o tramite componenti virtuali.

 

http://isiforums.net/f/showthread.p...nt-for-rFactor-2?p=19389&viewfull=1#post19389


Il concetto di mod privata è previsto, ma non ancora pienamente implementato.
A differenza di rF, adesso abbiamo account online persistenti.
Come risultato, permettere agli utenti di appartenere a dei teams e avere ModID assegnate privatamente ai team diventa una possibilità.
Ma, ripeto, questo concetto non è implementato per ora, anche se il piano è quello di far crescere il sistema in modo da renderlo più pratico così da venire incontro ai desideri e alle necessità della comunità

 

http://isiforums.net/f/showthread.p...nt-for-rFactor-2?p=19393&viewfull=1#post19393

Una lega può prendere una mod, creare una nuova versione che per esempio abbia le piste con più garages, e usare una nuova SubmitID, rendendola disponibile ai propri membri.
Quando qualcuno che ha la versione originale della mod desidera entrare nel server, riceverà un messaggio di avvertimento che non può entrare.

 

Non so dire di preciso ... fuori da ogni ipocrisia tendo a pensare che, o qualcuno interno a ISI si prende la bega di fare controlli approfonditi (ipotesi remota a mio parere), o la vittima dovrà dare prove evidenti sul torto subito.

Una volta accertata la scorrettezza, ho tradotto poco sopra .... ci potrebbe essere il ban o l'interdizione a creare ModID.

 

domanda: ma offline sarà possibile creare campionati scegliendo tra auto e piste disponibili nelle varie mod? Perchè in rF1 non si poteva fare se non con l'ausilio di utility esterne (o smanettando sui file, cosa un po' più complessa)

 

Tanto per chiacchierare, visto che attualmente possiamo soltanto fare bar dello sport e poco altro, l'unica cosa che mi convince poco di questo sistema di packaging che, ripeto, per il resto mi pare eccellente, è proprio questa...
Mi fa un pò storcere il naso la necessità di legare tutto in un unico pacchetto le mod e le piste perchè in questo modo diventa in primo luogo molto piu difficile per noi admin(chiam) effettuare eventuali sostituzioni dei tracciati che talvolta si rendono necessarie a campionato in corso per bug non conosciuti al momento della presentazione del materiale, avvenuta magari diversi mesi prima.
Inoltre, s'era detto che tutto questo era orientato ad evitare i mismatch ma a mio parere, leggendo la traduzione di Max delle parole di Gjon, di fatto resta comunque molto complicato accedere ai server.
Rischia di morire il concetto stesso di Special Event, gare singole su piste singole con le mod piu disparate, volte a tastare il gradimento degli utenti e la presenza o meno di bug per poterle utilizzare poi in eventuali campionati, se ogni volta è necessario fare un nuovo pacchetto (leggasi nuova mod!!) con auto e pista.
Io, visto che per le piste c'è molto meno l'esigenza di "proteggere" il lavoro dei modders, francamente lascerei slegate le piste dalle mod...

 

Penso proprio che saranno necessari tools esterni, a meno che ISI non abbia qualche coniglio nel cappello di cui non sono a conoscenza.

 

Il sistema è questo, aperto a modifiche per renderlo più flessibile e adatto alle esigenze di vari tipi di utenza, ma sulle basi Gjon è molto convinto e penso non ci sia spazio per ripensamenti.
Insomma, le vetture sono componenti, le piste sono componenti e le mod devono contenere le une e le altre.

Io credo che la chiave sia trovare un modo condiviso per aggiornare le mod (aggiungendo piste) e per rendere facile il sapere che la mod X è stata aggiornata alla vY con l'aggiunta delle piste A, B, C ecc.

Questo per i server pubblici.

Per le leghe, fossi admin e volessi costruire la mia mod inserirei alcune piste di riserva, per ridurre la noia di dover aggiornarla a causa di problemi non previsti con i tracciati.

Poi, per quanto riguarda eventi singoli, una mod costruita sulla base di componenti virtuali peserebbe pochissimo, mentre il tempo di creazione sarebbe nell'ordine di un paio di minuti, una volta fatta la mano con il tool di packaging.

Diciamo che, in quanto a fastidi per gli organizzatori e per i piloti, non cambia molto.

 

Mi fido al 100% delle tue parole Max.
Unica cosa che non capisco bene è cosa intendiamo per "componenti virtuali" in una mod. Si può essere più dettagliati sul punto oppure non puoi ancora sbilanciarti?

PS: quando esce rFactor2?

 

non so se ho capito bene ma ad occhio e croce si prendono in prestito concetti di software versioning che poi non è tanto balzana come idea dato che sempre di software stiamo parlando.
I modder creano i componenti che dalla figura sembrano essere audio, modelli, piste ecc ovvero componenti ancora + discreti rispetto al concetto di mod che intendiamo con rF1 dove un mod è l'insieme di modelli, fisica, audio.. tutto insomma tranne le piste.
Una volta che i modder hanno fatto i componenti creano anche un mod mettendoci almeno una pista quindi con il rilascio del modid sappiamo che è stato rilasciata almeno una macchina completa su una pista completa.
Fin qui spero di aver capito bene.
Poi succede che chiunque può creare una evoluzione di questo mod, ci cambia qualcosa, magari ci aggiunge una pista ma questo non genera un nuovo modid poichè l'id originario resta quello, si genera solo un submitid (si chiama così vero?) e quindi in questo modo non si perdono le tracce ne del mod originario, ne del modid, ne della sua intera evoluzione e ne di chi fa cosa.. modder e contributi successivi.
Questo pare chiaro.
E' chiaro anche il concetto di virtuale ovvero se io parto da un mod e ci aggiungo una pista, il mod risultato è fatto da un riferimento al mod originario che quindi essendo solo referenziato non genera un nuovo pacchetto a cui si aggiungono le modifiche, questa volta con un pacchetto pesante, contenente per esempio la pista o il nuovo audio o quasiasi altra correzione.

Prendiamo una lega tipo che vuole organizzare uno Special Event, decide per il mod 001 ma le piste che contiene ora non gli piacciono, decide quindi di correre sulla pista (che immagino è un contributo ma a questo punto mi chiedo che ID abbia) e genera un nuovo submitid quindi una evoluzione del mod 001. Se poi dopo 1 mese decide di fare un'altro evento deve fare l'ulteriore evoluzione di questo mod.. insomma nulla di osceno ma di certo proliferanno le versione ed attenzione, non ci sarà un solo ramo ma tanti rami evoluzionistici, posso aspettarmi che dalla release base del MOD io abbia in partenza 2 evoluzioni (per esempio) e poi da queste ne escano altre ancora ed è facile immaginare una ramificazione bella affollata.. tutto tracciato e tutto riconducibile ma il fattore mismatch non scompare, è solo + documentato.

Credo...

EDIT: ma anche per aggiungere una skin si deve fare una submit id ?

 

Facciamo un esempio:

metti che la beta esca con le monoposto storiche che hanno due piste, Monaco e Spa.
Metti che esca la Megane con altre tre piste.

Ora, metti che entrambe le mod siano installate.

Se volessimo creare una nuova mod, diciamo la Megane con le sue piste più Monaco e Spa storiche, sarebbe uno spreco di spazio crearle con tutti i file, ci sarebbero doppioni della macchina e delle piste, cioè doppioni di tutti i componenti già installati (parecchie centinaia di MB).

Ecco che entrano in gioco i componenti virtuali.
Il creatore della nuova mod ha solo da creare il file rFm e da puntare i file della macchina e delle piste seguendo il percorso di quelle già installate.
In questo modo la nuova mod, fatta di componenti virtuali, va a pesare pochi KB.
Vengono chiamati componenti virtuali perchè sono utilizzati dalla nuova mod senza appartenere fisicamente al pacchetto della mod.

Chiaro che tutti coloro che vanno ad installare questa ipotetica mod debono avere già installati i componenti.