ferram4

@Wanderfound: I assume you mean that the settings for control surfaces won't load, rather than that the crafts won't load. There's no way around that. FAR and the stock aerodynamics use completely different part modules, and there's no easy way to bring the settings from one module over to the other, particularly from FAR -> stock, because in stock, the FAR module doesn't even exist, so there's no way to load the data short of a manual parsing of the craft file to try and find the data, which will be a nightmare to try and code up. @madlemur: Well, considering the thin wings that FAR assumes, the control problems aren't that bad. It's just that the ability to produce lift falls off a cliff. @Jaevko: Those rocket tanks sticking off sideways? They're always going to get ripped off in any amount of high dynamic pressure. You're either going to have to set them up on IR hinges so that they can only deploy once dynamic pressure is lower or you'll have to come up with a sturdier way of putting the legs further out. Landers for Eve will basically need to look like the kind of rockets that you'd launch from Kerbin, sort of the same with Laythe (though its smaller size means you can have lower dV requirements), but for Duna a plain old Mun lander with a little extra dV is enough. The trick in designing atmospheric landers is to look at them and think about where it will break if you apply a force across the entire thing.

@Dre4dW0rm: Yes, that is intentional. They are about as powerful as real jets (without the reduction in thrust with altitude), have the mass of real jets, and are still far more fuel efficient than their real life counterparts. Fuel consumption per unit thrust has not changed with NEAR, so I don't know what you're talking about with respect to fuel consumption being wrong. If you can't get a plane off the ground, then I'm going to take a wild guess and say that your planes are way too heavy; even so, you should have no difficulty reaching a (relatively high) take off velocity of 100 m/s by about 3/4 of the way down the runway with normal-sized vehicles.

@BadManiac & forsaken1111: Yeah, and that behavior is pretty much what you see any time a real life rocket goes out of control and reaches a high angle of attack. In particular, that rocket you posted (with the gigantic fairing) will become highly unstable if you reach an angle of attack high enough to make the size of the fairing matter. Also, what's your TWR? Very high TWRs encourage rockets to lose control and become unstable. I'm curious though, considering that ascent profiles are heavily affected by aerodynamic forces, did you not think that changing aerodynamics would require changes to your flight profile? @NWDogg & Arron Rift: Ignore terminal velocity. You will not reach it and will have control difficulties if you get close to it. You're making the same mistakes that BadManiac and forsaken1111 seem to be making, but at a later stage.

This looks pretty good! The only suggestion I have so far is to flip the radial engine body around so that the intake is on the other side. As it currently stands, radially attaching a radial engine body embeds the intake in the part you attach it to. Also, the delta wing model seems shifted back a bit more than the stock one; it's shifted by about the length of the tip chord, which isn't much, but it does mess up existing planes.

@Kaa253: That's not FAR if you can prevent the failure from happening by reducing the thrust of the sepratrons. FAR's aerodynamic failures only care about aerodynamic forces to the exclusion of any others. @Akira_R: DRE has always attempted to get realistic heating; it has always supported FAR better than the stock model.

@Nori: It depends on the rocket. However, if your rocket is oscillating in certain situations, that either means too much control authority in general, not enough stiffness in the design, or SAS just being tremendously wrong for some reason. @RadarManFromTheMoon: They should be identical, but the only place where it could return different values is in the overloads for FlightGlobals.getStaticPressure and FlightGlobals.getExternalTemperature, since the only difference between those functions is in the overloads they call... So this seems like either FlightGlobals.getAltitudeAtPos is returning the wrong number, or one of those other FlightGlobals functions is returning the wrong number. In any case, this doesn't look like something I can fix, but thanks for the heads up; I'll look into replacing one of them to make it more consistent.

@DaMichel: Besides increasing the lift and decreasing the drag of any wing part that is in the middle of a wing from its baseline performance (essentially, increasing the effective aspect ratio of that part), FAR also includes the effects of changes in lift and drag caused by changes in the camber of the wing, whether that is caused by the shape created by wing parts or by control surfaces deflecting. Further, the stall angle of wing parts is affected by multipart-wings as well. There's also the effect of biplane wings robbing each other of some lift due to interference effects. NEAR models none of that. The canard effects you're talking about would be the result of downwash behind the canard, and lack of downwash is one of the last remaining great errors in FAR; I just haven't come up with a good way to handle it yet, though the math for it is relatively simple. @Voculus: Good to hear, it's always nice to know that FAR brings things closer to flight-sim quality.

