Eleusis La Arwall

What is STFS? STFS is a mod that allows users to choose which switcher-mod they want to use on the stock LFO tanks. Furthermore users can configure the fuel-setups to their likings. The customization is done via PatchManager, no need to dive into the MM-patches. What are the dependencies? ModuleManager and PatchManager are hard-dependency and the mod will not work without them. At least one Resource Switcher mod is also required. Currently InterstellarFuelSwitch (IFS), Firespitter (FS) and B9PartSwitch (B9PS) are supported. Depending on the resource-setups you want to use, you may need CommunityResourcePack. None of the dependencies are included in the download! How to use it? When you install STFS, it will do nothing (*1) unless you configure it. To do so: 1. start KSP, load a savegame and at the KSC open the PatchManager window. Navigate to STFS000priority and expand it. Now choose a mod to handle the fuel-switching. If no switcher is chosen, the mod is deactivated. 2. In the PatchManager window navigate to STFS100LFOtanks and expand it. Now choose the resources you want to have available on the stock tanks. 3. Apply the changes AND RESTART KSP! Will it interfere with other mods patching stock LFO tanks? STFS always plays nicely (hopefully) with other mods. By default the patching will take place at the end of MM load order (zzSTFS...). If fuel-switcher modules are detected, no further fuel-switcher modules will be applied. Even in aggressive mode, STFS will never add fuel-switchers to parts that already have a fuel-switcher module (not breaking stuff if other mods don't play nicely). How does 'aggressive mode' work? Aggressive mode adds a 'dummy' fuel-switcher in the :FIRST section of MM-patching and removes it right before STFS starts its usual patching. As long as your other mods also play nicely and don't apply additonal switcher modules, STFS can do its job. How is STFS balanced? That is the tricky part, which is mostly WIP currently: - Each setup on a tank uses the same volume for resource-storage. The Resource-Storage-Volume (RSV) is calculated from the amount of stored LiquidFuel and Oxidizer on each tank. - Cost of each stock LFO tank is reduced to its dry-cost (KSP default cost include resource-cost) - Each setup uses the default tank-mass. The results are rather bad fuel-to-mass ratios on some setups. I'm open for suggestions! No pics, no clicks? Since there is not really anything to show, some screenshots of the PatchManager setups: Currently supported fuel-setups: Download: The current release is very early development and I'm looking for testers! If you are interested let me know in this thread or via pm. Download from GitHub (direct) Limitations: - Order of setups cannot be changed - The setups are global for all savegames on the same installation of KSP Notes: (*1): The mod adds a useless key (stockLFO = true) to all stock tanks to make identification easier. The key will be removed at the end of MM-patching. - The cost of stock LFO tanks is set to their dry-cost instead of the default wet-cost. - The default RESOURCE nodes are removed. Warranty: The mod is VERY WIP, so no warranty if it breaks craft- or save-files. Make backups in time! License: CC-BY-SA 4.0 International Changelog: Thanks to - @sarbian for ModuleManager - @linuxgurugamer for PatchManager - @FreeThinker for InterstellarFuelSwitch - @blowfish for B9PartSwitch - @Snjo & @RoverDude for Firespitter - @RoverDude for CommunityResourcePack - @NecroBones for FuelTanksPlus - @534443 for the help with costs

I've used the LaunchPadSide to build a plane similar to the one from the screenshot. Once with cockpit as root part, once with fuselage as root part and once with a rotated ProbeCore inside a cargobay as root. I was not able to reproduce the problem you describe, all three vessels spawned with the correct orientation. From the screenshot I see you use a well modded install, have you tried a fresh install with just EL & KD installed? If you have a craft-file (stock only if possible) that reproduces the error all the time, I'd take a look at it. Otherwise there is not much I can do.

It's been quite a while but I'm currently working on the next update for Keridian Dynamics. Similar to the EL update it will break savegames. Hopefully v.0.9 will be the last savegame-breaking update and if everything goes as planned it will become the 1.0 release. I will not release this update before KSP 1.4.3 but I made a PreRelease of the current status for everyone who wants to take a look or do some testing (which I would greatly appreciate ). The PreRelease is only available on GitHub: Download The picture below shows the new ExtensionPad (left) that can be used to extend exisiting vessels, the LaunchPad (OrbitalPad replacement, middle) and the powerfull LauchPad/ProbeCore combination Keronica. The LaunchMarkers have been reworked and now show the unity axis at the vessel spawn point (toggleable). Changelog (so far): ToDo: Big THANK YOU to @534443 for the cost and entryCost rebalance! Yes, the hextanks were very outdated and now they are gone Still thinking about the best way to make the dependencies a bit clearer. In general all dependencies are for the plugins (dlls), no parts, models or textures from other mods are(/should be) required. Ships are recycled part-by-part as long as they remain in the RecycleField. Thank you very much for the quick fix! I'm not sure if I understand that correctly, the rovers spawn looking at the sky? If a rover is spawned correctly aligned when normally launched from VAB/SPH it should also spawn correctly aligned from the SidePad. Could you upload some pictures visualizing the problem?

Here's a little preview to a new fusion reactor model I just finished:

@blackheart612 Thank you very much Some more Landing Leg stuff: After the basic landig leg I've tried to achive some more complex builds. Especially the second example took me lot of time to figure out. I won't explain them as detailed as before but hopefully enough to rebuild them. I save the blend file under a different name and start with a new unity scene for each example. Also the animation names change, so you may need to adapt the config ("animationTrfName" and "animationStateName" in ModuleWheelDeployment). 1.) Position This example extends the whole leg 1 m to the side before deploying the piston and it also uses constraints (Pneuma objects). The hierarchy has changed a little and therefor all new or moved objects are marked in blender. The ChassisCollider is now a child of ChassisBlue, the rest is new. The Pneuma objects have the origin at their individual hinge points and PneumaHullRed is 180° rotated around the x-axis to make Z+ face down. The unity setup is pretty much the same as before. StaticCollider must be set up and the animation needs some new keys for the sideway-movement. Config also stays the same, just the constraints need a new module: MODULE { name = FXModuleLookAtConstraint CONSTRAINLOOKFX { targetName = PneumaStickYellow rotatorsName = PneumaHullRed } CONSTRAINLOOKFX { targetName = PneumaHullRed rotatorsName = PneumaStickYellow } } Now check the wheelCollider position in KSP. I usually set gravity to 0.04 and move the vessel to the side on the launchpad until it drops down: The constraints work as well. 2. Rotation This example rotates the leg by 30° before deploying the piston and this is where it gets messy. First I'll explain my unsuccessfull attempt and show the problem that arises: The blender setup is the same as the example above just the origin of ChassisBlue has been set to the hinge-point. All children except the PneumaStickYellow still have their origin at 0,0,0 (global coordinates). Unity setup is again the same, just the animation needs rotate keys instead of position. Config is also the same again. When I verify the position of the wheelCollider, it is off. First thing I noticed is a minimal vertical offset but the main problem is the horizontal offset. For hours I've tried everything I could come up with but the result is always the same (or a broken model). My thoughts on deployTgt mechanic: When the leg deploys in KSP, the animation is played and at a given point during this animation (TsubSys key in ModuleWheelDeployment), the suspension-object and all children are "moved" to the location of deployTgt. The (local) position of the suspension-object and children is identical to their position on the last frame of the animation. Y+ of the deployTgt also sets the axis for the suspension. The suspensionOffset in ModuleWheelSuspension is an offset for the "moved" suspension-object along the Y axis of deployTgt. What I don't know/understand is how the wheelCollider gets its offset from deployTgt position. So currently my best guess is that the wheelCollider is not lowered along the Y-axis of deployTgt but instead along the global Y-axis. I was about to write this down up to this point and ask for help when I realized that the model could be rotated by 30° in retracted state. This way the suspension is always along the global Y axis. The model would need to be rotated manually in the config file later. A quick look at the stock legs revealed that the models are rotated: ... node_attach = 0.0, 0.0, 0.0, 0.0, 0.3756781, 0.9267502 ... // From landingLeg1 The solution 1.) In blender set the cursor to the hinge-point of ChassisBlue 2.) Make sure pivot point is 3D cursor 3.) Select ChassisBlue and PneumaHullRed and rotate them 30° around the X axis. Save and go to unity. Some of the animation keys need to be set up again but everything else should be fine. Export the model and open the config. Now a direction vector is required that is perpendicular to the flat sides of StaticGray. It needs to be parallel to the green arrow in the picture above (the one on the textured model). 0.0, 0.5, 1.0 is such a vector and the config should look like this node_attach = 0.0, 2.4384, -0.26651, 0.0, 0.5, 1.0, 1 Another thing I forgot to mention in the tutorial is Center of Mass Offset. It should be set to move it away from the foot. CoMOffset = 0.0, 2.4, 0.0 Fire up KSP and verify that the wheelCollider is in place now Done! The attachment of the legs to the capsule is a bit off but it should be easy to fix with some trial and error on the attach node. I will add the additions to OP after I did dome more experiments with legs (and maybe wheels ?!).

