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

[Lisias]

3 hours ago, ColdJ said:

@Lisias

How hard would it be for you to add the ability to "AnimateGeneric" of looping the animation?

That's a great idea... I wish I had thought of it before!

There's the isOneShot property that I think may do the trick, but it's not persistent - so there's no point on trying to setting it on the Config node.  So I'm guessing that programatically setting it to False may do the trick.

Worst case scenario, I trap the OnStop KSPEvent and trigger the Animation again.

Are you talking about the propeller for your biplane?

 

[ColdJ]

3 hours ago, Lisias said:

Are you talking about the propeller for your biplane?

No, that is handled by the "FXModuleAnimateThrottle" module, which does have the ability to loop, as does the one used for rotating scanners. I haven't configed my Biplane yet as I am slowly chopping it up so as to have realistic aerodynamics once finished. But here is the one for the Zeppelin engines that are proven to work. I have adjusted the way I animate rotors to per single frame, and then the degree of rotation for speed of the rotor. The last frame should be short of a full rotation by the amount of degrees you have been putting per frame, then when it resets to the start it jumps by the same amount and looks fluid.

    MODULE
    {
        name = FXModuleAnimateThrottle
        animationName = Rotor
        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
    }

I can't say that         baseAnimSpeed = 100.0        // base + (throttle setting * multiplier) and baseAnimSpeedMult = 800 have ever made a decent amount of difference in game, so you have to rely of you .mu animation.

 

The reason why I ask is that it used to be possible to animate lights and other things with a looped animation before something got changed in an update.

There are a number of mods that used to work that had rotating safety lights. Both @Manul and myself are interested in being able to have the ability to create them again, but currently you would have to config them as a throttle or a scanner in order to get them to loop.

As those 2 modules have the ability to loop I have hope that a programmer like yourself might be able to add the option to the "ModuleAnimateGeneric" so that this and other things you would like to have a looping animation are possible again.

 

P.S

I actually sent you a PM last Monday, asking about this. I think there may be a problem in the PM system related to the server troubles.

[Manul]

1 hour ago, ColdJ said:

"ModuleAnimateGeneric" so that this and other things you would like to have a looping animation are possible again.

The answer is FSanimateGeneric. Parts that use this module still have looping animations.

[ColdJ]

2 minutes ago, Manul said:

The answer is FSanimateGeneric. Parts that use this module still have looping animations.

Do you need to make Firespitter a dependency for this?

[ColdJ]

@Manul

Could you pop up a working example of the module so I can see how it is layed out please?

[ColdJ]

Only found this so far.  https://docs.google.com/document/d/1iD52DfHft04Hb48TEhF5a4n5JOc8efUevdg5Y_QPICQ/edit#heading=h.h0s8ttjh2reb

FSanimateGeneric

This is a replacement module for the stock ModuleAnimateGeneric. In addition to the functionality of that module, this one supports:

-Custom Action name.

-Can start deployed, or toggle the animation in the hangar, via popup menu in the Action editor.

-Custom animation speed

-EVA context menu actions

-Handles more than one animation per part

-The animation can be reversed mid deployment

 

Does not support:

-isOneShot

-Locking the animation while running

 

MODULE

