michelcolman

Sorry I didn't reply for a while, but I am still occasionally having the problem with the latest release (1.1.0.1230), without any mods whatsoever, clean install of the game. It seems to occur less often now, but maybe that's just an impression. Anyway, it's easy to fix: whenever it happens, I close the lid of the laptop, wait for it to go to sleep, open it up again, and see whether or not it's fine. Sometimes OK right away, sometimes needs a second attempt. So if I'm the only one reporting this problem, I suppose I can live with it. Sluggishness is less pronounced in map, I suspect it's video related. Possibly the integrated graphics are being used instead of the discrete graphics (my 17 inch MacBook Pro has both integrated and discrete graphics, supposedly switching automatically between the two). But that's just a wild guess.

That really is an interesting mission. I wonder what would be the most efficient way of accomplishing it. Slingshot way out to somewhere around Eelo so you don't need so much delta-v to get to a standstill, plummet towards the sun and slingshot around one of the inner planets to a retrograde orbit? Then you're still nowhere near the stranded astronaut of course, but at least it will give you a big chunk of the required delta-v. In any case, you are completely right that this should not be a one star mission :-)

That's another way of doing it, indeed, but still a whole lot more work than landing on Minmus at a location of your choice and planting a flag. And if you're picking up the module using a rover, that rover will have to dock to some bigger ship to make it back to Kerbin and survive reentry. So no matter how you do it, the reward is way too low.

Yep, noticed this as well. Very strange.

There's a bug (which I reported a couple of weeks ago, #8690) where text will be too small if you start a flight while in 120% UI scale. If you start in 100% UI scale and then switch to 120% from the in flight settings menu, the text is a lot larger and nicely readable. Basically: Start in 120% then switch to 100%: unreadable Start in 120% and stay in 120%: barely readable Start in 100% and stay in 100%: OK (like in 1.0.5) Start in 100% and switch to 120%: Nicely readable (a bit larger than 1.0.5) Whenever you go back to the Space Center, make sure you set 100% again before starting or switching to another flight. I stopped using 120% due to this hassle.

I got a contract to recover a module from the surface of the Mun. I accepted it because it looked like a nice challenge, and finally managed to complete it after lots of trying and quickloading. Either I did something wrong, or this is WAAAY more difficult than, say, planting a flag on Minmus which yielded more money and reputation. I think the reward for this recovery contract should probably be a lot higher. Recover a module from the surface of the Mun: advance 81,237, completion 185,595, and 16 reputation stars Simply planting a flag on Minmus (anywhere at all): advance 79,875, completion 199,375 and 16 stars as well. When you start out, you don't even know what you will be recovering, you have to fly over and look. It turned out to be a Swivel engine standing upright in the middle of nowhere. So I flew there with a rocket that had a last stage consisting of a brown fuel tank, eight thuds near the top (to avoid blowing away the module), a claw at the bottom, and RCS thrusters. I first had to navigate to the precise location, come down, hover in the vicinity of the module, with the nose perfectly up (without mods like Mechjeb's SmartASS), then used RCS to move over the module. Positioning had to be extremely precise, this is much harder than docking because of the gravity. I viewed the rocket from such an angle that I could see the left/right position and height directly, and used the shadow on the ground to judge forward/aft. If I wasn't precisely above the thing before trying to pick it up, the claw wouldn't engage and the module would just fall over. In fact I almost gave up because I thought the claw would never pick up such an item. But finally it latched on after dozens of quickloads. Then I had just enough fuel left over to make it into Mun orbit, so I launched a refueling mission to dock with the first one to refuel. Fortunately I had thought of including a docking port. Then I had to get the module back to Kerbin without burning it up on reentry. Used a very shallow reentry with retrograde burning keeping things just below overheat until I could deploy the chutes. I guess I could have transfered the engine to a different craft with the claw at the top and a heat shield at the bottom, or I could have started out with a heat shield at the top of my initial rocket, but anyway, I made it down in one piece. It's certainly doable, but the reward should have been way higher than for a simple Minmus landing which I normally get right on the first try. Picking up that Swivel engine took dozens of attempts. Or is there some sort of easier method that I missed? Michel

