Streetwind

Yeah, the commonly given form uses effective exhaust velocity, v(e), instead of I(sp). Conversion factor is the gravity constant g(0) (not the actual gravity g). People keep disagreeing about what that constant is set at for KSP, with some claiming 9.82 and some claiming 9.81. I use the latter, because it gives me the "worst case scenario". dV = v(e) * ln(mass ratio) = I(sp) * g(0) * ln(mass ratio)

Nope. Going uphill takes extra energy, meaning extra fuel. Just try it with your own car: drive along a level road at a fixed speed, and then keep your foot's position on the pedal perfectly steady as you start going uphill. You still burn the same amount of fuel, but your car slows down. If you want the car to hold its speed, you must depress the pedal further, meaning you spend more fuel. This is independent of speed. Going uphill costs fuel because you go uphill. In physics terms: Energy is always transformed, never lost or gained. Going uphill is equal to raising your potential energy. That energy has to come from somewhere. It comes either from your vehicle's kinetic energy (you slow down) or from your vehicle's chemical energy (you expend more fuel).

Turn towards the horizon in the direction of rotation of the celestial body, as soon as you can, as hard as you can without falling back down or hitting a mountainside. 5 meters above the ground is just as much an orbit as 50 kilometers, as long as there are no obstructions. Ascending vertically means spending fuel on countering gravity. But go sideways fast enough, and gravity goes away for free. EDIT: also, a tighter orbit doesn't require you to accelerate sideways as much, i.e. you need less fuel to launch and circularize right above the surface as opposed to dozens of kilometers out. And the Oberth effect is stronger the closer you are to the celestial body, as well. Exceptions may apply. if your intent is to escape the celestial body, and the ideal escape vector is straight above you in the sky, then launch straight up. A good example of this is you are returning to Kerbin from the Mun, and your landing site is directly retrograde of the Mun's orbit.

I want my station to be rotate-able so that the command cupola can be made to face Kerbin at any given time. Is it necessary? Absolutely not! Do the Kerbals want to gaze at their homeworld anyway? Absolutely so!

KSP uses real physics in most places, but often chooses simplified models that are "good enough" for the application at hand. For example, gravity interactions in space are usually a n-body problem, which can get very complicated in a hurry. But KSP uses an approach called patched conics in which only one body affects your spacecraft with gravity at any one time. The simplification is possible because there is one body (Kerbol) which overpowers all other bodies by gigantic proportions. Therefore, you know that any object in KSP is always in orbit around Kerbol, no matter where it is and what it does (even when landed on a planet). Because that is always true, you don't have to bother calculating it; you just focus on the thing that applies the most changes to your Kerbol orbit - in other words, the closest celestial object. The result is accurate to within a couple of percent, which is not always accurate enough IRL but is all but indistinguishable from the real thing for gameplay purposes. We don't have Lagrange points, but that's about it. Units for ingame numbers are a thing that I missed as well when I started, because I didn't know how to interpretate the numbers in the part stats. But you can very quickly figure it out empirically. KSP uses the metric system, and the units for common numbers are: weight in tons, thrust in kilonewtons, specific impulse in seconds, distance in meters, speed in meters per second, acceleration (including gravity) in meters per second squared. Other numbers are completely arbitrary, such as electric charge or the number of fuel units in a tank.

I always thought of it like this: - Vehicle speed scales linearly with engine rpm. - Fuel usage scales fairly linearly with engine rpm in a frictionless environment (like when you run the engine on a test stand). - Combined friction from wheels, aerodynamic drag, slip etc. increase exponentially with vehicle speed. - Going uphill while keeping fuel input constant slows you down. Therefore: - Maintaining speed while going uphill requires more fuel input. - Going faster, regardless of uphill or not, worsens your gas mileage. Finally leads to: - Going uphill fast is less fuel efficient than going uphill slowly.

Thanks, I learned a lot today!

Good news, that. I tend to decouple and deorbit the probe cores used to transfer the parts. And I worry about stationkeeping because of experiences with a station in Minmus orbit, which naturally comes with a very low orbit and a very low orbital energy/velocity. I noticed that the mere act of the docking collars sucking two crafts towards each other in the final coupling moment was enough to modify the opposite apsis by a two-digit amount of meters (depending on the size of the docked craft). And in an orbit of around 10,000m, that number may have been small but not insignificant over time and continued use. I suppose a station screaming around Kerbin at 2500 m/s would be a lot less affected. Now, extra questions: - Will rotating a highly asymmetric object induce translation, in the same way an unbalanced translation induces rotation? - Am I understanding you right, that switching to precision control will actually make the thrusters dynamically throttle themselves as needed in regards to their position, whereas in normal control mode they always fire 100%?

I'm planning a new space station. It will consist of at least six individually launched parts that get docked together in orbit. Each of these parts will come with RCS installed, and the station is ultimately supposed to use RCS for turning and stationkeeping (what little of it you need to do). The question is: does that even work? Can you stick together random parts that all have enough RCS thrusters for themselves, and then have them work together as a whole? Or is any RCS equipped station destined to be an uncontrollable mess unless you pre-assemble all of it in the VAB and then never change its weight distribution (making it useless for refueling)? I could of course stick reaction wheels on everything but I kind of want to avoid using magic this time around...

Too bad you can hardly see anything since it's deepest night.

Considering you can easily do everything in the game without needing a crutch like MechJeb - go for the barometer. Not because the barometer is particularly good, but because the next thing it unlocks (the seismograph) is. You really want that on all your off-world landers.

From the Squadcast interview, it seems they will be offering new stock rocket parts to deal with the insane amount of delta-V required to intercept an asteroid on an arbitrary trajectory and then insert it into an orbit (without having to resort to breeding up a Newtype Kerbal). These parts are supposedly comparable to one orange tanks surrounded by six more orange tanks - that would make them 7.5m parts, far larger than anything we've seen so far. You can find 3.75m and 5m parts in the modding community, but this looks to be much much larger still. Of course, take this with a grain of salt, as interviews can be misunderstood, and even things that are true today might change tomorrow if it makes sense for the game. As far as my opinion goes, I'm not sure I understand the need for parts of this size... KSP as a whole is scaled down quite a bit from IRL. But it seems to me that a 7.5m part would be close to a life-size replica of the SLS, which as of current plans will feature a 8.4m main stage (built around a modified space shuttle external tank frame). Isn't that just a little bit big for Kerbals? And if these parts become stock, don't we need something in between? And how will they affect the difficulty of the game, considering the sheer payload capacity they'll offer? I sincerely hope that Squad will find a reasonable compromise.

Good point. Thankfully unnecessary to experiment with it, though, because I just successfully fixed it. By doing @key,0 and @key,1 instead of two times @key, I got it to set the atmosphere curve correctly. Which still does not explain the really strange error with the negative thrust/Isp I got before. *headscratch* I suppose I'll just have to wait and see if it returns during further experimentation...

Okay, even more confused now. I started troubleshooting the issue by removing all my mods. The issue disappeared. Then I spent half an hour adding them back in, one by one. They are now all back in - the exact same folders, no changes - and the issue has not reappeared. The booster works fine... ...except that on close examination, I am getting 280-280 Isp and not 280-300. So I must have screwed up something with the atmosphere curve. @MeCripp: Thanks for the suggestion, but by the understanding that I got from post #2, wouldn't that create duplicates of all those entries that the original file already has? Maybe that's why the Isp is wrong, maybe I need to address the two identically named key values differently...

Hello all, super confused newcomer here. I just downloaded ModuleManager today and tried to do something (anything) with it. For starters, I thought, let's try and modify a stock part. Like a solid rocket booster. The default values have it running for ca. 30 seconds at 250 thrust, with an Isp of 225-240. I calculated that 310 thrust at 280-300 Isp should also run 30 seconds. So after carefully studying the instructions in post #2, I did the following: @PART[solidBooster]:Final { @MODULE[ModuleEngines] { @maxThrust = 310 @atmosphereCurve { @key = 0 300 @key = 1 280 } } } After heading back ingame and checking in the VAB, I confirmed that the changes did indeed take effect. The part info shows 310 thrust and the Isp specified. The fuel flow rate changed as well, but only by the second or third digit after the comma, which basically means that runtime should be unaffected, just as I had planned and calculated. Then I went to the launchpad... and upon igniting the booster, I got this: https://dl.dropboxusercontent.com/u/44754370/screenshot12.png Ummm... what? o__O Help? KSP 0.23 with ModuleManager_1_5_6.dll

So I figured it out. It didn't like me having struts attached to modular girders, for some reason. As soon as I removed those struts and attached them to somewhere else, the issue immediately stopped. When previously, the craft would have spun itself enough to make a full rotation within half a minute of stopping time warp, now it stays perfectly still. Watched it for 5 minutes and it didn't even budge a degree out of line.

