[0.20] ModuleManager 1.3 - for all your stock-modding needs

[KerbMav]

Am I helping him or am I talking utter Kerpoop?

@PART[[I]name of engine[/I]]
{
@sound_rocket_new = running
}

Or should it look like

@PART[name of engine]
{
!sound_rocket = running
sound_rocket_new = running
}

I also do not know if this entry in the wiki is up-to-date regarding placement of sound files?

But here is something that seems to work, so wiki is out of date.

Please throw food in my general direction if I am cluttering this thread, original question was if MM can swap sound entries in part.cfg or rather if I am doing it right.

And I found an answer ...

Edited October 24, 2013 by KerbMav
probably doing it wrong ...

[Tfly]

ModuleManager doesn't actually do anything to individual files. It makes changes to the configuration nodes after they've been loaded into memory. It is by no means file aware.

All that happens when the game loads and before you reach the main menu. Even if there is a node that is loaded from the save file that could theoretically be altered by ModuleManager, it will be loaded well after ModuleManager has actually processed the nodes during game startup so by that time it would already be too late. So not only is it unable to affect save files on an individual basis but it's already done all of its work well before those save files will ever be loaded.

The only thing that I see you being able to accomplish is using it to force all parts to show up as though already researched and that would happen globally for all saves.

On another note, I'm not even sure I see the point in doing this because Science is only meaningful for researching parts. If you already have all the parts there's no point in doing the science. I have to assume that is why it's locked in sandbox mode to begin with.

I use Sandbox as my test bed - so this is helpful to make sure my designs will transmit back properly in career mode .. but in sandbox R&D is closed .. so no results .. and no transmissions ect... I figured out how to Hard wire R&D in but it's slow and not always the best

It also means I have to check all my mods to make sure they're on the tech tree just to see them . but hey

Anywho thanks for your response

[KerbMav]

It also means I have to check all my mods to make sure they're on the tech tree just to see them . but hey

If it is only for testing purposes, you could tell MM to add the tech lines to all parts in the game and assign the values for the starting node.

You would have to move the cfg everytime you wanted to play for real though.

[therealcrow999]

Is this code right? I am trying to add a node to stock parachutes and edit where it attached at. I'm trying to make it that way so I can add a LES to it.

Another thing, when I add in @part[name of part] is that the name of part folder or the name of part inside part.cfg under general parameters?

The stock parachutes don't have node_stack_top and I didn't know how to add it.

//Parachute attach node on top//

@part[parachute_single]

{ @attachRules = 1,0,1,1,0}

{ Module

{node_stack_top = 0.0, 1.53, 0.0, 0.0, 1.0, 0.0, 0}}

@part[parachuteLarge]

{ @attachRules = 1,0,1,1,0}

{ Module

{node_stack_top = 0.0, 5.0, 0.0, 0.0, 1.0, 0.0, 1}}

[Crater]

Is this code right? I am trying to add a node to stock parachutes and edit where it attached at. I'm trying to make it that way so I can add a LES to it.

Another thing, when I add in @part[name of part] is that the name of part folder or the name of part inside part.cfg under general parameters?

The stock parachutes don't have node_stack_top and I didn't know how to add it.

//Parachute attach node on top//

@part[parachute_single]

{ @attachRules = 1,0,1,1,0}

{ Module

{node_stack_top = 0.0, 1.53, 0.0, 0.0, 1.0, 0.0, 0}}

@part[parachuteLarge]

{ @attachRules = 1,0,1,1,0}

{ Module

{node_stack_top = 0.0, 5.0, 0.0, 0.0, 1.0, 0.0, 1}}

no idea if it will work or not, but the syntax to do what you seem to be attempting would be

@PART[parachuteSingle]
{
	@attachRules = 1,0,1,1,0
        node_stack_top = 0.0, 1.53, 0.0, 0.0, 1.0, 0.0, 0
}

@PART[parachuteLarge]
{
	@attachRules = 1,0,1,1,0
        node_stack_top = 0.0, 5.0, 0.0, 0.0, 1.0, 0.0, 1
}

The PART needs to be in caps, the name for the small chute is not the same as the folder name, the attachRules should replace the existing line, and the node_stack_top is new, both of them are properties of the main part node, so no need for a MODULE statement or any further braces.

Good Luck

