cantab

Yet another thought: If my maths is right the alternator on one nuclear engine generates enough electricity to run 10 ion engines as well, and the combination has a specific impulse of around 1600 s, better than what's being quoted above for fuel-cell-ion propulsion. That might work well, especially as you might have the option of using pure ion power at times. Scrap that, I mixed up the xenon and Ec consumption!

In my view there is a Step Zero: Determine if you will be producing and sharing "Adapted Material". The Creative Commons licenses do not directly address this matter, you would need to look to wider precedent in copyright law. It appears to be generally accepted for example that a mod may combine multiple files distributed under various different licenses - that including them in the same download and even having some rely on others for correct functioning does not constitute producing adapted material. But I don't know if any relevant situation has ever come to court.

I find the current ion engine fine. Now that Squad added decent sized xenon tanks you can do useful missions with it if you have a bit of patience, for example this ship took a lander to Moho, then stopped off at Gilly and Bop for jetpack landings afterwards. For the outer solar system I'm told fuel cell ion ships can work well, giving an effective Isp of around 1600 s. That said a big solar panel might be nice, enough that one or two can run an ion engine at Jool because when you need 12 gigantors a big nuisance is stopping them shading each other. As for a nuclear reactor, well maybe. There have been real nuclear reactors in space, it's somewhat proven technology, but getting the game balance right could be tricky.

This is how you should approach Laythe in order to aerobrake at it laythe approach by cantab314, on Flickr

