ferram4

Likewise, it's kind of annoying. And for some reason, it puts FAR as Ferram Aeronautics Research when it's Ferram Aerospace Research, which kind of points towards a minor issue with this: it can be wrong. Also, should anyone want to talk about Federal Aviation Regulations (for example, FAR Part 25, specifying regulations for designing aircraft for safe landings, kind of relevant maybe if people want to get all realistic aviation) will get the wrong acronym. It needs some means to determine context.

For some context on my problems with CKAN, I was ambivalent about my mods being listed initially (basically, I expected things to not go well, but I saw no reason to complain so long as CKAN did not cause problems). I was told by one of the CKAN contributors that if I did have a problem, I could ask, and they would de-list the mods. FAR v0.15 comes out, and due to CKAN's metadata being incorrect for that version (CKAN has no archive/metadata error checking of any form for mod updates) CKAN pushes out a completely broken install at the same time that I am attempting to bugfix a complete overhaul of the aero model. Bug reports that I need to read to fix things get buried by CKAN-only install issues that are being reported by people that I knew never had install issues before. So in one swoop, CKAN caused more install issues for me than I ever got before on the one thing where they were supposed to make things easier for modders (at least when they were pretending they cared about modders). A little over a month later, after fixing those FAR issues I'm mulling over asking FAR to be de-listed over the entire mess, though not sure either way. I look at the CKAN policies, and lo and behold, they've declared that non-All Rights Reserved mods shall not be de-listed. A month after CKAN causes hundreds of install errors on one of the most-used mods authored by one of the more outspoken critics of CKAN. I demanded it be de-listed simply on principle at this point. So yeah, I have a few problems with CKAN. Unlike RD, who handles his metadata for his own sanity, I'm ticked enough at them that I refuse to do that. I don't think it's right that CKAN can cause issues for you and then get you to handle the metadata for them under threat of more metadata errors and issues if you don't.

@Recon777: I'm not seeing where you have an issue with FAR here. FAR is an aero mod, not a crash tolerance and part survivability mod. Changing the Flea's crash tolerance is out of scope. The Flea being destroyed on landing does no damage to anything whatsoever; hell, it shouldn't even explode because it lacks explosives inside it, it should just crumple. However, those effects are also out of scope for FAR. Yes, it will not go as high. Stock does not model supersonic effects properly and short, relatively fat rockets have terrible supersonic drag. Drop the thrust so you hit that later and you'll go higher. That isn't the first craft that you have to launch. Although it's very likely someone will rush to actually fly a rocket, nothing stops you from just launching the pod and grabbing enough science on the pad to get to the next node. Editing the stock tree to make the first vehicle saner is similarly out of scope. FAR already risks trying to handle too many things. I will not attempt to fix stock's silly career mode as well, nor do I want to expand into making an aero mod about how things are affected when they crash. I'm also not going to make the aerodynamics less realistic to save something stupid like that. @Neutrino.: Perhaps only having 4 degrees of pitch control on the elevators is the problem. It's got no problem handling 100 knots in the air with about 15 degrees AoA if you increase the pitch authority up to something higher. The stupidly excessive dihedral and anhedral on the tail and wingtips probably hurts its stall behavior a bit, but otherwise this looks about correct for a plane 6.3 tonne plane with 39 m^2 of wing area that has this degree of pitch stability. The spinning out is likely something to do with the landing gear changes in KSP 1.1+. Nothing I can do, I don't change anything about those. The pitch down, no idea; it sounds like you either stalled something or simply lack sufficient pitch control to keep it on target at low speeds.

@Tidus Klein: There's a very simple answer for that: that's too simplistic to represent how ground effect works. If I did things that way, either teeny tiny planes with small wings would have way too much ground effect at too high an altitude or massive planes would have no ground effect too low to the ground. It needs to scale with the size of the wings, and that requires the wing overhaul first. @Griffon345: And if you had read my post above, you would know that the issue is entirely due to the VSR new engine models and you need to uninstall VSR or revert to an older version of it. Please don't post if you're not adding any new information, it just buries useful information faster.