[therealcrow999]

no idea if it will work or not, but the syntax to do what you seem to be attempting would be

@PART[parachuteSingle]
{
	@attachRules = 1,0,1,1,0
        node_stack_top = 0.0, 1.53, 0.0, 0.0, 1.0, 0.0, 0
}

@PART[parachuteLarge]
{
	@attachRules = 1,0,1,1,0
        node_stack_top = 0.0, 5.0, 0.0, 0.0, 1.0, 0.0, 1
}

The PART needs to be in caps, the name for the small chute is not the same as the folder name, the attachRules should replace the existing line, and the node_stack_top is new, both of them are properties of the main part node, so no need for a MODULE statement or any further braces.

Good Luck

It didn't work, but this helped me out further. I will try adding something.

[therealcrow999]

It didn't work, but this helped me out further. I will try adding something.

Found the problem, I was using Module Manager 1.4 - Experimental release

[skbernard]

hey guys, first time i've ever really gotten into MM and have a quick question/just-making-sure-i'm-not-an-idiot regarding syntax...

In the following three examples, the only format that is supported in MM is the last one on the ContainerBay right? Does the plugin specifically look for line breaks, not whitespace?

thanks

@PART[KAS_Container1] { TechRequired = start entryCost = 0 }

@PART[KAS_Container2]
{ TechRequired = start entryCost = 0 }

@PART[KAS_ContainerBay1]
{
  TechRequired = start
  entryCost = 0
}

[HoneyFox]

hey guys, first time i've ever really gotten into MM and have a quick question/just-making-sure-i'm-not-an-idiot regarding syntax...

In the following three examples, the only format that is supported in MM is the last one on the ContainerBay right? Does the plugin specifically look for line breaks, not whitespace?

thanks

@PART[KAS_Container1] { TechRequired = start entryCost = 0 }

@PART[KAS_Container2]
{ TechRequired = start entryCost = 0 }

@PART[KAS_ContainerBay1]
{
  TechRequired = start
  entryCost = 0
}

It's not easy to judge whether white space is part of a string, or a line break. e.g. FloatCurve have their key/value pairs with white space in between, that's quite obvious.

[Starwaster]

hey guys, first time i've ever really gotten into MM and have a quick question/just-making-sure-i'm-not-an-idiot regarding syntax...

In the following three examples, the only format that is supported in MM is the last one on the ContainerBay right? Does the plugin specifically look for line breaks, not whitespace?

thanks

@PART[KAS_Container1] { TechRequired = start entryCost = 0 }

@PART[KAS_Container2]
{ TechRequired = start entryCost = 0 }

@PART[KAS_ContainerBay1]
{
  TechRequired = start
  entryCost = 0
}

Last example is correct.

[skbernard]

thanks guys

[sTiKyt]

Hmm I seem to be having trouble deleting or replacing modules I've tried both this;

@PART[GooExperiment] {
	description = This part has been augmented

	!MODULE[ModuleScienceExperiment]
	{
	}
}

and this

@PART[GooExperiment] {
	description = This part has been augmented

	@MODULE[ModuleScienceExperiment]
	{
		name = NewScienceExperiment
	}
}

(NewScienceExperiment is a extension of ModuleScienceExperiment)

While the description changes in the editor the science experiment module always stays attached.

[Starwaster]

Hmm I seem to be having trouble deleting or replacing modules I've tried both this;

@PART[GooExperiment] {
	description = This part has been augmented

	!MODULE[ModuleScienceExperiment]
	{
	}
}

and this

@PART[GooExperiment] {
	description = This part has been augmented

	@MODULE[ModuleScienceExperiment]
	{
		name = NewScienceExperiment
	}
}

(NewScienceExperiment is a extension of ModuleScienceExperiment)

While the description changes in the editor the science experiment module always stays attached.

They seem syntactically correct except that description should be @description on the grounds that the part already has a description property defined. Technically what yours is doing is trying to add a second one.But it seems odd because the behavior that I'd expect is that the description wouldn't change at all and the rest of the code SHOULD still process anyway. Maybe that's breaking it in some weird way but I'm not sure how.

Your second example, same thing. There's already a name property so you need the @ in front. (think of it as a splice operator)

