Antares 3.0 [sviluppo]

Per quanto mi riguarda è praticamente pronto, possiamo comunque aspettare fino a settembre per la release in modo da testarla per bene durante quelle missioni!

Questa opzione mi trova favorevole, anche perché a dirla tutta dobbiamo ancora integrare l'Antares LR col nuovo Jarvis M, procedura magari banale a livello di dll, ma che ancora ci manca. Il primo test del nuovo stack sarà proprio in occasione di quella missione. tongue 2

Fausto hai un PM.

Fausto hai visto questo messaggio su Orbiter Forum? C'è chi sarebbe interessato al modello (non so se codice o solo modello matematico) del boil off per usarlo su una sua creazione.

Grazie della segnalazione, fornirò una risposta! Thumb Up 2

Sto guardando l'attracco alla ISS in diretta, ed ho notato la scritta "per cent" sullo HUD, a proposito della carica della batteria.

Posso dire che scritto in quel modo mi pare sbagliato?
Io toglierei quello spazio, o userei il simbolo (che mi sembra pure meglio).

Fonti inglesi dicono che si può anche usare, ma a occhio, quello spazio mi pare così brutto...
In USA si preferisce una sola parola, in UK due.

http://oxforddictionaries.com/us/definition/american_english/percent
http://public.wsu.edu/~brians/errors/percent1.html
http://forum.wordreference.com/showthread.php?t=1028955&langid=14

Inizialmente avrei voluto usare il simbolo percentuale ma chissà perché non me lo visualizza.. quindi ho optato per la soluzione più semplice. Magari lo unirò non appena metterò mano al codice un'altra volta!

Grazie per la segnalazione comunque!

Non so come hai scritto il codice ma per visualizzare il simbolo della percentuale va scritto due volte di fila

Finalmente oggi ho finito di sistemare la documentazione in inglese ed in italiano, un altro piccolo passo verso il rilascio. Alla fine la compatibilità con d3d9 non è completa al 100 per cento, ma ciò non compromette affatto l'utilizzo. Pensavo di rilasciare prima della missione lunare simulata, voi che ne dite?

Non so.
La cosa che mi turba è che negli scenari lunari Antares rimane vincolato al vecchio razzo vettore: allo stato attuale non c'è neanche uno straccio di scenario che usi il lanciatore che effettivamente useremo per la missione di Settembre e da li in avanti per tutte le successive. Per questo proponevo di posticipare...
Oltretutto per adattare Antares al nuovo Jarvis M va corretto il timer di bordo, che altrimenti resterebbe sballato (seppur per poche decine di secondi) in quanto le tempistiche di distacco del HES-5 (e quindi di attivazione del modulo) sono state modificate.

Si, posticipare non è un problema.. ci vorrebbero anche ulteriori test effettivamente! Per ora quindi rimaniamo in stand by per quanto riguarda il rilascio, tanto c'è ancora agosto di mezzo

Posto qui l'avviso che la nuova versione di Antares 3.0 (build 20161021) è in condivisione su Dropbox. Per chi avesse problemi ad accedervi o vuole provare la nuova versione aggiornata con tutte le novità me lo dica che gli fornisco il link. Per le novità consultare il manuale (non ancora in PDF ma provvederemo)
Non è sistemato al 100 per 100 ma al 99 si.. manca lo scenario (o gli scenari) nuovi ma questi saranno aggiunti nei giorni a venire.

Fausto,
ho visto il suggerimento su OF rispetto a Multistage2, per la release definitiva ti consiglierei di mettere direttamente Multistage2015 negli scenari di lancio (basta aggiungere "015"), così da evitare sorprese o gente che fa confusione.

Poi manda il link anche a me che voglio proprio fare un giro con Antares happy face

fred18 ha scritto:: Fausto,
ho visto il suggerimento su OF rispetto a Multistage2, per la release definitiva ti consiglierei di mettere direttamente Multistage2015 negli scenari di lancio (basta aggiungere "015"), così da evitare sorprese o gente che fa confusione.

Poi manda il link anche a me che voglio proprio fare un giro con Antares

Si, in realtà ho impostato questa procedura macchinosa perché ero sicuro funzionasse.. quindi mi assicuri che aggiungendo quel 015 a tutti gli scenari non dovrebbero esserci sorprese o CTD all'avvio della simulazione?

Ti mando subito il link su tramite PM happy face

Fausto ha scritto:: quindi mi assicuri che aggiungendo quel 015 a tutti gli scenari non dovrebbero esserci sorprese o CTD all'avvio della simulazione?

Beh proviamo, ma non credo proprio: se rinomini tutto il 2015 con 2 e funziona, se lo chiami direttamente 2015 dovrebbe funzionare senza problemi happy face

Scusa fausto, ti scrivo qui per non generare confusione su OF. non ho ancora provato Antares ma su OF mi pare di capire che c'è un problema in cui in pratica è come se rimanesse un motore sempre leggermente acceso. Dall'altra ho letto anche che usando il motore di Hover per garantire il suono questo però poi non si spegne. Sei sicuro che le due cose non siano collegate? non ho ancora provato e quindi potrebbe essere una cavolata!

