nli2work

you can use RPM plugin to do this. I don't think stock internal module allows translation based on throttle, at least not when I tried it a while back. but things might have changed.

you have to save out the internal config via PartTools, reload the config again. Props are spawned in to into Unity scene and not updated, side effect is your scenes for internals can get huge due to the # of props saved.

The wear looks too uniform. I would spend some extra polies to chamfer the cog teeth, then make an edge mask to concentrate the wear on the leading edges of the cog. edge mask is easy to do in PS with the UV guides or other 3d painting software.

you got it there. look at the right side (Inspector Panel) in the second image... the last section is the material properties. Some call it "shader" some call it "material"; same thing. you drop the texture into appropriate slots or channels in the shader that's applied to the mesh _MainTex is your color RGB channel; "Color"; "Diffuse"; "Albedo"... generally the same. This is typically the most basic shader you use. The RGB (spec (A)) tells you it's using RGB for colors; and Alpha channel to control Specular intensity (below). _Bump is used make the surface appear to have some texture. in games it's generally a Normal map, blue/red/green looking map. You can feed it a b/w map, it's probably converted to a Normal map internally. depending on how teh shader is built, you can feed it separate map for Specular (simulated shine on polished surfaces); or use the alpha channel from another texture like RGB (spec (A) above. Specular is a strange beast, it simulates reflection that's in all real world surfaces. It can have 3 aspects, intensity, color, and Shininess (spread), depending on the shader. Intensity is strength of the high light; color changes the color, but the color value interacts with Intensity. Shininess determines whether the highlight has a sharp edge or a soft fall off to diffuse color. Basic last gen (Xbox 360/PS3) shaders has the above 3 components. Additional channels can control Self Illumination; "glow"; "emissive"; same names; and Reflection either baked or real time. Physical Based Rendering is the current thing and is pretty different beast since it changes the whole rendering system, we expect/hope KSP with Unity 5 to support that.

No one knows except for Squad.

check the part's materials, make sure there're no missing textures.

Yes, for sure. I should have specified that earlier. The Unitypackages are just the source files, using the parts falls under "unmodified". I think many of the parts need quite a bit of fiddling to get functional in 1.x. If you mean the "missing Monobehaviour" on the root object, that's the KSP export script. I think it happens because the packages are exported from different projects. Should be fine if you reassign the PartTool script or remake the PartTool component.

that's really weird... I don't know what might cause the FBX to blow up when imported to blender to be honest. The FBX were exported from 3dsmax, that may have something to do with it. best suggestion I have is try recreating the animation in Unity instead of what came in the FBX. The pivots are in the correct places so no need to add extra gameobjects in Unity.

here's one, I added curves on the Emit and Max Energy attributes, from 4.2.2 %YAML 1.1 %TAG !u! tag:unity3d.com,2011: --- !u!74 &7400000 AnimationClip: m_ObjectHideFlags: 0 m_PrefabParentObject: {fileID: 0} m_PrefabInternal: {fileID: 0} m_Name: particleCurve serializedVersion: 3 m_AnimationType: 1 m_Compressed: 0 m_RotationCurves: [] m_CompressedRotationCurves: [] m_PositionCurves: [] m_ScaleCurves: [] m_FloatCurves: - curve: serializedVersion: 2 m_Curve: - time: 0 value: 0 inSlope: 6 outSlope: 6 tangentMode: 10 - time: .166666672 value: 1 inSlope: 6 outSlope: 6 tangentMode: 10 m_PreInfinity: 2 m_PostInfinity: 2 attribute: emit path: classID: 114 script: {fileID: -1272454729, guid: a1b1dd47b2bfcd04ba9203ca055053c4, type: 3} - curve: serializedVersion: 2 m_Curve: - time: 0 value: 3 inSlope: 21 outSlope: 21 tangentMode: 10 - time: .333333343 value: 10 inSlope: 21 outSlope: 21 tangentMode: 10 m_PreInfinity: 2 m_PostInfinity: 2 attribute: maxEnergy path: classID: 114 script: {fileID: -1272454729, guid: a1b1dd47b2bfcd04ba9203ca055053c4, type: 3} m_SampleRate: 60 m_WrapMode: 0 m_Bounds: m_Center: {x: 0, y: 0, z: 0} m_Extent: {x: 0, y: 0, z: 0} m_MuscleClipInfo: m_StartTime: 0 m_StopTime: 1 m_OrientationOffsetY: 0 m_Level: 0 m_CycleOffset: 0 m_LoopBlend: 0 m_LoopBlendOrientation: 0 m_LoopBlendPositionY: 0 m_LoopBlendPositionXZ: 0 m_KeepOriginalOrientation: 0 m_KeepOriginalPositionY: 1 m_KeepOriginalPositionXZ: 0 m_HeightFromFeet: 0 m_Mirror: 0 m_EditorCurves: - curve: serializedVersion: 2 m_Curve: - time: 0 value: 0 inSlope: 6 outSlope: 6 tangentMode: 10 - time: .166666672 value: 1 inSlope: 6 outSlope: 6 tangentMode: 10 m_PreInfinity: 2 m_PostInfinity: 2 attribute: emit path: classID: 114 script: {fileID: -1272454729, guid: a1b1dd47b2bfcd04ba9203ca055053c4, type: 3} - curve: serializedVersion: 2 m_Curve: - time: 0 value: 3 inSlope: 21 outSlope: 21 tangentMode: 10 - time: .333333343 value: 10 inSlope: 21 outSlope: 21 tangentMode: 10 m_PreInfinity: 2 m_PostInfinity: 2 attribute: maxEnergy path: classID: 114 script: {fileID: -1272454729, guid: a1b1dd47b2bfcd04ba9203ca055053c4, type: 3} m_EulerEditorCurves: [] m_Events: []

Very Interesting. I didn't know that, never tried it that way either. I'll take a look when I get back home from wokr.

I think you got it mixed up. KSP Particles are exported as separate MU files, it's essentially an empty game object with a particle emitter. They are spawned and attached at run time in KSP and values manipulated through part modules in the part config file, usually engines, or RCS with RCSFX plugin. you never animate any values of an emitter in a animation clip. Doing so will most likely cause an error when you attempt to export the part.

Unity's shuriken particle system won't work in KSP at the moment. You have to use KSP particle. After Unity 5 part tools that might change. KSP Particle is really the unity legacy particle system settings collected in one place. My engine tutorial covers some of KSP Particle tool. It should still apply since PartTools haven't changed so far with KSP 1.x.

Looked closely at your original blend file, my best guess regarding cause is the bone scaling at the retracted position caused the vert loops at the rim to cross or get too close, as result the normals averging in that situation gave you the odd falloff to black. splitting the smoothing group (max speak), creasing the edge? in blender might have been an easier solution. I'm only a noob with blender so can't say for sure.

more added in FP

if it's a seam in the UVs, add few pixels of bleed around the UV island; 3 to 6 pixels should be good. Setting the background color of the texture close to the main color of your color scheme can help in some cases as well.;

I'd ditch the bones that you move and scale. Bind (Armature modifier in blender) the dish mesh to the arms directly (use bone for each arm if blender doesn't allow skin bind to other mesh objects) and animate the arms like you already have. use bind weights to fix any interpenetration in the antenna mesh.

