[1.8.x-1.12.x] Module Manager 4.2.3 (July 03th 2023) - Fireworks season

[Tahib]

Hi, I want to add a toggle switch to the stock Place-Anywhere 7 Linear RCS Port, for switching between rcs and engine mode. The fuel should stay monopropellant, just want to use the RCS Port as normal engine sometimes (I like it more than the stock O-10 "Puff").

How do i do that with modulemanager? Thankyou in advance!

[blowfish]

55 minutes ago, Tahib said:

Hi, I want to add a toggle switch to the stock Place-Anywhere 7 Linear RCS Port, for switching between rcs and engine mode. The fuel should stay monopropellant, just want to use the RCS Port as normal engine sometimes (I like it more than the stock O-10 "Puff").

How do i do that with modulemanager? Thankyou in advance!

You can't make it "switch" between RCS and engine, but you can make it respond to the main throttle, and you can do it without ModuleManager.  Just open the tweakables, show the actuation toggles, and enable "Fore by Throttle"

[Superfluous J]

For the tl;dr crowd, the question is at the bottom in bold.

I'm trying to create a MM config that will create a tech tree node for every part. I can do it manually with multiple hundreds of lines, but it'd obviously be easier and more robust if there was some kind of loop to do so. NOTE: I don't care at the moment where those nodes are located on the R&D screen, so don't bring up that they'd all be on top of each other

I think, for the part side (I want each part in its own tech tree node) all I need do is something like this:

@PART[*]
{
		TechRequired = #$name$
}

