[Thread Ufficiale] ArmA III: THIS IS WAR

[D4N!3L3]

Originariamente inviato da marcolpasini

Ti do una delusione, passando da una 980 ad una 1080 su Yet Another Arma Benchmark non ho avuto 1 fps di aumento Detto questo anche io ho un esacore e non serve a niente, quello che arma vuole in questo momento sono i ghz, fsb ed il clock della ram. Un mio amico con una 1080 e un 7700k ( neanche overcloccato ) fa 10 fps in più in quella stessa missione benchmark

Comunque qualsiasi missione multiplayer può essere giocata localmente, basta che vai su multiplayer ed hosti una partita su rete locale LAN e joini solo tu

Infatti, come immaginavo, io ora sto a 4.4 Ghz, è assurdo però che non venga sfruttato il multi-threading adeguatamente, quando faccio musica uso progetti anche belli grossi e pesanti con tantissima roba da elaborare in real time e con l'hardware attuale va che è una bellezza.

Ecco perché è un engine vecchio, si basa sui Ghz più che sul multi-threading, nel 2017 con le tecnologie attuali non si può vedere.

[marcolpasini]

Forse ArmA IV passerà ad Enfusion e la situazione potrebbe migliorare, forse.. Ti consiglio di fare qualche test con YAAB provando enableht e cpucount, mettendo hugepages e provando un po a pasticciare, qualcosina magari sfrutti

[Sberla101]

Io sinceramente con ArmA 3 non ho mai avuto problemi di FPS, anche quando avevo il 2600k; appena avrò la fortuna di prendere la 1080ti Strix (quando la troverò) vi dirò i bench

[marcolpasini]

Originariamente inviato da Sberla101

Io sinceramente con ArmA 3 non ho mai avuto problemi di FPS, anche quando avevo il 2600k; appena avrò la fortuna di prendere la 1080ti Strix (quando la troverò) vi dirò i bench

Dipende sempre dal tipo di missione, settaggi e server.. su arma non vedresti differenze tra una 980 ed una 1080ti, roba insignificante, basta far girare afterburner con le statistiche di utilizzo cpu e gpu... che cpu e ram hai?

[{BDR}*Nemesi*]

Originariamente inviato da marcolpasini

1. oddio, ognuno ha standard differenti ed intende le parole in modo diverso ( anche se il dizionario definisce scompenso come una mancanza di equilibrio ) . Il virtual è clientside e può avere o meno blacklist impostate dalla missione, per questo si genera questo "scompenso" o come vuoi chiamarlo. Senza contare che questo può generare anche il fatto non solo di vedere un semplice fucile o una texture ma anche veicoli nemici, unità nemiche ( vedresti pupazzetti nudi con in mano nulla ), genererebbe errori in ace ed altri script della missione ( da che calibro sei stato colpito ? ops, non si sa ), alcune mod modificano la mappa ( basta pensare a quelle con zombie o post apocalittiche ) e ti troveresti ad entrare magari in edifici che per il server e per gli altri sono demoliti o viceversa.
Per me questo sarebbe anche oltre uno scompenso, sarebbe ingiocabile; poi ognuno ha i suoi standard ovviamente.
Ovviamente questo succede se il mission editor è intelligente da non piazzare tutto in editor e demolire gli fps ma sottointendo che più nessuno piazza tutto in editor ( spero... )

2. non è dal dal server in ogni caso, se il server usa la versione mod del CH view distance o la view distance di ace o la view distance di cba o vattelapesca, è il client che la regola a piacimento, come è giusto che sia. Alcuni preferiscono spararsi la view distance a 2k e girare a 70-80 fps, altri preferiscono maggiore profondità di campo ( quando volo tengo la view distance al massimo ma la object distance a 6k per non abbassare troppo gli fps ).

3. come fa a giocare quella missione senza quella missione?

Qui si sta facendo una gran confusione. Ricapitoliamo da quando siamo partiti, un giocatore viene buttato fuori da un server (dove è in corso una missione precisiamo, se no le cose cambiano), questo può succedere per due motivi

