CaptainKipard

Almost finished here. I've checked off all my to-do items, except the integrated RCS. Unless anyone has any last minute recommendations I'll release this as it is.

Ziw/Erendrake/Sirkut how hard is it to add the scrollwheel for increasing/decreasing numbers?

Instead of bothering with numbers, you should just use EGOs and NODE{}

I don't think so. There's no such thing in the fixed scene.

This looks interesting but there's almost no reference for model makers. Schematics aren't that useful.

J'utilise Google Traduction Salut Stephm Tu es revenu! J'ai souvent vérifié votre profil pour voir si vous avez posté quelque chose, et aujourd'hui, je ai vu votre poste au haut de la page! Je vais être honnête avec vous. Je savais que vous étiez déprimé. Je pourrais dire de la façon dont vous avez parlé parce que je ai une certaine expérience avec la dépression aussi. J'étais inquiet pour toi. Je suis content que vous êtes ok bien. Je sais que vous avez dit que vous ne aimez pas modding plus, mais si vous changez d'avis que nous pouvons travailler ensemble sur quelque chose de nouveau. Et si vous voulez parler de choses personnelles, je serai heureux de le faire aussi. Je sais ce que le désespoir se sent.

I guess because that's what official visualisations show. The manual doesn't mention the wheels at all unfortunately.

Good to hear from you again Pappystein. If you're up for it I have a specific task for you, and that would be researching various types of aeroplane landing gear and their components. If not then let me know the kind of things you could do. Also let me know whether you're qualified (and how) or a hobbyist.

I replaced the animation with another one that I did for a different light/emissive and KSP loaded the model fine this time. Everything is working as intended, but I still don't know what I did wrong previously.

I added the stuff from Mattasmack except the solar panel one because I couldn't find anything of interest to me. Who would like to take a look to see if they find something? - - - Updated - - - Are you joking or being serious? Also what does all that mean?

OK, but how would you use those? The seal one is so esoteric as to be nearly useless for part makers, and the second one has schematics, rather than blueprints, and again that's not useful to people making models. We should start with basics, like blueprints and cutaways. I mean technical documents are fine, but they have to contain one of those two. - - - Updated - - - Unless they're for plugin authors, in which case diagrams aren't as important.

I wonder why, since no one told you to do that. Should be -z is the direction of lift (can be "+" or "-" for the aero system, but "-" makes the arrow show up correctly), +x is right, +y is the direction of travel. You also need to make sure your attach node is oriented correctly - I think.

Yep. All that matters by the way is the mesh orientation in relation to your parttools empty. You can change the mesh orientation of the mesh object in blender if you want, but that's down to personal preference, and wont matter unless you do more advanced wings that have stack attachments or integrated control surfaces, where precise orientation really matters. MODS Is it possible to fix something in the OP? The orientation information at the top is wrong and keeps confusing people. I've already had a couple of beginners contact me about this.

That all looks fine, provided the lightName is correct. I doubt this will make a difference but you can try without hyphens. Can you show a screenshot of the animation keyframes and hierarchy?

Justin Kerbice. It has been several months and your OP still contains misleading information. Could you please change it already?

That's even a good addition on its own. I think this is the precise name i've been looking for, and if not precisely this then something like. At least this level of abstraction. I'm not sure how to say this. If there's another name for a similar linkage that overhangs the way one of the arms does on the PLBD mechanism that would also be good to know. This would go under miscellaneous obviously. Agreed.

Did you create an animation in Unity and refer to it in the cfg under ModuleLight? Is that animation animating both the emissive and the light? What does your MODULE look like?

