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

Random Annoying Guy

Random Annoying Guy

Posted
Posted

This doesnt work for some reason 

@PART[petra_basic_docking_port_s0p5_1_female|petra_basic_docking_port_s0p5_1_male]
{
@category = Structural
@title  = #LOC_tantares_petra_docking_plate_s0p5_1
@description = #LOC_tantares_petra_docking_plate_s0p5_1_description
@tags = #LOC_tantares_petra_docking_plate_s0p5_1_tags
!MODULE[ModuleDockingNode]
{
}
}

@PART[petra_basic_docking_port_s0p5_1_male]
{
@category = Coupling
@title = #LOC_tantares_petra_docking_grapple_s0p5_1
@description = #LOC_tantares_petra_docking_grapple_s0p5_1_description
@tags = #LOC_tantares_petra_docking_grapple_s0p5_1_tags
MODULE
{
name = ModuleGrappleNode
nodeTransformName = dockingNode
deployAnimationController = 0
nodeType = petra_basic_s0p5_1
captureRange = 0.05
captureMinFwdDot = 0.5
captureMaxRvel = 0.5
pivotRange = 0
}
}

 

 

Link to comment
Share on other sites
TranceaddicT

TranceaddicT

Posted
Posted
37 minutes ago, Random Annoying Guy said:

This doesnt work for some reason 


@PART[petra_basic_docking_port_s0p5_1_female|petra_basic_docking_port_s0p5_1_male]
{
@category = Structural
@title  = #LOC_tantares_petra_docking_plate_s0p5_1
@description = #LOC_tantares_petra_docking_plate_s0p5_1_description
@tags = #LOC_tantares_petra_docking_plate_s0p5_1_tags
!MODULE[ModuleDockingNode]
{
}
}

@PART[petra_basic_docking_port_s0p5_1_male]
{
@category = Coupling
@title = #LOC_tantares_petra_docking_grapple_s0p5_1
@description = #LOC_tantares_petra_docking_grapple_s0p5_1_description
@tags = #LOC_tantares_petra_docking_grapple_s0p5_1_tags
MODULE
{
name = ModuleGrappleNode
nodeTransformName = dockingNode
deployAnimationController = 0
nodeType = petra_basic_s0p5_1
captureRange = 0.05
captureMinFwdDot = 0.5
captureMaxRvel = 0.5
pivotRange = 0
}
}

 

How about a KSP.log and a MMConfig so we can see what's happening.

 

But, my first guess, you want to use % not @

Link to comment
Share on other sites
HansAcker

HansAcker

Posted
Posted
8 hours ago, Random Annoying Guy said:
12 hours ago, TranceaddicT said:

Try a less malicious site.

 

???

"Firefox blocked this page because it might try to trick you into installing programs that harm your browsing experience (for example, by changing your homepage or showing extra ads on sites you visit). Advisory provided by Google Safe Browsing. s000.tinyupload.com has been reported as containing harmful software. You can ignore the risk and go to this unsafe site."

Getting to your log takes a click to bypass this warning in Firefox. Dropbox or pastebin don't provoke this message.

Link to comment
Share on other sites
HansAcker

HansAcker

Posted
Posted
On 7/21/2020 at 7:49 PM, Random Annoying Guy said:

This doesnt work for some reason

The name of the parts are "petra_docking_port_s0p5_1_*", not "petra_basic_docking_port_s0p5_1_*" ("basic" is, confusingly, only in the file name)

https://github.com/Tantares/Tantares/blob/master/GameData/Tantares/parts/ANY_DOCKING_PORT/LOK_DOCKING_PORT/_petra_basic_docking_port_s0p5_1_male.cfg

Link to comment
Share on other sites
TranceaddicT

TranceaddicT

Posted
Posted (edited)
6 hours ago, HansAcker said:

The name of the parts are "petra_docking_port_s0p5_1_*", not "petra_basic_docking_port_s0p5_1_*" ("basic" is, confusingly, only in the file name)

https://github.com/Tantares/Tantares/blob/master/GameData/Tantares/parts/ANY_DOCKING_PORT/LOK_DOCKING_PORT/_petra_basic_docking_port_s0p5_1_male.cfg

 
 
 

Concur. You're calling the folder name not the part name. 

@PART[petra_basic_docking_port_s0p5_1_female|petra_basic_docking_port_s0p5_1_male]

You want this: 

@PART[petra_docking_port_s0p5_1_female|petra_docking_port_s0p5_1_male]

I believe, best practice is to:

