Jarvis - versione dll

Bene ragazzi...

ecco la patch per l'ultima versione (serve sempre prima l'originale di qualche giorno fa per gli altri moduli), compreso il modulo per l'esplosione

LINK

(poi, se avete voglia di giocare con le specifiche di particle stream,  mi fate sapere quali secondo voi d'anno l'effetto migliore per l'esplosione? così le inserisco). Failure del countdown, scrub e failure del primo stadio fatti. Manca il failure del secondo stadio a cui penseremo la prossima settimana.

Poi voglio passare al Jarvis-B perché comincio ad odiare l'S

Un fatto strano: sul computer dei miei le percentuali vengono rispettate, sul mio portatile no, nel modo più assoluto. Stasera vedo se la cosa mi funziona o no sul mio PC ammiraglio.. Mi chiedo se ci voglia una libreria particolare da installare per questa funzione che genera i numeri random..

prova anche a riscaricare l'ultima patch perché mi sono accorto un minuto fa che avevo sbagliato la dll che avevo caricato...   

Si ok ora funziona!
Bell'effetto! Secondo me si può migliorare ancora a livello di texture, troverò qualcosa da proporti! 

Questa è la texture per l'esplosione del Themis A di Loru.. gli chiederemo un piccolo consiglio in proposito  

http://speedy.sh/srgxS/explosion.dds
http://speedy.sh/NMzAr/explosion.bmp

Ecco la textures in dds e bmp!

Fred, hai mica voglia di ricaricare tutto insieme in un unico link? in modo che sia più comodo anche per altri che vogliano far del beta testing.

Ho trovato un bel suono di esplosione:

http://speedy.sh/FPTNe/explosion.wav

Se vi interessa risale ad un razzo atlas del 1965 che ha polverizzato la rampa  

 

Ho fatto una prova veloce, a proposito davvero molto bella la separazione dei fairing. 

Non ho capito bene come impostare le failures... si può fare un riepilogo?  

Ho notato una cosa, particolarmente evidente nel portatile-cesso che sto usando: l'autoguida pare particolarmente sensibile ai bassi frame-rate: in quelle condizioni il pitch tende ad andare veramente tanto "a scatti", o "a sobbalzi" se la cosa rende l'idea... non che incida sull'accuratezza di guida, ma visivamente è proprio brutto da vedersi. Credo che il problema sia causato in parte dal carico grafico aggiuntivo dato dallo scenario di lancio: infatti quando si sale di quota e ci si allontana, la cosa tende a scomparire. Lo fa solo a me? C'è modo di porre rimedio alla cosa?

ah un'altra cosa, non ho capito per cosa sta la sigla COI...

EDIT
trovato...  

Andrew ha scritto:

Non ho capito bene come impostare le failures... si può fare un riepilogo?  

Devi andare in config/jarviss/failures.cfg e impostare i valori che sono in percentuale. Se ad esempio imposti COUNTDOWN_STOP=100 avrai sicuramente uno stop del conto alla rovescia. Stessa cosa per le failures del primo e del secondo stadio.

Amici,

eccomi... allora ho lavorato un paio d'ore sulle ultime cose e posto qui il link al pacchetto completo, senza patch o nulla, tutto in un file:

LINK PACCHETTO

- attivando l'opzione "lowres" ora i controlli del pitch nella prima parte del volo avvengono ogni 3 decimi di secondo e non più ogni frame come prima. Il risultato è che il pitch oscilla un pochino su e giù, ma in maniera abbastanza contenuta, sperando che non vada più a sobbalzi come ora per i pc con problemi di FPS.

- funzionano le failures anche per il secondo stadio, l'unico problema è che se si spegne uno dei due motori laterali il vettore comincia a imbardare e bisogna tenere la rotta corretta a mano. il pitch funziona in automatico e se a spegnersi è il motore centrale in alto non c'è bisogno di toccare niente. Ho provato a scrivere una routine che correggesse da sola questo problema correggendo lo yaw ma per ora non funzionava, quindi l'ho esclusa. Ci riproverò nei prossimi giorni, ma non è molto semplice.

- ho aggiunto la texture dell'esplosione la boom, ma non ho ancora fatto in tempo ad aggiungere il suono, ottimo lavoro fausto per aver trovato questi particolari.

Per le failures correttissimo quello che dice fausto: nel file failures.cfg ci sono le probabilità che avvenga qualcosa in percentuale:

COUNTDOWN_STOP=18

18% di probabilità che durante il countdown il conto si fermi

SCRUB=25

25% di probabilità che una volta che si è fermato non riparta più.

S0_FAILURE=1.2

1,2% di probabilità che durante il periodo di accensione del primo stadio si abbia un'avaria

S1_FAILURE=3

3% di probabilità che durante il periodo di accensione del secondo stadio si abbia un'avaria

come giustamente suggeriva fausto, se vuoi fare delle prove per vedere gli effetti, basta mettere quello che vuoi al 100 e a quel punto sei sicuro che qualcosa di brutto succederà  


a parte l'imbardata in caso di engine failure e la taratura delle particle dell'esplosione per me il Jarvis S è finito, voi che dite?

come effetti direi di si, credo!
comunque direi, prima di passare alle prossime versioni, di prenderci qualche giorno di beta testing per limare eventuali altre cose in modo da avere una base già pronta per gli step successivi. Che ne dite?

per il problema dei sobbalzi: quando hai detto che il pitch viene corretto "ad ogni frame" mi hai fatto pensare a una cosa. Nei sistemi più lenti, subito dopo il lancio, la simulazione rallenta, quindi ci sono meno frames al secondo. Di conseguenza anche il pitch viene corretto più lentamente e va a sobbalzi. Se invece di legarlo ai frames provassi a impostare il pitch a un valore fisso, ma anziché 3 decimi di secondo come hai fatto tu, lo impostassi a 1 decimo di secondo (con la grafica normale e non lowres)?

Per il discorso dell'imbardata, io ho un'idea che non so se sia applicabile: usare un comando di rollio. Cioè, se si spegne un motore laterale, il razzo ferma il pitch, ruota di 60° fino a che il motore si trovi ad essere in alto (o in basso) in modo che la spinta asimmetrica vada a cadere sull'asse di beccheggio e non di imbardata (come se si fosse spento il motore in alto) e poi riprende il pitch.

Sarebbe la soluzione al problema, ma non so se è applicabile.

Grande Fred, ottimo lavoro per quanto riguarda l'esplosione!

Per me una sola cosa manca: la debug string che ci dice qual'è il problema per lo stop del countdown. Avevo previsto 4 ragioni perché questo accadesse:

COUNTDOWN HOLDING: LAUNCH PAD PROBLEM (probabilità di ripresa del conto: 40%)
COUNTDOWN HOLDING: ELECTRIC FAILURE (probabilità di ripresa del conto: 30%)
COUNTDOWN HOLDING: HIGH PRESSURE VALUE (probabilità di ripresa del conto: 20%)
COUNTDOWN HOLDING: MAIN TANK LEAK (probabilità di ripresa del conto: 10%)

Le probabilità che invece uno di questo problema sorga si equivalgono, per sempliità.

Non so se ti è un casino implementare anche questo, se si lasciamo così che già p un risultato eccezionale! 

Amici,

vi scrivo da un aeroporto perché oggi sono in viaggio di lavoro quindi perdonatemi
eventuali imprecisioni  

anzitutto @Fausto: si hai ragionissima, mi sono completamente scordato di aggiungerle. Vedo come fare, ma non vedo problemi. Lascerei comunque così il calcolo della probabilità di scrub.

Poi pensavo di mandarvi una dll apposita del jarvis, da non lanciare ma solo lasciarla in rampa qualche minuto, dove invece che fare i conti "random" per le probabilità solo all'inizio della simulazione, il modulo faccia un conto ogni frame, e mostri le percentuali dei risultati. In questo modo in pochi secondi sulla rampa avremo a disposizione subito centinaia di tentativi e potremmo verificare che sui pc di tutti noi le cose tornino come devono tornare.

poi rispondendo ad Andrew su tutti i punti:

il sistema di guida frame per frame vuole simulare una IMU. Quella del saturn aveva una frequenza di aggiornamento di 120 hz, quindi per noi equivarrebbe ad avere 120 FPS che è già un valore alto. In realtà ho fatto un po' di prove e per ottenere dei risultati soddisfacenti in termini di continuità e precisione la frequenza minima che ho trovato è circa 50 Hz. Adesso, impostare il check ogni 50esimo di secondo oppure ad ogni frame non fa molta differenza, anche perché nei momenti immediatamente successivi al lancio gli fps sono spesso più bassi di 50. Controllando poi con altri addon di "guida" tipo l'attitude mfd, il launch mfd etc, hanno tutti i comandi impostati per agire ad ogni frame, quindi sarei orientato per lasciare così.

per l'imbardata anch'io per un attimo avevo pensato di ruotare il tutto ma ci sono due grossi problemi:

il primo è il transitorio: mentre effettuo il rollio ho una spinta già dissimmetrica che produce un'imbardata. combinando rollio e imbardata diventa un bel po' complicato capire dove si va a finire alla fine del giro. E' molto probabile che quando ho finito il rollio mi trovo perpendicolare alla direzione di prima, con un assetto del tutto casuale, difficile da gestire.

L'altra cosa, la più importante forse, è che se dovessi girare di 90 gradi si potrebbe anche tentare, perché a quel punto sostituirei il pitch con lo yaw e proseguirei così. ma girando di 60° per determinare il nuovo "pitch" dovrei utilizzare una combinazione di pitch e yaw che è veramente complicatissimo da implementare. La scomposizione delle rotazioni sui vari assi, quando possibile semplifica enormemente le cose. infatti quasi tutti i sistemi di guida fanno prima rollio e poi pitch separatamente proprio perché la gestione delle 3 rotazioni combinate è difficile e "pericolosa" perché basta un piccolo errore per produrre un effetto disastroso.

tra l'altro per rendere il tutto comunque gestibile ho dovuto giocare molto con le posizioni dei motori del secondo stadio. infatti l'hes3 è "corto" fornendo pochissimo momento d'inerzia a contrastare l'imbardata. Questo fa sì che ho dovuto fittiziamente avvicinare i motori all'asse longitudinale, perché altrimenti appena se ne si spegneva uno il tutto partiva in una rotazione violenta veloce come una trottola. Nell'ottica delle failure del secondo stadio viste come partial e comunque di garantire anche un minimo di spettacolarità alla cosa (vedere lo stadio con 2 motori accesi ed uno spento e l'auotguida che corregge in automatico per trovare i nuovi assetti giusti secondo me è un bello show) ho giocato un pochino con la posizione delle spinte per rendere il tutto un po' più gestibile, mantenendo la veridicità.

comunque ho in mente un paio di idee per provare ad annullare l'imbardata, che non ho fatto in tempo ancora a provare. Ad esempio mi è venuto in mente che si può calcolare direttamente tramite l'interfaccia orbiter il momento torcente sui 3 assi del veicolo, se riuscissi ad impostare il sistema in modo che attivi l'rcs per annullare il momento torcente attorno all'asse y saremmo a posto... domani ci provo!

ultima cosa, si potrebbero impostare i messaggi che appaiono durante le varie fasi del conto alla rovescia e spiegano che succede, ad esempio "GO For Launch from Mission Control" e altro. però mi servirebbe la sequenza di avvenimenti completa.

Ho scritto di corsa, spero si capisca qualcosa!

Ciao ragazzi a presto!

sei stato chiarissimo come sempre!
secondo me la soluzione che proponi mediante l'uso degli RCS è la migliore!

Amici,

vi do un rapido aggiornamento, poi in serata finisco il lavoro con quanto suggerito da fausto (motivi di interruzione del countdown e suono dell'esplosione)

anzitutto ho risolto il problema dell'imbardata in caso di avaria. Mi ci sono un po' rotto la testa, però alla fine sono riuscito a ricreare un mini autopilota che tenesse l'orientamento allineato con il vettore velocità del veicolo.

Dopodiché ho aggiunto gli esausti all'RCS del secondo stadio, visto che c'ero, tanto è stato lavoro da poco.

La novità più importante secondo me è un'altra, una cosa su cui mi sono scervellato per un bel po' di tempo e che pare ora funzioni:  

il payload viene caricato tramite file scenario! bisogna aggiungere nello scenario (obbligatorio questo!) la voce ad esempio PAYLOAD_FILE JARVISs\DEFAULT.ini e il modulo va a prendersi il payload scelto.

Questa secondo me è una cosa mooolto importante, perché permette di salvarsi tutti i payload in tutti gli ini, e poi per caricarli basta scrivere nel file scenario il file prescelto. Si potrebbe addirittura fare un lancio di due jarvis con due payload diversi in contemporanea... 

soprattutto in vista della release, permetterebbe di preparare tutti gli scenari delle varie missioni già pronti, senza che gli utenti debbano andarsi a modificare a mano quello che prima era il file Jarvis-payload.  

comunque in serata vi posto tutto. Io poi la prossima settimana sono tutta la settimana fuori per lavoro, quindi beta-testing a manetta  

grandi notizie quindi! Sfrutteremo la settimana per beta testing allora!  

Beh che dire, un'ottima pensata la tua!! Inoltre l'autoguida intelligente che risolve l'avaria di un motore del secondo stadio è un assoluto tocco di classe.!
Attendo con ansia il nuovo file!

Entro stasera posto tutto.

Fausto riesci mica a passarmi la sequenza di avvenimenti della procedura di lancio? Cosi implemento anche i messaggi che confermano i vari avvenimenti, pensa se durante la diretta viene scritto che il controllo missione ha dato il Go e tu possa dire "abbiamo ora la conferma dal controllo missione" :-)))

Pronti:

Codice:

T - 12:00:00
Inizio conto alla rovescia
T  -11:30:00
Sgombero del personale non necessario
T -11:00:00
Preparazione dei sistemi del Pad-J-C
T -10:50:00
Controllo del tempo atmosferico
T -10:30:00
Sistemi di alimentazione attivati sul Pad-J-C
T -09:00:00
Sistemi Jarvis in sicurezza in attesa del carico dei combustibili
T- 08:40:00
Controllo dei sistemi del Jarvis
T -08:00:00
Inizio carico dell’ossigeno liquido sul secondo stadio
T -07:30:00
Inizio carico dell’RP-1 nel primo stadio
T -07:00:00
Inizio carico dell’idrogeno liquido sul primo e secondo stadio
T- 02:00:00 HOLDING (HOLD di 30 minuti)
Riunione finale per il GO-NO GO al lancio
T -01:30:00
Serbatoi del primo alla temperatura  di lancio
T -01:20:00
Serbatoi secondo stadio alla temperatura di lancio
T -00:40:00
Carico dei propellenti completato
T -00:35:00
Sistemi pneumatici dei motori principali al livello di volo
T -00:10:00
Controllo finale delle condizioni del tempo atmosferico
T -00:05:00
Inizio conto finale con sequenza automatica controllata dal computer
T - 00:03:00
Serbatoi alla pressione di volo
T - 00:02:00
Passaggio all’alimentazione interna del Jarvis
T -00:01:40
Sistemi di controllo del lancio attivati
T -00:00:50
Inizio richiamo bracci di alimentazione PAD-J-C
T -00:00:05
Accensione motori principali
T +00:00:00
Decollo

Questo è molto dettagliato. Si potrebbe far attivare una finestra ci che ci dica tutte queste cose quando accadono, attivabile tramite un tasto come quella del countdown.
C'è un ultima cosa che vorrei passarti, il codice della finestrella che dice altitudine (in km) e velocità (in m/s) del razzo ma non ce l'ho sotto mano quindi lo lasciamo per quando rientrerai!  

ottimo, grazie mille!

la finestrella si può fare, io pensavo però alla debug string, è molto più semplice e meno pesante per la simulazione. Oppure delle "screen annotations" tipo quella che appare all'inizio con i tasti da premere. Che dici?

Se siete d'accordo poi implementerei da T- un'ora e mezza in poi, dubito che apriremo mai la simulazione 12 ore prima del lancio...  e metterei il Go-no go a T-30 minuti, quando il carico propellenti è completato e quando i sistemi sono a livello di volo, che dite? così tra l'altro compare nella diretta che di solito è già aperta 30 minuti prima