a.g.

Adding this here in case it helps somebody searching for this in the future: dumping the actual message object contents to the log shows that messages apparently recognize some HTML tags, so for instance this works to produce orange italic text: ScreenMessages.PostScreenMessage( "<color=#ff9900ff>["+part.partInfo.title+"] <i>"+subject.title+":</i> Container Full.</color>", 10f, ScreenMessageStyle.UPPER_LEFT ); P.S. Interestingly, these dumped messages also appear colored etc in the in-game debug log viewer window, so this may be some obscure feature of unity GUI controls in general.

Lvl has nothing to do with prograde or anything, it stops the plane rolling and thus turning left or right.

I only just got around to testing Kerbals in seats, and they are really wobbly. With debug output it's obvious why: for whatever reason it cannot compute the size, so all strength values end up as zero. A good workaround is to add KerbalEVA to exemptModuleType list.

Check the log for messages: maybe something is crashing or something.

As I mentioned in an adjacent thread, there actually is one place in the current game where time warp already isn't an option: flying planes and driving rovers (4x warp isn't really significant). Currently this activity doesn't have any real in-game purpose to it, so generating a small amount of science over time when in motion may provide additional reward.

The curious thing here is what's the difference between stock parachutes and those, since the code doesn't appear to do anything special for parachutes. Before 0.11 parachutes were just ignored altogether and left stock. Another small detail, is that I suspect that setting stowed drag to 0 in the MM cfg may not completely neutralise the stock drag because there is also the default 0.1 drag for the part itself, but I'm not sure. It's probably similar to intake drag.

One special case here is that you can't use non-physical timewarp when flying a plane or driving a rover. This means that this counter-argument doesn't apply to some kind of 'aerial/ground survey' module that provides a trickle of science while active in a moving craft on the ground or in atmosphere, and it will provide more meaning to planes and rovers.

Since it wasn't mentioned in the release announcement, here is how mouse input actually works. The feature was inspired by the Mouse Drive mod (and the fact that SAS doesn't work too well with FAR, so you want some kind of precise analog input for things like landing); however there are large differences in the interface. The general points are: In order to enable mouse input it is necessary to activate the relevant option, and lock window positions so that dragging the mouse won't move the HUD window instead. In the options you can also switch whether the input would affect Pitch+Roll (airplane) or Pitch+Yaw (rocket mode). The general metaphor is that you grab the "--W--" thing in the center with the mouse and drag it in the direction where you want it to go. The actual sensitive area where the drag can start is significantly larger, but the current input value is always calculated from the relative position of the cursor to the center indicator. Since KSP interface is based on clicking and right-clicking buttons and things on the screen, I thought that the press and drag mode of operation is less confusing than the stateful toggle mode Mouse Drive is using. It also means that there is no need to suddenly disable input when the mouse leaves the 'proper' area; it can just be clamped to 100%. The feature is aimed at smooth high-precision input, so there is a large dead zone, and sensitivity is nonlinear, with significantly more precision near zero. When mouse input activates, a mark appears to show how the horizontal and vertical dead zone stripes meet in the center. If you hold right Ctrl when pressing the mouse down, the Pitch+Yaw vs Pitch+Roll choice is temporarily reversed until you release the mouse. If you hold the modifier key (Left Alt or right Shift depending on os) as you release the mouse, the input is added to trim instead of simply being reset to zero. This trim feature allows easily releasing active control after guiding the plane into a stable mode. Since SAS only reacts to actual user input as implemented by stock, and othewise suppresses any control input from plugin hooks, when it is active the mouse input switches to a different mode where it directly controls the orientation SAS tries to hold. A mark showing the current value of that orientation appears, and moving the mouse adjusts it on a rate of turn basis. When mouse input is enabled, a minimized form of HUD appears on all screens where HUD is not normally shown like map mode. In the passive state it consists only of the mouse input dead-zone crosshair, and pressing the mouse down directly over it activates mouse input and shows the pitch ladder and vectors. Setting HUD alpha to zero using the slider forces this minimized mode everywhere. The minimized mode HUD is always locked and cannot be moved. Also, as another aid for landing at a specific spot, when you target a landed object, like for instance a flag you planted at the runway, the targeting data displayed by HUD is now computed differently based on surface speed, latitude, longitude and heading data (these are always valid for landed objects, unlike orbits which often don't make any sense). Relative inclination is actually difference in current and target heading, and closest approach is sea-level distance ignoring altitude of both objects.

The backspace key resets the camera position, but for some reason Squad also binds it to the abort action group by default. I personally assign abort to the big Enter key instead.

The way SAS is currently implemented, it only takes into account the actual user input, and overrides any input added by code that is before it in the callback list.

These values are not 'rebuilt', they carry on between frames and it is critical for correct operation. The stall value is stateful by definition in order to provide the hysteresis property of stall, and the increment variable relies on the adjacent frames being pretty similar to each other to avoid the issue of the undefined order in which the parts are processed. This means however that you must run at least two passes of computation in order to compute the effect of wing interaction correctly (see CoL code), and you also must call computations exactly once per part every pass or you'd effectively apply the interaction effect multiple times. The original code for computing a sample for the graphs in the editor was basically something like: Which produced completely incorrect (as in completely different from in-flight behavior) Cm graphs when flaps were deployed. All that was needed to fix that particular issue was to change it to:

I said (or meant) that I was doing some patches to fix stuff in editor like CoL and graphs, which was broken in part due to not handling these specific stateful interactions properly, and thus I know what I'm talking about here. Most of the changes are already in v0.10. To me it seems all around simpler if the pitch/yaw/roll surfaces just returned to neutral when atmospheric density dropped to zero and remained there. After all, the whole point is what are they moving for if there is no air. Flaps and spoilers are separately controllable, so they should follow these commands as usual.

Your code will affect the stall state of the control surface, and the interaction coefficients used for applying actual forces to the surface and the wing it is attached to. Until you do something with ClIncrementFromRear and stall, you cannot call any of that stuff in flight. Also, through that very change in ClIncrementFromRear on the wing, the effect of deflecting the surface is amplified to an extent dependent on the size difference.

I already sent a fix for that to Ferram. The root problem seems to be that something in the stock KSP loading code chokes fatally on public const fields in some circumstances, and the controllable surface class has one.

Check for any errors in the message log. KJR also produces detailed messages if you set the debug parameter in its config file to 1.

It seems it also solved the HUD interaction issue. What probably was happening actually is that because of the uninitialized tangents, the attribute value in the shader became whatever stateful garbage was in the opengl state before, so the texture coordinate changes done by HUD code ended up affecting the value.

It replaces every default 'fixed joint' which has its properties in a black box and mostly but not quite does the right thing, with a joint with manually configured parameters based on part size and whatnot. For decouplers and launch clamps it does also create 'invisible struts' that span the decoupler and connect parts on either side to each other, as a workaround for the issue of a tiny light decoupler connecting big heavy tanks.

Another thing is that I downloaded the part from here, and the picture I see is quite different. Now, the change in the graphs is likely due to some fixes I didn't send to Ferram in time for the release. However, the CoM location & mass is also different for some reason.

It shows the change in both the total aerodynamic force and total torque if AoA is increasing, with the directions immediately obvious, and the proportion between force and torque implied from the lever arm to the center of mass. For planes with actual non-stalled wings this indicator should give the conventional Center of Lift location, which due to some aerodynamic laws related to wings doesn't move much and provides guidance for stability. When you get into nonlinear drag interactions, it does act weird sometimes, but then you don't exactly have any conventional lift there. And before you complain about the use of derivatives: that's actually how the FAR CoL indicator always worked; the only thing that changed is that instead of hoping that the stock CoL code will add up the data correctly (which it doesn't), it now computes everything itself and feeds just the final result to the stock code.

Looking at the compiled files for your shaders on github, they appear to do lots of stuff with the tangent attribute of a vertex; however your code does not initialize the mesh tangents anywhere. This might not be the cause of this particular issue, but it can't be good.

Anything in the erorr log? Also, try launching and immediately reverting to editor when that happens - I had a similar issue before KJR even existed, and that workaround helps with it.

OK, I did some experiments with the weird interaction between steam gauges and the clouds, and it turns out that the issue is somehow caused by the lines setting texture coordinates: GL.TexCoord(mat.MultiplyPoint3x4(new Vector3(-xsize, ysize, 0))); Commenting just those lines out, while obviously breaking the rendering of the relevant part of the HUD, also removes the effect on clouds. This suggests to me that perhaps your shader may be using some uninitialized texture (or texture coordinate) data or something; that would be the natural conclusion if all this was just plain OpenGL programming anyway. Also, when looking at this from space, it is now obvious that the actual effect is to remove the fade-out of the clouds near the horizon, so they become visible over the space background:

However you forgot sin(angle), so the effective arm is exactly the same.

Hint: T = (R + c*F) x F = R x F + c * (F x F) = R x F for any scalar c. The first-order derivative of force and torque by angle of attack. Because by definion the aerodynamic center is more or less the location where the derivative of the pitching moment by angle of attack is zero. Now, I'm very shaky on all of the specifically aerodynamic stuff, but I interpreted that as the location of basically the torque-free resultant location, only operating on the derivatives instead of the forces. Note here that generally the derivative of the torque of a number of forces is the same as the 'torque' of the derivatives of forces, provided the points of application are constant; the analogy is also correct if locations change, but you are going to use finite-difference approximation for everything anyway. P.S. What I see likely happening in your screenshot, is that the total force only slightly increases to the right with AoA increase; however, its center of application moves relative to the center of mass to produce notable change in torque. This is equivalent to an equivalent increase in force applied way outside of the bounds of the craft. I expect if you tilt the craft more, the direction and location of the arrow actually flips around.

Remove all bump_texture nodes from cloudLayers.cfg - this seems to be a common issue.