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

[sirklick]

In need of a nth pair of eyes. Attempting to remove a bunch of the default nodes from FusTek station parts with

@PART[Karmony*]
{
	!MODULE[ModuleReactionWheel]
	!MODULE[ModuleCommand]
	!MODULE[MechJebCore]
	!MODULE[ModuleSAS]
	!MODULE[ModuleRemoteTechSPU]
	!RESOURCE[MonoPropellant]
	!MODULE[ModuleGenerator]
}

but failing. Ideas?

Edit: Solution found. DL'ed 1.5.6 from a link deep in thread and ended each removal line with {}. Works now.

Edited December 30, 2013 by sirklick
Solution found

[Black-Talon]

I've been thinking for awhile that it would be really nice if there was a utility that worked with Module Manager to do a few things with MM configs:

1. Creates a list/csv of changes applied by MM: [PartName][Key][stockValue][NewValue] - ideally this would use a shared parsing engine so it could be used to test if your configs are working without loading the game
   
2. An "export configs from the in game database" in game - I don't have a great reason "why" anyone would want this - but the idea is that actual part configs could be written out to disk that include all loaded ModuleManager config tweaks - perhaps then someone who doesn't want to run ModuleManager DLL could go back to the old days of overwriting stock config files - or at least an easy diff between files could show you the changes (getting you a poor man's version of #1)
   
3. (bonus)Once I dream of a world with these things it feels obvious that there should be a reverse option to take a modified-from-stock config file and create a ModuleManager config that would correctly modify a stock config to the modified config (used in order to easily create/distribute your config changes to others). OR of course an easy part editor, spreadsheet driven, part editor that drives the creation of MM configs for distribution would be fun.
   

So #1 at least has always seemed super useful. Especially now that so many modders are in fact using the awesomeness of ModuleManager but without a lot of work you're never quite sure what has been changed (I always used to diff files to see updates, now I can't as easily). Does something like that already exist by chance? Tempted to make something myself but I know my time limits will likely prevent me.

[sarbian]

You can check the in game value with the KSP debug menu (ALT F12) for PART, RESOURCE and others I forgot. It require to load the game but it's better than nothing at all.

[sirklick]

I would like to make a suggestion, include links to the point releases in the op. I understand the want/need to not rev MM frequently, but having easy to find fixes that address issues that people are having with the current major release would likely save people a lot of time and frustration. Thank you again for all of your work on MM.

[alacrity]

Ok so after perusing a bulk of the thread, I am having problems getting started on the new syntax.

I am just trying to add parts to the tech tree. After all the high end functioning I see noted in the posts here I feel a bit a nubbin but I just need the header for a basic config, or better yet the syntax bible.

Alacrity

[sarbian]

sirklick : Previous point version had bugs. I wanted to be sure the current one as none before putting it on the front page. Will do next year

alacrity : all you need for that is in the second post. Here is 2 example for techlevel :

Setting all part without a tech level to advScienceTech

@PART[*]:HAS[~TechRequired[]]:Final
{
	TechRequired=advScienceTech
}

Setting one part to advScienceTech

@PART[NameOfThePart]:Final
{
	TechRequired=advScienceTech
}

[Black-Talon]

You can check the in game value with the KSP debug menu (ALT F12) for PART, RESOURCE and others I forgot. It require to load the game but it's better than nothing at all.

Right, I knew that. That helps you find out what a particular part's loaded settings are. And that's nice. But in order to understand what all the changes being made by module manager are you'd need to know ahead of time what parts were being modified and what their stock values were in order to look them up in game. This is possible to do but requires opening up all the config files. That's A LOT of config files and A LOT of manually comparing files in order to understand all the changes being made.

What I'm thinking about making is something that allows you to quickly see all the changes ModuleManager has made to your parts. Ideally this would point out places where multiple changes are being made to the same part (potentially by separate mods, potentially conflicting). But much more importantly, answering the question, "What changes have been made to the stock parts anyway!?" Without loading up all the MM Configs AND all the part configs to see what was changed to what.

[alacrity]

Ok I found the reference post and got started... It is a little more complex than I thought... and too many parts to do one at a time. Please take a look at this a let me know where I am going wrong

@PART[JARFR_Tri*]:HAS[#category[Structural]]
{
 TechRequired = advConstruction
}

@PART[JARFR_TriStrutA*]:HAS[#category[Structural]]
{
 TechRequired = basicRocketry
}

@PART[GE_THSS*]:HAS[#category[Structural]]
{
 TechRequired = advConstruction
}

@PART[GE_THSS*]:HAS[#category[Control]]
{
 TechRequired = specializedControl
}

@PART[JARFR_*:HAS[#breakingForce[100]]
{
 TechRequired = aerodynamicSystems
}

@PART[JARFR_*:HAS[#breakingForce[200]]
{
 TechRequired = aerodynamicSystems
}

@PART[JARFR_Tri*]:HAS[@MODULE[ModuleEngines]:HAS[ @PROPELLANT[XenonGas]]
{
 TechRequired = ionPropulsion
}

@PART[JARFR_Tri*]:HAS[@MODULE[ModuleEngines]:HAS[ @PROPELLANT[LiquidFuel]]
{
 TechRequired = heavierRocketry
}

@PART[JARFR_TriStrutN*]:HAS[@MODULE[ModuleEngines]:HAS[ @PROPELLANT[LiquidFuel]]
{
 TechRequired = heavierRocketry
}

@PART[JARFR_Tri*]:HAS[#category[Control]]
{
 TechRequired = specializedControl
}

@PART[JARFR_Tri*]:HAS[#category[Pods]]
{
 TechRequired = specializedControl
}

@PART[JARFR_Tri*]:HAS[@Resource[MonoPropellant]]
{
 TechRequired = fuelSystems
}

@PART[JARFR_Tri*]:HAS[@Resource[LiquidFuel]]
{
 TechRequired = fuelSystems
}

@PART[JARFR_Tri*]:HAS[@Resource[XenonGas]]
{
 TechRequired = ionPropulsion
}

@PART[GE_THSS*]:HAS[@Resource[LiquidFuel]]
{
 TechRequired = fuelSystems
}

Thanx in advance

Alacrity

[sarbian]

5th and 6th one have a missing closing square bracket.

And I would avoid searching by breakingForce. Some other mod may change it before your patch.

[alacrity]

Silly question but is your wildcard operator this versatile?

@PART[*Heatshield]:HAS[#category[Structural]]
{
 TechRequired = aerodynamicSystems
}

@PART[*Heatshield]:HAS[#category[Structural]]
{
 TechRequired = aerodynamicSystems
}

The naming convention on the mod I am playing with is a nightmare to navigate

Ok so that didn't work... only a few of them actually got added...section 3 and 4 made it, but nothing else seemed to take.

Not seeing the differences but it may be conflicts in the wildcards

EDIT:

Well it seems that Module Manager does not like the JARFR_ naming convention for some reason... No ammount of changing the callout picks up the parts and places them...GRRRRRRRRR

EDIT 2:

So it turns out that I am an idiot... the callouts are based on the NAME inside the part cfg not the name of the containing folder... I will now crawl into a hole and die of shame

ALacrity

Edited December 31, 2013 by alacrity

[alacrity]

Final update... I argued and stabbed and lied my way through but managed to put together a working cfg for the THSS mod.

Naming conventions and crossover made it tricky but I managed to get things together without having to create an entry for every part.

Alacrity

[Galane]

Had to Google ModuleManager_1_5_6.dll to find http://www.sarbian.com/sarbian/ModuleManager_1_5_6.dll

A happy new year gift would be a forum search that can find individual posts instead of just threads, and indexes common three and four letter terms used in KSP.

[rottielover]

Question (as I'm not familiar with how this works). I downloaded RemoteTech2, AIES, and JohnsonWax's AIES module manager files for AIES. I made certain that I only have the ModuleManager 1.5.6 .dll file and no other module manager dll's anywhere in GameData. I'm getting 2 antenna modules in each of the antenna anyway?

It's as if there are two module managers, but I've done both Windows Search and visually went into each folder and could not find any more Module Manager DLL files. Any thoughts on what could be causing this?

[Starwaster]

Question (as I'm not familiar with how this works). I downloaded RemoteTech2, AIES, and JohnsonWax's AIES module manager files for AIES. I made certain that I only have the ModuleManager 1.5.6 .dll file and no other module manager dll's anywhere in GameData. I'm getting 2 antenna modules in each of the antenna anyway?

It's as if there are two module managers, but I've done both Windows Search and visually went into each folder and could not find any more Module Manager DLL files. Any thoughts on what could be causing this?

Yes, duplicate cfg files. Or a single config file with duplicate entries.

[rottielover]

Yes, duplicate cfg files. Or a single config file with duplicate entries.

Bingo! Thank you! Had a cfg hiding in a subfolder

[TheDude]

Greetings,

How do you change the atmospherecurve inside of the engine module?

I've tried this:

@PART[My_Engine]:Final

{

@MODULE[ModuleEngines]

{

@maxThrust = 150

@heatProduction = 325

@atmosphereCurve

{

@key = 0 600

@key = 0.25 463

@key = 1 200

}

}

}

The thrust and heat changes but for the life of me I can't get the atmosphere curves to change. They are always stay the original values as defined in the CFG file.

Best regards,

The Dude

[NathanKell]

@atmosphereCurve

{

@key,0 = //value for first key in original atmosphereCurve, like 0 600

@key,1 = // value for second key like 0.25 463

key = 1 200 // since original curve only had 2 values, right?

}

Or probably better since it doesn't depend on knowing the number of keys:

!atmosphereCurve {}

atmosphereCurve

{

key = 0 600

key = 0.25 463

key = 1 200

}

[TheDude]

Yep, that worked. For future searches this worked for me:

@PART[My_Engine]:Final

{

@MODULE[ModuleEngines]

{

!atmosphereCurve {}

@maxThrust = 150

@heatProduction = 325

atmosphereCurve

{

key = 0 575

key = 0.25 463

key = 1 188

}

}

}

[velusip]

It seems like the new RAPIER engine is missing the necessary tag variable required for this mod to query the multiple MODULES named ModuleEnginesFX independently. After adding appropriate tags to the RAPIER part, the following ModuleManager script works:

@PART[RAPIER]
{   
    @maxTemp = 1800
    @MODULE[ModuleEnginesFX,AirBreathing]
    {   
        @heatProduction = 300
    }
    @MODULE[ModuleEnginesFX,ClosedCycle]
    {   
        @heatProduction = 250
    }
}

To be fair, the "tag" feature of ModuleManager is a bit strange in that it imposes a part.cfg convention which Squad isn't necessarily going to follow. It would make more sense to open the syntax up a bit to allow queries for any variable or value. I thought that was what the new :HAS syntax is for, but I can't seem to make it work. In this case, we would like to query for the variable engineID which has either "AirBreathing" or "ClosedCycle" as a value. The following is one failed attempt of many, many variations:

@PART[RAPIER]
{       
    @maxTemp = 1800
    @MODULE[ModuleEnginesFX]:HAS[@engineID[AirBreathing]]
    {       
        @heatProduction = 300
    }
    @MODULE[ModuleEnginesFX]:HAS[@engineID[ClosedCycle]]
    {       
        @heatProduction = 250
    }
}

If possible, how should I discern a particular NODE of many without using tag?

[DennyTX]

gentlemen

any way to do someting like this?

@PART[*]:HAS[@MODULE[ModuleName]
[B][COLOR="#FF8C00"]get ModuleName[moduleProperty][/COLOR][/B]
{
[B][COLOR="#FF8C00"]IF (moduleProperty)>10[/COLOR][/B]
 @MODULE[name]
   {
     [COLOR="#FF8C00"][B]@moduleProperty*2[/B][/COLOR]
   }
[B][COLOR="#FF8C00"]ELSE[/COLOR][/B]
 @MODULE[ModuleName]
   {
    [B][COLOR="#FF8C00"] @moduleProperty/2[/COLOR][/B]
   }
[B][COLOR="#FF8C00"]ENDIF[/COLOR][/B]
}

this for changing properties depends of its previous value

Edited January 8, 2014 by DennyTX

[sarbian]

velusip it should be :

@PART[RAPIER]
{       
    @maxTemp = 1800
    @MODULE[ModuleEnginesFX]:HAS[#engineID[AirBreathing]]
    {       
        @heatProduction = 300
    }
    @MODULE[ModuleEnginesFX]:HAS[#engineID[ClosedCycle]]
    {       
        @heatProduction = 250
    }
}

DennyTX : no. MM is limited by the KSP parser.

[ZobrAA]

Can anyone give an example how % operator works?

[NathanKell]

@PART[foo]

{

%breakingForcce = 200 // will set breakingForce = 200, whether or not it exists.

}

just using breakingForce = 200 will add a duplicate if a breakingForce line already exists; @breakingForce = 200 will fail if no breakingForce line exists.

[TheDude]

Greetings,

I have several parts that I'd like to remove and/or replace the some of the models that they're composed of. I assume adding a model would be straight forward as

@PART[foo]:Final

{

MODEL { bla bla bla bla}

}

However, Id' like to completly remove some models and replace others. Since the MODEL{} is in no particular order in the config files, I'd need to search on the model name being loaded.

Best regards,

The Dude

[velusip]

velusip it should be :

@PART[RAPIER]
{       
    @maxTemp = 1800
    @MODULE[ModuleEnginesFX]:HAS[#engineID[AirBreathing]]
    {       
        @heatProduction = 300
    }
    @MODULE[ModuleEnginesFX]:HAS[#engineID[ClosedCycle]]
    {       
        @heatProduction = 250
    }
}

That's one of the many variations I tried. While it would be nice if it worked that way, it doesn't. I'm having a hard time following the the code, but I figure I'll start here and work backwards: https://github.com/sarbian/ModuleManager/blob/master/moduleManager.cs#L417