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

[Whovian41110]

1 minute ago, Enceos said:

I'm not sure which order is right '>0' or '0>', so please check both. One of those will add 0 resources to the pods or every part :3

Ok will do

[blowfish]

3 minutes ago, Enceos said:

I'm not sure which order is right '>0' or '0>', so please check both. One of those will add 0 resources to the pods or every part :3

It's >0

[Enceos]

@blowfish or anyone else,

I want to patch multiple nodes of the same type under their parent node, is that possible?

Here's the sample config:

Spoiler

STATIC
{
    title = Flood Lights

        Instances
        {
            RadiusOffset = 1252
        }
        Instances
        {
            RadiusOffset = 1250
        }
        Instances
        {
            RadiusOffset = 1215.534
        }
}

And here's my WIP patch:

Spoiler

@STATIC[*]:FINAL

{

   @Instances

    {

        @RadiusOffset *= 1.32 // the multiple of the altitude by which to raise the buildings.

    }

}

Do I need to put brackets with an asterisk like this:   @Instances[*]   ?

EDIT: Asterisk didn't work, MM still pathed only the first node.

Edited May 12, 2016 by Enceos

[Sigma88]

1 hour ago, Enceos said:

@blowfish or anyone else,

I want to patch multiple nodes of the same type under their parent node, does MM patch them all or only the first one? How to patch them all?

Here's the sample config:

  Hide contents

STATIC
{
    title = Flood Lights

        Instances
        {
            RadiusOffset = 1252
        }
        Instances
        {
            RadiusOffset = 1250
        }
        Instances
        {
            RadiusOffset = 1215.534
        }
}

And here's my WIP patch:

  Hide contents

@STATIC[*]:FINAL

{

   @Instances

    {

        @RadiusOffset *= 1.32 // the multiple of the altitude by which to raise the buildings.

    }

}

Do I need to put brackets with an asterisk like this:   @Instances[*]   ?

@Instances[*] means "The first node of type Instances with name = * " (where * is a wildcard that means "anything")

what you want to use is:

@Instances,* that means "All nodes of type Instances"

this is the general case of targetting a node by it's position:

@Instances,0 targets the first node
@Instances,1 targets the second node
...
@Instances,99 targets the 100th node
@Instances,* targets all the nodes

 

using a :HAS[] tag will have the same effect, so if you use:

@Instances:HAS[#RadiusOffset[*]]

this means "Target all nodes of type Instances that contain a key of type RadiusOffset (with any value)"

 

@sarbian @blowfish

I always wondered, is there any difference in efficiency between using these two configs?

@Part
{
	@Module,*
	{
		@key = changed
	}
}

@Part
{
	@Module:HAS[#key[*]]
	{
		@key = changed
	}
}

the output is exactly the same, but will one of the two run quicker?

Edited May 12, 2016 by Sigma88

[Enceos]

@Sigma88 Oh thank you very much, been a while since I wrote MM patches, didn't know this syntax.

BTW, This patch will adapt Kerbal Konstructs to any planet resizing mods.

Edited May 12, 2016 by Enceos

[Sigma88]

11 minutes ago, Enceos said:

@Sigma88 Oh thank you very much, been a while since I wrote MM patches, didn't know this syntax.

BTW, This patch will adapt Kerbal Konstructs to any planet resizing mods.

then you might want to add a :NEEDS[!SigDim] tag so that it doesn't do anything if SigmaDimensions is installed

[Enceos]

4 minutes ago, Sigma88 said:

then you might want to add a :NEEDS[!SigDim] tag so that it doesn't do anything if SigmaDimensions is installed

I see you've done it before )

[FreeThinker]

Question, how to specify that at MM script should not be applied when a specfic resource is on a part?

It tried the following MM (only relevant part)

 

@PART[*]:HAS[@RESOURCE[LiquidFuel],@RESOURCE[Oxidizer],@RESOURCE[!MonoPropellant],!MODULE[InterstellarFuelSwitch],!MODULE[FSfuelSwitch],!MODULE[B9PartSwitch],!MODULE[ModuleEnginesFX],!MODULE[ModuleEngines]]

Not the problem is with the Monopropellant. I only want my script to affect tanks with the resouces LiquidFuel and Oxidiser but not Monopropellant.

[blowfish]

6 minutes ago, FreeThinker said:

Question, how to specify that at MM script should not be applied when a specfic resource is on a part?

It tried the following MM (only relevant part)

 

@PART[*]:HAS[@RESOURCE[LiquidFuel],@RESOURCE[Oxidizer],@RESOURCE[!MonoPropellant],!MODULE[InterstellarFuelSwitch],!MODULE[FSfuelSwitch],!MODULE[B9PartSwitch],!MODULE[ModuleEnginesFX],!MODULE[ModuleEngines]]

Not the problem is with the Monopropellant. I only want my script to affect tanks with the resouces LiquidFuel and Oxidiser but not Monopropellant.

Should be !Resource[MonoPropellant], just like the modules

[lodestar]

I realized the USI ART Mass Driver engines are grossly overpowered, and I'm trying to write an MM patch to reduce thrust and increase Ec consumption ratio by 10x each. This patch reduces thrust, but Ec consumption is unchanged. Any idea on what I'm doing wrong?

 

Spoiler

@PART[HA_MassDriver_250]:AFTER[UmbraSpaceIndustries]
{
    @MODULE[ModuleEngines]
    {
    @maxThrust /= 10
    
    @PROPELLANT[ElectricCharge]{
        @ratio *= 10
    }
    }

    @MODULE[ModuleRCS]
    {
    @thrusterPower /= 10
    
    @PROPELLANT[ElectricCharge]{
        @ratio *= 10
    }
    }
}

Edited May 12, 2016 by lodestar

[Jenyaza]

@PART:HAS[@RESOURCE[LiquidFuel],@RESOURCE[Oxidizer],!RESOURCE[MonoPropellant],...

 

[Svm420]

On May 3, 2016 at 2:18 AM, Svm420 said:

Would anyone be able to help with a patch? I had this patch in 1.0.5 before MM 2.6.20+ that I used to duplicate the top node of every engine without a second top nod already. Now since the changes to MM the patch just doesn't work. I was wondering how else I can write this simply to get the result I want. Thanks in advance!

@PART[*]:HAS[~node_stack_top2[],@MODULE[ModuleEngines*]:HAS[!PROPELLANT[IntakeA*]]]:FINAL
{
	%node_stack_top2 = #$node_stack_top$
}

 

 

On May 4, 2016 at 8:00 AM, sarbian said:

Ok there may be a bug there. I ll have a look tonight and hopefully I can fix it before I leave tomorrow...

@sarbian

Did you ever get a chance to look in to this? Thanks!

Edited May 13, 2016 by Svm420

[Toonu]

Hi, is there way to include/exclude parts to patch by its title? I searched wiki, some posts about how to make dependency checking, but it wasn't here. Any ideas?

I tried it with :HAS[title[[SLS]]] but that haven't helped...and I tried many combinations. I m searching for title [SLS]

Thanks for any help! Ave!

Toonu

Edited May 13, 2016 by Toonu

[blowfish]

3 hours ago, Toonu said:

Hi, is there way to include/exclude parts to patch by its title? I searched wiki, some posts about how to make dependency checking, but it wasn't here. Any ideas?

I tried it with :HAS[title[[SLS]]] but that haven't helped...and I tried many combinations. I m searching for title [SLS]

Thanks for any help! Ave!

Toonu

You probably want :HAS[#title[SLS*]] - that tells it to look for a value named title that starts with "SLS" (# means has value, ~ means does not have value, @ means has node, ! means does not have node in this context.  If you wanted to search for SLS anywhere in the title (not just the beginning), it would be *SLS*

Edited May 14, 2016 by blowfish

[drtedastro]

On 5/7/2015 at 10:39 AM, sarbian said:

No it does not supported and I don't plan too unless the bug you talk about are confirmed.

Are you sure about the naming problem when you set the cube ? Some of the stock part use that and if it was bugged we would have seen it. Are you sure that the problem is not that ModuleParachute force the cube to be recalculated ? Do you try with the procedural flag ?

 

 

DRAG_CUBE
{
	procedural = True
}

 

I found a part that has an incorrect DRAG_CUBE module in it.

Can I delete it with !DRAG_CUBE ?  And or what would the bracketing need to be?

!DRAG_CUBE{} ?? or something else

thanks.

 

[Phineas Freak]

@drtedastrodoes the module have just one drag cube or multiple? If it is only one then deleting it is simple:

!DRAG_CUBE{}

Or for multiple:

!DRAG_CUBE,*{}

If it has multiple but only the first is wrong then:

!DRAG_CUBE,0{}

But i think that deleting the drag cube should be done in a specific MM pass (might be FIRST or FINAL?) since KSP will recalculate a drag cube if a part does not have one already defined inside it's part module config.

[drtedastro]

It only has the one, and YES I agree it should be done ????? FINAL I am guessing?????

Cheers.

[sarbian]

The cube are rebuild after MM is done. What is this part with wrong cubes ? 

[evileye.x]

@sarbian,  I'm sorry if I'm asking stupid question, but does latest version works with 1.0.5? What I really want to have in 1.0.5 - changed cfgs mentioned in log file.  (Cannot upgrade to 1.1.2 because I have no idea how to adapt Better Atmospheres mod for new EVE... ) 

[sarbian]

no, it does not. You need 2.6.20 https://ksp.sarbian.com/jenkins/job/ModuleManager/109/

[Svm420]

On May 3, 2016 at 2:18 AM, Svm420 said:

Would anyone be able to help with a patch? I had this patch in 1.0.5 before MM 2.6.20+ that I used to duplicate the top node of every engine without a second top nod already. Now since the changes to MM the patch just doesn't work. I was wondering how else I can write this simply to get the result I want. Thanks in advance!

@PART[*]:HAS[~node_stack_top2[],@MODULE[ModuleEngines*]:HAS[!PROPELLANT[IntakeA*]]]:FINAL
{
	%node_stack_top2 = #$node_stack_top$
}

 

@sarbian

[evileye.x]

6 hours ago, sarbian said:

no, it does not. You need 2.6.20 https://ksp.sarbian.com/jenkins/job/ModuleManager/109/

Thanks. However " [ModuleManager] Changes " is not in log with this version. O'k, my 1.0.5 install will keep to rebuid module manager cache each time. It's my problem if I stuck with 1.0.5 anyway.

Oh, I had a blonde moment, it works. And now I see:

[LOG 22:33:58.374] [ModuleManager] Changes :
Changed : PersistentRotation/PersistentRotation_pefomance parts_0.cfg
Changed : PersistentRotation/PersistentRotation_pefomance parts_1.cfg
Changed : PersistentRotation/PersistentRotation_pefomance parts_2.cfg
Changed : TriggerTech/KerbalAlarmClock/settings.cfg
Added   : ConnectedLivingSpace/Config/ASETStackableInlineLights .cfg
Deleted : ConnectedLivingSpace/Config/ASETStackableInlineLights.cfg
Deleted : PersistentRotation/PersistentRotation_pefomance parts_3.cfg
Deleted : PersistentRotation/PersistentRotation_pefomance parts_4.cfg
Deleted : PersistentRotation/PersistentRotation_pefomance parts_5.cfg

So those are mods to blame MM has to rebuild cache each run?

Edited May 14, 2016 by evileye.x

[Whovian41110]

@Enceos MM on loading says there are 92 errors related to the supply patch that you helped me make.

Edited May 14, 2016 by Whovian41110

[Enceos]

1 hour ago, Whovian41110 said:

@Enceos MM on loading says there are 92 errors related to the supply patch that you helped me make.

Would you post here the final version of the patch you got.

[Whovian41110]

4 hours ago, Enceos said:

Would you post here the final version of the patch you got.

Spoiler

@PART[*]:HAS[#CrewCapacity[>0]]:NEEDS[UmbraSpaceIndustries]
{
    %RESOURCE[Supplies]
    {
        %amount = 15
        @amount *= #$/CrewCapacity$
        %maxAmount = #$amount$
    }
    %RESOURCE[Mulch]
    {
        %amount = 0
        @amount *= #$/CrewCapacity$ you don't need this line since you want initial amount to be always 0
        %maxAmount = 15
        @maxAmount *= #$/CrewCapacity$
    }
}