ferram4

@Blipser: KJR doesn't care about node sizes, because experience has shown part packs don't have the nodes sized right. It uses the mesh for joint strengths. @eddiew: Welp, then I don't know what to tell you, because there's nothing to trigger a disconnect in the new multipart joints for docking ports in 3.0.0. @Traches: Okay, I can reproduce it. Thanks, no one else mentioned that gigantic mass ratios were necessary for it to be caused; it's like they didn't even care enough to provide reproduction steps. I think what's happening is something's breaking in KJR's attempt to stabilize physics loading, as well as the issues of launch clamps and floating point errors with those. I'll see what I can do, but I have no idea if I can actually fix any of it. The more and more I look at things, the more apparent it is that the stock attempt at fixing joints just got in KJR's way.

I dunno Augustus, you've been pretty quick to try and take over every mod that you can touch, so I think you're up tot he task of fixing those issues, right? Surely you wouldn't be bundling mods or trying to take them over if you weren't able to do anything about it, right? I mean, that would be rather confusing and kind of a scummy thing to do to the original authors, make them have to deal with whatever you mess up. Anyway, yes, the issue is on your side; your pack, your mod, whatever. BB works fine so long as planets conform to the stock expectation that flightGlobalsIndex matches the index that the body is in in the FlightGlobals.Bodies list. If they don't, that's not on me.

Very interesting, because it fixed the standard shielded clamp-o-trons perfectly.

@NonWonderDog: Not much I can do without needing a ton of part-specific data, which I really don't want to do, ever. That just causes issues when people show up later asking, "Why does X not work the way I expected? Why does it need configs, I want it to work automagically!" Damping on splashed-down parts should be approximately what it is in the air. Dunno why they're spinning so much. @_Augustus_: Fine, let me walk you through the code then: BB stores water densities in a Dictionary that associates an integer (the FlightGlobalsIndex) with a double (the water density). The first time a density calculation is called, it loads data from a config to get densities associated with each FlightGlobalsIndex. Once that's done, it goes through all of the bodies that exist to make sure it got them all, adding them to the Dictionary. There can be no repeats here, because the dictionary cannot handle repeat indices. After that, the BB module uses that in flight to find the appropriate density for each body. There are only three possibilities here: 1) You've got multiple bodies using the same FlightGlobals index, which breaks the Dictionary. 2) You've got bodies that have different FlightGlobalsIndices than the _actual_ index they use, in which case, your Kopernicus code is doing something damn funky and needs to be fixed; I'm sure you'll get on that right now, you are, after all, the main coder for that, right? 3) The bodies don't exist early in flight, in which case, Kopernicus is heavily broken and they should exist as soon as the Space Center Scene loads. Nothing I can do, problem is on your end.

Why not try the dll and find out? More data points are always helpful when dealing with bugs.

@Redgum: If your rocket is acting like a pendulum, I'd suggest cutting its connection to the ground. If that's not the problem, you need to describe it more clearly. @eddiew: I need a full copy of the output_log.txt, since I haven't seen any issues with physicsless parts in cargo bays. @DaMichel: Update all your FARPartClassification files and get rid of the custom one, intake handling has moved back into code, not MM.

@_Augustus_: Problem on Kopernicus's / the planet pack's side then; why the hell do you have multiple planets with the same FlightGlobalsIndex? Are you deliberately trying to break things? @EladDv: 1) *Points to name* Whadda you think bub? 2) Try it. 3) Why? There's not much to improve, and you only get numerical errors because the engine isn't set up for forces like that. Not worth it.

None of the mk3 have a lifting body module; they are all commented out. Further, the override does not actually do anything if the lifting body module is not applied. Finally, when the lifting body module is not applied by the game (which it is not, because it is commented out), FAR will treat it as if it is the same as any other fuselage without wing lifting surface parameters. They are identical in every way that matters to the HL fuselages. They will behave identically to the HL fuselages. I know because I've made planes with them, and they behave identically. There is absolutely nothing for me to change at all; the modules you complain about don't exist in code, the drag values are never used by FAR anyway, since it applies its own. I don't know what you want me to do, besides lie and say that I fixed them even though nothing changed.

Mk3 fuselage parts are identical to B9 HL fuselage parts in every way. There is nothing to fix.

Based on behavior, this probably goes back to the introduction of tweakables. This is probably not a new issue.

Yes, congrats on finding the well-known and easily exploitable issues with FAR where blunt body drag based on attach nodes is either all on or all off, never in-between due to sizing difficulties. If I could rely on nodes being sized exactly properly or figure a quick and easy way of getting it from geometry that worked in all cases that wouldn't happen, but unfortunately, I have not.

We are quite fortunate that KSp mods are generally devoid of multithreading, so Schrodingbugs don't show up that often. However, if there are NaNs appearing only with trajectories, my first guess would be that trajectories is doing something funny. You can try out the dev build of FAR (dll in the github repo, not the release itself) if you want to see if it makes a difference.

Ummm... what? But nothing changes physics-wise between flight view and map view at all; are you sure that it's not a coincidence or that something else isn't interfering? And I still need reproduction steps that include the minimum rocket needed to recreate it, since I haven't seen anything happen when switching to map view myself. Full logs would be helpful, maybe. I dunno, this is just too weird to actually be caused by switching to the map.

Try the dev build. That's already been fixed.

@Hektos: If no reproduction steps, no ability to address the issue. That's the way it works. @Sandworm: I would say that since the NRE is happening in Toadicus's stuff, it's probably an issue there. Nothing I can do about someone else's code.

...I appreciate all the effort going into the mod lists, but given how simple the reproduction steps are, either something is being missed or it is a mod interaction. If it's a mod interaction, you need to simplify it down to only the mods necessary to cause the issue, and no others, because the more mods are involved, the more complicated the troubleshooting becomes. No, it's not much work, and you guys get the better end of it, because you don't have to try and fix the issue, just tell me the actual causes of it.

Nope. Code change that fixed USI sounding rockets was in 3.0.1. Nothing has been pushed to github since has changed how KJR behaves with respect to USI auto-decoupling. If the sounding rockets were still having issues, you were running 3.0, not 3.0.1.

Your terminal velocity with NEAR is probably something around 400 m/s at SL for a fully-fueled rocket. It's only going to get higher as you gain altitude. Stop thinking in terms of stock aerodynamics when you're running an aerodynamics mod.

No, experience has shown that multiple releases close to each other results in people getting update fatigue and continuing to run on older versions; then they report bugs that have been fixed. As proof, I submit Damaske, who just recently reported an issue that was fixed in 3.0.1, but who was still running on 3.0. It is simply not worth the hassle, and the stable release will wait until people providing bug reports can simplify the issues down to the minimum crafts and mods needed to cause them so that I can either close the issues as due to something else or address them.

FAR has never done anything that would conflict with PlanetFactory itself. There have always been cases where careless planet creators would set multiple bodies to use the same FlightGlobalsIndex, which would then cause issues, because FAR uses that index to identify planets for the purpose of applying atmosphere data. It's nothing either of us can fix; it has always been a problem created only by planet makers who refuse to take responsibility for the issues.

No, this is just as useless as a center of lift indicator, and it's why that is the worst name ever for an indicator. Let me explain why: Let's say you have the center of lift behind the CoM, and the center of drag in front of it. Is the vehicle stable or not? Well, it depends on the relative strengths of drag and lift, which you're not gonna get clearly out of the indicators at all. If drag is much stronger than lift, then it will be unstable. If lift is much stronger than drag, then it will be stable. In both cases, though the vehicle dynamics will be completely different, the indicators will show the same thing, which makes different center indicators useless. To that end, NEAR and FAR change the center of lift into a center of pressure indicator, which accounts for both. And whoever named it the center of lift needs to be smacked for making something so confusing.

No different acronyms! BB doubleplusgood. Goodthinkers bellyfeel BB. Ungood crimethinkers ungoodthink BB. Crimethinkers report to miniluv joycamp asap. (Yes, the entire acronym is the setup for a Nineteen Eighty-Four reference. Yeah, I'm weird.) Anyway. I might have fixed something related to the sinking Kerbals, which might be the cause of the EVA stuff not being applied properly if it tries to run on a null vessel / Kerbal before it gets to the one that was actually created. Github repo has a dll with the change, but I don't know if that's actually gonna fix it. I also need to add a maximum splashdown velocity sanity check, because it's come to my attention that ditching can be done at 150 m/s if you're crazy enough, and that's ridiculous.

Well, good news is that I tracked down the vessel-stuck issue and the undocking issues; the dll in the github repo has fixes for those. v3.0.2 will be out at some point to fix those in a stable release, but I'm still waiting to make sure that I get all the bugs, since the bug reports I've been getting are absurdly general with highly generic reproduction steps, which basically means that a full release will have to wait for those people to provide more information. Until I can actually reproduce the issues I can't fix them.

That's something that FAR does, not BB. And if you're trying to go too fast with too draggy a part in the water, it will come apart. Stick to using structural, non-fuel tank, non-wing parts though. Those tend to hold up better to aero-/hydro-dynamic forces. On the other hand, you could probably get away with using the other type if you keep the forces on it low by putting them in low-drag configurations. Build it like you would a plane, just designed for higher forces at lower speeds.

Aero stress failure is determined by the aero- (or in this case, hydro-) dynamic forces on the part, which is measured against the maximum force it can handle per unit area before failing. If that force is exceeded, it fails. Parts are better at handling hydro forces though, but they will still fail at relatively moderate speeds; you need to understand that water is 815 times as dense as air. Going above 40 m/s (90 mph, 144 km/h) is asking for trouble, and you deserve it at that point. Buoyancy force is directly related to the volume of the object and the density of the fluid displaced; how something floats depends on whether or not that buoyancy force can balance gravity. Very straightforward. It's also very obvious how dense command pods are compared to their real life counterparts, but I'm not changing the physics magically to account for that.