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

TranceaddicT · August 23, 2020

1 hour ago, Jognt said:

@Lisias I understand the whole "Others are already/still ignoring the best practices, so we cannot be sure we beat even them unless we also ignore the best practice." intention. However: As long as all mods are treated equal there will be no way to 100% guarantee any one mod will always be last in any pass (though LAST and FINAL are both well after FOR/AFTER). So while one achieves less annoyed users at his/her doorstep by joining the racers, the race also continues, causing more annoyed users at others' doorsteps.

I can understand where you're coming from, I just don't agree with it.

Good luck with what is undoubtedly little work to leave as is, and quite a bit of work to find an ideal fix for. o7

My idealistic €0,02.

I started this entire debate and was where you are on this specific issue.

The question needing answer when employing :FINAL , particularly as a mod-creator, is "Is it's use a necessity or a desire?"

In Kopernicus, it is a necessity. The desired result is to ensure all Solar Panels (via specific patching of a specific MODULE[ModuleDeployableSolarPanels]) is COMPLETELY controlled by Kopernicus ... AND NO OTHER. The only way to truly accomplish complete control as such, beyond introducing additional complexity to MM pass process, is to process a :FINAL pass on the specified module. (But, even this is subject to a mod alphanumerically after "Kop" ("Kopernikus" or "Kopernicus-like").)

Lisias · August 24, 2020

8 hours ago, Jognt said:

So while one achieves less annoyed users at his/her doorstep by joining the racers, the race also continues, causing more annoyed users at others' doorsteps.

I can understand where you're coming from, I just don't agree with it.

So you didn't understood it at all - otherwise the logical consequence of understanding it but not agreeing with it is thinking that it's OKEY to trash users' savegames.

You will have way more than annoyed users when some 2.5 years old savegame someone is nurturing just get corrupted beyond salvage due something someone else did, but ended exploding under your nose because there's no standard mechanisms that would allow me to prevent it.

Jognt · August 24, 2020

5 hours ago, Lisias said:

So you didn't understood it at all - otherwise the logical consequence of understanding it but not agreeing with it is thinking that it's OKEY to trash users' savegames.

You will have way more than annoyed users when some 2.5 years old savegame someone is nurturing just get corrupted beyond salvage due something someone else did, but ended exploding under your nose because there's no standard mechanisms that would allow me to prevent it.

You and I both know that there are always plenty of options in programming.

Ive read a few solid reasons to use final so far, but your comment is not one of them. I’d appreciate it if you did not make this personal.

Programming allows for the creation of just about anything you can imagine. While not wanting to spend the time to write a solution is understandable, it’s a poor excuse for skirting guidelines IMO.

In short: Its not okay to thrash a save. There’s just a LOT of ways to deal with that. FINAL is just the easiest. If RTB decides to stick with FINAL despite now knowing the ins&outs of it, then that’s his choice.

Until then: He asked for feedback on his patch and got it.

12 hours ago, TranceaddicT said:

I started this entire debate and was where you are on this specific issue.

The question needing answer when employing :FINAL , particularly as a mod-creator, is "Is it's use a necessity or a desire?"

In Kopernicus, it is a necessity. The desired result is to ensure all Solar Panels (via specific patching of a specific MODULE[ModuleDeployableSolarPanels]) is COMPLETELY controlled by Kopernicus ... AND NO OTHER. The only way to truly accomplish complete control as such, beyond introducing additional complexity to MM pass process, is to process a :FINAL pass on the specified module. (But, even this is subject to a mod alphanumerically after "Kop" ("Kopernikus" or "Kopernicus-like").)

Key phrase being “beyond introducing additional complexity.”

Look, RTB asked for feedback which I provided. That feedback can then be disregarded or ignored.

But please don’t equate “It would take more time and effort to smooth this out than I have.” with “There’s no other choice!”

Because the first is understandable, but the second is a lie.

Edited August 24, 2020 by Jognt

blowfish · August 24, 2020

The official guidance is: avoid distributing :FINAL patches with a mod if at all possible.

Lisias · August 24, 2020

6 hours ago, Jognt said:

Ive read a few solid reasons to use final so far, but your comment is not one of them. I’d appreciate it if you did not make this personal.

I don't. You are. The logical consequences of your advises will be savegames corruption. This is fact, not an opinion - and facts are not personal.

I'm not arguing you. I'm arguing with your mistaken opinions.

6 hours ago, Jognt said:

In short: Its not okay to thrash a save.

So please don't push solutions that will lead to that, unless when nothing else exists. I'm not talking about a small feature that could be gliched with bad patching, I'm talking about serious breakage that happens on savegame loading when the prefab ends up being built wrongly.

6 hours ago, Jognt said:

