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

[sebi.zzr]

On ‎26‎.‎7‎.‎2016 at 10:36 PM, Cobrag0318 said:

-snip-
 Unless you're like me and my bud, who at least want to run it just to run it. 

 i see your point,it that case try to add

MODULE
{
	name = ModuleScienceContainer
	reviewActionName = Review Data
	storeActionName = Store Experiments
	collectActionName = Take Data
	evaOnlyStorage = True
	storageRange = 2
	allowRepeatedSubjects = True
}

to your existing patch,because i don't see anything wrong with it

[Cobrag0318]

It already has a section like that as far as the principal item cfg file. But maybe using a replace function with that in this file will overwrite the original section and make it work. 

[pap1723]

I am working on my Historical Progression Tech Tree and have run into a problem that I just cannot crack. SpaceY-Lifters and SpaceY-Expanded add tech nodes to the stock tree as well as Community Tech Tree. I do not want those nodes added, but I am running into problems with the proper Module Manager syntax to delete them after SpaceY has created them. Here is the code that SpaceY uses that is causing me some issues.

@PART[SY*]:NEEDS[!CommunityTechTree]
{
	@SpaceYtree = True
}
@PART[SY*]:HAS[#SpaceYtree[*rue]]:FOR[zSpaceY]
{
	!SpaceYtree = delete
}
@TechTree:FOR[SpaceY]
{
	RDNode
	{
		id = massiveRocketry
		title = Massive Rocketry
		description = Significantly larger rockets are sometimes needed. For those times, we have these.
		cost = 1000
		hideEmpty:NEEDS[!RSSeaDragon&!RealScaleBoosters] = True
		hideEmpty:NEEDS[RSSeaDragon|RealScaleBoosters] = False
		@hideEmpty:NEEDS[CommunityTechTree] = True
		nodeName = node8_massiveRocketry
		anyToUnlock = False
		icon = RDicon_rocketry-veryHeavy
		pos:NEEDS[CommunityTechTree] = -927,1604,-1
		pos:NEEDS[!CommunityTechTree] = -952,1550,-1
		scale = 0.6

		Parent
		{
			parentID = highPerformanceFuelSystems
			lineFrom = RIGHT
			lineTo = LEFT
		}
		Parent
		{
			parentID = veryHeavyRocketry
			lineFrom = RIGHT
			lineTo = LEFT
		}
	}

 

[Starwaster]

@pap1723

@TechTree
{
	!RDNode,*:HAS[#id[massiveRocketry]]{}
}

 

[Araym]

I'm going to add USI-LS supplies to all my crewed parts:

There was already an old MM cfg around doing so, and I just modded it to latest values:

 

// Adds 15 days worth of Supplies (per kerbal seat) to Command Modules
// Ignores parts that already have Supplies values declared
@PART[*]:HAS[@MODULE[ModuleCommand],!RESOURCE[Supplies],#CrewCapacity[>0]]:FINAL
{
	RESOURCE
	{
		name= Supplies
		maxAmount = 243
		@maxAmount *= #$/CrewCapacity$
		amount = #$maxAmount$
	}
}

// Adds 30 days worth of Supplies (per kerbal seat) to non-Command Modules
// Ignores parts that already have Supplies values declared
@PART[*]:HAS[!MODULE[ModuleCommand],!RESOURCE[Supplies],#CrewCapacity[>0]]:FINAL
{
	RESOURCE
	{
		name= Supplies
		maxAmount = 486
		@maxAmount *= #$/CrewCapacity$
		amount = #$maxAmount$
	}
}

Easy and simple, a check on crewed parts and some supplies added based on number of crew seats, in their 2 flavours (command and crew cans)

 

... then my problem started:

as a lot of crewed parts have a very low cost, if I empty the supplies they went on a "negative" cost (meaning I even get a "discount" on other part's costs).

I figured how add a flat value to the "cost":

@cost += xxxxx

meaning that I'm adding "xxxxx" to the original cost value, and manually added all the possible cases 1 by 1 (some example only for crewed command module: I have similar one for not command but crewed parts)

@PART[*]:HAS[@MODULE[ModuleCommand],!RESOURCE[Supplies],#CrewCapacity[1]]:FINAL
{
@cost += 607.5
}

@PART[*]:HAS[@MODULE[ModuleCommand],!RESOURCE[Supplies],#CrewCapacity[2]]:FINAL
{
@cost += 1215
}

@PART[*]:HAS[@MODULE[ModuleCommand],!RESOURCE[Supplies],#CrewCapacity[3]]:FINAL
{
@cost += 1822.5
}

@PART[*]:HAS[@MODULE[ModuleCommand],!RESOURCE[Supplies],#CrewCapacity[4]]:FINAL
{
@cost += 2430
}

... etc etc...

but it is tedious to figure out how many crewed parts I have, to cover all the cases, and also I liked the "automatic" calculation that the original life support patch could achieve.
So... what is it my problem?

How could I write a "function" like:

@cost += .......(SUPPLIEScost * crew capacity).......?????

** NOTE: "SUPPLIEScost" as a "number": 607.5 is the actual value I need for command-crewed parts, multipled x crew seats, and 1215 is the cost of the same but for crew cans/labs/passenger seats **

As I figured, I need 2 different codes (one for crewed command parts and one for non-command but crewed cans/labs, as I add different supplies quantity), but I cannot figure how to syntax it.......

 

Thanks In advance for any help

Edited August 1, 2016 by Araym

[Sigma88]

@Araym

@PART:HAS[@MODULE[ModuleCommand],!RESOURCE[Supplies],#CrewCapacity[>0]]:FINAL
{
	%addedCost = 607.5            // (temporary variable) defines the cost for 1 crew
	@addedCost *= #$CrewCapacity$ // multiplies the cost for the crew capacity
	@cost += #$addedCost$         // adds the additional cost to the original cost
	!addedCost = DEL              // (OPTIONAL) deletes the temporary variable
}

 

Edited August 1, 2016 by Sigma88

[Araym]

1 hour ago, Sigma88 said:

@Araym

@PART:HAS[@MODULE[ModuleCommand],!RESOURCE[Supplies],#CrewCapacity[>0]]:FINAL
{
	%addedCost = 607.5            // (temporary variable) defines the cost for 1 crew
	@addedCost *= #$CrewCapacity$ // multiplies the cost for the crew capacity
	@cost += #$addedCost$         // adds the additional cost to the original cost
	!addedCost = DEL              // (OPTIONAL) deletes the temporary variable
}

 

Oh!
I missed the idea to create a new, specific, "addedCost" value... CLEVER!
Thank you

[Starwaster]

@Araym

Just an FYI (because I didn't see it explicitly stated in the past several posts here) all part costs are assumed to be wet costs for the part + any resources. There is sanity checking to make sure that the cost of the part is not lower than the combined resource cost but that can be broken allowing for negative part costs. 

(too easily broken, due to what I consider a bug, but sadly, officially is considered not to be a bug)

[Sigma88]

2 hours ago, Araym said:

Oh!
I missed the idea to create a new, specific, "addedCost" value... CLEVER!
Thank you

alternatively, if you hate using temporary variables (like I do), you can use this code:

@PART:HAS[@MODULE[ModuleCommand],!RESOURCE[Supplies],#CrewCapacity[>0]]:FINAL
{
	@cost /= #$CrewCapacity$
	@cost += 607.5
	@cost *= #$CrewCapacity$
}

and this also saves 1 line of code, win-win

[h0yer]

Hi!

I was trying my very first attempt to make some MM patches, but since I was trying something rather complex, I failed.

Not horribly, nothing broke

But the outcome was quite different^^

 

What I planned:

Add SCANsat functionality to the HGA-7 and the Communotron 88, as versions from Ven's stock revamp, as part of a full blown RO suite^^

Basically using the small round dish for RAD scans and the larger one for SAR scans. (I'm as well planning do give Raidernick's probes appropriate science/scanner/antennae patches so they reflect the full plethera of gadgets, they were launched with.)

But instead adding SCANsat-modules to the both antennae, I 'modified' accidentaly the actual SCANsat parts, which had two sets of SCAN options (in the VAB).

 

Here my code: (I Frankenstein'd it together from existing configs and a few parts of the MM wiki, I guess the names of the parts are 'vague including some borked syntax?'^^)
 

@PART[mediumFixedAntenna]:NEEDS[RealismOverhaul&RealSolarSystem&VenStockRevamp&RP-0&SCANsat]:AFTER[RealismOverhaul&RP-0]
{
    +module
    {
        name = SCANsat
        sensorType = 1   //2^0
        fov = 5
        min_alt = 1000
        max_alt = 1000000
        best_alt = 500000
        scanName = RADAR Scan
        power = 0.25
    }
    @description ^=:$: (Integrated SCANsat RADAR altimetry)
}

@PART[largeFixedAntenna]:NEEDS[RealismOverhaul&RealSolarSystem&VenStockRevamp&RP-0&SCANsat]:AFTER[RealismOverhaul&RP-0]
{
    +module
    {
        name = SCANsat
        sensorType = 2  //2^1
        fov = 2
        min_alt = 5000
        max_alt = 8000000
        best_alt = 7500000
        power = 0.85
        scanName = SAR Scan
    }
    @description ^=:$: (Integrated SCANsat SAR scanner)
}

 

[NecroBones]

@h0yer, those ":AFTER[RealismOverhaul&RP-0]" parts probably need to be editing. "AFTER" specifies a specific point in the list, as to when to apply the patches. If you want to make sure it executes after both of those mods, you just need to go later in the alphabetical sequence, so something like ":FOR[zMyPatches]" (notice the "z" there) could do it. I don't think you can specify two mods with in the AFTER.

 

 

[Araym]

2 hours ago, Starwaster said:

@Araym

Just an FYI (because I didn't see it explicitly stated in the past several posts here) all part costs are assumed to be wet costs for the part + any resources. There is sanity checking to make sure that the cost of the part is not lower than the combined resource cost but that can be broken allowing for negative part costs. 

(too easily broken, due to what I consider a bug, but sadly, officially is considered not to be a bug)

I know that "cost" should be a "wet cost", that why I found always problematic any mod that add new resources to parts (like, as I was patching, life support ones) and I was fighting with MM to add the new resource cost (I found the very same "bug" also in DangIt, with the "spare parts" resource needed to repair broken assets)

1 hour ago, Sigma88 said:

alternatively, if you hate using temporary variables (like I do), you can use this code:

@PART:HAS[@MODULE[ModuleCommand],!RESOURCE[Supplies],#CrewCapacity[>0]]:FINAL
{
	@cost /= #$CrewCapacity$
	@cost += 607.5
	@cost *= #$CrewCapacity$
}

and this also saves 1 line of code, win-win

That is even better than the previous one! Implemented right now

Thanks again for the help!

[h0yer]

1 minute ago, NecroBones said:

@h0yer, those ":AFTER[RealismOverhaul&RP-0]" parts probably need to be editing. "AFTER" specifies a specific point in the list, as to when to apply the patches. If you want to make sure it executes after both of those mods, you just need to go later in the alphabetical sequence, so something like ":FOR[zMyPatches]" (notice the "z" there) could do it. I don't think you can specify two mods with in the AFTER.

 

 

Ah, I see, so I could just use a ":FOR[RP-0] " instead of the double-thingy? (Or still a :AFTER ?)

Will try it 'till it breaks

Thanks for the reply

 

(I might come here more often, hehe)

[NecroBones]

12 minutes ago, h0yer said:

Ah, I see, so I could just use a ":FOR[RP-0] " instead of the double-thingy? (Or still a :AFTER ?)

Will try it 'till it breaks

Thanks for the reply

 

(I might come here more often, hehe)

 

Sort of. Here's what they do:

 

FOR[something] - Basically says "a mod now exists called 'something', and this patch belongs to it". Because it creates this name in the list, you never want to use it unless the name belongs to your mod. So don't say "FOR[RP-0]" unless the patch is actually included with RP-0. But you can make up a new name associated with it, and do something like "FOR[RP0andH0yer]" or whatever. Make sure to pick names that are unlikely to be used by other mods. The reason you need to be careful here, is that anything added with a "FOR" will also trigger the "NEEDS" in other mods that check for the same name.

 

AFTER[something] and BEFORE[something] - These will make the patches apply before or after "something", but only if "something" exists in the list (having been created by a "FOR" somewhere else, or being the name of a mod's folder or DLL). These are great for adding rules before or after another mod, but since your patches only apply once, you need to be sure the mod name that you're referencing actually exists, and is before/after all of the other mods you're depending on. This is why it's sometimes better to use a "FOR", but again, "FOR" really needs you to use a name that doesn't exist for other mods.

 

If you're making the patches for yourself (not to be distributed with a mod), and you want them to apply after everything else, you can instead put a ":FINAL" on your patches and not use BEFORE/FOR/AFTER.

 

 

[h0yer]

6 minutes ago, NecroBones said:

 

...Very interesting stuff...

Awesome, now it's much clearer, so I want actually a :FINAL, which I strangely didn't even think of/try out^^

Yup, for the time beeing, they're intended for my sole funz/curiosity, but if I get a hang of MMing the stuff out of stuff, I might partake in much more than just writing configs for my own purposes (Maybe participating in writing MM stuff for RO/RP-0 future releases, helping out, stuff..)

Thanks again, Maestro, much appreciated

[DStaal]

Out of curiosity: If I have a line along the lines of '@PART[apart]:FOR[x]:NEEDS[y]', does the 'mod x exists' feature come into play even if mod y isn't installed?  (And: Would it matter the order the :FOR and :NEEDS are in?)

[Cetera]

I am trying to write a MM patch to give all kerbals a short omni-antenna in RemoteTech while on EVA, but I can't figure out how to apply it.  There isn't an "@part" that seems to work.  How would I add this to all EVA kerbals?

[blowfish]

20 minutes ago, DStaal said:

Out of curiosity: If I have a line along the lines of '@PART[apart]:FOR[x]:NEEDS[y]', does the 'mod x exists' feature come into play even if mod y isn't installed?  (And: Would it matter the order the :FOR and :NEEDS are in?)

I'm not 100% sure about this, but I think MM would count x as existing regardless.  The reason is that all the FOR clauses are processed before everything else (to figure out which ones actually exist)

11 minutes ago, Cetera said:

I am trying to write a MM patch to give all kerbals a short omni-antenna in RemoteTech while on EVA, but I can't figure out how to apply it.  There isn't an "@part" that seems to work.  How would I add this to all EVA kerbals?

You can't modify the EVA kerbal part through ModuleManager (because it is created programmatically by KSP).  There are ways to do this with code though.  I believe @anxcon figured out how to do this, maybe you can have a chat if you're interested in doing it this way.

[DStaal]

18 minutes ago, blowfish said:

I'm not 100% sure about this, but I think MM would count x as existing regardless.  The reason is that all the FOR clauses are processed before everything else (to figure out which ones actually exist)

That's what I'm hoping for, I'm just looking for verification. 

19 minutes ago, blowfish said:

You can't modify the EVA kerbal part through ModuleManager (because it is created programmatically by KSP).  There are ways to do this with code though.  I believe @anxcon figured out how to do this, maybe you can have a chat if you're interested in doing it this way.

AntennaRange does this by adding a 'EVA_MODULE'.  Though there's a DLL involved as well, so...

[Cobrag0318]

Bump on my earlier question about adding research ability to the Skylab mod via module manager patch. 

[Starwaster]

1 hour ago, Cobrag0318 said:

Bump on my earlier question about adding research ability to the Skylab mod via module manager patch. 

Apologies if this is wrong... I'm not sure what you're really asking for?

Edit: No, never mind that was definitely wrong, I see what you're asking for. You added the science converter and science lab; the converter is what does the actual research that you were talking about but it depends internally on the science lab which in turn needs a science container to store the data in:

You copied and pasted from the stock research lab, yes? 

See this bit here?

containerModuleIndex = 0

That number has to match the MODULE's index in the PART config. If the science container is NOT first then index = 0 is wrong. Look at the original config and see what position it's in. Whatever its index would be subtract 1 and change containerModuleIndex to that number. So if the container is the third MODULE then containerModuleIndex = 2

Edited August 1, 2016 by Starwaster

[NecroBones]

20 hours ago, DStaal said:

Out of curiosity: If I have a line along the lines of '@PART[apart]:FOR[x]:NEEDS[y]', does the 'mod x exists' feature come into play even if mod y isn't installed?  (And: Would it matter the order the :FOR and :NEEDS are in?)

 

19 hours ago, blowfish said:

I'm not 100% sure about this, but I think MM would count x as existing regardless.  The reason is that all the FOR clauses are processed before everything else (to figure out which ones actually exist)

 

I'm not 100% sure either, but I thought it was the other way around.   Theoretically, you'd want the conditional to determine whether or not the "x" in the "FOR" gets added or not. I have a rule in SpaceY that works this way, but I don't rely on it. The other rules in SpaceY that reference the "x" also reference "y" in their own "NEEDS" statements, just to be sure (I didn't spend the time to experiment with it).

 

MM has gotten so wonderfully complex that it's a bit of a learning curve to figure out what works and what doesn't.

 

 

[Sigma88]

12 minutes ago, NecroBones said:

 

 

I'm not 100% sure either, but I thought it was the other way around.   Theoretically, you'd want the conditional to determine whether or not the "x" in the "FOR" gets added or not. I have a rule in SpaceY that works this way, but I don't rely on it. The other rules in SpaceY that reference the "x" also reference "y" in their own "NEEDS" statements, just to be sure (I didn't spend the time to experiment with it).

 

MM has gotten so wonderfully complex that it's a bit of a learning curve to figure out what works and what doesn't.

 

 

As far as I can remember blowfish is right

FOR conditions need to be "read" before NEEDS (otherwise you would not know what to keep and what to discard) so x would be considered installed even if the node will be later deleted by the check for NEEDS 

[NecroBones]

13 minutes ago, Sigma88 said:

As far as I can remember blowfish is right

FOR conditions need to be "read" before NEEDS (otherwise you would not know what to keep and what to discard) so x would be considered installed even if the node will be later deleted by the check for NEEDS 

 

If that's the case, that's good to know. My hope would have been to use that NEEDS/FOR combination to optionally enable something for another NEEDS, but now that I'm thinking about it, I can see how that turns into a "chicken and egg" problem, so I think you both are right.

 

The method I've been favoring for optionally enabling/disabling features for other parts is to do it with variables in those parts, that can then be referenced with HAS instead. That's a pretty reliable method.

 

[Cobrag0318]

On August 1, 2016 at 3:11 PM, Starwaster said:

Apologies if this is wrong... I'm not sure what you're really asking for?

Edit: No, never mind that was definitely wrong, I see what you're asking for. You added the science converter and science lab; the converter is what does the actual research that you were talking about but it depends internally on the science lab which in turn needs a science container to store the data in:

You copied and pasted from the stock research lab, yes? 

See this bit here?

containerModuleIndex = 0

That number has to match the MODULE's index in the PART config. If the science container is NOT first then index = 0 is wrong. Look at the original config and see what position it's in. Whatever its index would be subtract 1 and change containerModuleIndex to that number. So if the container is the third MODULE then containerModuleIndex = 2

Ok. I'll check it out. Raidernick did a pretty sweet job on the mod, but that script file is a jumbled mess. Not returned and indented like standard, but evidently still works. I'm guessing he's using a script editor or something. I'm simply using notepad. I'm assuming, since his script files still work, the scripts aren't exactly processed line by line. Hopefully module manager is able to find the desired modules when patching. 

 

Also, I read somewhere about module manager applying patches to objects already saved in a save file. This'd mean the lab I already have in orbit will update with research capabilities if/when I get the patch working?