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

[Lisias]

1 hour ago, 4x4cheesecake said:

wild guess: you got "research bodies" installed which hides celestial bodies...

Yep... He does!!!

[LOG 10:39:03.019] Load(Assembly): REPOSoftTech/ResearchBodies/Plugins/ResearchBodies
[LOG 10:39:03.019] AssemblyLoader: Loading assembly at C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Mod v2.0\GameData\REPOSoftTech\ResearchBodies\Plugins\ResearchBodies.dll

 

[Fizzlebop Smith]

I will copy the entire directory and remove research bodies. 
I do indeed have this installed and have not yet officially uncovered EVE.

Perhaps orbiting the Mun / Minmus triggered something because of the hiding of celestial bodies. 

The Tourism Expanded was an impulse when the newest tourism overhaul came out i went Tourist Happy. I was looking forward to making them quite Kourageous. I will remove the Tourism Expanded Mod

The Error with the Kerbal Academy is likely my fault. I have modified this mod a little bit to change some of the fund mechanics associated with some of the missions. There are a couple other ongoing things that I will probably never get around to tweaking, but that one can be ignored.

@Lisias As far as Contract Configurator (Updated 17/01/2025)
(IIRC) You do not advocate CKAN but I am pretty crappy at most of this and often give in to least resistance.
It recently was updated after prolonged inactivity on 15/01/2025)

 

Spoiler

And also:

[LOG 10:44:42.327] [ScienceParamModifier],1/26/2025 10:44:42 AM,Error while loading celestial body default container list; possibly a duplicate entry: System.Nu
llReferenceException: Object reference not set to an instance of an object
  at ScienceParamModifier.ScienceConfigValuesNode+<>c.<OnDecodeFromConfigNode>b__2_0 (ScienceParamModifier.bodyParamsContainer a) [0x00006] in <48c3521c5ab245bb
