ferram4

If it is related to the previous craft file issues, go into the craft file and search for "FARBasicDragModel." Then go and copy the entire block the module is defined in, including the curly brackets {}. Then Go and use the replace tool to replace that block with nothing in the entire file; the issues should be removed.

That bug was not specific to KJR; that was simply that when struts were connected across a decoupler they would zero the decoupler's breaking force, and KJR created virtual struts across decouplers to make things stiffer. Since my method to fix that obviously doesn't work, it has to be done on Squad's end.

A hotfix has been pushed for that issue.

Sure, just like you can flip around with the Stock Drag Fix. That's what happens when you disconnect drag and mass; there's no way around it. Either you have to deal with instabilities or you have to argue for drag proportional to mass at all times; you can't have both, since they directly contradict each other. Just pushed a fix to deal with ModStats support.

Alright, I believe I've fixed the issue with the old example ships, and I've also included a fix related to ModStatistics support.

It is fixed.

It certainly does now.

@FenrirWolf: I have confirmed the issue; something is corrupted with the older example ships that FAR includes. It only occurs with them; all other vehicles are fine. I'll look into what's wrong with them. @ObsessedWithKSP: I don't believe there's an option to use the stock toolbar in the map. In any case, I don't see why you'd open or close the FAR window there; you're either in space, in which case it's useless, or you're in the atmosphere on a long-haul flight, in which case, you probably already opened it.

There is no interface or GUI for NEAR. User feedback suggested that it was unnecessary and confusing, so it is not available for NEAR.

The first null is happening in the code that determines what parts are what. Confirm that you have (working from the KSP root directory) a file at GameData/FerramAerospaceResearch/FARPartClassification.cfg. Then confirm that there are two blocks inside that file labelled "GreebleModule" and "GreebleTitle"

You must make the file public. I can't access it. And the version naming being off is an error on my part, but I just tried it and I'm not seeing any null references in flight.

KSP.log is useless. You must upload the output_log.txt instead, as that will actually have a stack trace to the source of the error. I suspect that you are not actually running FAR v0.14, as constant nulls when velocity is above zero is a result of an older version of FAR.

@AngusJimiKeith: I dunno if the KSO can be made to work with this. Even though NEAR isn't as much of a deviation from stock as FAR is, it's still enough to make a lot of stock designs completely unworkable. @FlowerChild: Yep. Unfortunately, I haven't worked towards making KIDS 0.24 compatible yet.

The only option you have is to make sure that there are struts connecting parts on either side of the docking port and that your g-forces are not insanely high (read: above 1.5).

It will handle MJ just as well as FAR will: if you give it the right input parameters it will fly perfectly fine. If you tell it to fly like stock it will not. Edit: To elaborate, this is a consequence of disconnecting the CoM and CoD. FAR has this "issue," the Stock Drag Fix has this "issue," NEAR has this "issue." The fact is, the only way around instability problems during launches is to simply accept the brokenness of "drag must be proportional to mass at all times, and no dependence on orientation or shape" and argue for no aerodynamic improvements ever.

Want a better aerodynamics model, but think that FAR is too much? Dislike having to deal with Mach number effects, strange wing interactions and aerodynamic dis-assemblies? Ain't got time for aerodynamic analysis, just got time to build and fly? Then you should try: Neophyte's Elementary Aerodynamics Replacement A simpler aerodynamics model Features: What it does that is similar to FAR: --Drag is based on shape and orientation --Body lift from parts --Infiniglide wings are gone, and now follow a velocity2 proportionality like they should. --Payload fairings and cargo bays function properly --Vehicle stability does need to be considered when building rockets and planes What it doesn't do, that FAR does: --Changes in physics with Mach number --Complicated changes in wing lift and drag due to other parts around them --Aerodynamic dis-assembly (though they can still be broken off if they overload the stock joints) --Complicated aerodynamic analysis tools in the editor This mod is intended as a simpler aerodynamics model for people who want to get into FAR but are discouraged by the learning curve or for users that aren't interested in all that FAR has. It is built on the same code as FAR, and so any mods that are compatible with FAR should be compatible with NEAR. Note: To avoid possibly exacerbating any of the win64 KSP build's instability inherent issues, this mod will disable itself if run on a win64 build of KSP. Download NEAR v1.3.1 from Kerbal Stuff!Download NEAR v1.3.1 from GitHub! As with FAR, licensed GPL v3. FAQ I'm using the win64 KSP build and NEAR doesn't seem to be functioning. What gives? Due to the instability of the win64 KSP build, NEAR will disable itself on that build. This is to ensure that any issues caused by the win64 build can be definitively traced back to it. NEAR is not supported on the win64 build, and you are encouraged to use either the win32 build or to switch over to linux, as both of those builds are much more stable.

