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

[Olympic1]

Hi, this maybe a dumb question but do I need the correct version of MM for my KSP version (0.25) or canI use the current one? If I need an older version fpr my KSP where can I get the right version of MM?

I think you can use the latest on, but here you can get older MM versions.

[NathanKell]

You need the latest version for that release of KSP. Please do not try running 2.5.9 on KSP 0.25!

Please use 2.5.3, I believe that was the last version for 0.25.

[Olympic1]

It is probably not possible, but I ask it anyway:

Can MM keep a whole subfolder from loading?

It's easy to write a config for keeping 50 parts from loading, but if I could do that with subfolders then that would be easier.

[sarbian]

Nope. Remember than even if it could it would not stop KSP from loading the textures.

Edited January 26, 2015 by sarbian

[Olympic1]

Nope. I remember than even if it could it would not stop KSP from loading the textures.

okay, no problem

[FreeThinker]

I have a problem when loading RealFuels, in combination with my own mod KSPI Extented Config Mod I

'm getting 4 Module Manager Errors when loading KSPI_RF.cfg

I first narrowed it down to the flowing MM code

//Specific part fixes
@PART[FNMethaneTank*]:HAS[@RESOURCE[LqdMethane]&@RESOURCE[Oxidizer]&!MODULE[ModuleFuelTanks]]:NEEDS[WarpPlugin]:FOR[RealFuels]
{
    MODULE
    {
        name = ModuleFuelTanks
        temp = 0
        volume = 0
        type = Cryogenic
        @temp = #$../RESOURCE[LqdMethane]/maxAmount$
        @temp *= 4.412
        @volume = #$../MODULE[ModuleFuelTanks]/temp$
        @temp = #$../RESOURCE[Oxidizer]/maxAmount$
        @temp *= 5
        @volume += #$../MODULE[ModuleFuelTanks]/temp$
        !temp = 0
    }
    !RESOURCE[LqdMethane] {}
    !RESOURCE[Oxidizer] {}
}

Inside this I found which one cause 4 error message during load:

@volume = #$../MODULE[ModuleFuelTanks]/temp$ and 

@volume += #$../MODULE[ModuleFuelTanks]/temp$

each cause 2 errors. What does it actual do? Any idea how to fix this?

[mecki]

I have a problem when loading RealFuels, in combination with my own mod KSPI Extented Config Mod I

'm getting 4 Module Manager Errors when loading KSPI_RF.cfg

I first narrowed it down to the flowing MM code

//Specific part fixes
@PART[FNMethaneTank*]:HAS[@RESOURCE[LqdMethane]&@RESOURCE[Oxidizer]&!MODULE[ModuleFuelTanks]]:NEEDS[WarpPlugin]:FOR[RealFuels]
{
    MODULE
    {
        name = ModuleFuelTanks
        temp = 0
        volume = 0
        type = Cryogenic
        @temp = #$../RESOURCE[LqdMethane]/maxAmount$
        @temp *= 4.412
        @volume = #$../MODULE[ModuleFuelTanks]/temp$
        @temp = #$../RESOURCE[Oxidizer]/maxAmount$
        @temp *= 5
        @volume += #$../MODULE[ModuleFuelTanks]/temp$
        !temp = 0
    }
    !RESOURCE[LqdMethane] {}
    !RESOURCE[Oxidizer] {}
}

Inside this I found which one cause 4 error message during load:

@volume = #$../MODULE[ModuleFuelTanks]/temp$ and 

@volume += #$../MODULE[ModuleFuelTanks]/temp$

each cause 2 errors. What does it actual do? Any idea how to fix this?

I think that both could be replaced by

@volume = #$temp$

and

@volume += #$temp$

[undercoveryankee]

I have a problem when loading RealFuels, in combination with my own mod KSPI Extented Config Mod I

'm getting 4 Module Manager Errors when loading KSPI_RF.cfg

I first narrowed it down to the flowing MM code

//Specific part fixes
@PART[FNMethaneTank*]:HAS[@RESOURCE[LqdMethane]&@RESOURCE[Oxidizer]&!MODULE[ModuleFuelTanks]]:NEEDS[WarpPlugin]:FOR[RealFuels]
{
    MODULE
    {
        name = ModuleFuelTanks
        temp = 0
        volume = 0
        type = Cryogenic
        @temp = #$../RESOURCE[LqdMethane]/maxAmount$
        @temp *= 4.412
        @volume = #$../MODULE[ModuleFuelTanks]/temp$
        @temp = #$../RESOURCE[Oxidizer]/maxAmount$
        @temp *= 5
        @volume += #$../MODULE[ModuleFuelTanks]/temp$
        !temp = 0
    }
    !RESOURCE[LqdMethane] {}
    !RESOURCE[Oxidizer] {}
}

