ferram4

@AnatolyVasserman: The CoL is automatically calculated based on the wing parameters specified for the PartModule (documentation in the Readme) assuming that the part origin as located at the center of the wing root. In order to make sure that it is placed properly the wing must be able to be radially attached properly so FAR can orient things properly. So you're going to have to shift the models in the config so that the part origin is in the proper place and then make sure that it can be surface attached like the stock wings.

Make it less stable or add more pitch control. The problem is that the CoL is shifting backwards as you head into supersonic flight. This makes the plane more stable. When the plane becomes more stable, it takes more pitch authority to change its angle of attack. If you make it less stable you'll counteract that. Another problem might just be that the relatively low sweep angle of your main wing is creating a lot of drag at supersonic speeds and that is enough to hurt your pitch authority. Sweeping the wings more or replacing them with delta wings might help.

Then do that and I'll look into it. Maybe ReStock has something really weird going on with it.

I just tried playing around with TT-70s and they're solid as a rock. You're going to have to post a problem craft (preferably without mods), since I can't seem to reproduce the issue on my own.

If you have a ton of struts between the rockets that might be the problem, since struts can cause lots of weird structural issues if used to excess. Besides that, this sounds like you're using the small extended radial decoupler (which has the problem of giving parts a very large moment arm to work with) with very large masses on the end; that's a recipe for things breaking. Frankly, I don't know why anyone would use the TT-70s, they're heavier and wobble more than any of the other radial decouplers. If you really want to "fix" it, go into the config.xml, find the "breaktorqueperMOI" value and add a zero to it. There, you won't ever get any failures due to over-torquing again.

Pretty much all of the shuttle mods have been designed without the ability to be set up for FAR compatibility, and I'm not exactly in the mood to go and dig through how the wings are set up to try and hack it together. Ultimately, even if the wing properties could be properly applied the shuttles will probably handle badly due to the fact that they will have been optimized for stock aerodynamics, not FAR aerodynamics. The last time I tried to work on something like this it involved trying to get Bobcat's Buran to work and it never ended up working properly.

My plugin measures the size of the parts in order to determine how much surface area they have for applying drag. The "size 1" parts end up being ~1.25m, the "size 2" parts end up being ~2.5m, and the "size 0" parts end up being ~0.625m. The numbers aren't exact since there are flanges and pipes on the sides of the cylinders that mess things up, but those are numbers taken directly from the meshes as they are displayed in-game. So the descriptions are wrong and the parts actually are 1.25m, 2.5m, etc.

Yep, just checked and removed that. Will be fixed in the next version; thanks Blizzy.

That problem is caused by Real Solar System exacerbating a stock KSP bug involving launch clamps that causes them to shift a bit when the rocket loads. There's nothing I can do about it, and it also occurred in v1.7. Actually, I saw it happen worse in v1.7 than in 2.0, so my experience is completely different.

Does the problem occur only if you add it to intake parts, or can it be caused with all parts? I'll admit, at this point I'm at something of a loss for solutions.

You still have tons of control authority. You don't need ailerons that large for a plane that small.

It's called "SAS doesn't know how to handle lots of control authority." You're adding too many control surfaces; reduce the number and you'll be fine.

No, I read that straight from the config file; it's 4t empty. Also, all the fuel tanks (with the exception of the Oscar are 8/9 fuel and 1/9 structure, which is consistent with 4t dry, 36t full.

Try specifying a "majorMinorAxisRatio" of 1 and see if that fixes it.

I don't know then. Does it occur with any other intakes, or just that particular one?

@NWM: But all of that should be counteracted by the effect of the payload on top of the rocket, which will become a much larger portion of the rocket's mass and should help pull the CoM forward. If you want to play around with things, there are two values in the config.xml that you need to change: set incompressibleAttachDrag to 0.01 and sonicAdditionalDrag to 0.2, and then it will be realistic levels of drag. @Nemrav: That sounds like a good way to have extra code bloating the game for no reason, especially if you have to put the work in to set up a popup to inform people that you're going to remove an option. You'll also never convince people to let you remove an option once you give it to them. IMO, the best way to handle aerodynamics options is to put a button labeled "Disable Aerodynamics" next to "Infinite Fuel" and "Hack Gravity" in the debug menu. If people don't want to deal with aerodynamics, they don't have to; they'll just have to own up to the fact that they're using the debug menu to get past things that they can't handle.

The first key you have for CdCurve is -1 0 .01; that will be read in as 3 numbers; either fix it so it's -1 0.01 or -1 0 .01 .01. That's the issue. FAR can calculate all of the aerodynamic properties or you can override all the aerodynamic properties; there's no way to pick and choose. If you're not concerned about the lift parameters, just specify a 0 lift curve.

