haltux

I am curious about your results, and I'll try myself. Because I am not sure enough to stand against everyone (and maybe I have some north Korean ancestors), but my intuition is that this "gravity turn" does not help at all (for the specific goal of escaping Kerbin). The so call "slingshot effect" provides only the energy that you have put in the sling shot, that is the energy used to reach orbital speed. You get what you paid: to get potential energy you have to pay it in thrust, plus the price paid per second spend to fight gravity. The the best way is the quickest, straight to the sky. Well, I am no physics major... I could have missed something. Interesting question, anyway. I'll really check that.

BTW I'll stop hijacking this thread, to go back on topic, a good way to test artificial gravity in KSP could be that:

This whole tintin is very Kerbalesque. Look at the Dupondts:

Actually roidon_herrera is amazingly right. This page of tintin is in Gaumais, a dialect from the south east of belgium. That was the only version of this page found by Google.

This tintin is quite bad from the scientific point of view. Not as bad as "The shooting star" who is really terrible (even as little kid I was able to locate major bugs). However, the live description by tintin of its first EVA on the moon is epic. One of the best scene of all tintins I think.

That's the expected behaviour in strafe mode. In this mode to turn you have to use mouse to rotate the view and press the space bar to align kerbal direction with mouse view orientation You can change mode and go back to the usual turn mode by pressing a key. I can't remember which one, it is in the settings (toggle EVA mode or something like that). This is not a bug and should not be confused with what happened to beeblebrox (and once myself) where left or right makes you go forward exactly like if you were pressing the forward key.

If it were, then getting blutonium from Eve would be completely pointless. It would not even help you to leave Eve because nuclear reactors have low thrust. And if it were pointless but just a geological fact (which does make sense), it would not be specifically highlighted in the chart.

Just like in Tintin on the moon: engine thrust does generate artificial gravity, until Dupont is accidentally switching off the engine. (bonus game: guess in what language that is)

Yes, you are right. I missed that, sorry.

I guess it has been discussed to death on other threads, but one thing this diagram says is that nuclear fuel will have to be taken from eve, making it an extremely complex ressource to exploit. I trust Squad to make all that nice and enjoyable, but before that it would somehow make sense to get use to not having nuclear engines for free. Otherwise I guess it will be a little bit painfull the day we ressources are actually integrated in the game. EDIT: I made a mistake: you can get blutonium from rock as well.

Anyone who would never leave a stranded Kerbal to his fate.

