Starman4308

What you need to do is either copy-paste the BB code field when viewing your image, or copy the direct link, click the "insert image" button here, and paste the direct link into that button. The result should have the direct link surrounded by IMG tags, as so: [noparse][/noparse] In any event, remove the fins from the upper stage. You want fins to be below Center of Mass: KSP gets a bit confused by control surfaces in unexpected places, and it's good practice anyways for if you decide to use FAR or NEAR aerodynamics. By your upper stage, you shouldn't really need aerodynamic control surfaces anyways. I redesigned your rocket a couple times: version I is pretty much your original, and version II replaced the two Mainsail arrangement with a single vertical Mainsail and a couple Rockomax BACC SRBs. Version III was more or less me trying to get the same performance with a different design, using a Poodle instead of the LV-T45 and a Skipper in place of the Mainsails. It doesn't have as much delta-V, and will lose a bit more to gravity drag (even with the SRBs set to 80% thrust), but is significantly cheaper, has parachutes, uses the physics-less 400-charge batteries, loses the overkill Gigantors, and uses a bit of onion staging (fuel tanks on top of SRBs).

DRE is balanced for stock, which has much lower reentry velocities. The solution is literally in the first post.

Staging error. Make sure the SRB decouplers are in a stage before the main engine decoupler. And while KSP tries its best to set up a good staging order, it usually fails horribly. Always manually inspect and reconfigure your staging. EDIT: Look at the stages in the lower-right. The first one will decouple SRBs and the Mainsail at the same time, while the second one has had the Mainsail decoupler moved one stage up.

Hey Necrobones, are you happy with the tank configurations as they are? It shouldn't be much effort for me to write up a RealFuels patch for those. I think Raptor is working on incorporating the engines to his config, but that may take a bit more time (more complex math involved, engines more likely to change in the final version). I like the concept of the first-stage engines by the way, giant fuel hoses like the Rocketdyne F-1 built with one purpose in mind: lifting colossal rockets off the ground.

First off, uneven struts can cause a spin, because they affect the rigidity of the attachment, causing the engine to twist around the decoupler (or strut, etc). Fuel lines also count as struts. In general, you want struts to be as symmetric as possible and placed far from the attachment point. Second, Wanderfound is right: off-axis orbits are usually just piloting error. Keep your eye on the trackball and keep moving along the 90 degree axis. An unstable design might make it difficult, and you might make a joke design which must go in a certain direction, but it's mostly just sticking to 90 degrees on the trackball. Third, you would probably benefit a lot by replacing your radial Mainsails with a stack of 2 Jumbo-64 tanks (or 4 32 tanks) with a single Mainsail and a couple SRBs (Solid Rocket Boosters). For stock ascents, you usually want your launch TWR to be between 1.6 and 2.0*, and for the amount of fuel and payload you have, you get 1.4 TWR from a single Mainsail, which can be boosted with a couple cheap SRBs until you burn some of the fuel off. *The most fuel-efficient vertical ascents occur when you are traveling at terminal velocity (force from gravity equals force from aerodynamic drag). As such, for the vertical part of your ascent, you would want TWR to be slightly greater than 2 (1 for gravity, 1 for aero drag, a little remainder for acceleration); however, as you burn fuel, your TWR will go up past your launch TWR, requiring you to slow down (look Ma, wasted engine mass!). To quickly calculate TWR and delta-V, I would strongly recommend the Kerbal Engineer or MechJeb mods. Some people dislike MechJeb's autopilot functions, but both of them assist in rocket design by giving these figures.

15 m/s is indeed a very slim dV margin, and bespeaks either very good or very bad design skills, depending on how you look at it. In any event, the tech tree is a bit hard to cope with: a lot of the things you need to pull off good interplanetary missions (particularly docking ports) come so late in the tech tree that you pretty much need to spam Mun/Minmus biomes until you have almost finished the tree. What I'd probably do is move the end-game science parts and docking ports to a lower node, nerf the gain from those end-game parts, and nerf Mun/Minmus biome-specific science, such that you really need to send some lightweight probes to other planets to polish out your tree. Also, in the spirit of the thread: started re-designing a new unmanned Duna mission, abusing NecroBones's 1.25m cargo bay to stuff in a million science parts and other little things. I just had the idea of sticking my Duna landing parachutes on radial decouplers, which is much easier to handle than a stack parachute with Sepratrons.

You need to forget everything you learned about ascents. You also need to stop using MechJeb (unless you really tweak the gravity turn profile), because MechJeb is tailored to stock aero. Step 1 of ascent: Make sure you have fins to drag center of lift/center of pressure behind center of mass. Also, aim for a launch TWR of 1.2-1.6. Also, in general, wobbly payloads and long fairings are bad news. Strut it up, try to make it wider, and if you must have a long vehicle, consider assembling in orbit. Step 2 of ascent: At around 60-100 m/s, turn about 2-5 degrees in the direction you want to turn. Step 3 of ascent: Wait for prograde marker to catch up. Step 4 of ascent: Look Ma, no hands! Step 5 of ascent: Once past 20-25 km, you can start to have your own ideas about where to point the rocket. The thing about FAR is that, if you do not deviate far from prograde, you benefit from aerodynamic stability: if Center of Lift is properly behind CoM, aerodynamic forces will try to keep your rocket pointed in the direction of travel. If you deviate too far, you will start to flip over. This is most noticeable in the 10-20 km range, where you've built up a lot of speed but still haven't gotten through the thickest of the atmosphere.

Or you just attach wheels directly to the engine and back slowly into the water. I've done that a few times: been able to recover 100%. Except for the one time that, when the SRB finished firing, I let off the brakes, and it slid back into the water just fast enough to destroy the booster.

Finally completed that Apollo-style mission to the 6.4x Mun, from launch to reentry. I don't feel very good about it: I redesigned my CSM a little and forgot to add life support (requiring a little save-file editing), and found out that the "bug" causing Bob to crash last time was probably just me not accounting for the greater max terrain height in 6.4x (smashed into lunar regolith on the dark side of the Mun a couple times until I figured it out). On the plus side, I raked in almost 850 science, enough to unlock the seismometer, gravity meter, and sensor nose cone I wanted for my Duna mission.

You'd either have to do some config file editing, or write a Module Manager-based mod to do that. I think this should work for a Module Manager-based mod (haven't written one from scratch, yet, so there might be something I've forgotten). I snagged the list of wing parts off a FuelWings config file, which may or may not have included all the parts. // Could also do @PART[partlist]:FOR[ModName]. That may or may not work better. @PART[sweptWing1,sweptWing2,wingConnector,wingConnector2,wingConnector3,wingConnector4,wingConnector5,structuralWing,structuralWing2,deltaWing,delta_small,wingStrake,StandardCtrlSrf,elevon2,elevon3,elevon4,elevon5] { @TechRequired = start }

I'm not sure that can even be done. KSP is one of those rare CPU-limited games, the physics is single-threaded, and physics time is super-linear with respect to part count (physics calculation time increases faster than the number of parts you add). Many people start to see lag in the 250-400 part range, and a 1700-part vehicle is probably going to cause any CPU to grind to a near-halt. I would suggest moving your delta-time slider all the way to large time steps: it reduces the accuracy of KSP simulation, but will increase framerate. Even still, I suspect you won't see a crisp framerate.

It would be very useful to have the images here in the thread. In any case, the most likely problem is that your payload is asymmetric, causing a misalignment of CoT (Center of Thrust) with CoM (Center of Mass), causing it to spin. You'd be surprised how even a tiny misalignment can cause a major torque (spinning force) on your rocket. The other thing I can think of offhand is that you might've accidentally messed up the staging order or fuel lines of the Kerbal X booster, causing asymmetric fuel drain, and thus a CoT/CoM misalignment.

Ion engines are done. My sole question is if you want me to include the spreadsheet I used to calculate the parameters along with the pull request. The three custom configs range from 1800s at 2.7 kN of thrust to 3600s at 0.675 kN of thrust, all consuming approximately 4 Gigantors' worth of electricity (the higher-thrust variants use more). The stockalike is for people who want stock performance. Based on feedback from Nertea, I didn't touch atmospheric Isp, so ion gliders are still a go. I would've liked to have this sooner, but real life got in the way. EDIT: I just noticed my Isp values were a half-hour, 45 minutes, and an hour. I completely did not plan this: I was just tweaking them to get somewhat saner values. EDIT #2: Anyone know some decent open-source software for low-acceleration maneuvers? Trying to do standard manuever nodes for interplanetary transit is just about impossible in RSS with an ion engine, and if I can steal the code logic, I can write a kOS script.

You can refuel anywhere: your plan is possible, albeit hardly the most efficient way to do it. The primary issue is that space shuttles are a bad idea for space: the wings are dead mass when there's no atmosphere*. For efficiency, you want to use SSTO jet-powered spaceplanes to bring stuff up (particularly fuel and light payloads), but dump off the SSTO's payload in LKO and immediately return them. You might, say, bring a probe to orbit in a cargo bay, dump it off, and the probe will propel itself to its destination. If you really like space shuttles, go for it, but wings do you precisely 0 good in vacuum. *It's also really difficult to stick a landing on airless worlds without placing dedicated VTOL engines, which are more dead mass for getting to and from that place.

Short answer: Yes, if you're thrusting prograde. It's better to think of it as "capacity to change velocity by 2,000 m/s", because that eliminates wonkiness with reference frames, the direction of your burn, and gravity. Long answer: in the absence of other forces in a non-accelerating reference frame: yes. If your reference frame is Kerbin, and you are trying to get off the launch pad with a TWR of 1.01, you aren't going to be able to change your velocity much, because Kerbin surface gravity is eliminating 9.8 m/s per second of your upwards velocity, so you have to spend delta-V to replace the velocity lost to gravity drag.