An interesting problem. I couldn't find a solution to filter the same key for various exact matches, so I came up with a patch that adds a new key with identical values for all matches: @PART[*]:HAS[@MODULE[ModuleDockingNode]:HAS[#nodeType[size?]]]:BEFORE[stockSizeDockingPortPatch] { @MODULE[ModuleDockingNode]:HAS[#nodeType[size0]],*{stockSizeDockingPort = true} @MODULE[ModuleDockingNode]:HAS[#nodeType[size1]],*{stockSizeDockingPort = true} @MODULE[ModuleDockingNode]:HAS[#nodeType[size2]],*{stockSizeDockingPort = true} } @PART[*]:HAS[@MODULE[ModuleDockingNode]:HAS[#stockSizeDockingPort[true]]]:FOR[stockSizeDockingPortPatch] { @MODULE[ModuleDockingNode],* { // If you want X degrees wide margin, use cos(0.5*X) as captureMinRollDot // 0.5 degrees = 0.99999048 // 1 degree = 0.99996192 // 2 degrees = 0.9998477 // 3 degrees = 0.99965732 // 5 degrees = 0.99904822 %captureMinRollDot:NEEDS[!DockRotate] = 0.99996192 // more relaxed version to use with DockRotate %captureMinRollDot:NEEDS[DockRotate] = 0.99904822 %snapRotation = true %snapOffset = 30 } } @PART[*]:HAS[@MODULE[ModuleDockingNode]:HAS[#stockSizeDockingPort[*]]]:FINAL { @MODULE[ModuleDockingNode],*{!stockSizeDockingPort = true} } ( stockSizeDockingPort is key I made up, not a real one.) I'd really like to see a more elegant solution.

