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

[sarbian]

lefter : I made a .cfg that does that and fix B9 science part for Scott Manley IQ series : https://www.sarbian.com/sarbian/scott_manley_IQ_science_fix.cfg

[leftler]

lefter : I made a .cfg that does that and fix B9 science part for Scott Manley IQ series : https://www.sarbian.com/sarbian/scott_manley_IQ_science_fix.cfg

You CFG file does not add the removable science to the magnatomitor, it would just be

@PART[FNGCMS]:Final
{
    @MODULE[ModuleScienceExperiment]
    {
        dataIsCollectable = True
        collectActionName = Take Data
        interactionRange = 1.2
    }
}

Or you can do what I like to do and just add removable science to all modules that currently do not have any removal rule defined.

@PART[*]:HAS[@MODULE[ModuleScienceExperiment]:HAS[!dataIsCollectable]]:Final
{
    @MODULE[ModuleScienceExperiment]
    {
        dataIsCollectable = True
        collectActionName = Take Data
        interactionRange = 1.2
    }
}

[Gojira]

How would I add Protractor to all command pods?

[leftler]

How would I add Protractor to all command pods?

I have never used protractor, but if you go look at the 2nd post it shows how to add MecJeb to all command pods that do not currently have it.

@PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[MechJebCore]]:Final
{    
    MODULE
    {
        name = MechJebCore
    }
}

Just replace the MechJeb refrences to whatever needs to be added to add Protractor.

[swamp_ig]

^ I oppose this ^

Please don't remove it at all, rather give an option to show it or not.

I like this stuff to show me how much stuff i have patched and will know my new patch is at least reconized or not in a single glance at this.

I think best to show it. No option to turn it off.

Really it does no harm, but can potentially cause trouble if it's not there (you don't know when things don't work)

[SmarterThanMe]

G'day guys.

I need a cfg to replace the radiator functionality in the Near Future radiators with that from Interstellar.

This is the sort of thing I need to remove (this is from just one of the radiators, the others have different values - the important one is *'ed):

MODULE

{

name = FissionRadiator

DeployAnimation = RadiatorExtend

HeatAnimation = RadiatorHex_Heat

HeatRadiated = 1250*

HeatRadiatedClosed = 25

Breakable = false

AllowRotation = False

RotatorName = LinkNub

RotationRate = 1.0

PressureCurve

{

key = 0 0

key = 1 10

}

}

This is what I need to add (the *'ed number from above should go into where the **'ed number is below, and then perhaps be multiplied for the ***'ed numbers):

MODULE

{

name = FNRadiator

animName = a1

radiatorTemp = 1350**

radiatorArea = 100

originalName = Mo Li Heat Pipe

upgradeCost = 15

upgradedName = Graphene Radiator

upgradedRadiatorTemp = 3500***

upgradeTechReq = experimentalElectrics

}

RESOURCE

{

name = WasteHeat

amount = 0

maxAmount = 625000***

}

Is this possible?

[phoenix_ca]

You can't automate that, no. The most you can do is remove the FissionRadiator module altogether and replace it with a complete FNRadiator module. To do what you ask would require that one could declare and use variables with MM, and that is not a feature that will be added. Ever.

[SmarterThanMe]

Ever.

Ah well.

I suppose I'll edit the part files individually.

Thanks mate.

[Gaalidas]

Okay, after lurking in the shadows for about a year now (yes, I know... it's pretty creepy eh?) I find myself unable to continue without personally asking a question.

From what I understand, module manager is unable to save a value as a variable and use it later in the current patch. With this in mind, I was thinking that perhaps I could do a wildcard search for a module within a part and check to see if a value is equal to a certain predefined value and only apply the patch if that works. Specifically, I'm trying to add a new gimbal module to all engines that have a standard gimbal on them (as part of a mod that automates the gimbal centering process) but the new module requires specifying the transform-name. Most squad engines use "thrustTransform" but the rapier engine does not, and many modded engines also do not. If I could test for the specific value of the "gimbalTransformName" property to equal something that I define in the search, then I might be able to, at the very least, manually account for multiple common values for that property and limit the number of patches to every single engine in any mod I use that I have to write by hand. Am I making any sense?

So, to wrap this up, what I'm looking for is a wildcard search that finds all parts with "ModuleGimbal" where that module contains "gimbalTransformName" equal to a value that I specify, then applies my patch to that part. An example of this would be helpful, I learn best by example.

Thanks in advance.

[Alewx]

Ok it is official, i'm, too dump.

I wanted to make a MM file for changing the stepIncrement of the 0.15 Infernal Robotics parts.

So I made a Little Folder with one single .cfg file that should only do that.

@Part[*]HAS[#stepIncrement[*]]:Final
{
	@stepIncrement = 1.0
}

What am I doing wrong?

Edited May 16, 2014 by Alewx

[Quiana]

Ok it is official, i'm, too dump.

I wanted to make a MM file for changing the stepIncrement of the 0.15 Infernal Robotics parts.

So I made a Little Folder with one single .cfg file that should only do that.

@Part
[*]HAS[#stepIncrement
[*]]:Final
{
    @stepIncrement = 1.0
}

What am I doing wrong?

There needs to be a : in there, specifically: @Part

[*]:HAS[#stepIncrement

[*]]:Final

The rest looks okay to me, which leads to my own question.

Can we search @PART

[*] while excluding specific parts? EX:

@PART[*,!RCSBlock]:HAS[@MODULE[ModuleRCS]]:Final

It, to me, logically should work but does not appear to. The example I want to do for this is boost all other RCS module thrust *2 while leaving out the two stock ones (because they're already modified by another CFG change to be hard-set to 2x).

Edited May 16, 2014 by Quiana

[mwlue]

texture = (URL to texture) in the MODEL node

Hey, just to notify the exact sytax is "texture = original_texture_name, path_to_new_texture/new_texture_name"

file extension eg. .tga .png is not needed.

db reload will void the patch.

[K3-Chris]

Is there some way to determine if various mods are installed? I've like to supply an alternate version of an IVA for people that don't have RasterPropMonitor.

[Alewx]

There needs to be a : in there, specifically: @Part

[*]:HAS[#stepIncrement

[*]]:Final

The rest looks okay to me, which leads to my own question.

Can we search @PART

[*] while excluding specific parts? EX:

@PART[*,!RCSBlock]:HAS[@MODULE[ModuleRCS]]:Final

It, to me, logically should work but does not appear to. The example I want to do for this is boost all other RCS module thrust *2 while leaving out the two stock ones (because they're already modified by another CFG change to be hard-set to 2x).

Thanks for the solution. Should have seen it myself

[swamp_ig]

is there some way to determine if various mods are installed? I've like to supply an alternate version of an iva for people that don't have rasterpropmonitor.

For the section where you want the mod:

MODULE:NEEDS[someMod] { ... }

or:

key:NEEDS[someMod] = value

Similarly for !SomeMod if you want it if the mod isn't there. You'll need 2.1.3.

Edited May 17, 2014 by swamp_ig

[swamp_ig]

Here's a new version of MM:

The only real change since 2.1.2 is that I've dialed-down some of the backups.

You'll only get a backup created if there's some major change, mostly only when you delete or add new mods.

These times include:

• A part is deleted that is used in a craft or vessel in flight
  
• A part contains a module that has been deleted (module config will be backed up in the part)
  
• A new module is added to a part.
  
• A module is re-added to a part after being backed up.
  
  
  You won't get backups when:
  
  • The order of modules changes (this used to result in broken saves)
    
  • Modules are added to parts using AddModule in the VAB or in flight
    

The upshot:

It's now safe to add and remove mods. Most of the time it won't mess up your save games. This is of course best-effort, and mod coders will have to handle having their mods being removed and then added back again later, but it's a lot better than before.

If you delete a mod you may end up getting new backups every time you load the game. This will occur if you delete a mod and have a quicksave with vessels that have modified parts in them. If you look in the saves_backup dir, there's subdirs for every backup with date and timestamps, and you can have a look a the logs to see what's going on.

The thing to do is that if you delete a mod, go through your existing saves and load them up, and do a quicksave to overwrite the existing quicksave. You can always restore from the backup in the future if you want to.

Edited May 17, 2014 by swamp_ig

[K3-Chris]

For the section where you want the mod:

MODULE:NEEDS[someMod] { ... }

or:

key:NEEDS[someMod] = value

Similarly for !SomeMod if you want it if the mod isn't there. You'll need 2.1.3.

RPM adds

MODULE {
		name = RasterPropMonitorComputer
}

To pods, can you set INTERNAL using that method? ie:

@PART[*]:HAS[@INTERNAL[b9S26m]]

{

@Internal:NEEDS[RasterPropMonitorComputer] {@name = B9S26mRPM}

MODULE { name = RasterPropMonitorComputer }

}

other pods get RasterPropMonitorComputer, does the specific part need it?

[ialdabaoth]

Is there some way to determine if various mods are installed? I've like to supply an alternate version of an IVA for people that don't have RasterPropMonitor.

That's exactly what :NEEDS[] is for.

[K3-Chris]

I cant wrap my head around some of this MM syntax, swamp tried to explain it to me on IRC but I didn't manage to absorb it all, he mentioned being able to check if a part exists or not to do MM changes or not to other parts, and being able to make parts using MM to act in this capacity as a variable more or less.

@PART[somePartName]:FOR[Whatever] { }

He gave me that line, but I'm not sure what to do with it, could someone less thick please provide an example that changes something about "PartA" if "PartB" exists and another example that makes said "PartB" in such a manner that a mod could include that mm.cfg for people to check if the mod is installed or not using the first example?

Sadly the mod in question doesn't include a .dll and uses a grouped up author-based root folder in gamedata which checking if it exists or not just tells you if you got something from that author, not if you got this particular addon.

Addon in question is the ASET Prop pack: http://forum.kerbalspaceprogram.com/threads/54925 I want to provide alternate IVAs based on it being installed or not instead of having to have it as a hard dependency.

[Quiana]

I cant wrap my head around some of this MM syntax, swamp tried to explain it to me on IRC but I didn't manage to absorb it all, he mentioned being able to check if a part exists or not to do MM changes or not to other parts, and being able to make parts using MM to act in this capacity as a variable more or less.

@PART[somePartName]:FOR[Whatever] { }

He gave me that line, but I'm not sure what to do with it, could someone less thick please provide an example that changes something about "PartA" if "PartB" exists and another example that makes said "PartB" in such a manner that a mod could include that mm.cfg for people to check if the mod is installed or not using the first example?

Sadly the mod in question doesn't include a .dll and uses a grouped up author-based root folder in gamedata which checking if it exists or not just tells you if you got something from that author, not if you got this particular addon.

Addon in question is the ASET Prop pack: http://forum.kerbalspaceprogram.com/threads/54925 I want to provide alternate IVAs based on it being installed or not instead of having to have it as a hard dependency.

The second one isn't too bad.

@Part[bravo]:NEEDS[!ExampleModName] { Do things }

In this case, perform something to BRAVO if there is not ALCOR installed. You'll just need to use the name of the DLL for that prop pack (Name.dll) and drop the .dll off the end. Then it will ONLY fire if the DLL is not there.

[K3-Chris]

Again as said it doesn't include a .dll hence I'm asking the author to make a part to act as a check, it only includes props.

Edit: Sarbian helped me out, disregard question

Edited May 17, 2014 by K3|Chris

[swamp_ig]

After looking at what K3|Chris was asking - I felt it would be good if you could use NEEDS and BEFORE / AFTER for mods that don't specify much in the way of MM code.

To enable that here's release 2.1.4.

This will scan the subdirs under GameData, and enable them for NEEDS checking.

Edit: To clarify - if you have a mod installed under GameData in a directory called MyMod, then you can use :NEEDS[MyMod] for any config that you want to be dependent on that mod being present.

Edited May 18, 2014 by swamp_ig

[Haze-Zero]

I do not know why, and I peeked a tiny bit around this forum to see if I missed something and I am sorry I didn't dig deeper but my KSP will never reach the main-menu screen if I use a ModuleManager 2.1.3 or 2.1.4.

I can go back to 2.1.0 and the game loads fine. I would have tried 2.1.2 or 2.1.1 to test but I don't have those dll files in any of the mods I downloaded recently. Yes, I saw the thing about 2.0.7 updating to 2.1.0 and got past that without a problem. I haven't done any other experimentation to help shed any light on this issue. I write this in hopes that I perhaps missed something I needed to do, but didn't or in perhaps I am not the only one with the issue.

Update: I found the releases folder on GitHub and I have tried 2.1.2 version. The game fails to reach the menu screen there also.

Edited May 18, 2014 by Haze-Zero

[NathanKell]

We need your KSP/KSP_Data/output_log.txt (or player.log on Mac/linux). Just saying "it won't load" doesn't really give us any information.

[Haze-Zero]

We need your KSP/KSP_Data/output_log.txt (or player.log on Mac/linux). Just saying "it won't load" doesn't really give us any information.

Thank you for pointing me towards the output log, it shed some light on things. It seems that the newer versions of ModMan is going through EVERY persistence file I had in the game, some going back as far as .19. Many of these I have not loaded into the game possibly since .19, so their persistence files have a ton of flights with ships, many with mods I do not even use anymore (such as Kethane). With each new version of KSP or even when I change a large mods (like Kethane), I will make copy the last save game and use notepad++ to edit/update whatever it is I need to update in the persistence and leave the old game profiles sitting, incase I need to go back to them for whatever reason. Now I suspect that if I left KSP (and ModMan) sit there and do its thing for 20 minutes or so, it would eventually load the main-menu but I never did that because I thought it froze right there.

To solve my issue, I simply zipped up the old saved profiles leaving only 1 single persistence and 1 single profile that I have active. This cuts down my wait time and it loads the main-menu.