There’s just a LOT of ways to deal with that. FINAL is just the easiest.

Nope, sir. Currently (and assuming the present status quo of avoiding :FINAL unless absolutely necessary prevails), it's the safer way.

Unless you are suggesting that Kopernicus should ditch MM and do the things itself on the code - what, frankly, it's tempting sometimes.

6 hours ago, Jognt said:

Look, RTB asked for feedback which I provided. That feedback can then be disregarded or ignored.

There's a third option: explaining because it's less than acceptable, what there're at least two people trying to explain it to you. You see, it's not about you, it's about everybody else reading this. There're situations in which using :FINAL is the best (or the safer) way - the present MM semantics is not enough to ensure a safe patching on non usual situations, and your insistence on accepting that one size doesn't fits all will lead to people writing worse patches, hurting everybody.

That said, IMHO is more than OK to ask people why they are using :FINAL. It really should be the a last resort measure to solve things, otherwise the fickle gentlemen agreement that holds all together will fall as a castle of cards. But we must learn how to recognise when a "best practice" is hurting and even potentially destructive.

Jognt · August 24, 2020

2 hours ago, Lisias said:

Unless you are suggesting that Kopernicus should ditch MM and do the things itself on the code - what, frankly, it's tempting sometimes.

There you go, that's indeed one of the other options.

When I was reading up on ModuleManager and its passes I did a lot of searches and came across several posts in this thread that detailed the reasoning behind adding passes, and the official guidance that came from it.
When RTB posed his question he was unfamiliar with MM syntax. So repeating "It is recommended to not use FINAL in distributed software" should not be a surprise.

Even a patch using FINAL can ruin games if someone else distributes their own FINAL patch on solar panels after Kopernicus. So if Kopernicus wishes to truly be safe from it, then an alternate solution would be recommended.

These solutions can be anything from 'Assume other modders use the FOR pass for their mod and utilize the earliest pass that isn't FINAL to overwrite those changes' to 'Backup a user's savegame before loading it.' or even 'write completely new modules from scratch and ignore any existing solar panel modules.'

All have their pros and cons.

Quote

That said, IMHO is more than OK to ask people why they are using :FINAL. It really should be the a last resort measure to solve things, otherwise the fickle gentlemen agreement that holds all together will fall as a castle of cards. But we must learn how to recognise when a "best practice" is hurting and even potentially destructive.

The guys that made MM what it is today put in a LOT of hours and a LOT of thinking to get it where it is today. I think it's a better idea to learn and understand where the best practice came from.

I'm honestly baffled by the tone of your comments, so since I have said what I wanted to say: I wish you a good day and I'll let @R-T-B decide for himself.

-Jognt

Edited August 24, 2020 by Jognt

Lisias · August 24, 2020

26 minutes ago, Jognt said:

The guys that made MM what it is today put in a LOT of hours and a LOT of thinking to get it where it is today. I think it's a better idea to learn and understand where the best practice came from.

No more thinking and hours than anyone else on the most used Add'Ons - not to mention KSP itself.

Everybody borks. And nothing is so good that can't be made better - but, granted, nothing is so bad that can't be made worse neither.

26 minutes ago, Jognt said:

I'm honestly baffled by the tone of your comments, so since I have said what I wanted to say: I wish you a good day and I'll let @R-T-B decide for himself.

Welcome to the good and old technical discussion, where passionate technicians battle for the best outcome possible for our users. Sometimes we lose, sometimes we win - but it really dosn't matters, as the only goal is delivering better toys for the users (not winning discussions)

I'm baffled you didn't understood it.

Edited August 24, 2020 by Lisias
Hit "save" too soon.

etmoonshade · September 19, 2020

So, yet another question about "can I do this with MM?" :V

I'm looking to do two things:

- Set a value to -1 if it's -1 or smaller. Essentially, I need to put a conditional on a key.

~~- Modify multiple nodes under a main node, like so:~~

@MODNODE
{
	@stuff = things

	@SUBNODE[*]
	{
		@things = stuff
	}
}

From digging through the MM docs, there doesn't seem to be an obvious way to modify multiple SUBNODE entries in the same way. Is there a non-obvious way? It's mentioned as a feature that's planned, but there aren't any actual examples that point to it being doable.

Edit: Okay, I dug through the MM test cases and found that @SUBNODE,* edits all subnodes with that value. ~~Maybe I'll add that into the handbook or wiki.~~ I have now added this to the wiki.

I think the answer to the first question, if it's possible, would point towards a solution to the problem I have now - I don't think the negative values will hurt me, but I need to truncate the values down to integers. To be fair, it's probably easier for that to be fixed in the target mod for the patch - but I'm still curious if there's a way to put a conditional on a key anyway.

Edited September 20, 2020 by etmoonshade
Learning! Discovery! More questions!

