Thanny

So this one's a bit weird, because it doesn't happen unless you have some very specific design elements. The key elements: 1) A pair of KR-1x2 engines on side separators of a central fuel tank with an engine. 2) At least one additional tank on top of the KR-1x2 engines. 3) Fuel pipes from the KR-1x2 engines or the extra top tanks to the central fuel tank. 4) SRB's on side separators attached to the KR-1x2 engines. 5) SRB's burn separately on first stage, then the LF+O engines. A picture of an example ship that should be easy to recreate by sight is attached. Here's what happens when you launch the ship: 1) The SRB's lift off normally. 2) After staging the SRB's away, one of the tanks on top of the KR-1x2 engines drains faster than the other. 3) After the top tanks are empty, the KR-1x2 tanks themselves seem to drain normally, but their levels are by then uneven, causing a large yaw force. As you can see in the image, the fuel delivery paths look messed up as well, though that's still true with the SRB's removed, which results in no fuel flow problem. If you put all engines in the first stage, the fuel flows normally. I tried to reproduce the problem with other engines in the same configuration, but was unable to. Any thoughts?

Are there any mods that make wheels brake properly? Right now, even with braking power and friction set to max, the brakes hardly work at all.

I had two missions for a class B asteroid - one to bring it to orbit around Kerbin, and one to bring it to orbit around Minmus. After taking both missions, I found a class B and brought it into orbit around Kerbin. The Minmus contract still showed the ship as meeting the asteroid requirement, so I performed a burn that would bring the ship to Minmus. The contract text, after all, only says the asteroid has to be newly discovered after taking the contract, not that it can't be applied to another contract, so it makes sense. However, after reloading this game after some number of months of hiatus, I found that the ship is no longer showing as satisfying the asteroid part of the Minmus contract. Rather than go through the hassle of fetching another asteroid, I want to fix the problem in the save game, since this counts as a bug in my book. Does anyone know which part of the save needs to be changed, and how?

As I stated, the second save is not using claw docking, and SAS is not enabled in either case.

Though I'm putting this in the modded forum, the same problem happens with no mods. Put simply, I've found a couple situations where my fuel station shakes itself apart, and it's not obvious what the actual trigger is. Here are two saves which show the problem: https://drive.google.com/file/d/0B3tt82xN7ijMdk8yaTQtSGo1bnM/view?usp=sharing With the first one, one ship is approaching the station, which already has two ships docked to it via claws (three if you count an extension via large docking port). When you get within about 250m, the station starts shaking, increasingly violently, until it falls apart with copious explosions. If you switch over and detach the two claw-attached ships, the catastrophe doesn't occur. When I re-attached them in series (one clawed to station, the other clawed to the first), no future shaking occurred in that session. In the second save, the two ships are gone, but the approaching one from the first save is now docked at the rear via the large docking port. The station has just been switched to, to check on fuel creation progress. Despite there being no issues for a few orbits previously (even with another large ship docked near the top for while), it now starts shaking not long after loading the save, and falls apart. The shaking does not occur if you detach the ship at the rear. If you detach shortly after the shaking begins, it stops, with no damage (wait too long, and it stops but not before wreaking havoc). So, any ideas on what the actual root problem is here? There's no SAS involved. I don't think there's any part clipping. I know using the claws has been buggy in the past, but the second save has no claw attachments (though there are three present - two on the station, one on the docked ship). I'm at a loss how to describe this bug beyond "This is bad; make it stop."

So I have an asteroid harvester that I built in 1.1, and used several times. The full details of the design aren't really important, but it has four drills mounted radially, and in the spaces between them (four total) a medium extendible radiator. In version 1.1, these radiators kept the drills at optimum temperature, as should be expected. I just used the same ship in my 1.2 game, and find that the radiators do nothing at all. The drills heat up to max, which makes them work incredibly slowly. I even shut down all but one drill, with zero change - still no cooling whatsoever. So is this just a bug I should report? I have the following mods installed, none of which do anything to change heat physics in the game: Distant Object Enhancement Editor Extensions Redux Kerbal Alarm Clock Kerbal Joint Reinforcement (only because FAT-455 wings are unusable otherwise) Navball Docking Alignment Indicator Precise Node TAC Fuel Balancer Toolbar Transfer Window Planner