@Buisson & @TeiwazVIE: I have tracked the problem to certain VSR engine models. There is nothing that can be fixed on my end; revert to earlier versions of VSR to get things working again.

@Ven: It looks like your new models for the Mainsail, Skipper, Rhino, and I believe the Poodle and Terrier as well all cause voxelization errors with FAR. All of the resulting behavior points to vertexes or triangles of either mesh or collider floating WAY out beyond the rest of the model, screwing up all attempts to figure out the bounds of the vehicle. This will also cause issues with stock drag and heating as well, if that concerns you. I can't fix any of this on my end, I'm afraid. FAR doesn't have any easy way to determine which parts of the mesh / colliders to ignore, so could you take a look at those and see if you can find any issues? Edit: I copied this issue to the repo for easy tracking. Hope that doesn't cause any issues.

Actually, I pushed them on this when the policy came out, and the basic gist is that it's a "courtesy" that is extended because full ARR makes it trivial for an author to add a clause forbidding installation through CKAN and then they're on Napster-style facilitation of copyright infringement ground. So ARR actually has power of CKAN, which is something that should probably be acknowledged somewhere. I don't expect things to change on the policy though. That policy was officially adopted about a month after they completely and totally screwed FAR installs via CKAN and gave me an actual reason to consider de-listing and dropping CKAN support. If they change their policy, FAR gets de-listed. If FAR gets de-listed, Realism Overhaul can't be installed via CKAN. And installing Realism Overhaul is basically the reason that CKAN exists in the first place; if that can't be installed by CKAN because a mod has been de-listed due to CKAN continually screwing up, that's a massive hit to their PR and general argument for existing in the first place. They can't allow that to happen.

Your bug reports need to be done with the minimal mod installs possible, with every single step you took, from getting into the game to causing the bug itemized and a full copy of the log before I can do anything about it. I can't do anything I have reliable, perfect reproduction steps. And also, NO CKAN.

@dpitch40: Well, I can can confirm that it does oscillate to destruction under thrust. I cannot confirm that it oscillates to destruction after loading in; I loaded in twice and it was perfectly stable so something else is happening to start it there. I'll look into it, but if you were deliberately trying to create the most unstable collection of rigidbodies-on-spring-dampers possible you couldn't have done better job of breaking things here. Seriously, large heavy masses connected through lots of ultra-light parts through a central part is a recipe for a disaster, even in the stock game.

It looks like GetPotentialTorque is supposed to only report positive numbers. And yes, if the old CLS was breaking FAR that updating that would probably cause FAR to be less broken too.

In order for me to fix any oscillation bugs, I need a stock parts only craft file that will cause the issue the second I load it in. Otherwise I can't reproduce the issue to try and fix it.

Well, I don't know if that's an issue with FAR or kOS. None of the documentation on GetPotentialTorque states that it needs to provide positive values, and I can see lots of control issues if negative values are not accepted. I'll try and find out if GetPotentialTorque must return only positive values, but if it isn't supposed to, then there's nothing I can do.

@ss8913: Nope, nothing. 0.0 m/s EAS on the runway after taking off, flying to 5 km, and returning to the runway. Even more confusing is that there is no mechanism in the code for there to be any constant error at all. The air/water density is multiplied by vessel.srfSpeed, so that would imply that vessel.srfSpeed is wrong, or the air/water density is way, way, WAY wrong. Post a stock craft that causes the issue.

@ss8913: Never seen it; I need full reproduction steps then. @Gordon Dry: No, it is not due to swaying. No revoxelization occurs on swaying. It is that the parts continue animating, and the animations require a revoxelization because they could indicate large changes in the craft shape. Alternatively, another mod is continuously forcing FAR to revoxelize. In either case, FAR is doing exactly what it should do in this scenario. As for why it happens even in space, 1) needed for reentry when that starts and 2) also handles radiative heating / cooling. @starikki: Not happening at any time in the foreseeable future. For one thing, 4 numbers will not properly model what you want and will likely introduce lots of confusion. For another thing, the right-click menu is already bloated for FAR control surfaces. For another, there is no easy way to create the full curve variation that I'd rather use. Until those can be solved, nothing is being implemented in FAR.

