Racescort666

1.1.1 has not fixed this problem. I updated the drivers thinking that might be the problem but this did not fix the problem.

I suppose we could petition the IAU: http://www.minorplanetcenter.net/iau/info/HowNamed.html My vote is Minmus but Mün may be more appropriate.

I appear to be having some graphics card related issues with x64 so once that gets sorted out, I will install MOAR VISUALS!! Seriously though, the graphics issues are annoying.

After realizing that I was still running on 32-bit 1.1, I started using 64-bit and immediately noticed a huge performance hit super slow FPS, yellow clock, et al. I tried switching back and forth, 32-bit runs fine, 64-bit runs like manure. After some tweaking it started to feel like a graphics problem which led me to check the logs. 32-bit log shows using my NVIDIA graphics card, 64-bit uses integrated Intel graphics. I checked the old logs from my previous playthoughs, all used the NVIDIA. Specs: OS: Win7 KSP: 1.1.1.1250 CPU: Intel i7-4810MQ @ 2.8 GHz GPU: Intel HD Graphics 4600, NVIDIA Quadro K3100M I will admit that I don't have that much experience with this so I changed the settings in the NVIDIA control panel so the global settings used the NVIDIA card as the preferred. I also tried it under program settings and this doesn't seem to work either, KSP log still showing Intel graphics. I'm not sure if this is a bug or if I'm doing something wrong that's not related to KSP or if it's something completely different. Help is appreciated. Output log here.

I used a webapp to calculated my departure dV and arrival dV as well as planetary alignment. It wasn't super hard to calculate the dV in an excel spreadsheet. Agree 100% on Navball Docking Alignment even though I prefer the NavyFish version.

I laughed out loud like a crazy person at this. Time is what you make of it I guess and there are good arguments for and against realism.

I'm always amazed at the kind of great work you guys always do. Transfer windows are definitely one of the real rocket science parts that's very hard to figure out. Calculating dV is one thing but trying to get to another planet is a whole new ballgame. It can't be overstated how appreciative I am of your time as both a game developer and as a mod developer.

TriggerAu will have to speak to it if I'm wrong but KAC uses a simplified transfer window. Transfer Window Planner (also a TriggerAu mod) gives you a porkchop plot like MechJeb and is much more accurate IMO but Alexmun wrote the code for the Lambert Solver that actually calculates the transfer. As far as I can tell, TWP assumes a circular equatorial orbit whereas MechJeb uses the orbit of the active vessel accounting for eccentricity and inclination. The problem is that you can't really make perfect burns and the game has limitations on how accurately it can calculate orbits so the best you can do is closeish.

CPUs are rated in GHz (gigahertz) which is a fancy way of saying how many calculations they can do per second.* When you overclock a processor, you adjust settings to increase this processing rate. Here is an article that explains how to do it and hopefully it will help you to understand what it does. *Ok, it's a little more complicated than that but it's an easy way of thinking of it.

Fair enough. I'm just trying to dispel the rumor that fine control does anything other than reducing thrust.

Fine control does not balance RCS, it only reduces the thrust of RCS.

I wouldn't feel too bad. There are a few people I have worked with where they wouldn't read my email if it was longer than 2 sentences. If it had to be longer than 2, I'd basically have to have a bulleted list with highlights. Beyond the people who willfully don't read what I send them due to attention deficit, there are always people who fail to read what I send them due to incompetence. This is more frustrating.

Like maybe SCANsat? This is not a "there's a mod for that" comment. Actually, I really love the way SCANsat features a game play mechanic that emulates real life and it would be great if something like it was part of the base game.

Helium would still add mass.

I've experimentally used it. But I found it makes a much better fin stabilized sounding rocket. Note: "fin" autocorrected to "fun" when I first typed this out.

People have said this all over the place but using fine control has never balanced RCS for me. It has decreased the power of RCS to the point where the reaction wheels can take up whatever excess torque they produce though. EDIT: I remembered to test this tonight and fine control does not balance RCS.

I will say that docking large, heavy, wobbly ships is a PITA without an alignment indicator of some kind. If you're not perfectly square to the target port, they won't dock and the magnetic attraction usually makes it worse. Especially when you're running at 3-4 fps. It goes from brutally painful to toeing the line between tedious and somewhat fun. It also helps to have well balanced RCS but that isn't the topic of discussion. I'm not going to say that it would have been impossible to do this without the alignment indicator but as a "quality of life" improvement, it's hard to live without.

@Snark personally, I love the docking port alignment indicator but I generally agree with the minimalist approach to "what should be stock?" I'm going to have to try the mod you suggested and see if I like it more than docking port alignment indicator and see if I like it better. Sometimes I need more information, sometimes I need less, so I'm happy to open and close windows as I need them since certain information can never be useful all the time. That being said, the current docking UI is absolutely worthless. 0/10 would not buy again.

This works for me. Thanks! this thing was fun, I think I'm going to try a slightly more realistic spaceplane on Duna coming up.

Ok, I changed my plans a little and landed on Ike instead of Duna. However, this was a full return mission. Hopefully points are not docked too badly for the rough water landing. :-/

Ok, initial attempt. I honestly wasn't going for part count, just something that would work reasonably well. In hindsight, I should have included a battery. There will be a part 2 because I'm convinced I can land on Duna, take off, and return to Kerbin. Although I think that FAT wing will explode in the atmosphere. No idea on scoring but it was 36 parts at liftoff and 20 parts after separating the boosters. Does not explode on launchpad: 10 + 36Lifts off successfully: 15 + 36Suborbital trajectory: 15 + 36Orbit: 50 + 36 Sun orbit: ?? + 20 Duna flyby: ?? + 20 Duna Orbit: ?? + 20 Duna Flight: ?? + 20 Is a Spaceplane: 100 Or whatever the judges feel appropriate as scoring.

Racescort logs in, sees there are new posts in the Hypetrain thread, thinks "hmm, I haven't read that in a few days," 10 pages of comments behind, skips to end.

I've got a working prototype spaceplane (loosely interpreted but it does in fact fly). My plan is a Minmus landing but I'm not sure if I'll make the return. ETA: I spent all night working on it and tweaking it and I now have no time to actually fly a mission. Hopefully mission update tomorrow.

There is much to be said about the claw blades of yore.

An Eve return mission is something that I've wanted to do for a long time. My first attempt was back in 0.90 days and it was this huge beastly thing made from 2.5m parts that my computer could barely handle and kept breaking apart while testing it over Kerbin. Eventually, I gave up and crashed it when 1.0 came out. I also started playing on my work computer (HP zBook) which has got way more horsepower. Anyway, here is my submission. Probably in the nick of time before 1.1 comes out. I'll have to figure out the statistics on this ship. I was a little worried that I wouldn't have enough dV to get into orbit of Eve because I landed at a pretty low elevation and the ascent vehicle only has about 7-8 km/s of dV when I was shooting for 10 km/s. I guess the dV requirement for Eve has gone down.