added Command Pods in FP

Hi all, haven't been doing much KSP modding for a while, don't think I will be doing more in the foreseeable future. Still have assets from Transparent Pods and RetroFuture projects. I figured I'd share them here for everyone. License is CC-BY. TL;DR: Credit me if you redistribute without modifications. Otherwise you don't have to credit me. No other restrictions in use, you can repackage, redistribute, modify, for commercial or non-commercial purposes. New CC-BY applies to TransparentPod and RF Mods, previously released under CC-BY-NC-SA. Everything is Unity 4.2.2; should work without issue in any newer versions of Unity. CommandPods Internal Props 2m Square Parts Engines Misc: Gears; Structural; 1.5m parts

the props require Firespitter mod, it's created by Snjo; right now maintained by RoverDude I think. It is a very popular mod.

I keep referring to this thread from time to time, very helpful for any kind of game modeling. http://www.polycount.com/forum/showthread.php?t=56014&page=222

If you only do KSP modding, Blender is best bet since you can get much more support from the community here. If you do more than just KSP, Max or Maya are much more common. Both have full function free student licenses that doesn't require a student ID or email. As far as Unity supporting Blend files natively, that's a little bit of a trojan horse, Unity just runs Blender's FBX exporter in the background. If you don't have Blender's FBX plugin installed correctly, you won't be able to drag/drop Blend files into Unity. I recommend getting familiar with the plugin settings as it is an important step of the asset pipeline.

Max and Blender are Z-Up; Maya and Wings3D are Y-Up. C4D and Modo are user selectable I believe.

http://forum.kerbalspaceprogram.com/threads/94638

I don't know your forum name, but thanks for adding/updating all that CFG documentation on KSP Wiki. That was a lot of work!!! I am grateful, and I'm sure many other modders are too.

sorry, I might have overlooked that part... it's just second nature when working in Unity. Remember Unity is all about Components and GameObjects. Everything in Unity starts as a GameObject, holding only basic 3d information: Position, Rotation, and Scale. You add "Components" to give the GameObject different properties and behaviours. GameObject + Light component = Light GameObject + Camera component = game camera GameObject + Collider + Rigid Body = object subject to in-game physics GameObject + Mesh Filter + Mesh Renderer = 3d object that is visible in game etc etc etc. When a tutorial talks about something like thrustTransform; or RCSThruster; they mean a GameObject with a specific name. KSP's PartModule system works very similarly. A part can look like anything, based on the MU and texture assigned in the part config file. And behave like anything within in the scope of the game, based on Part Modules attached to it in the part config file, and that the Part Modules are provided appropriate GameObjects to work with; for instance a thrustTransform is necessary for Engine module to generate force. An antenna can behave as an Engine if you so desire; an Engine can work as a Wing surface; etc. PartModules are configured by parameters inside the Module. An extensive list of stock/mod part modules are described in detail here http://wiki.kerbalspaceprogram.com/wiki/Module#STOCK_MODULES most parameters have default values and a PartModule will function without all the parameters being specified in the part config file. Some PartModules require specialized parameters and GameObjects, like Engine Module or Landing Leg/Gear Modules. now apropos the EngineModules thrustVectorTransformName = specifies the GameObject within the engine MU file the PartModule should use as thrust point. By standard convention this GameObject is named "thrustTransform", but it is not necessary. It can be named GameObject, PooFighter, 24faw4ywg, etc As long as the engine MU file contains the named GameObject matches (case sensitive, no spaces or periods) what is specified in the EngineModule's thrustVectorTransformName value, the engine will work.