fred18 ha scritto:: Scusa fausto, ti scrivo qui per non generare confusione su OF. non ho ancora provato Antares ma su OF mi pare di capire che c'è un problema in cui in pratica è come se rimanesse un motore sempre leggermente acceso. Dall'altra ho letto anche che usando il motore di Hover per garantire il suono questo però poi non si spegne. Sei sicuro che le due cose non siano collegate? non ho ancora provato e quindi potrebbe essere una cavolata!

Il problema del motore acceso (che poi è un motore fantasma con spinta praticamente nulla) è risolto. Il problema che non capisco riguarda un certo scenario (ALR-1, quello di lancio) che dopo l'arrivo in orbita e la separazione della capsula, passati alcuni secondi l'orbita inizia ad aumentare in modo costante senza che nessun motore sia acceso. E non aumenta di poco! Praticamente la terra schizza via con un'accelerazione ben superiore alle capacità di LR.. ma se vado su altri scenari, dopo il lancio non succede assolutamente nulla e tutto va perfettamente... non capisco questa cosa! confused 2

Poi alcuni hanno problemi al rientro, sembra che gli effetti dello scudo termico facciano effetti strani.. a me su O2016 funziona bene, mi segnalano che addirittura su O2010 l'intera capsula sparisce appena inizia il rientro...

per l'ALR1 ci guardo anch'io vediamo se trovo qualcosa di utile.

Per O2010 ti sconsiglio di usare la stessa dll per le due versioni, ma di compilarne una per O2016 e una per O2010 con le librerie diverse altrimenti ci possono essere un sacco di problemi.

fred18 ha scritto:: per l'ALR1 ci guardo anch'io vediamo se trovo qualcosa di utile.

Per O2010 ti sconsiglio di usare la stessa dll per le due versioni, ma di compilarne una per O2016 e una per O2010 con le librerie diverse altrimenti ci possono essere un sacco di problemi.

Un buon consiglio, ne terrò conto!

Ho dovuto scaricare di nuovo O2010 con relativi add-on, stasera proverò ad effettuare le compilazioni separate.

Nel frattempo ho provveduto a cambiare tutto in Multistage2015 nei file scn e funziona bene senza problemi (meno male che avevo già ripulito gli scenari) mentre continuo a sospettare che l'instabilità dell'orbita sia dovuta al contatore GET.. infatti quando lo spengo non accade.. per ovviare pensavo di rubare un altra "skill" di fred: ho notato che intelligentemente l'orientamento dei pannelli solari viene aggiornato meno spesso quando l'accelerazione della simulazione è aumetata.. potrei utilizzare questo stratagemma per far aggiornare il contatore che ne so, magari ogni 0,8 secondi a velocità normale, e moltiplicarlo di un fattore di dieci ad ogni aumento della velocità della simulazione. E' inutile farlo lavorare di più dato che non vengono visualizzati i millesimi di secondo.... vediamo se funziona..

altra cosa che voglio fare è aggiungere l'effetto camshake, ho visto che c'è il codice sorgente a disposizione e siccome durante il lancio il tremolio non funziona, volevo provare ad inserirlo direttamente in Antares (se non è troppo complicato ma non credo)

Domanda: come si faceva a visualizzare il numero di FPS?

