Jump to content
Sign in to follow this  
72sq_Savinio

Dserver issue

Recommended Posts

Buongiorno a tutti.

Provando con altri giocatori ad hostare un dediserver stiamo incontrando un pò di problemi di lag quando le AI si fanno numerose ( almeno 3 :blink: ) oppure quando i giocatori si fanno numerosi (almeno 4 :o:  :o:  ).

Dai valori riportarti sul launcher del Dserver risulta un andamento decisamente altalenante dei vari ping. Se ciò non crea grossi problemi per i bersagli a terra dove, a parte effetti grafici indesiderati tipo raffiche che durano molto più di quanto effettivamente dovrebbero, non si verificano lag stessa cosa non si può dire dei dogfight, dove la lag è imperante, tanto da rendere impossibile giocare.

Alcuni dati che possono aiutare.

 

-La missione è leggerissima, praticamente ha solo le nuvole e gli aerei che spawnano di volta in volta solo se qualcuno si avvicina.  Ne vengono generati tanti quanti sono i giocatori che si avvicinano (un pò di casisitica: 1AI vs 1p nessuna lag, 2AI vs 2p lag presente - 2p vs 1p lag presente - 2p vs 2p lag presente - 1p vs 3AI lag presente)

 

-La mia linea non è un granchè, i valori accertati arrotondati per difetto sono Down:10mb Up:800kb, il computer è bene o male quello in firma quindi non dovrebbe creare problemi nella gestione di 3 AI. 

 

-Il server di norma ha un ping di 30, dei giocatori tra i 30 e i 40.

 

-I valori di configurazione in Download e upload sono quelli di default.

 

Qualcuno riscontra gli stessi problemi?

Il punto è che sui server online questi rallentamenti non sono presenti. Mi domando quindi se non ci sia qualche setting particolare dei valori sopra riportati da sistemare per ovviare alla fastidiosa e impossibilitante problematica. 

Grazie in anticipo a chi risponderà. 

S!

 

72sq_Savinio

 

 

Share this post


Link to post
Share on other sites

Ciao Savino,

 

attualmente non sto riscontrando questi problemi in una missione con 20 aerei AI ( + 5/6 giocatori) e una 30ina di unità di terra. In queste settimane sto proprio dedicandomi a comprendere i limiti che BoS ha in termini di peso rispetto alle missione di RoF (aihmé il fratello WWI è più leggero rispetto alla WWII finora).

 

Anche le mie prove si affidano ai valori di default ed è per questo che, salvo i classici suggerimenti (firewall, antivirus bla bla bla) che ormai diamo per assodati come anche l'evenienza di problemi esterni a BoS, prova a verificare gli script dei spawn e active, un consiglio che tendo a dare è quello di evitare quanto possibile la contemporaneità degli eventi.

 

Esempio : Mission Begin > Trigger Time : 2sec > Complex trigger (Controlla che l'aereo XYZ entra nell'area) > Trigger Time : 1s > Trigger  spawn > Trigger time : 0.50s > Trigger active.

 

Perché? (risposta in soldoni) Il sistema di programmazione delle missioni di RoF/BoS è a lettura lineare del file missione e la missione viene processata dal punto A al punto B nel modo più veloce possibile... se i due punti si distanziano parecchio il processore si concentrerà su quelli rallentando le altre operazioni indi LAG nel dogfight (ritardi nel processare la posizione degli aerei e delle traiettorie di fuoco).

 

---

 

Nel caso se vuoi condividere la missione vediamo assieme se c'è qualche problema ( se preferisci mandala pure in PM).

Share this post


Link to post
Share on other sites

Ciao Acasto e grazie della risposta

Anzitutto per far verificare a qualcuno con esperienza e capacità non mancherò di inviarti la missione appena ne avrò la possibilità. :)

 

Dovrei aver implementato già i trigger timer necessari, ma confido di averne saltato qualcuno visto che non li utilizzo per una struttura passo passo come quella da te descritta.

 

Approfitterei della disponibliltà per fare un paio di domande così da capire meglio: 

 

-

 

se i due punti si distanziano parecchio il processore si concentrerà su quelli rallentando le altre operazioni indi LAG nel dogfight

 

Temo di fare un pò di confusione.. oltre ad inserire i trigger timer questi non dovrebbero occupare troppo tempo altrimenti la CPU si "fossilizza" su quella particolare sequenza, che seppur interrotta (magari da un timer trigger di 10minuti :ph34r: )  rimarrebbe in sottofondo togliendo potenza di calcolo per le altre operazioni?

 

Il tuo consiglio e quindi di snellire il tutto utilizzando i trigger timer solo per la sequnzialità delle azioni e per il resto di utilizzare eventi che attivano e disattivano ogni determinato scrip così da terminare di volta in volta la porecessazione da A a B il più rapidamente possibile? 

 

Altra domanda: Nel caso di due processi in parallelo? E' consigliabile alternarli o si possono far procedere assieme?

 

Scusa i termini un pò arrangiati, ma non sono un tecnico ed è mi trovo all'inizio della strada per l'utilizzo dell'editor. Che trovo peraltro molto bello.  :salute:

 

Grazie ancora e non mancherò di fare altre domande se non è di disturbo. :)

 

 

Edit: C'è un'altra cosa che non mi torna... ma se dipendesse dalla cpu non dovrebbero anche calare gli fps? invece questi rimangono fissi e non variano di 1 singolo fps.

Edited by 72sq_Savinio

Share this post


Link to post
Share on other sites

Vediamo di fare un po' d'ordine anche a futura memoria dei visitatori:

 

Grazie ancora e non mancherò di fare altre domande se non è di disturbo. :)

 

Dove posso arrivare rispondo :hunter: oltre bisogna sperimentare... l'editor missione è complesso e da buon "linguaggio di programmazione" ci sono n+1 strade per raggiungere un risultato di cui molte sembrano corrette ma non funzionano.

 

Premetto che parliamo di multiplayer, per quel che è la mia esperienza personale il motore RoF/BoS sembra abbia un livello in cui si "satura" (1), sostanzialmente un punto in cui più di un predefinito numero di funzioni contemporanee che seppur semplici, iniziano a rallentare il funzionamento del simulatore (indifferentemente dalle prestazioni hardware della macchina, ecco le ragioni della non presenza di problemi sugli FPS).

Per funzioni intendo tutte quelle dinamiche che vengono scritte, lette, analizzate e rielaborate dalla missione contemporaneamente (2), e dobbiamo fare una suddivisione tra le funzioni logiche (L) e le funzioni materiali (O); visto che stai mettendo mano all'editor i colori delle mie parole dovrebbero rimandarti alle linee che l'editor congiunge tra le funzioni che colleghi.  Per chi non ha provato lo FME le funzioni L sono quelle che avvengono in modo invisibile come possono essere l'attivazione di un controllo territoriale (Trigger Check Zone) o di un punto rotta (Trigger Waypoint), mentre le funzioni O sono quelle che avvengono in modo visibile come può essere il comando di bombardare un area o di far comparire un oggetto.

Tra le funzioni che portano alla saturazione dobbiamo fare un'ulteriore classificazione tra le funzioni "instantanee" e le funzioni "pendenti" alle funzioni instantanee come nel caso dei Timer.

