Gestione dei contenuti: informazioni e diagramma.

sequel said:
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 ?
Click to expand...

Dunque, i dettagli del sistema non li conosco ... il feedback sulla beta, da parte dei modders, aiuterà a chiarire tutti i meccanismi.

Le "ramificazioni" ci saranno seza dubbio, del resto la customizzazione è una caratteristica peculiare dei software ISI, ma la prima ramificazione penso che sarà

mod per leghe - mod per il pubblico

Da questi due tronchi principali si svilupperanno molti altri rami, ma penso che gli interessi (e quindi il modo di ramificare) saranno differenti.
Cioè, mentre le leghe andranno a ramificare senza curarsi del pubblico, ma solo dei propri piloti (quindi ramificazioni a iosa hehe), il tronco delle mod per il pubblico dovrà trovare, in modo concordato, la maniera più efficace per far "crescere il tronco" senza ramificare troppo.

E' un sistema nuovo e tutti ci poniamo questioni, nella consapevolezza che si abbandona una strada per percorrerne una nuova, ma guardate cosa la comunità è riuscita a fare di rF in questi sei anni (mod, siti di riferimento, piste, addon vari).
Con una tale potenza creativa, onestamente non ho dubbi sul fatto che la "ramificazione pubblica" di rF2 troverà una sua via di sviluppo condivisa, riducendo al minimo i disagi.

Ma questa è solo la mia opinione, solo il tempo potrà dire se la scelta di disegno del sistema di modding si rivelerà vincente. :)

Le skin fanno parte dei componenti ... aggiungere una skin singola diventerà un fastidio (credo, perchè non sono certo che le livree "esterne" al pacchetto non vengano viste), ma uno skin pack sarà un semplice componente da aggiungere nel file della mod, niente di problematico.

Certo, le leghe che utilizzeranno rF2 dovranno prendere atto e riadattarsi ... prima di fare uno skin pack sarà bene che tutti abbiano inviato all'admin le loro livree definitive.
 
Max Angelo said:
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.
Click to expand...

giusto per capire meglio.
ma quindi se uno volesse mettere su un server pubblico con le F1 storiche + Sepang, da quanto ho capito deve creare un mod componente virtuale.

la domanda è:
una volta messo online il server free, se uno volesse entrare dalla lista server senza sapere niente, lo può fare? lo vede il server?
(o deve prima registrarsi al determinato forum che organizza e scaricare il mod virtuale?)
 
abbastanza chiaro quello che dici Max, diciamo che di base l'approccio porta vantaggi perché si basa sulla filosofia che un componente fa parte di un pacchetto (mod) ma allo stesso tempo può essere usato, referenziandolo, da altri mod i quali possono contenere altri componenti e referenziarne altri. La svolta rispetto a rF1 pare essere che mentre in rF1 un mod è composto solo dalle auto (modelli, fisica e suoni) mentre ora è composto da almeno una pista le quali piste in rF2 non possono viaggiare da sole ma devono essere incluse sempre in un mod.. ecco che succede però una cosa, se una lega vuole fare un campionato con il mod GT (esempio) al cui interno ha per esempio 15 piste.. però la sfiga vuole che a questa lega queste piste non piacciono o non piacciono tutte.. allora trova altre 5 piste che (sempre per sfiga) sono in 5 altri mod diversi, in rF1 gli bastava prendere il mod e copiarci le 5 piste che gli interessavano senza altro peso, in rF2 deve far installare a tutti oltre al mod GT anche altri 5 mod dove per ognuno solo la pista serve ed il resto diventa peso e spazio inutili occupato sul disco.
Come vedi non è affatto detto che questo sistema faccia risparmiare spazio, in molti casi ne può far occupare molto di più, almeno così pare.
 
giusto per capire meglio.
ma quindi se uno volesse mettere su un server pubblico con le F1 storiche + Sepang, da quanto ho capito deve creare un mod componente virtuale.

la domanda è:
una volta messo online il server free, se uno volesse entrare dalla lista server senza sapere niente, lo può fare? lo vede il server?
(o deve prima registrarsi al determinato forum che organizza e scaricare il mod virtuale?)
Click to expand...