- non ha i mod necessari per giocare la missione, errore generato "non puoi giocare/modificare la missione, essa è legata a contenuti scaricabili che sono stati cancellati" e giù la lista;

- ha attivato dei mod che non sono consentiti dal server, errore "il file xxx richiede una chiave non accettata da questo server" qualcosa del genere

Non viene cacciato se ha dei mod in più che non sono presenti nella missione se il server non ha controllo firme, quello che lui carica all'inizio quando lancia il gioco non viene usato dalla missione ed è ininfluente (a meno di mod particolari che entrano in conflitto l'uno con l'altro, per esempio se ha una modificazione "apocalittica" della mappa del chernarus, ma in questo caso viene direttamente buttato fuori perchè mancano contenuti). Normalmente coi mod di contenuti, es armi come era il caso di cui si parlava, se quelle armi non sono usate nella missione non si crea nessun conflitto e il mod in più è ignorato.

Poi ci sono altri problemi che sono legati alla località, ma questi sono problemi ben diversi. Se l'arsenale virtuale è locale al client come ho detto un motivo in più per non usarlo in missione (io non l'ho mai usato in missione e mai lo userò per mille motivi, si vanno a far benedire i ruoli etc etc), tornando a noi sicuramente ci sono dei sistemi per farlo gestire dal server come correttamente deve essere. Ci sono sistemi che ovviano il fatto che uno possa entrare in un server senza un mod particolare e sono di piazzare nell'editor un oggetto legato al mod (oppure crearlo se non esiste), alternativamente attivare "check for addons" nella config del server (però è pesantuccio se si controllano tutti gli addons, si può ricercare uno o pochi addons particolari). Ovviamente in una missione tutti i client devono vedere le stesse cose e il mission maker deve stare molto attento a problemi di località (es se c'è la randomizzazione di un obiettivo essa va gestita dal server e così via). Non so in che server giochi ma ovviamente quello che hai descritto non deve esistere e se esiste vuol dire che la missione è quanto meno "da rivedere".

Lo scompenso come lo chiami tu è una definizione fumosa, quello che succede in una missione o in un server ha cause precise che vanno individuate con precisione se si vogliono correggere, se non sappiamo qual è la causa non possiamo intervenire.

2. Infatti la view distance non è gestita dal server ma dalla missione in prima istanza, solo se la missione non ha impostato nessun valore viene preso quello del server. In multiplayer mai è gestita dal client, le impostazioni del client valgono per il single player e basta. Come è corretto che sia aggiungo, perchè è il mission maker che stabilisce qual è la view distance giusta per la missione, e perchè i client devono vedere tutti la stessa cosa. Quindi la view distance, e view object distance, possono essere inferiori a quelli della missione se così li imposta il client, mai superiori. La view distance/object distance può essere parametrizzata, ma di nuovo è una impostazione della missione. Ogni client in quel caso imposta il suo parametro, che non può superare i parametri della missione. CH addon è un sistema di parametrizzazione un po' più complesso e sofisticato, ma sempre parametrizzazione è, puoi vedere da qui (si riferisce alla versione scripted), sono valori che vanno impostati in missione (la versione addon fa la stessa cosa ma come addon invece che come script)

1. Place "CHVD" folder in your mission folder.

2. Add this code to description.ext file in your mission folder:

#include "CHVD\dialog.hpp"
class CfgFunctions
{
#include "CHVD\CfgFunctions.hpp"
};

3. Quando si vuole trovare la causa di un qualcosa bisogna separare le variabili l'una dall'altra. Se si fanno prove con più variabili tutte assieme non si troverà mai la causa. Ne caso in questione gli fps bassi sono dovuti a Tanoa o a quella particolare missione, inzeppata di script non sappiamo se fatto bene o no? Quindi appurato che con quella missione gli FPS sono bassi si ripete la prova, sempre nella stessa zona di Tanoa, con lo stesso numero di IA, e si guarda. Se gli fps sono più o meno uguali si potrà dire ok la missione non c'entra niente, è proprio Tanoa che non va.

