Somewhere to put any knowledge learned about using the .mu plugin.

[Kurld]

3 hours ago, ColdJ said:

When using the thrust transforms from the original Squad parts, they seem to rotate 90 degrees on export for some reason. 

Also just do all rotations in quarternions. The rotation tools work in degrees, so it is easy to see how you have adjusted, but all changes will be recorded in the quarternions that the game uses.

OK, cool I was just wondering if there was something else I was missing that would lead to transforms flopping around or other bad behavior.

I am doing the adjustments to angles in degrees and then setting them back to quarternions after I'm done, which is what I think you're saying here.

I was able to tweak the part I was messing with the way I wanted so maybe I've forgotten less of Blender than I thought.

Thanks for your help!

[LeTrash]

Thank you a lot for all this documentation its been very helpful. I've run into one hurdle that I'm not sure where to turn though and wonder I if anyone has any ideas to fix it.

I've got an animation working in game on a part I've made however, I want the animation to loop continuously spinning on its Z axis, ideally without reversing. I animated a 0 to 720-degree spin in Blender over 180 frames and converted everything to quaternion. My code is very basic using the ModuleAnimateGeneric module and just defining the speed, layer and activeAnimationName. 

As far as I can gather without using the .mu plugin I would set the animation to looped in unity before exporting but I'm not sure how that transfers when using the plugin. I can't find any stock module that defines infinite spinning so I'm not sure if I need to use a 3rd party one or if I’ve gone wrong in Blender. 

Any help is much appreciated.

[Stone Blue]

@LeTrash I recently encountered this problem while trying to get SDHI Strobe Light mod working.

I came *close*... but the stock animation/light modules are very limited, and partially broken.

I found by looking at the stock Orbital Scanner part, it does what we need. But I still couldnt quite get it working. I think its all in how Unity and the ModuleAnimationGroup allow layering of animations.

See if you can figure that out, and you might be able to get your thing working.

Her'es the API page for that module: https://www.kerbalspaceprogram.com/ksp/api/class_module_animation_group.html

[ColdJ]

Hi @LeTrash.

In KSP it is easier to to do a looped animation using a module in the config. As @Stone Blue has said, the module used to make the orbital scanner turn when on will do the trick nicely. Then you can just turn your part on out in the world and it will keep rotating till you turn it off.

You don't need to do so many frames in order to get the effect unless you want it to turn very slowly.

This is an example from my Thunderbird 5 config to make the dish rotate. I left the stock names in so that it could use the Location file of KSP for other languages. You could just put "deployActionName = Activate" etc if you wanted.

    MODULE
    {
        name = ModuleAnimationGroup
        deployAnimationName =
        activeAnimationName = Dish
        deployActionName = #autoLOC_6001485 //#autoLOC_6001485 = Activate
        retractActionName = #autoLOC_6001957 //#autoLOC_6001957 = Deactivate
        deployActionName = #autoLOC_6002387 //#autoLOC_6002387 = Deploy <<1>>
        retractActionName = #autoLOC_6002388 //#autoLOC_6002388 = Retract <<1>>
        toggleActionName = #autoLOC_6002389 //#autoLOC_6002389 = Toggle <<1>>
        moduleType = #autoLOC_7001229 //#autoLOC_7001229 = Scanner
    }

You could also use the module to animate throttle and then treat the part as if it were an engine. You don't need to have thrust and could configure it to be instantly on once staged, only turning off if you click shutdown engine on it.

For Example. This makes my helicopter rotor spin.

    MODULE
    {
        name = FXModuleAnimateThrottle
        animationName = Rotors
        responseSpeed = 0.05
        layer = 2
        dependOnEngineState = True
        dependOnThrottle = True
        weightOnOperational = True
        affectTime = false
        baseAnimSpeed = 100.0        // base + (throttle setting * multiplier)
        baseAnimSpeedMult = 800
        playInEditor = False
        animWrapMode = 2      //    Default = 0    Once = 1        Clamp = 1    Loop = 2        PingPong = 4    ClampForever = 8
    }

Can't remember if you can use "animWrapMode = 2" in ModuleAnimateGeneric, but you could always experiment.

Hope this helps.

 

[LeTrash]

@ColdJ @Stone Blue

Thanks for the replies, I have tested with the ModuleAnimationGroup before but I'm going wrong somewhere because I cant get the activeAnimationName to play. Does it need to be a different animation to the "deployAnimationName"? Ideally I'd just use something like:

MODULE
    {
        name = ModuleAnimationGroup
        activeAnimationName = SpinAnim
        alwaysActive = true
        autoDeploy = true
    }

But nothting happens when doing this and coding isnt my strong suit. The animation based on throttle is a nice last resort though!

Edited March 1, 2023 by LeTrash
Accidentally sent

[ColdJ]

@LeTrash

I use what stock uses. Without clear documentation of all the variables that the modules can use, it is best to stick to what is proven to work.

[Stone Blue]

On 3/1/2023 at 9:49 AM, LeTrash said:

I have tested with the ModuleAnimationGroup before but I'm going wrong somewhere because I cant get the activeAnimationName to play. Does it need to be a different animation to the "deployAnimationName"?

Try leaving the *active* animation blank, and put your anim name in `deployAnimationName =`

IIRC, the stoc Orbital Scanner part which uses the module, has a "dummy" anim, that isnt keyed for any movement, that is the "active" anim... meaning its the one that is always active...*until the deployAnim gets triggered and takes over*...

Then its deployAnim is the one that plays when you activate/deploy the part.... *this is the one you want looped*, I believe...
It *should* continuously play, till you trigger the part again, to "deactivate" the anim...

Edited March 3, 2023 by Stone Blue

[LeTrash]

I guess I'm doing something stupid or there's some compatibility issue? Copying the scanner code exactly(I changed my animation name to Dish in blender too this time) I get no animation at all, when I set the deployAnimationName to Dish the animation plays once when deploying and when I click retract it reverses the animation. Leaving activeAnimationName blank has the same result. I don't know whats stopping my animation from working in the activeAnimationName field.

I tried shortening the animation to one full spin 0 degrees at 0 frames and 360 degrees at 90 frames which made no difference.

My blender structure is Empty>Empty(with animation)>Spinning Object.

I'll have to try taking it into Unity over the weekend and see if I can get it to loop when exported from there.

[ColdJ]

On 3/4/2023 at 4:19 AM, LeTrash said:

My blender structure is Empty>Empty(with animation)>Spinning Object.