Gordon Dry · September 22, 2020

Problem:

I want to do a regex but it does not work.

Inside

    Profile
    {
        name = default

...

		Process
		{
			name = monoprop fuel cell
			title = monoprop fuel cell
			modifier = _MonopropFuelCell
			input = [email protected]
			input = [email protected]
			output = [email protected]
			output = [email protected]
			output = [email protected]
			dump_valve = Nitrogen,Water,Nitrogen&Water
		}

I want to replace MonoPropellant with HTP.

I tried this

@Profile[default]:NEEDS[Kerbalism]:FOR[ZZZ_REFUSE]
{
	@Process[*],*
	{
		@input,* ^= :monopropellant:HTP:
		@output,* ^= :monopropellant:HTP:
		@dump_valve ^= :monopropellant:HTP:
		@input,* ^= :liquidfuel:Kerosene:
		@output,* ^= :liquidfuel:Kerosene:
		@input,* ^= :oxidizer:LqdOxygen:
		@output,* ^= :oxidizer:LqdOxygen:
	}
  }
}

with and without the ,* at Process and at the imput and output nodes.

I also tried @Process,*

And I started with uppercase for the first block in the regex and switched to lowercase.

How many combinations of possibilities I have to try?

Edited September 22, 2020 by Gordon Dry

HansAcker · September 22, 2020

2 hours ago, Gordon Dry said:

How many combinations of possibilities I have to try?

You cannot change Kerbalism's Profile with MM. Kerbalism reads it before MM can patch it.
Kerbalism reads a profile named "KerbalismSupport" where you could define additional processes and configs. You cannot overwrite or delete processes defined in the default.

Edited September 22, 2020 by HansAcker

captinjoehenry · September 23, 2020

Is there a way to patch all parts from a mod? I'm just looking to increase the wing area of all things with wing area from a certain mod

Gordon Dry · September 23, 2020

21 minutes ago, captinjoehenry said:

Is there a way to patch all parts from a mod? I'm just looking to increase the wing area of all things with wing area from a certain mod

~~:NEEDS[Modname]~~ scrap

Check for some common info like the mods' author in the part configs.

Some mod authors do a good job and always use a prefix in the part names and the filenames as well.
Example: "bluedog_" for all parts of Bluedog Design Bureau.
And ofc there is

author = CobaltWolf

in each part config.

Edited September 23, 2020 by Gordon Dry

Gordon Dry · September 23, 2020

How do I handle nodes without 'names', like I try in a @BODY patch

	@BODY:HAS[@PQS,@Atmosphere,!Ocean]
	{
		@PQS
		{
			@Mods:HAS[!LandControl]
			{
				LandControl
				{
					name = _LandClass
					Scatters
					{
						Value
						{
							name = boulder
							Components
							{
								ScatterColliders {}
							}
						}
					}
				}
			}
		}
	}

The patch does not add the 'LandControl' node.

blowfish · September 24, 2020

@Gordon Dry your syntax looks correct, can you show an example of one of the nodes you're trying to patch?

Gordon Dry · September 24, 2020

This is the most common case that does not work:

1. my patch that fits to the circumstances

@Kopernicus:AFTER[SSCEP]
{
	// rock planets or moons without an atmosphere
	@BODY:HAS[@PQS,!Atmosphere]
	{
		@PQS
		{
			@Mods:HAS[!LandControl]
			{
				LandControl
				{
					name = Scatter
					Scatters
					{
						Value
						{
							name = boulder
							Components
							{
								ScatterColliders {}
							}
						}
					}
				}
			}
		}
	}
}

2. the original config I want to tinker with