[{BDR}*Nemesi*]

Originariamente inviato da Sberla101

Io sinceramente con ArmA 3 non ho mai avuto problemi di FPS, anche quando avevo il 2600k; appena avrò la fortuna di prendere la 1080ti Strix (quando la troverò) vi dirò i bench

Idem, mai problemi neppure con i5 e gtx 560 nel mio caso.

[D4N!3L3]

Originariamente inviato da marcolpasini

Forse ArmA IV passerà ad Enfusion e la situazione potrebbe migliorare, forse.. Ti consiglio di fare qualche test con YAAB provando enableht e cpucount, mettendo hugepages e provando un po a pasticciare, qualcosina magari sfrutti

Ok proverò e vi dico il risultato.

[D4N!3L3]

Originariamente inviato da Sberla101

Io sinceramente con ArmA 3 non ho mai avuto problemi di FPS, anche quando avevo il 2600k; appena avrò la fortuna di prendere la 1080ti Strix (quando la troverò) vi dirò i bench

Prova a mettere una 60ina di IA (anche 80), 30 vs 30 o 40 vs 40 di fronte nell'editor e poi mi dici.

[marcolpasini]

Originariamente inviato da {BDR}*Nemesi*

Qui si sta facendo una gran confusione. Ricapitoliamo da quando siamo partiti, un giocatore viene buttato fuori da un server (dove è in corso una missione precisiamo, se no le cose cambiano), questo può succedere per due motivi

- non ha i mod necessari per giocare la missione, errore generato "non puoi giocare/modificare la missione, essa è legata a contenuti scaricabili che sono stati cancellati" e giù la lista;

- ha attivato dei mod che non sono consentiti dal server, errore "il file xxx richiede una chiave non accettata da questo server" qualcosa del genere

Non viene cacciato se ha dei mod in più che non sono presenti nella missione se il server non ha controllo firme, quello che lui carica all'inizio quando lancia il gioco non viene usato dalla missione ed è ininfluente (a meno di mod particolari che entrano in conflitto l'uno con l'altro, per esempio se ha una modificazione "apocalittica" della mappa del chernarus, ma in questo caso viene direttamente buttato fuori perchè mancano contenuti). Normalmente coi mod di contenuti, es armi come era il caso di cui si parlava, se quelle armi non sono usate nella missione non si crea nessun conflitto e il mod in più è ignorato.

Poi ci sono altri problemi che sono legati alla località, ma questi sono problemi ben diversi. Se l'arsenale virtuale è locale al client come ho detto un motivo in più per non usarlo in missione (io non l'ho mai usato in missione e mai lo userò per mille motivi, si vanno a far benedire i ruoli etc etc), tornando a noi sicuramente ci sono dei sistemi per farlo gestire dal server come correttamente deve essere. Ci sono sistemi che ovviano il fatto che uno possa entrare in un server senza un mod particolare e sono di piazzare nell'editor un oggetto legato al mod (oppure crearlo se non esiste), alternativamente attivare "check for addons" nella config del server (però è pesantuccio se si controllano tutti gli addons, si può ricercare uno o pochi addons particolari). Ovviamente in una missione tutti i client devono vedere le stesse cose e il mission maker deve stare molto attento a problemi di località (es se c'è la randomizzazione di un obiettivo essa va gestita dal server e così via). Non so in che server giochi ma ovviamente quello che hai descritto non deve esistere e se esiste vuol dire che la missione è quanto meno "da rivedere".

Lo scompenso come lo chiami tu è una definizione fumosa, quello che succede in una missione o in un server ha cause precise che vanno individuate con precisione se si vogliono correggere, se non sappiamo qual è la causa non possiamo intervenire.