Landing gear and wheels are not easy and even though there is quite some information spread across the forum it took me very long to get working results. One thing I really missed was a step-by-step tutorial that tells me what is required, where stuff needs to be placed and so on. A couple of days ago, I had successfully created my first working landing leg. It's very simple with just a suspension and rotateable foot but it works! Now I wanna try to write down a step-by-step tutorial on how to create the most basic landing legs. I also hope to get some feedback to improve my assembly of landing legs and/or this tutorial. Software: - Blender (v2.79) - Gimp (v2.8.22) - Unity (5.4.0p4) - Part Tools - NotePad/NotePad++ 1. Blender The Blender part is rather easy just make sure to build the retracted version. Create the objects as shown in the picture and drag them in the correct hirearchy. What I found to be important is that the center of foot-hinge is at 0,0,0 and the model is build around it. All objects should have their origin at 0,0,0, rotation 0,0,0 and scale 1,1,1. 2. Unity 1.) Start with a New Scene and delete everything in it. "Create Empty" (Ctrl+Shift+N) and set position to 0,0,0. 2.) Make sure the Layers are set up correctly in unity. The following are required: Layer26: WheelCollidersIgnore, Layer27: wheelColliders, Layer30: SurfaceFX. If the Layers aren't set up already, expand the Layers, click "Add Layer" and enter the Layer names at the corresponding User Layer. 3.) Add the Part Tools script and set up Model Name, URL and Texture Format. 1.) Drag the TestLeg.blend file to the newly created GameObject (I use the .blend file directly with .fbx conversion done in the background) 2.) Select "ExampleLandingLeg" and remove the Animator Component (right click / Remove Component). 1.) Create an Empty, rename it to "wheelCollider" and drag it as child of "GameObject". 2.) Create an Empty, rename it to "deployTgt"" and drag it as child of "ChassisBlue". 3.) Make sure their position is 0,0,0. Now all objects except the PistonCollider (comes later) are present and they can be configured. Start with the deploy animation. 1.) Select "ExampleLandingLeg". 2.) Hit "Add Component / Miscellaneous / Animation" (Note that AnimatoR and AnimatioN are two different things!). 3.) Click " Window / Animation" (or Ctrl + 6). The Animation Window pops up. Click "Create" and enter a name like "deployLegAnim". 1.) Click "Add Property" and navigate to "ChassisBlue / PistonRed / Transform". 2.) Add the "Position" entry by hitting the small +. 3.) Change to CurveView. 1.) Go to Frame 60. 2.) Set Z position to -2 (suspension-distance). 3.) Animation is done, close the Animation window. 1.) Select "ChassisCollider". 2.) Remove the MeshRenderer Component (right click / Remove Component). 3.) Hit "Add Component / Physics / MeshCollider" and check the "Convex" box. 4.) Set layer to "WheelCollidersIgnore" (26). 1.) Select "wheelCollider". 2.) Hit "Add Component / Physics / Wheel Collider" and configure it as shown in the picture (non-default values are marked red). Mass: IDK, just works Radius: The distance from hinge-origin (0,0,0) to the lowest point of the foot (while retracted) Suspension Distance: As the name says (should be the same distance covered by the animation) Spring: Springhardness Damper: IDK, just works Target Position: Default suspension position. 1 is fully deployed (landing gear), 0.5 is half deployed (wheels). 3.) Set Layer to "wheelColliders" (27). There is one last step but I highly recommend to save the unity scene at this point and exported/test the model. Once the PistonCollider is added, it becomes much harder to verify that the wheelCollider is in the right position (in KSP). Switch to a filebrowser and navigate to the GameData folder of the KSP installation. Create a new folder "ExampleLandingLeg" and copy modelELL.mu and the texture in that folder. Also Create or copy a new config file in that folder and paste the following (the config already references "PistonCollider" which is not yet included but don't worry): PART { // General parameters name = ExampleLandingLeg module = Part author = YourName // Asset parameters mesh = TestLeg.mu scale = 1 rescaleFactor = 1 // Node definitions - Position X, Position Y, Position Z, Up X, Up Y, Up Z node_attach = 0.0, 1.5, -0.19, 0.0, 0.0, 1.0, 1 // Editor parameters TechRequired = advLanding entryCost = 1 cost = 1 category = Utility subcategory = 0 title = ExampleLandingLeg manufacturer = None description = Soon TM tags = example landing leg // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision attachRules = 0,1,0,0,0 // Standard part parameters mass = 1.0 bulkheadProfiles = srf // Drag dragModelType = default maximum_drag = 0.2 minimum_drag = 0.2 angularDrag = 2 // Damage and Temperature crashTolerance = 40 maxTemp = 2200 // Resources // Modules MODULE { name = ModuleWheelBase wheelColliderTransformName = wheelCollider // object with WheelCollider-Component wheelType = LEG FitWheelColliderToMesh = False // setting this to true will override the radius and center parameters radius = 0.1 // Same as set in unity center = 0,0,0 // Same as set in unity mass = 0.05 // Same as set in unity autoFrictionAvailable = False clipObject = PistonCollider // Moving Collider for the piston. Causes trouble if not set. TooltipTitle = none TooltipPrimaryField = groundHeightOffset = 4 } MODULE { name = ModuleWheelSuspension baseModuleIndex = 0 // Reference to the location of "ModuleWheelBase" in the config (first module is 0) suspensionTransformName = PistonRed // object (and children) that will be moved by suspension suspensionColliderName = PistonCollider // Moving Collider for the piston. Causes trouble with the wheelCollider if not configured suspensionDistance = 2 // Same as set in unity suspensionOffset = 0 // IDK. There is some interaction with the position of deployTgt in unity targetPosition = 1 // Same as set in unity; With no force applied the suspension will be fully deployed springRatio = 20 // Same as set in unity; Springhardness damperRatio = 1 // Same as set in unity } MODULE { name = ModuleWheelDeployment baseModuleIndex = 0 // Reference to the location of "ModuleWheelBase" in the config (first module is 0). animationTrfName = ExampleLandingLeg // object with Animation Component (not the animated object!) animationStateName = deployLegAnim // name of the animation deployedPosition = 1 deployTargetTransformName = deployTgt // object that will become the wheelCollider when deployed TsubSys = 1 // When will wheelCollider switch during the animation. 1=end, 0=start } MODULE { name = ModuleWheelLock maxTorque = 500 } MODULE { name = ModuleWheelBogey baseModuleIndex = 0 // Reference to the location of "ModuleWheelBase" in the config (first module is 0) bogeyTransformName = FootYellow // Object that will act as foot deployModuleIndex = 2 // Reference to the location of "ModuleWheelDeployment" in the config (third module is 2) maxPitch = 160 // Degree. Maximum positiv deflection minPitch = -160 // Degree. Maximum negative deflection restPitch = 0 // Degree. Position with no influences pitchResponse = 100 bogeyAxis = 1, 0, 0 // Axis to rotate around bogeyUpAxis = 0, 0, 1 // Axis pointing upward. Can be 0, 1 or -1 } } Save the config and fire up KSP. Choose a Pod, add four legs around it and launch vessel (it may jump a bit at first, use launchclamps to avoid). If everthing went well, the foot should be exactly level with the ground and the suspension should work as well. Hit Alt + F12 to bring up the cheatmenu and play a bit with the gravity to see if everthing is alright. Hit "g" to retract the landing gear and deploy it afterwards again. The piston will go in the ground and the vessel jumps high at the end of deployment. So the PistonCollider needs to be set up to avoid this. Close or minimize KSP and go back to unity. The PistonCollider: 1.) Create another empty GameObject, name it "PistonCollider", make sure it is at 0,0,0 and set it as child of "PistonRed" 2.) Add Component "Physics / CapsuleCollider" and configure it as shown. The lower end should match the center of the wheelcollider (0,0,0) 3.) Set Layer to "SurfaceFX" (30) Re-export the model, fire up KSP or Reload the Database and test the deploy mechanic. Done! imgur album My sincere thanks to the people on the forum who shared their experience and knowledge about landing legs and wheels! EmbersArc for the cheat-sheet NecroBones and nli2work for the information provided in the Landing Legs 1.1 thread SpannerMonkey(smce) for information provided in the most basic wheel thread blackheart612 for the guide to making Deployable Landing Gears Nils266 for the "LandingLeg2" part from PlanetaryBaseSystems, it was a very usefull example. Nifty255 and linuxgurugamer for Kerbal Object Inspector Continued

