E' per me evidente che ci sono cose che ancora mi sono oscure e quindi vorrei capirle. Parlo di quando un client si connette ad un server tramite la lobby e qui gli ISI si sono prodotti in una comunicazione non verbale parecchio colorata ma per me per nulla chiara. Parlo del colore che assumono le info a sx, giallo, grigio, blu. Hanno un significato preciso o è un ritorno allo psichedelico? ad esempio ora sto cercando di connettermi ad un mio server ma mi da il grigio e nulla posso fare. Ho in pratica installato il F2 degli ISI che è un multicomponent. Ho creato un mod virtuale con dentro i componenti del F2 (auto, suoni, talent) e poi la solita pista. Lato client ho scaricato e installato l'identica roba e lasciato sulla mia installazione solo queste cose qui disintallando tutto il resto per non creare confusione ne a me e ne a rF2. Ebbene quando cerco di collegarmi mi dice che la serie non è installata, mod non trovata e nulla posso fare. Il grigio delle scritte mi dovrebbe suggerire qualcosa in più? Cmq sia, cosa sto sbagliando?
Il grigio dovrebbe significare che il server non è impostato per scaricare la VMod dalla lobby http://isiforums.net/f/showthread.php/20909-Colors-in-online-launcher?highlight=colors quindi non penso che il colore sia attinente al tuo problema. Se in single player la VMod ti risulta installata io proverei a ricreare la VMod del server o a copiare/incollare nel server quella che hai installato sulla tua macchina client.
grazie Max. E' successa una cosa non nuova ovvero io creo un mod da un mod manager di una installazione ma fisicamente me lo mette sulla package di una installazione diversa. Io ho diverse installazioni tutte identiche su path diversi ed ognuno con il file data.path settato correttamente ma malgrado ciò quando lavoro su un mas2 o mod manager i path risultano sballati, come se cmq lui usasse i path dell'ultimo utilizzo a prescindere su quale server io lavori. Non è nulla di grave ma ogni volta ci faccio caso e mi trovo ad impazzire per mod piazzati in posti diversi o anche la cartella installed risultano sfasate.
rF2 è disegnato per avere una singola installazione, cmq ci sono casi in cui è necessario averne più di una (io per esempio ne ho due da sempre, una con la build pubblica e l'altra con la build interna). Per non avere perdite di tempo, trovo che tenere una singola cartella Data (con Packages, UserData e tutte le altre cartelle "non Core") condivisa tra tutte le istanze installate sia la soluzione migliore. Nel caso in cui una o più istanze siano server, l'unica cosa da tenere separata direi che è UserData, in modo che ogni istanza abbia il suo player. Il sistema di base (una sola istanza per PC) funziona bene, ma quando ci sono istanze multiple se non ci si ricorda ogni volta di modificare il Data Path è facile andare in confusione. Per questo tenere un Data Path condiviso è a mio parere una buona cosa ... in fondo solo solo dati, non si condividono cartelle Core che potrebbero creare incompatibilità o altri problemi.
mah io condivido solo la cartella packages, per cambiare un percorso è un attimo, quando si inizia a fare spesso viene automatico
io neanche quella, preferisco tenere tutto separato per non avere confusione di nessun tipo anche perchè poi nella packages ci tengo solo i componenti usati da quel server e poi quando finito l'evento cancello tutto e disintallo. Cmq altra cosa, senza che apro un nuovo topic, ci sono due distinti bug riguardo al download di un vmod da un dedi. il primo è quando il client non ha ancora quel vMod ed avviene che spesso è necessario fare diversi tentativi prima che dalla lobby parta il download e non dia errore mod non trovato. In poche parole mi connetto, trovo il dedi, clicco sul dedi, metto la pwd, ci pensa un po' e mi dice che non si può scaricare, poi senza modificare nulla riclicco sul dedi, stessa procedura e magari mi parte. A volte al primo tentativo ma a volte dopo due o tre tentativi. Il prob è che gli utenti non lo sanno ed iniziano ad andare in paranoia. L'altro problema è che se io ho gia il vMod ma lato server è stato rifatto ma con lo stesso nome, il client non lo scarica anzi, dice che lo scarica ma poi non lo installa. Ha problemi quindi ad accorgersi o a gestire aggiornamenti di vMod. L'unico sistema per uscirne fuori è quello di disinstallare e rimuovere lato client il vMod e quindi al dedi appari come uno che non ha il vMod e te lo scarica. Anche qui però gli utenti nn lo capiscono e via di paranoia. Ci sono speranze che tutto questo venga sistemato?
Per il mancato scaricamento al primo tentativo è capitato ieri da noi, partito al secondo Per la vmod basta cambiare la versione mettendo as esempio 1.1 invece di lasciare 1.0 prima di impacchettarla
Per quanto riguarda il problema della Password,abbiamo gia reportato il problema ad ISI,e penso ci stiano gia lavorando. Come dice il Carra,quando cambi/aggiorni la Vmod,e bene cambiare qualcosa nel nome e nella versione,cosi da evitare che nella cartella Packages del utente non si abbiano "conflitti" di stesso nome,mandando in confusione il Sim. Aggiungo anche,che in futuro quando il server Prototipo sara funzionante a tutti gli effetti,questi problemi spariranno. Babs
Prototipo nel senso che per ora è al suo primo livello di implementazione. Praticamente rappresenta un nuovo passo di semplificazione, sia per quanto riguarda la creazione delle VMod sia per quanto riguarda la gestione dei contenuti all'interno delle VMod. Ora non ritrovo il thread, ma mi pare che se ne fosse già parlato. Cmq, il nuovo server è attivabile dalla tab Advanced del launcher, funziona bene ma solo con le vetture impacchettate come singolo componente (cioè ISI avrà da aggiornare tutti i vecchi rilasci, quelli con i multicomponenti) e le sue impostazioni per il momento credo siano regolabili tramite il vecchio server ... cioè il nuovo per ora va a pescare le impostazioni dal vecchio. I vantaggi: creare VMod è assai più semplice (una sola finestra e tre click) e gli utenti potranno entrare nel server anche non avendo già installate tutte le piste.
Per quanto riguarda i bug che hai segnalato Babs ha detto tutto. Da parte mia vorrei aggiungere solo una considerazione di tipo generale, diciamo "un reminder": rF2 è un prodotto non finito, nel senso che il suo sviluppo si concluderà solo quando diventerà "non efficiente" continuarne la programmazione, al punto da rendere consigliabile uno step di piattaforma. La modularità del software (offerta diciamo dall'ingegneria di programmazione, cioè da come i vari moduli interloquiscono tra loro) consente ampi margini di sviluppo in tutti i campi (non escluderei per esempio che il 2015 possa essere l'anno del passaggio a DirectX più moderne, così come il modello di gomme è davvero al suo stato di infanzia ... immaginate il TBC alla sua prima integrazione (fine anni '90, primi 2000? ... non so perché a quel tempo non seguivo ISI: ecco il TGM è, per semplificare, allo stesso stato e mi aspetto una quindicina di anni di suo sviluppo (chiaro, anche su piattaforme future, non dico che rF2 durerà 15 anni ). Insomma, aggiungiamo a queste considerazioni il fatto che il team è piccolo in termini di risorse umane ... si può capire che questo sviluppo costante possa portare a incidenti di percorso (bug introdotti), ma il ritmo di avanzamento (nuove builds ogni 6/8 settimane) in genere fa si che i bug importanti vengano fixati in tempi relativamente brevi.
Ultime news sul problema Password Sembra che nell ultima Build interna il problema sia stato fixato. Per quanto riguarda il server prototipo,e ancora "acerbo" pero come diceva Max,non ci sara piu bisogno della vmod,in quanto la creera al momento. Per il momento si puo usare solo una pista con il sistema Get Missing Component,in quanto se si va alla seconda pista,ancora non e possibile uscire in lobby e rientrare per scaricarla. Per fare funzionare il Get Missing Component,con questa tipologia di Server,sara necessario avere installato nel server,il materiale "moddato" con il sistema. Per impostare le opzioni del Server,come diceva Max,bisogna prima Lanciare il vecchio server,impostare,e poi lanciare il Prototipo. Babs
