Kerbal101

Updated: now the hottest part is officially - Valentina! Edit: OP updated, shallow cobra works for more "traditional style SSTO" if nose is kept under control (below 45k, its max 45 or its causes uncontrollable flip). However, blackbird always works - yet may overheat the sensitive parts. Combination of both seems to be best for "traditional SSTO". Rolling also seems to work so long apoapsis is low enough.

Yes, its actually from carrier mode. It doesn't have any non-stock parts, except - scaled down heatshield in front. But, basic aerodynamic cone should work - had hardly any reason for heatshield, its actually ineffective when so small. I fully understand your concern about real SSTO, but have not yet unlocked all parts to assemble one. So,.. had to use a rocket. =)

Yes, I misundertood. I meant - my AoA is within or just above of prograde vector. The prograde vector always slips below horizon. So my AoA is still negative as its below horizon too, even if above of prograde. If I understand you correctly, what you mean by "positive AoA" is that your AoA should be above horizon (positive), with prograde slipping below horizon (negative). This looks like "shallow cobra" and it seems to work only at low speeds and with good wing spans. For my case, it failed even at 60km apo / 30km peri.

I just happen to test this approach exactly following instructions and happen to explode from both 200 and 60 km apoapsises. Note, the author used 40km apo! This is unrealistic case ingame, usually its at least 70km apo. Granted, my tiny SSTO lacks a bit of wing space, - it survived my method from 200km, and some other (perhaps I find more better methods over time). The shallow cobra is ... not as efficient. At least in case of my mini-ugly SSTO.

Can you please define the high negative AoA, which plane would manage to survive. I am willing to test this in practice. In my personal tests craft gets overheated very fast and explodes. It gets just out of prograde for 5-10 degrees for a dozen of seconds - also overheats. In my scenario, I am going from 120k apoapsis. The flipping over caused by very high speed and high drag at 55k-35k, to be precise ... say, more than 10 degree difference (note the delayed response to controls!) to prograde vector is enough to force SSTO into uncontrollable deviation and almost immediate desintegration at perpendicular to prograde. Below 20k the possible deviation angles are much more relaxed. Regarding uncontrollable rotation as a method to deaccelerate: http://forum.kerbalspaceprogram.com/index.php?/topic/127258-spaceplane-reentry/ I am going to also test this as a method. Although, nobody would survive the G in reality, so it belongs to array of KSP "features" like stacking multiple engines/fuel/gears within same space. Edit: I misunderstood you. Eitherway, you don't describe the method detailed: "And if you start at a high AOA in the upper atmo, by the time you're into the lower danger zone (under 35k for me) you've already bleed off enough speed to not have to worry about overheating." using typical shallow cobra - failed. Apparently cobra requires a lot of wingspace, see my test in OP below.

First thing I learned when initial practicing the re-entry... the basic Nose cone is much better than the Advanced one; as the former exploded right in my face right around 33k from overheating. Luckily, the exposed basic batteries where strong enough to withstand ~2000K. That was before I got KER to get accurate readings. I also lost all four whipsplashes and good part of left wing, but that was due to my greed for an attack angle... =) I landed just barely on the shore mountain near KSC.. =)

Yes, by my response I only mean - I am going to test your approach. I did not mean that I disagree. Yes, my observation with KER is that - when within re-entry, anything outside of prograde (descend vector) - heats up way faster than when staying inside the vector. So, if you are to: in higher atmosphere (55k-22k), you will overheat and explode pretty quickly. Specifically, because in high-atm the heat factor for every additional angle is high, but the cooling-down factor is low. This is why my current tactic is to stay within prograde and do only occasional "nose ups" using the SAS stability-prograde switching loops (since prograde slowly goes down and stability stays same). Also the risk of fliping over if doing this manually.. But at 22K and lower the heat principle above stops to apply, and "keep nose above prograde" becomes a very good thing; as it discharges both horizontal speed and temperature.

