Jarvis - versione dll

Un'altra cosa che si potrebbe inserire sono i razzetti di separazione (bulloni esplosivi) tra uno stadio e l'altro come accade attualmente per l'HES 5, ma soprattutto la fonte di luce locale corrispondente al bagliore degli scarichi! Ho anche pronto il codice, quindi il lavoro da parte tua sarebbe minimo per questo effetto!

EDIT Mi sa che i bulloni bulloni esplosivi li avevate già messi in lista scusate!

Andrew ha scritto:

Bisognerà anche fare in modo che la mesh appaia sempre, nel caso in cui non ci sia ogiva (ad esempio è il caso di Eridanus, che lanciamo con il vettore Quasar che però funzionerà nello stesso modo del Jarvis)

Allora la mia idea in generale è la seguente: se nel file scenario appare un certo parametro (dico io "PLD_MESH_VIS=1") allora viene visualizzata, altrimenti compare solo quando si aprono le ogive. In multistage mi pare funzioni così.

Sull'argomento veicoli manned però si apre un capitolo a parte e secondo me molto importante: secondo me la cosa migliore sarebbe che ad esempio per quanto riguarda Antares, non ci fosse solo la mesh, ma la vera navetta in cima al Jarvis, in modo da poter seguire il lancio dal virtual cockpit.

A quel punto come addon ci si avvicinerebbe molto secondo me al livello di AMSO.

Credo che per fare questo probabilmente basti utilizzare in maniera corretta (correggendo a dovere i pesi) degli attachment points, ma bisognerà studiarci con calma.

Per Eridanus bisognerebbe però ritoccare anche la DLL in quanto da qualche tentativo che ho fatto mi sono accorto che sotto una certa altitudine parte comunque il LES.

per gli altri punti:

Andrew: le coordinate vanno bene in entrambi i modi, forse mi viene più facile averle relative all'intero vettore.

Fausto: perfetto se mi passi il codice, anche perché con le luci ancora non so smanettare! :-)

fred18 ha scritto:

Sull'argomento veicoli manned però si apre un capitolo a parte e secondo me molto importante: secondo me la cosa migliore sarebbe che ad esempio per quanto riguarda Antares, non ci fosse solo la mesh, ma la vera navetta in cima al Jarvis, in modo da poter seguire il lancio dal virtual cockpit.

Sono d'accordo, però con un distinguo: sarebbe da fare in modo che si possa sì andare nel virtual cockpit, ma che la mesh della capsula nelle visuali esterne risulti comunque invisibile fino all'apertura del fairing, per i motivi di cui sopra. E che magari fino al distacco della capsula si usi la mesh semplificata che già usiamo con Multistage. Anche AMSO adotta una strategia simile: fino al distacco dal Saturn, l'Apollo usa una mesh semplificata (attraverso il finestrino si vede che l'interno è vuoto).

Poi vabbè bisognerebbe capire come far funzionare il LES di Antares ma son cose che si guarderanno con molta calma più avanti. Queste cmq sono tutte cose che ricadono secondo me più sull'addon Antares che su Jarvis.

Un altro effetto carino sarebbe il distacco delle ogive automatico quando si arriva ad una certa pressione, Loru di OF ha usato questo effetto su uno dei suoi razzi.

Per quanto riguarda Antares ed Eridanus io suggerisco invece un'altra via: integrare il lanciatore direttamente nella dll di queste ultime. Molto più pratico ed integrabile con le varie funzionalità (mi viene ad esempio in mente il famigerato timer di Antares, mai sincronizzato con il tempo di lancio)

Si, ci sto. A patto però di usare una dll con un nome diverso in modo da evitare sovrascritture pericolose. In questa dll si potrebbe inserire anche il LES pienamente funzionante.

A questo punto si potrebbe giungere a integrare direttamente nel vettore (o nel veicolo manned, a seconda dell'addon) anche il discorso delle failures, comprese quelle in volo con relativo abort e autodistruzione del vettore (range safety)... ma non vorrei correre troppo! Andiamo per step e vediamo di fare una dll con funzionalità base, che funzioni e sia stabile!

Fausto ha scritto:

Un altro effetto carino sarebbe il distacco delle ogive automatico quando si arriva ad una certa pressione, Loru di OF ha usato questo effetto su uno dei suoi razzi.

Al momento il distacco delle ogive avviene automaticamente quando si raggiungono i 125km di altitudine. Se preferite un'altitudine diversa oppure la pressione come parametro posso metterla senza problemi.

Sulla dll dedicata ed integrata era la mia idea di base e sicuramente è la cosa migliore, non la proponevo perché non sapevo se eravate d'accordo a condividere le sorgenti di antares, eridanus etc.

Comunque ci vorrà un po' ad integrare il tutto. Penso che la cosa migliore sia:

1) finire il jarvis-s (quasi ci siamo) con tutti i dettagli definiti
2) aggiungere il controllo della rampa
3) estendere a tutta la famiglia jarvis il lavoro fatto sull's e avere le dll di tutti
4) prendere antares e il jarvis ed unire le due cose in una dll dedicata con tutto ciò che richiede la situazione (LES, failures etc)
5) partire con il quasar
6) adattare eridanus