When you're flying a tall, wobbly rocket, the trajectory lines jitter about and it's very hard to plan precise course corrections for distant intercepts and flybys. I initially thought the jittering was just due to rounding errors causing uncertainty, but today I found out it's caused by wobbling of the spacecraft, which really ought to have no effect on its trajectory since the wobble does not affect the center of gravity. Apparently, the projected trajectory lines (orbits) are based on the current speed of the cockpit (or root part) while they ought to be based on the speed of the CG. Apart from the obious annoyance from this jittering, this error can also be exploited to gain free energy because when you activate time warp, the currently displayed trajectory line is fixated and the craft ends up actually flying that trajectory. I used that trick today to get an escape trajectory out of Minmus using only the reaction wheels. I had a contract to activate an engine on an escape trajectory out of Minmus, but the previous stage ran out of fuel when I was still in orbit with a 1400 km apoapsis. So I started to wobble the rocket using "A"/"D", the apoapsis went up and down between 1450 and 1350, I did my best to press the period key at the right time and got a 1420 km apoapsis. Back out of time warp, wobble again, time warp: 1435 km. I got it all the way up to escape trajectory step by step (above 2000 km!), so I could activate the next stage in the required conditions and finished the contract. The time warp trick does not work if the wobble is too intense (cannot activate time warp during acceleration), but once the intensity of the wobble has decreased somewhat, it does work. I filed bug report 9131.

I wrote in my bug report that it was probably just an adjustment to a single line of code, but they replied it would be a lot more. I'm having trouble imagining this, though. I would asume the code fetches the orientation of the new trajectory and applies that transformation to the node. All that needs to be changed is "fetch the orienation of the old trajectory". How much harder can it be? That's one function call! Maybe the code got duplicated in two or three places due to poor coding style (which I'm frequently guilty of too, so perfectly understandable), maybe its orientation is set when clicking, when dragging, when updating the map view,... but surely that's it? A few identical lines that do the same thing and need the same change? All the handles do is change the respective component of the node. You can see the values change in the Mechjeb maneuver node editor. I originally thought (based on the weird orientation of the node) that there was some kind of complicated calculation going on with the handles acting relative to the new trajectory (something like transformation matrices that either have the old coordinates of the new base vectors or the new coordinates of the old vectors) but no, each handle just modifies the delta-v in that direction, relative to the original trajectory. Nothing more complicated than that. So all that needs to change is the display orientation of the node so the handles match what they actually do.

It's in the prerelease as well. The "intuitive maneuver" option in PreciseNode does something different, not sure exactly what, and whether or not it was a good idea, I never tried it. I don't think it changes the behavior of the original nodes. There appears to be a different mod that does fix the issue, though, but I don't know it if still works. Bug reports: There already was a report in the bug tracker for the released KSP: http://bugs.kerbalspaceprogram.com/issues/3953 And I added a new one for the prerelease: http://bugs.kerbalspaceprogram.com/issues/7860

Hi everyone, I'm just posting here out of frustration that nobody seems to take bug reports about the illogical behavior of maneuver nodes seriously. They get downgraded to "feedback" and low priority, even with the explicit mention that this is unlikely to be changed since it doesn't break the game and users seem to manage just fine. The problem is as follows: When you add a perpendicular input (normal or radial) to a maneuver node, the handles rotate to align with the new trajectory. However, their effect is still relative to the old reference frame which creates a very counterintuitive experience. Rotating the maneuver node handles is simply wrong. They don't act in that direction, so why make it seem so? Is there any vaid reason for prefering this behavior over the much more logical alternative that keeps the node aligned with the original trajectory? Example scenario: - User is in an equatorial orbit (let's call it "horizontal") and wants to transition to a polar orbit - User pulls the "normal" handle (triangle) - The post-maneuver trajectory rotates around until it approaches vertical - Meanwhile , the triangle handle rotates and approaches horizontal. It is pointing exactly in the direction where the user wants to pull the trajectory to reach a polar orbit. - So the user pulls the normal handle some more, but the trajectory does not move in that direction, it just stretches out further upwards - User visits the forums for help - Someone points out that he needs to add retrograde - User is confused, because the retrograde handle is pointing downwards. He tries it anyway, and low and behold, it works, who would have thunk? Must be some weird mathematical reason behind it, orbital mechanics are apparently really complicated and counterintuitive, you probably need a degree in mathematics to figure it out so better just move on to a simpler game. Now compare this with the correct behavior that nodes should have: - User is in an equatorial orbit ("horizontal") and wants to transition to a polar orbit - User pulls the "normal" handle (triangle) - The post-maneuver trajectory rotates around until it approaches vertical, but the node stays put - User sees that he needs to twist the trajectory sideways now to get towards the pole. The retrograde handle is pointing in that direction, so he pulls it. - Great, the node performs the correction exactly as expected. See, orbital mechanics are easy, this is a fun game! So, once again, why would anyone prefer the former behavior? I've really been thinking about this long and hard, and can't find a single reason, not even a small one, for rotating the node. The more I think about it, the more flabbergasting it seems. Why would anyone prefer the current behavior? It makes absolutely no sense. I know that there are mods to correct this, but that's no reason for stock to be so wrong.