(Note this isn't tested and I'm not asking for help on it, just showing what I want for the next bit.

So, assuming the above works, I'd have every part with a "techrequired" set to its name. Now I need to create all those tech nodes. hundreds of lines like:

@TechTree
{
	+RDNode[start] { @Name=PartName }
	+RDNode[start] { @Name=OtherPartName }
	...etc
}

would (I think) do it, but I'd have to put it in there once per part and update the config every time the stock game (or a mod) added new parts.

Is there a way to loop through all parts, and create a RDNode in the TechTree with that part's name? From what I've seen in countless Google searches, I think not. But before I give up I figured I'd ask here.

[Voidryder]

Hi, I'm hoping someone can point me in the right direction.

I'm running various mods, each with their own type of docking port nodeType. Ex: NodeType = apasSize0

I'm wanting to simplify my life and make them all compatible, i.e. nodeType = size1

Here's the script I wrote, but it isn't working.

Can someone tell me what my error is?

Thanks.

 

Spoiler

@PART[*]:HAS[@MODULE[ModuleDockingNode]]:FINAL
{
@MODULE
{
    @name = ModuleDockingNode
    @referenceAttachNode = top
    @nodeType = Size1    
}
}

 

[Sigma88]

@Voidryder

you almost got it right

@PART:FINAL
{
    @MODULE:HAS[#name[ModuleDockingNode]]
    {
        @referenceAttachNode = top
        @nodeType = Size1    
    }
}

you had a lot of unnecessary stuff in the first line and didn't specify which module you wanted to edit properly.

Edited September 1, 2016 by Sigma88

[Voidryder]

3 minutes ago, Sigma88 said:

@Voidryder

you almost got it right

@PART:FINAL
{
    @MODULE:HAS[#name[ModuleDockingNode]]
    {
        @referenceAttachNode = top
        @nodeType = Size1    
    }
}

you had a lot of unnecessary stuff in the first line and didn't specify which module you wanted to edit properly.

Thanks Sigma88! 

[Fwiffo]

What's the difference between ModuleManager's Reload Database and Quick Reload Database buttons?  What's the difference between these buttons compared to the Reload All on the stock Alt+F12 window?

e.g. I notice the stock one doesn't reload "dynamic" parts I added via MM's +PART syntax.  So after reloading using the Alt+F12 window, such parts are reported as "missing" when I try to open a craft file using them).  Also a search of the forum turned up one difference between MM's two buttons:

Anything else?

[Merkov]

On ‎2016‎-‎04‎-‎22 at 2:57 PM, blowfish said:

Okay, I'll walk you through it.  In spoiler tags for those who don't wish to see a long tutorial

  Reveal hidden contents

General info on how MM works: all .cfg files in GameData (with a few exceptions) are loaded into something called the game database in KSP.  Before any parts (or other stuff) are loaded, ModuleManager goes through that database and identifies patches that need to be made.

MM uses the @ symbol to identify edits to existing nodes.  We want to edit all PART nodes

@PART[*] { }

All parts have a name = something field, which MM matches based on what's inside the square brackets [ ].  * means match anything.  If you only wanted to match parts starting with KW (for instance), it would be @PART[KW*].  If you only wanted to match a specific part, it would be @PART[MyPart]

This patch doesn't do anything yet, since there's nothing between the curly braces { }

Now, we really only want to match parts with ModuleReactionWheel:

@PART[*]:HAS[@MODULE[ModuleReactionWheel]] { }

The :HAS block tells MM to look for stuff in the node and only match if conditions are met.  @MODULE[ModuleReactionWheel] tells it to look for a MODULE node with name = ModuleReactionWheel (@ in this context means has this node, ! means does not have this node, # means has this value, ~ means does not have this value).

Now, to actually do something.  Once these nodes are matched, we want to actually edit the ModuleReactionWheel

@PART[*]:HAS[@MODULE[ModuleReactionWheel]]
{
    @MODULE[ModuleReactionWheel] { }
}

Where here again @ means modify this node or value.

Then we want to modify the pitchTorque, yawTorque, and rollTorque inside that.  Let's say you wanted to divide each by a factor of 5

@PART[*]:HAS[@MODULE[ModuleReactionWheel]]
{
    @MODULE[ModuleReactionWheel]
    {
    	@pitchTorque /= 5
        @yawTorque /= 5
        @rollTorque /= 5
    }
}

You can also use other mathematical operators, including *=, +=, and -=

Oh, and we should make sure it runs at the right time.

@PART[*]:HAS[@MODULE[ModuleReactionWheel]]:FINAL
{
    @MODULE[ModuleReactionWheel]
    {
    	@pitchTorque /= 5
        @yawTorque /= 5
        @rollTorque /= 5
    }
}

The :FINAL will tell MM to run this after all other patches (except those also marked :FINAL).  It's not recommended to use :FINAL in an actual mod that will be distributed (when to run should be specified explicitly in that case), but for personal patches it's fine.

Hope that helps.

 

I realize this is an older post of yours, but I just wanted to thank you for making it. I more or less stumbled upon it by accident, but something about the way that you very simply yet systematically explained what MM is doing as you go along the patch just helped make everything click in my code-illiterate brain. The syntax guide in the MM wiki is really good, but this post gave me the foundation to understand the language used in that guide. I'm currently playing with making MM patches to allow mods to work with each other, and keep coming back to a copy of this tutorial you made as a sort of "checklist" as I write my patches.

Again, thanks a lot for taking the time to write it. +1 rep didn't really do a proper job of describing how good of a post this is.

[sarbian]

2 hours ago, Fwiffo said:

What's the difference between ModuleManager's Reload Database and Quick Reload Database buttons?  What's the difference between these buttons compared to the Reload All on the stock Alt+F12 window?

e.g. I notice the stock one doesn't reload "dynamic" parts I added via MM's +PART syntax.  So after reloading using the Alt+F12 window, such parts are reported as "missing" when I try to open a craft file using them).  Also a search of the forum turned up one difference between MM's two buttons:

Anything else? 

No, it is exactly that 

[Nnimrod]

If I wanted to remove all parts that I haven't specifically allowed, I could write a patch like this

!PART[*]:HAS[~description[*Configured]]{}

And just add "Configured" to the end of the description of all parts that I want to use. Right?

How might I do it if I don't want to put the word "Configured" at the end of every description? Because it kind of breaks immersion.

[Sigma88]

9 minutes ago, Nnimrod said:

If I wanted to remove all parts that I haven't specifically allowed, I could write a patch like this

!PART[*]:HAS[~description[*Configured]]{}

And just add "Configured" to the end of the description of all parts that I want to use. Right?

How might I do it if I don't want to put the word "Configured" at the end of every description? Because it kind of breaks immersion.

why don't you use a custom parameter? like

Quote

!PART:HAS[#deleteme[true]] {}

this will delete all PARTs that contain deleteme = true

(be careful that MM is case-sensitive)

[Nnimrod]

10 minutes ago, Sigma88 said:

why don't you use a custom parameter? like

this will delete all PARTs that contain deleteme = true

(be careful that MM is case-sensitive)

Because I didn't know you could do that ^.^

I assume I could do the inverse? 

!PART:HAS[~allowme[true]] {}

This would require me to make a patch like this for every part I want to show up, right?

@PART[solidBooster_sm]
{
	%allowme = true
}

EDIT I tried this and it doesn't work :s

Edited September 2, 2016 by Nnimrod

[Sigma88]

17 minutes ago, Nnimrod said:

Because I didn't know you could do that ^.^

I assume I could do the inverse? 

!PART:HAS[~allowme[true]] {}

This would require me to make a patch like this for every part I want to show up, right?

@PART[solidBooster_sm]
{
	%allowme = true
}

EDIT I tried this and it doesn't work :s

yes, that should work, provided that the two patches are applied in the correct order (before you add allowme, then you delete the parts without it)

try

@PART[solidBooster_sm]:FINAL
{
	%allowme = true
}
!PART:HAS[~allowme[true]]:FINAL {}

if you put everything in the same cfg make sure the delete bit is the last one

if you put them in different files make sure the delete file is loaded last

[Nnimrod]

4 minutes ago, Sigma88 said:

yes, that should work, provided that the two patches are applied in the correct order (before you add allowme, then you delete the parts without it)

try

@PART[solidBooster_sm]:FINAL
{
	%allowme = true
}
!PART:HAS[~allowme[true]]:FINAL {}

if you put everything in the same cfg make sure the delete bit is the last one

if you put them in different files make sure the delete file is loaded last

Thanks! Adding ":FINAL" to master do not load patch made it work as intended

Master do not load patch

!PART[*]:HAS[~allowme[true]]:FINAL {}

And then I just add that key+value to anything that I do want to show up. Much much easier than making a do not load patch for every part I didn't want to see, which is what I was doing before.

[Sigma88]

you don't need the [*] after PART

other than that the patch is fine

 

[AlphaMensae]

Ok, I'm getting a brain-lock on this: to change the scale values in MODEL {} for a part, do I use "@MODEL[...full path name to model...] or just the model filename?  Or do I use "HAS[#id[...model filename or path...]]".

[blowfish]

1 hour ago, Laguna said:

Ok, I'm getting a brain-lock on this: to change the scale values in MODEL {} for a part, do I use "@MODEL[...full path name to model...] or just the model filename?  Or do I use "HAS[#id[...model filename or path...]]".

Uhh, back up a bit.  What part are you trying to change?  Does it already have a MODEL{} node?  Does it have more than one?

[AlphaMensae]

8 hours ago, blowfish said:

Uhh, back up a bit.  What part are you trying to change?  Does it already have a MODEL{} node?  Does it have more than one?

It's one of the SpaceY thrust plates, and it does have one MODEL{} node.  I want to scale up the diameter while keeping the height (Y value) the same or reducing it, in order to to shorten the engine shroud that the SpaceY thrust plates provide.  Itr doesn't matter how it will end up looking, as most of it will be clipped into a fuel tank.

[Mecripp]

3 hours ago, Laguna said:

It's one of the SpaceY thrust plates, and it does have one MODEL{} node.  I want to scale up the diameter while keeping the height (Y value) the same or reducing it, in order to to shorten the engine shroud that the SpaceY thrust plates provide.  Itr doesn't matter how it will end up looking, as most of it will be clipped into a fuel tank.

PART {
 
name = SYplate3m1mX7
module = Part
author = NecroBones
 
MODEL
{
    model = SpaceY-Lifters/Parts/ThrustPlates/SYplate3m1mX7
    scale = 1.0, 1.0, 1.0
}
scale = 1.0
rescaleFactor = 1                  <----------------  Just change the rescaleFactor = *** to what you want

@PART[SYplate1m0mX1]
{
  %rescaleFactor = *  //<--- what ever # you want to use
}

 

[Mecripp]

On 9/1/2016 at 6:44 PM, Sigma88 said:

@Voidryder

you almost got it right

@PART:FINAL
{
    @MODULE:HAS[#name[ModuleDockingNode]]
    {
        @referenceAttachNode = top
        @nodeType = Size1    
    }
}

you had a lot of unnecessary stuff in the first line and didn't specify which module you wanted to edit properly.

How is that doing what he asked ?

On 9/1/2016 at 6:21 PM, Voidryder said:

Hi, I'm hoping someone can point me in the right direction.

I'm running various mods, each with their own type of docking port nodeType. Ex: NodeType = apasSize0        <------  here NodeType = apasSize0  and your patch is liking for nodeType = size1

I'm wanting to simplify my life and make them all compatible, i.e. nodeType = size1

Here's the script I wrote, but it isn't working.

Can someone tell me what my error is?

Thanks.

 

  Hide contents

@PART[*]:HAS[@MODULE[ModuleDockingNode]]:FINAL
{
@MODULE
{
    @name = ModuleDockingNode
    @referenceAttachNode = top
    @nodeType = Size1    
}
}

wouldn't it be

@PART:FINAL
{
    @MODULE:HAS[#name[ModuleDockingNode]]
    {
        %referenceAttachNode = top
        %nodeType = Size1    
    }
}

 

But that change all docking nodes to size 1

Edited September 3, 2016 by Mecripp2
whoops

[blowfish]

@MeCripp I think @Laguna wanted to scale along two axes but not the third (so rescaleFactor won't work here).

3 hours ago, Laguna said:

It's one of the SpaceY thrust plates, and it does have one MODEL{} node.  I want to scale up the diameter while keeping the height (Y value) the same or reducing it, in order to to shorten the engine shroud that the SpaceY thrust plates provide.  Itr doesn't matter how it will end up looking, as most of it will be clipped into a fuel tank.

Ok, that makes sense.  In that case, you don't need to worry about the path to the model at all, you just need to modify the scale value in the MODEL node

@PART[SYplate1m0mX1]:FINAL
{
    @MODEL
    {
        %scale = 2, 1, 2 // Or whatever values you want
    }
}

 

[AlphaMensae]

11 minutes ago, blowfish said:

@MeCripp I think @Laguna wanted to scale along two axes but not the third (so rescaleFactor won't work here).

Ok, that makes sense.  In that case, you don't need to worry about the path to the model at all, you just need to modify the scale value in the MODEL node

@PART[SYplate1m0mX1]:FINAL
{
    @MODEL
    {
        %scale = 2, 1, 2 // Or whatever values you want
    }
}

@blowfish, thank you, that's exactly what I wanted, scaling individual values; I know about rescaleFactor, but it increases all the dimensions, and in this case, that wouldn't work, since I want to make a 3.75m thrust plate into a 5m one but keep the shroud at it's 3.75m height or shorter.

Edited September 3, 2016 by Laguna

[Sigma88]

 

27 minutes ago, MeCripp said:

How is that doing what he asked ?

wouldn't it be

@PART:FINAL
{
    @MODULE:HAS[#name[ModuleDockingNode]]
    {
        %referenceAttachNode = top
        %nodeType = Size1    
    }
}

 

But that change all docking nodes to size 1

the only difference between mine and yours is that if "referenceAttachNode" or "nodeType" do not exist already your code will create them, while mine will not do anything.

I used @ only because he had already used @ in his cfg

the difference between @ and % is pretty easy to understand if you are using MM so I assumed he already knew what he was doing when choose to use @

[Mecripp]

10 minutes ago, Sigma88 said:

 

the only difference between mine and yours is that if "referenceAttachNode" or "nodeType" do not exist already your code will create them, while mine will not do anything.

I used @ only because he had already used @ in his cfg

the difference between @ and % is pretty easy to understand if you are using MM so I assumed he already knew what he was doing when choose to use @

But what you posted are just looking at the nodes and that's it and not even finding the nodes he what's to change ?

[Sigma88]

2 minutes ago, MeCripp said:

But what you posted are just looking at the nodes and that's it and not even finding the nodes he what's to change ?

I don't understand sorry