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

[blowfish]

1 minute ago, Bit Fiddler said:

how can I find the proper "name" for    :needs[ ]

my understanding is that if a mod has a .dll the name of that .dll is used here.  however I am also led to believe that if a mod does not have a .dll the mod author can somehow still give MM a "name" so others can use :For[ ] or :After[ ] etc.

the question is how can I find this name?  how and where is that defined?

There are 3 things that define a mod's existence to MM:

1. Presence of a dll with that name (as you guessed)
2. Presence of a directory with that name in GameData
3. Presence of a patched marked :FOR[xxx]

[Bit Fiddler]

ok so the mod in question is FTT by RoverDude.   it does not have a .dll as far as I can tell so the name must come from the directory or a :FOR[ ] ?

 

so the directory would be :Needs[UmbraSpaceIndustries\FTT]  ?

or with option 3 where is this :for[ ] defined?  I was under the impression that :For[ ] meant this mm patch should be run right after the mod...  differentiated from :after[ ] which was any time after that mod is done,  or :needs[ ] which may be done before or after just so long as the mod is installed.  is this not true?

[linuxgurugamer]

Will this work properly?  It will need to only process on parts in the MunarIndustries directory only, but be done before any patches are done from the InterstellarFuelSwitch mod are done.

This was copied from a patch from IFS and modified for my needs:

@PART[*]:FOR[MunarIndustries]:NEEDS[InterstellarFuelSwitch]:HAS[@RESOURCE[LiquidFuel],@RESOURCE[Oxidizer],!RESOURCE[MonoPropellant],!MODULE[ModuleTankManager],!MODULE[InterstellarFuelSwitch],!MODULE[FSfuelSwitch],!MODULE[B9PartSwitch],!MODULE[ModuleEnginesFX],!MODULE[ModuleEngines]]:NEEDS[InterstellarFuelSwitch&!CryoTanks&!ModularFuelTanks&!RealFuels]:BEFORE[InterstellarFuelSwitch]
{
blah blah blah
}

Thanks

[blowfish]

1 hour ago, Bit Fiddler said:

so the directory would be :Needs[UmbraSpaceIndustries\FTT]  ?

I've actually never seen that before.  Could you point to where it's used?

2 hours ago, Bit Fiddler said:

or with option 3 where is this :for[ ] defined?  I was under the impression that :For[ ] meant this mm patch should be run right after the mod...  differentiated from :after[ ] which was any time after that mod is done,  or :needs[ ] which may be done before or after just so long as the mod is installed.  is this not true?

FOR tells MM two things: (1) That the mod exists and any patches marked NEEDS, BEFORE, or AFTER that mod should be processed, and that (2) The patch should be processed during that mods pass

[Bit Fiddler]

@blowfish  Did I miss something?   in you previous post..

2 hours ago, blowfish said:

There are 3 things that define a mod's existence to MM:

1. Presence of a dll with that name (as you guessed)
2. Presence of a directory with that name in GameData
3. Presence of a patched marked :FOR[xxx]

this implied to me that if I supply a folder name like so:     :Needs[UmbraSpaceIndustries\FTT] 

that it would require that mod to be installed.  if this is not what you meant by #2 in your list, what did you mean?

 

 

27 minutes ago, blowfish said:

FOR tells MM two things: (1) That the mod exists and any patches marked NEEDS, BEFORE, or AFTER that mod should be processed, and that (2) The patch should be processed during that mods pass

right, exactly what I just said.  and this brings me back to the original question.  Where does this :For[ ] get defined.  it would be in the original mod makers hands to do this yes?  as it would need to be in the directory where the original parts etc. reside so MM knows "this directory belongs to a mod with some name"?  And if I use :For[ ] in a patch I make later the patch will become "attached" to the original mod as far as the order of processing is concerned?

 so in a mod that is parts only,and there are no MM patches made by the author to include a :For [ ].   I cant then use the :Needs[ ],  or :After[ ], etc.  so in the case of a mod with no .dll and no MM patches created by the author, how do I tell MM that it needs to be installed after this mod?  I assume with item 2 on your list.. a directory name.  thus the question for FTT example that had a compound directory name, does it work?

 

 

 

 

Edited May 23, 2017 by Bit Fiddler

[blowfish]

9 minutes ago, Bit Fiddler said:

@blowfish  Did I miss something?   in you previous post..

this implied to me that if I supply a folder name like so:     :Needs[UmbraSpaceIndustries\FTT] 

that it would require that mod to be installed.  if this is not what you meant by #2 in your list, what did you mean?

I addressed that with a question...

9 minutes ago, Bit Fiddler said:

right, exactly what I just said.  and this brings me back to the original question.  Where does this :For[ ] get defined.  it would be in the original mod makers hands to do this yes?  as it would need to be in the directory where the original parts etc. reside so MM knows "this directory belongs to a mod with some name"?  And if I use :For[ ] in a patch I make later the patch will become "attached" to the original mod as far as the order of processing is concerned?

 so in a mod that is parts only,and there are no MM patches made by the author to include a :For [ ].   I cant then use the :Needs[ ],  or :After[ ], etc.  so in the case of a mod with no .dll and no MM patches created by the author, how do I tell MM that it needs to be installed after this mod?  I assume with item 2 on your list.. a directory name.  thus the question for FTT example that had a compound directory name, does it work?

