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

[Beale]

Hi, could someone help me?

The following script stops Antenna animations working, if the mod RemoteTech is not installed.

Though really with the "FOR[RemoteTech]" it shouldn't be applying anything if the mod is not present?

Module manager 2.5.1

@PART[Tantares_Antenna_A]:FOR[RemoteTech]
{
	!MODULE[ModuleDataTransmitter]
	{

	}

	@MODULE[ModuleAnimateGeneric]
	{
		allowManualControl = false
	}

	TechRequired = flightControl
	MODULE
	{
		name = ModuleRTAntenna
		Mode0OmniRange = 0
       		Mode1OmniRange = 500000
		EnergyCost = 0.07

		DeployFxModules = 0

		TRANSMITTER
		{
			PacketInterval = 0.3
			PacketSize = 2
			PacketResourceCost = 15.0
		}
	}

	MODULE
	{
		name = ModuleSPUPassive
	}
}

[Crater]

Hi, could someone help me?

The following script stops Antenna animations working, if the mod RemoteTech is not installed.

Though really with the "FOR[RemoteTech]" it shouldn't be applying anything if the mod is not present?

Module manager 2.5.1

Try changing it to :NEEDS[RemoteTech] instead

The way I understand it is that FOR means it is a part of the mod, NEEDS means it depends on it.

[Beale]

Try changing it to :NEEDS[RemoteTech] instead

The way I understand it is that FOR means it is a part of the mod, NEEDS means it depends on it.

Thanks, but I have also tried NEEDS, it has the same problem

[NathanKell]

If a patch with NEEDS[RemoteTech] in it runs, that means either

1. There is, somewhere, a RemoteTech.dll OR

2. There is, in some MM file somewhere, a :FOR[RemoteTech]

3. There is a folder in GameData called RemoteTech

Make sure you don't have *any* :FOR[RemoteTech] lines, and make sure you don't have the folder or the dll. Then NEEDS[RemoteTech] will fail.

[Beale]

If a patch with NEEDS[RemoteTech] in it runs, that means either

1. There is, somewhere, a RemoteTech.dll OR

2. There is, in some MM file somewhere, a :FOR[RemoteTech]

3. There is a folder in GameData called RemoteTech

Make sure you don't have *any* :FOR[RemoteTech] lines, and make sure you don't have the folder or the dll. Then NEEDS[RemoteTech] will fail.

Thanks for the explanation, it makes more sense now.

It seems there was a stray FOR in my original MM script, my own fault really.

Working fine now!

Thanks.

[dreadicon]

Just wanted to thank Sarbian yet again! I also threw together some Language Configs for Notepad++ syntax highlighting for Module Manager. It's available here, or on my dev page in my sig. Hope it's useful! I welcome any feedback on it!

To use it, just go to Language (top bar in Notepad++), then "Define Your own Language...", then choose import. Select the file, and it's imported! To use it, select Language -> ModuleManager (same menu as "Define your own Language..."). You may have to restart NP++ before it shows up, but otherwise it should work fine!

[Creeperchair]

Win64 is better than MacAnything or Win 32.

[NathanKell]

Yes, yes it is. Shame KSP Win64 is not.

[S1gmoid]

Is there a generally accepted way to hide / disable certain parts via ModuleManager?

[Master Tao]

This works well:

@PART[IR_RotatronScaleable]
{
    %category = -1
}

That prevents the Infernal Robotics Rotatron from showing up in the VAB/SPH, but doesn't remove it from the game. That way, you can still load crafts that have the part, but can't build new crafts with it.

If you're looking to save memory, you have to actually delete the parts and associated textures. ModuleManager doesn't prevent KSP from loading the textures.

[BudgetHedgehog]

Is there a generally accepted way to hide / disable certain parts via ModuleManager?

@PART[partnamehere]
{
    %techRequired = Unresearchable
    %category = -1
}

Should hide the part in both the tech tree and the editor part list. Not 100% sure the syntax is right though, MM has always confused me.

[NathanKell]

If you want to *deprecate* the part (i.e. not kill vessels that use it, but make it not show up in the editor) that will work. If you want to literally hide the part from KSP, you can do !PART[foo] {} and actually delete its config before it's compiled, leading it to not be compiled. Same caveat applies regarding its textures being loaded anyway, though.

[S1gmoid]

If you want to *deprecate* the part (i.e. not kill vessels that use it, but make it not show up in the editor) that will work. If you want to literally hide the part from KSP, you can do !PART[foo] {} and actually delete its config before it's compiled, leading it to not be compiled. Same caveat applies regarding its textures being loaded anyway, though.

Thanks all for the insight.

[Gh0st_DovahJeb]

Possibly a stupid question. Here goes; If I have a mod that is bundled with an older version of MM, will the mod be automatically managed by the latest version, OR do I need to do something to make it work? Thank you!

[Ippo]

Possibly a stupid question. Here goes; If I have a mod that is bundled with an older version of MM, will the mod be automatically managed by the latest version, OR do I need to do something to make it work? Thank you!