2. Infatti la view distance non è gestita dal server ma dalla missione in prima istanza, solo se la missione non ha impostato nessun valore viene preso quello del server. In multiplayer mai è gestita dal client, le impostazioni del client valgono per il single player e basta. Come è corretto che sia aggiungo, perchè è il mission maker che stabilisce qual è la view distance giusta per la missione, e perchè i client devono vedere tutti la stessa cosa. Quindi la view distance, e view object distance, possono essere inferiori a quelli della missione se così li imposta il client, mai superiori. La view distance/object distance può essere parametrizzata, ma di nuovo è una impostazione della missione. Ogni client in quel caso imposta il suo parametro, che non può superare i parametri della missione. CH addon è un sistema di parametrizzazione un po' più complesso e sofisticato, ma sempre parametrizzazione è, puoi vedere da qui (si riferisce alla versione scripted), sono valori che vanno impostati in missione (la versione addon fa la stessa cosa ma come addon invece che come script)

1. Place "CHVD" folder in your mission folder.

2. Add this code to description.ext file in your mission folder:

#include "CHVD\dialog.hpp"
class CfgFunctions
{
#include "CHVD\CfgFunctions.hpp"
};

3. Quando si vuole trovare la causa di un qualcosa bisogna separare le variabili l'una dall'altra. Se si fanno prove con più variabili tutte assieme non si troverà mai la causa. Ne caso in questione gli fps bassi sono dovuti a Tanoa o a quella particolare missione, inzeppata di script non sappiamo se fatto bene o no? Quindi appurato che con quella missione gli FPS sono bassi si ripete la prova, sempre nella stessa zona di Tanoa, con lo stesso numero di IA, e si guarda. Se gli fps sono più o meno uguali si potrà dire ok la missione non c'entra niente, è proprio Tanoa che non va.

Non credo di aver fatto confusione

Originariamente inviato da wolf74

Va be ma se non la usano allora sarà un qualcosa in più. Non penso che avere più mod di quelle richieste dal server crei problemi di incompatibilità. Posso capire se io avessi una mod in meno di quella richiesta dal server...

L'utente, secondo la sua esperienza iniziale, pensa che caricare una mod in più non crea problemi di incompatibilità. Come avevo anche risposto, correttamente ( tralasciando il problema del kick, cosa che se avesse hostato una partita con un amico non sarebbe successo o se il server fosse mal gestito ), questo crea confusione sia tra i giocatori che al server, non avendo lui quella mod. Il discorso che hai tirato fuori di required, verifysignature, bla bla bla non ha senso ( ho capito che sai qualcosa del gioco ), la domanda era molto semplice 1+1 fa 3? No.

Quello che ho descritto può succede tranquillamente in realtà, se uno fa partire una mod in meno e joina nel server e la missione, non avendo nei required addon le unità, non lo caccia. Ma se la missione spawna quelle unità tramite script ed il giocatore non ha caricato la mod, gli apparirà solo un pop-up di errore ( molto comuni con le mod in arma ) e non vedrà le unità o i veicoli.

In realtà è abbastanza comune se non si fa attenzione a tenere le bisign aggiornate ad ogni update anche di un singolo pbo, alcuni giocatori a volte si dimenticano di fare il sync per la fretta e joinano ugualmente ( da allora infatti rifirmo tutto sempre )

Questo non succede se si giocano missioni molto banali con due unità piazzate in mappa, allora l'editor salvando la missione legge tutte le mod e piazza la mod tra i required ( ma chi fa più missioni piazzando la roba in editor?? )

2. scusa ma prima dici che MAI i client in multiplayer possono gestire le impostazioni ( o MAI è relativo ? ) e poi sotto invece dici l'incontrario?
Che parametrizzazione? Quello che hai postato è semplice una istruzione che dice di includere il dialog del CH alle opzioni associate allo scroll, ogni script deve essere lanciato da init o da qualche parte per funzionare.. Altrimenti non può funzionare

3. prima hai parlato di provare la missione senza la mod ma non mi pare avesse caricato mod, si stava parlando solo di quella missione