Per variare l'aggiornamento a seconda dell'accelerazione della simulazione ti consiglio di decidere quale sia la frequenza di aggiornamento (o meglio l'intervallo tra gli aggiornamenti) ad accelerazione 1, poi dividerlo per l'accelerazione (con oapiGetTimeAcceleration() o come si chiamava). In pratica ti ritrovi con la stessa frequenza nel tempo reale ma molto meno pesante per la simulazione e se fai cosi non devi scrivere mille "if" per ogni possibile accelerazione della sim. Nel caso ti servisse ti mando qualche riga di codice, no problem.

Cmq stranissimo che per un display si alteri tutto cosi, se vuoi passami il codice del display che provo a capire anch'io.

Per visualizzare gli fps in o2010 era tasto F di default, in o2016 tasto destro sulla barra in alto al centro e ti fa scegliere tutto quello che vuoi visualizzare!

fred18 ha scritto:: Per variare l'aggiornamento a seconda dell'accelerazione della simulazione ti consiglio di decidere quale sia la frequenza di aggiornamento (o meglio l'intervallo tra gli aggiornamenti) ad accelerazione 1, poi dividerlo per l'accelerazione (con oapiGetTimeAcceleration() o come si chiamava). In pratica ti ritrovi con la stessa frequenza nel tempo reale ma molto meno pesante per la simulazione e se fai cosi non devi scrivere mille "if" per ogni possibile accelerazione della sim. Nel caso ti servisse ti mando qualche riga di codice, no problem.

Cmq stranissimo che per un display si alteri tutto cosi, se vuoi passami il codice del display che provo a capire anch'io.

Per visualizzare gli fps in o2010 era tasto F di default, in o2016 tasto destro sulla barra in alto al centro e ti fa scegliere tutto quello che vuoi visualizzare!

Ok, prima di tutto ho diviso le compilazioni e ho capito perché la capsula non funzionava in O2010: utilizzavo una funzione nuova non esistente nella precedente versione.

Per il timer seguirò il tuo consiglio. Appena posso ti passo il codice così ci dai un'occhiata.

Grazie per la dritta sui tasti Thumb Up 2

Allora il codice per il Get è il seguente:

Codice:: //GET

int TmpCLKHR;

   int TmpCLKMNT;

   int TmpCLKsec;

   int Curdigit;

   int Curdigit2;

if(O2time>=0){ TmpCLKHR = O2time/3600;

   TmpCLKMNT = ((O2time-(TmpCLKHR*3600))/60);

   TmpCLKsec = ((O2time-((TmpCLKHR*3600)+TmpCLKMNT*60)));

}

else if(O2time<0){TmpCLKHR = ((O2time*-1)/3600);

   TmpCLKMNT = ((O2time*-1-(TmpCLKHR*3600))/60);

   TmpCLKsec = ((O2time*-1-((TmpCLKHR*3600)+TmpCLKMNT*60)));}

   // Hour display on three digit

   Curdigit=TmpCLKHR/100;

   Curdigit2=TmpCLKHR/1000;

   oapiBlt(tex1,srf,8,30, 30*(Curdigit-(Curdigit2*10)),0,30,50);

   Curdigit=TmpCLKHR/10;

   Curdigit2=TmpCLKHR/100;

   oapiBlt(tex1,srf,8+30,30, 30*(Curdigit-(Curdigit2*10)),0,30,50);

   Curdigit=TmpCLKHR;

   Curdigit2=TmpCLKHR/10;

   oapiBlt(tex1,srf,8+60,30, 30*(Curdigit-(Curdigit2*10)),0,30,50);

   //oapiBlt(tex1,srf,8+95,0, 356,0,35,128);

   // Minute display on five digit

   Curdigit=TmpCLKMNT/10;

   Curdigit2=TmpCLKMNT/100;

   oapiBlt(tex1,srf,8+105,30, 30*(Curdigit-(Curdigit2*10)),0,30,50);

   Curdigit=TmpCLKMNT;

   Curdigit2=TmpCLKMNT/10;

   oapiBlt(tex1,srf,8+135,30, 30*(Curdigit-(Curdigit2*10)),0,30,50);

   //oapiBlt(tex1,srf,8+168,0, 356,0,35,128);

   // second display on five digit

   Curdigit=TmpCLKsec/10;

   Curdigit2=TmpCLKsec/100;

   oapiBlt(tex1,srf,8+180,30, 30*(Curdigit-(Curdigit2*10)),0,30,50);

   Curdigit=TmpCLKsec;

   Curdigit2=TmpCLKsec/10;

   oapiBlt(tex1,srf,8+210,30, 30*(Curdigit-(Curdigit2*10)),0,30,50);

}

else if (status_timer==DOOR_CLOSED||!oapiCameraInternal()) oapiColourFill(tex1,(oapiGetColour(160,0,0)),0,0,256,256);

Stamattina il cervello è un pigro.. come si dovrebbe implementare il suggerimento riguardo la frequenza di aggiornamento a cui accennavi? Scemo

allora non mi è chiarissimo il sistema che usi, ma se vuoi che tutto ciò che è scritto sopra venga fatto una volta ogni tot io farei così:

1) variable di classe da dichiarare nell'header

Codice:: double updateGET_dt;

2) definizione dell'intervallo di aggiornamento, ad esempio 1 secondo, sopra alla classe, all'inizio dell'header

Codice:: #define UPDATEGET_INTERVAL 1

3) nel cpp inizializzazione della variabile updateGET_dt, non so dove inizializzi tu le variabili, si può fare nel costruttore della classe ad esempio (importante è sicuramente non farlo in pre o poststep!)

Codice:: updateGET_dt=0;

4) in pre o poststep a seconda di cosa usi fai crescere la variabile del punto sopra

Codice:: clbkPreStep....
{
updateGET_dt+=oapiGetSimStep();
}

5) tutto il codice del GET lo racchiudi qui dentro:

Codice:: if(updateGET_dt>(UPDATEGET_INTERVAL*oapiGetTimeAcceleration()))
{
update_GET_dt=0;

...FUNZIONE GET...
}

dovrebbe fuzionare, l'ho scritto qui direttamente e molto rapidamente, fammi sapere che se non va ci riguardo con calma

Grazie Fred, proverò presto!

Intanto ho aggiunto l'effetto vibrazione al lancio: CamShake non funziona con vascelli uniti tramite attachment, ma non volevo perdere quell'effetto quindi mi sono arrangiato.. credo che lo aggiungerò anche per il rientro e per gli altri thrustres, in modo da averlo già incluso senza dover scaricare l'addon Thumb Up 2

» Sviluppo satellite
» Jarvis HLV - sviluppo
» Antares 3.0