{

name = FSanimateGeneric

 

// The name of the animation in Unity

animationName =

 

// if you want a faster or slower playback speed without having to redo the anim, adjust this. 1 is normal speed

animSpeed = 1

 

// The right click anim start Event name while in flight. Can be anything

startEventGUIName = Deploy

 

// The right click anim reverse Event name while in flight. Can be anything

endEventGUIName = Retract

 

// optional Action editor name. e.g. “Toggle Animation”. Defaults to the above Event names.

toggleActionName =

 

// If true, the part starts at the end of the animation in SPH and in flight, (unless altered in the action editor)

startDeployed = False

 

// GUI text for the hangar starting state toggle

startDeployedString = Start Deployed?

 

// animation speed multiplier. 1.0 is the default speed. Does not care about custom Unity animation speeds.

customAnimationSpeed = 1.0

 

// Is the right click menu Events available while on foot?

availableInEVA = False

 

// Is the right click menu Events available while controlling the craft?

availableInVessel = True

 

// The range the action is available in EVA

EVArange = 5

 

// Animation Layer. If you have more than one animation on a part, this must be unique for each one in order for them to not interrupt each other. If the stock engine heat animation module is used, that’s probably on layer 0, so make this 1 or higher.

layer = 1

 

// If true, clicking on the part in the Action Group editor pops up a menu asking if the part should start deployed. Also useful for things like cargo bay doors where you want o to open them to place stuff inside, then close before launch.

useActionEditorPopup = True

 

// If you have more than one FSanimateGeneric on a part, give each a unique ID to. This makes the popup menu appear in a separate location for each module, and not steal each others windows. values: 0-9.

moduleID = 0

 

// To make it obvious that this part has animation abilities, the animation can play once, from deployed to retracted state when the part is spawned/loaded. This only happens in the editor, not in flight.

playAnimationOnEditorSpawn = True

 

// Set the default location of the hangar GUI window (Optional)

defaultWindowRect = 550, 300, 150, 100

 

// play a named part effect from an fx node when in different states of delpy/retract. Meant for sounds, but any fx should work.

fullyRetractedEffect = 

fullyDeployedEffect = 

startDeployEffect = 

startRetractEffect = 

 

}

[ColdJ]

Found this from a post in 2015

It is a long waited complex animation module. But there is no any info for us, modders.

MODULE

{

name = ModuleAnimationGroup

deployAnimationName = Your_deploy/retract_animation (as it seems)

activeAnimationName = Looping_animation_for_active_state (as it seems)

deployActionName = Activate

retractActionName = Deactivate

moduleType = Scanner/Drill/... What else?

}

 

---

Actually found out.

- moduleType is just a string to be displayed in buttons: "{deployActionName} {moduleType}" and "{retractActionName} {moduleType}"

- you can skip deployActionName and retractActionName, they default to "Deploy" and "Retract".

- activeAnimationName DO start and stop looping animation, which is great. It actually follows the state of ModuleResourceHarvester and ModuleResourceScanner.

- you can skip deployAnimationName to only use looping animation. However not sure if loop can be started/stopped manually.

When combining both looping and non-looping animation in editor - ensure that during the wanna-be-looping part of animation everything else is stuck in deployed position. Then just divide your animation in two clips in Unity.

If you work in Blender and your loop looks weird - go to "File->User Preferences->Editing->New F-curve defaults" and set Interpolation to Linear. Then delete all loop keyframes and make new ones.

 

This the scanner module setup.

 

    MODULE
    {
        name = ModuleAnimationGroup
        deployAnimationName =
        activeAnimationName = miniscanner
        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  // seems to link it to the scanner module.
    }

[Lisias]

1 hour ago, ColdJ said:

Do you need to make Firespitter a dependency for this?

Yes. At very least, FirespitterCore.(a trimmed down version installing only the Assembly and needed boilerplate, no parts).

[NippyFlippers]

15 hours ago, ColdJ said:

Yes, but you assign them in material properties in Blender. (Using the fork BforArtists is easier and makes it easier to help you if you need help with things.)

Starting to use the .mu plugin but having had previous experience using"Unity" or "Blender without using it for KSP" actually works against you. There are things that you do in those creators that don't work, or work in the same way when using the plugin. Don't worry about baking in when it comes to textures or animations. It doesn't work that way for this method.

I have actually answered your question but I fear that Manul may have confused things because they are used to the way Unity works and you can't apply those methods for this.

So having used KSP/ALPHA/TRANSLUCENT/SPECULAR I have created a demonstration for you. There are 6 identical cubes, they all use the same shader and the same colour but I have put 6 panels on the texture pic, starting from completely opaque and becoming less so for each panel in turn.

And as you can see in my pic you have different levels due to this.

Your posts of config show that you are using an older method of doing things.

    mesh = FlyingBoatServiceBay

