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

swamp_ig · May 12, 2014

That's what I thought. Just wanted confirmation.

Confirmed! Fixed in the post.

swamp_ig · May 12, 2014

Probably because it still breaks things.
What I really want to know is if I'm starting a new game, should I use 2.1.2? Or should I expect more changes to be made that'll break things? I assume the answer is no but still...

Strictly speaking, the old MM was the one that broke things, or it was a KSP bug that broke things, or something...

Being a parser and in quite broad use, it's impossible for me to test every config with the new code, and it does mess around with save games, so I can't absolutely guarantee that this won't cause your five month old multiple-launch space station to either explode obviously, or malfunction in some subtle way that you won't even notice until you try and launch the mission to Jool.

Having said that, I have done a fair bit of testing and it seems to work for me. This release is really aimed at fixing things, including any breaking that was done by previous versions of MM.

So in answer to your question - use the new version. It should be safe, and future-compatible, and backwards compatible, and even will handle things that KSP just doesn't handle properly. I just don't know for sure that it's not going to break things in some subtle, hard to detect way until people start trying it out, but I really expect this to solve vastly more issues than it ever creates.

Edited May 12, 2014 by swamp_ig

Sokar408 · May 13, 2014

I'm playing a save with KSP Interstellar, where all resources are excluded from the VAB except UF4. As such some tweaking of the extraction rates is necessary, however I want to do so in a separate file, and I don't want to change the abundance of resources, but rather the extraction rate. Here is a an example of the Module Part for an extraction:


MODULE
{
	name = FNModuleResourceExtraction
	powerConsumptionLand = 40
	powerConsumptionOcean = 40
	extractionRateLandPerTon = 0.0008826
	extractionRateOceanPerTon = 0.0008826
	resourceName = Lithium
	unitName = Lithium Extractor
	extractActionName = Extract Lithium
	stopActionName = Stop Lithium Extraction
	resourceManaged = True
	resourceToUse = Megajoules
}

My guess as to how to handle it is this:


@PART[*]:HAS[@Module[FNModuleResourceExtraction]]
{
	@resourceName = Lithium
	@name = FNModuleResourceExtraction
	@extractionRateLandPerTon = 0.0008826
	@extractionRateOceanPerTon = 0.0008826
}

with changed values in the extraction rate. However since ALL resources in KSP Interstellar would pass the check "@PART[*]:HAS[@Module[FNModuleResourceExtraction]]" wouldn't that apply the changes to all the resources, in effect making all resources into lithium (in this example), or does it also check the appropriate resources name?

If it doesn't, how do I add a check so that its only the wanted resource that ends up being affected?

phoenix_ca · May 13, 2014

Unfortunately that has a few problems. One, it'll insert resourceName, name, and the extractionRate fields in the PART array, not the MODULE array that you're trying to target. The worst part about that is that you'll end-up renaming every part that has a MODULE array with name = FNModuleResourceExtraction to "Lithium". That'll do bad things.

After fiddling with it for a while though, I'm not sure if there's a way to tell MM to do exactly what you want to do in a robust manner. You may need to define each change for every part, abandoning wildcard searches and instead using the NODENAME, <index> {} format to adjust specific nodes. Unless there's a way to tell MM to only adjust a module node based on a field in it other than the name. Something like maybe:


@PART[FOO]:HAS[@MODULE[FNModuleResourceExtraction]]
{
  @MODULE[FNModuleResourceExtractionresourceName[Lithium]]
  {
  }
}

But I'm guessing. The # character is poorly documented on the first page and the only example use is in the @PART line, so it might not work at all. There's also no indication that :HAS will work anywhere other than in the starting @PART line so I threw that idea out too.

Worst case scenario, you need to use indexes, but that comes with the annoying issue that if the config it's changing gets changed (say when a mod updates) with new nodes, it could break your patch, partially or fully. You'd have to be very aware of which configs/mods are changed and go over your patch carefully every time.

Edited May 13, 2014 by phoenix_ca

Starwaster · May 13, 2014

I'm playing a save with KSP Interstellar, where all resources are excluded from the VAB except UF4. As such some tweaking of the extraction rates is necessary, however I want to do so in a separate file, and I don't want to change the abundance of resources, but rather the extraction rate. Here is a an example of the Module Part for an extraction:
<code snipped>
with changed values in the extraction rate. However since ALL resources in KSP Interstellar would pass the check "@PART[*]:HAS[@Module[FNModuleResourceExtraction]]" wouldn't that apply the changes to all the resources, in effect making all resources into lithium (in this example), or does it also check the appropriate resources name?
If it doesn't, how do I add a check so that its only the wanted resource that ends up being affected?