Per le sorgenti c++ del jarvis se mi spiegate come preferite averle ve le mando subito, unica richiesta è di lavorarci sempre uno alla volta perché se ci lavoriamo contemporaneamente in tanti poi non riusciamo più ad unire i nostri sforzi.

Ah beh, io non so programmare quindi per quanto mi riguarda non c'è pericolo!

Per quanto riguarda il quasar, prevedo una semplificazione. La versione 220 nella versione unmanned è da tempo inutilizzata, avendo come unico payload Eridanus (nella versione specifica manned del vettore), quindi penso che per il pacchetto base del Quasar si potrà anche fare a meno di codificarla e si eliminerà semplicemente.

E non dimentichiamoci del Neptune (nonché eventualmente del Peregrin)! Fred, ti sei infilato in un bel casino  

Andrew ha scritto:

E non dimentichiamoci del Neptune (nonché eventualmente del Peregrin)! Fred, ti sei infilato in un bel casino  

Ho già fatto opera di stalking su Fred tempo addietro  

Fred qui FOI passo... Fred... Abbiamo perso il contatto...    

Amici...

allora ecco l'ultimo aggiornamento del Jarvis-S, scaricabile al solito link di prima che ri-posto: LINK

le news sono:

- autoguida ancora ottimizzata come detto prima.
- La mesh del payload NON viene caricata, a meno che nel file ini del payload non si specifichi il parametro VISIBLE=1
- E' possibile caricare mesh di adattatori inserendo sempre nel file ini le righe ADAPTER_MESHNAME e ADAPTER_OFFSET. Attenzione che non ho provato questa cosa e non ho idea se funzioni al momento

dal file scenario si possono impostare:

- il limite di forza G inserendo la riga GLIMIT XX
- l'accelerazione verticale del "gravity turn" inserendo la riga GTVACC XX (di default la dll prende 6 perché la ottimale, ma in caso di necessità si può modificare inserendo appunto la riga)
- il countdown prima del lancio dal momento dell'attivazione dell'autopilota in poi parte di default da T-30 sec, ma si può modificare anche questo parametro inserendo la riga COUNTDOWN XX

ora c'è bisogno di un po' di "beta testing" per scoprire tutti i bug che ci sono!  attendo presto vostri feedback  

Da aggiungere:

- eventuale scia di condensa
- effetti di ullage, retro, bulloni esplosivi etc (già pronti, solo da inserire)
- effetto ghiaccio al lancio
- interazione con la rampa
- rifiniture finali (tipo il formato del launch report etc)

con le info posso finire il lavoro in un paio d'ore di lavoro!

fatemi sapere presto  

ah giusto, l'effetto ghiaccio al lancio l'avevo dimenticato! E si che nella versione multistage l'ho pure messo  

Cosa intendi per "launch report"?

Andrew ha scritto:

Cosa intendi per "launch report"?

Ogni volta che il programma di guida termina la procedura di lancio e comanda il cutoff dei motori genera in automatico un file launchreport.txt dove scrive l'ora del lancio, il tempo di missione al cutoff, il combustibile rimasto, i parametri target per apogeo, perigeo ed inclinazione ed i parametri effettivi raggiunti.

in questo file bisogna aggiungere i riferimenti a FOI al jarvis etc perchè per ora dice solo che è creato da fred18 etc  

Ah capisco! Interessante!
Se riesco a mettere le mani sulle mesh, tra stasera e domani ti passo le coordinate che ti devo!

Ho fatto una prova veloce. Due problemi:

1) l'accensione del secondo stadio avviene con troppo anticipo, per cui durante lo staging la mesh tende a urtare quella dello stadio precedente. Questo aspetto sarà aggiustato con tutte le features come bulloni esplosivi e quant'altro.

2) se mi trovo nel virtual cockpit al momento della separazione dei fairing, la simulazione mi va in crash.

No, anzi, EDIT: la simulazione mi va in crash in tutti i casi quando si separano i fairing. Premetto che sto appositamente testando il tutto sul PC della mia fidanzata che è tenuto in piedi con lo sputo (però ha Win 7)  

Aggiungo un punto 3): il riquadro bianco col timer in basso a sinistra funziona solo nella visuale interna.