Yes, FOR[MyMod] in general should only be used by the MyMod mod.  But it doesn't matter where it's defined, or exactly what it is.  For instance, it's common to see FOR[000_MyMod] or FOR[zzz_MyMod] in order to get things to apply in a certain order.

For the parts-only mod in your scenario, MM would detect its presence by what the folder name is in GameData (satisfying condition 2 in my above criteria).  Others could then make patches with e.g. NEEDS[SomeMod] that would be applied because it is found in GameData.

[Bit Fiddler]

and this support complex directories like in the FTT example?  because for instance I may have all the USI mods installed except FTT and in this case the "Umbraspaceindustries" folder will exist, but not the sub folder "ftt"

 

[blowfish]

18 minutes ago, Bit Fiddler said:

and this support complex directories like in the FTT example?  because for instance I may have all the USI mods installed except FTT and in this case the "Umbraspaceindustries" folder will exist, but not the sub folder "ftt"

 

 

1 hour ago, blowfish said:

I've actually never seen that before.  Could you point to where it's used?

 

29 minutes ago, blowfish said:

I addressed that with a question...

 

[Bit Fiddler]

I think we may both be asking the question...   as in "does that work with subdirectories?"  if that is the case sorry for the confusion.  as I do not know the answer, I was hoping someone here did.  I have never seen it used that way before, so that is why I posted the FTT as an example, as it fit the model of a parts only mod nested in a subdirectory.   I guess the only real way to figure it out is to just write some test patches and see what happens.   I will have to try this out when I have some time.

[Jso]

3 hours ago, linuxgurugamer said:

Will this work properly?  It will need to only process on parts in the MunarIndustries directory only, but be done before any patches are done from the InterstellarFuelSwitch mod are done.

This was copied from a patch from IFS and modified for my needs:

@PART[*]:FOR[MunarIndustries]:NEEDS[InterstellarFuelSwitch]:HAS[@RESOURCE[LiquidFuel],@RESOURCE[Oxidizer],!RESOURCE[MonoPropellant],!MODULE[ModuleTankManager],!MODULE[InterstellarFuelSwitch],!MODULE[FSfuelSwitch],!MODULE[B9PartSwitch],!MODULE[ModuleEnginesFX],!MODULE[ModuleEngines]]:NEEDS[InterstellarFuelSwitch&!CryoTanks&!ModularFuelTanks&!RealFuels]:BEFORE[InterstellarFuelSwitch]
{
blah blah blah
}

Thanks

Maybe but it's a mess. It has two NEEDS, a FOR and a BEFORE. I'm pretty sure FOR, BEFORE and AFTER are mutually exclusive.

Edit: If you're expecting @PART[*]:FOR[MunarIndustries]... to only process part in that mod, that' not how it works.

 

39 minutes ago, Bit Fiddler said:

and this support complex directories like in the FTT example?  because for instance I may have all the USI mods installed except FTT and in this case the "Umbraspaceindustries" folder will exist, but not the sub folder "ftt"

 

Try NEEDS[FTT]. RoverDude uses FOR[FTT] in one of the files. NEEDS[UmbraSpaceIndustries\FTT] won't work because module manager only identifies first level subdirectories of GameData for a NEEDS clause. Not the subdirectories of those.

If you have a mod installed in a subdirectory like that, and it has neither a .dll or a FOR clause anywhere there's no way to confirm it's presence with MM. You can ask the mod author to add a do-nothing MM patch with a FOR[ModName] clause in that case.

Edited May 23, 2017 by Jso

[Bit Fiddler]

yes needs FTT works as he has the :For[ ] ... I was just talking in general terms as I could not find one nested like that that did not have a .dll or some .cfg with a :for[ ]

 

but thanks for the info on nested directories.   saves me testing patch files.

[Sigma88]

It's also worth noting that there is no link whatsoever between the tags generated by mm and the mods patches themselves unless those tags are generated by  :FOR[]

The tag has the same name of the folder / plugin provided by the mod, but unless the mod uses that tag, :BEFORE[]s and :AFTER[]s won't work as expected

The most reliable way to check for a mod is to look at its cfgs to see how the dev checks for the the presence of his/her own mod.

[Bit Fiddler]

so the author does not have a ":for[ ]", but his mod does have a "thingamajig.dll", I can't use ":after[thingamajig]"?

 

[Sigma88]

1 hour ago, Bit Fiddler said:

so the author does not have a ":for[ ]", but his mod does have a "thingamajig.dll", I can't use ":after[thingamajig]"?

 

you can use it in the sense that MM will have generated that tag, but if the mod author doesn't use that tag himself, the fact that you are using it won't necessarily do what you want it to do.

if the patches of the mod in question are without any tag, they will applied before everything else

:LEGACY goes first

:FIRST goes after legacy

everything without a tag goes here, alphabetically (in order of file location)

