Modulo TG

E' un piacere ragazzi!

Domanda per gli utenti... la questione poi è sempre quella: realismo o non realismo...

Ho impostato i consumi del TG in maniera realistica cercandomi i dati su internet (quanti kg di ossigeno consuma un astronauta ogni giorno secondo la nasa, quanto cibo etc).

Solo che se si riempie la stiva di scorte come ho fatto con la missione di prova l'autonomia secondo me diventa troppa visto che i pacchetti di cibo sono da 1000kg... c'è il rischio che diventi noioso usare il modulo se non c'è mai da andare a rifornirlo. Stavo pensando implementare almeno un paio di cose: creazione di carichi di spazzatura oltre all'acqua, da lasciare alle missioni di resupply (e quindi necessità di avere degli slot vuoti in stiva per non disperderla in orbita) e poi i famosi carichi di missione... tipo esperimenti da "consumare"...
oppure molto molto molto più semplicemente, cambiare i numeri dei consumi, in modo che le scorte finiscano molto prima!

io sono sempre dalla parte del realismo (e poi a pancia e polmoni pieni...si riesce a pensare meglio..)

qualsiasi missione periodica per "ritiro spazzatura", manutenzione, sostituzione personale, guasti, riparazioni o esperimenti magari da assemblare in orbita....sono i benvenuti!

In effetti sono d'accordissimo con te.

Facciamo che mi invento dei piccoli moduli per esperimenti da far fare agli astronauti. Potrei inventarmi un minisatellite spia utilizzando ciò che ho imparato con l'MT4 con durata limitata, un carico di piccoli cubesat e un qualche altro esperimento.

Sarebbero moduli molto più piccoli e semplici da fare, non dovrebbero richiedere troppo tempo... poi sono aperto a idee e suggerimenti come sempre!

