Smidge204

Pricing is based on the amount and type of material, the physical volume occupied in the machine (a large, hollow print will be more expensive than a small, solid print that uses the exact same amount of material), and labor to process the part (e.g. cleaning the unused material from the part). The small stargazer has a bounding box of 84.27 cubic centimeters. Valentina takes up 247.55 cubic centimeters. That's nearly three times the volume and hey, she's about three times the price! =Smidge=

Seems very straightforward to me that if your fuel is producing more useful energy, then it's worth more delta-V. Answer me this: Where does that extra useful energy go if not into your craft's kinetic energy, and therefore manifest as extra velocity? Okay. Here's the rocket equation: *points to ve - the exhaust velocity term* The exhaust velocity relative to the rocket is constant. The faster you go, the slower the exhaust velocity will be relative to some inertial frame. The slower the exhaust velocity, the less energy it has. Where does that energy go? Into your rocket! The goal of "get from the surface of Kerbin to Duna's SOI" is made of several specific maneuvers. If it does not apply to specific maneuvers then it's not at all clear how it would apply to a collection of maneuvers. Here's an experiment: Build a ship and HyperEdit it into a a few given, nearly perfectly circular orbits around Tylo and see what the total change in velocity it can do in each situation. The ship will comprise the following components: 0.8000t - Command Pod Mk1 0.5625t - FL-T100 fuel tank (full) 0.5000t - LV-909 Engine Total start mass: 1.8625t Total empty mass: 1.3625t Engine Isp(vac): 370 seconds Calculated dV = 370 * 9.81 * ln(1.8625/1.3625) = 1134.64 m/s The engine will burn for 9.07 seconds at full throttle. We will test the claim that the ship has a fixed delta-V. If true, we would expect that whatever our velocity is to start with, our final velocity will be Vo + 1134.6m/s higher when we're done in every case. If I'm correct, however, we should expect our final velocity to be larger and dependent on our initial orbital velocity. I'm choosing Tylo because I can get very low and fast without worrying about atmosphere, maximizing the range of starting orbit altitudes. In practice it should not matter, but experimentally it should be easier. Edit: Okay, Tylo wasn't as ideal as I thought it would be... SOI is actually rather small and it's hard to keep it straight with such a small radius. Going to the Sun! Solar Orbit 1: 101000 meters at 63124.0 m/s. Final velocity: 64292.0 m/s. Change: 1,168.0 m/s. Solar Orbit 2: 10119100000 meters at 10627.0 m/s. Final Velocity: 11794.7 m/s. Change: 1,167.7 m/s Solar Orbit 3: 1012400000000 meters at 1076.0 m/s. Final velocity: 2243.6 m/s. Change: 1,167.6 m/s Solar Orbit 4: 10200000000000 meters at 339.0 m/s. Final Velocity: 1506.6 m/s. Change: 1,167.6 m/s Trying to go much further out results in a Kraken encounter. The effect, though, is small but clear. =Smidge=

Which is one reason why this discussion has managed to hit 15 pages. It's somewhat wrongheaded and easily causes confusion. Exhibit A. If that were true, there would be no consequence of the Oberth effect because the total amount your craft can accelerate would be constant regardless of circumstance. However, your engine is more effective at higher speeds - meaning that if you start at a higher velocity your fuel is worth more delta-V. It's NOT the same. This confusion goes away when you stop thinking of delta-V as a number that MechJeb throws at you as if it were a physical metric of your craft. Delta-V is not an intrinsic property of your craft just as the miles you can drive is not an intrinsic property of a car. It's a potential that is subject to change based on conditions... one of which being how fast you're already going. =Smidge=

So does Oberth reduce dV requirements, or does is not have the ability to change dV requirements? This is why I've been harping on "dV is not a physical quantity" - your craft does not "have delta-v" any more than your car "has miles." Your craft has fuel, which it can use to change it's velocity, just as your car has fuel which it can use to travel some distance. The point I've been trying to make - and which we now seem to agree upon based on your more recent post - is that delta-V is analogous to the distance to your destination; Oberth can not decrease your delta-V requirement any more than driving a more fuel efficient car can make your destination closer. What it can do, though, is have the same effect as burning the fuel more efficiently. You still need the same delta-V to get where you're going, but you just need less fuel to get there. =Smidge=

Not that it matters, because Oberth manifests itself anyway simply because the game understands and implements basic Newtonian physics. It does not require additional simulation. Force = Mass * Acceleration. Engines provide the force, the ship has mass, and therefore the ship is given an acceleration. Work = Force * Distance. Engine provides force, the ship is moving (at an ever increasing rate.) Work is being done even if the game does not explicitly calculate it. The engine "burns" a certain amount of fuel every second. During that second, the ship will cover some finite distance (S = V*t + 0.5*a* t^2). Therefore, that amount of fuel can be equated to a certain distance traveled, as a function of velocity and acceleration. Since engine force is constant, and fuel use per distance traveled is a function of velocity and acceleration, then the faster you are moving the more distance you travel per second. And since fuel use rate is also constant, then the faster you travel, the farther you travel per unit of fuel consumed. Therefore! Since work is force multiplied by distance, and the faster you are going the larger the distance per unit fuel consumed, then the faster you are going the more work is being done per unit fuel consumed. And you never had to actually calculate energy or work for this to happen - it just happens. Let's glue all of that together: Work = delta-Ek = delta-(0.5 * Mass * Velocity^2) = Force * Distance = Force * (Velocity * Time + 0.5 * Acceleration * Time^2) It's pretty easy to see that the change in kinetic energy (and therefore the change in velocity) is dependent upon your current velocity. That's Oberth writ large and you don't need to do any special simulation to make it work. No, no it does not. You seem to be confusing delta-V as some sort is discrete physical quantity, rather than a convenient way to express specific energy (energy per unit mass) of the craft. If you are in an orbit at R1 and want to be in an orbit at R2, you need to change the specific energy of your craft by some amount. You effectively do that by changing your velocity (since conservation of momentum prohibits you from magically decreasing your mass without consequence) which is expressed "delta-V" - literally "the change in velocity." Oberth can't affect the amount you need to change your specific energy, only how much fuel you need to spend to make it happen. =Smidge=

I think just about anything wold be easier than what you just described... For starters, you're almost always better off leaving the launchpad at or close to the inclination you want. If you time it right (launch just before KSC passes under the ascending/descending node of the target) you can match orbital planes very closely right from the start, and the extra dV you miss out on by not going due east is more than made up for by not trying to change your inclination later. You don't always need to circularize immediately after reaching orbit and then proceed to a transfer maneuver. If you time it right you can go directly to the desired orbit. If you must change your inclination by a lot after you're in orbit, you want to be going slow... so raise your Ap way, way up, change inclination, then lower it back down. If you only need a relatively small change, you can usually combine that into your transfer burn with minimal penalty. Ultimately, unless your timing is perfect, you DO want your orbit to be slightly more or less elliptical than the target's... with either your Ap or Pe matching. This will mean your orbital periods will be slightly different and allow the two craft to eventually meet up. =Smidge=

Moreover, the dV you get from the first "unit" of fuel will be different for the dV you get from the last "unit" of fuel, because the mass ratio changes. That makes any attempt to define dV in terms of fuel units a poor estimation at best. =Smidge=

Get creative with trusses: That's all of the stock science bits. Everything is accessible from the ladder for collecting the data prior to jettison. It's build from a single Cubic Octagonal with a tiny decoupler on it, and the nosecone is mounted to an Octagonal Cubic on the side of the first one (and I can probably clip the nosecone in farther if I ever go back to that design). Pretty compact, not a complete eyesore, totally stock. =Smidge=

Joints are flexible. Even if things are perfectly assembled, once you're under the influences of gravity, lift and thrust your whole craft warps and twists because the joints are not infinitely rigid. One theory is that any engine that it not directly in line with the CoM of your rocket might end up ever so slightly twisted/off-center, and even if the thrust and mass is balanced by symmetry this offset is not mirrored and can cause odd behavior. Since most rockets have plenty of pitch/yaw control with gimbal'd engines, they usually lack in roll control... so your rocket starts to roll, which is also self-stabilizing to a point since any pitch/yaw induced by an offset engine gets averaged out over a full rotation. That's the idea, anyway. You can add lots of struts to see if it helps (usually does), plus there's promise that 0.24 will improve joint mechanics. =Smidge=

Don't wait until you're at Apoapsis to burn towards the horizon. You may need to pitch up to keep your craft from falling down again. Exactly how much going to depend on the craft, but with practice you should be able to keep the prograde marker on the horizon line - if you can do that, you can actually "surf" the Apoapsis all the way to a circular orbit. Check out the video below starting at around the 3:50 mark. TWR < 1.0, just have to ride the apoapsis. Note the navball shows I'm pitched upwards quite a bit... https://www.youtube.com/watch?v=D3Y3e_TciAE =Smidge=

