Starman4308

At the very low-mass level, monopropellant is actually better. The O-10 monopropellant engine and the LV-1s both have 290s Isp. The O-10 is physics-less, while the LV-1 has a mass of 0.03t. Additionally, the FL-R10 monopropellant tank has a 5/1 mass ratio, while the ROUND-8 tank has 4.67 mass ratio. The first LF/O tank with a better mass ratio is the FL-T100, with a mass ratio of 9.33/1. A single FL-R10 and a Stayputnik core will give you 3128 m/s dV for 0.3t of mass. Two ROUND-8 tanks with an LV-1 and a Stayputnik give you 2689 m/s dV for 0.36t of mass. It's only when you get to the FL-T100 that the story goes the other way: two FL-R10s net you 3700 m/s of dV for 0.55t, while a single FL-T100 nets you 4328 m/s of dV for 0.64t. If one were to extrapolate the mass ratio of the FL-R10, a theoretical 0.64t probe with the O-10 would get 3808 m/s for the same 0.64t.

One thing which could be done is to have each stack have both a Clamp-o-Tron and a Clamp-o-Tron Jr. That way, the total height of both stacks is identical. You'd just have to be a bit careful about uncoupling to make sure you don't ever release at the wrong point. It'd look a bit like this (the one on the right has the Clamp-o-Tron Jr. completely hidden below the full-size one).

Stock Jool isn't Jupiter. Jupiter isn't stock Jool. In RSS, atmospheric entry velocities are much higher, and atmospheric densities are adjusted to match the real planets. Notice how you're going over 5 km/s when your spaceplane disintegrates. Also, MechJeb can have issues trying to keep planes level with FAR aerodynamics installed. I think there's optional FAR modules out there for MechJeb, otherwise you can switch to using FAR's aerodynamic assistance and more manual piloting.

It's a known bug, amplified if you have stuff near the capsule hatch. One of Claw's stock bug fixes makes the problem go away... and the other modules he has aren't shabby either. As to getting Bill back to his capsule, the easiest thing would just be to jetpack him to his original capsule: press R to activate jetpack, WASD to translate forwards/backwards and sideways, shift to translate up, and ctrl to translate down (this is identical to translate mode for docking).

It's also a spreadsheet and Raptor's blood, sweat, and tears.

Hey Ferram, I'm beginning to work on a contract payout adjuster for RSS, which basically grabs orbital and atmospheric parameters, figures out how much dV certain maneuvers would require, assumes a given Isp, and appropriately adjusts it from stock. Orbital maneuvers are easy. Ascents and descents, not so much, but I've figured out a general framework. I'll simulate a repeated TWR curve up to the edge of atmosphere (straight vertical), multiply accumulated aero drag by 1.5-2.5, and call it the atmosphere drag for that body. My question is: would the ideal drag equation with a reference cross-sectional area and drag coefficient* be a reasonable representation of FAR/NEAR aerodynamics, particularly as one goes hypersonic (I can approximate out the transonic region by ignoring it)? *Looking at Wikipedia, its "streamlined object" has a Cd of 0.04; I might go with 0.10 as my default, so as to be generous about the quality of rocket design. It probably doesn't matter a huge deal if I cut out the thrust when drag-adjusted apoapsis hits the edge of atmosphere, or have the reference vehicle thrust all the way to the edge: the second option will probably not add much aero drag. EDIT: Solved my own problems. Found your Mach effect code, and based on building a smallish rocket, I think I'll go with a cross-sectional area of 5.5 m^2 and a Cd of 0.18 (had one 1.25m stack with three fins, with three 1.25m SRBs on decouplers, all with aerodynamic caps). I'm thinking that the 5.5 m^2 area came out of having the fins, and Cd went down significantly after staging because much less of that 5.5 m^2 area was actually filled up?

Please read the first post. The issue is that Deadly Reentry is calibrated to stock, where a Munar reentry is a paltry 3 km/s.

Thanks for the feedback. Hopefully this all goes without a hitch, because if stuff goes kaboom, I'm not sure this career mode game will survive the financial hit. The payload ratio is making me wince: about 2.1 tonnes of science payload, which will probably in the end require 1000+ tonnes of booster.

Only works for a while, until Kerbin orbits around and you start having shadow to deal with. While I'm fairly certain ScanSat doesn't properly model electricity draw during timewarp/inactive time, but I don't want to exploit that (though I will assume I'd devised this miraculous "point panels directly at Sun" thing). Also, thinking about it a bit more, I'm wondering if 6.4x might be working for me, since I suspect it might have made the relative distances greater (and thus the max angle from the Sun smaller). In any event, I am probably 70-80% through design of what I am now calling my Venturer project: a combined Duna/Ike unmanned land-and-return mission. The landers and return stage are finalized: total mass to trans-Dunar injection will be 78t. Design of the Ceres V booster is in progress: estimated mass is around 1000t, but only the uppermost stage is complete. I was reminded a couple times of the evilness of the rocket equation: I have separate Duna landing and Kerbin return heatshields (the Duna heatshield will be ejected during landing). It also lacks a Kerbin return parachute: I determined that it would be just about break-even to skip the 'chute and rendezvous with a mobile lab in orbit, and the other difficulties inherent in a return direct to Kerbin's surface made up my mind for me. It'd be a lot more efficient with some LV-Ns, but I've made up my mind: I'm going to get my next batch of science from Duna, and that means chemical rockets only.

Pretty sure that the reaction wheel nerf is part of the RO core, not one of the auxiliary mods.

