diomedea

I'd suggest not to rush for the orbit goal, unlocking more techs will certainly make the achievement easier. Anyway, here is the pic of a 2-stage rocket able to achieve orbit with just those few parts (Reliant engines, FL-T200 tanks, small fins), without too much correction and not even SAS. My suggestions for a successful orbit are: 1) stability: while building the rocket, each stage must remain stable even when almost empty of fuel. Place fins at the tail so the Center Of Lift is visibly lower then the Center of Mass at all times. With a CoL much lower then the CoM, the rocket will be very hard to steer, but that is not so bad during the ascent, because ... 2) during ascent, always keep the nose of the rocket very close to the prograde direction. Sure, you want to pitch down during the ascent, but pitching too fast will make the rocket travel within the lower and denser atmosphere for longer, and drag will waste much of your DV. Not pitching enough will not provide the horizontal speed required, in the end you need a horizontal speed of about 2200 m/s for a LKO. So, you need to angle the nose of your rocket just a little at a time in the correct direction (generally, pitch down towards heading 090°), the smaller the angle, the more similar the ascent profile is to a true gravity turn (the most efficient profile). 3) After the separation of the second stage, rocket will be much more maneuverable (due to less moment of inertia, but also due to lower aerodynamic effects on the fins). Apply some angle (never more than 5°, the size of the prograde marker of the navball) if needed to start gaining horizontal speed. Start looking at the apoapsis altitude in the map view, you need to achieve 70-75 Km: so, throttle down if you are already at that value. If the profile was correct, you would have gained considerable horizontal speed already, and with a final burn when aoutside the atmosphere you'll get to the orbital speed. It always requires a bit of experience to judge the correct profile.

@Chiodo: sicuramente c'è un bug con le proprietàtermiche degli asteroidi. Ho provato con un grosso asteroide (quindi, anche dotato di elevata massa termica), dirigendgli i motori contro. Si è surriscaldato in un attimo. Grazie della segnalazione, merita senz'altro attenzione e vedrò se questo bug possa ricevere l'attenzione che merita .

wmvanvliet, thank you for keeping Kerbulator compatible with KSP. It is such an useful tool to learn orbital math, and what a reward when I can use some formula with it to achieve my goals .

