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

Starwaster · February 22, 2018

54 minutes ago, 1of6Billion said:

Nyan Cats... April Fools is early this year

It's never too early for Nyan!!!

AG5BPilot · February 23, 2018

If I had to guess, the herd of cats is an indicator that MM is unable to connect with Github to check if there's a new version available. That, in turn, could be because Github deprecated TLS 1 today. (That broke CKAN today.) It could be just a coincidence that the cats appeared when Github deprecated the protocol, but it seems like a likely culprit.

Krakatoa · February 23, 2018

27 minutes ago, AG5BPilot said:

If I had to guess, the herd of cats is an indicator that MM is unable to connect with Github to check if there's a new version available. That, in turn, could be because Github deprecated TLS 1 today. (That broke CKAN today.) It could be just a coincidence that the cats appeared when Github deprecated the protocol, but it seems like a likely culprit.

From what I hear, it's just coincidence, today (2/22) is apparently National Cat Day in Japan.

sarbian · February 23, 2018

3 hours ago, AG5BPilot said:

If I had to guess, the herd of cats is an indicator that MM is unable to connect with Github to check if there's a new version available. That, in turn, could be because Github deprecated TLS 1 today. (That broke CKAN today.) It could be just a coincidence that the cats appeared when Github deprecated the protocol, but it seems like a likely culprit.

You should read about Occam razor.

Starwaster · February 24, 2018

On 2/23/2018 at 4:44 AM, sarbian said:

You should read about Occam razor.

The simplest explanation is that Module Manager has become self aware and is testing us through the Nyan Cats....

Newbinator · February 27, 2018

I am not sure if this is the correct place to ask but I am trying to compile .cfg file for mm. What I am trying to achieve (as an experiment) is to apply a surface shine to all part except wheels for rovers and such. My attempt at the script is as follows

@PART[*]:HAS[!MODULE[TRR_Reflection]]:NOT[!ModuleWheelBase]:NEEDS[TextureReplacerReplaced]
{
   %MODULE[TRR_Reflection]
   {
%name = TRR_Reflection
%shader = ShaderNG/TR_Reflective_Emissive_Alpha
%colour = 0.5 0.5 0.5
%interval = 4
%meshes =
   }
}

This part ":NOT[!ModuleWheelBase]" is my attempt exclude wheels. I tried to understand the reference material provided in the ModuleManger Syntax page with in the MM Wiki and have tested various versions but to no avail.
Could I ask anyone can suggest how this can be achieved, please? If I am asking in the wrong forum, any suggestions where to ask would be appreciated

Warezcrawler · February 27, 2018

7 hours ago, Newbinator said:

I am not sure if this is the correct place to ask but I am trying to compile .cfg file for mm. What I am trying to achieve (as an experiment) is to apply a surface shine to all part except wheels for rovers and such. My attempt at the script is as follows

@PART[*]:HAS[!MODULE[TRR_Reflection]]:NOT[!ModuleWheelBase]:NEEDS[TextureReplacerReplaced]
{
   %MODULE[TRR_Reflection]
   {
%name = TRR_Reflection
%shader = ShaderNG/TR_Reflective_Emissive_Alpha
%colour = 0.5 0.5 0.5
%interval = 4
%meshes =
   }
}

This part ":NOT[!ModuleWheelBase]" is my attempt exclude wheels. I tried to understand the reference material provided in the ModuleManger Syntax page with in the MM Wiki and have tested various versions but to no avail.
Could I ask anyone can suggest how this can be achieved, please? If I am asking in the wrong forum, any suggestions where to ask would be appreciated

Maybe this will work

@PART[*]:HAS[!MODULE[TRR_Reflection,!ModuleWheelBase]]:NEEDS[TextureReplacerReplaced]

You are checking that two modules does not exist in the part. That mean you have two criteria for your "HAS[]" statement.

I do not remember if you should use the comma (",") or maybe a "|" or something else between the criteria. It is in the documentation if comma does not do the trick.

AccidentalDisassembly · February 27, 2018

4 hours ago, Warezcrawler said:

Maybe this will work