Thanks for the update! Harvester and converter now work as intended. The MM-patch for IntakeATM does not. MM 3.0.6 shows an error during the loading screen and the log reveals: [ERR 14:37:15.641] [ModuleManager] Error - pass specifier detected on an insert node (not a patch): GTI_Utilities/Resources/MM_IntakeAtm/RESOURCE_DEFINITION:FOR[GTI] Remove the :FOR[GTI] and it works just fine.

Yes it is: @PART[*]:HAS[@MODULE[ModuleReactionWheel]] { @MODULE[ModuleReactionWheel] { @RESOURCE[ElectricCharge] { @rate *= 15 } } } The patch looks for all parts that use ModuleReactionWheel and applies the multiplication factor (15) to the rate. Have fun!

You need to apply the "Icon_Hidden" tag to the fairing-mesh(s). In unity select the mesh you want to hide in the preview. In the Inspector panel at the top is a field "Tag Untagged", expand it. If you haven't used this tag before it will propably not appear straight away (if it does, select it and you're done). Hit "Add Tag" and enter "Icon_Hidden" at one of the tags (you may have to add a new tag with the small + first). Afterwards select the mesh you want to hide again and make sure the Inspector says "Tag Icon_Hidden". Here you can find a list of all tags and layers for KSP:

A simple ModuleManager patch to restore helmets in KV-X and MK 2 Command Pod: @INTERNAL[KV?_IVA|MK2POD_IVA] { @MODULE[InternalSeat],* { @allowCrewHelmet = true } } If you don't want to use MM look into the Internal.cfgs (GameData\SquadExpansion\MakingHistory\Spaces\) and replace all "allowCrewHelmet = false" with "allowCrewHelmet = true".