Module Manager will detect the multiple instances and only run the most recent version. Of course, as the OP says:

How to install

You just have to put the dll in your KSP/GameData folder. Then you can put you patch .cfg file anywhere. I would create a folder for your personal patch, but it's up to you.

As mentioned earlier you can have multiple version of it. But you can clean up too

It's not a problem to have multiple copies... but it's better not to have them.

[Starwaster]

Module Manager will detect the multiple instances and only run the most recent version. Of course, as the OP says:

It's not a problem to have multiple copies... but it's better not to have them.

Unfortunately, that's not been true for awhile. There have been several versions released which don't properly work with the election process and cause problems. It's better to delete old versions instead of leaving them in the GameData folder. (or rename their extensions which is effectively the same thing as it stops them from being loaded by the game)

[dreadicon]

Is there any way to use something like :FINAL but have it run before any other :FINAL configs? Basically I want it to run after all other mods have been processed, but before any other :FINAL configs so that users/tweakers can override them. Any way to do that? My only thought is to create a folder 'zzz' and put a 'zzz.cfg' file in it with a dummy MM opperation that does nothing, but includes a :FOR[zzz] to trigger dependency, then have all items I want to run after other mods but before :FINAL use :FOR[zzz]

Is that the only way to do this? (Or will not even that work?)

[NathanKell]

That is probably the best method, honestly.

[michaelhester07]

I want to add a request for a change to Module Manager:

Add support for the Reload All button from the database tab of the Ctrl F12 menu. I found that when testing models for a mod that using this would clear any changes done by Module Manager. If that's doable... thanks!

[BudgetHedgehog]

I want to add a request for a change to Module Manager:

Add support for the Reload All button from the database tab of the Ctrl F12 menu. I found that when testing models for a mod that using this would clear any changes done by Module Manager. If that's doable... thanks!

Press Alt+F11 and use that reload instead.

[Mecripp]

What would be the best way to write a MM to change these

PREFAB_PARTICLE
    {
      prefabName = fx_smokeTrail_veryLarge
      transformName = smokePoint
      emission = 0.0 0.0
      [COLOR="#FF0000"]emission = 0.05 0.0
      emission = 0.075 0.25
      emission = 1.0 1.25[/COLOR] <---- These
      speed = 0.0 0.25
      speed = 1.0 1.0
      localOffset = 0, 0, 1
    }
    MODEL_MULTI_PARTICLE
    {
      modelName = Squad/FX/ks25_Exhaust
      transformName = thrustTransform
      emission = 0.0 0.0
      [COLOR="#FF0000"]emission = 0.05 0.0
      emission = 0.075 0.25
      emission = 1.0 1.25[/COLOR] <---- these
      speed = 0.0 0.5
      speed = 1.0 1.2
    }

and just change the emission so they look like this

PREFAB_PARTICLE
{
prefabName = fx_smokeTrail_light
emission = 0.0 0.0
[COLOR="#FF0000"]emission = 0.66 0.0
emission = 0.068 0.75
emission = 1.0 1.25 1.668269 1.668269 [/COLOR] <--- To this
speed = 0.0 0.25
speed = 1.0 1.0
localOffset = 0, 0, 1
}
MODEL_MULTI_PARTICLE
{
modelName = AerojetKerbodyne/FX/AK10Flame
transformName = thrustTransform
emission = 0.0 0.0
[COLOR="#FF0000"]emission = 0.66 0.0
emission = 0.068 0.75
emission = 1.0 1.25 1.668269 1.668269 [/COLOR] <--- To this
speed = 0.0 0.5
speed = 1.0 1.2
}
}

Would this work ?

@PART[*]:HAS[MODULE[EFFECTS]
{
     @PREFAB_PARTICLE
     {
      %emission = 0.0 0.0
      %emission = 0.66 0.0
      %emission = 0.068 0.75
      %emission = 1.0 1.25 1.668269 1.668269
     }

     @MODEL_MULTI_PARTICLE
     {
      %emission = 0.0 0.0
      %emission = 0.66 0.0
      %emission = 0.068 0.75
      %emission = 1.0 1.25 1.668269 1.668269
     }
}

Edited October 23, 2014 by Mecripp2

[NathanKell]

When multiple values are involved, you need to index

@emission,0 = new_emission_for_first_emission_value

@emission,1 = etc

[Mecripp]

When multiple values are involved, you need to index

@emission,0 = new_emission_for_first_emission_value

@emission,1 = etc

What about the node PREFAB_PARTICLE it too ? There is 2 node PREFAB_PARTICLE in a cfg or would it hit the first 1.

EDIT- And thanks

Edited October 23, 2014 by Mecripp2

[NathanKell]

Same deal. If there are two NODEs, then @NODE,0 { do stuff } will change the first.

And you're welcome!

[Dr. Jet]

How to delete unneeded parts when some mod is detected?

For example I tried to get rid of sized-clone-part in presence of TweakScale: "-PART[PartNameHere]:NEEDS[TweakScale]". It didn't work. Surely I'm doing something wrong... but what?