blakemw

I think I actually just figured it out. I wasn't running the tutorial with the provided craft and instead with one of my own vessels. This vessel is a fairly bog-standard SSTO Twin-Boar rocket with 2 orange tanks and some stuff on top and a 1.25m reaction wheel. What I think is happening is the Autopilot thinks there isn't enough reaction control and simply refuses to even try to rotate the vessel, possibly running into the "When the available angular acceleration is zero" corner case but I'm not sure about that I guess it could also be the calculations just work out to zero. This vessel takes around 20s to rotate 90 degrees under the stock SAS so I wouldn't consider it chronically under-torqued, but by adding more reaction wheels the autopilot will rotate it. It also turns out I can make the autopilot rotate the vessel by raising "stopping_time", set to a higher value and the auto_pilot will apply the full power of the reaction wheels and successfully rotate the vessel. It seems on the whole the autopilot defaults work well for atmospheric use but poorly in microgravity - particularly when compared with the stock SAS direction holds that rotate the vessel using full power as optimal. While in the original case I was using a large vessel, the autopilot also just seems very sluggish when rotating normal vessels, altough as I gradually make more sense of the tuning parameters I can make it work better. It seems to me it should be possible to autotune the autotune based on the vessels moment_of_inertia and available_torque, the defaults seem to assume a high torque as is the case when thrust vectoring and control surfaces are available and that's why they work poorly when only the low torque of reaction wheels is available.

I'm a new user to kRPC with KSP 1.3.1, using python client (0.4.2), I got the Launch to Orbit script from the tutorial working except for one part: # Orientate ship print('Orientating ship for circularization burn') vessel.auto_pilot.reference_frame = node.reference_frame vessel.auto_pilot.target_direction = (0, 1, 0) vessel.auto_pilot.wait() The autopilot fails to point the ship at the node. It just does nothing. I decided to try it the naive way I'd normally do it in-game and replaced it with this code which did work: vessel.auto_pilot.disengage() vessel.auto_pilot.sas = True time.sleep(0.1) vessel.auto_pilot.sas_mode = vessel.auto_pilot.sas_mode.maneuver vessel.auto_pilot.wait() I'm not sure why I had to disengage the autopilot, but as long as it was engaged then SAS would refuse to stay on. Also the documentation says auto_pilot.wait() will throw an exception if used while the auto_pilot is disengaged, but it does work if SAS has a target. Anyway I'm very happy with my script and don't need help per-se, I'm just puzzled that the tutorial code doesn't work.

I was trying to debug an issue with suicide burn readout being suicidal to use (i.e. hitting the surface of Mun at hundreds of m/s), and noticed it's actually due to a glitch with Altitude (Terrain) Assume starting a session (i.e. reloading a game) at above 10000m at Mun. When the ship has never passed below 10000m* at Mun, the "Altitude (Terrain)" is almost exactly equal to the "Altitude (Sea Level)" After the ship has passed below 10000m at Mun, the "Altitude (Terrain)" becomes the true altitude above the surface. If the ship goes above 10000m again, the "Altitude (Terrain)" will be lower than the "Altitude (Sea Level)" by a constant amount equal to the difference when passing through 10000m This is why the suicide burn distance wasn't working, as long as you're above 10000m it assumes the ship has 10000m to stop in, when it could be only 4000m (or if you've already passed through 10000m on a previous orbit it could be messed up in all sorts of other ways, like thinking you have 6000m to stop in when you actually have 9000m). I also poked through the source code because at first I thought there was something wrong with the suicide burn distance calculation, but that was when I noticed that the "Altitude (Terrain)" was just plain wrong, and the suicide burn calculation is using that just plain wrong altitude. I do note that "Better Burn Time" does not seem to suffer from this glitch, or at least there is no sharp discontinuity in its "impact time" readout when passing through 10000m and seems accurate.

There's a couple of reasons that can happen. First there's only a couple of probe cores which fit, the OKTO2, and I believe the QBE, others will still have some skin poking out into the airstream, which is bad. Secondly, it's important to not directly attach the probe core to the heat shield because enough heat can conduct through to destroy the probe core with their puny 1200/1200 tolerances. Instead high-tolerance parts (i.e. reaction wheel, radial battery or cubic octagonal strut) should be used as a buffer.