@Kopernicus:FOR[MPE]
{
	Body
	{
		name = Lint-Mikey
		cacheFile = MPE/Cache/LintMikey.bin
		Template
		{
			name = Gilly
			removeAllPQSMods = true
		}
		Properties
		{
			displayName = 68P-Lint/Mikey^N
			description = Lint Kerman discovered an object wondering in an elliptical orbit which took it out past Jool. The object was confirmed by Mikey Kerman, who also discovered a small coma around the object. The object now bares both of their names, and was the first short-period comet ever discovered. Due to it's (relatively) close nature many agencies believe that it may be a good target for exploration, at least robotically. It has been warned however that microgravity may make navigation difficult.
			radius = 550
			geeASL = 0.00015
			isHomeWorld = false
			tidallyLocked = false
			rotationPeriod = 18000
			timewarpAltitudeLimits = 0 5 10 15 20 25 30 35
			inverseRotThresholdAltitude = 3000
			maxZoom = 10000
			ScienceValues
			{
				landedDataValue = 13.5
				inSpaceLowDataValue = 12.5
				inSpaceHighDataValue = 9.75
				recoveryValue = 12.25
				spaceAltitudeThreshold = 7500
			}
			biomeMap = MPE/MPE_Textures/PluginData/Lint-Mikey_biomes.png
			Biomes
			{
				Biome
				{
					name = Lowlands
					displayName = Lowlands
					color = #38466d
					value = 1
				}
				Biome
				{
					name = Midlands
					displayName = Midlands
					color = #5d70a8
					value = 1
				}
				Biome
				{
					name = Highlands
					displayName = Highlands
					color = #85a0ef
					value = 1
				}
			}
		}
		Orbit
		{
			referenceBody = Sun
			semiMajorAxis = 51806000000
			inclination = 7.0405
			eccentricity = 0.64102
			longitudeOfAscendingNode = 122.11
			argumentOfPeriapsis = 12.780
			meanAnomalyAtEpoch = 303.71
			epoch = 1
			color = 0.239,0.239,0.239,1
			iconTexture = MPE/MPE_Textures/PluginData/Small.png
		}
		PQS
		{
			minDetailDistance = 8 
 			fadeStart = 100000
 			fadeEnd = 135000
 			deactivateAltitude = 135000
			Mods
			{
				VertexHeightMap
				{
					map = MPE/MPE_Textures/PluginData/LintMikey_elevation.png
					offset = 0
					deformity = 1800
					scaleDeformityByRadius = False
					order = 1
					enabled = True
				}
				HeightColorMap
				{
					blend = 1
					order = 3
					enabled = true
					LandClasses
					{
						Class
						{
							name = Lowlands
							altitudeStart = 0
							altitudeEnd = 0.5
							color = 0.259,0.184,0.129,1
							lerpToNext = True
						}
						Class
						{
							name = Highlands
							altitudeStart = 0.5
							altitudeEnd = 0.7
							color = 0.647,0.566,0.498,1
							lerpToNext = True
						}
						Class
						{
							name = Peaks
							altitudeStart = 0.7
							altitudeEnd = 1
							color = 0.573,0.408,0.345,1
							lerpToNext = False
						}
					}	
				}
  				VertexHeightNoiseVertHeightCurve2
			   		{
					deformity = 110	
					ridgedAddSeed = 1
					ridgedAddFrequency = 12
								ridgedAddLacunarity = 3
				  			ridgedAddOctaves = 4
					 		ridgedSubSeed = 1
								ridgedSubFrequency = 5
								ridgedSubLacunarity = 3
					 		ridgedSubOctaves = 6
					 		simplexCurve
					 		{
						 			key = 0 0 0.1466263 0.1466263
						 			key = 0.7922793 0 0.6761706 1.497418
						 			key = 1 1 6.106985 6.106985
							}
					 		simplexHeightStart = -8000
					 		simplexHeightEnd = 1000
					 		simplexSeed = 1
					 		simplexOctaves = 3
					 		simplexPersistence = 0.3
					 		simplexFrequency = 8
					 		enabled = true
					 		order = 4
				 		}
			}
		}
		ScaledVersion
		{
			fadeStart = 9000
			fadeEnd = 8900
			Material
			{
	   		shininess = 0.0
				specColor = 0.0, 0.0, 0.0, 1
			}
			OnDemand
			{			
				texture = MPE/MPE_Textures/PluginData/Lint-Mikey_Color.png
				normals = MPE/MPE_Textures/PluginData/Lint-Mikey_Normal.png
			}
		}
	}
}