Unfortunately that has a few problems. One, it'll insert resourceName, name, and the extractionRate fields in the PART array, not the MODULE array that you're trying to target. The worst part about that is that you'll end-up renaming every part that has a MODULE array with name = FNModuleResourceExtraction to "Lithium". That'll do bad things.
After fiddling with it for a while though, I'm not sure if there's a way to tell MM to do exactly what you want to do in a robust manner. You may need to define each change for every part, abandoning wildcard searches and instead using the NODENAME, <index> {} format to adjust specific nodes. Unless there's a way to tell MM to only adjust a module node based on a field in it other than the name. Something like maybe:
<code snipped>
But I'm guessing. The # character is poorly documented on the first page and the only example use is in the @PART line, so it might not work at all. There's also no indication that :HAS will work anywhere other than in the starting @PART line so I threw that idea out too.
Worst case scenario, you need to use indexes, but that comes with the annoying issue that if the config it's changing gets changed (say when a mod updates) with new nodes, it could break your patch, partially or fully. You'd have to be very aware of which configs/mods are changed and go over your patch carefully every time.

# is for properties, it says that on the front page.

What you want would be:


// Do you see what I did here? We checked that the PART :HAS[FNModuleResourceExtraction] and immediately appended a :HAS[#resourceName[Lithium]] to the first :HAS[]
// Also pay strict attention to bracket placement and always make sure you have matching numbers of []
@PART[*]:HAS[@MODULE[FNModuleResourceExtraction]:HAS[#resourceName[Lithium]]]
{
	@MODULE[FNModuleResourceExtraction]
	{
		// None of these values make any sense in this example because none of them are actually altered; just using them to stay within context of your example
		@resourceName = Lithium
		// @name = FNModuleResourceExtraction <- Huh?!?? Don't touch this unless you intend to change this PartModule into a different PartModule
		@extractionRateLandPerTon = 0.0008826
		@extractionRateOceanPerTon = 0.0008826
	}
}

Edited May 13, 2014 by Starwaster

phoenix_ca · May 13, 2014

But the problem I see there is that a single part can have multiple FNModuleResourceExtraction modules (I had the very same idea Starwasher but threw it out for the following reasons). For example, here's an excerpt from KSPI's large refinery:


MODULE
{
	name = FNModuleResourceExtraction
	powerConsumptionLand = 40
	powerConsumptionOcean = 0.001
	extractionRateLandPerTon = 0.0081300813
	extractionRateOceanPerTon = 1
	resourceName = LqdWater
	unitName = Water Extractor
	extractActionName = Extract Water
	stopActionName = Stop Water Extraction
	resourceManaged = True
	resourceToUse = Megajoules
}

MODULE
{
	name = FNModuleResourceExtraction
	powerConsumptionLand = 30
	powerConsumptionOcean = 0.1
	extractionRateLandPerTon = 0.012657
	extractionRateOceanPerTon = 0.01
	resourceName = Ammonia
	unitName = Ammonia Extractor
	extractActionName = Extract Ammonia
	stopActionName = Stop Ammonia Extraction
	resourceManaged = True
	resourceToUse = Megajoules
}

MODULE
{
	name = FNModuleResourceExtraction
	powerConsumptionLand = 40
	powerConsumptionOcean = 40
	extractionRateLandPerTon = 0.0008826
	extractionRateOceanPerTon = 0.0008826
	resourceName = Lithium
	unitName = Lithium Extractor
	extractActionName = Extract Lithium
	stopActionName = Stop Lithium Extraction
	resourceManaged = True
	resourceToUse = Megajoules
}

And it goes on from there. From what I understand, your example would find any part that has an FNModuleResourceExtraction module that also has Lithium, and then edit that part. But the edit applied with @MODULE in your example doesn't specify which of the various modules of the same name should be changed, so I assume from the examples and prior experience that it will change the first module node it finds with the name FNModuleResourceExtraction. In that case it would change the LqdWater node in the above example, and not the target Lithium one. (Or worst case MM misbehaves and applies the edit to every module.)

I guess the best bet would be to try this instead, assuming it'll even work:

@PART[*]:HAS[@MODULE[FNModuleResourceExtraction]]
{
  @MODULE[FNModuleResourceExtractor:HAS[#resourceName[Lithium]]
  {
    @extractionRateLandPerTon = 0.0008826
    @extractionRateOceanPerTon = 0.0008826
  }
}

Hopefully that'd just fail instead of adding Lithium extractor module to everything. But the @ documentation is also a bit nebulous on that. If it even said just a few words like "If the node doesn't exist it won't be added" then I wouldn't be so confused. But since it doesn't, I don't make any assumptions about how @ works beyond that it will edit a node if it exists. No clue what happens if it doesn't exist.

Edited May 13, 2014 by phoenix_ca

sarbian · May 13, 2014

@ only edit a node that exist. % edit if exist and create if not.

I know the doc is lacking. I'll copy swamp_ig new doc in the first post and add what missing to it soon, but I started a new position at work and I'll be a bit busy for a couple of days.

swamp_ig · May 13, 2014


@PART[*]:HAS[@MODULE[FNModuleResourceExtraction]]
{
  @MODULE[FNModuleResourceExtractor:HAS[#resourceName[Lithium]]
  {
    @extractionRateLandPerTon = 0.0008826
    @extractionRateOceanPerTon = 0.0008826
  }
}

If that doesn't do the trick, try this:


@PART[*]:HAS[@MODULE[FNModuleResourceExtraction]]
{
  @MODULE[FNModuleResourceExtractor]:HAS[#resourceName[Lithium]]
  {
    @extractionRateLandPerTon = 0.0008826
    @extractionRateOceanPerTon = 0.0008826
  }
}

Note that the name is in its own bracket.

Edited May 13, 2014 by swamp_ig

Sokar408 · May 13, 2014

If that doesn't do the trick, try this:


@PART[*]:HAS[@MODULE[FNModuleResourceExtraction]]
{
  @MODULE[FNModuleResourceExtractor]:HAS[#resourceName[Lithium]]
  {
    @extractionRateLandPerTon = 0.0008826
    @extractionRateOceanPerTon = 0.0008826
  }
}

Note that the name is in its own bracket.

Much appreciated

enneract · May 14, 2014

Any idea why this breaks EVA? If you apply this patch, and then go EVA, your focus remains in the craft, the portrait says 'BAILED OUT', and the Kerbal is an 'Unknown Mystery Component'. If you remove the Final(s), it stops breaking things but doesn't work anymore.

@PART[*]:HAS[@MODULE[ModuleCommand],@MODULE[ModuleReactionWheel]]:Final
{
	!MODULE[ModuleReactionWheel]{}
}

@PART[*]:HAS[@MODULE[ModuleReactionWheel],!MODULE[ModuleCommand]]:Final
{
	@MODULE[ModuleReactionWheel]
	{
		PitchTorque *= 0.1
		YawTorque *= 0.1
		RollTorque *= 0.1

		@RESOURCE
		{
			!rate *= 5
		}
}

Edited May 14, 2014 by enneract

sarbian · May 14, 2014

an } is missing in the second patch. I don't see how this would break EVA, but then you never know.


!rate *= 5

What are you trying to do ? "!" delete the value.

Just do that :


@PART[*]:HAS[@MODULE[ModuleCommand],@MODULE[ModuleReactionWheel]]:Final
{
	@MODULE[ModuleReactionWheel]
	{
		@PitchTorque *= 0.1
		@YawTorque *= 0.1
		@RollTorque *= 0.1

		@RESOURCE
		{
			@rate *= 5
		}
	} 
}

Edited May 14, 2014 by sarbian

enneract · May 14, 2014

Yea, it was the lack of @'s, and the weird extra ! that idk how that got in there, apparently.

@PART[*]:HAS[@MODULE[ModuleReactionWheel],@MODULE[ModuleCommand]]:Final
{
	!MODULE[ModuleReactionWheel]{}
}

@PART[*]:HAS[@MODULE[ModuleReactionWheel],!MODULE[ModuleCommand]]:Final
{
	@MODULE[ModuleReactionWheel]
	{
		@PitchTorque *= 0.1
		@YawTorque *= 0.1
		@RollTorque *= 0.1

		@RESOURCE
		{
			@rate *= 5
		}
	}
}

works fine.

enneract · May 14, 2014

Thanks for math, BTW! Now if only we could do something like....


@PART[*]:HAS[@MODULE[ModuleCommand]]
{
	@MODULE[ModuleCommand]
	{
		$i = crewCapacity
	}

	@RESOURCE[Food]
	{
		@amount = $i
		@maxAmount = $i
	}
}

Or maybe..


@PART[*]:HAS[@MODULE[ModuleCommand]]
{
	@RESOURCE[Food]
	{
		@amount = PARENT[#crewCapacity]
		@maxAmount = PARENT[#crewCapacity]
	}
}

phoenix_ca · May 14, 2014

enneract, that would indeed be wonderful. Defining variables and then doing math on them.

Though this is seemly become its own scripting language. MMScript? KSPScript? JebScript?

sarbian · May 14, 2014

One word : NO

If you need that much complexity then you need a plugin to do it. MM is already a complex bit of code. We have to maintain it and it's easy enough to add a big bug while doing something inconspicuous. And we still have to deal with the KSP parser. If you need that much complexity then integrate a LUA or ECMA parser and write script that amounts to a full mod

phoenix_ca · May 14, 2014

Can I call it JebJuniorScript then? HalfBillScript?

No I'm not being serious.

sarbian · May 14, 2014

JebScript. "Don't Panic" edition.

enneract · May 14, 2014

One word : NO
If you need that much complexity then you need a plugin to do it. MM is already a complex bit of code. We have to maintain it and it's easy enough to add a big bug while doing something inconspicuous. And we still have to deal with the KSP parser. If you need that much complexity then integrate a LUA or ECMA parser and write script that amounts to a full mod

Fair enough, though that is what you said the last time that I saw math being brought up. I imagine that keeping a stack of parent-child relationships as you descent the hierarchy, and allowing previous values to be referenced by name would add significant complexity, or allowing for the defining and use of variables even if such variable only had a scope of the current 'block' would be only moderately less so, given the limited utility of such features.

Edited May 14, 2014 by enneract

swamp_ig · May 15, 2014

I note that the ^ is currently not used for any function. Can we assign it to FOR THE POWER since that would make sense. It would have the power to do whatever you want!

Examples:


^PART[myEngine] { }

Takes an engine and makes it a POWER engine. Able to launch megatons to orbit in a single stage. Can push planets to alternate orbits. Change the axial tilt of the Sun!


^JEB {}

Takes Jeb and makes him into POWER JEB! Gives him super-powers. Leap the VAB in a single bound, the power to do a interstellar ballistic re-entry to kerbin surface... y'know... power!

I can think of myriad other uses for this operator.

:sticktongue:

Edited May 15, 2014 by swamp_ig

Starstrider42 · May 15, 2014

Takes Jeb and makes him into POWER JEB! Gives him... the power to do a interstellar ballistic re-entry to kerbin surface

I thought he could already do that in the stock game? :sticktongue:

Eleven · May 15, 2014

Any way to remove the 'Module Manager patched 700 things' message at game start? If nothing goes wrong, I don't particularly want to see it

leftler · May 15, 2014

Is it possible to "undelete" a setting that is being deleted by another configuration file?

For example, In KSP Interstellar it has in science.cfg


@PART[sensorAccelerometer]
{
	!MODULE[ModuleScienceExperiment]
	{
	}
	MODULE
	{
		name = FNSeismicProbe	
		experimentID = FNSeismicProbeExperiment
		rerunnable = true
		deployEventName = Collect Impact Data
		reviewEventName = Review Impact Data
		resetEventName = Reset Impact Data
	}
}

It deletes the stock ModuleScienceExperiment from the accelomitor and replaces it with it's own. I would like to bring the old stock measurements back, but keeping the new mesurments KSPI adds too.

The two options I see are either modifying KSPI's science.cfg and deleting the "!MODULE[ModuleScienceExperiment]", or copy and paste the text from the accelerometer's part.cfg from Squad's folder and put it in a "@PART[sensorAccelerometer]:final" in my own configuration file. I would like it if I did not need to modify other mod's configuration files but that means I just have to keep the accelerometer up to date if Squad ever changed it (its easier to just delete the line from KSPI every time I update it).

Is there any way to counteract that "!MODULE[ModuleScienceExperiment]" without modifying the science.cfg file or manually re-creating whatever the default settings where before they where deleted?

phoenix_ca · May 15, 2014

As far as I'm aware, nope. Best option would be to use the % operator to ensure that should KSPI stop removing the module, your patch doesn't do anything.

leftler · May 15, 2014

As far as I'm aware, nope. Best option would be to use the % operator to ensure that should KSPI stop removing the module, your patch doesn't do anything.

Could you show a example of how I could use the % operator to do that?

mwlue · May 15, 2014

Any way to remove the 'Module Manager patched 700 things' message at game start? If nothing goes wrong, I don't particularly want to see it

^ I oppose this ^

Please don't remove it at all, rather give an option to show it or not.

I like this stuff to show me how much stuff i have patched and will know my new patch is at least reconized or not in a single glance at this.

[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