While this is true, it changes nothing about the Mun, because you gain much more benefit by doing the burn in LKO than while passing the Mun, because Kerbin's gravity is much stronger. It's actually often similar with Jool, if you come in hot and the moons can't capture you outright, you'll probably get more out of a burn close to Jool than close to Tylo/Laythe. About the only case where a "powered assist" might be useful, is when you're doing an Eve assist, not only does Eve have stronger gravity than Kerbin but it's also deeper in Kerbol's gravity well so you can get oberth effect from both from Eve and Kerbol. In principle it ought to be pretty useful if you want to do an extra-fast transfer (probably in outer planets mod). Incidentally I also don't bother much with gravity assists, I usually play with a life support mod (usually Kerbalism) and like to do expedited transfers (actually Kerbalism also adds part malfunction, so even for an uncrewed probe there is benefit in getting places faster). Also IRL gravity assists are mainly only used due to tiny budgets, not really a problem in KSP.

That's why I qualified with "assist in capture". Mun is pretty useful in general within the Kerbin system, like to help lower heavy payloads from Minmus without having to bother with aerobraking, and when doing Kerbol "peekaboo" as Kerbal training it's handy when falling back down from the SOI edge.

You can't meaningfully use the Mun to assist in capture, the reason is that when you cross the Mun's orbit like that, what you're essentially getting is a radial/anti-radial burn, which is not useful for slowing down. The problem is that when you're coming in at hyperbolic speeds, you can't both encounter Mun at a point where you'll get maximum benefit from a gravity assist, and have a low periapsis around Kerbin for maximum oberth effect. That is, if you aim for a low periapsis around Kerbin to maximize oberth effect, you'll cross Mun's orbit at 90 degrees and can't get a meaningful gravity assist. When dealing with interplanetary velocities, the oberth effect at Kerbin is much more valuable than any gravity assist the Mun can provide. As for why it depends on velocity: Gravity is an acceleration, change in velocity over time, the more time spent near a body, the more time gravity has to bend the trajectory. When a ship is racing in like a bat out of hell it only spends a very short time near Mun and so Mun's gravity can only bend the trajectory a very small amount. Conversely, when approaching Mun at low velocities the Mun's gravity has a long time to accelerate the ship and can apply several hundred m/s of velocity. So a body either needs to have powerful gravity, or you need to approach it slowly, to get a meaningful gravity assist. The only two moons which can apply meaningful gravity assists for interplanetary transfers are Tylo and Laythe.

Is there going to be changes to emissions from nuclear devices? It'd be neat if they take inverse square law into account, like taking the weighted average of the distance between the emitter and each crewed component and calculating how much distance should reduce the irradiation. Like if you make an interplanetary ark and have 50m of fuel tanks between the nuclear engines and the crew the exposure would be quite minimal compared with bolting an LV-N under a lander can. An actual calculation of shielding would be even cooler, but just inverse square law would probably suffice and could be a static analysis and not need to take into account things like the amount of fuel in tanks changing.