From 35k to space - almost any rocket engine is more efficient than Rapier and Whiplash is more fuel efficient to get to 22K. The efficiency between 22K and 35K is defined by an AoA. Rapier can achieve the same efficiency by a bit steeper AoA.. To rephrase: getting to Orbit - Rapier can be just as efficient as a combo, given the right strategy. Its compact weight turns into huge plus for small SSTOs. But any operations within of "not getting to Orbit" - Rapier looses on ISP. The answer to the question lies within area of operation for the SSTO. PS. Your SSTOs are awesome! Hide any part that can't take 2400K Tmax. Use the right descend strategy. Heatshield can be scaled down with Tweakscale, but usually not needed (thats no rule, YMMV).

This sums up the controversy around MechJeb pretty much. It helps by removing big part of gameplay - big area to experience, learn, big part of challenge. The question is - do you want this challenge? Game should be enjoying experience, in the end. The answer defines the need for MechJeb. If you don't want to learn from failures or if you are simply bored by sheer amount of real (micro-)action, then MechJeb is a positive feature.

1. MechJeb. Its like playing FPS game with Aimbot. With it, KSP goes from "Challenging" into "Easymodo". There is sandbox mode to experiment, Kerbal Engineer Redux and similar mods to deliver you more information and hints. Mods should provide aids to ease the work, but not ease the work by replacing pilot/engineer. Real-life pilots do use more and more sophisticated autopilots, but merely because there is no "Load Button" in real life and manual "experimentation on living patient" is only encouraged when lacking any other options. The only real argument for keeping MechJeb, is when pilot wants to be a strategist, and KSP should play as a round-based strategy as virtually all real-time challenges are lost. 2. I don't need orbiting for planets without atmosphere or with acceptable gravity - and can save tons of fuel. 3. SRB have no thrust vectoring, no ability to control - which is a BIG minus. Without KER or manual calculation of stage 1 T/W to be between 1.5 and 2, using SRB is asking for trouble. It may not explode, but it will burn through more fuel due to inefficient ascend. 4. Thrust-to-Weight is everything for Stage 1 (uplift) and Stage 2(orbiting) or combined Stage 1 for Single-Stage-To-Orbit designs. If you have too much fuel, but too less thrust from engine - you will fall down, spin at higher atmosphere or waste fuel (Stage 1) or will not be able to circularize (Stage 2). 5. Less is more applies only to payload. For engines and fuel - Thrust-to-Weight ratio and Asparagus method - rule. 6. Playing more KSP allows to navigate using navball only, even in total darkness. 7. I like retractable Solar panels --- 8. Ion engine suck, if there is any gravity. Either splash or stranded alone. 9. KSP wings suck for bigger planes. Procedural wings mod - is a godsend 10. KER rules. 11. KIS, KAS, KAX, USI - the big expansion four. Edit: 12. If you build a lander and want to land on the feet - its shape must look as a "bug", not as a "bottle". The very same hint is given by the game at start screen. 13. Invest in science! Create a biome x scientific experiment zone table! Hunt science! Create a rover on four wheels with a basic jet engine, and do a science tour around KSC for over 120 science.

Thanks for response! I dislike "might" =) My suggestion in topic is tested on practice, which I would like to keep it. I will test your suggestion today. I use KER to observe critical skin temperatures and in my experience, above 35k the cool off rate is very low, but heat rate is very high. As result more perpendicular-to-surface (higher negative AoA) result in a faster ... cremation. That said, I thank you for your information and I am going to test it and update the post! By burn there, I mean literal burn as in "burning" from plasma. Not engine burn, as in firing engines. Hopefully fixed the wording now. Thank you! The maneuver is in (5). The big problem is that one can correct a too shallow angle (which is corrected in (5)), but correcting a too steep one is far more dangerous - as steeper negative AoA means fast overheating and higher instability.

Rapiers are by default inefficient on medium and bigger SSTO. They are very competitive for ascending, given the right strategy; but loose on ISP below 22k and in space, compared to specialized engines. Their major advantage is to save weight, but when you need more than two (aircraft dry weight is more than 20-25t; typical rule is 1 air-breath engine per 10t weight), its much better to switch to J-X4 "Whipsplash". Otherwise, in your typical SSTO orbiting, already 3x Rapiers will burn through more fuel than 2x Whipsplash + 1x T-1 Dart. This is because their typical ISP is worse than both Whipsplash and Dart.

