Camion Spaziale

si, megaupload a me lascia scaricare una volta su venti... ribadisco, molto più comodo speedyshare, anche se non ti conserva i files...

Ho visto che non siete riusciti a scaricare (strano, a me riesce sempre ) e quindi ho passato il file su SpeedyShare. Speriamo di risolvere i problemi dei file .ini perchè giuro non capisco dove ci sta l'errore!


Aggiungo la lista dei comandi, che fino ad adesso mi ero dimenticato di esplicitare (ls sta per "left shift" al solito seguito dal numero del tastierino numerico senza in "numpad"):
k = apertura Cargo Bay
g = carrello di atterraggio
ls+0 = apertura antenna
ls+1 = apertura "docking nose"
ls+2 = apertura portello docking
ls+3 = chiusura portello cabina-airlock e dopo breve pausa per depressurizzazione successiva apertura del portello airlock-cargobay
ls+4 = apertura pannelli solari
ls+9 = uso timoni di coda come freni aerodinamici (non mi funziona )

Grazie Vittorio... guarderò l'ini, sicuramente c'è qualche errore di sintassi di quelli subdoli; basta un niente per mandare all'aria il funzionamento.

intanto una cosa che posso fare subito (per modo di dire: diciamo oggi quando rimetto le mani sui dati) è correggere i parametri del veicolo (peso, potenza motori, riserva combustibile eccetera)

Andrew ha scritto:

intanto una cosa che posso fare subito (per modo di dire: diciamo oggi quando rimetto le mani sui dati) è correggere i parametri del veicolo (peso, potenza motori, riserva combustibile eccetera)

Questi parametri non li avevo nemmeno presi in considerazione, perchè era ovvio che toccavano a te Prova anche caso mai (hai visto funzioni) a rimappare le animazioni fatte con il tastierino numerico.

OK vedo che posso fare...