Fun fact though, is that if you merely "flyby" the sun (that is, leave Kerbin's SOI on a trajectory which enters another SOI, either back to Kerbin after ~1 year or another planet) you get awarded the flyby but not the orbit. I used to believe that any escape from Kerbin's SOI would award the Sun Orbit, but nope, it has to display a proper, non-broken orbit.

The small heat shield is the first available 0.625m decoupler, it's also the cheapest one, though not the lightest (but if you remove the ablator it is pretty light) An OKTO2 probe core does fit behind the 0.625m heat shield, so does the 0.625m battery and reaction wheel, so it is just barely possible to make micro-landers for dumping into atmospheres at high speeds (i.e. hyperbolic), actually getting the micro-lander to do anything useful is a bit of a design challenge.

A third SpaceY. In addition when playing RSS it's absolutely vital to use either SMURFF or RealFuels w/ stock configs. The stock engines are very underpowered compared with real engines, this works fine in the kerbalverse, but when playing in RSS the underpowered engines make it extremely hard to put substantial payloads in orbit.

Man, what a hog. Actually I've encountered a similiar thing with "recover kerbal and his wreck" contracts, the food and water adds several tonnes to the vessel to be recovered, which sucks when the contract informed you you'd be recovering a 1t pod.

He's probably progressively cheated more over time. Like you start by cheating a little, and when no-one notices you get emboldened and cheat a bit more and so on, seeing how far you can take it. There's no questioning the guy's skill. It's like an athlete who takes steroids to break new records, you couldn't take your everyday joe and pump him up with steroids and have him break world records, you still have to be supremely skilled and dedicated, but it cheapens the accomplishments and does a disservice to those who play by the rules.

Well that's funny, you just said exactly what I said in my last paragraph ;). Reverse thrust is convenient to have. Though I normally don't bother on vessels less than 20t.

You might try to master the art of docking without RCS. It's quite easy as long as the docking port is aligned with the engines, especially if the docking port is at the nose. All you need is a good reaction wheel so the vessel is reasonably nimble. Docking without RCS involves getting close to the target vessel, killing relative velocity, getting the docking ports to aim at each other ("control from here", and setting the other docking port as target is very useful here, as is "target lock" on an advanced probe core), and then flying forward so the vessels dock. I find it's usually quicker than docking with RCS. Eliminating the RCS has two benefits: First it eliminates unbalanced RCS. When you try to do translation with RCS it's easy for the thrusters to jitter the vessel around, sending it slightly off-course. It can be worked around in variuos ways, but it's a pain. Pure reaction wheel rotation is perfectly clean without side effects and you can rotate the ship and direct thrust to "pull" the prograde marker over the target marker (the trick is that a burn will always pull the prograde marker towards the reticule, hence this technique is sometimes called "prograde pulling"). The second benefit is it saves a lot of mass: the mass of monoprop and all the RCS thrusters to achieve balanced thrust adds up, it's not a big deal for low orbit, but when you're sending stuff a long way, like to Moho, you don't really want to bring any unnecessary mass. A final thing to note in relation to this is that RCS thrusters are generally grossly overpowered for small vessels, there is a similar problem with aircraft control surfaces, the AV-R8 winglet is perfectly sized for a "Twin-Boar" rocket and there's nothing small enough to be actually suitable for smaller rockets. While you can dial down the authority limiter/thruster power this doesn't stop them being excessively heavy/costly for the small vessel. The flipside is small vessels are incredibly nimble with reaction wheels alone, making it a great solution for small vessels. When I do use RCS it's usually only for forward/reverse thrust. Even when doing "aim, fly forward, and dock" docking it's pretty useful to have reverse thrust, not essential, but useful. When I do this I limit the actuation toggles to fore/aft so that the reaction wheels take sole responsibility for roll/yaw/pitch.

Are you aware of NASA's trajectory planner? It has some limitations when applied to KSP and in particular you cannot get trajectories for any arbitrary time (and they probably wouldn't be accurate anyway due to drift), but is awesome to get a general idea of the requirements for a Mars/Venus flyby.

Best nose cone is fairing, as a bonus you can put a few small parts inside. Good idea to disable staging on a nose cone fairing to avoid accidentally popping it.

No mods. Just IVA (viewing cupola) with a targeting guide (I used the hollow structural piece). I took those screenshots in LKO, but it worked just as well from the ground, day or night didn't seem to matter. The main thing is game resolution matters, the higher you crank up your resolution the more pixels a planet will occupy. You can also set the value "SCREENSHOT_SUPERSIZE" in settings.cfg to 2 or more to increase the resolution used for screenshots.

Yeah using 4k resolution and an IVA-scope Jool and Eve are resolvable as small disks. Duna is a couple of pixels. Moho can be seen as a pixel that flickers in and out of existence - I doubt it'd be visible on 2k. Dres and Eeloo are for all intents and purposes unobservable but I wouldn't discount the possibility that they might be occasionally be seen as a pixel that lights up for a single frame. Jool at 4k through IVA zoom (looking down the barrel of a 1.25m structural fuselage piece): Jool is the little green thing And here is Jool with IVA-zoom at 16k resolution via screenshot supersample, and resized to 8x in gimp I was hoping one of the moons would show up but I guess even higher resolution would be needed. I also tried taking an image of Dres using supersample, however nothing appeared in the screenshot.

For those starting out to plane-based SSTOs I recommend to begin with very thrusty spaceplanes because they are more forgiving. My first successful spaceplane SSTO. From there you can work on getting the engines to lift more weight into orbit, by making better use of wings, smarter ascent trajectories and improving the ratio of lf to lf/ox so as little unburned propellant remains as possible. The little plane pictured above probably has a runway TWR of about 2 which is ridiculously high, in contrast the lowest viable runway TWR is about 0.3 (through 0.5 is more comfortable), this provides enough power to get enough lift to get into flight, the RAPIER enjoys a high mach multiplier which means as the plane goes faster it generates more thrust, so by flying horizontally over the ocean at fairly low altitude you can gradually build up speed until TWR ramps up allowing the plane to go supersonic, at that point it should have plenty of thrust to climb up to higher altitudes. (note you can also just end up flying horizontally until the plane has burned enough fuel that it can break the sound barrier: in that case you should've just launched with less fuel, which also makes a great way to tune a spaceplane, if it can't break the sound barrier, remove a small amount of fuel and try again). Note that rocket-SSTOs, based on Twin-Boar or Mammoth, are much more practical and generally economical than spaceplane SSTOs. You should only build plane SSTOs because you enjoy it, not to get stuff into space.

I set my resolution to 4K 8x AA and using target lock tried really hard to see any other planets. The only visible bodies where Kerbol, Mun and Minmus. This leads me to conclude that - at least from the surface - it's not possible to see other planets. I also tried from sun orbit, using the approach where you start close to the planet and then recede away and see when it disappears. First thing to note is that planets are bloody obvious when they are visible, they stick out like sore thumbs relative to the starfield. You might not randomly see them without some kind of targetting system, but I used a great number of I-Beams to make a long pointer and if the planet was there at the end of my pointy stick it was obvious, flickering and sharp relative to the blurry starfield, this is especially obvious with Jool's moons which are exceptionally flickery on timewarp when you are close enough to see them, after a while the flickering stops so I assume they simply stop being rendered altogether. Eve disappeared at about the closest approach distance between Eve and Kerbin, but that was with my ship being at a location where Eve was well lit. At the closest approach between Eve and Kerbin, Eve will be very poorly lit. I wouldn't discount the possibility that Eve might be visible from Kerbin orbit but it would probably be a small dark pixel, perhaps with an occasional flicker to bright depending on whether the game chooses to render a pixel from the dark or bright part of the disc. As for Jool, ehhhh, it kind of disappeared at about 1/4 the distance from Kerbin to Jool. It's also fairly dim, being green and black. I suppose it might be possible to see it as a single pixel that flickers between green and black. Without zoom, no chance at all of seeing the other planets.

Just a quick note: Contracts don't work in Science Mode. For that reason science contracts shouldn't be a major factor in unlocking the tech tree or incentivizing use of a part. I like the DMagic contracts a lot for career but "relying" on them for balance really breaks science mode.

According to the simulator it should work. Since toggle habitat can be added to an action group I might have to try that for a "solar storm bunker down" mode.

The Kerbalism simulator thing will tell you how much Pb-equivalent shielding thickness there is. By default maximum shielding (20mm) blocks 90% of the radiation, 10mm would block 45% of radiation. Kerbals die of radiation once they have accumulated 50rad (you get the first warning when they have accumulated 25rad - so at that point you are warned they are half dead). For example basic radiation rate outside a magnetosphere is 0.02 rad/h so it will take 2500hr or 416.67 days (just under one year) to die of radiation poisoning in an unshielded ship, this is increased to 4166.7 days with max shielding and you can go even higher by piling on active shielding. A solar storm inflicts 5rad/h for 6h so inflicts 30 radiation which is guaranteed to make an unshielded Kerbal sick and two storms be lethal. With maximum shielding the solar storm only inflicts 3 rad. Active shielding doesn't do much to stop solar storms, so with enough active shielding to prevent all background radiation and maximum passive shielding your Kerbals will be killed by the 17th solar storm. Solar storms strike on average every 500 days so maximum mission duration is about 8500 days or 20 years. Note that because shielding is averaged across a vessel, you can make a solar storm "bunker" on an otherwise unshielded ship by having a maximum shielded pod, then *decouple* the pod during the solar storm so the kerbals enjoy maximum shielding. This is fairly illogical and it'd be fair to consider it an exploit.

Sounds good It would go a long way to create justification to having labs and I like the idea of streaming data home for incremental rewards. Some basic biological experiments would be plant study, fish study, rodent/chicken study and kerbal study. Logically these experiments could be done separately in microgravity (stations) and low-gravity surfaces (bases) and take at least 6 months to complete, but could be much longer too. There would be a certain logic to having them be done separately on every surface, growing plants on Minmus is not the same as growing plants on Eve. Another category could be the development of various microgravity manufacturing processes. This would be specifically for stations, location shouldn't really matter, microgravity is microgravity. Lots of scope for making stuff up here from basic smelting/refining to advanced electronics. Then there would be, I guess you'd call them material sciences, to learn how to utilize regolith and thus be specifically for bases. It would actually be very logical that these experiments could be done separately on different planetary/moon surfaces. Developing concrete on Mun would be different to Duna because the local materials are different. You can also make them take an arbitrarily long time to complete. Within material sciences there could be research for construction materials, fuels, alloys and polymers. hah, I don't mind that there's an incentive to visit different locations, but being forced to grind biomes to develop the tech tree is silly. It's actually even logical that (some) experiments could be redone at different biomes, but if you have to sit the base there for 2 years to complete the experiments it'd create a very different feel to biome-hopping.