Cerbis

I had no reason to suspect FAR in this, as as far as I could see all other parts were correctly voxelized. If I encounter an issue I suspect is due to FAR, I'll make sure to investigate it thoroughly on my own first and submit as complete a report as I can. I know you get to deal with a lot of incomplete stuff, I lurk routinely in the FAR thread. I set aside some time today to do more tests, and it seems that even if the voxelization doesn't display correctly in the VAB, everything works as it should once the craft is actually loaded for a launch. I also identified how this happens in the VAB. 1. Place a pFairings base and give it a dimension, either with a payload or just setting dimensions yourself. 2. Place a fairing onto a fairing node, making sure to set the symmetry mode to only place one single section of the full fairing, as in my first screenshot. 3. Verify with the debug voxel view that the fairing section and anything within is correctly voxelized, as it should be. 4. Click the same fairing section to pull it off the fairing base, and while still holding it, change the symmetry mode to make it become a full fairing when reattached (from single to 2, 4 or higher symmetry). 5. Verify with the debug voxel view that the outer fairing is not voxelized in the VAB. 6. Save and reload the craft in the VAB. 7. Verify again with the debug voxel view that the fairing is now correctly voxelized. So in short; it doesn't cause any issues whatsoever for an actual launch and may just look odd in the VAB. Sorry if I caused any inconvenience!

NathanKell: Will Procedural Fairings pass the correct geometry to FAR if I cap the bottom with something, then? softweir: Exactly. I'm not sure what's going on there, but it sure isn't right. Playing around with it more, it seems that FAR occasionally 'sees' the correct fairing if the craft is reloaded in the VAB. Manipulating the fairing in any way usually makes it break again. This doesn't bode well for the flights themselves, if the geometry isn't read correctly when the craft is loaded for an actual launch.

I'm not sure if I missed anything in the thread, but I haven't been able to make Procedural Fairings 3.15 and FAR 0.15.5.7 understand each other. I can make FAR 'see' a procedural fairing as long as it's only one piece of the fairing, verified using the debug voxel mode. Here it is with the full fairing, seen from below. Note the missing voxels on the fairing itself, while the base has accurate voxels. And finally, a comparison with stock fairings. Is there some configuration I missed to make this work? I started from a clean KSP with updated versions of the mods. Are these mods simply no longer compatible?

@Lack: Ah, I missed that page when checking if anyone had mentioned it already, d'oh! And I can confirm that stock aero calculates from the folding wing part origin... at least, if that's right at the attachment point. Some aero forces for you; http://i.imgur.com/N9wgnBu.jpg Having folding wings is great, even if the mechanics don't quite match the visuals!

I was playing around with the foldable wings, and I couldn't get the deployment state to make a difference for the aerodynamics. All forces (gleaned from the aerodynamics overlay) seemed to be applied just the same to the attachment point of the part regardless of the wings being folded or not. This also had the effect of making the control surfaces very ineffective for rolling, as the game thought the control surfaces were right at the fuselage. Is this normal behaviour for stock aerodynamics? Is FAR a required/suggested mod for SXT?

Unless you backed up the entire Kerbal Space Program folder, you won't be able to run 1.0.2; GameData alone isn't enough. If you did back up the entire game directory though, you can just run the KSP.exe in the backup folder and it should work fine!

You could try to go into an orbit around the Sun in the game universe at the exact distance and speed that Kerbin orbits at. That would let you be free of Kerbin's gravity while still watching all the planets move with respect to Kerbin; Kerbin would stay at the same distance away from you. Alternatively, you could put yourself in any other orbit around the Sun, I'd suggest a closer one, so all the planets would move at different velocities compared to your craft. Inner planets would go faster than you, outer ones would go slower. If you want to just watch the planets spin, you can go into the Tracking Station, double-click on the Sun to change focus to it, and then use Timewarp to watch the planets go round and around!

Oh, I am most definitely nitpicking there, in the interest of completeness, and to make the point that even in the game you'll always be moving with respect to something else, no matter what you do! Indeed you cannot become stationary relative to every object in space, and I didn't think that's what the OP meant.

Sorry, there's no "parking" in space! In real life, gravity works over infinite distances. To put it simply; if there were only two objects in the universe, they would eventually fall towards each other. In Kerbal Space Program, it works a little bit differently (gravity is still functionally infinite as noted above) but not quite enough to make a difference. Being a video game, KSP has an internal coordinate system. Objects exist in set, discrete locations that are so tightly packed that you don't see the 'jump' from one spot to another as you travel, it all looks smooth to you. It would be possible to cancel out your velocity with respect to this coordinate system in the game engine... for a moment. The reason for that is that no matter where you are in the game world, you're always pulled on by gravity from some source. Even if you fly away from all other planets and bodies in the game, you'll always be under the influence of the Sun. All other objects around the Sun in the game also travel around it, so even if you cancel your velocity with respect to the coordinate system used internally by the game engine, you won't be going at 0 m/s compared to the planets, and you won't be able to stay stationary with respect to the coordinate system for very long either, as you'll be invariably pulled towards whatever you end up orbiting! So like with so many things in life, the answer is "Yes, and no, depending on how you look at it". But mostly "No"!

