ferram4

@Comrade Jenkins: FAR would be fine for stock KSP, there are only three main reasons that people have serious issues adjusting to it: People are used to stock aerodynamics, and the changeover causes problems since it requires a different attitude towards piloting. Of course, this isn't difficulty in the model itself, it's just the apparent difficulty due to change. Engines are too heavy. This puts the CoM of KSP rockets a lot lower than it should be; I personally would drop the engine masses either to 1/2 or 1/3 of what they are and then increase the dry masses of fuel tanks to compensate. That or increase the dry mass of decouplers or something like that. Either option ends up shifting the CoM further up the rocket, making rockets more stable. SAS doesn't play well with lots of control authority; this is currently hidden with the ineffectiveness of the current control surfaces and the small thrust vectoring ranges that most engines have. The solution to this is obviously to re-tune SAS. Only more advanced players will really be able to handle the more interesting aspects of the model (body lift, space plane stuff, building really heavy complicated landers), but I think that the difficulty that most players have with it is simply due to habits and design principles that work for the stock model but then are detrimental with FAR. They forget that they had to fail a lot before they got good at stock KSP, but think that they're masters at the game and are unwilling to recognize that they're back to being newbies again. I suspect that players who just jumped into KSP + FAR without taking any time dealing with stock aero won't have that bad a time once they get past the initial "I have no idea what I'm doing" phase of playing KSP. So... how do we determine what should count as empty space? This sounds like a really good way to get even worse interactions due to slight errors in the distances between parts. There is a small amount of distance between fuel tanks when they're connected. And besides that, in real life it would depend on the shape of the object and the Mach number. There might not be any air right behind the part. There might be a lot of turbulent air right behind it. In either case, simply resetting drag is just going to be completely wrong anyway, and it wouldn't make much sense to take all the calculations necessary to figure all that out.

So basically, handling all of this without any occlusion then? At that point there's no point in doing light at all and it would be faster to just do vector math on the part's orientation. But I doubt that's what majic79 was talking about since he specifically mentioned occlusion and how that would allow nose cones to positively affect drag. That could only happen (under his system) if parts could occlude each other. So now we're back to strange effects.

This is not how aerodynamics works. Your system (since it's treating airflow like light and handling occlusion) will end up with very strange effects that are only ever realistic at Mach numbers well above ~5 (read: Kerbin reentry speeds only), but for anything lower they'll be completely incorrect (read: actually trying take off or land a plane). For example on this Cessna 172, at moderate to high angles of attack the vertical tail will be completely occluded from the airflow; this will result in no forces on the tail, which means that the plane will immediately go into a flat spin. Similarly, at negative angles of attack the main wing will occlude the horizontal tail, making the vehicle unstable in pitch. Now, Cessna 172's don't tend to go into flat spins after rotating to take off or become unstable if they have a negative angle of attack, so you're going to end up with completely unrealistic aerodynamics that will confuse players a lot. You'll get the same effects with pretty much any plane that doesn't have the vertical tail mounted below the fuselage and that doesn't have its horizontal tail mounted below the main wing. Players will be completely unable to look to real life for aerodynamic solutions, which is really, really bad, since aerodynamics isn't a simple thing to learn to deal with. Except if all the drag is applied to the nose cones then you end up with the majority of drag in front of the CoM, which results in the rocket becoming unstable. In a lot of ways, this is actually less accurate than the current messed up drag model, since it'll be almost impossible to build something stable. TL;DR: This system has very nasty unintended consequences that will make airplane and rocket design much more difficult, more unrealistic, and will be more expensive to run. This is the aerodynamic equivalent of the "Why don't we simulate Lagrange points using small, low gravity SOIs?" with the same errors: it has no basis in reality and is confusing for players. This is a really bad idea.

Get rid of the skinny upper stage. The gigantic drop in cross-sectional area right behind the fairing (and thus, ahead of almost all of the mass) is creating a stupid amount of drag and is making it unstable. And drop your TWR down to 1.4 or so. If you're hitting 200 m/s before you flip at 2 km you're not going to be able to control the thing. Use a smaller core engine (like say, the Vesta) and use small boosters if you need to get the TWR > 1.

@brusura: Barely large enough vertical tail there. I'd expect to get issues with that at high speeds to be honest.

@prullenbak: That's the fault of the planet pack maker. They're supposed to set the flightGlobalsIndex for each planet to a unique number, but they're not, which causes the error. Bring it up with them, not me. @brusura: That sounds like intended behavior. You probably don't have a large enough vertical tail. All of those are signs that the plane doesn't have enough yaw stability, and if all of your intakes are at the front of the plane then they will make the plane less stable.

@Boamere: I think our definitions of "average delta-wing spaceplane with large flaps" are very different. You'll need to post a picture if you want any further suggestions. @Zuni: Yep! And at supersonic speeds as well!

@Damaske: Clipped parts don't cause problems unless you manage to make them break off. If you're managing to get things to randomly break off in the latest version, you're doing something very, very wrong. @OneRaven: Confirmed, and I think I fixed it. KAS creates its joints after KJR goes through its initial physics easing code, which includes multiplying all the joint's breakForces by some ridiculous factor. Then when the physics easing is done it multiplies all the joint breakForces by 1 / ridiculous factor. So that means that KAS joints end up getting their breakForces dropped through the floor because they weren't initially made stronger. I can't delay when KJR acts, so it's going to simply keep track of what joints it did affect and then work from there. It needs some testing, but v2.1 should be up soon with the fix.

@Boamere: Normally you can ignore Xw and Zu if the magnitudes are small enough. I'd guess that your issues stem from the plane being too stable, since that's normally the cause of losing control at supersonic Mach numbers. @thufir: What issues are you having? Try uploading the output_log.txt from KSP_Data to a pastebin or dropbox after you cause the issue in-game.

Actually, that's what I was asking you guys to check when I told you to flip that particular sign; that implies that something else might be off... hmm. I made a few changes in my current dev build and I'll have to get around to checking if it worked (eventually).

Well, then I don't know what's wrong. I can make some quick looks at what's happening in the code, but I'm stumped to be honest; it should work fine.

Derp. I meant the wing configs. Go into the left and right wing configs and change that line.

That angle of attack should be about okay, I think. I don't see why it wouldn't be for a stable spaceplane during reentry.

Actually, I've got an idea. Go into the config and find the node_attach line. There's a number that's for X orientation (should be the 4th number, or the 3rd from last), and it should be either 1 or -1; try flipping it and see if the issue persists. If it's fixed, reset the number, I think I found the bug and it's just a sign error / inconsistency in FAR.

Well, that's simple. If you're flying straight into the airstream the cockpit has to deflect all of the air in front of the vehicle, creating a very high-pressure shockwave. That adds a lot of drag. On the other hand, at very high Mach numbers the fuel tank at the back is only dealing with skin friction drag. When it flips around and flies backwards the situation should reverse (mostly) with the cockpit making very little drag (which it will in 0.13, I finally got a handle on that issue) and the engine making most of the pressure drag. Probably the reason it's flipping are the canards at the front and all the fuel at the back. You'll want to get rid of the canards and get pitch control using elevons instead.

Probably what's happening is either the cargo bay model is being detected as being far too large (which I've never been able to fix; animating shapes always give FAR weird issues) or the cargo bay code isn't properly accounting for the requirement that both the wing root and the wing tip are inside the bay bounds. The code is exactly correct for the latter, so I suspect the former, and I don't know how to fix that.