Dunque, devo rifarmi a quel poco di chimica che ricordo... la combustione avviene per reazione tra un combustibile e un comburente (quasi sempre ossigeno). Esistono altre sostanze idonee a fare da comburente, ma in genere producono reazioni troppo lente, o prodotti di reazione troppo pesanti, per essere utili a fini propulsivi. Sulla Terra usiamo l'ossigeno presente nell'aria atmosferica (al 21%) come comburente (per i motori degli aerei, dei veicoli terrestri, per la respirazione...). Quindi, se su un pianeta abbiamo ossigeno in atmosfera (disciolto in forma gassosa), abbiamo la possibilitàdi usarlo (certo, sarebbe bene che la percentuale di ossigeno non sia inferiore a determinati valori... se l'ossigeno scende a meno del 18% noi iniziamo ad avere problemi respiratori, a meno dell'11% ci restiamo secchi; i motori possono essre adattati a funzionare con un tenore inferiore ma il rendimento ne risente). Ufficialmente, in KSP l'ossigeno atmosferico è presente solo su Kerbin e Laythe. Qualsiasi cosa ci sia nell'atmosfera di Eve (che potrebbe essere a base di anidride carbonica), certo non ammette la presenza di ossigeno atmosferico. In breve, nessuna presa d'aria su Eve ti forniràmai il comburente necessario. Questi Kerbal! Vanno su Eve senza avere una tuta termica per proteggerli dal calore! Scherzi a parte, mi sa che i kerbal possano necessitare di qualche correzione dal punto di vista termico. Non ne so nulla di eliche in Stock (e se lo sapessi come futura aggiunta, non potrei comunque dirlo). Per quanto mi riguarda, aspetto con trepidazione che alcuni add-ons (che hanno eliche come parti aggiuntive) siano resi compatibili alla 1.0. L'elica è un dispositivo (una macchina leonardesca nella sua concezione originale, italiani sempre primi !!) idoneo a muoversi in un fluido viscoso (in pratica tutti i gas e liquidi, ma anche solidi cedevoli). Se posta in rotazione attorno al suo asse, l'elica avanzerànel fluido in ragione del suo passo (a meno delle perdite dovute all'inerzia, tanto maggiori quanto minore è la densitàdel fluido). L'atmosfera di Eve certamente NON E' ARIA, ma è un fluido con densitàsuperiore all'atmosfera di Kerbin: pertanto un'elica è perfettamente idonea per trasformare il moto del suo asse in avanzamento a fini propulsivi. Peccato però che il motore (che deve fornire la rotazione all'elica) abbia bisogno di energia per funzionare. Nei motori a combustione, l'energia è rilasciata nella trasformazione chimica di combustibile + comburente => gas di scarico. Dato che su Eve non c'è aria, il comburente (ossigeno) te lo devi portare da casa....

Dunque, ben venga un thread (o anche mille!) dove siano segnalati i problemi che trovate in KSP. Sicuramente ne troverete molti più di me. Io per quanto posso cercherò di operare su quanto riportate con la metodologia necessaria (in poche parole, verifica indipendente e conferma del problema, controllo che non si tratti di un problema giàsegnalato, delimitazione della/e situazione/i in cui si verifica, possibile ipotesi circa le cause, segnalazione per gli sviluppatori completa di ogni elemento utile). Solo, non sempre potrò dare un riscontro in tempi rapidi. Tenete conto che, anche nell'attivitàdi test, alcuni problemi sono sfuggenti, le corrette condizioni non sono note e non sempre si riesce a riprodurli. Con ogni probabilitàdovrò farvi molte domande, e chiedervi di fornire documentazione (tipo file di log, immagini o video in cui si veda il problema), se un problema non si verifica sulla mia macchina. Tenete conto che diversi problemi si presentano solo per una piattaforma specifica (solo Windows, OSX o Linux) e/o con particolari modalità(es. solo in fullscreen): io "lavoro" solo in Windows, se avete problemi su altre piattaforme potrei al più chiedere ad altri (che so utilizzano tali piattaforme) per la verifica. Circa i "problemi", esiste una classificazione. Gli errori del programma (bugs) sono ovviamente da correggere, ma ricevono una prioritàmaggiore se hanno un impatto maggiore: alla fine gli sviluppatori, che sono pochi e non hanno molto tempo, devono necessariamente dedicarsi ai problemi a maggiore priorità. A volte individuare le cause non è per nulla facile, a volte applicare una correzione potrebbe causare altri guasti: gli sviluppatori a volte spendono giorni per correggere un errore. Altri "problemi" sono dovuti all'uso di valori non corretti. In particolare con la 1.0 (ma anche in precedenti release) è stato fatto uno sforzo per ribilanciare molti dei valori, ma tante delle nuove aggiunte al gioco richiedono ulteriori sforzi in tal senso. Che sono tuttora in corso. Il problema qui è spesso il giudizio soggettivo circa i valori corretti degli effetti: quasi sempre ci sono coloro che vorrebbero di più, contrapposti ad altri che vorrebbero di meno... il valore ottenuto ovviamente scontenta tutti. Le segnalazioni circa possibili varianti (chiamate "feedback") ricevono attenzione dagli sviluppatori solo se c'è un riscontro che una notevole parte della comunitàle appoggia. Altra questione sono i suggerimenti (nuove "features"). Per i suggerimenti ovviamente sapete che esiste una sezione apposita in inglese. Vi prego di non ritenere che, proponendo suggerimenti a me, questi abbiano una via preferenziale: gli sviluppatori comunque realizzano solo ciò che ritengono idoneo per il gioco (che vada bene per la più vasta comunitàdi utenti possibile). Io al massimo posso solo commentare se avanzate suggerimenti. Altra cosa: le segnalazioni possono essere fatte da tutti sul bugtracker pubblico (come indicato qui). Non è certo un segreto, che sul bugtracker pubblico non compare nulla di quanto viene riportato dai testers: esistono altri bugtrackers riservati. Se una segnalazione risulteràdi particolare interesse/importanza, la inoltrerò non sul bugtracker pubblico, ma su uno riservato, dove i problemi segnalati sono esaminati con maggiore sollecitudine. Corollario: molti problemi non sono visibili, perchè sono riportati solo sui tracker riservati: non trovarne menzione, non significa che non siano giàstati notificati (anzi, lo sono ad un livello più elevato!). Infine, ma importantissimo. Tenete conto che io opero sotto precise condizioni di segretezza. In particolare, nulla vi posso dire circa quanto effettivamente avviene nell'ambito dei test (nemmeno a posteriori).

That's really great news, MacTee! Conflict detection ahoy.

@Chiodo: molte utili osservazioni. 1) occorre sempre evitare l'occlusione dei motori. Avere un asteroide dietro gli scarichi non permette di esercitare molta spinta (anzi, nessuna), si finisce solo per "riscaldare l'ambiente". Quindi, la tattica da usare è sempre di spingere gli asteroidi. 2) anche gli asteroidi, come ogni parte, sono dotati di una massa termica, che poi significa quanto calore devono assorbire perchè la temperatura salga di un grado. Grossomodo, la massa termica è proporzionale alla massa della parte. Come (ritengo sia) noto, la massa di un asteroide è ignota fino a quando viene agganciato: in realtàKSP assegna una massa (entro un limite per la classe dell'asteroide) solo in tale momento, a differenza di ogni altra parte la cui massa è definita nel file config. Quanto riporti (esplosione immediata "burnandoci" sopra) fa pensare che ci sia un bug nella determinazione della massa termica. Ma per provarlo dovrò lavorarci sopra un poco, ripetendo agganci con vari asteroidi per capire cosa succede; dopo ne farò segnalazione. NOTA: se si vuole contribuire, fornitemi i valori riscontrati sia di massa che di massa termica per asteroidi che avete agganciato. Per la massa, occorre leggere la massa totale dell'assieme dopo l'aggancio, e togliere la massa del veicolo poco prima l'aggancio, senza significativo consumo di combustibile. La massa totale si legge dal pannello informativo ("knowledge base") sulla destra in map mode. La massa termica si legge dall'action menu della parte (click destro sull'asteroide) dopo aver abilitato i dati termici (Alt-F12 per il debug menu/Physics/Thermal/"Display Thermal Data in Action Menus"). Anche i valori di temperatura e dei quantitativi di calore trasferito (per conduzione, convezione, irraggiamento) dell'asteroide sono utili, ma occorrono osservazioni multiple in momenti successivi per capire se l'andamento sia corretto. 3) Dovrò anche verificare se la massa termica degli asteroidi sia adeguata perchè almeno i più piccoli possano bruciare in atmosfera. C'è sicuramente un problema di bilanciamento: se la massa termica è troppo alta, non bruceranno mai. Dato che il calore prodotto per attrito con l'atmosfera cresce in ragione della superficie esposta al flusso (proporzionale al quadrato del raggio medio dell'asteriode) mentre la massa termica in ragione della massa totale (proporzionale al cubo del raggio medio), è facile capire che asteroidi piccoli bruciano più facilmente di quelli grandi. Non posso escludere che, se anche l'effetto termico risultasse perfettamente bilanciato (privo di bug), asteroidi piccoli abbiano massa termica piccola a sufficienza per farli esplodere riscaldandoli coi motori. Ma certo non dovrebbero esplodere immediatamente. 4) Il sistema dell'ablator sicuramente richiede ulteriori perfezionamenti. Purtroppo gli scudi termici sono apparsi solo molto tardi, non c'è stata possibilitàdi sperimentarli a sufficienza. Inoltre, il comportamento termico ha continuato ad essere modificato (anche con le ultime patch), per cui è cambiato molto come il calore si accumula e trasmette da un parte alle altre. Ritengo tuttavia saràsempre valido il concetto che per preservare gli scudi è bene tenerli lontani da fonti di calore, quindi sia i motori, sia il flusso aerodinamico se ci si muove a vari mach in atmosfera.