I'm really sorry, I've done some experimenting and I finally understand what's going on with these stock maneuver node gizmos. Even though for some weird reason the gizmos are twisting to match the new trajectory, the actual inputs are still relative to the old one! That's so counterintuitive it's unbelievable it made it into the released game this way and hasn't been corrected since. I just gave it a try: started with a circular horizontal orbit, used the stock gizmo to add lots of normal. Track twists up, normal vector now points to the right, but more normal only makes it go up more (NOT in the direction of the handle, but in the direction the handle was pointing in originally). Meanwhile the prograde handle is now pointing up, in the new direction of the trajectory. But if I now pull that handle upwards, it does not change the track in that direction but actually moves it towards the original prograde direction, so back towards horizontal even though you are pulling a handle that is pointing vertically. That's just so wrong it staggers the mind. Why does the gizmo rotate if it still gives inputs in the unrotated reference frame? The gizmo should just stay put! I was thinking that the handles were pulling the trajectory in the current direction of the handle, which would have meant that some kind of complicated calculation was going on behind the scenes with inputs being given in the new coordinates (handle pointing to the right means raw delta-v to the right), but I was overthinking it. In fact the maneuver gizmo is simply pointing in the wrong direction and all inputs are really given in the original reference frame. I think I'll file a bug report because that makes no sense whatsoever. I bet I won't be the first one, though. Anyway, that means you don't have to change anything to your code, sorry about the confusion!

I was thinking you could have a switch between "relative to old" and "relative to new" in the PreciseManeuver window which would only affect the display in that window. The stock gizmo will always show "relative to new", but the values in the PreciseManeuver window could be converted values that are relative to the old trajectory. Whenever you change those values, they get converted to the new trajectory for the actual maneuver node. If you change the maneuver node directly, those values get converted to the old trajectory in PreciseManeuver. So even if you can't change the stock gizmo, your window could give the impression of showing a node relative to the old trajectory, with transparent conversions back and forth. For a minute I thought that was what your "intuitive maneuver" did, but now it looks like that's something different after all? I understand what you mean, and it's true over long distances, but in the Jool system in my experience it really was very precise. I have indeed seen trajectories that looked completely different after adding and then subtracting 0.1 m/s, especially for interplanetary intercepts where the final result was nowhere near the prediction. But I've also seen trajectories that consistently moved in the same direction with successive inputs of less than 0.01, and the final flown trajectory matched the prediction. That was for small corrections over a timescale of a few hours in the Jool system.