Well there's always the "press Z, then spacebar really quickly" trick. It doesn't have to be guided to fly. Might not be practical with the current skycrane (too much thrust, might get too much height), but the skycrane could stand to lose some thrust anyways (or, more precisely, lose some excess engine mass).

That might be realistic, but I'm not so certain myself. Sure, sounding rockets are kinda cool, but I don't think we want players to spend 10 launches without even hitting space. For playability, I'd probably have the first contract be "hit upper atmosphere/the Karman line", the second be "reach space", and from there start offering contracts like orbital probes and suborbital manned flights.

I've been throwing together my first unmanned Duna mission (6.4x Kerbin, FAR), and I'm wondering: how essential are fins? They'd help with stability on ascent, but I'm concerned they might cause strange issues during landing (for the descent, they would pull CoP in the wrong direction). And for that matter, how are your typical ascents going to be handled? I know the whole "2-5 degrees at 60-100 m/s" thing for Kerbin ascents, but I suspect Duna launches are going to have a sharper gravity turn*. *Depending on final engine layout, I suspect I'll have a starting Duna TWR of 1.8-2.5, which further encourages sharp turns.

95% sure this should work if you add it to a config file somewhere (borrowed some code from RO's Mechjeb config): @PART [*]:HAS[@MODULE[ModuleCommand],!MODULE[ProtractorModule]]:FINAL{ MODULE { name = ProtractorModule } }

I generally don't part clip, but I see where it would be useful for things like making replicas of real-world craft, and dealing with certain annoyances in ways which should be possible but aren't due to limitations of the game. Airhogging, though, is the moral evil of our day.

It's a sign. Build yourself a boat. But yes, probably duplicated Squad folders in your GameData folder.

The Protractor mod does give you current phase angles. I'm not sure if it can give you future phase angles; I've never used the mod.

Step 1 of installing Linux is always to back up your Windows disk to hell and back. For pure paranoia, I would recommend having two backups: for me, #1 was the Carbonite service, and #2 was my external hard drive. Step 2 is to wait until you've got time to spare in case things go south. Step 3 is to find a step-by-step guide and follow it to the letter. You may have to deal with things like disabling fast boot, and you really don't want to screw up your system. Honestly, if this is your work laptop, I would not install Linux until you're more familiar with how it works. It should work, but you don't screw with work equipment unless you have to.

Built my first ScanSat satellite, put it into a nearly perfect polar orbit. I found that an excellent way to keep all four solar panels going was to point the craft at Moho, which would ensure there was only a small angle to the Sun (I don't seem to be able to target the Sun directly). I'm wondering if people tend to go with battery monsters like the one I built (that thing is probably 80-90% batteries), or just accept that they'll only be able to scan on the sunlit side of the planet.

I'm thinking through this myself, and I think it comes back to the Oberth effect. Let's assume a constant gravity of 1 m/s^2*, a vehicle with a 1 kg mass, a target orbital altitude of 20 km, and a requisite orbital velocity of 500 m/s. You thus need gravitational potential energy (Eg = mgh) and kinetic energy (KE = 1/2 *mv^2). For this, you need 1kg*1m/s^2*20000m = 20,000 J of gravitational energy, and 1/2*1kg*(500 m/s)^2 = 125,000 J of kinetic energy. *Yes, technically it'd decline a bit going from 0-20 km. The math is simpler this way. To go straight up would require a burn such that KEup = Eg: 1/2*mv^2 = 20,000 J. The ascent burn would thus require 200 m/s, and circularization would require 500 m/s, for a total of 700 m/s for the up-then-sideways strategy. But, remember our old friend Oberth. You get more energy the faster you're going. The total orbital energy we need is 125,000 J + 20,000 J, thus 145,000 J. A perfect burn would thus be 1/2 mv^2 = 145000 J, with a requisite velocity of just 538.5 m/s. I think this would essentially mean an instantaneous burn, mostly sideways but a bit up, designed to put you into a 20km circular orbit. I would presume a horizontal burn designed to put you in a 20km x 0 km orbit, followed by a circularization on the other side, would be almost as efficient. EDIT: The Oberth effect would also neatly explain why prograde/retrograde is more efficient than radial burns for changing your orbit: prograde/retrograde are in your velocity vector, thus directly add or subtract to it, while a radial burn would describe a triangle, such that your final velocity change is less than that of (current velocity +/- delta-V expenditure).

Click [ or ] to switch to nearby vessels, which happens to include stranded Kerbals.

First off, I'd like to thank you enormously for the cargo bays, which I have abused immensely to keep my new Duna lander streamlined for FAR. Second, the SpaceY fuel tank config is written and submitted to Nathan. If you're wondering: the blue thing is just a procedural battery that I used as a central post to stick stuff on. I initially had them attached to the outside, but the bulkiness of the mystery goo model meant they weren't shielded according to FAR, at which point I got the idea of hanging something down from the top to attach them to.

Update to the latest version of FAR. The prior version had issues not shielding things when you resized the fairing. Also make sure you're flying a sane FAR ascent (2-5 degree gravity turn at 50-100 m/s, launch TWR 1.2-1.6, etc).

Surface gravity is the same: ~9.8 m/s^2. The intention of 6.4x Kerbin is, as I see it, not realism, but rather scaling KSP up a bit to ratchet up the difficulty, and help account for the increased performance of rockets using FAR and Real Fuels. It's also big enough to make achieving orbit feel like a big accomplishment: LKO requires a smidge more than 6 km/s orbital velocity, which isn't a hop and a skip from the launchpad.

To supplement, here are the instructions for bug reports (including how to find the appropriate log). In any event, possibly a botched installation, but beyond that, Chris really needs the log file to do anything.