Although, is that really what you want to do? Do you HAVE a module named NewScienceExperiment Because that's what it looks like that line is trying to do; switch the module to a different module defined on some DLL somewhere. Or do you perhaps mean a different property? Like maybe @experimentID = NewScienceExperiment

Also, for deletion, try doing it this way:

!MODULE[ModuleScienceExperiment] {} // {} on the same line

[sTiKyt]

Thanks for your advice. It turns out the only reason it didn't load the new module was the lack of @ in front of name.

[FlowerChild]

I was just wondering if there was a way to specify the order in which various .cfg files are processed by MM. I'm currently working on a mod/plugin that's intended to be played alongside others but which will likely need to modify values that others are also modifying through MM to get the whole thing to be balanced between the individual mods involved.

So, is there any way to specify a change as being a priority one? Are the directories involved reliably parsed in alphabetical order for example where I could just plop my .cfg files in a "zzzMyMod" directory to ensure it gets processed last?

Any help would be appreciated.

Edited October 31, 2013 by FlowerChild

[NathanKell]

You can use :Final after the @NODE[name] tag to specify doing that change last.

i.e. other mods may have

@PART[mypart]

{

@dostuff

}

but yours, if it has

@PART[mypart]:Final

{

@dofinalstuff

}

will be applied last.

[FlowerChild]

You can use :Final after the @NODE[name] tag to specify doing that change last.

Ah! Thanks a million man! I just checked back over the OP as I hadn't noticed that in my last read through, so my apologies for the brain-fart that resulted in me asking a question that was already clearly answered there

[NathanKell]

No problem.

[OrtwinS]

I can't seem to be able to work this one out.

I just want to add electrical consumption to a part. However, when I look at existing parts that use electricity (spot lights, rover wheels, command pods) they all have a completely different way of adding resource consumption!

Spot lights:

MODULE
{
	name = ModuleLight
        lightName = spotlight
	useAnimationDim = true
	lightBrightenSpeed = 2.5
	lightDimSpeed = 2.5
	resourceAmount = 0.04  // <<<<<<<<<<<this
	animationName = LightAnimation
	useResources = true     // <<<<<<<<<<< and this
}

Wheels:

MODULE
{
	name = ModuleWheel
	hasMotor = true
	resourceName = ElectricCharge //<<< this
    	resourceConsumptionRate = 2  //<<< and this
	canSteer = true
	// -snip-, lots of wheel-related stuff
}

mk1 pod (actually, its reaction wheel module):

MODULE
{
	name = ModuleReactionWheel

	PitchTorque = 10
	YawTorque = 10
	RollTorque = 10

	RESOURCE
	{
		name = ElectricCharge // this here, looks actually pretty neat
		rate = 0.375
	}
}

There doesn't seem to be a unified method of using electricity. I know .cfg files are not 'programming', but how does the programming read (and understand) all these different syntaxes of defining electric charge consumption?

What I'm trying to do:

@PART[SCANsat_Scanner]:Final
{
    @description = Does this tweaking actually work?
    @MODULE[SCANsat]
    {
        RESOURCE
        {
            name = ElectricCharge
            rate = 1.9 // Yes it's very high, for testing purposes
        }
    }
}

The description does change (so something is working), but there is no electric consumption.

Placing RESOURCE outside the SCANsat module has no effect either.

Using other names (resourceName = ElectricCharge resourceConsumptionRate = 2) doesn't do anything either.

Edited November 1, 2013 by OrtwinS

[sarbian]

The resource consumption need to be build into the module code to work.

[Starwaster]

power consumption works for those modules because there's programming in c# that reads those properties from the module and requests the resource via the API.

If SCANSat is a PartModule you're developing via C# you should look at other plugin source to see how they're doing it.

For example the radiator code in the most recent versions of ModularFuels. Go take a look at how it implements

1. reading properties from a module
   
2. requests resources from the craft
   
3. I thought there was a #3 but i just woke up and have no coffee so I forget...
   

[OrtwinS]

The resource consumption need to be build into the module code to work.

power consumption works for those modules because there's programming in c# that reads those properties from the module and requests the resource via the API.

If SCANSat is a PartModule you're developing via C# you should look at other plugin source to see how they're doing it.

-snip-

Thanks for the quick answer!

I should have known that MM is only for tweaking stuff in .cfg files that's already there (though, earlier in this thread someone added energy generation to a part that didn't have any before, hence perhaps my confusion)