That's strange, you can increment and decrement it but you can't get the current value? I haven't actually tried the current version of precise node/maneuver yet, and right now I'm running the KSP beta, but maybe "intuitive maneuver" already does what I was looking for. Just to make sure it's the same thing: the stock maneuver nodes have the annoying "feature" of lining up with the new trajectory rather than the old one. So as you input more normal component, the node twists around so that "normal" becomes something in between normal and retrograde. And if you want to reverse the direction of your craft with lots of retrograde, you can't because the node flips around when your predicted speed passes through zero, making prograde and retrograde switch places. It would be nice if we could use a node that remains lined up with the old trajectory so that 100 m/s "normal" really means "point the nose towards the triangle, then burn 100 m/s". But if that's what "intuitive maneuver" does, then great, you've already implemented it :-) I do use such minuscule corrections when I'm bouncing around in the Jool system. On my last trip, after setting course to Jool from somewhere around Duna, I used a grand total of 18 m/s to - get captured by Jool using a gravity assist from Laythe - pass through the Jool upper atmosphere using an assist from Tylo - set up further assists to get all high and low science from all non-polar biomes of the three inner moons. All of that with 18 m/s, so the individual corrections were just a few m/s each. In that context, 0.003 m/s can make the difference between exiting a moon's SOI precisely in the orbital plane, or ever so slightly out of the plane. I could really see the path jump a little with a 0.01 m/s change. The hyperbolic trajectories multiply the error quite a bit and make subsequent encounters (which also had to be as near to the orbital plane as possible) significantly more costly to set up. But anyway, if it's such a lot of work, never mind, I'll just keep doing it the old-fashioned way. Thanks, Michel

I'll give a couple of suggestions: - Maybe add the maneuver direction icons (prograde, normal, radial) to make it clear which one you're adjusting. - "Orbit mode:" would probably be better named "Conics mode:" since escape trajectories are not technically orbits. - Not sure what the "+orbits" and "-orbits" buttons do, does that change CONIC_PATCH_LIMIT? In that case it's certainly a good idea to include it, but it might be confused with the +/- buttons on the standard maneuver nodes which go to the next and previous orbits. Since it's changing a setting just like the "orbit mode" buttons that are directly above, it's probably better to add a label "Number of conics" for better visual consistency, or even better "Display 3 conics" with "+"/"-" buttons behind it that change the number. - Can you also display the three individual delta-v components instead of just the total delta-v? And maybe to a higher than 0.1 m/s precision. With atomic engines, I often make really tiny adjustments by pressing shift and immediately X again. Nice if you want to leave a gravity assist trajectory exactly in the orbital plane, for example. Doesn't matter much when you're just going to the Mun, but makes a huge difference when pingponging in the Jool system. - Stock maneuver nodes are relative to the new path for some reason. When you add a normal burn, the node axes twist around so that the normal vector is really applying some unwanted retrograde. It would often be useful to define the node relative to the old path. I understand it may take a lot of work to convert between the two, but if it's at all possible, it would be a great addition if users could switch between "relative to old" and "relative to new". (The actual node will probably always be relative to the new path, but your window could display and manipulate a converted set of values) - An "execute maneuver" button like the one in Mechjeb would be nice, too. But try to make it more precise, Mechjeb's execution only has about a 0.1 m/s accuracy, so I usually have to do the last bit of the burn by hand to get exactly the path I want. That's all, should only take you 5 minutes or so ;-) Thanks! Michel

Almost two months ago, I gently landed an asteroid at KSC, right in the middle of the R&D department (on purpose), does that count? No mods, Science mode.

