nli2work

yeah definitely look like a pickle here... I'd go with 2. a bit of a compromise now, but room for expansion in the future

Oh I see what you are doing, just watched the video on 0-point fairings. you could use a separator for the base, and a normal decoupler for the top no? isOmniDecoupler = true; that will make a decoupler separate from the payload and the lower stage at the same time. then a 2nd decoupler module for the top to pop the cone off.

maybe use module jettison? or split out the fairing cone into sections like KW does?

here's what I deciphered from Lo-fi's rig. the 2ndary wheelColliderR moves a LookAt Target for the main beam that holds the two sets of wheels. the main wheelCollider does all the visual work of suspension and spinning the wheels. wheelColliderR has longer suspension and very light spring, when it hits the ground, it moves the LookAt Target up; and the main beam will rotate to look at the target, and rotates both sets of wheels about it's pivot, front set down, rear set up. then the main wheelCollider hits the ground, and that compresses the suspension piston and all the torque arms that are driven by the main compression action.

CTRL-6 to bring up Unity Console when you export. if any errors in there, whatever MU got exported, if any, probably won't work in KSP. if that's all clear; then check the output_log.txt. search for the part you just made (naming the MU to something descriptive comes in handy here), and see what log messages are associated with it.

you mean IVA? that's in progress. almost through with all the props. after that it's configuring the MFDs.

I'm gonna hazzard a guess, you need two suspensionParent objects? two different wheelColliders fighting over control of 1 suspensionParent probably does strange things.

I think your maps are working correctly and the indent/outdent flip is just optical illusion. compare these two maps; I only inverted the Green channel; all else are the same. lower right corner is green channel of the normal map; left two are screencaps from Unity viewport and VAB. http://i.imgur.com/m7NfCiN.jpg vs http://i.imgur.com/0KSqEA8.jpg

if you just need the DLL, always download from here: http://snjo.github.io/; the button "Download plugin". the plugin has been updated to 0.25 for a while now. snjo simply didn't have the time to change the OP.

no importer for max. you need blender 2.72 and MU importer/exporter plugin.

interesting... can you send me the normal map when you get some time?

that looks correct, the round corner rectangle areas appear to be indented consistently

they look that way because that's how Unity handles normal maps. don't worry about the gray look, it's still a normal map as far as Unity is concerned. import your tangent space (blue looking) normal map into Unity, in the texture inspector panel set it to "Normal Map" and that's all you need to do. If it looks inverted Up/Down in game, open the original (in Unity assets or the original original), and invert the Green channel (95% of the time). If it looks inverted Left/Right in game, invert the Red channel. export the maps as normal and things should look right in game. You do want to add "_NRM" to the end of your normal maps file name for correct handling by KSP and ATM if you have it installed. if you care about the technicalities Standard Tangent Space normal map records XYZ in RGB channels. Generally 255-R = +X; 255-G = +Y; 255-B = +Z. some programs inverts Y direction for whatever reason. Unity uses a slightly different way of handling Normal maps since DTX compression doesn't treat standard tangent space maps well. X is recorded in R, and duplicated into G and B channels; Y is recorded in Alpha channel. the graphics engine combines the map's X (RGB) and Y(A) with the mesh's Normal vector to get the final look for each pixel.

I don't know... everything works okay when I export them here. no error in the logs either.

I'm as stumped as you are... it's a long shot but send me the ksp parts w/ configs (original and new). maybe something in the logs. so far the only difference between our two setups is unity version, and I'm pretty sure you are no the only one using 4.5.2 to make IVAs.

your layers and settings all look in order, I didn't change anything at all. exported skylab and IVA, everything works fine. gonna send you the exported part and configs. nothing I can see on Unity side that would cause the behavior you have. maybe something with the configs? I have no idea. Maybe problem with Unity version? I exported with 4.2.2

taking a look. it's probably something simple we over looked. which version are the blender files from? 2.72?... okay looks like things are importing okay.

the internal gets left behind when the ship starts to move correct? if internal is attached to the vessel, then it's a matter of figuring out the correct orientation in Unity, that could take a little trial and error. if internal is left behind after you've added the layers and set the objects to the correct layers then I don't know. are you able to spawn the internal through part tools panel? do the external and internal line up correctly when you have their top level parent objects at 0,0,0; 0,0,0; 1,1,1? if you've checked all those and they fit correctly then I can't really say. I'll have to look at the unity project.

you have to name the layers too. "Internal Space" - 20; and "Kerbals" - 16 all IVA objects must be on one of those layers, not just the parent. easiest thing is select the top level object (one with parttools script), change the layer, and click add child objects in the window that pops up.

Squad's SPP standard and inline cockpits share the same IVA. link to the RPM internal config in post #1443

Spanner's right re. TransparentPod module as well, I didn't mention it since it didn't look like your IVA was using it. Pods without JSITransparentPod will have their IVA displaced outside when in the vicinity of a Pod with JSITransparentPod. JSI includes MM patch that applies JSINonTransparentPod module too Pods that do not have TransparentPod to prevent this from happening accidentally. this is all because of the strange way Squad decided to orient the Internals relative to the Externals.

new cockpit is excellent!

looks like the internal is not on Internalspace or Kerbals layer. if not set to any layers the internal will spawn at the center of launch pad, I made that mistake more than my fingers and toes can count.

B9 uses ResGen plugin as the converter module. converter takes ElectricCharge and IntakeAir as inputs; and outputs B9CompressedAir resource. I would start by copying the Air RCS block config and change the ResGen module's inputs to something like LiquidFuel and IntakeAir; leaving rest the same, and see if it behaves as expected. change one thing at a time and see what happens, whether's what you expect or not. ALT-F11 brings up ModuleManager's database reloader, I recommend using this one. ALT-F12 brings up Squad's database reloader;

I think Dragon01 is referring to the invisible meshes you use to reinforce joints, they would be perpendicular to airflow and potentially creating massive drag (similar to the folding MW array from Interstellar generated massive drag unless in a fairing). Wing/Nacelle combined part probably isn't too big a problem since you will need to specify explicit FARDragModel values for it.