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

[kspbutitscursed]

44 minutes ago, ColdJ said:

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.

Thanks 

I was wondering if the you could have  a part that is deployable and have the wheel base be deployable with wheels node attached to it?

[ColdJ]

17 minutes ago, kspbutitscursed said:

I was wondering if the you could have  a part that is deployable and have the wheel base be deployable with wheels node attached to it?

If you make wheels that are just wheels, that aren't animated. Like the ones in my Mini Moke Versatile mod. You could attach them to a part that moves.

The problem is that you can't attach them to a standard animated part, as the nodes will not move with the animation.

To make this work you will need to have "Breaking Ground" installed and to make your own model of a piston, hinge or rotor.

The robotic parts don't use animation but rather modules that move various sub models in the part to other locations, pivoting in hinges and rotors, or sliding in a set direction. The attach nodes are locked to "Empties" in the .mu that are then moved by the modules through a set range.

So if you want to do what you are proposing then you will have to create robotic parts.

[kspbutitscursed]

1 hour ago, ColdJ said:

If you make wheels that are just wheels, that aren't animated. Like the ones in my Mini Moke Versatile mod. You could attach them to a part that moves.

The problem is that you can't attach them to a standard animated part, as the nodes will not move with the animation.

To make this work you will need to have "Breaking Ground" installed and to make your own model of a piston, hinge or rotor.

The robotic parts don't use animation but rather modules that move various sub models in the part to other locations, pivoting in hinges and rotors, or sliding in a set direction. The attach nodes are locked to "Empties" in the .mu that are then moved by the modules through a set range.

So if you want to do what you are proposing then you will have to create robotic parts.

ah ok 

can you show me what a robotics part looks like.

[ColdJ]

I will have to leave the computer in 15 minutes, so quickly, do you have "Breaking Ground" and BforA or Blender installed?

@kspbutitscursed

[kspbutitscursed]

yes i have blender and breaking ground

[ColdJ]

Ok Go to      Kerbal Space Program\GameData\SquadExpansion\Serenity\Parts\Robotics

and open     hinge_01.cfg

Then open Blender and import mu and import.

Kerbal Space Program\GameData\SquadExpansion\Serenity\Parts\Robotics\Assets\hinge_01_s.mu

Open up the heirachy so that you can see all the bits. Then look in the config file modules to see which names correspond to the bits that you can see in the heirachy.

On my windows 8.1 I can click on the open config on the task bar and drag it to the left so that I can see in the config at the same time as seeing the heirachy.

This will help you to understand what the modules are doing to the .mu model.

 

This bit in the module.

    MODULE
    {
        name = ModuleRoboticServoHinge
        servoTransformName = TopJoint
        baseTransformName = BottomJoint
        servoAttachNodes = top
        servoSrfMeshNames = COL2
        traverseVelocityLimits = 1, 180
        hardMinMaxLimits = -90, 90
        softMinMaxAngles = -90, 90
        targetAngle = 0
        maxMotorOutput = 200
        driveSpringMutliplier = 100
        driveDampingMutliplier = 20
        motorizedMassPerKN = 0.0003
        motorizedCostPerDriveUnit = 0.75
        connectedMassScale = 1
        efficiency = 0.75
        baseResourceConsumptionRate = 0.02
        referenceConsumptionVelocity = 180
        // if RESOURCE is used, negative power is simply dumped
        RESOURCE
        {
            name = ElectricCharge
            rate = 1
        }
        // INPUT_RESOURCE is by default equivalent to RESOURCE
        //INPUT_RESOURCE
        //{
        //    name = ElectricCharge
        //    rate = 1
        //}
        //OUTPUT_RESOURCE is required to reclaim energy from negative power
        //OUTPUT_RESOURCE
        //{
        //    name = ElectricCharge
        //    rate = 1
        //}
        mainAxis = X
    }

Relates to the node of the same name.

 

    node_stack_bottom = 0.0, -0.3125, 0.0, 0.0, -1.0, 0.0, 1
    node_stack_top = 0.0, 0.3125, 0.0, 0.0, 1.0, 0.0, 1
    node_attach = 0.0, -0.3125, 0.0, 0.0, -1.0, 0.0, 1

 

So that node will move as the hinge on that side moves.

@kspbutitscursed

Edited August 28, 2023 by ColdJ