It is possible but depends on the engine how to remove these effects. I've quickly wrote a small MM-patch that removes all visual/sound effects and damages to other parts as @steve_v suggested from the Mammoth Engine Cluster as an example: @PART[Size3EngineCluster] { !EFFECTS{} // Removes all engine effects (flame, smoke, etc) @MODULE[ModuleEnginesFX] { @exhaustDamage = false // No damage to other parts } @MODULE[FXModuleAnimateThrottle] // This Module makes the heat-effects { @responseSpeed = 0 } !MODULE[ModuleSurfaceFX]{} // Removes Surface effects when engine is close to the surface } This patch won't work on some of the older engines like the LV-T45 because they use different configs for the effects.

When I wanted to download the MHE from KSPStore (direct download) I sadly noticed that there is no portable version for Windows. 1. Will there be a portable version for Windows in the future? Since I use Linux and Windows, I also downloaded the linux package and it seems pretty much like a portable version. It contians an installer script but afaik it just checks the KSP version and extracts the (2nd) archive when version is valid. 2. Are the different versions really platform-dependant? 3. Do I have to expect the Kraken when extracting the contents of the GameData folder from the MHE-linux-package into the GameData folder of a Win x64 portable install?

PatchManager PreciseNode There are much more I wanna have but PatchManager is the most important one.