@PART[*]:HAS[!MODULE[TRR_Reflection,!ModuleWheelBase]]:NEEDS[TextureReplacerReplaced]

You are checking that two modules does not exist in the part. That mean you have two criteria for your "HAS[]" statement.

I do not remember if you should use the comma (",") or maybe a "|" or something else between the criteria. It is in the documentation if comma does not do the trick.

Think it needs to be HAS:[!MODULE[TRR_Reflection],!MODULE[ModuleWheelBase]]:etc. <--- meaning only apply to parts that don't have TRR_Reflection, and also don't have ModuleWheelBase.

Otherwise - if I'm reading that right, the extra ! in your patch might mean something like: check that the part does not have TRR_Reflection, and does not NOT have ModuleWheelBase... I think a comma alone without an ! might also work inside the !MODULE[] as well.

Newbinator · February 28, 2018

10 hours ago, Warezcrawler said:

Maybe this will work

@PART[*]:HAS[!MODULE[TRR_Reflection,!ModuleWheelBase]]:NEEDS[TextureReplacerReplaced]

You are checking that two modules does not exist in the part. That mean you have two criteria for your "HAS[]" statement.

I do not remember if you should use the comma (",") or maybe a "|" or something else between the criteria. It is in the documentation if comma does not do the trick.

6 hours ago, AccidentalDisassembly said:

Think it needs to be HAS:[!MODULE[TRR_Reflection],!MODULE[ModuleWheelBase]]:etc. <--- meaning only apply to parts that don't have TRR_Reflection, and also don't have ModuleWheelBase.

Otherwise - if I'm reading that right, the extra ! in your patch might mean something like: check that the part does not have TRR_Reflection, and does not NOT have ModuleWheelBase... I think a comma alone without an ! might also work inside the !MODULE[] as well.

I would like to thank you for you help, very very appreciated.

The end result is:

@PART[*]:HAS[!MODULE[TRR_Reflection],!MODULE[ModuleWheelBase]]:NEEDS[TextureReplacerReplaced]

I again thank you for your help

HaullyGames · March 3, 2018

Hi everyone,

Do u know how I can get a value from a module through MM?

The example below I get #$../CrewCapacity$ value from Part:

