arq

At least one person is lying about being Scott Manley...

A turbojet engine provides no thrust near or above 2400m/s (and very very little above 2200), so the only way to do this to enter a fall above 35km (so that your terminal velocity will be high enough to carry you faster). Of course, this involves a vertical component, so the horizontal will never exceed 2400m/s even then. So the Mach7 club is unattainable without leaving the atmosphere (and difficult even then, it involves obtaining a relatively high and eccentric orbit - maybe 100x50km would be enough?).

SSTO does not require clipping (though neither does airhogging), and can be done with a very low intake/engine ratio (heck it can be done just using rockets). Another way to make airhogging less viable is to increase the drag cap on intakes. Though what I would really like to see is more variety in intakes and engines. Specifically, ones designed for very high altitudes and speeds (ramjets or scramjets?). Maybe some that can operate up to closer to 35km, though perhaps with lower TWR to keep them from reaching orbital speeds? Make them have even lower low-speed thrust than turbojets, have low ISP, and/or something else to keep them in-balance and give the other engines a place?

I'd recommend Kerbal Engineer Redux or Mechjeb. They provide this info and more.

Agreed. It would be nice if there were a 'unstaged' stage above stage zero that couldn't be triggered by the staging button. Instead it would require moving the part to an active stage or right-clicking to manually trigger the part.

IIRC, an inactive ship 'crashes' if it gets too close to a body with an atmosphere. For Kerbin, I think this is something like 37km. Otherwise, no aerobraking takes place on inactive vessels. Though I am surprised by SRV Ron's comment above. SOI changes (and thus gravity assists) should still be treated properly. I suspect that was more an issue with time-warp. SOI changes and near-body passes should be done at relatively low time warp (10-50x or less) or else floating point issues can cause orbits to shift.

Interesting. The editor values for pWing lift display as 0.5, but your statement suggests that they need to be changed internally. Does anyone know how pWings compare to the stock wings in terms of lift/mass ratio? Is the Mk3 simply heavier with no added benefit? EDIT: After discovering the debug printer ('o'), I have determined that the Mk2 and Mk3 wings are functionally identical. For a given size and shape they have the exact same mass, drag, lift, and other stats. Also, they very nearly match the delta wing when made to its size/shape.

It shouldn't be terribly devastating on your system's performance.