There's no way to skip getting fuel to orbit. The Extraplanetary Launchpads mod might let you assemble craft in space (once you get suitable materials there), you can refuel in space by docking, and various mods allow ISRU (In Situ Resource Utilization, making fuel from stuff you find on planets or asteroid), but you cannot magic up rockets from the aether. In any event, it is really not difficult to get to the Mun and back in 2-3 stages. Are you using sandbox or career/science? I'm testing out a slight modification to my first attempt at a "this is how you get to the Mun with barebones tech" rocket.

They're procedural; right-click the part, and a size slider should pop up. The arrow keys allow for large changes in radius, while clicking and dragging on the slider allows fine control (down to millimeter accuracy).

So... then why are your rear wheels so far from CoM? You need your main wheels to be just about below CoM to minimize torque, and keep the weight almost straight down on the wheels.

While it won't be nearly as fancy as the real Curiosity rover's entry* shell, Procedural Fairings can be used to make nice shells: in this case, you'd probably put a fairing ring just on top of your heatshield (perhaps use Deadly Reentry with the heat transfer coefficient set to 0.1 or something), another fairing ring at the top, and whack on a fairing to one, which will stretch to the other.

This thread is pure gold for making your first aircraft. My greatest piece of advice is to beware CoM (Center of Mass) shifts as fuel depletes: RCS Build Aid can be used to visualize where dry CoM is.

If you don't want the full Realism Overhaul experience (I don't, at least not until the RO career mode project gets going), there are ways to do RO-lite by installing components of RO. The big ones: Real Fuels (changes tank and engine masses to be far more realistic, gives more variety in liquid fuels), some config for Real Fuels (I enjoy Raptor's stockalike configs), FAR (makes the souposphere much easier to deal with), Procedural Parts (to help build stuff big), and a large parts pack like KW Rocketry (make sure it is compatible with your RF engine config). Just be sure to read the descriptions of these mods, particularly Real Fuels, or you will be in for nasty surprises. There are other ones I like, such as Deadly Reentry, Real Chutes, and TAC Life Support. If you're running 32-bit Windows, I suggest Active Texture Management to help keep stuff within the 4 GB limit imposed by 32-bit.

It might just be the game engine or KER/MJ being really confused on account of your "orbit" being a straight drop to the center of Kerbin: remember that KSC is not dead-equatorial, but a little offset. I usually eyeball it: I zoom out, line up Minmus's orbit with Kerbin's equatorial plane, and launch when it looks like I'm just about under Minmus's orbit.

There's been another recent thread here. In short, I'll echo what's been said before: you can get some spectacular gains from a Munar flyby*, milk crew reports to the greatest extent possible, and EVA reports are your friend. One caution on crew reports: they cost 30 electrical charge to send, the Mk. 1 capsule stores 50 charge, and the only way to get electricity before solar panels is to fire liquid-fuel engines (not including the LV-909, which strangely has no electrical generation). You also need some of that electricity to turn your vehicle: reaction wheels cost charge. *The way to do it is a free-return trajectory. This requires that you set up an early, high-thrust Hohmann transfer which gives you a figure-8 around the Mun and back into Kerbin atmosphere. Don't be too afraid if you can't quite nail the Kerbin atmosphere: you can perform correction burns very efficiently at your Munar periapsis (all praise Oberth). NecroBones has a couple free-return tutorials in his sig. EVA reports from low orbit are unique to the biome, so you can get different EVA reports from low space over: Kerbin's oceans, Kerbin's grasslands, Kerbin's highlands, Kerbin's mountains, Kerbin's shores, and a few misplaced patches of tundra in a single equatorial orbit. If you go into a polar orbit, you can also collect the poles, tundra the legitimate way, and badlands: Kerbin will rotate under you as you orbit, allowing you to fly over everything if you are sufficiently patient. The Gravioli detector also has the wonderful property of having biome-unique reports from low orbit (and high orbit too), but takes a long time to get to, but everything else is either global (unique to situation, not biome) or requires that you be in atmosphere or landed. I designed a Munar rocket which requires a bit more than Umbral's rocket: it requires basic rocketry, stability, survivability, and Science Tech, but is 100% capable of landing 4 goo pods and 4 Science Jrs. on the Mun and returning. Three pieces of advice not conveyed by the picture: add a couple radial parachutes (the lander is too heavy for the one parachute I used on the test), right-click and remove all monopropellant from the command pod, and right-click the RT-10s to set their max thrust to be about 60-80%.

Once the bugs are cleared out and Raven releases an updated version, CactEye should be what you're looking for. I like the idea of needing orbital telescopes, but I don't think it should be stock: for stock, it's best to keep things simple for new players.

Sounds delicious. Your problem is that both of the interstage fairings (which are more meant to cover engines between stages) are trying to cover each other, and so keep expanding to do so. To get a single fairing over a midsection, what you should do is attach two fairing bases (or fairing base rings) facing opposite directions; you can then attach a fairing to one of them, and it will stretch to the other one, as so: