ferram4

@Benmush: Stop. Seriously, absolutely none of the builds since FAR v0.15.0 have ever applied drag based on AttachNodes. I keep telling you this, but you refuse to believe it. Every single part gets a drag and lift vector. The drag and lift vector is displayed at the part origin. This happens in both stock and with FAR. The location of the drag and lift vector simply indicates the drag and lift applied to that part. It has nothing to do with the attach node. You could use code to remove the attach node, keep the part attached via joints, and those vectors would still appear in the same location because that is the origin of the fairing side objects. They would still have the same magnitude because they're based on the forces across the entire fairing part. Stop wasting everyone's time chasing after windmills. All you're going to do is convince people that there are bugs where there aren't and waste my time further / suppress bug reports on real issues because people think that it's this non-existent bug you keep insisting is there.

@SpannerMonkey(smce): First, like Chris97b said, don't use FOR. Use either BEFORE or AFTER. So that will work so long as your ModuleKerbachute is on a separate part that is "carried" (by being attached with a joint like any other part) to a Kerbal. If it isn't, I suspect it won't do anything. The latter modules I don't know anything about. The inner workings of other mods is not something I normally know about. If I do know about it and I haven't contributed to it, that's usually a bad sign.

That means that you installed FAR incorrectly. Because you didn't install it according to directions. FAR should not be in a "ksp-avc" folder and needs to be installed correctly or there is a good chance that it won't work right. Install it normally rather than doing clever things.

@loleo: I am unable to reproduce the issue. Debris has proper aerodynamics for me. I suspect that you have either installed FAR wrong or have some mod interfering with its voxelization. If it's the latter, you need to isolate that one so I can fix it. @Blasty McBlastblast: Well, that's good news at least. @Combatsmithen: That looks like the stock wheels being derpy to me. Don't use those wheels at all, they're broken beyond usability. Start using landing gear once you get to the retractable ones.

Never mind, I'm apparently incredibly, incredibly stupid. I think I managed to fix it; please grab the dev dll from the github repo and try it. I am unwilling to rush this out now because I expect some other bug to show up. Like happened here. Also, PSA for any modders reading: never use part.prefabMass for anything that even has a risk of running before Part.Start() at any time, because if it does run then, part.prefabMass will be 0. Instead, use part.partInfo.partPrefab.mass, and always assume anything involving interacting with other mods will run before Part.Start() for safety purposes. ARGGH.

You know what? I reproduced it. I have no idea what's going wrong, and at this point I don't care. I'll decide tomorrow if I'll even bother fixing this or if I'll just strip out all support for Tweakscale 'cause I'm tired of fighting this broken thing. The last bunch of releases have all involved fixes to handle this one mod and the bugs resulting from attempted fixes to handle this one mod.

@Umbra TuSlayer: Well, then if it's a ground height issue it certainly isn't FAR. FAR has no control of which height things spawn at in game. And if it's a landing gear issue, it certainly isn't FAR, because FAR has no control over how the stock landing gear behave. At all. And I can't even reproduce the issue. To the best of my knowledge, based on my testing, there is no cause or source of this bug in FAR. Go complain to the people that thought these landing gear were release quality.

@Umbra TuSlayer: 1. I cannot reproduce any bounciness with landing gear that did not exist in the stock game. My craft bounce slightly on load as physics start, but quickly damp out and remain stable. This was tested with both the FAR Firehound and FAR SkyEye example craft. 2. I attempted to reproduce by taking the FAR SkyEye example craft, removing the landing gear and letting it go. It successfully skidded down the runway up to ~70 m/s before exploding as I attempted to rotate it on the engines to take off. I cannot reproduce your issues with FAR alone, and I suspect another mod is the cause. Also, log files should always be included, as well as full reproduction steps and a list of all installed mods and their versions. @FluffySilverUnicorn: There are many errors being thrown from your log that have absolutely nothing to do with either FAR or ModularFlightIntegrator. I am able to access the VAB, SPH, TrackingStation through buttons and by clicking on the buildings, and I am also able to use all of the other buttons. I suspect that your errors lie with another mod, since there are a lot of errors in there from other mods.

@Vegetal: As I said, I couldn't reproduce the bug with the stock plane. Only a very minor error on one of the wings, but not sufficient to cause massive yawing or side lift. So I don't know what's going on there. Crzyrndm maintains the B9 pWings as well and there are releases later on in the thread; use those. @Combatsmithen: The aerodynamics are different, but the principles are the same as stock. Stop trying to make everything perfect for your first plane, just build it as you would as if it's stock using the CoM and CoL. The stability derivatives are better for tuning and improving functional designs than designing something ground up before even a single test. Only problem I can think you'd be having (likely) is that you need to cut mass and add more wing area. That's the most common error, since stock lets you get away with cows with butterfly wings (why I don't know). As for landing gear, I can't help you there. FAR doesn't touch the landing gear behavior. Same rules as for building landing gear with stock aerodynamics. Once you can fly, Wanderfound has some tutorials, one of the Scott Manley videos I linked in the beginning explains the Stability Derivatives alright, and @tetryds is supposed to have a FAR tutorial at some point. >_>

@Crzyrndm: Yo, we've got a problem: the way that these pWings generate their meshes results in FAR not voxelizing symmetry counterparts properly; one of the counterparts ends up with triangles with opposite "handedness," so when FAR attempts to voxelize it thinks that their normal vectors are facing the opposite way, so those triangles end up filling voxels the wrong way. I don't have an easy means to determine if the triangles are flipped or really an efficient way to handle that if I could, can you look into getting the triangles to have a consistent vertex ordering so this doesn't happen?

@Vegetal: It looks like the main issue on that plane is the Procedural Dynamics pWings. Whatever method that they use results in symmetry counterparts having triangles with the wrong "handedness" for FAR to voxelize properly (the vertexes are listed in the opposite order, so FAR thinks they're all facing the other direction). B9 Pwings are a good substitute, I'll have to bring up the issue with Crzyrndm. @Combatsmithen: I have no idea what you're asking about! I need more specific questions about your problems but I can't find any!

@Vegetal: Oh boy, I can see this is gonna be fun. It's a voxelization error of some kind... Edit: From my testing, I can confirm a very minor voxelization issue, but nothing on the scale of what you've shown. The plane you've linked flies straight in yaw with now sideways lift vectors at any point and does not tend to yaw in any direction whatsoever. Would you mind linking the plane in the picture with an actual serious problem? @karamazovnew: Then kindly go back to kOS authors and tell them, "FARControllableSurface has implemented ITorqueProvider and GetPotentialTorque() since FAR v0.15.6.0, and I am now on v0.15.6.5 with no issues there" and so implementation is now in their court since they have everything they need. Also, by turning off the FAR module you lose all of the FAR physics for that wing part. In addition, there is no way to keep stock control and FAR physics, which is why FAR overrides the stock physics.

I don't think that's anything on my end. The physics, to the best of my knowledge, are correct. If kOS refuses to control it, there's nothing I can do.

@Vegetal: Logs are less useful than the craft file and full reproduction steps. Provide those and I'll look at it.

And now, FAR v0.15.6.5 "Knudsen" is out, with a couple bugfixes for issues. Changelog has them, as usual. Today's namesake is Martin Knudsen, who is primarily known for his contributions to low-pressure gas dynamics. For aerodynamic purposes, we're primarily concerned with the Knudsen number, which is useful for determining if the flow we're looking at is a standard continuum flow (read: basically most every airflow that you've ever dealt with where there are so many molecules compared to anything else that they interact with each other so much that individual molecules don't really matter) or a Knudsen flow / free-molecular flow (read: just a bunch of molecules bouncing around not really interacting with each other much because there just aren't enough of them there), which is more accurate for the beginnings of reentry (and if it is ever implemented) orbital decay. Edit: @SpannerMonkey(smce): well, I dunno what to tell you, this is @stupid_chris's realm. FAR's Flight Data doesn't update the numbers based on RealChuteLite behavior (yes, I know, need to fix that at some point), but as for the actual performance... I dunno. Thing is that it works fine for every single other parachute part, including mod ones, so the question is, "what is unique about yours compared to every other parachute in stock and in every other mod?"

@MaxRebo: Looking at it, even with KJR fully stiffening things this design looks like it should be pretty prone to oscillation. It's got a lot more wing parts (and thus, joints) making up the wings than need to be there, the wings are a bit heavier than they actually need to be (which leads to less damping of the wing-only oscillations that occur) and the plane itself is a bit on the heavy side overall (expected, that's a KSP plane thing) so more flex overall. Aside from that, no issues, though I think you lack sufficient yaw stability for high-Mach number flight and this design will almost certainly have yaw and roll issues during reentry unless they are compensated for with large amounts of RCS or reaction wheels. This is one of those planes that I'd probably fly with just the wing leveler active and leave the rest of the control systems off, just manually adjusting trim every now and then to keep it on target. Otherwise... seems to behave as it should and needs tweaking to remove some of that behavior.

