Visione d'insieme del sistema di packaging (by Scott)

Il post di Scott
http://isiforums.net/f/showthread.php/1402-A-packaging-overview...


Vorrei darvi una visione d'insieme di come è il sistema di packaging allo stato attuale.

Chi ha confidenza con la struttura di rF conoscerà la cartella \GameData e i suoi subfolders.
Anche, conoscerà la frustrazione di essere stato sbattuto fuori dai server a causa dei mismathes.

Il sistema di packaging è la nostra creazione per abbattere la pazzia dei mismatches, come pure un tentativo di impedire il cheating relativo ai contenuti.

I modders che vorranno creare mods per rF2, dovranno tenere presente che \GameData è stato sostituito da \ModDev (sviluppo mod).
La sua struttura rimane la stessa per quanto riguarda vetture e piste.
ModDev è dove saranno create e testate offline le mod di rF2, usando il DevMod all'interno della modalità "Developer" che sarà già presente nella beta.
In quest'area le cose funzioneranno nello stesso modo di rF.

Quando poi sarete pronti ad iniziare i test online dovrete applicare un numero di ModID (facile da fare e logicamente gratuita).
Appariranno nel matchmaker (la lobby) solo le mods che avranno una ModID.
I componenti (singole vetture o piste) non hanno bisogno di ModID

Quando il testing è concluso e siete pronti a rilasciare la mod alla comunità, dovrete applicare una SigID (identità firmata) che collega i contenuti della tua mod alla ModID.
Questo è il modo in cui è possibile verificare che la gente abbia installata la giusta mod in modo da poter entrare nei server e verificare che nessuno entri nei server con files alterati.
E' utile ripetere che i singoli componenti non richiedono ModID e SigID.

So che può sembrare un procedimento confusionario, ma in realtà non lo è.
Facciamo un esempio con una pista:

--- files sciolti di una singola pista in Location/pista. Questo ricorda rF1
--- files sciolti impacchettati in un mas. Di nuovo, i mas ricordano rF
--- mas sono impacchettati in un file di formato rfcmp e diventano un Component. Qui è dove le cose diventano nuove.
Ogni mas ha una sua unica signature (firma) e ogni cambiamento dei files nel mas va a cambiare anche la signature.

Quando vai a impacchettare questi mas in un component, anche il component va a prendere una sua propria identità firmata, e ogni cambiamento ai mas andrà anche a cambiare la signature del component.
Questo è il modo in cui possiamo garantire che il component combaci esattamente con lo stesso component del server.

A questo punto puoi rilasciare la pista (come component) singolarmente, o impacchettarla insieme ad altre piste e vetture in un file di formato rfmod, cioè quello delle mod complete.

Mentre offline potrete usare la serie All Cars and Tracks e utilizzare qualsiasi combinazione di auto e piste, solo i contenuti in formato rfmod possono essere usati online.
Diciamo ... volete correre online con una F1 su una serie di piste da kart (perchè dovreste volerlo nessuno lo sa).
Per farlo potete prendere i componenti che volete usare, impacchettarli in un file rfmod e rilasciarlo come mod.

Questo è basicamente come stanno le cose in questo momento.

E' possibile anche rilasciare Vrtual Mods con i componenti che volete usare, indicando le referenze dei componenti piste e vetture che avete istallate, ma senza includerli effettivamente, così che la taglia del download diventa piccolissima. E' però cura degli utenti assicurarsi di avere installati i componenti necessari.
Questo sistema è simile a quanto avviene con rF, con la differenza che validiamo il fatto che l'utente ha tutti i componenti richiesti dalla Virtual Mod, per poter entrare nel server.

Se un file rfmod contiene un componente già installato, non verrà installato come doppione e, se una mod viene disinstallata mentre una seconda mod usa lo stesso componente, questo non viene disinstallato, in modo da non intaccare quest'ultima.

Diciamo che siete un amministratore di lega e volete che i vostri pioti abbiano il necessario per la stagione che sta per iniziare.
Potreste fornire loro i componenti da installare e poi una virtual mod per la serie di gare.
Oppure potreste impacchettare ogni cosa e dare ai piloti un unico file onnicomprensivo.
Se dovete fare dei cambiamenti, basterà rilasciare un update che porti la vostra mod di lega dalla v1.0 alla v1.1.


Cmq modders, non siate preoccupati per il fatto che altri possano usare i vostri componenti in un rfmod non vostro.
Abbiamo in mente un modo per crittare i vostri componenti in modo tale che i contenuti non possano essere estratti.
Così, per esempio, potrete inserire crediti nello schermo del caricamento delle piste e in qualsiasi posto il vostro componente è utilizzato, così che gli utenti potranno vedere chi è il creatore del componente.
La crittazione non è ancora implementata, ma non dovtrebbe essere un lavoro troppo difficile.

Tante cose nuove da digerire e da assimilare, sono sicuro che il meccanismo, al momento, potrà risultare confusionario. Questo è OK, a me sono state necessarie due settimane per impadronirmi del sistema.
Adesso però non riesco a pensare di poter rilasciare conenuti in una maniera differente.
Oltretutto il sistema rende semplice la disinstallazione dei componenti, con un singolo click.

Credetemi, una vola che avrete fatto pratica e imparato il sistema, penso che capirete che è possibile avere più o meno la stessa libertà che in rF.
E, logicamente, vi ascolteremo cercando di trovare il modo di trovare soluzioni per situazioi atipiche.
Come tutto il resto di rF2, il sistema di packaging crescerà e maturerà come noi riceveremo più e più feedback dagli utenti.