diomedea

Bene, sono felice che ora ti riesca di realizzare il gravity turn come previsto. Era questo l'obiettivo, ed una volta acquisita l'idea di come rendere stabile un razzo, la si può applicare per ogni veicolo. Circa la domanda, perchè i veicoli spaziali "veri" non hanno alette sul secondo stadio? In realtàin KSP l'atmosfera è ancora troppo densa alla quota a cui avviene la separazione del primo stadio col razzo che ho usato come esempio (non che sia sbagliata la densitàdell'atmosfera, ma lo è l'efficienza dei motori ed il rapporto peso massimo/peso vuoto degli stadi). Con atmosfera densa, l'effetto stabilizzante delle alette è predominante su altri (come pure l'effetto di deportanza dovuto all'angolo di attacco, che farebbe ribaltare il razzo se non stabile). I veicoli "veri" invece separano il primo stadio ad una quota alla quale la densitàatmosferica ha ormai un effetto minore, e per stabilizzare il veicolo conviene usare razzi vernieri. Naturalmente, è una tecnica che si può benissimo usare anche in KSP, ma sarebbe da valutare bene se il peso addizionale dei vernieri ed il consumo di combustibile do loro usato sia conveniente rispetto all'uso delle alette. (Nota: queste valutazioni andranno riviste con KSP 1.0, ci si aspetta una nuova aerodinamica e comportamento dei motori più realistici di quanto ottenuto fino a KSP 0.90, per cui l'uso appropriato di alette e razzi potrebbe rispecchiare meglio la realtà).

Following last year's prank, my poor Jeb would not dare try one of those snacks...

Arrowstar, congrats for the new job, really cool .

