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.

When you select the IVA of a pod, control is changed to that pod. If you're in the middle of an atmospheric reentry, with SAS pointing retrograde, and the pod in question is facing the other way entirely, you can see how this would have bad results. IVA should not automatically change where you're controlling from.

Press F10 to hide the heat gauges, and the memory will stop leaking.

After fulfilling a rescue mission and landing the vessel, recovering the vessel results in no recovery screen, and the KSC scene is frozen. I have to leave and reload the game for it to function again. The behind-the-scenes part of the recovery seems to be working correctly - the contract rewards, recovered parts, and new crew member(s) are recognized. Here's a snippet from the log of my most recent such recovery: [LOG 10:38:52.005] Awarding 53460 funds to player for contract completion [LOG 10:38:52.006] Awarding 9 reputation to player for contract completion [LOG 10:38:52.007] Added 7.311299 (9) reputation: 'ContractReward'. [LOG 10:38:52.021] [Vessel Fersel's Pod]: Destroyed. No crews were aboard. [LOG 10:38:52.024] Contract (Rescue Fersel Kerman from orbit of Kerbin.): Well done! Fersel Kerman has been recovered in one piece and is now enjoying a thorough debriefing from the comfort of his quarantine cell. Fersel Kerman is now part of your crew roster, and may be assigned to future missions. <b><#8BED8B>Completion Rewards:</></> <#B4D455>£53,460 </> <#E0D503>¡9 </> [EXC 10:38:52.028] NullReferenceException: Object reference not set to an instance of an object AnchoredDialog.setOpacity (Single value) KSCVesselMarker.onInputLocksModified (FromToAction`2 inputLocks) EventData`1[GameEvents+FromToAction`2[ControlTypes,ControlTypes]].Fire (FromToAction`2 data) InputLockManager.SetControlLock (ControlTypes locks, System.String lockID) MissionRecoveryDialog.Awake () UnityEngine.Object:Instantiate(Object) MissionRecoveryDialog:CreateFullDialog(ProtoVessel) VesselRecovery:OnVesselRecovered(ProtoVessel) EventData`1:Fire(ProtoVessel) VesselRetrieval:recoverVessel(Vessel) VesselRetrieval:recoverVessels() :MoveNext() [LOG 10:38:52.032] [VesselRecovery]: Fersel's Rescue recovered At KSC. Recovery Value: 98.0% [LOG 10:38:52.032] Crewmember Fersel Kerman is available again [LOG 10:38:52.034] Added 0 (0) reputation: 'VesselRecovery'. [LOG 10:38:52.037] [Research & Development]: +1 data on Recovery of a vessel returned from Kerbin orbit. +0.0 Science Added. Subject value is 0.00 [LOG 10:38:52.040] Flight State Captured [LOG 10:38:52.044] Saving Achievements Tree... [LOG 10:38:52.045] Saving Achievements Tree... [LOG 10:38:52.046] Saving Achievements Tree... [LOG 10:38:52.064] Game State Saved to saves/Thanny_1_0/persistent At that point in the log, the KSC scene is no longer responding to input, necessitating a reload. The mods I have installed: Blizzy's Toolbar Distant Objects Enhancement Editor Extension Enhanced NavBall Kerbal Engineer NavBall Docking Alignment Indicator Precise Node TAC Fuel Balancer Kerbal Alarm Clock Transfer Window Planner

I meant when both ports are radial. On my fuel station, the big port is axial, but the standard and mini ports (and claws) are radial. My interplanetary ships, which I launch essentially empty, also have radial ports. It's hard to see how one could reliably dock two large vessels with both ports offset by 90 degrees from the only source of thrust. It would actually be not too bad if the port were at the ship's CoM, as you could thrust at the target then pitch the ship so the port rotated to the front. But none of my ships are like that.

Up to a couple days ago, whenever I wanted to dock two vessels together, I mentally designated one ship the docker, and one the dockee. The docker maneuvered around the dockee to line up the docking ports. Then I had a ship dropping off a base at the Mun which had quite a bit more fuel than it needed for the return flight to Kerbin. As it happened, I also had another ship in orbit waiting to return a large rover back to Kerbin. It probably had enough fuel, but it certainly needed more than the other ship. So I decided to dock the two to transfer fuel, at which point I noticed that neither had any kind of RCS. After a very brief amount of time thinking about it, I figured I'd just arrest all relative velocity between the two ships after they were close enough, then point their docking ports towards each other, and give a short engine burst to get one of them moving (both ports were axial). It worked perfectly. So perfectly, in fact, that I sat there wondering why I hadn't been doing that all along with all docking operations. Sure, not all ships have axial ports, and main engines are worthless for radial ports. But once you control from the docking port, RCS automatically thrusts in the correct direction based on translation controls. Get to zero relative velocity, control from the docking ports, aim towards the target (each ship targets the other), then close the gap. With especially large ships, you need to switch back and forth adjusting the aim, as the slow speeds you want to be using between two behemoths give time for the different orbital paths to change relative orientation. In particular, it's shockingly better when docking a large tanker to a large fuel station (>1000t each). Previously, I'd burn up hundreds (if not thousands) of units of fuel maneuvering the tanker into position. Now I just burn at target retrograde until relative velocity is 0, then switch back and forth between station and tanker, pointing each to the other's targeted docking port, until the two docking ports are facing each other and square. A short burst of RCS to close the gap, a few minor adjustments back and forth, and they're docked, after using a miniscule amount of fuel. I could even get away with no RCS at all if need be, using just reaction wheels and main engines (with the latter tweaked to minimal output, of course). So, am I the only one that did it the hard way until the easy way became the only way in a certain situation?

