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

[FlexGunship]

I don't think you're going to be able to do that the way you want. You might have to use variables instead as detailed here: http://forum.kerbalspaceprogram.com/threads/55219-Module-Manager-2-3-5-%28Sept-14%29-Loading-Speed-Fix?p=1416253&viewfull=1#post1416253

Okay, thanks. I haven't seen anything about a parsing values (which would allow me to pull apart the data inside the "key = x y" in x and y), and I think that's a necessary step for generating the source value for the variable. But... trial-and-error will tell!

I don't think FloatCurve values can be edited with simple math. It's two or four numbers separated by spaces, and I don't believe MM knows what to do with that. As Starwaster mentioned, you might be able to do something with variables, though I don't know how you'd isolate the individual values in the first place.

Got it, thanks. Yes, parsing the information out of a space-delimited string(?) seems to be the principle challenge.

[regex]

Hi all. I'm wondering if Module Manager can do an "only" selector? For instance, I have this selector:

+PART[*]:HAS[@RESOURCE[MonoPropellant],!MODULE[ModuleCommand],!MODULE[FSfuelSwitch]]:NEEDS[Firespitter&!InterstellarFuelSwitch&!RealFuels&!ModularFuelTanks]

which works perfectly well but I need it to look for tanks that ONLY have MonoPropellant so that my fixes don't apply to odd service modules and such.

[Sigma88]

Hi all. I'm wondering if Module Manager can do an "only" selector? For instance, I have this selector:

+PART
[*]:HAS[@RESOURCE[MonoPropellant],!MODULE[ModuleCommand],!MODULE[FSfuelSwitch]]:NEEDS[Firespitter&!InterstellarFuelSwitch&!RealFuels&!ModularFuelTanks]

which works perfectly well but I need it to look for tanks that ONLY have MonoPropellant so that my fixes don't apply to odd service modules and such.

you can get the result you want by using logic, but I don't think theres an actual command for it

[Starwaster]

Hi all. I'm wondering if Module Manager can do an "only" selector? For instance, I have this selector:

+PART
[*]:HAS[@RESOURCE[MonoPropellant],!MODULE[ModuleCommand],!MODULE[FSfuelSwitch]]:NEEDS[Firespitter&!InterstellarFuelSwitch&!RealFuels&!ModularFuelTanks]

which works perfectly well but I need it to look for tanks that ONLY have MonoPropellant so that my fixes don't apply to odd service modules and such.

No, what you need doesn't exist in MM.

[regex]

you can get the result you want by using logic, but I don't think theres an actual command for it

Explain?

No, what you need doesn't exist in MM.

I figured there wasn't an explicit command but you're basically saying there's no way to do it?

[Starwaster]

Explain?

He probably means it's possible from a boolean standpoint but that MM doesn't actually support it.

That's the only explanation that makes sense because

I figured there wasn't an explicit command but you're basically saying there's no way to do it?

Correct. It's not possible to do what you want it to do while cloning a part since all detection has to take place in the :HAS immediately following your +PART

[*] and there are no conditionals that support checking for resource(s) that exist but failing when there are more resources than were designated.

Edit: If you want to EDIT an existing part, there's a somewhat convoluted means you might achieve it. It would require copying the monoprop resource node (using MM variables) then deleting it. Then adding the stuff you want IF zero resources exist. Then adding back in the monoprop node reconstructing it from the variables stored in step 1.

(none of which is possible on a single line that only accepts conditional checking)

Edited August 6, 2015 by Starwaster

[regex]

Correct. It's not possible to do what you want it to do while cloning a part since all detection has to take place in the :HAS immediately following your +PART

[*] and there are no conditionals that support checking for resource(s) that exist but failing when there are more resources than were designated.

Thanks, was just looking for the confirmation. It's totally fine, I can live with it (and so can will my users). I'll poke Sarbian about it later.

[Sigma88]

Explain?

sorry, was at dinner.

never postpone food

what I meant is that you can do it, but there is no quick way. you will need to set some rules.

