Jump to content

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

sarbian

By sarbian
in KSP1 Mod Releases

 Share

Recommended Posts

  • 4 weeks later...
FreeThinker

FreeThinker

Posted
Posted (edited)

Hello, I'm trying to replace all occurances of a specific module by another module. I tried the following script 

@PART[*]:HAS[@MODULE[IFSResourceTransfer]]
{
	@MODULE[IFSResourceTransfer]
	{
		@name = FNResourceTransfer
	}
	
	MM_PATCH_LOOP {}
}

I also tried another way 

@PART[*]
{
	@MODULE[IFSResourceTransfer],*
	{
		@name = FNResourceTransfer
	}
}

But both script not seem to work. So how to do it right?

Edited by FreeThinker
Link to comment
Share on other sites
Guest

Guest

Posted
Posted

@FreeThinker if you want to remove the original and add the new, I’d do it literally ie use “!” on the original then (separate code) add your new module (no prefix?) there's probably a more elegant way but that's how I've done it before.

Link to comment
Share on other sites
FreeThinker

FreeThinker

Posted
Posted (edited)
1 minute ago, FruitGoose said:

@FreeThinker if you want to remove the original and add the new, I’d do it literally ie use “!” on the original then (separate code) add your new module (no prefix?) there's probably a more elegant way but that's how I've done it before.

But then I would lose the content, I only want to change the partmodule type and maintain everything else. For a single item this isn't a problem, but for an unknown number of the same, it is.

Edited by FreeThinker
Link to comment
Share on other sites
Guest

Guest

Posted
Posted
2 minutes ago, FreeThinker said:

But then I would lose the content, I only want to change the partmodule type and maintain everything else. For a single item this isn't a problem, but for an unknown number of the same, it is.

Ah sorry I misunderstood. You mean change the name of the part module? Try: 

@PART[*]:HAS[@MODULE[IFSResourceTransfer]]
{
	@MODULE
	{
	  @name = FNResourceTransfer
	}
	
	
}

Don't think you need 2nd reference to module name as used in filter? 

Link to comment
Share on other sites
FreeThinker

FreeThinker

Posted
Posted
59 minutes ago, FruitGoose said:

Ah sorry I misunderstood. You mean change the name of the part module? Try: 


@PART[*]:HAS[@MODULE[IFSResourceTransfer]]
{
	@MODULE
	{
	  @name = FNResourceTransfer
	}
	
	
}

Don't think you need 2nd reference to module name as used in filter? 

This doen't work and when I add 

MM_PATCH_LOOP {}

ksp hangs at atartup

Link to comment
Share on other sites
Guest

Guest

Posted
Posted
6 minutes ago, FreeThinker said:

This doen't work and when I add 


MM_PATCH_LOOP {}

ksp hangs at atartup

Hmm not sure than that normally works for me. IFS resource transfer isn't stock right? Assuming it's spelt right, maybe needs an [AFTER] tag referencing the mod it's from? Other than that I'm out of ideas sorry. 

Not familiar with the mm_patch_loop at all so can't comment on that.

Link to comment
Share on other sites
DialoMalison

DialoMalison

Posted
Posted

Just a wild stab in the dark.

When Sarbian introduced the MM_PATCH_LOOP {}  feature, he included the following patch:

On 2/16/2016 at 4:52 PM, sarbian said:

A patch that would remove all ressource of all PART (of course there are easier way to do that) 


@PART[*]:HAS[@RESOURCE[*]]
{
	!RESOURCE,0 {}
	
	MM_PATCH_LOOP {}
}

Maybe you need the curly brackets on the resource line also. Like this:

Quote 

@PART[*]:HAS[@MODULE[IFSResourceTransfer]]
{
	@MODULE[IFSResourceTransfer] {}
	{
		@name = FNResourceTransfer
	}
	
	MM_PATCH_LOOP {}
}

 

 

 

Link to comment
Share on other sites
Lisias

Lisias

Posted
Posted (edited)
On 3/23/2021 at 9:25 AM, FreeThinker said:

This doen't work and when I add 






MM_PATCH_LOOP {}

ksp hangs at atartup

It's hanging because the :HAS is being satisfied. 