3. the result in the MM cache

		Body
		{
			name = Lint-Mikey
			cacheFile = MPE/Cache/LintMikey.bin
			Template
			{
				name = Gilly
				removeAllPQSMods = true
			}
			Properties
			{
				displayName = 68P-Lint/Mikey^N
				description = Lint Kerman discovered an object wondering in an elliptical orbit which took it out past Jool. The object was confirmed by Mikey Kerman, who also discovered a small coma around the object. The object now bares both of their names, and was the first short-period comet ever discovered. Due to it's (relatively) close nature many agencies believe that it may be a good target for exploration, at least robotically. It has been warned however that microgravity may make navigation difficult.
				radius = 550
				geeASL = 0.00015
				isHomeWorld = false
				tidallyLocked = false
				rotationPeriod = 18000
				timewarpAltitudeLimits = 0 5 10 15 20 25 30 35
				inverseRotThresholdAltitude = 3000
				maxZoom = 10000
				biomeMap = MPE/MPE_Textures/PluginData/Lint-Mikey_biomes.png
				ScienceValues
				{
					landedDataValue = 13.5
					inSpaceLowDataValue = 12.5
					inSpaceHighDataValue = 9.75
					recoveryValue = 12.25
					spaceAltitudeThreshold = 7500
				}
				Biomes
				{
					Biome
					{
						name = Lowlands
						displayName = Lowlands
						color = #38466d
						value = 1
					}
					Biome
					{
						name = Midlands
						displayName = Midlands
						color = #5d70a8
						value = 1
					}
					Biome
					{
						name = Highlands
						displayName = Highlands
						color = #85a0ef
						value = 1
					}
				}
			}
			Orbit
			{
				referenceBody = Sun
				semiMajorAxis = 51806000000
				inclination = 7.0405
				eccentricity = 0.64102
				longitudeOfAscendingNode = 122.11
				argumentOfPeriapsis = 12.780
				meanAnomalyAtEpoch = 303.71
				epoch = 1
				color = 0.239,0.239,0.239,1
				iconTexture = MPE/MPE_Textures/PluginData/Small.png
			}
			PQS
			{
				minDetailDistance = 8
				fadeStart = 100000
				fadeEnd = 135000
				deactivateAltitude = 135000
				Mods
				{
					VertexHeightMap
					{
						map = MPE/MPE_Textures/PluginData/LintMikey_elevation.png
						offset = 0
						deformity = 1800
						scaleDeformityByRadius = False
						order = 1
						enabled = True
					}
					HeightColorMap
					{
						blend = 1
						order = 3
						enabled = true
						LandClasses
						{
							Class
							{
								name = Lowlands
								altitudeStart = 0
								altitudeEnd = 0.5
								color = 0.259,0.184,0.129,1
								lerpToNext = True
							}
							Class
							{
								name = Highlands
								altitudeStart = 0.5
								altitudeEnd = 0.7
								color = 0.647,0.566,0.498,1
								lerpToNext = True
							}
							Class
							{
								name = Peaks
								altitudeStart = 0.7
								altitudeEnd = 1
								color = 0.573,0.408,0.345,1
								lerpToNext = False
							}
						}
					}
					VertexHeightNoiseVertHeightCurve2
					{
						deformity = 110
						ridgedAddSeed = 1
						ridgedAddFrequency = 12
						ridgedAddLacunarity = 3
						ridgedAddOctaves = 4
						ridgedSubSeed = 1
						ridgedSubFrequency = 5
						ridgedSubLacunarity = 3
						ridgedSubOctaves = 6
						simplexHeightStart = -8000
						simplexHeightEnd = 1000
						simplexSeed = 1
						simplexOctaves = 3
						simplexPersistence = 0.3
						simplexFrequency = 8
						enabled = true
						order = 4
						simplexCurve
						{
							key = 0 0 0.1466263 0.1466263
							key = 0.7922793 0 0.6761706 1.497418
							key = 1 1 6.106985 6.106985
						}
					}
				}
			}
			ScaledVersion
			{
				fadeStart = 9000
				fadeEnd = 8900
				Material
				{
					shininess = 0.0
					specColor = 0.0, 0.0, 0.0, 1
				}
				OnDemand
				{
					texture = MPE/MPE_Textures/PluginData/Lint-Mikey_Color.png
					normals = MPE/MPE_Textures/PluginData/Lint-Mikey_Normal.png
				}
			}
			Ocean
			{
				maxQuadLengthsPerFrame = 0.03
			}
		}

Or check this way:

Base
https://github.com/Gordon-Dry/Minor-Planets-Expansion/tree/master/GameData/MPE/KopConfigs

Patches on top (beginning at line 373, the generic patches)
https://github.com/Gordon-Dry/Stock-Scatter-Collider-Enabler-Patch/blob/attempt-to-add-a-generic-patch/GameData/SSCEP/Stock-Scatter-Collider-Enabler-Patch.cfg

Edit:

