ferram4

@DaMichel: Yes, I know. Intakes play very, very badly with attempts at dealing with clipping. Yes, I am aware. No, I don't know how to fix it right now. Yes, it would be fixed if part clipping weren't possible. I don't know what to do, besides try and refactor everything, which I'm doing, but it will be slow. Sometimes I think part clipping got enabled just to mess with FAR; it's a complete disaster. @SkyRender: I'm not seeing the problem. It oscillates around a stable point, with the oscillations slowly dying down over time... that's what happens. That's how any stable system behaves. Really, it depends on what vehicle you're talking about, as is always the case with these questions. Rocket? Probably realistic, but will end badly. Capsule? Realistic, nothing to worry about. Spaceplane? Probably also realistic, likely to break up. Things are complicated, one-size-fits-all answers don't really work well here.

That would be because FAR currently uses nodes as a quick approximation for figuring out the blunt ends of a part. When you do things like add a ton of unused nodes everywhere or clip parts in ways that mess with the nodes, FAR does things wrong. Get rid of the nodes and do the surface attach right (if your colliders are messed up, you're gonna have a bad time anyway), or say that you're not supporting FAR until I get the better code implemented.

My Eve ascent test, from the ocean to orbit used ~7.5 km/s. Thing was, this was running at nearly terminal velocity the whole way and being very careful to not break the rocket in two, so you may want to bring a little bit more and go a little slower for your first launch. This also included a fair bit of dV for breaking burns to keep the heating and disassembly during entry from occurring. On Jool, no idea, never tried it.

He's not sinking; he's floating right below the surface, there's a big difference. Anyway, not much I can do; Kerbals are just too dense. Ocean is already twice as dense as water, and the size of the Kerbals is set as the volume of human beings (which is a fair bit larger than Kerbals are). Not much I can do when I've already weighted it so much in their favor.

Alright, update to BB v1.1 with null checking in vessel spawn detection (which should fix the Hangar issues, whatever the hell weirdness was causing that) and a fix for ragdolling EVA'd Kerbals.

@Dr. Death: Yes, yes, you somehow have a magical win64 install that has no issues at all. The game doesn't crash randomly, it doesn't have graphics glitches, and career mode isn't broken. I've heard it all before, and I know it's a lie. The only people who have ever come out saying that win64 works fine are the few that decided they had to start showing up in modder's threads to give them hell for trying to keep inaccurate bug reports of stock behavior from burying things that can actually be fixed and to keep the insults, harassment, and demands that we fix someone else's code to a minimum. Now, I have considered unlocking for win64, since a large number of people are aware that it's broken now, but I'm not going to. Simple reason is that people have gone and demanded, demanded, demanded, as if they paid me for a product rather than getting something for free. They've insulted and thrown harassment at modders, because of course, maybe if you throw hell at the guy long enough he'll crack. At this point, "we don't appease trolls and entitled jerks," has been added to the list of reasons why win64 is still locked. It's not getting unlocked for a long, long time, and you are not doing anything right now to make it happen sooner. @*Aqua*: They automatically do that. In vacuum, control surfaces will not deflect from control inputs. Flaps, however, will still deflect so there is time to put everything in the right positions for reentry.

Yes, yes. Dev build has some changes that I think fixes the issue. Try it out, see if they reoccur.

Flap setting should be handled same as any other setting on the part, it uses the same method as anything else. Flap setting values can be read off by right-clicking the flap. They're somewhere between plain flaps and single-slotted flaps in performance.

I'm with marce on this one. The arguments against mod packs have been rehashed again and again, but at least most of those people had the decency to, ya know, ask about it first. Courtesy does make a big difference in reception. Also, I've noticed that you're unwilling to take all bug reports. Nope, sorry; you redistribute, you support. I have no idea what changes you've made to any of my mods that are being redistributed (and I can't even tell, given that there's no link to the source for any of them), and so I will not support any users that got them from you. You are doing a disservice to any users you might have by redistributing mods that you cannot support, and all you will do is make the workload heavier for modders. Absolutely no one wins from this, besides you, I guess, because you get the glory of being the great creator of the modpack.

The base drag for a part is. However, there are other factors used for part interactions, and those are the problems you're seeing. Because FAR uses an unused attach node as an indication of a highly blunt face. In theory, this would work out great, if Squad hadn't used the size 0 node for non-radius 0 parts. If it's just behind the nosecone, then that doesn't mean anything; they can still have an affect on the recirculating flow. If you're clipping parts together, then that's something that I can't detect, without making everything a lot laggier (and neither will Squad), which is why I tried to convince them to not enable part clipping by default. This is actually a legit problem, one that needs to be there because of that insane method KW Rocketry uses for attaching fairings, which results in tons upon tons of attach nodes. Turns out it's difficult to differentiate those from the ones elsewhere. Also a legit problem, one that could be fixed very very quickly by ensuring that the correct node sizes need to be connected in order for all drag to be cancelled. Problem though: mod packs rarely, if ever, set their nodes correctly. A possible solution is to instead try to get size from the part mesh, but that leads to issues for parts like the quadcoupler where you're trying to detect and allocate a common area among many nodes. Not really easy, and lots of edge cases. Also, that method is laggy as all hell, hence why it isn't implemented yet (incidentally, this would fix the payload issue as well). This one isn't my problem, RealChute does its own thing entirely that I have no control over. Don't blame me for another mod's behavior, I get enough of that already. I'm sorry that it isn't perfect. I'm sorry that I try to maintain compatibility with as many mods as I can. I'm sorry I care about trying to do this without lagging the game to hell. This works for 95% of the situations people find themselves in, with only a few oddities remaining. Methinks someone needs to check out the reference area being used. D = 0.5 * density * velocity^2 * area * Cd; increase the reference area, and it's effectively the same as decreasing the Cd. You should see some of the rockets you'll fly, with huge reference areas, because FAR uses surface area as the reference area to make skin friction drag easier to calculate. You were doing so well with criticisms until you edited that in and showed that you really aren't running the numbers.

That's actually impressive. You got a SSTO rocket that could auto-fly itself to orbit (and I assume a circular one, or you would have mentioned the elliptical orbit downside). That's actually really damn impressive, especially considering that high accelerations at burnout (like you get with SSTOs) generally makes getting nice circular orbits impossible in a single burn. I actually wanna see this rocket; I've never been able to get something like that to happen in NEAR or FAR.

No, actually. That's for roll stability and yaw damping, not for roll damping. The trick to get more roll damping is to have a longer wingspan.

@Cerebrate: I was insufficiently rigorous when making sure that the rigid bodies being connected were not null. When the second rigid body of a joint is null, the joint is connected to worldspace; this is what launch clamps do to stay in place, and is part of the reason why you can get them to fly after you if you accelerate away at >750 m/s, which is when the world moves with you. Problem is it seems like it takes a second for that to be set up right, so in that second, if you're moving at high enough velocity, the connection to worldspace asplodes your vehicle. Anyway, KJR v3.1.1 is out to fix the issue. That should be it for now.

Positive indicates rearward sweep, negative is forward sweep.

I am still unable to reproduce the issue. None of my vessels, however complicated suffer from that; what is different about your problem vessels? Can you simplify them down? Give me something to distinguish them from everything else. I have noticed a trend with this particular update, that all the people having issues have a very large number of mods and cannot simplify their vehicles down to a simple test case. I don't have the time to do all those test cases, especially since I don't even know what I'm testing for or what's on those problem vehicles to begin with. I'm being tasked with baking a cake without the baking time and baking temperature, and having attempted to substitute my own guesses for those, they've failed; it's up to you guys to tell me what I need to do to cause it and exactly, because I'm utterly clueless as to how to cause it. Edit: Wait, I think I got it! Okay, someone try out the dev build I just pushed and see if that fixed it.

@helaeon: A picture and point out which parts are physicsless, please. I can't figure out what you're doing at all. @Mystique: And can you reproduce it without those mods involved? I cannot reproduce following your steps at all, unless EL is necessary to produce the issue. Extra confounding variables do not help in finding and fixing bugs.

I can't reproduce it, on either tiny probes or large vessels, for both of your reports. I sent a probe out to Duna specifically to test, and it was perfectly fine, nothing wrong.

Try out the current dev build on the github repo, I think I may have fixed it.

Hmm. Might have to see what Universal Storage does differently. Hopefully it's not a major issue.

@LostOblivion: Need reproduction steps. In any case, any external forces capable of changing your orbit are from outside KJR; KJR only models internal forces, which will onyl affect the orbit due to KSP's inherent numerical errors. @Cerebrate: Need reproduction steps. @Mystique: I cannot reproduce. I need full reproduction steps, of absolutely everything that you did from that session until you caused the bug, as well as a full mod list. That occurring indicates that somehow the vessel was destroyed before KJR's physics easing could finish working, which could be KJR alone or it could be other mods interfering. I have no idea. @aradapilot: The current KJR build was developed using procedural parts as the standard test part, and I haven't seen any of the issues you're reporting. I require full reproduction steps and a copy of the full output log. Also, the build is still hosted, you just have to go back to earlier commits.

Well, you're compiling a dev version, not the stable version. That would do it.

If it's lagging that much, something else is eating up your processor. It'll hang for a second or two at the worst for a 10-part thing being attached in 6x symmetry, but if there's 20 seconds gone, something else is preventing FAR from doing the work it wants to do. You can try looking into measuring the execution time for updating all the FAR stuff OnAboutToBeAttached or whatever it's called (I honestly don't remember), but I think that some other process is hogging your processor or that your antivirus is constantly interrupting KSP or something.

I don't know why everyone's so disappointed about something not on the scale of FAR or NEAR; we should have seen this coming, given how long this has been delayed. An aerodynamics model on the level of either of those is, ultimately, an alpha feature, one that (for maximum efficiency and reduction in edge cases) should have been implemented many, many many updates ago. Long before NEAR actually existed, and probably before FAR was something significant. The very fact that this was put off until beta basically indicates that it's going to be less than what most had hoped for. And there is a reason for this: they can't make that change anymore. Too many users are used to the stock model; even their improved, not-quite-what-it-should-be one will make them scream bloody murder. Part clipping took away quite a few of the methods that would allow for quick and easy determination of the entire vessel's aerodynamics, and frankly, they're still gonna end up running into problems allowing that. They have ultimately backed themselves into a corner by waiting so long on this. As for implementing FAR or NEAR directly, that was never a viable option; they're both GPL and I'm not the only one who's contributed code. They're both locked away. Didn't stop me from offering to help them out with the aerodynamics, since I could have always coded something new for them, but given that they haven't contacted me over that, I gather that they're not interested. I hope they know what they're doing and that whatever comes out of it is just as easy to mod as the stock system we have now; FAR can't afford to use computationally expensive workarounds for locked-away stuff (not in real-time anyway), and if it comes to that, FAR will probably die with 0.90.

Well, there's nothing spamming the log. Maybe your computer just isn't powerful enough. Alternatively, you're launching large part count rockets and there's nothing to be done to fix that. Lag in the editor when placing things is somewhat expected; I've tried to optimize it, but there aren't many tools available to make sure that everything gets updated as it should be. 20 seconds of it gone is really, really odd, unless you're trying to attach 50-part rockets in symmetry. I suppose I should just not try to update aerodynamics in preparation for someone placing a part to make that easier. Not much else I can do about that, to be honest. Symmetry counterparts being borked indicates something wrong in the stock game. FAR doesn't change symmetry, it just reads off of it, so that points to something else wrong.

Alright, KJR v3.1 is up. Not only does it fix most of the earlier issues, it makes better use of them, so things should be stiffened even more. Woo hoo!