nli2work

overlap them if you can't get a convex collider with a single mesh.

if you see backface as the part rotates then the normals are flipped. invert or flip the faces in blender should fix it, be a good idea to unify the normals so they are all pointing in the same direction as well. technically there's nothing wrong with the model so you won't get any warnings.

the names can be anything strictly speaking, without spaces and special characters. As long as you give the Part Modules the correct objects they will work. MODULE { name = ModuleLandingGear animationName = Front Landing Gear \\ Deploy/Retract animation, the clip in the Animation component wheelCollider = wheelCollider \\name of the object with the wheel collider component, the object can be any name you want. naming it "wheelCollider" just makes it easier to identify than "8k3nf8" wheelName = Wheel \\name of the visible mesh object that spins, again, any name can do. but ideally something that's easily identifiable. wheelRotationAxis = -1,0,0 \\axis around which the Wheel mesh spins in X,Y,Z. typically X. add/remove negative sign to reverse direction BrakeTorque = 20 BrakeSpeed = 0.5 } you are making progress. Still need to add suspension. so to get the full landing gear module, you need one more object. Maybe the light as well, not sure on that one. MODULE { ... suspensionParentName = suspensionParent \\follows the suspension settings in the unity component up/down based on weight being supported. check Unity docs for specifics of wheel collider, this images might help too http://i.imgur.com/Uce0rLj.jpg ... } hierarchy would look something like this, check the sample file in the previous post. StrutsAndDoorPanels SteeringObject wheelCollider suspensionParent WheelMesh AdditionalStuff-Optional

FXModuleLookAtConstraint is for setting up the suspension linkage arms so they move when the suspension moves up and down, they are optional. the hierarchy look something like this: SteeringObject wheelCollider WheelMesh AdditionalStuff-Optional the wheel mesh object is on the same level as wheelCollider, not a child of wheelCollider. Alternatively you can place the wheelCollider on the same level as SteeringObject and use FXModuleConstraintPosition to link it to the SteeringObject. and no spaces in any object names, replace spaces with underscore if necessary.

the two objects both named "wheelCollider" is probably confusing the module. you need a wheelCollider component, it's a specialized component just for wheels with suspension. It is used by ModuleLandingGear, which provides visible suspension, wheel spinning, and deploy/retract animation trigger. ModuleSteering provides input control on a game object in the wheel heirarchy. FXModuleConstrainPosition links the wheelCollider to the object that responds to input control. the visible wheel mesh should be a child of the steer object. another mesh collider for the visible wheel is optional, but should not be named "wheelCollider". only one object in the wheel setup should be named "wheelCollider" landing gears and wheels are both very convoluted to setup correctly, you might have to dig some more. here's a unity project with working part file, might help you in your process. from this thread: http://forum.kerbalspaceprogram.com/threads/72802 dedicated to landing gears. http://www./download/psu9e2k70d6wwz0/skylonNoseGear.zip

maybe related to this... http://forum.kerbalspaceprogram.com/threads/114059 be sure to check the transforms of the part heirarchy before export. root object with PartTools script should be 0,0,0 Position and Rotation, 1,1,1 Scale; this is relative to World coordinates. children objects' transform are relative to their parent coordinate, not the World coordinate. Typically the main visible mesh is 0,0,0 Position and Rotation relative to the root object, but this is not always the case.

try removing the line "Scale = 0.1" from config. create a cylinder primitive in Unity with scale of 2.5,2.5,2.5 and check the size of your mesh. also remember KSP sizes are diameter; radius 2.5 = 5m tank in KSP.

in this pic, https://i.imgur.com/dEIpLpT.png, drag/drop "TANK_ASPER" onto PartTools. Now when you select PartTools in Heirarchy, the Tank mesh should become textured wireframe and turn blue. in the pic, you can see the Tank mesh doesn't have blue wireframe highlight, that means it's not going to get exported. you did everything correctly, except attach the tank object to the export process. PartTools script exports all of it's children into a *.MU file. since you didn't assign it any children before export, it returned an empty *.MU file and so you see no object in game. All things considered, this is far less frustrating than a part not loading at all.

Blender calls it "Origin"; Unity calls it "Pivot". your pivot is off center. the pivot is what KSP uses to figure CoM. your pivot is off on the right wall of the tank judging by that picture. The center of your mesh should be aligned to 0,0,0 relative to GameObject. since the pivot is off to one side, you have to correct it by moving "model" by the same distance as the radius of the cylinder in the opposite direction. You may have to move it in all X,Y,Z to position the visible mesh properly. Best way is to fix it in Blender, link down below... your mesh and pivot on the left; I replicated what you have with a simple cylinder in the middle; the right side is what you want. The capsule collider's direction setting will depend on it's host object's local pivot. The blue and red axis indicates world axis, they intersect at 0,0,0. Since you imported from Blender (my guess), Z is Blender's Up/Down axis, the capsule collider should be set to Z-Axis. In this case you would have to adjust the capsule collider's center to counter correct for the mesh's offset pivot. Think of it this way... GameObject with Part Tools script is at 0,0,0, relative to World. "model"'s position is relative to GameObject, not the World. Since "model"'s pivot is to the side, you have to shift it in the opposite direction by the radius so it's visible center (the Center of Mass you want) is at 0,0,0 relative to GameObject. This will ensure the Center of Mass in game is at the position you would expect for cylindrical object like your fuel tank. capsule collider inherits it's center from "model", which is off to the side. You shifted "model" earlier, which means capsule collider is now offset by the radius relative to GameObject. So you have to adjust the center setting so the collider is overlapping the "model" properly. you should fix the pivot in Blender and then import the mesh again. http://wiki.blender.org/index.php/Doc:2.6/Manual/Modeling/Objects

this certainly reads like there are multiple areas responding to a mouse over. at any rate. you used capsule collider, it has rounded ends, of course it will tip over... looking at this, https://i.imgur.com/SDXMVrc.png, your collider is off-center relative to the visible mesh. set your pivot display to "Pivot" & "Local" set your GameObject to 0,0,0 position and rotation rotate your visible mesh so it is positioned at 0,0,0 and oriented correctly. probably 90,0,0 remove "Animator" component remove and reapply capsule collider. it should automatically size to fit the visible mesh. If it sits horizontally, change "Direction" to Y-Axis, adjust Radius and Height. Center should be 0,0,0

the config file is fine. problem lies with the mesh's pivot. make sure the pivot for the visible mesh and collision mesh are in the same location, and have same rotation. the part's center of mass is the pivot of the object with Part Tools script. if you use an empty game object for the Part Tools script, place that object at the CoM of your part before export. multiple mouse over areas is probably due to having multiple collision meshes that are not aligned. resetting the pivots to the part's CoM should solve that.

the errors are new and not related to Animator component. Looks like the Internal config file you are attempting to save to doesn't exist, or the internal name doesn't match. Also, you only need either PartTools script, or Internal Space script to export. never both. this video explains IVA setup in detail

KerbalX rocket from Squad is around 62k triangles; around 70 parts IIRC. I'd shoot for something in that neighborhood for an entire ship. Per part I would shoot for no more than 5~10k on average; least possible is always preferred.

hardly endangered. the mod was created when there's a lack of something. Squad finally including something that is essential to a full game would free up modders to do better things.

FAR or Kerbal Joint Enforcement, that was back in 0.24.5.

if you installed Unity 5, it's probably the realtime GI cache that ate up the storage space. by default it can eat up to 10 gigs. Use Unity 4.2.2 for better compatibility with KSP, and not have to worry about running out of disk space because of GI precalculations. Unity requires FBX plugin for Blender in order to import *.blend files. removing/reinstalling blender probably resolved that issue.

I've only seen this sort of thing one time, it was due to a bug with a mod, it's been fixed now. moving parts can cause colliders from different parts to push the craft apart, but it takes quite a lot of force. minor clipping between parts like your jet doesn't seem like it would cause the problem. colliders on a single part would never do anything like this. Does this happen in a clean install?

all art assets by Squad of course. Also wouldn't have been possible without KSPBlender addon by Dasoccerguy. I made a few minor additions. Lit and rendered in Unity 5 full res @ 10800x6075

the errors are because you have the import model set to use MechAnim animation system. Set the import to "Legacy" animation and use "Animation" component instead of "Animator" component. Unity 4.x defaults to "Generic" for imports. Both "Generic" and "Humanoid" are only used with MechAnim system. In fact you should do that for all KSP parts. PartTools will not export "Animator" component. Remove "Animation" and/or "Animator" components from the IVA if you don't have any animations inside. check my sig for detailed IVA tutorial videos.

very nice! what mods did you use to get the post effects?

well, keep us posted on your progress. I know I'm not the only one interested in seeing what you have cooking.

I am wrong, thanks for the pics. I assume the shutter blades have mesh colliders? I think there is still a performance cost to do it based on this "In Unity 5.0 we’ve reduced the cost of scaling Mesh Colliders. Previously, when scaling a Mesh Collider, you would have to create a new mesh with scale baked into the vertices, and that required valuable time and memory. With PhysX3 we are able to support non-negative scaling without any baking. It’s basically free." The same does not work for nor ; which is what I think you are attempting to do from the OP.nevertheless, based on how your solar panel part appears to work, separate objects with box colliders is the best way to go performance and setup complexity wise. if your solar panel works like the shutter, then rotating and/or scaling colliders would certainly work better.

no idea. I expect it would be an issue if you have two clips trying to animate the same object. if the clips animate their own objects it's worth a try. I haven't tried using AnimateThrottle for a while since it conflicted with AnimateHeat back in 0.24. it might work fine with ModuleAnimateGeneric considering AnimateHeat does alright with AnimateGeneric.

you can try this one MODULE { name = FXModuleAnimateThrottle animationName = youranimation responseSpeed = //defaults to 0.5; a multiplier probably. 1 = full response speed. } I can't guarantee it will work. If it does, it probably will conflict with ModuleAnimateHeat and/or ModuleAnimateGeneric

I think you are confusing mesh collider and skinned mesh. mesh colliders don't scale, much less animate as skinned mesh, in Unity4. if you wanted to scale a collision mesh, you have to export a new mesh with the scale changed baked in to use as a collision mesh. Unity5 supports collision mesh scaling with new physx implementation, but KSP won't be on Unity 5 for a while. You can animate some mesh in Blender and import to Unity 4, but whatever it is, it won't work as a collision mesh. Skinned mesh will work in Unity4 and KSP. Skinned mesh has a bounding box, that appear similar to a collision mesh, but isn't a collision mesh. it's only for checking visibility in relation to camera frustum. Squad's solar panels are simple heirarchy chains with panels as separate objects. each panel has it's own box collider. if your panels are odd shapes, then use a mesh collider, otherwise use primitive colliders.