nli2work

same thing happens with all the flags? or just the default KSP flag? post images of your unity shader inspector panel expanded, and the part heirarchy.

yeah, any mesh object can be used for flag decal. just give the part module appropriate name of the mesh object. you can test this by changing the "textureQuadName = flagTransform". just keep in mind the flag image is mapped to the entire UV space, this can lead to unexpected results depending on your UV layout; or you might use this to your advantage.

the back should be white I presume? the split down the middle b/w can appear as if by design. well, looking at the image and what you said I had two guesses. since it's not the first guess.. are you running real-time reflection mod as well? I doubt that's the issue, but the image looks like either a hole in the mesh, or the flag material is doing reflection. just to clarify, flag mesh should be a simple quad/plane, not a box or some other closed shape.

pre-contract agency flags work fine with KSP/Alpha/Cutoff shader; contract agency flags work with KSP/Alpha/Translucent(specular) shaders, but not always with Cutoff shader. in the part in the image, did you extrude a face on the main mesh and split it off to a flagDecal object? if so, it's because you left the hole behind it and you are seeing the back face of the other side of the part through the interior. Just cap the hole.

I misread earlier posts and thought you were using max as well. split the panels out to individual pieces and link them in a chain. then apply box/mesh collider to each panel in Unity. a collider that changes shape don't work in Unity AFAIK, and definitely don't work in KSP. There's nothing in KSP that has collider boxes that changes shape in Flight mode. the only ones that allows it are the mods I mentioned, and they only work in Editor mode where there's no physics. primitive colliders are very cheap, use those unless your panels are trapazoidal or 5+gon shaped. If you have 90+ colliders you might need to reconsider the design. but if I read correctly you have half a dozen total of few hundred triangles. not a performance issue. If the panels use box colliders that's less than 50 triangles total between 7 colliders, that's nothing really.

split the panels out to individual pieces and link them in a chain. skinned mesh colliders don't work in Unity AFAIK. I don't think blendshapes works for colliders either. Closest thing I've seen to what I think you are trying to do are the procedural wing/tank plugins like pWings by DYJ or B9. if you want a smooth unfurling motion you can animate them in max using spline IK or wire paramters, and bake the frames down, then apply box/mesh collider to each panel in Unity. You can use frame reduction in Unity to lighten up the animation clip a bit. or do it in Max before exporting.

it maybe the modules are set to the same layer. if they are, try setting them to separate layers. stock animations are on layer 0 IIRC from FS docs, so anything from 1 up.

you have 3 FSanimateGeneric modules in the config file, one for each animation clip? do the animations try to animate same objects in the part? what messages do you see in ALT-F2 when you attempt to trigger the animation? how the animation clips are created doesn't matter.

dockingNode has to be slightly outside of the collider box or the collider will prevent the two dockingNode transforms from reaching each other, and game tries to pull them together forever but never fully docks. or if your dockingNode is too far inside of collider, collider will prevent the node from getting close enough for the magnetic force to kick in at all, and it just looks as if the docking port doesn't work. I find the ideal way is place the dockingNode flush with the top of visible docking ring, and position the collider slightly below the visible mesh. when the port is docked, the visible mesh clips slightly into the other port so you don't have a tiny gap between them. there are some additional parameters you can adjust as well nodeTransformName = controlTransformName = undockEjectionForce = 10f; //how hard the base pushes the undocking vessel when undocking. Haven't tested. minDistanceToReEngage = 1f; //how far you have to back away before attempting to redock acquireRange = 0.5f; //how close before magnetic force kicks in between the ports acquireMinFwdDot = 0.7f; //the max forward angle between the two port's Z axis for acquireForce to kick in. cosine of the angle, 0.7 is roughly 45 degrees acquireMinRollDot = -3.40282347E+38f; //not sure, haven't tested. don't think it matters since you can dock in any roll angle acquireForce = 2f; //how strong the magnetic pull is acquireTorque = 2f; //how strong the force is attempting to align the docking port's Z to the target port's Z axis. captureRange = 0.06f; //how close the dockingNodes has to be before game considers them "Docked" captureMinFwdDot = 0.998f; //the max angle between the two ports when docked, cosine of the angle. 1 = cosine 0 degrees captureMinRollDot = -3.40282347E+38f; captureMaxRvel = 0.3f; //max rel. velocity to dock and not bounce off. referenceAttachNode = string.Empty; nodeType = //two ports of the same type can dock together, can be any string, not restricted to size0, 1, 2, etc. deployAnimationController = -1; // not sure what deployAnimationController parameters do. deployAnimationTarget = 1f;

I'll check my engine when I get home. It's same deal as yours. Works fine with AnimateGeneric for rotation and animateHeat for engine emissive IIRC. B9's light prop probably uses RPM's internalLight JSIGroupActionSwitch: https://github.com/Mihara/RasterPropMonitor/wiki/Prop-modules. You do need at least one prop in the IVA with RasterPropMonitor module or none of your RPM props will work. They all share alot of code from the RasterPropMonitor module. Stock code has an internal module for switching lights, but I'm not sure if it works. shows the part setup in Unity and relevant CFG bits. works as expected in 0.9

Unity 4.2.2 is the best version for KSP currently.

try splitting the emissive part to separate object, child it to the rotating part. Use two animation components, one on part that rotates, one on part that is emissive.

DOF leaves much to be desired... but it's tough without proper z-buffer pass

migration to Unity 5 is just a matter of time, and it will definitely be a worthwhile improvement for KSP. I'd like to see PartTools overhauled and fleshed out to support MechAnim, Shuriken, PBR. Additional tools to mod Kerbals Planets and Systems.

pulled the Mk3 cockpit from 0.9 and messed around with it in Unity 5. Additional maps were hacked from the existing Diffuse map and has a lot of room for improvement, at the cost of extra development time.

better comparison differences between Unity 4 and 5? Alot of rendering improvements. I only skimmed the change log. Most visible thing is the Standard Shader and realtime GI system. The editor is still familiar. If you know Unity 4 it's just a matter of seeing what's new. As far as relevant to KSP, it's hard to say. really depends on what Squad does with PartTools. Parttools 0.23 can probably work in Unity 5, you'll have to hack around the broken emissive animation, it's just too legacy for Unity to support and PartTools 0.23 doesn't support Animator component AFAIK. MechAnim is geared toward animating characters, setting animations for KSP type stuff like solar panels and lights can be more time consuming than with the legacy animation system. But MechAnim is easier to control through script when a controller is properly setup with parameters the scripts can use as triggers. Squad stands to gain a lot by switching the Kerbals to MechAnim.

Moving to Unity 5 is only a matter of time. KSP is still using animation and particles from Unity 3 judging by PartTools 0.23. PartTools will need a big overhaul to take advantage of the new stuff in Unity 4 and 5.

not much KSPing these days... but... did get a few hrs to play around with Unity 5. Get on it Squad!

external cameras are added as separate part. you see a blue cone indicating field of view. right click on the added camera and set it's ID # between 1~8 in VAB or after Launch. the one included with RPM should have a black dot indicating the up direction.

I checked each shader in the list on mk1-2 pod. the same thing occurs with all of them. maybe it's something the part module?

TRReflection module causes Airlock and Ladder to become surface attachable in Editor. Also causes Airlock to become unclickable in Flight, trapping kerbals in parts without IVA. no error messages in output_log.txt; tested with clean install with TextureReplacer 2.2.3 and ModuleManager 2.5.9, using sample module in readme file applied to stock Mk1-2 pod.

try removing TRReflection from the pods you are having problems with. does that change anything? apparently it's TRReflections. Removed that and my pods work as expected. added TRReflections to stock mk1-2 pod; and it's hatch exhibit same problems being surface attachable; and not clickable in Flight so kerbals are trapped inside if the part doesn't have IVA.

tagging Ladder and Airlock as something other than Ladders and Airlocks breaks them unfortunately. are you able to check the tags on MK3's cockpit hatch and ladders? I checked the layer with lo-fi's utility and they are set to 21. They are named Hatch1, 2, 3, and Airlock1, 2, 3. not sure what it is. Doesn't seem to happen with NovaPunch nor B9's pods.

It appears with 0.9, surface attach parts will detect and attach to trigger colliders set to layer 21 in VAB/SPH. This seems to happen only with mod parts exported with part tool 0.23, and not the new MK3 airlock and ladders. I tested with capsule colliders and box colliders tagged appropriately and set to layer 21, both are detected by surface attach parts. Otherwise they behave normally, same as before 0.9. I'm not sure if it's due to some new setting needed; or if PartTools 0.23 needing an update; or something else. See Ven's recent thread for images of the issue. http://forum.kerbalspaceprogram.com/threads/108445 command pods from NP and B9 seems normal in all respects.

hm... that's really odd. my parts do the same thing. Kerbals can walk through just fine, and they don't collide with terrain or other parts. but radial attach will attach to part trigger colliders. same if I change to a different collider type. Something changed with 0.9 and/or PartTools 0.23 apparently. Appears the colliders are still using layer 21. not sure what's different.