per il punto 1 ho visto ma andrà a posto come dici giustamente tu non appena sarà messo a posto il resto.

per il punto 2 lo sospettavo perché sugli adattatori sono andato un po' veloce. ora non ho un pc decente a portata. se hai voglia fai una prova mettendo una mesh qualsiasi come adattatore per vedere se lo fa lo stesso :-)

il riquadro in basso è solo temporaneo, mi serviva per il debug, poi lo tolgo

OK ho ritentato velocemente: penso che il problema derivi dal fatto che non trova la mesh del payload, infatti se rimango dentro il VC la simulazione non va in crash. Ammetto di aver tralasciato le istruzioni della pagina precedente, forse devo rileggermele!

Sono quindi arrivato in orbita e come premettevi c'è del residuo di carburante: dovrò rivedere al ribasso il valore target di delta V che uso abitualmente nel mio foglio Excel per calcolare i pesi dei payloads! Farò qualche prova e poi darò un dato più adatto a questa nuova versione del Jarvis.
Intanto mi complimento per la precisione oserei dire CHIRURGICA dell'autoguida. Veramente eccezionale. Questi brevissimi test mi hanno convinto che siamo sulla strada giusta!

Ulteriori features grafiche: sul Jarvis S si potrebbe aggiungere un'altra cosa carina. Se guardi il razzo noti che alla fine del primo stadio, in corrispondenza dell'interstadio, ci sono due pod di colore metallico, uno di fronte e uno sul retro. Questi in teoria contengono i razzetti RCS che servono per indirizzare il razzo sul giusto heading di lancio. Sul Jarvis S sono necessari perché avendo un solo motore non può ruotare sul proprio asse come invece può fare un razzo bimotore semplicemente usando in modo differenziale i gimbal dei motori principali. Infatti sugli altri Jarvis, che sono a più motori, questi pod non ci sono.

Ovviamente su Multistage i pod sono solo li per far scena ma potremmo magari pensare di visualizzare i piccoli esausti degli RCS nel momento in cui il razzo ruota per indirizzarsi sul giusto azimuth, prima di iniziare il programma di pitch.

Così come si potrebbe pensare di rendere funzionanti gli RCS degli upper stages.

Allora, per i vari effetti:

BULLONI ESPLOSIVI
Su multistage li facevo partire 2 secondi dopo il burnout del primo stadio e la fiamma durava 2 secondi a sua volta.
Le coordinate sono:

Z = 36.412 (partendo dalla base del razzo), che corrispondono alla linea di separazione tra primo e secondo stadio.
Direi che si possano mettere quattro bulloni, a X=3,2 e X=-3,2 e a Y=3,2 e Y=-3,2.

Le altre coordinate adesso non riesco a dartele...

Provato, primissima cosa: ho notato che dopo aver inserito i dati di apogeo, perigeo e inclinazione, uscendo dalla simulazione e andando ad aprire il current state non ho trovato questi numeri salvati nel file scenario. E' necessario che ciò sia fatto perché nei futuri lanci simulati sarebbe snervante dover andare ad inserire tutto ogni volta che si apre la simulazione.
L'ideale sarebbe istruire il modulo così: se nessun dato è inserito dare la possibilità di inserirlo manualmente nella simulazione tramite tasto A(opzione peraltro comodissima) ma una volta che i parametri sono determinati, lasciarli così e salvarli / caricarli dal file scn. Se non sai come fare io ti posso dare una mano perché è questa pressapoco la situazione che capita quando Antares si stacca dal Jarvis.

Poi ti manderò un messaggio privato per spiegarti come impostare le fonti di luce locale (davvero una sciocchezza). insieme magari al codice che gestisce il padjcont al lancio con rampa dinamica,, qui il discorso è da organizzare bene.

Sono d'accordo con te per quanto riguarda la non sovrapposizione dei lavori sul C++. Anzi è meglio che sia tu a smanettare con il tuo codice, senza passarmelo per il momento. Ti fornirò le linee relative a diverse funzionalità che dovrai solo inserire nelle sezioni giuste per ottenere quel particolare effetto. Noi forniamo le note e tu componi la melodia. Mi pare che sia la strada più efficiente cosa ne dici?

Io concordo!

Stasera provvedo alle altre coordinate necessarie!

Per me va benissimo!  

allora breve update (in pausa caffè ho dato un'occhiata  )

- il problema del crash all'apertura del fairing ora dovrebbe essere risolto (era colpa dell'opzione sugli adattatori che non era fatta bene).

- stasera aggiungo:
1) valori target salvati e caricati anche da file scenario (se non c'è nulla nel file scenario carica quelli di default. Comunque premendo A si potranno modificare)

2) ullage e bulloni esplosivi (e retrofire per lo stadio sganciato)