Si, sarebbe necessario creare una nuova mod, ma quella di usare componenti virtuali è solo una opzione di scelta.
Volendo, il creatore della nuova mod potrebbe inserire nel package la pista completa, con il risultato di avere un peso di oltre 100MB, oppure potrebbe inserire tutti i componenti (macchine, piste, audio ecc) con il risultato di avere una mod di oltre 1GB.

Nel caso delle mod ISI, dando per scontato che tutta l'utenza avrà installate tutte le mod, quella dei componenti virtuali mi sembra la soluzione più conveniente per ampliare il parco piste, ma in futuro potrebbero esserci casi nei quali inserire il componente nel pacchetto potrebbe essere più pratico.

Dipende dalla diffusione del componente, nel senso che gli utenti, o come componente della mod X o come componente virtuale della mod Y, avranno necessità di installarlo.

Per la domanda, l'ingresso alla lista è sempre aperto a coloro che hanno l'account online e, a vedere la lista di ieri notte, le mod dovrebbero essere visibili.
Uso il condizionale perchè ieri in verità vedevo solo tre differenti versioni della stessa mod e c'è stata una discussione sulla possibilità o meno di vedere nella lista le mod non installate, ma non so quale decisione è stata presa.

Questo genere di curiosità ce le leveremo quando la beta è pubblica. :)

In ogni caso, un sito di riferimento (tipo rFC) sarebbe molto utile con il passare del tempo, in modo da poter aggiornare le mod installate (probabilmente con il sistema dei componenti virtuali) aggiugendo le piste via via che saranno rilasciate.
 
io sequel penso che per quanto riguarda le piste da aggiungere forse funziona cosi:
Facciamo un esempio con la Megane che uscira con rfactor 2,io vorrei fare un campionato,con tutte le piste disponibili comprese quelle storiche,dovro preparare il "pacco"con la Mod completa,delle suddette piste,e poi gli utilizzatori scaricheranno quello,non penso che gli utilizzatori dovranno scaricare anche la mod 1966(so che e gia compresa ma e un es.).
io ho capito cosi,spero di aver capito bene,poi bisogna toccare con mano e iniziare a smanettarci per capire il funzionamento,purtroppo stiamo facendo dei discorsi "virtuali",fino a CHE non USCIRA rFactor 2.




Babs
 
sequel said:
ecco che succede però una cosa, se una lega vuole fare un campionato con il mod GT (esempio) al cui interno ha per esempio 15 piste.. però la sfiga vuole che a questa lega queste piste non piacciono o non piacciono tutte.. allora trova altre 5 piste che (sempre per sfiga) sono in 5 altri mod diversi, in rF1 gli bastava prendere il mod e copiarci le 5 piste che gli interessavano senza altro peso, in rF2 deve far installare a tutti oltre al mod GT anche altri 5 mod dove per ognuno solo la pista serve ed il resto diventa peso e spazio inutili occupato sul disco.
Come vedi non è affatto detto che questo sistema faccia risparmiare spazio, in molti casi ne può far occupare molto di più, almeno così pare.
Click to expand...

Vabbè, in questo caso la lega creerà una mod con alcuni componenti "fisici" e altri virtuali.
Cioè, le piste che piacciono le lasci e le punti alla nuova mod (componenti virtuali) e le piste nuove le aggiungi come componenti "fisici", ottimizzando il peso della mod.
Non c'è necessità di scaricare e installare mod complete ... basta usare i componenti che servono. :)
 
~IsR~Barabba said:
io ho capito cosi,spero di aver capito bene,poi bisogna toccare con mano e iniziare a smanettarci per capire il funzionamento,purtroppo stiamo facendo dei discorsi "virtuali",fino a CHE non USCIRA rFactor 2.
Click to expand...

Si, il sistema già ora offre molteplici possibilità e via via diventerà sempre più flessibile a seguito delle richieste dei modder prima, dalle leghe in seconda battuta e infine degli utenti comuni.

Ci sarà da smanettare di sicuro, per prendere confidenza con il sistema e per ottimizzarne il modo di utilizzo.