This challenge thread seems to have gone quiet for a while, so I think I'll go ahead and grab first place while I can :-) At least temporarily, because I'm sure somebody will beat it given enough patience and time. I could have gotten a lot more with better planning and more patience. I got a grand total of 38330.6 from a single vessel, without any docking. And: this was during an actual career game, without editing the save file! A lot of science had already been done and was no longer available, making the challenge a little bit harder. I used Mechjeb for its delta-v display, orbital info, setting up some of the Hohmann transfers (out of laziness), but especially for manually editing maneuvers to high precision. I love how you can tweak maneuver nodes with 0.01 m/s precision, and sometimes even less than that! I also installed VOID later on during the mission just to see which biomes I was passing over. I didn't initially because I felt it was cheating, but at some point I really felt "this is ridiculous, incessantly clicking that little button to get the last elusive biome and doing it over and over again, why am I wasting my time with this?" and got VOID. The mission didn't start out as a challenge mission, in fact I just wanted to fulfill a few contracts on a mission to Eve and Gilly: put a satellite into Eve orbit (the whole rocket was the satellite, which explains the cupola, hitchhiker's cabin and unused docking port), gather science around Eve, land in four places on Gilly. And while doing all that, I also wanted to get as much science as I could to finish the tech tree. The rocket in a nutshell: fourteen of the biggest fuel tanks with seven Mammoths underneath, 18 solid fuel boosters, 13 brown tanks with nukes (no oxidizer in those tanks), a few reaction wheels, 12 cheap solar panels, a hitchhiker module, a cupola (because of the Eve satellite contract), a small docking port (also for that contract), some parachutes, a Science Jr., and a service bay containing Goo, atmosphere analysis, gravity monitor, pressure monitor, seismic thingy, and a battery. Oh, and a thermometer of course, and probably some more stuff I forgot to mention here. I made a mistake placing the ladder, so the goo was just a tiny a bit too far away for a scientist to reset. That meant I had to EVA from the ladder to the goo and back every single time. That's a mistake I won't make again :-) I took Bob, Bill and Jeb but I might as well have left Bill home since he didn't do anything during the entire mission. Launch took a bit of babying because of collisions with the boosters during staging. I had to cut the engine, stage, wait a few seconds for the boosters to clear, then throttle up again. Took a few attempts to get it right. I didn't bother with asparagus staging (which would not be very realistic anyway, no pump can transfer that amount of fuel that quickly) Anyway, so I went to Eve, got into orbit, went through all biomes in high space, low space and upper atmosphere (getting lucky on some of the rarer biomes like impact ejecta since I didn't have VOID yet), then went to Gilly, got science for all biomes high and low, landed in the four required locations for the contract, then landed in the remaining two biomes for some extra science. No need for a landing gear, I could just balance on the middle engine using the reaction wheels and smartASS while Bob gathered the science. When that was all done, I still had an enormous amount of delta-v left over thanks to the highly efficient nuclear engines, much more than I had initially expected. So I thought I might as well pop over to Jool and play some ping pong there until I ran low on fuel. I remembered getting 6000 science points there during an earlier science game without even trying hard, and it sounded like fun. To get from Gilly to Jool, I left Gilly's sphere of influence, had MechJeb set up a transfer to Kerbin and tweaked that into a beautiful textbook gravity assist (150 degrees or so course reversal), then manually set up another one at Duna (after a few years of orbiting Kerbol), which got me to an orbit about the size of Duna's but intersecting it in two places. I got some more science while passing Duna, but I already had most of it from an earlier mission. From there I just made a normal burn for Jool, losing much of what I gained from the gravity assists since I was burning less efficiently from Kerbol orbit, but on the whole I must have saved somewhere between 500 and 1000 m/s compared to a straight Hohmann transfer from Eve orbit. And the Jool entry was easier with less speed to bleed off. The pingponging around Jool went much better than I expected. Starting from the interplanetary halfway point, I used a total of only 18 m/s to: - Get captured by Jool using a gravity assist from Laythe - Get all science from Jool, high, low and upper atmosphere - Get science from all non-polar biomes on the three inner moons, low and high. I didn't go for the Laythe atmosphere because that would have required entering orbit (passing through the atmosphere on an escape trajectory is considered in space low by the game) and I didn't feel like spending that much delta-v for that. The gravity assists during this part were quite a lot of fun, really. I used MechJeb's maneuver editor (not the planner) to set up the flybys as accurately as possible so the outbound trajectory was always in the orbital plane and I went low enough to get all the science, while keeping the resulting Jool orbit useful for further bouncing around. I let MechJeb execute the first part of most maneuvers but then did the last m/s or so by hand with just a tiny bit of engine power to kill the engine when the trajectory was exactly where I wanted it. This way, I could really execute them to 0.01 m/s precision. The last pass over Tylo is when I installed VOID. Those craters were just taking forever to catch and, even though I could do it by repeatedly quickloading and flying the same trajectory over and over again while incessantly clicking the gravity scan button and noting when the biome changed, I figured I had better things to do with my time. During the mission I picked up a few extra contracts. Always fun to see a "return science from Tylo" come up while you're in the neighbourhood anyway. Ka-ching! OK, so now all the low hanging fruit around Jool was picked, and I still had lots of delta-v left. So I went for Pol, which is a bit further out than Bop but closer to the orbital plane of the other moons. With the low speed so far away from Jool, I decided to enter a polar orbit to get all biomes high and low. Then I thought, well, with still so much delta-v left and plenty of power from the four active nuclear engines, I might as well see if I can land there. It took a couple of attempts but actually wasn't that hard: as long as I touched down really, really gently and perfectly upright, the reaction wheels were strong enough to balance the rocket on its middle engine on a slope. If I touched down a little too hard or got a couple of degrees off vertical, the rocket tipped over and I had to quickload to start over. Funny thing, at one point the rocket started sliding down a hill but somehow the SAS managed to keep it upright, so I could let Bob go down, get science from the surface, and chase the sliding rocket to get back in :-) Hey, a new contract just popped up for landing on Pol... Yep, can do, in fact I'm already there! :-) OK, when Pol was done (landed in all biomes), I went for Bop. I didn't land there since it has more gravity and I had now staged the four outer nukes. I did get all the high and low biomes from a polar orbit. So, what's next? Still plenty of delta-v, those nukes are incredible! I could have gone back to Laythe to get its atmosphere, and maybe the polar biomes that I skipped on Laythe and Vall, but then I had a look on Alex Moon's KSP Launch Window Planner website and saw to my surprise that Eelo was just about a thousand m/s away, with a transfer window coming up in a few years! That would be a much better use of my remaining fuel. So I had MechJeb set up a transfer (which didn't really match the Launch Window Planner but was good enough, and I didn't feel like trying to find a better solution manually) and then tweaked it to arrive in a polar orbit. Got most of the biomes relatively quickly, then spent ages getting the craters. Just two little craters on the whole planet, seriously?! They're easy to get from an equatorial orbit but a lot harder from a polar one... Fortunately at least they are clearly visible, so I finally managed to pass right over one of them twice, high and low. So now what? By now I was frankly getting really bored of all the science hunting. I briefly considered a chain of slingshots all the way down to Moho, it looked like I might have enough delta-v left over if I played it right, but finally I decided I had had enough and just went home. I could always revisit the quicksave file later if I changed my mind. Kerbin entry was uneventful. Phew... glad to be home again, that's not the kind of mission I'm likely to ever do again. And I'm not just saying that to keep others from breaking my record ;-) Edit: the mission started during year 4 and ended in year 57. Good thing Kerbals don't need much food. Real life time 20 days but not playing every day of course. No idea how many hours I spent on this. I had about 800,000 funds left when I took off, and more than 5 million when I got back, even after I upgraded a bunch of buildings during the mission. If you ever do a long mission like this, make sure to regularly pay a visit to the space center to see if any new contracts popped up that you can fulfill right away.