I think it was the first one in the dropdown menu that TreeLoader gives you. I just grabbed one without really looking. Yeah, I grabbed TreeEdit and noticed the differences and observed how the nodes behave. The question I now have is - how did you export what you built in TreeEdit into the tree.cfg textfile?

Keyboard & mouse here.

No, I don't have a cat. No, I was not under 100km to the planet - I was 1 hour out from a Mun intercept, about 9-10 million km above Kerbin. However yes, I was moving slower than 750 m/s. Very interesting. I also find it curious that no other spacecraft of mine, many of which flew nearly identical routes, ever exhibited this. It was so strong, I could sit and watch it happen - zero out everything perfectly, then turn SAS off, and within 10-20 seconds it would be spinning randomly again. Could this maybe be the result of accidental part clipping, since it seems to be craft specific?

Okay, here's a funny story. Just before dinnertime, I was checking the arrival times of all my current vessels in flight. Then I jumped back to the ship with the shortest time left (a couple hours). I set the camera for a pretty perspective with Kerbin in the background, then went downstairs to cook and eat. I did not touch any ship-controlling button whatsoever. SAS was off, no RCS installed, and the ship completely stationary. Roughly one hour later, I come back to a ship that's spinning wildly around all three axes. What is happening here? o_O

Thanks for the answers! Disappointing, but okay, I can work with that. I'm just slightly confused that the arrows are drawn differently from the way they are drawn on the stock tree. There, the arrows aim for the middle of a node icon, whereas here, they seem to aim (rather sloppily) for the upper left corner. In your tree, it does sometimes one thing, sometimes the other, almost randomly. How did you build your tree? Completely with TreeEdit, or did you also edit some nodes in by hand? Maybe I'll switch to a vertical layout as well, to see if that helps things... I haven't seen a top down one done yet EDIT: I just looked at one of the trees builtin via TreeLoader. And dang, just look how smooth this one is. All the arrows are proper and correct. I'm starting to wonder if the issues are connected to using a tree.cfg file, or if TreeEdit lets you do something extra that the file doesn't let you do...

Hey Ackander, you seem to me a fairly skilled and knowledgeable individual when it comes to custom tech trees, so would you mind if I asked you some questions to help me get my feet wet in the topic? I'd like to know if there is a way to: - Center the research window onto where my starter node is. Coincidence has it that my starter node would be just barely outside the normal view when you open the research window... - Have the player start with something designated "newnode_" already unlocked. I notice only the stock "start" node unlocks itself by default; is that a feature I can assign to other nodes? - Avoid this ugly junk from happening with the auto-drawn connectors? It's ruining all my planned symmetry!

Nope, but there are science instruments meant for use inside the atmosphere. Namely the barometer and the sensor array nosecone. The thermometer also works, in contrast to space (where it only works when being landed on a celestial body). So you can get a number of science points by exploring Kerbin's biomes with your plane.

Well, here is the craft file of the stock variant. It is not very good by most standards, but considering that I built it on my first playthrough ever, in career mode, without reading a single design guide (a rule I tend to set for myself in games that rely on player skill and knowledge) I was still fairly proud of it. Though not the first one to achieve a Mun landing (that goes to variants VI for a one-way trip and VII for a return trip), this rocket was the heavy muscle that earned about two thirds of the total amount of science needed for the stock tech tree through many consecutive (and often parallel) missions to both moons. After the addition of mods it has since been improved in many areas, most notably by adding more thrust so it isn't underpowered anymore (back then I didn't know about ideal speeds inside the atmosphere). I did a few test flights just now. Rotating the engines by 45° definitely did something. I wasn't able to fully eliminate roll, maybe because I have other sources contributing, but it was noticably reduced. And in one case, even switched directions! Quite funky, but good to know for the future

Very interesting, Claw! This would imply that there is some sort of directional weirdness going on with the physics simulation of the engine part. Case in point, the roll also happens with mod-added engines - KW Rocketry's Wildcat-V's are a great replacement for the LV-45T's. The Wildcat's model does not feature a one-sided exhaust, I believe. As such, I highly doubt that the game is trying to simulate minor thrust from exhaust gases or anything like that. Even the location of the exhaust should be irrelevant; for the LV-30T it was probably pure coincidence that the model was aligned in a way that made sense with the behavior. It's likely related to the part itself, internally and model-agnostic. I will test and confirm/deny whether rotating the engines fixes my roll (both for the LV-45T and the Wildcats) when I get home today. If people are interested, I can also provide the craft file (stock variant) and/or screenshots. Just didn't think it was important since the phenomenon is easily replicated.