Il timer infatti è una funzione che impegna immediatamente la memoria e per il tempo del suo conteggio, continua ad essere presente in background al processo di missione per intenderci (la stessa cosa vale per un Trigger Check Zone che continua ad analizzare un area fintanto che non viene disattivata. Ma allo stesso tempo il Timer permette di traslare temporalmente una serie di azioni instantanee al fine di alleggerire l'unità di tempo specifica.

 

Sono una serie articolata e complessa di concetti da capire ma ti possono portare a capire un po' di problemi che possono emergere e causare dei rallentamenti.

 

Fatta questa considerazione torniamo alla struttura della mia precedente risposta:

 

Esempio : Mission Begin > Trigger Time : 2sec > Complex trigger (Controlla che l'aereo XYZ entra nell'area) > Trigger Time : 1s > Trigger  spawn > Trigger time : 0.50s > Trigger active.

 

ora vediamo di intrecciare le nozioni che abbiamo acquisito prima, abbiamo il Mission Begin che tramite una funzione L attiva un Timer che allo scadere del tempo T attiva una funzione questa funzione necessita di una risposta materiale per proseguire e quindi (indifferentemente dal tipo di risposta) dovrà aspettare il corretto adempimento materiale per continuare il ciclo; ques'ultimo continua non richiedendo subito un altro adempimento materiale ma pone un tempo tramite una funzione che L trasla temporalmente in un momento "migliore" l'adempimento della funzione che fa comparire l'oggetto richiesto tramite una funzione O.

NOTA : i tempi di processo non sono legati solo alla velocità di elaborazione del file missione, anche dal tempo di risposta lato client degli eventi materiali. Capiamo facilmente che dopo la comparsa di un oggetto i pacchetti dati inerenti dovranno essere inviati a tutti i giocatori e seppur parliamo di pochi dati e poche frazioni di secondo... il tempo facilmente raggiunge valori che per noi diventa tastabile a botte di lag. Pertanto se richiediamo subito qualche altra operazione alla nostra missione/programma rischiamo di iniziare un rincorrersi di pacchetti dati tra client e server (il famoso desync tanto caro agli amici di ArmA).

 

 

:happy: Concludo che non voglio demotivare nessuno, anzi! Benvenga qualche altro italiano che ci si cimenti, se ci sbattiamo la testa in molti è più facile per tutti arrivare a dei risultati. Ma del resto, qui parliamo solo di pulizia di forma...

 

 

 

(1) ben sperimentato nella campagna FeOW dove con un accurato lavoro di studio il buon Sonk è riuscito a ottimizzare la missione per farci giocare +100 piloti con dinamiche invidiabili a molti altri server.

(2) non parliamo di un numero basso ma, come avrai iniziato a capire, si fa presto a far lievitare le entità che generano funzioni nel simulatore.

Share this post


Link to post
Share on other sites

Ok, a parte che sono daltonico e non vedo la minima differenza dei colori nel tuo post :biggrin: , è tutto abbastanza chiaro ed è un'infarinatura sull'argomento decisamente corposa. Dovrò fare un po' di esercizio per tradurre la teoria in pratica. Per adesso ti invio la missioncina via pm. Intanto grazie e appena ho altri dubbi (è una lista già ad oggi abbastanza lunga :happy: ) provvederò a chiedere.

Edited by 72sq_Savinio

Share this post


Link to post
Share on other sites
Avendo gli stessi problemi di Savinio, ho letto questo utilissimo thread, e verificato la mia missione. Missione che è anche più semplice di quella di Savinio. Tutto ciò che c'è sono solo dei complex trigger, che all'ingresso di un qualsiasi aereo attivano dei mezzi al suolo. Complex trigger che poi vengono disabilitati una volta usati. Non vi sono aerei AI in nessun caso.

Ho rincontrollato la mia missione, ed ogni passaggio vi è un timer come indicato da te.

Poniamo il caso peggiore, e cioè che tutti e 3 i miei complex trigger stiano facendo un check di zona. In questo caso se ci fosse un qualche peso, tale peso dovrebbe esserci 'sempre'. Volando in formazione di 5-6 elementi non ho mai notato lag. Nel momento in cui uno spara, cominciano le botte di lag. Nel caso di attacchi al suolo vi è una non sincronia fra ciò che uno fa e ciò che gli altri vedono. Anche nel caso più semplice, aereo player al suolo, aereo player che lo mitraglia. Non succede sempre, ma spesso.

Dubito fortemente vengano mandati pacchetti in più quando c'è solo una check zone. Questo a naso dovrebbe essere compito del server, a cui vengono comunque mandate tutte le informazioni necessarie degli aerei in ogni momento, informazioni che poi usa per le verifiche. Immagino poi che l'attivazione del trigger manderà le nuove modifiche 'fisiche' a tutti i client. Questo però dovrebbe fermarsi al momento dell'attivazione, dopo di ché, immagino, vi siano solo gli aggiornamenti server->client per quanto riguarda le eventuali AI.

Inoltre non mi è chiaro il 'peso' che dovrebbe avere un timer. Perché dovrebbe occupare memoria? Memorizzare un momento in cui un evento succederà, con un callback su chi si è registrato mi sembra che, dopo gli anni 70, sia la cosa più leggera al mondo :/. Grazie mille per i chiarimenti Acasto.

 

ps: entro in confusione con la tua definizione, hai detto prima che L (logiche) in verde sono funzioni 'invisibili' come i check zone, dopo hai messo in rosso il complex trigger per il check zone. Svista o mi son perso qualcosa? Grazie ancora!

Share this post


Link to post
Share on other sites

Ho ricevuto la missione di Savinio tramite PM ma non ho ancora avuto occasione di analizzarla ed aggiungo che quello che sto scrivendo è frutto di considerazioni personali, non bibliche  :biggrin: non potendo visionare il codice del FME, nate dall'uso in RoF riportato ora in BoS esattamente come state facendo voi adesso... tentativi e tentativi.

 

Analizzo per punti:

 

 

Poniamo il caso peggiore, e cioè che tutti e 3 i miei complex trigger stiano facendo un check di zona. In questo caso se ci fosse un qualche peso, tale peso dovrebbe esserci 'sempre'.

il peso effettivamente c'è ma il LAG subentra quando questa funzione agisce poi sul lato materiale della missione. Sostanzialmente quando abbiamo le connessioni Rosse nel FME (devo scoprire se c'è modo di cambiare questi colori per aiutare Savinio :salute: ) il Complex trigger è si una funzione logica ma analizza un evento materiale, personalmente lo classifico più nella categoria delle funzioni materiali.

 

 

 