use @ to mark a node for change (https://github.com/sarbian/ModuleManager/wiki/Module-Manager-Syntax#edit----).

use % when changing or adding values (https://github.com/sarbian/ModuleManager/wiki/Module-Manager-Syntax#edit-or-create---). 

@PART[petra_docking_port_s0p5_1_female|petra_docking_port_s0p5_1_male]
{
%category = Structural
%title  = #LOC_tantares_petra_docking_plate_s0p5_1
%description = #LOC_tantares_petra_docking_plate_s0p5_1_description
%tags = #LOC_tantares_petra_docking_plate_s0p5_1_tags
!MODULE[ModuleDockingNode]
{
}
}

@PART[petra_docking_port_s0p5_1_male]
{
%category = Coupling
%title = #LOC_tantares_petra_docking_grapple_s0p5_1
%description = #LOC_tantares_petra_docking_grapple_s0p5_1_description
%tags = #LOC_tantares_petra_docking_grapple_s0p5_1_tags

@MODULE
{
%name = ModuleGrappleNode
%nodeTransformName = dockingNode
%deployAnimationController = 0
%nodeType = petra_basic_s0p5_1
%captureRange = 0.05
%captureMinFwdDot = 0.5
%captureMaxRvel = 0.5
%pivotRange = 0
}
}

 

Edited by TranceaddicT
urls
Link to comment
Share on other sites
HansAcker

HansAcker

Posted
Posted
12 hours ago, TranceaddicT said:

use @ to mark a node for change

If it exists. A single "@MODULE" without a name won't work.

Apart from the names, RAG's patch looked ok to me. All @edited values (currently) are set in the original part and the dockingNode transform exists in the model. I wasn't sure about "deployAnimationController" (does the grapple module require an arming animation? the default value would be -1) and "nodeType" (should work, the value is just copied from the original part's docking module).

I didn't quite see, *why* to convert a docking port into a grappling klaw ;) But if there's a need, MM can patch it.

Link to comment
Share on other sites
Jognt

Jognt

Posted
Posted
On 7/21/2020 at 7:49 PM, Random Annoying Guy said:

This doesnt work for some reason 


@PART[petra_basic_docking_port_s0p5_1_female|petra_basic_docking_port_s0p5_1_male]
{
@category = Structural
@title  = #LOC_tantares_petra_docking_plate_s0p5_1
@description = #LOC_tantares_petra_docking_plate_s0p5_1_description
@tags = #LOC_tantares_petra_docking_plate_s0p5_1_tags
!MODULE[ModuleDockingNode]
{
}
}

@PART[petra_basic_docking_port_s0p5_1_male]
{
@category = Coupling
@title = #LOC_tantares_petra_docking_grapple_s0p5_1
@description = #LOC_tantares_petra_docking_grapple_s0p5_1_description
@tags = #LOC_tantares_petra_docking_grapple_s0p5_1_tags
MODULE
{
name = ModuleGrappleNode
nodeTransformName = dockingNode
deployAnimationController = 0
nodeType = petra_basic_s0p5_1
captureRange = 0.05
captureMinFwdDot = 0.5
captureMaxRvel = 0.5
pivotRange = 0
}
}

 

 

Besides the part name thing that was mentioned: '|' means OR. As far as I know, MM doesn't like OR filters in the ID field. If your patch doesnt work after fixing the names, try using a comma instead of the pipe.

You're also adjusting the male port twice there. Since the descriptions mention ports vs grapples I'm assuming that's due to the erroneous name usage. But something to keep in mind if not.

Link to comment
Share on other sites
Stone Blue

Stone Blue

Posted
Posted (edited)

If those are the only two parts with the same name, up to the _male/_female, you could shorten the whole thing with a wildcard character:
  

@PART[petra_basic_docking_port_s0p5_1_female|petra_basic_docking_port_s0p5_1_male]
becomes:
@PART[petra_basic_docking_port_s0p5_1*]


That will do everything that macthes up to the wildcard '*', and apply to all that match (ie *both* the _male/female)

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

Qyst

Posted
Posted

I'd like to request some assistance: I'm trying to create an MM patch to remove smoke plumes from all engines (but not engine flames or other particles). While I have already made plenty of other patches I'm unsure about a particular detail of MM syntax/behaviour.

Engines such as the stock Rapier have several running modes and each of them can (and does) have its own smoke trail configuration, for example:

Spoiler 

EFFECTS
{
	running_closed
	{
		PREFAB_PARTICLE
		{
			prefabName = fx_smokeTrail_aeroSpike
			transformName = smokePoint
		}
	}
	running_open
	{
		PREFAB_PARTICLE
		{
			prefabName = fx_smokeTrail_aeroSpike
			transformName = smokePoint
		}
	}
}

(Some parts removed for the sake of compactness)

Now, if I got it right, both running_open and running_closed in that example are "nodes", right? And from what it's written in the MM Syntax wiki, wildcards can not currently be used with nodes. I'm assuming this is why it didn't work when I tried something like: 

@running_*
{
	-PREFAB_PARTICLE,* {}
}

... so instead I must explicitly and separately @ every differently-named engine running mode in my install in order for my patch to apply to all of them? Or is there a way I could do this in less lines with wildcards or something?

Link to comment
Share on other sites
Stone Blue

Stone Blue

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

. so instead I must explicitly and separately @ every differently-named engine running mode in my install in order for my patch to apply to all of them? Or is there a way I could do this in less lines with wildcards or something?

I'm not sure if ModuleEngineFX is the only module that uses those effects nodes, but if so, you could do something like:

target ALL parts, that HAS ModuleEngineFX, then inside that target & delete each EFFECTS node you wnat to delete, seperately

I'm really t ired, and I cant put together the proper syntax for that... :P
But that should be a MUCH shorter patch than trying to target *every* part seperately

EDIT: ugh... nvm... my reading comprehension is not good rn
"separately @ every differently-named engine running mode in..." I read that to mean you were looking to target every differently named *engine*...I didt put the "running mode" in there... Sorry

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

TranceaddicT

Posted
Posted
12 hours ago, HansAcker said:

If it exists. A single "@MODULE" without a name won't work.

My read of the patch is to create the new MODULE[ModuleGrappleNode].

11 hours ago, Jognt said:

Besides the part name thing that was mentioned: '|' means OR. As far as I know, MM doesn't like OR filters in the ID field. If your patch doesnt work after fixing the names, try using a comma instead of the pipe.

You're also adjusting the male port twice there. Since the descriptions mention ports vs grapples I'm assuming that's due to the erroneous name usage. But something to keep in mind if not.

You're right the '|' pipe only works in the :NEEDS[ ] dependency checking.

In @PART [ ] there is no optioning, it's always 'and'; so, it would properly be  @PART[myNewPart, yourNewPart, theirNewPart] -or- @PART[*NewPart]

 

 

RAG, this is all you should need. You didn't need to duplicate the info changes twice. 

@PART[petra_docking_port_s0p5_1_*]
{
	@category = Structural
	@title  = #LOC_tantares_petra_docking_plate_s0p5_1
	@description = #LOC_tantares_petra_docking_plate_s0p5_1_description
	@tags = #LOC_tantares_petra_docking_plate_s0p5_1_tags

	!MODULE[ModuleDockingNode]
{


@PART[petra_docking_port_s0p5_1_male]
{
	%MODULE
	{
		%name = ModuleGrappleNode
		%nodeTransformName = dockingNode
		%deployAnimationController = 0
		%nodeType = petra_basic_s0p5_1
		%captureRange = 0.05
		%captureMinFwdDot = 0.5
		%captureMaxRvel = 0.5
		%pivotRange = 0
	}
}

The first is applied to BOTH female & male parts.

The second will only be applied to the male part.

Link to comment
Share on other sites
Qyst

Qyst

Posted
Posted
2 hours ago, Stone Blue said:

I'm not sure if ModuleEngineFX is the only module that uses those effects nodes, but if so, you could do something like:

target ALL parts, that HAS ModuleEngineFX, then inside that target & delete each EFFECTS node you wnat to delete, seperately

I'm really t ired, and I cant put together the proper syntax for that... :P
But that should be a MUCH shorter patch than trying to target *every* part seperately

EDIT: ugh... nvm... my reading comprehension is not good rn
"separately @ every differently-named engine running mode in..." I read that to mean you were looking to target every differently named *engine*...I didt put the "running mode" in there... Sorry

No worries, I guess I could have been clearer. For the record, I've been using the following patch to get rid of most smoke trails:

Spoiler 

@PART:HAS[@MODULE[ModuleEngine*]]:FINAL			// Target any PART with ModuleEngines or ModuleEnginesFX.
{
	-fx_smokeTrail* = DELETE			// Delete all the standalone smoke trails.
	-MODULE[ModuleSurfaceFX],* {}			// Delete all the ground particles. Some parts have more than one.
	@EFFECTS					// Delete the prefab smoke trails inside the running modes inside EFFECTS.
	{
		@running_open
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@running
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@running_closed
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@running_thrust
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@running_thrust2
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@running_full
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@running_LH
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@running_dry
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@running_wet
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@running_four
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@running_one
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@running_shrcam
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
	}
}

 

I'm just trying to see if there is a way to make the large block inside EFFECTS smaller with wildcards or that's not within MM's current feature set (which is why i tried "@running_*" ). Mostly because I'm seeing some mods I use escape my patch, and I wanted to see if there was a way to avoid adding fifty more entries to that list, hahaha.

Link to comment
Share on other sites
Stone Blue

Stone Blue

Posted
Posted (edited)

@Qyst heh.. yeah.. I see now.
Youre already on the right track, for what *I* thought I read... lol

So far, looks good, except, I think you need to still specify specific parts in the top line.
Since you want every part in the game, thats easy :P
You need [*] in there:

EDIT: so i have been informed that using [*], alone, for a top level node, ie PART{ }, is bad and shouldnt be done, as it creates issues with nodes that do *NOT* contain a 'name = ' key. Sorry for the mis-info.
Quote from someone *much* moar knowledgable than I, about the voodoo of MM:
 

Quote

Unless you're single-ing out parts or module nodes explicitly because of their name values, it's quite an oopsie to write [*] in everything

 

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

Jognt

Posted
Posted
On 7/24/2020 at 2:38 PM, Stone Blue said:

@Qyst heh.. yeah.. I see now.
Youre already on the right track, for what *I* thought I read... lol

So far, looks good, except, I think you need to still specify specific parts in the top line.
Since you want every part in the game, thats easy :P
You need [*] in there:
  


@PART[*]:HAS[@MODULE[ModuleEngine*]]:FINAL

 

I could be wrong, but I remember MM not really caring about that asterisk there. Easy enough to test. And using the asterisk would probably still be good practice though. ;)

Link to comment
Share on other sites
Qyst

Qyst

Posted
Posted
On 7/24/2020 at 9:38 AM, Stone Blue said:

@Qyst heh.. yeah.. I see now.
Youre already on the right track, for what *I* thought I read... lol

So far, looks good, except, I think you need to still specify specific parts in the top line.
Since you want every part in the game, thats easy :P
You need [*] in there:

 

 

4 hours ago, Jognt said:

I could be wrong, but I remember MM not really caring about that asterisk there. Easy enough to test. And using the asterisk would probably still be good practice though. ;)

According to the syntax wiki on the MM Github the [*] actually restricts the range of the search to nodes that have a defined "name" field, making it equal to :HAS[#name[*]]. My personal patches file is decently large and uses exclusively @PART:HAS throughout, haven't had any immediately evident issues with it.

In any case, that's besides the point, what I'd like to know is if there is truly no way to use wildcards for node selection, or a viable alternative. Because mods like ReStock, Plus, and CryoEngines make each engine use a differently-named running-mode node for each engine, making my personal smoketrail-removing patch rather excessively large and repetitive right now. In other words, I want to compact this:

Spoiler 

@PART:HAS[@MODULE[ModuleEngine*]]:FINAL				// Target any PART with ModuleEngines or ModuleEnginesFX.
{
	-fx_smokeTrail* = DELETE				// Delete all the standalone smoke trails.
	-MODULE[ModuleSurfaceFX],* {}				// Delete all the ground particles. Some parts have more than one.
	@EFFECTS						// Delete the prefab smoke trails inside the running modes inside EFFECTS.
	{
			// For stock KSP/Squad.
		
		@running_open
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@running
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@running_closed
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@running_thrust
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@running_dry
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@running_wet
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		
			// For mod SpaceY-Lifters.
		
		@running_four
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@running_one
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@running_full
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		
			// For mod PrakasaAeroworks.
		
		@running_thrust2
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@VaporPlume
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		
			// For mod OPT_Reconfig.
		
		@running_shrcam
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@powersharp
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@powerspool
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@running_classic
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@running_smoke
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		
			// For mod Mk2Expansion.
		
		@power_open
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@power_dry
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@power_wet
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		
			// For mod RLA_Reborn.
		
		@linearmain
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@ntrsmall
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@smallSRB
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@blueredtiny
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		
			// For mod ReStock.
		
		@fx-mainsail-running
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-skipper-running
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-ant-running
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-spider-running
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-twitch-running
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-rhino-running
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-mammoth-running
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-poodle-running
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-twinboar-running
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-mite-running
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-shrimp-running
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-tb-running
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-clydesdale-running
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-kickback-running
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-thumper-running
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-hammer-running
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-flea-running
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-separatron-running
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-les-running
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-nerv-running
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-vector-running
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-terrier-running
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-reliant-running
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-swivel-running
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-thud-running
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-dart-running
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-spark-running
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-puff-running
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		
			// For mod ReStock Plus.
		
		@fx-mallet-running
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-torch-running
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-striker-running
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-panda-running
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx--running
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-cherenkov-running
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-boar-running
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-valiant-running
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-pug-running
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-schnauzer-running
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-anvil-running
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-caravel-running
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-ursa-running
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-mastodon-running
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-corgi-running
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		
			// For mod CryoEngines.
			
		@fx-stromboli
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-fuji
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-ulysses
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-hecate
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-vesuvius
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-pavonis
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-erebus
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-tharsis
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
		@fx-etna
		{
			-PREFAB_PARTICLE:HAS[#prefabName[fx_smokeTrail*]],* {}
		}
}

 

 

Link to comment
Share on other sites
etmoonshade

etmoonshade

Posted
Posted

Is there a way to tell MM to prevent a folder or .cfg from being loaded?

Use case:

I maintain a personal mod that consists of a fair number of MM patches. I add a number of parts, and make some tweaks on others.

I want to use MM to disable certain patches and/or features bundled with other mods though - an example would be KSPI-E's near future mode, or bundled mods with planet packs (the latter being what started me thinking down this path.) Being able to blacklist a .cfg or folder entirely from being loaded would save a lot of trouble field-stripping a mod after every update - I'm not afraid of doing some initial work to patch things up, but I don't want to have to go in and remove stuff every time something gets updated.

I kind of assume MM can't do that, because I can see a mod creator causing hate and discontent by including patches to disable other mods they don't like. But maybe my cynicism is unwarranted, and the feature is there and just not widely used. :D

Link to comment
Share on other sites
TranceaddicT

TranceaddicT

Posted
Posted (edited)
4 hours ago, etmoonshade said:

Is there a way to tell MM to prevent a folder or .cfg from being loaded?

Use case:

I maintain a personal mod that consists of a fair number of MM patches. I add a number of parts, and make some tweaks on others.

I want to use MM to disable certain patches and/or features bundled with other mods though - an example would be KSPI-E's near future mode, or bundled mods with planet packs (the latter being what started me thinking down this path.) Being able to blacklist a .cfg or folder entirely from being loaded would save a lot of trouble field-stripping a mod after every update - I'm not afraid of doing some initial work to patch things up, but I don't want to have to go in and remove stuff every time something gets updated.

I kind of assume MM can't do that, because I can see a mod creator causing hate and discontent by including patches to disable other mods they don't like. But maybe my cynicism is unwarranted, and the feature is there and just not widely used. :D

 
 

To disable/prevent loading, no.  MM loads every patch it finds from the get go. Then, it proceeds to dismiss those patches for which there are unmet :NEEDS. 

Can you give me an example of KSPIE-NF you find bothersome? I haven't used it so I'm not familiar.

Also, if I may so bold, if you're maintaining a singular MMConfig that can get difficult to manage.  I create a folder '__myLOCAL' with an internal structure which mirrors /GameData. Each patch only addresses one issue for that mod. 

/GameData

../mmyLOCAL
../../ModA
../../ModB

../ModA
../ModB
Edited by TranceaddicT
Link to comment
Share on other sites
etmoonshade

etmoonshade

Posted
Posted
1 minute ago, TranceaddicT said:

To disable/prevent loading, no.  MM loads every patch it finds from the get go. Then, it proceeds to dismiss those patches for which there are unmet :NEEDS. 

Can't you give me an surviving example of KSPIE-NF you find bothersome? I haven't used it so I'm not familiar.

Also, if I may so bold, if you're maintaining a singular MMConfig that can get difficult to manage.  I create a folder '__myLOCAL' with an internal structure which mirrors /GameData. Each patch only addresses one issue for that mod.

 

The USI_NF_Mode.cfg under WarpPlugin\Patches scales most power-related stuff down to 1% of the original, but there's some stuff it doesn't cover such as antenna transmission power. I've already reported that bit to @FreeThinker. I don't like the patch in general though because I like Big NumbersTM. :D A former issue with KSPI-E that fits the other complaint is that InterstellarFuelSwitch was bundled (it's not anymore,) and I never used it since my personal parts include procedural tanks for everything KSPI-E.

And no, I've got one patch per mod. I'm not mirroring GameData like you're suggesting, but I don't actually have that many patches. My issue isn't maintenance, so much as trying to revert another patch - as far as I can tell, I'd essentially have to re-overwrite whatever the patch changed, and that'd be a nightmare of diffing .cfgs every time a mod updated. At that point, deleting whatever annoys me by hand is probably a lot easier.

I realized after posting that this probably isn't a good function for MM in the first place (although it could easily fit into the config format,) and ended up posting it to the CKAN Github as a suggestion instead.

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...