@PART[*]:HAS[#CrewCapacity[>0]]:NEEDS[ProfileDefault]:FOR[Kerbalism]
{
  MODULE
  {
    name = ProcessController
    resource = _Scrubber
    title = Scrubber
    capacity = #$../CrewCapacity$
    running = true
  }
}

How should this code be if I had to get a value from a module?

Thank you!

HaullyGames · March 3, 2018

6 hours ago, HaullyGames said:

Do u know how I can get a value from a module through MM?

nvm!

Apaseall · March 5, 2018

Hello, would someone be kind and help me out with this little patch I am trying to make please.

I have this:

Spoiler

@EXPERIMENT_DEFINITION[*]:HAS[#id[WBI*]&#requiredPart[Doc?Science?Lab]]:NEEDS[OPT_h_3m_lab_mm]:AFTER[Pathfinder]
{
requiredPart = OPT H Mounted Science Lab
}

I am trying to add requiredPart = OPT H Mounted Science Lab to the list of experiments that current have a requiredPart = Doc Science Lab. These are defined in GameData\WildBlueIndustries\000WildBlueTools\Experiments\BasicExperiments.cfg

Here is an example of one experiment I am trying to add to:

Spoiler

EXPERIMENT_DEFINITION
{
   id = WBIPowerToolsEvaluation
   title = Power Tools Evaluation
   baseValue = 24
   scienceCap = 48
   dataScale = 1
   biomeMask = 7
   situationMask = 63
   description = What happens if you try to turn a screwdriver in space? The Power Tools Evaluation will evaluate different designs for power tools to find the ones that work best in a microgravity environment.
   mass = 0.01
   techRequired = spaceExploration
   tags = basic
   minCrew = 1
   requiredResources = LabTime,36
   situations = ORBITING

   requiredPart = M.O.L.E.
   requiredPart = LDEF Science Processor
   requiredPart = Bigby Orbital Workshop
   requiredPart = D2 Centrifuge
   requiredPart = D2 Science Module
   requiredPart = GondoLab
   requiredPart = Doc Science Lab
   requiredPart = Tranquility Mk2 Habitat

   RESULTS
   {
       default = We've found some tool designs that work in microgravity.
       KerbinInSpace = When turning a screwdriver in one direction, the kerbal will spin in the opposite direction. Future tools should have counter-torque systems built in.
       KerbinInSpace = Kerbals like hammers. They're particularly useful on cantankerous electronics.
       KerbinInSpace = Hand saws are great for zombie apocolypses but aren't so effective in space. Recommend mounting the saw to a bulkhead or other massive object.
       KerbinInSpace = Powered wirecutters should have a hand crank in case extra force is needed.
       KerbinInSpace = Kerbals like kPads. Just sayin.
       MunInSpace = Tool design does not appear to be affected by what body we orbit. The engineers refer you to the results from Kerbin orbit.
       MinmusInSpace = In a completely unexpected finding, orbiting Minmus appears to be the same as orbiting Kerbin for designing hammers. There have been some interesting ideas for ice cream scoops though.
       MunSrfLanded = Screwdriver designs for the Mun appear to be much easier than for microgravity. It has to do with Bill being able to put his feet on the ground.
       MunSrfLanded = Mundust appears to be electrically charged and very fine. Ideal for making power tools malfunction.
       // Note that the 'Y/S' is intentional, not a typo. It's malfunctioning.
       MunSrfLanded = kPads and Mundust do *bsszt* SAVEFILE HAS BEEN CORRUPTED, REBOOT (Y/S).
   }
}

In output log I can see:

Spoiler

Line 78032: Config(@EXPERIMENT_DEFINITION[*]:HAS[#id[WBI*]&#requiredPart[Doc?Science?Lab]]:NEEDS[OPT_h_3m_lab_mm]:AFTER[Pathfinder]) my_MM/OPT_h_3m_lab_mm_Exp_Def_requiredPart/@EXPERIMENT_DEFINITION[*]:HAS[#id[WBI*]&#requiredPart[Doc?Science?Lab]]:NEEDS[OPT_h_3m_lab_mm]:AFTER[Pathfinder]

There is no deleting root node or deleting node entry.

Most importantly there is no applying update entry.

Eventually I have come to believe that the patch is not being applied because it cannot satisfy it :HAS. Specifically the :HAS[#requiredPart[Doc?Science?Lab]]. I think this is because there are multiple entries for the name value pairs requiredPart. Possibly the existing code is trying to match only on index 0. This would fail obviously.

So am I right in thinking why the patch is not applying?

How would I rewrite the code to force it to search through all the entries for requiredPart, other than specifying each index, which would require me to know the size of the index etc etc.

I am quite new to writing patches and I am full of zeal right now lol.

Must say then a great big thank you to @sarbian for this truly game changing mod. Thank you.

sarbian · March 5, 2018

4 hours ago, Apaseall said:

So am I right in thinking why the patch is not applying?

@EXPERIMENT_DEFINITION[*] search for node with a name value. Experiments do not have a name so you need to do

@EXPERIMENT_DEFINITION,*:HAS[#id[WBI*]&#requiredPart[Doc?Science?Lab]]:NEEDS[OPT_h_3m_lab_mm]:AFTER[Pathfinder]
{
    requiredPart = OPT H Mounted Science Lab
}

Apaseall · March 5, 2018

3 minutes ago, sarbian said:
@EXPERIMENT_DEFINITION[*] search for node with a name value. Experiments do not have a name so you need to do
@EXPERIMENT_DEFINITION,*:HAS[#id[WBI*]&#requiredPart[Doc?Science?Lab]]:NEEDS[OPT_h_3m_lab_mm]:AFTER[Pathfinder]
{
    requiredPart = OPT H Mounted Science Lab
}

I see, so clear now that you point it out! Many thanks.

So <op>blah,* searches through all the sub nodes of blah? Which then can be tested with the :HAS

sarbian · March 5, 2018

Yep

Apaseall · March 5, 2018

Well this is odd. I even tried removing the :NEEDS

Spoiler

@EXPERIMENT_DEFINITION,*:HAS[#id[WBI*]&#requiredPart[Doc?Science?Lab]]:AFTER[Pathfinder]
{
requiredPart = OPT H Mounted Science Lab
}

I see: Config(@EXPERIMENT_DEFINITION,*:HAS[#id[WBI*]&#requiredPart[Doc?Science?Lab]]:AFTER[Pathfinder]) my_MM/OPT_h_3m_lab_mm_Exp_Def_requiredPart/@EXPERIMENT_DEFINITION,*:HAS[#id[WBI*]&#requiredPart[Doc?Science?Lab]]:AFTER[Pathfinder]

I do not see [ModuleManager] Applying update.

I also do not see either Deleting root node in file, or Deleting node in file

Is it still failing on #requiredPart[Doc?Science?Lab] because the experiment is like this:

Spoiler

EXPERIMENT_DEFINITION
{
id = WBIPowerToolsEvaluation
//snip

   requiredPart = M.O.L.E.
   requiredPart = LDEF Science Processor
   requiredPart = Bigby Orbital Workshop
   requiredPart = D2 Centrifuge
   requiredPart = D2 Science Module
   requiredPart = GondoLab
   requiredPart = Doc Science Lab
   requiredPart = Tranquility Mk2 Habitat

   RESULTS
   {
        //snip
   }
}

Starwaster · March 5, 2018

3 hours ago, Apaseall said:

Well this is odd. I even tried removing the :NEEDS

Hide contents

@EXPERIMENT_DEFINITION,*:HAS[#id[WBI*]&#requiredPart[Doc?Science?Lab]]:AFTER[Pathfinder]
{
   requiredPart = OPT H Mounted Science Lab
}

I see: Config(@EXPERIMENT_DEFINITION,*:HAS[#id[WBI*]&#requiredPart[Doc?Science?Lab]]:AFTER[Pathfinder]) my_MM/OPT_h_3m_lab_mm_Exp_Def_requiredPart/@EXPERIMENT_DEFINITION,*:HAS[#id[WBI*]&#requiredPart[Doc?Science?Lab]]:AFTER[Pathfinder]

I do not see [ModuleManager] Applying update.

I also do not see either Deleting root node in file, or Deleting node in file

Is it still failing on #requiredPart[Doc?Science?Lab] because the experiment is like this:

Hide contents

EXPERIMENT_DEFINITION
{
   id = WBIPowerToolsEvaluation
//snip

   requiredPart = M.O.L.E.
   requiredPart = LDEF Science Processor
   requiredPart = Bigby Orbital Workshop
   requiredPart = D2 Centrifuge
   requiredPart = D2 Science Module
   requiredPart = GondoLab
   requiredPart = Doc Science Lab
   requiredPart = Tranquility Mk2 Habitat

   RESULTS
   {
        //snip
   }
}

You will only see node deletion when a :NEEDS isn't met. It's not done for other conditonals such as :HAS - deletion happens so that it doesn't try to match on any parts at all.
As far as mod names go, ModuleManager only looks for folders immediately under GameData or for plugin dll names. Pathfinder is actually under WildBlueIndustries so that is what you should specify for the scheduled AFTER phase.
Change @EXPERIMENT_DEFINITION,*:HAS[#id[WBI*]&#requiredPart[Doc?Science?Lab]] to @EXPERIMENT_DEFINITION:HAS[#id[WBI*]&#requiredPart[Doc?Science?Lab]] (take note @sarbian )

Point #3 will definitely kill the patch. Not sure how MM reacts if you schedulef or non-existent phases but I think that can kill it too. Point #1 is just to clear up when you will see nodes being deleted in the logs.

Just to clarify: are you intending to add this patch to EVERY WBI experiment? Because that's what #id[WBI*] will do. Not just WBIPowerToolsEvaluation but to EVERY WBI experiment def. (I checked; there are thirteen of them)

Anyway, just fix points 2 and 3 and it should patch.

Edited March 5, 2018 by Starwaster

DStaal · March 5, 2018

2 minutes ago, Starwaster said:

As far as mod names go, ModuleManager only looks for folders immediately under GameData or for plugin dll names. Pathfinder is actually under WildBlueIndustries so that is what you should specify for the scheduled AFTER phase.

This is somewhat incomplete, and doesn't apply here. The incomplete is that there is an important third condition that often gets overlooked: A config with a ':FOR[ModName]' will also trigger the mod.

The reason it doesn't apply here is that Pathfinder includes a Pathfinder .dll file, so that will trigger it, despite the fact that it's a couple of levels deep. So, no need to change. (And in fact, if changed to 'WildBlueIndustries' the patch might trigger when Pathfinder isn't present, as that's not the only mod that uses that folder.)

Apaseall · March 5, 2018

5 minutes ago, Starwaster said:

You will only see node deletion when a :NEEDS isn't met. It's not done for other conditonals such as :HAS - deletion happens so that it doesn't try to match on any parts at all.

As far as mod names go, ModuleManager only looks for folders immediately under GameData or for plugin dll names. Pathfinder is actually under WildBlueIndustries so that is what you should specify for the scheduled AFTER phase.

Change @EXPERIMENT_DEFINITION,*:HAS[#id[WBI*]&#requiredPart[Doc?Science?Lab]] to @EXPERIMENT_DEFINITION:HAS[#id[WBI*]&#requiredPart[Doc?Science?Lab]] (take note @sarbian )

Point #3 will definitely kill the patch. Not sure how MM reacts if you schedulef or non-existent phases but I think that can kill it too. Point #1 is just to clear up when you will see nodes being deleted in the logs.

Just to clarify: are you intending to add this patch to EVERY WBI experiment? Because that's what #id[WBI*] will do. Not just WBIPowerToolsEvaluation but to EVERY WBI experiment def.

Anyway, just fix points 2 and 3 and it should patch.

Thanks for the clarity on point 1.

I am using Pathfinder in the :AFTER as there is a Pathfinder.dll. I was under the impression that dll names where something I could test for.

Yes it is my intention to patch every WBI experiment, if those experiments already have a requiredPart = Doc Science Lab.

I have a new lab and I want it to be able to function like a lab, using WBI experiments.

To do so I am basically saying 'hey I have a crew cabin I have converted into a lab, its an OPT part but I want it to behave like it is the Doc Science Lab from WBI'. I believe I have all the lab setup correctly, but it will not let me perform experiments, because a requirement is not being met, the experiments clearly state that one of a list of parts must be present, one of which is the Doc Science Lab. As I understand it I only have to meet one of the requirements. Rather than trying to fool KSP into thinking my plane lab is another Doc Science Lab I thought I would patch the requirements to add my new lab.

Yes @DStaal. I need Pathfinder to be present as all the lovely modules that make a lab a lab, in terms of a WBI lab-a-like, come from my examination of the Pathfinder Doc Science Lab.

Starwaster · March 5, 2018

2 minutes ago, Apaseall said:

I am using Pathfinder in the :AFTER as there is a Pathfinder.dll. I was under the impression that dll names where something I could test for.

Yes it is my intention to patch every WBI experiment, if those experiments already have a requiredPart = Doc Science Lab.

Ok then just remove that one ,* after EXPERIMENT_DEFINITION and it should be fine

9 minutes ago, DStaal said:

This is somewhat incomplete, and doesn't apply here. The incomplete is that there is an important third condition that often gets overlooked: A config with a ':FOR[ModName]' will also trigger the mod.

I had already covered that with him elsewhere

Apaseall · March 5, 2018

Got to say, many thanks folks for helping me out. I am trying out the patch as I write. I am also trying out something else which is making my head ache.

So...As a different question I am having trouble doing this:

:HAS [A AND ( NOT ( B OR C OR D OR E ) ) ]

I tried :HAS [ A & !B | !C | !D | !E ]

But I got no where fast. How do I write what I am trying to achieve? Spaces are added just to make it clearer here, not in the patch.

I think I can get :HAS [ A & !B | !C ] to work as A AND ( NOT ( B OR C ) ) but when I expand it out to more than B, C I run into trouble.

Any guidance would be great.

Apaseall · March 5, 2018

On now this is not expected:

Spoiler

When the patch says:

Spoiler

@PART:HAS[#manufacturer[OPT?Aerospace?Division]&#name[opt_wing*]|#name[opt_stab*]]:NEEDS[OPT&ConnectedLivingSpace]:AFTER[OPT]
{
   -MODULE[ModuleConnectedLivingSpace] {}
}
@PART:HAS[#manufacturer[OPT?Aerospace?Division]&#name[opt_pylon*]|#name[?_drone*]]:NEEDS[OPT&ConnectedLivingSpace]:AFTER[OPT]
{
   -MODULE[ModuleConnectedLivingSpace] {}
}
@PART:HAS[#manufacturer[OPT?Aerospace?Division]&#name[opt_oms*]|#name[opt_rcs*]]:NEEDS[OPT&ConnectedLivingSpace]:AFTER[OPT]
{
   -MODULE[ModuleConnectedLivingSpace] {}
}
@PART:HAS[#manufacturer[OPT?Aerospace?Division]&#name[i_4m_tail]|#name[mk2_ramIntake]]:NEEDS[OPT&ConnectedLivingSpace]:AFTER[OPT]
{
   -MODULE[ModuleConnectedLivingSpace] {}
}
@PART:HAS[#manufacturer[OPT?Aerospace?Division]&#name[j_engine*]|#name[j_linear_aerospike]]:NEEDS[OPT&ConnectedLivingSpace]:AFTER[OPT]
{
   -MODULE[ModuleConnectedLivingSpace] {}
}
@PART:HAS[#manufacturer[OPT?Aerospace?Division]&#name[engine_darkDrive]|#name[AAengine]]:NEEDS[OPT&ConnectedLivingSpace]:AFTER[OPT]
{
   -MODULE[ModuleConnectedLivingSpace] {}
}
@PART:HAS[#manufacturer[OPT?Aerospace?Division]&#name[opt_nebula_engine]|#name[opt_mk2_engine_short]]:NEEDS[OPT&ConnectedLivingSpace]:AFTER[OPT]
{
   -MODULE[ModuleConnectedLivingSpace] {}
}
@PART:HAS[#manufacturer[OPT?Aerospace?Division]&#name[opt_retro_rcs]]:NEEDS[OPT&ConnectedLivingSpace]:AFTER[OPT]
{
   -MODULE[ModuleConnectedLivingSpace] {}
}

MM is being too clever because at present I only get:

Spoiler

Which is the same result I would get if:

Spoiler

@PART:HAS[#manufacturer[OPT?Aerospace?Division]&#name[opt_wing*]]:NEEDS[OPT&ConnectedLivingSpace]:AFTER[OPT]
{
-MODULE[ModuleConnectedLivingSpace] {}
}

So not helpful. grrArg!

sarbian · March 5, 2018

There is no OR. OR means priorities, a more complex parser and more mess with the stock ConfigNode parser.

56 minutes ago, Starwaster said:

(take note @sarbian )

This mod is way too complex. I should complain to the maintainer.

Apaseall · March 5, 2018

3 minutes ago, sarbian said:

There is no OR. OR means priorities, a more complex parser and more mess with the stock ConfigNode parser.

This mod is way too complex. I should complain to the maintainer.

No OR, is that way to cryptic like, there is no spoon?

Pretty sure there is an OR " You can use & for AND, | for OR and ! for NOT in the needs listing. ". But I guess I am not really fully understanding your comment, other than the I like the bit about it being complex.

BTW I am not complaining, I am trying to learn my way around

@StarWarp and @DStaal The @EXPERIMENT_DEFINITION:HAS[#id[WBI*]&#requiredPart[Doc?Science?Lab]]:AFTER[Pathfinder] appears to now be applying the patch. Great Stuff.

Now back to the A AND ( NOT ( B OR C ) )...

DStaal · March 5, 2018

I'd go with two-pass: One patch applies a dummy module (Z) on B or C, the second applies on A not Z.

If you want to be clean, then do a third afterwards that removes Z.

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

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation