Laie

Yes. If RCS is active and no other engine is available, MJ automatically uses RCS -- I think. Maybe you have to turn that on somewhere, but I think MJ does it by default. Otherwise, RCS has a "Forward on Throttle" Setting in the Advanced Tweakables. As for delta-V, a standard Mk1 command pod + heatshield + parachute comes to what, 1100kg? It also holds 40kg of monoprop, at ISP=240s that would be enough for 80m/s or so, without even adding a monoprop tank. How much you can do on 80m/s is up to you.

Hmm. It's just a hyperlink leading to a .webm file, which I thought would play inline in every browser. Can you download the file ("save link as") and view it in another application, perhaps. Meanwhile, I've had a look at Near Future Propulsion... First off, the engines have tremendous power requirements on the order of 400-3000 units of ElectricCharge per second. You definitely want "Near Future Electrical" for the nuclear reactors to drive them. Don't bother with "Near Future Solar": Solar Panels are much heavier than reactors, even after factoring in the heatsinks. Solar power becomes interesting only if you need power for years, where a reactor's fuel supply would need to be replaced. Reactors create a lot of CoreHeat, requiring radiators. Far and away the best heat sinks / mass are the stock static panels. Nertea's "Heat Control" mod offers some good-looking items, but they are heavier and require more power than stock panels. NFE also brings "capacitors" which store 8x as much electricity per mass compared to batteries. Technically speaking, they hold a resource called "StoredCharge" that converts 1:1 to/from ElectricCharge. Capacitors charge only slowly, can hold their charge for ever, and can be discharged at the press of a button. Discharging a capacitor will dump it's entire StoredCharge in a matter of 10-20 seconds. Once started, the discharge cannot be stopped. If your consumption is less than the discharge rate, you need a large enough conventional battery to act as buffer, or the charge will be wasted. for all that, they're still rather heavy. If you need power for more than approx. 5 minutes, it's better to bring an adequately-sized power supply. For the purposes of our challenge, only to kinds of engine are of interest: the most powerful Ion engine: 3.8kN, 19200 ISP, 400EC/s. There's many other engines with a slightly better TWR and much worse ISP. All of them will require burn times upwards of one hour. In convenience terms, I think that once you're willing to take that time, you may as well go all the way and pick the single most efficient engine. Including power supply and radiators, the engine package comes to 1.5t and requires virtually no propellant. Magnetoplasmadynamic Engines. Including the power supply and radiators, these provide NERV-like TWRs on the order of 24-30kN / ton, however at ISPs of 2600-3500, with the biggest Item having the worst TWR and best ISP. That's totally suitable for an upper stage and can provide about half the dV to LEO in the first place. They create a lot of heat and need active cooling, though. As radiators will only shed normal (non-"Core") heat outside of the atmosphere, you absolutely have to be above 140km within 30-50 seconds after ignition. With an electrical upper stage, I manage a liftoff mass under 500t. Discarding a reactor after 15 minutes of use isn't exactly economical, though.

Well, I'm spiraling outward - that alone is already pretty inefficient, dV-wise. This doesn't mean I'm willing to blow dV for no gain, though. Even for a standard two-impulse transfer to GEO, it is worthwhile to add some normal to the first burn in LEO: the savings on the second burn are larger than the additional cost for the first. GTO+GEO maneuvering normal m/s at PE dv PE dv AP total 0 2480 1830 4310 500 2510 1720 4230 1000 2620 1725 4340 These were arrived at "experimentally", dialling in maneuvers: 1) PE kick to 35,786 km at DN, 2) circularize and fix inclination in one maneuver at AN/AP. I think it's interesting that dv at AP appears to increase again despite the inclination being lower... anyway, this gave me the idea of working on the inclination on the way up. Due to the spiraling-out approach, I will also have a rather high PE by the time my AP touches on GEO.That is, I will also have contributed quite a bit to circularisation already, leaving less prograde work to be done at AP, and generally a lower-magnitude burn to hide the normal component in. I think this makes it even more important to already work on inclination before I get to AP. Then again, orbital mechanics is weird.

I've launched a very low-TWR vessel from KSC (28 degrees and a bit) and want to spiral it out to equtorial GEO. Basic approach: point prograde and apply my minuscule thrust until apoapsis is high enough. Then look and fix as necessary. My question now is, what can I do about inclination during the long burn?I expect to go around the world several times until AP touches GEO, which means I'll also cross the equator several times. While I don't expect to reach zero inclination during the long burn, I do think I should be able to shave off a few degrees. But how? Should I: thrust parallel to the equator at all times? point +-30° from prograde whenever I go down/up? only deviate from prograde when I'm "near" an AN/DN? If so, how near and by what measure? something else I didn't think of? Please don't suggest a higher TWR or periapsis kicking. Both are out, because of reasons.

You mean something like this? I've tried with a rapier, but that one blew up before reaching the target.

Be sure to turn on the subtitles.

I'm not too happy about that "payload fraction" thing: once more we have a challenge that favors Vectors and Wolfhounds, the latter being pay-to-win. But anyway, here's my approach: Launched into a rather high, lopsided orbit, not caring too much about the details as long as it seems that it will take me well over the equator. Then I turned left, 55° NE on the compass, and just kept going. A bit of pitch was added as necessary to keep the climb (or rather, descent) rate within acceptable limits. PE was below the surface to begin with and dropped further at first, I didn't reach an workable orbit until I was well past the equator. At that point I still had a 16° inclination, that was trivially fixed with a normal maneuver. Decoupled payload of exactly 20t, final orbit shows 0.0° inclination. With a takeoff mass a little shy of 333t, that resolves to a payload fraction of slightly more than 6%.

The terrain map, specifying altitude at a specific ground position, is incredibly coarse-grained. Hold on.... on my install, it's 8196px wide and 4096 tall. So on the equator, one data point determines an area of approx 5x5km. The specific terrain is made up by an algorithm. In first approximation, higher ground is more bumpy (=mountains) while lower ground is less so (gentle dunes). I think the bumpiness can be overridden in some way, perhaps taking the biome map as a hint? You'd have to ask the folks at Kopernicus for details. But I don't think it's possible to have Mount Everest in just the right position. At best, you can make it so that the Himalayas, Andes or Alps have about the right altitude, on average.

@AllenLi making the turn too shallow, and then keeping the rocket pitched up later, is a trick I learned playing RO. Picking up extra horizontal velocity early on is so valuable that it more than makes up for the cosine losses of the pitch. Hold on, let's see if I can do this without youtube... (edit) yup, it works. Full ascent as time-lapse video, 37 seconds, 7MB. This time it's 5x Wolfhound, 4x Rhino, and -again- twelve SRBs. 619,353 funds 2805 tons Compared to my previous stack, that's a 10% reduction in mass for a similar payload. Some of the work has been moved from the upper to the sustainer. Improved ISP overall means less propellant carried, resulting in comparable TWR at liftoff. Sorry, this isn't relevant to the challenge, but I have to ask: are you aware of SMURFF? It's totally possible to have reasonable mass fractions without getting the whole RO suite.

Well, the payload to LEO has been reduced by, what, nearly 50%? It makes sense that I only need half as much rocket. Note, however, that my Wolfhound upper stage is contributing much more work relative to the rest of the rocket than yours does. My launch recipe, by the way: dial in a gravity turn that will bring the rocket close to 30° pitch by the time the first stage burns out, then hold approx 25-30° pitch - precise value depends on the original gravity turn being a little lower or higher than desired. Anyway, I usually stick to the same pitch relative to the horizon all the way throughout the second stage, and until time-to-apoapsis eventually starts to increase on the upper. I'm not using FAR, but even in stock RSS the atmosphere is of zero concern beyond 50km. Stock aero makes it necessary to wrap the interstages in fairings, though. Not much. There were a few droplets left, but IIRC they amounted to 50m/s at most. I had planned for the nuke to provide perhaps 100m/s to making orbit, but found that this leaves not enough dV for going to GEO -- not at nuclear TWR. The next model will be a little heavier. Or maybe it won't. @AllenLi is explicitly allowing Near Future stuff, and I wonder if I should have a look at these fabled VASIMR engines. I'm not familiar with NFT, but browsing the data on github, it seems as if you could get 280kN / 2000 ISP ( or 66kN / 6000 ISP) from a 3t engine, plus however much mass you need to satisfy the power demand. That might already work even as an upper stage.

Other than aesthetics? No. They are configured as LF-only, however, so no worries.

FWIW, here's my attempt. I started with a wrapper of Mammoth boosters similar to Pds314 above, then replaced them with SRMs on a whim just to see what happens. What a pleasant surprise! TWR is incredibly high for my standards, I don't usually see heat effects on ascent (in RSS, that is). Engines used: 1 Nerva 7 Wolfhound 8 Mastodon 12 Clydesdale Total cost including payload: 668,256 funds Total mass including payload: 3,103,048 kg nominal vacuum dV of the booster: 8888m/s @Pds314: I don't know how to say it diplomatically, but: all those high-res PNGs really add up. Viewing this page currently requires a 100MB download.

Well, it would have been nice if patience had solved it....Have a look at the logfile. With any luck, it will tell you what the game tried to do last but couldn't finish. However, as you say that it worked before but now it doesn't, I suspect that you messed something up when removing and re-adding RSS. If the log doesn't tell you what's wrong, I'd suggest to start over from a fresh KSP installation.