Should not be used anymore as no matter what you write as the name of the .mu file it will use the first mesh it comes across in alpabetical order in the folder.

In any new config always use "MODEL" as it makes it clear to the config which .mu to use and you can even put your .mu in another folder as long as you make the path clear.

You only ever need to put the texture locations in the MODEL if they are not in the same folder as the .mu and of course you need to have them setup in your .mu material properties.

This is the config for the test I did, note no need to tell the config what texture to use.

 

  Reveal hidden contents

PART
{
    name = CJTestBed
    module = Part
    author = ColdJ
    MODEL
    {
        model = HotAirBalloon/Biplane/TestBed1
    }
    scale = 1
    rescaleFactor = 1
    PhysicsSignificance = 1
    node_stack_top = 0.0, 0.1287344, 0.0, 0.0, 1.0, 0.0, 0
    node_stack_bottom = 0.0, -0.1287344, 0.0, 0.0, -1.0, 0.0, 0
    node_attach = 0.0, -0.1287344, 0.0, 0.0, -1.0, 0.0, 0
    TechRequired = precisionEngineering
    entryCost = 5800
    cost = 16
    category = Structural
    subcategory = 0
    title = TestBed
    manufacturer = CJ Auto Instruction
    description = A test for opacity
    attachRules = 1,1,1,1,0
    mass = 0.001
    dragModelType = default
    maximum_drag = 0.2
    minimum_drag = 0.2
    angularDrag = 2
    crashTolerance = 7
    maxTemp = 2000 // = 3000
    bulkheadProfiles = size0, srf
    tags = #autoLOC_500774 //#autoLOC_500774 = connect cube frame girder scaffold structur truss
    MODULE
    {
        name = ModuleCargoPart
        stackableQuantity = 3
        packedVolume = 14
    }
}

Your use of

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

While still valid and used for robotic parts is not needed, and simply using the    "node_stack_top = 0.0, 0.1287344, 0.0, 0.0, 1.0, 0.0, 0" method gives you much more versatility, and allows you to change things without having to edit the .mu you have created.

Some Preset shaders that come with the .mu plugin can have some amounts adjusted in the right hand panel ( I have done this for KSP Bumped Specular Mapped to go from a metallic sheen to a mirror finish) but generally should not be messed with and just left as they come.

SO I hope once you have read this and tried what I have told you that you will get the result you want.

Well, moisten my crumpets and call me Betty!

I found the error. I forgot to name the material below the Field "Name: _MainTex" in Mu Shader tab.

I hate that it does not explain why it has to have two names, '_MainTex' and 'customNameByMe'. This is so confusing.

But you answered quite a few questions for me and I am much less confused now. Great thanks for the help, mate!

 

[ColdJ]

6 minutes ago, NippyFlippers said:

But you answered quite a few questions for me and I am much less confused now. Great thanks for the help, mate!

Glad I could help.

Do you know about buoyancy and faking the drag cube so things sit in the water more realistically?

This is a complicated one. You can to a small extent make things more likely to float or sink through the use of the parameter "buoyancy =" . 0 for not buoyant and up to 1.5 for most buoyant. The config for the stock Mk1 pod has a good example. But it is the mass of the object vs it's Drag Cube that play the biggest part. The drag cube is determined by the mesh volume not by it's colliders. If you don't have a specified Drag Cube in your config file then the game auto calculates on loading up. If the mass doesn't overcome the Drag Cube then it floats. The simplest thing to do if you want something to sit lower or sink in the water is to go into the PartDatabase text file in the main Kerbal Space Program folder, find a part that has a smaller but similar drag cube and copy it's auto calculated drag cube into your config. The game will use the Drag Cube you have in the config and so there will be less surface area vs the mass of the object calculated and it will be more likely to sink or sit lower in the water. Best not done on wing parts as the Drag Cube also affects flight/lift characteristics.