The patch @DialoMalison about removing resources works because there's a condition in which the :HAS eventually fails. Suppose we have 

PART
{
	name = Foobar
	RESOURCE
	{
		name = foo
	}
	RESOURCE
	{
		name = bar
	}
}

When this patch: 

@PART[*]:HAS[@RESOURCE[*]]
{
	!RESOURCE,0 {}
	
	MM_PATCH_LOOP {}
}

Hits it by the fist time, the part have 2 RESOURCEs, satisfying the :HAS and  so the patch will be executed once, removing the resource at position 0 and giving us: 

PART
{
	name = Foobar
	RESOURCE
	{
		name = bar
	}
}

This part still satisfies that :HAS, so it will be executed again, giving us so: 

PART
{
	name = Foobar
}

Now the :HAS fails, and MM moves on.

Spoiler

(nope. I screwed up the test, I shoved an extra { } on the patch. please ignore this)

-- -- -- POST EDIT  -- -- 

I ended up answering @DialoMalison and ignored the main issue at all (sigh). 

@FreeThinker, I think you found a bug.

I created this (fake) part: 


PART
{
	name = teste de Module Manager
	MODULE
	{
		name = IFSResourceTransfer
	}
	MODULE
	{
		name = IFSResourceTransfer
	}
	MODULE
	{
		name = IFSResourceTransfer
	}
}

After confirming it on the ModuleManager's Config Cache (the official one, of course), 


UrlConfig
{
    parentUrl = __LOCAL/MMbug.cfg
    PART
    {
        name = teste de Module Manager
        MODULE
        {
            name = IFSResourceTransfer
        }
        MODULE
        {
            name = IFSResourceTransfer
        }
        MODULE
        {
            name = IFSResourceTransfer
        }
    }
}

I applied this patch: 


@PART[*]:HAS[@MODULE[IFSResourceTransfer]]
{
	@MODULE[IFSResourceTransfer] {}
	{
		@name = FNResourceTransfer
	}
}

and got this instead of the expected result: 


UrlConfig
{
    parentUrl = __LOCAL/MMbug.cfg
    PART
    {
        name = teste de Module Manager
        MODULE
        {
            name = IFSResourceTransfer
        }
        MODULE
        {
            name = IFSResourceTransfer
        }
        MODULE
        {
            name = IFSResourceTransfer
        }

        {
        }
    }
}

Note a nameless and empty node on the bottom of the PART node.

So the eternal loop is explained - no module is being renamed at all, and so the :HAS is always satisfied.

No warnings or stackdumps on KSP.log neither MMPatch.log:

Spoiler 



[LOG 06:38:21.210] Extracting patches
[LOG 06:38:21.332] Applying patches
[LOG 06:38:21.334] :INSERT (initial) pass
[LOG 06:38:21.420] :FIRST pass
[LOG 06:38:21.420] :LEGACY (default) pass
[LOG 06:38:21.438] Applying update __LOCAL/MMbug/@PART[*]:HAS[@MODULE[IFSResourceTransfer]] to __LOCAL/MMbug.cfg/PART[teste de Module Manager]
[LOG 06:38:21.460] :BEFORE[__LOCAL] pass
[LOG 06:38:21.460] :FOR[__LOCAL] pass
[LOG 06:38:21.460] :AFTER[__LOCAL] pass
[LOG 06:38:21.460] :BEFORE[ASSEMBLY-CSHARP] pass
[LOG 06:38:21.460] :FOR[ASSEMBLY-CSHARP] pass
[LOG 06:38:21.460] :AFTER[ASSEMBLY-CSHARP] pass
[LOG 06:38:21.460] :BEFORE[KSPSTEAMCTRLR] pass
[LOG 06:38:21.460] :FOR[KSPSTEAMCTRLR] pass
[LOG 06:38:21.460] :AFTER[KSPSTEAMCTRLR] pass
[LOG 06:38:21.460] :BEFORE[MODULEMANAGER] pass
[LOG 06:38:21.460] :FOR[MODULEMANAGER] pass
[LOG 06:38:21.460] :AFTER[MODULEMANAGER] pass
[LOG 06:38:21.460] :BEFORE[SQUAD] pass
[LOG 06:38:21.460] :FOR[SQUAD] pass
[LOG 06:38:21.460] :AFTER[SQUAD] pass
[LOG 06:38:21.460] :BEFORE[SQUADEXPANSION] pass
[LOG 06:38:21.460] :FOR[SQUADEXPANSION] pass
[LOG 06:38:21.460] :AFTER[SQUADEXPANSION] pass
[LOG 06:38:21.462] :FINAL pass
[LOG 06:38:21.462] Done patching
[LOG 06:38:21.462] Saving Cache
[LOG 06:38:21.948] Done!

 