Yes I did experience that once. I did not report the bug because once solved I could not reproduce it. I think I just went back to my ship and then quit and went back to the game and it solved the problem. You can try to switch between control modes as well (can't remember the key, check in the settings), which switch between strafe and turn when you use left and right. Sorry if that does not help.

There is a recent thread on n-body physics: http://forum.kerbalspaceprogram.com/showthread.php/29938-A-question-on-n-body-physics?highlight=lagrange Developers said (in a lost post I guess) that n-body physics would not be implemented because it raises problems with time warp. This can be easily understood. Patched Conics Approximation (current KSP model) allows exact predictions. It means that you can easily know where your ship will be any time in the future. Real n-body modelling does not allow exact prediction, you can only make approximations. Consequently, the behaviour of your ship will depend on the time warp mode. To know where you ship will be at the next frame, in normal speed, you compute the position of your ship a fraction of a second later. In maximum time warp, you compute the position of your ship (let's say) one minute later. The cumulative error will be much higher in the second case after the same amount of (game) time, whatever prediction algorithme you use. In terms of gameplay, knowing that the time acceleration changes the trajectory is difficult to accept. I don't know how Orbiter is handling that problem.

You are right, Splode, and I agree with comham. But I think than when you release an update with flags and chairs (no offense), you don't plan to completely rewrite half of you game (the rocket design), which I think would be required for a "realistic rocket" design.

The most obvious I can think of is the lack of proper drag model. It can be seen as a technical issue, and it has been clearly stated that it will change in the future. However, I guess it is also a gameplay issue. With a vaguely realistic drag model, the silly, fat, cathedral-like rockets that you can send now in orbit would become useless. Basically, rockets would have to look like rockets, and I am not sure most people would like that. I really wonder how squad will handle that. About the fact that only one body attract your ship at one given instant, my guess is that it does not change trajectory as much as you would think. The main difference it makes is that with this model, any trajectory is entirely predictable with extreme precision, which is not true in reality. If a multi-body gravity model were implemented, predicted trajectories would not exactly match with actual trajectories, which could be interesting. However, I think that devs said that it would not happen.

Maybe you will when you get your first thread lock. It has just happened to me, and honestly it feels more humiliating than being insulted by a random guy. Maybe that is the price to pay to have a forum that looks so polite. Just like in real life, being in a police state makes you feel more secure. Until you get hunt for no reason... Whatever. KSP is amazing and a lot of great people are hanging around here.

Hello all KSP fans, I am myself a huge fan of KSP but please let me rant a little bit. Sorry. I am fed up with the feeling of having rockets and space stations made of rubber. Fact: there is no way to apply a significant torque to any part of a rigid object in space by applying a force at a given point of this object. Not sure whether my english is ok here so I can rephrase it: if you push an object in space you don't bend it, you move it or you turn it. There is absolutely no reason (except collisions of course...) why any rocket or station should bend or dismantle in space. We should be able to build space station as big as we want, to build rocket as long as we want without worrying about their integrity as long as we managed to bring them to space. We should not have to use several docking ports or quantum struts, this is nonsense. I think I can go even further in this direction : rockets sould be completely rigid objects, not sets of objects linked with springs. This spring model is (I guess) complex, unrealistic, brings nothing to the gameplay, and most likely increase the risk of bugs (explainable spinning or wobbling...). I would be more than happy to get your opinion and the opinions of the dev on this point.

Thanks for the tip. I'll try that. But did you try to turn while flying?

Hello guys, You seem to be experts in EVA extreme manoeuvres. I have a problem when I tried to use EVA on MinMus, I was wondering if you had the same problem, and wether you had solutions. When I do a big jump, my kerbal start to slowly spin forward, he does not stay vertical. The problem is that I have no way to rotate him, to put him back in the right direction, except by pressing the space bar to reorient my kerbal. However, once I do that, I have to keep pressing it otherwise the kerbal starts spinning, and it consumes a lot of fuel. Any hints?

I don\'t think that this kind of real-time mesh-by-mesh modelling is the right approach. I could be wrong, but it sounds too ambitious and probably not very efficient. My opinion is that reentry heating (with associated destruction threshold) models should be statically computed at rocket design validation. For each potentially independant part of the rocket there would be different models computed (for example for a 2 stage rocket there would be 3 models:stage 1+2, stage 1 and stage 2). Each of this models, once computed, would be no more than simple functions altitude, attitude,speed -> heat. Of course that would not be completely realistic, but that would be good enough or a game. And that would be very cheap in terms of real-time computation. Anyway, I think even the most basic heating/destruction model would be much better than nothing. Entering kerbin atmosphere at whatever speed and whatever angle with whatever rocket and just opening the parachute to be 100% sure to go back home safe is killing half of the game right now (the trip back part).

There is an alternative approach that works fine for Minmus. Take a circular orbit around Kerbin, similar to the one of Minmus, just a bit smaller. Eventually you catch up with it. You can improve this technic by taking a significantly smaller orbit to catch up Minmus faster, and enlarge it when you get closer to Minmus (spiral trajectory) Of course it makes you waste a little bit of energy and a lot of time. But at least it works 100% times and does not require a hasardeous and not very natural 'trick' like the minmusrise one. It works also for Mun, I actually went there like that the first time. But it makes less sense considering that any elliptic orbit which brings you far enough will bring you tu Mun anyway in three or four orbits at most.

I get your point. However, your reference to Apollo is incorrect. Apollo Nav Ball used several modes, the main one providing absolute directions. Other modes being made for specific manoeuvres. http://nassp.sourceforge.net/wiki/CSM_FDAI

Yes, that\'s about it. I use to be carefull when I make this kind of assumptions, but most suggestions that has been made in this thread are pretty straightforward to implement. It is clear that the two first ones of my initial post (same point of view when switching view, displayed vector in orbital map), and the true 'apollo style' global Navball would not be a problem. But I can understand that developpers are thinking twice before making any kind of change in the interface. People don\'t want the interface to change at each version. When things are changing, some people does not like it and complain, and so on...

It is possible to do anything with the keyboard, and it is not much more difficult than joystick with intensive use of SAS and RCS, but there is no doubt that in terms of fun, joysticks are a must have. It is probably not that much important for orbital manoeuvres, but for landing, the joysticks makes the game much more immersive. And the throttle is at least as much important as the main stick. Most current joysticks have one, though (but you should really check).

Actually, in the thread 'Is the navball global?', Temstar is describing the Apollo navball, and it seems similar to what I described as 'space navball':