I strongly suggest you to install Kerbal Engineer Redux mod. Its a statistic-pure mod and also allows you to show heating, ascend/descent, orbital time, thrust-to-weight, total vehicle weight and much more. Aside from giving your vital information, it does not change anything. Its real real shame stock KSP lacks this.

I have over 2,400 patches and it loads under 5 minutes from HDD. There are definitely improvements. The process seem to bottlenecked to maximum performance of one CPU core, than any disk IO.

So, how do you land your SSTO (space plane, with wings) in 1.0.5 (stock, no dynamics mods, no high-tech stuff) ? This is a question. I offer my answer. I very welcome YOUR answers and YOUR corrections! Its very useful to learn this, by going into sandbox mode, putting your plane in 120k Orbit, named quicksaving ([mod key]+F5) and learning to land safely. Edit: I think I found all the reasons to make descend 100% reliable and predictable. 1. Know-how Assume, the planet is Kerbin. 1.1 The number one factor is - angle/trajectory. The steeper you go down, the more heat will you absorb. The higher your speed, the better is to aim at near flat trajectory. For example, Jool with thick atmosphere will destroy any spacecraft aimed too steep. Airbraking trick via Jool to save fuel instead of retrograde burn is pretty known. As such, if your speed is more than 2100m/s in high Kerbin orbit (70k), you might consider air-braking loops around planet. a) If your angle is too steep, burn anti-radial. 1.2 The number two factor is - speed. Higher speeds at same altitude cause atmosphere to heat more and cool less. At 55k, your speed should be less than 2000 m/s. If your speed is higher than 2000m/s - you are at risk. Ways to disengage speed: a) if you have fuel, burn retrograde between 70k and 50k. b) if you have substantial surface amount (wings), position yourself as a cobra: nose pointing at angle between anti-radial and prograde, and carefully try to maintain this position as long as possible. There is some risk your plane flips, so be careful. This approach makes, basically, "AIRBREAKS" from your whole spacecraft. c) if you have nothing, the most efficient way is to position yourself normal/anti-normal, engage SAS on stability and hold rotation key (Q or E) permanently down. This is similar to cobra, but more stable - and rotation causes equal heat distribution. Parts with less than 2k Tmax may explode! 2. Methods 2.1 Blackbird - direct descend from high-orbit at high speed (pictures) Note: because of high speed, you will only stabilize at around 10k. 2.1.1 Target almost shallow trajectory to surface, preferably not mountains. Correct for about place you want to descend. 2.1.2 Plasma heat starts around at 55k. Set your course to prograde (currently - vector of descend) and lock it. If you can only stabilize - stabilize at prograde and over time carefully push down to be within prograde vector. From observation - any attempt to deviate against prograde at this altitude will result in more heating and shorter descend (more heating at lower trajectory). 2.1.3 Between 55k and 33k, any part with less Tmax than 2400 will overheat and explode. 2.1.4 Around 35k it is possible to shorten the descend by - switching autopilot to stabilize for some time, then switching back to prograde. Trying to do this manually can induce too sharp angles and cause flip, immediate overheat+explosion. 2.1.5 Around 15k, it is encouraged to do breaking maneuver as in (5) above. At this altitude atmosphere is actually capable to cool the SSTO more, than drag can heat it. 2.1.6 Stable trajectory is possible at 10k or continue descend + landing as a regular plane. Congratulations, you survived! 2.2 Shallow cobra (community contributed) Note: this method will only work, if you dropped speed below 2100m/s at 55k. Any higher, go more shallow. At certain speed limit, it does not help anymore. "I don't know about FAR but stock aero from Kerbin orbit, cobra reentry is the way to go. Set your periapse to 30 km, point the nose at the zenith and nothing gets very hot. " Outcome 1: descend from 200km Apo (stock method). My outcome - explosion. Proof: http://imgur.com/a/3TpBY Outcome 2: descend from 60km Apo (as in author image). My outcome - explosion. Proof: http://imgur.com/a/U1Cx9 Outcome 3: Additional test using more traditional (flat, with more wings) type of SSTO. My outcome - flip and explosion if nose at "zenith", yet SURVIVED if nose is between 45 and 0(variates depending on heat and stability). Proof: http://imgur.com/a/1Kpz4 The bottom line: deviations from prograde (descending vector) in 55-35km are deadly. 22km-12km - helpful. 2.3 Rotating apporoach (community contributed) Note: this method is superb, if you lack any wing area. Its very useful for orbital worker bots or re-usable rocket stages. "a reentry technique with as much chaotic movement as possible. The angle doesn't matter as your chaotic rotation will keep the heat evenly distributed and let parts cool off while they are occluded." "A demonstration with FAR, no damage due to aerodynamic stresses, craft is kept cold, works in 100% of cases with no part loss" "The actual rotation speed was about 1 rotation per 1-2 seconds. " Outcome 1: descend from 200km Apo. My outcome - explosion. Retested 4 times to be sure, same situation in the end, same outcome. Proof: http://imgur.com/a/15ffD Outcome 2: descend from 60km Apo. My outcome - SURVIVED. Retested 3 times, every time - survived. Proof: http://imgur.com/a/KcFa8 The bottom line: rotating helps a lot to distribute the heat equally.