Beh, se hai problemi, puoi provare a farmi avere il file .craft del razzo che usi. Giusto per provare, vedi cosa succede con questo, è intrinsecamente stabile e (con FAR) si riesce a fargli fare un bel gravity turn impartendogli una rotazione di circa 1,5° appena dopo il lancio (ovviamente, senza SAS). Come potrai notare, non ha sistemi di controllo a parte la reaction wheel interna al pod di comando, quindi anche volendo non potrebbe essere corretto di molto. A seconda della velocitàdi rotazione impressa con la manovra iniziale, ti puoi accorgere di come proceda il turn. Per me dàottimi risultati appunto facendolo ruotare a 88,5° di pitch (-1,5° di rotazione) subito, dovresti vederlo ruotare a 80° a circa 600m di quota, a 70° a circa 2700m, a 60° circa a 7800m, a 50° intorno a 18000m. Successivamente guardo l'apoapside, per cui riduco spinta se ci sta arrivando troppo in fretta, per ridarla prima di raggiungerlo comunque con pitch ancora sopra a 0°, a quel punto la spinta è praticamente orizzontale e serve ad ottenere la velocitàorbitale (Nota). Come potrai notare, non eseguo alcuna correzione alla direzione del razzo durante il volo, dopo la rotazione iniziale (tuttavia potrebbe essere necessaria una piccola correzione in yaw per correggere l'inclinazione della traiettoria, se l'heading non è quello desiderato). Non ruota in yaw da solo (essendo perfettamente simmetrico non risente di forze che possano causare cambiamenti in yaw, ovvero creare angoli "sideslip" laterali rispetto all'orientazione prograde); talvolta può prendere una piccola rotazione in roll (facilissima da correggere, e non influisce sull'efficienza del lancio), la cui causa è sconosciuta (possibile sia dovuta ad errori di arrotondamento nel calcolo delle forze agenti sulle superfici alari). Consiglio prima di provarlo in volo, per farsi un'idea di come si comporta. Quindi, di caricarlo nell'editor (VAB), per vedere come sono posizionati CoM e CoL su ciascuno degli stadi: questo dovrebbe darti un'idea di cosa dovresti cercare di ottenere. Per quanto riguarda il CoM, sarebbe opportuno visualizzarlo non solo a serbatoi pieni, ma anche con serbatoi vuoti per ogni stadio: molti velivoli sembrano stabili a pieno carico ma diventano instabili coi serbatoi vuoti. Nota: con circa 2°-2,5° di rotazione iniziale, si otterrebbe un profilo talmente arcuato da non dover ridurrre spinta prima di raggiungere la velocitàorbitale. Tuttavia, in tal modo la velocitàdiventa molto elevata quando il razzo si trova ancora ad altitudine ridotta (quindi, atmosfera densa), per cui l'attrito diventa troppo elevato. Usando KSP 0.90 e l'add-on "Deadly Re-Entry" (oltre a FAR), quell'attrito è anche sufficiente a far disintegrare il razzo. P.S.: per vedere meglio l'angolo di pitch, invece di usare la NavBall standard in KSP, si può ricorrere ad alcuni add-on. Io trovo molto utile usare lo HUD di SteamGauges.

Dunque, ferram è un maestro per quanto riguarda la stabilitàdei velivoli, razzi inclusi. Quanto ha scritto è perfettamente vero, il lancio più efficiente si ottiene con un VERO gravity turn, che significa non dover esercitare alcuna azione di controllo sull'assetto del razzo mentre questi segue una traiettoria che va arcuandosi progressivamente per il solo effetto della rotazione impressa dalla gravità. MechJeb al contrario esercita un controllo attivo sull'assetto, che è preprogrammato in modo che l'angolo di pitch vari con l'altitudine. Occorre dire che, se il profilo di ascesa è impostato correttamente, le azioni di controllo esercitate da Mechjeb saranno minime. Minori le azioni di controllo, e minori le perdite di energia (tipo, attrito delle superfici di controllo, angolazione del gimbal (per cui parte della spinta è spesa per il controllo dell'assetto, invece che per accelerare il razzo)). E in particolare, nessun cambio di direzione repentino (equivalente ad andare a zig-zag, invece che seguire la strada più breve, per metterla in termini molto semplicistici). Il problema, dunque, ricade nel costruire razzi sufficientemente stabili da mantenere l'assetto anche senza SAS (e quindi senza le azioni di controllo che esso eserciterebbe). La simmetria è importante, certo, ma occorre anche qualche accorgimento circa la statica e gli effetti dinamici di portanza e attrito, nonchè circa il modo in cui la distribuzione del peso varia durante l'ascesa (e quindi come si sposta il centro di massa). Spero di non annoiare con quanto segue: 1) staticamente, i razzi sono instabili, il loro centro di massa (CoM) è sempre avanti rispetto al centro di spinta (CoT). Quindi, ogni minima variazione di assetto rispetto alla direzione "prograde", comporta un aumento della rotazione ad accentuare l'errore. Questo effetto è in realtàquello che permette la rotazione del gravity turn. 2) dinamicamente, i razzi sono tanto più stabili quanto più il CoM è avanti rispetto al centro di pressione (CoP, praticamente corrisponde col CoL per quanto riguarda le superfici portanti). Se troppo avanti, anzi, il razzo diventa "rigido" e si comporta come una freccia, quasi impossibile da far deviare. Pertanto, la distanza CoM-CoP deve essere scelta adeguatamente. 3) quanto precede si modifica durante il volo con il consumo dei combustibili ed il distacco degli stadi usati. La stabilitàdeve essere garantita durante tutto il volo, e questo comporta scelte per quanto riguarda la conformazione del razzo e le parti da usare. Se si è costruito un razzo stabile secondo i punti precedenti, non sarànecessario il ricorso al SAS per mentenerlo in traiettoria, tenderànaturalmente a tenere il naso in direzione prograde a meno di un eventuale piccolo errore. In tal caso, basteràapplicare una lieve rotazione nella direzione voluta (in genere Est, heading 090) poco dopo il lancio, per vederla aumentare progressivamente mentre il razzo accelera a sale in quota. Nel caso "teorico" di una rotazione esattamente pari a quanto necessario, il razzo arriveràin posizione orizzontale proprio quando raggiunge la quota orbitale stabilita e la velocitàorbitale. Se la rotazione fosse insufficiente, è in genere possibile ridurre o temporaneamente annullare la spinta, per riprenderla quando opportuno (con un poco di pratica, si nota quando meglio dare "gas", ovvero quando la direzione prograde è abbastanza prossima all'orizzonte per aumentare la velocitàdi quanto necessario, ma sempre prima di raggiungere l'Apoapside. Se la rotazione è eccessiva, l'unica è usare sistemi di controllo per cercare di ridurla. Ovviamente, dare alla traiettoria l'inclinazione corretta (tipo esattamente 0° con Heading 090) può richiedere qualche correzione, perchè un piccolo errore sarebbe anch'esso progressivamente aumentato. Ora, i "professionisti" delle agenzie aerospaziali programmano precisamente il profilo di ascesa, quindi la rotazione che il razzo deve aver assunto ad ogni punto della traiettoria è calcolata in anticipo ed usata come parametro di controllo (per l'autopilota). L'approccio in pratica è senz'altro quanto usa MechJeb, solo che con un profilo di volo preciso, le correzioni saranno talmente ridotte da avere pochissima differenza rispetto ad un volo con "gravity turn" puro.

Ti rispondo in PM, non vorrei che il thread venga dirottato se iniziamo a parlare di noi stessi (forse, argomento per un thread differente...)

Guarda, hai messo il dito su uno degli argomenti che spesso ricorrono sul forum (in senso negativo). Ovvero, diversi forumisti pensano che KSP vada giocato senza "aiuti", più o meno come Squad l'ha realizzato, e criticano aspramente chi la pensa diversamente. E' una delle questioni che spesso impone ai moderatori di intervenire per consentire a chiunque di esprimere liberamente le proprie opinioni ma senza mai offendere altri. Ti posso dire la mia opninione in proposito, che è praticamente simile a quanto pratica l'intero team di moderatori: chiunque giochi a KSP ha il diritto di farlo come meglio crede: può costruire i veicoli come crede, pilotarli come vuole, ed usare gli add-on che desidera. Tra l'altro, l'uso di un autopilota richiede comunque una certa abilità, e molto di più se l'autopilota è stato programmato proprio dal giocatore (che sia in KOS, o in qualsiasi degli altri add-on che lo consentono). In quanto alla considerazione che in realtàtutti i mezzi spaziali fanno uso di autopiloti, è perfettamente vero. La possibilitàdi controllare manualmente un veicolo è limitata solo a casi di emergenze quasi inconcepibili (devono essersi guastati tutti i sistemi di guida primari e alternativi). Perlomeno per quanto riguarda il programma spaziale americano, la capacitàdi controllo da parte dell'equipaggio si deve solo all'impulso dato dai primi astronauti (in particolare, Schirra e Grissom) che non potevano accettare, da piloti collaudatori come erano, di essere "declassificati" a puri passeggeri (in particolare, mentre il programma degli aerei razzo, tipo X-2 e X-15, vedeva i relativi piloti effettivamente controllare il loro veicolo, e questi piloti facevano spesso notare la differenza tra loro ed i primi astronauti). Ed in realtà, l'azione di questi "astronauti piloti" è spesso stata negativa quando hanno potuto esercitare il pilotaggio autonomamente (es. volo Mercury di Carpenter).

Quei valori derivano dalle date. Nell'esempio fornito da PLAD, la partenza dalla Terra è il 16/7/1976. Se inserisci quella data nel riquadro di FlybyFinder "Time Format Converter" (come data gregoriana), e fai click su "All to this" a fianco, ti vengono le date corrispondenti. Il giorno "KSP UT Day" è in tal caso 9329. Ora, meglio lasciare un margine adeguato come periodo di ricerca (per poter trovare la finestra migliore), nel caso ho preso un periodo di 50 giorni attorno alla data indicata, quindi inizio da UT Day = 9300 (per finire con UT Day = 9350). Stessa procedura con l'incontro con Giove e con Plutone. Solo, il periodo di ricerca viene ampliato in modo da coprire comunque un'arco sufficientemente ampio dell'orbita di quei pianeti (quindi più ampia l'orbita, maggiore il periodo di ricerca), sempre al fine di consentire di individuare le potenziali finestre migliori. Se non fossero giànote in precedenza le date (come indicato da PLAD), si dovrebbe iniziare con un periodo di ricerca almeno pari ad un periodo sinodico, per essere certi di includere tutte le traiettorie possibili. Il programma fornirebbe allora alcune soluzioni migliori, ma solo approssimate: è quindi opportuno fare una successiva ricerca limitata attorno alle date individuate come migliori, per poter affinare le soluzioni. Se osservi il grafico delle soluzioni fornito dal programma, usando periodi di ricerca molto ampi, le soluzioni appaiono molto sparse e poco correlate. Limitando il periodo di ricerca, le soluzioni si addensano attorno alle vere finestre, e si nota bene l'andamento dei tempi di trasferimento e Delta-V necessaria, che assumono un andamento coerente (prova ad esempio, con valori ristretti come 9300, 50; 10050, 200; 16900, 200 per i tre pianeti del flyby Terra-Giove-Plutone: il grafico mostra l'addensamento delle soluzioni su curve definite).

Premetto che non ho (ancora) una conoscenza completa riguardo come le superfici di controllo vengono gestite in KSP (sebbene stia cooperando con alcuni modders che sviluppano codice per estenderne le capacità), ma almeno ho qualche conoscenza circa l'autopilota (sia il SAS che il RSAS). In KSP (almeno fino alla 0.90, con la nuova aerodinamica della 1.0 qualcosa potrebbe cambiare) l'uso delle superfici di controllo serve solo al controllo d'assetto del veicolo (ovvero, a farlo ruotare in pitch, roll e yaw). L'autopilota nel codice di KSP è in grado solo di usare l'errore angolare su questi assi, per stabilire come debbano essere azionati i dispositivi di controllo (quindi, anche le deflessioni delle superfici). Infatti hai perfettamente ragione circa il posizionamento avanti o dietro il CoM, perchè l'autopilota inverte l'azione delle superfici in relazione alla loro posizione rispetto al CoM (e talvolta sbaglia ad azionare quelle davanti al CoM). Nel codice di KSP non esiste un controllo circa gli spostamenti lineari (velocitào accelerazioni lungo i tre assi, come potrebbe essere nel sistema di riferimento locale di un pianeta, per Nord, per Est e verticale), quindi nessuna azione può essere ordinata ad alcun dispositivo (inclusi motori e RCS) perchè forniscano una spinta (opportunamente angolata) che "azzeri" l'errore di posizionamento lineare rispetto ad un valore desiderato. Quanto precede, per indicare che le deflessioni delle superfici di controllo sarebbero comunque comandate per ottenere un assetto desiderato (angoli nei tre assi), e questo può essere totalmente slegato rispetto alle posizioni lineari: pertanto ottenere una spinta vettoriale nella direzione voluta non sarebbe possibile anche se i propulsori fossero montati sopra le superfici di controllo. Operando manualmente con molta abilità, invece che usando l'autopilota, potrebbe tuttavia essere possibile impartire la deflessione voluta e quindi usare la spinta dei propulsori in modo vettoriale, ma occorre essere molto veloci per annullare ogni rotazione del veicolo (che verrebbe impartita in conseguenza del comando che origina la deflessione delle superfici). Tra le difficoltà, il fatto che il veicolo sarebbe intrinsecamente instabile, e solo l'azione di dispositivi di controllo lo potrebbe tenere nell'assetto voluto - mentre purtroppo le stesse azioni sarebbero usate per la traslazione vettoriale, quindi occorre molto rapidi ad annullare la spinta e ripristinare l'assetto ogni volta il veicolo inizi a ruotare. Altra notevole difficoltà, il fatto che se si usano superfici di controllo sotto al CoM, la deflessione è comandata in senso opposto alla rotazione comandata, e di conseguenza la spinta di propulsori montati sopra ad esse (ovvero, occorre comandare una rotazione in direzione opposta rispetto alla direzione della spinta vettoriale che si desidera ottenere: se voglio ottenere una spinta verso destra, il propulsore deve orientarsi a destra (senso orario), ma questo si ottiene con una deflessione della superficie di controllo sotto il CoM conseguente un comando di rotazione verso sinistra (senso antiorario)).

Teoricamente KOS potrebbe consentire il controllo automatico, l'ho usato per la realizzazione di autopiloti. Ma per il tuo scopo, occorre che KOS possa azionare gli attuatori (di IR, se continui ad usare quella mod per ruotare i propulsori), e devi scrivere un programma in KOS che ne regoli il movimento in base alla grandezza che vuoi controllare (tipo la variazione di velocitàsui due assi orizzontali). Non è assolutamente banale, concettualmente scrivere un add-on che faccia lo stesso è appena un poco più complesso. In realtà, se vuoi provare la strada di KOS, potrebbe essere interessante vedere se KSP Flight Computer sia un'alternativa valida. Non ho ancora avuto occasione di usarlo, ma alcune prerogative sono piuttosto interessanti, e potrebbe risultare una soluzione migliore per il tuo caso specifico. Quanto al problema dello stall... mi sembra di capire che usi FAR, quindi occorre costruire il Kodiak in modo che risulti naturalmente stabile e bilanciato nel volo traslato (un bel problema, dato che non sembra che il Kodiak sia particolarmente aerodinamico). Se un veicolo si comporta da mattone, FAR lo faràfinire come un mattone...non c'è scampo una volta che il drag prende il sopravvento sulle capacitàdi controllo esercitata dagli organi di governo (control surfaces, gimbal, reaction wheels o RCS).

Bel problema, quello di avere angolazioni fisse oltre che quelle variabili! Sicuramente interessante come idea, ma non saprei proprio come possa essere fatto. Bloccando il gimbal, posso avere solo una posizione (quella con gimbal a 0°), di angolazioni diverse predefinite non ne esistono altre. Certo, nelle mie precedenti considerazioni stavo cercando una possibile soluzione per la sola modalitàatterraggio. Angolazioni predefinite in realtàmi fa pensare al RCS block. Tuttavia, non conosco come viene gestito (da parte del modulo "ModuleRCS") per fare l'emissione alle angolazioni stabilite. I motori usano invece di norma il modulo "ModuleEngines" (oltre al "ModuleGimbal" se orientabili), sarebbe necessario fare qualche esperimento con la configurazione delle parti per verificare se sia possibile mescolarli. In caso negativo (o se il risultato non sia adeguato graficamente, perchè il motore non verrrebbe ruotato ma solo il getto che ne esce) sarebbe proprio necessario ricorrere ad un add-on specifico. Sono convinto che tra i tanti modders nella comunità, qualcuno saprebbe realizzarlo, ma è da vedere se l'idea sia di loro interesse.

Uh, non credo esista un singolo add-on in grado di controllare la velocitàorizzontale orientando i propulsori. Ce ne sono diversi che svolgono singole attivitàattinenti il problema, tipo i seguenti: 1) Gimbal Auto Trim : orienta i propulsori (tramite il gimbal), modo tenere la spinta centrata rispetto al CoM 2) Throttle Controlled Avionics : bilancia la spinta di diversi propulsori per rendere stabile il veicolo 3) Davon Throttle Control Mod : definisce comandi separati per diversi propulsori azionabili contemporaneamente 4) Horizontal Landing Aid : permette di azzerare la velocitàorizzontale sopra un punto specifico 5) Vertical Velocity Control : controlla con precisione la velocitàdi discesa (probabile sia quello che non trovavi?) Non ho però idea se un mix dei predetti possa funzionare, o se andranno in conflitto. Tra l'altro, non conosco add-ons in grado di comandare le parti di Infernal Robotics per ottenere automaticamente un risultato specifico (come nel caso in questione, azzerare la velocitàorizzontale). L'uso manuale delle rotazioni con Infernal Robotics penso sia estremamente arduo. Presumo sia particolarmente difficile mantenere bilanciato un mezzo mentre si comandano le rotazioni, a meno di potersi affidare agli add-on citati sopra almeno per questo. Se io dovessi realizzare un mezzo tipo il Kodiak, penserei ad un nuovo add-on che incorpori le funzionalitànecessarie da quelli sopra citati, oltre a modificare (o modellare ex-novo) un propulsore in modo che abbia il gimbal necessario (a tutti gli effetti, il gimbal è una rotazione - su due assi - del propulsore, giàgestita nel codice di KSP: permette quindi di comandare direttamente l'orientamento per ottenere una spinta vettoriale, senza dover ricorrere alle complicazioni di IR).

In effetti la sezione italiana non è troppo frequentata ultimamente, per fortuna c'è qualcuno come te a smuoverla un pò . Ho notato i tuoi interventi sui thread internazionali (in inglese), incluso quello circa il Flyby Finder. Potrai notare che si tratta di un programma che conosco (dal numero di miei interventi sul thread originale), non te l'ho nominato prima in quanto richiede pratica per ottenere risultati, le impostazioni di default sono restrittive, in genere buone solo per trasferimenti di breve durata. Comunque è un programma molto veloce nell'esecuzione, pertanto ottimo per una ricerca iniziale dei fly-bys. Io lo uso talvolta insieme a KSPTOT (che pure è in grado di effettuare la ricerca di fly-bys multipli, e di tracciare i porkchop delle varie tratte), che trovo più preciso, ma richiede più tempo. Per trovare soluzioni con Flyby Finder, occorre settare correttamente diversi parametri. Per trovare le finestre indicate da PLAD, puoi impostare quanto segue: Start at = Earth (Kerbin), Earliest Search Date = 9300, Search Period = 50 1st Encounter = Jupiter, Earliest Search Date = 10000, Search Period = 500 2nd Encounter= Pluto, Earliest Search Date = 16100, Search Period = 1000 inoltre, molto importante, V at SOI: max = 12000, min = 8000 (la min può essere bassa a piacere pe questa ricerca). Con i predetti parametri, FF mi ha trovato 496 Flybys. Occorrerebbe almeno un affinamento per trovare i valori migliori (quelli ottenuti alla prima ricerca sono grezzi), ma comunque il minor tempo mostrato è di 7032,5 giorni (per Total DV 13188 m/s, di cui 5217 di braking). La minore DV è invece di 10869m/s (di cui 4383 di braking), per un tempo di 7710,5 giorni. I valori precedenti mostrano bene un concetto importante nei fly-bys. La fionda gravitazionale esercitata (soprattutto da un pianeta massiccio come Giove) permette di risparmiare molto carburante (ovvero, DV) per ottenere comunque le velocitànecessarie per raggiungere l'orbita di rendez-vous. Tuttavia non ci sono grandi risparmi di DV nell'inserimento in orbita all'arrivo, ovvero la velocitàrelativa con Plutone è comunque sempre piuttosto elevata: non esiste un altro pianeta in orbita vicino a Plutone che consenta di "frenare" con un'altra fionda; se la velocitàrelativa è minore, saràcomunque maggiore il tempo necessario.

Ciao Carlo, piacere di notare il tuo interesse per gli add-on che hai nominato. Rispondo in quanto io li ho provati, ed ho una sincera intenzione di tornare ad usarli successivamente al rilascio della KSP 1.0 (e ulteriori). In tutte le installazioni di KSP, creo una versione ad-hoc comprendente gli add-on in questione; tuttavia il mio fine al momento non è di giocarvi, quanto di poter effettuare verifiche circa il loro corretto funzionamento. Purtroppo la modalitàcarriera è sbilanciata al momento in RO/RSS (mia opinione) e questo non mi consente di usarli per un gioco regolare; inoltre, sono molti gli altri add-on intesi a funzionare correttamente solo in modalitàcarriera (di cui non vorrei fare a meno) che sarebbero ulteriormente sbilanciati con RO/RSS (esempi sono Kerbal Construction Time, Mission Controller Extended). Tuttavia, ritengo che il bilanciamento arriveràsuccessivamente, in quanto solo questione di modificare alcuni parametri. Circa le tue domande, ti porto quanto risulta dalle mie esperienze: 1. 9770 m/s per orbita circolare a 220 Km di altitudine; 2. Uso MJ, ma con alcuni accorgimenti, debbo intervenire per ottenere un lancio accettabile. Senz'altro uso l'Ascent Guidance, faccio iniziare il gravity turn molto presto (es. 1,3 km) per terminarlo a 130 km (per l'orbita a 220km). Ovviamente, iniziando il turn così presto, debbo limitare l'angolo di attacco (uso il limitatore a 5°), altrimenti le sollecitazioni dovute a FAR farebbero capovolgere e distruggere il razzo. Ma arrivati ad una quota adeguata (es. 50 Km) tolgo il limitatore, altrimenti MJ non riuscirebbe a portare il razzo sulla traiettoria prevista. Ovviamente questo dipende dal razzo usato, io uso razzi molto lunghi e quindi lenti ad allinearsi, con razzi più "compatti" forse MJ ce la farebbe senza aiuto. 3. Ti consiglio senz'altro KSPTOT, che può essere configurato per funzionare con qualsiasi sistema stellare (RSS incluso), ed è decisamente più "realistico" degli altri tools disponibili per KSP. 4. Non ho idea circa add-on chiaramente incompatibili, ma certamente non le ho provate tutte. A parte le numerose elencate sul thread di RO (quindi verificate compatibili) ne uso diverse altre (es. VOID, Tweakable Everything, PreciseNode, KerbalAlarmClock, KSP Advanced Resource Panel, Active Texture Management), e non ho mai avuto problemi ( a meno dello sbilanciamento per le add-on sulla modalitàcarriera). Circa InterStellar (che non ho mai provato insieme a RO/RSS), potrebbe essere legato alla "versione" utilizzata (come noto, KSPI originale non è stato aggiornato, e sono sorte diverse "alternative" per KSP 0.90). 5. Premetto che non ho mai tentato di raggiungere Plutone. Tuttavia, per qualsiasi rendez-vous, la traiettoria che si avvicina alla minima velocitàpossibile è sempre una "Hohmann transfer", ed è noto che si tratta della traiettoria che richiede maggior tempo. Ti posso confermare che occorrono anche oltre 60 anni per una simile traiettoria (es, usando KSPTOT, mi dàcome primo R/V possibile partendo dalla LEO all'anno 2, giorno 9, per arrivare dopo 66 anni e 337 giorni, ed occorrono 11,68 Km/s per lasciare la LEO ed altri 5,72 Km/s per entrare in orbita attorno a Plutone).

Delightful news, what better reason to not have freetime left? Yes, I was wondering at the reason keeping you from furthering the release of DPAI 6.0, though the latest RC is solid enough to be used in the meantime.

Finally back, and working. Thanks nlight .

Fine if you put the license file into the Github repo (many modders do!), but what is required to publish add-ons here is to comply with the Add-on posting rules. About licensing (rule 1.), "... This license must be made available in both the download file and in the location the user downloads from (such as a forum post or a Curse listing)." Please ensure any of the download files you link include your llicense, and that is shown in the opening post of this thread, and you're good.

daniel L, nobody is allowed to spam new threads just for publishing new versions of anything. Now feel free to edit the initial post with this thread to go about the version 2 you made a new thread for (now merged here).

Nice, tested after removing that line, and all works (and sure no more exception logged). Issue Scratched . Question. I see "du" gained under one scope have no effect with other scopes (intended for what I guess). That means parts abruptly change MTBF due to du change when transitioning from one scope to another, e.g. from X_atmosphere to X_space. But the transition is effectively smooth in reality. Even more smooth would be a transition from X_space to Y_space (changing SoI), but the amount of du gained while in space can be pretty high so the change is really sharp in TestFlight (of course, if both X_space and Y_space are defined, though one may be substituted with the "default" scope). Can't see if a mechanic to address smooth changes in scope is already present. If not, I would allow some "transfer" of du to adjacent scopes (similar to what exists for similar parts). Or, would try a different approach, e.g. from atmosphere to space as a function of current altitude, or of pressure; from one to another SoI based on distance and ratio of the bodies GM (gravitational parameter).

You're right, I was using the same savegame while switching configs. Did another test with only the config files from 0.4.6.2 and a brand new game, (output_log.txt here), and the first Exception above (tied to MM) still shows, not the second as (IMHO) the craft parts effectively are missing the TestFlight modules.

Agathorn, maybe what shows in the log when I use the Squad_Engines.cfg from TestFlight version 0.4.6.2 (and doesn't show when instead use configs from 0.4.0.e7) could hint at the cause for parts not being recognized. The whole log is here, what follows is an abstract of it that shows a number of times during loading: and here an abstract of the log showing what appears while entering fligth: and the same repeats for all other modules, obviously as all those were not loaded by MM for the exception above.

Definitely yes. I appreciate the idea of the "default" scope, and my configs will certainly have a section with that. Thanks about the "TextFlightReliability_EngineCycle", I was still wondering why that worked both with and without the reliabilityCurve data. I had the section with the NRE to appear in groups of 4 in the log, so not really spamming, but an event while entering flight. Believe the number matches some parts, so could be dependent on the craft used. Have to conduct more tests. Wouldn't be surprised if such NREs were indeed benign, and could just disappear when all parts in a vessel are matched to a TestFlight config. So, I'd like to provide more info when tests show further evidence. Yes. Odd for me as well, but that is exactly that. I can notice newer config files to be rather "scrambled" (e.g. the FlightDataRecorder module in the end, and TestFlightReliability_EngineCycle defined before the TestFlightReliability proper module), so those are some possible causes (to me) for the oddity of newer files not working. Have not scanned the add-on code, just what written on the dev thread, so my knowledge of things is still pretty scarce. Of course sorting this issue comes first to me, as I need a solid template before filling data. EDIT: a piece of info I'd like to find, but couldn't, is about what could be valid for a "scope". "Default", "Kerbin_atmosphere", "Kerbin_space" are those I can find. Would "Jool_atmosphere" work too? Could something like "anything_atmosphere" as well? With other parts (wheels, e.g) an interesting scope could be "Mun_landed", may that be valid too?

They're here. The "Tanks" one is still what was distributed with TestFlight development version 0.4.0e7, the "Stock" one has all the lines from the "Engines" one from that same dev version, but for comments, and I'm checking what works or not towards the later versions of config files, before filling in values separately for each engine. So, some of the lines that went deprecated are commented. I'm trying to solve the problem why these config files, though old, allow parts to be recognized (and also seem completely functional), while instead config files from later versions (e.g. TestFlight 0.4.6.2-Stock) don't work.

While trying to test parts config files with TestFlight 1.1.0.0, as I enter flight scene, am getting a number of exceptions like the one below in the log: Have not yet discovered what issue the above brings in game. I'm also having nothing displayed in the Flight HUD (while instead the MSD shows the parts being tracked), though that may be a different issue. Whenever I enable the Flight HUD, the following Exception is logged:

Many thanks . Indeed my issue had another cause (two copies of that ModuleRCSFX.dll installed).