this is just out the top of my mind:

if you want to patch all the parts that have only monopropellant*

you could

1- copy the monopropellant resource to a subnode, like this:

@PART:HAS[@RESOURCE[Monopropellant]]
{
TEMP_RESOURCE
{
#../RESOURCE[Monopropellant] {}
}
}

2- then, delete all RESOURCE[monopropellant] like this:

@PART:HAS[@RESOURCE[Monopropellant]]
{
!RESOURCE[Monopropellant] {}
}

3- then, add a key to all PARTS that still have a RESOURCE node, like this:

@PART:HAS[@RESOURCE
[*]]
{
DONTpatchTHIS = true
}

4- then, move back the RESOURCE to it's original place, like this:

@PART:HAS[@TEMP_RESOURCE]
{
#TEMP_RESOURCE\RESOURCE {}
!TEMP_RESOURCE {}
}

5- then, apply your patch:

@PART:HAS[@RESOURCE[Monopropellant],~DONTpatchTHIS[true]]
{
// my patch is super awesome!
}

6- finally, remove the DONTpatchTHIS key, like this:

@PART:HAS[#DONTpatchTHIS
[*]]
{
!DONTpatchTHIS = DEL
}

the code may need still some tweaks, this is just out the top of my head, but it gives you the idea...

there are probably more efficient / elegant solutions to your problem. but I'm not a coder, so that's the crap I write

---

*PS:

I noticed that your code uses a "+", using "+" will create a new part, it won't patch the old ones.

I think using "+" will create only 1 part tho. So if you actually want to create new parts instead of just modify them, I may have misunderstood your question earlier.

Edited August 6, 2015 by Sigma88

[regex]

snip...

That's actually an interesting idea, using patches at different stages... It's a real cluster, though. I might give it a shot.

I noticed that your code uses a "+", using "+" will create a new part, it won't patch the old ones.

That's the idea, yeah.

[Sigma88]

That's actually an interesting idea, using patches at different stages... It's a real cluster, though. I might give it a shot.

That's the idea, yeah.

so, you want to create a copy for each PART that has only monopropellant?

I don't think THAT is possible.

when you use + you create just 1 part, so you'll need some way to

1- copy a part

2- mark that part as "already copied"

3- repeat untill you've copied all parts

I don't think there is a way to loop commands in MM

you could just write it manually to repeat the copying 100 times, but I'm pretty sure that it would be a bad coding decision

Edited August 6, 2015 by Sigma88

[regex]

so, you want to create a copy for each PART that has only monopropellant?

I don't think THAT is possible.

when you use + you create just 1 part, so you'll need some way to

1- copy a part

2- mark that part as "already copied"

3- repeat untill you've copied all parts

I don't think there is a way to loop commands in MM

Oh, that wouldn't be a problem. You could do all the stuff you propose quite easily before copying the part. And in that case, only copy the parts that don't include a DONTpatchTHIS addition. Edited August 6, 2015 by regex

[Sigma88]

Oh, that wouldn't be a problem. You could do all the stuff you propose quite easily before copying the part. And in that case, only copy the parts that don't include a DONTpatchTHIS addition.

yeah, but copying multiple parts is not really the best thing.

It's messy and I don't think coders would approve

Edited August 6, 2015 by Sigma88

[regex]

yeah, but copying multiple parts is not really the best thing.

It's messy and I don't think coders would approve

Uh... Okay... Why wouldn't coders (in particular) approve?

[Sigma88]

Uh... Okay... Why wouldn't coders (in particular) approve?

well as far as I know, you can copy just 1 part at a time.

if you don't know how many parts to copy there are, you could copy a part and then mark that part as "already copied", then copy another part and mark that as well..