Did you take a photograph of your screen? >.> Press F1 and look at the "Screenshots" folding in KSP's install directory! I don't know much about the mod you're using, but if there is anything not part of the module that is attached in top of the hatch, that is an obstruction. Even if it looks like there's a hatch, or if the attached part is "hollow" and you can see the hatch through it, it's still obstructed. =Smidge=

I finished the second leg on my All-Biome science rover roundup: (Path approximate based on craters I explicitly remember driving around) That's about 6 hours of real-world driving, with much more to go! =Smidge=

I will add this: 1) Disable steering for the "rear" wheels on your rovers to allow better high-speed handling, as you will not turn as sharply and be less likely to flip over. The downside of course is a larger turning radius. 2) Keep SAS and your reaction wheels on when driving, and use docking mode/remap the keys so you are not pitching forward when trying to drive forward. This will help keep you rover stable even at high speeds. The downside is it can make turning difficult since the reaction torque will resist the wheel's attempt to turn the rover. 3) To combat the downside of (2), use both turn and roll controls to "lean in" to a turn. Roll (Q and E) still works in docking mode, and by rolling into the turn you are putting more weight on the inside wheels, giving better grip and helping you turn. You are also helping to counter any centrifugal force on your craft from the turn itself making it less likely you'll flip. 4) If you have a lot of torque, periodically turn SAS off for a moment to make sure all your rover's wheels are making contact. I've been able to do some unintended wheelies... 5) When trying to get up steep slopes, consider going back to staging mode. Attempting to go forward will now also pitch your rover forward, which will help push the front wheels down and improve traction. Provided, of course, you don't have so much torque that you do a forward flip! 6) Consider putting a fuel tank and thrusters pointing upwards to provide down force for extra traction. Here's my Science Rover on Mun crawling up a 45 degree slope with relatively little effort thanks to the upward-pointing traction thrusters: 7) Consider putting a fuel tank and thrusters pointing downwards to help you jump over peaks and soften landings if you accidentally (or deliberately?) drive off a cliff. 8) Use structural trusses as bumpers to help guard delicate parts from crashes... as long as those bumpers don't obstruct the function of the parts they protect. =Smidge=

I can't remember the last time I returned from Minmus that didn't have a Mun encounter, at least briefly. Mun's SOI is pretty big and thanks to being in a lower orbit means you're very likely to encounter it. Minmus' inclination is only 6 degrees. This is not enough to avoid Mun's SOI: (Drawn to scale, BTW) It would absolutely be easier to visit Minmus first, in just about every situation. As stated, it would be easier to deal with the fuel required fro a Mun landing on Minmus than the fuel required for a Minmus encounter/Landing/Return on Mun, so burn that fuel early. There's no need for course corrections if you launch at the proper angle; Launch 6 degrees north or south of due east at the right time and you'll be in the proper inclination right from the start. =Smidge=

I got Bill's head caught in the wheel gear of my science rover! =Smidge=

Spoiler: Might have to change the conic section draw mode so see it, but it's possible without too much effort. Edit: After the burn: =Smidge=

Protip: If you really need that much control torque, you can place the SAS modules *anywhere* on your craft and they'll always have the same effect. There is no need to place them in the stack and have their extremely poor structural integrity ruin your rocket. Attach them radially to the sides with trusses like so: Same torque, none of the wibbly-wobbly. =Smidge=

Mash F1 thirty times per second, then make an anigif out of it! +1 for Fraps, but that's not free. I did stumble upon a free utility that records video, unintentionally. MSI Afterburner is a free utility suite for tweaking video card performance, but also includes a screen capture and video recording function. Might be worth looking into since it's free, and not many worthwhile screen capture programs are. =Smidge=

The only thing wrong with my comment, which I do apologize for, is somehow I got my head stuck in a non-inertial reference frame: If the reference frame is allowed to rotate with the ships, then their relative velocity is zero if they are in identical orbits. (Think two painted dots on a spinning disk - relative to the disk they are not moving, but relative to the table or other inertial reference, they are) =Smidge=

There is not enough information in that image to tell which way they're going. All we know for certain from that screenshot is that the orbits are low, very close to the same and very close to circular, and that the two objects are approaching or receding at 4367 m/s. =Smidge=

