ferram4

That's called the plane being stable but not having much damping. There are two solutions: 1) add more wing surface far from the CoM, but keep the CoL about the same. This will result in more damping. 2) move the CoL ahead of the CoM. This will result in the plane being unstable, preventing it from wanting to head back to its original orientation, fixing the seesawing. This is unlikely to be the solution you wnat though. But seriously, this is actually the way planes behave if you slam the controls all over the place (like, say, if you're using a keyboard without pulse width modulating your inputs).

Alshain, tell me, what are the two lines just above that one in the KIDS post, hmmm? The main purpose was always rescaling Isps. Thrust correction was just a nice thing I could throw in while I was at it.

SymbolicFrank, I really don't know what your complaint is. The most recent question/request/report from you in the FAR thread of substance is this one, where you expressed a desire for configuration settings that were already in the dev build at that time. In fact, the default FAR settings are already excessively lenient about supersonic drag and area ruling, so the one complaint I can find that you actually sent to me has not only been addressed with a solution, but also had that solution set as the default for all users. I don't understand how this: Is accurate at all when what you wanted is already the default in FAR. Seriously, what do you want?

@darqen27: And all of that is great and wonderful, but without the log, if it is something on my end, I can't fix it. You might be able to read logs, but I can't read your computer screen from here (though it would save so much time fixing bugs if I could). So with that in mind, would you kindly post the entire, complete log and full reproduction steps? @Phylan: Update to 1.0.2. Apparently some things changed in between that RealChuteLite relies on.

Wing section thickness has no bearing on stability at lower speeds. All it does is reduce the stall angle and make stalling (when it happens) more severe. In the end, the lift slope is the same and doesn't care about the thickness of the wing. Also, the X-1 has 0 sweep. The wings are completely straight, with only some minor tapering as they get closer to the tips. The wing section is a NACA 0008 at the root, IIRC, compared to the NACA 2412 on the Cessna, so it's about 2/3 the thickness, and both are thin enough for thin airfoil theory to be perfectly valid.

@Pirke: What do I say two posts above yours?

@FourGreenFields: Known issue, mostly fixed in my dev builds. Hopefully there'll be a bugfix update soon to address that and a few other issues. @amankd: Easy enough if I can handle wings on an aggregate basis it's simple enough using the standard "treat the ground as a mirror for the wing vortices to create a streamline along the ground." The trick is handling wings on an aggregate basis, which I still haven't figured out how to do.

@Mipe: Yellow arrows are moment arrows, which signify the direction a torque rotates around. Odds are the cause is just the vehicle flexing, like always happens. Unless it's on the runway, in which case, that's because landing gear. Edit: with picture, the problem is that you have no yaw authority because your plane has no length to put the vertical tail behind the CoM. @taniel0401: Need reproduction steps, they work perfectly fine for me so long as you configure the control surfaces.

Then here are the tests I want you to do: Find data on a real life plane. Build a replica of said plane. Test plane in flight, compare Cd values from FAR to stated data. When I have data to work with, then I can fix any actual discrepancies. I can't code feelings. Last I heard from NathanKell, subsonic drag was too high because he couldn't get a Bonanza up to its rated top speed. This is also consistent with my findings given that I've tended to allow slightly higher subsonic drag on planes in order to achieve proper subsonic performance on command pods.

Yes, it must reduce energy. However, removing body lift turns it from requiring a "how much energy was removed" calculation involving Ap and Pe to a simple, "did Ap lower? Then it's fine."

@Azimech: If the body is closed, FAR will treat it as a closed shape. If not, it'll treat it as hollow. No, building airfoils doesn't work, and the wing code is still legacy code. @Wanderfound: I'm not nerfing the engine parameters because thrust does not need nerfs. Instead, engines need code for catastrophic failures from heat and overspeed, which Squad never bothered to implement. @UnanimousCoward: For one, I recall RoverDude saying something about pulling FAR support for all his stuff once 1.0 hit because it wasn't necessary anymore. For two, if the CoL isn't a dot and is instead a vector, it means that FAR is not functioning properly, as FAR removes the vector from the CoL because it is confusing; in any case, something is very wrong there. @Ravien: I can look into that, but those values should be saved whenever changing from the Space Center scene to another seen. If you made a change and then ALT-F4'd, then they won't take. @Iasus: Not a bug. You have a giant rocket and tiny fins, of course the rocket is going to have a greater effect on the CoL than the fins. @JohnFX: Sounds like stupid_chris needs to send an event when he updates chute sizes. Maybe he already is, but is doing it at the wrong time? @prog: Yep, work perfectly fine. @cttw: Need reproduction steps that include a perfectly non-lifting vehicle engaging in an aerobrake. If not, I'm assuming that's just body lift raising your apoapsis. @Mipe: Yes, blunt objects have poor transonic characteristics. This is expected, and the little pod + flea is a blunt as hell rocket.