There is indeed no singular Tome of Lego Spaceflight available with concise and complete information for KSP, at least not quite yet. Scott Manley's tutorial guide goes over a LOT of what you might be interested in, but does take quite a bit of time to sit through. So! Here's a bunch of links that'll take less time to read! Old and with some spottiness of outdated information, but mostly applicable for the current version still. Has a few handy hints about the VAB/SPH too! https://www.reddit.com/r/KerbalSpaceProgram/comments/21dco6/things_you_may_not_have_known_about_playing_ksp/ To fill in a bit of my own knowledge about the VAB/SPH; Keys 1 through 4 will change the current tool you use. 1 is the regular part selector and placement tool, 2 is Offset, 3 is Rotate and 4 is changing root part. Enabling and disabling Angle Snap with the C key or the circle/hexagon button down to the left will also have an effect on the Offset and Rotate tools, making it so that changing offset and rotation happens in discrete steps rather than smoothly. Really helps for tweaking craft just the way you want them. Pressing the F key with the Offset and Rotate tools will change the reference orientation for the tools. These tools are very handy for pointing parts in the right direction, especially aircraft engines and wings! Entropius of these very forums put together a beautiful, illustrated guide for getting to other objects in orbit. It's also applicable to getting to other planets; the principle is pretty much identical, with only the scale being different! http://forum.kerbalspaceprogram.com/threads/92480-Illustrated-Tutorial-for-Orbital-Rendezvous keptin, also of these forums, drew up a lengthy and rather comprehensive tutorial on the principles of aircraft design. This will really help with making things that fly straight! http://forum.kerbalspaceprogram.com/threads/52080-Basic-Aircraft-Design-Explained-Simply-With-Pictures There's also a number of mods that help with designing spacecraft, such as Kerbal Engineer Redux, but seeing as you've lurked around for a while I'm sure you're already familiar with it! As for aircraft behaving strangely, there are to my knowledge still a few small details that make aircraft not perfectly symmetrical with respect to the air that can cause drift. Trim (Alt+WASDQE) will help with that, as noted in the Reddit link. Edit: I just remembered another detail with the SPH in particular I haven't seen mentioned anywhere. Your placement of the craft inside the SPH will actually change where on the runway it appears. There is a center line in the SPH that will match the center line of the actual runway out in the world. This generally doesn't matter, as your aircraft will still point straight down the runway at default orientation, but it's there. I hope this helps!

"Funds". That's it, and it is indeed a square root symbol that's got a few extra bits on it for stylization.

You're absolutely right, but the rocket still went further in 1.0.1 than 0.9 despite the dV difference! That's the main thing to take away from it.

I was aware of that, but I have no idea how to change the modules for a true apples-to-apples comparison. Even then, the power and efficiency goes up quickly with even a little altitude, so the error isn't quite as large as it seems. If you, or someone else, know how to change the values, that would be better than what I did. What we can assume though is that the new aerodynamics are more lenient overall than 0.9 stock, as flat/improved power and specific impulse will only make the rocket go further still.

I did some back-and-forth testing of the aerodynamics and came up with some numbers. Sadly I didn't manage to get a copy of 1.0 saved away to test in. The rocket was built in Sandbox mode with, top to bottom: Mk16 parachute, Mk1 Command Pod with a Pilot Kerbal, 1.25m separator, FL-T800 fuel tank fully fueled, LV-T45 engine set at 51% max throttle and kept there for the entire duration of the launch. SAS was enabled on the launchpad prior to ignition and the rocket was kept pointing straight up until the fuel ran out, at which point I recorded the following values. 0.9 with latest compatible version of NEAR: Flame-out at 83,566m. Final apoapsis 351,074m 0.9 stock Flame-out at 35,434m. Final apoapsis 90-ish km 1.0.1 stock Flame-out at 45,626m. Final apoapsis 141,060m As we can see, the new-new aerodynamics are still slightly more lenient than the old stock aerodynamics, probably owing to drag occlusion alongside a more "old-stock" like amount of drag. Having played with FAR/NEAR for a long time, I very much enjoyed the 1.0 aerodynamics and its lower amount of drag, but I can understand these changes if the goal is to have aerodynamics like old-stock with more realistic behaviour.

I feel that the increased drag overall in 1.0.1 is a step down from 1.0. I did some back and forth testing between 1.0.1, 0.9 with stock aerodynamics and with the latest 0.9-compatible version of NEAR, and the worst performance was with 1.0.1. Of course, I played nearly exclusively with NEAR so the decreased drag of stock 1.0 compared to previous versions suited me just fine, but with 1.0.1 the drag feels heavier than in even 0.9 stock! For me, 1.0 was just right.

What kind of bad things could I expect? What if the craft is stationary or not in atmosphere while the switching is occuring? I admit to not really having understood most of the FAR source, yet.

I'm planning out a mod and I'm wondering how FAR/NEAR would react to having the properties of a wing, e.g. lift and drag, change while a craft is loaded and in flight. Would it even be possible for FAR/NEAR?