Propably I'm overthinking this but I can't stop thinking about it: So when I upload a screenshot of KSP to imgur, I accept imgurs ToS and thereby grant Imgur Inc. a non-exclusive, irrevokeable license to use that image. Am I able/allowed to grant an exclusive, irrevokeable license to use said image as required by TTIs ToS?

Step-by-step unity only sequence for 2 cubes with moving animation: Creating an empty GameObject and the two cubes is self-explaining I think. Make sure GameObject is at 0,0,0 and has the parttools-component. Select the GameObject (1) and hit "Add Component"(2). Under Miscellaneous click on "Animation"(3) (not AnimatoR!). This way the animation component is located at the GameObject. Open the Animation window. Ctrl + 6 or Window/Animation. Create a new Animation, in this case "TestAnimation". In the top left (1) you can switch between different animations if you want to have multiple. Switch to curve-view (2) and hit "Add Property"(3). Navigate down to the transformation of the mesh you want to move and add "Position"(4). Go to frame 60 (1) and change the value of the Y coordinate from 0 to 1 (2). That's it. Close the animation window, export the model and all you need is a config: PART { // General parameters name = TestAnim module = Part author = A // Asset parameters mesh = model.mu scale = 1 rescaleFactor = 1 // Node definitions - Position X, Position Y, Position Z, Up X, Up Y, Up Z node_stack_top = 0.0, 0.5, 0.0, 0.0, 1.0, 0.0, 2 node_stack_bottom = 0.0, -0.5, 0.0, 0.0, -1.0, 0.0, 2 // Editor parameters TechRequired = experimentalElectrics entryCost = 10 cost = 10 category = Utility subcategory = 0 title = TestAnim manufacturer = A description = // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision attachRules = 1,1,1,0,0 // Standard part parameters mass = 1.85 fuelCrossFeed = True bulkheadProfiles = size2, srf // Drag dragModelType = default maximum_drag = 0.2 minimum_drag = 0.2 angularDrag = 2 // Damage and Temperature crashTolerance = 10 maxTemp = 1400 // Modules MODULE { name = ModuleAnimateGeneric animationName = TestAnimation actionAvailable = true actionGUIName = Toggle Cube startEventGUIName = Deploy Cube endEventGUIName = Retract Cube eventAvailableEditor = true eventAvailableEVA = true eventAvailableFlight = true evaDistance = 5 } // Resources } The only important lines inside the Module are name and animationName. I've used ModuleAnimateGeneric but ModuleAnimationGroup is also valid. Notes: The hirarchy and names of GameObjects and meshes cannot be changed after you created the animation. There are ways around that but it's easier to make the animations as last step when everything else is already set up. (imgur album) Hope this solves your problem

Found it just because I wanted to make sure no other mod is causing the harvester thing During my read through the thread I stumbled upon this from about a year ago: I know it's very quick to ask for another feature already, but do you have plans for a MultiMode RCS Module?

Hm, without further information I don't know what went wrong but you can modify the position of the IVA manually in the internals.cfg: INTERNAL { name = MyIVA MODEL { model = Path/to/model position = 0.0, -2.0, 0.0 } }

The model must be imported but before you export it to .mu file you need to configure it in unity. For a first part it looks pretty nice. My first part was a storage tank aka simple cylinder Never tested colliders in unity. Have you verified it in KSP?