I think you found a bug on Module Manager.

-- -- -- POST POST EDIT -- -- -- 

Well this is embarrassing.  I ended up creating a problem myself while testing the thing.... :blush: (original content on the Spoiler, for the amusement of the reader for the years to come. 

Well, I redid the tests, the right way this time:

First, I tried changing something else that not the @name: 

PART
{
	name = teste de Module Manager
	MODULE
	{
		name = IFSResourceTransfer
		xxx = IFSResourceTransfer
	}
	MODULE
	{
		name = IFSResourceTransfer
		xxx = IFSResourceTransfer
	}
	MODULE
	{
		name = IFSResourceTransfer
		xxx = IFSResourceTransfer
	}
}


@PART[*]:HAS[@MODULE[IFSResourceTransfer]]:FINAL
{
	@MODULE[IFSResourceTransfer]
	{
		@xxx = FNResourceTransfer
	}
	MM_PATCH_LOOP { }
}

And... well... I reproduced the behaviour @FreeThinker reported. As expected, MM enters into an infinite loop - KSP never goes into Main Menu and the MMPatch.log logs 

[LOG 13:46:39.974] Applying update __LOCAL/MMBug/@PART[*]:HAS[@MODULE[IFSResourceTransfer]]:FINAL to __LOCAL/MMPart.cfg/PART[teste de Module Manager]

in secula seculorum.

So, no, I was WRONG, no bug on MM was found here.

Well, I tried the LOOPless patch again, but changing name instead of xxx: 

@PART[*]:HAS[@MODULE[IFSResourceTransfer]]:FINAL
{
	@MODULE[IFSResourceTransfer]
	{
		@name = FNResourceTransfer
	}
	MM_PATCH_LOOP { }
}

And then I  got: 

UrlConfig
{
    parentUrl = __LOCAL/MMPart.cfg
    PART
    {
        name = teste de Module Manager
        MODULE
        {
            name = FNResourceTransfer
            xxx = IFSResourceTransfer
        }
        MODULE
        {
            name = FNResourceTransfer
            xxx = IFSResourceTransfer
        }
        MODULE
        {
            name = FNResourceTransfer
            xxx = IFSResourceTransfer
        }
    }
}

---- LOG ----

[LOG 13:42:00.515] :AFTER[SQUADEXPANSION] pass
[LOG 13:42:00.517] :FINAL pass
[LOG 13:42:00.529] Looping on __LOCAL/MMBug/@PART[*]:HAS[@MODULE[IFSResourceTransfer]]:FINAL to __LOCAL/MMPart.cfg/PART[teste de Mod
ule Manager]
[LOG 13:42:00.529] Applying update __LOCAL/MMBug/@PART[*]:HAS[@MODULE[IFSResourceTransfer]]:FINAL to __LOCAL/MMPart.cfg/PART[teste d
e Module Manager]
[LOG 13:42:00.539] Applying update __LOCAL/MMBug/@PART[*]:HAS[@MODULE[IFSResourceTransfer]]:FINAL to __LOCAL/MMPart.cfg/PART[teste d
e Module Manager]
[LOG 13:42:00.539] Applying update __LOCAL/MMBug/@PART[*]:HAS[@MODULE[IFSResourceTransfer]]:FINAL to __LOCAL/MMPart.cfg/PART[teste d
e Module Manager]
[LOG 13:42:00.540] Done patching
[LOG 13:42:00.540] Saving Cache
[LOG 13:42:01.084] Done!

i.e... It worked fine!

What I can conclude from my mishaps that an extra { } shoved where it should not played havoc with my previous tests, and this was pretty hard to eye ball. It took me some hours doing something else and going back to this to detect the error.

My test suggests that the example above from @FreeThinker should had worked. I think that the original patch has some small mishap (as the { } I did) and this is preventing the module's name to be changed, and then the MM_PATCH_LOOP enters into a infinite loop.

One thing that may be affecting the result is the ordering directive, I used :FINAL on my patch that worked.

On a second attempt, the very same patch failed when I removed the :FINAL operator: it entered into a infinite loop!

So I think I diagnosed the problem! :)

 

