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

[Jognt]

On 6/18/2019 at 9:12 PM, zer0Kerbal said:

[snip]

Instead of :NEEDS[X]:FOR[X] you can just write :AFTER[X] since AFTER functions as both a timer and a conditional. (timer: After, conditional: won't run if X is not defined).
With regards to :FOR[zzzzzzme] you can also go for :LAST[me]. The LAST pass happens after the FOR and AFTER passes so it's even better if you want to make sure you get a 'special' place in the end without a FINAL.

Lastly, I've seen a few people using non nested consecutive :HAS conditionals and wanted to point out that in these cases only the first HAS is fulfilled. The 2nd and onwards are dropped.
So @PART[*]:HAS[@MODULE[foo]]:HAS[#value[bar]] will only filter for modules named foo.

By the way, I don't think anything about MM is undocumented. I just think it's all documented in different places

2 hours ago, Eklykti said:

Am I really supposed to write something like:

[multi search]

instead of just:

single multiconditional search

Or am I missing something about why the later doesn't work?

 

Nope, | does not work in HAS statements. There will be ways to shorten that cfg, but this isn't one of them. Note that it is currently set to filter for MODULES named Experiment, which I doubt is what you want. Since DMagic, Stock, and Universal Storage use differing Science Modules you are better off going for @MODULE[*]:HAS[#experimentID[*] to filter for experiments. Then you can filter within that for specific IDs in a similar way you're doing now, or (I think, I haven't yet played with this) you may be able to define the changes you want made in a module elsewhere in MyModConfigs for example and 'summon' that snippet in the subsequent specific ID filters. Though that last bit will need to be confirmed by someone wiser than me.

Often there are different variables that are equal for all the things you want to filter for without them being obvious at first glance though. For example I had a CFG that filtered for thermometer, barometer, seismometer, etc science and adjusted their values. Eventually I realised that (because I had the same | + HAS struggle) all of these experimentIDs had rerunnable=true set, so if I filtered for just that I would still hit the ones I wanted to  

Edited June 22, 2019 by Jognt

[Eklykti]

5 hours ago, Jognt said:

Note that it is currently set to filter for MODULES named Experiment, which I doubt is what you want.

Experiment module is defined by Kerbalism and those are exact 3 experiments which I want to produce transmittable data instead of collectable samples.

[Jognt]

23 minutes ago, Eklykti said:

Experiment module is defined by Kerbalism and those are exact 3 experiments which I want to produce transmittable data instead of collectable samples.

Ah, fair enough. I hope the rest is still helpful regardless

[Lisias]

On 5/24/2019 at 1:42 PM, Lisias said:

I think that this problem can be mitigated on a better way.

Module Manager would issue a "meta-name" with the current KSP version, so you can use ":NEEDS" et all to check the current KSP version in the same way we do for Add'Ons.

Something like:

• KSP_<MAJOR>
• KSP_<MAJOR>.<MINOR>
• KSP_<MAJOR>.<MINOR>.<PATCH>

So the author would peek the less restrictive one that works for him.

 

I gave some thoughts on this again, and realized that perhaps what follows could be a better idea, as supporting ranges of KSP versions would be cumbersome (i.e support from 1.3.1 to 1.7.1). How about adding also

• KSP_OLDER_<MAJOR>
• KSP_OLDER__<MAJOR>.<MINOR>
• KSP_OLDER__<MAJOR>.<MINOR>.<PATCH>
• KSP_NEWER_<MAJOR>
• KSP_NEWER__<MAJOR>.<MINOR>
• KSP_NEWER__<MAJOR>.<MINOR>.<PATCH>

to fullfil that use case?

I think this stunt would cause the less impact on the MM code - besides being somewhat ugly.

Edited June 24, 2019 by Lisias
off cuorse, tyops!

[blowfish]

On 6/21/2019 at 11:22 PM, Eklykti said:

Am I really supposed to write something like:

Spoiler

@PART[*]:HAS[@MODULE[Experiment]:HAS[#experiment_id[dmNAlbedoScan]]]:NEEDS[DMagicOrbitalScience,FeatureScience]:AFTER[Kerbalism]
{
	
	@MODULE[Experiment]
	{
		%unsamplify = True
	}
}

@PART[*]:HAS[@MODULE[Experiment]:HAS[#experiment_id[dmXRayDiffract]]]:NEEDS[DMagicOrbitalScience,FeatureScience]:AFTER[Kerbalism]
{
	
	@MODULE[Experiment]
	{
		%unsamplify = True
	}
}

@PART[*]:HAS[@MODULE[Experiment]:HAS[#experiment_id[dmlaserblastscan]]]:NEEDS[DMagicOrbitalScience,FeatureScience]:AFTER[Kerbalism]
{
	
	@MODULE[Experiment]
	{
		%unsamplify = True
	}
}

@PART[*]:HAS[@MODULE[Experiment]:HAS[#unsamplify[True]]]:NEEDS[DMagicOrbitalScience,FeatureScience]:AFTER[Kerbalism]
{
	@MODULE[Experiment]
	{
		-unsamplify = True
		-sample_mass = anything
		-sample_collecting = True
		-sample_reservoir = 0
	}
}

instead of just:

Spoiler

@PART[*]:HAS[@MODULE[Experiment]:HAS[#experiment_id[dmNAlbedoScan|dmXRayDiffract|dmlaserblastscan]]]:NEEDS[DMagicOrbitalScience,FeatureScience]:AFTER[Kerbalism]
{
	@MODULE[Experiment]
	{
		-sample_mass = anything
		-sample_collecting = True
		-sample_reservoir = 0
	}
}

Or am I missing something about why the later doesn't work?

| only works in the first bit, i.e. @PART[part1|part2|part3]

It's on the to-do list to allow this in a HAS block, but I don't feel comfortable implementing that until the code is cleaned up a bit (too easy to possibly break something else otherwise)

[Tonka Crash]

Is there a syntax to access values from the game's main settings.cfg? Specifically I have a need to be able to use the UI_SCALE in some patches for some mods with scalable GUI elements. I frequently swap between a 1080p  and 4K displays. 

[Starwaster]

1 hour ago, Tonka Crash said:

Is there a syntax to access values from the game's main settings.cfg? Specifically I have a need to be able to use the UI_SCALE in some patches for some mods with scalable GUI elements. I frequently swap between a 1080p  and 4K displays. 

No. It's outside the GameData folder so it's inaccessible. It doesn't get processed into a set of ConfigNode s.

[Drew Kerman]

5 hours ago, Starwaster said:

No. It's outside the GameData folder so it's inaccessible

so is physics.cfg but you can MM that with @PHYSICSGLOBALS, so if it's not possible now maybe it can be made possible for a future version

[fifthfloyd]

On 5/26/2019 at 12:08 PM, FreeThinker said:

Hello. I'm trying to create a script that adds a partmodule (AtmosphericIntake) based on the fields of an existing stock partmodule (ModuleResourceIntake)

 

@PART[*]:HAS[@MODULE[ModuleResourceIntake]:HAS[#resourceName[IntakeAir]]]:FOR[WarpPlugin]
{
	%ResourceIntakeArea = #$MODULE[ModuleResourceIntake]/area$
	%ResourceIntakeTransformName = #$MODULE[ModuleResourceIntake]/intakeTransformName$
	%ResourceIntakeUnitScalar = #$MODULE[ModuleResourceIntake]/unitScalar$

	MODULE
	{
		name = AtmosphericIntake
		area = #$../ResourceIntakeArea$
		intakeTransformName = #$../ResourceIntakeTransformName$
		unitScalar = #$../ResourceIntakeUnitScalar$
	}

	RESOURCE
	{
		name = IntakeAtm
		amount = 0
		maxAmount = 1.0 // stub, will be updated by AtmosphericIntake
	}
}

 What I'm trying to do is readout the area field in the ModuleResourceIntake module.

How can I fix it?

Edit: it appears the only mistake is that the field unitScalar is usually not present. Is there a way to make it optional or give it a default value when not found?

@FreeThinker did you ever find a way to get a default value in this condition?

[FreeThinker]

1 hour ago, fifthfloyd said:

@FreeThinker did you ever find a way to get a default value in this condition?

Well Basicly what I do is use MM filter feature

@PART[*]:HAS[!MODULE[AtmosphericIntake],@MODULE[ModuleResourceIntake]:HAS[#resourceName[IntakeAir]]]:FOR[WarpPlugin]
{
	// first add AtmosphericIntake
	MODULE
	{
		name = AtmosphericIntake
	}

	// add IntakeAtm buffer
	RESOURCE
	{
		name = IntakeAtm
		amount = 0
		maxAmount = 1.0 // stub, will be updated by AtmosphericIntake
	}
}

// only copy area when available in ModuleResourceIntake
@PART[*]:HAS[@MODULE[ModuleResourceIntake]:HAS[#resourceName[IntakeAir],#area]]:FOR[WarpPlugin]
{
	%ResourceIntakeArea = #$MODULE[ModuleResourceIntake]/area$

	@MODULE[AtmosphericIntake]
	{
		%area = #$../ResourceIntakeArea$
	}
}


// only copy intakeTransformName when available in ModuleResourceIntake
@PART[*]:HAS[@MODULE[ModuleResourceIntake]:HAS[#resourceName[IntakeAir],#intakeTransformName]]:FOR[WarpPlugin]
{
	%ResourceIntakeTransformName = #$MODULE[ModuleResourceIntake]/intakeTransformName$

	@MODULE[AtmosphericIntake]
	{
		%intakeTransformName = #$../ResourceIntakeTransformName$
	}
}

// only copy intakeSpeed when available in ModuleResourceIntake
@PART[*]:HAS[@MODULE[ModuleResourceIntake]:HAS[#resourceName[IntakeAir],#intakeSpeed]]:FOR[WarpPlugin]
{
	%ResourceIntakeSpeed = #$MODULE[ModuleResourceIntake]/intakeSpeed$

	@MODULE[AtmosphericIntake]
	{
		%intakeSpeed = #$../ResourceIntakeSpeed$
	}
}

Basicly this ensures you add a module with default values which are overriden when present

[blowfish]

On 6/23/2019 at 3:26 PM, Tonka Crash said:

Is there a syntax to access values from the game's main settings.cfg? Specifically I have a need to be able to use the UI_SCALE in some patches for some mods with scalable GUI elements. I frequently swap between a 1080p  and 4K displays. 

 

On 6/23/2019 at 10:05 PM, Drew Kerman said:

so is physics.cfg but you can MM that with @PHYSICSGLOBALS, so if it's not possible now maybe it can be made possible for a future version

Indeed, ModuleManager has special handling for certain files like physics.

However, I am going to say this should NOT be done for settings.  The reason is that settings can be modified dynamically by the game, whereas ModuleManager runs once (plus any database reloads).

Now, certainly just accessing those values is a lot less risky than opening up settings to patching, but it could still result in a lot of confusion when someone changes their settings and then doesn't see the expected changes to e.g. the UI in your case.

If there's a mod that renders GUI elements but does not take the ui scale into account, I would consider that a bug with that mod and not something ModuleManager should have to mess with.

[Tonka Crash]

5 minutes ago, blowfish said:

If there's a mod that renders GUI elements but does not take the ui scale into account, I would consider that a bug with that mod and not something ModuleManager should have to mess with.

I modified the mod where I was thinking of using this to respect the UI_SCALE and put in a PR yesterday. So the issue is closed to me.

[zer0Kerbal]

My next question is: about ModuleManagerMath (or M³).

Is there a direct or indirect way to round a number in MMM? Even if it is just to remove digits (so 2.718 from 2.71828182845904523536028747135266249775724709369995)

would a REGEXP work?

same as for ABS (Absolute value)? (so -2 becomes 2)

Spoiler

	@entryCost = 39.25564654811
	@cost = -2459.25564654811
	
	// entire string : replace with beginning to .001 (longhand)
	@entryCost ^= :^.*$:-?\d+.\d\d\d:
	@cost ^= :^.*$:-?\d+.\d\d\d:

 

 

win a :medal: or :cookie:!  ( optional)

[blowfish]

20 hours ago, zer0Kerbal said:

My next question is: about ModuleManagerMath (or M³).

Is there a direct or indirect way to round a number in MMM? Even if it is just to remove digits (so 2.718 from 2.71828182845904523536028747135266249775724709369995)

would a REGEXP work?

same as for ABS (Absolute value)? (so -2 becomes 2)

  Hide contents

	@entryCost = 39.25564654811
	@cost = -2459.25564654811
	
	// entire string : replace with beginning to .001 (longhand)
	@entryCost ^= :^.*$:-?\d+.\d\d\d:
	@cost ^= :^.*$:-?\d+.\d\d\d:

 

 

win a :medal: or :cookie:!  ( optional)

Truncate everything after the decimal point: https://github.com/blowfishpro/B9-Aerospace/blob/11115f7f92eea61839fc6c6e4138ffa9bf693117/GameData/B9_Aerospace/B9_Aerospace-Globals.cfg#L68

If you wanted to keep 3 decimal places, it's possibly a bit more complicated but I think it can be done since I believe capture groups can be used in the result

@cost ^= :(\.\d\d\d)\d+$:$1: (disclaimer, I haven't tested this)

Rounding is tough because it involves increment the number in some cases.  But you could maybe do it with two patches

Spoiler

@NODE
{
    @cost ^= :(\.\d\d\d)[^56789]\d*$:$1
    @cost ^= :(\.\d\d\d)[56789]\d*$:$1+increment:
}

@NODE:HAS[#cost[*+increment]]
{
    @cost ^= :\+increment$::
    @cost += 0.001
}

(disclaimer, also untested) ... note that there's nothing special about +increment, it was just convenient to add to the end

Absolute value is easy, just remove the leading minus sign

@cost ^= :^-::

Note that as far as parts are concerned, entryCost must be an integer whereas cost does not.

Edited June 28, 2019 by blowfish

[SpaceMart]

The download link seems to be broken. https://ksp.sarbian.com/jenkins/ looks like this to me:

Quote

Error

java.lang.IllegalArgumentException: Unable to inject class hudson.model.UserIdMapper
	at hudson.init.TaskMethodFinder.lookUp(TaskMethodFinder.java:125)
	at hudson.init.TaskMethodFinder.invoke(TaskMethodFinder.java:105)
	at hudson.init.TaskMethodFinder$TaskImpl.run(TaskMethodFinder.java:175)
	at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:296)
	at jenkins.model.Jenkins$5.runTask(Jenkins.java:1091)
	at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:214)
	at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:117)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)
Caused: org.jvnet.hudson.reactor.ReactorException
	at org.jvnet.hudson.reactor.Reactor.execute(Reactor.java:282)
	at jenkins.InitReactorRunner.run(InitReactorRunner.java:48)
	at jenkins.model.Jenkins.executeReactor(Jenkins.java:1125)
	at jenkins.model.Jenkins.<init>(Jenkins.java:932)
	at hudson.model.Hudson.<init>(Hudson.java:85)
	at hudson.model.Hudson.<init>(Hudson.java:81)
	at hudson.WebAppMain$3.run(WebAppMain.java:233)
Caused: hudson.util.HudsonFailedToLoad
	at hudson.WebAppMain$3.run(WebAppMain.java:250)

 

[Tabris]

are the new suit colors added in 1.7 alterable via MM?

also can MM detect Kerbal classes (pilot, scientist, engineer)?

[Starwaster]

59 minutes ago, Tabris said:

are the new suit colors added in 1.7 alterable via MM?

also can MM detect Kerbal classes (pilot, scientist, engineer)?

If you want to change the default emissive color for the future suit then this should do it

@PART[kerbalEVAFuture|kerbalEVAfemaleFuture]
{
	@MODULE[ModuleColorChanger]
	{
		@redColor = 1.0
		@greenColor = 0.5176
		@blueColor = 0.0
	}
}

What do you mean about 'detecting' kerbal classes? What are you trying to do? You can't target specific Kerbals as they don't really exist until you start a game. Module Manager only affects the part of the game database which has configs in cfg files... (and cannot affect anything after the game has started). If you're wanting to assign specific colors to specific Kerbal classes then no you can't do that. Not without a new custom plugin...

 

Edited June 29, 2019 by Starwaster

[Tabris]

1 hour ago, Starwaster said:

If you want to change the default emissive color for the future suit then this should do it

@PART[kerbalEVAFuture|kerbalEVAfemaleFuture]
{
	@MODULE[ModuleColorChanger]
	{
		@redColor = 1.0
		@greenColor = 0.5176
		@blueColor = 0.0
	}
}

What do you mean about 'detecting' kerbal classes? What are you trying to do? You can't target specific Kerbals as they don't really exist until you start a game. Module Manager only affects the part of the game database which has configs in cfg files... (and cannot affect anything after the game has started). If you're wanting to assign specific colors to specific Kerbal classes then no you can't do that. Not without a new custom plugin...

 

i was hoping to use the new suits to sort of replicate the functionality of 

by assigning a color to each class automatically

[Starwaster]

14 hours ago, Tabris said:

i was hoping to use the new suits to sort of replicate the functionality of 

by assigning a color to each class automatically

Yeah you're going to need a plugin... something that sits on the suit part and when the EVA Kerbal spawns it sets his color according to his occupation.

Or.... something that monitors for Kerbals being added to the roster. Actually that's even better. Because although the colors are SET on the suit they are actually permanently stored on the Kerbals themselves in the roster along with their occupation and other attributes...

Yeah.... that's pretty easy to code actually. In fact, I just went and coded up the prototype.... all of the Kerbals below had their suit color set automagically as soon as they became Applicants.

This isn't ready to release yet as it does NOT work for the first four Kerbals (Jeb and friends) I guess because there is no event generated for them? They aren't added in a way that fires one off.... I'll have to look into that.

OR I could leave them as is... being veterans and all maybe they should get a different color. I dunno.

Also, I want to make the colors configurable. That will probably be in a config file in the mod's folder. And maybe I'll make a menu for it too... or maybe that will be a later version.

https://forum.kerbalspaceprogram.com/index.php?/topic/185931-17-kerbal-occupation-colors-version-10/

Edited June 29, 2019 by Starwaster

[zer0Kerbal]

@blowfish the rounding code seems to work. Will test it further. Thank you.

 

Next query: I want to write a NEED[partname] statement and am unsure about the syntax:

Spoiler

	!MODULE:NEEDS[@PART[!KAS_CPort1]][KASModuleWinch] {}
	!MODULE:NEEDS[@PART[!KAS_CPort1]][ModuleKISPartMount] {}
	
	MODULE:NEEDS[@PART[!KAS_CPort1]]
	{
		name = KASLinkWinch
	}

Thank you in advance!

[linuxgurugamer]

12 minutes ago, zer0Kerbal said:

@blowfish the rounding code seems to work. Will test it further. Thank you.

 

Next query: I want to write a NEED[partname] statement and am unsure about the syntax:

  Hide contents

	!MODULE:NEEDS[@PART[!KAS_CPort1]][KASModuleWinch] {}
	!MODULE:NEEDS[@PART[!KAS_CPort1]][ModuleKISPartMount] {}
	
	MODULE:NEEDS[@PART[!KAS_CPort1]]
	{
		name = KASLinkWinch
	}

Thank you in advance!

What exactly are you trying to do?  Modules go in parts, not the other way around

Are you saying that if the part is NOT  a KAS_CPort1, then to add the KASLinkWinch?

or

Add the module only if the part KAS_CPORT1 is not installed?

 

[zer0Kerbal]

7 minutes ago, linuxgurugamer said:

Add the module only if the part KAS_CPORT1 is not installed?

This. if KAS-CPORT1 is installed/present then old KAS is installed, if it isn't then new KAS is installed.

Need to install the appropriate modules for the winches on the Orbital Tug.

Could just leave it up to the user to switch on/off patches, but rather prefer if possible an elegant, simpler approach such as this.

[blowfish]

9 hours ago, zer0Kerbal said:

This. if KAS-CPORT1 is installed/present then old KAS is installed, if it isn't then new KAS is installed.

Need to install the appropriate modules for the winches on the Orbital Tug.

Could just leave it up to the user to switch on/off patches, but rather prefer if possible an elegant, simpler approach such as this.

NEEDS can only check for directories, assemblies, and FOR[x] tags.  Subdirectories are allowed though (e.g. NEEDS[SquadExpansion/MakingHistory]) so that usually ends up being a decent workaround

[zer0Kerbal]

2 minutes ago, blowfish said:

NEEDS can only check for directories, assemblies, and FOR[x] tags.  Subdirectories are allowed though (e.g. NEEDS[SquadExpansion/MakingHistory]) so that usually ends up being a decent workaround

*drat*

thank you.

won't be as good as needs[part]

[Starwaster]

8 hours ago, zer0Kerbal said:

*drat*

thank you.

won't be as good as needs[part]

As he said, it allows subdirectories. Most parts if the mod's folders are structured sensibly will have the part in its own properly named folder. So target that folder. Obviously that won't work for mods which force their parts to live all in one folder or groups masses of them into one folder.