@stildawn: Unless the code is breaking during load, KJR is functioning. However, there is only so much that can be done, and connecting very heavy parts through a very light part will always cause flexing. @smart013: No, v2.4 is confirmed compatible with KSP 0.24. Don't know what you're talking about.

No there isn't, at least not any that's accessible.

@AndersW: You would be better served by using KJR's source to produce a plugin that would fix the bug and nothing else. That bugfix is a happy bonus allowed by what KJR has to do to fix some stiffening issues; I am not going to set up the mod to do everything that it needs to do to fix that issue without also getting something out of the extra overhead from adding the partmodules. So quite simply, no. If you would like to, the license allows you to modify KJR as you desire to do that yourself if you are so inclined. @sirkut: Alright, I'll add that to the config.

@mk-fg: Control surfaces stay at zero when in space. It was a requested feature by someone (I forget who). @dlrk: I trust you got it working after discussions on IRC? @Alshain: You right-clicked one of the B9 engines and caused the NaN EC bug, which caused NaN mass, which caused NaN in the math. Either replace the engine parts or set the EC in them to 0, and then it will function. This is not a FAR bug, this is a bug caused by messed up engine w/ alternator configs and it is not possible for me to fix this; it must be done on the part side.

@mk-fg: Known issue. It will not affect gameplay though. There is also no reason to re-launch crafts. @dlrk: A section of a cone. Your service module must be an extension of the command module, otherwise you'll end up with something too streamlined.

That issue has been fixed (a while ago) in the dev builds on github. A link to the repo (not the release link) can be found in the OP, where you will be able to download updated dlls with the fixes.

Check the readme that came with the download? In any case, if you're running an out-of-date version of KJR on an out-of-date version of KSP, there's not much I can do to help you. Those issues have likely already been solved, or will simply not ever be solved for you until you upgrade, since the update to 0.23.5 broke backwards compatibility with KJR due to the new joint system.

Those "collisions" are the reason that the physics easing was originally added. As the issue is caused by accelerations when restarting physics, and those accelerations are proportional to velocity when leaving timewarp, and since people in RSS deal with much higher velocities without causing the issue, you're going to have to provide a save file with the minimum parts required to cause the issue reliably and as few mods as possible. Unless you're using a hacked version of KJR that removes physics easing those issues should not appear.

The CoL is supposed to point in that direction; it's pointing towards the rocket's top, correct? It's working in the same way that it would in the SPH with a plane, except instead of looking at the vehicle moving horizontally, it's moving vertically. That is not your issue, that looks fine and is intended behavior. Make the fairing a simple cone. Whatever dV you might lose by adding fairing weight will be offset by the fact that your rocket will be less likely to flip around during launch. Make the stages out of a single tank, not the many it seems you have now. You're adding unnecessary flexing into your design everywhere with those tanks. Replacing the 4 boosters with 2 larger ones might help, but last I saw you still don't have enough thrust. I'd instead take the redesigned fewer-part-but-same-size boosters you're going to make and use 6 of them; this will increase your TWR and increase your dV to balance out that added by the fairing, as well as decreasing the dV requirements overall since you won't waste dV just hovering above the pad. Frankly, the way this looks, your problem might not be that the rocket is unstable, but that it is too stable, combined with the low TWR. Since the rocket doesn't accelerate well, any deviation from pure vertical results in the rocket wanting to pitch over horribly. If that's the case, adding more thrust will fix the issue.