SCANsat isn't mine by the way. It's still in development and electricity might not be high on the priority list, I had hoped to tweak it in.

My C# is rusty/nonexistant (never used it after those 8 lessons in the first year of university) so I probably shouldn't attempt messing with that myself .

[Starwaster]

Thanks for the quick answer!

I should have known that MM is only for tweaking stuff in .cfg files that's already there (though, earlier in this thread someone added energy generation to a part that didn't have any before, hence perhaps my confusion)

SCANsat isn't mine by the way. It's still in development and electricity might not be high on the priority list, I had hoped to tweak it in.

My C# is rusty/nonexistant (never used it after those 8 lessons in the first year of university) so I probably shouldn't attempt messing with that myself .

It's not totally hopeless. Use ModuleGenerator to provide the power drain.

MODULE
{
  name = ModuleGenerator
  isAlwaysActive = true/false
  activateGUIName = <text>
  shutdownGUIName = <text>
  INPUT_RESOURCE
  {
   name = <resource name>
   rate = 1.9
  }
  OUTPUT_RESOURCE
  {	  
   name = <resource name>	
   rate = <numerical value>	
  }
}

Entirety of its possible parameters provided.

What you want should be fairly simple...

Module
{
  name = ModuleGenerator
  isAlwaysActive = true
  INPUT_RESOURCE
  {
   name = ElectricCharge
   rate = 1.9
  }
}

That should do it...

[Kinote]

I seem to have run into some difficulty with MM, but I'm not sure where I've gone wrong. My first project to add Engineer, Protractor, and MechJeb functionality to all pods worked out quite well, but my attempt to add tech tree entries to KAS and StretchyTank parts has failed and I'm not entirely sure why. I've tried scribbling the code up a few different ways but nothing works, although adding the lines directly into the individual part.cfg files works just fine although is a little too labour intensive with future patches coming down the pipe. Could somebody point me in the right direction? Cheers.

Project 1: Working

@PART[*]:HAS[@MODULE[ModuleCommand]] {
	MODULE {
		name = BuildEngineer
	}

	MODULE {
		name = FlightEngineer
	}

	MODULE {
		name = ProtractorModule
	}

	MODULE {
		name = MechJebCore
	}

}

Project 2: Failure

@PART[KAS_Container1]
{
	@TechRequired = start
}

@PART[KAS_Container2]
{
	@TechRequired = generalConstruction
}

@PART[KAS_ContainerBay1]
{
	@TechRequired = start
}

@PART[KAS_CPort1]
{
	@TechRequired = generalConstruction
}

@PART[KAS_CPort2]
{
	@TechRequired = generalConstruction
}

@PART[KAS_Hook_Anchor]
{
	@TechRequired = landing
}

@PART[KAS_Hook_GrapplingHook]
{
	@TechRequired = generalConstruction
}

@PART[KAS_Hook_Magnet]
{
	@TechRequired = advElectrics
}

@PART[KAS_HookSupport]
{
	@TechRequired = advElectrics
}

@PART[KAS_Pipe1]
{
	@TechRequired = fuelSystems
}

@PART[KAS_Pylon1]
{
	@TechRequired = advConstruction
}

@PART[KAS_Strut1]
{
	@TechRequired = advConstruction
}

@PART[KAS_Winch1]
{
	@TechRequired = generalConstruction
}

@PART[KAS_Winch2]
{
	@TechRequired = generalConstruction
}

@PART[KAS_Winch3] 
{
	@TechRequired = specializedConstruction
}

@PART[KAS_Winch4]
{
	@TechRequired = specializedConstruction
}

@PART[stretchyTank05m] 
{
	TechRequired = precisionEngineering
}

@PART[stretchyTank1m] 
{
	TechRequired = advRocketry
}

@PART[stretchyTank2m] 
{
	TechRequired = veryHeavyRocketry
}

@PART[stretchyTank3m] 
{
	TechRequired = veryHeavyRocketry
}

@PART[stretchyTank4m] 
{
	TechRequired = veryHeavyRocketry
}

Edited November 8, 2013 by Kinote

[sarbian]

The @ is to edit something that exist. Since the TechRequired properties is not here you need to do

@PART[KAS_Container1]
{
	TechRequired = start
}