That means that you're probably missing a dependency. If you installed using CKAN, don't; do it manually, CKAN hasn't caught up to handling FAR yet.

Stock parachute code is replaced with RealChuteLite code, as noted in the changelog and the announcement post a few pages back. To the best of my knowledge, stupid_chris set up the parachutes to provide the same drag when deployed as the stock chutes did, so the difference is not due to the chutes being weaker, but due to the rocket itself having less subsonic drag. I don't think you should expect to recover the booster when the only thing you're using to land all of that is a single parachute.

We have no data for win64 on 1.0.2 because it does not exist, except in hacked versions that have god knows what issues. We do have lots of data for win64 on other versions of KSP, and it is always the same: lots of memory crashes for no apparent reason. I know, because I was hopeful for win64 on 0.24, which was a disaster. It's only gotten worse, and I don't see how it would work any better now.

Ouch. That sounds like the computer tried to allocate a lot of memory for voxelization all at once and then broke things horribly. I can look into putting a cap on that and instead make the voxelization wait, unless the issue is actually the number of threads set to work to handle that.

As noted right above your post, it is a confirmed issue, and I'm working on it. I know, repeating it unfortunately doesn't fix it faster.

And at this point, I've got this super-smart guy filling my thread up with a bunch of noise about how his win64 is utterly and completely perfect and never crashes ever. Sure. The data completely and totally lies, and you're not glossing over crashes or running well below 4 GB to avoid crashes. Yeah, I believe you, really. Now stop filling up my thread with this. If you're really so super-smart that you can make the win64 build magically stable when it isn't, you surely have the brains to recompile a mod.

@chunes: Yeah, I see it. I think the hypersonic moment might not be high enough to counter the drag of the heat shield. Should be an easy enough fix. @Dermeister: But have they been updated since FAR updated? No? Then they're probably not informing FAR of the shape change.

And it's back to working, which was fortunately easy. So v1.2 is out.

Probably because, for whatever reason, it is not actually symmetrical. Are there procedural parts on that, and have the mods been updated to inform FAR when they change shape? If not, then there's your problem.

Nope, no need for it anymore. CoL should be exactly where it's supposed to be.

I'm not in charge of CKAN and frankly don't care whether it works or not with FAR, but in my experience, it's just made things more difficult. The less people rely on it, the fewer issues they seem to have.

@eodh: Unless VSR is constantly animating something, there is no reason that should occur. That is very, very strange. @PrometheanVR & yithpistol: If both of you were relying on CKAN, you made a bad decision. It isn't aware of the new ModularFlightIntegrator dependency, and so everything breaks. Install manually and everything will be fine.

@eodh: That's FAR re-voxelizing the vessel. It needs to send the fairings back to their original positions to voxelize properly (else they're floating off in space and the fairing basically doesn't exist). It only happens when an editor update event fires, so unless you've got something that's spamming editor updates it should only happen when you change the shape of the vessel. Yes, I'm aware of the little hitches that can occur and I'm looking at ways to reduce it even in the worst cases. For the most part though, this only happens when the vessel needs to update, so it's not an utterly critical issue.

Yes, because wing parts have to account for the fact that the sharp trailing edge at the back of the wing forces the flow to separate right there, which is what actually creates the flowfield that produces large amounts of lift on a subsonic wing. Supersonic wings are a little easier, but if the trailing edge is swept back enough the same trailing-edge effects need to be accounted for. For now, wing parts are different from ordinary rectangular parts unless they are flat against something or used as a structural piece to enclose, say, a fairing. In that case, the legacy wing code is shut off.