Thats Awesome! "Release early, release often?" Pretty please... =)

With 1.0.5, it really makes sense to increase "maxTemp" to 2400-2700. They all default at 1700K - at this temp stuff explodes even on shallow-cobra style (typical) SSTO re-entry, PWings become super useless for anything "space". This is an easy .cfg text editor change, but I thought I should mention this. Edit: forgot to mention - they work beautifully with default aerodynamics.

Right... Confirm the issue with Debian Stable, KDE 4 , AMD HD5850, Radeon open driver (backport'ed from current release), Kernel 4.3 Liquorix (parts of DRM driver sit there) OpenGL renderer string: Gallium 0.4 on AMD CYPRESS OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.3.2 OpenGL core profile shading language version string: 3.30 Linux tiger 4.3-3.dmz.5-liquorix-amd64 #1 SMP PREEMPT Debian 4.3-10 x86_64 GNU/Linux Looks like HyperZ-related (Z-depth fighting). This is about the only issue I have with KSP. Very stable good framerate, even for bigger parts. ALSO, the whole time KSP seem to use just 1 core, which could strongly impact performance on low-clocked multicore system. I get just 25% nearly all the time. Surely physics would be happy to be processed by 3 throttled cores... From: http://bugs.kerbalspaceprogram.com/issues/4787 Because it works on Intel, this must be the HyperZ issue. The Radeon devs had problems getting it stable to work, but I recon they enabled it sometime ago. I wonder if its possible to force-enable HyperZ... This is the Radeon HyperZ issues thread: https://bugs.freedesktop.org/show_bug.cgi?id=75112 They seem to have fixed all issues and it should be default since Mesa 10.4. It can be force-enabled with (this is GOG version (DRM-free ftw! =)) ): $ export R600_HYPERZ=1 $ ./start.sh I will report if it works and how stable it is. But it should be quite buggy pre-10.3 (see linked thread above, comment #16) Edit: no, its still messed up, although "echo $R600_HYPERZ" gives 1.

Bugreport! KerbPaint causes this (smoking black box schroud glitch around BACC thumper booster). Fixed by editing KerbPaint.cfg and commenting two "solidBooster" sections just below "// Engines!".

I have exact same problem right now and it appeared after I modded the game. The boosters are BACC "Thumper". This is on Linux x64, native binary, opensource radeon driver / mesa 10 / kernel 4.1. problem does not exist without mods. I have about 40 mods, those messing with rockets are: Near Future Technologies (all of them), Dr. Jet ChopShop, USI: Warp Drive + Kolonization Systems, Kerbal Aircraft Expansion. I will report back if I find something. Update 1: Some pictures done in sandbox mode. http://imgur.com/a/a03XL Update 2: Running in stock mode (all mods were quarantined outside of GameData), solved the problem. Means, problem is created by some mod. http://imgur.com/uQSxtxQ Update 3: By adding handfull of listed mods with each step, I have filtered it down to ... KerbPaint, ScanSat or KAX! Investigating further... http://imgur.com/a/MZYc5 Update 4, pre-final: Its KerbPaint! It seem to apply painting to BACC flame texture .... I am investigating if I can solve it. UPDATE 5 - Final: Yes, its KerbPaint. To solve this, edit "KerbPaint.cfg" in GameData, find line: // Engines! And comment out the below section completely: //@PART[solidBooster1-1] //{ // MODULE // { // name = ModulePaintable // Texture = solidBooster1-1_Paint // Shader = EmissiveBumpSpec // } //} //@PART[solidBooster] //{ // MODULE // { // name = ModulePaintable // Texture = solidBooster_Paint // Shader = EmissiveBumpSpec // } //} You will loose ability to paint "BACC" though.

Well, you stated "There is a ModuleManager.dll distributed with the download that must be removed, it is very old and will cause issues." Problem is - nearly every mod redistributes "ModuleManager.dll". However, this one hides it inside - this is why it wasn't really obvious to me. Thank you very much!!

http://www.ietf.org/rfc/rfc2396.txt Street unemployed begging people are: Tim Berners-Lee World Wide Web Consortium MIT Laboratory for Computer Science, NE43-356 Roy T. Fielding Department of Information and Computer Science University of California, Irvine Larry Masinter Xerox PARC Apparently, Unity has just to add a semaphore to the boolean variable regarding the network availability, instead of checking it on every URI open call. But I don't know the details...

Hi! Did you know that you are awesome?! Now you do!!! You are awesome, my friend!!! The persistence you repeat "ModuleManager" - made me unzip and check the whole directory tree of plugin. Indeed! There is a "ModuleManager.dll" sitting inside of "KerbPaint/Plugins/". Dear Developer! Please delete this file for good!! It causes serious issues, if left there! Just state this mod depends on latest "ModuleManager" and delete it for good! The plugin now works as advertized and does not affect game loading speed!

EDIT (by the "later" me): This issue is caused by latent "ModuleManager.dll" HIDDEN INSIDE OF PLUG-IN DIRECTORY. Thanks to selfish_meme for persistently pointing this out!! Hello! Thanks for pinging back! I am using standalone Module Manager (pulled, extracted, installed manually): 2.6.17. I also tried older currently shipped with other mods - 2.6.13. No difference. Module Manager DLL from other mods is not pesent, only one latest DLL in root of GameData By just adding KerbPaint folder back to GameData, I again get massive performance drop. To compare how actually massive: - without KerbPaint: start KSP, make a cup of coffee, when I get back its loaded. - with KerbPaint: start KSP, make breakfast, go to work, make dinner, eat it, go back from work late at night - I think it would still be loading. Its like difference between ... Pentium 1(one) 90Mhz and Pentium Core2Quad. Screenshot: http://imgur.com/04aW6Mu The CPU usage is 25% all the time (I have quadcore, means 1 core is fully loaded - regardless of affinity or scheduler type, or priority(niceness) for CPU and IO). It does not play a role which resource is loaded - sounds, textures - they all slow. Also UI itself is *extremely* sluggish, for example mods such as *StockBugFix* detect first launch and draw initial configuration box right at loading screen. Without *KerbPaint* they are perfectly responsible as stuff happily loads in background. Game is from GOG, stock 1.0.5, then about 40 mods. Most heavy is OuterPlanets Mod. Also, I have not "slapped" mods over and over - I created a comparsion table in LibreOffice Calc first. For *each* mod I installed, I have read throuroughly what it does, where it conflicts, read posts if it has some bugs, if it works with 1.0.5. Every one is manually downloaded and manually installed. The only file conflict was between - *Kerbal Aircraft Expansion(KAX)(mod)* and *USI Kononization(mod)*, both include internal version of *Firesplitter (mod)* - and KAX one is patched (stated in readme) and must be installed overwriting stock one from USI; no other file conflicts... game is currenlty perfectly playable with same fps and only 500MiB more RAM (1,8GiB vs 1,2GiB). Thank you!

EDIT (by the "later" me): This issue is caused by latent "ModuleManager.dll" HIDDEN INSIDE OF PLUG-IN DIRECTORY. Thanks to selfish_meme for persistently pointing this out!! Hello I would like to confirm that this mod causes MASSIVE increase in loading time of the game. This happens on Linux x64 version! The loading time increases to over 60 minutes+ (I had to terminate it). I figured this out by removing mods one by one! This is quite serious bug!