As I see it, these are the things that need to be done to make rovers viable: 1) Variable acceleration. Rather than only 0% and 100% as wheel powers, make some kind of throttled speed control. It could be an additional throttle, or just have the wheel power ramp up as the key is held down longer. 2) Variable braking. Have brake pressure increase the longer the button is held down, rather than being on and off. 3) Variable steering. Like the previous two items, this is either straight or hard left/right, which makes it impossible to safely steer at speed without reaction wheels (i.e. it's better to tap the rotate button than try to steer the wheels). Steering more in a given direction with a longer key press is an option, as is making it persistent with a new key to center the wheels (i.e. steering works more like a throttle from left to right, with a shortcut to go completely straight). 4) Bearing friction. Right now, wheels spin completely freely with zero friction, which leads to absurd speeds going downhill (I recently got up to >53m/s on Minmus). Make rover wheels more like Earthly EV wheels - when not actively applying power, they use regenerative braking (and yes, that should recharge batteries a bit). Doing this makes a better case for having a dedicated wheel throttle instead of a gradual increase on keypress, since you'd need to have constant throttle to even go downhill. Being able to disable brakes on the fly would be a helpful addition for the interim, as it's easy to forget to set the action groups before launching. So, has there been any indication that changes like these are planned for KSP at any point in the future?

If you can't build low, because the whole point of a rover is carrying (sometimes large) bits where you want them, try outriggers with wheels off the ground to prevent tipping. Works reasonably well on my current Minmus rover. I'd probably add them to the front and back as well next time, as I neglected to disable the front brakes, so it's challenging to stop it. Always have reaction wheels. Put SAS on when moving fast, but remember to reset it (with the momentary SAS key) periodically so it stops trying to pitch into the ground when the slope changes. It's main use is to keep the rover pointed the right way when it gets chucked skyward from bumps, turning, braking, etc. And if you're already going to be adding big objects, throw in a fuel tank and some engines. You might need to jump fissures in the geometry on Minmus, or power out of a crater on the Mun that you just can't drive up. Also handy for those scanning missions where you need to be above a certain altitude -drive to the spot, then shoot straight up to the correct altitude. For below a certain altitude in flight, just leave the ground for a second. Stick with either the small gear bay or the Ruggedized wheels. The RoveMax wheels are great at absorbing terrain changes, but their absurdly low top speed of 30m/s, coupled with a complete lack of wheel friction on hilly terrain, means you'll be spending a lot of time trying to brake without crashing. Probably the best advice is to save often. Use Alt-F5 to make named saves, so if you want to revert some driving you can. If you're going at a good clip, you can often still save when the rover leaves the ground. Make sure it's going to be above the surface for at least a couple seconds, and use Alt-F5 instead of just F5, so you don't kill a good quicksave with a potentially disastrous one. The reason you need a couple seconds of air (or vacuum) is that on reload, the physics engine doesn't work properly for those couple seconds, and if your rover touches the ground, it will bottom out and be destroyed.

I'd like to add a couple points. First, the information about changing aerodynamics clearly expressed Squad's desire to not obsolete existing designs. People are not going to have to start from scratch with every rocket. Second, I don't think many people understand the significance of the TWR drop, if the current thrust becomes max thrust, rather than initial thrust. The KR-2L probably gives the most extreme example. If you have a ship weighing about 195t powered by a single KR-2L, your current TWR is 1.3, which makes for a bit of a slow start but works quite well. If you make the current max thrust the vacuum max thrust, then your TWR with the same ship drops to 0.96, and you won't even get off the pad. It is a big deal which will require massive changes in ship designs, which is something Squad has said they don't want to force on people. So it's very likely the changes to engines will be more extensive, so that a good chunk of existing rockets can still fly. KSP is, after, intended to be a game first and simulator second.

While it's more realistic, it's going to ground a lot of rockets. With only a fraction of the rated thrust available at sea level, TWR at the launchpad is going to fall well below 1.0 for a huge number of designs.

Multi-threaded physics will be, by far, the most important change. Right now the game is virtually always bottlenecked by the CPU (no matter how fast it is) once you start building ships bigger than middle-size. Stable 64-bit would be the next bigger thing, though that would be less important without the memory leaks currently in the game, until you start loading lots and lots of mods.