Inside this I found which one cause 4 error message during load:

@volume = #$../MODULE[ModuleFuelTanks]/temp$ and 

@volume += #$../MODULE[ModuleFuelTanks]/temp$

each cause 2 errors. What does it actual do? Any idea how to fix this?

That patch as a whole is converting Interstellar's methane tanks to RealFuels modular cryogenic tanks. It takes the tank's original methane capacity, multiplies by 4.412 to convert from stock-like units to liters, then does the same for Oxidizer at 5 liters per unit, and sets the modular tank's available volume to a number of liters that represents its original capacity.

I don't see anything wrong with the patch. Can you look in the log and post the exact text of the errors it's generating?

[FreeThinker]

I don't see anything wrong with the patch. Can you look in the log and post the exact text of the errors it's generating?

Ok, the whole output_log does not fit in here, so I selected the relevant bits

Config(@PART[FNMethaneTank*]:HAS[@RESOURCE[LqdMethane]&@RESOURCE[Oxidizer]&!MODULE[ModuleFuelTanks]]:NEEDS[WarpPlugin]:FOR[RealFuels]) RealFuels/KSPI_RF/@PART[FNMethaneTank*]:HAS[@RESOURCE[LqdMethane]&@RESOURCE[Oxidizer]&!MODULE[ModuleFuelTanks]]:NEEDS[WarpPlugin]:FOR[RealFuels]

[ModuleManager] ModuleManager: 915 patches applied, found 4 errors
4 errors in GameData/RealFuels/KSPI_RF.cfg

Edited January 26, 2015 by FreeThinker

[Olympic1]

That patch as a whole is converting Interstellar's methane tanks to RealFuels modular cryogenic tanks. It takes the tank's original methane capacity, multiplies by 4.412 to convert from stock-like units to liters, then does the same for Oxidizer at 5 liters per unit, and sets the modular tank's available volume to a number of liters that represents its original capacity.

I don't see anything wrong with the patch. Can you look in the log and post the exact text of the errors it's generating?

Use

@volume += #$/temp$

[undercoveryankee]

Ok, the whole output_log does not fit in here, so I selected the relevant bits

Config(@PART[FNMethaneTank*]:HAS[@RESOURCE[LqdMethane]&@RESOURCE[Oxidizer]&!MODULE[ModuleFuelTanks]]:NEEDS[WarpPlugin]:FOR[RealFuels]) RealFuels/KSPI_RF/@PART[FNMethaneTank*]:HAS[@RESOURCE[LqdMethane]&@RESOURCE[Oxidizer]&!MODULE[ModuleFuelTanks]]:NEEDS[WarpPlugin]:FOR[RealFuels]

[ModuleManager] ModuleManager: 915 patches applied, found 4 errors
4 errors in GameData/RealFuels/KSPI_RF.cfg

Those lines are just a summary. The actual errors should have been logged farther back in the Unity log. What version of MM are you using?

[FreeThinker]

Those lines are just a summary. The actual errors should have been logged farther back in the Unity log. What version of MM are you using?

I was using ModuleManager.2.5.9.dll , I switched back to ModuleManager.2.5.6.dll which does not have the problem, going to test more versions ...

Edit: ModuleManager.2.5.8.dll also shows 4 errors

Edited January 26, 2015 by FreeThinker

[Olympic1]

I was using ModuleManager.2.5.9.dll , I switched back to ModuleManager.2.5.6.dll which does not have the problem, going to test more versions ...

Edit: ModuleManager.2.5.8.dll also shows 4 errors

Oh, then I know the issue.

Replace your "&" with ","

In 2.5.7 this was changed for fixing the science reports containing a "&"

[FreeThinker]

Oh, then I know the issue.

Replace your "&" with ","

In 2.5.7 this was changed for fixing the science reports containing a "&"

Great, this seems to work, we must tell all Mod makes which use "&" to replace it with ","

Still weird that no one else had noticed it ...

Edited January 26, 2015 by FreeThinker

[Olympic1]

Great, this seems to work, we must tell all Mod makes which use "&" to replace it with ","

Still weird that no one else had noticed it ...

Most of them use the ","

[sarbian]

I knew this would bite me back ....

[RobotsAndSpaceships]

So if I wanted to remove a module from a part I would use:

!MODULE[the module I want to remove]{

}

[undercoveryankee]

So if I wanted to remove a module from a part I would use:

!MODULE[the module I want to remove]{

}

That looks right to me.

[Olympic1]

So if I wanted to remove a module from a part I would use:

!MODULE[the module I want to remove]{

}

Thats right.

Don't forget to put it in a PART

@PART[partname]
{
    !MODULE[module you want to remove] {}
}

[Raptor831]

Went back 10 pages and couldn't find this. Say we have a Module like this:

MODULE
{
  name = MyModule
  value = foo,1;bar,2
}

How do I test for "value contains 'foo'", and then alter 'foo'? I'm sure it can be done, but I can't find any of the regex stuff in any docs, and I can't quite figure it out from looking at other examples I know of.

[NavyFish]

I've seen mention that eventually MM will apply patches to ALL matching nodes, not just the first or specifically indexed one. Is this functionality currently in place?

[Starwaster]

I've seen mention that eventually MM will apply patches to ALL matching nodes, not just the first or specifically indexed one. Is this functionality currently in place?

Yes. The following will be applied to every MODULE node named ModuleEngineConfigs, and in turn every single CONFIG node that it finds in those nodes will be processed.

    @MODULE[ModuleEngineConfigs],*
    {
        @CONFIG
[*],*
        {
            @heatProduction *= #$/tempMult$
        }
    }

Edited January 28, 2015 by Starwaster

[NavyFish]

Beautiful. Thanks!

- - - Updated - - -

Hmm. This is strange, I'm not seeing any patches being applied.

This boiled-down test patch is placed two folders below GAMEDATA.

@PART[*]
{
    MODULE
    {
        name = testModule
        other = stuff
    }    
}   

The log shows this patch being applied to every part, but neither persistence.sfs or quicksave.sfs reflects the addition. I tried creating a new game, launching a new vessel, and still no addition. What am I missing...

Using 2.5.9.

[Starwaster]

Beautiful. Thanks!

- - - Updated - - -

Hmm. This is strange, I'm not seeing any patches being applied.

This boiled-down test patch is placed two folders below GAMEDATA.

@PART
[*]
{
    MODULE
    {
        name = testModule
        other = stuff
    }    
}   

The log shows this patch being applied to every part, but neither persistence.sfs or quicksave.sfs reflects the addition. I tried creating a new game, launching a new vessel, and still no addition. What am I missing...

Using 2.5.9.

looks ok to me. Check the log and make sure testModule's plugin is loading

[NavyFish]

It is loading, but I'm curious why that would matter? Does the added module have to have an associated PartModule assembly?

If so, and wanted to add a Module without an associated .dll, could I do so by using a :FINAL tag?

Hmm.. off to test..

- - - Updated - - -

Regardless of my above curiosity, the following does not work:

@PART[*]:HAS[@MODULE[ModuleDockingNode]]
{
    @MODULE[ModuleDockingNode],*
    {
        %portName_DPAI = default
        %portName_DPAI_initialized = false
    }
}

- - - Updated - - -

Applying node NavyFish/Plugins/moduleDockingNodeNamed/@PART[*]:HAS[@MODULE[ModuleDockingNode]] to Squad/Parts/Utility/dockingPort/dockingPort/dockingPort2
[LOG 23:49:39.978] [ModuleManager] Applying node NavyFish/Plugins/moduleDockingNodeNamed/@PART[*]:HAS[@MODULE[ModuleDockingNode]] to Squad/Parts/Utility/dockingPortInline/dockingPortInline/dockingPortLateral
[LOG 23:49:39.979] [ModuleManager] Applying node NavyFish/Plugins/moduleDockingNodeNamed/@PART[*]:HAS[@MODULE[ModuleDockingNode]] to Squad/Parts/Utility/dockingPortJr/dockingPortJr/dockingPort3

The patch is being applied and the "ModuleDockingNode" is stock... Yet no changes to the persistence or quicksave files for existing craft or newly created craft. wha...

Edited January 28, 2015 by NavyFish