Ecco, una domanda: supponiamo che sia in uno scenario già iniziato e abbia bisogno di rifornimenti. Non volendo andare a prendermeli dalla ISS che magari è chissà dove e forse ha bisogno dei moduli per le sue necessità. Ci sarebbe la possibilità di far decollare un DGIV (che ha anche il docking automatico -c'è il trasponder sul TG?-) con i carichi da portare in orbita?
Magari potrebbe essere uno scenario aggiuntivo, con il DGIV che viene fatto arrivare al TG e poi di nuovo a terra dove si rifornisce automaticamente per la prossima missione. Ovviamente in quella fase si controllerebbe il DGIV. 11.04.2014

Allora per le missioni di resupply ci sono due modi molto semplici:

- utilizzare lo scenario editor per caricare a a terra la nave preferita per il resupply (DGIV, Shuttle PB, o quel che è)
oppure con le navi più "esigenti" dal punto di vista del setup dello scenario come il Jarvis, il Quasar con Eridanus o altro si fa così:
- si prepara il file scenario della nave che deve effettuare il rifornimento, con solo la nave che deve decollare
una volta messo a punto
- si apre il file scenario __Realtime (o quello che preferiamo per lui) e si incollano le righe relative al nuovo vascello.

Intanto il nostro TG continuerà ad orbitare, non si ferma mai   

comunque ho intenzione di preparare una guida dettagliata su come fare queste operazioni.
Intanto ho aggiornato il modulo da scaricare con le luci di docking (attivabili con CTRL+L) e la documentazione ufficiale.

Devo ancora aggiungere il transponder e la frequenza radio al TG, cosa che farò in questi giorni, preparare quei carichi speciali di cubesat etc che dicevo ieri, e preparare le ultime due guide: piano di volo della missione di test (tipo quello che ho già fatto in italiano, ma devo tradurlo), istruzioni dettagliate su come effettuare un rifornimento.

Pensi che sarebbe utile una funzione di auto docking? Da usare prevalentemente con la ISS, anche perchè al primo lancio non ci sarebbe nessuno a pilotarlo (se non da terra).

Un'altra cosa: credo possa tornare utile implementare la funzione di retrorazzi utilizzando l'RCS lineare direttamente col tasto "meno" del tastierino numerico senza dover passare dalla funzionalità rotazionale a quella traslazionale. Praticamente come si fa col delta glider (che però ha dei retrorazzi dedicati). La funzione di shortcut dei razzi frenanti potrebbe essere utile durante dei docking manuali. Io te la butto là poi vedi tu se può essere il caso di fare sta roba o no!

apollo17 ha scritto:

Pensi che sarebbe utile una funzione di auto docking? Da usare prevalentemente con la ISS, anche perchè al primo lancio non ci sarebbe nessuno a pilotarlo (se non da terra).

in assoluto sì, però di fatto esistono già degli mfd che effettuano l'autodocking in maniera egregia(io uso di solito il pursuit MFD che funziona davvero bene al riguardo). Il fatto è che per preparare una funzione autodocking, tararla etc. ci vuole un bel po' di lavoro, che non credo sarebbe ripagato dal vero apprezzamento degli utenti: il DGIV ce l'ha e su OF un sacco di gente si lamenta che è "troppo automatizzato" o cose simili... Preferirei lasciare quindi la possibilità di usare MFD vari o di fare le cose a mano e stop.

apollo17 ha scritto:

Un'altra cosa: credo possa tornare utile implementare la funzione di retrorazzi utilizzando l'RCS lineare direttamente col tasto "meno" del tastierino numerico senza dover passare dalla funzionalità rotazionale a quella traslazionale. Praticamente come si fa col delta glider (che però ha dei retrorazzi dedicati). La funzione di shortcut dei razzi frenanti potrebbe essere utile durante dei docking manuali. Io te la butto là poi vedi tu se può essere il caso di fare sta roba o no!

questa è molto più semplice, volendo si può fare anche l'hover. Basta "registrare" i motori RCS indietro anche come retrorazzi e quelli in alto anche come hover.

io non li uso mai, ma se può essere utile lo faccio, ci vuole molto poco.

Guarda, mi sono appena scaricato il pursuitMFD. L'attracco l'ho fatto a mano (col tastierino perchè non avevo voglia di metter su il joystick) e dover controllare 6 direzioni contemporaneamente è un bel lavoro (anche perchè di solito sbaglio un tasto e capita di tutto)!

oki vediamo di lavorarci:

col pursuit mfd di solito faccio così (riassunto veloce per utilizzo rapido).

quando sono abbastanza vicino (e abbastanza lento relativamente, diciamo che mi porto sotto i 10 m/s)

accendo il pursuit, modo docking, tdk (target dock) quello che è, UDK (user dock) di solito 1 col TG.
poi DIS e metto 0 0 50 e poi schiaccio APD. Quando sono allineato e a 50 metri schiaccio DIS e metto 0 0 -0.3 e tack attracca che è una bellezza!

noooooo...non vale!  

il docking non è bello...se non è manuarello!    

intanto piccola nota: in ufficio al venerdi pome non c'è più nessuno e mi sono messo a smanettare un po' come al solito, sono riuscito a cambiare dinamicamente le proprietà del materiale delle mesh, quindi in pratica si possono accendere e spegnere le luci interne (che prima erano sempre brillanti da occhiali da sole...)

EDIT:

per capirci:

Molto bene. Il famoso scenario realtime. Come funziona? Mi sembra che sia collegato ad un quicksave che ho effettuato...

funziona così:

se l'opzione realtime è attivata -> ogni volta che orbiter salva lo scenario (quindi sia che lo fai con ctrl s, sia che lo faccia in automatico chiudendo la sessione) orbiter salva ANCHE lo scenario __Realtime. Serve per evitare di impazzire coi quicksave e con i current state. Puoi lavorare col TG, chiudere, fare qualcos'altro con qualche altra nave e poi aprire lo realtime senza preoccuparti di ripescare i quicksave o di rinominare i current state etc.

Ho capito, però il _Realtime non compare nell'elenco scenari. Con cosa lo richiamo? In teoria, almeno una volta dovrei salvare per avere un riferimento da lanciare (poi quello andrà avanti col _Realtime). O NO?

EDIT

Ho riscontrato un CTD quando si depressurizza il TG, subito appena appare la scritta. sia con dock2 che con stiva

RE EDIT

CTD sparito, va a sapere cosa non andava...
Consiglio di sviluppo:


Vedo che ci sono due ugelli per il movimento verticale; sarebbero utili anche 2 ugelli frontali (al posto del singolo attuale) per facilitare le frenate di docking.

apollo17 ha scritto:

Ho capito, però il _Realtime non compare nell'elenco scenari. Con cosa lo richiamo? In teoria, almeno una volta dovrei salvare per avere un riferimento da lanciare (poi quello andrà avanti col _Realtime). O NO?

non compare dentro la cartella TG_Habitat?

apollo17 ha scritto:

Consiglio di sviluppo:


Vedo che ci sono due ugelli per il movimento verticale; sarebbero utili anche 2 ugelli frontali (al posto del singolo attuale) per facilitare le frenate di docking.

sicuramente hai ragione che l'RCS diciamo di retro è il più sacrificato.

comunque non sono l'unico che ha fatto questa scelta    

Piccolo sondaggio:

sto giocando un po' con le texture dei pannelli solari. quella che c'è ora l'ho ricavata io da una foto della ISS ma non riesco a capire se è "bella" oppure no...

così ho fatto un po' di prove, a voi cosa piace di più?
Originale


Varianti





Dettaglio della variante 3, forse la mia preferita


che dite?

Grazie per l'aiuto!

la 2° e 3° foto ma sopratutto l'ultima...!    

complimenti...

Sondaggio colorazione pannelli solari:

..anche a me piace la colorazione elegante dell'ultima foto  

Realtime:
il file di autosalvataggio compare regolarmente nella cartella "TG_Habitat" ...tra l'altro mi sono "dimenticato" un astronauta fuori...ho chiuso ...e poi riaprendolo era mezzo morto...  

Seconda e ultima foto. Lo scenario realtime non mi compare nella cartella. Forse perchè ho salvato?

Ho scaricato il nuovo file beta ma mi rimane lo schermo bianco e la parete senza cassetti.

apollo17 ha scritto:

Seconda e ultima foto. Lo scenario realtime non mi compare nella cartella. Forse perchè ho salvato?

  dovrebbe comparire, fai conto che ogni volta che salvi viene salvato anche quello... (dovrebbe almeno)... non so dirti il perché, ci guardo e faccio delle prove.
Semmai crea un file di testo vuoto chiamato __Realtime.scn nella cartella scenarios/TG_Habitat, giusto per vedere se poi ci scrive sopra oppure no.

apollo17 ha scritto:

Ho scaricato il nuovo file beta ma mi rimane lo schermo bianco e la parete senza cassetti.

lo schermo bianco è un problema con l'inline client che non riesco a capire perché non trovo uno schema per cui accade: su qualche pc è bianco, su altri funziona... col d3d9 funziona sempre (consiglio caldamente di usarlo anche perché ci sono mille altri vantaggi, soprattutto l'uso delle normalmaps).

