Jarvis - versione dll

Ciao Ragazzi,

buona sera a tutti!

Mi pare che i primi mesi del 2013 stiano determinando una grande attività di sviluppo qui su FOI, è troppo divertente seguire tutti i post con gli aggiornamenti

Sto finendo di scrivere il manualetto del plugin per le telecomunicazioni, ma intanto ho ripreso il progetto del Jarvis creato interamente in dll.

Il Jarvis S vola già, perfettamente, con particle stream, fumi, mesh colori etc. come la versione in multistage. Sto iniziando il lavoro dalla versione S perché è il più piccolino e probabilmente il più semplice.

Quindi a questo punto apro il thread per due motivi:

Il primo è chiedervi idee o richieste da implementare sul vettore, quindi sotto con i desiderata a tuttotondo

Il secondo motivo è una domanda per quanto riguarda l'autoguida: ho notato che la fortissima accelerazione nella parte finale dell'accensione del primo stadio mi fa purtroppo "sballare" un po' i parametri dell'autoguida, e dopo un buon numero di tentativi mi sono accorto che non sarà semplice trovare una soluzione (a parte quella di togliere un po' di gas ad un certo punto).

A parte il fatto che potete star certi che ci lavorerò ancora un po' prima di arrendermi, la domanda è: se non trovassi una soluzione preferireste togliere gas per ridurre l'accelerazione ed ottenere un inserimento diretto nell'orbita desiderata, oppure fare come fanno molti altri addon in cui si arriva al MECO solo in base all'apogeo e dopodiché si procede ad una seconda accensione un po' di tempo dopo per regolare il perigeo?

Spero di essermi spiegato!

ciao ciao

Fred

E' preferibile ridurre gradualmente la spinta una volta raggiunto un certo limite di fattore G, come del resto fanno i vettori reali. Indicativamente, direi che per le versioni unmanned si può spingere fino a 5 o 5,5 G prima di iniziare a togliere gradatamente gas.

La versione DLL del Jarvis sarà una bella implementazione; teniamoci in contatto perché essendo l'addon in cui sono più direttamente coinvolto, vorrei essere tenuto al corrente dei tuoi sviluppi e fornire tutto il supporto tecnico necessario!
Certo essendoci molte versioni di questo vettore, immagino che non sarà un lavoro da poco predisporle tutte, ma facciamo un po' alla volta!

Andrew ha scritto:

E' preferibile ridurre gradualmente la spinta una volta raggiunto un certo limite di fattore G, come del resto fanno i vettori reali. Indicativamente, direi che per le versioni unmanned si può spingere fino a 5 o 5,5 G prima di iniziare a togliere gradatamente gas.

Perfetto, nei prossimi giorni proverò con questi valori e ti/vi farò sapere

Andrew ha scritto:

La versione DLL del Jarvis sarà una bella implementazione; teniamoci in contatto perché essendo l'addon in cui sono più direttamente coinvolto, vorrei essere tenuto al corrente dei tuoi sviluppi e fornire tutto il supporto tecnico necessario!
Certo essendoci molte versioni di questo vettore, immagino che non sarà un lavoro da poco predisporle tutte, ma facciamo un po' alla volta!

ovvio, in questo caso io sono un mero "trasformatore", cioè prendo un vettore vostro e lo trasformo in dll, quindi poi tutte le richieste e le note devono essere vostre.

Sulle versioni ti dò piena ragione, una per volta con calma, sennò impazzisco

E alla fine siamo arrivati al grande momento dello sviluppo del Jarvis in dll

Eccolo qui che lo stavo aspettando

Grandiiiii!!!!!!!!!!!!

Mitici!Non vedo l'ora!!

Un suggerimento che mi viene in mente è ordinare lo sgancio automatico dei fairings quando la pressione dinamica è sotto un certo livello.

Il grande vantaggio di un'implementazione in DLL è dovuta alla semplificazione della configurazione e dell'eliminazione della necessità di avere un'autoguida dedicata per ogni missione. Una volta scelto il lanciatore si da all'utente la possibilità di scegliere tipo di fairings tra quelli disponibili, payload e suo peso, ed il gioco è fatto. Dato che si parte dell'inizio sarebbe addirittura possibile configurare il lanciatore direttamente dal file scenario, senza files config in giro per le cartelle e limitando ulteriormente perdite di tempo e complicanze.

Una prospettiva allettante! Sarebbe una pacchia organizzare una missione su OLM con queste funzionalità

Ah e finalmente si potrebbe implementare un virtual cockpit per le missioni abitate già al lancio!

Rispondo per punti:

Fausto ha scritto:

Un suggerimento che mi viene in mente è ordinare lo sgancio automatico dei fairings quando la pressione dinamica è sotto un certo livello.

Questo è semplicissimo, ora avviene in base all'altitudine, ma scegliere la pressione dinamica è facilissimo.

Fausto ha scritto:

Il grande vantaggio di un'implementazione in DLL è dovuta alla semplificazione della configurazione e dell'eliminazione della necessità di avere un'autoguida dedicata per ogni missione. Una volta scelto il lanciatore si da all'utente la possibilità di scegliere tipo di fairings tra quelli disponibili, payload e suo peso, ed il gioco è fatto. Dato che si parte dell'inizio sarebbe addirittura possibile configurare il lanciatore direttamente dal file scenario, senza files config in giro per le cartelle e limitando ulteriormente perdite di tempo e complicanze.

Mi sembrano ottime idee!! per ora si configura il payload tramite un file separato dedicato solo al payload (ovviamente per ora funziona come l'ELIS). Si potrebbe pensare anche ad un configuratore, ma ci vorrà un po' di tempo per quello. E la prima cosa da mettere a posto è sicuramente l'auotguida con inserziona in orbita diretta. Detto chiaramente se usassimo l'opzione delle due accensioni separate potrei mandarvi il jarvis S domani, e' già quasi fatto. Con l'inserzione in orbita diretta è invece molto più complicato e ci devo lavorare ancora un po'.

Fausto ha scritto:

Ah e finalmente si potrebbe implementare un virtual cockpit per le missioni abitate già al lancio!

Per Antares si potrà finalmente fare il lancio da dentro il cockpit!

quella della configurazione dal file scenario è una cosa interessante, semplificherebbe le cose anche se alla fin fine con multistage non è poi così complicato, alla fine si hanno due files anziché uno. La cosa davvero essenziale è secondo me eliminare il file autoguida e sostituirlo con una vera autoguida adattiva a seconda del payload. Quindi credo che gli sforzi dovrebbero andare soprattutto in quella direzione.

Il discorso del fairing invece non lo vedo così essenziale; secondo me va benissimo farlo distaccare a una quota prestabilita o, come adesso, a un tempo T prestabilito dopo il liftoff.
Più interessante invece stabilire l'apparizione del max Q al momento di massima pressione dinamica, anziché a un momento prestabilito a priori come accade ora. Ciò significherebbe che il max Q apparirebbe in momenti diversi a seconda del peso del veicolo, o potrebbe anche addirittura non apparire affatto se la pressione dinamica non sale oltre un certo livello.


Una cosa che invece semplificherei (probabilmente non sarete d'accordo) sarebbe di togliere le varie voci di commento, che sono carine ma alla lunga stufano. E poi nelle Live Missions il commento è fatto da Fausto e Vittorio

P.S.
un configuratore per la selezione del payload dentro la simulazione sarebbe fichissimo, ma credo non essenziale almeno all'inizio.

Andrew ha scritto:

Più interessante invece stabilire l'apparizione del max Q al momento di massima pressione dinamica, anziché a un momento prestabilito a priori come accade ora. Ciò significherebbe che il max Q apparirebbe in momenti diversi a seconda del peso del veicolo, o potrebbe anche addirittura non apparire affatto se la pressione dinamica non sale oltre un certo livello.

Ecco, al riguardo ho una domanda per tutti voi:

Nelle varie dirette di OLM, nell'usare i vostri addon etc, ho sempre notato che la famosa nuvola di vapore bianco appare al momento del MaxQ.

Da quello che ne so io invece è la nuvola generata dalla condensa che si crea al momento del superamento del muro del suono, quindi al passaggio di Mach1 (che generalmente avviene un po' prima del MaxQ). Questo perché le onde d'urto dovute al passaggio a moto supersonico fanno variare bruscamente la pressione atmosferica, facendone condensare l'umidità e creando quindi la nube.

ho cercato un po' online e ad esempio ho trovato questo su wikipedia:

http://en.wikipedia.org/wiki/Vapor_cone

dove si dice testualmente: "A vapor cone is typically observed as an aircraft, or object, approaches transonic velocity"

quindi a mio modesto avviso sarebbe da impostare la creazione della nuvola di vapore al passaggio di Mach1 e non di MaxQ, che ne dite?

Il fatto è che vista l'accelerazione in gioco, il momento di massima pressione dinamica arriva si prima di Mach 1, ma diciamo appena prima... diciamo che è sufficiente mettersi d'accordo; non penso che il realismo ne risentirebbe in nessun caso. Secondo me quindi va benissimo impostarlo al passaggio di mach 1, credo sia anche più comodo da implementare (ma magari no).

Andrew ha scritto:

Secondo me quindi va benissimo impostarlo al passaggio di mach 1, credo sia anche più comodo da implementare (ma magari no).

yes, molto più facile! Perché ad orbiter si può "chiedere" direttamente il numero di mach. Quindi basta far comparire la nuvola ad esempio tra mach 0,95 e 1,05 o qualcosa di simile! Grazie per la risposta immediata

Prego, figurati!
Sono d'accordo con la tua soluzione!

fred18 ha scritto:

...

Fausto ha scritto:

Ah e finalmente si potrebbe implementare un virtual cockpit per le missioni abitate già al lancio!

Per Antares si potrà finalmente fare il lancio da dentro il cockpit!

Andrew ha scritto:

...
Una cosa che invece semplificherei (probabilmente non sarete d'accordo) sarebbe di togliere le varie voci di commento, che sono carine ma alla lunga stufano. E poi nelle Live Missions il commento è fatto da Fausto e Vittorio

Però almeno non togliamo il countdown. Ti ricordo, inoltre, che le voci sono per chi se la simula a casa e non ascoltando le dirette ...

Sisi, certo. Però, parere personale, dopo un po' vengono a noia. Si può certo tenere il countdown, quello si... vabbè questo è un aspetto secondario, vedremo.

Altra cosa che mi viene in mente ora è la possibilità dell'utente di scegliere di un adattatore personalizzato e la sua posizione.

Si, diciamo che nel file scenario ci andrebbero due voci, anzi tre:
- selezione payload
- selezione fairing
- selezione adattatore

Per una massima praticità dovrebbe essere possibile che almeno il fairing e l'adattatore siano posizionati automaticamente nelle corrette coordinate, come già adesso sduccede nella versione multistage.

queste features secondo me sono già sufficienti, insieme all'autoguida, a creare un Jarvis dll completamente flessibile!

Però l'adattatore è come un payload secondario e quindi dato che ce ne possono essere infiniti anche scelti dall'utente secondo me è meglio dare facoltà di scegliere la posizione. Per quanto riguarda le ogive sono d'accordo per il posizionamento automatico!

La mia idea è la seguente:

visto che il payload al momento è gestito da un file ini a parte, del tutto simile a quelli di spacecraft e multistage, aggiungerei a quel file la parte dell'adattatore, come se fosse un payload, con la sua mesh, il suo peso e la sua posizione da specificare.

per le ogive in che senso intendete il posizionamento automatico? io me lo immagino così: nel file scenario si potrà specificare se le ogive saranno di tipo A oppure B ad esempio. Se non specificato nulla verrà utilizzato il tipo A, se invece specificato allora verranno utilizzate quelle specifiche. Comunque andrà specificato solo e soltanto il tipo, perché posizione, orientamento o altro saranno automatici.

posizionamento automatico nel senso che, a seconda dell'ogiva scelta, dovrebbe essere posizionata nel modo giusto senza che si debbano indicare a mano le coordinate. Proprio come dici tu nell'ultima frase: "Comunque andrà specificato solo e soltanto il tipo, perché posizione, orientamento o altro saranno automatici." Ci hai già pensato tu.

Praticamente hai usato il sistema che ho imbastito io sul file ini nella versione multistage.

Amici...

pare e dico pare che una soluzione definitiva per l'autoguida sia in vista... il Jarvis-S sta rispondendo bene ai vari tentativi con dati diversi, e una volta finita l'auotguida si passerà al resto, dove spero, si potrà andare "a razzo" ( ) visto che le cose da implementare sono abbastanza semplici.

appena posso metto in chiaro l'autoguida (per ora è un groviglio di if, che vorrei mettere a posto con tante funzioncine che assomiglino ai programmi stile apollo P01-P02... etc ) e poi proseguo con lo sviluppo.

Purtroppo sono in partenza per un viaggio di lavoro un bel po' lunghetto che mi terrà fuori portata per tutta la prossima settimana (torno sabato prox), ma appena tornerò prometto di chiudere la questione autoguida entro pochissimi giorni e di iniziare a mandarvi i primi risultati!

Intanto vi butto lì giusto due cose, la prima abbastanza normale, la seconda un po' più "rivoluzionaria".

La prima è che tutti gli effetti che ora sono del Jarvis ma "agganciati" alle rampe di lancio (sfiati etc) io li passerei direttamente dentro la dll del Jarvis. Secondo me è molto realistico se è il razzo stesso ad emettere gli sfiati ad esempio. E' solo una nota tecnica su cui mi devo allineare soprattutto con fausto, ma penso che siamo tutti d'accordo. E' anche più facile evitare errori di realismo così.

La seconda è la seguente, su cui sto iniziando a riflettere e non ho ancora capito se e come è fattibile ma intanto butto lì l'idea: noi stiamo cercando di creare addon realistici al massimo esatto? e un fattore del realismo (e del divertimento) sono anche le procedure, i controlli etc.

Quindi se provassimo ad implementare un Jarvis che arriva sulla rampa senza combustibile e lì con le apposite procedure si riempie di combustibile, si pressurizzano i serbatoi, si controlla che i valori siano tutti entro i parametri, si dà il go per il lancio e poi si parte?

ovviamente si fornirebbero agli utenti le due opzioni, quella normale (x ki non ha voglia di farsi tutta la procedura ma vuole partire immediatamente) e quella completa, un po' come in flight simulator quando con alcuni aerei si può scegliere di partire da "cold and dark" e bisogna accendere tutto, o come in space shuttle ultra, dove se non si legge un po' il manuale non si riesce neppure ad accendere le luci e rimane tutto spento.

che ne dite? io ci penserò su nelle lunghe ore di vole che mi attendono

ciao ciao

Fred

Io concordo su tutto! Soprattutto sulla possibilità di scegliere le due procedure di lancio.
Un consiglilo/quesito: se queste implementazioni sono molto complesse, pensaci! Perché poi dovrai farle anche per gli altri razzi della famiglia (Quasar, Neptune e quant'altro)

Assolutamente d'accordo per le due possibilità di scelta tra cold start e hot start.