Open up the stock scanner module (or my Thunderbird 5) in blender at the same time as their config and see how they are layed out. This is how I learned to make it work. Usually it is something subtle that we overlook, that trips us up.

[ColdJ]

Though I have the latest BforArtists (windows version) working by using W.I.NE, on my new Zorin OS (Ubuntu based).  When I originally tried installing the Linux version, first .deb then .tar, it seemed to install correctly, but when I clicked on the launch program, nothing would happen.

As I am brand new to using Linux I was wondering if @Stone Blue or @linuxgurugamer, or anybody else. Might have insight as to if there are other steps I have to do to make it work?

[Stone Blue]

I havent used Linux in a few years... Tho i *did* use Blender with it at the time... I have no no idea

[nascarlaser1]

Does anyone have a tutorial for using this plugin? I've found 1 tutorial about it but I'm running into a roadblock using it and I've not been able to find anyone who knows how to help me on discord .

Using Regular Blender Version 3.3.0

Edited March 22, 2023 by nascarlaser1
Blender Version Info

[ColdJ]

1 hour ago, nascarlaser1 said:

Does anyone have a tutorial for using this plugin? I've found 1 tutorial about it but I'm running into a roadblock using it and I've not been able to find anyone who knows how to help me on discord .

Using Regular Blender Version 3.3.0

Assuming you have read the posts on the first page of this thread and not found an answer, then ask about a specific issue you are having, and I or someone else knowledgeable will try to help you through.

[Stone Blue]

@nascarlaser1 I assume you've read the wiki on the repo?

[nascarlaser1]

@Stone Blue , @ColdJ turns out I was a dumby who forgot the basics of setting up UVs in blender. After spending 5 hours staring at my mesh tree I finally figured out why my texture was purple instead of an actual texture. My apologies!! 

[Kavaeric]

Hi @ColdJ, I've been learning to use the .mu exporter for Blender as well. I've been taking notes and things of what I learned and been compiling it into a Notion page:

https://kavaeric.notion.site/Notes-on-creating-engines-for-KSP-16f8338f483b473486ca9657674d85e2?pvs=4

Feel free to mirror any of the info. I'm still figuring out a bunch of stuff: right now, how mesh deforms/weight painting works, and later how to do animations. Note that most of it is more comprehensive about modelling and texturing, but hopefully there's still some good/new info in there about the exporter.

Edited June 10, 2023 by Kavaeric

[ColdJ]

Hi @Kavaeric

A very professional looking job. I will try to copy it across to here in a simple form so that members can read through without leaving the forum. Making it clear that it is your work.

The following are the pages created by @Kavaeric to explain processes they worked out for creating  parts with the help of the .mu plugin.

Notes on creating engines for KSP

 

 

I decided to write this as, being completely new to the whole process of modding KSP1, I found the documentation quite lacklustre. Many links were broken owing to changing hands and forum migrations; many creatives rarely publicly documented their production process. The process of learning to make an engine from start to finish was quite a difficult one as a result; we even had to re-discover lost techniques to building these rockets as if archeologists investigating ancient construction methods.

As such this page aims to consolidate what I’ve learned from building my own engines, as well as process and workflow tips to make things easier.

What this will and won’t cover

This note page will cover:

 

How to ideate and plan out an engine concept, both for visuals and balance.

 

How to produce an engine part with rich features such as working heat effects, shrouds, multiple variants, and Waterfall plume configurations.

 

How to guide development to follow a ReStock-, Near Future-, or CryoEngines-alike aesthetic.

 

Best practises for modelling in Blender, including workspace management tips.

 

How to UV unwrap and produce texture maps, and workflow tips to speed up the process.

 

How to write an engine config and build out feature and effects functionality.

I will try to be as comprehensive as possible. However, I will not give instruction on:

 

How to create models. I will cover considerations and workflow techniques specific to preparing a model for KSP, but otherwise I will assume you are comfortable working in Blender.

 

How to design textures. Again, I will cover the technical side of things, such as file format exports, and will give advice on how to create assets that feel congruent with ReStock or Nerteaverse parts. Otherwise, I will assume you already have a raster image editing software of choice and that you are comfortable using it.

In other words, I will give information regarding the technical side of things in regards to creating a part for the game and how technical requirements will affect your creative workflow. I won’t give information on creative aspects of learning how to 3D model or use image editing software.

What you’ll need

You won’t need all these things off the bat, but in case it helps to do a sort of mies en place for your development, you’ll need the following:

 

Blender with taniwha’s .mu export plugin. Installation instructions are available on the wiki. Using this plugin, we can bypass having to install Unity altogether.

 

The Blender plugin, Texel Density Checker. This will help us ensure we’re using our UV map resolution efficiently.

 

A raster image editing programme. I personally use Photoshop CC, as it’s what I’m already familiar with as an artist. Ideally, to make things easier, you’ll want something that has layer blending modes, layer effects, and filters.

 

A bumpmap to normal map converter. Tools like xNormal and NormalMapOnline work just fine.

 

A DDS converter. KSP uses DDS files for textures. One thing we lose from not using Unity and PartTools is a DDS exporter, so we’ll need something to export with. I personally like using the Nvidia Texture Tools Exporter as it can be installed as a Photoshop plugin or standalone app.

 

A text or code editor for editing our part configs. Something as simple as Notepad or Notepad++ works. Since I’m all fancy I use Visual Studio Code.

I’ll cover the specifics of each in more detail with each step.

 

 

Ideating

Modelling

Texturing

Export and Configuration

 

 

Additional techniques

--------------------------------------------------------------------------------------------------------------------------------------------------------------------

Ideation and Concept

 

 

Before we actually start making a part it’s a good idea to make sure you grasp what it is you’re trying to make. You might be tempted to dive right into smashing shapes together in Blender, but you can save yourself a lot of trouble if you at least check to make sure you have a firm grasp of your goal.

Balancing

To put it in business-y terms, what’s the value proposition of your mod? Why would people want to use it, and why do you want to make it? There’s no right or wrong answer to these questions, but things can change unexpectedly in your process and stuff is fluid; ensuring you know the why will help ground your decision-making.

In the case of engines, here’s some questions to mull over:

 

Is this meant to synergise with an existing mod? What do you have to do to make sure it feels congruent with the set?

 

Are you making this to address a gap in mods? Do existing mods exist? What’s lacking about them that you think you can do better?

 

Is this a very functional part, or do you want to focus on aesthetic quality? What kind of aesthetic are you going for? Are you trying for something stockalike, or something to look like an expansion of another, existing mod?

 

