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

[aikixd]

Is it possible to combine these?

 

@PART[*]:HAS[@MODULE[ModuleB9PartSwitch]#moduleID[fuelSwitch],!@MODULE[ModuleEngines*]]:Final
{
	//@description = "passed"	
	@maxTemp *= 0.3
}

@PART[*]:HAS[@RESOURCE[MonoPropellant],!@MODULE[ModuleEngines*]]:Final
{
	//@description = "passed"	
	@maxTemp *= 0.3
}

 

[Vorg]

12 hours ago, sarbian said:

It is well know that moving a Sprite across a screen takes at least a SLI of 1080 GTX and a 6 core 4Ghz CPU. Good things Nintendo had such hardware when they made Zelda on the NES 30 years ago.

Nintendo didn't run windows.

[Youen]

On 21/10/2016 at 1:39 AM, 5thHorseman said:

As much as we can argue that if someone doesn't like the cat they should just not use the mod

I don't know if you were serious with this statement, but just in case, if you were, I strongly disagree. Module Manager is not just "a mod", it is a mod most other mods depend on. So basically, if you don't like the cat, you have to remove ALL mods from your game (I'd be interested if someone has statistics on how many mods rely on MM). I don't think it's a fair move from Sarbian to impose this to players AND modders (and for what reason?). Don't take me wrong, it's not an important matter (it only impacts the loading screen), but on the principle, it's a bit of a treason, to let modders become confident with Module Manager doing what it's supposed to (and nothing more), and all of a sudden add this quite out-of-place "feature". Also, I'm wondering why it's in MM, and not in MechJeb instead, for example? Feels a bit like a virus in it's current form.

I was considering to remove the dependency on MM from my mod, and then I found out (by reading this thread) that it was going away in a few days, to only come back one day a year. This makes it less annoying, for sure, but yet, I'm hesitating (this is not a threat, I know very well that Sarbian doesn't care if I use his library or not, just thinking aloud).

Edited October 23, 2016 by Youen

[sarbian]

15 minutes ago, Youen said:

I know very well that Sarbian doesn't care

Tout à fait

[DomiKamu]

18 hours ago, sarbian said:

It is normal. 2.7.2 is available on the build server but the only change is related to how it logs some info and it did not warrant an announcement.

Thanks sarbian, Initially I haven't found dev releases server for MM (Jenkins) - like MechJeb2 devs.

Merci beaucoup pour ton énorme travail sur tes add-ons (thanks a lot for your huge stuff on your addons).

Edited October 23, 2016 by DomiKamu

[falken]

So I am trying to edit the tankagemass on SSTU parts from 0.15 to 0.037 (in line with SMURFF).

It doesn't seem to want to play ball. Tankagemass remains the same. If i edit a file manually it works fine however.

	@PART[*]:HAS[@MODULE[SSTUVolumeContainer*]]:Final
{
       
    @MODULE[SSTUVolumeContainer]
    {
        @Tankagemass *= 0.037
    }
}
	

Edited October 23, 2016 by falken

[ThePhoenixSol]

On 10/22/2016 at 0:35 PM, Laguna said:

It looks like he just massively edited the stock tree, creating the new horizontal-branch layout by moving the stock nodes around and adding the new HP Tree-specific nodes to fill it out.

That might actually be the better way, to just edit the stock nodes and use them for other purposes, though I think you should be able to delete nodes with, e.g. !RDNode:HAS[#id[basicRocketry]]{}

just an fyi. i got into contact with pap through a mutual friend, and nearly every issue has been fixed within a day  pap is awesome.

[Kerbal Kommander]

I've skinned the Nyan Cat!  And you know what's in there?  A Pot O Gold!  Just kidding, its pop tart.

 

Also, thanks for all of your work on MM Sarbian! 

[ShotgunNinja]

@sarbian This directive:

@Node:HAS[#Cat[true]]:FOR[ThereAreCats] {}

always expose 'ThereAreCats'. It does so irregardless of the result of the test that precede it (in this case, :HAS[#Cat[true]]). I understand that is the intended behaviour.

However, I'm 'abusing' the NEEDS/FOR directives to allow customization of features in my mod. Right now it work in this way:

// user need to comment out this line to disable feature 'Something'
@SomeNode:FOR[MyModSomething] {} 

// then
@PART[xxx]:NEEDS[MyModSomething]
{
  .. add stuff that only need to be present if the user enable feature 'Something' ..
}

but it would be better if something like this would be possible

// user simply change a setting
MyModSettings
{
  something = true 
}

// then internally I map the user setting to something that can be queried with NEEDS[]
@MyModSettings:HAS[#something[true]]:FOR[MyModSomething] {}

// and finally
@PART[xxx]:NEEDS[MyModSomething]
{
  .. add stuff that only need to be present if the user set 'something' to 'true' in settings ..
}

So to get to the point, my question is: it would be possible in future to have FOR[] directives exposed only if their preceding test directives evaluate to true?

In alternative, could the HAS[] directive be extended to test values outside the node? That will also work.

Anyway, thanks for your attention and keep up the good work.

[DBowman]

The way I read the NEEDS docs is that a 'top level directory' name in GameData can be used or a .dll name. Would it be easy to implement the top level directory as 'top level path'? like NEEDS:[MyAgency/MySecondMod] so people could have some structure / avoid cluttering GameData even if they didn't have/need a dll?

[Sigma88]

2 hours ago, ShotgunNinja said:

So to get to the point, my question is: it would be possible in future to have FOR[] directives exposed only if their preceding test directives evaluate to true?

iirc this question was already asked in the past and the answer is: it would be very difficult to do that.

a better way to do what you want to do would be this:

1. in the node that you check for "cat = true"
   1. check if it contains cat = true
   2. if not, add cat = false 
2. in the nodes you need to edit when "cat = true"
   1. add a new variable cat, copying the value of the cat in the settings node
   2. run your patch checking for "cat = true" in the node you want to edit

step 1 is important because if you try to copy a variable that does not exist, mm will throw an error

step 2 is self explanatory

(keep in mind that mm is case sensitive so cat = True would not be considered "true", there is a way to make it non-case-sensitive if you are interested just pm me)

 

1 hour ago, DBowman said:

The way I read the NEEDS docs is that a 'top level directory' name in GameData can be used or a .dll name. Would it be easy to implement the top level directory as 'top level path'? like NEEDS:[MyAgency/MySecondMod] so people could have some structure / avoid cluttering GameData even if they didn't have/need a dll?

all my mods are in one folder (GameData/Sigma), each one of them has a specific :FOR[] that I use instead of relying on the folder name

that would be the best solution for anyone releasing multiple mods that could fit in the same folder

(at least in my opinion)

 

PS: what FOR[] does is it adds a new "mod" that you can use in NEEDS[]

so my mod GameData/Sigma/Binary  has :FOR[SigmaBinary] so that I can use :NEEDS[SigmaBinary] to check if that mod is installed

Edited October 24, 2016 by Sigma88

[Psycho_zs]

I wonder how removing parts ( !PART[]{} ) currently affects memory consumption? My part blacklist is growing and the only info I've found so far is a 2013 comment by @NathanKell. Has anything changed from that time? Can MM unload unused things or is it even theoretically possible?

[sarbian]

3 hours ago, Psycho_zs said:

Has anything changed from that time?

No

3 hours ago, Psycho_zs said:

Can MM unload unused things or is it even theoretically possible?

No, and yes but since there is not way to know what is actually needed at runtime (a mod can use a texture or model without declaring it in a cfg) it is not something I plan to look at.

[ThePhoenixSol]

Hey, how come this code wont delete the specified tech nodes?

!RDNode:HAS[#id[nuclearPropulsion|advMetalworks|largeVolumeContainment|composites|electronics|ionPropulsion|hypersonicFlight|nanolathing|advUnmanned|metaMaterials|veryHeavyRocketry|advScienceTech|advancedMotors|specializedElectrics|highPerformanceFuelSystems|experimentalAerodynamics|automation|aerospaceTech|largeUnmanned|experimentalScience|experimentalMotors|experimentalElectrics]] {}

as far as i can tell, with my very limited, and new knowledge of module manager, this SHOULD be working, but yet it doesnt.

@sarbian @Laguna

[Frybert]

Several posts have been removed. Please stay on topic. There are already several other threads for nyancat. 

Edited October 24, 2016 by Frybert

[DBowman]

20 hours ago, Sigma88 said:

all my mods are in one folder (GameData/Sigma), each one of them has a specific :FOR[] that I use instead of relying on the folder name

that would be the best solution for anyone releasing multiple mods that could fit in the same folder

thanks that sounds great - but I'm not sure I'm using it right:

1. on one of my parts I put "@manufacturer:NEEDS[UDASoylent] = Bogus" so I could see if the :FOR is working
2. in SoylentConfig.cfg I added :FOR[UDASoylent] to the existing UDA_SOYLENT_CFG{} - the manufacturer got 'Bogus' but the parts no longer found the config values. I'm using that 'module' (?) to hold constants and strings
3. I tried adding :FOR[UDASoylent] to the test part itself: "+PART[RCSTank1-2]:FOR[UDASoylent]{}" the part got 'Bogus' and all the constants - but all the other parts that copied it (to use 'inheritance') no longer appeared
4. I tried adding a 'dummy' module that was just Dummy:FOR[UDASoylent] in the SoylentConfig.cfg but the part doesn't get 'Bogus' - beats me why this didn't work and #2 did...

So far it looks like adding :FOR[] to some part I don't later copy might 'work' but it seems kind of klunky and side effecty - what's the correct way to use :FOR? ideally I'd want the main config file to say 'this is the mode I am'

[Cobrag0318]

On 10/8/2016 at 7:31 PM, Galileo said:

I think the reason nobody is giving any input is because we cant just read your questions and determine if there is an issue in the cfgs.  Include those and you will probably get more help

I included them in my original post. I didn't repost them with my bump. Question number 2 really doesn't have a cfg to copy as I really haven't any idea where to begin to add docking functionality.

[Sigma88]

1 hour ago, DBowman said:

thanks that sounds great - but I'm not sure I'm using it right:

1. on one of my parts I put "@manufacturer:NEEDS[UDASoylent] = Bogus" so I could see if the :FOR is working
2. in SoylentConfig.cfg I added :FOR[UDASoylent] to the existing UDA_SOYLENT_CFG{} - the manufacturer got 'Bogus' but the parts no longer found the config values. I'm using that 'module' (?) to hold constants and strings
3. I tried adding :FOR[UDASoylent] to the test part itself: "+PART[RCSTank1-2]:FOR[UDASoylent]{}" the part got 'Bogus' and all the constants - but all the other parts that copied it (to use 'inheritance') no longer appeared
4. I tried adding a 'dummy' module that was just Dummy:FOR[UDASoylent] in the SoylentConfig.cfg but the part doesn't get 'Bogus' - beats me why this didn't work and #2 did...

So far it looks like adding :FOR[] to some part I don't later copy might 'work' but it seems kind of klunky and side effecty - what's the correct way to use :FOR? ideally I'd want the main config file to say 'this is the mode I am'

FOR changes when a patch gets applied. That might mess up your current configs.

Just add a new cfg with inside a placeholder patch like:

 

@PART:FOR[UDASoylent] {}

(This patch will do nothing other than tell mm your mod is installed)

I think FOR works only on root nodes, but I'm not 100% sure

Ps: I just noticed your nick

Edited October 25, 2016 by Sigma88

[Ruedii]

BTW, next time you have your pre-releases, you could use the numbering  2.7.90-B1 format (this would be the 2.8 pre-release), so people with experience in software numbering know it's beta. 

I like the idea of doing a pre-release that has the bare necessity for the new version of KSP without taking advantage of the new features of KSP.

[Jahulath]

Hi, I've been ready a lot but haven't found any reference to concatenation anywhere. Is it possible to create a variable (the part name for example) and then append text to it ("liquid fuel filled" for example)?

I want to make a patch that takes any lfo tanks and copies them to make a part with just fuel in it but I don't want to do it per tank, rather just use variables so it covers all of them... the rest is easy but dynamically making new parts is a different story!

[Sigma88]

1 hour ago, Jahulath said:

Hi, I've been ready a lot but haven't found any reference to concatenation anywhere. Is it possible to create a variable (the part name for example) and then append text to it ("liquid fuel filled" for example)?

I want to make a patch that takes any lfo tanks and copies them to make a part with just fuel in it but I don't want to do it per tank, rather just use variables so it covers all of them... the rest is easy but dynamically making new parts is a different story!

var1 = abc

var2 = def

vartot = #$var1$$var2$

 

this will merge var1 and var2 into vartot

 

if you want to merge them into var1 you can do this:

 

var1 = abc

var2 = def

@var1 = #$var1$$var2$

 

basically what happens is:

if you add # at the beginning of a line, you can then insert the value of a variable you want by typing the name of the variable between 2 $ signs ( e.g.   $var1$ )

you can also add normal text and numbers, so if you want var2 to say "the value of var1 is xxxxx"

(where xxxxx is the value of var1), you can do this:

 

var2 = #The value of var1 is $var1$

Edited October 25, 2016 by Sigma88

[sarbian]

1 hour ago, Ruedii said:

BTW, next time you have your pre-releases, you could use the numbering  2.7.90-B1 format (this would be the 2.8 pre-release), so people with experience in software numbering know it's beta. 

I like the idea of doing a pre-release that has the bare necessity for the new version of KSP without taking advantage of the new features of KSP.

?

I don't understand why you are posting this. Can you develop a bit ?

[Jahulath]

2 hours ago, Sigma88 said:

var1 = abc

var2 = def

vartot = #$var1$$var2$

 

this will merge var1 and var2 into vartot

 

if you want to merge them into var1 you can do this:

 

var1 = abc

var2 = def

@var1 = #$var1$$var2$

 

basically what happens is:

if you add # at the beginning of a line, you can then insert the value of a variable you want by typing the name of the variable between 2 $ signs ( e.g.   $var1$ )

you can also add normal text and numbers, so if you want var2 to say "the value of var1 is xxxxx"

(where xxxxx is the value of var1), you can do this:

 

var2 = #The value of var1 is $var1$

Awesome! Thank you

[Ruedii]

6 hours ago, sarbian said:

?

I don't understand why you are posting this. Can you develop a bit ?

Yeah, generally the ".9x" release numbering method is a good way to tell everyone you aren't done with getting it up to par, and they should know there are likely known issues and they should be patient about it.   A lot of open source projects use this numbering method.

[sarbian]

3 minutes ago, Ruedii said:

Yeah, generally the ".9x" release numbering method is a good way to tell everyone you aren't done with getting it up to par, and they should know there are likely known issues and they should be patient about it.   A lot of open source projects use this numbering method.

Yeah, I know how numbering works. What I don't understand is why you bring that up here. MM is fully functional and up to date.