Even if it doesn't have a direct measurement of control authority, it should be able to detect right away that a control input is havig a huge effect, and reduce its inputs accordingly. But that's not the only problem: even on craft with more limited control input, it still does a very poor job. For example, while facing about 10 or 20 degrees off retrograde and clicking prograde, you would expect the indicator to start moving directly away from the retrograde symbol. Instead, it starts to move in some other direction, often perpendicular to where it needs to go, then starts arcing towards prograde, still accelerating until it passes prograde (not through it, but 10 or 20 degrees to the side of it), then starts slowing down and arcing back to prograde again, usually going through it on the second pass but overshooting it again, coming back and overshooting a third time, etc. It can take minutes to finally stabilize, especially on ships with underpowered reaction wheels. It just keeps accelerating until it's really close to the target and there's no way it can stop in time.

No, the mouse rotates the camera exactly like the arrow keys do. You still can't rotate the view sideways while looking at the top, or rotate around the center while looking at the side. Just to make it more clear: imagine in the map view you would like to look at the side of the solar system with the orbits going up/down. That's impossible, you can only go from circles over ellipses to horizontal lines and then back via ellipses to circles again. No way of getting them to vertical lines. Now of course there's no need for that in the map view, but when looking at your rocket you sometimes really want to point it in some orientation which is rendered impossible because of how the camera works. No matter whether you're using mouse or keys. Sometimes the only place I can get to see the mystery goo is right behind the attitude indicator (OK, I can hide it, but still).