If you can deal with the long burns it will be fairly straightforward I think. Things like hold prograde / hold manoeuvre make it not so bad, I just set the burn going then watch some TV or play on my 3DS until it finishes. (And if you use an autopilot you don't even need to pay the game any attention at all). At a rough estimate, 5 tons for the ship excluding the fuel tanks, then ten of the largest xenon tanks should get you the delta-V you need. That gives a ship that's 15 tons overall. You'd be looking at roughly 8 hours of burns at 4x timewarp, which is in my view doable, and you could add extra ion engines to use when closer to the Sun with more available power. If you set it to drop the empty xenon tanks that helps too.

Here's a discussion of the Apollo entryhttp://space.stackexchange.com/questions/2661/what-was-apollo-11s-reentry-speed-at-parachute-deployment This indicates that drogue chute deployment was at around 7 km up at a speed of merely 100 m/s or so. Obviously these things depend on spacecraft design, and of course Apollo never did a straight-down entry, but this suggests that if anything FAR is still not applying quite enough drag to a blunt object

I've played with exactly that behaviour from Antenna Range and found it good. I had to be mindful of when I did and didn't have connection, for example one mission was limited to operating in the fraction of Minmus's day I had both Kerbin and the Sun in sight, and I made good use of relay orbiters. As for realism, it's no more or less unrealistic than the lack of a speed-of-light delay.

Did you use the version of Kopernicus supplied with Kerbol Plus? I've found K+ only worked with that and not with Kopernicus downloaded elsewhere.

In an aircraft it doesn't matter much if the thrust isn't through the centre of mass, because the wings and tail will keep you flying straight. You do have to be mindful of it, changes in throttle will require changes in trim, but it need be no barrier to flying. The centre of lift should as usual be a little behind the centre of mass.

Is it not possible to edit the save or craft file to fix the fault?

I don't think that's going to work, since Unity 4 that KSP uses doesn't support DirectX 12.

A concept I had along the same vein: For any body without a moon (including most moons themselves), you don't get the projected trajectory of your spacecraft until at least one operating craft has entered its SOI. (Perhaps you instead get a range of possible trajectories indicated somehow) That seems grounded in realism - if a body doesn't have a moon it's hard to know its mass until you send a probe past it, but rather easier to know its orbit from telescope observations. It wouldn't excessively hold the players back or make us jump through hoops or do gruntwork - if we want we can just go for it and sort things out when we get there at a probable delta-V penalty. And I think it would add some interest, and another reason to do a quick preliminary mission to a planet before sending Kerbals there.

Really only looked at this briefly so far, but a barrage of questions/feedbacks: What made you decide to put all the parts in the same relatively early tech node? Is there a GUI to change the settings? If so how do you get to it? If not do you plan on adding that? Relatedly, do you plan on moving those settings into the save file so they can be different for different saves? What does the line HomeworldAltitude = 50000 mean in the GameData/UmbraSpaceIndustries/LifeSupport/Settings.cfg file? What's the supplies consumption rate of the Kerbals? In what if any situations will they not consume available, unlocked supplies? (Eg landed on Kerbin?) Do you plan on adding a tool in the VAB to check LS duration, a la TAC LS?

Double-check you're copying the mod into the right place, it sounds like you're accidentally clobbering one of the stock files.

My two cents: I've used Antenna Range a lot and liked it. I've tried Remote Tech somewhat briefly and rather disliked it. So I feel Squad and Roverdude's ideas are pretty good. Why I dislike Remote Tech relates to what I would like to see and not see in stock. My biggest beef with RT is it's built on premises that are so unlike the real world. Only one ground station and doing everything by satellites, really? Sputnik was launched and tracked just fine around the world and it certainly didn't have a huge comsat network to support it! And the ground station having far inferior performance than the portable dishes, seriously? Remote Tech has been designed to force the player into a certain approach, it's not about "realism" in the slightest, and that certain approach of setting up a Kerbin comsat network just becomes gruntwork after a few saves. I feel, then, that Squad's system should be built on sound premises. That includes the assumed presence of a Deep Space Network meaning connections only need to be to "anywhere on Kerbin" (or set multiple specific ground stations if you really want), and the ground-based antennae being the best performing. Relay satellites will still be useful to connect to the far side of other planets and moons, or to boost the signal of a craft with a weak antenna. It's also good to avoid encouraging "grunt work" and to give the player multiple viable options, we have enough gruntwork in early career/science mode as it is. My second problem with Remote Tech is the flight computer is sorely lacking. No editing an action already set, no RCS translation, no obvious indication you have additional delay enabled, I could go on. Now I'm unsure whether signal delay should be added in stock because it really makes probes in KSP an entirely new game, it turns it from being about flying to being about computer programming, and I'm not sure that's the direction KSP should take. But if Squad do feel that's worth adding, I would want to see much better probe programming tools than what RT offers. And using a more normal syntax than the weird thing kOS has too! That's the ideas. As for the implementation, well that's where I'm sceptical. Squad have a poor recent record of implementing their new ideas. The aerodynamics does seem basically bug-free but it received two game balance patches after 1.0 that messed with people's designs. The heating on the other hand is riddled with serious bugs. So even though it's a different programmer (Roverdude) working on the antenna stuff I'm not confident. Finally I'll be more positive and suggest something I think would be really nice: Realistic(ish) calculation of communication ranges instead of hard-coded figures. Give each antenna a transmit power and a gain, assume sensible values for bandwidth and noise floor, and it's fairly easy to calculate data rate over the link. Then impose a minimum data rate for various tasks. This would add complexity but I think make for some nice aspects. For example a Mun lander with a low-gain antenna might be able to communicate back to the big dishes on Kerbin because those dishes have lots of power and gain, but not be able to communicate with a closer satellite with another low-gain antenna.

The problem is partly down to very high speeds and partly to the atmospheres having "sharp edges".

My belief is the root cause is the heating system being numerically unstable, meaning that in some circumstances one or more parts will have their temperature "run away". It's a common mistake to make when simulating any physical system since simple and 'obvious' approaches can cause it, there are methods to avoid it but a non-expert such as a game developer might not know them.

I love this world already.

By the way, the license currently refers to KScale2 not to 64K.

Fuel lines from the LF tanks to the LFO tanks may suffice. The jets will draw fuel from all tanks, then the rockets will draw from the LF tanks first then the LFO tanks so will be able to access all the remaining fuel. Use of parts that disallow crossfeed may work, but ups the part count.

+1 to this. We can argue about whether planes should or shouldn't need high takeoff speeds, but the runway at KSC is on the short side at 2.5 km / 8200 feet. Major real airports such as London Heathrow, Paris CdG, New York JFK, have runways around 12,000 feet or longer.

KSP now cares about the direction a node is in, and won't allow you to attach another part the "wrong way" unless you turn on that cheat option. This change was made to resolve issues with attaching thin parts such as heatshields. In your config node_stack_bottom = 0.0, -0.45, 0.0, 0.0, 1.0, 0.0, 1 node_stack_top = 0.0, 0.45, 0.0, 0.0, 1.0, 0.0, 1 The first three numbers are position, and the next three are direction. Notice how both nodes point in the same direction, upwards. You want the bottom node to point downwards, so change it to node_stack_bottom = 0.0, -0.45, 0.0, 0.0, -1.0, 0.0, 1 You may also want to add a node_attach line to control how the booster attaches radially to other parts.

Activity on the planets in general would be great to have, but a major update and one that should wait until the game is better debugged and optimised I feel.

"Aerospike" is now the nickname - because I've a sneaking suspicion it's not a real aerospike.

KSP isn't always fully realistic, and this is one place it's been simplified for gameplay.