The problem is that FAR doesn't figure out and apply drag properties to wing parts, and the cargo bay's module type is "Winglet." Change it to be "Part" like all the other parts and it should work fine.

@not-a-cylon: That sounds less like KJR and more like a stock bug; there's really nothing to be done about it without seriously decreasing the physics timestep, which would make the game horribly laggy. It's an error that can be replicated stock, in KJR, whatever, as long as enough of an initial error is caused things will fly apart. Lemme guess, it has very heavy masses, radially attached on spars, with a very high symmetry count. @Duxwing: Go ahead, looks good. I've also cleaned out my inbox.

I'd be afraid of the mesh being difficult to read due to the fact that we're dealing with 3D visualizations, which might make the location of particular dips and rises difficult to pinpoint. Contours could be projected onto a plane, removing that issue completely. Yeah, guess I'm kinda over-complicating things. Fortunately, no one has a system that includes lots of bodies close together with high relative inclinations. I mean as a subtle kind of highlighting or darkening of the contour. Not enough for it to jump out and scream "THIS IS A HILL SPHERE," but enough that it grabs the player's eye, marking it as important, even if it's only subconsciously. Subtleties can go a long way towards making things clearer with no one even realizing that it's there.

Resizing nozzles is shiny! Go chase the shiny resizing nozzles Nathan! More seriously, it'd be nice to have that, since otherwise I'll have to build a mortar rocket to take advantage of it for fun and profit (it does minimize gravity losses, so there's a reason too).

The problem is that you have too much roll control, which causes SAS to way over-react to minor deviations in roll. Use tweakables to shut off roll on the fins and you should be fine. SAS is terrible if it has too much control authority. Always bring less control then you think you need.

Some more thoughts: Well, if you do something like this graph, or something based on it but with colored contours I think it would be very helpful for figuring out what is going on if it can be toggled on and off. I think that the best way to do that would be to draw it in the plane of the orbit only (to reduce confusion), and allowing the player to select which body to base the plane on as an advanced option. By default, set it to handle the "dominant" bodies in the situation, so by default around Kerbin it would work in the plane of Kerbin and the Mun, until the player gets closer to Minmus and Minmus' influence outweighs the Mun's. In a situation like the inner Joolian moons it should attempt to draw in some type of "local ecliptic" plane that attempts to do a mass average of the bodies involved to find the proper plane, but only do that once. I'm not sure how you would handle the rotational potential for the Joolian moons, probably base it on the most massive body? Whatever is done, if it's possible to mark the edges of a body's Hill Sphere that should be done to make the effects as clear as possible. We'll need that to be the new SOI type of effect. I have an idea here: once you start something under thrust, show the current trajectory (time t), the last calculated trajectory (time t-ÃŽâ€t), and the estimated trajectory based on the craft's instantaneous acceleration a slight bit in the future (time t + ÃŽâ€t). Make the last one a little less accurate than the others, since you'll throw it away; store the current trajectory and shift it over to the last calculated every time you recalculate things forward. Your ghost past and future trajectories now show the approximate error that will occur due to the player making a fraction-of-a-second error in the burn time. My only concern is that the less accurate future calculation might add a bit to the computational overhead, in which case you can simply use the old trajectory. Seems simple enough, especially if fainter colors are used for the ghost trajectories.

Nope, FAR doesn't affect the max temperature or heat production of engines at all. You must have changed something else in the process.

@toadicus: What's really happening there is that spoilers are intended to reduce lift, wherever they're placed. Apparently the vertical ones create a very tiny downwards force by deflecting to that side, so they'll deflect to that side. The spoiler assignment algorithm isn't designed for purely-vertical parts. @wasmic: Whoever told you that more TWR with FAR is better is wrong. Best initial TWR range is between 1.2 and 1.6.

Perhaps the best choice would be to find the "end" parts for the stiffening and only connect those, and only if they have other things connected to them. It should give approximately the same effect.