dAbOTZ
07-08-2011, 17:01
The Elder Scrolls IV: Oblivion (http://www.theelderscrolls.com/)
Guida al Modding Estremo
PREMESSA
Perchè un altro thread sul modding di Oblivion? Perchè, senza voler togliere nulla all'utilità di quelli già presenti, dopo anni di test e continui aggiornamenti sia riguardo i mod manager sia riguardo gli stessi mod credo si senta il bisogno di svecchiare argomenti e procedure ormai obsolete e a volte controproducenti, che non potrebbero comunque essere aggiornabili nei thread attuali poichè gli autori originali sono spariti nel nulla o non sembrano essere interessati ad aggiornarli. Chi desidera limitarsi all'installazione di pochi ed essenziali mod si può comunque sentire lbero di fare riferimento ai thread esistenti. Chi invece come me ha interesse a portare il modding di oblivion a livelli estremi e vuole viaggiare felicemente con una media di 200 e più mod installati, prosegua la lettura.
Questo thread impone tre punti fermi elencati di seguito. Se non si è d'accordo nessuno se ne risentirà, significherà semplicemente che non è il thread che fa per voi.
A) Lasciate da parte tutti i preconcetti e dimenticatevi di tutto quello che sapete. Qua si ricomincia da zero.
B) La macchina su cui installerete il gioco moddato non dovrà necessariamente essere di ultimissima generazione, ma nemmeno vetusta. Il modding estremo di oblivion richiede molta pazienza, molto tempo ma soprattutto molte risorse hardware. Se sul vostro hardware Oblivion vanilla gira male dovete aspettarvi che pesantemente moddato giri peggio.
C) Le procedure elencate di seguito non sono per l'utente sbrigativo e che conta di far funzionare tutto subito. Non aspettatevi una cosa del tipo "scarico, installo il mod e gioco". Qui non funziona in questo modo. Sono necessari calma, tempo, pazienza e piena coscienza di quel che si sta facendo.
Questo thread non avrà mai la presunzione di ricoprire tutti i casi esistenti ma avrà lo scopo di guidarvi passo passo nell'uso degli strumenti necessari nell'obiettivo di darvi una buona base da cui iniziare, per poter poi aggiungere con calma quanto desiderate.
Nel primo post si parlerà di come Oblivion gestisce le risorse e degli strumenti necessari per preparare il modding, senza riferirsi strettamente a questo o quell'altro mod. Alla fine della lettura conto che non solo possiate sapere cosa state facendo ma anche perchè lo dovete fare in quel modo.
Saranno naturalmente ben accetti consigli su cosa modificare e/o migliorare.
NOTA BENE: i più esperti noteranno che a quanto illustrato sotto come verità rivelata esistono alcune eccezioni. Quando non ritenute necessarie ai fini della funzionalità del gioco vengono volutamente omesse per non generare confusione.
Parte I - COME FUNZIONA OBLIVION
Di m***a. Fine prima parte.
Ok, scherzavo :D
Oblivion è, nella sua forma originale [di seguito "vanilla"], uno dei giochi più bacati e instabili della storia. Le varie esperienze degli utenti e i vari test dei modder hanno evidenziato che la maggior parte dei problemi riscontrati quali crash, quest non completabili, difetti grafici e compagnia cantante sono dovuti non a problemi lato utente ma a tutta una serie di bug mai corretti da Bethesda, e che con ottime probabilità verrano ormai lasciati come sono. Fortunatamente l'estesissima comunità di modding non ha solo provveduto a migliorare le caratteristiche del gioco sfornando mod ad ogni piè sospinto ma ha anche risolto una miriade di bug grazie a patch non ufficiali. Pertanto ogni utente, anche quello che non ha alcun interesse a moddare il gioco, può trarre vantaggio dal modding di Oblivion.
Iniziamo con l'illustrare come funziona Oblivion vanilla, cosa che ci darà modo di capire perchè è così facilmente moddabile, dopodichè vedremo nelle parti successive come e con cosa modificare il tutto.
I.1 - Struttura file e directory
La struttura di Oblivion è fondamentalmente semplice: un solo eseguibile ed un insieme di risorse alle quali accede l'eseguibile tramite i riferimenti contenuti nei plugin. Vediamo cosa troviamo nelle varie directory del gioco:
Il file oblivion.exe in Directory Installazione\oblivion
L'eseguibile principale contenente il codice necessario ad accedere alle risorse tramite l'interpretazione dei file esm ed esp.
Il file oblivion.ini in Directory utente\Documenti\My Games\Oblivion
Come dice l'estensione si tratta del file di inizializzazione. Contiene parecchi parametri necessari per istruire l'eseguibile riguardo le impostazioni relative a grafica, audio, controlli, etc. Non viene rimosso in seguito a disinstallazione del gioco.
I file .bsa in Directory Installazione\oblivion\data
Acronimo di Bethesda Softworks Archive, è il formato storico dei file archivio di Bethesda, contenenti le risorse quali meshes, texture, suoni, etc., strutturate all'interno dell'archivio in una serie di sottodirectory di nome meshes, sound, textures e così via. Sono referenziati sia dagli ESM sia dagli ESP.
I file .esm in Directory Installazione\oblivion\data
Acronimo di Elder Scrolls Master, si tratta dei file che contengono i dati sulla struttura degli ambienti interni ed esterni, gli script delle quest vanilla, gli script per l'interazione con personaggi ed oggetti, e più in generale ogni dato utile per far funzionare il gioco, all'infuori di modelli, texture e suoni. Nel vanilla esiste il solo oblivion.esm e non è modificabile in nessun modo con gli strumenti di modding. Il motivo è semplice: Bethesda ha limitato la modifica ai soli file ESP in modo che nessun modder possa andare a lamentarsi con loro se gli funziona male un gioco che lui stesso ha distrutto : )
MOD particolarmente impegnativi per il gioco come Nehrim e OOO dispongono di ESM propri, per via del fatto che il gioco sembra avere seri problemi con ESP superiori a certe dimensioni e per via di un bug di visualizzazione che affligge gli ambienti esterni quando modificati pesantemente.
I file .esp in Directory Installazione\oblivion\data
Acronimo di Elder Scrolls Plugin, si tratta di fatto dei medesimi file di cui sopra ma con la differenza di essere completamente modificabili tramite gli strumenti di modding. Sono i file che vengono creati dai modder tramite il Construction Set per istruire l'eseguibile ad accedere a tutta una serie di risorse personalizzate quali nuove armature, nuove armi, nuovi personaggi o a modificare quanto contenuto negli esm senza intaccare il contenuto dell'esm originale. Utile ad esempio per modificare la posizione di una casa contenuta in un esm senza dover modificare l'esm che la contiene o, tramite script, variare l'esito di una quest vanilla. Esp e plugin sono tendenzialmente termini intercambiabili. Il termine mod è invece preferibile per indicare la totalità delle risorse del mod, quindi non solo l'esp ma eventuali texture e meshes che vengono distribuite con l'archivio del mod del caso.
I file .ess in Directory utente\Documenti\My Games\Oblivion
Acronimo di Elder Scrolls Save, nient'altro che i file di salvataggio. Non vengono rimossi in seguito a disinstallazione del gioco.
La directory Directory Installazione\oblivion\data
La directory fondamentale di ogni mod user che si rispetti : )
Nel vanilla è quasi vuota poichè quasi tutto il necessario è nei BSA ma, una volta moddato il gioco, si popolerà con varie sottodirectory aventi la medesima struttura interna dei file BSA che contengono le risorse, ovvero texture, meshes, sound, etc. I file risorsa contenuti sotto \data vengono in gergo definiti loose file [file sparsi] ed ogni mod ne può contenere da uno fino a diverse migliaia. Il gioco carica i loose file secondo i seguenti principi:
se il loose file da caricare ha l'obiettivo di rimpiazzare un file preesistente nella struttura dei BSA, esso deve:
avere lo stesso nome del file originale contenuto nel BSA
trovarsi nella sottodirectory di \data corrispondente alla directory del BSA che contiene il file originale
essere più recente del BSA che contiene l'originale
Ad esempio una texture customizzata ad alta risoluzione che deve rimpiazzare quella vanilla del BSA lo può fare solo se è più recente del BSA.
se il loose file da caricare non si basa su nessun file preesistente l'unico modo per caricarlo è tramite un ESP nel quale verrà indicato il suo percorso.
Ad esempio una nuova spada della quale non vi è nessuna traccia nei BSA vanilla, nè a livello di meshes nè a livello di textures, richiederà un ESP tutto suo del tipo MiaSpadonaTroppoFiga.esp, che indicherà al gioco di caricare i loose file necessari.
Il caso 1 soffre di un noto bug del gioco che causa il mancato caricamento dei loose file, problema risolvibile tramite un hack di nome Archive Invalidation, del quale nel corso degli anni ne sono state escogitate diverse varianti. Vedremo più avanti qual è la più affidabile.
I.2 - Avvio del gioco
La procedura di avvio di Oblivion è sommariamente la seguente:
lettura oblivion.ini
verifica ESM in ordine di data
verifica BSA a cui puntano gli ESM
verifica loose file a cui puntano gli ESM
verifica ESP in ordine di data
verifica BSA a cui puntano gli ESP
verifica loose file a cui puntano gli ESP
visualizzazione menu principale
selezione salvataggio da parte dell'utente e verifica ESS
caricamento ESM + ESP in ordine di data
caricamento BSA a cui puntano gli ESM
caricamento loose file a cui puntano gli ESM
caricamento BSA a cui puntano gli ESP
caricamento loose file a cui puntano gli ESP
caricamento ESS
Niente di particolarmente complicato ma và da sè che se uno degli step di cui sopra non va a buon fine, ad esempio perchè è assente un loose file referenziato da un ESP, il gioco agirà in maniera alquanto bizzarra generando ogni sorta di anomalia grafica e di gameplay.
Notiamo una cosa importante: il check e il caricamento degli ESM e degli ESP viene sempre eseguito in ordine di data dei file, dando priorità agli ESM. Prima vengono caricati tutti gli ESM in ordine di data, a seguire tutti gli ESP, anch'essi in ordine di data. E' il modo in cui il gioco decide l'ordine di caricamento dei file, dando priorità al plugin che viene caricato dopo, ed è essenziale per il suo corretto funzionamento: quando due o più mod modificano la stessa entità, come nel caso di due mod che modificano la potenza di una medesima arma o le caratteristiche di un medesimo edificio, va deciso a quale dei due si debba lasciare la priorità. Si parla in questo caso di conflitto controllato, la cui errata gestione tramite un ordine di caricamento errato può al massimo dare problemi a livello di gameplay. Quando invece due mod fanno due cose concettualmente opposte si parla di conflitto indesiderato: è il caso di un mod A che elimina un'arma dal gioco e un mod B che le assegna una potenza differente dal vanilla. Se il mod B viene caricato dopo il mod A il gioco andrà in crash poichè l'ESP del mod B tenterà di fare riferimento ad un'arma che in quella istanza del gioco non esiste più.
Il secondo caso è una delle cause principali dei crash di Oblivion: il gioco non è in grado di ignorare i conflitti indesiderati tralasciando gli errori causati dai conflitti fra i mod. L'ho messo in grassetto poichè si tratta di un concetto chiave col quale si rischierà di scontrarsi più e più volte e va ben compreso prima di gettarsi nell'installazione folle di una moltitudine di mod senza comprendere a fondo cosa si propongano di modificare.
Fortunatamente da diverso tempo esiste BOSS , uno strumento per riordinare automaticamente gli ESP senza alcuna fatica. Che in gran parte si limita comunque a riordinare i mod secondo la filosofia del conflitto controllato, non può fare molto per i conflitti indesiderati poichè date le migliaia di mod disponibili nessuno è in grado di stabilire a priori se siano liberi da conflitti indesiderati fra loro. Ragion per cui prima di installare un mod è buona abitudine leggerne sempre la documentazione per sapere se l'autore ha già individuato conflitti con altri mod.
I.3 - Ambiente di gioco
Oblivion gestisce l'ambiente in cui ci muoviamo tramite celle di dimensione predeterminata [4096 x 4096 unità, che si traducono in circa 3600mq]. Una mappa completa della provincia di Cyrodiil, divisa per celle, è visibile qui (http://www.tesnexus.com/downloads/images/23939-1-1240451419.jpg). Si possono notare i confini della provincia contornati in marrone. Gli ambienti interni non fanno eccezione, anch'essi sono a volte suddivisi in celle quando ne viene superata la dimensione.
Il plugin oblivion.esm contiene tutte le caratteristiche esterne ed interne della provincia di Cyrodiil, che viene costruita referenziando i vari BSA che contengono le risorse necessarie a comporre gli ambienti nelle varie celle. Ad esempio, Oblivion - Meshes.bsa contiene la forma di una roccia; Oblivion - Textures - Compressed.bsa contiene le sue texture; Oblivion - Sounds contiene il suono dei passi quando ci camminiamo sopra. In oblivion.esm si decide in quali e quante celle va posizionata quella roccia. Ragion per cui ci imbattiamo spesso in rocce identiche, mobili identici, architetture identiche, persone identiche. Sono tutte copie di quanto contenuto nei BSA e referenziato più volte negli ESM o ESP, combinato in maniera più o meno abile per dare una parvenza di unicità.
I mod funzionano secondo il medesimo principio. I vari ESP generati nel Construction Set referenziano i contenuti dei BSA riutilizzandoli alla bisogna e senza la necessità di reinventare la ruota ogni volta: tutto il necessario è contenuto nei BSA, basta costruire gli ambienti componendone i vari pezzi. Una dovuta eccezione è data dai mod che introducono nuove risorse, ovvero modelli e texture che in Oblivion Vanilla non esistono. Come ad esempio Martigen's Monster Mod che introduce tutta una serie di nuove creature, le cui meshes e texture per comodità degli autori sono state compresse in un unico enorme BSA di centinaia di Mb, per poi essere referenziate da ESM ed ESP in modo che il gioco possa caricarle correttamente.
Sulla carta è tutto molto bello e funzionale. Purtroppo il motore che muove il gioco e ne controlla il funzionamento è estremamente bacato, pesante e ben poco ottimizzato per le macchine odierne. Per dirne una, non vi è nessun supporto per il multicore, sebbene alcuni parametri presenti in oblivion.ini portino a pensare che almeno in una fase iniziale risultasse previsto. Non c'è nessun supporto nativo al Large Address Aware nè tantomeno supporto ai sistemi 64bit, ragion per cui oblivion.exe va sistematicamente in crash superato un certo impegno di ram di sistema [per la cronaca 1.8Gb]. Non c'è nessun sistema di prevenzione dei crash in caso di errata referenziazione risorse. Apparentemente il sistema di buffer purging delle celle è bacato, ragion per cui quando girovagando si cambia cella ci si porta dietro anche i riferimenti della precedente, cosa che impegna risorse inutilmente. Non c'è nessun sistema per controllare dinamicamente le prestazioni, liberando tempo CPU per gli script. A causa di tutto ciò un Oblivion pesantemente moddato è, ad oggi, probabilmente il gioco più pesante esistente.
Fortunatamente la gran parte delle magagne di cui sopra è stata col tempo risolta dalla comunità di modder grazie ad una serie di artefizi che vedremo nella Parte III: installazione base.
Ora è tempo di illustrare gli strumenti a nostra disposizione.
Parte II - GLI STRUMENTI PER IL MODDING
Nella prima parte abbiamo visto come funziona Oblivion e come gestisce risorse e plugin. Ora continuiamo con la teoria illustrando quali strumenti abbiamo a disposizione per aggiungere e gestire i vari mod, senza addentrarci nella spiegazione passo passo del loro utilizzo. Questo sarà il compito della terza parte - Installazione base - e della quarta parte - Rifinire l'installazione - per poi concludere la nostra guida nella quinta parte - I mod consigliati. Quest'ultima parte per quanto possibile verrà costantemente aggiornata.
II.1 - L'installazione dei mod
Bethesda non ha mai fornito nessuno strumento utile per l'installazione dei mod. La comunità si è pertanto dovuta arrangiare sviluppando autonomamente strumenti propri quali OBMM e Wrye Bash per poter gestire agevolmente installazioni più o meno pesantemente moddate.
I mod vengono solitamente distribuiti in formato compresso rar, zip, 7z, OMOD ed exe. I primi tre direi non richiedano spiegazioni. Il quarto è il formato nativo di uno dei primi tool ad essere usciti per Oblivion: il mod manager OBMM [OBlivion Mod Manager], oggi reso obsoleto da Wrye Bash ma ancora molto diffuso fra gli utenti sia per la sua semplicità d'uso sia perchè numerosi mod vengono ancora oggi distribuiti in formato OMOD. Il formato exe è tipico dei rari mod forniti con installer.
Vediamo ora i principali metodi di installazione:
Installazione manuale
I mod forniti nei comuni formati di compressione possono essere semplicemente scompattati nella directory del gioco, per poi abilitare gli eventuali ESP dalla sezione Data Files dell'Oblivion Launcher. Si tratta di un metodo caldamente sconsigliato poichè non permette di tenere traccia agevolmente di cosa si è installato dove, nè di eventuali conflitti di risorse fra diversi mod. L'utente che segue questa strada deve essere cosciente che tale tipologia di installazione andrebbe limitata a pochi e conosciuti mod. Questo metodo non verrà ulteriormente esposto in questa sede.
Installazione tramite installer
Come sopra. I mod forniti con installer sono rari e alla pari dell'installazione manuale non permettono di tenere traccia dei conflitti di risorse, pur permettendo una più agevole disinstallazione dei mod rispetto all'installazione manuale. Anche questo metodo non verrà ulteriormente esposto in questa sede.
Installazione tramite OBMM
Il primo mod manager creato per Oblivion ed attualmente il più diffuso, sebbene il suo sviluppo si sia arenato da tempo. Una volta installato, OBMM permette di installare il mod agevolmente tramite poche operazioni sul file OMOD scaricato. Oltre alla possibilità di decidere l'ordine di caricamento degli ESP possiede un sistema per evidenziare eventuali conflitti di risorse, quali meshes e texture, fra mod diversi. La sua semplicità d'uso è ben nota ma soffre di gravi problemi risolti dal più efficiente Wrye Bash. Spiegamoli con degli esempi:
installiamo MOD A che contiene un pacchetto di texture aggiornate per ambienti esterni ed interni
scoviamo MOD B che contiene anch'esso un pacchetto di texture aggiornate, ma sono limitate alle caverne. Ci piace e lo installiamo, sovrascrivendo le texture delle caverne del MOD A
tutto funziona correttamente. Abbiamo le texture ambientali aggiornate da MOD A, e le texture delle caverne aggiornate dal MOD B
MOD B non ci piace più e decidiamo di disinstallarlo
le texture di MOD A che hanno lo stesso nome e percorso di quelle di MOD B vengono completamente rimosse senza che OBMM si opponga minimamente, perchè vede quei file come facenti parte del MOD B che gli abbiamo detto di disinstallare. Di conseguenza non solo abbiamo disinstallato MOD B ma abbiamo anche corrotto l'installazione di MOD A senza che OBMM abbia segnalato alcunchè! La reinstallazione di MOD A risolverebbe il problema ma l'utente non può saperlo.
Simile scenario accade se decidiamo di disinstallare MOD A poichè troppo pesante, e decidiamo di tenere solo le texture delle caverne del MOD B. L'operazione elimina TUTTI i file di MOD B, e anche in questo caso l'utente non ne sa nulla.
Questo è il banale scenario per quanto riguarda due semplici texture pack. Vi lascio immaginare cosa succede durante la disinstallazione di un mod che condivide dei modelli di creature con un altro mod. I casi di cui potete leggere in rete riguardo texture assenti e sostituite da una texture fucsia, i casi riguardo punti esclamativi comparsi qua e là e più in generale i casi dove nel gioco manca qualcosa sono con buona probabilità causati da disinstallazioni di mod eseguite tramite OBMM.
Vediamo un caso più subdolo:
installiamo MOD A che modifica la potenza di una particolare spada
installiamo MOD B che modifica la portata della medesima spada
nel gioco solo UNA delle due caratteristiche comparirà, dipendentemente dall'ESP che viene caricato dopo, che eliminerà completamente le caratteristiche del precedente per via della particolare gestione da parte di Oblivion di ESP che modificano le caratteristiche di una medesima entità. OBMM non è in grado in nessun modo di gestire conflitti di questo tipo.
I casi di cui sopra sono solo due dei motivi per cui OBMM [pur rispettando il suo storico valore] verrà evitato come mod manager principale, salvo per esigenze molto particolari che illustreremo più avanti. Il nostro mod manager principale sarà Wrye Bash.
Installazione tramite Wrye Bash
Wrye Bash ha una storia difficile. Lo sviluppatore originale ha abbandonato il progetto più di due anni fa, dopo aver sfornato un programma estremamente efficiente ma con un'interfaccia grafica quasi interamente a drop-down menu e non esattamente user-friendly. L'attuale team di sviluppo ha aggiornato l'interfaccia rendendola più semplice da utilizzare ma ha conservato lo spirito della originale. Pertanto l'utente medio può facilmente trovarsi spiazzato dalla miriade di opzioni disponibili. Wrye Bash, che richiederebbe un thread a sè, verrà illustrato con sufficiente profondità nella terza parte di questa guida. Nel frattempo ci limitiamo ad esporre i suoi principali punti di forza:
nessun file OMOD necessario. Per l'installazione del mod del caso si usa direttamente il file compresso scaricato
ordine di installazione modificabile in tempo reale. I mod che vengono installati nell'ordine errato possono essere spostati agevolmente in altra posizione, al resto penserà WB riallineando file e directory dove necessario
visualizzazione in tempo reale dei conflitti di risorse fra mod e organizzazione mod per genere
gestione ESP conflittuali per abilitare le caratteristiche di due mod che modificano gli stessi record tramite la funzione Bashed Patch
costantemente in aggiornamento
Nel corso della Parte III - Installazione base - illustreremo passo per passo l'uso di Wrye Bash.
II.2 - Il riordinamento automatico dei plugin
Lo spartano Oblivion Launcher permette di selezionare quali ESP abilitare o disabilitare dalla sezione Data Files ma non fornisce alcuna indicazione utile sull'ordine di caricamento. Tutti gli ESP vengono semplicemente elencati in ordine alfabetico, che non è l'ordine con cui verranno caricati poichè fa sempre fede la data del file, dal più vecchio al più recente. L'utilità del Launcher si ferma all'abilitazione dei DLC di Bethesda, ovvero le espansioni come Shivering Isles e Knights Of The Nine più i vari plugin minori come Horse Armor e Spell Tomes. Se ci si limita ad essi non vi è sostanzialmente nessun problema, i plugin della casa madre sono risultati liberi di conflitti fra loro e possono essere caricati senza problemi nel predefinito ordine determinato dalla loro data di creazione. Aggiungere ulteriori plugin senza poterne stabilire l'ordine di caricamento significa invece andare incontro ad un sacco di grane.
Riprendiamo a questo proposito il tema dell'ordine di caricamento anticipato nella parte I e vediamo con un esempio tangibile perchè sia così importante. Di seguito l'elenco dei plugin contenuti nell'edizione GOTY di Oblivion, elencati in ordine di caricamento:
Oblivion.esm
DLCShiveringIsles.esp
DLCHorseArmor.esp
DLCOrrery.esp
DLCVileLair.esp
DLCMehrunesRazor.esp
DLCSpellTomes.esp
DLCThievesDen.esp
DLCBattlehornCastle.esp
DLCFrostcrag.esp
Knights.esp
Come detto non esistono conflitti fra i plugin dei DLC e il loro ordine di caricamento non è strettamente importante se sono gli unici ad essere installati. Ma cosa succede quando viene installato un ulteriore plugin che va a referenziare le stesse risorse di un plugin esistente o ne modifica gli stessi record? Uno dei primi e più acclamati mod è stato Frostcrag Reborn [la cui installazione è oggigiorno non consigliabile causa una nota serie di conflitti con le Unofficial Patch], il cui plugin Frostcrag Reborn.esp è stato creato ovviamente dopo DLCFrostcrag.esp e quando installato va dilingentemente ad ordinarsi dopo il DLC originale. In questo modo Frostcrag Reborn, il cui obiettivo è estendere il plugin originale aumentando le dimensioni della torre del mago e aggiungendo nuove quest, funziona come previsto: va a modificare dei record preesistenti nel plugin originale, ad esempio aumentando le dimensioni un'area o spostando del mobilio, e il gioco non può far altro che obbedire agli ordini modificando quanto necessario secondo le istruzioni contenute nel plugin Frostcrag Reborn.esp. Ora, ipotizziamo che per qualche strano motivo la data di DLCFrostcrag.esp risulti successiva a quella di Frostcrag Reborn.esp. Quest'ultimo verrebbe erroneamente caricato prima, e farebbe riferimento a dei record che in quella istanza del gioco non esistono ancora. Nella migliore delle ipotesi all'ingresso nella torre ci aspetterebbero ogni sorta di anomalie grafiche. Nella peggiore, il gioco andrebbe in crash.
L'esempio di cui sopra ci fa realizzare un aspetto importante dell'interazione fra i diversi mod: prima che fosse globalmente ben chiara l'importanza dell'ordine di caricamento numerosi plugin han funzionato al primo colpo per diversi utenti semplicemente perchè sono stati creati successivamente a plugin che interagivano con le stesse risorse, pertanto la loro data di creazione è risultata necessariamente successiva alla data dei plugin esistenti e il caricamento avveniva in ordine corretto senza che lato utente fosse necessaria alcuna operazione. In sostanza i plugin funzionavano benone ma non tutti avevano piena coscienza del perchè.
Con l'evoluzione della comunità di modders e la diffusione di centinaia e a seguire migliaia di plugin il problema si è col tempo ingigantito e gli utenti hanno iniziato ad avere seri problemi nel coordinare il funzionamento dei vari plugin. OBMM e Wrye Bash possiedono una funzione integrata per decidere l'ordine di caricamento degli ESP, di fatto semplicemente cambiando la data dei file, ma non dispongono di nessuna funzione per riordinare automaticamente gli ESP secondo i dettami della comunità. A questo fortunatamente ci pensa il BOSS citato nella prima parte, un gran bel pezzo di software che scansiona tutti gli ESP presenti nella directory \data, li confronta con una masterlist online costantemente aggiornata e riordina gli ESP in locale variandone la data dove serve.
Nel corso della Parte III - Installazione base - illustreremo il semplice uso di BOSS.
II.3 - La pulizia dei plugin
Il TES Construction Set TESCS o, come è meglio conosciuto, semplicemente CS] è purtroppo un software estremamente scadente. E' instabile, macchinoso, ha un'interfaccia grafica che fa rimpiangere lo SCO Open Desktop e la sua complessità è spesso fonte di una miriade di errori involontari da parte del malcapitato modder. Fra questi errori ci sono quelli comunemente conosciuti come wild edits e dirty edits, che possono essere risolti tramite il programma Tes4Edit.
I wild edits sono dovuti all'inesperienza del modder e consistono in modifiche involontarie di entità che non dovrebbero essere minimamente coinvolte dal mod. Prendiamo l'esempio di un altro nostro mod AltraMiaSpadonaTroppoFiga.esp. Il mod si propone di modificare le caratteristiche di una spada rinvenuta in una tomba nel profondo di un dungeon assegnandole una potenza mai vista, e lo fa modificando il record della spada originale invece della sua referenziazione contenuta nella tomba. Errore. TUTTE le spade di quel tipo nell'intero gioco verranno coinvolte dalla modifica. Non che sia un gran problema ma non è sicuramente quanto il mod si proponeva di fare. Il metodo corretto è modificare la copia di quella spada, ovvero la sua referenziazione dell'oggetto originale contenuta nella tomba, senza alterare l'entità originale contenuta in oblivion.esm. I wild edits non sono identificabili automaticamente da nessun software, poichè non esiste un modo per stabilire a priori quali fossero gli obiettivi del modder. Per quel che ne si sa la modifica di tutte le spade dello stesso tipo nell'intero gioco potrebbe anche essere intenzionale. In linea di massima i rari wild edits incontrabili sono caratteristica di modder inesperti e non inficiano comunque la stabilità del gioco, al massimo scombinano il gameplay con eventi bizzarri e indesiderati. Nel caso si riscontrasse un'anomalia nel gameplay e la si sospetti dovuta ad un mod la strada migliore da seguire è segnalarla all'autore. Questa stessa guida non darà alcuna indicazione sulla risoluzione dei wild edits per due motivi: primo, si tratta per lo più di retaggio di mod vetusti e/o scritti da modder inesperti; secondo, la risoluzione dei wild edits richiederebbe un intero thread a parte. In buona sostanza il gioco non vale la candela.
I dirty edits sono dovuti principalmente sia a distrazione sia alla complessità del CS, che porta facilmente a commettere errori. Ne esistono di due tipi:
ITM - Identical To Master. Si tratta di entità presenti nel plugin master [solitamente oblivion.esm] che sono state modificate in qualche modo per poi essere ripristinate alle caratteristiche originarie. E' il caso di una spada la cui potenza base viene modificata, per poi essere riportata ai valori originali poichè il modder ha cambiato idea. Il CS non interpreta quest'ultima azione come un annullamento undo] ma come una modifica a tutti gli effetti da registrare nell'ESP. Ragion per cui l'ESP aumenta inutilmente di dimensioni, inoltre il gioco si troverebbe a gestire un inutile ed evitabile conflitto nel caso un altro mod modifichi le caratteristiche della medesima spada.
DR - Deleted Reference. Si tratta di entità presenti nel plugin master [solitamente oblivion.esm] che sono state cancellate per qualche ragione dal mod. Errore. Le entità dei master non si cancellano mai, si disabilitano. Non è in realtà possibile cancellarle dal master oblivion.esm, nel senso che nulla può essere modificato nel file originale, ma Oblivion le considererà rimosse in quella tale istanza del gioco. Pertanto se per qualche motivo viene rimossa dal gioco una spada alla quale fa riferimento anche un altro mod Oblivion andrà in crash quando caricherà la cella che la contiene.
Appare chiaro che la pulizia dei plugin sia un'operazione necessaria per garantire la stabilità del gioco. Fortunatamente il software BOSS per riordinare i plugin ha anche la possiblità di individuare i plugin "sporchi" fra quelli installati e ce li segnalerà prontamente, senza che li si debba controllare manualmente uno ad uno. La pulizia si esegue con pochi click grazie al programma Tes4Edit, che si incarica sia di rimuovere completamente gli inutili ITM sia di bonificare i pericolosi DR convertendoli in UDR ripristinando il record originale come necessario al gioco per poi disabilitarlo come richiesto dal mod.
Volete ridere? ANCHE i plugin dei DLC di Bethesda contengono dei dirty edits, e van puliti alla pari degli altri mod. Questo dovrebbe farci realizzare quanto complicato sia l'utilizzo del CS persino per gli stessi sviluppatori che l'hanno creato.
Nel corso della Parte IV - Rifinire l'installazione - illustreremo l'uso di Tes4Edit.
II.4 - L'ottimizzazione delle meshes
Oblivion usa meshes [gli "scheletri" dei modelli in 3D] in formato NIF [Net Immerse File], dal nome del motore grafico NetImmerse antenato del motore GameBryo utilizzato dal gioco. Il formato di per sè non è completamente aperto riguardo la licenza ma le sue specifiche sono note da anni e diversi programmi di modellazione 3D possono aprirlo senza problemi. Fra i programmi in grado di manipolare le meshes esiste PyFFI [Python File Format Interchange], un'utility sviluppata per ottimizzare le meshes rimuovendone i nodi vuoti o duplicati generati da errore umano o da bug del software di modellazione, che pur dovendo essere gestiti dal motore grafico non aggiungono assolutamente nulla in termini di qualità. Di conseguenza è vero anche l'opposto: la rimozione dei dati inutili, pur mantenendo inalterata la qualità visiva, aumenta le prestazioni del motore. Non aspettiamoci miracoli, comunque: si parla di pochi fps, ma avendo a che fare con un motore poco ottimizzato come quello di Oblivion ogni piccola miglioria è sempre la benvenuta.
Per ottimizzare le meshes del gioco sarà prima necessario scompattarne l'originale archivio Oblivion - Meshes.bsa per poi ottimizzarlo con PyFFI [operazione che potrà durare diverse ore] e ricompattarlo nuovamente in formato BSA. Per l'operazione sarà necessario utilizzare un tool di estrazione e creazione BSA, integrato in OBMM, più il software PyFFI per l'ottimizzazione, il quale richiede necessariamente l'installazione di Python.
Nel corso della Parte IV - Rifinire l'installazione - illustreremo l'uso di PyFFI.
Parte III - INSTALLAZIONE BASE
Nella seconda parte abbiamo illustrato i principali strumenti per il modding. Ora impareremo ad usarli, e mano a mano che proseguiremo con la configurazione di Oblivion e degli strumenti per moddarlo aggiungeremo altri software non ancora citati ma estremamente utili. La presente guida si applica a più o meno qualsiasi tipo di installazione di Oblivion, sia essa eseguita da DVD o via Steam, sia essa limitata al solo Oblivion o includente i DLC dell'edizione GOTY. L'unica installazione non supportata dalla guida è la Direct2Drive poichè non è in grado di avviare l'essenziale OBSE. Dove necessario saranno indicati i diversi passi da seguire a seconda del tipo di installazione. Prima di eseguire i passi della guida in tempo reale vi suggerisco di darle una lettura in modo da avere ben chiari tutti i punti.
Pronti? Chiudetevi in casa, mettete fuori il gatto, dite alla fidanzata di uscire con le amiche e staccate il telefono. Avete bisogno di una serata tutta per voi. Si comincia!
III.1 - L'installazione di Oblivion vanilla
Ok, come prima cosa disinstallate Oblivion.
Sì, avete letto bene. Ignoro ovviamente in che stato si trovi la vostra attuale installazione di Oblivion, pertanto posso dare garanzie sui risultati della presente guida solo se le sue istruzioni vengono eseguite su una macchina vergine. Del resto eravate stati avvertiti: qua si ricomincia da zero ; )
Sta a voi decidere cosa fare della vostra attuale installazione e decidere se seguire o no la guida su un'installazione vergine, ma è bene che sappiate che è straconsigliato partire davvero da capo.
Nota per utenti Steam: per evitare di scaricare Oblivion da capo è sufficiente eseguirne un backup dalla apposita funzione integrata, per poi ripristinarlo in seguito. Il backup si limiterà a file e directory predefiniti, senza copiare eventuali mod già installati, quindi avrete la garanzia di un'installazione pulita. La disinstallazione di Oblivion si esegue sempre da Steam stesso.
Rimuovete ogni mod manager, scordatevi ogni utility che potreste aver già installato, eventualmente fatevi un backup dei salvataggi presenti in Directory utente\Documenti\My Games\Oblivion\Saves, dopodichè eradicate completamente Oblivion dal vostro sistema. Successivamente assicuratevi di cancellare la directory Directory Installazione\oblivion\ e Directory utente\Documenti\My Games\Oblivion\. A disinstallazione completata riavviate il sistema e lanciate più volte la pulizia registro dell'utility Ccleaner (http://www.piriform.com/CCLEANER) per rimuovere ogni chiave lasciata per strada.
Ora siamo pronti ad installare Oblivion.
A qualunque tipologia di installazione vi affidiate i risultati cambiano poco. Ad eccezione della Direct2Drive qualunque versione di Oblivion è moddabile su qualunque sistema operativo supportato nativamente dal gioco. Quel che è importante sapere è che su Vista e Seven [e in futuro con ottime probabilità anche su Windows 8] la directory di installazione non deve essere quella predefinita. Il motivo è dovuto al UAC, che impedisce la corretta installazione dei mod nella directory c:\program files anche a UAC disabilitato. Scegliete dunque una directory al di fuori di c:\program files, come ad esempio c:\Oblivion o c:\giochi\Oblivion.
Nota per utenti Steam: nessun gioco di Steam può essere installato all'esterno delle sue directory, pertanto l'unico modo per poter installare Oblivion al di fuori di c:\program files, dove viene installato Steam per impostazione predefinita, è spostare Steam, ad esempio sotto c:\Steam o c:\giochi\Steam. La procedura corretta è qui (https://support.steampowered.com/kb_article.php?ref=7418-YUBN-8129). Quando avrete terminato potrete proseguire con la guida.
Inseriamo il DVD o, nel caso di utenti Steam, apriamo steambackup.exe contenuto nella directory di backup di Oblivion precedentemente selezionata e seguiamo i passi per l'installazione. Al termine dell'installazione sarà necessario scaricare e installare le patch ufficiali da qui (http://www.bethsoft.com/eng/downloads_01.html). Assicuratevi di scaricare ed installare le patch corrispondenti alla vostra versione. Non avviate ancora il gioco, non è ancora il momento. Abbiamo ancora qualche passo da seguire.
Nota per utenti Steam: nessuna patch va scaricata dal sito Bethesda. Tutto il necessario è già incluso in quanto avete scaricato e installato.
Prima di avviare il gioco facciamo un giretto nelle directory, per avere un'idea chiara dell'aspetto di un Oblivion vergine. Fotografate mentalmente quel che vedete, vi sarà utile per capire cosa accade durante l'installazione dei vari mod. Notiamo innanzitutto che la directory Directory utente\Documenti\My Games NON contiene una directory Oblivion. E' normale, verrà creata solo durante il primo avvio del gioco. Spostiamoci nella directory Directory Installazione\oblivion\ e osserviamone il contenuto. La struttura di un Oblivion vanilla corrisponde sommariamente a quanto segue, dipendentemente dalla presenza o meno delle due espansioni ufficiali Shivering Isles e Knights Of The Nine e i vari DLC. In grassetto le directory, in carattere normale i file:
\oblivion:
Data
Directx
Oblivion.exe
OblivionLauncher.exe
LauncherMusic.wav
Oblivion_default.ini
Bethesda.TXT
Readme.txt
binkw32.dll
Possiamo vedere l'eseguibile principale, il Launcher da cui si modificano le impostazioni e si abilitano/disabilitano gli ESP e il file Oblivion_default.ini dal quale viene generato il file oblivion.ini. NOTA BENE: il file Oblivion_default.ini non deve essere modificato per nessun motivo.
Nota per utenti Steam: a quanto sopra si aggiungono i file per l'inserimento delle chiavi di registro installscript.vdf ed eventualmente un suo backup installscript.vdf.bak
\oblivion\data:
Music
Shaders
Textures
Video
[..]
Oblivion - Meshes.bsa
Oblivion - Misc.bsa
Oblivion - Sounds.bsa
Oblivion - Textures - Compressed.bsa
Oblivion - Voices1.bsa
Oblivion - Voices2.bsa
Oblivion.esm
A quanto sopra si aggiungono gli eventuali BSA ed ESP dei DLC preinstallati dalla versione GOTY.
La sottodirectory Music contiene l'intera colonna sonora di Oblivion in formato .mp3. Non è lì come bonus, si tratta effettivamente dei file che verranno riprodotti nel gioco.
La sottodirectory Shaders contiene i 19 shader pack utilizzati dal motore grafico. Di essi ne verranno utilizzati solo alcuni, dipendentemente dalle caratteristiche della scheda video.
La sottodirectory Textures\Effects contiene un unico file TerrainNoise.dds, aggiunto da Bethesda con la patch 1.2 per migliorare l'erba visibile in lontananza.
La sottodirectory Video contiene i video in formato .bik necessari a riprodurre il logo Bethesda all'avvio, le varie cut sequence, la mappa scorrevole nel menu principale, etc.
Come possiamo constatare Oblivion vanilla non ha directory molto affollate, si parla di meno di un centinaio di file se si escludono quelli contenuti nella directory Directx. Questo perchè quasi tutto il necessario al funzionamento del gioco, come illustrato precedentemente, è contenuto nei BSA e nell'unico ESM oblivion.esm, più gli eventuali BSA ed ESP dei DLC. Ma con l'installazione di nuovi mod la directory si popolerà di una miriade di file, aumentando dalle canoniche dimensioni di circa 6Gb della GOTY fino ad alcune decine di Gb. La mia, per la cronaca, è al momento attorno ai 25Gb e contiene circa 60mila file.
Ora è il momento di avviare il gioco una prima volta. Il Launcher ci informerà che verrà identificata la scheda video e verranno impostati i parametri video di conseguenza. L'autodetect è tendente a fallire con le ultime schede video ma non si tratta di un problema, Oblivion girerà ugualmente. In assenza di un riconoscimento corretto i parametri verranno impostati a Medium. Li sistemeremo poi, per ora usciamo nuovamente dal Launcher senza avviare Oblivion e andiamo a dare un'occhiata in Directory utente\Documenti\My Games\. Ehilà, è spuntata una directory di nome Oblivion! E dentro è stata creato il file oblivion.ini, che inizialmente è poco più di una copia del file Oblivion_default.ini e non contiene ancora tutti i parametri modificabili. Dopo il primo avvio di Oblivion verrà aggiornato aggiungendo i parametri selezionabili dall'interno del gioco.
Avviamo nuovamente il Launcher, che nel trovare una copia corretta di oblivion.ini non tenterà più di crearne uno nuovo e non ci segnalerà più nulla riguardo l'identificazione delle scheda video, e andiamo su Options a modificare i parametri grafici a nostro piacimento. Personalmente imposto tutto al massimo scegliendo Ultra High, abilito le tre opzioni per il distant rendering e abilito vsync e HDR. Non è questa la sede per parlare delle impostazioni grafiche, semplicemente sceglietele compatibilmente con le caratteristiche della vostra macchina, date OK e selezionate Play per avviare finalmente il gioco la prima volta. Bene, e ora? E ora USCITE senza fare nulla. Dobbiamo moddare, mica giocare! :D
All'uscita tornate nuovamente in Directory utente\Documenti\My Games\Oblivion e notate la presenza di due nuovi file: RendererInfo.txt che altro non è che uno stringato dump delle capacità grafiche del vostro sistema e BlendSettings.ini, il cui scopo non è tuttora chiaro ma sembra avere a che fare con il rilevamento della collisione durante i combattimenti. Nessuno dei due è di nostro interesse.
Notate piuttosto come sono aumentate le dimensioni di oblivion.ini [di circa 5K]. E' perchè in seguito all'uscita dal gioco vi sono state aggiunte tutte le impostazioni che si possono selezionare dal menu interno di Oblivion. Noi non abbiamo ancora cambiato nulla, ma vi sono comunque state salvate quelle di default. Ricordatevi di questo punto importante: oblivion.ini viene scritto solo all'uscita da Oblivion e solo se Oblivion non va in crash all'uscita, non viene modificato assolutamente nulla in oblivion.ini dopo aver cambiato le impostazioni dal menu interno. Pertanto in mancanza di un'uscita regolare da Oblivion tutte le impostazioni modificate vengono perse. Niente paura, esiste il rimedio e lo vedremo in questa stessa sezione della guida.
I vari parametri modificabili in oblivion.ini non verranno illustrati, salvo quelli strettamente necessari al modding. Ma prima di proseguire dobbiamo assolutamente cambiare un singolo parametro molto importante, che al suo valore di default può essere causa di crash. Aprite oblivion.ini, individuate la riga iShadowMapResolution=256 e cambiatela in iShadowMapResolution=512 o, se la vostra scheda video è abbastanza recente, iShadowMapResolution=1024. La dimensione consigliata della shadowmap non è strettamente legata alla ram video, quanto alle prestazioni complessive della scheda. Valuterete eventualmente in seguito se sia il caso di lasciarla a 1024 o dimezzarla, compatibilmente con le prestazioni rilevate.
Salvate oblivion.ini e avviate nuovamente il gioco. Entrate nel menu impostazioni e cambiate tutte le impostazioni grafiche come da vostro gradimento. Personalmente imposto tutto al massimo ma lascio l'Anti-aliasing del gioco disabilitato poichè ha problemi di compatibilità con l'HDR. Come AA utilizzo uno shader di OBGE che eventualmente vedremo in seguito. Entrate nel menu gameplay e disabilitate le ultime tre impostazioni per il salvataggio automatico, nota causa di crash. Uscite dal gioco, create nella medesima directory Directory utente\Documenti\My Games\Oblivion una copia di oblivion.ini e chiamatela oblivion.original.ini, sarà la vostra copia di riferimento se lungo la strada qualcosa andrà storto.
Benone, avete terminato l'installazione di Oblivion vanilla. Ora viene il bello : )
III.2 - L'avvio con l'utente di test
Avviamo Oblivion e iniziamo una nuova partita. Diamo al nostro PG provvisorio il nome Test e non perdiamo tempo a modificarne razza e aspetto, lasciando le impostazioni ai valori predefiniti. Il nostro personaggio ci servirà solo per eseguire i nostri test di modding e non verrà usato per giocare, pertanto è inutile caratterizzarlo in alcun modo.
Come prima cosa apriamo la console con il tasto \ [~ sulle tastiere inglesi] e diamo il comando tdt [toggle debug test] per visualizzare le informazioni di debug e abilitiamo la sezione 13 col comando sdt 13 [set debug test]. In alto a destra verranno visualizzati gli FPS e in alto a sinistra la vram impegnata alla riga TextureMem = T xxx Mb. In condizioni ideali quest'ultimo valore non dovrebbe mai superare le dimensioni della vram a bordo della vostra scheda video.
Abituatevi a tenere d'occhio questi valori, saranno utili per discriminare eventuali problemi di overload in seguito all'installazione dei vari mod.
Un'altra sezione di debug molto utile è la 0. Diamo il comando sdt 0 e notiamo in alto a sinistra il nome della cella in cui ci troviamo: ImperialDungeon01 il cui nome mappa è Imperial Prison. Il nome mappa è un mero identificativo per dar modo al giocatore di capire dove si trova ma il dato importante ai fini del modding è il nome della cella. Poter sapere in che cella ci si trova è utile per identificare problemi di conflitti fra mod che modificano i contenuti delle stesse celle. Quando e se ci capiterà di incontrare un problema nel corso del gioco una delle prime informazioni che dovrete fornire a chi vi vorrà aiutare dovrà essere il nome della cella in cui vi trovavate quando avete riscontrato il problema. Mano a mano che avanzeremo nel tutorial del gioco passeremo di cella in cella e ne vedremo cambiare il nome da ImperialDungeon01 a ImperialDungeon02, 03, etc.
Riabilitamo la sezione 13 col comando sdt 13 e leggiamo il valore di Tri: è il triangle count, la quantità di triangoli generati dal motore grafico. Notate come varia a seconda di dove volgete lo sguardo, diminuendo sensibilmente quando guardate verso il basso, dove la scena è limitata alla gestione dei pochi triangoli necessari a generare il terreno. Lo potete verificare visivamente col comando twf per abilitare la modalità wireframe. Notate anche come gli FPS aumentino sensibilmente quando volgete lo sguardo verso zone con minore quantità di triangoli. Su giochi pesantemente moddati tale valore può raggiungere anche i 5 milioni in zone particolarmente complesse, minando le prestazioni. Vedremo più avanti come sarà possibile diminuire il triangle count grazie all'ottimizzazione delle meshes con PyFFI.
Proseguiamo nel tutorial fino ad uscire dalle fogne per arrivare al molo davanti alle rovine di Vilverin e fermiamoci lì. Con sdt 13 e tdt attivo notate il nome della cella: ICPrisonSewerExit01 alle coordinate 11,20. Potete individuare la cella in cui vi trovate su questa (http://www.tesnexus.com/downloads/images/23939-1-1240451419.jpg) mappa nel sublock 1,2. Ribadiamo che è molto importante sapere sempre dove ci si trova in caso di problemi, come ad esempio crash inaspettati, poichè chi vi può aiutare nell'identificare la causa di un crash potrebbe essere già al corrente di un noto conflitto fra mod individuato in una determinata cella. A questo proposito è bene esporre che Oblivion genera gli spawn [creature e NPC] e gestisce oggetti e script in 25 celle [u]esterne per volta: la cella in cui ci si trova più le 24 intorno ad essa [8 nel quadrato interno più le 16 del quadrato esterno]. Salvo dimensioni spropositate di un dungeon, la cella interna è invece sempre e solo una, quella in cui ci si trova in un dato momento. Ne consegue che la probabilità di crash in seguito a gravi conflitti è in esterno 25 volte superiore all'interno . Motivo per cui gli interni sono tendenzialmente considerati "sicuri", mentre il giocatore che si avventura all'esterno ha buon diritto di temere più i crash di quanto non tema gli eventuali nemici incontrati : )
E' il momento di salvare la partita. Aprite la console e digitate save PrisonSewer01, un istante dopo apparirà il messaggio Game Saved. Importante: abituatevi fin da ora a salvare la partita sempre in questo modo, ovvero salvando a mano dalla console dando un nome mnemonico al salvataggio seguito da un numero sequenziale, se possibile evitando gli spazi. Evitate per quanto possibile le sovrascritture del medesimo salvataggio e soprattutto scordatevi per sempre del quicksave. Ripetetelo con me: il quicksave è una Cosa Molto Brutta™. Per quanto possibile cercate inoltre di salvare sempre la partita in una cella interna in modo che al caricamento il gioco non sia stressato dal ricreare immediatamente tutti gli spawn e rigestire tutti gli oggetti e gli script. Scordatevi anche della funzione Autosave, che comunque abbiamo disabilitato più indietro. Avrete potuto notare che all'inizio della partita ne viene comunque generato uno nonostante li si sia disabilitati dal menu. Ignoratelo, è un autosave limitato alle fogne imperiali e non capiterà più.
Il sistema di salvataggio di Oblivion è notoriamente bacato, ed ha particolari problemi con la sovrascrittura dei medesimi salvataggi. Ragion per cui il quicksave va dimenticato a tutti i costi. Col tempo vi abituerete alla semplice sequenza di comandi \ + save nomesalvataggio01, alla quale eventualmente seguirà \ + freccia in su per ripetere l'ultimo comando + save nomesalvataggio02 e così via. Evitate inoltre di palleggiare da un salvataggio ad un altro quando i salvataggi caricano celle [i]differenti [ad esempio caricare un salvataggio in Anvil per poi caricare un salvataggio precedente in Bruma]: Oblivion non resetta correttamente il contenuto del caricamento precedente, pertanto anche se il giocatore non può saperlo ci si potrà trovare in Bruma con delle entità referenziate esistenti solo in Anvil, che verranno incluse in un eventuale salvataggio eseguito in Bruma. Se dovete necessariamente passare da un salvataggio all'altro, uscite prima dal gioco [tornare al menu principale non è sufficiente].
Ora che abbiamo il nostro personaggio di test bell'e pronto possiamo proseguire nel modificare altri aspetti importanti del gioco. Usciamo da Oblivion, per comodità scrivendo in console qqq [Quit Quit Quit :D] e vediamo come si può migliorare la stabilità di Oblivion prima ancora di iniziare a moddarlo. I più curiosi potranno inoltre verificare che sotto Directory utente\Documenti\My Games\Oblivion\Saves è stato creato il file PrisonSewer01.ess, esattamente col nome che abbiamo indicato in console. I due file autosave.ess e autosave.bak possono essere tranquillamente eliminati.
III.3 - L'installazione di OBSE
OBSE [Oblivion Script extender] è un sistema di estensione delle capacità di scripting di Oblivion, che permette agli script di eseguire comandi non nativamente supportati dal gioco. Col tempo si è evoluto permettendo il caricamento di DLL non native di Oblivion, capacità che ha dato modo ai vari sviluppatori di creare particolari plugin come OSR e FastExit, che illustreremo a breve. OBSE non è di per sè un mod in senso stretto, ma viene sfruttato da una moltitudine di mod e plugin per spingere Oblivion oltre i limiti imposti dal gioco. In questa parte della guida ne sfrutteremo le funzionalità per rendere Oblivion più stabile e reattivo, pertanto nessuna installazione di Oblivion, nemmeno quella vanilla, dovrebbe poter fare a meno di OBSE : )
Non essendo OBSE un vero e proprio mod non può essere installato da nessun mod manager, pertanto lo installeremo manualmente prima ancora di arrivare all'installazione di Wrye Bash e gli altri strumenti.
Iniziamo col creare da qualche parte una directory OblivionSetup dove scaricare il necessario. Non fatevi venire la tentazione di creare tale directory come sottocartella di \oblivion, createla da un'altra parte. Oblivion, per ragioni non chiarite, ha la pessima abitudine di eseguire all'avvio un check su tutti i file contenuti nelle sua directory \data. Tale check fallisce miseramente quando i file ivi contenuti superano pressappoco i 400, e il gioco va in crash all'avvio o al caricamento di un salvataggio. Per tale ragione la directory \oblivion\data e se possibile anche \oblivion non dovrebbero contenere nient'altro che quanto necessario al funzionamento del gioco, lasciando tutti i necessari file di installazione dei mod in una directory esterna. Gli eventuali file .txt dei doc non sembrano essere coinvolti dal check, pertanto i vari readme dei mod, quando non installati automaticamente sotto oblivion\docs, possono anche risiedere serenamente in \oblivion\data.
Scarichiamo OBSE da qui (http://obse.silverlock.org/) e salviamo il file obse_0020.zip nella nostra directory OblivionSetup. Apriamo lo zip ed estraiamo direttamente nella directory \oblivion i seguenti file:
obse_1_2_416.dll
obse_editor_1_2.dll [facoltativo per il gioco ma necessario per il CS]
obse_loader.exe
Nota per utenti Steam: nella directory \oblivion va estratto anche il file obse_steam_loader.dll. OBSE richiede inoltre che per il suo corretto funzionamento con Steam sia abilitato lo Steam Community In-Game [lo trovate fra le impostazioni di Steam]. Inoltre il readme segnala di non copiare obse_loader.exe poichè inutilizzato da Steam, in realtà va comunque copiato poichè è l'unico modo per Wrye Bash per capire se state utilizzando OBSE.
Al termine dell'estrazione la directory \oblivion apparirà così:
\oblivion:
Data
Directx
Oblivion.exe
OblivionLauncher.exe
obse_loader.exe
LauncherMusic.wav
Oblivion_default.ini
Bethesda.TXT
Readme.txt
binkw32.dll
obse_1_2_416.dll
obse_editor_1_2.dll
Con in più i file installscript.vdf, installscript.vdf.bak e obse_steam_loader.dll per gli utenti Steam.
D'ora in poi tutte le volte che avvierete il gioco lo dovrete fare lanciando obse_loader.exe. Eventualmente fatevene un collegamento sul desktop per comodità. Se lancerete il gioco dal Launcher o direttamente dal suo eseguibile oblivion.exe, OBSE non funzionerà. Lanciate ora obse_loader.exe e arrivati al menu uscite subito dal gioco.
Nota per utenti Steam: obse_loader.exe non va utilizzato, l'avvio del gioco va eseguito normalmente dal Launcher come siete soliti fare.
Se OBSE funziona correttamente vedrete comparire nella directory di Oblivion il file obse.log con questo contenuto:
OBSE: initialize (version = 20.6 010201A0)
oblivion root = Directory Installazione\oblivion\
plugin directory = Directory Installazione\oblivion\Data\OBSE\Plugins\
patched
OBSE: deinitialize
Nota per utenti Steam: nella directory \oblivion dovreste trovare anche il file obse_steam_loader.log con questo contenuto:
crc = A2408F04
dll = Directory Installazione\steam\steamapps\common\oblivion\obse_1_2_416.dll
Ora che abbiamo un OBSE bello funzionante vediamo di sfruttarlo a dovere installando alcuni plugin essenziali.
OBSE - L'installazione di FastExit2
Come detto sopra, Oblivion non è in grado di salvare il file oblivion.ini in caso di crash in uscita, eventualità la cui probabilità aumenterà esponenzialmente con l'installazione dei mod anche quando essi funzioneranno perfettamente nel gioco. Oblivion è fatto così, o lo prendi a botte o ne prendi atto e porti pazienza :D
Oppure ci si arma degli strumenti necessari per domarlo. FastExit è un semplice ed utilissimo plugin che risolve il problema dei crash in uscita alla radice intercettando il comando di uscita dal gioco e salvando correttamente il file oblivion.ini, per poi killare il processo oblivion.exe. Scarichiamolo da qui (http://www.nexusmods.com/oblivion/mods/22410), sezione Files > Main Files > FastExit2 e salviamolo nella nostra directory OblivionSetup. Preleviamo la directory Data dal file zippato ed estraiamola nella directory \oblivion, sovrascrivendo quando richiesto. Nella directory \oblivion\data compariranno due nuove sottodirectory obse e plugins, al cui interno troveremo il file FastExit2.dll:
Oblivion
Data
obse
plugins
FastExit2.dll
Non c'è bisogno di configurare assolutamente nulla. All'avvio del gioco OBSE eseguirà uno scan della directory plugins ed abiliterà tutti i plugin rintracciati. Verifichiamo il funzionamento di FastExit avviando il gioco, carichiamo il nostro salvataggio PrisonSewer01 dal menu e usciamo immediatamente col comando qqq da console. Oblivion privo di mod non ha problemi a chiudersi correttamente e velocemente, ma rispetto a prima dovremmo comunque notare una maggiore reattività al comando di uscita.
Come ulteriore verifica apriamo nuovamente il file obse.log da \oblivion\data, dovremmo poter vedere delle informazioni in più relative al corretto caricamento del plugin:
OBSE: initialize (version = 20.6 010201A0)
oblivion root = Directory Installazione\oblivion\
plugin directory = Directory Installazione\oblivion\Data\OBSE\Plugins\
checking plugin Directory Installazione\oblivion\Data\OBSE\Plugins\\FastExit2.dll
plugin Directory Installazione\oblivion\Data\OBSE\Plugins\\FastExit2.dll (00000001 FastExit 00000002) loaded correctly
patched
OBSE: deinitialize
A quanto sopra si aggiungono alcune segnalazioni riguardo l'assenza di PrisonSewer01.obse. Si tratta dei file che crea OBSE in Directory utente\Documenti\My Games\Oblivion\Saves al salvataggio di una partita, contenenti tutti i dati e le variabili supportate unicamente da OBSE e che devono essere ricaricati successivamente al caricamento del canonico file di salvataggio del gioco, pena il mancato funzionamento degli script di OBSE in quel dato caricamento. Siccome non abbiamo ancora salvato nessuna partita con OBSE attivo, è corretto che OBSE non trovi traccia di quel file. Provvediamo subito: riavviamo Oblivion, carichiamo il nostro salvataggio PrisonSewer01 e creiamo un nuovo salvataggio col comando save PrisonSewer02. Usciamo dal gioco, riavviamo Oblivion e carichiamo il salvataggio PrisonSewer02. Uscendo nuovamente dal gioco e consultando il file obse.log potremo vedere che successivamente al caricamento di PrisonSewer02.ess è stato correttamente caricato anche PrisonSewer02.obse.
OBSE - L'installazione di ConScribe
Oblivion è praticamente privo di un vero e proprio strumento di debug, pertanto anche in questo caso la comunità si è dovuta arrangiare per quanto possibile. Ad oggi non è possibile controllare il comportamento dell'eseguibile oblivion.exe per identificare eventuali crash, ma è possibile visualizzare in console alcune informazioni fornite dai mod che prevedono un qualche tipo di debug dei loro script. Siccome in seguito al crash di Oblivion non è ovviamente più possibile visualizzare alcunchè si è reso necessario salvare queste informazioni di debug in un file di log. E' lo scopo di ConScribe, un utilissimo plugin che provvederà a scrivere su un file di log tutto quello che è apparso in console nell'ultima sessione di gioco. Prevede anche la possibilità di salvare i log singolarmente per ogni mod, ma essi devono espressamente sfruttarla tramite una funzione RegisterLog inclusa negli script, cosa che pochi modder fanno. Scarichiamo ConScribe da qui (http://www.nexusmods.com/oblivion/mods/26510), sezione Files > Main Files > ConScribe 90 e salviamolo nella nostra directory OblivionSetup. Notate che nei dettagli del file è indicato che si tratta di un OMOD Ready Archive. Non significa che il file è in formato OMOD, attenzione. Significa semplicemente che può essere agevolmente [i]convertito in formato OMOD. Riprenderemo quest'argomento più avanti.
Preleviamo la directory OBSE dal file zippato ed estraiamola nella directory \oblivion\data, sovrascrivendo quando richiesto. Nella directory \oblivion\data\obse\plugins comparirà un nuovo file ConScribe.dll. Come nel caso di FastExit non c'è bisogno di configurare nulla, OBSE rileverà la presenza del plugin e lo caricherà di conseguenza.
Avviamo Oblivion e usciamo immediatamente senza caricare nessun salvataggio. Verifichiamo in \oblivion la presenza di un nuovo file ConScribe.log, dove verrà indicato che in assenza di un file ConScribe.ini ne è stato creato uno nuovo in \oblivion\data\obse\plugins, contenente le impostazioni di default. Lasciamo quel file in pace, avviamo Oblivion, carichiamo il nostro salvataggio PrisonSewer02, apriamo la console e scriviamo pippo. Il gioco giustamente si lagnerà segnalando che Pippo non lo conosce. Strano, Pippo lo conoscono tutti. Usciamo dal gioco, andiamo sotto la nuova directory \oblivion\data\ConScribe Logs e apriamo il file Static Log.log. Potremo vedere che all'interno è stato salvato il medesimo errore segnalato in console. Allo stesso modo ConScribe registrerà tutti gli eventuali errori nel gioco registrati dalla console, ma dal momento che ad un crash non necessariamente corrisponde un messaggio di errore in console non è affatto detto che ConScribe possa dare indicazioni sulle cause del crash. Si tratta comunque di uno strumento estremamente utile per identificare anomalie dovute a script non eseguiti correttamente.
OBSE - L'installazione di Oblivion Stutter Remover
E arriviamo al pezzo da novanta : )
Notate che fino ad ora non abbiamo ancora parlato di mod manager e ci siamo limitati ad installare i plugin manualmente. Wrye Bash non avrebbe alcuna difficoltà ad installare FastExit, ConScribe e OSR ma non è ancora il momento di parlare di WB e i tre plugin di cui sopra possono essere installati manualmente senza problema alcuno.
I giocatori di Oblivion sono da sempre afflitti da un problema comune: il famigerato stuttering, ovvero il fenomeno per cui il gioco si muove "a strappi", problema particolarmente sentito negli ambienti esterni. Le cause sono due: limite del motore grafico e limite hardware della macchina su cui gira. Oblivion vanilla va che è una bellezza sulle macchine di ultima generazione, ma una volta moddato pesantemente ecco ritornare lo stuttering. Le soluzioni sono diverse, e nessuna di esse da sola è sufficiente:
- procurarsi hardware più potente
- abbassare i dettagli grafici
- variare una serie di parametri in oblivion.ini, dei quali non ci occuperemo in questa sede
- deframmentare spesso la directory \oblivion con un programma come Defraggler (http://www.piriform.com/defraggler)
- usare Oblivion Stutter Remover
Non ci dilungheremo sul principio di funzionamento dell'ultima soluzione: ci basta sapere che funziona, e anche bene : )
Un ulteriore vantaggio dato da OSR è rendere il gioco molto più stabile in situazioni di overload. Si tratta pertanto di una scelta quasi obbligata per tutti, sia per chi non ha interesse a moddare oblivion, sia per chi preferisce limitarsi a pochi e leggeri mod, sia per chi lo intende moddare fino allo sfinimento.
Prima di installare OSR è il momento di eseguire uno stutter test. Avviate Oblivion, caricate il salvataggio PrisonSewer02, aprite la console e digitate quanto segue:
tdt
sdt 13
tgm
player.setav speed 250
Sì, stiamo barando. Ma è necessario per il test. Aprite la mappa e usate il fast travel verso le stalle alle porte di Bruma. Da lì dirigetevi come dei treni a sud verso Leyawiin, possibilmente non fermatevi mai e proseguite diritti per quanto possibile. Ignorate qualunque nemico lungo la strada, data la velocità dopò un po' sarà lui a ignorare voi. Non è necessario che prendiate nota mentalmente di FPS e VRAM impegnata mano a mano che viaggiate, piuttosto badate all'eventuale stuttering che state subendo e cercate di ricordarvi il percorso che avete seguito. Avete attraversato tutta Cyrodiil e siete arrivati a Leyawiin? Ottimo, ora uscite dal gioco [non avete bisogno di salvare la partita].
Scarichiamo OSR da qui (http://www.nexusmods.com/oblivion/mods/23208), sezione Files > Updates > OSR_4-1-24_RC e salviamolo nella nostra directory OblivionSetup. Preleviamo la directory Data dal file zippato ed estraiamola nella directory \oblivion, sovrascrivendo quando richiesto. Nella directory \oblivion\data\obse\plugins compariranno tre file sr_Oblivion_Stutter_Remover.dll, sr_Oblivion_Stutter_Remover.ini e sr_Oblivion_Stutter_Remover.txt, più una directory ComponentDLLs che alle impostazioni di default verrà ignorata. Apriamo sr_Oblivion_Stutter_Remover.ini e cambiamo i seguenti parametri:
da bReplaceHeap = 0 a bReplaceHeap = 1
da iHeapSize = 450 a iHeapSize = 1024 su PC con almeno 3Gb di ram
Ora rientrate nel gioco e ripetete il test, partendo dalla stessa posizione alle porte di Bruma e se possibile rifacendo la stessa strada fino a Leyawiin. Dovreste notare dei sensibili miglioramenti, ma soprattutto dovreste notare una cosa importante: il vostro frame rate non supererà mai i 30FPS. Questo perchè OSR alle impostazioni di default usa un sistema di FPS CAP per bloccare il framerate a un sottomultiplo della più comune frequenza di refresh dei monitor: 60Hz [a questo proposito è caldamente consigliato abilitare il vsync]. In questo modo il sistema è meno stressato dal motore e può dedicarsi a compiti altrettanto gravosi come l'AI e la gestione degli script.
La configurazione di OSR non ha bisogno di particolari rifiniture ma alcuni utenti potrebbero trovare lo iHeapAlgorithm di default instabile per la loro macchina. Nel caso si può provare ad usare il 5 e, per utenti su Vista e Seven, il 2.
Per quanto riguarda i plugin di OBSE per ora è tutto. In futuro alcuni mod potrebbero aver bisogno di installarne altri, ma nel caso vi verrà indicato nei vari Readme. Quanto sopra è la base per iniziare con OBSE e dovrebbe essere seguita anche da chi non ha la minima intenzione di moddare Oblivion.
III.4 - La Large Address Aware patch
Fact number 1: l'installazione di pesanti mod impegna un sacco di ram di sistema.
Fact number 2: oblivion.exe va in crash superato l'impegno di 1.8Gb.
Chi dispone di un sistema a 64bit con almeno 3Gb di ram può decidere di applicare questa (http://www.ntcore.com/4gb_patch.php) patch all'eseguibile oblivion.exe, eventualmente dopo averne creata una copia di backup, per permettere ad oblivion.exe di sfruttare fino a 3.8Gb di ram [nella realtà in un Oblivion pesantemente moddato l'impegno di ram si assesta fra i 2.5 e i 3Gb]. L'operazione è rapida e indolore, è sufficiente lanciare l'eseguibile scaricabile al link a fondo pagina e puntare al file oblivion.exe. Un messaggio ci informerà che l'eseguibile è stato patchato correttamente.
Nota per utenti Steam: perchè la patch funzioni correttamente pare sia necessario patchare anche il file GameOverlayRenderer.dll presente nella directory principale di Steam. L'operazione dà risultati discordanti fra i vari utenti ed è tuttora in test sui forum ufficiali di Bethesda. La stessa presenza di un file GameOverlayRenderer64.dll fa pensare che l'operazione non dovrebbe ritenersi necessaria. Eseguirla non compromette comunque in nessun modo la funzionalità del gioco.
Patchare l'eseguibile su sistemi a 32bit dotati di 3Gb di ram non ha alcun effetto senza che si aggiunga al boot.ini uno switch /3GB per indicare al sistema di utilizzare più di 2Gb per le applicazioni. Trattandosi di un'operazione che può compromettere la stabilità del sistema non verrà ulteriormente documentata da questa guida.
Nota: al momento l'unico modo per verificare a quanto ammonti l'impegno ram di oblivion.exe è avviare il gioco in modalità finestra lasciando in primo piano il task manager.
III.5 - L'installazione di Wrye Bash
Ed eccoci qua. Siete andati a caccia di mod, vi siete informati sulle ultime novità, avete saturato la banda del provider nel scaricare un bel malloppo di mod e non vedete l'ora di installarli e giocare. Se siete entrati nello spirito di questa guida dovreste aver ormai realizzato che il metodo migliore per scombinare tutto è installarli a caso e sperare che tutto funzioni.
Il metodo migliore per avere invece un Oblivion virtualmente privo di crash, oltre a seguire i passi già illustrati, è imparare ad utilizzare Wrye Bash.
WB è un software dall'aspetto ostico. L'interfaccia, benchè migliorata con gli anni, appare di primo acchito estremamente complicata. Scopriremo invece che una volta imparati i meccanismi basilari è molto più semplice di quel che sembra nonostante la miriade di opzioni, delle quali vedremo solo una parte. Ne impareremo l'uso fino ad arrivare ad un livello di conoscenza intermedio, il resto verrà volutamente ignorato e lasciato ad ulteriore indagine da parte dell'utente.
Lo sviluppo di WB è iniziato con una versione basata su Python, e le versioni attuali non fanno eccezione. Gli sviluppatori preferiscono che gli utenti continuino nell'utilizzare la versione Python-based poichè gli è molto più semplice identificare le cause dei bug segnalati, ma per nostra fortuna ne forniscono una versione Standalone che non richiede l'installazione di Python e di tutta una serie di suoi componenti. L'unico requisito necessario è il pacchetto dei componenti di runtime delle librerie di VisualC++ aggiornate all'SP1 2008, che potreste già avere installato nel vostro sistema in seguito all'installazione di software che ne richiedono la presenza. Lo potete verificare da Pannello Di Controllo > Installazione Applicazioni, in elenco dovreste vedere "Microsoft Visual C++ 2008 Redistributable - x86 9.0.30729.17". In caso contrario potete scaricare quanto necessario da qui (http://www.microsoft.com/downloads/it-it/details.aspx?familyid=a5c84275-3b97-4ab7-a40d-3802b2af5fc2).
Ora che abbiamo i requisiti necessari scarichiamo Wrye Bash da qui (http://www.nexusmods.com/oblivion/mods/22368), sezione Files > Main Files > Wrye Bash 295 - Installer e salviamo il file nella nostra directory OblivionSetup. Avviamo il setup e diamo un'occhiata alle opzioni dell'installer.
Wrye Bash ha la possibilità di essere installato in più versioni differenti in directory differenti, in modo da poterne mantenere una copia stabile e utilizzarne altre da aggiornare con le versioni in test. Noi non lo faremo e ci limiteremo ad installare WB nella sua forma Standalone nella sua directory predefinita Directory Installazione\oblivion\. Pertanto dovremo spuntare solo i flag "Oblivion" e "Wrye Bash [Standalone]". Clickiamo su Next e, se i requisiti risultano soddisfatti, verremo accolti dal messaggio "All prerequisites detected". Clickiamo su Next, lasciamo nella schermata successiva tutti i flag attivi e clickiamo su Install. Attendiamo il termine della copia dei file, rimuoviamo i segni di spunta da tutte e tre le opzioni dell'ultima schermata e clickiamo su Close. Prima di avviare Wrye Bash per la prima volta andiamo a farci un giro nella directory \oblivion. Noteremo la presenza di una nuova directory Mopy, che contiene tutti i file necessari al funzionamento di Wrye Bash. Andiamo sotto \oblivion\mopy\bash\l10n\ e cancelliamo il file italian.txt. Si tratta del file contenente la traduzione dell'interfaccia di WB in italiano, ma è incompleto poichè risalente a vecchie versioni e ci ritroveremmo l'interfaccia metà in inglese e metà in italiano.
Chiudiamo la cartella e finalmente avviamo Wrye Bash da Start > Programmi > Wrye Bash > Wrye Bash - Oblivion [nulla vi impedisce di crearvi un collegamento sul Desktop per comodità]. All'avvio vi suggerisco di non toccare nulla e seguire la guida passo per passo. Non che si corra il rischio di far esplodere qualcosa, ma potreste inavvertitamente abilitare un'oscura opzione senza che abbiate immediata evidenza dell'effetto. Attendete il caricamento di WB e non clickate da nessuna parte.
Nota: se non mi avete dato retta nel ripulire completamente il sistema come indicato nella guida e avete ancora OBMM installato potreste veder apparire una popup che vi chiede di disabilitare il Lock Times ["Turn Lock Times Off?"]. Nel caso rispondete di No. Vedremo più avanti di che si tratta.
L'interfaccia di Wrye Bash
Dopo qualche secondo ci ritroviamo davanti ad una finestra divisa in una serie di tab e totalmente priva di qualsivoglia menu. Oddio, dov'è il mio rassicurante menu File? Dove sono le preferenze? Cosa sono quelle tab? Che razza di programma è questo? Prima di farvi prendere dal panico guardate l'elenco dei file nella tab Mods. Dovreste vedere al minimo il familiare oblivion.esm [che verrà indicato come oblivion.esm [SI] per chi possiede l'espansione Shivering Isles] e un molto oscuro Bashed Patch, 0.esp. Chi possiede espansioni e vari DLC dovrebbe poter vedere in elenco anche tutti i loro ESP.
Se vedete quanto sopra, Wrye Bash si è installato correttamente e ha identificato correttamente la vostra installazione di Oblivion. Ora che ci siamo assicurati che WB stia funzionando come si deve vediamo di illustrare brevemente l'interfaccia del programma. Mano a mano che installeremo i mod vedremo sempre più nuove funzionalità, in modo da poter imparare ad usare WB mentre lo stiamo usando attivamente.
Nota: su alcune installazioni di Oblivion GOTY e più in generale su installazioni dove vi sono almeno due ESP di DLC potreste vedere visualizzati alcuni ESP in rosso poichè hanno erroneamente la medesima data e di conseguenza il medesimo ordine di caricamento. Non allarmatevi, sistemeremo poi.
Clickiamo sul tab Installers in alto a sinistra e rispondiamo Si alla popup che ci chiede se abilitare o meno gli Installers. Apparirà un'ulteriore popup con barra d'avanzamento e messaggio informativo "Refreshing Installers". E' un'operazione che WB eseguirà ogni volta che ad ogni nuovo avvio clickeremo su Installers, senza che ci venga più chiesto se abilitarli o meno. L'abilitazione degli Installers non fa altro che abilitare un sottoprogramma di nome BAIN , che è il software interessato alla gestione dell'installazione e disinstallazione dei mod. Al termine del refresh ci ritroveremo davanti ad una schermata meravigliosamente.. vuota. E' previsto, è perchè non abbiamo ancora nessun mod installabile in elenco. Ora chiudiamo Wrye Bash, banalmente chiudendone la finestra con la X in alto a destra, e torniamo per un attimo nella nostra directory \oblivion. Risaliamo di un livello e notiamo che allo stesso livello di \oblivion in seguito all'abilitazione di BAIN è stata creata una directory Oblivion Mods. Se abbiamo installato Oblivion in C:\Giochi\Oblivion, la nuova directory di nostro interesse sarà C:\Giochi\Oblivion Mods.
Nota per utenti Steam: se ad esempio avete installato Steam in C:\Giochi la directory verrà creata sotto C:\Giochi\Steam\steamapps\common, allo stesso livello della directory di Oblivion.
Come impostazione predefinita la directory Oblivion Mods contiene quanto segue:
Bash Installers
Bain Converters
--Corrupt
--Duplicates
Bash
Converters.dat
Installers.dat
Bash Mod Data
Table.dat
Table.dat.bak
Tutti i nostri mod in formato rar, zip o 7z dovranno essere copiati sotto la directory Bash Installers perchè BAIN vi possa accedere. Per ora non fatelo, dobbiamo prima capire bene come funziona WB. Notate che WB non può installare mod in formato OMOD, pertanto se ne avete già scaricati in quel formato le alternative sono due: riscaricarli in formato non-OMOD oppure convertirli da OMOD a formato compresso rar, zip o 7z. Vedremo più avanti come eseguire quest'ultimo punto. Ora vediamo nel dettaglio le varie tab.
La tab Installers
Riapriamo WB e torniamo sulla tab Installers. Stavolta il refresh impiegherà un istante ma mano a mano che installeremo mod impiegherà sempre più tempo. Ridimensioniamo a piacere i vari box in modo da visualizzare correttamente tutti gli header e diamo uno sguardo al box di sinistra: contiene un unico package di nome ==Last==, che altro non è che uno dei marker che utilizzeremo per suddividere i mod per categoria. I vari header del box indicano rispettivamente il nome del package, l'ordine di installazione, la data dell'ultima modifica, le dimensioni del package e la quantità di file contenuti. Selezionamo ==Last== clickandolo una sola volta col sx e notiamo che nel box in alto a dx sono comparse delle informazioni nelle varie tab.
La tab General, che al momento indica ogni caratteristica con N/A poichè il package selezionato è di per sè vuoto, visualizza una serie di informazioni riassuntive delle caratteristiche del package nella sezione ==Overview, più i file installati nella sezione ==Configured files. Avendo selezionato un package vuoto ovviamente non viene elencato nessun file.
La tab Matched, al momento vuota, indica quali file del mod sono stati installati in locale nella struttura \oblivion\data. Ovviamente per il package ==Last== non ve ne è nessuno.
La tab Missing, che in condizioni normali deve essere sempre vuota, indica quali file del package non sono stati installati, ad esempio perchè il package scaricato è corrotto.
La tab Mismatched, al momento vuota, elenca quali file in locale sono diversi da quelli nel package, ad esempio i vari file .ini che abbiamo customizzato manualmente o i file che sono stati sovrascritti con altre versioni da altri package.
La tab Conflicts, al momento vuota, elenca quali file del package siano in conflitto con file di altri package. Ne vedremo solitamente elencati parecchi ed è perfettamente normale.
La tab Underriden, che in condizioni normali deve essere sempre vuota, elenca i file che in seguito a riordinamento dei package [ad esempio perchè è stato sbagliato l'ordine di installazione] dovrebbero essere nuovamente reinstallati poichè non ve ne è in locale la versione corretta.
La tab Dirty, che in condizioni normali deve essere sempre vuota, elenca i file che in seguito a riconfigurazione di un package [ad esempio perchè abbiamo installato una parte del mod che non desideravamo] dovrebbero essere rimossi poichè inutilizzati.
La tab Skipped contiene i file non riconosciuti come "standard" da Wrye Bash, ad esempio screenshot inclusi in un texture package, che l'utente può decidere di escludere durante l'installazione dei package per risparmiare spazio.
La tab Mods
Ritorniamo in alto fra le tab principali e selezioniamo Mods, che insieme ad Installers sarà la tab dove risiederemo per la maggior parte del tempo. La tab elenca tutti gli ESM ed ESP presenti nella directory \data, sia abilitati sia disabilitati, ordinabili eventualmente per nome, ordine di caricamento, autore, ecc. I vari header indicano il nome del file su disco, l'ordine di caricamento, il voto [Rating] che gli abbiamo facoltativamente assegnato, il gruppo al quale abbiamo facoltativamente assegnato l'ESP, l'Installer di cui fa parte, la data di ultima modifica [che di fatto determinerà l'ordine di caricamento], la dimensione, l'autore del mod e il suo univoco CRC check. L'ordine visualizzato varierà a seconda dell'header su cui clickeremo col tasto sx. Clickiamo su Load Order in modo da visualizzare l'elenco in ordine di caricamento.
Nella parte destra della finestra vediamo un box contenente una serie di informazioni che compariranno selezionando uno degli ESM/ESP. Proviamo ora, selezionando oblivion.esm clickandoci su una sola volta col sx. Dall'alto in basso il box visualizzerà il nome del file, l'autore, la data di ultima modifica, la descrizione [vuota per oblivion.esm], i suoi master [oblivion.esm non ne ha chiaramente nessuno] e i tag della bashed patch, anch'essi vuoti per oblivion.esm, e che illustreremo quando spiegheremo nei dettagli il funzionamento della bashed patch.
Chi ha in elenco altri ESP di eventuali DLC può selezionarli e notare come cambiano le varie informazioni nel box di dx. In particolare per ogni ESP verrà indicato che il loro master è oblivion.esm.
Come anticipato più su, alcuni ESP potrebbero essere evidenziati in rosso poichè hanno erroneamente il medesimo ordine di caricamento di altri ESP. Posizionandovi sopra il puntatore del mouse dovreste vedere nella barra di stato in basso il messaggio "Active in load list. WARNING: Has some load order as another mod". Nel caso clickate col tasto dx sugli ESP evidenziati in rosso, scegliete File > Redate e nella nuova popup assegnategli una data qualsiasi, purchè diversa dalla data degli altri ESP. Per semplicità limitatevi a cambiare l'ultima cifra dell'anno, le date corrette le imposteremo più avanti grazie a BOSS.
Fra gli ESP in elenco vedrete anche un ESP molto particolare, che deve sempre essere caricato per ultimo: la Bashed Patch, ovvero la chiave di volta su cui si basa l'intero modding di Oblivion. Per ora lasciamola in pace, vedremo più avanti nei dettagli a cosa serve e perchè è così utile.
La tab Saves
Qui vengono elencati i file di salvataggio. Dovremmo vedere in elenco i nostri PrisonSewer01.ess e PrisonSewer02.ess che abbiamo creato più indietro. I vari header indicano il nome del file su disco, la data del salvataggio, la dimensione, il tempo di gioco, il nome del giocatore [nel nostro caso Test] e la cella in cui ci si trovava al momento del salvataggio [nel nostro caso City Isle]. Il colore del piccolo box a sx del nome del salvataggio ne indica lo stato:
[b]Porpora indica un salvataggio completamente sincronizzato con gli ESP abilitati nella tab Mods.
Blu indica un salvataggio non completamente sincronizzato con gli ESP abilitati nella tab Mods, capita quando il salvataggio comprende degli ESP i cui master sono assenti o disabilitati.
Verde indica un salvataggio che non fa uso di uno o più ESP abilitati nella tab Mods, capita quando il salvataggio non comprende ancora un ESP di recente installazione.
Arancione indica un salvataggio i cui ESP hanno un ordine di caricamento diverso rispetto a quel che avevano quando il salvataggio è stato eseguito; chi possiede ESP di DLC e poco più su ha dovuto cambiarne la data poichè evidenziati in rosso causa medesima data fra più ESP vedrà il salvataggio in colore arancione. Per ora non è un problema per i nostri salvataggi PrisonSewer01.ess e PrisonSewer02.ess poichè come detto più indietro i DLC sono privi di conflitti fra loro e possono essere caricati in qualsiasi ordine quando sono gli unici presenti in Oblivion.
Rosso indica un salvataggio che fa riferimento a degli ESP che nella tab Mods non esistono, capita quando il salvataggio non può più far riferimento ad ESP che sono stati eliminati in seguito alla disinstallazione di un mod. Caricare un salvataggio di questo tipo in Oblivion farà apparire un messaggio di avviso riguardo a contenuto non più presente. In questi casi prima di proseguire nel gioco è bene eseguire un nuovo salvataggio, uscire da Oblivion e ricaricare il nuovo salvataggio, che sarà diventato quello che in gergo si definisce un Clean Save e che verrà visualizzato in porpora.
Va da sè che la condizione ideale per rendere felice Oblivion è avere a che fare unicamente con salvataggi in porpora.
Selezionando uno dei salvataggi vedremo apparire una serie di informazioni nel box di destra. Dall'alto in basso il nome del file su disco, le informazioni su nome giocatore, livello del giocatore, data, tempo di gioco e nome cella, lo screenshot del luogo in cui ci trovavamo al momento del salvataggio e la lista degli ESM/ESP a cui fa riferimento il salvataggio, che Wrye Bash definisce come masters list al pari di quella che abbiamo visto per gli ESP nella tab Mods. Ebbene sì, dal punto di vista di Oblivion i file di salvataggio ESS non sono nient'altro che degli ESP, contenenti inoltre la struttura ad albero di NetImmerse per memorizzare le variazioni sui nodi con le informazioni sui vari stati delle celle. Mano a mano che avanzeremo nel gioco i file di salvataggio aumenteranno sempre più di dimensione, poichè all'albero di default verranno via via aggiunti tutti i nodi con gli stati aggiornati. Gli ESS non possono comunque essere caricati dal Construction Set poichè il file ha un header differente dagli ESP e pertanto non viene riconosciuto.
La tab INI Edits
Non vi siete stufati di dover editare oblivion.ini a manina ogni volta? Ora non vi stuferete più. WB contiene una moltitudine di impostazioni comunemente variata dall'utente nel file oblivion.ini, come la disabilitazione del joystick, la disabilitazione delle border regions, eccetera. In più i vari mod possono fornire degli INI Edits personalizzati, come DarnUI che necessita di cambiare i font di default. L'utente può poi scegliere di prepararsi degli INI Edits personalizzati secondo il proprio gusto. Per scegliere i vari tweak è sufficiente clickare col dx sulla voce che si desidera abilitare/disabilitare e dare Apply. Per ora non tocchiamo nulla, al momento non ne abbiamo bisogno.
Le tab Screenshots, PM Archive e People
Personalmente non utilizzo nessuna di esse ma c'è chi può trovarle utili. Nella tab Screenshots vengono appunto conservate le schermate del gioco salvate su disco, mentre le tab PM Archive e People servono per conservare traccia dei messaggi scambiati con i modder sui vari forum e con ogni probabilità non saranno funzioni che utilizzerete. Non verranno esposte ulteriormente in questa guida.
Ora chiudiamo Wrye Bash e prima di proseguire facciamo una piccola digressione per installare un software essenziale che va ad integrarsi perfettamente con Wrye Bash: BOSS.
L'installazione di BOSS
Grazie a BOSS non dovrete più preoccuparvi di riordinare manualmente i plugin. BOSS va ad interrogare una masterlist costantemente aggiornata contenente l'ordine di caricamento di oltre 12mila mod e si incaricherà di ridatare ogni singolo ESP per far sì che venga caricato nell'ordine corretto. L'uso di BOSS è questione di un singolo click in Wrye Bash.
Scarichiamo BOSS da qui (http://www.nexusmods.com/oblivion/mods/20516), sezione Files > Main Files > BOSS 1-8 Installer e salviamolo nella nostra directory OblivionSetup. Avviamo l'installer, clickiamo su Next e attiviamo il flag su Oblivion senza cambiare il percorso offerto. Nel caso Oblivion non compaia in elenco poichè BOSS non è stato in grado di riconoscerne la presenza spuntiamo Other Location e andiamo a puntare a Directory Installazione\oblivion\ [per gli utenti Steam sarà Directory Installazione\Steam\Steamapps\common\oblivion]. Clickiamo su Next, lasciamo nella nuova schermata tutti i flag al default e clickiamo Install. Al termine della copia dei file clickiamo su Next, nella nuova schermata rimuoviamo tutti i flag e clickiamo su Close. Per ora NON lanciamo BOSS, abbiamo ancora qualcosa da fare in Wrye Bash.
Configurare Wrye Bash
Apriamo WB e nella tab Mods clickiamo col dx in un punto libero qualsiasi dello schermo, o in alternativa su uno qualsiasi degli header. Nel drop-down menu comparso assicuriamoci che siano abilitati i flag solo sulle seguenti voci [disabilitare tutte le voci non comprese nella lista]:
Auto-Ghost
Lock Times
BOSS Disable Lock Times
Check mods against BOSS's dirty mod list
Spostiamoci nella tab Installers e clickiamo col dx in un punto libero qualsiasi dello schermo, o in alternativa su uno qualsiasi degli header. Nel drop-down menu comparso assicuriamoci che siano abilitati i flag solo sulle seguenti voci [disabilitare tutte le voci non comprese nella lista, incluso "Skip OBSE Plugins"]:
Avoid at Startup
Enabled
Auto-Anneal
Auto-Anneal/Install Wizards
BSA Redirection
Clean Data Directory
Show Lower Conflicts
Wizard Icon Overlay
L'abilitazione di BSA Redirection avrà due effetti:
- In \oblivion\data verrà creato un nuovo file di nome ArchiveInvalidationInvalidated!.bsa
- oblivion.ini verrà modificato aggiungendo alla direttiva SArchiveList il BSA ArchiveInvalidationInvalidated!.bsa
Lo scopo di tale operazione è permettere ad Oblivion di caricare correttamente i loose file che si propongono di sostituire quelli contenuti nei BSA vanilla, come ad esempio una texture ad alta risoluzione. Come indicato nella Parte I di questa guida, Oblivion carica i loose file col medesimo nome di quelli già presenti nei BSA quando i loose file risultano essere più recenti, di fatto invalidando in tempo reale il file del caso contenuto nel BSA [pur non modificando in nessun modo il file BSA originale]. Tale sistema non sempre funziona correttamente poichè il gioco inizia a ritenere i file nei BSA come invalidabili solo quando durante il caricamento dei loose file incontra il primo di essi senza che venga eseguito un controllo di invalidazione a monte, pertanto nel frattempo Oblivion potrebbe aver già caricato erroneamente i file originali nei BSA, col risultato di miscelare texture vanilla con texture aggiornate senza caricare quest'ultime nella loro totalità.
In sintesi il bug consiste nel fatto che Oblivion non sa di dover invalidare i file nei BSA fino a che non rileva correttamente la presenza di un loose file. Il problema è che nel frattempo potrebbe già aver caricato parte di quei BSA, compresi i file originali che il mod si propone di sostituire.
Il metodo BSA Redirection fa sì che Oblivion venga ingannato caricando per primo il file ArchiveInvalidationInvalidated!.bsa, che contiene una dummy texture non utilizzata nel gioco, in modo da essere avvertito in tempo sufficiente della presenza di file esterni ai BSA vanilla, scansionando quindi correttamente i vari i loose file presenti in \data. L'operazione va eseguita una sola volta e dimenticata per sempre. Qualunque texture pack installeremo verrà d'ora in poi caricato correttamente dal gioco.
La configurazione di WB è completata, ora vedremo come installare i nostri mod.
L'installazione del nostro primo mod
Installeremo un mod che non dovrebbe mancare in nessuna installazione di Oblivion, pertanto al pari dei plugin di OBSE installati addietro verrà considerato fra i mod essenziali. Ricordate di quando abbiamo accennato al problema del cell buffer purging? Per ovviare al problema si dovrebbe prendere l'abitudine di dare periodicamente il comando pcb [Purge Cell Buffer] da console, ma è molto meglio avere chi lo fa automaticamente per noi. A questo ha pensato in passato il mod Streamline, ma Streamline possiede una serie di funzioni ormai obsolete sulle macchine moderne e installarlo solo per avere un sistema automatizzato di buffer purging non vale la pena. Molto meglio avere a disposizione un plugin che si occupi solo di buffer purging, come il neonato ExPCB, che accoppiato ad OSR esegue un gran bel lavoro nel mantenere la sessione di gioco pulita da schifezzuole varie. Scarichiamo ExPCB da qui (http://www.nexusmods.com/oblivion/mods/38441), sezione Files > Main files > ExPCB Eng e salviamolo in Directory Installazione\Oblivion Mods\Bash Installers. Avete letto bene, non lo salveremo nella nostra directory OblivionSetup dove finora abbiamo conservato tutto ma nella directory di BAIN. D'ora in poi scaricheremo qualunque mod in questa particolare directory in modo che BAIN lo possa installare correttamente via Wrye Bash. In futuro potreste voler spostare tutto quanto abbiamo scaricato finora dalla nostra directory OblivionSetup alla directory di BAIN e re-installare quei mod in BAIN per fare ordine. Per ora non è necessario, lasciate quei file dove sono.
Torniamo in Wrye Bash e selezioniamo la tab Installers. Se non vi vedete nulla di nuovo clickate col dx e dal menu selezionate Refresh Data. Ehilà, è comparso un nuovo package! Ed è proprio quello che abbiamo scaricato. Clickate una o più volte sull'header Order in modo da visualizzare i package in ordine di installazione. ==Last== dovrebbe comparire per ultimo, con il load order 1, mentre il nostro package ExPCB_Eng-38441-1.7z dovrebbe comparire con l'ordine 0.
Un momento, mi pare di sentire arrivare qualche obiezione dal fondo della fila.. ma la buona norma non diceva di installare sempre per prime le patch non ufficiali? Perchè stiamo andando controcorrente? Semplice: con Wrye Bash non abbiamo alcun bisogno di rispettare alcun ordine di installazione dei package così come facevamo manualmente o con OBMM. Semplicemente, se ci accorgeremo di dover sistemare qualcosa ci basterà spostare il package nell'ordine corretto ed eseguire la funzione Anneal ["tempra"], che dove necessario riallineerà i file decompressi e installati in \data prelevandoli dai package originali presenti nella directory di BAIN. Pertanto ci possiamo sentire perfettamente liberi di installare prima ExPCB e POI le Unofficial Patch, che provvederemo a sistemare nell'ordine corretto. Ora torniamo al nostro ExPCB.
Prima di vedere come installarlo inseriamolo in una categoria sufficientemente generica, ad esempio TWEAKS per indicare i mod che rifiniscono il comportamento del motore del gioco. Clickiamo col dx e dal menu scegliamo Add Marker. Comparirà un nuovo dummy package di nome ====, noi chiamiamolo ==TWEAKS== e diamo invio. Se necessario assicuriamoci che i package siano tuttora ordinati per ordine di caricamento clickando su Order, dopodichè teniamo premuto il sx sul package ExPCB e trasciniamolo fra ==TWEAKS== e ==Last==. In alternativa possiamo spostare il package selezionato con la combinazione CTRL + freccia su/giù. L'ordine dei package dovrà essere il seguente:
Package Order
==TWEAKS== 0
ExPCB_Eng_38441-1.7z 1
==Last== 2
I marker altro non sono che dei package vuoti alla pari di Last. In un'installazione pesantemente moddata potremmo volerne creare diversi, ad esempio GUI per quelli che modificano l'interfaccia grafica, TEXTUREPACK per quelli che installano nuove texture, etc.
Ora selezioniamo col sx il nostro package ExPCB e diamo un'occhiata a cosa accade nel box di destra. Nella tab General vedremo un riassunto delle caratteristiche del Package, nel tab Matched non vedremo nulla, nella tab Missing vedremo un elenco dei file del package assenti in locale [perchè non lo abbiamo ancora installato], tutte le altre saranno vuote. Diamo un'ultima occhiata alla tab General: nella sezione Configured Files vedremo i file che saranno installati in \oblivion\data:
== Configured Files
ExPCB.esp
Docs\Readme.txt
ini\ExPCB.ini
TUTTI i file installati da Wrye Bash hanno come directory radice \oblivion\data, sebbene il percorso completo dei file venga omesso dall'elenco. Pertanto ExPCB.esp andrà a finire sotto oblivion\data, Readme.txt andrà a finire sotto \oblivion\data\Docs ed ExPCB.ini andrà a finire sotto oblivion\data\ini . A questo proposito è bene precisare che gli archivi dei mod per poter essere installati in BAIN devono essere in formato BAIN-ready, ovvero avere al loro interno una struttura ad albero identica a quella di \oblivion\data. Normalmente quasi tutti gli archivi sono così costruiti, ma alcuni potrebbero avere una struttura particolare che richiede qualche rimaneggiamento, come ad esempio la presenza di tutti i file sotto un'ulteriore directory col nome del mod, cosa che BAIN non è in grado di riconoscere. Nel caso si scaricassero dei mod con tale struttura, essi vanno prima decompressi e ricostruiti propriamente, per poi essere nuovamente compressi.
Guardiamo un poco più in basso e vediamo che il box Sub-Packages è rimasto vuoto. E' corretto, poichè il package scaricato non contiene nessun sub-package, caratteristica di mod di grandi dimensioni che suddividono il package in diverse sezioni a seconda di cosa si voglia installare. L'utente potrebbe ad esempio voler installare solo una parte di un texture pack che offre la possibilità di migliorare le texture di rocce, alberi, murature, eccetera. In quel caso il modder dovrebbe aver avuto cura di suddividere il package in diversi sub-package con vari nomi come [i]rocce, alberi, murature selezionabili singolarmente via BAIN.
In basso a destra nel box Esp/m Filter troviamo gli eventuali ESM ed ESP facenti parte del mod. Sarà perfettamente normale trovare tale box vuoto in caso di mod come i texture pack migliorativi delle texture esistenti, che non necessitano di ESP per caricare i loose file delle varie texture. Assicuriamoci che sia presente il check su ExPCB.esp, indicando a WB che saremo intenzionati ad installare anche quel file.
L'ultimo box in basso è utile per indicare qualche nota personale sul mod. Tranquilli, WB non ha accesso online e le leggerete solo voi, pertanto siete liberi di scriverci dentro questo mod fa schifo. Scriviamoci "Il mio primo mod!" tanto per verificare il funzionamento del box. Non c'è nessuna funzione di salvataggio della nota, verrà automaticamente salvata all'uscita di WB.
Ora, finalmente, installiamo il mod! Nel box di sx clickiamo col dx sul package ExPCB e dal menu scegliamo Install. Notiamo che il piccolo box di fianco al package è passato da rosa [non installato] a verde con all'interno un + . Le varie tab han cambiato aspetto, tutto ciò che era elencato in Missing è ora finito in Matched, e il riassunto nella sezione ==Overview della tab General si è aggiornato di conseguenza.
Spostiamoci nella tab Mods, verifichiamo la presenza di ExPCB.esp nell'elenco e attiviamolo con un singolo click sul piccolo box verde.
Fine! Questa è l'installazione dei mod in BAIN. Per disinstallarli basta seguire la procedura opposta, clickandovi su col dx e selezionando Uninstall. Il package originale che avete scaricato NON verrà cancellato. Se date un'occhiata nella directory \oblivion\data potrete verificare che sono stati aggiunti i file contenuti nel package ExPCB.
Ora, un ultimo dettaglio prima di proseguire: riordiniamo automaticamente gli ESP con BOSS! Chi di voi possiede le espansioni e/o i DLC potrebbe avere un buon elenco di ESP. Tutti gli altri dovrebbero vedere in elenco solo oblivion.esm, ExPCB.esp e la misteriosa Bashed Patch, il cui scopo verrà illustrato più avanti.
Date un'occhiata in basso a sinistra sulla barra di stato. C'è una serie di icone fra cui una con su scritto BOSS, non molto leggibile a dire il vero. Clickiamoci su una singola volta col sx e attendiamo il caricamento di BOSS. Wrye Bash sembrerà andare in freeze, attendete qualche istante e verrà aperta una pagina del vostro browser predefinito con il report del riordinamento. Essendo la prima volta che lanciate BOSS porebbe anche apparirvi una pagina con l'help. Quella di nostro interesse è Better Oblivion Sorting Software Log. Se volete potete dare un'occhiata veloce al report, dopodichè potete chiudere il browser. Tutto qui? Tutto qui. BOSS non richiede nessuna interazione lato utente, deve essere semplicemente lanciato [o da Wrye Bash o dal menu avvio di Windows] e come output visualizza il report, indicando che ha completato quanto richiesto: si è collegato al server contenente la masterlist, se necessario ha aggiornato la copia locale, dopodichè ha riordinato tutti gli ESP. Tale operazione andrà eseguita [i]ogni volta che si installerà un nuovo mod. Torniamo in Wrye Bash.
Nella tab mods quando ordinata per Load Order dovreste vedere, al minimo, quanto segue:
Oblivion.esm
ExPCB.esp
Bashed Patch, 0.esp
Chi possiede la GOTY vedrà quanto segue:
Oblivion.esm [SI]
DLCShiveringIsles.esp
ExPCB.esp
DLCHorseArmor.esp
DLCOrrery.esp
DLCVileLair.esp
DLCMehrunesRazor.esp
DLCSpellTomes.esp
DLCThievesDen.esp
DLCBattlehornCastle.esp
DLCFrostcrag.esp
Knights.esp
Bashed Patch, 0.esp
In più i possessori della GOTY dovrebbero notare che ogni singolo DLC all'infuori di Shivering Isles è ora sottolineato. Wrye Bash ci indica così gli ESP contenente dei dirty edits così come rilevato da BOSS. Potete vedere i dettagli di quanto rilevato in due modi: posizionando il puntatore del mouse sul singolo ESP e leggendo la nota nella barra di stato in basso, o clickando sull'icona Mod Checker sulla barra in basso [l'ultima a destra prima del ?] per visualizzare una nuova finestra con un report dettagliato. Nella Parte IV - rifinire l'installazione - vedremo come ripulire tali record con Tes4Edit.
Ora proseguiamo l'installazione base aggiungendo le patch non ufficiali.
L'installazione delle Unofficial Patch con Wrye Bash
Le Unofficial Patch non dovrebbero mancare in nessuna installazione di Oblivion, sia che si intenda moddarlo sia che si intenda lasciare il gioco nel suo stato vanilla. Ad oggi correggono quasi 2mila bug di diversa natura [quest non completabili, meshes e textures errate e così via] e sono da ritenersi un mod essenziale per chiunque. Iniziamo con lo scaricare la Unofficial Oblivion Patch da qui (http://www.nexusmods.com/oblivion/mods/5296), sezione Files > Main files > Unofficial Oblivion Patch v3_2_0 Manual Version e salviamola nella directory di BAIN [la solita \Oblivion Mods\Bash Installers]. Tenete presente che TESNexus richiede registrazione per il download di file superiori a 2Mb.
Apriamo Wrye Bash e andiamo sulla tab Installers. Il package Unofficial_Oblivion_Patch_v3_2_0_Manual_Version-5296.7z sarà comparso in elenco. Come abbiamo visto più indietro creiamo un nuovo marker di nome ==PATCH== e spostiamo il package Unofficial Oblivion Patch v3_2_0 Manual Version subito sotto tale marker. L'ordine dei package sarà il seguente:
Package Order
==PATCH== 0
Unofficial Oblivion Patch v3_2_0 Manual Version 1
==TWEAKS== 2
ExPCB_Eng_38441-1.7z 3
==Last== 4
Selezioniamo il package della UOP e prima di installarlo diamo un'occhiata nei box a destra. La tab General conterrà una lista di 2399 file fra meshes, texture e suoni che una volta installato il package verranno copiati in \data allo stesso modo di come è avvenuto con quelli di ExPCB. La nostra directory \oblivion\data si sta popolando di un sacco di loose file, referenziati dall'ESP Unofficial Oblivion Patch.esp che avremo cura di lasciare abilitato nel box Esp/m Filter. In tale box deselezioniamo invece Oblivion Citadel Door Fix.esp e UOP Vampire Aging & Face Fix.esp. Il primo è ignorabile, riguardo il secondo vedremo più avanti come sostituirne l'effetto tramite un tweak della Bashed Patch. Clickiamo col dx sul package della UOP, selezioniamo install e attendiamo l'estrazione dei file.
Se ci siamo scordati di deselezionare i due ESP Oblivion Citadel Door Fix.esp e UOP Vampire Aging & Face Fix.esp prima di installare il package, niente paura. Semplicemente deselezioniamoli ora, clickiamo col dx sul package della UOP e selezioniamo Anneal. Gli ESP verranno rimossi dalla directory locale \oblivion\data.
Spostiamoci sulla tab Mods e abilitiamo l'ESP Unofficial Oblivion Patch.esp.
Chi ha la GOTY o possiede l'espansione Shivering Isles deve scaricare la Unofficial Shivering Isles Patch da qui (http://www.nexusmods.com/oblivion/mods/10739), sezione Files > Main files > v1_4_0 Manual install 7Z version e installarla con BAIN allo stesso modo della UOP, avendo prima cura di spostare il package della USIP sotto quello della UOP. Il suo ESP andrà abilitato nella tab Mods.
Chi ha la GOTY o possiede uno o più DLC deve scaricare la Unofficial Official Mods Patch da qui (http://www.nexusmods.com/oblivion/mods/9969), sezione Files > Main files > Unofficial Official Mods Patch v15 Manual Version e installarla con BAIN, avendo prima cura di spostare il package della UOMP sotto quelli della UOP e della USIP. Nel box Esp/m Filter andranno abilitati solo gli ESP dei DLC in vostro possesso [lasciateli tutti abilitati se avete la GOTY]. L'ESP DLCThievesDen - Unofficial Patch - SSSB.esp è obsoleto e va lasciato disabilitato sia per chi ha la GOTY, sia per chi ha solo alcuni DLC. Tutti gli ESP installati andranno abilitati nella tab Mods.
Tutti quanti indipendentemente dalla versione posseduta devono scaricare gli Unofficial Oblivion Patch Supplementals da qui (http://www.nexusmods.com/oblivion/mods/27710), sezione Files > Main files > Unofficial Patch Supplementals e installarli con BAIN, avendo prima cura di spostare il package degli UOPS sotto quelli di UOP, USIP e UOMP. Nel box Sub-Packages tutti quanti dovranno abilitare 00 Unofficial Oblivion Patch Supplemental e verificare che nel box Esp/m Filter sia abilitato Unofficial Oblivion Patch.esp. Chi possiede espansioni e DLC vari dovrà abilitare i restanti compatibilmente con quanto posseduto. Chi ha la GOTY deve semplicemente abilitare tutto. Chi possiede i vari DLC o chi ha la GOTY vedrà apparire al termine dell'installazione un box informativo riguardo alle date modificate degli ESP installati. Al termine verifichiamo che nella tab Mods tutti gli ESP installati siano abilitati. Il vostro package order dovrebbe ora essere simile a questo:
Package Order
==PATCH== 0
Unofficial Oblivion Patch v3_2_0 Manual Version 1
v1_4_0_Manual_install_7Z_version-10739 2
Unofficial_Official_Mods_Patch_v15_Manual_Version-9969 3
Unofficial_Patch_Supplementals-27710-3-3-7 4
==TWEAKS== 5
ExPCB_Eng_38441-1.7z 6
==Last== 7
Indipendentemente dalla versione posseduta dovreste poter notare che uno o più package al di sopra di Unofficial Oblivion Patch Supplementals han cambiato colore. Sono diventati arancione, per indicare che sono in conflitto con altri package. Nel loro caso sono in conflitto proprio con la UOPS, poichè ne condividono file con lo stesso nome. E' un male? NO! E' perfettamente normale, è previsto e sarebbe un male se non fosse così. Semplicemente, la UOPS ha sovrascritto diversi file dei package precedenti con i suoi aggiornati. Lo potete verificare agevolmente nella tab Conflicts di ogni package.
Se avete sbagliato qualcosa nell'ordine dei package o nella selezione degli ESP non ricominciate da capo! Non ne avete alcun bisogno. Semplicemente riordinate i package come sopra indicato, abilitate gli ESP necessari come sopra indicato e usate una delle geniali funzioni di Wrye Bash: ANNEAL ALL [Ritempra tutto]. Click dx nella finestra di BAIN > Anneal All. Il comando non farà altro che riallineare tutti i file in locale compatibilmente con quanto avete riordinato e selezionato in BAIN. Mica male, eh?
Questo è quanto potrete aver bisogno di fare in futuro quando installerete dei mod che han necessariamente bisogno di un preciso ordine di installazione. Se per ipotesi installerete un mod che come da suo Readme esige di essere installato prima di ExPCB non dovrete aver bisogno di disinstallare ExPCB, installare il mod e reinstallare ExPCB. Semplicemente in BAIN posizionerete il mod PRIMA di ExPCB, installerete il mod e darete il comando Anneal All.
Dimenticatevi di tutti gli errori di installazione che potete aver commesso installando i mod manualmente o con OBMM, dimenticatevi di dover passare le notti a reinstallare tutto. Ora che avete Wrye Bash non avrete [i]mai più bisogno di rifare tutto da capo nè di scervellarvi a capire cosa dovete installare PRIMA, col rischio di mandare tutto a scatafascio se sbagliate l'ordine. Se certi mod avranno bisogno di essere installati in un certo ordine, semplicemente li posizionerete dove necessario e lancerete l'Anneal. E' o non è un gran bel pezzo di software? : )
Come ultimo particolare lanciate ancora una volta BOSS dall'icona di Wrye Bash in modo da riordinare al posto giusto gli ESP delle Unofficial Patch. La prossima volta che avvieremo Oblivion verremo accolti dal messaggio "Unofficial Oblivion Patch added", è un particolare oggetto dell'inventario per configurare i dettagli della UOP dall'interno di Oblivion. Non c'è bisogno di configurare nulla, le impostazioni di default van benissimo come sono.
Prima di proseguire fatevi un giretto in \oblivion\data. Potrete notare che rispetto alla nostra installazione vergine sono comparse più directory [textures, meshes, DistantLOD, etc.]. Sono tutti i loose file che abbiamo installato in BAIN, contenuti negli archivi compressi delle Unofficial Patch. Come accennato più indietro, questa directory col tempo si popolerà di un sacco di file, alcuni particolarmente piccoli come i file NIF delle meshes. Ragion per cui andrà deframmentata spesso, in particolare in seguito all'installazione di nuovi mod.
La nostra installazione base di Oblivion ha ormai preso forma quasi completa, ma prima di dichiararla conclusa dobbiamo ancora installare una piccola utility, dopodichè potremo passare alla Parte IV - Rifinire l'installazione - dove scenderemo più in profondità nell'uso di Wrye Bash e vedremo altri strumenti utili a limare per bene l'installazione.
L'installazione di RefScope
Quando la nostra installazione di Oblivion raggiungerà livelli mai visti prima potremmo aver bisogno di identificare all'interno di Oblivion a quale mod appartiene un oggetto problematico. Come? Con RefScope. Scarichiamolo da qui (http://www.nexusmods.com/oblivion/mods/21862), sezione Files > Main Files > RefScope 2_1_2 e salviamolo nella directory di BAIN. Andiamo nella tab Installers di Wrye Bash, creiamo un marker di nome ==TOOLS== e installiamo RefScope come da solita procedura. Ormai non ci dovrebbe essere bisogno di spiegare come, giusto? : )
Il vostro package order dovrebbe essere simile a questo:
Package Order
==PATCH== 0
Unofficial Oblivion Patch v3_2_0 Manual Version 1
v1_4_0_Manual_install_7Z_version-10739 2
Unofficial_Official_Mods_Patch_v15_Manual_Version-9969 3
Unofficial_Patch_Supplementals-27710-3-3-7 4
==TWEAKS== 5
ExPCB_Eng_38441-1.7z 6
==TOOLS== 7
RefScope_2_1_2-21862-2-1-2.zip 8
==Last== 9
Ricordatevi naturalmente di abilitare l'ESP di RefScope dalla tab Mods dopo aver installato il package. RefScope non ha conflitti di risorse con assolutamente nulla poichè risorse non ne usa [nessuna meshes, nessuna texture, etc], pertanto il suo package può essere posto dove ci pare. L'ho messo in quella posizione giusto per fare ordine. Anche l'ordine di caricamento del suo ESP non è granchè influente, ma è sempre bene lanciare BOSS dopo aver installato RefScope, come dovremo fare per qualsiasi altro futuro mod.
A questo proposito è bene chiarire alcuni concetti importanti nel caso non siano stati finora evidenti:
L'ordine di INSTALLAZIONE dei mod package va deciso manualmente dall'utente
L'ordine di CARICAMENTO degli ESP lo decide BOSS [d'altra parte è il boss.. ok, era brutta]
L'ordine di installazione dei package è influente solo quando vi sono conflitti di RISORSE, non hanno nulla a che vedere coi conflitti fra gli ESP e possono essere identificati agevolmente da Wrye Bash
L'ordine di caricamento degli ESP è influente solo quando ci sono conflitti di ENTITA' interne al gioco e non hanno nulla a che vedere coi conflitti fra i package. I conflitti controllati possono essere gestiti agevolmente da BOSS. I conflitti indesiderati che causano crash possono essere identificati solo dall'utente, disabiltando un ESP per volta e testando ogni volta il risultato nel gioco fino a rintracciare il mod incriminato.
Chiudiamo la parentesi e ritorniamo al nostro RefScope. Avviamo Oblivion e carichiamo il nostro salvataggio PrisonSewer02. Verremo accolti da una popup che ci informerà che RefScope è attivo, la hotkey di default sarà X e verrà abilitato il log grazie a ConScribe che abbiamo provveduto ad installare poco più su. Se vorrete cambiare il tasto di default X vi basterà clickare col dx sullo spell RefScope nel menu degli spells e seguire le voci del nuovo menu apparso. Nota: lo spell di configurazione di RefScope non dovrebbe mai essere selezionato col tasto sx come spell corrente. Limitatevi a selezionarlo col dx per eventuali configurazioni.
All'uscita delle fogne imperiali ci sono due rocce grandi poco più di un pallone da calcio, giusto ai piedi del gradone in pietra di fronte alla grata. Miriamo ad una delle due rocce e teniamo premuto il tasto X. La roccia verrà evidenziata da RefScope per indicarci che è pronto ad analizzarla. Senza rilasciare il tasto X premiamo il tasto Azione [predefinito: barra dello spazio] e comparirà una popup che ci dirà i dettagli dell'oggetto.
Una delle due rocce è la Reference 0012DBBA dello Static 0009DA3B. Entrambi risultano definiti in oblivion.esm. Significa che in oblivion.esm è presente un SINGOLO oggetto 0009DA3B [una roccia] che è ripetuto nel medesimo oblivion.esm una quantità spropositata di volte, fra cui una che si chiama 0012DBBA. La roccia che vediamo quindi nel gioco non è proprio quella roccia Static di nome 0009DA3B, ma una sua referenziazione, che in oblivion.esm si chiama 0012DBBA. Se analizziamo l'altra roccia con RefScope vedremo che lo Static è sempre quello ma la reference è diversa, infatti quella roccia si chiama 0012DBB9.
RefScope ci dà quindi modo di capire a quale ESM/ESP appartiene un entità del gioco, sia essa una creatura o un oggetto inanimato. Se Oblivion andrà in crash quando raccoglierete la spada generata dal mod MiaSpadonaTroppoFiga.esp saprete che quella spada appartiene ad un mod problematico. Ma come identificare a quale mod appartiene? Facile: punterete alla spada, premerete l'hotkey di RefScope e leggerete "Defined in MiaSpadonaTroppoFiga.esp". A quel punto saprete che MiaSpadonaTroppoFiga.esp è un mod da cestinare.
Inoltre, ricordate di quando parlando di wild edits abbiamo accennato a quanto sia sbagliato per un modder modificare le caratteristiche dell'oggetto originale? Bene, quell'oggetto originale non è nient'altro che lo Static. Se un domani vorrete imparare ad usare il Construction Set per eliminare quelle rocce che vi danno un sacco fastidio perchè all'uscita delle fogne ci inciampate, sappiate che dovrete disabilitarne le due Reference 0012DBBA e 0012DBB9, NON il loro Static 0009DA3B, in caso contrario disabiliterete TUTTE le rocce di quel tipo nel gioco. Notate che abbiamo parlato di disabilitazione e non cancellazione. Se ricordate quanto abbiamo accennato a proposito dei dirty edits DR vi ricorderete che le entità degli ESM si disabilitano, non si cancellano. Questo perchè un domani potrebbe capitarvi di installare un mod che fa riferimento proprio a quelle rocce per spostarle poco più in là, e non trovandole vi ritrovereste un bel crash proprio all'uscita delle fogne imperiali [della serie "iniziamo bene.."]. Parleremo a breve di come si ripuliscono dai mod i dirty edit di questo tipo. Nel frattempo puntiamo ancora una volta ad una delle due rocce con RefScope, usiamo il comando Save to Log per salvare nei log di ConScribe quanto abbiamo analizzato, creiamo un nuovo salvataggio PrisonSewer03 e usciamo da Oblivion. Nella directory oblivion\data\ConScribe Logs\Per-Mod vedremo che sono state salvate le informazioni sull'oggetto analizzato. Ci saranno utili per comunicarle eventualmente al modder del caso.
Ultima verifica prima di passare alla quarta parte della guida: apriamo Wrye Bash e diamo un'occhiata alla tab Saves. Dovreste rilevare quanto segue:
PrisonSewer01 è in arancione poichè da quando abbiamo creato quel salvataggio abbiamo cambiato l'ordine degli ESP con BOSS.
PrisonSewer02 è in verde poichè da quando abbiamo creato quel salvataggio abbiamo installato altri ESP dei quali quel salvataggio non fa uso.
PrisonSewer03 è in porpora [condizione ottimale] poichè gli attuali ESP elencati nella tab Mods corrispondono esattamente a quanto fa riferimento quel salvataggio.
E con quest'ultima verifica abbiamo concluso la terza parte della guida. Ora siamo pronti per scendere più in profondità nei meandri di Wrye Bash e dare un tocco di classe all'installazione, che nell'obiettivo di moddare pesantemente il gioco è lungi dall'essere completa, ma sta pian piano crescendo su solide fondamenta : )
Parte IV - RIFINIRE L'INSTALLAZIONE
Nella terza parte abbiamo installato Oblivion da zero, abbiamo migliorato le performance dell'installazione vanilla con alcuni plugin di OBSE e abbiamo imparato l'uso basilare di Wrye Bash. La nostra installazione base è già ad un livello molto solido, ma non è ancora pronta per essere pesantemente moddata. Prima dobbiamo ripulire i plugin preinstallati dalla GOTY [chi non ce l'ha segua comunque la guida per imparare come si fa, sarà necessario farlo con molti altri futuri mod], imparare ad usare la Bashed Patch ed eventualmente ottimizzare le meshes con PyFFI. Quest'ultima parte dato l'impegno molto gravoso per l'utente in termini di tempo verrà indicata come facoltativa.
Quanto segue prevede la modifica di file di Oblivion che se corrotti in qualche modo causa errori da parte dell'utente possono essere ripristinati solo in seguito a reinstallazione. E' quindi il momento di eseguire un backup dell'intera directory \oblivion\data creandone una copia di sicurezza da conservare in un posto sicuro, eventualmente nella nostra directory OblivionSetup.
IV.1 - La pulizia dei plugin con Tes4Edit
Nella prima parte abbiamo spiegato quanto sia importante pulire i plugin dai dirty edits, ora vediamo come. Scarichiamo Tes4Edit da qui (http://www.nexusmods.com/oblivion/mods/11536), sezione Files > Main files > TES4Edit_3_0_15_EXPERIMENTAL e salviamolo dove ci pare, eventualmente nella nostra buona vecchia directory OblivionSetup. Tes4Edit è un software a sè stante e non un mod, pertanto non andrà scaricato nella directory di BAIN. Preleviamo l'unico eseguibile dal file compresso ed estraiamolo nella directory \oblivion. Apriamo Wrye Bash e notiamo la presenza di una nuova icona a forma di cubo nella barra in basso con su scritto Edit. Prima di lanciare Tes4Edit diamo un'occhiata alla tab Mods di Wrye Bash. Potremo vedere che diversi ESP risultano sottolineati, è il modo in cui Wrye Bash ci informa di aver rintracciato dei plugin sporchi grazie al check eseguito da BOSS. Se abbiamo gli ESP ordinati per ordine di caricamento il primo plugin sporco che vedremo dall'alto in basso dovrà essere DLCHorseArmor.esp per chi possiede la GOTY. Puntiamoci su il puntatore del mouse e notiamo che nella barra di stato in basso viene indicato che tale ESP contiene 3 ITM e 0 UDR. Questi ultimi in realtà sono DR [Deleted Reference] e non UDR [Undeleted and Disabled Reference], ma la notazione UDR ha ormai preso piede per indicare entrambi i tipi di record. Prendiamo nota del nome del plugin e lanciamo Tes4Edit dalla barra in basso.
La finestra di avvio di Tes4Edit visualizzerà tutti gli ESP presenti in \oblivion\data in ordine di caricamento. E' estremamente importante pulire UN solo ESP per volta senza intaccare minimamente gli altri. Per fare ciò clickiamo col dx in un punto qualsiasi della finestra di avvio e scegliamo Select None per rimuovere tutti i flag dagli ESP elencati. Selezioniamo il solo DLCHorseArmor.esp e diamo OK. La finestra di avvio sparirà per lasciare il posto alla finestra principale di Tes4Edit, che notiamo essere divisa in due: nella parte sinistra viene visualizzato il plugin selezionato più i suoi master [che nel caso di DLCHorseArmor.esp è il solo oblivion.esm] che vengono caricati automaticamente nonostante non li si sia selezionati nella finestra di avvio, nella parte destra vengono visualizzati i messaggi del software. Attendiamo qualche istante perchè Tes4Edit carichi tutto il necessario. Nella parte destra dovrebbe apparire in fondo il messaggio Background Loader: finished.
Tes4Edit è uno strumento estremamente potente per individuare i conflitti fra gli ESP, ma noi ci limiteremo ad usarlo unicamente per la pulizia. Clickiamo col dx in un punto libero qualsiasi della parte di sinistra e dal drop-down menu scegliamo Apply Filter. Nella nuova finestra impostiamo tutti i flag così come li vediamo in questa (http://cs.elderscrolls.com/constwiki/images/3/3c/Tes4editcleaningfilter.jpg) schermata. Di fatto tutti i flag principali vanno disabilitati e va abilitato il solo "Conflict status inherited by parent". I flag rimarranno in quello stato fra una sessione e l'altra di Tes4Edit, pertanto è necessario impostarli una sola volta, ma ogni volta va comunque applicato il filtro. Dopo aver impostato tutto come si deve clickiamo su Filter e attendiamo qualche istante. Al termine del filtraggio nella parte destra della finestra vedremo apparire il messaggio Processed Records seguito dalla quantità di record processati.
Ora nella parte sinistra della finestra clickiamo col dx su [01] DLCHorseArmor.esp e dal menu scegliamo Undelete and Disable References. Apparirà un Warning al quale daremo Yes. Nella parte destra della finestra vedremo comparire il messaggio "Processed records: 167 - Undeleted Records: 0". Significa che Tes4Edit su 167 record processati nell'ESP DLCHorseArmor.esp non ha rintracciato nessun DR. In caso contrario ci avrebbe indicato quali e quanti record cancellati sarebbero stati rintracciati per poi essere ripristinati e disabilitati.
Clickiamo ancora una volta col dx su DLCHorseArmor.esp e selezioniamo Remove Identical to Master records. Nel caso apparisse un ulteriore Warning diamo ancora una volta Yes. Nella parte destra della finestra vedremo comparire il messaggio "Processed records: 167 - Removed Records: 3". Significa che Tes4Edit su 167 record processati nell'ESP DLCHorseArmor.esp ha rintracciato 3 record per i quali l'autore dell'ESP aveva modificato qualche parametro per poi riportarli allo stato originale, operazione che come abbiamo accennato nella prima parte non fa altro che aumentare inutilmente le dimensioni dell'ESP e genera inutili conflict check da parte del gioco.
La pulizia è terminata, chiudiamo Tes4Edit con la X in alto a destra e vedremo apparire una finestra di conferma salvataggio. Lasciamo il flag abilitato sull'ESP DLCHorseArmor.esp e diamo OK per confermare le modifiche. Se valutate di aver sbagliato qualcosa togliete il segno di spunta all'ESP e date OK, Tes4Edit uscirà senza salvare. Nel tornare nella finestra di Wrye Bash verremo accolti da una popup che ci informa a proposito della data modificata per DLCHorseArmor.esp, diamo semplicemente OK e notiamo come il plugin DLCHorseArmor.esp non sia più sottolineato. E' perchè l'abbiamo pulito! Come ulteriore verifica potete lanciare BOSS e notare come nel suo report non venga più indicato che DLCHorseArmor.esp è sporco, mentre tale indicazione è ovviamente ancora presente per diversi altri plugin ["Needs Tes4Edit cleaning"].
Se andate a dare un'occhiata in \oblivion\data vedrete che Tes4Edit ha creato un backup dell'ESP originale, col nome DLCHorseArmor.esp.backup.data. Come accennato nella terza parte Oblivion ha seri problemi quando i file contenuti in \oblivion\data superano i 400, pertanto se avete creato un backup dell'intera directory \oblivion\data sarebbe bene cancellare il file DLCHorseArmor.esp.backup.data per non affollare ulteriormente la directory.
Ora che sappiamo come pulire gli ESP proseguiamo con tutti gli altri indicati come sporchi da Wrye Bash fino a pulirli tutti. Nota bene: va sempre e solo pulito UN plugin per ogni sessione di Tes4Edit. Aprite Tes4Edit, selezionate un solo plugin da pulire, procedete alla pulizia, salvate ed uscite. E' inoltre buona abitudine pulirli nell'ordine di caricamento, dall'alto in basso come visualizzati in Wrye Bash.
Per vostra comodità vi elenco tutti i plugin che dovreste pulire nella vostra attuale installazione se avete la GOTY:
DLCHorseArmor.esp
DLCOrrery.esp
DLCVileLair.esp
DLCMehrunesRazor.esp
DLCSpellTomes.esp
DLCThievesDen.esp
DLCBattlehornCastle.esp
DLCBattlehornCastle - Unofficial Patch.esp
DLCFrostCrag.esp
Knights.esp
Ora facciamo una cosa molto utile: creiamo un archivio compresso [con winrar, winzip, 7z o altro] di nome CleanedESPs.7z [personalmente uso 7zip] con dentro tutti i plugin puliti e mettiamolo nella directory di BAIN. Da Wrye Bash aggiungiamo un marker ==USERPATCH== e subito sotto posizioniamoci il nostro archivio. Il vostro package order a questo punto dovrebbe assumere questo aspetto:
Package Order
==PATCH== 0
Unofficial Oblivion Patch v3_2_0 Manual Version 1
v1_4_0_Manual_install_7Z_version-10739 2
Unofficial_Official_Mods_Patch_v15_Manual_Version-9969 3
Unofficial_Patch_Supplementals-27710-3-3-7 4
==TWEAKS== 5
ExPCB_Eng_38441-1.7z 6
==TOOLS== 7
RefScope_2_1_2-21862-2-1-2.zip 8
==USERPATCH== 9
CleanedESPs.7z 10
==Last== 11
Installiamo l'archivio via BAIN come siamo soliti fare, abilitando ogni flag sugli ESP nella sezione Esp/m Filter e dando il comando Install dal drop-down menu. Dal punto di vista della directory \oblivion\data al momento non cambierà nulla perchè ci stiamo copiando dentro i medesimi file. Provvederemo ad aggiornare tale archivio con gli ESP puliti mano a mano che installeremo e puliremo nuovi mod, in modo da non doverli ripulire nuovamente se ci capiterà di disinstallare e reinstallare il mod con l'ESP sporco. Va da sè che il package order di CleanedESPs dovrà essere sempre l'ultimo, poichè i suoi ESP puliti dovranno sovrascrivere gli eventuali ESP sporchi installati dai mod originali.
Piccola digressione: in futuro nella sezione USERPATCH potremo eventualmente aggiungere un ulteriore archivio personalizzato con dentro le nostre texture preferite che dovranno sovrascrivere quelle installate da certi mod. Se ormai siete entrati nell'ottica di BAIN avrete realizzato che il suo sistema di package ordering vi permette combinazioni infinite per l'installazione dei mod. Prendiamo ad esempio un mod come Oscuro's Oblivion Overhaul, che fra le altre cose sostituisce le texture degli Ogre con le sue personalizzate. Se abbiamo già installato un texture pack che sostituisce tutte le texture delle creature e che per qualche motivo richiede di essere installato PRIMA di OOO, perderemo la possibilità di vedere in Oblivion gli Ogre texturizzati dal pack, poichè verranno sovrascritti da OOO. Come fare? Semplicemente estraiamo dal pack la texture dell'Ogre, la inseriamo in un archivio MyTextures e via BAIN lo installiamo per ULTIMO, inserendolo nella nostra sezione personalizzata USERPATCH. In questo modo la texture di OOO sovrascriverà quella del pack, ma il nostro archivio personalizzato sovrascriverà nuovamente quella di OOO ripristinando l'originale del pack! Niente male, eh? : )
Chiudiamo la parentesi e passiamo oltre. Ora dobbiamo illustrare la più geniale funzione di Wrye Bash: la Bashed Patch!
IV.2 - La creazione della Bashed Patch
Se arrivati a questo punto avete ben chiaro il funzionamento del caricamento degli ESP in Oblivion avrete sicuramente ormai ben radicato in mente un concetto chiave: l'ultimo ESP caricato vince. Ribadiamo il concetto con un esempio già visto:
ESP A cambia la potenza di una spada
ESP B cambia la portata della medesima spada
A seconda di quale ESP viene caricato per ultimo avremo in Oblivion solo UNA delle due modifiche
Non sarebbe bello poterle avere [i]entrambe invece di dover rinunciare ad una delle due? In condizioni ideali si dovrebbe ottenere in qualche modo un unico ESP che fa entrambe le cose, ma contattare gli autori di due mod diversi e pregarli di unire le forze non sembra una grande idea. Chi sa usare il CS potrebbe importare in un unico ESP le caratteristiche di entrambi i mod, ma non dovrebbe essere un'attività demandata all'utente medio. Molto meglio se ci pensa qualcun altro al posto nostro: Wrye Bash.
La soluzione che ci offre Wrye Bash è aggiungere ai due ESP di cui sopra un terzo ESP che importi in Oblivion le caratteristiche di entrambi gli ESP, dopo averli scansionati e aver identificato cosa va importato dall'uno e dall'altro. Questo particolare ESP altro non è che la Bashed Patch.
L'abbiamo già vista nella tab Mods di Wrye Bash, al fondo del load order, e i più attenti si saranno accorti che la sua dimensione è al momento pari a 0Kb . E' normale poichè al momento non contiene nulla, all'infuori dell'header identificativo per permetterle di essere riconosciuta da Oblivion come un ESP a tutti gli effetti e caricata di conseguenza. Su installazioni pesantemente moddate raggiungerà le dimensioni di diversi Mb. A breve vedremo come si importano i record dei vari ESP nella Bashed Patch.
Selezioniamo la Bashed Patch con un singolo click sx e diamo un'occhiata nel box Masters a destra: notiamo che al momento è completamente vuoto. Col tempo si popolerà con una lista degli ESP da cui avremo importato i record necessari.
Come facciamo a sapere quali siano i record da importare e da quali ESP? Semplice: non abbiamo bisogno di saperlo. A questo ci pensa BOSS, che integrandosi con Wrye Bash provvede a contrassegnare tutti gli ESP di cui si conosce la necessità di importazione nella Bashed Patch con una serie di tag, che possiamo vedere nel box Bash Tags in basso a destra. La Bashed Patch ovviamente ne è priva perchè non può essere importata su se stessa, ma se clickiamo su Unofficial Oblivion Patch.esp ne vedremo una lunga lista. Si tratta di record che gli autori della UOP hanno indicato al mantainer di BOSS come indispensabili da mantenere attivi. Non ci dilungheremo sul significato dei vari tag, vi basti sapere che identificano tutta una serie di record che verranno importati nella Bashed Patch per assicurarsi che la Unofficial Oblivion Patch funzioni a dovere [i]anche in presenza di successivi ESP che ne modificano i contenuti. Per fare un semplice esempio, la UOP prevede la correzione di nomi malformati di alcune celle del gioco. Per evitare che un qualsiasi mod riporti erroneamente i nomi delle celle all'errato stato originale, la UOP viene contrassegnata col tag C.Name. Durante la creazione della Bashed Patch, Wrye Bash importerà i record necessari dalla UOP alla Bashed Patch, che venendo caricata per ultima sovrascriverà qualunque modifica eseguita da ESP caricati dopo la UOP.
E questo è solo UNO dei casi in cui può emergere la necessità di importare dei record nella Bashed Patch. Con qualcosa come 23mila file sul solo TesNexus che si traducono grezzamente in circa 15/20mila mod potete immaginare quante diverse combinazioni di importazione record si potrebbero incontrare.
Ne consegue che qualunque tipo di installazione di Oblivion, dalla leggermente moddata alla moddata a livelli stellari DEVE avere una Bashed Patch opportunamente creata. La sua importanza per il corretto funzionamento delle meccaniche del gioco è BASILARE. Un altro vantaggio dato dalla Bashed Patch è poter superare un limite di Oblivion riguardo la quantità massima di ESP caricabili [255], importando completamente diversi piccoli ESP per poi poterli disabilitare completamente dal Load Order, di conseguenza liberando uno slot.
Nota importante: prima di creare una Bashed Patch gli ESP dai quali devono essere importati i record vanno PULITI dai dirty edits. E' il motivo per cui in questa stessa guida abbiamo anticipato la pulizia degli ESP all'esposizione della Bashed Patch.
Ora vediamo come creare la nostra prima Bashed Patch. Chi possiede la GOTY o comunque altri ESP appartenenti a DLC vari può eventualmente dare prima un'occhiata alla lista dei tag degli altri ESP, per avere un'idea di cosa verrà importato nella Bashed Patch.
Clickiamo col dx su Bashed Patch, 0.esp e scegliamo dal drop-down menu la voce Rebuild Patch [NON la voce Rebuild Patch (CBash *BETA*), si tratta di una funzione avanzata ancora in sviluppo]. Chi possiede la GOTY potrebbe vedere visualizzata una popup con la richiesta di disattivazione di DLCSpellTomes - Unofficial Patches.esp. Rispondete Yes.
Vedrete apparire una nuova finestra divisa in due parti. A sinistra i rami principali dei tag e una serie di tweak, a destra la lista degli ESP importabili [poichè taggati propriamente] e i parametri dei tweak. Al default la configurazione della Bashed Patch è completamente vuota all'infuori di Alias Mod Names, che per ora non ci serve e possiamo disabilitare.
La Bashed Patch dovrebbe sempre avere, al minimo, i seguenti flag di Import abilitati. Selezioniamo nella parte sinistra i vari flag indicati e nella parte destra scegliamo Select All [alcuni box potrebbero essere vuoti, provvediamo comunque ad abilitarne il ramo principale nel parte sinistra].
Merge Patches [Select All]
Import Actors [Select All]
Import Actors: AIPackages [Select All]
Import Actors: Animations [Select All]
Import Actors: Death Items [Select All]
Import Actors: Spells [Select All]
Import Cells [Select All]
Import Factions [Select All]
Import Graphics [Select All]
Import Inventory [Select All]
Import NPC Faces [Select All]
Import Names [Select All]
Import Relations [Select All]
Import Roads [Select All]
Import Scripts [Select All]
Import Sounds [Select All]
Import Spell Stats [Select All]
Import Stats [Select All]
Inoltre dovrebbero essere sempre attivi i seguenti Tweak:
Tweak Actors > Vanilla Beast Skeleton Tweaker
Tweak Assorted > Bow Reach Fix
Tweak Names > Lore Friendly Names: Dwarven > Dwemer
Tweak Settings > UOP Vampire Aging and Face Fix
Inoltre dovrebbero essere sempre attivi i seguenti:
Contents Checker
Leveled List > Automatic
Race records [Select All]
SEWorld Tests
Tutti le altre voci rimanenti nella parte sinistra andrebbero lasciate disabilitate.
Volendo possiamo dare un'occhiata ai tweak e selezionare quelli di nostro gusto, ve ne sono diversi interessanti come il poter modificare la distanza della telecamera in terza persona dal PG o aumentare il tempo di respawn delle celle. Quando abbiamo terminato di selezionare tutto il necessario clickiamo su Build Patch. La costruzione della Bashed Patch su certe macchine potrebbe impiegare anche diversi minuti. Al termine verrà visualizzata una popup informativa con quanto importato nella Bashed Patch, clickiamo su OK e se nella lista Mods la Bashed Patch non era stata precedentemente attivata ci verrà richiesto se abilitarla o no. Rispondiamo sì e diamo un'occhiata al nostro ESP Bashed Patch, 0.esp nella lista Mods.
Le sue dimensioni sono aumentate a circa 4Mb, ma ciò che è interessante rilevare è cosa è ora indicato nei box a destra. Nel box Description possiamo vedere che la Bashed Patch, pur avendo a che fare con pochi ESP, ha importato la bellezza di oltre 5mila record [chi non ha la GOTY potrebbe leggere valori inferiori]. Si tratta di 5mila correzioni di record di cui potrete benificiare nel gioco, di molte senza che nemmeno ve ne accorgiate. Nel box Masters potrete vedere tutta la lista degli ESP da cui sono stati importati dei record. Clickando nel box apparirà un Warning riguardo l'edit della lista. E' una funzione per sostituire eventualmente ESP corrotti dalla Master list e di cui potreste non aver mai bisogno, potete dare indifferentemente Ok o Cancel, l'importante è che al momento non tocchiate nulla. Eventualmente potrete documentarvi più avanti sul suo scopo grazie all'help di Wrye Bash.
Chi possiede la GOTY noterà che DLCSpellTomes - Unofficial Patch.esp è elencato nella tab Mods con un + verde invece del canonico flag. Significa che l'ESP è stato completamente importato nella Bashed Patch per poi essere disabilitato. E' tuttora visualizzato nel Load Order semplicemente per completezza, ma in realtà Oblivion non lo prenderà nemmeno in considerazione. Se durante la configurazione di Wrye Bash vi siete inoltre ricordati di abilitare l'Auto-Ghost potrete notare che nella directory \oblivion\data il file DLCSpellTomes - Unofficial Patch.esp è stato rinominato da Wrye Bash in DLCSpellTomes - Unofficial Patch.esp.ghost in modo da non concorrere nel conteggio limite dei 400 file della directory \data.
In seguito all'installazione di ulteriori mod potreste aver bisogno di ricostruire la Bashed Patch. E' buona abitudine farlo sempre quando notate che l'ESP installato possiede dei Bash Tag. Notate che alcuni mod particolari come All Natural lo richiederanno espressamente.
A questo punto la nostra installazione di Oblivion è stabile come una roccia e pronta per accogliere qualunque tipo di mod, compatibilmente con le caratteristiche hardware della nostra macchina. Avviamo Oblivion e carichiamo il nostro ultimo salvataggio PrisonSewer03. Chi ha la GOTY e di conseguenza ha importato e disabilitato DLCSpellTomes - Unofficial Patch.esp nella Bashed Patch verrà accolto dalla popup del contenuto mancante. E' corretto, poichè tale ESP non esiste più: l'abbiamo completamente importato nella Bashed Patch, ma ovviamente Oblivion non può saperlo. Diamo Yes per confermare il caricamento e creiamo un nuovo salvataggio PrisonSewer04, che come abbiamo accennato più indietro diventerà il nostro nuovo clean save.
Chi pur non avendo alcun interesse nel moddare Oblivion ha seguito la guida per rendere la sua installazione vanilla solida e reattiva può fermarsi qui e iniziare finalmente una nuova partita con tutti i crismi.
Gli altri proseguano nella lettura, abbiamo ancora molta strada da percorrere : )
IV.3 - Funzioni utili di Wrye Bash
Ora dovreste già avere abbastanza dimestichezza con Wrye Bash per poter girovagare fra le sue funzioni senza paura, non proseguiremo nello spiegarle tutte ma qualche dritta in più non fa male.
Per salvare l'attuale lista degli ESP, in modo da sperimentare con più combinazioni di mod diverse, clickiamo col dx nella tab Mods e scegliamo Load > Save List. Diamo ora un nome alla nostra attuale lista e chiamiamola PatchedVanilla. Comparirà in elenco nel medesimo menu, pronta per essere ricaricata all'occorrenza. Notate che è già presente la voce Bethesda ESMs, che di fatto disabiliterà tutti gli ESP lasciando attivo il solo oblivion.esm [utile per disabilitare tutti gli ESP e testare poi un solo ESP per volta].
La funzione Mod Checker attivabile dalla barra in basso fornirà un report su eventuali problemi nella lista degli ESP [master mancanti, dirty edits, eccetera]. In condizioni normali dev'essere vuota. La funzione Scan for Dirty Edits nella finestra del Mod Checker è al momento in beta e manda spesso in crash WB, è vivamente sconsigliato usarla. Molto meglio affidarsi al check di BOSS.
Per poter copiare agevolmente l'ordine di caricamento in modo da incollarlo sui forum di aiuto clickiamo col dx nella tab Mods e scegliamo List Mods. La lista è preformattata coi tag SPOILER e XML dei forum ufficiali di Bethesda. Qui su HwUP non vengono riconosciuti, pertanto è bene sostituire i due tag con l'unico tag QUOTE prima di incollare la lista in un post. Quanto segue è la lista attuale della nostra installazione, per chi possiede la GOTY:
Active Mod Files:
00 Oblivion.esm [CRC: 2FF840C5]
01 Unofficial Oblivion Patch.esp [Version 3.3.7] [CRC: 6AB8F177]
02 DLCShiveringIsles.esp [CRC: 2BB84977]
03 Unofficial Shivering Isles Patch.esp [Version 1.4.4] [CRC: F6C1D21D]
04 ExPCB.esp [CRC: B66B4951]
05 DLCHorseArmor.esp [CRC: BD0084C5]
06 DLCHorseArmor - Unofficial Patch.esp [Version 1.0.6] [CRC: 00F74B09]
07 DLCOrrery.esp [CRC: 351A3894]
08 DLCOrrery - Unofficial Patch.esp [Version 1.0.4] [CRC: 9AA76E38]
09 DLCVileLair.esp [CRC: 3B6E3A93]
0A DLCVileLair - Unofficial Patch.esp [Version 1.0.7] [CRC: 5B9FF91B]
0B DLCMehrunesRazor.esp [CRC: FD5BE3C6]
0C DLCMehrunesRazor - Unofficial Patch.esp [Version 1.0.5] [CRC: FF57D0F8]
0D DLCSpellTomes.esp [CRC: 02FA9682]
++ DLCSpellTomes - Unofficial Patch.esp [Version 1.0.1] [CRC: 8CC91BA1]
0E DLCThievesDen.esp [CRC: 7F76D2D3]
0F DLCThievesDen - Unofficial Patch.esp [Version 1.0.10] [CRC: 401934BE]
10 DLCBattlehornCastle.esp [CRC: BEE27F25]
11 DLCBattlehornCastle - Unofficial Patch.esp [Version 1.0.6] [CRC: 0F1BBF7E]
12 DLCFrostcrag.esp [CRC: FBEE32B7]
13 DLCFrostcrag - Unofficial Patch.esp [Version 1.0.5] [CRC: 5744D6B8]
14 Knights.esp [CRC: 4CB1DF3D]
15 Knights - Unofficial Patch.esp [Version 1.1.2] [CRC: 2F15B12C]
16 RefScope.esp [Version 2.1.2] [CRC: 09E4EE27]
17 Bashed Patch, 0.esp [CRC: 120EC898]
Allo stesso modo si può copiare la lista dei package dalla tab Installers, col comando click dx > List Packages:
Bain Packages:
000 - ==PATCH==
++ 001 - Unofficial_Oblivion_Patch_v3_2_0_Manual_Version-5296.7z (BCBA7B56) (Installed)
++ 002 - v1_4_0_Manual_install_7Z_version-10739.7z (79CE866D) (Installed)
++ 003 - Unofficial_Official_Mods_Patch_v15_Manual_Version-9969.7z (59895567) (Installed)
++ 004 - Unofficial_Patch_Supplementals-27710-3-3-7.7z (7807463F) (Installed)
005 - ==TWEAKS==
++ 006 - ExPCB_Eng-38441-1.7z (AE27691D) (Installed)
007 - ==TOOLS==
++ 008 - RefScope_2_1_2-21862-2-1-2.zip (A57B7DD5) (Installed)
009 - ==USERPATCH==
++ 010 - CleanedESPs.7z (C3F4959E) (Installed)
011 - ==Last==
Per visualizzare tutti gli ESP dei quali sono stati importati uno o più record nella Bashed Patch, nella tab Mods clickiamo col dx sulla Bashed Patch e scegliamo List Masters:
Masters for: Bashed Patch, 0.esp
00 Oblivion.esm [CRC: 2FF840C5]
01 Unofficial Oblivion Patch.esp [Version 3.3.7] [CRC: 6AB8F177]
02 Unofficial Shivering Isles Patch.esp [Version 1.4.4] [CRC: F6C1D21D]
03 DLCHorseArmor.esp [CRC: BD0084C5]
** DLCHorseArmor - Unofficial Patch.esp [Version 1.0.6] [CRC: 00F74B09]
04 DLCOrrery.esp [CRC: 351A3894]
05 DLCVileLair.esp [CRC: 3B6E3A93]
** DLCVileLair - Unofficial Patch.esp [Version 1.0.7] [CRC: 5B9FF91B]
06 DLCMehrunesRazor.esp [CRC: FD5BE3C6]
** DLCMehrunesRazor - Unofficial Patch.esp [Version 1.0.5] [CRC: FF57D0F8]
07 DLCSpellTomes.esp [CRC: 02FA9682]
++ DLCSpellTomes - Unofficial Patch.esp [Version 1.0.1] [CRC: 8CC91BA1]
08 DLCThievesDen.esp [CRC: 7F76D2D3]
09 DLCThievesDen - Unofficial Patch.esp [Version 1.0.10] [CRC: 401934BE]
0A DLCBattlehornCastle.esp [CRC: BEE27F25]
0B DLCBattlehornCastle - Unofficial Patch.esp [Version 1.0.6] [CRC: 0F1BBF7E]
0C DLCFrostcrag.esp [CRC: FBEE32B7]
** DLCFrostcrag - Unofficial Patch.esp [Version 1.0.5] [CRC: 5744D6B8]
0D Knights.esp [CRC: 4CB1DF3D]
0E Knights - Unofficial Patch.esp [Version 1.1.2] [CRC: 2F15B12C]
Maggiori informazioni sull'uso di Wrye Bash sono consultabili nell'help clickando su ? nella barra in basso. E' bene precisare che al momento l'help si riferisce a vecchie versioni di WB e non sempre quanto riportato corrisponde a quanto è presente nel software.
IV.4 - L'installazione di OBMM
Wrye Bash è ora diventato il nostro mod manager principale e se siete arrivati fino a qui ne avrete ormai apprezzato le grandi potenzialità. Attualmente però ha ancora tre limiti:
Non può installare mod in formato OMOD
Non ha un'utility integrata per scompattare e ricomprimere i file BSA
Non può patchare gli shader vanilla
Utilizzeremo largamente le prime due funzionalità di OBMM per gestire i nostri file OMOD e BSA, mentre la terza sarà limitata all'installazione di un'unico particolare mod, tale Detailed Terrain, che necessita di modificare gli shader contenuti nella directory \oblivion\data\shaders.
Scarichiamo OBMM da qui (http://www.nexusmods.com/oblivion/mods/2097), sezione Files > Main files > obmm 1_1_12 full manual e salviamolo nella nostra directory OblivionSetup. Estraiamone tutto il contenuto in \oblivion e lanciamo Wrye Bash.
A causa della presenza di OBMM nel sistema verremo accolti da una richiesta di disabilitazione della funzione Lock Times, alla quale abbiamo accennato più indietro. Rispondiamo di NO. Lock Times fa sì che le date degli ESP, memorizzate internamente in Wrye Bash, vengano bloccate allo stato attuale per impedire ogni cambiamento accidentale nell'ordine di caricamento che potremmo eseguire usando OBMM. Notate che nella barra in basso è spuntata una nuova icona simile al logo di Oblivion con su scritto OBMM.
Come avrete ormai potuto realizzare, Wrye Bash integra agevolmente molti programmi orientati al modding di Oblivion. Mano a mano che aggiungeremo utility, esse verranno identificate da Wrye Bash per un più immediato utilizzo.
Molti di voi sapranno già usare OBMM per installare e rimuovere gli OMOD, ma noi NON lo useremo per questo motivo. Gli unici usi che ne faremo consisteranno nel decomprimere gli eventuali OMOD già scaricati e ricomprimerli in formato BAIN-ready, e nel decomprimere e ricomprimere i BSA dopo averne ottimizzati i file con PyFFI.
La conversione di mod da OBMM ad archivio compresso
NOTA BENE prima di iniziare: alcuni mod in formato OMOD una volta convertiti in archivio BAIN-ready NON possono essere installati correttamente in Wrye Bash poichè contenenti uno script di installazione riconosciuto solo da OBMM. E' ad esempio il caso di DarNified UI, il cui OMOD una volta convertito in archivio BAIN-ready viene compreso da Wrye Bash nella sua sola forma di archivio contenente dei file risorsa, ignorandone gli script. Wrye Bash usa un sistema suo per gli script di installazione per mod particolarmente complessi, e non ha nessuna possibilità di interpretare gli script di OBMM. Pertanto prima di procedere alla conversione è bene capire tramite il Readme cosa il mod si proponga di installare e come. Nel caso si tratti di un mod che preveda l'installazione tramite script di OBMM è bene scaricarne una versione BAIN-ready, che il modder o chi per lui potrebbe già aver reso disponibile per il download. Ad esempio DarNified UI in formato BAIN-ready si trova qui (http://www.nexusmods.com/oblivion/mods/22170), sezione Files > Main files > DarNified UI 132-BAIN.
Nella Parte V - i mod consigliati - verrà indicato il link da dove scaricare i più comuni mod in formato BAIN-ready.
Lanciamo OBMM tramite la sua icona in Wrye Bash. Clickiamo su Load in basso e andiamo a puntare ad uno dei file OMOD che potremmo aver già scaricato. Il mod comparirà in elenco nella parte destra della finestra. NON clickateci sopra due volte o lo installerete, che NON è quello che vogliamo fare. Clickateci su col dx e scegliete Convert to archive. Dalla nuova finestra scegliete come destinazione la directory di BAIN, alla richiesta "Create omod conversion information" rispondete di No e attendete. Per mod molto pesanti come QTP3R l'operazione potrebbe richiedere parecchio tempo, ma è sempre meno del tempo che impieghereste a riscaricarne la versione BAIN-ready. Al termine apparirà un popup con indicato Conversion successful. Procedete allo stesso modo fino a che non avete convertito tutti i vostri OMOD, che potrete poi cancellare.
Notate che l'originale OMOD potrebbe essere stato pacchettizzato in un formato anomalo e incomprensibile da BAIN, ad esempio con la directory DATA contenuta in una serie di sottocartelle. Nel caso l'archivio dovrà prima essere estratto, ristrutturato in un formato comprensibile e ricompresso prima di poter essere installato il BAIN.
NOTA: gli OMOD possono essere estratti con Wrye Bash [ma NON installati] se si trascina il file OMOD in Wrye Bash nella tab Installers. Nella directory di BAIN verrà creata una directory con tutto il contenuto dell'OMOD [compresa la sottodirectory "omod conversion data" che in OBMM abbiamo escluso espressamente], che in Wrye Bash verrà indicato con un rombo per segnalare che si tratta di una directory e non un archivio compresso. Una volta ottenuta la directory compressa la si può comprimere in un archivio compresso per poterne installare il contenuto in BAIN, eventualmente dopo aver apportato i necessari cambiamenti alla struttura della directory.
Estrazione e compressione dei BSA tramite OBMM
Ci sono principalmente tre motivi per cui vorremmo estrarre il contenuto di un BSA: il primo è poterne ottimizzare le meshes con PyFFI, cosa che vedremo più avanti. Il secondo è decomprimere il file Oblivion - Textures - Compressed.bsa e ricomprimerlo in formato uncompressed, in modo da aumentare le prestazioni quando Oblivion dovrà caricarne i file. Il terzo è la curiosità di sapere cosa c'è dentro : )
Iniziamo col decomprimere proprio Oblivion - Textures - Compressed.bsa. Nella nostra directory OblivionSetup creiamo una nuova directory BSA.
Da OBMM clickiamo sul pulsante Utilities e scegliamo BSA Browser.
Comparirà una nuova finestra nella quale clickeremo sul pulsante Open. Andiamo a puntare alla directory \oblivion\data e apriamo Oblivion - Textures - Compressed.bsa. Dopo qualche istante ne verrà elencato l'intero contenuto.
La struttura del BSA vi dovrebbe essere familiare, è esattamente la stessa della directory \oblivion\data. Clickiamo su Extract All e andiamo a puntare alla nostra directory OblivionSetup\BSA. Attendiamo pazientemente, il file è grande e l'estrazione richiederà diversi minuti. Al termine clickiamo su pulsante Close e chiudiamo la finestra del BSA Browser. Nella nostra directory OblivionSetup\BSA sarà stata creata una directory textures contenente l'intera struttura del BSA appena decompresso. Ora ricomprimiamo il nostro bel malloppo di textures in formato BSA uncompressed.
Chiudiamo OBMM per liberare la ram impegnata dall'estrazione dell'archivio, che OBMM non è in grado di liberare autonomamente, e riapriamolo.
Clickiamo sul pulsante Utilities e scegliamo BSA Creator. Nella nuova finestra assicuriamoci che la voce nel menu a tendina in basso a sx indichi No compression, dopodichè premiamo il pulsante Add folder(s). Andiamo a puntare alla directory OblivionSetup\BSA, assicurandoci che nella finestra di dialogo sia evidenziata esattamente la directory BSA e non la sua sottodirectory textures, e diamo Ok. Attendiamo qualche istante e il contenuto della directory verrà visualizzato. Se abbiamo eseguito tutto correttamente la colonna Relative Path dovrà visualizzare i nomi dei file comprensivi della directory \textures. Clickiamo il pulsante Create, andiamo a puntare a \oblivion\data e nel Nome file scriviamo "Oblivion - Textures.bsa" [ovviamente senza virgolette]. Clickiamo Salva e attendiamo molto pazientemente. OBMM sembrerà andare in freeze, lasciamolo in pace qualche minuto e il file verrà creato. Non viene data nessuna indicazione riguardo l'avvenuta creazione del BSA, ce ne accorgeremo quando saremo nuovamente in grado di scorrere il contenuto della finestra del BSA Creator.
Chiudiamo OBMM e, just in case, invece di cancellare Oblivion - Textures - Compressed.bsa spostiamolo nella directory OblivionSetup. Nella directory \oblivion\data diamo un'occhiata al nuovo file Oblivion - Textures.bsa. A differenza del file compresso dovrebbe essere grande 2Gb, ma quello che dovremmo veramente notare è la sua data: 01/01/2006. Ma come? L'abbiamo creato adesso! E' la magia di Wrye Bash, che lasciato aperto in sottofondo ha individuato un nuovo file BSA in \oblivion\data e ha provveduto a modificarlo propriamente: per evitare che nella directory \oblivion\data siano presenti dei file più vecchi dei BSA, cosa che causerebbe problemi di caricamento dei loose file, ogni BSA viene automaticamente ridatato da Wrye Bash al 01/01/2006, data sicuramente antecedente ad ogni loose file che potremmo avere sotto \oblivion\data.
Come ultimo dettaglio dobbiamo indicare ad Oblivion che il file delle textures ha cambiato nome, in caso contrario nessuna texture vanilla verrà individuata. Apriamo oblivion.ini e cerchiamo la direttiva SArchiveList, dove cambieremo il nome del nostro BSA da Oblivion - Textures - Compressed.bsa a Oblivion - Textures.bsa.
Per verificare di aver eseguito il tutto correttamente lanciamo Oblivion e carichiamo il nostro salvataggio PrisonSewer04. In caso di problemi ce ne dovremmo accorgere immediatamente: se il nuovo BSA non verrà individuato correttamente, perchè ne abbiamo sbagliato il nome in oblivion.ini, nel menu principale vedremo i soli testi su sfondo bianco. Se abbiamo commesso qualche errore nella costruzione del file decompresso, una volta caricato il salvataggio vedremmo una marea di texture porpora.
Se sembra tutto in ordine possiamo uscire.
NOTA: chi non sopporta OBMM può utilizzare BSA Commander (http://www.nexusmods.com/oblivion/mods/3311) per gestire il contenuto dei BSA. Questo software, unito alla possibilità di decomprimere gli OMOD via Wrye Bash, vi permette di fare quasi completamente a meno di OBMM. L'unico uso per cui lo utilizzereste sarebbe l'installazione di mod estremamente particolari, come Detailed Terrain che necessita di patchare gli shader vanilla, feature al momento assente in Wrye Bash.
E con questo abbiamo concluso! La nostra installazione di Oblivion è più che mai pronta ad accogliere una moltitudine di mod, che ora sappiamo perfettamente come installare e gestire. I più pignoli potranno eventualmente seguire l'ulteriore step dell'ottimizzazione delle meshes, ma non è un passo essenziale per poter moddare pesantemente Oblivion.
Ora potete ufficialmente dare il via alla vostra lunga carriera di mod user! :cool:
IV.4 - L'ottimizzazione delle meshes con PyFFI
[in stesura]
***NOTA***
Questa parte della guida è la più gravosa per la macchina, l'ottimizzazione delle meshes è un processo lungo e laborioso per la CPU e può impiegare diverse ore. Dati il grande impegno utente/macchina e i risultati non proprio eclatanti rispetto alle meshes vanilla mi riservo di preparare questa parte della guida in un secondo tempo, dando invece priorità alla Parte V - i mod consigliati.
L'ottimizzazione delle meshes è un'operazione completamente facoltativa e può essere eseguita in qualunque momento, anche a gioco pesantemente moddato. Pertanto sentitevi liberi di installare tutti i mod che vi pare, all'ottimizzazione delle meshes ci penserete eventualmente poi.
**********
Update 20/10/11: al momento è tuttora in lavorazione una nuova release di PyFFI, se ne attende l'uscita per esporne l'uso
Guida al Modding Estremo
PREMESSA
Perchè un altro thread sul modding di Oblivion? Perchè, senza voler togliere nulla all'utilità di quelli già presenti, dopo anni di test e continui aggiornamenti sia riguardo i mod manager sia riguardo gli stessi mod credo si senta il bisogno di svecchiare argomenti e procedure ormai obsolete e a volte controproducenti, che non potrebbero comunque essere aggiornabili nei thread attuali poichè gli autori originali sono spariti nel nulla o non sembrano essere interessati ad aggiornarli. Chi desidera limitarsi all'installazione di pochi ed essenziali mod si può comunque sentire lbero di fare riferimento ai thread esistenti. Chi invece come me ha interesse a portare il modding di oblivion a livelli estremi e vuole viaggiare felicemente con una media di 200 e più mod installati, prosegua la lettura.
Questo thread impone tre punti fermi elencati di seguito. Se non si è d'accordo nessuno se ne risentirà, significherà semplicemente che non è il thread che fa per voi.
A) Lasciate da parte tutti i preconcetti e dimenticatevi di tutto quello che sapete. Qua si ricomincia da zero.
B) La macchina su cui installerete il gioco moddato non dovrà necessariamente essere di ultimissima generazione, ma nemmeno vetusta. Il modding estremo di oblivion richiede molta pazienza, molto tempo ma soprattutto molte risorse hardware. Se sul vostro hardware Oblivion vanilla gira male dovete aspettarvi che pesantemente moddato giri peggio.
C) Le procedure elencate di seguito non sono per l'utente sbrigativo e che conta di far funzionare tutto subito. Non aspettatevi una cosa del tipo "scarico, installo il mod e gioco". Qui non funziona in questo modo. Sono necessari calma, tempo, pazienza e piena coscienza di quel che si sta facendo.
Questo thread non avrà mai la presunzione di ricoprire tutti i casi esistenti ma avrà lo scopo di guidarvi passo passo nell'uso degli strumenti necessari nell'obiettivo di darvi una buona base da cui iniziare, per poter poi aggiungere con calma quanto desiderate.
Nel primo post si parlerà di come Oblivion gestisce le risorse e degli strumenti necessari per preparare il modding, senza riferirsi strettamente a questo o quell'altro mod. Alla fine della lettura conto che non solo possiate sapere cosa state facendo ma anche perchè lo dovete fare in quel modo.
Saranno naturalmente ben accetti consigli su cosa modificare e/o migliorare.
NOTA BENE: i più esperti noteranno che a quanto illustrato sotto come verità rivelata esistono alcune eccezioni. Quando non ritenute necessarie ai fini della funzionalità del gioco vengono volutamente omesse per non generare confusione.
Parte I - COME FUNZIONA OBLIVION
Di m***a. Fine prima parte.
Ok, scherzavo :D
Oblivion è, nella sua forma originale [di seguito "vanilla"], uno dei giochi più bacati e instabili della storia. Le varie esperienze degli utenti e i vari test dei modder hanno evidenziato che la maggior parte dei problemi riscontrati quali crash, quest non completabili, difetti grafici e compagnia cantante sono dovuti non a problemi lato utente ma a tutta una serie di bug mai corretti da Bethesda, e che con ottime probabilità verrano ormai lasciati come sono. Fortunatamente l'estesissima comunità di modding non ha solo provveduto a migliorare le caratteristiche del gioco sfornando mod ad ogni piè sospinto ma ha anche risolto una miriade di bug grazie a patch non ufficiali. Pertanto ogni utente, anche quello che non ha alcun interesse a moddare il gioco, può trarre vantaggio dal modding di Oblivion.
Iniziamo con l'illustrare come funziona Oblivion vanilla, cosa che ci darà modo di capire perchè è così facilmente moddabile, dopodichè vedremo nelle parti successive come e con cosa modificare il tutto.
I.1 - Struttura file e directory
La struttura di Oblivion è fondamentalmente semplice: un solo eseguibile ed un insieme di risorse alle quali accede l'eseguibile tramite i riferimenti contenuti nei plugin. Vediamo cosa troviamo nelle varie directory del gioco:
Il file oblivion.exe in Directory Installazione\oblivion
L'eseguibile principale contenente il codice necessario ad accedere alle risorse tramite l'interpretazione dei file esm ed esp.
Il file oblivion.ini in Directory utente\Documenti\My Games\Oblivion
Come dice l'estensione si tratta del file di inizializzazione. Contiene parecchi parametri necessari per istruire l'eseguibile riguardo le impostazioni relative a grafica, audio, controlli, etc. Non viene rimosso in seguito a disinstallazione del gioco.
I file .bsa in Directory Installazione\oblivion\data
Acronimo di Bethesda Softworks Archive, è il formato storico dei file archivio di Bethesda, contenenti le risorse quali meshes, texture, suoni, etc., strutturate all'interno dell'archivio in una serie di sottodirectory di nome meshes, sound, textures e così via. Sono referenziati sia dagli ESM sia dagli ESP.
I file .esm in Directory Installazione\oblivion\data
Acronimo di Elder Scrolls Master, si tratta dei file che contengono i dati sulla struttura degli ambienti interni ed esterni, gli script delle quest vanilla, gli script per l'interazione con personaggi ed oggetti, e più in generale ogni dato utile per far funzionare il gioco, all'infuori di modelli, texture e suoni. Nel vanilla esiste il solo oblivion.esm e non è modificabile in nessun modo con gli strumenti di modding. Il motivo è semplice: Bethesda ha limitato la modifica ai soli file ESP in modo che nessun modder possa andare a lamentarsi con loro se gli funziona male un gioco che lui stesso ha distrutto : )
MOD particolarmente impegnativi per il gioco come Nehrim e OOO dispongono di ESM propri, per via del fatto che il gioco sembra avere seri problemi con ESP superiori a certe dimensioni e per via di un bug di visualizzazione che affligge gli ambienti esterni quando modificati pesantemente.
I file .esp in Directory Installazione\oblivion\data
Acronimo di Elder Scrolls Plugin, si tratta di fatto dei medesimi file di cui sopra ma con la differenza di essere completamente modificabili tramite gli strumenti di modding. Sono i file che vengono creati dai modder tramite il Construction Set per istruire l'eseguibile ad accedere a tutta una serie di risorse personalizzate quali nuove armature, nuove armi, nuovi personaggi o a modificare quanto contenuto negli esm senza intaccare il contenuto dell'esm originale. Utile ad esempio per modificare la posizione di una casa contenuta in un esm senza dover modificare l'esm che la contiene o, tramite script, variare l'esito di una quest vanilla. Esp e plugin sono tendenzialmente termini intercambiabili. Il termine mod è invece preferibile per indicare la totalità delle risorse del mod, quindi non solo l'esp ma eventuali texture e meshes che vengono distribuite con l'archivio del mod del caso.
I file .ess in Directory utente\Documenti\My Games\Oblivion
Acronimo di Elder Scrolls Save, nient'altro che i file di salvataggio. Non vengono rimossi in seguito a disinstallazione del gioco.
La directory Directory Installazione\oblivion\data
La directory fondamentale di ogni mod user che si rispetti : )
Nel vanilla è quasi vuota poichè quasi tutto il necessario è nei BSA ma, una volta moddato il gioco, si popolerà con varie sottodirectory aventi la medesima struttura interna dei file BSA che contengono le risorse, ovvero texture, meshes, sound, etc. I file risorsa contenuti sotto \data vengono in gergo definiti loose file [file sparsi] ed ogni mod ne può contenere da uno fino a diverse migliaia. Il gioco carica i loose file secondo i seguenti principi:
se il loose file da caricare ha l'obiettivo di rimpiazzare un file preesistente nella struttura dei BSA, esso deve:
avere lo stesso nome del file originale contenuto nel BSA
trovarsi nella sottodirectory di \data corrispondente alla directory del BSA che contiene il file originale
essere più recente del BSA che contiene l'originale
Ad esempio una texture customizzata ad alta risoluzione che deve rimpiazzare quella vanilla del BSA lo può fare solo se è più recente del BSA.
se il loose file da caricare non si basa su nessun file preesistente l'unico modo per caricarlo è tramite un ESP nel quale verrà indicato il suo percorso.
Ad esempio una nuova spada della quale non vi è nessuna traccia nei BSA vanilla, nè a livello di meshes nè a livello di textures, richiederà un ESP tutto suo del tipo MiaSpadonaTroppoFiga.esp, che indicherà al gioco di caricare i loose file necessari.
Il caso 1 soffre di un noto bug del gioco che causa il mancato caricamento dei loose file, problema risolvibile tramite un hack di nome Archive Invalidation, del quale nel corso degli anni ne sono state escogitate diverse varianti. Vedremo più avanti qual è la più affidabile.
I.2 - Avvio del gioco
La procedura di avvio di Oblivion è sommariamente la seguente:
lettura oblivion.ini
verifica ESM in ordine di data
verifica BSA a cui puntano gli ESM
verifica loose file a cui puntano gli ESM
verifica ESP in ordine di data
verifica BSA a cui puntano gli ESP
verifica loose file a cui puntano gli ESP
visualizzazione menu principale
selezione salvataggio da parte dell'utente e verifica ESS
caricamento ESM + ESP in ordine di data
caricamento BSA a cui puntano gli ESM
caricamento loose file a cui puntano gli ESM
caricamento BSA a cui puntano gli ESP
caricamento loose file a cui puntano gli ESP
caricamento ESS
Niente di particolarmente complicato ma và da sè che se uno degli step di cui sopra non va a buon fine, ad esempio perchè è assente un loose file referenziato da un ESP, il gioco agirà in maniera alquanto bizzarra generando ogni sorta di anomalia grafica e di gameplay.
Notiamo una cosa importante: il check e il caricamento degli ESM e degli ESP viene sempre eseguito in ordine di data dei file, dando priorità agli ESM. Prima vengono caricati tutti gli ESM in ordine di data, a seguire tutti gli ESP, anch'essi in ordine di data. E' il modo in cui il gioco decide l'ordine di caricamento dei file, dando priorità al plugin che viene caricato dopo, ed è essenziale per il suo corretto funzionamento: quando due o più mod modificano la stessa entità, come nel caso di due mod che modificano la potenza di una medesima arma o le caratteristiche di un medesimo edificio, va deciso a quale dei due si debba lasciare la priorità. Si parla in questo caso di conflitto controllato, la cui errata gestione tramite un ordine di caricamento errato può al massimo dare problemi a livello di gameplay. Quando invece due mod fanno due cose concettualmente opposte si parla di conflitto indesiderato: è il caso di un mod A che elimina un'arma dal gioco e un mod B che le assegna una potenza differente dal vanilla. Se il mod B viene caricato dopo il mod A il gioco andrà in crash poichè l'ESP del mod B tenterà di fare riferimento ad un'arma che in quella istanza del gioco non esiste più.
Il secondo caso è una delle cause principali dei crash di Oblivion: il gioco non è in grado di ignorare i conflitti indesiderati tralasciando gli errori causati dai conflitti fra i mod. L'ho messo in grassetto poichè si tratta di un concetto chiave col quale si rischierà di scontrarsi più e più volte e va ben compreso prima di gettarsi nell'installazione folle di una moltitudine di mod senza comprendere a fondo cosa si propongano di modificare.
Fortunatamente da diverso tempo esiste BOSS , uno strumento per riordinare automaticamente gli ESP senza alcuna fatica. Che in gran parte si limita comunque a riordinare i mod secondo la filosofia del conflitto controllato, non può fare molto per i conflitti indesiderati poichè date le migliaia di mod disponibili nessuno è in grado di stabilire a priori se siano liberi da conflitti indesiderati fra loro. Ragion per cui prima di installare un mod è buona abitudine leggerne sempre la documentazione per sapere se l'autore ha già individuato conflitti con altri mod.
I.3 - Ambiente di gioco
Oblivion gestisce l'ambiente in cui ci muoviamo tramite celle di dimensione predeterminata [4096 x 4096 unità, che si traducono in circa 3600mq]. Una mappa completa della provincia di Cyrodiil, divisa per celle, è visibile qui (http://www.tesnexus.com/downloads/images/23939-1-1240451419.jpg). Si possono notare i confini della provincia contornati in marrone. Gli ambienti interni non fanno eccezione, anch'essi sono a volte suddivisi in celle quando ne viene superata la dimensione.
Il plugin oblivion.esm contiene tutte le caratteristiche esterne ed interne della provincia di Cyrodiil, che viene costruita referenziando i vari BSA che contengono le risorse necessarie a comporre gli ambienti nelle varie celle. Ad esempio, Oblivion - Meshes.bsa contiene la forma di una roccia; Oblivion - Textures - Compressed.bsa contiene le sue texture; Oblivion - Sounds contiene il suono dei passi quando ci camminiamo sopra. In oblivion.esm si decide in quali e quante celle va posizionata quella roccia. Ragion per cui ci imbattiamo spesso in rocce identiche, mobili identici, architetture identiche, persone identiche. Sono tutte copie di quanto contenuto nei BSA e referenziato più volte negli ESM o ESP, combinato in maniera più o meno abile per dare una parvenza di unicità.
I mod funzionano secondo il medesimo principio. I vari ESP generati nel Construction Set referenziano i contenuti dei BSA riutilizzandoli alla bisogna e senza la necessità di reinventare la ruota ogni volta: tutto il necessario è contenuto nei BSA, basta costruire gli ambienti componendone i vari pezzi. Una dovuta eccezione è data dai mod che introducono nuove risorse, ovvero modelli e texture che in Oblivion Vanilla non esistono. Come ad esempio Martigen's Monster Mod che introduce tutta una serie di nuove creature, le cui meshes e texture per comodità degli autori sono state compresse in un unico enorme BSA di centinaia di Mb, per poi essere referenziate da ESM ed ESP in modo che il gioco possa caricarle correttamente.
Sulla carta è tutto molto bello e funzionale. Purtroppo il motore che muove il gioco e ne controlla il funzionamento è estremamente bacato, pesante e ben poco ottimizzato per le macchine odierne. Per dirne una, non vi è nessun supporto per il multicore, sebbene alcuni parametri presenti in oblivion.ini portino a pensare che almeno in una fase iniziale risultasse previsto. Non c'è nessun supporto nativo al Large Address Aware nè tantomeno supporto ai sistemi 64bit, ragion per cui oblivion.exe va sistematicamente in crash superato un certo impegno di ram di sistema [per la cronaca 1.8Gb]. Non c'è nessun sistema di prevenzione dei crash in caso di errata referenziazione risorse. Apparentemente il sistema di buffer purging delle celle è bacato, ragion per cui quando girovagando si cambia cella ci si porta dietro anche i riferimenti della precedente, cosa che impegna risorse inutilmente. Non c'è nessun sistema per controllare dinamicamente le prestazioni, liberando tempo CPU per gli script. A causa di tutto ciò un Oblivion pesantemente moddato è, ad oggi, probabilmente il gioco più pesante esistente.
Fortunatamente la gran parte delle magagne di cui sopra è stata col tempo risolta dalla comunità di modder grazie ad una serie di artefizi che vedremo nella Parte III: installazione base.
Ora è tempo di illustrare gli strumenti a nostra disposizione.
Parte II - GLI STRUMENTI PER IL MODDING
Nella prima parte abbiamo visto come funziona Oblivion e come gestisce risorse e plugin. Ora continuiamo con la teoria illustrando quali strumenti abbiamo a disposizione per aggiungere e gestire i vari mod, senza addentrarci nella spiegazione passo passo del loro utilizzo. Questo sarà il compito della terza parte - Installazione base - e della quarta parte - Rifinire l'installazione - per poi concludere la nostra guida nella quinta parte - I mod consigliati. Quest'ultima parte per quanto possibile verrà costantemente aggiornata.
II.1 - L'installazione dei mod
Bethesda non ha mai fornito nessuno strumento utile per l'installazione dei mod. La comunità si è pertanto dovuta arrangiare sviluppando autonomamente strumenti propri quali OBMM e Wrye Bash per poter gestire agevolmente installazioni più o meno pesantemente moddate.
I mod vengono solitamente distribuiti in formato compresso rar, zip, 7z, OMOD ed exe. I primi tre direi non richiedano spiegazioni. Il quarto è il formato nativo di uno dei primi tool ad essere usciti per Oblivion: il mod manager OBMM [OBlivion Mod Manager], oggi reso obsoleto da Wrye Bash ma ancora molto diffuso fra gli utenti sia per la sua semplicità d'uso sia perchè numerosi mod vengono ancora oggi distribuiti in formato OMOD. Il formato exe è tipico dei rari mod forniti con installer.
Vediamo ora i principali metodi di installazione:
Installazione manuale
I mod forniti nei comuni formati di compressione possono essere semplicemente scompattati nella directory del gioco, per poi abilitare gli eventuali ESP dalla sezione Data Files dell'Oblivion Launcher. Si tratta di un metodo caldamente sconsigliato poichè non permette di tenere traccia agevolmente di cosa si è installato dove, nè di eventuali conflitti di risorse fra diversi mod. L'utente che segue questa strada deve essere cosciente che tale tipologia di installazione andrebbe limitata a pochi e conosciuti mod. Questo metodo non verrà ulteriormente esposto in questa sede.
Installazione tramite installer
Come sopra. I mod forniti con installer sono rari e alla pari dell'installazione manuale non permettono di tenere traccia dei conflitti di risorse, pur permettendo una più agevole disinstallazione dei mod rispetto all'installazione manuale. Anche questo metodo non verrà ulteriormente esposto in questa sede.
Installazione tramite OBMM
Il primo mod manager creato per Oblivion ed attualmente il più diffuso, sebbene il suo sviluppo si sia arenato da tempo. Una volta installato, OBMM permette di installare il mod agevolmente tramite poche operazioni sul file OMOD scaricato. Oltre alla possibilità di decidere l'ordine di caricamento degli ESP possiede un sistema per evidenziare eventuali conflitti di risorse, quali meshes e texture, fra mod diversi. La sua semplicità d'uso è ben nota ma soffre di gravi problemi risolti dal più efficiente Wrye Bash. Spiegamoli con degli esempi:
installiamo MOD A che contiene un pacchetto di texture aggiornate per ambienti esterni ed interni
scoviamo MOD B che contiene anch'esso un pacchetto di texture aggiornate, ma sono limitate alle caverne. Ci piace e lo installiamo, sovrascrivendo le texture delle caverne del MOD A
tutto funziona correttamente. Abbiamo le texture ambientali aggiornate da MOD A, e le texture delle caverne aggiornate dal MOD B
MOD B non ci piace più e decidiamo di disinstallarlo
le texture di MOD A che hanno lo stesso nome e percorso di quelle di MOD B vengono completamente rimosse senza che OBMM si opponga minimamente, perchè vede quei file come facenti parte del MOD B che gli abbiamo detto di disinstallare. Di conseguenza non solo abbiamo disinstallato MOD B ma abbiamo anche corrotto l'installazione di MOD A senza che OBMM abbia segnalato alcunchè! La reinstallazione di MOD A risolverebbe il problema ma l'utente non può saperlo.
Simile scenario accade se decidiamo di disinstallare MOD A poichè troppo pesante, e decidiamo di tenere solo le texture delle caverne del MOD B. L'operazione elimina TUTTI i file di MOD B, e anche in questo caso l'utente non ne sa nulla.
Questo è il banale scenario per quanto riguarda due semplici texture pack. Vi lascio immaginare cosa succede durante la disinstallazione di un mod che condivide dei modelli di creature con un altro mod. I casi di cui potete leggere in rete riguardo texture assenti e sostituite da una texture fucsia, i casi riguardo punti esclamativi comparsi qua e là e più in generale i casi dove nel gioco manca qualcosa sono con buona probabilità causati da disinstallazioni di mod eseguite tramite OBMM.
Vediamo un caso più subdolo:
installiamo MOD A che modifica la potenza di una particolare spada
installiamo MOD B che modifica la portata della medesima spada
nel gioco solo UNA delle due caratteristiche comparirà, dipendentemente dall'ESP che viene caricato dopo, che eliminerà completamente le caratteristiche del precedente per via della particolare gestione da parte di Oblivion di ESP che modificano le caratteristiche di una medesima entità. OBMM non è in grado in nessun modo di gestire conflitti di questo tipo.
I casi di cui sopra sono solo due dei motivi per cui OBMM [pur rispettando il suo storico valore] verrà evitato come mod manager principale, salvo per esigenze molto particolari che illustreremo più avanti. Il nostro mod manager principale sarà Wrye Bash.
Installazione tramite Wrye Bash
Wrye Bash ha una storia difficile. Lo sviluppatore originale ha abbandonato il progetto più di due anni fa, dopo aver sfornato un programma estremamente efficiente ma con un'interfaccia grafica quasi interamente a drop-down menu e non esattamente user-friendly. L'attuale team di sviluppo ha aggiornato l'interfaccia rendendola più semplice da utilizzare ma ha conservato lo spirito della originale. Pertanto l'utente medio può facilmente trovarsi spiazzato dalla miriade di opzioni disponibili. Wrye Bash, che richiederebbe un thread a sè, verrà illustrato con sufficiente profondità nella terza parte di questa guida. Nel frattempo ci limitiamo ad esporre i suoi principali punti di forza:
nessun file OMOD necessario. Per l'installazione del mod del caso si usa direttamente il file compresso scaricato
ordine di installazione modificabile in tempo reale. I mod che vengono installati nell'ordine errato possono essere spostati agevolmente in altra posizione, al resto penserà WB riallineando file e directory dove necessario
visualizzazione in tempo reale dei conflitti di risorse fra mod e organizzazione mod per genere
gestione ESP conflittuali per abilitare le caratteristiche di due mod che modificano gli stessi record tramite la funzione Bashed Patch
costantemente in aggiornamento
Nel corso della Parte III - Installazione base - illustreremo passo per passo l'uso di Wrye Bash.
II.2 - Il riordinamento automatico dei plugin
Lo spartano Oblivion Launcher permette di selezionare quali ESP abilitare o disabilitare dalla sezione Data Files ma non fornisce alcuna indicazione utile sull'ordine di caricamento. Tutti gli ESP vengono semplicemente elencati in ordine alfabetico, che non è l'ordine con cui verranno caricati poichè fa sempre fede la data del file, dal più vecchio al più recente. L'utilità del Launcher si ferma all'abilitazione dei DLC di Bethesda, ovvero le espansioni come Shivering Isles e Knights Of The Nine più i vari plugin minori come Horse Armor e Spell Tomes. Se ci si limita ad essi non vi è sostanzialmente nessun problema, i plugin della casa madre sono risultati liberi di conflitti fra loro e possono essere caricati senza problemi nel predefinito ordine determinato dalla loro data di creazione. Aggiungere ulteriori plugin senza poterne stabilire l'ordine di caricamento significa invece andare incontro ad un sacco di grane.
Riprendiamo a questo proposito il tema dell'ordine di caricamento anticipato nella parte I e vediamo con un esempio tangibile perchè sia così importante. Di seguito l'elenco dei plugin contenuti nell'edizione GOTY di Oblivion, elencati in ordine di caricamento:
Oblivion.esm
DLCShiveringIsles.esp
DLCHorseArmor.esp
DLCOrrery.esp
DLCVileLair.esp
DLCMehrunesRazor.esp
DLCSpellTomes.esp
DLCThievesDen.esp
DLCBattlehornCastle.esp
DLCFrostcrag.esp
Knights.esp
Come detto non esistono conflitti fra i plugin dei DLC e il loro ordine di caricamento non è strettamente importante se sono gli unici ad essere installati. Ma cosa succede quando viene installato un ulteriore plugin che va a referenziare le stesse risorse di un plugin esistente o ne modifica gli stessi record? Uno dei primi e più acclamati mod è stato Frostcrag Reborn [la cui installazione è oggigiorno non consigliabile causa una nota serie di conflitti con le Unofficial Patch], il cui plugin Frostcrag Reborn.esp è stato creato ovviamente dopo DLCFrostcrag.esp e quando installato va dilingentemente ad ordinarsi dopo il DLC originale. In questo modo Frostcrag Reborn, il cui obiettivo è estendere il plugin originale aumentando le dimensioni della torre del mago e aggiungendo nuove quest, funziona come previsto: va a modificare dei record preesistenti nel plugin originale, ad esempio aumentando le dimensioni un'area o spostando del mobilio, e il gioco non può far altro che obbedire agli ordini modificando quanto necessario secondo le istruzioni contenute nel plugin Frostcrag Reborn.esp. Ora, ipotizziamo che per qualche strano motivo la data di DLCFrostcrag.esp risulti successiva a quella di Frostcrag Reborn.esp. Quest'ultimo verrebbe erroneamente caricato prima, e farebbe riferimento a dei record che in quella istanza del gioco non esistono ancora. Nella migliore delle ipotesi all'ingresso nella torre ci aspetterebbero ogni sorta di anomalie grafiche. Nella peggiore, il gioco andrebbe in crash.
L'esempio di cui sopra ci fa realizzare un aspetto importante dell'interazione fra i diversi mod: prima che fosse globalmente ben chiara l'importanza dell'ordine di caricamento numerosi plugin han funzionato al primo colpo per diversi utenti semplicemente perchè sono stati creati successivamente a plugin che interagivano con le stesse risorse, pertanto la loro data di creazione è risultata necessariamente successiva alla data dei plugin esistenti e il caricamento avveniva in ordine corretto senza che lato utente fosse necessaria alcuna operazione. In sostanza i plugin funzionavano benone ma non tutti avevano piena coscienza del perchè.
Con l'evoluzione della comunità di modders e la diffusione di centinaia e a seguire migliaia di plugin il problema si è col tempo ingigantito e gli utenti hanno iniziato ad avere seri problemi nel coordinare il funzionamento dei vari plugin. OBMM e Wrye Bash possiedono una funzione integrata per decidere l'ordine di caricamento degli ESP, di fatto semplicemente cambiando la data dei file, ma non dispongono di nessuna funzione per riordinare automaticamente gli ESP secondo i dettami della comunità. A questo fortunatamente ci pensa il BOSS citato nella prima parte, un gran bel pezzo di software che scansiona tutti gli ESP presenti nella directory \data, li confronta con una masterlist online costantemente aggiornata e riordina gli ESP in locale variandone la data dove serve.
Nel corso della Parte III - Installazione base - illustreremo il semplice uso di BOSS.
II.3 - La pulizia dei plugin
Il TES Construction Set TESCS o, come è meglio conosciuto, semplicemente CS] è purtroppo un software estremamente scadente. E' instabile, macchinoso, ha un'interfaccia grafica che fa rimpiangere lo SCO Open Desktop e la sua complessità è spesso fonte di una miriade di errori involontari da parte del malcapitato modder. Fra questi errori ci sono quelli comunemente conosciuti come wild edits e dirty edits, che possono essere risolti tramite il programma Tes4Edit.
I wild edits sono dovuti all'inesperienza del modder e consistono in modifiche involontarie di entità che non dovrebbero essere minimamente coinvolte dal mod. Prendiamo l'esempio di un altro nostro mod AltraMiaSpadonaTroppoFiga.esp. Il mod si propone di modificare le caratteristiche di una spada rinvenuta in una tomba nel profondo di un dungeon assegnandole una potenza mai vista, e lo fa modificando il record della spada originale invece della sua referenziazione contenuta nella tomba. Errore. TUTTE le spade di quel tipo nell'intero gioco verranno coinvolte dalla modifica. Non che sia un gran problema ma non è sicuramente quanto il mod si proponeva di fare. Il metodo corretto è modificare la copia di quella spada, ovvero la sua referenziazione dell'oggetto originale contenuta nella tomba, senza alterare l'entità originale contenuta in oblivion.esm. I wild edits non sono identificabili automaticamente da nessun software, poichè non esiste un modo per stabilire a priori quali fossero gli obiettivi del modder. Per quel che ne si sa la modifica di tutte le spade dello stesso tipo nell'intero gioco potrebbe anche essere intenzionale. In linea di massima i rari wild edits incontrabili sono caratteristica di modder inesperti e non inficiano comunque la stabilità del gioco, al massimo scombinano il gameplay con eventi bizzarri e indesiderati. Nel caso si riscontrasse un'anomalia nel gameplay e la si sospetti dovuta ad un mod la strada migliore da seguire è segnalarla all'autore. Questa stessa guida non darà alcuna indicazione sulla risoluzione dei wild edits per due motivi: primo, si tratta per lo più di retaggio di mod vetusti e/o scritti da modder inesperti; secondo, la risoluzione dei wild edits richiederebbe un intero thread a parte. In buona sostanza il gioco non vale la candela.
I dirty edits sono dovuti principalmente sia a distrazione sia alla complessità del CS, che porta facilmente a commettere errori. Ne esistono di due tipi:
ITM - Identical To Master. Si tratta di entità presenti nel plugin master [solitamente oblivion.esm] che sono state modificate in qualche modo per poi essere ripristinate alle caratteristiche originarie. E' il caso di una spada la cui potenza base viene modificata, per poi essere riportata ai valori originali poichè il modder ha cambiato idea. Il CS non interpreta quest'ultima azione come un annullamento undo] ma come una modifica a tutti gli effetti da registrare nell'ESP. Ragion per cui l'ESP aumenta inutilmente di dimensioni, inoltre il gioco si troverebbe a gestire un inutile ed evitabile conflitto nel caso un altro mod modifichi le caratteristiche della medesima spada.
DR - Deleted Reference. Si tratta di entità presenti nel plugin master [solitamente oblivion.esm] che sono state cancellate per qualche ragione dal mod. Errore. Le entità dei master non si cancellano mai, si disabilitano. Non è in realtà possibile cancellarle dal master oblivion.esm, nel senso che nulla può essere modificato nel file originale, ma Oblivion le considererà rimosse in quella tale istanza del gioco. Pertanto se per qualche motivo viene rimossa dal gioco una spada alla quale fa riferimento anche un altro mod Oblivion andrà in crash quando caricherà la cella che la contiene.
Appare chiaro che la pulizia dei plugin sia un'operazione necessaria per garantire la stabilità del gioco. Fortunatamente il software BOSS per riordinare i plugin ha anche la possiblità di individuare i plugin "sporchi" fra quelli installati e ce li segnalerà prontamente, senza che li si debba controllare manualmente uno ad uno. La pulizia si esegue con pochi click grazie al programma Tes4Edit, che si incarica sia di rimuovere completamente gli inutili ITM sia di bonificare i pericolosi DR convertendoli in UDR ripristinando il record originale come necessario al gioco per poi disabilitarlo come richiesto dal mod.
Volete ridere? ANCHE i plugin dei DLC di Bethesda contengono dei dirty edits, e van puliti alla pari degli altri mod. Questo dovrebbe farci realizzare quanto complicato sia l'utilizzo del CS persino per gli stessi sviluppatori che l'hanno creato.
Nel corso della Parte IV - Rifinire l'installazione - illustreremo l'uso di Tes4Edit.
II.4 - L'ottimizzazione delle meshes
Oblivion usa meshes [gli "scheletri" dei modelli in 3D] in formato NIF [Net Immerse File], dal nome del motore grafico NetImmerse antenato del motore GameBryo utilizzato dal gioco. Il formato di per sè non è completamente aperto riguardo la licenza ma le sue specifiche sono note da anni e diversi programmi di modellazione 3D possono aprirlo senza problemi. Fra i programmi in grado di manipolare le meshes esiste PyFFI [Python File Format Interchange], un'utility sviluppata per ottimizzare le meshes rimuovendone i nodi vuoti o duplicati generati da errore umano o da bug del software di modellazione, che pur dovendo essere gestiti dal motore grafico non aggiungono assolutamente nulla in termini di qualità. Di conseguenza è vero anche l'opposto: la rimozione dei dati inutili, pur mantenendo inalterata la qualità visiva, aumenta le prestazioni del motore. Non aspettiamoci miracoli, comunque: si parla di pochi fps, ma avendo a che fare con un motore poco ottimizzato come quello di Oblivion ogni piccola miglioria è sempre la benvenuta.
Per ottimizzare le meshes del gioco sarà prima necessario scompattarne l'originale archivio Oblivion - Meshes.bsa per poi ottimizzarlo con PyFFI [operazione che potrà durare diverse ore] e ricompattarlo nuovamente in formato BSA. Per l'operazione sarà necessario utilizzare un tool di estrazione e creazione BSA, integrato in OBMM, più il software PyFFI per l'ottimizzazione, il quale richiede necessariamente l'installazione di Python.
Nel corso della Parte IV - Rifinire l'installazione - illustreremo l'uso di PyFFI.
Parte III - INSTALLAZIONE BASE
Nella seconda parte abbiamo illustrato i principali strumenti per il modding. Ora impareremo ad usarli, e mano a mano che proseguiremo con la configurazione di Oblivion e degli strumenti per moddarlo aggiungeremo altri software non ancora citati ma estremamente utili. La presente guida si applica a più o meno qualsiasi tipo di installazione di Oblivion, sia essa eseguita da DVD o via Steam, sia essa limitata al solo Oblivion o includente i DLC dell'edizione GOTY. L'unica installazione non supportata dalla guida è la Direct2Drive poichè non è in grado di avviare l'essenziale OBSE. Dove necessario saranno indicati i diversi passi da seguire a seconda del tipo di installazione. Prima di eseguire i passi della guida in tempo reale vi suggerisco di darle una lettura in modo da avere ben chiari tutti i punti.
Pronti? Chiudetevi in casa, mettete fuori il gatto, dite alla fidanzata di uscire con le amiche e staccate il telefono. Avete bisogno di una serata tutta per voi. Si comincia!
III.1 - L'installazione di Oblivion vanilla
Ok, come prima cosa disinstallate Oblivion.
Sì, avete letto bene. Ignoro ovviamente in che stato si trovi la vostra attuale installazione di Oblivion, pertanto posso dare garanzie sui risultati della presente guida solo se le sue istruzioni vengono eseguite su una macchina vergine. Del resto eravate stati avvertiti: qua si ricomincia da zero ; )
Sta a voi decidere cosa fare della vostra attuale installazione e decidere se seguire o no la guida su un'installazione vergine, ma è bene che sappiate che è straconsigliato partire davvero da capo.
Nota per utenti Steam: per evitare di scaricare Oblivion da capo è sufficiente eseguirne un backup dalla apposita funzione integrata, per poi ripristinarlo in seguito. Il backup si limiterà a file e directory predefiniti, senza copiare eventuali mod già installati, quindi avrete la garanzia di un'installazione pulita. La disinstallazione di Oblivion si esegue sempre da Steam stesso.
Rimuovete ogni mod manager, scordatevi ogni utility che potreste aver già installato, eventualmente fatevi un backup dei salvataggi presenti in Directory utente\Documenti\My Games\Oblivion\Saves, dopodichè eradicate completamente Oblivion dal vostro sistema. Successivamente assicuratevi di cancellare la directory Directory Installazione\oblivion\ e Directory utente\Documenti\My Games\Oblivion\. A disinstallazione completata riavviate il sistema e lanciate più volte la pulizia registro dell'utility Ccleaner (http://www.piriform.com/CCLEANER) per rimuovere ogni chiave lasciata per strada.
Ora siamo pronti ad installare Oblivion.
A qualunque tipologia di installazione vi affidiate i risultati cambiano poco. Ad eccezione della Direct2Drive qualunque versione di Oblivion è moddabile su qualunque sistema operativo supportato nativamente dal gioco. Quel che è importante sapere è che su Vista e Seven [e in futuro con ottime probabilità anche su Windows 8] la directory di installazione non deve essere quella predefinita. Il motivo è dovuto al UAC, che impedisce la corretta installazione dei mod nella directory c:\program files anche a UAC disabilitato. Scegliete dunque una directory al di fuori di c:\program files, come ad esempio c:\Oblivion o c:\giochi\Oblivion.
Nota per utenti Steam: nessun gioco di Steam può essere installato all'esterno delle sue directory, pertanto l'unico modo per poter installare Oblivion al di fuori di c:\program files, dove viene installato Steam per impostazione predefinita, è spostare Steam, ad esempio sotto c:\Steam o c:\giochi\Steam. La procedura corretta è qui (https://support.steampowered.com/kb_article.php?ref=7418-YUBN-8129). Quando avrete terminato potrete proseguire con la guida.
Inseriamo il DVD o, nel caso di utenti Steam, apriamo steambackup.exe contenuto nella directory di backup di Oblivion precedentemente selezionata e seguiamo i passi per l'installazione. Al termine dell'installazione sarà necessario scaricare e installare le patch ufficiali da qui (http://www.bethsoft.com/eng/downloads_01.html). Assicuratevi di scaricare ed installare le patch corrispondenti alla vostra versione. Non avviate ancora il gioco, non è ancora il momento. Abbiamo ancora qualche passo da seguire.
Nota per utenti Steam: nessuna patch va scaricata dal sito Bethesda. Tutto il necessario è già incluso in quanto avete scaricato e installato.
Prima di avviare il gioco facciamo un giretto nelle directory, per avere un'idea chiara dell'aspetto di un Oblivion vergine. Fotografate mentalmente quel che vedete, vi sarà utile per capire cosa accade durante l'installazione dei vari mod. Notiamo innanzitutto che la directory Directory utente\Documenti\My Games NON contiene una directory Oblivion. E' normale, verrà creata solo durante il primo avvio del gioco. Spostiamoci nella directory Directory Installazione\oblivion\ e osserviamone il contenuto. La struttura di un Oblivion vanilla corrisponde sommariamente a quanto segue, dipendentemente dalla presenza o meno delle due espansioni ufficiali Shivering Isles e Knights Of The Nine e i vari DLC. In grassetto le directory, in carattere normale i file:
\oblivion:
Data
Directx
Oblivion.exe
OblivionLauncher.exe
LauncherMusic.wav
Oblivion_default.ini
Bethesda.TXT
Readme.txt
binkw32.dll
Possiamo vedere l'eseguibile principale, il Launcher da cui si modificano le impostazioni e si abilitano/disabilitano gli ESP e il file Oblivion_default.ini dal quale viene generato il file oblivion.ini. NOTA BENE: il file Oblivion_default.ini non deve essere modificato per nessun motivo.
Nota per utenti Steam: a quanto sopra si aggiungono i file per l'inserimento delle chiavi di registro installscript.vdf ed eventualmente un suo backup installscript.vdf.bak
\oblivion\data:
Music
Shaders
Textures
Video
[..]
Oblivion - Meshes.bsa
Oblivion - Misc.bsa
Oblivion - Sounds.bsa
Oblivion - Textures - Compressed.bsa
Oblivion - Voices1.bsa
Oblivion - Voices2.bsa
Oblivion.esm
A quanto sopra si aggiungono gli eventuali BSA ed ESP dei DLC preinstallati dalla versione GOTY.
La sottodirectory Music contiene l'intera colonna sonora di Oblivion in formato .mp3. Non è lì come bonus, si tratta effettivamente dei file che verranno riprodotti nel gioco.
La sottodirectory Shaders contiene i 19 shader pack utilizzati dal motore grafico. Di essi ne verranno utilizzati solo alcuni, dipendentemente dalle caratteristiche della scheda video.
La sottodirectory Textures\Effects contiene un unico file TerrainNoise.dds, aggiunto da Bethesda con la patch 1.2 per migliorare l'erba visibile in lontananza.
La sottodirectory Video contiene i video in formato .bik necessari a riprodurre il logo Bethesda all'avvio, le varie cut sequence, la mappa scorrevole nel menu principale, etc.
Come possiamo constatare Oblivion vanilla non ha directory molto affollate, si parla di meno di un centinaio di file se si escludono quelli contenuti nella directory Directx. Questo perchè quasi tutto il necessario al funzionamento del gioco, come illustrato precedentemente, è contenuto nei BSA e nell'unico ESM oblivion.esm, più gli eventuali BSA ed ESP dei DLC. Ma con l'installazione di nuovi mod la directory si popolerà di una miriade di file, aumentando dalle canoniche dimensioni di circa 6Gb della GOTY fino ad alcune decine di Gb. La mia, per la cronaca, è al momento attorno ai 25Gb e contiene circa 60mila file.
Ora è il momento di avviare il gioco una prima volta. Il Launcher ci informerà che verrà identificata la scheda video e verranno impostati i parametri video di conseguenza. L'autodetect è tendente a fallire con le ultime schede video ma non si tratta di un problema, Oblivion girerà ugualmente. In assenza di un riconoscimento corretto i parametri verranno impostati a Medium. Li sistemeremo poi, per ora usciamo nuovamente dal Launcher senza avviare Oblivion e andiamo a dare un'occhiata in Directory utente\Documenti\My Games\. Ehilà, è spuntata una directory di nome Oblivion! E dentro è stata creato il file oblivion.ini, che inizialmente è poco più di una copia del file Oblivion_default.ini e non contiene ancora tutti i parametri modificabili. Dopo il primo avvio di Oblivion verrà aggiornato aggiungendo i parametri selezionabili dall'interno del gioco.
Avviamo nuovamente il Launcher, che nel trovare una copia corretta di oblivion.ini non tenterà più di crearne uno nuovo e non ci segnalerà più nulla riguardo l'identificazione delle scheda video, e andiamo su Options a modificare i parametri grafici a nostro piacimento. Personalmente imposto tutto al massimo scegliendo Ultra High, abilito le tre opzioni per il distant rendering e abilito vsync e HDR. Non è questa la sede per parlare delle impostazioni grafiche, semplicemente sceglietele compatibilmente con le caratteristiche della vostra macchina, date OK e selezionate Play per avviare finalmente il gioco la prima volta. Bene, e ora? E ora USCITE senza fare nulla. Dobbiamo moddare, mica giocare! :D
All'uscita tornate nuovamente in Directory utente\Documenti\My Games\Oblivion e notate la presenza di due nuovi file: RendererInfo.txt che altro non è che uno stringato dump delle capacità grafiche del vostro sistema e BlendSettings.ini, il cui scopo non è tuttora chiaro ma sembra avere a che fare con il rilevamento della collisione durante i combattimenti. Nessuno dei due è di nostro interesse.
Notate piuttosto come sono aumentate le dimensioni di oblivion.ini [di circa 5K]. E' perchè in seguito all'uscita dal gioco vi sono state aggiunte tutte le impostazioni che si possono selezionare dal menu interno di Oblivion. Noi non abbiamo ancora cambiato nulla, ma vi sono comunque state salvate quelle di default. Ricordatevi di questo punto importante: oblivion.ini viene scritto solo all'uscita da Oblivion e solo se Oblivion non va in crash all'uscita, non viene modificato assolutamente nulla in oblivion.ini dopo aver cambiato le impostazioni dal menu interno. Pertanto in mancanza di un'uscita regolare da Oblivion tutte le impostazioni modificate vengono perse. Niente paura, esiste il rimedio e lo vedremo in questa stessa sezione della guida.
I vari parametri modificabili in oblivion.ini non verranno illustrati, salvo quelli strettamente necessari al modding. Ma prima di proseguire dobbiamo assolutamente cambiare un singolo parametro molto importante, che al suo valore di default può essere causa di crash. Aprite oblivion.ini, individuate la riga iShadowMapResolution=256 e cambiatela in iShadowMapResolution=512 o, se la vostra scheda video è abbastanza recente, iShadowMapResolution=1024. La dimensione consigliata della shadowmap non è strettamente legata alla ram video, quanto alle prestazioni complessive della scheda. Valuterete eventualmente in seguito se sia il caso di lasciarla a 1024 o dimezzarla, compatibilmente con le prestazioni rilevate.
Salvate oblivion.ini e avviate nuovamente il gioco. Entrate nel menu impostazioni e cambiate tutte le impostazioni grafiche come da vostro gradimento. Personalmente imposto tutto al massimo ma lascio l'Anti-aliasing del gioco disabilitato poichè ha problemi di compatibilità con l'HDR. Come AA utilizzo uno shader di OBGE che eventualmente vedremo in seguito. Entrate nel menu gameplay e disabilitate le ultime tre impostazioni per il salvataggio automatico, nota causa di crash. Uscite dal gioco, create nella medesima directory Directory utente\Documenti\My Games\Oblivion una copia di oblivion.ini e chiamatela oblivion.original.ini, sarà la vostra copia di riferimento se lungo la strada qualcosa andrà storto.
Benone, avete terminato l'installazione di Oblivion vanilla. Ora viene il bello : )
III.2 - L'avvio con l'utente di test
Avviamo Oblivion e iniziamo una nuova partita. Diamo al nostro PG provvisorio il nome Test e non perdiamo tempo a modificarne razza e aspetto, lasciando le impostazioni ai valori predefiniti. Il nostro personaggio ci servirà solo per eseguire i nostri test di modding e non verrà usato per giocare, pertanto è inutile caratterizzarlo in alcun modo.
Come prima cosa apriamo la console con il tasto \ [~ sulle tastiere inglesi] e diamo il comando tdt [toggle debug test] per visualizzare le informazioni di debug e abilitiamo la sezione 13 col comando sdt 13 [set debug test]. In alto a destra verranno visualizzati gli FPS e in alto a sinistra la vram impegnata alla riga TextureMem = T xxx Mb. In condizioni ideali quest'ultimo valore non dovrebbe mai superare le dimensioni della vram a bordo della vostra scheda video.
Abituatevi a tenere d'occhio questi valori, saranno utili per discriminare eventuali problemi di overload in seguito all'installazione dei vari mod.
Un'altra sezione di debug molto utile è la 0. Diamo il comando sdt 0 e notiamo in alto a sinistra il nome della cella in cui ci troviamo: ImperialDungeon01 il cui nome mappa è Imperial Prison. Il nome mappa è un mero identificativo per dar modo al giocatore di capire dove si trova ma il dato importante ai fini del modding è il nome della cella. Poter sapere in che cella ci si trova è utile per identificare problemi di conflitti fra mod che modificano i contenuti delle stesse celle. Quando e se ci capiterà di incontrare un problema nel corso del gioco una delle prime informazioni che dovrete fornire a chi vi vorrà aiutare dovrà essere il nome della cella in cui vi trovavate quando avete riscontrato il problema. Mano a mano che avanzeremo nel tutorial del gioco passeremo di cella in cella e ne vedremo cambiare il nome da ImperialDungeon01 a ImperialDungeon02, 03, etc.
Riabilitamo la sezione 13 col comando sdt 13 e leggiamo il valore di Tri: è il triangle count, la quantità di triangoli generati dal motore grafico. Notate come varia a seconda di dove volgete lo sguardo, diminuendo sensibilmente quando guardate verso il basso, dove la scena è limitata alla gestione dei pochi triangoli necessari a generare il terreno. Lo potete verificare visivamente col comando twf per abilitare la modalità wireframe. Notate anche come gli FPS aumentino sensibilmente quando volgete lo sguardo verso zone con minore quantità di triangoli. Su giochi pesantemente moddati tale valore può raggiungere anche i 5 milioni in zone particolarmente complesse, minando le prestazioni. Vedremo più avanti come sarà possibile diminuire il triangle count grazie all'ottimizzazione delle meshes con PyFFI.
Proseguiamo nel tutorial fino ad uscire dalle fogne per arrivare al molo davanti alle rovine di Vilverin e fermiamoci lì. Con sdt 13 e tdt attivo notate il nome della cella: ICPrisonSewerExit01 alle coordinate 11,20. Potete individuare la cella in cui vi trovate su questa (http://www.tesnexus.com/downloads/images/23939-1-1240451419.jpg) mappa nel sublock 1,2. Ribadiamo che è molto importante sapere sempre dove ci si trova in caso di problemi, come ad esempio crash inaspettati, poichè chi vi può aiutare nell'identificare la causa di un crash potrebbe essere già al corrente di un noto conflitto fra mod individuato in una determinata cella. A questo proposito è bene esporre che Oblivion genera gli spawn [creature e NPC] e gestisce oggetti e script in 25 celle [u]esterne per volta: la cella in cui ci si trova più le 24 intorno ad essa [8 nel quadrato interno più le 16 del quadrato esterno]. Salvo dimensioni spropositate di un dungeon, la cella interna è invece sempre e solo una, quella in cui ci si trova in un dato momento. Ne consegue che la probabilità di crash in seguito a gravi conflitti è in esterno 25 volte superiore all'interno . Motivo per cui gli interni sono tendenzialmente considerati "sicuri", mentre il giocatore che si avventura all'esterno ha buon diritto di temere più i crash di quanto non tema gli eventuali nemici incontrati : )
E' il momento di salvare la partita. Aprite la console e digitate save PrisonSewer01, un istante dopo apparirà il messaggio Game Saved. Importante: abituatevi fin da ora a salvare la partita sempre in questo modo, ovvero salvando a mano dalla console dando un nome mnemonico al salvataggio seguito da un numero sequenziale, se possibile evitando gli spazi. Evitate per quanto possibile le sovrascritture del medesimo salvataggio e soprattutto scordatevi per sempre del quicksave. Ripetetelo con me: il quicksave è una Cosa Molto Brutta™. Per quanto possibile cercate inoltre di salvare sempre la partita in una cella interna in modo che al caricamento il gioco non sia stressato dal ricreare immediatamente tutti gli spawn e rigestire tutti gli oggetti e gli script. Scordatevi anche della funzione Autosave, che comunque abbiamo disabilitato più indietro. Avrete potuto notare che all'inizio della partita ne viene comunque generato uno nonostante li si sia disabilitati dal menu. Ignoratelo, è un autosave limitato alle fogne imperiali e non capiterà più.
Il sistema di salvataggio di Oblivion è notoriamente bacato, ed ha particolari problemi con la sovrascrittura dei medesimi salvataggi. Ragion per cui il quicksave va dimenticato a tutti i costi. Col tempo vi abituerete alla semplice sequenza di comandi \ + save nomesalvataggio01, alla quale eventualmente seguirà \ + freccia in su per ripetere l'ultimo comando + save nomesalvataggio02 e così via. Evitate inoltre di palleggiare da un salvataggio ad un altro quando i salvataggi caricano celle [i]differenti [ad esempio caricare un salvataggio in Anvil per poi caricare un salvataggio precedente in Bruma]: Oblivion non resetta correttamente il contenuto del caricamento precedente, pertanto anche se il giocatore non può saperlo ci si potrà trovare in Bruma con delle entità referenziate esistenti solo in Anvil, che verranno incluse in un eventuale salvataggio eseguito in Bruma. Se dovete necessariamente passare da un salvataggio all'altro, uscite prima dal gioco [tornare al menu principale non è sufficiente].
Ora che abbiamo il nostro personaggio di test bell'e pronto possiamo proseguire nel modificare altri aspetti importanti del gioco. Usciamo da Oblivion, per comodità scrivendo in console qqq [Quit Quit Quit :D] e vediamo come si può migliorare la stabilità di Oblivion prima ancora di iniziare a moddarlo. I più curiosi potranno inoltre verificare che sotto Directory utente\Documenti\My Games\Oblivion\Saves è stato creato il file PrisonSewer01.ess, esattamente col nome che abbiamo indicato in console. I due file autosave.ess e autosave.bak possono essere tranquillamente eliminati.
III.3 - L'installazione di OBSE
OBSE [Oblivion Script extender] è un sistema di estensione delle capacità di scripting di Oblivion, che permette agli script di eseguire comandi non nativamente supportati dal gioco. Col tempo si è evoluto permettendo il caricamento di DLL non native di Oblivion, capacità che ha dato modo ai vari sviluppatori di creare particolari plugin come OSR e FastExit, che illustreremo a breve. OBSE non è di per sè un mod in senso stretto, ma viene sfruttato da una moltitudine di mod e plugin per spingere Oblivion oltre i limiti imposti dal gioco. In questa parte della guida ne sfrutteremo le funzionalità per rendere Oblivion più stabile e reattivo, pertanto nessuna installazione di Oblivion, nemmeno quella vanilla, dovrebbe poter fare a meno di OBSE : )
Non essendo OBSE un vero e proprio mod non può essere installato da nessun mod manager, pertanto lo installeremo manualmente prima ancora di arrivare all'installazione di Wrye Bash e gli altri strumenti.
Iniziamo col creare da qualche parte una directory OblivionSetup dove scaricare il necessario. Non fatevi venire la tentazione di creare tale directory come sottocartella di \oblivion, createla da un'altra parte. Oblivion, per ragioni non chiarite, ha la pessima abitudine di eseguire all'avvio un check su tutti i file contenuti nelle sua directory \data. Tale check fallisce miseramente quando i file ivi contenuti superano pressappoco i 400, e il gioco va in crash all'avvio o al caricamento di un salvataggio. Per tale ragione la directory \oblivion\data e se possibile anche \oblivion non dovrebbero contenere nient'altro che quanto necessario al funzionamento del gioco, lasciando tutti i necessari file di installazione dei mod in una directory esterna. Gli eventuali file .txt dei doc non sembrano essere coinvolti dal check, pertanto i vari readme dei mod, quando non installati automaticamente sotto oblivion\docs, possono anche risiedere serenamente in \oblivion\data.
Scarichiamo OBSE da qui (http://obse.silverlock.org/) e salviamo il file obse_0020.zip nella nostra directory OblivionSetup. Apriamo lo zip ed estraiamo direttamente nella directory \oblivion i seguenti file:
obse_1_2_416.dll
obse_editor_1_2.dll [facoltativo per il gioco ma necessario per il CS]
obse_loader.exe
Nota per utenti Steam: nella directory \oblivion va estratto anche il file obse_steam_loader.dll. OBSE richiede inoltre che per il suo corretto funzionamento con Steam sia abilitato lo Steam Community In-Game [lo trovate fra le impostazioni di Steam]. Inoltre il readme segnala di non copiare obse_loader.exe poichè inutilizzato da Steam, in realtà va comunque copiato poichè è l'unico modo per Wrye Bash per capire se state utilizzando OBSE.
Al termine dell'estrazione la directory \oblivion apparirà così:
\oblivion:
Data
Directx
Oblivion.exe
OblivionLauncher.exe
obse_loader.exe
LauncherMusic.wav
Oblivion_default.ini
Bethesda.TXT
Readme.txt
binkw32.dll
obse_1_2_416.dll
obse_editor_1_2.dll
Con in più i file installscript.vdf, installscript.vdf.bak e obse_steam_loader.dll per gli utenti Steam.
D'ora in poi tutte le volte che avvierete il gioco lo dovrete fare lanciando obse_loader.exe. Eventualmente fatevene un collegamento sul desktop per comodità. Se lancerete il gioco dal Launcher o direttamente dal suo eseguibile oblivion.exe, OBSE non funzionerà. Lanciate ora obse_loader.exe e arrivati al menu uscite subito dal gioco.
Nota per utenti Steam: obse_loader.exe non va utilizzato, l'avvio del gioco va eseguito normalmente dal Launcher come siete soliti fare.
Se OBSE funziona correttamente vedrete comparire nella directory di Oblivion il file obse.log con questo contenuto:
OBSE: initialize (version = 20.6 010201A0)
oblivion root = Directory Installazione\oblivion\
plugin directory = Directory Installazione\oblivion\Data\OBSE\Plugins\
patched
OBSE: deinitialize
Nota per utenti Steam: nella directory \oblivion dovreste trovare anche il file obse_steam_loader.log con questo contenuto:
crc = A2408F04
dll = Directory Installazione\steam\steamapps\common\oblivion\obse_1_2_416.dll
Ora che abbiamo un OBSE bello funzionante vediamo di sfruttarlo a dovere installando alcuni plugin essenziali.
OBSE - L'installazione di FastExit2
Come detto sopra, Oblivion non è in grado di salvare il file oblivion.ini in caso di crash in uscita, eventualità la cui probabilità aumenterà esponenzialmente con l'installazione dei mod anche quando essi funzioneranno perfettamente nel gioco. Oblivion è fatto così, o lo prendi a botte o ne prendi atto e porti pazienza :D
Oppure ci si arma degli strumenti necessari per domarlo. FastExit è un semplice ed utilissimo plugin che risolve il problema dei crash in uscita alla radice intercettando il comando di uscita dal gioco e salvando correttamente il file oblivion.ini, per poi killare il processo oblivion.exe. Scarichiamolo da qui (http://www.nexusmods.com/oblivion/mods/22410), sezione Files > Main Files > FastExit2 e salviamolo nella nostra directory OblivionSetup. Preleviamo la directory Data dal file zippato ed estraiamola nella directory \oblivion, sovrascrivendo quando richiesto. Nella directory \oblivion\data compariranno due nuove sottodirectory obse e plugins, al cui interno troveremo il file FastExit2.dll:
Oblivion
Data
obse
plugins
FastExit2.dll
Non c'è bisogno di configurare assolutamente nulla. All'avvio del gioco OBSE eseguirà uno scan della directory plugins ed abiliterà tutti i plugin rintracciati. Verifichiamo il funzionamento di FastExit avviando il gioco, carichiamo il nostro salvataggio PrisonSewer01 dal menu e usciamo immediatamente col comando qqq da console. Oblivion privo di mod non ha problemi a chiudersi correttamente e velocemente, ma rispetto a prima dovremmo comunque notare una maggiore reattività al comando di uscita.
Come ulteriore verifica apriamo nuovamente il file obse.log da \oblivion\data, dovremmo poter vedere delle informazioni in più relative al corretto caricamento del plugin:
OBSE: initialize (version = 20.6 010201A0)
oblivion root = Directory Installazione\oblivion\
plugin directory = Directory Installazione\oblivion\Data\OBSE\Plugins\
checking plugin Directory Installazione\oblivion\Data\OBSE\Plugins\\FastExit2.dll
plugin Directory Installazione\oblivion\Data\OBSE\Plugins\\FastExit2.dll (00000001 FastExit 00000002) loaded correctly
patched
OBSE: deinitialize
A quanto sopra si aggiungono alcune segnalazioni riguardo l'assenza di PrisonSewer01.obse. Si tratta dei file che crea OBSE in Directory utente\Documenti\My Games\Oblivion\Saves al salvataggio di una partita, contenenti tutti i dati e le variabili supportate unicamente da OBSE e che devono essere ricaricati successivamente al caricamento del canonico file di salvataggio del gioco, pena il mancato funzionamento degli script di OBSE in quel dato caricamento. Siccome non abbiamo ancora salvato nessuna partita con OBSE attivo, è corretto che OBSE non trovi traccia di quel file. Provvediamo subito: riavviamo Oblivion, carichiamo il nostro salvataggio PrisonSewer01 e creiamo un nuovo salvataggio col comando save PrisonSewer02. Usciamo dal gioco, riavviamo Oblivion e carichiamo il salvataggio PrisonSewer02. Uscendo nuovamente dal gioco e consultando il file obse.log potremo vedere che successivamente al caricamento di PrisonSewer02.ess è stato correttamente caricato anche PrisonSewer02.obse.
OBSE - L'installazione di ConScribe
Oblivion è praticamente privo di un vero e proprio strumento di debug, pertanto anche in questo caso la comunità si è dovuta arrangiare per quanto possibile. Ad oggi non è possibile controllare il comportamento dell'eseguibile oblivion.exe per identificare eventuali crash, ma è possibile visualizzare in console alcune informazioni fornite dai mod che prevedono un qualche tipo di debug dei loro script. Siccome in seguito al crash di Oblivion non è ovviamente più possibile visualizzare alcunchè si è reso necessario salvare queste informazioni di debug in un file di log. E' lo scopo di ConScribe, un utilissimo plugin che provvederà a scrivere su un file di log tutto quello che è apparso in console nell'ultima sessione di gioco. Prevede anche la possibilità di salvare i log singolarmente per ogni mod, ma essi devono espressamente sfruttarla tramite una funzione RegisterLog inclusa negli script, cosa che pochi modder fanno. Scarichiamo ConScribe da qui (http://www.nexusmods.com/oblivion/mods/26510), sezione Files > Main Files > ConScribe 90 e salviamolo nella nostra directory OblivionSetup. Notate che nei dettagli del file è indicato che si tratta di un OMOD Ready Archive. Non significa che il file è in formato OMOD, attenzione. Significa semplicemente che può essere agevolmente [i]convertito in formato OMOD. Riprenderemo quest'argomento più avanti.
Preleviamo la directory OBSE dal file zippato ed estraiamola nella directory \oblivion\data, sovrascrivendo quando richiesto. Nella directory \oblivion\data\obse\plugins comparirà un nuovo file ConScribe.dll. Come nel caso di FastExit non c'è bisogno di configurare nulla, OBSE rileverà la presenza del plugin e lo caricherà di conseguenza.
Avviamo Oblivion e usciamo immediatamente senza caricare nessun salvataggio. Verifichiamo in \oblivion la presenza di un nuovo file ConScribe.log, dove verrà indicato che in assenza di un file ConScribe.ini ne è stato creato uno nuovo in \oblivion\data\obse\plugins, contenente le impostazioni di default. Lasciamo quel file in pace, avviamo Oblivion, carichiamo il nostro salvataggio PrisonSewer02, apriamo la console e scriviamo pippo. Il gioco giustamente si lagnerà segnalando che Pippo non lo conosce. Strano, Pippo lo conoscono tutti. Usciamo dal gioco, andiamo sotto la nuova directory \oblivion\data\ConScribe Logs e apriamo il file Static Log.log. Potremo vedere che all'interno è stato salvato il medesimo errore segnalato in console. Allo stesso modo ConScribe registrerà tutti gli eventuali errori nel gioco registrati dalla console, ma dal momento che ad un crash non necessariamente corrisponde un messaggio di errore in console non è affatto detto che ConScribe possa dare indicazioni sulle cause del crash. Si tratta comunque di uno strumento estremamente utile per identificare anomalie dovute a script non eseguiti correttamente.
OBSE - L'installazione di Oblivion Stutter Remover
E arriviamo al pezzo da novanta : )
Notate che fino ad ora non abbiamo ancora parlato di mod manager e ci siamo limitati ad installare i plugin manualmente. Wrye Bash non avrebbe alcuna difficoltà ad installare FastExit, ConScribe e OSR ma non è ancora il momento di parlare di WB e i tre plugin di cui sopra possono essere installati manualmente senza problema alcuno.
I giocatori di Oblivion sono da sempre afflitti da un problema comune: il famigerato stuttering, ovvero il fenomeno per cui il gioco si muove "a strappi", problema particolarmente sentito negli ambienti esterni. Le cause sono due: limite del motore grafico e limite hardware della macchina su cui gira. Oblivion vanilla va che è una bellezza sulle macchine di ultima generazione, ma una volta moddato pesantemente ecco ritornare lo stuttering. Le soluzioni sono diverse, e nessuna di esse da sola è sufficiente:
- procurarsi hardware più potente
- abbassare i dettagli grafici
- variare una serie di parametri in oblivion.ini, dei quali non ci occuperemo in questa sede
- deframmentare spesso la directory \oblivion con un programma come Defraggler (http://www.piriform.com/defraggler)
- usare Oblivion Stutter Remover
Non ci dilungheremo sul principio di funzionamento dell'ultima soluzione: ci basta sapere che funziona, e anche bene : )
Un ulteriore vantaggio dato da OSR è rendere il gioco molto più stabile in situazioni di overload. Si tratta pertanto di una scelta quasi obbligata per tutti, sia per chi non ha interesse a moddare oblivion, sia per chi preferisce limitarsi a pochi e leggeri mod, sia per chi lo intende moddare fino allo sfinimento.
Prima di installare OSR è il momento di eseguire uno stutter test. Avviate Oblivion, caricate il salvataggio PrisonSewer02, aprite la console e digitate quanto segue:
tdt
sdt 13
tgm
player.setav speed 250
Sì, stiamo barando. Ma è necessario per il test. Aprite la mappa e usate il fast travel verso le stalle alle porte di Bruma. Da lì dirigetevi come dei treni a sud verso Leyawiin, possibilmente non fermatevi mai e proseguite diritti per quanto possibile. Ignorate qualunque nemico lungo la strada, data la velocità dopò un po' sarà lui a ignorare voi. Non è necessario che prendiate nota mentalmente di FPS e VRAM impegnata mano a mano che viaggiate, piuttosto badate all'eventuale stuttering che state subendo e cercate di ricordarvi il percorso che avete seguito. Avete attraversato tutta Cyrodiil e siete arrivati a Leyawiin? Ottimo, ora uscite dal gioco [non avete bisogno di salvare la partita].
Scarichiamo OSR da qui (http://www.nexusmods.com/oblivion/mods/23208), sezione Files > Updates > OSR_4-1-24_RC e salviamolo nella nostra directory OblivionSetup. Preleviamo la directory Data dal file zippato ed estraiamola nella directory \oblivion, sovrascrivendo quando richiesto. Nella directory \oblivion\data\obse\plugins compariranno tre file sr_Oblivion_Stutter_Remover.dll, sr_Oblivion_Stutter_Remover.ini e sr_Oblivion_Stutter_Remover.txt, più una directory ComponentDLLs che alle impostazioni di default verrà ignorata. Apriamo sr_Oblivion_Stutter_Remover.ini e cambiamo i seguenti parametri:
da bReplaceHeap = 0 a bReplaceHeap = 1
da iHeapSize = 450 a iHeapSize = 1024 su PC con almeno 3Gb di ram
Ora rientrate nel gioco e ripetete il test, partendo dalla stessa posizione alle porte di Bruma e se possibile rifacendo la stessa strada fino a Leyawiin. Dovreste notare dei sensibili miglioramenti, ma soprattutto dovreste notare una cosa importante: il vostro frame rate non supererà mai i 30FPS. Questo perchè OSR alle impostazioni di default usa un sistema di FPS CAP per bloccare il framerate a un sottomultiplo della più comune frequenza di refresh dei monitor: 60Hz [a questo proposito è caldamente consigliato abilitare il vsync]. In questo modo il sistema è meno stressato dal motore e può dedicarsi a compiti altrettanto gravosi come l'AI e la gestione degli script.
La configurazione di OSR non ha bisogno di particolari rifiniture ma alcuni utenti potrebbero trovare lo iHeapAlgorithm di default instabile per la loro macchina. Nel caso si può provare ad usare il 5 e, per utenti su Vista e Seven, il 2.
Per quanto riguarda i plugin di OBSE per ora è tutto. In futuro alcuni mod potrebbero aver bisogno di installarne altri, ma nel caso vi verrà indicato nei vari Readme. Quanto sopra è la base per iniziare con OBSE e dovrebbe essere seguita anche da chi non ha la minima intenzione di moddare Oblivion.
III.4 - La Large Address Aware patch
Fact number 1: l'installazione di pesanti mod impegna un sacco di ram di sistema.
Fact number 2: oblivion.exe va in crash superato l'impegno di 1.8Gb.
Chi dispone di un sistema a 64bit con almeno 3Gb di ram può decidere di applicare questa (http://www.ntcore.com/4gb_patch.php) patch all'eseguibile oblivion.exe, eventualmente dopo averne creata una copia di backup, per permettere ad oblivion.exe di sfruttare fino a 3.8Gb di ram [nella realtà in un Oblivion pesantemente moddato l'impegno di ram si assesta fra i 2.5 e i 3Gb]. L'operazione è rapida e indolore, è sufficiente lanciare l'eseguibile scaricabile al link a fondo pagina e puntare al file oblivion.exe. Un messaggio ci informerà che l'eseguibile è stato patchato correttamente.
Nota per utenti Steam: perchè la patch funzioni correttamente pare sia necessario patchare anche il file GameOverlayRenderer.dll presente nella directory principale di Steam. L'operazione dà risultati discordanti fra i vari utenti ed è tuttora in test sui forum ufficiali di Bethesda. La stessa presenza di un file GameOverlayRenderer64.dll fa pensare che l'operazione non dovrebbe ritenersi necessaria. Eseguirla non compromette comunque in nessun modo la funzionalità del gioco.
Patchare l'eseguibile su sistemi a 32bit dotati di 3Gb di ram non ha alcun effetto senza che si aggiunga al boot.ini uno switch /3GB per indicare al sistema di utilizzare più di 2Gb per le applicazioni. Trattandosi di un'operazione che può compromettere la stabilità del sistema non verrà ulteriormente documentata da questa guida.
Nota: al momento l'unico modo per verificare a quanto ammonti l'impegno ram di oblivion.exe è avviare il gioco in modalità finestra lasciando in primo piano il task manager.
III.5 - L'installazione di Wrye Bash
Ed eccoci qua. Siete andati a caccia di mod, vi siete informati sulle ultime novità, avete saturato la banda del provider nel scaricare un bel malloppo di mod e non vedete l'ora di installarli e giocare. Se siete entrati nello spirito di questa guida dovreste aver ormai realizzato che il metodo migliore per scombinare tutto è installarli a caso e sperare che tutto funzioni.
Il metodo migliore per avere invece un Oblivion virtualmente privo di crash, oltre a seguire i passi già illustrati, è imparare ad utilizzare Wrye Bash.
WB è un software dall'aspetto ostico. L'interfaccia, benchè migliorata con gli anni, appare di primo acchito estremamente complicata. Scopriremo invece che una volta imparati i meccanismi basilari è molto più semplice di quel che sembra nonostante la miriade di opzioni, delle quali vedremo solo una parte. Ne impareremo l'uso fino ad arrivare ad un livello di conoscenza intermedio, il resto verrà volutamente ignorato e lasciato ad ulteriore indagine da parte dell'utente.
Lo sviluppo di WB è iniziato con una versione basata su Python, e le versioni attuali non fanno eccezione. Gli sviluppatori preferiscono che gli utenti continuino nell'utilizzare la versione Python-based poichè gli è molto più semplice identificare le cause dei bug segnalati, ma per nostra fortuna ne forniscono una versione Standalone che non richiede l'installazione di Python e di tutta una serie di suoi componenti. L'unico requisito necessario è il pacchetto dei componenti di runtime delle librerie di VisualC++ aggiornate all'SP1 2008, che potreste già avere installato nel vostro sistema in seguito all'installazione di software che ne richiedono la presenza. Lo potete verificare da Pannello Di Controllo > Installazione Applicazioni, in elenco dovreste vedere "Microsoft Visual C++ 2008 Redistributable - x86 9.0.30729.17". In caso contrario potete scaricare quanto necessario da qui (http://www.microsoft.com/downloads/it-it/details.aspx?familyid=a5c84275-3b97-4ab7-a40d-3802b2af5fc2).
Ora che abbiamo i requisiti necessari scarichiamo Wrye Bash da qui (http://www.nexusmods.com/oblivion/mods/22368), sezione Files > Main Files > Wrye Bash 295 - Installer e salviamo il file nella nostra directory OblivionSetup. Avviamo il setup e diamo un'occhiata alle opzioni dell'installer.
Wrye Bash ha la possibilità di essere installato in più versioni differenti in directory differenti, in modo da poterne mantenere una copia stabile e utilizzarne altre da aggiornare con le versioni in test. Noi non lo faremo e ci limiteremo ad installare WB nella sua forma Standalone nella sua directory predefinita Directory Installazione\oblivion\. Pertanto dovremo spuntare solo i flag "Oblivion" e "Wrye Bash [Standalone]". Clickiamo su Next e, se i requisiti risultano soddisfatti, verremo accolti dal messaggio "All prerequisites detected". Clickiamo su Next, lasciamo nella schermata successiva tutti i flag attivi e clickiamo su Install. Attendiamo il termine della copia dei file, rimuoviamo i segni di spunta da tutte e tre le opzioni dell'ultima schermata e clickiamo su Close. Prima di avviare Wrye Bash per la prima volta andiamo a farci un giro nella directory \oblivion. Noteremo la presenza di una nuova directory Mopy, che contiene tutti i file necessari al funzionamento di Wrye Bash. Andiamo sotto \oblivion\mopy\bash\l10n\ e cancelliamo il file italian.txt. Si tratta del file contenente la traduzione dell'interfaccia di WB in italiano, ma è incompleto poichè risalente a vecchie versioni e ci ritroveremmo l'interfaccia metà in inglese e metà in italiano.
Chiudiamo la cartella e finalmente avviamo Wrye Bash da Start > Programmi > Wrye Bash > Wrye Bash - Oblivion [nulla vi impedisce di crearvi un collegamento sul Desktop per comodità]. All'avvio vi suggerisco di non toccare nulla e seguire la guida passo per passo. Non che si corra il rischio di far esplodere qualcosa, ma potreste inavvertitamente abilitare un'oscura opzione senza che abbiate immediata evidenza dell'effetto. Attendete il caricamento di WB e non clickate da nessuna parte.
Nota: se non mi avete dato retta nel ripulire completamente il sistema come indicato nella guida e avete ancora OBMM installato potreste veder apparire una popup che vi chiede di disabilitare il Lock Times ["Turn Lock Times Off?"]. Nel caso rispondete di No. Vedremo più avanti di che si tratta.
L'interfaccia di Wrye Bash
Dopo qualche secondo ci ritroviamo davanti ad una finestra divisa in una serie di tab e totalmente priva di qualsivoglia menu. Oddio, dov'è il mio rassicurante menu File? Dove sono le preferenze? Cosa sono quelle tab? Che razza di programma è questo? Prima di farvi prendere dal panico guardate l'elenco dei file nella tab Mods. Dovreste vedere al minimo il familiare oblivion.esm [che verrà indicato come oblivion.esm [SI] per chi possiede l'espansione Shivering Isles] e un molto oscuro Bashed Patch, 0.esp. Chi possiede espansioni e vari DLC dovrebbe poter vedere in elenco anche tutti i loro ESP.
Se vedete quanto sopra, Wrye Bash si è installato correttamente e ha identificato correttamente la vostra installazione di Oblivion. Ora che ci siamo assicurati che WB stia funzionando come si deve vediamo di illustrare brevemente l'interfaccia del programma. Mano a mano che installeremo i mod vedremo sempre più nuove funzionalità, in modo da poter imparare ad usare WB mentre lo stiamo usando attivamente.
Nota: su alcune installazioni di Oblivion GOTY e più in generale su installazioni dove vi sono almeno due ESP di DLC potreste vedere visualizzati alcuni ESP in rosso poichè hanno erroneamente la medesima data e di conseguenza il medesimo ordine di caricamento. Non allarmatevi, sistemeremo poi.
Clickiamo sul tab Installers in alto a sinistra e rispondiamo Si alla popup che ci chiede se abilitare o meno gli Installers. Apparirà un'ulteriore popup con barra d'avanzamento e messaggio informativo "Refreshing Installers". E' un'operazione che WB eseguirà ogni volta che ad ogni nuovo avvio clickeremo su Installers, senza che ci venga più chiesto se abilitarli o meno. L'abilitazione degli Installers non fa altro che abilitare un sottoprogramma di nome BAIN , che è il software interessato alla gestione dell'installazione e disinstallazione dei mod. Al termine del refresh ci ritroveremo davanti ad una schermata meravigliosamente.. vuota. E' previsto, è perchè non abbiamo ancora nessun mod installabile in elenco. Ora chiudiamo Wrye Bash, banalmente chiudendone la finestra con la X in alto a destra, e torniamo per un attimo nella nostra directory \oblivion. Risaliamo di un livello e notiamo che allo stesso livello di \oblivion in seguito all'abilitazione di BAIN è stata creata una directory Oblivion Mods. Se abbiamo installato Oblivion in C:\Giochi\Oblivion, la nuova directory di nostro interesse sarà C:\Giochi\Oblivion Mods.
Nota per utenti Steam: se ad esempio avete installato Steam in C:\Giochi la directory verrà creata sotto C:\Giochi\Steam\steamapps\common, allo stesso livello della directory di Oblivion.
Come impostazione predefinita la directory Oblivion Mods contiene quanto segue:
Bash Installers
Bain Converters
--Corrupt
--Duplicates
Bash
Converters.dat
Installers.dat
Bash Mod Data
Table.dat
Table.dat.bak
Tutti i nostri mod in formato rar, zip o 7z dovranno essere copiati sotto la directory Bash Installers perchè BAIN vi possa accedere. Per ora non fatelo, dobbiamo prima capire bene come funziona WB. Notate che WB non può installare mod in formato OMOD, pertanto se ne avete già scaricati in quel formato le alternative sono due: riscaricarli in formato non-OMOD oppure convertirli da OMOD a formato compresso rar, zip o 7z. Vedremo più avanti come eseguire quest'ultimo punto. Ora vediamo nel dettaglio le varie tab.
La tab Installers
Riapriamo WB e torniamo sulla tab Installers. Stavolta il refresh impiegherà un istante ma mano a mano che installeremo mod impiegherà sempre più tempo. Ridimensioniamo a piacere i vari box in modo da visualizzare correttamente tutti gli header e diamo uno sguardo al box di sinistra: contiene un unico package di nome ==Last==, che altro non è che uno dei marker che utilizzeremo per suddividere i mod per categoria. I vari header del box indicano rispettivamente il nome del package, l'ordine di installazione, la data dell'ultima modifica, le dimensioni del package e la quantità di file contenuti. Selezionamo ==Last== clickandolo una sola volta col sx e notiamo che nel box in alto a dx sono comparse delle informazioni nelle varie tab.
La tab General, che al momento indica ogni caratteristica con N/A poichè il package selezionato è di per sè vuoto, visualizza una serie di informazioni riassuntive delle caratteristiche del package nella sezione ==Overview, più i file installati nella sezione ==Configured files. Avendo selezionato un package vuoto ovviamente non viene elencato nessun file.
La tab Matched, al momento vuota, indica quali file del mod sono stati installati in locale nella struttura \oblivion\data. Ovviamente per il package ==Last== non ve ne è nessuno.
La tab Missing, che in condizioni normali deve essere sempre vuota, indica quali file del package non sono stati installati, ad esempio perchè il package scaricato è corrotto.
La tab Mismatched, al momento vuota, elenca quali file in locale sono diversi da quelli nel package, ad esempio i vari file .ini che abbiamo customizzato manualmente o i file che sono stati sovrascritti con altre versioni da altri package.
La tab Conflicts, al momento vuota, elenca quali file del package siano in conflitto con file di altri package. Ne vedremo solitamente elencati parecchi ed è perfettamente normale.
La tab Underriden, che in condizioni normali deve essere sempre vuota, elenca i file che in seguito a riordinamento dei package [ad esempio perchè è stato sbagliato l'ordine di installazione] dovrebbero essere nuovamente reinstallati poichè non ve ne è in locale la versione corretta.
La tab Dirty, che in condizioni normali deve essere sempre vuota, elenca i file che in seguito a riconfigurazione di un package [ad esempio perchè abbiamo installato una parte del mod che non desideravamo] dovrebbero essere rimossi poichè inutilizzati.
La tab Skipped contiene i file non riconosciuti come "standard" da Wrye Bash, ad esempio screenshot inclusi in un texture package, che l'utente può decidere di escludere durante l'installazione dei package per risparmiare spazio.
La tab Mods
Ritorniamo in alto fra le tab principali e selezioniamo Mods, che insieme ad Installers sarà la tab dove risiederemo per la maggior parte del tempo. La tab elenca tutti gli ESM ed ESP presenti nella directory \data, sia abilitati sia disabilitati, ordinabili eventualmente per nome, ordine di caricamento, autore, ecc. I vari header indicano il nome del file su disco, l'ordine di caricamento, il voto [Rating] che gli abbiamo facoltativamente assegnato, il gruppo al quale abbiamo facoltativamente assegnato l'ESP, l'Installer di cui fa parte, la data di ultima modifica [che di fatto determinerà l'ordine di caricamento], la dimensione, l'autore del mod e il suo univoco CRC check. L'ordine visualizzato varierà a seconda dell'header su cui clickeremo col tasto sx. Clickiamo su Load Order in modo da visualizzare l'elenco in ordine di caricamento.
Nella parte destra della finestra vediamo un box contenente una serie di informazioni che compariranno selezionando uno degli ESM/ESP. Proviamo ora, selezionando oblivion.esm clickandoci su una sola volta col sx. Dall'alto in basso il box visualizzerà il nome del file, l'autore, la data di ultima modifica, la descrizione [vuota per oblivion.esm], i suoi master [oblivion.esm non ne ha chiaramente nessuno] e i tag della bashed patch, anch'essi vuoti per oblivion.esm, e che illustreremo quando spiegheremo nei dettagli il funzionamento della bashed patch.
Chi ha in elenco altri ESP di eventuali DLC può selezionarli e notare come cambiano le varie informazioni nel box di dx. In particolare per ogni ESP verrà indicato che il loro master è oblivion.esm.
Come anticipato più su, alcuni ESP potrebbero essere evidenziati in rosso poichè hanno erroneamente il medesimo ordine di caricamento di altri ESP. Posizionandovi sopra il puntatore del mouse dovreste vedere nella barra di stato in basso il messaggio "Active in load list. WARNING: Has some load order as another mod". Nel caso clickate col tasto dx sugli ESP evidenziati in rosso, scegliete File > Redate e nella nuova popup assegnategli una data qualsiasi, purchè diversa dalla data degli altri ESP. Per semplicità limitatevi a cambiare l'ultima cifra dell'anno, le date corrette le imposteremo più avanti grazie a BOSS.
Fra gli ESP in elenco vedrete anche un ESP molto particolare, che deve sempre essere caricato per ultimo: la Bashed Patch, ovvero la chiave di volta su cui si basa l'intero modding di Oblivion. Per ora lasciamola in pace, vedremo più avanti nei dettagli a cosa serve e perchè è così utile.
La tab Saves
Qui vengono elencati i file di salvataggio. Dovremmo vedere in elenco i nostri PrisonSewer01.ess e PrisonSewer02.ess che abbiamo creato più indietro. I vari header indicano il nome del file su disco, la data del salvataggio, la dimensione, il tempo di gioco, il nome del giocatore [nel nostro caso Test] e la cella in cui ci si trovava al momento del salvataggio [nel nostro caso City Isle]. Il colore del piccolo box a sx del nome del salvataggio ne indica lo stato:
[b]Porpora indica un salvataggio completamente sincronizzato con gli ESP abilitati nella tab Mods.
Blu indica un salvataggio non completamente sincronizzato con gli ESP abilitati nella tab Mods, capita quando il salvataggio comprende degli ESP i cui master sono assenti o disabilitati.
Verde indica un salvataggio che non fa uso di uno o più ESP abilitati nella tab Mods, capita quando il salvataggio non comprende ancora un ESP di recente installazione.
Arancione indica un salvataggio i cui ESP hanno un ordine di caricamento diverso rispetto a quel che avevano quando il salvataggio è stato eseguito; chi possiede ESP di DLC e poco più su ha dovuto cambiarne la data poichè evidenziati in rosso causa medesima data fra più ESP vedrà il salvataggio in colore arancione. Per ora non è un problema per i nostri salvataggi PrisonSewer01.ess e PrisonSewer02.ess poichè come detto più indietro i DLC sono privi di conflitti fra loro e possono essere caricati in qualsiasi ordine quando sono gli unici presenti in Oblivion.
Rosso indica un salvataggio che fa riferimento a degli ESP che nella tab Mods non esistono, capita quando il salvataggio non può più far riferimento ad ESP che sono stati eliminati in seguito alla disinstallazione di un mod. Caricare un salvataggio di questo tipo in Oblivion farà apparire un messaggio di avviso riguardo a contenuto non più presente. In questi casi prima di proseguire nel gioco è bene eseguire un nuovo salvataggio, uscire da Oblivion e ricaricare il nuovo salvataggio, che sarà diventato quello che in gergo si definisce un Clean Save e che verrà visualizzato in porpora.
Va da sè che la condizione ideale per rendere felice Oblivion è avere a che fare unicamente con salvataggi in porpora.
Selezionando uno dei salvataggi vedremo apparire una serie di informazioni nel box di destra. Dall'alto in basso il nome del file su disco, le informazioni su nome giocatore, livello del giocatore, data, tempo di gioco e nome cella, lo screenshot del luogo in cui ci trovavamo al momento del salvataggio e la lista degli ESM/ESP a cui fa riferimento il salvataggio, che Wrye Bash definisce come masters list al pari di quella che abbiamo visto per gli ESP nella tab Mods. Ebbene sì, dal punto di vista di Oblivion i file di salvataggio ESS non sono nient'altro che degli ESP, contenenti inoltre la struttura ad albero di NetImmerse per memorizzare le variazioni sui nodi con le informazioni sui vari stati delle celle. Mano a mano che avanzeremo nel gioco i file di salvataggio aumenteranno sempre più di dimensione, poichè all'albero di default verranno via via aggiunti tutti i nodi con gli stati aggiornati. Gli ESS non possono comunque essere caricati dal Construction Set poichè il file ha un header differente dagli ESP e pertanto non viene riconosciuto.
La tab INI Edits
Non vi siete stufati di dover editare oblivion.ini a manina ogni volta? Ora non vi stuferete più. WB contiene una moltitudine di impostazioni comunemente variata dall'utente nel file oblivion.ini, come la disabilitazione del joystick, la disabilitazione delle border regions, eccetera. In più i vari mod possono fornire degli INI Edits personalizzati, come DarnUI che necessita di cambiare i font di default. L'utente può poi scegliere di prepararsi degli INI Edits personalizzati secondo il proprio gusto. Per scegliere i vari tweak è sufficiente clickare col dx sulla voce che si desidera abilitare/disabilitare e dare Apply. Per ora non tocchiamo nulla, al momento non ne abbiamo bisogno.
Le tab Screenshots, PM Archive e People
Personalmente non utilizzo nessuna di esse ma c'è chi può trovarle utili. Nella tab Screenshots vengono appunto conservate le schermate del gioco salvate su disco, mentre le tab PM Archive e People servono per conservare traccia dei messaggi scambiati con i modder sui vari forum e con ogni probabilità non saranno funzioni che utilizzerete. Non verranno esposte ulteriormente in questa guida.
Ora chiudiamo Wrye Bash e prima di proseguire facciamo una piccola digressione per installare un software essenziale che va ad integrarsi perfettamente con Wrye Bash: BOSS.
L'installazione di BOSS
Grazie a BOSS non dovrete più preoccuparvi di riordinare manualmente i plugin. BOSS va ad interrogare una masterlist costantemente aggiornata contenente l'ordine di caricamento di oltre 12mila mod e si incaricherà di ridatare ogni singolo ESP per far sì che venga caricato nell'ordine corretto. L'uso di BOSS è questione di un singolo click in Wrye Bash.
Scarichiamo BOSS da qui (http://www.nexusmods.com/oblivion/mods/20516), sezione Files > Main Files > BOSS 1-8 Installer e salviamolo nella nostra directory OblivionSetup. Avviamo l'installer, clickiamo su Next e attiviamo il flag su Oblivion senza cambiare il percorso offerto. Nel caso Oblivion non compaia in elenco poichè BOSS non è stato in grado di riconoscerne la presenza spuntiamo Other Location e andiamo a puntare a Directory Installazione\oblivion\ [per gli utenti Steam sarà Directory Installazione\Steam\Steamapps\common\oblivion]. Clickiamo su Next, lasciamo nella nuova schermata tutti i flag al default e clickiamo Install. Al termine della copia dei file clickiamo su Next, nella nuova schermata rimuoviamo tutti i flag e clickiamo su Close. Per ora NON lanciamo BOSS, abbiamo ancora qualcosa da fare in Wrye Bash.
Configurare Wrye Bash
Apriamo WB e nella tab Mods clickiamo col dx in un punto libero qualsiasi dello schermo, o in alternativa su uno qualsiasi degli header. Nel drop-down menu comparso assicuriamoci che siano abilitati i flag solo sulle seguenti voci [disabilitare tutte le voci non comprese nella lista]:
Auto-Ghost
Lock Times
BOSS Disable Lock Times
Check mods against BOSS's dirty mod list
Spostiamoci nella tab Installers e clickiamo col dx in un punto libero qualsiasi dello schermo, o in alternativa su uno qualsiasi degli header. Nel drop-down menu comparso assicuriamoci che siano abilitati i flag solo sulle seguenti voci [disabilitare tutte le voci non comprese nella lista, incluso "Skip OBSE Plugins"]:
Avoid at Startup
Enabled
Auto-Anneal
Auto-Anneal/Install Wizards
BSA Redirection
Clean Data Directory
Show Lower Conflicts
Wizard Icon Overlay
L'abilitazione di BSA Redirection avrà due effetti:
- In \oblivion\data verrà creato un nuovo file di nome ArchiveInvalidationInvalidated!.bsa
- oblivion.ini verrà modificato aggiungendo alla direttiva SArchiveList il BSA ArchiveInvalidationInvalidated!.bsa
Lo scopo di tale operazione è permettere ad Oblivion di caricare correttamente i loose file che si propongono di sostituire quelli contenuti nei BSA vanilla, come ad esempio una texture ad alta risoluzione. Come indicato nella Parte I di questa guida, Oblivion carica i loose file col medesimo nome di quelli già presenti nei BSA quando i loose file risultano essere più recenti, di fatto invalidando in tempo reale il file del caso contenuto nel BSA [pur non modificando in nessun modo il file BSA originale]. Tale sistema non sempre funziona correttamente poichè il gioco inizia a ritenere i file nei BSA come invalidabili solo quando durante il caricamento dei loose file incontra il primo di essi senza che venga eseguito un controllo di invalidazione a monte, pertanto nel frattempo Oblivion potrebbe aver già caricato erroneamente i file originali nei BSA, col risultato di miscelare texture vanilla con texture aggiornate senza caricare quest'ultime nella loro totalità.
In sintesi il bug consiste nel fatto che Oblivion non sa di dover invalidare i file nei BSA fino a che non rileva correttamente la presenza di un loose file. Il problema è che nel frattempo potrebbe già aver caricato parte di quei BSA, compresi i file originali che il mod si propone di sostituire.
Il metodo BSA Redirection fa sì che Oblivion venga ingannato caricando per primo il file ArchiveInvalidationInvalidated!.bsa, che contiene una dummy texture non utilizzata nel gioco, in modo da essere avvertito in tempo sufficiente della presenza di file esterni ai BSA vanilla, scansionando quindi correttamente i vari i loose file presenti in \data. L'operazione va eseguita una sola volta e dimenticata per sempre. Qualunque texture pack installeremo verrà d'ora in poi caricato correttamente dal gioco.
La configurazione di WB è completata, ora vedremo come installare i nostri mod.
L'installazione del nostro primo mod
Installeremo un mod che non dovrebbe mancare in nessuna installazione di Oblivion, pertanto al pari dei plugin di OBSE installati addietro verrà considerato fra i mod essenziali. Ricordate di quando abbiamo accennato al problema del cell buffer purging? Per ovviare al problema si dovrebbe prendere l'abitudine di dare periodicamente il comando pcb [Purge Cell Buffer] da console, ma è molto meglio avere chi lo fa automaticamente per noi. A questo ha pensato in passato il mod Streamline, ma Streamline possiede una serie di funzioni ormai obsolete sulle macchine moderne e installarlo solo per avere un sistema automatizzato di buffer purging non vale la pena. Molto meglio avere a disposizione un plugin che si occupi solo di buffer purging, come il neonato ExPCB, che accoppiato ad OSR esegue un gran bel lavoro nel mantenere la sessione di gioco pulita da schifezzuole varie. Scarichiamo ExPCB da qui (http://www.nexusmods.com/oblivion/mods/38441), sezione Files > Main files > ExPCB Eng e salviamolo in Directory Installazione\Oblivion Mods\Bash Installers. Avete letto bene, non lo salveremo nella nostra directory OblivionSetup dove finora abbiamo conservato tutto ma nella directory di BAIN. D'ora in poi scaricheremo qualunque mod in questa particolare directory in modo che BAIN lo possa installare correttamente via Wrye Bash. In futuro potreste voler spostare tutto quanto abbiamo scaricato finora dalla nostra directory OblivionSetup alla directory di BAIN e re-installare quei mod in BAIN per fare ordine. Per ora non è necessario, lasciate quei file dove sono.
Torniamo in Wrye Bash e selezioniamo la tab Installers. Se non vi vedete nulla di nuovo clickate col dx e dal menu selezionate Refresh Data. Ehilà, è comparso un nuovo package! Ed è proprio quello che abbiamo scaricato. Clickate una o più volte sull'header Order in modo da visualizzare i package in ordine di installazione. ==Last== dovrebbe comparire per ultimo, con il load order 1, mentre il nostro package ExPCB_Eng-38441-1.7z dovrebbe comparire con l'ordine 0.
Un momento, mi pare di sentire arrivare qualche obiezione dal fondo della fila.. ma la buona norma non diceva di installare sempre per prime le patch non ufficiali? Perchè stiamo andando controcorrente? Semplice: con Wrye Bash non abbiamo alcun bisogno di rispettare alcun ordine di installazione dei package così come facevamo manualmente o con OBMM. Semplicemente, se ci accorgeremo di dover sistemare qualcosa ci basterà spostare il package nell'ordine corretto ed eseguire la funzione Anneal ["tempra"], che dove necessario riallineerà i file decompressi e installati in \data prelevandoli dai package originali presenti nella directory di BAIN. Pertanto ci possiamo sentire perfettamente liberi di installare prima ExPCB e POI le Unofficial Patch, che provvederemo a sistemare nell'ordine corretto. Ora torniamo al nostro ExPCB.
Prima di vedere come installarlo inseriamolo in una categoria sufficientemente generica, ad esempio TWEAKS per indicare i mod che rifiniscono il comportamento del motore del gioco. Clickiamo col dx e dal menu scegliamo Add Marker. Comparirà un nuovo dummy package di nome ====, noi chiamiamolo ==TWEAKS== e diamo invio. Se necessario assicuriamoci che i package siano tuttora ordinati per ordine di caricamento clickando su Order, dopodichè teniamo premuto il sx sul package ExPCB e trasciniamolo fra ==TWEAKS== e ==Last==. In alternativa possiamo spostare il package selezionato con la combinazione CTRL + freccia su/giù. L'ordine dei package dovrà essere il seguente:
Package Order
==TWEAKS== 0
ExPCB_Eng_38441-1.7z 1
==Last== 2
I marker altro non sono che dei package vuoti alla pari di Last. In un'installazione pesantemente moddata potremmo volerne creare diversi, ad esempio GUI per quelli che modificano l'interfaccia grafica, TEXTUREPACK per quelli che installano nuove texture, etc.
Ora selezioniamo col sx il nostro package ExPCB e diamo un'occhiata a cosa accade nel box di destra. Nella tab General vedremo un riassunto delle caratteristiche del Package, nel tab Matched non vedremo nulla, nella tab Missing vedremo un elenco dei file del package assenti in locale [perchè non lo abbiamo ancora installato], tutte le altre saranno vuote. Diamo un'ultima occhiata alla tab General: nella sezione Configured Files vedremo i file che saranno installati in \oblivion\data:
== Configured Files
ExPCB.esp
Docs\Readme.txt
ini\ExPCB.ini
TUTTI i file installati da Wrye Bash hanno come directory radice \oblivion\data, sebbene il percorso completo dei file venga omesso dall'elenco. Pertanto ExPCB.esp andrà a finire sotto oblivion\data, Readme.txt andrà a finire sotto \oblivion\data\Docs ed ExPCB.ini andrà a finire sotto oblivion\data\ini . A questo proposito è bene precisare che gli archivi dei mod per poter essere installati in BAIN devono essere in formato BAIN-ready, ovvero avere al loro interno una struttura ad albero identica a quella di \oblivion\data. Normalmente quasi tutti gli archivi sono così costruiti, ma alcuni potrebbero avere una struttura particolare che richiede qualche rimaneggiamento, come ad esempio la presenza di tutti i file sotto un'ulteriore directory col nome del mod, cosa che BAIN non è in grado di riconoscere. Nel caso si scaricassero dei mod con tale struttura, essi vanno prima decompressi e ricostruiti propriamente, per poi essere nuovamente compressi.
Guardiamo un poco più in basso e vediamo che il box Sub-Packages è rimasto vuoto. E' corretto, poichè il package scaricato non contiene nessun sub-package, caratteristica di mod di grandi dimensioni che suddividono il package in diverse sezioni a seconda di cosa si voglia installare. L'utente potrebbe ad esempio voler installare solo una parte di un texture pack che offre la possibilità di migliorare le texture di rocce, alberi, murature, eccetera. In quel caso il modder dovrebbe aver avuto cura di suddividere il package in diversi sub-package con vari nomi come [i]rocce, alberi, murature selezionabili singolarmente via BAIN.
In basso a destra nel box Esp/m Filter troviamo gli eventuali ESM ed ESP facenti parte del mod. Sarà perfettamente normale trovare tale box vuoto in caso di mod come i texture pack migliorativi delle texture esistenti, che non necessitano di ESP per caricare i loose file delle varie texture. Assicuriamoci che sia presente il check su ExPCB.esp, indicando a WB che saremo intenzionati ad installare anche quel file.
L'ultimo box in basso è utile per indicare qualche nota personale sul mod. Tranquilli, WB non ha accesso online e le leggerete solo voi, pertanto siete liberi di scriverci dentro questo mod fa schifo. Scriviamoci "Il mio primo mod!" tanto per verificare il funzionamento del box. Non c'è nessuna funzione di salvataggio della nota, verrà automaticamente salvata all'uscita di WB.
Ora, finalmente, installiamo il mod! Nel box di sx clickiamo col dx sul package ExPCB e dal menu scegliamo Install. Notiamo che il piccolo box di fianco al package è passato da rosa [non installato] a verde con all'interno un + . Le varie tab han cambiato aspetto, tutto ciò che era elencato in Missing è ora finito in Matched, e il riassunto nella sezione ==Overview della tab General si è aggiornato di conseguenza.
Spostiamoci nella tab Mods, verifichiamo la presenza di ExPCB.esp nell'elenco e attiviamolo con un singolo click sul piccolo box verde.
Fine! Questa è l'installazione dei mod in BAIN. Per disinstallarli basta seguire la procedura opposta, clickandovi su col dx e selezionando Uninstall. Il package originale che avete scaricato NON verrà cancellato. Se date un'occhiata nella directory \oblivion\data potrete verificare che sono stati aggiunti i file contenuti nel package ExPCB.
Ora, un ultimo dettaglio prima di proseguire: riordiniamo automaticamente gli ESP con BOSS! Chi di voi possiede le espansioni e/o i DLC potrebbe avere un buon elenco di ESP. Tutti gli altri dovrebbero vedere in elenco solo oblivion.esm, ExPCB.esp e la misteriosa Bashed Patch, il cui scopo verrà illustrato più avanti.
Date un'occhiata in basso a sinistra sulla barra di stato. C'è una serie di icone fra cui una con su scritto BOSS, non molto leggibile a dire il vero. Clickiamoci su una singola volta col sx e attendiamo il caricamento di BOSS. Wrye Bash sembrerà andare in freeze, attendete qualche istante e verrà aperta una pagina del vostro browser predefinito con il report del riordinamento. Essendo la prima volta che lanciate BOSS porebbe anche apparirvi una pagina con l'help. Quella di nostro interesse è Better Oblivion Sorting Software Log. Se volete potete dare un'occhiata veloce al report, dopodichè potete chiudere il browser. Tutto qui? Tutto qui. BOSS non richiede nessuna interazione lato utente, deve essere semplicemente lanciato [o da Wrye Bash o dal menu avvio di Windows] e come output visualizza il report, indicando che ha completato quanto richiesto: si è collegato al server contenente la masterlist, se necessario ha aggiornato la copia locale, dopodichè ha riordinato tutti gli ESP. Tale operazione andrà eseguita [i]ogni volta che si installerà un nuovo mod. Torniamo in Wrye Bash.
Nella tab mods quando ordinata per Load Order dovreste vedere, al minimo, quanto segue:
Oblivion.esm
ExPCB.esp
Bashed Patch, 0.esp
Chi possiede la GOTY vedrà quanto segue:
Oblivion.esm [SI]
DLCShiveringIsles.esp
ExPCB.esp
DLCHorseArmor.esp
DLCOrrery.esp
DLCVileLair.esp
DLCMehrunesRazor.esp
DLCSpellTomes.esp
DLCThievesDen.esp
DLCBattlehornCastle.esp
DLCFrostcrag.esp
Knights.esp
Bashed Patch, 0.esp
In più i possessori della GOTY dovrebbero notare che ogni singolo DLC all'infuori di Shivering Isles è ora sottolineato. Wrye Bash ci indica così gli ESP contenente dei dirty edits così come rilevato da BOSS. Potete vedere i dettagli di quanto rilevato in due modi: posizionando il puntatore del mouse sul singolo ESP e leggendo la nota nella barra di stato in basso, o clickando sull'icona Mod Checker sulla barra in basso [l'ultima a destra prima del ?] per visualizzare una nuova finestra con un report dettagliato. Nella Parte IV - rifinire l'installazione - vedremo come ripulire tali record con Tes4Edit.
Ora proseguiamo l'installazione base aggiungendo le patch non ufficiali.
L'installazione delle Unofficial Patch con Wrye Bash
Le Unofficial Patch non dovrebbero mancare in nessuna installazione di Oblivion, sia che si intenda moddarlo sia che si intenda lasciare il gioco nel suo stato vanilla. Ad oggi correggono quasi 2mila bug di diversa natura [quest non completabili, meshes e textures errate e così via] e sono da ritenersi un mod essenziale per chiunque. Iniziamo con lo scaricare la Unofficial Oblivion Patch da qui (http://www.nexusmods.com/oblivion/mods/5296), sezione Files > Main files > Unofficial Oblivion Patch v3_2_0 Manual Version e salviamola nella directory di BAIN [la solita \Oblivion Mods\Bash Installers]. Tenete presente che TESNexus richiede registrazione per il download di file superiori a 2Mb.
Apriamo Wrye Bash e andiamo sulla tab Installers. Il package Unofficial_Oblivion_Patch_v3_2_0_Manual_Version-5296.7z sarà comparso in elenco. Come abbiamo visto più indietro creiamo un nuovo marker di nome ==PATCH== e spostiamo il package Unofficial Oblivion Patch v3_2_0 Manual Version subito sotto tale marker. L'ordine dei package sarà il seguente:
Package Order
==PATCH== 0
Unofficial Oblivion Patch v3_2_0 Manual Version 1
==TWEAKS== 2
ExPCB_Eng_38441-1.7z 3
==Last== 4
Selezioniamo il package della UOP e prima di installarlo diamo un'occhiata nei box a destra. La tab General conterrà una lista di 2399 file fra meshes, texture e suoni che una volta installato il package verranno copiati in \data allo stesso modo di come è avvenuto con quelli di ExPCB. La nostra directory \oblivion\data si sta popolando di un sacco di loose file, referenziati dall'ESP Unofficial Oblivion Patch.esp che avremo cura di lasciare abilitato nel box Esp/m Filter. In tale box deselezioniamo invece Oblivion Citadel Door Fix.esp e UOP Vampire Aging & Face Fix.esp. Il primo è ignorabile, riguardo il secondo vedremo più avanti come sostituirne l'effetto tramite un tweak della Bashed Patch. Clickiamo col dx sul package della UOP, selezioniamo install e attendiamo l'estrazione dei file.
Se ci siamo scordati di deselezionare i due ESP Oblivion Citadel Door Fix.esp e UOP Vampire Aging & Face Fix.esp prima di installare il package, niente paura. Semplicemente deselezioniamoli ora, clickiamo col dx sul package della UOP e selezioniamo Anneal. Gli ESP verranno rimossi dalla directory locale \oblivion\data.
Spostiamoci sulla tab Mods e abilitiamo l'ESP Unofficial Oblivion Patch.esp.
Chi ha la GOTY o possiede l'espansione Shivering Isles deve scaricare la Unofficial Shivering Isles Patch da qui (http://www.nexusmods.com/oblivion/mods/10739), sezione Files > Main files > v1_4_0 Manual install 7Z version e installarla con BAIN allo stesso modo della UOP, avendo prima cura di spostare il package della USIP sotto quello della UOP. Il suo ESP andrà abilitato nella tab Mods.
Chi ha la GOTY o possiede uno o più DLC deve scaricare la Unofficial Official Mods Patch da qui (http://www.nexusmods.com/oblivion/mods/9969), sezione Files > Main files > Unofficial Official Mods Patch v15 Manual Version e installarla con BAIN, avendo prima cura di spostare il package della UOMP sotto quelli della UOP e della USIP. Nel box Esp/m Filter andranno abilitati solo gli ESP dei DLC in vostro possesso [lasciateli tutti abilitati se avete la GOTY]. L'ESP DLCThievesDen - Unofficial Patch - SSSB.esp è obsoleto e va lasciato disabilitato sia per chi ha la GOTY, sia per chi ha solo alcuni DLC. Tutti gli ESP installati andranno abilitati nella tab Mods.
Tutti quanti indipendentemente dalla versione posseduta devono scaricare gli Unofficial Oblivion Patch Supplementals da qui (http://www.nexusmods.com/oblivion/mods/27710), sezione Files > Main files > Unofficial Patch Supplementals e installarli con BAIN, avendo prima cura di spostare il package degli UOPS sotto quelli di UOP, USIP e UOMP. Nel box Sub-Packages tutti quanti dovranno abilitare 00 Unofficial Oblivion Patch Supplemental e verificare che nel box Esp/m Filter sia abilitato Unofficial Oblivion Patch.esp. Chi possiede espansioni e DLC vari dovrà abilitare i restanti compatibilmente con quanto posseduto. Chi ha la GOTY deve semplicemente abilitare tutto. Chi possiede i vari DLC o chi ha la GOTY vedrà apparire al termine dell'installazione un box informativo riguardo alle date modificate degli ESP installati. Al termine verifichiamo che nella tab Mods tutti gli ESP installati siano abilitati. Il vostro package order dovrebbe ora essere simile a questo:
Package Order
==PATCH== 0
Unofficial Oblivion Patch v3_2_0 Manual Version 1
v1_4_0_Manual_install_7Z_version-10739 2
Unofficial_Official_Mods_Patch_v15_Manual_Version-9969 3
Unofficial_Patch_Supplementals-27710-3-3-7 4
==TWEAKS== 5
ExPCB_Eng_38441-1.7z 6
==Last== 7
Indipendentemente dalla versione posseduta dovreste poter notare che uno o più package al di sopra di Unofficial Oblivion Patch Supplementals han cambiato colore. Sono diventati arancione, per indicare che sono in conflitto con altri package. Nel loro caso sono in conflitto proprio con la UOPS, poichè ne condividono file con lo stesso nome. E' un male? NO! E' perfettamente normale, è previsto e sarebbe un male se non fosse così. Semplicemente, la UOPS ha sovrascritto diversi file dei package precedenti con i suoi aggiornati. Lo potete verificare agevolmente nella tab Conflicts di ogni package.
Se avete sbagliato qualcosa nell'ordine dei package o nella selezione degli ESP non ricominciate da capo! Non ne avete alcun bisogno. Semplicemente riordinate i package come sopra indicato, abilitate gli ESP necessari come sopra indicato e usate una delle geniali funzioni di Wrye Bash: ANNEAL ALL [Ritempra tutto]. Click dx nella finestra di BAIN > Anneal All. Il comando non farà altro che riallineare tutti i file in locale compatibilmente con quanto avete riordinato e selezionato in BAIN. Mica male, eh?
Questo è quanto potrete aver bisogno di fare in futuro quando installerete dei mod che han necessariamente bisogno di un preciso ordine di installazione. Se per ipotesi installerete un mod che come da suo Readme esige di essere installato prima di ExPCB non dovrete aver bisogno di disinstallare ExPCB, installare il mod e reinstallare ExPCB. Semplicemente in BAIN posizionerete il mod PRIMA di ExPCB, installerete il mod e darete il comando Anneal All.
Dimenticatevi di tutti gli errori di installazione che potete aver commesso installando i mod manualmente o con OBMM, dimenticatevi di dover passare le notti a reinstallare tutto. Ora che avete Wrye Bash non avrete [i]mai più bisogno di rifare tutto da capo nè di scervellarvi a capire cosa dovete installare PRIMA, col rischio di mandare tutto a scatafascio se sbagliate l'ordine. Se certi mod avranno bisogno di essere installati in un certo ordine, semplicemente li posizionerete dove necessario e lancerete l'Anneal. E' o non è un gran bel pezzo di software? : )
Come ultimo particolare lanciate ancora una volta BOSS dall'icona di Wrye Bash in modo da riordinare al posto giusto gli ESP delle Unofficial Patch. La prossima volta che avvieremo Oblivion verremo accolti dal messaggio "Unofficial Oblivion Patch added", è un particolare oggetto dell'inventario per configurare i dettagli della UOP dall'interno di Oblivion. Non c'è bisogno di configurare nulla, le impostazioni di default van benissimo come sono.
Prima di proseguire fatevi un giretto in \oblivion\data. Potrete notare che rispetto alla nostra installazione vergine sono comparse più directory [textures, meshes, DistantLOD, etc.]. Sono tutti i loose file che abbiamo installato in BAIN, contenuti negli archivi compressi delle Unofficial Patch. Come accennato più indietro, questa directory col tempo si popolerà di un sacco di file, alcuni particolarmente piccoli come i file NIF delle meshes. Ragion per cui andrà deframmentata spesso, in particolare in seguito all'installazione di nuovi mod.
La nostra installazione base di Oblivion ha ormai preso forma quasi completa, ma prima di dichiararla conclusa dobbiamo ancora installare una piccola utility, dopodichè potremo passare alla Parte IV - Rifinire l'installazione - dove scenderemo più in profondità nell'uso di Wrye Bash e vedremo altri strumenti utili a limare per bene l'installazione.
L'installazione di RefScope
Quando la nostra installazione di Oblivion raggiungerà livelli mai visti prima potremmo aver bisogno di identificare all'interno di Oblivion a quale mod appartiene un oggetto problematico. Come? Con RefScope. Scarichiamolo da qui (http://www.nexusmods.com/oblivion/mods/21862), sezione Files > Main Files > RefScope 2_1_2 e salviamolo nella directory di BAIN. Andiamo nella tab Installers di Wrye Bash, creiamo un marker di nome ==TOOLS== e installiamo RefScope come da solita procedura. Ormai non ci dovrebbe essere bisogno di spiegare come, giusto? : )
Il vostro package order dovrebbe essere simile a questo:
Package Order
==PATCH== 0
Unofficial Oblivion Patch v3_2_0 Manual Version 1
v1_4_0_Manual_install_7Z_version-10739 2
Unofficial_Official_Mods_Patch_v15_Manual_Version-9969 3
Unofficial_Patch_Supplementals-27710-3-3-7 4
==TWEAKS== 5
ExPCB_Eng_38441-1.7z 6
==TOOLS== 7
RefScope_2_1_2-21862-2-1-2.zip 8
==Last== 9
Ricordatevi naturalmente di abilitare l'ESP di RefScope dalla tab Mods dopo aver installato il package. RefScope non ha conflitti di risorse con assolutamente nulla poichè risorse non ne usa [nessuna meshes, nessuna texture, etc], pertanto il suo package può essere posto dove ci pare. L'ho messo in quella posizione giusto per fare ordine. Anche l'ordine di caricamento del suo ESP non è granchè influente, ma è sempre bene lanciare BOSS dopo aver installato RefScope, come dovremo fare per qualsiasi altro futuro mod.
A questo proposito è bene chiarire alcuni concetti importanti nel caso non siano stati finora evidenti:
L'ordine di INSTALLAZIONE dei mod package va deciso manualmente dall'utente
L'ordine di CARICAMENTO degli ESP lo decide BOSS [d'altra parte è il boss.. ok, era brutta]
L'ordine di installazione dei package è influente solo quando vi sono conflitti di RISORSE, non hanno nulla a che vedere coi conflitti fra gli ESP e possono essere identificati agevolmente da Wrye Bash
L'ordine di caricamento degli ESP è influente solo quando ci sono conflitti di ENTITA' interne al gioco e non hanno nulla a che vedere coi conflitti fra i package. I conflitti controllati possono essere gestiti agevolmente da BOSS. I conflitti indesiderati che causano crash possono essere identificati solo dall'utente, disabiltando un ESP per volta e testando ogni volta il risultato nel gioco fino a rintracciare il mod incriminato.
Chiudiamo la parentesi e ritorniamo al nostro RefScope. Avviamo Oblivion e carichiamo il nostro salvataggio PrisonSewer02. Verremo accolti da una popup che ci informerà che RefScope è attivo, la hotkey di default sarà X e verrà abilitato il log grazie a ConScribe che abbiamo provveduto ad installare poco più su. Se vorrete cambiare il tasto di default X vi basterà clickare col dx sullo spell RefScope nel menu degli spells e seguire le voci del nuovo menu apparso. Nota: lo spell di configurazione di RefScope non dovrebbe mai essere selezionato col tasto sx come spell corrente. Limitatevi a selezionarlo col dx per eventuali configurazioni.
All'uscita delle fogne imperiali ci sono due rocce grandi poco più di un pallone da calcio, giusto ai piedi del gradone in pietra di fronte alla grata. Miriamo ad una delle due rocce e teniamo premuto il tasto X. La roccia verrà evidenziata da RefScope per indicarci che è pronto ad analizzarla. Senza rilasciare il tasto X premiamo il tasto Azione [predefinito: barra dello spazio] e comparirà una popup che ci dirà i dettagli dell'oggetto.
Una delle due rocce è la Reference 0012DBBA dello Static 0009DA3B. Entrambi risultano definiti in oblivion.esm. Significa che in oblivion.esm è presente un SINGOLO oggetto 0009DA3B [una roccia] che è ripetuto nel medesimo oblivion.esm una quantità spropositata di volte, fra cui una che si chiama 0012DBBA. La roccia che vediamo quindi nel gioco non è proprio quella roccia Static di nome 0009DA3B, ma una sua referenziazione, che in oblivion.esm si chiama 0012DBBA. Se analizziamo l'altra roccia con RefScope vedremo che lo Static è sempre quello ma la reference è diversa, infatti quella roccia si chiama 0012DBB9.
RefScope ci dà quindi modo di capire a quale ESM/ESP appartiene un entità del gioco, sia essa una creatura o un oggetto inanimato. Se Oblivion andrà in crash quando raccoglierete la spada generata dal mod MiaSpadonaTroppoFiga.esp saprete che quella spada appartiene ad un mod problematico. Ma come identificare a quale mod appartiene? Facile: punterete alla spada, premerete l'hotkey di RefScope e leggerete "Defined in MiaSpadonaTroppoFiga.esp". A quel punto saprete che MiaSpadonaTroppoFiga.esp è un mod da cestinare.
Inoltre, ricordate di quando parlando di wild edits abbiamo accennato a quanto sia sbagliato per un modder modificare le caratteristiche dell'oggetto originale? Bene, quell'oggetto originale non è nient'altro che lo Static. Se un domani vorrete imparare ad usare il Construction Set per eliminare quelle rocce che vi danno un sacco fastidio perchè all'uscita delle fogne ci inciampate, sappiate che dovrete disabilitarne le due Reference 0012DBBA e 0012DBB9, NON il loro Static 0009DA3B, in caso contrario disabiliterete TUTTE le rocce di quel tipo nel gioco. Notate che abbiamo parlato di disabilitazione e non cancellazione. Se ricordate quanto abbiamo accennato a proposito dei dirty edits DR vi ricorderete che le entità degli ESM si disabilitano, non si cancellano. Questo perchè un domani potrebbe capitarvi di installare un mod che fa riferimento proprio a quelle rocce per spostarle poco più in là, e non trovandole vi ritrovereste un bel crash proprio all'uscita delle fogne imperiali [della serie "iniziamo bene.."]. Parleremo a breve di come si ripuliscono dai mod i dirty edit di questo tipo. Nel frattempo puntiamo ancora una volta ad una delle due rocce con RefScope, usiamo il comando Save to Log per salvare nei log di ConScribe quanto abbiamo analizzato, creiamo un nuovo salvataggio PrisonSewer03 e usciamo da Oblivion. Nella directory oblivion\data\ConScribe Logs\Per-Mod vedremo che sono state salvate le informazioni sull'oggetto analizzato. Ci saranno utili per comunicarle eventualmente al modder del caso.
Ultima verifica prima di passare alla quarta parte della guida: apriamo Wrye Bash e diamo un'occhiata alla tab Saves. Dovreste rilevare quanto segue:
PrisonSewer01 è in arancione poichè da quando abbiamo creato quel salvataggio abbiamo cambiato l'ordine degli ESP con BOSS.
PrisonSewer02 è in verde poichè da quando abbiamo creato quel salvataggio abbiamo installato altri ESP dei quali quel salvataggio non fa uso.
PrisonSewer03 è in porpora [condizione ottimale] poichè gli attuali ESP elencati nella tab Mods corrispondono esattamente a quanto fa riferimento quel salvataggio.
E con quest'ultima verifica abbiamo concluso la terza parte della guida. Ora siamo pronti per scendere più in profondità nei meandri di Wrye Bash e dare un tocco di classe all'installazione, che nell'obiettivo di moddare pesantemente il gioco è lungi dall'essere completa, ma sta pian piano crescendo su solide fondamenta : )
Parte IV - RIFINIRE L'INSTALLAZIONE
Nella terza parte abbiamo installato Oblivion da zero, abbiamo migliorato le performance dell'installazione vanilla con alcuni plugin di OBSE e abbiamo imparato l'uso basilare di Wrye Bash. La nostra installazione base è già ad un livello molto solido, ma non è ancora pronta per essere pesantemente moddata. Prima dobbiamo ripulire i plugin preinstallati dalla GOTY [chi non ce l'ha segua comunque la guida per imparare come si fa, sarà necessario farlo con molti altri futuri mod], imparare ad usare la Bashed Patch ed eventualmente ottimizzare le meshes con PyFFI. Quest'ultima parte dato l'impegno molto gravoso per l'utente in termini di tempo verrà indicata come facoltativa.
Quanto segue prevede la modifica di file di Oblivion che se corrotti in qualche modo causa errori da parte dell'utente possono essere ripristinati solo in seguito a reinstallazione. E' quindi il momento di eseguire un backup dell'intera directory \oblivion\data creandone una copia di sicurezza da conservare in un posto sicuro, eventualmente nella nostra directory OblivionSetup.
IV.1 - La pulizia dei plugin con Tes4Edit
Nella prima parte abbiamo spiegato quanto sia importante pulire i plugin dai dirty edits, ora vediamo come. Scarichiamo Tes4Edit da qui (http://www.nexusmods.com/oblivion/mods/11536), sezione Files > Main files > TES4Edit_3_0_15_EXPERIMENTAL e salviamolo dove ci pare, eventualmente nella nostra buona vecchia directory OblivionSetup. Tes4Edit è un software a sè stante e non un mod, pertanto non andrà scaricato nella directory di BAIN. Preleviamo l'unico eseguibile dal file compresso ed estraiamolo nella directory \oblivion. Apriamo Wrye Bash e notiamo la presenza di una nuova icona a forma di cubo nella barra in basso con su scritto Edit. Prima di lanciare Tes4Edit diamo un'occhiata alla tab Mods di Wrye Bash. Potremo vedere che diversi ESP risultano sottolineati, è il modo in cui Wrye Bash ci informa di aver rintracciato dei plugin sporchi grazie al check eseguito da BOSS. Se abbiamo gli ESP ordinati per ordine di caricamento il primo plugin sporco che vedremo dall'alto in basso dovrà essere DLCHorseArmor.esp per chi possiede la GOTY. Puntiamoci su il puntatore del mouse e notiamo che nella barra di stato in basso viene indicato che tale ESP contiene 3 ITM e 0 UDR. Questi ultimi in realtà sono DR [Deleted Reference] e non UDR [Undeleted and Disabled Reference], ma la notazione UDR ha ormai preso piede per indicare entrambi i tipi di record. Prendiamo nota del nome del plugin e lanciamo Tes4Edit dalla barra in basso.
La finestra di avvio di Tes4Edit visualizzerà tutti gli ESP presenti in \oblivion\data in ordine di caricamento. E' estremamente importante pulire UN solo ESP per volta senza intaccare minimamente gli altri. Per fare ciò clickiamo col dx in un punto qualsiasi della finestra di avvio e scegliamo Select None per rimuovere tutti i flag dagli ESP elencati. Selezioniamo il solo DLCHorseArmor.esp e diamo OK. La finestra di avvio sparirà per lasciare il posto alla finestra principale di Tes4Edit, che notiamo essere divisa in due: nella parte sinistra viene visualizzato il plugin selezionato più i suoi master [che nel caso di DLCHorseArmor.esp è il solo oblivion.esm] che vengono caricati automaticamente nonostante non li si sia selezionati nella finestra di avvio, nella parte destra vengono visualizzati i messaggi del software. Attendiamo qualche istante perchè Tes4Edit carichi tutto il necessario. Nella parte destra dovrebbe apparire in fondo il messaggio Background Loader: finished.
Tes4Edit è uno strumento estremamente potente per individuare i conflitti fra gli ESP, ma noi ci limiteremo ad usarlo unicamente per la pulizia. Clickiamo col dx in un punto libero qualsiasi della parte di sinistra e dal drop-down menu scegliamo Apply Filter. Nella nuova finestra impostiamo tutti i flag così come li vediamo in questa (http://cs.elderscrolls.com/constwiki/images/3/3c/Tes4editcleaningfilter.jpg) schermata. Di fatto tutti i flag principali vanno disabilitati e va abilitato il solo "Conflict status inherited by parent". I flag rimarranno in quello stato fra una sessione e l'altra di Tes4Edit, pertanto è necessario impostarli una sola volta, ma ogni volta va comunque applicato il filtro. Dopo aver impostato tutto come si deve clickiamo su Filter e attendiamo qualche istante. Al termine del filtraggio nella parte destra della finestra vedremo apparire il messaggio Processed Records seguito dalla quantità di record processati.
Ora nella parte sinistra della finestra clickiamo col dx su [01] DLCHorseArmor.esp e dal menu scegliamo Undelete and Disable References. Apparirà un Warning al quale daremo Yes. Nella parte destra della finestra vedremo comparire il messaggio "Processed records: 167 - Undeleted Records: 0". Significa che Tes4Edit su 167 record processati nell'ESP DLCHorseArmor.esp non ha rintracciato nessun DR. In caso contrario ci avrebbe indicato quali e quanti record cancellati sarebbero stati rintracciati per poi essere ripristinati e disabilitati.
Clickiamo ancora una volta col dx su DLCHorseArmor.esp e selezioniamo Remove Identical to Master records. Nel caso apparisse un ulteriore Warning diamo ancora una volta Yes. Nella parte destra della finestra vedremo comparire il messaggio "Processed records: 167 - Removed Records: 3". Significa che Tes4Edit su 167 record processati nell'ESP DLCHorseArmor.esp ha rintracciato 3 record per i quali l'autore dell'ESP aveva modificato qualche parametro per poi riportarli allo stato originale, operazione che come abbiamo accennato nella prima parte non fa altro che aumentare inutilmente le dimensioni dell'ESP e genera inutili conflict check da parte del gioco.
La pulizia è terminata, chiudiamo Tes4Edit con la X in alto a destra e vedremo apparire una finestra di conferma salvataggio. Lasciamo il flag abilitato sull'ESP DLCHorseArmor.esp e diamo OK per confermare le modifiche. Se valutate di aver sbagliato qualcosa togliete il segno di spunta all'ESP e date OK, Tes4Edit uscirà senza salvare. Nel tornare nella finestra di Wrye Bash verremo accolti da una popup che ci informa a proposito della data modificata per DLCHorseArmor.esp, diamo semplicemente OK e notiamo come il plugin DLCHorseArmor.esp non sia più sottolineato. E' perchè l'abbiamo pulito! Come ulteriore verifica potete lanciare BOSS e notare come nel suo report non venga più indicato che DLCHorseArmor.esp è sporco, mentre tale indicazione è ovviamente ancora presente per diversi altri plugin ["Needs Tes4Edit cleaning"].
Se andate a dare un'occhiata in \oblivion\data vedrete che Tes4Edit ha creato un backup dell'ESP originale, col nome DLCHorseArmor.esp.backup.data. Come accennato nella terza parte Oblivion ha seri problemi quando i file contenuti in \oblivion\data superano i 400, pertanto se avete creato un backup dell'intera directory \oblivion\data sarebbe bene cancellare il file DLCHorseArmor.esp.backup.data per non affollare ulteriormente la directory.
Ora che sappiamo come pulire gli ESP proseguiamo con tutti gli altri indicati come sporchi da Wrye Bash fino a pulirli tutti. Nota bene: va sempre e solo pulito UN plugin per ogni sessione di Tes4Edit. Aprite Tes4Edit, selezionate un solo plugin da pulire, procedete alla pulizia, salvate ed uscite. E' inoltre buona abitudine pulirli nell'ordine di caricamento, dall'alto in basso come visualizzati in Wrye Bash.
Per vostra comodità vi elenco tutti i plugin che dovreste pulire nella vostra attuale installazione se avete la GOTY:
DLCHorseArmor.esp
DLCOrrery.esp
DLCVileLair.esp
DLCMehrunesRazor.esp
DLCSpellTomes.esp
DLCThievesDen.esp
DLCBattlehornCastle.esp
DLCBattlehornCastle - Unofficial Patch.esp
DLCFrostCrag.esp
Knights.esp
Ora facciamo una cosa molto utile: creiamo un archivio compresso [con winrar, winzip, 7z o altro] di nome CleanedESPs.7z [personalmente uso 7zip] con dentro tutti i plugin puliti e mettiamolo nella directory di BAIN. Da Wrye Bash aggiungiamo un marker ==USERPATCH== e subito sotto posizioniamoci il nostro archivio. Il vostro package order a questo punto dovrebbe assumere questo aspetto:
Package Order
==PATCH== 0
Unofficial Oblivion Patch v3_2_0 Manual Version 1
v1_4_0_Manual_install_7Z_version-10739 2
Unofficial_Official_Mods_Patch_v15_Manual_Version-9969 3
Unofficial_Patch_Supplementals-27710-3-3-7 4
==TWEAKS== 5
ExPCB_Eng_38441-1.7z 6
==TOOLS== 7
RefScope_2_1_2-21862-2-1-2.zip 8
==USERPATCH== 9
CleanedESPs.7z 10
==Last== 11
Installiamo l'archivio via BAIN come siamo soliti fare, abilitando ogni flag sugli ESP nella sezione Esp/m Filter e dando il comando Install dal drop-down menu. Dal punto di vista della directory \oblivion\data al momento non cambierà nulla perchè ci stiamo copiando dentro i medesimi file. Provvederemo ad aggiornare tale archivio con gli ESP puliti mano a mano che installeremo e puliremo nuovi mod, in modo da non doverli ripulire nuovamente se ci capiterà di disinstallare e reinstallare il mod con l'ESP sporco. Va da sè che il package order di CleanedESPs dovrà essere sempre l'ultimo, poichè i suoi ESP puliti dovranno sovrascrivere gli eventuali ESP sporchi installati dai mod originali.
Piccola digressione: in futuro nella sezione USERPATCH potremo eventualmente aggiungere un ulteriore archivio personalizzato con dentro le nostre texture preferite che dovranno sovrascrivere quelle installate da certi mod. Se ormai siete entrati nell'ottica di BAIN avrete realizzato che il suo sistema di package ordering vi permette combinazioni infinite per l'installazione dei mod. Prendiamo ad esempio un mod come Oscuro's Oblivion Overhaul, che fra le altre cose sostituisce le texture degli Ogre con le sue personalizzate. Se abbiamo già installato un texture pack che sostituisce tutte le texture delle creature e che per qualche motivo richiede di essere installato PRIMA di OOO, perderemo la possibilità di vedere in Oblivion gli Ogre texturizzati dal pack, poichè verranno sovrascritti da OOO. Come fare? Semplicemente estraiamo dal pack la texture dell'Ogre, la inseriamo in un archivio MyTextures e via BAIN lo installiamo per ULTIMO, inserendolo nella nostra sezione personalizzata USERPATCH. In questo modo la texture di OOO sovrascriverà quella del pack, ma il nostro archivio personalizzato sovrascriverà nuovamente quella di OOO ripristinando l'originale del pack! Niente male, eh? : )
Chiudiamo la parentesi e passiamo oltre. Ora dobbiamo illustrare la più geniale funzione di Wrye Bash: la Bashed Patch!
IV.2 - La creazione della Bashed Patch
Se arrivati a questo punto avete ben chiaro il funzionamento del caricamento degli ESP in Oblivion avrete sicuramente ormai ben radicato in mente un concetto chiave: l'ultimo ESP caricato vince. Ribadiamo il concetto con un esempio già visto:
ESP A cambia la potenza di una spada
ESP B cambia la portata della medesima spada
A seconda di quale ESP viene caricato per ultimo avremo in Oblivion solo UNA delle due modifiche
Non sarebbe bello poterle avere [i]entrambe invece di dover rinunciare ad una delle due? In condizioni ideali si dovrebbe ottenere in qualche modo un unico ESP che fa entrambe le cose, ma contattare gli autori di due mod diversi e pregarli di unire le forze non sembra una grande idea. Chi sa usare il CS potrebbe importare in un unico ESP le caratteristiche di entrambi i mod, ma non dovrebbe essere un'attività demandata all'utente medio. Molto meglio se ci pensa qualcun altro al posto nostro: Wrye Bash.
La soluzione che ci offre Wrye Bash è aggiungere ai due ESP di cui sopra un terzo ESP che importi in Oblivion le caratteristiche di entrambi gli ESP, dopo averli scansionati e aver identificato cosa va importato dall'uno e dall'altro. Questo particolare ESP altro non è che la Bashed Patch.
L'abbiamo già vista nella tab Mods di Wrye Bash, al fondo del load order, e i più attenti si saranno accorti che la sua dimensione è al momento pari a 0Kb . E' normale poichè al momento non contiene nulla, all'infuori dell'header identificativo per permetterle di essere riconosciuta da Oblivion come un ESP a tutti gli effetti e caricata di conseguenza. Su installazioni pesantemente moddate raggiungerà le dimensioni di diversi Mb. A breve vedremo come si importano i record dei vari ESP nella Bashed Patch.
Selezioniamo la Bashed Patch con un singolo click sx e diamo un'occhiata nel box Masters a destra: notiamo che al momento è completamente vuoto. Col tempo si popolerà con una lista degli ESP da cui avremo importato i record necessari.
Come facciamo a sapere quali siano i record da importare e da quali ESP? Semplice: non abbiamo bisogno di saperlo. A questo ci pensa BOSS, che integrandosi con Wrye Bash provvede a contrassegnare tutti gli ESP di cui si conosce la necessità di importazione nella Bashed Patch con una serie di tag, che possiamo vedere nel box Bash Tags in basso a destra. La Bashed Patch ovviamente ne è priva perchè non può essere importata su se stessa, ma se clickiamo su Unofficial Oblivion Patch.esp ne vedremo una lunga lista. Si tratta di record che gli autori della UOP hanno indicato al mantainer di BOSS come indispensabili da mantenere attivi. Non ci dilungheremo sul significato dei vari tag, vi basti sapere che identificano tutta una serie di record che verranno importati nella Bashed Patch per assicurarsi che la Unofficial Oblivion Patch funzioni a dovere [i]anche in presenza di successivi ESP che ne modificano i contenuti. Per fare un semplice esempio, la UOP prevede la correzione di nomi malformati di alcune celle del gioco. Per evitare che un qualsiasi mod riporti erroneamente i nomi delle celle all'errato stato originale, la UOP viene contrassegnata col tag C.Name. Durante la creazione della Bashed Patch, Wrye Bash importerà i record necessari dalla UOP alla Bashed Patch, che venendo caricata per ultima sovrascriverà qualunque modifica eseguita da ESP caricati dopo la UOP.
E questo è solo UNO dei casi in cui può emergere la necessità di importare dei record nella Bashed Patch. Con qualcosa come 23mila file sul solo TesNexus che si traducono grezzamente in circa 15/20mila mod potete immaginare quante diverse combinazioni di importazione record si potrebbero incontrare.
Ne consegue che qualunque tipo di installazione di Oblivion, dalla leggermente moddata alla moddata a livelli stellari DEVE avere una Bashed Patch opportunamente creata. La sua importanza per il corretto funzionamento delle meccaniche del gioco è BASILARE. Un altro vantaggio dato dalla Bashed Patch è poter superare un limite di Oblivion riguardo la quantità massima di ESP caricabili [255], importando completamente diversi piccoli ESP per poi poterli disabilitare completamente dal Load Order, di conseguenza liberando uno slot.
Nota importante: prima di creare una Bashed Patch gli ESP dai quali devono essere importati i record vanno PULITI dai dirty edits. E' il motivo per cui in questa stessa guida abbiamo anticipato la pulizia degli ESP all'esposizione della Bashed Patch.
Ora vediamo come creare la nostra prima Bashed Patch. Chi possiede la GOTY o comunque altri ESP appartenenti a DLC vari può eventualmente dare prima un'occhiata alla lista dei tag degli altri ESP, per avere un'idea di cosa verrà importato nella Bashed Patch.
Clickiamo col dx su Bashed Patch, 0.esp e scegliamo dal drop-down menu la voce Rebuild Patch [NON la voce Rebuild Patch (CBash *BETA*), si tratta di una funzione avanzata ancora in sviluppo]. Chi possiede la GOTY potrebbe vedere visualizzata una popup con la richiesta di disattivazione di DLCSpellTomes - Unofficial Patches.esp. Rispondete Yes.
Vedrete apparire una nuova finestra divisa in due parti. A sinistra i rami principali dei tag e una serie di tweak, a destra la lista degli ESP importabili [poichè taggati propriamente] e i parametri dei tweak. Al default la configurazione della Bashed Patch è completamente vuota all'infuori di Alias Mod Names, che per ora non ci serve e possiamo disabilitare.
La Bashed Patch dovrebbe sempre avere, al minimo, i seguenti flag di Import abilitati. Selezioniamo nella parte sinistra i vari flag indicati e nella parte destra scegliamo Select All [alcuni box potrebbero essere vuoti, provvediamo comunque ad abilitarne il ramo principale nel parte sinistra].
Merge Patches [Select All]
Import Actors [Select All]
Import Actors: AIPackages [Select All]
Import Actors: Animations [Select All]
Import Actors: Death Items [Select All]
Import Actors: Spells [Select All]
Import Cells [Select All]
Import Factions [Select All]
Import Graphics [Select All]
Import Inventory [Select All]
Import NPC Faces [Select All]
Import Names [Select All]
Import Relations [Select All]
Import Roads [Select All]
Import Scripts [Select All]
Import Sounds [Select All]
Import Spell Stats [Select All]
Import Stats [Select All]
Inoltre dovrebbero essere sempre attivi i seguenti Tweak:
Tweak Actors > Vanilla Beast Skeleton Tweaker
Tweak Assorted > Bow Reach Fix
Tweak Names > Lore Friendly Names: Dwarven > Dwemer
Tweak Settings > UOP Vampire Aging and Face Fix
Inoltre dovrebbero essere sempre attivi i seguenti:
Contents Checker
Leveled List > Automatic
Race records [Select All]
SEWorld Tests
Tutti le altre voci rimanenti nella parte sinistra andrebbero lasciate disabilitate.
Volendo possiamo dare un'occhiata ai tweak e selezionare quelli di nostro gusto, ve ne sono diversi interessanti come il poter modificare la distanza della telecamera in terza persona dal PG o aumentare il tempo di respawn delle celle. Quando abbiamo terminato di selezionare tutto il necessario clickiamo su Build Patch. La costruzione della Bashed Patch su certe macchine potrebbe impiegare anche diversi minuti. Al termine verrà visualizzata una popup informativa con quanto importato nella Bashed Patch, clickiamo su OK e se nella lista Mods la Bashed Patch non era stata precedentemente attivata ci verrà richiesto se abilitarla o no. Rispondiamo sì e diamo un'occhiata al nostro ESP Bashed Patch, 0.esp nella lista Mods.
Le sue dimensioni sono aumentate a circa 4Mb, ma ciò che è interessante rilevare è cosa è ora indicato nei box a destra. Nel box Description possiamo vedere che la Bashed Patch, pur avendo a che fare con pochi ESP, ha importato la bellezza di oltre 5mila record [chi non ha la GOTY potrebbe leggere valori inferiori]. Si tratta di 5mila correzioni di record di cui potrete benificiare nel gioco, di molte senza che nemmeno ve ne accorgiate. Nel box Masters potrete vedere tutta la lista degli ESP da cui sono stati importati dei record. Clickando nel box apparirà un Warning riguardo l'edit della lista. E' una funzione per sostituire eventualmente ESP corrotti dalla Master list e di cui potreste non aver mai bisogno, potete dare indifferentemente Ok o Cancel, l'importante è che al momento non tocchiate nulla. Eventualmente potrete documentarvi più avanti sul suo scopo grazie all'help di Wrye Bash.
Chi possiede la GOTY noterà che DLCSpellTomes - Unofficial Patch.esp è elencato nella tab Mods con un + verde invece del canonico flag. Significa che l'ESP è stato completamente importato nella Bashed Patch per poi essere disabilitato. E' tuttora visualizzato nel Load Order semplicemente per completezza, ma in realtà Oblivion non lo prenderà nemmeno in considerazione. Se durante la configurazione di Wrye Bash vi siete inoltre ricordati di abilitare l'Auto-Ghost potrete notare che nella directory \oblivion\data il file DLCSpellTomes - Unofficial Patch.esp è stato rinominato da Wrye Bash in DLCSpellTomes - Unofficial Patch.esp.ghost in modo da non concorrere nel conteggio limite dei 400 file della directory \data.
In seguito all'installazione di ulteriori mod potreste aver bisogno di ricostruire la Bashed Patch. E' buona abitudine farlo sempre quando notate che l'ESP installato possiede dei Bash Tag. Notate che alcuni mod particolari come All Natural lo richiederanno espressamente.
A questo punto la nostra installazione di Oblivion è stabile come una roccia e pronta per accogliere qualunque tipo di mod, compatibilmente con le caratteristiche hardware della nostra macchina. Avviamo Oblivion e carichiamo il nostro ultimo salvataggio PrisonSewer03. Chi ha la GOTY e di conseguenza ha importato e disabilitato DLCSpellTomes - Unofficial Patch.esp nella Bashed Patch verrà accolto dalla popup del contenuto mancante. E' corretto, poichè tale ESP non esiste più: l'abbiamo completamente importato nella Bashed Patch, ma ovviamente Oblivion non può saperlo. Diamo Yes per confermare il caricamento e creiamo un nuovo salvataggio PrisonSewer04, che come abbiamo accennato più indietro diventerà il nostro nuovo clean save.
Chi pur non avendo alcun interesse nel moddare Oblivion ha seguito la guida per rendere la sua installazione vanilla solida e reattiva può fermarsi qui e iniziare finalmente una nuova partita con tutti i crismi.
Gli altri proseguano nella lettura, abbiamo ancora molta strada da percorrere : )
IV.3 - Funzioni utili di Wrye Bash
Ora dovreste già avere abbastanza dimestichezza con Wrye Bash per poter girovagare fra le sue funzioni senza paura, non proseguiremo nello spiegarle tutte ma qualche dritta in più non fa male.
Per salvare l'attuale lista degli ESP, in modo da sperimentare con più combinazioni di mod diverse, clickiamo col dx nella tab Mods e scegliamo Load > Save List. Diamo ora un nome alla nostra attuale lista e chiamiamola PatchedVanilla. Comparirà in elenco nel medesimo menu, pronta per essere ricaricata all'occorrenza. Notate che è già presente la voce Bethesda ESMs, che di fatto disabiliterà tutti gli ESP lasciando attivo il solo oblivion.esm [utile per disabilitare tutti gli ESP e testare poi un solo ESP per volta].
La funzione Mod Checker attivabile dalla barra in basso fornirà un report su eventuali problemi nella lista degli ESP [master mancanti, dirty edits, eccetera]. In condizioni normali dev'essere vuota. La funzione Scan for Dirty Edits nella finestra del Mod Checker è al momento in beta e manda spesso in crash WB, è vivamente sconsigliato usarla. Molto meglio affidarsi al check di BOSS.
Per poter copiare agevolmente l'ordine di caricamento in modo da incollarlo sui forum di aiuto clickiamo col dx nella tab Mods e scegliamo List Mods. La lista è preformattata coi tag SPOILER e XML dei forum ufficiali di Bethesda. Qui su HwUP non vengono riconosciuti, pertanto è bene sostituire i due tag con l'unico tag QUOTE prima di incollare la lista in un post. Quanto segue è la lista attuale della nostra installazione, per chi possiede la GOTY:
Active Mod Files:
00 Oblivion.esm [CRC: 2FF840C5]
01 Unofficial Oblivion Patch.esp [Version 3.3.7] [CRC: 6AB8F177]
02 DLCShiveringIsles.esp [CRC: 2BB84977]
03 Unofficial Shivering Isles Patch.esp [Version 1.4.4] [CRC: F6C1D21D]
04 ExPCB.esp [CRC: B66B4951]
05 DLCHorseArmor.esp [CRC: BD0084C5]
06 DLCHorseArmor - Unofficial Patch.esp [Version 1.0.6] [CRC: 00F74B09]
07 DLCOrrery.esp [CRC: 351A3894]
08 DLCOrrery - Unofficial Patch.esp [Version 1.0.4] [CRC: 9AA76E38]
09 DLCVileLair.esp [CRC: 3B6E3A93]
0A DLCVileLair - Unofficial Patch.esp [Version 1.0.7] [CRC: 5B9FF91B]
0B DLCMehrunesRazor.esp [CRC: FD5BE3C6]
0C DLCMehrunesRazor - Unofficial Patch.esp [Version 1.0.5] [CRC: FF57D0F8]
0D DLCSpellTomes.esp [CRC: 02FA9682]
++ DLCSpellTomes - Unofficial Patch.esp [Version 1.0.1] [CRC: 8CC91BA1]
0E DLCThievesDen.esp [CRC: 7F76D2D3]
0F DLCThievesDen - Unofficial Patch.esp [Version 1.0.10] [CRC: 401934BE]
10 DLCBattlehornCastle.esp [CRC: BEE27F25]
11 DLCBattlehornCastle - Unofficial Patch.esp [Version 1.0.6] [CRC: 0F1BBF7E]
12 DLCFrostcrag.esp [CRC: FBEE32B7]
13 DLCFrostcrag - Unofficial Patch.esp [Version 1.0.5] [CRC: 5744D6B8]
14 Knights.esp [CRC: 4CB1DF3D]
15 Knights - Unofficial Patch.esp [Version 1.1.2] [CRC: 2F15B12C]
16 RefScope.esp [Version 2.1.2] [CRC: 09E4EE27]
17 Bashed Patch, 0.esp [CRC: 120EC898]
Allo stesso modo si può copiare la lista dei package dalla tab Installers, col comando click dx > List Packages:
Bain Packages:
000 - ==PATCH==
++ 001 - Unofficial_Oblivion_Patch_v3_2_0_Manual_Version-5296.7z (BCBA7B56) (Installed)
++ 002 - v1_4_0_Manual_install_7Z_version-10739.7z (79CE866D) (Installed)
++ 003 - Unofficial_Official_Mods_Patch_v15_Manual_Version-9969.7z (59895567) (Installed)
++ 004 - Unofficial_Patch_Supplementals-27710-3-3-7.7z (7807463F) (Installed)
005 - ==TWEAKS==
++ 006 - ExPCB_Eng-38441-1.7z (AE27691D) (Installed)
007 - ==TOOLS==
++ 008 - RefScope_2_1_2-21862-2-1-2.zip (A57B7DD5) (Installed)
009 - ==USERPATCH==
++ 010 - CleanedESPs.7z (C3F4959E) (Installed)
011 - ==Last==
Per visualizzare tutti gli ESP dei quali sono stati importati uno o più record nella Bashed Patch, nella tab Mods clickiamo col dx sulla Bashed Patch e scegliamo List Masters:
Masters for: Bashed Patch, 0.esp
00 Oblivion.esm [CRC: 2FF840C5]
01 Unofficial Oblivion Patch.esp [Version 3.3.7] [CRC: 6AB8F177]
02 Unofficial Shivering Isles Patch.esp [Version 1.4.4] [CRC: F6C1D21D]
03 DLCHorseArmor.esp [CRC: BD0084C5]
** DLCHorseArmor - Unofficial Patch.esp [Version 1.0.6] [CRC: 00F74B09]
04 DLCOrrery.esp [CRC: 351A3894]
05 DLCVileLair.esp [CRC: 3B6E3A93]
** DLCVileLair - Unofficial Patch.esp [Version 1.0.7] [CRC: 5B9FF91B]
06 DLCMehrunesRazor.esp [CRC: FD5BE3C6]
** DLCMehrunesRazor - Unofficial Patch.esp [Version 1.0.5] [CRC: FF57D0F8]
07 DLCSpellTomes.esp [CRC: 02FA9682]
++ DLCSpellTomes - Unofficial Patch.esp [Version 1.0.1] [CRC: 8CC91BA1]
08 DLCThievesDen.esp [CRC: 7F76D2D3]
09 DLCThievesDen - Unofficial Patch.esp [Version 1.0.10] [CRC: 401934BE]
0A DLCBattlehornCastle.esp [CRC: BEE27F25]
0B DLCBattlehornCastle - Unofficial Patch.esp [Version 1.0.6] [CRC: 0F1BBF7E]
0C DLCFrostcrag.esp [CRC: FBEE32B7]
** DLCFrostcrag - Unofficial Patch.esp [Version 1.0.5] [CRC: 5744D6B8]
0D Knights.esp [CRC: 4CB1DF3D]
0E Knights - Unofficial Patch.esp [Version 1.1.2] [CRC: 2F15B12C]
Maggiori informazioni sull'uso di Wrye Bash sono consultabili nell'help clickando su ? nella barra in basso. E' bene precisare che al momento l'help si riferisce a vecchie versioni di WB e non sempre quanto riportato corrisponde a quanto è presente nel software.
IV.4 - L'installazione di OBMM
Wrye Bash è ora diventato il nostro mod manager principale e se siete arrivati fino a qui ne avrete ormai apprezzato le grandi potenzialità. Attualmente però ha ancora tre limiti:
Non può installare mod in formato OMOD
Non ha un'utility integrata per scompattare e ricomprimere i file BSA
Non può patchare gli shader vanilla
Utilizzeremo largamente le prime due funzionalità di OBMM per gestire i nostri file OMOD e BSA, mentre la terza sarà limitata all'installazione di un'unico particolare mod, tale Detailed Terrain, che necessita di modificare gli shader contenuti nella directory \oblivion\data\shaders.
Scarichiamo OBMM da qui (http://www.nexusmods.com/oblivion/mods/2097), sezione Files > Main files > obmm 1_1_12 full manual e salviamolo nella nostra directory OblivionSetup. Estraiamone tutto il contenuto in \oblivion e lanciamo Wrye Bash.
A causa della presenza di OBMM nel sistema verremo accolti da una richiesta di disabilitazione della funzione Lock Times, alla quale abbiamo accennato più indietro. Rispondiamo di NO. Lock Times fa sì che le date degli ESP, memorizzate internamente in Wrye Bash, vengano bloccate allo stato attuale per impedire ogni cambiamento accidentale nell'ordine di caricamento che potremmo eseguire usando OBMM. Notate che nella barra in basso è spuntata una nuova icona simile al logo di Oblivion con su scritto OBMM.
Come avrete ormai potuto realizzare, Wrye Bash integra agevolmente molti programmi orientati al modding di Oblivion. Mano a mano che aggiungeremo utility, esse verranno identificate da Wrye Bash per un più immediato utilizzo.
Molti di voi sapranno già usare OBMM per installare e rimuovere gli OMOD, ma noi NON lo useremo per questo motivo. Gli unici usi che ne faremo consisteranno nel decomprimere gli eventuali OMOD già scaricati e ricomprimerli in formato BAIN-ready, e nel decomprimere e ricomprimere i BSA dopo averne ottimizzati i file con PyFFI.
La conversione di mod da OBMM ad archivio compresso
NOTA BENE prima di iniziare: alcuni mod in formato OMOD una volta convertiti in archivio BAIN-ready NON possono essere installati correttamente in Wrye Bash poichè contenenti uno script di installazione riconosciuto solo da OBMM. E' ad esempio il caso di DarNified UI, il cui OMOD una volta convertito in archivio BAIN-ready viene compreso da Wrye Bash nella sua sola forma di archivio contenente dei file risorsa, ignorandone gli script. Wrye Bash usa un sistema suo per gli script di installazione per mod particolarmente complessi, e non ha nessuna possibilità di interpretare gli script di OBMM. Pertanto prima di procedere alla conversione è bene capire tramite il Readme cosa il mod si proponga di installare e come. Nel caso si tratti di un mod che preveda l'installazione tramite script di OBMM è bene scaricarne una versione BAIN-ready, che il modder o chi per lui potrebbe già aver reso disponibile per il download. Ad esempio DarNified UI in formato BAIN-ready si trova qui (http://www.nexusmods.com/oblivion/mods/22170), sezione Files > Main files > DarNified UI 132-BAIN.
Nella Parte V - i mod consigliati - verrà indicato il link da dove scaricare i più comuni mod in formato BAIN-ready.
Lanciamo OBMM tramite la sua icona in Wrye Bash. Clickiamo su Load in basso e andiamo a puntare ad uno dei file OMOD che potremmo aver già scaricato. Il mod comparirà in elenco nella parte destra della finestra. NON clickateci sopra due volte o lo installerete, che NON è quello che vogliamo fare. Clickateci su col dx e scegliete Convert to archive. Dalla nuova finestra scegliete come destinazione la directory di BAIN, alla richiesta "Create omod conversion information" rispondete di No e attendete. Per mod molto pesanti come QTP3R l'operazione potrebbe richiedere parecchio tempo, ma è sempre meno del tempo che impieghereste a riscaricarne la versione BAIN-ready. Al termine apparirà un popup con indicato Conversion successful. Procedete allo stesso modo fino a che non avete convertito tutti i vostri OMOD, che potrete poi cancellare.
Notate che l'originale OMOD potrebbe essere stato pacchettizzato in un formato anomalo e incomprensibile da BAIN, ad esempio con la directory DATA contenuta in una serie di sottocartelle. Nel caso l'archivio dovrà prima essere estratto, ristrutturato in un formato comprensibile e ricompresso prima di poter essere installato il BAIN.
NOTA: gli OMOD possono essere estratti con Wrye Bash [ma NON installati] se si trascina il file OMOD in Wrye Bash nella tab Installers. Nella directory di BAIN verrà creata una directory con tutto il contenuto dell'OMOD [compresa la sottodirectory "omod conversion data" che in OBMM abbiamo escluso espressamente], che in Wrye Bash verrà indicato con un rombo per segnalare che si tratta di una directory e non un archivio compresso. Una volta ottenuta la directory compressa la si può comprimere in un archivio compresso per poterne installare il contenuto in BAIN, eventualmente dopo aver apportato i necessari cambiamenti alla struttura della directory.
Estrazione e compressione dei BSA tramite OBMM
Ci sono principalmente tre motivi per cui vorremmo estrarre il contenuto di un BSA: il primo è poterne ottimizzare le meshes con PyFFI, cosa che vedremo più avanti. Il secondo è decomprimere il file Oblivion - Textures - Compressed.bsa e ricomprimerlo in formato uncompressed, in modo da aumentare le prestazioni quando Oblivion dovrà caricarne i file. Il terzo è la curiosità di sapere cosa c'è dentro : )
Iniziamo col decomprimere proprio Oblivion - Textures - Compressed.bsa. Nella nostra directory OblivionSetup creiamo una nuova directory BSA.
Da OBMM clickiamo sul pulsante Utilities e scegliamo BSA Browser.
Comparirà una nuova finestra nella quale clickeremo sul pulsante Open. Andiamo a puntare alla directory \oblivion\data e apriamo Oblivion - Textures - Compressed.bsa. Dopo qualche istante ne verrà elencato l'intero contenuto.
La struttura del BSA vi dovrebbe essere familiare, è esattamente la stessa della directory \oblivion\data. Clickiamo su Extract All e andiamo a puntare alla nostra directory OblivionSetup\BSA. Attendiamo pazientemente, il file è grande e l'estrazione richiederà diversi minuti. Al termine clickiamo su pulsante Close e chiudiamo la finestra del BSA Browser. Nella nostra directory OblivionSetup\BSA sarà stata creata una directory textures contenente l'intera struttura del BSA appena decompresso. Ora ricomprimiamo il nostro bel malloppo di textures in formato BSA uncompressed.
Chiudiamo OBMM per liberare la ram impegnata dall'estrazione dell'archivio, che OBMM non è in grado di liberare autonomamente, e riapriamolo.
Clickiamo sul pulsante Utilities e scegliamo BSA Creator. Nella nuova finestra assicuriamoci che la voce nel menu a tendina in basso a sx indichi No compression, dopodichè premiamo il pulsante Add folder(s). Andiamo a puntare alla directory OblivionSetup\BSA, assicurandoci che nella finestra di dialogo sia evidenziata esattamente la directory BSA e non la sua sottodirectory textures, e diamo Ok. Attendiamo qualche istante e il contenuto della directory verrà visualizzato. Se abbiamo eseguito tutto correttamente la colonna Relative Path dovrà visualizzare i nomi dei file comprensivi della directory \textures. Clickiamo il pulsante Create, andiamo a puntare a \oblivion\data e nel Nome file scriviamo "Oblivion - Textures.bsa" [ovviamente senza virgolette]. Clickiamo Salva e attendiamo molto pazientemente. OBMM sembrerà andare in freeze, lasciamolo in pace qualche minuto e il file verrà creato. Non viene data nessuna indicazione riguardo l'avvenuta creazione del BSA, ce ne accorgeremo quando saremo nuovamente in grado di scorrere il contenuto della finestra del BSA Creator.
Chiudiamo OBMM e, just in case, invece di cancellare Oblivion - Textures - Compressed.bsa spostiamolo nella directory OblivionSetup. Nella directory \oblivion\data diamo un'occhiata al nuovo file Oblivion - Textures.bsa. A differenza del file compresso dovrebbe essere grande 2Gb, ma quello che dovremmo veramente notare è la sua data: 01/01/2006. Ma come? L'abbiamo creato adesso! E' la magia di Wrye Bash, che lasciato aperto in sottofondo ha individuato un nuovo file BSA in \oblivion\data e ha provveduto a modificarlo propriamente: per evitare che nella directory \oblivion\data siano presenti dei file più vecchi dei BSA, cosa che causerebbe problemi di caricamento dei loose file, ogni BSA viene automaticamente ridatato da Wrye Bash al 01/01/2006, data sicuramente antecedente ad ogni loose file che potremmo avere sotto \oblivion\data.
Come ultimo dettaglio dobbiamo indicare ad Oblivion che il file delle textures ha cambiato nome, in caso contrario nessuna texture vanilla verrà individuata. Apriamo oblivion.ini e cerchiamo la direttiva SArchiveList, dove cambieremo il nome del nostro BSA da Oblivion - Textures - Compressed.bsa a Oblivion - Textures.bsa.
Per verificare di aver eseguito il tutto correttamente lanciamo Oblivion e carichiamo il nostro salvataggio PrisonSewer04. In caso di problemi ce ne dovremmo accorgere immediatamente: se il nuovo BSA non verrà individuato correttamente, perchè ne abbiamo sbagliato il nome in oblivion.ini, nel menu principale vedremo i soli testi su sfondo bianco. Se abbiamo commesso qualche errore nella costruzione del file decompresso, una volta caricato il salvataggio vedremmo una marea di texture porpora.
Se sembra tutto in ordine possiamo uscire.
NOTA: chi non sopporta OBMM può utilizzare BSA Commander (http://www.nexusmods.com/oblivion/mods/3311) per gestire il contenuto dei BSA. Questo software, unito alla possibilità di decomprimere gli OMOD via Wrye Bash, vi permette di fare quasi completamente a meno di OBMM. L'unico uso per cui lo utilizzereste sarebbe l'installazione di mod estremamente particolari, come Detailed Terrain che necessita di patchare gli shader vanilla, feature al momento assente in Wrye Bash.
E con questo abbiamo concluso! La nostra installazione di Oblivion è più che mai pronta ad accogliere una moltitudine di mod, che ora sappiamo perfettamente come installare e gestire. I più pignoli potranno eventualmente seguire l'ulteriore step dell'ottimizzazione delle meshes, ma non è un passo essenziale per poter moddare pesantemente Oblivion.
Ora potete ufficialmente dare il via alla vostra lunga carriera di mod user! :cool:
IV.4 - L'ottimizzazione delle meshes con PyFFI
[in stesura]
***NOTA***
Questa parte della guida è la più gravosa per la macchina, l'ottimizzazione delle meshes è un processo lungo e laborioso per la CPU e può impiegare diverse ore. Dati il grande impegno utente/macchina e i risultati non proprio eclatanti rispetto alle meshes vanilla mi riservo di preparare questa parte della guida in un secondo tempo, dando invece priorità alla Parte V - i mod consigliati.
L'ottimizzazione delle meshes è un'operazione completamente facoltativa e può essere eseguita in qualunque momento, anche a gioco pesantemente moddato. Pertanto sentitevi liberi di installare tutti i mod che vi pare, all'ottimizzazione delle meshes ci penserete eventualmente poi.
**********
Update 20/10/11: al momento è tuttora in lavorazione una nuova release di PyFFI, se ne attende l'uscita per esporne l'uso