I use the track pad on my laptop. Clicking with two fingers is like a right mouse click, but I guess I have to download some utility to allow a center click.

A, OK, "Locked" does indeed correspond to an axis of the ship. Not the most intuitive one for a rocket (full up shows one side of the rocket, full down shows the other side, so to look at the top you have to aim somewhere in between and then rotate until the top is at the top) but at least it doesn't move about while you're flying by a planet. So I guess that part is almost OK, I just wish they'd picked a different axis. With gimbal-less, I mean that it shouldn't be based around some particular axis, like the gimbals of an oldfashioned gyroscope. The camera currently works as if it were connected to gimbals. When you're in certain orientations, it becomes very difficult to rotate in a particular direction you want. For example, after moving the camera full up, if you then want to rotate the object sideways, you can't do that directly because left/right rotates around the center of the screen (you are looking along the axis of rotation). So you have to rotate 90 degrees around the center and then rotate up/down to look at the part you wanted to see. But if you now want to rotate this image around the center of the screen (for example because the particular part you want is obscured by a window), that's impossible again because now left/right does what you wanted it to do in the first example, rotate the view sideways. In fact there is no way of getting the object into the orientation you really want. Just take a tall rocket and try to get a particular side of the capsule into view (for example the door of the capsule visible somewhere around the right hand side of the screen). It's really, really hard if the gimbals are pointing in an awkward direction. Very often you just want to rotate "up" a little further but you can't because you're already fully up. I wish there would be a way of controlling the camera that worked like w-a-s-d on the attitude indicator. Pitch and yaw rather than heading and inclination.

Yes, I do use it on a flat surface (I actually got burn marks when I kept it on my lap), and the fan starts to go down quickly after quitting KSP. Right now it's showing around 80% CPU and 150 "energy impact" (no idea what units that's in, but Safari is less than 10 while typing right now)

Hi everyone, Camera angles are driving me nuts. It can be quite difficult to rotate a large ship in such a way that some specific science item, near the top and far away from the center of mass, comes into view. To make the rocket rotate one way, sometimes you have to use the right arrow, sometimes the up arrow, and then when you almost reach the desired angle, rotation stops because the camera reached gimbal lock and you have to rotate 180 degrees right and then down again, looking at everything upside down but at least hopefully getting to see the item you wanted. And you get different results depending on the camera mode ("free"(?), "chase", "orbit",...) but never really quite the one you wanted. Would it be at all possible to make a gimbal-less camera that just rotates left and right when you use the left/right arrows, and up/down when you use the up/down arrow? And rotate around the center of the screen either with a modifier key or by pressing two arrows together (up+down = clockwise, left+right = counterclockwise or something like that). Basically, at any given time, pretend the gimbal axis is going up/down on the screen. It would make it so much easier to move the camera! And maybe "free" should be called "planet" or something like that, because "free" doesn't quite describe it. And you could add a "ship" one that is relative to the fixed axis of the ship instead of its direction of motion ("chase"). In fact, just that last suggestion would already solve a lot of my problems. When you're in space and want to conduct experiments, there should be a fixed camera gimbal that always looks at the rocket in the same way no matter which way it's going, which way it's pointing, or which orbit it's in. Top = capsule, bottom = engines. Pretty please? (BTW I know you can move the camera using the middle mouse button, but I don't have a middle mouse button and anyway an easier way of rotating the camera would still be welcome in any case) Thanks in advance! Michel

It already did that before I had MechJeb installed, and that's the only mod I have.

I had already set "SIMULATE_IN_BACKGROUND = False" in settings.cfg. But even if I hadn't, it still shouldn't consume resources while *paused*. SIMULATE_IN_BACKGROUND should only matter if you switch to another app while the game is still running. Anyway, just to be clear, I did set it to False and it doesn't seem to make any difference.

Also, it's not just SAS. Manually controlling a small pod can be next to impossible even with caps lock on. Instead of just reaction wheels on/off, we should have a slider controlling their torque so we can turn it way down if the craft has become much lighter.