[Lisias]

Found this on the WeekEnd, found it pretty. and pretty useful!

ATTENTION: This chart is wrong! The Y (green) and X (red) arrows are inverted on this chart! Their positive is on the other side (where the negative is on the chart) and vice versa!

Source: reddit.

Edited August 28, 2023 by Lisias
CHART IS WRONG! Sorry!

[ColdJ]

1 hour ago, Lisias said:

Found this on the WeekEnd, found it pretty. and pretty useful!

Hi. @Lisias Great little diagram but unfortunately the top part is back to front, as can be seen here.

As can be seen , the top in the VAB or front in the SPH ,SPH facing the open hangar door is positive Z in Blender or positive Y in Unity. The right side of the pod,(right side of the window.) is positive X and the left side negative X. The window side (which is the up side when spawned in the SPH) is Negative Y in Blender or Negative Z in Unity, while Positive Y Blender, Positive Z Unity, is down (SPH), the flag side.

Hope this helps, as otherwise all the node co-ordinates in your config would get confused.

[Lisias]

40 minutes ago, ColdJ said:

Hi. @Lisias Great little diagram but unfortunately the top part is back to front, 

[...]

Hope this helps, as otherwise all the node co-ordinates in your config would get confused.

Oukey, Houston we have a problem!

I will double check things this night.  I'm being royally screwed toying with a new engine, and what you said may explain why in hell my trustTransform is screwed.

Edited August 28, 2023 by Lisias
tyops. as usulla.

[ColdJ]

14 minutes ago, Lisias said:

I will double check things this night.  I'm being royally screwed toying with a new engine, and what you said may explain why in hell my trustTransform is screwed.

If it is a copy of the Squad transform in the .mu then for some reason they turn 90deg on export. Best to create your own or copy one out of one of my mods that have thrust. Mine are named MainThrust but really they are just an empty on layer 0, as long as the positive Y is pointing in the direction you want the thrust to push away from it will work correctly. You can check that by changing it to the Arrows view in "Object Data Properties" in Blender.

[ColdJ]

Just some info I am putting here about bogey setting that I found in old thread.

It turns out that the ModuleWheelBogey settings are pretty straightforward. They do what they say, with the caveat of the two axis entries being slightly non-intuitive. "bogeyAxis" defines which axis the foot is going to pivot around, at the ankle. But the axis is defined in terms of the parent object's (the piston's) coordinate space. "bogeyUpAxis" is more obvious, as it just defines which direction is "up" in the foot's own transform-relative coordinates. If you made your foot with the "blue" (Z) axis pointing down, then you use the stock-like setting of "bogeyUpAxis = 0, 0, -1".

 

This was a handy find, as a result I now have my first successful bogey landing gear with 2 axles.

Edited August 28, 2023 by ColdJ

[Lisias]

2 hours ago, ColdJ said:

If it is a copy of the Squad transform in the .mu then for some reason they turn 90deg on export. 

Ah! So it's this!

We may had found a bug on the mu_import code!

The mu_export is probably fine.

[ColdJ]

1 minute ago, Lisias said:

The mu_export is probably fine.

When I used to try to use them, I had to set them 90deg in the opposing direction to the way they would rotate. That way they ended up correct in game.

But as said, they are just a named Empty, so just make your own and they won't rotate on export.

[Lisias]

10 hours ago, ColdJ said:

If it is a copy of the Squad transform in the .mu then for some reason they turn 90deg on export. Best to create your own or copy one out of one of my mods that have thrust. Mine are named MainThrust but really they are just an empty on layer 0, as long as the positive Y is pointing in the direction you want the thrust to push away from it will work correctly. You can check that by changing it to the Arrows view in "Object Data Properties" in Blender.

Ha! I finally nailed it!! Thank you!

I was fighting two different problems!

1: Yeah, that Cheat Sheet was wrong. At the time it was created, KSP was using Unity 4. A few months later, KSP updated unity to Unity 5 (KSP 1.1.). I think things changed on this version, because I was able to read my files downto 1.1 using the io_object_mu with the exact same results (I'm looking on its code right now, and there's no specialised code).

Out of pure curiosity, the first 8 bytes identify the mu file (and version), being the first 4 bytes a "magic" with the value "FF 2A 01 00" (hex), and the next 4 bytes the version.