E' vero che fino a che la beta non sarà pubblica andrà a mancare il terreno sotto i piedi, ovvero la possibilità di verificare le varie opzioni.
 
Io credo che, così com'è adesso, l'uso dei componenti virtuali sia efficiente solo con i componenti ufficiali ISI, cioè già presenti all'interno dell'installazione standard (e aggiornata) di rF2.

Usando le componenti ISI, non c'è bisogno di appesantire la MOD.

Credo di aver capito anche che il nuovo sistema sia rivolto all'eliminazione dei mismatch e non alla protezione dei contenuti.
 
Si, con le mod ISI sarà probabilmente conveniente usare quanti più componenti virtuali possibili e per quanto riguarda mod di terze parti è da vedere caso per caso.

Faccio un esempio: la lega X si fa un track pack di 40 piste e lo utilizza su qualsiasi mod. In questo caso il track pack potrebbe essere installato una sola volta ed essere usato come componente virtuale.

Oppure, se la mod X viene rilasciata con 16 piste, per aggiungerne altre potrebbe essere conveniente usare i componenti virtuali della versione precedente, aggiungendo via via le nuove piste come componenti "fisici".

Sono solo idee, possibilità ... poi vedremo in realtà quali sono le soluzioni migliori. :)

Si, l'obiettivo principale è eliminare i mismatch e rendere più fruibile, per tutti, l'uso online di rF2.
La protezione può avvenire tramite segnalazione di utenti scorretti, tramite crittazione ecc, ma non è l'obiettivo primario.
 
Ci sarà la possibilità di creare dei mod privati? Mi spiego meglio... i server possono risultare online con mod privati e quindi non sarà possibile scaricarli a meno che ai singoli players non siano assegnate le credenziali per l'accesso al server & download del mod? A mio parere sarebbe molto importante distinguere dei mod con server pubblici da mod privati per server privati. In caso contrario questo nuovo sistema di sviluppo sarebbe molto limitativo per chi utilizza mod privati e non abbia piacere che sia divulgato il proprio lavoro a chiunque.
 
Il sistema mi sembra interessante bisognerà vedere con la beta sottomano come funziona
anche se non capisco la necessità di legare piste e auto insieme come componente unico,
anche perchè mi pare che la maggior parte dei modders realizza o le piste o le auto.
Provo a fare delle ipotesi non so se giuste o meno:
una lega che voglia organizzare un campionato, scegliendo n. piste e n. auto fra quelle disponibili.
potrà o fare un mod ex novo copiando , se può, piste e macchine in un pacco unico e renderlo disponibile con ID etc.
oppure creare un mod con i contenuti virtuali ai mod che vuole e in teoria il nuovo mod non è altro che un file
con n. link ad altri a patto che tutti abbiano installato gli originali.
Tutto bene con pochi mod, dimensioni dell'installato elefantiache una volta che si sia a regime.
per le piste forse si può ovviare se ogni pista come auto a corredo fa riferimento ad una originale di rf2 che comunque tutti anno.
Poi con gli aggiornamenti sarà necessario rifare tutto ?
Pista pincopallo versione 001 a cui tanti fanno riferimanto viene aggoirnata dal suo modder i riferimenti valgono
automaticamente o c'è da rifare tutto?

molto interessante quando uscirà ci sara da smanettare parecchio e provare :)
 
Mi pare di aver capito, cosa che prima non era chiara, che le piste incluse in un mod che un modder ha fatto possono essere estrapolate e copiati in altri mod. Quindi non c'è solo la possibilità di usare materiali virtuali ma anche di copiare fisicamemente un componente (es. una pista) e includerlo in un'altro mod nuovo.. esattamente come si fa ora in rF.
Dico bene?

Questo cambierebbe non poco le cose perchè sennò come detto dopo poco tempo ogni utente si troverebbe diversi Giga di roba inutile sul proprio HD, esattamente l'opposto di quello che si vuole ottenerte.