Per i cassetti è strano, dopo faccio un check

EDIT:

ho controllato e la mesh è corretta, i cassetti si dovrebbero vedere, mandi screenshot se puoi?

Qui si vedono entrambi

P.S. Cosa cavolo è il d3d9?




EDIT

Negativo, non scrive niente sul file _Realtime.scn

Sembra quasi che non ti si sia scaricata la mesh nuova... se re-installi di nuovo la beta?

Il d3d9 e' un client grafico per orbiter che sfrutta le librerie direct x. Ora sono fuori e non a casa e posso scrivere poco, comunque riassumendo permette di avere effetti grafici notevolmente migliori, molti piu' fps etc. Cercalo su OF, e' semplice da installare e da far partire, penso che ci siano parecchie guide in giro, quando rientro a casa te le indico (intanto ripley ci puo' aiutare qui).

Ok, cassetti e scenario realtime presenti!

...Fred, so che sarà il tuo ultimo ritocco.... ma pensi di scrivere il nome del modulo sulla sua superficie esterna?

stavo pensando di fare un simpatico video su Orbiter...e mi piacerebbe che "firmassi" la tua opera..  

apollo17 ha scritto:

Ok, cassetti e scenario realtime presenti!

Grande! Ottimo!   

m.a.s. ha scritto:

...Fred, so che sarà il tuo ultimo ritocco.... ma pensi di scrivere il nome del modulo sulla sua superficie esterna?

guarda mi hai letto nel pensiero.

Ho fatto una fesseria con la texture scafo perché invece di farne una grande ed avvolgerlo con quella ne ho fatta una piccola e ripetuta mille volte... è meglio come prestazione grafica, ma non posso scriverci nulla e giusto oggi pensavo che sarebbe più bello poterci scrivere qualcosa...

ora vedo di inventarmi qualcosa perché anche secondo me è più bello con un po' di scritte e loghi!