tea_bag97

Hey guys, I've been looking for v1.2.3 for KSP 1.1.2 (hoping it's still compatible with 1.1.3) but I don't seem to be able to find it. Any advice?

Scusate per la risposta attardata, ma sono appena rientrato in possesso del mio pc. Attualmente tra frame rate basso e memoria scarsa il problema che preme di più è il primo, rende impossibile giocare. Quello che mi piacerebbe sapere con precisione è se sia possibile far girare su una configurazione come la mia (l'elenco è nel primo post del thread) KSP con l'Astronomer's Pack ad almeno 30 fps. Tra l'altro mi ricordo che ai tempi della 0.23 ero in grado di far girare il gioco con molte più mod, tra cui la Better Atmospheres V5... mi ricorda quasi il passaggio di Minecraft dalla 1.2.5 alla 1.3.2, quando installare mod è diventato di colpo più difficile. In ogni caso ho installato l'Astronomer's senza componenti aggiuntivi come tempeste di sabbia o altro, solo quanto necessario.

Davvero grazie mille a entrambi per i chiarimenti, adesso rimane solo un dubbio da fugare: KSP gira meglio su Linux nel senso che essendo possibile allocare più memoria si possono installare più mod e quindi si possono rendere i crash per Access Violation meno frequenti o migliora anche la performance da un punto di vista del frame rate?

E la versione x64 mi farebbe avere prestazioni migliori, oltre a crash meno frequenti? Tra l'altro, da quanto ho sperimentato di persona, la versione x64 per Windows è molto più buggata di quella per Linux. Se così fosse, varrebbe la pena di installare Linux su una partizione per giocare ai giochi con Unity in x64?

Quindi Scott avrebbe accesso a versioni di iOS o KSP che gli permettono di far girare il gioco in x64, o ad un hardware più potente? Perché se il problema del lag può essere risolto installando Linux e quindi potendo giocare in x64, lo faccio subito.

Quindi finché il gioco non passeràad Unity 5, sempre se lo farà, non saràpossibile risolvere questi problemi? E poi mi rimane ancora questo cruccio: come fa Scott Manley a far girare il gioco così fluidamente con praticamente più mod di quelle che uso io? Possibile che sia solo grazie alla maggiore potenza della CPU?

Quindi, se uno dei problemi maggiori è causato dal multicore, è possibile fare in modo che KSP utilizzi soltanto una quantitàlimitata di core, diciamo 2-3, di modo tale che i processi non vengano "spezzettati" tra tutti e 8 i core, per rendere teoricamente il gioco più veloce? Anche perché monitorando le prestazioni della CPU in diretta, soltanto un paio di core vengono impegnati oltre il 15%, il resto rimane piuttosto inutilizzato, inutilmente a mio parere.

Salve a tutti, questa volta avrei una domanda di carattere un po' più tecnico del solito. KSP è arrivato alla release ufficiale e la vanilla è piuttosto stabile, è ben ottimizzata e sul mio PC gira senza problemi a 60fps e oltre finché non si superano le 100 parti in un veicolo. Il problema sorge quando vengono installate mod: siano alterazioni al gameplay come FAR, l'aggiunta di nuove parti come KW Rocketry o di elementi estetici come l'Astronomer's Pack, vanno tutte ad inficiare negativamente sulle prestazioni del gioco. Ognuna però agisce in maniera differente, che io non conosco. Dalla mia esperienza posso immaginare che mod che aggiungono parti occupano più RAM e rallentano i caricamenti, mod come FAR, Deadly Reentry e RemoteTech rendono i calcoli che il gioco deve eseguire più complessi e quindi richiedono un maggiore sforzo da parte della CPU(?), mentre le mod che migliorano la grafica, come EVE e l'Astronomer's Pack sono per me un mistero. Un paio di giorni fa ho provato a installare per la prima volta l'Astronomer's Pack, e ho notato che purtroppo era necessario avviare il gioco in OpenGL, che stranamente nel mio caso, a differenza di Scott Manley o Bob Fitch, rende l'immagine spigolosa, come se l'antialiasing non venisse applicato. Ciononostante il frame rate si aggirava tra i 20 e i 25, quindi immagino che questa mod non vada ad impegnare solo RAM e CPU, forse anche la GPU? La cosa più strana è che riscontravo tale frame rate anche nel VAB, il che mi impensierisce perché apparentemente non ci sono effetti dell'AP in quella scena. C'è qualcosa che mi sfugge. Se qualcuno di voi è in grado di far girare il gioco a frame rate decenti, magari oltre i 30, avendo installato l'Astronomer's pack, o anche solo EVE, insieme a poche altre mod come FAR, sarebbe così gentile da svelarmi come fare? Grazie in anticipo. In ogni caso questa è la mia configurazione: -OS: Windows 7 Ultimate x64 -CPU: AMD FX-8150 8-core 3.6GHz -RAM: 16GB DDR3 -GPU: AMD Radeon R7 200 Series

Per fortuna poco prima che riscontrassi il bug avevo eseguito un quicksave... nel caso posso analizzare quello. Che programma consigli per farlo? In ogni caso ho riscontrato il bug anche oggi, ma stavolta mi sono spinto un po' oltre nell'analisi: ciò che non appare è solo ed esclusivamente la possibilitàdi vedere il veicolo (premendo M praticamente, non so come si chiama tecnicamente) mentre in mapmode scompaiono linee delle orbite e possibilitàdi selezionare bersagli e tutto il resto. Tuttavia rimangono la toolbar superiore e la navball. Non sono in grado di capire se il veicolo ruota veramente, però quando imprimo una rotazione viene consumata carica, e soprattutto se incremento la manetta il carburante viene consumato e la velocitàorbitale nella navball aumenta. Prima di provare ad alterare la velocitàorbitale però ho salvato, quindi ho provato, dopodiché ho ricaricato il salvataggio precedente, dove l'hud era scomparso, ed era lì. A quanto pare facendo quicksave e subito quickload risolve il problema, anche se è strano, perché ritornando al menù principale e ricaricando la stessa partita, senza chiudere il gioco, non risolve nulla.

Scusa se non ho risposto prima, tra un impegno e l'altro... comunque sono riuscito ad avere di nuovo il solito bug, ma stavo usando baretail e credo di essere riuscito a individuare il punto nel log che riporta cosa è successo. Nel log appaiono svariate "NullReferenceException: Object reference not set to an instance of an object PlanetariumCamera.LateUpdate ()" (la prima è a riga 179), ma anche verso la fine del paste che ho caricato (dalla riga 706) ci sono stringhe che mi sembrano strane... Soltanto che non ho disinstallato nulla, ci sono comunque le mod che utilizzo di solito, anche se oltre a RT nessuna sembra essere particolarmente coinvolta. http://pastebin.com/2miHj3Ua

Riguardo all'isolare il problema, non saprei da dove cominciare... sembra avvenire senza un motivo, in genere quando passo da mapmode e viceversa. L'unica azione che avevo pensato potesse essere correlata era alterare i valori con Precise Node, ma se è come tu dici... Comunque, andando per esclusione, direi che RemoteTech è in qualche modo responsabile della scomparsa dell'HUD. Un'altra cosa da riportare è che in ogni caso interessato sul veicolo erano presenti soltanto parti di stock, ad eccezione di un solo serbatoio di ProcParts. Tra l'altro è successo di nuovo qualche minuto fa, per fortuna in orbita bassa di Kerbin, e ho notato un paio di cose in più: Kerbin continua a trovarsi lì, non scompare, mentre il veicolo è completamente svanito. Nessuna traccia. In modalitàmappa però, se faccio doppio click su Kerbin per poi premere backspace, la visuale si focalizza di nuovo dove dovrebbe essere il satellite. Dopo un po' di tempo però non sono più riuscito a passare da mapmode a zoom sul veicolo, infatti premendo M la visuale si restringeva e basta, non c'era un cambio di scena. Poi se ritorno alla schermata dello Space Center o torno al menù principale, l'hud non riappare nella scena di gioco, mentre appare nella tracking station. Se invece chiudo il gioco seguendo la procedura standard e lo riavvio, perché premendo esc almeno il menù di pausa risponde, tutto ritorna alla normalità. Il satellite è dove lo ho lasciato prima che l'HUD scomparisse ed è come se non fosse successo nulla. Spero che queste poche informazioni che sono riuscito a raccogliere possano aiutare in qualche modo.

Negli ultimi giorni mi sono dedicato alla messa in orbita di una nuova rete di ComSat con RemoteTech in orbita intorno a Kerbin, uno dei miei primi tentativi. So che non è necessario avere valori precisi fino alla seconda cifra dopo la virgola perché gli errori rientrano in certi margini, ma mi piace fare le cose con accuratezza. Una cosa che ho sempre notato in KSP è che a volte il gioco stesso non è sicuro di quali siano apoapside e periapside, nel senso che i valori indicati nella mappa fluttuano, specialmente quando il veicolo ruota molto velocemente. Attualmente uso il flight computer di RT per effettuare le manovre e mantenere l'attitudine, quindi credo che questo pilota automatico sia forse troppo preciso e tenda a eseguire rotazioni impercettibili ma che a quanto pare confondono il gioco. Come ho detto prima, questo problema in fin dei conti c'è sempre stato da quando ho iniziato a giocare, ma negli ultimi 2-3 giorni, nella 1.0.2, mi è successa almeno cinque volte una cosa stranissima: mentre cercavo di modificare il maneuver node, l'orbita cominciava a destabilizzarsi pesantemente fino a quando nella barra del ÃŽâ€V appariva NaN. Quindi tutto l'hud scompariva, e senza punti di riferimento non sono mai riuscito a ritrovare nemmeno Kerbin. L'unica cosa che ero in grado di vedere era la skybox. Ora, premetto che utilizzo anche Precise Node di blizzy, e che un paio di volte questo problema è successo mentre stavo editando il node utilizzando valori numerici per alterarne il tempo, ma mi sembra che non sovverta in nessun modo il codice del gioco. Potrebbe anche darsi che, avendo installato kOS, ProcParts e ProcWings, che tutte richiedono le KSPAPIExtensions, visto che le KSPAPIExtensions siano ritenute dal mio gioco incompatibili con la 1.0.2, questo possa essere in qualche modo collegato. Per il resto non so che pensare, ho provato a installare KerbalJointReinforcement ma non è cambiato nulla... che posso fare?

Ah fantasitco, mi sembrava strano che non ci fosse una versione dev della mod, grazie infinite Comunque hai idea se esistono varianti anche per il pod da 1.25m?

L'estetica è un fattore che personalmente ritengo fondamentale per non uccidere l'immedesimazione in KSP. Certo, è solo un gioco, ma non amo l'aspetto di alcune parti di stock come i decoupler. Per questo non gioco mai senza mod come ProcParts o ProcFairings, quantomeno per avere la libertàdi decidere quali texture utilizzare. Ho ancora un problema da risolvere: cosa mettere in cima al modulo di comando? Prima della 1.0, avevo installato la SDHI, che aggiungeva una parte da mettere sopra il CM Mk1-2, un ibrido tra un docking port e un paracadute, simile a quello dell'Orion. Purtroppo la mod non è ancora stata aggiornata per problemi vari, così mi ritrovo senza alternative se non montare i paracadute di stock o quelli di RealChute, questi ultimi orribili a mio avviso per la loro forma a punta, anche se molto funzionali. Da quello ho potuto osservare del design di razzi con equipaggio nella realtà, in cima al CM c'è molto spesso un Launch Escape System che viene rimosso successivamente, sotto al quale sono posizionati i paracadute, come nel CM dell'Apollo. Il LES è presente in KSP, ma in stock se si vuole montare il LES, in cima non c'è posto per il paracadute, dovendo così ricorrere ai paracadute radiali che irrimediabilmente faccio esplodere durante il rientro. Perciò quello che vi voglio chiedere è se conoscete espedienti o mod non troppo ingombranti, come FASA, che mi permettano di piazzare un paracadute in cima alla capsula, sotto il LES, per avere un impatto visivo migliore. Grazie mille

Spettacolari, il Blackbird è qualcosa di sublime... tutto questo in stock + KerbPaint? Niente mod come ProcParts o ProcWings?

Con la versione 0.90 l'editor è stato aggiornato e sono state aggiunte nuove funzioni, molte delle quali ancora a me sconosciute. Perciò accade abbastanza spesso un particolare problema: quando cerco di rimuovere una parte del veicolo, esso viene selezionato per intero, come se stessi premendo contemporaneamente shift, e quando succede questo non ho idea di come fare in modo da selezionare la singola parte per rimuoverla, senza cancellare l'intero razzo. È molto frustrante, ma ho notato che è più probabile che accada se la parte è stata copiata premendo alt + click. Forse premo qualche shortcut di cui ignoro l'esistenza?

Seguendo i tuoi consigli, per la prima volta sono riuscito a mandare in orbita un razzo con equipaggio in Realism Overhaul. Il gravity turn sicuramente permette di risparmiare tantissimo carburante. Grazie mille!

Ah, quindi nella realtàsi usano espedienti analoghi all'RCS in game? E io che pensavo che fosse da niubbi... Comunque, adesso che ho capito almeno in minima parte come avviene il gravity turn vorrei provare ad applicarlo a kOS, più per essere preciso nella manovra che per automatizzare il lancio. Ho giàfatto svariati tentativi, il mio programma consiste in un "wait until velocity > 100m/s, lock steering to heading (90, 85-88.5), wait 5" e l'esito è sempre lo stesso: non appena l'autopilota di kOS si disattiva, il razzo sussulta in maniera innaturale (o forse soprannaturale con la magia delle reaction wheels di KSP) e ottengo heading e rotation assurdi, completamente deviati. Secondo te è possibile automatizzare la manovra, creando ogni volta un programma apposito per veicolo?

Ho provato il tuo razzo ed è stato fondamentale per farmi un'idea sulla distanza ottimale tra CoL e CoM. Quindi ne ho costruito uno tutto mio, e funziona a meraviglia: senza toccare i comandi, senza SAS, dopo i 5km di quota, ho ottenuto un'orbita inclinata di soli 1,9°, conservando a fine circolarizzazione più carburante di quanto avesse fatto MJ con lo stesso razzo, con i parametri consigliati da ferram (TWR: 1,25; turn shape: 50%; turn start: 1.4km). Veramente fantastico. Soltanto che per avere una stabilitàottimale è stato necessario mettere winglets (fisse) anche sul secondo stadio, che esteticamente non sono proprio il massimo. Anche perché non mi viene in mente nessun razzo IRL che abbia un design del genere. Come fanno le grandi agenzie spaziali a ottenere la stabilitàottimale senza? E poi, da quello che ricordo, lo SMAP lanciato a fine gennaio non ne aveva nemmeno una...

Non mi hai assolutamente annoiato, anzi apprezzo veramente lo sforzo che hai fatto per cercare di rispondermi in maniera così approfondita. Quindi credo di aver capito che il segreto per avere un razzo aerodinamicamente stabile (con FAR) è trovare la giusta distanza tra CoM e CoL. Il problema è che ogni mio razzo, se lanciato senza SAS, tende a deviare irrimediabilmente, variando non soltanto l'angolo di pitch e yaw, ma anche quello di roll, ed è questo fatto in particolare ad incuriosirmi. Non riesco proprio a capire come calcolare i valori correttamente per avere un razzo stabile.

Ciao a tutti Documentandomi su Realism Overhaul ho letto su una pagina di GitHub scritta da Ferram (in persona) che per avere la massima efficienza in un lancio sarebbe meglio lasciare che sia soltanto la forza di gravitàa far deviare il razzo, dando soltanto un input iniziale ridotto. Al contrario, mod come MechJeb alterano il pitch a seconda della quota alla quale si trova il veicolo usando reaction wheels e winglets, intervenendo in maniera innaturale e quindi presumibilmente sprecando prezioso carburante. Quindi ho fatto vari tentativi seguendo le istruzioni di Ferram. Nei casi in cui mantenevo l'SAS attivo, il razzo rimaneva troppo stabile e non veniva deviato naturalmente, mentre nei casi in cui spegnevo l'SAS cominciava a ruotare e cambiare direzione fuori controllo. Sono sicuro di aver posizionato tutte le parti simmetricamente, dunque immagino si tratti delle famose forze fantasma provocate da FAR. Perciò la mia domanda è: è possibile compiere un gravity turn senza perdere il controllo del mezzo? L'unica soluzione verosimile che mi viene in mente è fare in modo che l'autopilota controlli soltanto roll e yaw, tralasciando temporaneamente il pitch. Fonte: https://github.com/KSP-RO/RealismOverhaul/wiki/False-KSP-Lessons https://github.com/KSP-RO/RealismOverhaul/wiki/Ferram-on-Ascent-Profile-and-TWR

Già, in effetti anche solo il fatto che sono io a programmare l'autopilota ne giustifica l'utilizzo... mentre sinceramente non ho mai provato soddisfazione nell'utilizzare MechJeb. Grazie per la chiarificazione! P.S.: Comunque dove hai imparato tutte queste cose? Sei un ingegnere o qualcosa del genere??

Scusate se rispondo solo ora, ma in questi giorni non ho potuto giocare a KSP e ho avuto problemi di internet. Vi ringrazio molto per i suggerimenti, siete stati davvero competenti e d'aiuto, offrendo spunti a cui non avrei mai pensato... Comunque penso che per ora lascerò perdere questo progetto. Mi sembra un'impresa giàsolo andare a capire qualcosa da tutti i moduli, per non parlare di editare qualcosa... Anche se, leggendo principalmente (ma non sperimentando) mi sono documentato su kOS e ad una prima occhiata penso che si possa fare qualcosa per la stabilizzazione orizzontale, magari considerando il vettore spostamento e facendo in modo che i motori si orientino in maniera opposta. Ma come ha detto diomedea, il problema rimane l'integrazione automatica nell'SAS. Appena possibile farò esperimenti e vedrò se saràfattibile una cosa simile con kOS. Intanto ho scritto un paio di programmi per l'automazione del lancio e circolarizzazione e devo dire che mi sembra qualcosa che va a semplificare molto il gioco, anche se mi è stato detto più volte che anche le agenzie spaziali del mondo reale utilizzano autopiloti programmati, almeno per l'ascesa. Secondo voi usare kOS per i lanci di routine è cheating, o in qualche modo snatura KSP dell'aspetto del pilotare, oltre che costruire? Mi sento quasi in colpa

@PlonioFludrasco Il problema però in questo caso sarebbe che i due assi di rotazione sarebbero l'asse del pitch e l'asse dello yaw (passatemi questi termini, non conosco il linguaggio tecnico), mentre effettivamente a me servirebbero quello del roll e dello yaw. Avrei usato IR perché mi avrebbe permesso di ruotare con un hinge i propulsori e quindi formare una specie di X, per avere un maggior controllo, ma pare che IR sia un mondo a sé stante per quanto riguarda l'interazione con le altre mod, quindi credo che lascerò perdere per un po', soprattutto dopo aver visto che fine fa il mio caro Kodiak quando arriva a 280 m/s... Large scale stall @diomedea Credo che smanettando tra i moduli potrei fare più danni che altro... Magari IR non potràinteragire direttamente con le mod per il controllo di volo, ma che dici di KOS? Non l'ho mai usato, ma ho visto che BevoLJ nella sua serie su RO/RSS l'ha pesantemente utilizzato per i lanci. Magari ad un tasto si può associare la rotazione ad un angolo predefinito e insieme il thrust limiter...? Dico così solo perché non ho idea delle potenzialitàche potrebbe offrire, e questa è l'unica cosa che mi viene in mente. E poi rimane il fatto che ha la aerodinamicitàdi un mattone...

Hai ragione, anche se ho provato bene o male tutti gli add-on da te suggeriti (devo dire che sono veramente interessanti, soprattutto Throttle Controlled Avionics), nessuno di questi riesce a controllare IR. La tua idea dello sfruttare il codice giàesistente per magari creare una parte in grado avere un vectoring range significativamente maggiore, magari di 45° anziché 1°, è interessante, però dal poco che capisco di scripting dovrei modificare il codice in modo tale che l'orientamento del propulsore possa a seconda della situazione o rimanere fisso o essere alterato dal computer di bordo che fa le correzioni necessarie per azzerare la velocitàorizzontale. Cerco di spiegarmi meglio: ci dovrebbe essere a mio avviso la possibilitàdi impostare posizioni predefinite fisse, come 0°, 90° e 180°, che corrisponderebbero in teoria a accelerazione, decollo e decelerazione, possibilmente attivabili con action groups, e poi la modalitàatterraggio in cui la rotazione viene affidata al computer per azzerare la velocitàorizzontale. Tutto questo mantenendo un'attitudine che eviti di schiantarsi al suolo distruggendo qualsiasi cosa, quindi facendo qualcosa di simile a porre un limite all'angolo d'attacco. Quindi per quello che ho capito io qui si tratterebbe proprio di creare una mod da zero, e temo di non esserne proprio capace... Comunque, con MJ e Throttle Controlled Avionics sono riuscito a far "volare" per quanto mi ha consentito Ferram il Kodiak, ma il problema più pressante che ho avuto è stato controllare l'orientamento dei Rotatron di IR. Per caso conosci un modo per creare delle angolazioni predefinite come ho scritto prima, quindi 0, 90 e 180?