Edited by Lisias
post edit
Link to comment
Share on other sites
Lisias

Lisias

Posted
Posted
2 hours ago, FreeThinker said:

impressive, but it meansyou need to use :FINAL, which is kind of ugly

Yep. And I was wrong when I thought I was wrong! :sticktongue:

There's a bug on Module Manager. A real nasty bug.

I recompiled MM with LOGSPAM, and noticed that with or wihout :FINAL, the patch enters in a infinite loop! The MMPatch.log is HUGE, with an almost endless repetition of what follows: 

[ModuleManager] INFO: Looping on __LOCAL/MMBug/@PART[*]:HAS[@MODULE[IFSResourceTransfer]]:FINAL to __LOCAL/MMPart.cfg/PART[teste de Module Manager]
[ModuleManager] INFO: Applying update __LOCAL/MMBug/@PART[*]:HAS[@MODULE[IFSResourceTransfer]]:FINAL to __LOCAL/MMPart.cfg/PART[teste de Module Manager]
[ModuleManager] INFO: modding values
[ModuleManager] INFO: modding values
   @name= FNResourceTransfer: IFSResourceTransfer -> FNResourceTransfer
[ModuleManager] INFO:   Applying subnode @MODULE[IFSResourceTransfer]

[ModuleManager] INFO: modding values
<and now it loops into INFO: Applying update in secula seculorum>

The difference is that, somehow, the :FINAL is not locking the thread.

I'm guessing that by not using :FINAL, the patch runs on the LEGACY phase and whatever calls the LEGACY phase locks waiting for its finish (what never happens), but the caller don't locks on :FINAL - so when the code detects everything is patched, it moves on and the dead-looped thread is killed by someone else.

Link to comment
Share on other sites
blowfish

blowfish

Posted
Posted

@Lisias I couldn't reproduce any infinite loop with this setup, FINAL or no (there shouldn't be any difference between how patches in different passes are applied).

Spoiler 

NOTPART2
{
	name = teste de Module Manager
	MODULE
	{
		name = IFSResourceTransfer
	}
	MODULE
	{
		name = IFSResourceTransfer
	}
	MODULE
	{
		name = IFSResourceTransfer
	}
}


@NOTPART2[*]:HAS[@MODULE[IFSResourceTransfer]]
{
	@MODULE[IFSResourceTransfer]
	{
		@name = FNResourceTransfer
	}
	MM_PATCH_LOOP { }
}

There's also no locking (except when it comes to queueing and dequeuing log messages) - patching happens on a single thread to an isolated copy of the configs, it's applied to the real game database later on the main thread, but only after the patching thread has exited and written that set of configs to a variable.

@FreeThinker this is probably the simplest thing to accomplish what you want, worked when I tried

Spoiler 

@PART:HAS[@MODULE[IFSResourceTransfer]]
{
	@MODULE[IFSResourceTransfer],*
	{
		@name = FNResourceTransfer
	}
}

Evidently here the HAS isn't strictly necessary, I like to include it though just because it doesn't produce log messages for parts it doesn't do anything to.

 

Link to comment
Share on other sites
Lisias

Lisias

Posted
Posted (edited)
2 hours ago, blowfish said:

@Lisias I couldn't reproduce any infinite loop with this setup, FINAL or no (there shouldn't be any difference between how patches in different passes are applied).

We have two reports that the MM_PATCH_LOOP was entering on a infinite loop, mine and @FreeThinker, so this is unlikely to be a misdiagnosing. And I made my tests using both canonical and my experimental (customised) fork, with identical results, so none of my customisations affected the result. MM 3 also presented the problem, by the way...