I knew I've seen someone complain about this before. I'm getting the exact same error as shown in this thread, but I don't know how I should proceed because I don't know anything about prefabs, and very little about animations. I created one, afaik in the same way as I had for my the non-androgynous docking ports (it's just a spotlight and an emissive light), but this time it's not working.

What could be some possible reasons? The configs and textures are loaded by the game, but the models don't show up in the debug window. The parts also don't show up in the parts list. I would have expected to see invisible parts, but no. PART { name = kipunivdockport375 module = Part author = Cpt. Kipard scale = 1 rescaleFactor = 1 MODEL { model = KipEng/parts/UnivDockPorts/UnivPort3 } NODE { name = top transform = n_top size = 3 method = FIXED_JOINT } NODE { name = bottom transform = n_bottom size = 3 method = FIXED_JOINT } // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision attachRules = 1,0,1,1,0 TechRequired = metaMaterials entryCost = 28000 cost = 3100 category = Utility subcategory = 0 title = Universal Docking Port X-Large manufacturer = Kip. Engineering description = Docking port capable of attaching to ports of sizes 3.75m and smaller as well as other Universal Docking Ports. Compatible with "Connected Living Space". Impassable. mass = 0.675 dragModelType = default maximum_drag = 0.25 minimum_drag = 0.25 angularDrag = 0.5 crashTolerance = 30 maxTemp = 3400 MODULE { name = ModuleConnectedLivingSpace passable = false } MODULE { name = ModuleDockingNode nodeType = size3 referenceAttachNode = top } MODULE { name = ModuleAdaptiveDockingNode ValidSizes = size0,size1,size2,size3 } MODULE { name = ModuleLight lightName = Spotlight useAnimationDim = true lightBrightenSpeed = 20 lightDimSpeed = 20 resourceAmount = 0.01 animationName = DockLightAnimUniv useResources = true } } PART { name = kipunivdockport25 module = Part author = Cpt. Kipard scale = 1 rescaleFactor = 1 MODEL { model = KipEng/parts/UnivDockPorts/UnivPort2 } NODE { name = top transform = n_top size = 2 method = FIXED_JOINT } NODE { name = bottom transform = n_bottom size = 2 method = FIXED_JOINT } // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision attachRules = 1,0,1,1,0 TechRequired = metaMaterials entryCost = 14000 cost = 1550 category = Utility subcategory = 0 title = Universal Docking Port Large manufacturer = Kip. Engineering description = Docking port capable of attaching to ports of sizes 2.5m and smaller as well as other Universal Docking Ports. Compatible with "Connected Living Space". Impassable. mass = 0.22 dragModelType = default maximum_drag = 0.25 minimum_drag = 0.25 angularDrag = 0.5 crashTolerance = 30 maxTemp = 3400 MODULE { name = ModuleConnectedLivingSpace passable = false } MODULE { name = ModuleDockingNode nodeType = size2 referenceAttachNode = top } MODULE { name = ModuleAdaptiveDockingNode ValidSizes = size0,size1,size2 } MODULE { name = ModuleLight lightName = Spotlight useAnimationDim = true lightBrightenSpeed = 20 lightDimSpeed = 20 resourceAmount = 0.01 animationName = DockLightAnimUniv useResources = true } } PART { name = kipunivdockport125 module = Part author = Cpt. Kipard scale = 1 rescaleFactor = 1 MODEL { model = KipEng/parts/UnivDockPorts/UnivPort1 } NODE { name = top transform = n_top size = 1 method = FIXED_JOINT } NODE { name = bottom transform = n_bottom size = 1 method = FIXED_JOINT } // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision attachRules = 1,0,1,1,0 TechRequired = specializedConstruction entryCost = 8000 cost = 450 category = Utility subcategory = 0 title = Universal Docking Port Medium manufacturer = Kip. Engineering description = Docking port capable of attaching to ports of sizes 1.25m and 0.625 as well as other Universal Docking Ports. Compatible with "Connected Living Space". Impassable. mass = 0.07 dragModelType = default maximum_drag = 0.25 minimum_drag = 0.25 angularDrag = 0.5 crashTolerance = 30 maxTemp = 3400 MODULE { name = ModuleConnectedLivingSpace passable = false } MODULE { name = ModuleDockingNode nodeType = size1 referenceAttachNode = top } MODULE { name = ModuleAdaptiveDockingNode ValidSizes = size0,size1 } MODULE { name = ModuleLight lightName = Spotlight useAnimationDim = true lightBrightenSpeed = 20 lightDimSpeed = 20 resourceAmount = 0.01 animationName = DockLightAnimUniv useResources = true } }

What's wrong with the huge sticky in Add-on Development?

Has the "white texture" bug been resolved?

I think this would be a better solution generally speaking. You could have toroidal tanks for anything.

As long as it helps modders make realistic looking parts or code realistic systems then it's fine. Speaking of which a foolproof guide to PID controllers is something that could be useful. I'm guessing you understand those? Plesse subscribe to the thread.

This. At first I thought "How could you possibly put various fuels in the same tank" but this solves the immersion problem nicely.

Great. Do you think you'll have the time to answer modders questions in that thread from time to time? Or contribute in other ways in the future? Nice Good news is that armed with the knowledge on that page I was able to find this document. Payload Bay Doors and Radiator Panels Familiarization Handbook. There aren't many diagrams, and they're of terrible quality but it uses engineering jargon. Apparently the mechanism is called the "PLBD drive system". I think this and your first document will be enough for this particular item (payload bays).