Going into 'Kerbal Space Program\settings.cfg' and set 'FRAMERATE_LIMIT' to 20 or 30 will likely lessen the GPU load (though 75C isn't awful - just try to keep it below 90ish). The lowest this can be set using the in-game interface is 60. Note that every time you edit the settings through the in-game interface, it will reset this value to -1 (unlimited) and you will need to exit KSP, change the value back, and restart KSP.

I like the OP's idea. Using a part with the proper mass, CoM, Rotational Intertia, Drag, and CoD for the innards would indeed allow identical physics. If something doesn't hold together in this game you can always just strut the #*% out of it and it will (and struts are currently weightless anyway), so the 'internal structural stability' argument is not a big issue IMO (just pretend there is a spiderweb of struts inside that get jettisoned with the fairings). Disabling the physics on those parts would be a massive computational saving on its own (and is the current bottleneck), so disabling rendering is probably unnecessary. The only issue I see is at the instant that the fairings are jettisoned and physics are enabled (stuff might explode unexpectedly), but maybe they could only be staged when the engines are off.

I think the main point of this thread is that a rebalancing is in order. Parts have been added over time and without a hard-set rule for determining stats. Since Squad went through all the trouble to model these parts, it would be nice if each part had a niche that it could fill. This will be much more important with the release of career mode (this game will not remain strictly a sandbox forever, or for much longer based on the dev's latest pushes). For example, engine clusters outperform some of the bigger engines. This encourages higher part-counts, which the game does not like at all. Every part (especially nonstructural parts) should be pareto-optimal for some specific situation (ie the Ant engine gives the highest dV for very light vessels despite possessing abysmal ISP and TWR).

Is Lift Rating a per-mass parameter, like Drag? I have always believed that it is (like drag) because of the values for the stock wings, but have never found certain confirmation. Specifically, does the 50% heavier Mk3 wing provide more lift per unit area than the smaller Mk2 when they both have the same lift coefficient? I just want to make sure I'm not being silly by using it. Also, are they almost 4x less lift per unit weight than the Delta Wing (0.5 vs 1.9), or is the lift rating a more absolute number and pWing scales the actual lift rating in the final craft? If it's true that lift is a function of part mass, I might do some editing to rebalance pWings against some of the stock surfaces, because in that case they are significantly less efficient than almost every other wing.

Also, weight is a consideration. If you use the 3x LV-45's to get gimbling, you have a higher mass. This can offset some of the gain of the higher ISP (or in some cases, all of it). But engines aren't the place to look for unbalanced parts. Look at a lot of the other ones. For example, the Mk1 aviation fuel tank is heavier and carries less fuel than the Mk2. The ONLY reason to use the Mk1 is the shape. Also, prices are meaningless right now. The above two tanks also cost the same. Along with many of the engines.

I like the idea of going out and scanning for anomalies (not necessarily the same as easter eggs) on other bodies and in space. Discovering an anomaly and exploring it (either going there and sending back data or physically bringing back a sample) will award science points, which can be used to advance down the tech tree.

Ferram Aerospace Research (FAR) is the only mod that I know of that takes a stab at improving the stock aerodynamics. Procedural Wings is nice because you can make large wings instead of using 10 small ones. My planes tip (stock aerodynamics) is to not worry so much about the CoL as the CoD (drag). Having many intakes on the front of the craft will tend to cause it to flip because of their high drag coefficient (~7 times higher than other parts). The most reliable way to control CoD is to place as many of your wings as possible near the back of the craft (with only a little bit at the front to keep it under control). The stock aerodynamics are made for rockets, which are fletched like arrows, so you do well to have arrow-like craft. Because they are behind the CoM, if the craft tries to flip or tumble they will help to get you pointed prograde again, and keep you there.

Agreed. When landing on a gear in a vacuum, you need to treat it like the rocket it is. Once you are hovering upright over the surface, pitch forward and come down on the gear. I had bad experiences trying to land conventionally on Minmus, even at 30m/s (I bounced then crashed 10 times before abandoning the idea). But a conventional takeoff works fine. Just try to get off the surface ASAP so you don't hit any bumps.

Start small. One turbojet, 2 LV-909s, and 3 intakes should be enough to get you up. Or try 2 turbojets, 3-5 intakes, and a LV-45 engine. Learn to make bigger ones from there.

IRL the drag is probably enough to push them away. But with KSP drag (omnidirectional) that doesn't happen. I usually add a sepratron at the top or bottom of radial stages, on the outside side. Point it upward (and possibly 5-10deg inward, if it does not clear the inner stage well enough), so that it will spin the stage away after release.

If you put your station in a very high Munar orbit, it will be much cheaper to make the changes to match it. However, this makes trips to the surface very expensive, so it would prob be better to be in a low Munar orbit. I would suggest go to Mun as normal, brake there just enough to capture in its SOI, coast back to Apo, make your inclination change, and then lower your Apo for a station rendezvous. Make sure that you capture such that your Peri/Apo are aligned with the polar orbit you want. This is probably easier if you start out in a more polar orbit in the first place.

As others have stated above, Jet ISP depends on altitude and thrust depends on speed. ISP includes the intake air so it is actually much, much higher (16x) if you only consider the fuel mass. Taken from part.cfg files: The basic jet has 2000isp at 1atm (0km), 1800isp at 0.3atm (6.02km), and 1000isp in a vacuum. It has 100% thrust at 0m/s, 20% at 850m/s, and 0% at 1000m/s. The tubojet has 800isp at 1atm (0km), 2500isp at 0.3atm (6.02km), and 1200isp in a vacuum. It has 50% thrust at 0m/s, 100% at 1000m/s, 50% at 2000m/s, and 0% at 2400m/s. The ISP values scale linearly (in pressure) between the marks I listed. I'm not certain, but I expect the thrust scales linearly in velocity between the values I listed.

If you don't care about lowering your final orbit altitude on the opposite side of the body, you can get away with as little as delta_V = current_velocity * sin(inclination_change) by burning at double the angle by which you wish to change your orbit, but this will quickly leave you on a suborbital trajectory so this is rarely useful unless you are parked in a high circular-ish orbit and wish to move to a lower orbit at a different inclination. Note that for angles >=90deg this just means burning full retrograde to a full-stop (a 0km*Xkm orbit can change inclination for free at X), which will just have you plummet to the surface.

Since this is happening on the ground, I'm going to agree with many of the others here and suggest that it has to do with your wheels being ever-so-slightly misaligned. If this happens in the air, though (and typically only at high-speed), it sometimes has to do with having a forward center-of-drag. If your CoD is forward of the CoM, it will make your plane unstable flying forward (but stable backward - lucky you!) and it will try to flip around. The solution in this case is to move your wings backward to keep the drag towards the back.

I think he's referring to Angle of Attack, not pitch control. Wings in KSP use fully-symmetric airfoils. Thus, they generate no lift at 0deg. As AoA increases, they create more lift. If you had a higher lift/weight ratio, your planes would fly at a lower AoA. Alternatively, you can use shift-wasdqe to pitch your surfaces upward slightly (5-10deg) on your ship, thus inducing a nonzero AoA and producing lift even when your navball reads 0deg (but upside-down flight will require an even higher AoA). CoL/CoM position only affect what your plane does with no control inputs. Control surfaces dramatically move your CoL, so as long as they aren't too far apart you can compensate for any discrepancy. What I find to be much more important is Center of Drag. If your CoD is in front of your CoM, your plane will attempt to flip around and fly backwards. The further back your CoD, the easier it will be to recover from spins and tumbles. This is especially an issue for spaceplanes, which experience massive drag forces on re-entry. You want as many of your lifting surfaces as possible to be behind the CoM, with just enough in front to keep your CoL close to the CoM.

You get an 8500t rocket in 450 parts? That many usually only yields me around 2000t (and only around a 300t payload). I'd be curious to see how you keep that together. If I'm doing a simple mission (round trip to a planet) my ships usually come in around 60-150 part range, don't remember the mass. But I also have a thing for launching tankers (even though to this day I have never refueled out of one of them, I like single-launch missions) and other heavy payloads. These commonly weigh in the 200-400t range, so the total launch masses are typically 1500-3000t and 300-700 parts. They also usually require around 30 design iterations to make stable enough to reliably get to orbit.

I assume you're talking about hiding/showing the navball in map mode, where you must press <numpad .>? See if you can re-bind it in the settings.