tl:dr Ho capito che stai facendo gara a chi ne sa di più ma qui si stanno facendo wall of text per semplici domande banali di altri utenti includendo risposte e precisazioni che boh...

[marcolpasini]

Originariamente inviato da D4N!3L3

Prova a mettere una 60ina di IA (anche 80), 30 vs 30 o 40 vs 40 di fronte nell'editor e poi mi dici.

In quella situazione stai stressando il gioco particolarmente, si trova di botto 1vs1 ed elabora tutte le sue filosofie Posta qualche screen con preset ULTRA ( senza toccare nulla ) di YAAB in 1080 e vediamo, ora trovo qualcuno dei miei

http://i.imgur.com/0Gfzji9.jpg

Questo ancora con la 980, con la 1080 è cambiato di 0,x ed era anche prepatch

[{BDR}*Nemesi*]

Originariamente inviato da marcolpasini

Non credo di aver fatto confusione



L'utente, secondo la sua esperienza iniziale, pensa che caricare una mod in più non crea problemi di incompatibilità. Come avevo anche risposto, correttamente ( tralasciando il problema del kick, cosa che se avesse hostato una partita con un amico non sarebbe successo o se il server fosse mal gestito ), questo crea confusione sia tra i giocatori che al server, non avendo lui quella mod. Il discorso che hai tirato fuori di required, verifysignature, bla bla bla non ha senso ( ho capito che sai qualcosa del gioco ), la domanda era molto semplice 1+1 fa 3? No.

Quello che ho descritto può succede tranquillamente in realtà, se uno fa partire una mod in meno e joina nel server e la missione, non avendo nei required addon le unità, non lo caccia. Ma se la missione spawna quelle unità tramite script ed il giocatore non ha caricato la mod, gli apparirà solo un pop-up di errore ( molto comuni con le mod in arma ) e non vedrà le unità o i veicoli.

In realtà è abbastanza comune se non si fa attenzione a tenere le bisign aggiornate ad ogni update anche di un singolo pbo, alcuni giocatori a volte si dimenticano di fare il sync per la fretta e joinano ugualmente ( da allora infatti rifirmo tutto sempre )

Questo non succede se si giocano missioni molto banali con due unità piazzate in mappa, allora l'editor salvando la missione legge tutte le mod e piazza la mod tra i required ( ma chi fa più missioni piazzando la roba in editor?? )

2. scusa ma prima dici che MAI i client in multiplayer possono gestire le impostazioni ( o MAI è relativo ? ) e poi sotto invece dici l'incontrario?
Che parametrizzazione? Quello che hai postato è semplice una istruzione che dice di includere il dialog del CH alle opzioni associate allo scroll, ogni script deve essere lanciato da init o da qualche parte per funzionare.. Altrimenti non può funzionare

3. prima hai parlato di provare la missione senza la mod ma non mi pare avesse caricato mod, si stava parlando solo di quella missione

tl:dr Ho capito che stai facendo gara a chi ne sa di più ma qui si stanno facendo wall of text per semplici domande banali di altri utenti includendo risposte e precisazioni che boh...

Deve essere cura del mission maker fare in modo che quello che hai descritto non succeda, se il server spawna unità il mission maker deve fare in modo che ci sia un controllo sui mod e i sistemi sono quelli che ho detto, mi dispiace ma è così, e la missione quanto meno è da rivedere

Il CH addon si basa su una parametrizzazione della view distance da mettere in missione (oppure lo fa lui direttamente tramite addon) ma la cosa è quella, è una parametrizzazione. Il client può scegliere il parametro consentito dalla missione, nella missione si può anche mettere che il client può scegliere la sua view distance ma deve essere fatto dalla missione, se la missione forza una view distance quella è quella resta. Giustamente anche, secondo me.

Sto parlando del fatto che non si possono cambiare più variabili alla volta, che siano mod o missioni particolari piene di script non fa differenza.

[Viper1979]