Faccio inoltre notare che con rF non è raro che se si hanno installati molti mod e piste, l'intero rF è molto rallentato sia nel caricamento iniziale e sia nel gioco stesso.
Altra cosa che ora avviene con rF, e direi anche più grave, è che 2 piste o 2 mod fatti da modder diversi (caso tipico) vanno reciprocamente in conflitto e scatenano mismatch a non finire.
Non è un caso quindi che molti (noi compresi) facciamo installare per ogni evento o campionato lo strettissimo numero di piste indispensabili proprio per evitare questi strani conflitti.
Il sistema di rF2 di cui parliamo invece pare essere un incentivo all'installazione di molte piste o componenti rischiando gli identici problemi di rF1. Prendete questo come punto di attenzione.
 
Il sistema mi sembra interessante bisognerà vedere con la beta sottomano come funziona
anche se non capisco la necessità di legare piste e auto insieme come componente unico,
anche perchè mi pare che la maggior parte dei modders realizza o le piste o le auto.
Provo a fare delle ipotesi non so se giuste o meno:
una lega che voglia organizzare un campionato, scegliendo n. piste e n. auto fra quelle disponibili.
potrà o fare un mod ex novo copiando , se può, piste e macchine in un pacco unico e renderlo disponibile con ID etc.
oppure creare un mod con i contenuti virtuali ai mod che vuole e in teoria il nuovo mod non è altro che un file
con n. link ad altri a patto che tutti abbiano installato gli originali.
Tutto bene con pochi mod, dimensioni dell'installato elefantiache una volta che si sia a regime.
per le piste forse si può ovviare se ogni pista come auto a corredo fa riferimento ad una originale di rf2 che comunque tutti anno.
Poi con gli aggiornamenti sarà necessario rifare tutto ?
Pista pincopallo versione 001 a cui tanti fanno riferimanto viene aggoirnata dal suo modder i riferimenti valgono
automaticamente o c'è da rifare tutto?

molto interessante quando uscirà ci sara da smanettare parecchio e provare.
Click to expand...

Piste e vetture sono legate per evitare disagi a chi vuole entrare in un qualsiasi server.

Con il sistema di rF2 una volta che server e client hanno la mod con la stessa ID l'ingresso al server sarà sempre possibile.
Se piste e macchine non fossero legate ci sarebbe sempre la possibilità che il client non abbia le stesse piste.

I due casi che ipotizzi sono in realtà uno solo, cioè l'importante è la ID unica della mod (e della sua versione), poi se un modder preferisce inserire "fisicamente" tutti i componenti oppure usare componenti virtuali, rimane sempre il fatto di dover chiedere una SubmitID (processo automatico e istantaneo del sistema) in modo che la mod sia letta dal matchmaker.

La dimensione dell'installato, se i modder usano razionalmente il sistema, sarà pressappoco la stessa di rF.

Con gli aggiornamenti del software non sarà necessario reinstallare le mod, se invece una mod viene aggiornata questa dovrà una nuova identità di versione, ma a parte l'identità e il fatto di "comprimere" i files in un unico file del formato consentito, in pratica è la stessa cosa che accade con rF. :)

Se la pista X, che è componente virtuale della mod A B e C viene aggiornata, bisognerà aggiornare le mod, ma solo modificando il componente pista X.
 
sequel said:
Mi pare di aver capito, cosa che prima non era chiara, che le piste incluse in un mod che un modder ha fatto possono essere estrapolate e copiati in altri mod. Quindi non c'è solo la possibilità di usare materiali virtuali ma anche di copiare fisicamemente un componente (es. una pista) e includerlo in un'altro mod nuovo.. esattamente come si fa ora in rF.
Dico bene?

Questo cambierebbe non poco le cose perchè sennò come detto dopo poco tempo ogni utente si troverebbe diversi Giga di roba inutile sul proprio HD, esattamente l'opposto di quello che si vuole ottenerte.

