cantab

I tried to standardise action groups, but I'm not sure it was entirely successful. More successful has been my move to modules joined used big docking ports. The general idea is: Command module: Regular docking port on the nose, Sr port on the tail. Saved as a ship. Payload module: Ideally Sr ports on both ends, saved as a subassembly. Saved as a subassembly. Engine module: Root Sr port on the front, more Sr ports on the sides, suitable point to attach a lifter on the tail. Saved as a subassembly. I also have some Standard-Sr adapters for when I need them, though I realised I don't need them for launch, only when assembling in orbit. They include attitude control so they can be easily docked with, though not propulsion. These are saved as subassemblies, in two versions differing only in which port is the root. So far its worked well, although it's a bit of a nuisance to combine multiple engine modules in the VAB. Maybe I should get SelectRoot and make versions with the root part as one of the side docking ports.

The current time or "UT" is not stored as an integer number of seconds. Just look in the save file: FLIGHTSTATE { version = 0.23.5 UT = 850423999.083749 activeVessel = 0 It's also evident that the game needs to store the UT with a resolution finer than whole seconds, in order to run the physics calculations. Even the on-rails physics updates more than once a second. I suspect SkyRender had it right early on - that some part of the code handling displaying the current date casts the UT to an integer, meaning the integer overflow will break the displays but not the physics. Assuming the UT is stored as a floating point, I would expect issues to arise when the precision of the floating point became equal to the gap between physics frames. Say that time's 1/100 of a second, then if UT is a double precision float issues will start to arise around 1014 seconds, or a few million years. (Were it single precision, we'd be in trouble in a couple of days, so it can't be that.) So, we should be safe. PS: No need to timewarp to experiment with this - one can simply edit the save.

Hmmm...I didn't know about this when I randomised my start time. I started in Kerbin year 27, so have already lost about half my duration... That said, the way I play I'm unlikely to hit the limit. It's a bigger problem for one-mission-at-a-time players.

Getting a stock ion glider into orbit is TOUGH, but it has been done. There's a thread in the challenges forum for it. If you allow staging it might be made easier.

Yeah, it's been in the save file forever but for some reason never exposed in the game interface. Maybe it still has bugs (.23.5 introduced one with asteroids being considered first vessels), maybe Squad just haven't got round to it.

An E class, that's going to be tough. They weigh in at up to 3000 tons, with rare outliers even heavier. The most fuel efficient approach will be to encounter it while it's in solar orbit. It may take more delta-V to make the intercept, but that's delta-V expended without the asteroid attached. You then only need a small correction, delta-V-wise, to bring periapsis to 50 km or so for aerocapture. Even if you don't want to risk an aerocapture, getting your incoming trajectory close to equatorial and into a low periapsis will give you an economical capture burn. The "trick" to making a solar orbit interception is to leave Kerbin's SOI in the same direction the asteroid is predicted to arrive. I'm not sure why, but that seems to make things work out nicely. If you're aerocapturing, I suggest rating your ship for 250 m/s when pushing 3000 tons, and then 1500 m/s for getting to the asteroid from LKO. Also, don't overlook the challenges of turning such a large asteroid and keeping it on course. My approach has been to use little control sections that can be clawed on dotted around the asteroid to help turn it. That's handled a 500 ton D class fine, but even I don't know how it would deal with a 3000 ton E. An alternative is to actually unclaw the tug and reclaw it facing the way you need for a burn.

This is a bit annoying, but I've found a workaround to be to set it so that I'm automatically subscribed to any thread I post in, and then I can just check my subscribed threads. Of course this might conflict with other uses of subscriptions.

Yeah, plenty of ways to achieve circularisation I think: Centrifugal force, as Kasuha demonstrated. Munar or Minmus gravity assist, probably the only non-exploity way. "Canned air" with the intakes. Separator abuse. Glitch drives. The fuel transfer drive would probably be most in spirit of the challenge: by appropriately spinning the ship and transferring fuel from end to end you can translate the ship in space. And if you want probably the most Kerbal way: Get one ship on a suborbital trajectory, then hit it with another one to give the boost to orbit.

The one time I've done a "real" gravity turn, it was with about the simplest possible rocket, just a long SRB and the payload to circularise. I started it canted over 5 degrees on the pad and let it fly. Probe core torque, very weak on such a big thing, let me influence apoapsis but not "visibly" control the rocket. Though it's slightly less efficient, tilting it on the pad will have the advantage of reproducability - it'll be the same angle first time, every time. That will I expect help you fine tune the other aspects of your rocket.

Agreed, I think it's going to be a physical thing, given to someone who's done a lot for KSP. Though probably not solid gold!

Nice work. As for the Canadarm 2, if you look closely you'll see the bars over the astronaut's feet. He's clipped in, like how a skier's boots are clipped to their skis, not stuck on.

Also, I suspect, works better when the developers don't have a load of their previous customers saying "I want a big update and I want it now".

I did something similar on my first Munar orbit mission. It's not necessary if you make your ejection burn correctly, of course, but worth knowing if you do get stuck in a high orbit round Kerbin. I'm not sure how much the delta-V requirements drop actually. For a regular bi-elliptic transfer, with no aerobraking involved, the savings are usually small, but if you're aerobraking into your low orbit (or even landing) I think they can be larger.

One other thing to note is the most powerful engines tend to be first stage ones, operating in dense atmosphere. Upper stage engines are generally less powerful so presumably generate less heat.

*sigh* Not this one again. Like so many "amazing" ideas, it's got a ton of problems.

That just means you have to do Jool last. So that, even if only for a moment, you can say you've had Kerbals on the surface of every planet.

Around one metre per second. That's how much I calculate I would have had left after I used 148 out of 150 units of monopropellant to establish a stable orbit for my Whittle crew transport, after it had inadvertently decoupled from its launcher too early. It had 21 Kerbals on board and landing is a risky only-in-emergencies affair, so I was very glad to make it. Of course, that's not counting GOAP. I resorted to pushing earlier today, after a deorbit burn from an escape trajectory gave me a 90x80000 km orbit. In theory I should have had just enough fuel, but I think not being quite on target during the burn is what spoiled it.

A game bug, or a mod that either extends the physics range (Lazor?) or keeps physics running for a ship (TT Never Unload?)

Prepared a big asteroid for aerocapture: Weighs in at just over 500 tons, and thanks to some errors earlier in the mission I've only got 100 m/s of delta-V with it attached. But she handles well thanks to the little control sections, and I want it in an eccentric polar orbit anyway so should have enough fuel for the job. And brought a small asteroid to my station: Just a little A class, I wanted this to look like an asteroid on the station not a station on the asteroid. I'll give it a more permanent attachment at some point but for now I just docked the whole tug.

Depends on the mission. I believe they won't be much good for the moon, but as I said earlier, I can see them being useful for a Mars (or Venus) mission, where the travel times are longer anyway so the low thrust isn't really going to slow the trip down.

As Kasuha mentioned and demonstrated, you can still make an eclipse impossible by making your orbital period a simple fraction of Kerbin's year, such that when the sun is on the satellite's orbital plane the satellite is well away from its sun-relative ascending/descending nodes.Of course the inevitable small imperfection in orbital period may mess things up eventually, but you're talking many decades if not centuries I expect.

Lick William the Conqueror's elbow

In terms of the stock game: Firstly only Kerbin, the Mun, and Minmus have biomes. Everywhere else you're only getting one result for in space high, and another for in space low. Thus a satellite that sticks around is only better for science than a one-off flyby around those three bodies. Then in terms of specific experiments: EVA Reports, and Surface Samples require a Kerbal, so are moot for unmanned satellites. Circling Kerbin, the Mun, or Minmus with a manned ship taking and transmitting EVA reports on the other hand is a great way to get science. The barometer, seismometer, and Sensor Nosecone are of no use in space. The Mystery Goo and Science Jr (aka Materials Bay) are single-use unless you have a science lab (the big one) with 2 kerbals in it to clean up the experiments. Crew Reports, surprisingly, do NOT require a Kerbal. You need a manned command pod but that pod doesn't have to be occupied, though if it's empty you will need a separate probe core to control your ship. However, they aren't biome-sensitive. The thermometer is not biome-sensitive in space either, you can only get a single result when you're close enough to the celestial. That leaves the gravimeter. Its results are biome-sensitive both low and high over the celestial, and even with the transmission penalty it's still capable of sending back a nice chunk of science. IMHO it's the only experiment that can make a satellite useful in terms of science gathering. Unfortunately, it's the last science instrument to be unlocked. That said, a gravimetry satellite taking and transmitting readings from high and low orbit over all biomes would bring you 144 science from Kerbin, 720 from the Mun, or 576 from Minmus. Not bad for what by the end-game will be a very simple, if a touch tedious, mission.

The thing is that on Kerbin you can get "landed" science from the Ocean biome, if you either find a bit of land that counts or IIRC if you stand on a boat, and "splashed" science from terrestrial biomes if you find a river.

I expect the opposite - it will be one of the last "big" updates. With a feature-complete career mode (coming in .24), a game engine update for 64 bit anf multithreaded physics (tied to an expected Unity release), and maybe some new or improved celestials, it's then only bug fixes and game balance tweaks standing in the way of the 1.0.