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

[Van Disaster]

1) The .. only works inside the same root node. TO get an other root node you use @

2) It does not work inside a new node, only inside one you edit. I don't plan to change that for now since it would me a lot more complex afaik.

the (clearly not optimal) solution :

Rgr, thanks.

[Svm420]

@PART
[*]:HAS[@MODULE[ModuleReactionWheel],!MODULE[RWSaturatable]]:Before[RWSaturatable]
{
    @MODULE[ModuleReactionWheel]
    {
        @PitchTorque /= 3.25
        @YawTorque /= 3.25
        @RollTorque /= 3.25
        ecMult = #$PitchTorque$
        @ecMult /= 10 


        @RESOURCE[ElectricCharge]
        {
            @rate = #$/ecMult$
        }
    }
}

I need some help. I want to set all reaction wheels EC to 10% of torque. I haven't been able to get EC rate to equal the value I am trying to copy there. Can someone see something wrong that I am missing. I used deadly reentry as a guide based on starwasters code to set heatproduction based on how much a parts max temp was changed. Thanks!

- - - Updated - - -

Also would MM be able to target say building limits in career like size limits upgrade costs, and/or action group unlocking to be editable in a cfg file? I know this isn't currently a function just wondered if it could handle something like this.

[Crzyrndm]

@PART
[*]:HAS[@MODULE[ModuleReactionWheel],!MODULE[RWSaturatable]]:Before[RWSaturatable]
{
    @MODULE[ModuleReactionWheel]
    {
        @PitchTorque /= 3.25
        @YawTorque /= 3.25
        @RollTorque /= 3.25
        ecMult = #$PitchTorque$
        @ecMult /= 10 


        @RESOURCE[ElectricCharge]
        {
            @rate = #$[B][COLOR=#ff0000]..[/COLOR][/B]/ecMult$
        }
    }
}

ecMult is defined in the node one step out, I think that's all you were missing

Also would MM be able to target say building limits in career like size limits upgrade costs, and/or action group unlocking to be editable in a cfg file? I know this isn't currently a function just wondered if it could handle something like this.

No, if it isn't defined in a .cfg (and/or the cfg isn't loaded in the typical way) Module Manager can't do anything about it.

Buildings are plugin territory

[sarbian]

Hey I'm wondering if I can do something here, patch with MM the config file for TACLS.

Currently its built under the GlobalSettings, which I don't think its a node.

[...]

I haven't seen any mention of it on MM cache. Is it possible?

If you don't see it in the cache then it is not loaded but the game at the start and MM can't edit it..

And I have something planned for the career limits but I was too busy with MJ to finish it.

[NathanKell]

TACLS still uses the ConfigNode.LoadObjectFromConfig() and Save-to methods, i.e. it doesn't use GameDatabase at all.

[Svm420]

@PART
[*]:HAS[@MODULE[ModuleReactionWheel],!MODULE[RWSaturatable]]:Before[RWSaturatable]
{
    @MODULE[ModuleReactionWheel]
    {
        @PitchTorque /= 3.25
        @YawTorque /= 3.25
        @RollTorque /= 3.25
        ecMult = #$PitchTorque$
        @ecMult /= 10 


        @RESOURCE[ElectricCharge]
        {
            @rate = #$[B][COLOR=#ff0000]..[/COLOR][/B]/ecMult$
        }
    }
}

ecMult is defined in the node one step out, I think that's all you were missing

So I need the periods? And thank you for the help.

[Gfurst]

If you don't see it in the cache then it is not loaded but the game at the start and MM can't edit it..

And I have something planned for the career limits but I was too busy with MJ to finish it.

TACLS still uses the ConfigNode.LoadObjectFromConfig() and Save-to methods, i.e. it doesn't use GameDatabase at all.

Thanks guys.

The Career limit thingy sounds good.

[Van Disaster]

1) The .. only works inside the same root node. TO get an other root node you use @

2) It does not work inside a new node, only inside one you edit. I don't plan to change that for now since it would me a lot more complex afaik.

Ended up having to do this:

DEF {
    MODULE {
       name = ModuleName
       id = Foo
    }
}

PART
{
    name = Partname
    #@DEF/MODULE[ModuleName] { }
    #@DEF/MODULE[ModuleName] { }
}

@PART[Partname]
{    
    @MODULE[ModuleName],2 {
        @id = Bar
    }
}

I can't remember if module lists start at 0 or 1, but as it's the last module in the part anyway then it was caught.

[Lithium-7]

Check your brackets ?

RDNode
[SIZE=5][B]}[/B][/SIZE]

Oh, I see! Thanks for the help.