I will give it a try replacing SSCEP with ZZZZ_SSCEP in the patching order.
(that did not make any difference but it's still a good idea to have the patch late but avoid FINAL)

Edited September 24, 2020 by Gordon Dry
now

Nnimrod · September 25, 2020

Could someone point out to me what I've done wrong with this?

@MODULE[ModuleEnginesFX]{
	name = ModuleEnginesFX
	@useAtmCurve = False
	@velCurve{
		%key,0  = 0.0000 1.0000  0.0000 -0.0039
		%key,1  = 0.0500 0.9998 -0.0039 -0.0058
		%key,2  = 0.1000 0.9995 -0.0058 -0.0086
		%key,3  = 0.1500 0.9991 -0.0086 -0.0127
		%key,4  = 0.2000 0.9984 -0.0127 -0.0187
		%key,5  = 0.2500 0.9975 -0.0187 -0.0277
		%key,6  = 0.3000 0.9961 -0.0277 -0.0409
		%key,7  = 0.3500 0.9941 -0.0409 -0.0604
		%key,8  = 0.4000 0.9911 -0.0604 -0.0891
		%key,9  = 0.4500 0.9866 -0.0891 -0.1317
		%key,10 = 0.5000 0.9800 -0.1317 -0.1945
		%key,11 = 0.5500 0.9703 -0.1945 -0.2872
		%key,12 = 0.6000 0.9559 -0.2872 -0.4242
		%key,13 = 0.6500 0.9347 -0.4242 -0.6265
		%key,14 = 0.7000 0.9034 -0.6265 -0.9253
		%key,15 = 0.7500 0.8571 -0.9253 -1.3666
		%key,16 = 0.8000 0.7888 -1.3666 -2.0184
		%key,17 = 0.8500 0.6879 -2.0184 -2.9810
		%key,18 = 0.9000 0.5389 -2.9810 -4.4028
		%key,19	= 0.9500 0.3187 -4.4028 -6.3743
		%key,20 = 1.0000 0.0000 -6.3743 -0.0000
	}
}

Does "name = ModuleEnginesFX" need to be in there? For some reason the rest of the patch is applying, but not the changes that I'm trying to make to ModuleEnginesFX.

TranceaddicT · September 26, 2020

17 hours ago, Nnimrod said:

Could someone point out to me what I've done wrong with this?


@MODULE[ModuleEnginesFX]{
	name = ModuleEnginesFX
	@useAtmCurve = False
	@velCurve{
		%key,0  = 0.0000 1.0000  0.0000 -0.0039
		%key,1  = 0.0500 0.9998 -0.0039 -0.0058
		%key,2  = 0.1000 0.9995 -0.0058 -0.0086
		%key,3  = 0.1500 0.9991 -0.0086 -0.0127
		%key,4  = 0.2000 0.9984 -0.0127 -0.0187
		%key,5  = 0.2500 0.9975 -0.0187 -0.0277
		%key,6  = 0.3000 0.9961 -0.0277 -0.0409
		%key,7  = 0.3500 0.9941 -0.0409 -0.0604
		%key,8  = 0.4000 0.9911 -0.0604 -0.0891
		%key,9  = 0.4500 0.9866 -0.0891 -0.1317
		%key,10 = 0.5000 0.9800 -0.1317 -0.1945
		%key,11 = 0.5500 0.9703 -0.1945 -0.2872
		%key,12 = 0.6000 0.9559 -0.2872 -0.4242
		%key,13 = 0.6500 0.9347 -0.4242 -0.6265
		%key,14 = 0.7000 0.9034 -0.6265 -0.9253
		%key,15 = 0.7500 0.8571 -0.9253 -1.3666
		%key,16 = 0.8000 0.7888 -1.3666 -2.0184
		%key,17 = 0.8500 0.6879 -2.0184 -2.9810
		%key,18 = 0.9000 0.5389 -2.9810 -4.4028
		%key,19	= 0.9500 0.3187 -4.4028 -6.3743
		%key,20 = 1.0000 0.0000 -6.3743 -0.0000
	}
}

Does "name = ModuleEnginesFX" need to be in there? For some reason the rest of the patch is applying, but not the changes that I'm trying to make to ModuleEnginesFX.

No, you identify the module to be patched with @MODULE[]. Using 'name = ' would be to change the module name ... you DO NOT want to do that.

REMOVE: name = ModuleEnginesFX

Expected result: ModuleEnginesFX will not use AtmCurve and replace any existing velCurve with the KeyValue pairs you've provided. Note: If the velCurve doesn't exist nothing will be replaced.

Change "@velCurve" to %velCurve" to create a velCurve if it doesn't already exist.

@MODULE[ModuleEnginesFX]
{
  @useAtmCurve = False

  !velCurve
  @velCurve
  {
  	%key = 0.0000, 1.0000, 	0.0000, -0.0039
  	%key = 0.0500, 0.9998, -0.0039, -0.0058
  	%key = 0.1000, 0.9995, -0.0058, -0.0086
  	%key = 0.1500, 0.9991, -0.0080, -0.0127
  	%key = 0.2000, 0.9984, -0.0127, -0.0187
  	%key = 0.2500, 0.9975, -0.0187, -0.0277
  	%key = 0.3000, 0.9961, -0.0277, -0.0409
	%key = 0.3500, 0.9941, -0.0409, -0.0604
	%key = 0.4000, 0.9911, -0.0604, -0.0891
	%key = 0.4500, 0.9866, -0.0891, -0.1317
	%key = 0.5000, 0.9800, -0.1317, -0.1945
	%key = 0.5500, 0.9703, -0.1945, -0.2872
	%key = 0.6000, 0.9559, -0.2872, -0.4242
	%key = 0.6500, 0.9347, -0.4242, -0.6265
	%key = 0.7000, 0.9034, -0.6265, -0.9253
	%key = 0.7500, 0.8571, -0.9253, -1.3666
	%key = 0.8000, 0.7888, -1.3666, -2.0184
	%key = 0.8500, 0.6879, -2.0184, -2.9810
	%key = 0.9000, 0.5389, -2.9810, -4.4028
	%key = 0.9500, 0.3187, -4.4028, -6.3743 
	%key = 1.0000, 0.0000, -6.3743, -0.0000
  }

Also: it would probably be better to bang the velCurve before adding it back. This would ensure the velocity curve is the one you've provided should any velCurve exist that extends beyond key, 20. (Not that I think there are any that go beyond key, 6.)

You also forgot your commas between values.

Edited September 26, 2020 by TranceaddicT
bloody mobile micro-screen

Nnimrod · September 26, 2020

3 hours ago, TranceaddicT said:
No, you identify the module to be patched with @MODULE[]. Using 'name = ' would be to change the module name ... you DO NOT want to do that.

REMOVE: name = ModuleEnginesFX

Expected result: ModuleEnginesFX will not use AtmCurve and replace any existing velCurve with the KeyValue pairs you've provided. Note: If the velCurve doesn't exist nothing will be replaced.

Change "@velCurve" to %velCurve" to create a velCurve if it doesn't already exist.
@MODULE[ModuleEnginesFX]
{
  @useAtmCurve = False

  !velCurve
  @velCurve
  {
  	%key = 0.0000, 1.0000, 	0.0000, -0.0039
  	%key = 0.0500, 0.9998, -0.0039, -0.0058
  	%key = 0.1000, 0.9995, -0.0058, -0.0086
  	%key = 0.1500, 0.9991, -0.0080, -0.0127
  	%key = 0.2000, 0.9984, -0.0127, -0.0187
  	%key = 0.2500, 0.9975, -0.0187, -0.0277
  	%key = 0.3000, 0.9961, -0.0277, -0.0409
	%key = 0.3500, 0.9941, -0.0409, -0.0604
	%key = 0.4000, 0.9911, -0.0604, -0.0891
	%key = 0.4500, 0.9866, -0.0891, -0.1317
	%key = 0.5000, 0.9800, -0.1317, -0.1945
	%key = 0.5500, 0.9703, -0.1945, -0.2872
	%key = 0.6000, 0.9559, -0.2872, -0.4242
	%key = 0.6500, 0.9347, -0.4242, -0.6265
	%key = 0.7000, 0.9034, -0.6265, -0.9253
	%key = 0.7500, 0.8571, -0.9253, -1.3666
	%key = 0.8000, 0.7888, -1.3666, -2.0184
	%key = 0.8500, 0.6879, -2.0184, -2.9810
	%key = 0.9000, 0.5389, -2.9810, -4.4028
	%key = 0.9500, 0.3187, -4.4028, -6.3743 
	%key = 1.0000, 0.0000, -6.3743, -0.0000
  }
Also: it would probably be better to bang the velCurve before adding it back. This would ensure the velocity curve is the one you've provided should any velCurve exist that extends beyond key, 20. (Not that I think there are any that go beyond key, 6.)

You also forgot your commas between values.

Thanks very much. I didn't know there needed to be commas between values. I'll try this tomorrow.

damerell · October 5, 2020

I am taking my first steps into the world of ModuleManager. I wrote the following line to try and identify RTGs:

@PART:HAS[@MODULE[ModuleGenerator]:HAS[!INPUT_RESOURCE,!OUTPUT_RESOURCE[~ElectricCharge],@OUTPUT_RESOURCE[ElectricCharge]:HAS[#rate[>0]]]]:LAST[CAMREC] {

This edits RTGs... but, however, if I temporarily make the RTG generate LF out of nowhere as well as EC, it becomes clear the bit I expected to rule out any part with an output resource that's not EC doesn't work.

Then I went for fuel cells:

@PART:HAS[@MODULE[ModuleResourceConverter]:HAS[@INPUT_RESOURCE:HAS[#ResourceName[LiquidFuel]],@INPUT_RESOURCE:HAS[#ResourceName[Oxidizer]],@OUTPUT_RESOURCE:HAS[#ResourceName[ElectricCharge]],!OUTPUT_RESOURCE:HAS[#ResourceName[~ElectricCharge]]]]:LAST[CAMREC]

Two problems here - the restriction on non-EC output resources doesn't work, and I don't even have a guess as to how to write the other bit I want, which is that it should have no input resource that is neither LF nor OX.

Then I went for ODFC fuel cells:

@PART:HAS[@MODULE[ODFC]:HAS[!MODE:HAS[@FUELS:@HAS[SolidFuel]]]]:LAST[CAMREC] {
  @description ^= :$: CAMREC ODFC correction.:
  @MODULE[ODFC] {
    MaxEC = #$/MODULE[ODFC]/MODE,1/MaxEC$
    // I am too stupid to understand why I can't do these all at once
    -MODE {}
    -MODE {}
    -MODE {}
    -MODE {}

I expected from the documentation that "-MODE {}" would delete all MODE nodes, but it doesn't.

Can someone tell me where I'm going wrong, please?

dawfedora · October 7, 2020

Can Module Manager be used with MacOS?

Is there a Mac .so somewhere, or does it require a compilation?

Has anyone generated a MacOS version and tested it?

DStaal · October 8, 2020

19 hours ago, dawfedora said:

Can Module Manager be used with MacOS?

Is there a Mac .so somewhere, or does it require a compilation?

Has anyone generated a MacOS version and tested it?

The standard version works just fine with macOS. No need for a separate version.

antonioltg · October 11, 2020

I have a question I looked for days but I can't find a solution, I wasn't sure if was better asking here or github anyway here is the question.

https://github.com/sarbian/ModuleManager/issues/165

blowfish · October 15, 2020

@Gordon Dry finally had a chance to look at this, I think it's a simple capitalization error of BODY vs Body

blowfish · October 15, 2020

On 10/5/2020 at 9:25 AM, damerell said:
@PART:HAS[@MODULE[ModuleGenerator]:HAS[!INPUT_RESOURCE,!OUTPUT_RESOURCE[~ElectricCharge],@OUTPUT_RESOURCE[ElectricCharge]:HAS[#rate[>0]]]]:LAST[CAMREC] {
This edits RTGs... but, however, if I temporarily make the RTG generate LF out of nowhere as well as EC, it becomes clear the bit I expected to rule out any part with an output resource that's not EC doesn't work.

To negate you'll need !OUTPUT_RESOURCE:HAS[~name[ElectricCharge]]

On 10/5/2020 at 9:25 AM, damerell said:

Then I went for fuel cells:


@PART:HAS[@MODULE[ModuleResourceConverter]:HAS[@INPUT_RESOURCE:HAS[#ResourceName[LiquidFuel]],@INPUT_RESOURCE:HAS[#ResourceName[Oxidizer]],@OUTPUT_RESOURCE:HAS[#ResourceName[ElectricCharge]],!OUTPUT_RESOURCE:HAS[#ResourceName[~ElectricCharge]]]]:LAST[CAMREC]

Quick change as above - !OUTPUT_RESOURCE:HAS[~ResourceName[ElectricCharge]]

On 10/5/2020 at 9:25 AM, damerell said:

I expected from the documentation that "-MODE {}" would delete all MODE nodes, but it doesn't.

It's a bit confusing unfortunately. Don't ask me why, it long predates my work on ModuleManager.

At the top level this is correct, but within a patch it's only true under one of two conditions: (1) it has a ,* (i.e. -MODE,* {}) or (2) it has a :HAS block

So you probably just want -MODE,* {}

On 10/7/2020 at 10:53 AM, dawfedora said:

Can Module Manager be used with MacOS?

Is there a Mac .so somewhere, or does it require a compilation?

Has anyone generated a MacOS version and tested it?

DStaal already answered the question generally, but I can add a bit more technical detail if you want. Most KSP plugin DLLs don't contain any os-native code - they contain MSIL (Microsoft Intermediate Language) byte code which can be run in the .NET runtime - Unity uses Mono which is an open source, cross-platform implementation of the .NET runtime.

damerell · October 15, 2020

9 hours ago, blowfish said:

To negate you'll need !OUTPUT_RESOURCE:HAS[~name[ElectricCharge]]

Now I have

@PART:HAS[@MODULE[ModuleGenerator]:HAS[!INPUT_RESOURCE,@OUTPUT_RESOURCE[ElectricCharge]:HAS[#rate[>0]]],!OUTPUT_RESOURCE:[HAS[~name[ElectricCharge]]]]:LAST[CAMREC] {

Unfortunately, this still selects the RTG that also outputs LF. (Is there a way to test for the number of output resources, please? That would fix all my problems.)

@PART:HAS[@MODULE[ModuleResourceConverter]:HAS[@INPUT_RESOURCE:HAS[#ResourceName[LiquidFuel]],@INPUT_RESOURCE:HAS[#ResourceName[Oxidizer]],@OUTPUT_RESOURCE:HAS[#ResourceName[ElectricCharge]]],!OUTPUT_RESOURCE:HAS[~ResourceName[ElectricCharge]]]:LAST[CAMREC] {

likewise selects a fuel cell modified to output monoprop as well as EC.

I'm pleased to say the MODE deletion rune worked fine. Thanks.

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

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation