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.