For how long? On the first launch after adding RSS, KSP is doing some things regarding textures / heightmaps / whatever. On my last install with SSD, this took 2-3minutes; with data still on disks, it was (IIRC) on the order of 10-15min.

Really? Is that official?

Single nuke and by no means the heaviest asteroid, acceleration was 35-40mm/s² (or TWR 0.004 in forum parlance). Capture and plane change worked out as usual, after that I moved it down to LKO in two long maneuvers of 6 and 10 hours burn time, respectively. So, rather quick by the standards of this thread. Paging @johnsonwax and @Rune who have done similar missions. Always pointed retrograde, throttle was controlled such that I'd maintain a certain distance to periapsis -- so, throttle down when PE slips away, and crank it up when PE comes too close. It took me an afternoon of experimenting to devise an automated kRPC throttle controller, the actual maneuver then played out unattended while I was sleeping. It stopped up in an 180x200km orbit.

Yes. Right-Click the asteroid and you will see data about it's mass and ore percentage. Moving the drills to a new location won't help: as long as the drills make contact with the asteroid, they will mine the asteroid. It's just one single ball of resources and it doesn't matter where you tap into it.

Asteroid mining is fast -- if you bring along an Engineer, you can refill even a large vessel in a matter of a few hours. A single drill will provide lots and lots of ore, the bottleneck is refining it to fuel. If you have sufficient power, you can run the Lf+Ox, Lf and Ox converters in parallel. With a 5-Star engineer, this will provide enough fuel to run one Terrier indefinitely. Or if you have a Rhino to feed, you will need about 30 minutes of refining to run it for a minute. A Two star-engineer will be about half as fast, but still 13x faster than no engineer at all. Check the Wiki for details.

Been trying to solve this on paper... LEO(KSC 23°)-> Geo requires about 4200m/s, with 20t payload and lots of nuke power I end up with 60t gross mass for that part of the mission. Below that, a Rhino upper stage with 4Min burn time, starting at TWR 0.87 for 3200m/s. Still reasonable. And then Tsiolkowski beats down hard: wrapping the above in eight Mammoths isn't quite enough, dV-wise, and TWR would be abysmal throughout. I'm used to RO launches where you'd reach 3-5g at the end of each stage, and have no idea how it would work out with an asparagus design that hardly ever reaches 2g. My guess is that it would require more like 12km/s to make orbit, rather than the 9+km/s I'm used to. In a nutshell, I don't think it's worthwhile to use stock parts in a RSS setting. The good old MOAR approach will eventually get you there, but it's not the kind of challenge I'd enjoy.

@Death Engineering once upon a time, I had plans to put the door in the bottom and lower everything on the bed of the truck by winches. In the very beginning, it was all supposed to come packed in crates to boot. The big-s cargo bay flaps would visibly interfere with the wings, for starters. I'd need legs / landing gear tall enough for a truck to go under the bay. I'd need to play a lot of camera games in order to focus on the winch in the bay, and the module it's supposed to attach to. precision parking of trucks in just the right spot is tricky to begin with, it gets trickier when vessels slide around by 5mm/s. So I scratched all that. The bay opens at the top where I, the player, can easily look into it. After the first run, I increased interaction range and by now, modules are picked from the bay and immediately attached to the base, just like that.

This doesn't follow any design restrictions, and it's autopiloted to boot. So probably not even "anything goes", but gatecrashing straight and simple. I tried to go for the tower, only to rush right through it: too fast! In conclusion: that was fun, thanks!

With a low CoM, you need to be more gentle and careful with the steering, that's all. In KSP, being gentle isn't always easy, especially not on WSAD controls. In real life, work on improved guidance systems has so far been considered more promising than trying to devise a tank that drains from the bottom up. Asymmetric rockets are a thing now, and tailfins have become scarce. As for myself, I don't like to drain my tanks from the bottom. But if it's either that, or scratching the mission? I know my priorities.

A decoupler's force moves stuff away from the parent. Until just now, I wasn't aware that the game is quite literal about this. It appears that the force always moves away from the parent part's center (CoM or origin, I don't know -- for most parts it's the same either way). It is definitely not the parent vessel CoM, but the parent part. I've only done limited testing and cannot say if the force simply goes through the decoupler, or if it is more complicated than that.

Can't participate for lack of flying skills, but here's a small MM patch that may come in handy: it equips the Radial Holding Tank with a built-in decoupler. Cluster munitions, anyone? Just plop it somewhere in your Gamedata folder, the bomblet can then be found in the "Payload" tab.

There's just too many things to watch out for at once. It may be doable with two flightsticks, but if you're on WASD controls, by all means get some flight assistance mod.