Edit: Actually, changing that bracket from a } to a { doesn't seem to have fixed it. Do I need to add a percentage to it, and/or add percentages to the individual properties?

Edited May 6, 2015 by Brixmon

[himnhouw]

EDIT: Came up with a simpler example to show my problem. This patch only matches the second module. The only difference between the modules is the order of the nodes. Shouldn't it match both?

PART
[*] 
{ 
    @MODULE:HAS[@NODE[a],@NODE:HAS[#prop[b]]]
    {
        matched = true
    } 
}

PART {
    MODULE {
        NODE {
            name = a
        }
        NODE {
            prop = b
        }
    }
    MODULE {
        NODE {
            prop = b
        }
        NODE {
            name = a
        }
    }    
}

Edited May 7, 2015 by himnhouw

[ackley14]

according to the wiki

this:

    
@PART[Part_Name]{
MODULE,0
    {
        name = ModuleAnimateGeneric
        animationName = Animation_Name
        allowManualControl = false

    }
}

should add a module with name "ModuleAnimateGeneric" at the begining of the modules list.

however, all i'm getting is the definition, verbatim at the end of the part config...am i doing something wrong? D:

Edited May 7, 2015 by ackley14

[Mecripp]

Not sure what you mean but you are targeting the the first ModuleAnimateGeneric in the CFG if you add a space , 0

MODULE, 0

[sarbian]

1) Space are E V I L. If you add a space in a line KSP cut the line there so MM does not see what follows.

2) the ,x works only for edits (@ % ! -) not for plain creation. And frankly I don't see the point of an insert to a specific point.

[Shadowmage]

Hi all,

I was wondering if it is possible to patch lines (drag cube entries) in the PartDatabase.cfg file using ModuleManager?

The reason I ask is that I have a complex part that refuses to properly auto-calculate drag-cubes when all of its animation modules are enabled (a conflict between ModuleParachute and ModuleAnimateGeneric prevents proper calculation of the ModuleParachute drag-cubes), the ability to manually specify/override drag-cubes in the part.cfg file itself is bugged and will not load them properly (they are not named properly when loaded from the part.cfg file), leaving my only recourse to manually patch in the proper drag-cube entries into the PartDatabase.cfg file.

Is this feature currently supported?

[sarbian]

No it does not supported and I don't plan too unless the bug you talk about are confirmed.

Are you sure about the naming problem when you set the cube ? Some of the stock part use that and if it was bugged we would have seen it. Are you sure that the problem is not that ModuleParachute force the cube to be recalculated ? Do you try with the procedural flag ?

DRAG_CUBE
{
	procedural = True
}

[Shadowmage]

Yes, I have tried it with the procedural flag; that is what it defaults to for my part. This does not work when trying to utilize the parachute drag-cube modifier modules in my part .cfg file to enable proper parachute draginess; the part plummets to the ground with seemingly normal drag regardless of deployed status of the parachutes (animation works properly for both semi- and full-deploy, including the altitudes when they should activate).

Regarding the stock issue; if you take a look at the stock parts that override the drag cubes in their part.cfg (stack separators are one example) -- while the drag-cube names are properly set in the part .cfg file, the drag cube names are incorrectly parsed when they are loaded into the PartDatabase.cfg. The entries in the PartDatabase.cfg file instead of being named 'cube = Default, [values...]', are named such as 'Default = Default, [values....]' (it writes the drag cube name twice, once where it should have written 'cube'). When this problem is applied to the drag-cubes for parachutes loaded from my part .cfg file, it results in the PartDatabase entries reading like 'DEPLOYED = DEPLOYED, [values...]', rather than the properly specified 'cube = DEPLOYED, [values...]', and these values fail to load/be recognized properly in regards to the parachute module.

I cannot confirm if the in-part-.cfg file overrides actually work properly for the stock parts that have them, I am not sure of a way to view the numerical values for the drag cubes while in-game to see what was loaded. Still working on putting together all of the information/etc so that I can open a proper bug-report, if that is what it turns out to be.

Sorry for the semi-off-topic posts and thanks for the response; been trying to sort out this problem for a few days now, and this is about the last recourse I have (other than removing all other non-parachute animations from my part... which allows it to work/be auto-calculated properly... but I'd rather keep the functionality/animations if I could).

Edit: Just to update; I was/am not looking for you to add additional functionality/create extra work for you; mostly just inquiring -if- it was possible, and explaining the problem. I still have a couple of possibilities to investigate for solving the problem (such as writing a custom animation module that does not interfere with parachutes/drag cube calculations, or perhaps even just trying out the FS animation modules).

Edited May 8, 2015 by Shadowmage

[ackley14]

1) Space are E V I L. If you add a space in a line KSP cut the line there so MM does not see what follows.

2) the ,x works only for edits (@ % ! -) not for plain creation. And frankly I don't see the point of an insert to a specific point.