3) ghiaccio

4) motori di rollio del primo stadio (non so ancora se riesco a fare anche gli rcs degli upper, devo prima verificare una cosa)

A questo punto correggetemi voi, ma mancheranno giusto i venting e l'interazione con le rampe per considerare il lavoro sull'S terminato!

Ammazza che bravi che siete!

Io aggiungerei tanti bei commenti nel file ini (ITA/ENG)!!
Ma si sa, la documentazione viene sempre alla fine.

Io sto alla finestra a guardare: per me C++ è arabo antico ...
Posso solo dire: bravi!

A-rieccomi...

al solito LINK trovate la versione aggiornata.

Ecco le modifiche effettuate:

- ghiaccio
- ullage e bulloni esplosivi del primo stadio (da vedere, ditemi se vi piace o cosa cambiereste)
- visibilità mesh payload ed eventuali adattatori messa a posto senza più crash (spero...)
- parametri di lancio salvati e ricaricati (in mancanza di dati nel file scenario carica quelli di default)
- autoguida "resumabile" se si ricarica la simulazione
- e per ultimo regalo per Andrew... guarda i pod in cima al core stage durante il programma di rollio (e volendo anche dopo se provi a rollare  )

Ora aggiungo i parametri di luminosità che mi ha passato fausto e inizio a lavorare alla rampa.

Vedo che ti sei ricavato da solo le coordinate che ti servivano! Bravo! Precisissime tra l'altro!
A me gli ullage sembrano perfetti! Forse ispessirei solo LEGGERMENTE gli ullage del secondo stadio, se non altro perché la prima volta che ho lanciato la simulazione non li ho neanche notati!

Però non vedo nessun bullone esplosivo! A dire il vero penso che i bulloni esplosivi e i retromotori del primo stadio si annullino un po' a vicenda, nel senso che non credo che servano entrambi. Però l'effetto dei bulloni esplosivi che avevamo implementato con multistage era molto spettacolare e mi spiacerebbe perderlo!

Nota 1) l'effetto ghiaccio va bene, forse lofarei leggermente più intenso, ma soprattutto non lo farei partire dalle ogive, ma lo farei solo più in basso, in corrispondenza dei due stadi (che sono quelli con superficie fredda perché contengono carburante)
Nota 2) metterei una certa rotazione nei fairing al momento del distacco... tipo apertura petali, non so se sono stato chiaro!

Comunque lavoro eccellente! Bravo!

Andrew ha scritto:

Vedo che ti sei ricavato da solo le coordinate che ti servivano! Bravo! Precisissime tra l'altro!

un po' per tentativi e un po' per calcoli  

Andrew ha scritto:

A me gli ullage sembrano perfetti! Forse ispessirei solo LEGGERMENTE gli ullage del secondo stadio, se non altro perché la prima volta che ho lanciato la simulazione non li ho neanche notati!

yes, hai ragione, procedo!

Andrew ha scritto:

Però non vedo nessun bullone esplosivo! Ecco forse se aggiungi i bulloni esplosivi, dovresti rendere gli ullage un po' più "potenti" affinché si vedano, oppure farli durare leggemente di più!

ecco qui volevo chiedere un attimo delucidazione, voi come effetto dei bulloni esplosivi intendete la fiammata rossastra che nella versione di multistage si vede poco prima dello staging? perché non l'ho messa ancora perché non volevo fare confusione. Se sì la aggiungo.

Andrew ha scritto:

Nota 1) l'effetto ghiaccio va bene, forse lofarei leggermente più intenso, ma soprattutto non lo farei partire dalle ogive, ma lo farei solo più in basso, in corrispondenza dei due stadi (che sono quelli con superficie fredda perché contengono carburante)

correttissimo, ho sbagliato le coordinate, perché c'è differenza tra i numeri di MS2 e la dll (devo ancora capire il perché...)

per l'intensità ho usato i numeri che sono nell'ini di MS2, se lo preferite diversamente ditemi pure, magari voi per queste rifiniture date un'occhiata con MS2 e poi io metto i numeri giusti sulla dll, che dite?

Andrew ha scritto:

Nota 2) metterei una certa rotazione nei fairing al momento del distacco... tipo apertura petali, non so se sono stato chiaro!

chiarissimo, è in programma, le ogive per ora usano ancora lo stage.dll, ma nel prossimo update avranno il loro moduletto dedicato che gli permetterà l'apertura come dici tu.

Andrew ha scritto:

Comunque lavoro eccellente! Bravo!

eheh grazie!  ma comunque a parte l'autoguida per cui sono veramente impazzito in questi mesi, per il resto è un lavoro di squadra