Yes, seems service bays have one issue currently that may be the cause of what you reported. That issue is already known. Thanks for the info.

I also noticed an issue with colliders and service bays (and already reported it so Squad may check). Thanks for the valuable info.

No, was on a clean new KSP 1.0, no toolbar. I may not have understood correctly toolbar still being required, the OP to me sounds to mean Steamgauges being compatible with toolbar, but missed to notice that still being a dependency.

No, those tools are not with stock KSP, not even in 1.02. For what I got, not giving a DV indicator is a choice about how the game should work, as KSP is not a simulator and is intended to have players try different ways to build their craft towards something successful (so, giving help to build them properly since the start would go contrary to this idea). About tools to help building aircrafts... I'm confident something may come in future.

Yes, a crash course at ESA, NASA, or any aeronautics school would help. KSP 1.0 implements credible aerodynamics now. That means, when moving in dense atmosphere, the aerodynamic forces are fierce enough to make a craft spin until its Center of Pressure is downstream in respect to the Center of Mass. The trick is to build crafts that already have the Center of Mass forward of the Center of Pressure (or, use the Center of Lift in the editor, as KSP does not show the Center of Pressure). That makes crafts stable in flight.

No decoupler should allow crossfeed. If they did, would be definitely a bug. Mind uploading your craft and providing a link here for testing it?