Volando in formazione di 5-6 elementi non ho mai notato lag. Nel momento in cui uno spara, cominciano le botte di lag. Nel caso di attacchi al suolo vi è una non sincronia fra ciò che uno fa e ciò che gli altri vedono.

piccola nota, il motore RoF/BoS (R&B) ha un sistema molto sofisticato nella gestione della balistica... giusto per darti un indicazione, se analizzi i pacchetti trasmessi durante la missione, all'interno delle stringhe di codice troverai : T di Sparo - Tipo di munizione - Velocità di uscita relativa - Coordinate dello sparo - Cordinate+Velocità al T+1 - Cordinate+Velocità al T+2 - Cordinate+Velocità al T+n.... la mole di pacchetti non è poca.
Possiamo obbiettare che è troppa e che può essere drasticamente semplificata con la vecchia concezione "dopo un tempo T la traiettoria del colpo inizia a decadere" ma perderemmo tutto quello che il motore fisico processa come ad esempio la fisica d'impatto(1) ma comunque questa cosa non la annovererei tra i problemi legati allo scripting della missione.

Nel caso specifico sei sicuro della configurazione del server? State usando il server che conoscevo come ITASeOW? 

 

 

(1) c'è una reale differenza tra il danno provocato dai proiettili sparati a diverse velocità verso il bersaglio. In RoF si vedeva benissimo...

Share this post


Link to post
Share on other sites

Penso di aver capito cosa intende Acasto, ma non riuscirei a spiegarlo senza il lato pratico perchè è un'idea piuttosto mal delineata. Riflettendo risulterebbe anche consono al tipo di lag che abbiamo riscontrato noi in Dogfight che sembra proprio un momento di pausa nella di processazione degli eventi del dogfight che interrompe il movimento degli aerei per occuparsi di altro e poi tornare agli aerei stessi. Il che può essere stato dovuto al tipo di impostazione che avevo dato al complex trigger dove mi sono reso conto avevo linee rosse e linee blu sovrapposte ad indicare lo stesso bersaglio. Nella missione inviata ad Acasto già queste non ci sono più e se mi riesce in serata faccio ulteriori test. La lag oltretutto non interferendo sugli fps può essersi benissimo protratta nel tempo anche quando noi non vedevamo le AI, ma è un'osservazione buttata lì. Nonostante ciò ho gli stess dubbi di Evil e ritengo corrette le osservazioni di Acasto il che è tutto dire.. l'unica è provare, provare e riprovare e proveremo su questo potete starne certi, questo Dserver ha da funzionare! :salute: 

Share this post


Link to post
Share on other sites

