ferram4

@Forty21112: There is, but there shouldn't be a vector associated with it at all. It's a point in space, not a vector floating at a point. The vector is meaningless, has always been meaningless and has caused unnecessary confusion. It should have never been there in the first place. @tetryds: No can do. Outside of my control, it seems. @Necrobones: Noted. I think the dev version fixes it.

@DaMichel: And now you understand why I don't try. It's even more difficult because some user designs don't have distinct wing / tail / canard surfaces, which makes it worse. @blowfish: 1) Known issue with the stable; try the dev build, it works much better there. 2) Remember to also keep track of your reference area. It is possible for total drag force to increase, but drag coefficient to decrease, if the decrease is countered by a sufficient increase in reference area. For winged vehicles, reference area is the summed flat area of each wing part, while for wingless vehicles it is the total surface area of the vehicle.

...well. That provides an explanation. I just have no idea what's going on. I'll try to look into it. Could you attempt seeing if the same behavior occurs in the 32-bit linux build through Steam as well?

I seriously doubt it's a Linux issue, something that bad would also pop up in stock. Go ahead, try it anyway, maybe there's something deeply screwed up there and I just don't have that many linux users. Try moving the KSP directory outside of Steam and run it without using Steam at all. As if it were just another program.

There is no mod manager because mod installation is incredibly simple; it's copying folders from an archive into the KSP directory, and that's basically computers 101. When mod installation is that easy, why complicate it with a whole extra program that obfuscates everything and leaves the user in the dark? It's just not necessary.

The log does have some "Look rotation vector is zero" lines that hint that something is going wrong, but it doesn't hint what. I just made another install of KSP 0.25. I installed FAR as it is included in the 0.14.2 download. I did not experience any of the behavior you describe. Your reproduction steps are, therefore, incomplete.

First, your logs are incomplete; they do not extend past the loading portion of the game. Second, your reproduction steps are incomplete; I have followed these steps multiple times and have not seen anything like this. Your reproduction steps are missing crucial information, or else the bug is caused by another mod / change to your install.

Well, in that case you need to find what causes the spin. Either the fins are not straight, the boosters are not straight, or under thrust they flex enough to not be straight. It's probably the fins if it only started after adding NEAR, because they're suddenly a lot better at lifting than they used to be. Odds are you don't need as much thrust as you have. If you've got a TWR > 2 when you start you're in for a bad time with NEAR or FAR. The key isn't to chase terminal velocity, the key is to go as fast as you can without losing control; going slower in the atmosphere reduces the chances of losing control.

Haven't worked towards fixing that, since it's such a small issue. I can look though.

Good news everyone! The next FAR is almost completed. At the very least, I've squashed all the really nasty obvious bugs. If you want to mess with it now, it's been uploaded to the github repo as the latest dev build. Wing interactions should be quite a bit smoother for this version.

There, try that build.

@Wanderfound: If you're setting the wings to be 10% their default mass, but somehow they're still stronger than the previous build, then your wing strength is not varying with mass. Setting the wing mass to 10% of the default will result in the wing only being able to sustain 20% the forces of the default. Since the default wing strength doubled between the old FAR build and the current one, this means that your wings should fail at forces that are 40% the forces felt in the previous build. Since you're reporting the opposite, I have to conclude that something is wrong on your end. Delete all the custom config files in your FAR directory and re-download. @JackY: As noted, these wing masses are more realistic and the wing properties for SP+ parts prior to 0.25 were completely wrong. You are complaining that FAR is handling things properly now.

@Wanderfound: I don't know where you're getting the setting going all the way up to 5; it only goes up to 2. Based on the problems you're having, I suspect that both of you simply have improper installs. I haven't been seeing any of the issues you are complaining about. If reducing the mass that much has no effect, I suspect that you haven't downloaded the updated FARAeroData.cfg, and so strength doesn't vary with mass at all. Remember to delete CustomFARAeroData if you that is the problem.

@Voculus: So they were built out of SP+ parts before they were re-balanced for inclusion in stock? Well, the wings were not given the correct parameters, prior to 0.25 and the masses of the fuselages changed, IIRC. The only flight mechanics that have changed at all are that intakes now have drag somewhat more than an equivalent-sized nosecone, so unless all your designs exploited incorrect wing parameters and no intake drag, nothing should have changed.

Altitudes don't matter here; velocity does. Based on the altitudes you have mentioned though, I gather that you're deploying your chutes well above 600 m/s. Even at those speeds, the heat is enough to destroy the chute. This sounds like intended behavior to me.

@UncleCrusty: Listed in the last changelog as a feature; wing masses are now based on the amount of area they need to support, and the numbers are based off of the approximate wing mass of an MD-83 (which happened to be about in the middle of the approximate wing-mass-per-area for a few jet transports). It certainly isn't multiply by 5.05, it's 0.065 tonnes per supported area. @Wanderfound & Voculus: Like I said, I don't even know how you got SAS to be useful in the first place. Reduce the amount of control authority you have or make the planes more stable.

I don't know how any of you had any success with SAS before, nothing significant has changed on the physics end. On the other hand, the number of changes to the SP+ modules might have changed things (they had a few problems previously) and so that might be part of the cause. Regex is looking into how SAS works to see if anything can be done about it, but I don't know how long it'll be before I can consider messing with that. At any rate, the dev build in the github repo now includes a refactoring of wing interactions stuff that should be more efficient and act a little smoother wrt what parts are in front of what. Feel free to try it out.

I cannot reproduce the issue on my machine, therefore, for me, the bug does not exist. I'm asking for logs and reproduction steps because while I can't cause the issue, apparently you can. For someone talking about trying to help me, you've really not provided any information at all that helps, and you've refused to multiple times now.

It's still there. Unfortunately.

Umm... with the way you have the fuel lines set, this is correct. The fuel search algorithm is looking at the part that the RAPIER is attached to, and it sees that there is fuel further from it. So it goes to the next tank. Then it sees that there is a fuel line going INTO the middle tank that comes FROM the bicoupler (the arrows on the fuel line matter). So it drains fuel from the bicoupler, through the middle tank, back to the bicoupler, into the engine. Solution: get rid of the fuel lines. Then it will behave as you expect.

FAR does not suffer from this issue, AFAICT, unless you are running on a very old dev version. Please follow the steps that I linked, or you will not get any support. Those steps are there and are stickied for a reason.

That's what I mean. Your initial post said: This is not the case. For your test case, the extra (small) control authority from the control surfaces at the ends of your swept wings was enough to make the plane controllable. Disabling the control surfaces on the tail and trying to fly using only the control surfaces on the wings for pitch control showed worse control authority than using only the control surfaces on the tail. Your test case did not prove what you were saying was happening, and my attempts to replicate that resulted in expected behavior. Your planes are just lacking in control authority. That's it. Make them less stable so the control authority you have is sufficient, or add more control authority.

@DundraL: I can't do that though. The stock wing masses are so low that the wings would rip off under tiny forces if I tried to get them close, and considering that the mass of the root of a wing will always be heavier than the mass of a similar piece placed at the tip of a wing. The best I can do is to have the wing mass appear in the tweakables readout. Also, I don't care if challenges disallow FAR. Most already do because of the lower dV to orbit. No skin off my nose. @Baughn: I suspect a bad install. Nothing has changed there for that to be the case, and it works fine for me.

@PDCWolf: Reproduced and confirmed behavior when both control surfaces on the tail and main wing are active. Could not confirm that plane pitched better only with control surfaces closer to the CoM as you originally indicated. Confirmed that control effectiveness is related to distance from CoM as intended. This is not a bug, your planes are just too stable for the control authority they have. In particular, your CoP needs to be closer to the CoM. Shift the wing forward a bit. @Corovaneer: http://forum.kerbalspaceprogram.com/threads/92229-How-To-Get-Support-%28READ-FIRST%29 <- follow the steps here. I will need full reproduction steps, since I don't experience that behavior.

@Temeter: There were some changes to the raycasts used by wing interaction stuff to get around some issues with the SP+ wings. I guess I'll just have to recode the whole damn thing. @Senshi: Good to hear! Now you're on your own, until win64 is stable. Have fun, and don't complain. @Da Michel: Okay... I guess I'll need to recode that then. @wingnutspeed: No, win64 is unstable because win64 is busted. The number of mods just exacerbates an already-existing stock issue. There are also pretty much no incompatibilities between mods; I don't know where you even got that idea. @JackY: If changing the gains and limits did nothing, then you didn't click the update values button. I think that you are expecting an autopilot rather than minor control assistance from the control assistants; perhaps you should code one of those up. Landed and stopped control oscillations are known; it's caused by the velocity vector changing direction like crazy, because you're never perfectly stopped. None of the control assistants are intended to hold attitude. As I said, they are assistants, not autopilots. I'm not building example craft again. They quickly become out-of-date if I update the physics to be more realistic and I expect that the spaceplane parts will get another pass anyway. So... you do want a different window with each value for the sweeps. Yeah, not going to bother. As a side note, I'll bet that plane of yours has really stupidly high wing loading. @Baughn: A completed build can always be found in the github repo.