• Version 3 was used until KSP 1.1.3 (don't know the first version to use it, I have only down to 1.1.3 installed on my rig right now).
• Version 4 was used at least from KSP 1.2.2 (presumably from KSP 1.2.0, but I'm guessing as I don't have 1.2.0 neither 1.2.1 installed).
• The first use of Version 5 that I'm aware was with Making History parts (I have confirmed it on KSP 1.4.3 at least), and this format is being in used until 1.12.5 (the fireworks introduced by KSP 1.12.4 uses mu v5).

Eventually I will check older KSP versions, but right now I'm focused on other tasks.

2: Yeah, this Kraken damned thrustTransform/MainThrust/whatever. Thanks to you I realised I need to rotate the thing +90d in the Blender's Z Axis to get the thing working on KSP!! Thank you!

I will try to update the Cheat Sheet in the weekend and republish it.

Cheers!

 

 

[ColdJ]

Just another bit of info from an old thread, so I can find it again.

This module basically causes an object in the exported part to point at another object in the same part along its blue transform axis. I use it for pistons and similar things.

Each ConstrainLookFX defines one relationship. The rotatorName defines the object that will be rotated to point at the targetName (again, along the blue transform axis in Unity). Usually for a freely moving piston, two relationships are needed, one to cause the piston to point into the sleeve, and one to cause the sleeve to point into the piston:

MODULE

{

name = FXModuleLookAtConstraint

CONSTRAINLOOKFX

{

rotatorsName = Piston1

targetName = Sleeve1

}

CONSTRAINLOOKFX

{

rotatorsName = Sleeve1

targetName = Piston1

}

}

For good setup, you want to confirm 3 things

1) That the rotator object's blue transform axis is correctly specified for the pointing you want

2) That the pivot of the rotator object is located at the point where you want the rotation to occur

3) That the pivot of the target object is located where you want the rotator object to point.

Then, it's just a matter of exporting and ensuring the names are correct in the module

 

(In the case of blender it is the positive Y that is pointed towards the target name, here is an example taken from Squads "Large Gear"

    MODULE
    {
        name = FXModuleLookAtConstraint
        CONSTRAINLOOKFX
        {
            targetName = anchor2
            rotatorsName = link1
        }
        CONSTRAINLOOKFX
        {
            targetName = anchor1
            rotatorsName = link2
        }
    }

In the .mu as seen in Blender the rotatorName called "link1" has its Positive Y pointing at "anchor2" , the same is true "link2" pointing at "anchor1"

This allows the 2 child models, one above the suspension pivot and one below, to look to stay attached and scissor when the suspension moves up and down.)

 

[ColdJ]

Found out in creating working bogey style landing gear that I have had a misunderstanding about where the Wheel Collider needs to be in order for the wheel to look right and function when in game.

I had always thought that it needed to be inside the model that represents the wheel, when it is deployed. And I think this may still be the case in the wheels I make that are just wheels without any suspension towers.

But it appears that it does not need to be and is related to the suspension system in wheels that have visible suspension system that you want look as if a piston or spring is moving or bouncing.

I had wondered why in Stock Squad landing gear, the Wheel Collider wasn't actually placed where the wheel would be when deployed. My work on figuring out Landing Legs also opened my mind to this.

It seems that the distance between the centre of the Wheel Collider and the centre of the Wheel Pivot it is the distance that should be set as the suspension length in the suspension module.

    MODULE
    {
        name = ModuleWheelSuspension
        baseModuleIndex = 0  //This states the location of the module: ModuleWheelBase. 0 is the first location of the order, if you do not have ModuleWheelBase as the first module then you will need to change the number.
        suspensionTransformName = SuspensionPivot  //Named parent empty, everything within its heirachy will move up and down compared to anything above its heirachy.
        suspensionDistance = 0.1  //distance of movement of all below "SuspensionTransformName", now known to be related to distance between Wheel Collider and Wheel pivot.
        //suspensionOffset = 0.0  // This is used if you want the wheels to spawned higher off the ground when first loaded out into the world, e.g when spawned on to the runway.
        targetPosition = 0.4        // 0-1 scalar - determines the 'at rest' position of the wheel along the suspension travel. So when no load, e.g when having taken off. 1 is fully extended.
        springRatio = 70  // Spring strength. The higher the number the more load it can take.
        damperRatio = 2.0  // The higher the number, the slower the springs react, Low number = very bouncy
        // boostRatio = 0.65
        useDistributedMass = true  //relates to the modern wheel system, spreads the weight out.
    }

I measure this in BforArtists using the measuring tool, then put that into the config.

I can only make assumptions but either the Wheel Collider gets moved in game to the location of the Wheel Pivot, so that it may travel between there and it's original location, or the radius of contact is applied to the Wheel Pivot.

Either way, the wheels look right and function as they should in game.

[Lisias]

On 8/28/2023 at 2:58 PM, ColdJ said:

When I used to try to use them, I had to set them 90deg in the opposing direction to the way they would rotate. That way they ended up correct in game.

This 90d rotating stunt is a pain in the SAS.

I finally managed to animate properly a gimballed new… uh… 'engine' I'm doing. Man, what a fight.

I managed to accomplish it by:

1. Creating an empty node, calling it the name you will use on the Part config (thrustTransform, whatever)
2. Rotate it 90d on the Blender's Z axis
3. THEN you create/import/whatever the mesh and move it inside that node's hierarchy.
   1. In my case, I created a simple cone, resized it to fit inside the engine's mesh and move it there. I kept this cone without texturing, because I want to use it only as a reference, not to be displayed in game. Yet.  

Adding anything to the node's hierarchy before rotating it will completely screw up the results inside the game. And, yeah, I realised it by trial and error.

About the engine, I'm reusing some game assets on the process - so the trick is to import the "source" into blender, create your changes on a different hierarchy, and then export only your hierarchy on a new mu file. And then stitch things on the Part's config MODEL sections, one fetching the original asset from Squad or SquadExpansion (or whatever you are using from), and other MODEL section for your customisations built over it (using rotate, translate and scale to make things fit as you want). Less things to redistribute (when allowed) with your package, less things to load into user's RAM.

Now I need to learn how to deal with that GLOW stunt, to add cabin lights to some crewed parts… 

[ColdJ]

5 hours ago, Lisias said:

This 90d rotating stunt is a pain in the SAS.

You only need to do this if reusing Squads original thrust transform. I don't know why it does it. When you simply make your own out of a new, named empty, all you need to do is make sure that the Y positive direction of the empty is facing in the direction you want it to push away from, that is out the back of the engine. New empties dont turn 90 degrees on export like Squads do.

5 hours ago, Lisias said:

Adding anything to the node's hierarchy before rotating it will completely screw up the results inside the game. And, yeah, I realised it by trial and error.

When you move things from one heirachy to the next, they retain their orientation based on what was directly above them originally. So if the new thing they are under doesn't have the same orientation then they will change direction accordingly, but for some reason not show it till imported back in again. Thankfully @taniwha already made a fix for this. When what you just moved  is still highlighted, go up to the menu box named "MU HEIRACHY"

and click on it. It should have 3 options. Click on "Clear Inverse" and it will reset the orientation to how it currently looks.

When I re-parent things I do it this way: Left click hold the empty or model or collider etc and drag it over where you want it to be placed in, Hold down SHIFT and ALT, then release the left mouse button. This will keep it looking the same as before you moved it, out in the work space. Then go and click on "Clear Inverse". Using this method, things are as I left them when I import back in.

5 hours ago, Lisias said:

About the engine, I'm reusing some game assets on the process - so the trick is to import the "source" into blender

Always remember to reduce the vertices when you first import. Open up the entire heirachy so you can see everything. While holding down control, left click every model that you can see so they are all highlighted. Then switch from the "Object Mode" workspace to the "Edit Mode" workspace. Everything should be glowing. Then open the "Mesh" drop down menu, go down to "Merge" and choose the sub menu item "By Distance", this will remove all the extra vertices that is required by unity, and will allow you to edit models without weird results. When you export the .mu plugin will automatically create all the extra vertices needed by unity.

5 hours ago, Lisias said:

I finally managed to animate properly a gimballed new… uh… 'engine' I'm doing. Man, what a fight.

With a gimbal, it is the Module in the config that does all the work. Whatever you choose as your gimbalTransformName in the heirachy will have everything within its heirachy move as well, So the engine bell model and the thrust transform should be within the gimbals heirachy. There is no need to animate this in blender. The module manipulates the named transform in game.

    MODULE
    {
        name = ModuleGimbal
        gimbalTransformName = Gimbal
        gimbalRange = 5
         gimbalResponseSpeed = 30
         useGimbalResponseSpeed = true
    }

More complicated effects like expanding and contracting nozzles is not something I have attemptd to learn as yet.

5 hours ago, Lisias said:

one fetching the original asset from Squad or SquadExpansion

So if you mean, making use of textures already created by Squad by referencing them in the model like in Airplanes plus.

    MODEL
    {
        model = AirplanePlus/Parts/Command/144cockpit/model
        texture = placeholder, Squad/Parts/FuelTank/mk2FuselageShort/mk2FuselageShort
    }

Then you just need to be sure they haven't been moved. A lot of things ended up with broken textures when updates to KSP1 changed directories. I know this is unlikely to ever happen again but it is why I build my own. I may never get my off white to perfectly match Squads, but I get close. I also don't have the patience to make complicated textures so I usually just create a pallet texture and then assign parts of  model in "UV Texturing" to create the effect I want.

6 hours ago, Lisias said:

Now I need to learn how to deal with that GLOW stunt, to add cabin lights to some crewed parts…

2 ways to do this. The simplist is the way the Mk1 Inline cockpit works. You have to set the material properties to use the shader.

KSP/Emissive/Specular

You can set this up yourself using the instructions in this thread or you can reassign the material of your model to that of the Mk1 inline cockpit by having it imported at the same time and then going to "Material Properties" and changing what your model uses to what the Mk1 uses. You will still need to go down and change the 2 texture names to what you want to use. _MainTex to the main texture you wrap the model in and _Emissive to a version of the main texture that has everywhere you don't want to glow darkened and everywhere you do want to glow lightened. The module below uses the _Emissive texture to adjust the main to create the effect.

    MODULE
    {
        name = ModuleColorChanger
        shaderProperty = _EmissiveColor
        animRate = 0.8
        animState = false
        useRate = true
        toggleInEditor = true
        toggleInFlight = true
        toggleInFlight = true
        unfocusedRange = 5
        toggleName = #autoLOC_502011 //#autoLOC_502011 = Toggle Lights
        eventOnName = #autoLOC_502012 //#autoLOC_502012 = Lights On
        eventOffName = #autoLOC_502013 //#autoLOC_502013 = Lights Off
        toggleAction = True
        defaultActionGroup = Light
        redCurve
        {
            key = 0 0 0 3
            key = 1 1 0 0
        }
        greenCurve
        {
            key = 0 0 0 1
            key = 1 1 1 0
        }
        blueCurve
        {
            key = 0 0 0 0
            key = 1 0.7 1.5 0
        }
        alphaCurve
        {
            key = 0 1
        }
    }

The second method animates the lights so they can change colour. It is best to go in and study either the latest Squad spotlights or  my Cybertruck to see how. The part of the model you want to glow has to be separate from the main and the name of that section is used by the module to work. You would have to transfer over the section from an imported model that has it and then edit the model to the shape you want.

I would stick to the first method till you are feeling confident you know how everything interacts.

6 hours ago, Lisias said:

(using rotate, translate and scale to make things fit as you want).

It is best to change the scale of things in the "Edit Mode" workspace as it won't change the main scale. If you do resize in the main workspace then you will need to use option "Apply Scale", found in the "MU HEIRACHY" menu I referenced earlier. Just before you export. This will cause whatever is highlighted to be consider 1 to 1 to 1. If you choose the Top of the heirachy then it should apply to everyting below. Not doing this can cause unexpected things to happen.

[HIN0TORI]

When I try to import it to mu files using "io_object_mu" addon, I get this error.

Python: Traceback (most recent call last):
  File "/Users/HIN0TORI/Library/Application Support/Blender/3.6/scripts/addons/io_object_mu-master/export_mu/operators.py", line 68, in execute
    return export_mu(self, context, **keywords)
  File "/Users/HIN0TORI/Library/Application Support/Blender/3.6/scripts/addons/io_object_mu-master/export_mu/operators.py", line 39, in export_mu
    mu = export.export_object (context.active_object, filepath)
  File "/Users/HIN0TORI/Library/Application Support/Blender/3.6/scripts/addons/io_object_mu-master/export_mu/export.py", line 188, in export_object
    anim_root_obj.animation = make_animations(mu, animations, anim_root)
  File "/Users/HIN0TORI/Library/Application Support/Blender/3.6/scripts/addons/io_object_mu-master/export_mu/animation.py", line 301, in make_animations
    clip.curves.append(make_curve(mu, muobj, curve, path, typ))
  File "/Users/HIN0TORI/Library/Application Support/Blender/3.6/scripts/addons/io_object_mu-master/export_mu/animation.py", line 217, in make_curve
    mucurve.keys.append(make_key(key, mult))
  File "/Users/HIN0TORI/Library/Application Support/Blender/3.6/scripts/addons/io_object_mu-master/export_mu/animation.py", line 126, in make_key
    t1 = dy / dx
ZeroDivisionError: float division by zero

I think this error is caused by "ZeroDivisionError: float division by zero". dx in t1 = dy / dx is less than 0, and it doesn't work with division, right? But I don't know how to solve it. If I put an animation in the NLA Strips it doesn't work, if I remove all the animations it works. It works with just normal animation, so I think it is the object contrains that are causing it, but if I bake it, it also doesn't work. Do you know how to improve this? Is this due to the program or me?

[ColdJ]

On 11/1/2023 at 12:32 PM, HIN0TORI said:

When I try to import it to mu files using "io_object_mu" addon, I get this error.

Hi. I don't know what "It" is. Could you actually mean "Export"?

I do not know programming so you might get help on the thread of the creator of the .mu plugin if they are available.

Usually messages like that only appear if you have forgotten something or attempted to do something that can't be achieved via the plugin.

It sounds like you may have used Blender before trying out the .mu plugin. This can make it harder because there are other ways to animate things in Blender that don't work for KSP. Baking an animation in is not something you do when animating for KSP.

This is a link for the post where I try to describe how to do basic animation that works for KSP.

There are more complicated animations done by Squad that involve "Joints" but that is not something I have attempted. Most times "Constraints" are applied in the configuration file rather than in Blender.

I have tried to leave information through this thread as to what you need to have models work, like Quarternions and Eevee. If you haven't already read through the entire thread you may find something that is helpful.

Sorry I can't help more.

[HIN0TORI]

6時間前、ColdJは言った:

こんにちは。「それ」が何なのかわかりません。実際には「輸出」という意味ですか?

私はプログラミングを知らないので、利用可能な場合は、.muプラグインの作成者のスレッドで助けを得るかもしれません。

通常、そのようなメッセージは、何かを忘れた場合や、プラグインでは達成できないことをしようとした場合にのみ表示されます。

.muプラグインを試す前にBlenderを使ったことがあるようですね。これは、BlenderでKSPで動作しないものをアニメーション化する他の方法があるため、難しくなる可能性があります。アニメーションを焼くことは、KSPのためにアニメーション化するときに行うことではありません。

これは、KSPで動作する基本的なアニメーションを行う方法を説明しようとする投稿のリンクです。

「ジョイント」を含むスクワッドによって行われたより複雑なアニメーションがありますが、それは私が試みたものではありません。ほとんどの場合、「制約」はBlenderではなく設定ファイルに適用されます。

QuarternionsやEeveeのようなモデルを機能させるために必要なものについて、このスレッドを通じて情報を残そうとしました。スレッド全体をまだ読んでいない場合は、役に立つものが見つかるかもしれません。

ごめん、これ以上手伝うことができない。

I found "FXModuleLookAtConstraint" module. I think this is what you taught me about. I'll try this! Thank you!

[HIN0TORI]

What are these differences in MU shaders?
How do you use them differently? Please explain in as much detail as possible.

[ColdJ]

On 11/11/2023 at 12:39 PM, HIN0TORI said:

What are these differences in MU shaders?
How do you use them differently? Please explain in as much detail as possible.

I haven't got the time to go heavily into them right now but basically each does a different effect, like a matt paint look, or a shiny look, or allows for the effect that looks like the windows lighting up. Some allow for a part to look transparent. Some allow for a texture to combine with a bump map to create the illusion of dents or bumps. The best way to learn is to import in Squad or other models and have a look at what shaders they are using and the texture files that go with them. And then look at the same part in game to get an idea how they look. Remember that for things like the light up windows that they are combined with a module in the config file to work. Most Squad use .dds files, so they will appear upside down in blender, even though they will map right on the model.

.DDS vs .PNG used for your texture files.

KSP can actually work with a wide range of texture type files and even used to use an obscure one called .mbm

These days KSP has the easiest time when using .dds format. Only problem is that .dds are flipped vertically when compared to most other formats. Even though blender will flip it in Material View, it won't in the UV map workspace, so if you are working off a .dds, where you place your UV maps will not correspond in Material View as seen on your model. The answer to this is use a .png to start when you are mapping, once you have finished all your mapping and have your model textured as you want it. Open your .png in something like Paint.net and flip it vertically then save it as a .dds Make sure you flip it, not rotate it.

It is important that you save it as a"BC3 (Linear, DXT5)" type .dds for it to be used properly by KSP. The option shows up on the "Save Configuration" window when "Saving As" in Paint.net

Looking at how others have have used shaders is the easiest way to learn, it is how I worked out how to use them. If you make something simple like a cylinder and then export it many times, each time with a different shader set up and texture files, then you can compare. Simplist way is copying the material setup from an already existing model, save your cylinder into a unique folder and copy the texture files from the donor into it as well. Remember to create a config file for it. Just copy one for a structural piece and then edit the various details to match your .mu and folder, also remember to make sure each have a unique name in their config.

Very important. Make sure your model has a collider before you export or you won't be able to manipulate it in the hangar.

[HIN0TORI]

Thank you for taking the time to reply. I have tried importing other parts and everything is black. I want to express metallic textures, but I am having trouble when I find out that metallics can't be exported.

So I succeeded in expressing metal without metallic, but I can't export this well. Which MU shader do you think would be best to use to export this node?

[ColdJ]

On 11/15/2023 at 4:22 PM, HIN0TORI said:

Thank you for taking the time to reply. I have tried importing other parts and everything is black. I want to express metallic textures, but I am having trouble when I find out that metallics can't be exported.

Certain KSP shaders won't show unless you do this.

Seeing your texture in the editor

There is an issue with some of the KSP shaders that mean if you don't do a thing in the shader section, they will only show as all black in "Viewport Shading, Display in Material preview mode" which is one of the four ball choices up near the top right of the workspace. The one with the little red and white checker pattern. Usually when you click on this, any UV mapping you have done will show your texture pic applied to your model. But on KSP shaders that make use of the "Vertex Color" parameter you get the black unless you detatch the "Color" link. This is fine because unless you rename the title of your shader set up it won't be saved and will be linked next time you load it. (atleast on loading a previously exported .mu, haven't checked a .blend file yet.)

So with a part of your model that has been given a UV map and texture pic previously, highlight it and then bring up the shader workspace ( Tab on the top Header labeled "Shading") and you will see a number of of rounded end boxes with link cables connecting them.  Look for a red one named "Vertex Color" and click and hold on the yellowish link, then drag it away to detatch. Now when you have "Viewport Shading, Display in Material preview mode" selected, you should see your texture applied to your model, but only the parts that share the same material setup. If you have parts that use a different material you will have to unlink theirs as well if they also use a shader with the "Vertex Color" parameter.

 

On 11/15/2023 at 4:22 PM, HIN0TORI said:

So I succeeded in expressing metal without metallic, but I can't export this well. Which MU shader do you think would be best to use to export this node?

You can't create your own KSP shaders in blender, you can only adjust the ones that come with the .mu plugin.

The shader you want is "KSP/Bumped Specular (Mapped)" .  It can only be adjusted in "Float 3" which is found in the "MU Shaders" section under "Material Properties" Any other way won't save.

The shader requires the main texture and a darker contrast texture, along with a bump map that is the shade of purple that this shader uses.

The following example uses the exact same shader as a base. KSP/Bumped Specular (Mapped) , the exact same texure pics for Main, SpecMap and BumpMap on exactly the same mesh. The only difference is the editing of the nodes in the blender program using the .mu plugin and saving as a .mu with a different name. As you can see in game, 1 looks like a polished metal and the other a mirror.

metal setup.

mirror setup.

This is where the "Float 3 gets adjusted.

I will send you a message with a link to download a folder with the 2 spheres set up that you can play with and see in game.