a.g.

Some points: First, according to the laws of physics, the point of application of a force can be moved to anywhere along the line of the force without any change in the effect. The indicator chooses the point that is closest to the center of the vessel. Second, the indicator is actually representing the derivative of the force and torque, not the plain value. Specifically, the arrow represents the derivative of the force, and the position is chosen so that this change in the force, if applied there, would cause the right change in torque. When the linear force change becomes very low, the lever arm to produce the necessary torque grows a lot.

I'll try commenting out bits of the code sequence tomorrow to see if any specific action is responsible.

It all happens in a perfectly ordinary OnGUI callback.

The HUD is actually mostly completely ordinary unity GUI code, but you can't draw an image rotated while clipping it to a straight rectangle using GUI.DrawTextureWithTexCoords, so it actually does it by manually rendering a straight quad, but transforming the texture coordinates to rotate the image: HUD_ladder.LoadImage(arrBytes); HUD_ladder.wrapMode = TextureWrapMode.Clamp; HUD_ladder_mat = new Material(Shader.Find("Hidden/Internal-GUITexture")); HUD_ladder_mat.mainTexture = Resources.HUD_ladder; Resources.HUD_ladder_mat.SetPass(0); } // Direct drawing calls to get full control over texture coords GL.Begin(GL.QUADS); GL.Color(GUI.color * 0.5f); // the shader appears to multiply by 2 for some reason GL.TexCoord(mat.MultiplyPoint3x4(new Vector3(-xsize, ysize, 0))); GL.Vertex3(area.xMin, area.yMin, 0.1f); GL.TexCoord(mat.MultiplyPoint3x4(new Vector3(xsize, ysize, 0))); GL.Vertex3(area.xMax, area.yMin, 0.1f); GL.TexCoord(mat.MultiplyPoint3x4(new Vector3(xsize, -ysize, 0))); GL.Vertex3(area.xMax, area.yMax, 0.1f); GL.TexCoord(mat.MultiplyPoint3x4(new Vector3(-xsize, -ysize, 0))); GL.Vertex3(area.xMin, area.yMax, 0.1f); GL.End(); I actually came up with this hack, and it appeared to work perfectly fine until I installed the clouds. Re cameras, I wouldn't even know where to start P.S. Note also that I'm on linux and already had to disable the bump map textures to avoid the issue already reported a few pages before.

Hm, I noticed some weird interaction with Steam Gauges beta HUD: for some reason when it is active, the clouds render differently. Any idea why? One clue may be that part of the HUD is rendered using materials and direct GL calls as a workaround for a certain unity GUI limitation.

Linear is movement, angular is rotation. And yes, except for decoupler and launch clamp reinforcement, it just replaces stock connection joints with custom configured ones.

I've seen that reported as a problem with stock as well somewhere in the support forum, and could reproduce it myself, so it might be some problem with the physics engine itself. One thing I noticed when observing it in slow motion at that time was that the wobble appeared to start with some of the heavy tanks twisting around the truss used to attach them, so the root of the problem may be in the angular motion. The Dynamic Warp mod is useful for observing how things happen frame by frame.

Note that the static analysis graphs in VAB are still computed as if the wind is coming from the door like in SPH. Also, the graphs ignore Cm and Cd when selecting the vertical scale, since they are intended for planes which tend to have more lift than drag. After fixing that and some other discrepancies, I got the static graphs agree even better with the in-flight behavior for that gliding rockets effect. In the flight scene it's possible to see how lift and drag force centers are exactly opposite each other relative to CoM and thus precisely balance each other's torque. It's not for me to say if the existence of this particular stable flight mode is realistic.

This is the same open attach node effect: basically, the open nozzle creates a lot of drag, which pushes the craft off-center; but the center of mass is very close to the engine, so the body of the craft acts to counteract this, and at a certain deviation it is stable with almost 1 L/D. Putting a nose cone on the engine completely eliminates this effect. If this is wrong, it might be a problem with how the drag from open nodes is computed.