How will this balance? Do you even care about balance at all? What stats should it have? How will that affect the visual and physical design of the part?

Ideate and sketch ideas

Again, it’s tempting to just jump into Blender and start making stuff, but gathering visual inspiration, references, and sketches goes a long way to preventing creative block. Even spending half an hour doodling on a napkin or poking around Wikipedia can go a long way. Below are some sketches I did, along with some notes for the Swallow methalox engine. Some of these concepts I’ll probably even re-use for other engines.

 

 

 

Another method I found quite useful is to “kitbash” in the game for inspiration: take some existing engines, structural parts, engine plates, multi-couplers, whatever, and begin combining them in different ways to generate ideas.

Remember, asset creation is more of an art than a science at this point—be creative and let loose.

 

By @Kavaeric

Modelling in Blender

 

 

Now that you have your idea it’s time to actually begin the modelling process. Make sure you have both taniwha’s plugin and the Texel Density Checker installed and set up and ready to go.

Basic part modelling guidelines

To ensure a baseline level of consistency across your parts, you’ll want to adhere to the following:

 

Segment counts for round stack parts, i.e. round cylindrical/circular parts that will stack.

 

For 3.75m parts (size 3) and under: 24 sides.

 

For 5m parts and over: 36 sides.

 

Round objects like round struts and wires should have at least 6 sides.

 

Polycount

 

For Stockalike and Restockalike parts, <5,000 triangles.

 

High quality parts like that of Near Future Technologies or CryoEngines: <10,000 triangles.

 

Mount clipping. Basically, the top of your engine should have details like pipes and tubes that extend upwards past the mounting point, such that when placed on certain fuel tanks there’s no awkward gap.

 

Engine nozzles should be kept a seperate object if gimbal control is desired.

Oh, and remember that KSP’s part sizes are defined by diameter, but Blender’s circle and cylinder creation tools require you to provide a radius: if you are making a 2.5m part, for example, you’ll need to input 1.25m as the circular radius. You can also type in 2.5/2 into the field and Blender will do the maths for you.

Model for multiple variants

Depending on your ideation process you may want to incorporate multiple variants into your engine. We can prepare for this by considering what parts will change and what won’t with each variant. For example, most CryoEngines are modelled with the engine mount as a seperate object from the actual engine “body”, and the script merely toggles with mount is being used—this will save you a lot of work in the long run when creating multiple variants.

You can model each variant side by side, but they will eventually be placed on top of each other, parented to the same empty.

Control smooth and flat surfaces

Obviously as a game asset we can’t exactly do highly resource-taxing subd modelling, and hence we’ll need to smooth shade our model while ensuring we can still control our sharp edges.

There are a few ways to do this, but my preferred method is to set Auto Smooth to its maximum setting of 180 degrees, and use the Mark Sharp feature on any edges I want creased. I’ve seen others use Edge Split as well, but I prefer the former method as it doesn’t require me to stay on top of my modifiers stack, especially if using other features like Array or Mirror.

Prevent clipping into an engine shroud

It’s customary to make the engine mounting ring a tad smaller than the actual diameter of the stack size you’re working on, such that when an engine plate shroud, a fairing, or even your own shroud is placed over top, it doesn’t clip.

 

Edited June 11, 2023 by ColdJ

[ColdJ]

By @Kavaeric

Mesh Preparation

 

 

With all our meshes done, we should make sure things are parented and ordered properly in the hierarchy, ready for being placed in the game.

Place transforms and order your hierarchy

At minimum, you’ll need at least the following:

 

An empty with your part name. Parent your main engine mesh to it.

 

An empty named gimbal. The config uses this to determine the location of where your engine nozzle pivots when gimballing, if your engine has gimbal. Due to weird coordinate translations between Blender and KSP/Unity, rotate it so that its Y-direction is facing downwards. The gimbal empty should be parented to the main part empty, and the engine nozzle should be parented to the gimbal empty.

 

An empty named thrustTransform. This is where the “thrust” of your engine comes from and what direction it travels in. Rotate it so that the Z-direction is facing downwards, and position it so that it’s aligned right with the nozzle of the engine. Parent it to gimbal. Note this will also determine where the Waterfall plume will be placed, if you want one.

Generate colliders

Colliders both determine how the object should behave in rigidbody physics, as well as determining the “hover area” when interacting with the part in the VAB/SPH.

For each seperate mesh object in your part, select it, head into the active tools tab, and click one of the options (usually Single Collider: Mesh) to generate a collider. The tool will automatically parent and name the collider properly for you; you could probably just hide it from the hierarchy at this point.

 

Define stack attachment points

You’ll want two empties, one for the top and bottom attachment nodes each. Name them node_stack_bottom and node_stack_top. Make sure the bottom node empty is pointing downwards—using the “single arrow” empty type is helpful for gauging orientation.

Both of these should be parented directly to the main part empty.

These empties and their names will be used by the config to define attachment nodes.

Set up your engine shroud

If you have a custom engine shroud, its mesh should be parented to the main part empty. To make sure it doesn’t show up in the icon preview in the VAB/SPH, head to the object properties tab, find the Mu Properties rollout, and set Tag to Icon_Hidden. It will also need its own collider too.

 

 

By @Kavaeric

Preparing Materials and Shaders

 

 

Before we start texturing, it’s not a bad idea to set up the material and KSP shader you’ll be using for this. Ideally, you’ll want one material for the entire part, working off one UV map and one set of textures.

Taniwha’s plugin adds shader options that are lifted from the game, letting us configure the settings and with a (if somewhat inaccurate and crude) preview in Blender’s rendering mode.

Creating a KSP Shader

Create a new material that is applied to all the meshes of the part. Underneath the typical material settings, you will find a new section called “Mu Shader”, where the in-game shader settings are configured. Below is an example of a material setup for the Swallow:

 

Relevant settings are:

 

The Shaders drop-down should be set to ksp emissive bumped specular. Specular is for shininess control, bumped lets us use a normal map, and emissive lets us create engine (over)heating effects.

 

Name doesn’t matter much, but I like setting it to the same name as the Blender material name.

 

_MainTex is our diffuse/specular texture. Its Name should match that of the texture file (e.g., if the texture file in the GameData folder will be called MESwallowC.dds, I will set this to MESwallowC).

 

_Emissive and _BumpMap are our emissive and normal map textures. Similarly to _MainTex, their names should match the filenames of your emission and bump map textures.

 

_Shininess is pretty-self explanatory. The default value of around 0.08 is fine; we’ll control the specularity with our main diffuse texture.

 

By @Kavaeric

UV Unwrapping

 

 

When your model(s) are done, it’s time to UV unwrap to begin the texturing process.

Enforce texel density

Texel density refers to how many pixels per metre of texture resolution a mesh is provided. In general, Restockalike parts aim for a resolution of 200-300px/m, whereas Nertea’s other mods (such as CryoEngines) go much higher, in the region of about 400px/m.

Use Texel Density Checker to check and rescale UV islands to match desired texel density.

Unwrap round objects

It’s recommended that for simple conical or cylindrical objects, the UV map should be straightened a la an equirectangular projection. You can of course let the UV unwrap do its thing, but it’ll make actually creating the colour textures much easier if you’re just working with a rectangle rather than a strange distorted shape.

Using Blender’s cylinder project works okay in a pinch in producing squared-off maps. Here a boattail is unwrapped, first by centering the cursor, then switching to an orthographic view before the operation is executed:

By @Kavaeric

Texture Preparation

 

 

There are a few things we should do to make our texture creation process easier and richer.

Bake ambient occlusion

A good way to start texturing is to first bake an ambient occlusion map. We can overlay this onto our texture map for some added depth to our final texture.

Create a new material and name it something like “AOBake”. This won’t be put into the game; it’s purely for our purposes. Give it this node structure in the shader editor:

 

 

On the left, we simply have an Ambient Occlusion shader that feeds into the base colour of a Principled BSDF (a diffuse would probably work equally fine). The colour of the AO node is set to pure white.

 

On the right, the UVMap feeds into a new image texture that will hold our AO bake.

To bake the AO map:

 

Delete or otherwise hide all lighting sources.

 

Set the rendering engine to Cycles.

 

Set the World Colour to pure white.

 

 

 

 

Finally, if all is set, go back to the render tab and click Bake.

Save the new image. If you load it into your raster image program of choice, setting it to a “multiply” blending mode will let you overlay it on top of your texture artwork. I tend to also find it useful as it marks intersections of geometry, such as where a pipe might make contact with the outside of the boattail.

Export UV map grid

This isn’t necessary, but it can help a lot in terms of creating your texture art. In Blender, select all the meshes of the same part, and press Tab to go into edit mode. In the UV Editor, select all the parts of the UV Map. Go to the top menu, and find UVExport UV Layout.

If you bring the exported file into your image program and set its blending mode to something like Multiply, you’ll find that you now have a reference overlay for your texture creation process.

 

Create the Diffuse/Specular Texture

 

 

Visually speaking, this is the most important texture as it involves the actual colours of your map. In addition, the alpha channel (transparency) of the texture determines what parts are shiny and what parts are less so: the more transparent the texture is at a certain area (alpha channel black), the more matte the surface will appear in the game.

Note that if you are creating a Restockalike or Nerteaverse-like part, the license for art assets for those mods are protected as All Rights Reserved, meaning you can’t simply copy and paste or otherwise redistribute the textures. You can, however, still have them open as reference and try to make your own textures look similar.

Nertea has documented the standards for Restock’s art assets on the relevant Github wiki, including colour palette and technical modelling standards. Again, feel free to open up textures from your GameData folder if you’d like to see how they are applied.

Manage your layers

While each part can be quite different in terms of texturing, I find that structuring my layers in the diffuse colour map like so makes things easier down the line. Below are the layers and effects I use, organised from the bottom of the stack first, and usually in the order I work on/add them in:

 

 

Base colour

I start with a midtone grey underneath everything.

 

 

Graphite nozzles

Black carbon nozzles with a striated texture. The silhouette can be copied for the heat emission texture.

 

 

White hull

Slightly off-white panelling; some variants include a black-and-orange colour scheme. Usually with a subtle striated texture. The silhouette can be copied for the specularity map.

 

 

Panel seams

The seams themselves are 1 or 2-pixel-wide lines drawn in 20% grey. An outer glow layer effect with about 2px thickness and 40-50% opacity with some noise to adds extra texture. The silhouette can be copied for the normal map, and the outer glow effect can be copied for the specularity map.

 

 

Painted decals/markings

Add some wear around the edges, and use the appropriate colours to mark fuel type if making assets for CryoEngines/Nerteaverse. Can be copied for the specularity map.

 

 

Embossed details

Things like rivets and reinforcing braces, though you can be creative. Applying a very slight outer shadow adds to the effect of depth. Can be copied for the normal map.

 

 

Engraved details and holes

Dimples, depressions, and straight up-holes. Giving them a slight white “glow” with layer effects adds some extra texture. Can be copied for the normal map.

 

 

Wear markings

Any additional (usually light) wear markings, often following the edges of objects. Can be copied for the specularity map.

On top of all of that, the ambient occlusion map baked earlier is overlaid.

Create the specular map

Once your colour map is done, it’s time to make your specularity map and apply it to the alpha channel.

Create a new layer group, and fill the bottommost layer with a 50% grey. I like to add a bit of texture here by generating noise, box blurring by about 25px, and then gaussian blurring again by 10px.

If you set up your layers properly in the colour map step, you can simply copy relevant parts to the specular map stack, recolouring them with the correct shade of grey to match the desired specularity. For Restockalike/Nertealike parts, the following is recommended:

 

Wear marks and scratches should be set to white at 50%-100% opacity.

 

White panelling/hulls should be darkened to 25% grey.

 

Paint marks should be darkened to 25% grey.

Once done, you can simply flatten those greyscale layers and apply it as a transparency/alpha mask to your colour layer:

 

This texture here is now ready to be exported. Remember that its name should match the _MainTex name field in the .mu plugin’s shader options in Blender.

Create The Normal Map

 

 

Normal maps are actually kind of difficult to make by hand as they encode vector data. Luckily, we can make a much simpler bump or heightmap, and then convert it to a normal map using various tools.

In a bump map, white represents areas of high elevation, and black represents low. I found the following to be useful when transferring from the colour map:

 

Baseline grey level of 50%.

 

Panel gaps and divets should be 30% grey.

 

Everything else is up to your discretion.

Once done, export it as a PNG and use a tool like xNormal or NormalMapOnline to convert it into the customary bluish-psychedelic normal map we’ll need. Since we used 50% grey for our baseline level, make sure you specify that in your tool’s options: for NormalMapOnline, checking Z range: -1 to +1 will do this. Save this output, making sure the final name is set to that of _BumpMap in the mu shader options in Blender.

 

Part of a bump map for the Hestia I made by converting parts of my colour map.

 

 

The bump map converted into a normal map with NormalMapOnline.

Create The Emission Map

The emission map is what is used to create the engine heating glow effect as the engine runs hot from being used for an extended period of time.

The best method I found in Photoshop is to use a gradient map, set to a fiery gradient like below that transitions from pure black to a dull red to a bright orange:

• Pure black at 0% position
• Dull red #680000 at 25% position
• Mid orange #d53700 at 50% position
• Warm orange #ff9800 at 100% position

Underneath, I have a greyscale image I use to actually map the brightness of the heat radiation, with white creating that orange colour and duller greys leaning towards the red.

For a Restockalike/Nertealike look, the inside of the engine cone should get brighter towards the combustion chamber. The exterior should stay within reddish colours.

The name of the exported emission texture should match the _Emissive name defined in the mu shader properties in Blender. The animation for the heating effect emission will be defined in the config file.

Creating the Interior Engine Glow

 

 

Something Nertea invented was the “engine core” mesh that allowed for the inside of the engine to glow brightly when the throttle was on.

You can see how in this shot, the Buzzard engine at the top has a brightly glowing purple interior thanks to this engine core mesh effect. The Swallow on the bottom didn’t have this effect, hence why the inside of its engine nozzle remains quite dark:

 

 

To add the effect yourself, create a mesh inside the nozzle of your engine and name it EngineCoreGlow. It doesn’t have to conform to the inside perfectly and can be quite low-poly, but it’s best to match the number of sides to prevent any strange gaps. Ensure that the normals of the mesh are facing correctly (i.e. downwards), and parent this mesh to the gimbal empty alongside the engine nozzle.

Create a new material, and set its KSP shader to ksp alpha transluscent additive. UVMap the mesh to a colour gradient of your choice—preferably a colour that matches that of the engine plume—and you’re good to go! The animation transition will be defined in the config file.

 

 

Edited June 11, 2023 by ColdJ

[ColdJ]

Export Your Model and Textures

 

 

If all done correctly, we should now have:

 

Meshes and empties (main part empty, gimbal, thrustTransform, node_stack_bottom, node_stack_top) in correct hierarchy and given good names we can use in our config code.

 

An engine shroud if needed, correctly set up to be hidden in the VAB/SPH icon.

 

Colliders for all our meshes.

 

Working diffuse, specular, and emissive texture maps.

 

An engine core glow effect.

Time to export. Click on the main part empty, the one where everything is ultimately parented to. In the active tool tab, click apply scale and clear inverse—this ensures your part is of the correct scale and that any strange transformations are taken care of. Then, click export mu model.

 

Exporting your textures to .DDS

KSP can actually use .PNG image files, but they are slow and not great for load times. Instead, it’s better to convert them to .DDS. There are a few tools for this, but again, I prefer Nvidia Texture Tools Exporter as it can be installed as a standalone tool or as a Photoshop plug-in that lets me open DDS file right in Photoshop.

To export a KSP-ready .DDS texture, start by taking your texture (probably saved in a PNG format) and flip the texture vertically. For reasons I’m not sure, DDS files are flipped vertically; not doing so usually ends up with weird situations like that pictured on the right.

 

 

You’ll then want to use your tool of choice to save as a DDS. For parts, your normal texture must be exported as a DXT5_NM to prevent strange lighting artefacts. Otherwise, all other textures are to be saved as DXT5. In the Nvidia tool, these two settings are listed as BC3n and BC3 respectively.

 

 

Create a Config

 

 

The last step in our engine creation adventure is to build out the config, which is a special kind of text file that defines the stats and behaviour of this part. It’s customary to simply copy the config over from another part that is quite similar, so I won’t go over everything step-by-step. Nonetheless, I will mention some important key points.

Everything below unless otherwise stated will be inside the main PART module.

Model information

Inside the main module, you’ll want to define your part model here. Set model to whatever your .mu file is named; you don’t need to include the extension.

 

 

MODEL { // My model is called MESwallow.mu model = Swallow/Parts/Engine/MESwallow position = 0, 0, 0 rotation = 0, 0, 0 scale = 1, 1, 1 }

 

Attachment nodes

Most configs you might find will define their nodes using a coordinate system. Since we created the node_stack_top and node_stack_bottom empties in Blender, though, we can simply ask KSP to create nodes at those locations:

 

 

NODE { name = top transform = node_stack_top size = 1 method = FIXED_JOINT crossfeed = True rigid = False } NODE { name = bottom transform = node_stack_bottom size = 1 method = FIXED_JOINT crossfeed = True rigid = False }

 

ModuleEnginesFX

For any engine, the ModuleEnginesFX module defines how the engine actually performs as a propulsive device, including fuel consumption and efficiency.

For the PROPELLANT modules, you’ll need to define the fuel-oxidiser mixture ratio, which you can reference with the table below:

Engine configuration	Fuel	Fuel ratio	Oxidizer ratio
Stock LFO/kerolox	LiquidFuel	0.9	1.1
CryoEngines methalox	LqdMethane	3.0	1.0
CryoEngines hydrolox	LqdHydrogen	1.5	0.1

The atmosphereCurve defines the engine’s ISP at various atmospheric pressures. Each key consists of two numbers: the first being a pressure in Kerbin sea-level atmospheres, and the second being the engine ISP. For example, the following atmosphereCurve defines a vacuum-optimised engine that is very efficient in the vacuum of space but otherwise performs poorly at sea level:

 

 

atmosphereCurve { key = 0 350 key = 1 90 key = 4 10 key = 12 0.1 }

 

Gimbal control

Remember our gimbal empty in our Blender file? In our config we’ll use the gimbal module to define the thrust vectoring ability of our engine:

 

 

MODULE { name = ModuleGimbal gimbalTransformName = gimbal // gimbalRange is in degrees gimbalRange = 2.5 gimbalResponseSpeed = 30 useGimbalResponseSpeed = true }

 

Engine variants

We can use the stock variants system to switch between multiple variants of our engine, if you have them modelled and ready to go. In essence, all it does is switch on and off the meshes that are relevant to each variant. Below is some example code for switching between an engine that comes in both 1.25m and 2.5m form factors, toggling on/off two meshes named MyEngine_125 and MyEngine_250, and with the default size being 1.25m:

 

 

MODULE { name = ModulePartVariants useMultipleDragCubes = false baseVariant = Size1 VARIANT { name = Size1 displayName = 1.25m size primaryColor = #999999 GAMEOBJECTS { MyEngine_125 = true MyEngine_250 = false } } VARIANT { name = Size2 displayName = 2.5m size primaryColor = #ffffff GAMEOBJECTS { MyEngine_125 = false MyEngine_250 = true } }

 

Adding the heating effect

With our emissive texture set up, we can use the config to control how much of that emissive texture is shown, producing the effect of an engine slowly glowing redder from heat. Note how we are excluding EngineCoreGlow, as that will be controlled seperately:

 

 

MODULE { name = FXModuleThrottleEffects fxModuleNames = heatColor responseSpeed = 1.0 dependOnEngineState = True dependOnThrottle = True } MODULE { name = ModuleColorChanger moduleID = heatColor animRate = 0.025 shaderProperty = _EmissiveColor excludedRenderer = EngineCoreGlow toggleInEditor = false toggleInFlight = false redCurve { key = 0 0 1 1 key = 1 1 1 1 } greenCurve { key = 0 0 1 1 key = 1 1 1 1 } blueCurve { key = 0 0 1 1 key = 1 1 1 1 } alphaCurve { key = 0 0 1 1 key = 1 1 1 1 } }

 

Adding the engine glow effect

At the same time, we can add the code that will make our EngineCoreGlow shader glow and fade to the tune of the throttle:

 

 

MODULE { name = FXModuleThrottleEffects fxModuleNames = throttleColor responseSpeed = 1.0 dependOnEngineState = True dependOnThrottle = True } MODULE { name = ModuleColorChanger moduleID = throttleColor animRate = 1 shaderProperty = _TintColor includedRenderer = EngineCoreGlow toggleInEditor = false toggleInFlight = false redCurve { key = 0 0 key = 1 1 } greenCurve { key = 0 0 key = 1 1 } blueCurve { key = 0 0 key = 1 1 } alphaCurve { key = 0 0 key = 1 1 } }

Multi-Nozzle Engines

 

 

Multiple thrustTransforms

Each nozzle requires its own thrustTransform. Blender will automatically rename any objects that have the same name, and youl’l get empties named thrustTransform.001, thrustTransform.002, etc. Luckily, Taniwha was thoughtful enough to write code that accounts for this—when exported to the .mu model, they will all get renamed as thrustTransform. In the config, your ModuleEnginesFX will automatically take care of multiple thrustTransforms.

Multiple gimballed nozzles

If you’d like for each nozzle to gimbal independently, you can create one gimbal empty for each. In your config, simply create multiple gimbal modules, one for each transform you made. Remember to set up the hierarchy of objects and transforms properly—each nozzle and its respective thrustTransform and engine core effect mesh should be parented to its own gimbal here.

 

Creating Gimbal Arms

 

 

Adding gimbal arms, hydraulic pistons, and actuators are a great way to add a lot of character to your engine. It’ll take a bit of fiddling, but the results are satisfying.

Basic gimbal arm setup

Each gimbal arm consists of an upper and lower section. The movements of each are defined using an FXModuleLookAtConstraint.

 

Courtesy of JadeOfMaar

 

 

Courtesy of JadeOfMaar

As a more comprehensive breakdown, for a given arm assembly:

 

The upper arm is parented to the engine mount/main engine empty (fixed).

 

The lower arm is parented to the gimbal transform/engine nozzle (moving).

 

The lower arm slides up and down telescopically with respect to the “fixed” upper arm.

 

Within FXModuleLookAtConstraint, each arm member requires its own CONSTRAINLOOKFX. Each part needs to set itself as the rotatorsName, and be targeted to its corresponding arm with targetName. A single gimbal arm will have two CONSTRAINLOOKFX, one for the upper and one for the lower section of the arm.

 

[Kavaeric]

No problem! Glad I could be of help. I'd recommend for people to simply save or archive the Notion page; though I do make updates every now and again.

(and if you know anything about mesh deformations and animations for the .mu plugin let me know)

[ColdJ]

4 minutes ago, Kavaeric said:

(and if you know anything about mesh deformations and animations for the .mu plugin let me know)

I know some simple things, generally from looking at you tube videos. Sometimes they work well, sometimes not.

There is stuff that if you read through the entire thread can be found about creating animations.

I have to go in a sec to work outside. If you ask some specific questions here about animations I will try to answer them when I am next on.

I am a bit rusty as I haven't made anything for around six months and often have to go back and look at my own work or posts to remember how I did something.

But I will give it a shot.

I did also add the link to your pages in the updates post that is the second in this thread.

[ColdJ]

Basic Animation

This a basic demo of how to animate for KSP1 using the .mu plugin. I did it in BforArtists 3 but it should be true for normal Blender too. (I hope)

It is assumed that you know the basics of creating a model and applying material properties to your model so that it will show up in KSP. I took pics without having changed the rotation to Quarternions but corrected before export. Just didn't want to redo them all.

First I added an Empty, then a second which I moved into the first, then added a cylinder which I moved in to the second. I then duplicated the cylinder and resized its width, before moving it into the original cylinder. This ended up in the heirachy seen in the following pic. As you can see I have labeled each part to make clear and moved the inner cylinder down 1.5 meters. It is best to have the 2 empties for a number of reasons, but in this case it acts as a buffer to help make sure the animation works correctly.

Then we open up the Animation workspace and click on the input area down the bottom right that has a 2 keys symbol. This gives you a menu with choices as to  what sort of animation change you want to apply. In this simple animation I chose the simple "Location" option as I just want the inner cylinder to move up. I forgot to show it but the "Inner" model is highlighted in the heirachy.

I then click the single white key that can be seen next to where it says "End 250" to apply the starting point. This will cause the orange dots to appear beneath the green position line. The default is always frame one, but you can change it if you like.

You then left click hold the green line and slide it to where you want the next position to be. Frame 100 is always good for simple, one movement animation. Once you have it there you click on the movent option, just like you would in the main workspace, the 4 arrows in 4 directions and then move the part you want moved, in this case moving the "inner" up the "Z" axis, I move it 1.5 meters to return it to the same location as the "outer" so that it is fully inside it.

Notice how the Location co-ordinates on the top right change colour to show what you are doing. Now I click the white key symbol to put the orange dots on the frame I am on, that now has the "inner" moved to where I want it. This is the end position for this simple animation. In more complicated ones you can repeat this process on further frames for more complicated animations.

I then click on the Nla button as can seen in the next pic, so that I can name my animation.

Then double left click on the part that says "NlaTrack" to make it changeable and type in the name of the animation you want.

I then added my material properties before export and exported it. Before importing it back in to make sure it all worked and looks right. Then added some simple box colliders, one for each section. Before exporting. (Yes when doing big complicated models it is best to work on a ".blend" until you are ready to export, but you will need to check it before putting it in game, so as long as you use the "The Merge by Distance" option in the Editing Mode workspace on all your models in the import before export, you will be ok.)

I then created this config file using the basic "ModuleAnimateGeneric" module.
 

Spoiler

PART
{
    name = CJDemoPiston
    module = Part
    author = ColdJ
    MODEL
    {
        model = BlackBirdCJ/Parts/Demo Leg
    }
    scale = 1
    rescaleFactor = 1
    node_attach = 0.0, 0.0, 0.0, 0.0, 0.0, 0.0
    TechRequired = landing
    entryCost = 2900
    cost = 440
    category = Ground
    subcategory = 0
    title = Demo Piston
    manufacturer = CJ Aerospace
    description = Demo for basic animation.
    attachRules = 1,1,1,1,1
    mass = 0.5
    thermalMassModifier = 3.0
    dragModelType = default
    maximum_drag = 0.2
    minimum_drag = 0.2
    angularDrag = 2
    crashTolerance = 50
    maxTemp = 3000 // = 2900
    bulkheadProfiles = srf
    tags = piston leg
    MODULE
    {
        name = ModuleAnimateGeneric
        animationName = Piston
        startEventGUIName = Gear Up
        endEventGUIName = Gear Down
        actionGUIName = Gear
        defaultActionGroup = Gear
        layer = 1
        deployEffectName = deploy

        postDeployEffectName = deployed
 
        postDeployEffectLength = 5.0
        retractEffectName = retract

        postRetractEffectName = retracted
 
        postRetractEffectLength = 5.0

        animSpeed = 1

    
    }
}

The sound options are just left in from when I use the mod "ModuleAnimateGenericEffects".

The tried it out in game to make sure it works as expected.

For @Watermel00n and anybody else who would like to start animating.

Edited August 25, 2023 by ColdJ

[ColdJ]

Landing Leg Building.

Here is the set up that has worked for me to build a working landing leg. The two pics show the heirachy in BforArtists 3. Use them to compare to the config file I use to make them work in game. Notice which named parts correspond to various named sections in the modules. The order in the heirachy is very important and the distance from the empty "deployTgt" to the bottom of the landing foot is the figure that needs to go into         suspensionDistance = 1.03
                                      suspensionOffset = -1.03

Notice that the offset is the negative mirror of the distance. The distance is for when the leg is deployed and "deployTgt" is at its extended location, which is exactly where the Wheel Collider is in the 3D space. You can use the measurement tool to work it out in BforArtists. It is also critical that all animations are within the heirachy of the part name that you put in

    MODULE
    {
        name = ModuleWheelDeployment
        baseModuleIndex = 0
        
        animationTrfName = Base
        animationStateName = Deploy
        deployedPosition = 1
        deployTargetTransformName = deployTgt
        retractTransformName = Base
        
        TsubSys = 0.8

        fxDeploy = deploy
        fxRetract = retract
        fxDeployed = deployed
        fxRetracted = retracted
    }

In this case it is named "Base" and you can see it near the top of my heirachy. If you dont't make sure all animations are inside the heirachy from this point then the gear won't work. When the gear is extended then this distance is where the leg will sit on the ground and is different from your leg collider. Too long and your leg will float above the ground. Too short and it will sink in to the ground untill it hits a collider. It is best to have the lower leg collider not go to the very bottom and to have no collider on the foot. If you observe the stock landing legs then you will see that they sink in to the ground and then pop back up to position when deployed.

So here are the pics and config. These gear start in the closed position and animate to the open position inside the .mu  It is the config that starts with them open.

Spoiler

PART
{
    name = CJHugex15SkidA
    module = Part
    author = ColdJ
    MODEL
    {
        model = LegT/X19ASkid
    }
    rescaleFactor = 1
    mirrorRefAxis = 0, 1, 0
    node_stack_side = 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 1
    node_stack_top = 0.0, 0.14567, 0.0, 0.0, 1.0, 0.0, 1
    node_attach = 0.0, 0.14567, 0.0, 0.0, -1.0, 0.0, 1
    TechRequired = advLanding
    entryCost = 4900
    cost = 1520
    category = Ground
    subcategory = 0
    title = X15 Skid A
    manufacturer = CJ Aerospace
    description = Working?
    attachRules = 1,1,1,0,0
    mass = 0.2
    thermalMassModifier = 3.0
    // heatConductivity = 0.06 // half default
    emissiveConstant = 0.8 // a bit better than usual, because conduction needs some work
    dragModelType = default
    maximum_drag = 0.1
    minimum_drag = 0.1
    angularDrag = 1
    crashTolerance = 35
    maxTemp = 2000 // = 2900
    breakingForce = 250
     breakingTorque = 250
    bulkheadProfiles = srf, size1
    tags = x15 skid

EFFECTS
    {
        deploy
        {
            AUDIO
            {
                channel = Ship
                clip = Squad/Sounds/elev_start
                volume = 0 0
                volume = 1 0.5
                pitch = 0.9
            }
            AUDIO_LOOP
            {
                channel = Ship
                clip = Squad/Sounds/elev_loop
                volume = 0 0
                volume = 1 0.5
                pitch = 0.65
            }
        }
        deployed
        {
            AUDIO
            {
                channel = Ship
                clip = Squad/Sounds/elev_stop
                volume = 0 0
                volume = 1 0.5
                pitch = 0.8
            }
        }
        retract
        {
            AUDIO
            {
                channel = Ship
                clip = Squad/Sounds/elev_stop
                volume = 0 0
                volume = 1 0.5
                pitch = 0.9
            }
            AUDIO_LOOP
            {
                channel = Ship
                clip = Squad/Sounds/elev_loop
                volume = 0 0
                volume = 1 0.5
                pitch = 0.65
            }
        }
        retracted
        {
            AUDIO
            {
                channel = Ship
                clip = Squad/Sounds/elev_start
                volume = 0 0
                volume = 1 0.5
                pitch = 0.9
            }
        }
    }

    MODULE
    {
        name = ModuleWheelBase        
        wheelColliderTransformName = Wheelcollider        
        wheelType = LEG
        adherentStart = 0.01
        frictionAdherent = 0.1
        peakStart = 2
        frictionPeak = 1.0
        limitStart = 7.0
        frictionLimit = 1.0
        // setting this to true will override the radius and center parameters
        FitWheelColliderToMesh = False        
        radius = 0.1
        center = 0,0,0
        mass = 0.040
        autoFrictionAvailable = False            
        clipObject = ShoveyCol
        tireForceSharpness = 1
        TooltipTitle = Landing Leg
        TooltipPrimaryField =
            
        groundHeightOffset = 1
    }
    MODULE
    {
        name = ModuleWheelSuspension
        baseModuleIndex = 0
        suspensionTransformName = Shovey
        suspensionColliderName = ShoveyCol        
        suspensionDistance = 1.03
        suspensionOffset = -1.03
        
        targetPosition = 1    // 0-1 scalar - determines the 'at rest' position of the wheel along the suspension travel    
                    
        springRatio = 45
        damperRatio = 2
        boostRatio = 0.75
        maximumLoad = 70.0        
        extendDurationFactor = 0.5
        retractDuractionFactor = 0.5
        useDistributedMass = true
    }
    MODULE
    {
        name = ModuleWheelDeployment
        baseModuleIndex = 0
        
        animationTrfName = Base
        animationStateName = Deploy
        deployedPosition = 1
        deployTargetTransformName = deployTgt
        retractTransformName = Base
        
        TsubSys = 0.8

        fxDeploy = deploy
        fxRetract = retract
        fxDeployed = deployed
        fxRetracted = retracted
    }
    MODULE
    {
        name = ModuleWheelLock
        maxTorque = 50
    }
    //MODULE
    {
        name = ModuleWheelBogey
        baseModuleIndex = 0
        
        bogeyTransformName = Shoe
        deployModuleIndex = 2
        
        maxPitch = 10
        minPitch = -10
        restPitch = 0
        pitchResponse = 100
        
        bogeyAxis = 0, 0, 1
        bogeyUpAxis = 0, 1, 0
    }

}

For @Watermel00n and others who are interested.

[kspbutitscursed]

Question I am planning on making a Mars perseverance rover mod which will have foldable boggies for the wheels of the rover i wondering if it would be possible that one the rover is folded up and when the boogies deploy i was wondering if there was a way to make the wheels thamself stay attached to the boogies?

currently in the early phase of modeling the rover ATM

[ColdJ]

1 hour ago, kspbutitscursed said:

Question I am planning on making a Mars perseverance rover mod which will have foldable boggies for the wheels of the rover i wondering if it would be possible that one the rover is folded up and when the boogies deploy i was wondering if there was a way to make the wheels thamself stay attached to the boogies?

You may need to edit this question to make it a bit more clear but I will try to answer what I think you are asking.

I personally have not attempted more than one axle on a bogey but I have been looking at Squads Large Landing Gear, comparing the config file to the .mu model in BforArtists.

Firstly, the way an animated wheel that can fold away works. The wheel you see in game is just a model that rotates around a named "Empty" . The name you have chosen for that empty is written in the Module called

ModuleWheelBase

Here is how it is written in the "Small Gear" made by Squad.

    MODULE
    {
        name = ModuleWheelBase
        
        wheelColliderTransformName = WheelCollider        
        wheelTransformName = WheelPivot
        useNewFrictionModel = true
        wheelType = FREE

        // setting this to true will override the radius and center parameters
        FitWheelColliderToMesh = False        
        radius = 0.18
        center = 0,0,0
        mass = 0.040
        groundHeightOffset = 1.15
                
        TooltipTitle = #autoLOC_502079 //#autoLOC_502079 = Retractable Landing Gear
        TooltipPrimaryField = #autoLOC_6004046 //#autoLOC_6004046 = Retractable
    }

The "WheelPivot" written here is the name used in the .mu model and it is the lowest "Empty" in the heirachy as everything below it will rotate around this point. Your wheel pivot empty can be named anything you want, as long as you write the name exactly the same in the module. for example

        wheelTransformName = Rotate

As long as your "Empty" in the .mu is named "Rotate" to match, it will work.

Now this "Empty" and the model below it can be moved when a model or Empty higher up the heirachy is animated to move.

The actual thing that affects the rolling contact on the ground is the "       wheelColliderTransformName = WheelCollider    " in this case it is named "WheelCollider" but again it could have a different  name as long as it matches  the name of the collider you have in the .mu  When you look at Squads model in BforA or Blender you will see that the wheel collider is under the very top of the heirachy but outside the heirachy that all the rest of the model is under. It is a special collider that is on a specific "layer" and you can either copy one from a previously created wheel model or you can add one using the "ADD" menu that is on the bar, third from the top in BforA in the main work space, e.g  Add/Mu Collider/Wheel

Once added it can have it's attributes adjusted in the "Object Properties" section. (in BforA this is the little orange cube on the right of the work space.) Generally you only need to adjust the Radius setting to the size you want, this is also the only place you should resize it. It should be created with "Separate" ticked and the "Layer" set to 27.

With animated to fold up wheel models there is an "Empty" that is called "deployTgt" in all Squad versions (I choose not to change this name), that is placed in the heirachy so that it will move with the animation. When the model is in its fully deployed position the "deployTgt" empty should be in exactly the same 3 dimensional location as the centre of the wheel collider. The corresponding module in the config is

    MODULE
    {
        name = ModuleWheelDeployment
        baseModuleIndex = 0
        
        animationTrfName = Small
        animationStateName = LandingGearSmallDeploy
        deployedPosition = 1
        deployTargetTransformName = deployTgt
        
        TsubSys = 1.0
        useStandInCollider = True
        slaveModules = 8
        
        fxDeploy = deploy
        fxRetract = retract
        fxDeployed = deployed
        fxRetracted = retracted
    }

Squad seem to get away with the begining of the animation being the closed position, but I have found this glitchy when I make them so I always have my animation start in the open position. So for mine in that module I have this set this way.

        deployedPosition = 0

So the short version is: You can animate your model to fold the wheels in any way you like, as long as the "deployTgt" empty is where the wheel colliders centre is when deployed.

The wheels have to be their own part, not part of the rover model. The orientation of wheels model has to be the same in the .mu as all other wheel models you may look at, because the game uses that to determine what way up the wheels are, and as you would know, wheels don't work at 90deg or 180deg.

 

If you want to know about having multiple wheels on a bogey, you will need to give me time to investigate and experiment, as I haven't tried it before. But if you look at the Squad configs and models for their large and extra large wheels (landing gear) it might help you.

I hope this post will help you.