Additionally the drag cube determines where the outer surface is on a mesh, and so how it sits on the water. That means that a ship will sit on the very edge of it's keel on the surface of the water and look very unrealistic. To overcome this when making your 3D model make a second one and from the wanted water line to the bottom of the hull, remove that area of mesh from the model. Load it up and then retrieve the game calculated Drag Cube. Put this Drag Cube in your config for your original and then your original will sit at the waterline you chose instead of on the keel edge.

[NippyFlippers]

28 minutes ago, ColdJ said:

Glad I could help.

Do you know about buoyancy and faking the drag cube so things sit in the water more realistically?

This is a complicated one. You can to a small extent make things more likely to float or sink through the use of the parameter "buoyancy =" . 0 for not buoyant and up to 1.5 for most buoyant. The config for the stock Mk1 pod has a good example. But it is the mass of the object vs it's Drag Cube that play the biggest part. The drag cube is determined by the mesh volume not by it's colliders. If you don't have a specified Drag Cube in your config file then the game auto calculates on loading up. If the mass doesn't overcome the Drag Cube then it floats. The simplest thing to do if you want something to sit lower or sink in the water is to go into the PartDatabase text file in the main Kerbal Space Program folder, find a part that has a smaller but similar drag cube and copy it's auto calculated drag cube into your config. The game will use the Drag Cube you have in the config and so there will be less surface area vs the mass of the object calculated and it will be more likely to sink or sit lower in the water. Best not done on wing parts as the Drag Cube also affects flight/lift characteristics.

Additionally the drag cube determines where the outer surface is on a mesh, and so how it sits on the water. That means that a ship will sit on the very edge of it's keel on the surface of the water and look very unrealistic. To overcome this when making your 3D model make a second one and from the wanted water line to the bottom of the hull, remove that area of mesh from the model. Load it up and then retrieve the game calculated Drag Cube. Put this Drag Cube in your config for your original and then your original will sit at the waterline you chose instead of on the keel edge.

I have not the slightest idea how to do that buoyancy stuff. I have no idea what a drag cube is and how to configure one in the plugin.

I hope I can figure it out as I go along. IRC buoyancy module needs Firespitter and user Lisias can help you since he takes care of Firespitter?

How does that dependecy even work? How make I use of that?

@Lisias (how do I mention a user here)

Edited June 26 by NippyFlippers

[ColdJ]

@NippyFlippers I just gave you all you need to make it work. All in stock, no need for a plugin.

Please read what I gave you. I had to work that all out over a couple of years as nobody ever gave me a straight answer when I asked.

38 minutes ago, ColdJ said:

The simplest thing to do if you want something to sit lower or sink in the water is to go into the PartDatabase text file in the main Kerbal Space Program folder, find a part that has a smaller but similar drag cube and copy it's auto calculated drag cube into your config.

 

38 minutes ago, ColdJ said:

That means that a ship will sit on the very edge of it's keel on the surface of the water and look very unrealistic. To overcome this when making your 3D model make a second one and from the wanted water line to the bottom of the hull, remove that area of mesh from the model. Load it up and then retrieve the game calculated Drag Cube. Put this Drag Cube in your config for your original and then your original will sit at the waterline you chose instead of on the keel edge.

 

[NippyFlippers]

50 minutes ago, ColdJ said:

@NippyFlippers I just gave you all you need to make it work. All in stock, no need for a plugin.

Please read what I gave you. I had to work that all out over a couple of years as nobody ever gave me a straight answer when I asked.

 

 

Yeah, sorry, I read it again and see I misunderstood. I'll will likely read your posts several times again. I will also likely keep asking stupid questions and go on with misunderstanding posts, because I am probably actually retarded.

Thanks again, mate!

[Manul]

22 hours ago, ColdJ said:

@Manul

Could you pop up a working example of the module so I can see how it is layed out please?

See the Rotating Mk2 Ring from Stock eXTesnion (SXT)