How do you set up your model in Unity? The thread is a bit old but it shows the material setup in unity: Afaik the PartTools don't work with .dds files. I use .png for the unity setup and exchange them with .dds files at the end (KSP can load .png as well). For the config your need a name (internal, must be uniqe) and a title (external, what you read ingame). Mesh colliders must be convex (check the box) and may not exceed ~250 faces afaik. For non-convex shapes you need multiple colliders.

There is a way to use emptys / gameobjects directly as attachment nodes. Haven't used that myself but you can find some infos here: The config nodes are pretty simple: // Node definitions - Position X, Position Y, Position Z, Up X, Up Y, Up Z node_stack_top = 0.0, 1.5, 0.0, 0.0, 1.0, 0.0, 2 node_stack_bottom = 0.0, -1.5, 0.0, 0.0, -1.0, 0.0, 2 node_attach = 0.0, 0.0, 1.3, 0.0, 0.0, 1.0 Stack nodes need 7 values separated by comas. First three numbers are for the coordinate (unity axis, Y is up), the next three numbers define the directions of the node and the last number is for the size of the stack node. The direction of a node is very important and can be 1 or -1. For a node on top of your model the direction would be 1 on Y-axis, for a node below your model the direction would be -1 on y-axis (as shown in the example above). The size can be 0 (for 0.625 m diameter parts), 1 (for 1.25), 2 (for 2.5) or 3 (for 3.75). Same goes for the attach nodes just without the need for a size. I've opened your Motor001.blend and the highest vertex is ~2.63 and the lowest ~0.66 on the Z-axis (make sure you see global and not local coordinates in blender). So the following should be a good start: node_stack_top = 0.0, 2.63, 0.0, 0.0, 1.0, 0.0, 2 node_stack_bottom = 0.0, 0.66, 0.0, 0.0, -1.0, 0.0, 2 Note that Blenders Z values are Unity/KSPs Y values.

Interstellar Fuel Switch has what you are looking for: With examples in the OP & download

It seems like the ModuleAnimationGroup breaks landing gear when both are on the same part. I wanted to make a Landing Leg with integrated Resource Harvester but as soon as I add the ModuleAnimationGroup, the lang gear stops working. In the VAB it stays retracted no matter how often I hit "deploy" and when I launch the Vessel, the Landing Legs stay deployed and can't be retracted. It doesn't matter if the part has multiple animations or not, a simple unconfigured Module is enough to break things. This example-patch breaks the stock medium landing leg: @PART[landingLeg1]{ MODULE { name = ModuleAnimationGroup } } I've tried fully configured ModuleAnimationGroups with all animations on the same object (in unity) and also with animations on different objects, but nothing works. ModuleAnimateGeneric doesn't break landing legs as far as I can tell. So is this a bug or by design or am I missing something? Couldn't find any information on the topic.

I'm glad you wanna give it a try! The recompiled version works with KSP 1.3.1 but requires CRP or a definition for Resource IntakAtm, othwerwise KSP won't start: [LOG 11:30:48.557] PartLoader: Compiling Part 'Squad/Parts/Aero/airIntakeRadialXM-G50/airIntakeRadialXM-G50/airScoop' [ERR 11:30:48.558] [ShipTemplate]: No Resource definition found for RESOURCE [WRN 11:30:48.564] Could not create PartResource of type 'IntakeAtm There seems to be a minor bug with the GTI MultiModeHarvester. The radial drill can extract ore without beeing deployed first.

Think I have to elaborate my situation a bit more: The mod will focus around hybrid rockets that use Aluminium and Silicon in combination with Oxygen as propellant. Resources can be extracted from Regolith (Al+Si+O2), Spodumene (Al+Si+O2), Alumina (Al+O2) and Silicates (Si+O2). One rocketmotor uses a slurry (Monopropellant) of Al/Si in LqdOxygen with different mixtures. For example Al/Oxygen slurry, Si/Oxygen slurry, Al/Si/Oxygen (50:50 Al:Si), and so on. It requires a lot of converters to cover all possible solutions and that's only for one motor. This is why I split the converters into resource extraction and propellant production. Atm I use the converting part only for resource extraction. The propellant production converters are put in the storage tanks. It works but is a bit hacky and not intuitive. The search for a better solution lead me to the converter-groups idea (I'm also open for other/better ideas, was just the first that came to mind). So to sum it, converter-groups would definitly be an improvement but only if it's not too much work