repeat the process for n times like 20 or 100. (to make sure you've copied all of them)

with the result that you are writing a bunch of code for nothing. and you may still miss some parts if you repeat your code not enough times

this process isn't very efficient, and it feels a bit hacky. but as I already said, I'm no professional coder, so what do I know

Edited August 6, 2015 by Sigma88

[regex]

well as far as I know, you can copy just 1 part at a time.

if you don't know how many parts to copy there are, you could copy a part and then mark that part as "already copied", then copy another part and mark that as well..

There's no need to do that, and it doesn't happen. "+PART[*]:HAS[]" selects all parts with the given HAS condition. In my case, I select all parts with a MonoPropellant resource, without an FSfuelSwitch module, and without a CommandModule module. MM then iterates over them doing what I want to do. "@" allows me to alter each part in turn while "+" allows me to copy each part once and then alter the copy in turn. This works perfectly fine and there is no need to mark a part as copied because MM only iterates over it once. If I were to follow that line up with another "+PART[*]:HAS[]" line that catches both the originals and copies, and copy those again, then I might have a problem. As it stands "+PART[*]:HAS[]" allows me to add parts to my mod without actually creating those parts. In fact, it is almost a better way to do it because the memory requirements over a new part are less since the copies generally use the same resources.

That's why you use the HAS condition, to narrow the list down and avoid willy-nilly copying everything.

[Sigma88]

MM then iterates over them doing what I want to do.

if you are sure about that then it's fine, I thought "+" worked only once

[regex]

if you are sure about that then it's fine, I thought "+" worked only once

It copies the parts you select. If you select a single part to copy, it only copies one part. If you select multiple, it copies them all. This allows you to do interesting things like this:

+PART[*]:HAS[@RESOURCE[MonoPropellant],!MODULE[ModuleCommand]]:NEEDS[!Firespitter&!InterstellarFuelSwitch&!RealFuels&!ModularFuelTanks]
{
	@name ^= :$:_Water:
	@title ^= :(rcs fuel(?i)|rcs(?i)|monopropellant(?i)):Water:
	@description = ISRU Water Tank
	@RESOURCE[MonoPropellant]
	{
		@name = Water
		@amount = 0
		@maxAmount *= 4.5
	}
}

Which duplicates parts that have Monopropellant but not ModuleCommand modules so long as neither Firespitter, InterstellarFuelSwitch, Real Fuels, or Modular Fuel Tanks is installed, appends "_Water" to the part name (to avoid it replacing the RCS tank), replaces "rcs fuel", "rcs", or "monopropellant" with "Water" in the title, regardless of case, changes the description, and then renames the MonoPropellant resource to Water while converting the MonoProp resource to a rough liter analogue (a unit is approx. 4.5 liters, but we can't be totally sure). In other words, it creates water tanks from RCS tanks.

[Sigma88]

It copies the parts you select. If you select a single part to copy, it only copies one part. If you select multiple, it copies them all. This allows you to do interesting things like this:

+PART
[*]:HAS[@RESOURCE[MonoPropellant],!MODULE[ModuleCommand]]:NEEDS[!Firespitter&!InterstellarFuelSwitch&!RealFuels&!ModularFuelTanks]
{
    @name ^= :$:_Water:
    @title ^= :(rcs fuel(?i)|rcs(?i)|monopropellant(?i)):Water:
    @description = ISRU Water Tank
    @RESOURCE[MonoPropellant]
    {
        @name = Water
        @amount = 0
        @maxAmount *= 4.5
    }
}

Which duplicates parts that have Monopropellant but not ModuleCommand modules so long as neither Firespitter, InterstellarFuelSwitch, Real Fuels, or Modular Fuel Tanks is installed, appends "_Water" to the part name (to avoid it replacing the RCS tank), replaces "rcs fuel", "rcs", or "monopropellant" with "Water" in the title, regardless of case, changes the description, and then renames the MonoPropellant resource to Water while converting the MonoProp resource to a rough liter analogue (a unit is approx. 4.5 liters, but we can't be totally sure). In other words, it creates water tanks from RCS tanks.

well then you are all set

I probably was confusing it in my memory with this line

You can match subnodes in one of seven ways:

@NODE[name] // will wildcard match name (so you can do ModuleEnginesFX or ModuleEngines*), and apply itself to the first NODE it finds.

@NODE[name],index // will wildcard match name, and apply itself to the indexth NODE it finds.

@NODE[name],* // will wildcard match name, and apply itself to ALL matching NODEs.

@NODE[name]:HAS[criteria] // will wildcard match name and apply itself to all matching NODEs which also meet the :HAS criteria

@NODE:HAS[criteria] // will apply itself to all matching NODEs which also meet the :HAS criteria

@NODE,index // will apply itself to the indexth NODE it finds

@NODE,* // will apply itself to ALL NODEs

These apply to @, ! and % nodes. $ nodes are necessarily single-application, and thus will always apply to the first node they find.

[regex]

Well, this is interesting. I took your idea, Sigma88, and refined it a bit.

@PART[*]:HAS[@RESOURCE[MonoPropellant]]
{
    @RESOURCE,1
    {
        testval = yes
    }
}

@PART[*]:HAS[@RESOURCE[*]:HAS[#testval[*]]]
{
	@description = Found one.
}

Now, I thought this would first select any part that had a Monoprop resource and then add "testval" to the second resource found, if any. Then the second select would come through and pick up anything that had a resource with a "testval", regardless of testval's actual value. What happened instead is that everything with only a monopropellant resource had its description changed.

Is this expected and desired behavior? It works pretty much like I want it to, in reverse, I just want to rely on it.

[Sigma88]

Well, this is interesting. I took your idea, Sigma88, and refined it a bit.

@PART
[*]:HAS[@RESOURCE[MonoPropellant]]
{
    @RESOURCE,1
    {
        testval = yes
    }
}

@PART
[*]:HAS[@RESOURCE
[*]:HAS[#testval
[*]]]
{
    @description = Found one.
}

Now, I thought this would first select any part that had a Monoprop resource and then add "testval" to the second resource found, if any. Then the second select would come through and pick up anything that had a resource with a "testval", regardless of testval's actual value. What happened instead is that everything with only a monopropellant resource had its description changed.

Is this expected and desired behavior? It works pretty much like I want it to, in reverse, I just want to rely on it.

no idea why it would do that

the base idea looks even better than mine. I actually thought about it halfway throught writing my other message, but I didn't want to delete everything

Edited August 6, 2015 by Sigma88

[regex]

After further playing around with this, I found something weird. The ConfigCache indicates that the testval variable is being added to every part with a monopropellant resource, but it is adding it to the second resource in the case where there is one. That appears to be working fine, although I would expect it to not add to the resource in the case where there isn't a second one. Oh well.

I think what's happening on the second pass is that it is only selecting the first resource to check against because if you change the first pass to

@PART[*]:HAS[@RESOURCE[MonoPropellant]]
{
    @RESOURCE,0
    {
        testval = yes
    }
}

it will apply the second pass to all parts with MonoPropellant, rather than those with only one resource.

Either way, this seems to be a reliable way to select parts that only have MonoPropellant.

Edited August 7, 2015 by regex

[Vist]

Hi everybody

Firstly, my apologies for my MM coding newb question :"> just started reading about MM's syntax awhile ago

Wanted to adjust the cost of all parts of a certain mod since they're not yet balanced, am I on the right track if my custom cfg file has this?

[COLOR=#333333]@PART[B9_*][/COLOR]
[COLOR=#333333]{[/COLOR]
[COLOR=#333333]@cost = cost/100[/COLOR]
[COLOR=#333333]}[/COLOR]

Can't test it out yet since am still at work

Regards and thanks in advance.

Edited August 7, 2015 by Vist
placed code in code tags

[regex]

Use

@cost *= 0.01

E: probably better to multiply instead of divide.

Edited August 7, 2015 by regex

[Errol]

Wanted to inform you that module manager 2.6.7 breaks the opentree mod. It makes the stock tech tree appear in place of that one, there are no parts in the nodes. Reverting to MM 2.6.6 fixes. Will cross post in their thread.

[Vist]

Use

@cost *= 0.01

E: probably better to multiply instead of divide.

Ah I see thanks regex!