@DaMichel: It'll probably get released before I get into a job, based on my experience with how unsuccessful job searching is. @ThorBeon: Part clipping can cause a lot of weird things to happen. That's probably the cause. @Piwa: Gimme the dimensions of the fin and I'll work out a config for you. @The Russian 1021: That's because Buran isn't configured to work with FAR. Based on the work that Dragon01 was doing trying to get it to work, the entire thing will need to be redone to even have a hope of being compatible with it. @camlost: Part of the error might be due to the CdCurve having three entries rather than two or four; that might cause an issue to occur. But I think the actual error is due to a change in variables that I haven't properly documented (oops), where ClCurve was split into ClPotentialCurve and ClViscousCurve (potential curve drops off after Mach 1, viscous curve doesn't), so you need to change ClCurve to one of those and define a zero-at-both-ends curve for the other one. Then it should work.

@Brandano: So, under this model, the best option is to build your rockets out as wide as possible, consisting of 1-tank tall liquid boosters only so that you can get as many nosecones attached as possible and maximize the drag reduction. This actually sounds like it'll encourage even less aerodynamic designs than we currently have, which means that as a quick-fix it's a bad idea since it will lead to players getting even further from proper rocket design with a good aerodynamic model. @NWM: I think you're misunderstanding what I'm saying, and you've done it twice. Decreasing the mass of engines and increasing the dry mass of fuel tanks a proportional amount leads to the same full and empty mass overall, which means no change in dV for the proportional cases and only very small changes in dV for other cases (generally leading to less dV, since the best possible full/empty ratio is lower). As an example of what I'm saying, let's use a Mainsail + 3 Jumbos as our stack: Current Masses: Dry: Mainsail (6t) + 3 * Jumbo (4t) = 18t Full: Mainsail (6t) + 3 * Jumbo (36t) = 114t So, let's cut the mass of the Mainsail in half and add the difference to the Jumbos equally so that the dry mass stays the same. Leave the amount of fuel as it is. Adjusted Masses: Dry: Mainsail (3t) + 3 * Jumbo (5t) = 18t Full: Mainsail (3t) + 3 * Jumbo (37t) = 114t Same full and empty masses, same dV out. This is what I want, it just shifts the CoM further into the fuel tanks rather than being pulled down as much by the engine.

@majic79: That should work for pretty much any shape, since all the parts are made up of flat polygons. You could grab it straight from mesh even. The only issue I can see is determining whether any particular face is exposed or not. @eggrobin: There are values in the config.xml that can be changed to fix that. I believe that the Realism Overhaul pack includes a fixed FAR config to adjust those drag properties.

Okay, yeah that makes sense. Sorry, it's just a bit of a knee-jerk reaction, and I wish there were a better term for it. It reminds me of objects "orbiting" around Lagrange points and the confusion that can stem from that, and then we end up with uninformed people getting misconceptions about what can work and then everything goes to hell. Okay, I think I see what you're talking about here. You're considering the actual thickness of the shock the wavelength; I was working under the assumption of the shock having no thickness. I haven't done work involving shocks with actual thicknesses in awhile. Oh. FAR does what you want then, though it does it on a part-by-part basis and won't even account for a fuel tank being half-buried in the side of a fuselage. I haven't figured out a good way to do that yet and I don't know much about graphical stuff to be honest. Sorry, I got a little trollish near the end. I should have realized that's what you meant, I was just confused. The point isn't to make things easier dV-wise, the point is to make rockets less likely to flip out. Way, way back, FAR actually had the back of rockets produce realistic amounts of drag. Pretty much every rocket you built (unless it had tailfins) needed to be controlled exactly right or it would flip out spontaneously, since the CoM was so low on it. Now, FAR applies 20 times real-life drag to the back of the rocket at Mach 0 and 5 times real-life drag to the back of the rocket at Mach 1 to try and keep the thing more stable. Unfortunately, this also makes planes and landers behave somewhat strangely. The solution then is to reduce the mass of the engines, and then add a corresponding amount of dry mass to fuel tanks to balance out the change. It's already about making things fun as opposed to realistic; it's just that KSP's current rocket mass distributions actually make a more sophisticated aerodynamics system a non-starter since it's almost impossible to prevent a rocket from flipping out, so things need to change.

@acc: There's a the option to set negative deflection angles that will be coming in the next version. That should do what you want. @DaMichel: No, they need more testing. Besides that, I haven't been able to do much testing recently because I've been doing a job search, which is even worse because I'm trying to move out of NYC to Palo Alto / Sunnyvale to get into a bunch of the aerospace and satellite companies that are there (also personal reasons). So I've been somewhat distracted from KSP due to that. So I have no idea when things will be released.

@wasmic: Fairings have a special exception to deal with that. That's been there to deal with fairings since KW first started doing their interesting fairing design. @DaMichel: A known issue with cargo bays. I have a fix from a.g., I'm just still testing stuff out. @camlost: Probably the best way would be to look into defining a new FARBasicDragModel for those parts that produces no lift or drag and make sure to use ModuleManager to set all of the stock drag parameters for that part to zero. @ThorBeorn: And you didn't have any trim set, nor did you have any of FAR's other control systems left on, correct? It just sounds like a control error, not a physics error to me.

Then you should have defined what you meant. You spoke about treating things using light and then used occlusion rather than speaking about faces exposed to the airflow; considering that the standard idea people have with respect to this is that "air == light" (why? I don't have any clue, it doesn't make sense), you basically shot your idea in the foot. Umm... I don't think shocks have a defined wavelength. I'm not actually sure what you're getting at here, since none of my aerodynamics classes (even the ones focused on supersonic flow) ever went into shocks having wavelengths. Shocks are more akin to step functions, not sine waves like traditional sound. It's a lot more intensive than it needs to be for what you're getting out of it. You could get the same effect by simply storing a bunch of properties and doing vector math every frame rather than running a lighting type of function on the CPU or trying to send it off to the GPU and waiting on the info getting back from there. I mean, vector math and storing variables what FAR does, and it really doesn't hit performance that much and it's not even completely optimized. What do you mean exactly by "without interfering with the remainder of the simulation?" It would be a pretty poor aerodynamics model if it didn't affect the rest of the simulation, so I have to assume you mean something else by this, since you just said you meant something other than light and occlusion when you were speaking about light and occlusion.

Ah, the old Raycast Drag Experiment? I need to get that up-to-date so it properly works in 0.23. I decided the best way to shoot the idea down was to implement it and let everyone realize how bad it is. Sort of works for rockets that flare at the bottom, completely fails for anything else. And that's with some kludge fixes in there to make it work. Also, it ate processor power like crazy and that was only calculating for the active vessel.