I really hope the "strategies" don't end up having the temporary power-up properties that are being talked about here. Dropping a lump sum to permanently increase the performance of something? That can be played off as research, design, etc, and makes sense in the context. A temporary buff for no explainable reason, linked to an arbitrary next number of launches? I'm sorry, I thought this was a decently hard-science space game, why is the administration building filled with wizards?

All I can think of is that you're not setting up the FARControllableSurface module correctly for the part (though I'm not sure how you'd manage that) or the transform isn't lined up correctly somehow, but I'm not sure how that would cause this issue but not any others in deflection.

I meant total number of players, since surely you would need to know something like that in order to come up with percentages, right? Surely if you're going to argue against something by using the smallness of the number of people that support it that your numbers have some actual data behind them, and not simply make up numbers that support maintaining the stock status quo above all else. So then surely you can provide a direct link to some examples, right? I've seen FAR users talk about how it makes the game more fun, I've seen them talk about how they enjoy the challenge, I've seen them talk about how they'll never go back to the stock atmosphere. I've never seen them say that anyone not using it isn't playing right.

Wait, you actually have access to that amount of data? I'd actually like to see that, because then that helps me with development and prioritizing features / fixing compatibility / handling bugs. You should enjoy it the way you want. You should now dislike me for telling you how to enjoy the game. That's... kind of a terrible reason to be honest; if you're going with that reasoning, you're letting people you detest control how you play. And I also don't see any rudeness in here; lots of passion, but very little rudeness or snobbery; could you point to some examples?

Yeah, it's hard-coded to look for obj_ctrlSrf, because AFAICT, the game is hard-coded to look for obj_ctrlSrf for the stock control surface code. Since all the parts that have control surface code have also included an obj_ctrlSrf transform to work with the stock module, this has never been an issue.

You don't need to set that if you're using the same setup as stock; that's only there if you want to change it to something else for some reason. Don't know why I added it, but people like options, so if I remove it now someone will complain.

It's in the source repo. Linked from the OP. That's why I mentioned the github source.

Known issue, fixed in the dev build in the github repo source.