@Gordon Dry: Everything in there appears to be correct. It looks like you have a lot of constant animations occurring on your vessels, which triggers a revoxelization. No issue here. @Bookstore44: 1) Fins in the front of a rocket with mass behind is unstable in FAR, as it should be. Note that wings do not have the same aerodynamic behavior as not-identical shapes. Note that the main source of low stability on your second craft (with the structural panels at the back) is due to the body lift created by the nose of the craft. On the version with the structural panels at the front the increase in cross-sectional area near the front of the vehicle produces a stabilizing pitching moment, like on command pods. In both cases the overall vehicle is only barely stable / unstable, which is why you can see a noticeable change with such a small cross-section adjustment with the structural panels. 2) FAR Flight Data has it in flight, Stability Deriv tab has it in the editor.

@habix: I have investigated and determined that this isn't a FAR bug. This is an interaction between CLS and RemoteTech breaking all PartModule.Start() functions that are set to happen after RemoteTech's. While this breaking FAR's aerodynamics might be the most noticeable effect, there should be other broken behaviors as well. Unfortunately, nothing I can do here.

@Gordon Dry: If you're not going to provide me reproduction steps, logs, and a mod list you can't expect to get any support. Bugs don't get fixed with absolutely no information.

@habix: FULL log, not snippet. I need to have EVERYTHING. Does it work without Remotetech, but still with BDB? Does it happen with any other part in any way? @AccidentalDisassembly: Confirmed, I know what's causing it. Stupid fix that I had to add to fix a bug introduced in part transform layers for KSP 1.1.2.

@habix: Provide full reproduction steps, the full log, and the problem craft please. @Gordon Dry: Full repro steps all the mods you're using, and the craft file. Also, if you did exactly the same thing as you did yesterday, then the behavior is exactly the same; if it's different, then you did something different. To fix bugs, I need to know what it is you did differently. Also, no, textures have nothing to do with what FAR voxelizes. Just provide the info I ask for.

@Gordon Dry: "Already implemented" as in "was implemented several versions ago." @Bookstore44 & @kcs123: Both of those look like cases where you attached the parts and then rushed to simulate before the voxelization was complete, so the wing parts hadn't had their setup code run yet. In any case, bugs like that will not be fixed until the wing overhaul happens, because spending time fixing code that will be completely replaced is silly.

@Klish: The Stability Derivative window starts by finding an AoA that allows the vehicle to achieve steady, level flight at the input conditions. If that is impossible, it will return impossible numbers. Very few single parts are capable of steady, level flight at Mach 0.35 at SL. The window thing does sound like a bug though, but that should be a quick fix. @Bookstore44: 1) that sounds about right. Similar mechanism to how body lift works on command pods, in this case it's just the body lift having a greater moment lever than the drag so it has a greater effect. 2) That would be news to me; I can't substitute structural panels for wings in any situation and achieve flight. You may also want to check the reference area for the vehicle, considering that will change and comparing coefficients from vehicles with different reference areas is invalid. 3) Real, implementation waits for wing overhaul. 4) Also waits for wing overhaul, if I can even find a way to implement it. 5) Dunno what's causing that, I can't reproduce the issue. 6) *shrug* not sure if that's valid, high angle of attack is very strange. 7) It's called, "making the wings stall unevenly" which will happen with high yaw (or less yaw and swept wings), aileron inputs at stall, or generally anything that causes more than pure pitch motion. It's not difficult to do at all. @Gordon Dry: 1) Already implemented for editor GUI, cannot be implemented for Flight GUI. 2) Already implemented.

Some of it is that, yes. A lot more is people deliberately building over-stable designs, as I said. Not if they have less damping, whether that's a result of simply having small tail / canard surfaces or simply a higher angular moment of inertia. Because many real life planes are designed with fast-damping short-period modes. many have stability augmentation systems to damp out those motions automatically. virtually all have a self-correcting system called a "pilot" who has analog control over the system Most KSP designs lack 1, 2 is often either off or not tuned properly, and virtually none of the tests in KSP are done with 3. And in the end, nearly all of these come down to players not designing their craft to be identical to real life designs. The only ones that are arguably not due to that are 2 and 3.

That is correct. Note that it assumes the ability to increase the angle of attack to the point where the plane stalls. Yet your complaints seem to be about planes that will never drop down to stall speed because they lack the pitch authority to bring their angle of attack to the point where the plane actually stalls. The wings remain completely unstalled even as the plane slows down and can't remain in the air. The balance is almost always less stability than what KSP planes have. Players simply over-stabilize their planes once they learn to build stable planes and also tend to build too small elevators. Most flight being limited to -1, 0, 1 pitch inputs because of keyboard flight just encourages that. So move the CoM further back, the CoL further forward, and larger control surfaces. But if it flies fine and it is stall-proof, why would you break it? Initially, that sounds like a simple short-period oscillation. Simply stated: the plane has angular momentum. That takes time to damp out. Until that happens, the plane will oscillate in pitch, but that should disappear over a second or two. Sustained oscillations, especially ones that jerk down quickly point to the plane stalling in the turn. Maintaining control in this simply indicates that the plane's wings have stalled evenly, so there is no roll moment or yaw moment to throw it into a spin. Given that most KSP planes are jets and that FAR does not model propwash for those that aren't, there is no source of roll or uneven flow in a zero-yaw stall. So the plane pitches down and recovers. If the plane is given aileron input or is yawed to the side then it will enter a spin, the severity of which depends heavily on how unevenly the wings stalled.

The stability derivatives are not used for that purpose. Never use the stability derivatives for figuring out any behavior very far from the angle of attack that the sim calculates for steady flight in those conditions. Instead, use the static analysis angle of attack sweep. Forward surfaces stalling first creates a strong pitch-down moment, so that will appear on the graph as a severe drop in the moment coefficient (yellow) line when that happens. The general way to achieve that is to make your tail have greater sweep or a lower aspect ratio than the main wing or forward surface. Alternatively, if you don't care about easily coming out of stall regardless of whether you're pulling positive or negative AoA, you can build some angle of incidence into the main wing so that it is always at a slightly higher angle of attack compared to the tail.

First, talking about stall speed in relation to aerodynamics is (frankly) kinda silly. It's a lie to children that engineers and designers give to pilots so they can use the readout they're more familiar with and more likely to have. Never worry about stall speed, only worry about the angle of attack that you stall at. And funny enough, if you can't reach the angle of attack that you stall at, you will never stall, and so never spin. That is a realistic behavior and FAR won't compromise aerodynamic fidelity to make stalls happen at unrealistically low angles of attack to cover up poor plane design, nor will FAR boost control surface effectiveness well above where it should be. Spins are possible, but most common KSP designs will naturally come out of spins because that's what they would do in real life. If the tail stalls at a higher AoA than the main wing, the plane will easily come out of a stall or spin because it will pitch down very hard when that happens, just like in real life. While PARE is very helpful for marginal planes or for getting out of spins faster, for many designs the plane will enter a spin, naturally spin around once or twice and then exit it. Getting into stalls is harder since most KSP planes are absurdly over-stable compared to their real-life counterparts. Also, if you continue to insist that these things don't happen, I've seen it happen developing planes for BD Armory battles; the AI manages to spin the plane and it easily goes into a steady tailspin until the AI lets the plane settle out (if it ever does). Tailspins they tend to come out of, flat spins they never do. Real life planes do behave this way, so long as they are designed identically to their KSP counterparts.