intanto, a partire da oggi prevedo di assemblare per la prima volta in Orbiter i nuovi vettori che ho fatto (il superheavy, Quasar-471 e il lanciatore per l'Eridanus, Quasar-220) e di iniziare a impostare le autoguide per il lancio.

Ah sì scusami, una precisazione: per rimappare intendevo"cambiare il tasto di comando" (esempio usare il 2 anzichè lo 0 e così via). Non voglio farti diventare matto a ricalcolare tutti i punti di aggancio, di appoggio ...

OK!

più che altro mi preoccupa la logica degli RCS... devo guardare come "funzionano" osservando il modello standard dello Shuttle. Sono abituato ai classici "quad" apollo-style!
Si vedono bene gli ugelli degli RCS sulla texture? mi sembra di si

Ho notato una cosa sbagliata nel file ini: vedo che crei diverse anim_seq che hanno lo stesso tasto, soprattutto per gli interruttori.. ad esempio:

[ANIM_SEQ_4]
; KuBand antenna
INIT_POS=0
KEY=0
DURATION=10
REPEAT=0

[ANIM_SEQ_5]
; interuttore KuBand antenna
INIT_POS=0
KEY=0
DURATION=0.1
REPEAT=0

che sia li l'errore?

Andrew ha scritto:

OK!

più che altro mi preoccupa la logica degli RCS... devo guardare come "funzionano" osservando il modello standard dello Shuttle. Sono abituato ai classici "quad" apollo-style!
Si vedono bene gli ugelli degli RCS sulla texture? mi sembra di si

Gli RCS posteriori sono praticamente dei "quad" apollo-style con la sola mancanza del razzetto rivolto verso prua, in quanto si sopperisce con quelli posti sul muso. Per quelli posti sul muso si procede all'opposto per quanto riguarda il quad posteriore (manca) mentre la direzione degli altri getti è secondo questa immagine:

Fausto ha scritto:

Ho notato una cosa sbagliata nel file ini: vedo che crei diverse anim_seq che hanno lo stesso tasto, soprattutto per gli interruttori..

No, è una scelta voluta. Funziona così: tu premi k per aprire i portelloni, ma se utilizzi la stessa sequenza di animazione per l'interruttore (movimento di pochi decimi di secondo) e per il portellone, in fase di chiusura del portellone tu vedi l'interruttore che resta sollevato in posizione aperta fintanto che il portellone non si chiude. Invece creando due sequenze di animazione diverse, ma comandate dallo stesso tasto, avrai anche in fase di chiusura che l'interruttore ruota istantaneamente. Non so se si è notato, i segnalini di posizione (aperto-chiuso) hanno un doppio movimento: in posizione chiusa sono completamente grigi, all'atto dell'inizio della sequenza si posizionano a metà (mezzo grigio, mezzo rigato), al raggiungimento della posizione di completa apertura si posizionano sul tutto rigato. Al contrario funziona allo stesso modo, quando si fa partire l'animazione in chiusura dal totalmente rigato passano al mezzo rigato, per diventare totalmente grigi a animazione conclusa (posizione di chiusura). E' un espediente utile per sapere se l'animazione si sta ancora muovendo o no.

Ancora una cosa, tanto per la curiosità. Ho effettuato con Anim8or una correzione al 3ds generato dal mio programma. Infatti una delle specifiche di Orbiter dice che i materiali "trasparenti" devono essere gli ultimi gruppi. Ora siccome in fase di conversione da 3ds a msh il convertitore ordina i gruppi per ordine alfabetico ho cambiato il nome del materiale ad alcuni gruppi, permettendo così di avere doppie finestre (avanti-dietro) e di vedere oltre senza che ciò che sta dietro sia cancellato (espediente che invece ho usato per la Mission Control Room).
Specifico: questa modifica non ha influenzato ovviamente le animazioni, in quanto ho cominciato a lavorare su di esse DOPO esser stato certo che la mesh si vedesse correttamente senza pezzi mancanti, errori e cancellature.

Pete Conrad ha scritto:

No, è una scelta voluta.

Ok! Mi chiedevo se assegnare lo stesso tasto a due animazioni creasse dei conflitti che poi fanno aprire l'antenna insieme ai carrelli!

Teoricamente credo di no. Si può provare a eliminare le animazioni degli interruttori, e vedere se la cosa funziona.

beh scusate, forse sto per dire una cosa che non c'entra niente, ma con l'Antares non abbiamo forse impostato due animazioni diverse comandate con lo stesso tasto? Pannelli solari e antenna. E tutto funzionava...

E' vero, la mia era solo un'ipotesi.. deve esserci qualcos'altro, qualche numero messo al posto sbagliato..

Ragazzi ho appena fatto una scopertona: ci deve essere un errore nei moduli Vinka, in quanto se non indico la sequenza di animazione dei timoni nella sezione

[AERODYNAMICS]

per la precisione la riga è questa

; reference to animation sequence of rudder
RUDDER_ANIM=16

l'antenna non appare più. In effetti, il pezzo di antenna che si muoveva è il sedicesimo gruppo (numero 15, ma il primo gruppo ha numero 0, se non sbaglio ...)
Riguardo all'impedimento all'animazione finchè un'altra non è eseguita Fausto, hai novità?

Ulteriore scopertona! Se invece di indicare il numero della sequenza di animazione metto un numero a caso (quello di un gruppo ad esempio) ecco che comincia a muovermi quelli relativi ad alcune sequenze di animazione ben precise (esempio per i timoni mi sembra sia l'animazione dei portelloni): non vorrei che in realtà bisogna mettere alcune sequenze proprio in quel posto (a quel numero) e le altre invece a piacere. Proverò a riguardare le istruzioni di Vinka per l'ennesima volta.

Pete Conrad ha scritto:

Riguardo all'impedimento all'animazione finchè un'altra non è eseguita Fausto, hai novità?

Purtroppo devo dirti che con SC3 non è possibile impedire un'animazione prima di un'altra (a meno che non siano parte di un'unica animazione, cosa non proponibile con gli interrutori) quindi dovremo pensarci quando faremo la DLL!

ma uniamoli in un'unica animazione i portelli e i pannelli solari, che male fa?

Se eliminassimo gli interrutori dei pannelli solari e dell'antenna si potrebbe fare, altrimenti..

Poi con calma, quando torno dal lavoro, vi spiego ciò che ho fatto e vi passo il file config con le animazioni corrette. da settare per quanto riguarda RCS, pesi, potenze, carburante ...

Andrew ha scritto:

ma uniamoli in un'unica animazione i portelli e i pannelli solari, che male fa?

Per intanto la lascio come animazione staccata, se vuoi la uniamo. Sarebbe però (oltre che più bella) una cosa più da lavorarci sopra per l'astronauta (come nella realtà). Inoltre se non la mettiamo, abbiamo lì quell'interruttore e quel segnalatore inutilizzati, tanto varrebbe toglierli dalla mesh e utilizzare lo spazio per altro.


Edit: senza aspettare di passare a casa ecco qua il file .ini con le animazioni corrette. Il problema lo ho risolto molto semplicemente, editando le animazioni originali del file di Vinka e aggiungendo quelle che non c'erano. Ora funziona tutto (ma proprio tutto!), resta solo da da chiarire la quantità frenante dei due timoni (ho provato ad atterrare al KSC, ma vado sempre lungo, non è per nulla un "mattone volante") ed eventualmente altri piccoli particolari tipo la sezione [LANDING GEAR] che gestisce la quantità frenante delle ruote.

Proposta: volete che ci mettiamo un paracadute?

OTTIMO!

Per il paracadute io credo che non sia necessario se le dimensioni dei carrelli sono simili a quelle dello Space Shuttle.. perchè a parità di potere frenante c'è una minore massa da frenare!

Mi sono accorto cercando di atterrare che non avevo implementato lo HUD display. Allora ho fatto una modifica alla mesh

e già che c'ero ho pure aggiunto un estintore e un paio di check list, tanto per far scena

Le correzioni incluse in questo pacchetto sovrascrivono i precedenti files, e sono composte dalla nuova mesh, dal file ini comprensivo di animazioni e hud che sostituisce quello di oggi pomeriggio, e dalle texture corrette.
Riassumendo: per avere la beta dell'Eridanus bisogna scaricare prima i files di ieri, quindi la patch di stasera e sovrascrivere i files.

Lista dei comandi:
k = portelloni
g = carrelli
left shift + 0 (numpad) = antenna
ls + 1 = freno aerodinamico
ls + 2 = apertura "docking nose"
ls + 3 = apertura portello docking
ls + 4 = apertura pannelli solari
ls + 6 = chiusura-apertura airlock EVA

Bellissimo! Un'altra cosa che si può fare con la DLL è impedire il movimento dei timoni quando si è in modalità RCS, ed ovviamente sostituire gli MFD falsi.
Comunque eccellente ottimo lavoro!