@MaxRebo: Uh.. there shouldn't have been any changes to lift or drag at all. The only changes to code are to make it compatible with Tweakscale, which should have had no affect on any of the wing aerodynamic properties. Upload the craft when you get the chance, it'll provide something I know is getting issues.

@MaxRebo: Then give me a craft with stock + B9 pWings. Just keep the mods to a minimum so I can load it up and confirm what's happening quickly.

@MaxRebo: If the dev build didn't help you, I need you to provide me a stock-parts-only craft that still experiences issues for testing to make sure that nothing is broken. I've got time while I wait for confirmation that the non-zero-convective-flux-in-pFairings issue has been fixed. @Mine_Turtle: Because of how that design is set up the vertical tails on the engine bodies will provide negligible effect at 0 angle of attack and will actually contribute to instability if the vehicle pitches below 0 AoA. You need to either get rid of them or move them further back; there are no planes in the world that put their vertical tails in line with the center of mass because that does nothing to help yaw stability.

@Benmush: The fairing is made up of 4 parts, right? And there are 4 drag/lift arrows attached. So that means that each of those arrows accounts for 1/4 the drag o the fairing and has nothing to do whatsoever with attach nodes. Internally that's probably an issue, but if that problem doesn't show up with the latest FAR dev build then that has already been fixed. It's just waiting on confirmation that that doesn't happen anymore so that I can actually make a stable release. @tetryds: No, this is correct. Please don't repeat incorrect information.

@Benmush: There is no code in FAR that applies drag to parts based on attach nodes, especially not for procedural fairings. @SpannerMonkey(smce): Yes, switching the module back to the stock module doesn't work because, as I mentioned, FAR turns off the dragcube model completely, thus breaking that module. That's why there's a RealChuteLite module to begin with; prior to KSP 1.0 FAR just left the default parachute model alone because it worked well enough, but that doesn't work anymore. Looking at your mod, I don't see any reason why it would not work as is. Replacing the ModuleParachute with a RealChuteLite module should work fine and it should have the proper behavior due to the fact that it appears to be completely identical to stock modules. @Svm420: Yeah, I found that. This is what I get for assuming part.prefabMass would always have a valid value, even in PartModule.Start(). Never assuming that again.

@SpannerMonkey(smce): Yeah, it's probably that. In the process of turning off stock's strange dragcube implementation, FAR breaks all parachutes, so it introduces its own RealChuteLite to replace it. You could either attempt to write a config to convert the parachute over (poking @stupid_chris) or apply the forces directly (given the way stock parachutes work, this is probably better). @hyf97ca: Confirmed and will be fixed in the next FAR build.

@cantab: Confirmed, and you've been drafted: test it with this dll and see if the issue still occurs. Everyone else with the issue should also check because the sooner I get confirmation it works the sooner I can rush out an update.

FAR v0.15.6.4 "Kleinhans" is out. Bugfix release, plays nice with Tweakscale, fix some drag issues. Changelog has info, as always; have fun with it.

Even back before NEAR existed you could turn those off. The option was available the very second that the feature was implemented into FAR, because I knew that people wouldn't like it and would want to turn it off. But back to the topic; anyone have any arguments for/against lift scaling with Mach number as I've suggested?