ratchet freak

try lowering the speed (mach in the bottom right) or switch to mach sweep, flaps should help you maintain lift at lower speeds. Once you are fast enough flaps don't help much.

@ferram4 A little checkbox that says "disable Flight Assist in vacuum" in the dialog would stop these little reports though.

That's looks like a cache issue, especially when an invalidation (moving a part and forcing a revoxel) "fixes" it. I'm talking about when you go to run the analysis while the background voxelizer thread is still busy. @ferram4's statement implied that the analysis code will pull incomplete data and try to analyze that even though that makes no sense to do.

As a possible quickfix: if voxelization/wingsetup is still going on, then delay the sim until it's done? Even after the overhaul that will probably be necessary. A few seconds extra delay right after manipulating a part is less of an issue than wrong sim output.

Redo the stability derivatives for the altitude and speed you were at. The ones in the screen shot are for surface flight and you were 18km up in the air.

It's pretty easy to swap out a battery.

it's a known event that no-one seems to be able to reliably reproduce. If you can reproduce it then detail exactly how you did it (include every single detail and the logs) so ferram can find what exactly goes wrong.

and it's licensed under GPL so you can release your own version (has to be also under GPL) I do suggest that then the name be changed to differentiate from the original.

right here ->

That's what a stable plane should do. Don't turn by yawing. If you want to turn you should bank in the direction you want to go and then pitch up. This way some of the lift is directed sideways and will shift your velocity vector.

in other words if you want to get reentry characteristics you'll need to turn it upside down. Maybe there should be an option for which stage of flight (Ascent and Reentry) the blue marker in the VAB is calculated for?

You can instead of going 1 by 1 is split the stuttering pack in half and check each half-pack for stutter. Then you can split the stuttering half-pack and repeat.

The OS will change which core the physics thread runs on to spread the load/heat generation This will result in all core's load being 100/number of cores percent.

Would it be possible to have a set of sliders (airspeed, pitch, bank, yaw, air density, etc.) to move the CoL indicator? This would allow a "simpler" visualization of how the plane would behave for those who can't figure out how to read the graph. For example if you set up the cruise configuration of a plane and you increase the speed then you would immediately see how that increased speed affects the aircraft. Then as an extra if you do an AoA analysis and you click on the graph the relevant parameters are selected and the CoL ball moves to show where the lift force ends up and how strong it is.

Nevermind it's under the tabs up top. Mouse over "Forum" and you can find it under "Guidelines"

When logging in the new forums you are presented with an updated ToS. However finding it again for re-reading is proving to be challenging. Where can I find it again.

[quote name='Hobbes Novakoff']So, dynamic loading eventually? My question is, what are you dynamically loading? The building interiors and such I see the point of, but planets and parts are going to always have to be loaded, as the game has no idea if a craft will appear out of nowhere the contains a part that isn't loaded yet, or if your craft will suddenly warp off to another planet.[/QUOTE] You don't need to keep the 4k height map, biomes and texture loaded for all planets (only the one you are orbiting), instead you can only keep a low res texture loaded for all bodies and only load the "details" of the planet when you enter the SoI, you don't even need to load the biomes unless there is a biome sensitive science part on the craft. And you can delay loading even that until the science happens. Same with parts; only keep a low poly model and low res texture loaded for all parts and only load the high res high poly when that part is on a craft that is appraoching. Crafts don't appear out of nowhere, you approach them quite slowly unless you are in very high timewarp, only when you switch to them from the tracking station is it suddenly needed but that's an opportunity for a small loading transition using a pan from that map screen to the craft to buy some time. [quote name='Keldor']Wouldn't the depth map be floating point in any remotely modern GPU implementation? In that case, doing a 1/z transformation is superfluous, since floats are pseudo-logarithmic in the first place and can cover a vast range without loosing precision for small numbers. Should be 3.4E-38 to 3.4E+38 for single precision, which is enough to cover both universe scale and subatomic scale in the same coordinate system. Since floating point is essentially scientific notation for computers, you get about 6-7 digits of precision at all scales. 1/z was common historically when depth buffers were integer, for what it's worth, though the reciprocal operation is expensive, or at least was back in the days where 1 TFlops wasn't the norm for mid-range GPUs.[/QUOTE] The depth stored in a depth buffer is often just an int (which gets rescaled to a 0-1 floating point in the shaders) unless you (explicitly) specify a floating point depth texture. BTW that should be the approach but I don't know if unity allows it.

struts, you need more of them

Why not a bonus to keep the satellite in orbit for a few years. Bonus should decay so you can't just do a few and then timewarp to infinite riches. Then you could a periodic contract to change its orbit slightly (to mimic orbital decay and station upkeep). Those (almost free) contracts would not show if the craft is ever not in the assigned orbit anymore.

eagerly awaiting the new stuff

You need higher landing gear further forward or a way to add upwards force at the nose (canards/seperatrons) to start your rotation.

they should stall before the main wing so the new CoL (after stalling the canards) is further back and will drop the nose so normal flight can be resumed

It's possible that you are not getting any drag due to a bug in FAR, update to the latest dev build or revert to a quicksave in orbit

that's because the CoL indicator is not coded properly in FAR and generally useless, you should instead rely on the graphs

maybe unlock steering on the front gear as well