Piccola nota, spero che Savinio non se ne offenda se uso immagini della sua missione; noto spesso nelle missioni degli utenti che gli aeroporti vengono piazzati facendo riferimento all'icona :friends: forse non tutti sanno che la pianta dell'aeroporto è svincolata dall'icona stessa; se guardiamo l'immagine qui sotto vediamo come l'icona sola, genera uno schema (le linee arancio .. ho eliminato la texture di fondo per migliorarne la visibilità) predefinito ma cliccando su Edit Chart si apre una finestra denominata Airfield Chart Editing che ci permetterà di modificare appunto lo schema dell'aeroporto. 

 

mws66q.png

 

Perché è importante questa funzione? Prevalentemente per due fattori, il primo è l'AI che nel caso presente opererà sull'aeroporto seguendo questo schema; il secondo è l'uso degli strumenti di bordo... alcuni aerei dispongono di sistemi comparabili al VOR non è un grosso problema arrivare al traverso della pista ma, saperci di arrivare già allineati da un valore aggiunto. (Nella beta dell'editor ci hanno fatto tribulare non poco su questo aspetto :lol:).

 

 

Share this post


Link to post
Share on other sites

Ma è un problema lasciarle così come sono se non è prevista l'Ai? perchè le prime volte mi peritavo per sistemare tutto a modo, poi ho letto che serviva alle AI e mi sono rilassato riponendole tra le cose inessenziali.

Share this post


Link to post
Share on other sites

No no, nessun problema, era solo una nota a futura memoria. Non ci sono forum italiani che parlano del FME in maniera costruttiva, almeno qui sul forum ufficiale lasciare qualche informazione male non fa.

 

Un altra NOTA: allo stato attuale le funzioni Rearm and Refuel non funzionano propriamente ( o meglio, non funzionano affatto :russian_ru:nell'editor beta abbiamo una nota a riguardo ), se si vuole simulare un tempo di "preparazione" consiglio di togliere la spunta al Return Aircraft e nel mettere nel menù Plane la ridisponibilità dell'aereo dopo un intervallo di tempo.

 

Sono riuscito a dare un'occhiata solo veloce alla missione ma nulla più che provarla velocemente... provvederò!

Share this post


Link to post
Share on other sites

piccola nota, il motore RoF/BoS (R&B) ha un sistema molto sofisticato nella gestione della balistica... giusto per darti un indicazione, se analizzi i pacchetti trasmessi durante la missione, all'interno delle stringhe di codice troverai : T di Sparo - Tipo di munizione - Velocità di uscita relativa - Coordinate dello sparo - Cordinate+Velocità al T+1 - Cordinate+Velocità al T+2 - Cordinate+Velocità al T+n.... la mole di pacchetti non è poca.

Possiamo obbiettare che è troppa e che può essere drasticamente semplificata con la vecchia concezione "dopo un tempo T la traiettoria del colpo inizia a decadere" ma perderemmo tutto quello che il motore fisico processa come ad esempio la fisica d'impatto(1) ma comunque questa cosa non la annovererei tra i problemi legati allo scripting della missione.

Nel caso specifico sei sicuro della configurazione del server? State usando il server che conoscevo come ITASeOW? 

 

 

(1) c'è una reale differenza tra il danno provocato dai proiettili sparati a diverse velocità verso il bersaglio. In RoF si vedeva benissimo...

 

No, stiamo usando 'server privati'. Io uso un portatile abbastanza veloce e una linea da 100Mb. Riguardo la configurazione è ovviamente in dubbio, non ho ancora provato a cambiare la dimensione dei pacchetti.

 

Per quanto riguarda la balistica, è abbastanza strana tale soluzione. Sicuramente gli sviluppatori la sapranno lunga quindi è quasi inutile discuterne, ma generalmente, le informazioni da passare client->server sono solo le informazioni che il server non può prevedere. Quindi tutto ciò che viene direttamente modificato dal client. In particolare il momento dello sparo, il momento di una qualsiasi pressione di un comando. Di solito nei giochi viene passato il comando e/o la posizione specifica quando cambia. Di tanto in tanto una posizione di 'resync'. Stranissimo dover passare ogni istante del proiettile, il server, avendo maggior certezza della posizione del target, e venendo a conoscenza dei proeittili in partenza, può tranquillamente calcolare ogni posizione intermedia e anche la collisione con il target con la dovuta precisione. Comunque il dserver è praticamente in beta, quindi magari semplicemente non è ancora ottimizzato per poter girare su pc relativamente normali.

  • Upvote 1

Share this post


Link to post
Share on other sites

Anche il server che utilizzo per le prove, concesso dai ragazzi di tuttovola.org è un pc a casa di un ragazzo torinese che con la fibra ha la 100mb e in una missione da me generata (Player vs AI con un attacco all'aeroporto da parte delle AI, il paese vicino bombardato a colpi di Katiusha e IL-2 che attaccano dei trinceramenti tedeschi che si oppongono all'avanzata di due divisioni di carri tra cui T-34 e KV-1S) gira serenamente con 5 giocatori connessi e un server DCS aperto sulla stessa macchina... chi ha configurato la macchina so che è bravissimo ma :biggrin: i miracoli li faceva qualcun'altro. Vediamo di scoprire le ragioni del problema... se non crea problemi Savinio provo a hostarla da loro e giocandola  con 5-6 di loro e vediamo se è un problema extra-FME. Dalla rapida occhiata il lavoro era veramente ben fatto...

Share this post


Link to post
Share on other sites

Nessun problema provatela senza problemi, mi fa piacere che sembri un lavoro ben fatto. L'unica crisi sono i treni distrutti per i quali non riesco a fare in modo che il carriage sparisca in modo rapido e preciso, gli altri script sono tutti da testare e sicuramente migliorabili e mano a mano che capisco come funziona gli sto alleggerendo di molto.

Un cruccio è la formazione degli aerei AI che spawnano, mi pare di aver letto che se utilizzato il trigger spawn non è possibile fargli volare con il "target leader" e di conseguenza non prendono la formazione, sto lavorando per aggirare il problema visto che mi preme far funzionare a modo quello script. Attendo il test vero e proprio. :salute: 

 

Grazie ancora.

Share this post


Link to post
Share on other sites

per tagliare la testa al topo e verificare se è un problema di settaggio server piuttosto che di "costruzione" della missione non sarebbe possibile utilizzare una missione sulla quale Acasto non ha problemi?

 

Almeno così uno saprebbe dove concentrare la raccolta informazioni

 

:)