Two objects in the same, circular orbits going in the same direction will have a relative velocity of zero. In a nearly circular orbit, it would be nearly zero. Since escape velocity for Kerbin is ~3400m/s, the only way for you to get 4000m/s relative velocity is for one of the orbits to be an escape trajectory or very near to it. Or they're orbiting in opposite directions. I mean, look at the screenshot: Nothing in that situation should be traveling anywhere near to 4000m/s. Not in a stock game, anyway... (no mention if he's using any mods.) If you're going 4000m/s at 70km you are on your way to interplanetary space and that is clearly not what that screenshot shows. If, however, one ship is going east at ~2300m/s and the other going west at ~2300m/s, then 4300m/s relative velocity is easily within reason depending the exact phasing. That's why it's easy to conclude the orbits are opposing. Now to be helpful: If the orbits really are that low, get out and push. It will not take much at all to lower your Pe into the atmosphere and then you can just wait it out while each orbit decays a little bit more than the last. =Smidge=

Looks like you took a stock Kerbal X and added another fuel tank. Nothing wrong with that, but I've a few suggestions. For one, the extra fuel tank makes the lander more top-heavy, making it much more likely to topple over unless you're very careful with the landing. I would suggest using four FL-T400 fuel tanks attached radially, between the legs (increase number of landing legs to four as well), rather than sticking a X200-16 in there and making the whole thing taller. Attach them to the main central tank using fuel lines. As a bonus, you could use radial decouplers and ditch those extra tanks once empty, which will boost your dV. Even more bonus if you use asparagus staging. You could even stick additional engines on those tanks - I'd recommend the 48-7S for it's great TWR and quite reasonable efficiency. If using asparagus, put them only on the two radial tanks to be dropped last. =Smidge=

Share pictures with http://imgur.com/ As long as the orbit doesn't intersect Mun or is an escape trajectory, it's fine. First, get your rescue ship into orbit around Mun. Ideally you want to be captured into Mun orbit as high as possible which will make the plane change more efficient. Extra points for matching the plane during intercept/capture! Now you are in a circular orbit around Mun, you need to match orbital planes. Selecting the target, you'll get Ascending and Descending nodes with dotted lines jointing your orbital path with the target's. You want these to be as close to zero as you can manage. Plane changes are more efficient at higher orbits, so if it's REALLY off (more than 30 degrees or so) consider raising your Ap to the edge of Mun SOI by burning prograde at either Ascending or Descending node (whichever is at a LOWER altitude) until your Ap is near 2000km or so. If done right, the ascending/descending node will be close to the Apoapsis. Put a node at the new Apoapsis and tweak the purple handles until the Ascending/Descending nodes are as close to zero as you can manage. Tweak the retrograde handle to get your new Pe to match the Target's Ap plus a little bit. Do that burn to match orbital planes. Note: Direction matters! Don't accidentally put yourself into an orbit in the opposite direction! Now that we have everything lined up, recircularize so that your orbit's Pe is roughly equal to the target's Ap. Doing this will enable you to control where you lower your Pe to match the target's Pe. Use another node. Don't get the orbits TOO perfect, because you want to meet up with the target. Remember that LOWER orbits are FASTER, so if your Ap matches the target, bring your Pe lower than the target's to catch up or leave it higher than the target's to let the target catch up to you. Wait for a close encounter. Once you have an encounter, match speeds with the target at closest approach by burning pro/retro grade to it. Once the relative velocity is the same, the orbits should be the same and you can very gently move in closer for a rescue. =Smidge=

I find landings tend to go a lot better with the wheels pointing down, rather than pointing up. YMMV. More seriously, you have two speed indicators in KSP: The readout just about the navball, which hopefully is in "Surface" mode and tells you your speed relative to the surface, and the readout to the right of the altimeter which tells you your vertical velocity. "Surface" velocity includes the vertical component, so it can be a little misleading some times. The vertical readout should be close to and slightly below zero, indicating that you're descending. You want your descent to be as gentle as possible - though the aircraft landing gear bays are stupidly tough (Good for 60m/s I think?) the rest of your craft might not handle the impact so well. Try to aim for the near edge of the runway to give yourself adequate time to slow down. Apply brakes as soon as all wheels are on the pavement. Disable the brakes on the front wheels to help prevent nose-diving. Learn the gliding ability of your craft and cut throttle early, so you come in slow. Nosing up at the last moment can kill a lot of horizontal speed.] Do your best to line up with the runway early... very early. KSP's runway is perfectly east-west so use the navball for help. =Smidge=

As mentioned, a point moving in a straight line relative to another point will also sweep equal area in equal time. A point moving in a perfect circle about another point will, intuitively, also sweep equal area in equal time. A line (e=infinity) and a circle (e=0) are just two extremes, and the "equal area in equal time" rule applies to all curves 0<=e<=infinity. =Smidge=