Spoiler

    MODULE
    {
        name = FSanimateGeneric
        animationName = mk2ringrotation
        animSpeed = 0.5
        toggleActionName = Toggle Spin
        startEventGUIName = Spin
        endEventGUIName = Reverse
        //actionGUIName = Toggle Rotation
        eventAvailableEditor = False
        startDeployed = False
        playAnimationOnEditorSpawn = False

        // animationRampSpeed - used to have the animation
        // slowly ramp up and down. Range is from 0 to 1
        // 1 being instant, 0 being never. 0.001 seems to do it
        // in about 4-5 seconds
        animationRampSpeed = 0.001

        // startAnimSpeed - Speed of animation when first loaded.
        startAnimSpeed = 0.5

        // reverseAnimSpeed - Speed of animation when in reverse
        // Set to 0.0 for no movement when in reverse
        reverseAnimSpeed = 0.1    
    }

Other centrifuge parts I've seen are using AnimationGroup, being actually drills in disguise. WBI centrifuges use WBI partmodules to centrifuge.

[ColdJ]

33 minutes ago, Manul said:

Other centrifuge parts I've seen are using AnimationGroup, being actually drills in disguise. WBI centrifuges use WBI partmodules to centrifuge.

Thank you, I will try it out.

I sent you a new link in the PM

[NippyFlippers]

I managed to insert animations for the doors on my part.

I copied and modified the module from the stock mk3bay (short) and it works okay, but the animation is very fast.

Here is my cfg:

Spoiler

PART {
    name = FlyingBoatServiceBay
    module = Part
    author = NippyFlippers
    scale = 1
    rescaleFactor = 1
    TechRequired = fuelSystems
    entryCost = 8200
    cost = 1550
    category = Payload
    subcategory = 0
    title = Flying Boat Service Bay
    manufacturer = testn
    description = Taken from Bill's fishing boat.
    attachRules = 1,1,1,1,0
    mass = 1
    dragModelType = default
    maximum_drag = 0.2
    minimum_drag = 0.3
    angularDrag = 2
    crashTolerance = 65
    breakingForce = 2000
    breakingTorque = 2000
    maxTemp = 2000
    bulkheadProfiles = size2, srf
    tags = Boat Hull Flying
    MODEL {
        model = TestMod/Parts/FlyingBoatServicebay/FlyingBoatServiceBay
    }

    MODULE {
        name = ModuleAnimateGeneric
        animationName = DoorAction
        startEventGUIName = #autoLOC_502051
        endEventGUIName = #autoLOC_502069
        actionGUIName = #autoLOC_502077
        allowDeployLimit = true
        revClampDirection = false
        revClampSpeed = true
        revClampPercent = true
    }

    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
    }

How can I get it to run a slower speed?

 

 

Edited June 28 by NippyFlippers
I am stupid, disregard this post!

[Manul]

On 6/26/2024 at 2:13 PM, ColdJ said:

find a part that has a smaller but similar drag cube and copy it's auto calculated drag cube into your config. The game will use the Drag Cube you have in the config and so there will be less surface area vs the mass of the object calculated and it will be more likely to sink or sit lower in the water.

Messing with drag cubes in this way is not a good thing to do because the next part in the stack will create enormous amount of drag due to wrong drag occlusion. The game will calculate drag as if the front end (Yp) of the next part is exposed to the airstream  if the Yn area of a modified part is smaller than the next part's Yp area.

[Manul]

Here is my mini guide to drag occlusion and it also explains why automatically calculated drag cubes for hollow parts don't work correctly in a stack.  The workaround for this is to create a solid part with exactly the same outer dimensions, save it's automatically calculated drag cube and use it for a hollow part or a cargobay's closed position.

P.S. Drag occlusion should not be mistaken with drag shielding

Edited June 29 by Manul

[JonnyOThan]

Btw there are a ton of bugs in drag cube calculation in the stock game. KSPCF should fix these.

[Manul]

6 hours ago, JonnyOThan said:

a ton of bugs in drag cube calculation in the stock game.

Yep, the stock Mk2 Drone Core and Airplane+  Mk1 Drone Core are the finest examples how NOT to calculate drag cubes