Inutile paragonare Arma 3 agli altri giochi dove si fanno tranquillamente 100 fps, è un mondo a se stante, nel clan ne ho viste di tutti i colori...
Fino ad un anno e mezzo fa giravo con un Core2duo ed una gtx 550, giocare ad arma 3 stava diventando un agonia, poi ho cambiato sistema mantenendo sempre la 550 ed è stata la svolta, giocando coi settaggi riuscivo a mantenere i 25-30 fps stabili, ora con la gtx 1070 giro con tutto sparato al max e faccio dai 20 nelle fasi più pesanti ai 60 e più fps, che per arma è il top

[marcolpasini]

Credo sia più responsabilità del server admin gestire la cosa, abilitare il check pbo tipo di ace è una pesantezza inutile; imho basta tenere il server ordinato con verifysignature attivo ed aggiornare le bikey e bisign ,ad ogni update, delle cartelle che cambiano. Tanto con arma3sync ormai è una cosa da 3 secondi. Poi è anche vero che molti giocano senza controllo firme e non ho idea di come facciano, molti giocatori testano mod scaricate qua e là nel tempo libero e a volte le lanciano accidentalmente.
Chi non ha mai lanciato una mod e non riusciva ad entrare per poi accorgersi di aver lanciato qualcosa in più? Alziamo le mani

Quello che ho spiegato è un caso limite, mica gioco e mantengo un server del genere Mi sarei già sparato

Come controllo view distance in genere in clan si usa CH/CBA o script creati ad hoc dal missionmaker, tenere tutti la stessa viewdistance lo trovo pratico solo se tenuta ad una valore accettabile e non si fa utilizzo di mezzi di alcun tipo, sennò voglio vedere l'apache, l'F18 o l'uav fare supporto long range: neanche vede a cosa sparare A meno che si tenga tutto sparato al massimo per tutti, ma allora ciao fps

[D4N!3L3]

Originariamente inviato da marcolpasini

In quella situazione stai stressando il gioco particolarmente, si trova di botto 1vs1 ed elabora tutte le sue filosofie Posta qualche screen con preset ULTRA ( senza toccare nulla ) di YAAB in 1080 e vediamo, ora trovo qualcuno dei miei

http://i.imgur.com/0Gfzji9.jpg

Questo ancora con la 980, con la 1080 è cambiato di 0,x ed era anche prepatch

Ok, appena lo faccio lo posto.

[{BDR}*Nemesi*]

Originariamente inviato da marcolpasini

Credo sia più responsabilità del server admin gestire la cosa, abilitare il check pbo tipo di ace è una pesantezza inutile; imho basta tenere il server ordinato con verifysignature attivo ed aggiornare le bikey e bisign ,ad ogni update, delle cartelle che cambiano. Tanto con arma3sync ormai è una cosa da 3 secondi. Poi è anche vero che molti giocano senza controllo firme e non ho idea di come facciano, molti giocatori testano mod scaricate qua e là nel tempo libero e a volte le lanciano accidentalmente.
Chi non ha mai lanciato una mod e non riusciva ad entrare per poi accorgersi di aver lanciato qualcosa in più? Alziamo le mani

Quello che ho spiegato è un caso limite, mica gioco e mantengo un server del genere Mi sarei già sparato

Come controllo view distance in genere in clan si usa CH/CBA o script creati ad hoc dal missionmaker, tenere tutti la stessa viewdistance lo trovo pratico solo se tenuta ad una valore accettabile e non si fa utilizzo di mezzi di alcun tipo, sennò voglio vedere l'apache, l'F18 o l'uav fare supporto long range: neanche vede a cosa sparare A meno che si tenga tutto sparato al massimo per tutti, ma allora ciao fps

Tenere aggiornate bisign e bikey è un'ovvietà, per il client le bisign si aggiornano con l'aggiornamento del mod, fanno parte del mod stesso, le bikey ovviamente vanno aggiornate da chi gestisce il server se no non si entra più. Se qualche utente lancia una mod in più e non c'è controllo firme non succede niente a meno di casi molto particolari (non succede niente con mod di armi e contenuti vari).

Poi per la view distance il discorso, semplice, è che comunque sia che la view distance, sia parametrizzata o forzata, questo dipende dalla missione e non dal client nel multiplayer, giustamente.

[marcolpasini]

Non sempre si aggiornano con l'aggiornamento della mod, ci sono parecchi modder che usano sempre la stessa biprivatekey e firmano mille versioni della stessa mod con la stessa versione. Uno con la versione 0.1 ed uno con la versione 21324546 possono joinare tranquillamente entrambi, tanto superano il controllo Sempre meglio rifirmare tutto in ambito clan

[{BDR}*Nemesi*]

Originariamente inviato da marcolpasini

Non sempre si aggiornano con l'aggiornamento della mod, ci sono parecchi modder che usano sempre la stessa biprivatekey e firmano mille versioni della stessa mod con la stessa versione. Uno con la versione 0.1 ed uno con la versione 21324546 possono joinare tranquillamente entrambi, tanto superano il controllo Sempre meglio rifirmare tutto in ambito clan

Beh non so di che mod parli, forse quelli fatti male perchè di solito invece sia bikey che bisign cambiano, come deve essere se no è inutile firmare il mod.

Rifirmare tutto è poco pratico in quanto se poi giochi con altri gli va fatto riscaricare tutto, quantomeno le bisign, se no vengono buttati fuori dal server. Non molto pratico.

[marcolpasini]

Originariamente inviato da {BDR}*Nemesi*

Beh non so di che mod parli, forse quelli fatti male perchè di solito invece sia bikey che bisign cambiano, come deve essere se no è inutile firmare il mod.

Rifirmare tutto è poco pratico in quanto se poi giochi con altri gli va fatto riscaricare tutto, quantomeno le bisign, se no vengono buttati fuori dal server. Non molto pratico.

In realtà ben pochi inizialmente usavano versioni incrementali delle bikey, basta guardare tfr.. FHQ, beketov, HLC, leights, ecc. Anche il primo A3MAP non cambiava mai le signature ed il ricordo di altri va perso nella notte di tempi.
I primi che hanno iniziato a fare le cose bene sono stati kju ed il team ace, cba, acre, rhs e poi a seguire altri hanno seguito il buon esempio..

Rifirmare tutto non implica assolutamente riscaricare tutto: intendi i pbo? I pbo, se aggiornati sarebbero da riscaricare ugualmente. Se il pbo non cambia ma viene solo rifirmato è da scaricare solo il bisign, ( 1 kb ? ) Scaricare 10-60 kb di bisign che problema sarebbe con le attuali connessioni adsl/fibra ottica ?

[marcolpasini]

Originariamente inviato da D4N!3L3

Ok, appena lo faccio lo posto.

I parametri che fanno "qualcosa" sono:

-nologs ( se non si deve fare debugging è inutile tenere l'hdd ed il gioco impegnato a scrivere eventuali errori )

-nosplash ( avvio più rapido dal desktop al gioco)

-skipIntro e -world=empty ( aiutano sempre al caricamento dal desktop al gioco )

-maxmem ( su 32bit con il performance executable si poteva settare 3072 , ora con il 64 bit in dev era settato a massimo 8192, ora non ho seguito ma avendo 32 gb tengo impostato 16384 e ciao )

-cpucount o -enableht ( o uno o l'altro, in caso di processori senza hypter-threading è inutile tenere enableht, in alcuni casi con core superiori a 4 ho notato miglioramenti rispetto all'ht, è soggettivo in base alla configurazione hw )

-hugepages ( abilita un differente allocatore di memoria che consente di ottimizzarne l'utilizzo )

-noPause ( utile se si altabba o si usa configurazioni multiscreen, il gioco non va in pausa anche se non come applicazione in primo piano )

[Viper1979]

ti sei scordato -ExThreads da mettere a 7 per i quadcore, i5 i7, da nn confondere con i threads delle cpu che son altra cosa https://community.bistudio.com/wiki/...ters#exThreads