a451b56640a533c3>:0
  at System.Linq.Enumerable.ToDictionary[TSource,TKey,TElement] (System.Collections.Generic.List`1[T] source, System.Func`2[T,TResult] keySelector, System.Func`
2[T,TResult] elementSelector, System.Collections.Generic.IEqualityComparer`1[T] comparer) [0x0001e] in <351e49e2a5bf4fd6beabb458ce2255f3>:0
  at System.Linq.Enumerable.ToDictionary[TSource,TKey,TElement] (System.Collections.Generic.IEnumerable`1[T] source, System.Func`2[T,TResult] keySelector, Syste
m.Func`2[T,TResult] elementSelector, System.Collections.Generic.IEqualityComparer`1[T] comparer) [0x00066] in <351e49e2a5bf4fd6beabb458ce2255f3>:0
  at System.Linq.Enumerable.ToDictionary[TSource,TKey,TElement] (System.Collections.Generic.IEnumerable`1[T] source, System.Func`2[T,TResult] keySelector, Syste
m.Func`2[T,TResult] elementSelector) [0x00000] in <351e49e2a5bf4fd6beabb458ce2255f3>:0
  at ScienceParamModifier.ScienceConfigValuesNode.OnDecodeFromConfigNode () [0x00000] in <48c3521c5ab245bba451b56640a533c3>:0

Let us see if this persists after taking away research bodies... or at least reduce some of the error content generated.

(The Error Remains but think its likely to be an issue with Research Bodies and my own fault. Reading through the research bodies thread indicates the compatability patches for ScanSat were never implemented. Reading through the thread seems there are a few issues)

The error persists after removing the Research Bodies, but that seems like one of those mods that kinds needs to be around when you start with it.

As I have only just breeched the kerbol system, I am willing to write this off i needed.

Edited January 27 by Fizzlebop Smith

[4x4cheesecake]

4 hours ago, Fizzlebop Smith said:

The Tourism Expanded was an impulse when the newest tourism overhaul came out i went Tourist Happy. I was looking forward to making them quite Kourageous. I will remove the Tourism Expanded Mod

I'm running Tourism Expanded myself and as far as I can tell, it works perfectly fine despite the error message. The error is based in the .dll which comes with Tourism Expanded to provide some custom features like calculating contract rewards based on dV required for a mission (which of course requires to calculate dV requirements in the first place).

As far as I can tell, the mod still runs perfectly fine though. Depending on the difficulty you are looking for, you may want to reduce the reward modifier though, compared to any other tourism contract, the rewards are way too high by default. Like the underwater adventure would reward me with 400k+ funds but can be easily done in early game.

You can do that by either using the ingame menu for tourism expanded (in the difficulty settings) or by running a MM patch, which is what I do. Wouldn't recommend to do both

@CONTRACT_TYPE:HAS[#group[TourismExpanded]]
{
    @BEHAVIOUR[SetRewardFunds]:HAS[#multiplier]
    {
        @multiplier *= 0.15
    }
    
    @BEHAVIOUR[SetRewardFunds]:HAS[~multiplier]
    {
        multiplier = 0.15
    }
}

(some contracts got the multiplier key and some don't, that's why it needs to be added for those)

[Monniasza]

I'm trying to make a patch that finds ISRUs for https://github.com/Monniasza/SSTO-Project/issues/5. After a disscussion with ChatGPT (click here to open it), I can't make a patch that finds all ISRUs. Here's my patch:

//Data collection - ISRUs
@PART[*]:HAS[@MODULE[ModuleResourceConverter]:HAS[#INPUT_RESOURCE[*],#OUTPUT_RESOURCE[*]],@INPUT_RESOURCE[*]:HAS[#ResourceName[Ore]],@INPUT_RESOURCE[*]:HAS[#ResourceName[ElectricCharge]],@OUTPUT_RESOURCE[*]:HAS[#ResourceName[LiquidFuel]]] {
	@lpg = true
	%lpgISRU = true
	@title = #$title$ (ISRU found)
}
@PART[*]:HAS[@MODULE[ModuleResourceConverter]:HAS[@INPUT_RESOURCE[*]:HAS[#ResourceName[Ore]]]]{
	@title = #$title$ (Ore Converter Found)
}
@PART[*]:HAS[@MODULE[ModuleResourceConverter]:HAS[@INPUT_RESOURCE[#ResourceName[Ore]]]]{
	@title = #$title$ (Ore Converter Found2)
}
@PART[*]:HAS[@MODULE[ModuleResourceConverter]] {
	@title = #$title$ (Converter Found)
}

[4x4cheesecake]

Not even going to try to decipher the first filter

How exactly do you define an ISRU though? I guess, you are not going just for the stock ISRUs because it would be much easier to address these parts by their name instead of coming up with a filter.

Judging by the next 2 filters, you are looking for ISRU which consumes ore? If so, you can use this:

@PART[*]:HAS[@MODULE[ModuleResourceConverter]:HAS[@INPUT_RESOURCE:HAS[#ResourceName[Ore]]]]:FINAL
{
    //do stuff
}

Yes, it looks like there are missing brackets after INPUT_RESOURCE but trust me, it only works this way but doesn't if you add the brackets. I honestly don't even remember why, just that I came across the same issue of "deep filtering" a while ago and that seems the way to go. This is also why your second filter doesn't work and the third is lacking a "HAS" for the resource.

You last filter will find any converter, including fuel cells. Is that something you actually want to cover or just AI going wrong?

[Monniasza]

15 hours ago, 4x4cheesecake said:

Not even going to try to decipher the first filter

How exactly do you define an ISRU though? I guess, you are not going just for the stock ISRUs because it would be much easier to address these parts by their name instead of coming up with a filter.

Judging by the next 2 filters, you are looking for ISRU which consumes ore? If so, you can use this:

@PART[*]:HAS[@MODULE[ModuleResourceConverter]:HAS[@INPUT_RESOURCE:HAS[#ResourceName[Ore]]]]:FINAL
{
    //do stuff
}

Yes, it looks like there are missing brackets after INPUT_RESOURCE but trust me, it only works this way but doesn't if you add the brackets. I honestly don't even remember why, just that I came across the same issue of "deep filtering" a while ago and that seems the way to go. This is also why your second filter doesn't work and the third is lacking a "HAS" for the resource.

You last filter will find any converter, including fuel cells. Is that something you actually want to cover or just AI going wrong?

I had added similar clause for debugging. Finally your solution works. I'll talk back  to ChatGPT.

[JonnyOThan]

16 hours ago, 4x4cheesecake said:

Yes, it looks like there are missing brackets after INPUT_RESOURCE but trust me, it only works this way but doesn't if you add the brackets. I honestly don't even remember why

Square brackets after a node filter (i.e. @X[Y]) is a shorthand for targeting the name field.  That is, it's equivalent to @X:HAS[#name[Y]].  If you don't include those brackets then it matches everything.  This also means that @PART[*] is a waste of typing, @PART is nearly identical except that it will match PART nodes that don't have a name field - which is hopefully none of them.

[4x4cheesecake]

3 hours ago, JonnyOThan said:

Square brackets after a node filter (i.e. @X[Y]) is a shorthand for targeting the name field.  That is, it's equivalent to @X:HAS[#name[Y]].  If you don't include those brackets then it matches everything.  This also means that @PART[*] is a waste of typing, @PART is nearly identical except that it will match PART nodes that don't have a name field - which is hopefully none of them.

Well, yes... that's exactly why this one is a bit weird. Since the INPUT_RESOURCE node got no name, you need to target all of them and then filter by their keys. And like you said, [*] brackets does target all the nodes, so you would expect that:

@PART[*]:HAS[@MODULE[ModuleResourceConverter]:HAS[@INPUT_RESOURCE[*]:HAS[#ResourceName[Ore]]]]

should do the same as

@PART[*]:HAS[@MODULE[ModuleResourceConverter]:HAS[@INPUT_RESOURCE:HAS[#ResourceName[Ore]]]]

but for some reason, it doesn't.  In both cases, you tell MM to target every INPUT_RESOURCE within every PART which got any ModuleResourceConverter but once you include the brackets after INPUT_RESOURCE it doesn't work anymore.

And I personally like to include all the brackets, it's just easier for me to read and understand what a patch does and where certain parts start and end. It also helps me to not forget any required ones while writing patches

[JonnyOThan]

2 hours ago, 4x4cheesecake said:

so you would expect that:

@PART[*]:HAS[@MODULE[ModuleResourceConverter]:HAS[@INPUT_RESOURCE[*]:HAS[#ResourceName[Ore]]]]

should do the same as

@PART[*]:HAS[@MODULE[ModuleResourceConverter]:HAS[@INPUT_RESOURCE:HAS[#ResourceName[Ore]]]]

No, you wouldn't.  Because INPUT_RESOURCE doesn't have a name field.  But PARTS do, so @PART[*] is a waste of typing.

2 hours ago, 4x4cheesecake said:

[*] brackets does target all the nodes

No, it doesn't.  It targets all nodes that have a name field.  The tendency of people to include [*] when it's not necessary hides what's actually going on and leads to this confusion.

Edited Monday at 07:35 PM by JonnyOThan

[4x4cheesecake]

I certainly would at least until now. Took me a hot minute to understand what you're saying. Now that I think about it, that might be how I stumbled upon it the first time.
And for everyone else being as slow as me: you can't target a node using a wildcard, if the node doesn't have any "name" key in the first place. It's basically NULL vs 0.

[Monniasza]

This doesn't catch any resource converters in any of Convert-O-Trons. How can I fix it?

@MODULE[ModuleResourceConverter]:HAS[@INPUT_RESOURCE:HAS[#ResourceName[Ore]],@INPUT_RESOURCE:HAS[#ResourceName[ElectricCharge]],@OUTPUT_RESOURCE:HAS[#ResourceName[LiquidFuel]],@OUTPUT_RESOURCE:HAS[#ResourceName[Oxidizer]]]]{
		flowrate = #$@OUTPUT_RESOURCE:HAS[#ResourceName[LiquidFuel]]/Ratio$
		@flowrate += #$@OUTPUT_RESOURCE:HAS[#ResourceName[Oxidizer]]/Ratio$
		@INPUT_RESOURCE:HAS[#ResourceName[ElectricCharge]]{
			@Ratio *= 2
		}
		@OUTPUT_RESOURCE:HAS[#ResourceName[LiquidFuel]]{
			@ResourceName = LPG
			@Ratio = #$../flowrate$
			@Ratio *= 1.4
		}
		@OUTPUT_RESOURCE:HAS[#ResourceName[Oxidizer]]{
			@Ratio = #$../flowrate$
			@Ratio *= 2.6
		}
		@ConverterName = LPG+Ox
		@StartActionName = Start ISRU [LPG+Ox]
		@StopActionName = top ISRU [LPG+Ox]
	}

 

[4x4cheesecake]

Did you simply miss the "@PART..." during copy&paste or is it actually missing? That could be a reason why.

Beside of that: what are you actually trying to accomplish? Why do you need such a specific but still generic filter to target an ISRU? If it is just the stock converters you want to target, you can simply address them by their names using @PART[ISRU] and @PART[MiniISRU]. That would simplify your patch by a lot and even if you want to target more converters, I would still recommend to start small and expand later. You can write a working patch for both stock ISRUs now just to get it up and running and expand it to "every ISRU in the whole universe and beyond" later.
That would also help you to experiment with all the other stuff you want to change instead of going back and forth just trying to target the correct part in your patch.

[Monniasza]

@4x4cheesecakeI've figured it out.  https://github.com/Monniasza/SSTO-Project/commit/4af5255009c2288421d568537c1052df8ad268a7