Both of them provide almost no drag occlusion for connected parts making them as draggy at supersonic speeds as a small drogue chute.

[ColdJ]

@Manul

There was never any suggestion of using this for stacked rocket parts. I doubt that many would care how a rocket going to space sits on the water. This specifically was for custom made parts that are being  designed to be used for boats, subs, and in this case, a flying boat. For the the flying boat I would guess there would be 3 to 4 parts in line, all using the "Remove the Bottom in 3D Modeling" method to get a drag cube that ignores the bottom so that the original parts look to sit properly in the water. So they would all be inline correctly as they are all adjusted the same.

If you wish to discuss the topic in a thread you have created yourself or even in the threads that already exist for discussing Drag Cubes, and put a link to it here, that is fine.

But I ask that discussions not directly related to the purpose of this thread do not take place here as it derails my thread.

It was only brought up originally to help someone who was building a specific type of craft.

[Manul]

38 minutes ago, ColdJ said:

There was never any suggestion of using this for stacked rocket parts.

Drag occlusion is even more important for aircraft and naval vessels because they spend all their life in a substance more dense then a vacuum  When I fixed dragshielding and drag occlusion for Buffalo2 hollow parts, the Guppy submarine became twice faster than it was with all of this extra drag. And it's especially important for a flying boat because it may be missing it's "flying" component due to incorrect drag calculations. Broken dragcubes may result in hundreds kN of extra drag from surfaces that aren't exposed to the airstream or water.

38 minutes ago, ColdJ said:

It was only brought up originally to help someone who was building a specific type of craft.

That uses hollow parts so it will require my method to fix automatically calculated dragcubes to be less draggy and more likely to takeoff from the water. The major problem with hollow parts is that the game assumes that there is an airfow through the part and if a hollow part is followed by a solid part, the front end of a solid part will behave as if it is exposed to the airstream.

9 hours ago, Manul said:

The workaround for this is to create a solid part with exactly the same outer dimensions, save it's automatically calculated drag cube and use it for a hollow part or a cargobay's closed position.

 

Edited June 30 by Manul

[ColdJ]

5 minutes ago, Manul said:

And it's especially important for a flying boat because it may be missing it's "flying" component due to incorrect drag

This is incorrect as you use the module

    MODULE
    {
        name = ModuleLiftingSurface
        useInternalDragModel = False
        deflectionLiftCoeff = 4.6
        dragAtMaxAoA = 0.5
        dragAtMinAoA = 0.03
    }

On body parts that you want to have lift.

I have happily built flying craft that I want to sit on the water realistically in the past using this method. In fact with this module, craft that would never fly in reality can fly in KSP. My Star Wars mod with X-wings, Y-wings, Tie Fighters etc would never realistically fly in atmosphere without this module.

If you wish to discuss this topic further, please create your own thread or post in a relevant one and ping me. Please do not discuss it further in this thread as it is not what this thread is for.

 

 

[Manul]

Returning to the original thread. This is what I had missing to make transparent glass look like glass

@NippyFlippers that might be a solution for your invisible glass problem as well. Assigning inverted texture alpha to shininess  makes the glass shiny and reflective while keeping non-transparent parts of the mesh intact.

1 hour ago, ColdJ said:

This is incorrect as you use the module

Spoiler

Drag occlusion has nothing to do with PartModules (unless you use custom drag cubes), it depends only on how you shape parts and the match of Y- and Y+ drag cube compounds for parts connected with their node_stack_bottom and node_stack_top. I guess we should discuss this in Airplane+ thread because there are lots of broken drag cubes in A+ and @Lisias might be interested as well.

 

[ColdJ]

16 minutes ago, Manul said:

Assigning inverted texture alpha to shininess  makes the glass shiny and reflective while keeping non-transparent parts of the mesh intact.

Just went through all the KSP shaders and that module is not part of any of the see through ones. Last I knew the .mu plugin cannot create and assign shaders not already a part of the game and have them stick on export.

Also the question was already answered.