Landing gears that use the stock module don't actually exist physically, so they can't have any mass or drag. All parts are modelled as basically a cylinder or cone segment, so the most important part is that FAR gets the axis orientation right. All stock parts are aligned so that their main axis is vertical when the part is displayed in VAB menu; if that is not correct for a part, it may cause problems unless some heuristics in FAR (based on attach nodes or intake direction) manage to correct for it.

It seems this may be because of attach node drag. Note how it has two stable equilibrium points at +-25 degrees AoA, but once I cap off the engine, it turns into one stable position at engine forward. Capping of the other end improves stability even more.

What's on top of that thing? It is hard to see due to re-entry effects.

Parts from kerbal engineer and a number of other mods have insanely low mass: 0.000001 for engineer. Personally, if you are going to make a part with such low mass and zero drag, I don't see why not make it non-physical altogether and be done with it.

Won't that send various other craft in KSC flying due to pre-existing internal stress and compressed wheel suspensions, like it often does when you hack gravity? Now, if it was possible to disable gravity just for one craft...

That suggests broken Module Manager to me.

Unless I'm much mistaken, a vessel can only have one root part, so when two crafts dock, it has to reshuffle hierarchy to make one of the vessels a child of the other. During this process it would obviously have to change parent links, and possibly re-create the joints, overwriting the ones you create; so you may need to re-run your code after a docking or undocking happens.

Did you test how this interacts with docking and undocking, especially on complicated stations with multiple modules and docking ports? I think the known bug with octagonal struts and docking ports is because the game reshuffles part hierarchy and joints when docking happens, and messes up with nonphysical parts. It may also kill the improved joints.

Is there any guide what each of the stability derivatives mean in practical terms, and how to fix it when the sign is wrong? For instance, why does this craft have persistent Xw problems?

The reason it crashes with FAR is that the efficiency value becomes infinite due to zero stock drag, and this loop runs over the end of the array. To fix it is necessary to reduce the max iteration count by one, so it stops at the last array item no matter what: // Loop through the notations until the smallest usable one is found. - for (notationIndex = 0; notationIndex < notation.Length; notationIndex++) + for (notationIndex = 0; notationIndex < notation.Length-1; notationIndex++)

Does the same fuel in the same orbit mean the same dV left? If you consider the overall mission difficulty rather than just getting to orbit, it probably should take into account the scaling of vacuum ISP by allowing an appropriate percentage of additional mass into orbit. What I'm looking for actually is some kind of hybrid setting, i.e. some values that reduce vacuum isp less, but don't reduce atmospheric efficiency as much, while providing an overall stock-like level of difficulty. Currently I have it set to 0.6 atm, 0.9 vacuum, thrust scaling on. The low thrust of liquid engines does make using atm-rated SRBs at liftoff more essential, so I think it might count as reducing the average isp of the first stage even more.

What is the proportion curve for balancing the change in atmospheric and space ISP for the "FAR to stock" difficulty setting idea? For instance, does 0.6 atm 0.9 space produce the same difficulty, or are the numbers off? Also, I wonder how enabling the thrust scaling feature affects the "difficulty" in this context.

The problem is that the executable contains a statically linked copy of libpng, which for some inexplicable reason includes a chunk of 32-bit MMX inline assembly code, which quite understandably crashes as soon as it happens to see a pointer that is not within the first 2GB. The patch makes the check for MMX fail, so the junk code doesn't get called.

This plugin appears to be compiled for NET 4.5 or something like that, but Unity only supports 3.5, so it constantly spams the Player.log with messages about there being no System.String::IsNullOrWhiteSpace. I had to remove that call and recompile it with the proper target.

Can you add a control to change the number of conic patches, in addition to the current choice of the display mode? This is also a parameter that you might want to keep at the default normally to avoid clutter, but increase when planning some maneuvers.

Speaking of jet engines, they have huge isp, but it won't make sense for them to be rated for vacuum. Solid boosters also are used on the low stages, and the default cutoff values seem to ignore the starting level SRB.