Faccio inoltre notare che con rF non è raro che se si hanno installati molti mod e piste, l'intero rF è molto rallentato sia nel caricamento iniziale e sia nel gioco stesso.
Altra cosa che ora avviene con rF, e direi anche più grave, è che 2 piste o 2 mod fatti da modder diversi (caso tipico) vanno reciprocamente in conflitto e scatenano mismatch a non finire.
Non è un caso quindi che molti (noi compresi) facciamo installare per ogni evento o campionato lo strettissimo numero di piste indispensabili proprio per evitare questi strani conflitti.
Il sistema di rF2 di cui parliamo invece pare essere un incentivo all'installazione di molte piste o componenti rischiando gli identici problemi di rF1. Prendete questo come punto di attenzione.
Click to expand...

Si, infatti, i circuiti sono componenti e i componenti possono essere estrapolati.

Il rallentamento è difficile da valutare, nel senso che non ci sono mod a sufficienza per dire con certezza. :)
Però il rallentamento di rF dava fastidio a ISI (da programmatori del software) come dava fastidio all'utenza e sono convinto che rFactor2 carica i contenuti iniziali con una logica più razionale.
Inoltre parte dei tempi biblici di caricamento di rF sono dovuti a Trymedia e rF2 usa un sistema proprietario.
Su un rallentamento di gioco (con rF) causato dai giga installati però non posso confermare, nel senso che è la prima volta che lo sento dire. :)

I conflitti possono capitare si, c'è da augurarsi (un po' come è successo con rF) che l'esperienza insegni a non duplicare nomi dei files sensibili che causano, appunto i mismatches.
 
Un nuovo intervento di Gjon che aiuta a fare chiarezza
http://isiforums.net/f/showthread.p...nt-for-rFactor-2?p=19520&viewfull=1#post19520

Una volta che una ModID è creata solo il proprietario (l'assegnatario diciamo, l'utente che ha chiesto l'ID) può inserire nuove versioni.
Se una lega altera una mod per uso personale, questa diventa un nuovo "ramo", con una nuova ModID.

Come politica generale, ISI non farà da arbitrato. Caso per caso, tuttavia, ISI potrà intervenire per facilitare le parti a fare la cosa giusta.
 
prepariamoci quindi ad submit id a 6 cifre perché il bello di rF è stato quello di poter usare ogni auto su ogni circuito, ora per fare ciò sarà necessario un giorno si e l'altro pure creare un nuovo submit id del mod. Se non è un problema per gli ISI o modder penso non lo sia neanche per le leghe.

Altra cosa, qui stiamo parlando comporre mod ad alto livello ovvero prendo un mod, ci lego una pista nuova e quindi faccio il nuovo mod con legata la submit id del mod.. ma se io invece avessi intenzione di mettere mano alla pista, modificare texture, aggiungere posti, correggere bug (e Dio solo sa quanta roba bacata ed insospettabilmente bacata esiste in rF).. la domanda è, si potrà fare? Oppure a livello di componenti tutto sarà blindato? Idem per le auto, anche qui il lavoro degli 'aggiustatori' è notevole, lo potranno ancora fare o ci dovremmo accontentare del materiale bacato dei modder?

EDIT: letto ora il precedente post in cui si dice "Se una lega altera una mod per uso personale", si intende per caso quello che ho detto io? Ovvero lo devo leggere come
"Se una lega apre i file e ci mette mano dentro" ?
 
Non ci sono problemi nell'avere un gran numero di ID, anche se 999.999 effettivamente mi sembano tantine, ma, insomma, magari si arrivasse a queste cifre! :)

Per il momento la crittazione credo sia la stessa di rF, quindi non dovrebbe essere un problema intervenire sulle piste e su tutti i files di testo.
In futuro penso che blindare i files sarà una scelta dei singoli modders, ma non so a quale livello di blindatura ISI sta pensando.
 
Max Angelo said:
Per il momento la crittazione credo sia la stessa di rF, quindi non dovrebbe essere un problema intervenire sulle piste e su tutti i files di testo.
In futuro penso che blindare i files sarà una scelta dei singoli modders, ma non so a quale livello di blindatura ISI sta pensando.
Click to expand...
ok
speriamo solo che quando gli ISI decideranno per un sistema di blindatura tengano presente che i modder non sono solo quelli che creano ma anche quelli che sistemano e ottimizzano... :)
 
You must log in or register to reply here.
Back
Top