There isn't a single way to play career mode (and that's for the better, KSP would become boring after one career otherwise). That said, contracts are how money is gained. You may use the strategies (from the admin building) to change how revenues work, so if interested in getting more money, you will choose strategies giving more (at the expense of other valuables, science and reputation).

Welcome to the forum and the realities of KSP. Well, many tutorials you can find around were for previous versions (up to KSP 0.90); with KSP 1.0 the differences in aerodynamics are so marked to be totally different for what those tutorials may tell. In KSP 1.0 aerodynamic forces on vessels can spin them. Stability of vessels is now absolutely needed to be able to maintain course or steer them where needed. While in the lower atmosphere and at high speed, the effect of lifting and control surfaces is highest. Center of Pressure of the aerodynamics forces should always be aft than the Center of Mass, to have a stable vessel. That means, use fins at the tail. While you have no fins (not yet researched the stability node), you have better maintain a rocket aligned with the prograde marker (only very minimal eroors can be corrected by the reaction wheel with a Mk1 pod, or by gimbaling engines when you have them). You have to get high, above the lower atmosphere (no less than 20 Km altitude) before the aerodynamic forces diminish enough to let control from the RW in the pod (or gimbaling engines) be enough to steer the craft where you like. Edit: please note, KSP does not show where the Center of Pressure is. In the editor you can display the Center of Lift (though it only works when at least one lifting/control surface is attached to the craft). Use the Center of Lift to have an approximate idea of where the Center of Pressure may be, so always build your crafts to have a Center of Lift aft of the Center of Mass.

Believe your issue is only due to not knowing exactly what to look for. Enter the Editor (VAB/SPH), select the "Aerodynamics" tab on the left. There you can find 3 parts: - AE-FF1 Airstream Protective Shell (1.25 m) - AE-FF2 Airstream Protective Shell (2.5 m) - AE-FF3 Airstream Protective Shell (3.75 m) Those are the base plates for fairings to develop. When placed, you can then choose how large and high each vertical section of fairings would be above the base (just need the text for [LMB] to turn green for fairings to be valid).

Many engines have been re-balanced, in later KSP versions, but even more important, the ISP relationship is now correct in KSP 1.0. The FF of the Thumper is 0.16995 U/s, that multiplied by the gravity (9.81 m/s^2) gives a weight of 1.667 kg/s. Yes the thrust at 0 ASL is 275 kN. Thrust divided by FF (in weight) gives ISP, and that is 165 at 0 ASL for the Thumper. Beware the KSP wiki is not always kept up-to-date.

regex, you made me smile with those Terms of Use, and glad you are again sharing something of yours.