it does say that's supported on the github wiki strangely enough. and i have a perfectly valid use: if you want to add science functionality to something that has an "active animation" with animation groups, you need to use the animate generic with manual activation set to false, BEFORE the animation group module or else the science part won't understand that theres an animateGeneric in the part file and thus, won't play the parts animation. but thanks for the tip it helped

[INSULINt]

I'm having some problems. I essentially want to create 3 new batteries that use probe core models due to lazyness:

+PART[probeStackSmall]:AFTER[PROBELIFESPAN]
{
	@name = bkupCompStackSmall

	!CrewCapacity = unneeded
	!vesselType = unneeded

	@category = Utility

	@title = Backup Computer, Small Stackable
	@description = A small, yet stackable, backup computer for probes. Requires connection to a main terminal to function. Essentially extends the life of probes.

	!MODULE[*] {}

	!RESOURCE[*] {}

	RESOURCE
	{
		name = LifeSpan
		amount = 250
		maxAmount = 250
	}
}

Unfortunately there are 2 problems I've encountered: the new "batteries" seem to keep their SAS modules, and the patch that I have to apply mechjeb to all unmanned probes also gets applied to them.

I've tried using :FINAL, and even splitting the module and resource section from the rest of the +PART into its own @PART[]:FINAL, but it doesn't solve problem a, and actually make it so that the patch I have to apply 1000 lifespan resource to all unmanned probes gets applied so the lifespan hold I add above becomes 1000 in size.

[futrtrubl]

I'm having some problems. I essentially want to create 3 new batteries that use probe core models due to lazyness:

May need to change to

!MODULE[*],* {}
!RESOURCE[*],* {}

or

!MODULE,* {}
!RESOURCE,* {}

Or it may just be deleting the first MODULE and RESOURCE it finds.

From the OP

@NODE[name] // will wildcard match name (so you can do ModuleEnginesFX or ModuleEngines*), and apply itself to the first NODE it finds.

@NODE[name],index // will wildcard match name, and apply itself to the indexth NODE it finds.

@NODE[name],* // will wildcard match name, and apply itself to ALL matching NODEs.

@NODE[name]:HAS[criteria] // will wildcard match name and apply itself to all matching NODEs which also meet the :HAS criteria

@NODE:HAS[criteria] // will apply itself to all matching NODEs which also meet the :HAS criteria

@NODE,index // will apply itself to the indexth NODE it finds

@NODE,* // will apply itself to ALL NODEs

These apply to @, ! and % nodes. $ nodes are necessarily single-application, and thus will always apply to the first node they find.

Edited May 8, 2015 by futrtrubl

[Gfurst]

Hey, a while back I've commented that somehow a window asking for database reload appeared for me, Module Manager title.

Can someone clarify to me if either, why did appear out of nowhere, and how to call if I want to reload database during run-time.

I'm aware too there is this feature in the stock debug options, in that does it reload and apply MM stuff too?

[INSULINt]

May need to change to

!MODULE,* {}
!RESOURCE,* {}

Or it may just be deleting the first MODULE and RESOURCE it finds.

If I was actually paying attention LOL thanks

Just out of curiosity, when it comes to cloning and creating parts with MM, is there a preferred place to put them in the chain of things. I'd assume FINAL, especially when cloning, but maybe FIRST for simple model reuse to prevent excessive patching?

[futrtrubl]

If I was actually paying attention LOL thanks

Just out of curiosity, when it comes to cloning and creating parts with MM, is there a preferred place to put them in the chain of things. I'd assume FINAL, especially when cloning, but maybe FIRST for simple model reuse to prevent excessive patching?

Depends on whether you are doing it for yourself, in which case wherever it works, or if you plan to release it for other people, in which case do NOT use final.

[sarbian]

Hey, a while back I've commented that somehow a window asking for database reload appeared for me, Module Manager title.

Can someone clarify to me if either, why did appear out of nowhere, and how to call if I want to reload database during run-time.

I'm aware too there is this feature in the stock debug options, in that does it reload and apply MM stuff too?

ALT F11 will show MM reloading menu in the Space Center and Main Menu.

[Ival70]

Thank you for updating for 1.0! For some reason McAfee Web Adviser says that the latest download file is malicious. Further scanning showed it was fine though.

[Gfurst]

ALT F11 will show MM reloading menu in the Space Center and Main Menu.

Thaaankksss!!!!