And pretty much no one expects that the stock game would ever have planets large enough for those velocities. You don't even need the magic torque with stock "aerodynamics." There really isn't anything to cause an instability in rockets with stock aerodynamics. And no one wants their mun landing to end with a crash because they didn't bring enough fuel, and that's why we have infinite fuel enabled by default. Oh, and proper aerodynamics makes command pods stable and ensures that they'll show the correct side towards the airflow during reentry; you'd have to try really hard to get it stuck facing the other way. The high-drag souposphere was the cause of nearly every single one of my failures when starting out. It ate all of my dV, it prevented me from being able to use designs inspired by real-life craft to make orbit, and generally just made launches unfun. Frankly, the stock atmosphere brought me pretty close to quitting because it made the game frustrating in the most boring way possible. It didn't make things easier for me; it made them more confusing, and made the game less fun to boot. How would he make an unstable rocket though? Either his design looks pretty much like a real life rocket (as I expect most newbie rockets would), and it'll be stable, or it's a LOLPARTSEVERYWHERE rocket, and there shouldn't be any expectation of it getting into space. Building a stable rocket is really not that hard. Given the parts you have to start with, it's nearly impossible to build an unstable rocket unless you immediately start with a booster pancake. I've never seen an ascent with FAR take more than 3 minutes. Most of them take less time than with the souposphere (as tends to happen when you're not losing tons of dV the whole way), and FAR ascents tend to be much more forgiving wrt starting your turn too early / late, assuming that you don't try something stupid like going sideways at Mach 1. Are you going to argue now that someone shouldn't be expected to consider that rockets should generally face the direction they're flying in the atmosphere? You're also overstating the amount of control needed for launches. I've flown rockets where I'm holding 10 degrees AoA the whole way and it's fine; having your angle of attack deviate from prograde by up to 10 degrees and you can still recover is a lot of margin to work with, and "slight errors" aren't going to throw you out of that unless you're not paying attention.

@WavefunctionP: Making the tweakables clearer is on the to-do list, but that will come in FAR before NEAR, probably. @noobz: Planes that are stable in FAR, but not in NEAR are running into the changes NEAR makes that greatly simplifies the aerodynamics for players at the cost of making them very wrong. In particular, anything that takes heavy advantage of wing interactions will not work well with NEAR, simply because NEAR pretends that wing interactions don't exist. @JewelShisen: No, you don't need FAR; why would I make you go to two separate threads to install NEAR? In fact, having both at the same time is a damn good way to have lots of problems. @SirJodelstein: That looks a lot like the CoM isn't low enough / the "heat shield" part you're using isn't flat enough for that purpose. Making a stable reentry vehicle is the same as making anything aerodynamically stable: aerodynamic center (or Center of Lift if you insist on that) behind the CoM. That's it. So make the thing relatively cone-shaped, with as much mass near the blunt end as possible. It should be wider than it is tall, ideally.

BWAHAHAHAHAHA. Sure, this massive thing could never be launched with a realistic aerodynamic model. Hell, I didn't even bother trying to smooth out the tops of the boosters and everything was fine and dandy. Biggest problem wasn't aerodynamics-related either, because all the booster separation issues I had were at the edge of the atmosphere, where aerodynamics really doesn't matter as much as the dry mass of those stacks. Seriously, this kind of argument just betrays a gross misunderstanding of how aerodynamics affect the game. Yes, you can't just ignore aerodynamics, but it doesn't lock you into a single playstyle at all. You can still do plenty of utterly insane things, it just ends up being a little harder to deal with than doing anything with the sleeker, more aerodynamic vehicles. Edit: Addendum: This is from my performance experiments with the NASA parts. It is kind of a cow, but it flies just fine. Good aerodynamic models do not preclude insane designs. They just require more thought to be put into them.

If there isn't something in-between the pilot and the plane to say, "Nope, you don't do that, cowboy," then yeah, that's what will happen. Modern fighters aren't piloted so much as given suggestions on what to do.

That behavior is what happens when you go from no pitch input to full elevator deflection in 0 time. There's pretty much no way around it besides smoother controls (using the pulse-width-modulation method you're using now; I'm particularly fond of it myself), using a joystick, having an autopilot of some kind do it for you, or by redesigning the plane so it is much more sluggish than it would otherwise be. It's not a problem, it's the way all planes fly. It just needs smoother control inputs.

They borked them trying to fix a decoupler issue that was in win64 went out originally went out the door as 0.24.0. Then they tried to fix it because people complained about radial decouplers doing nothing, but it caused its own issues. Get an old version of win64 0.24.0. Watch as decouplers apply no force. Switch to win32 0.24.0. Watch as decouplers apply force normally. Switch to any 0.24.2, watch as radial decouplers cause lots of twisting at speeds below 750 m/s. My only source is paying attention to how behaviors changed between KSP versions.

@TimberWolfe: Try waiting until you're going faster than 750 m/s to decouple. The decoupler changes to try and get them to work in win64 made them not play well with velocities below the Krakensbane limit.

@steve_v: Can't confirm that one, and I can't reproduce it in my slightly more up-to-date build that I haven't pushed yet due to some dependency changes. No issues that I can see, it always updates just fine. @BlitzkriegNein: Well, of course you can't fly most rocket designs in career mode. You can't fly most rocket designs at all, since there are an infinite number of designs that are unstable, have off-center thrust, cause the rocket to spin up like crazy, and cause all sorts of other problems that make flying with them impossible. You don't complain about those ones though. For reference, I've never had any trouble launching rockets in career mode, even in the very beginning. I personally start by collecting all the science around the launch pad though, since I think the stick-a-pod-on-a-booster-with-no-decoupler stage is just plain stupid. After that though it's quite difficult to build a rocket that will be flip happy in my experience, I'm really not sure what people do to create those.

Nope, no one calling MJ cheating in here. And no one calling something that does less than MJ cheating would imply that MJ is cheating. It's totally not like anyone has said that in their opinion MJ is cheating at all in this thread. Yeah, it's been called cheating in this thread. Always happens, no way around it, because that's the way these threads go.

This is not a NEAR issue. This is an issue with parts that do not have configs to work with NEAR, and thus you are running into the stock infiniglide issue. Check with the mod control surfaces that you are using to make sure that they are not only compatible with FAR, but that they also implement their compatibility if NEAR is present.