Thanks TaranisElsu for the update. This is one add-on I can't do without while playing KSP for myself.

Please, stay on topic (FAR in case it wasn't clear). This conversation is drifting away too much, would be better if continued on a thread of its own.

Bene, mi sembrano tutte valide osservazioni, meritano di essre prese in considerazione. @Chiodo: potresti farmi avere il file .craft del tuo lander? Se continua a perdere Ablator, mi viene da pensare che la scudo sia surriscaldato (la perdita è in relazione alla temperatura, mi sembra inizi a 500°K). Vale la pena di fare un test, ed eventualmente mi riesce di confermare la cosa, la segnalo agli sviluppatori. Forse anche il fatto che il motore sia rimasto ad alta temperatura contribuisce... certo vorrei vedere come vanno i valori del calore prodotto, scambiato e irradiato dalle parti in questione. Circa il rover: io finora ho solo costruito veicoli con tutto giàa bordo (trivella, serbatoio per Ore, ISRU, generatori, e scanner). Se usi un rover per trivellare e immagazzinare Ore, poi lo devi attaccare ad un veicolo con l'ISRU, il docking deve funzionare in tal senso. @eorin: sicuramente Squad non ha altrettanto gusto estetico, ma in genere Porkjet (che ha creato il nuovo cockpit e tantissime altre parti) fa ottimi lavori. Io credo aggiungano varietà, ed ho notato altri utenti giàusano quelle parti, con apprezzabili risultati. Ma certo non hanno il senso artistico che tu dimostri. In ogni caso, KSP non nasce per consentire le repliche, ed il fatto che farle (bene) sia una sfida, non fa che aggiungere merito a quelli che ne sono capaci.

Sure I'm on the same side, so much that I always used one scanning add-on or another all of my KSP life, and I look forward to have SCANsat being compatible with KSP 1.0. I hope SCANsat will continue to provide what realistically has to be expected out of scanning a planetary body, and sure I will avoid to use the stock scanners for anything SCANsat can do better (IMO). But while "realism" is my way of playing KSP, I totally accept other players may not be interested in the same mechanic, and instead will be plenty happy with "instascanning" a whole body (with the M700 orbital survey scanner, as the other stock scanners only show what is in range/contact). While I (and others) can easily accept to play KSP modded to have the features we like, most players still like to play with only what stock KSP provides, and in that view, the new survey mechanics are a huge step forward.

Eh, unfortunately one bug seems to be showing with version 1.7.0 in a brand new clean KSP 1.0 install (build 830). In game, there is nothing about SteamGauges showing (not an icon or else), and the log shows the following during the initial assembly loading: Non platform assembly: H:\Games\KSP\KSP 1.0\GameData\SteamGauges\Plugins\SteamGauges.dll (this message is harmless) AssemblyLoader: Exception loading 'SteamGauges': System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded. at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0 at AssemblyLoader.LoadAssemblies () [0x00000] in <filename unknown>:0 Additional information about this exception: System.TypeLoadException: Could not load type 'SteamGauges.SteamGauges' from assembly 'SteamGauges, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. Full log here.

They overheat differently because of the complexity of the thermal model. Though not the case with heat from speeding in atmosphere (attrition), heat affects parts exposed to Sun and not all. About attrition, heat is generated as drag is created by each part (more or less, area presented to the stream * air density * speed^3). Notice that parts upstream occlude those downstream (based on relative size), so heat is directly applied to the first, and less or none to the second. Then, heat is measured against the thermal capacity of each part to compute the temperature. Based on temperature of each part, heat is conducted, conveyed, and radiated in space. Parts with limited heat conductivity don't share much heat with others (even if directly attached), of course if heat keeps being generated for that part more than it can be radiated, conveyed or conducted away, that part temperature will finally get above the maxTemp value... and disintegrate from overheating.

che ti posso dire... Confermo, è uscita. Bando agli scherzi, cosa ne pensate? Le novitàsono di vostro gusto? Oppure, c'è qualche cosa strana di cui vorreste parlare? Ora che la 1.0 è uscita, dovrei essere più libero nel fornire notizie in proposito...