haltux

I am amazed! Thank you all, that was the problem. I was starting from Minmus and making the main burn once escaped. Now I tried going back to Kerbin just for a fly by, then going straight to Jool, and it worked great. It made it a little more difficult to time everything for an optimal trip Minus-Kerbin-Jool but it was worthing it. Now I realize how awfully difficult it became to aerobrake at Laythe since last time I tried (which was many years ago). But that's another problem...

First, thanks for all your answers and sorry for not having reacted faster. My issue is the cost of the trip to Jool. I said it takes 4500 m/s to orbit, that was a rough estimation, I know it depends of plenty of parameters, so let's say I just said somethin wrong, that was not the main post of my question, sorry for those who took time to anwser to me on this. But for the Jool transfer I am still not understanding what is wrong. Here is a screenshot, not from Kerbin but from an orbit around Kerbol slightly closer to Kerbol. Still you get the idea: 3109 m/s just to reach Jool orbit from Eve/Kerbin circular orbit. As you can see on the screenshot in my case "extend [my] Sun orbit all the way up to Jool" does not cost 980 but 3109 m/s. It would be a bit less just after a Kerbin escape because I would be a bit further from Kerbol. It would be 2800 m/s. This is driving me mad because I know I did that long time ago, I would have noticed it if the delta-v map would have been that off. So I assumed it was a recent change, but you tell me it's not. I am even wondering whether I could have installed a mod at some point that never properly uninstalled. But I checked, nothing suspicious in my gamedata. My issue is not to get an intercept but just to extend my apogee to Jool orbit. So it does not matter when I do it. But to answer to your question yes, I attempt that in a transfer window.

Hello, I have just executed a mission to Jool and the Delta V requirements were way bigger than what they were supposed to be according to available delta-V maps. To get an intersect from Kerbin escape takes 2800 m/s, and not 980 as stated on the maps. Also orbiting Kerbin takes 4500 m/s, not 3500. Did I misunderstand something or are these maps completely obsolete? Are there somewhere up-to-date maps? Thanks

I confirm Scatterer solves the problem.

OK, that's clearly this bug, thanks for the info even though there seems to be no solution so far. I'll try to see what mods might solve the problem, starting with scatterer. Unfortunately I am only the 7th voter. I guess not so many people face it. Hopefully they'll solve it, it is a very significant issue. Too bad it's only on "low", I tried to change it but could not.

Hello, I am facing blinking glitches at the surface of planets. Here is a screenshot, the glitch is the black triangle on the topleft corner: Triangles like that are randomly appearing and blinking. I have no other problems with my GPU in any other game. Any idea to solve this problem would be much appreciated. Thanks

I am also programmer and I am daily writing code that are pushing all cores of all CPUs of all servers I am actually using. And I am not suffering memory latency/bandwidth bottlenecks. With all due respect I think you are over-generalizing your situation, and without deep knowledge of Unity (or similar game engine) internals you can't really confidently assert that using several cores will not lead to major performance boost. You may be right, and maybe not. And everyone seems to agree on the fact that the bottleneck of KSP performance is physics, but as far as I know (please tell me if I am wrong) this has never been confirmed by the development team. And honestly I doubt it. I can imagine physics is a computation issue when you have tens of thousands of particles that you simulate independantly (see NVidia demos...). But for the kind of work that KSP requires, some hundreds of piece interactions at most, I don't see how that might overload our current PCs. And contrary to popular belief, many PC games are CPU bounded or at least partially CPU bounded, even when there is no physics involved. I have some ideas about what I am talking about, but I admit I am no expert, though. So my point is that we don't even know where is the bottleneck. So arguing about the efficiency of multi-core optimization is a bit rash.

Not in KSP where n-body gravity is not simulated. If it does in KSP it is a bug / floating point error. No, not without a third body. Without thrust, a body that touch the atmosphere is doomed to go back to the atmosphere again and again and crash at some point. I am no expert but you can easily notice that there Earth does not have plenty of satellites.

Getting 0 m/s is straightforward. Make sure your Navball is configured on "target" and burn retrograd. When you are close to 0, use RCS (H and N keys in docking mode) for fine tuning. Navball is the key. Docking alignment indicator helps, but your primary tool remains the navball.

Most (well, let's say "a large part of" to avoid useless flamewars) large scale web site back-ends are made in Java. I am sure you used some of them.

I did what you say with FSX and it did not work. I travelled in time to 2015 and I can tell you even 9 years in the future FSX is still lagging, no matter what (it is very much playable, though). That is rather interesting and says a lot about bottlenecks and home made 3D engines by teams who are just not good enough for that.

Yeah, I already got this one. I was pretty upset. Sure it is doable but it requires a lot of dV and it is stupid (basically you burn retrograde then prograde for the sake of burning). That should clearly be filtered out by the contract generator engine.

Sure you could do KSP in Lisp. Or at least you could claim it.

It presumes you are not using a recent graphic card (who does not around here?), you are not using Wifi, you are not using a Webcam, you don't have a laptop. Or you are very lucky. I am using Linux for 15 years (mainly in my job), and I love it. I know that the global driver issue is not the fault of anyone in the Linux community, it is because hardware manufacturer do not care about Linux and for some reason they do not want to agree on hardware level standards. But in my numerous (sometimes successfull) attempts to have a completely, satisfyingly running Linux desktop with everything working smoothly, with Wifi, webcam, graphic drivers with OpenGL, it never happened that everything wroked at first attempt when I installed the Linux distribution. Never. Even (and that's the worst part) when I checked on the Web the avilability of drivers before buying my hardware. I always had to recompile kernel modules, to adapt silly scripts I found on the Web made for another distribution, and so on... Linux works greatly and is as easy to use as Windows, or even more (when installing new packages for example), once it is up and running. But to make it work (for a gamer / multimedia use), that's another story.

I think the problem is that writing a story is the job of the game designer, not the job of a modder. A mod is something you do (I guess) to make the game better so that you can enjoy it better, to fill what you consider as a hole in the game. By definition when you write a story you write it for others, you will not have the same pleasure to play it because you already know it entirely. For the same reason when you look at open-source games you find none, or almost none, that have an actual story or even simply any kind of content that has to be discovered by the player.