I made my tests on many KSP versions, clean (only MM installed) and dirty (many random add'ons) installed, and got similar results on every try.

On the other hand, this is straightforward enough to be easily reproducible... So this must be something environmental, perhaps Mono itself?

I'm presuming you are running Windows, I'm running MacOS. @FreeThinker, what was you running when you detected the problem?

In a way or another, all my digging were made with the assumption there's a bug on the code, I didn't considered that it may be good code running on a "bad" runtime...  No to mention the stunt not locking forever when using :FINAL.... I will try using AFTER and BEFORE too to see what happens...

-- -- -- POST EDIT -- -- -- 

NOW I'm worried. One of the clean test beds that presented the problem two days ago, on March 25,  is passing with flying colours today. I didn't even recompile that LOGSPAM customised DLL I used, it was already there.

Weird.

Nothing changed from Thursday to today - other than a reboot on the machine.

I have no explanation for this. Not even a wild guess... :o

-- -- -- POST POST EDIT -- -- -- 

Another test bed that was borking Thursday is working now. This one was exactly as I leaved, including the patch.

Had not @FreeThinker reported it too, and had not I posted a log excerpt with this line: 

   @name= FNResourceTransfer: IFSResourceTransfer -> FNResourceTransfer

(evidence that I didn't messed up the patch with a typo or something), I would be considering I messed this up somehow...

Well, this clears Module Manager as a source of the problem. It's something environmental for sure, as the same testbed with the same binaries and patches behave differently today.

What remains to understand is how this happened, why and if this could not be happening somewhere else too...

Edited by Lisias
Now I'm worried™.
Link to comment
Share on other sites
Camelhairs06

Camelhairs06

Posted
Posted

How do I do this?

I have...

MODULE
    {
        name = ModuleEnginesFX
        engineID = CenterOnly

And ...

MODULE
    {
        name = ModuleEnginesFX
        engineID = AllEngines

 

When I do

@MODULE[ModuleEngines*]

It will obviously try to change both of them, how can I make it so I have 1 @MODULE for each of these without effecting each other?

Thanks.


 

Link to comment
Share on other sites
lookolookthefox

lookolookthefox

Posted
Posted

Hi all, I'm trying to make a patch that integrates MKS drills into SystemHeat, but I'm running into some coding issues with Modulemanager. The MKS mod chooses its resources based on a module "USI_HarvesterSwapOption", while most general info is stored in a different "USI_Harvester". I've been trying to integrate the systempower variable from systemheat into each HarvesterSwapOption but it requires the Ratio variable only found in the USI_Harvester. The following code is what I'm trying to use: 

  

 @PART[*]:HAS[@MODULE[USI_Harvester]:HAS[@INPUT_RESOURCE:HAS[#ResourceName[ElectricCharge]]]]:FINAL{ //really need final.
    !MODULE[ModuleCoreHeat] {}
    %MODULE[ModuleSystemHeat]
    {
        %name = ModuleSystemHeat
        // Cubic metres
        %volume = #$/mass$ //1 ton equals 1 cubic meter of cooling. it *very roughly* approximates the balance of squads ISRU
        %moduleID = harvester
        %iconName = Icon_Drill
    }
	    !MODULE[ModuleOverheatDisplay]{}
	    @MODULE[USI_Harvester]:HAS[@INPUT_RESOURCE:HAS[#ResourceName[ElectricCharge]]]{ //Ive seen some converters that dont use electric charge, those things need thier own patch, as we calculate produced heat based on EC consumption.
        @name = ModuleSystemHeatHarvester
        moduleID = Converter1 //this should be the localization string or the actual name, either way, unique.
        systemHeatModuleID = harvester
        shutdownTemperature = 750
        systemOutletTemperature = 400
        systemEfficiency
    {
        key = 0 1.0
        key = 400 1.0
        key = 650 0.0
    }
        !Thermalefficiency {}
        !TemperatureModifier {}
        @generatesHeat = false //disable stock heating
    }
    @MODULE[USI_HarvesterSwapOption]:HAS[#ResourceName[Dirt]]{
        systemPower = #$@MODULE[USI_Harvester]/Ratio$
        @systemPower *= #$Efficiency$ //set the heat ouput as proportional to the EC usage.
        // I *think* that all the energy goes into heat.
    }
    @MODULE[USI_HarvesterSwapOption]:HAS[#ResourceName[Gypsum]]{
        systemPower = #$@MODULE[USI_Harvester]/Ratio$
        @systemPower *= #$Efficiency$ //set the heat ouput as proportional to the EC usage.
        // I *think* that all the energy goes into heat.

And repeat this for all 13 or so resources. I get a set of very strange errors in my log, and i haven't the foggiest of what they mean and what I'm doing wrong: 

 [LOG 11:18:23.565] Applying update SystemHeatHarvesters/genericHarvestersUSI/@PART[*]:HAS[@MODULE[USI_Harvester]:HAS[@INPUT_RESOURCE:HAS[#ResourceName[ElectricCharge]]]]:FINAL to UmbraSpaceIndustries/MKS/Parts/MKS_Drill_01.cfg/PART[MKS_Drill_01]

	[WRN 11:18:23.572] Can't find nodeType:MODULE

	[ERR 11:18:23.572] Error - Cannot parse variable search when inserting new key systemPower = #$@MODULE[USI_Harvester]/Ratio$

	[WRN 11:18:23.575] Can't find nodeType:MODULE

	[ERR 11:18:23.575] Error - Cannot parse variable search when inserting new key systemPower = #$@MODULE[USI_Harvester]/Ratio$

	[WRN 11:18:23.576] Can't find nodeType:MODULE

	[ERR 11:18:23.576] Error - Cannot parse variable search when inserting new key systemPower = #$@MODULE[USI_Harvester]/Ratio$

	[WRN 11:18:23.577] Can't find nodeType:MODULE

	[ERR 11:18:23.577] Error - Cannot parse variable search when inserting new key systemPower = #$@MODULE[USI_Harvester]/Ratio$

	[WRN 11:18:23.581] Can't find nodeType:MODULE

	[ERR 11:18:23.581] Error - Cannot parse variable search when inserting new key systemPower = #$@MODULE[USI_Harvester]/Ratio$

	[WRN 11:18:23.587] Can't find nodeType:MODULE

	[ERR 11:18:23.587] Error - Cannot parse variable search when inserting new key systemPower = #$@MODULE[USI_Harvester]/Ratio$

	[WRN 11:18:23.589] Can't find nodeType:MODULE

	[ERR 11:18:23.589] Error - Cannot parse variable search when inserting new key systemPower = #$@MODULE[USI_Harvester]/Ratio$

	[WRN 11:18:23.591] Can't find nodeType:MODULE

	[ERR 11:18:23.591] Error - Cannot parse variable search when inserting new key systemPower = #$@MODULE[USI_Harvester]/Ratio$

	[WRN 11:18:23.592] Can't find nodeType:MODULE

	[ERR 11:18:23.592] Error - Cannot parse variable search when inserting new key systemPower = #$@MODULE[USI_Harvester]/Ratio$

	[WRN 11:18:23.593] Can't find nodeType:MODULE

	[ERR 11:18:23.594] Error - Cannot parse variable search when inserting new key systemPower = #$@MODULE[USI_Harvester]/Ratio$

	[WRN 11:18:23.597] Can't find nodeType:MODULE

	[ERR 11:18:23.597] Error - Cannot parse variable search when inserting new key systemPower = #$@MODULE[USI_Harvester]/Ratio$

	[WRN 11:18:23.605] Can't find nodeType:MODULE

	[ERR 11:18:23.605] Error - Cannot parse variable search when inserting new key systemPower = #$@MODULE[USI_Harvester]/Ratio$

	[WRN 11:18:23.608] Can't find nodeType:MODULE

	[ERR 11:18:23.608] Error - Cannot parse variable search when inserting new key systemPower = #$@MODULE[USI_Harvester]/Ratio$ [\code]

This then repeats for all MKS drills. I'm not even sure if the fix i'm trying to use will work, MKS and Systemheat don't interface that well, so if anyone happens to have an idea on that it'd be greatly appreciated too.

Link to comment
Share on other sites
Stone Blue

Stone Blue

Posted
Posted (edited)

@lookolookthefox first thing, I dont think you can have a :HAS inside a :HAS... you have to seperate them

Also, please try to avoid using :FINAL...

I have a low level of MM nowledge, and someone will probably come along with a better answer, but in the mean time, you could try something along the lines of:
  

@PART[*]:HAS[@MODULE[USI_Harvester],@INPUT_RESOURCE[#ResourceName[ElectricCharge]]]:FINAL

The `,` is AND, so it implies "and has" so you can use that in place of a :HAS inside a :HAS.. I see a couple places further down in the patch this could apply to, as well

Edited by Stone Blue
Link to comment
Share on other sites
lookolookthefox

lookolookthefox

Posted
Posted

@Stone Blue I did not write this entire cfg myself, it's from a standard template included in the systemheat mod. The final has a comment mentioning that the final is needed, and the first line works well enough in other scenarios. I'm fairly certain most of the issues come from later lines, since the logs reference those specifically. Will give your solution a shot though.

Link to comment
Share on other sites
Stone Blue

Stone Blue

Posted
Posted (edited)

well, like I said... I only have really basic nowledge of MM syntax/logic, and I still need to as for help on MM quite a bit myself... :P

@lookolookthefox hmm.. wait... I just looked closer, and I see you have `#$@MODULE`... as far as I can tell/thought, the `#` is used for filtering of variables, not nodes... maybe try dumping that... because that may be why its not able to find the module nodes

I thin thats what this means:
`Cannot parse variable search when inserting new key` ... its doing a variable search on a module node, when its really dealing with managing variables/keys, instead... vOv

Edited by Stone Blue
Link to comment
Share on other sites
lookolookthefox

lookolookthefox

Posted
Posted (edited)

@Stone Blue I've taken that bit directly from the syntax Wiki, at the bottom it says something about variables and using that @ to look in different parent nodes, which is what I'm trying to do. The #, from what I've gathered at least, is meant to indicate that I'm looking for the Ratio variable and/or signifying that the systemPower is a variable itself. Again very similar to the way it is done in the base generic code. Your suggestion from earlier has however gotten rid of my errors, now on to seeing if my improvised patch works. It's all down to trial and error sadly, I don't grasp this stuff well at all.

Edit: Patch don't work, will have to find this ModuleManager cache thing to see if it did anything even

Edited by lookolookthefox
progress
Link to comment
Share on other sites
blowfish

blowfish

Posted
Posted

@lookolookthefox this is the problem:
  

systemPower = #$@MODULE[USI_Harvester]/Ratio$

you want 

systemPower = #$/MODULE[USI_Harvester]/Ratio$

or 

systemPower = #$..MODULE[USI_Harvester]/Ratio$

in this context, @ tells it to look for root nodes (PARTs, RESOURCE_DEFINITIONs, etc), whereas / tells it to look in the root of the current node, and .. says to go up a level

Link to comment
Share on other sites
Lisias

Lisias

Posted
Posted (edited)
4 hours ago, Stone Blue said:

  




@PART[*]:HAS[@MODULE[USI_Harvester],@INPUT_RESOURCE[#ResourceName[ElectricCharge]]]:FINAL

 

@lookolookthefox What you need is to solve a triangular dependency, i.e, you (1st party) wants add support to a 2nd party's add'on for a 3rd party's feature.

Using :FINAL will only work safely if only you would be using :FINAL , but if we face a race to the bottom :FINAL, the sad true is that :FINAL will became useless. So we usually only use :FINAL for custom patches made by the user to be used on his own rig (or when absolutely no other way works - but even that...).

One way out of the mess is doing your patching after the MKS specific patches is applied: 

@PART[*]:HAS[@MODULE[USI_Harvester],@INPUT_RESOURCE[#ResourceName[ElectricCharge]]]:NEEDS[SystemHeat]:AFTER[UmbraSpaceIndustries]

This will ensure your patch will only be applied if SystemHeat is installed, and after the UmbraSpaceIndustries "phase", so will be sure that all patches :FOR UmbraSpaceIndustries was already applied when you apply yours.

Edited by Lisias
typo (sigh)
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
 Share
Go to topic listing
×
×
  • Create New...