(then, all tags are processed alphabetically)

:BEFORE[tag] goes before the 'tag' if that tag exists (otherwise it won't apply)

:FOR[tag] goes at the 'tag', and it grants the existence of said tag

:AFTER[tag] goes after the 'tag' if that tag exists (otherwise it won't apply)

:FINAL goes last

Edited May 23, 2017 by Sigma88

[Bit Fiddler]

oh, I see, well that changes things quite a bit then.  I was assuming that tag was not made specifically by the "for" but also the .dll and directory ideas would create the tag as well.

 

must go back and rethink my MM patches.  they may not work as expected.

[Sigma88]

3 minutes ago, Bit Fiddler said:

I was assuming that tag was made by the "for" but also by the .dll and directory ideas would create the tag as well.

this is exactly how it works

 

however, the creation of the tag on mm part doesn't imply that the mod responsible for the creation of the tag will actually use said tag

 

I don't know how to put it more clearly than that

Edited May 23, 2017 by Sigma88

[linuxgurugamer]

4 hours ago, Jso said:

Edit: If you're expecting @PART[*]:FOR[MunarIndustries]... to only process part in that mod, that' not how it works.

 

5 hours ago, Bit Fiddler said:

Ok, then how can I do that (forget the rest, it was a copy/paste and I added an extra NEEDS)

[Jso]

7 hours ago, linuxgurugamer said:

Ok, then how can I do that (forget the rest, it was a copy/paste and I added an extra NEEDS)

Unless the parts have something unique about them like a name prefix (PART[MunarInd*]) or an author or manufacturer that you can pickup in a HAS[#author[linuxgurugamer]], you can't.

[linuxgurugamer]

So, if all the parts begin with MI_ I can use this:

@PARTS[MI_*]

yes?

[TheRagingIrishman]

17 minutes ago, linuxgurugamer said:

So, if all the parts begin with MI_ I can use this:

@PARTS[MI_*]

yes?

yes

[Starwaster]

15 hours ago, Bit Fiddler said:

I think we may both be asking the question...   as in "does that work with subdirectories?"  if that is the case sorry for the confusion.  as I do not know the answer, I was hoping someone here did.  I have never seen it used that way before, so that is why I posted the FTT as an example, as it fit the model of a parts only mod nested in a subdirectory.   I guess the only real way to figure it out is to just write some test patches and see what happens.   I will have to try this out when I have some time.

No, it doesn't. Only folders in GameData and NONE of their subdirectories

1. folder name
2. dll name
3. FOR[some-mod-name]

Note that because of that last one it is DANGEROUS to use FOR unless the mod being so designated is YOURS and is the mod in question. If a third party mod or a player doing their own configs use FOR inappropriately it can fool ModuleManager into satisfying NEEDS that do not actually exist: Example being: My mod needs to run one of two configs based on whether a second mod is installed. A third mod contains does :FOR[second-mod] and my mod cheerfully decides to execute the config that is only supposed to run if second-mod is installed but it isn't so maybe my configs are now invalid. Maybe I used a RESOURCE that would only have had a corresponding RESOURCE_DEFINITION if second-mod had been installed. Now KSP is throwing exceptions because of the missing RESOURCE_DEFINITION and either parts don't compile now or KSP halts during the loading process. (in this example it's probably the former and not the latter)

So, long rant over, TL;DR no MM does not support subdirectories on a NEEDS

[Lewis Douglas]

F-Secure reports: 

 

Harmful web site blocked

https://ksp.sarbian.com/jenkins/job/ModuleManager/126/artifact/ModuleManager-2.7.6.zip

This web site has been reported as harmful.
We recommend that you do not visit this web site.

[Temeter]

Very likely false alarm.

I'm not getting anything, and the source ofc should be trustworthy.

[Torih]

Yeah it's fine.

[cgwhite4]

It looks like KSP 1.3, which just came out, is completely incompatible with MM 2.7.6.  I previously observed a report to this effect in the KSP 1.3 thread, indicating that the game was crashing.  Upon attempting to start KSP, KSP crashed at the point in the loading screen where the progress bar would jump back to take care of operations that would happen after the loading screen in the absence of MM.  Steam auto-updates KSP, so it appears I will be unable to proceed until MM is updated (I need EL to do what I am doing, and EL requires MM).

I currently have the following mods: MM 2.7.6, KAS 0.6.2, KAS Beta (0.7.3), EL 5.7.2, and KJR 3.3.2.  I did get 2 KAS compatibility warnings before the crash, but I believe MM is a pre-requisite for KAS (it certainly is for EL which requires KAS), and those warnings were expected due to the new KSP version.  I had already dismissed both KAS warnings before the crash.  Furthermore, KAS Beta is known not to conflict with current KAS: IgorZ created KAS Beta this way, and I had been running both before KSP 1.3 came out.

Edit: For clarification, the report of incompatibility is in the KSP 1.3 Grand Discussion thread, not the announcement thread.  I found it with the search tool while looking for this thread to check if MM had updated yet.

Edited May 26, 2017 by cgwhite4
clarification