Also came here to report that the AN/DN shortcuts no longer work for targets. They only position the node at the point relevant to the orbiting body, unlike in previous versions, which set the node based on the target (if there is one). It would be nice for this behavior to be restored.

In KAC 3.7.1.0 with KSP 1.1.3, the maneuver alarms don't seem to be working correctly. In the options, under maneuver node specifics, the default margin time seems to be ignored. Adding a manual maneuver node uses the default alarm margin. It does, however, add the half burn time correctly. When adding a fast maneuver node, in contrast, the configured margin is correct, but the half burn time is not added. This despite the fact that the time displayed on the flyout menu is correct. For example, with the margin set to 10s, and a maneuver with a half burn time of 6s, the flyout menu shows 16s, but the alarm actually added is only 10s. The they have inverse problems - one ignores the margin setting, but doesn't ignore the burn time setting, while the other respects the margin setting, but doesn't respect the burn time setting. I hope I've made that clear enough.

129,600 LF 158,400 Ox 24,000 Mono 168,000 Xenon If I were to start over, I'd go for a lot of LF-only tanks, as I draw way more of that than LF+O, due to nukes.

A lot depends on what techs you have available. Provided you have docking ports, you lander only needs enough fuel to get down and back up again. The rest stays in the transport ship that you re-attach to after leaving. Of course, if you're trying to maximize the amount of science you get, you can still have a monstrous lander. An asparagus hopper for Minmus is a good way to get a chunk of science once you've unlocked decouplers and fuel lines. And if you want to get the most out of your science, you don't transmit, but return it to Kerbin. That throws re-usability out the window, unless you get fancy with where the instruments are attached, or stick with capsule data that can be transferred (basically reports and surface samples). For me, a big part of the fun of the game is figuring out how to get [URL="http://oi68.tinypic.com/1yvm07.jpg"]particular monstrosities[/URL] into orbit, so I'm always coming up with something new for future missions. Quite beyond that, landers are hardly universal. A lander suitable for Minmus isn't going to be worth a damn on Duna. As a general rule, worry more about weight than aerodynamics. You'll want a fuel depot in low orbit to fill up large interplanetary craft that you launch empty, with a launch stage that has just enough fuel to get it to the depot.

Getting to Moho is easy. Staying there is a bit harder. Returning is difficult. I managed the first two not long after I got the game (0.23.5), with no mods, using the only method that came to mind - leave the SOI of Kerbin, then use maneuver nodes with the next-orbit button to find a Moho intercept. I had managed to get out of Moho's SOI, but needed to send a rescue ship with a claw to retrieve the science I had collected. That was an interesting exercise in and of itself.

So KSP updated while I was playing (don't launch through Steam, so it didn't "know" I was playing), which caused it to crash while I was in the middle of an atmospheric flight on Kerbin. When reloading the most recent quicksave, the plane was on the exact opposite side of the planet from where it should have been, with respect to KSC, as well as having zero velocity. I reloaded a previous save to avoid that problem, but I'm curious what the nature of the bug could be. Did something about the coordinate system change?

I mostly use the Mk2 lights to illuminate docking ports on the ship, so night-side rendezvous are not absurdly difficult. The Mk1 lights are generally landing lights and rover headlights, though I've also used them on asteroid fetchers (along with Mk2's, so I can avoid washing things out when close in).

I found this while trying to aerobrake under 40km from the Mun (which worked fine before 1.03/04, but doesn't now). My Goo canisters (and other bits afterwards) were exploding with no indication of heating at all (no gauges, no color difference on temperature overlay). Though while explosions were happening, I did see flashes of temperature gauges. And the gauges also do show very briefly when switching between map and ship view. The upshot is, you can't see when parts are overheating. Update: You can make the gauges flash briefly by pressing F10 twice to toggle visibility off and on again.

KER isn't handling the case of opposing and disabled engines in the same stage correctly. Consider this example, which is a Mun lander attached head-first to a transport ship. With both engines on, KER shows all information (total DV, maneuver burn time, etc.) as if the engines were pointing in the same direction. With the lander engine off, current DV and Isp display as 0. The total thrust is then reported correctly. Maneuver burn times are still displayed as if both engines were enabled and pointing in the same direction. Here's the vessel extracted from a save, and the full save. The '1' action group toggles the lander engine. Dragging the disabled engine to a separate stage seems to work around the problem entirely.