Share this post


Link to post
Share on other sites

A proposito dei lag. Ieri ho avuto modo di analizzare il comportamento del ping di un client in base all'azione effettuata:

 

Mitragliamento puntando verso il cielo : ping stabile.

Mitragliamento su aereo puntando il cielo: ping stabile.

Mitragliamento al suolo su nemici (altri player/aaa): ping salta da 40 fino a 600 (valori che variano ovviamente in base al player, ad esempio in altri 20-120)

Mitragliamento al suolo in zona libera e senza nemici: ping salta da 40 fino a 600

 

Da questo mi viene in mente che una causa possibile sia qualche bug/problema sulla collision detection con il terreno o la collision response per i traccianti/proiettili ed il loro effetto.

Edited by 6S.Evil

Share this post


Link to post
Share on other sites

Gira e rigira mi viene da riportare l'attenzione ai pacchetti dati che ti dicevo sui proiettili:

 

Mitragliamento puntando verso il cielo : ping stabile : nessun elaborazione, solo traiettoria.

Mitragliamento su aereo puntando il cielo: ping stabile : elaborazione traiettoria + impatto, nessun calcolo dell'effetto Ricochet;

Mitragliamento al suolo su nemici: ping salta da 40 fino a 600 elaborazione traiettoria + impatto+ calcolo dell'effetto Ricochet;

Mitragliamento al suolo in zona libera e senza nemici: ping salta da 40 fino a 600: elaborazione traiettoria + calcolo dell'effetto Ricochet;

 

o può essere come suggerisci tu un bug/problema sulla collision detection con il terreno o la collision response per i traccianti/proiettili ed il loro effetto.

Share this post


Link to post
Share on other sites

Sì certo, diciamo la stessa cosa, che l'effetto Ricochet costi 500 millisecondi lo vedo come un problema/bug, almeno considerando un gioco multiplayer contemporaneo. Non è stato già segnalato?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×
×
  • Create New...