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

[Andem]

Does anyone know why something happens in the MM Cache but not the actual Game? I wanted to update my mod several weeks ago and haven't been able to.

[blowfish]

1 hour ago, nli2work said:

mediocre question... when MM adds a MODULE{}... is it added at the end of the config after all the other MODULE{}? or at the beginning before all the other MODULE{}?

my config has a number of modules, two depends on two others and references their index. If MODULE{} added by MM is at the beginning, I can adjust the index references accordingly; if MODULE{} is added at the end, then all is well. 

By default, it's added at the end, but you can specify otherwise.

22 minutes ago, Andem said:

Does anyone know why something happens in the MM Cache but not the actual Game? I wanted to update my mod several weeks ago and haven't been able to.

That shouldn't be the case.  Is it different between the MM cache and looking at the config in the debug window (Alt+F12)?  Or is the behavior just not what you expect?  Specifics really help with these sorts of issues, just FYI.

[Andem]

1 hour ago, blowfish said:

That shouldn't be the case.  Is it different between the MM cache and looking at the config in the debug window (Alt+F12)?  Or is the behavior just not what you expect?  Specifics really help with these sorts of issues, just FYI.

On the previous page, I was told to look at the cache file. I did, and the patch appeared to be functioning there, but it does nothing in the game. Other MM patches work just fine, but not mine.

[blowfish]

10 minutes ago, Andem said:

On the previous page, I was told to look at the cache file. I did, and the patch appeared to be functioning there, but it does nothing in the game. Other MM patches work just fine, but not mine.

Well, looking at your config again you have specified a zero node normal (the last 3 numbers).  This is probably the issue.

[Akira_R]

I'm trying to do some math on some config points with MM and I'm not sure how it should be written.

The cfg I want to work on looks like this

Spoiler

EVE_CLOUDS
{
    OBJECT
    {
       
        speed = x,y,z
    }
}

If I want to change it like this

Spoiler

EVE_CLOUDS
{
    OBJECT
    {
        speed = 1.2x,1.2y,1.2z
    }
}

Can I do that with this?

Spoiler

@EVE_CLOUDS
{
    @OBJECT,*
    {
        @speed *= 1.2
    }
}

Or would I need something like this?

Spoiler

@EVE_CLOUDS
{
    @OBJECT,*
    {
        @speed *= 1.2 1.2 1.2
    }
}

 

Edited May 7, 2016 by Akira_R
fix weird spoiler tag behavior lol

[NecroBones]

55 minutes ago, Akira_R said:

I'm trying to do some math on some config points with MM and I'm not sure how it should be written.

The cfg I want to work on looks like this

  Hide contents

EVE_CLOUDS
{
    OBJECT
    {
       
        speed = x,y,z
    }
}

If I want to change it like this

  Hide contents

EVE_CLOUDS
{
    OBJECT
    {
        speed = 1.2x,1.2y,1.2z
    }
}

 

 

 

 

I think you need something more like this:

@EVE_CLOUDS
{
    @OBJECT
    {
        @speed[0,,] *= 1.2
        @speed[1,,] *= 1.2
        @speed[2,,] *= 1.2
    }
}

I haven't tried doing that with a wildcard in there for the index, instead of integers. The number index is a 0-based position, so "0" is the first item in the list, "1" is the second, etc. The reason there are two commas is because the first one separates the number from the second parameter, and the second comma is the second parameter. It's tell it which character to split around, in order to make a list from the "speed", so you can edit the values in it one at a time.

 

[blowfish]

1 hour ago, Akira_R said:

I'm trying to do some math on some config points with MM and I'm not sure how it should be written.

The cfg I want to work on looks like this

  Reveal hidden contents

EVE_CLOUDS
{
    OBJECT
    {
       
        speed = x,y,z
    }
}

If I want to change it like this

  Reveal hidden contents

EVE_CLOUDS
{
    OBJECT
    {
        speed = 1.2x,1.2y,1.2z
    }
}

Can I do that with this?

  Reveal hidden contents

@EVE_CLOUDS
{
    @OBJECT,*
    {
        @speed *= 1.2
    }
}

Or would I need something like this?

  Reveal hidden contents

@EVE_CLOUDS
{
    @OBJECT,*
    {
        @speed *= 1.2 1.2 1.2
    }
}

 

@NecroBones Is right, but there are a couple of simplifications that can be made: (1) Comma is the default separator so it doesn't need to be specified, (2) You can use * in place of an index to apply to all elements.  So you just need @speed[*] *= 1.2.  This is in the OP release notes for Version 2.6.14/15/16.

EDIT: Necrobones, are you saying the wildcard index doesn't work?  I think that would be a bug.

Edited May 7, 2016 by blowfish

[NecroBones]

9 minutes ago, blowfish said:

EDIT: Necrobones, are you saying the wildcard index doesn't work?  I think that would be a bug.

 

No, I just hadn't tried it.

 

[Aurelius]

I have been trying to add Mechjeb module to some computerized parts such as SAS modules and probe cores, but I cannot get it working. I would be most grateful for advice how to properly add Mechjeb functionality to certain parts. I tried unsuccessfully several syntaxes like these:

@PART[probeStackSmall],!MODULE[MechJebCore]:Final
{     
@MODULE
 {
 name = MechJebCore
 MechJebLocalSettings {
            MechJebModuleCustomWindowEditor { unlockTechs = flightControl }
            MechJebModuleSmartASS { unlockTechs = flightControl }
            MechJebModuleManeuverPlanner { unlockTechs = advFlightControl }
            MechJebModuleNodeEditor { unlockTechs = advFlightControl }
            MechJebModuleTranslatron { unlockTechs = advFlightControl }
            MechJebModuleWarpHelper { unlockTechs = advFlightControl }
            MechJebModuleAttitudeAdjustment { unlockTechs = advFlightControl }
            MechJebModuleThrustWindow { unlockTechs = advFlightControl }
            MechJebModuleRCSBalancerWindow { unlockTechs = advFlightControl }
            MechJebModuleRoverWindow { unlockTechs = fieldScience }
            MechJebModuleAscentGuidance { unlockTechs = specializedControl }
            MechJebModuleLandingGuidance { unlockTechs = specializedControl }
            MechJebModuleSpaceplaneGuidance { unlockTechs = hypersonicFlight }
            MechJebModuleDockingGuidance { unlockTechs = specializedControl }
            MechJebModuleRendezvousAutopilotWindow { unlockTechs = specializedControl }
            MechJebModuleRendezvousGuidance { unlockTechs = specializedControl }
 }
 }
}

@PART[advSasModule]:HAS[@MODULE[ModuleCommand]]:Final
{     
@MODULE
 {
 name = MechJebCore
 MechJebLocalSettings {
            MechJebModuleCustomWindowEditor { unlockTechs = flightControl }
            MechJebModuleSmartASS { unlockTechs = flightControl }
            MechJebModuleManeuverPlanner { unlockTechs = advFlightControl }
            MechJebModuleNodeEditor { unlockTechs = advFlightControl }
            MechJebModuleTranslatron { unlockTechs = advFlightControl }
            MechJebModuleWarpHelper { unlockTechs = advFlightControl }
            MechJebModuleAttitudeAdjustment { unlockTechs = advFlightControl }
            MechJebModuleThrustWindow { unlockTechs = advFlightControl }
            MechJebModuleRCSBalancerWindow { unlockTechs = advFlightControl }
            MechJebModuleRoverWindow { unlockTechs = fieldScience }
            MechJebModuleAscentGuidance { unlockTechs = specializedControl }
            MechJebModuleLandingGuidance { unlockTechs = specializedControl }
            MechJebModuleSpaceplaneGuidance { unlockTechs = hypersonicFlight }
            MechJebModuleDockingGuidance { unlockTechs = specializedControl }
            MechJebModuleRendezvousAutopilotWindow { unlockTechs = specializedControl }
            MechJebModuleRendezvousGuidance { unlockTechs = specializedControl }
 }
 }
}

but nothing has worked so far. Mechjeb module in those parts just doesn't show up in game.

[Aelfhe1m]

@Aurelius Try: 

@PART[probeStackSmall]:HAS[!MODULE[MechJebCore]]:Final
{
...
}

The Advanced Inline Stabilizer (advSasModule) does not have a ModuleCommand module so the second patch will never be applied. Since you can't control a craft without at least one ModuleCommand part (AFAIK) does it even make sense to add MechJeb to it?

[Phineas Freak]

@Aureliusyou are missing some bits:

@PART[probeStackSmall]:HAS[!MODULE[MechJebCore]]
{     
	MODULE
	{
		name = MechJebCore

		MechJebLocalSettings
		{
			MechJebModuleCustomWindowEditor { unlockTechs = flightControl }
			MechJebModuleSmartASS { unlockTechs = flightControl }
			MechJebModuleManeuverPlanner { unlockTechs = advFlightControl }
			MechJebModuleNodeEditor { unlockTechs = advFlightControl }
			MechJebModuleTranslatron { unlockTechs = advFlightControl }
			MechJebModuleWarpHelper { unlockTechs = advFlightControl }
			MechJebModuleAttitudeAdjustment { unlockTechs = advFlightControl }
			MechJebModuleThrustWindow { unlockTechs = advFlightControl }
			MechJebModuleRCSBalancerWindow { unlockTechs = advFlightControl }
			MechJebModuleRoverWindow { unlockTechs = fieldScience }
			MechJebModuleAscentGuidance { unlockTechs = specializedControl }
			MechJebModuleLandingGuidance { unlockTechs = specializedControl }
			MechJebModuleSpaceplaneGuidance { unlockTechs = hypersonicFlight }
			MechJebModuleDockingGuidance { unlockTechs = specializedControl }
			MechJebModuleRendezvousAutopilotWindow { unlockTechs = specializedControl }
			MechJebModuleRendezvousGuidance { unlockTechs = specializedControl }
 		}
	}
}

@PART[advSasModule]:HAS[!MODULE[MechJebCore]]
{
	MODULE
	{
		name = MechJebCore

		MechJebLocalSettings
		{
			MechJebModuleCustomWindowEditor { unlockTechs = flightControl }
			MechJebModuleSmartASS { unlockTechs = flightControl }
			MechJebModuleManeuverPlanner { unlockTechs = advFlightControl }
			MechJebModuleNodeEditor { unlockTechs = advFlightControl }
			MechJebModuleTranslatron { unlockTechs = advFlightControl }
			MechJebModuleWarpHelper { unlockTechs = advFlightControl }
			MechJebModuleAttitudeAdjustment { unlockTechs = advFlightControl }
			MechJebModuleThrustWindow { unlockTechs = advFlightControl }
			MechJebModuleRCSBalancerWindow { unlockTechs = advFlightControl }
			MechJebModuleRoverWindow { unlockTechs = fieldScience }
			MechJebModuleAscentGuidance { unlockTechs = specializedControl }
			MechJebModuleLandingGuidance { unlockTechs = specializedControl }
			MechJebModuleSpaceplaneGuidance { unlockTechs = hypersonicFlight }
			MechJebModuleDockingGuidance { unlockTechs = specializedControl }
			MechJebModuleRendezvousAutopilotWindow { unlockTechs = specializedControl }
			MechJebModuleRendezvousGuidance { unlockTechs = specializedControl }
 		}
	}
}

 

[Aurelius]

@Phineas Freak @Aelfhe1m Thank you both very much! Now it works properly.

[Rhedd]

I seem to have a problem that's the exact opposite of @NecroBones.

I have a few mods that :NEEDS[TacLifeSupport] for them to load related parts, but I'm now using Kerbalism to emulate all of TAC-LS's functions, so I want them to load those parts anyway without having TAC-LS.

How can I use MM to change the :NEEDS[] of a part definition to include Kerbalism? Can that be done?

 

Edited May 7, 2016 by Rhedd

[Warezcrawler]

2 minutes ago, Rhedd said:

I seem to have a problem that's the exact opposite of @NecroBones.

I have a few mods that :NEEDS[TacLifeSupport] for them to load related parts, but I'm now using Kerbalism to emulate all of TAC-LS's functions, so I want them to load those parts anyway without having TAC-LS.

How can I use MM to change the :NEEDS[] of a part definition to include Kerbalism? Can that be done?

 

The easiest I can come of, is to create the Tac lifesupport directory, but without contents.

Alternatively create the needed MM for your needs or lastly mod the mods to your needs.

[blowfish]

@Rhedd Create a single patch that's :FOR[TacLifeSupport] and MM will believe that it's there.  If that's really what you want.

[Rhedd]

30 minutes ago, Warezcrawler said:

The easiest I can come of, is to create the Tac lifesupport directory, but without contents.

Alternatively create the needed MM for your needs or lastly mod the mods to your needs.

I tried the directory thing, but that didn't work.

Modding the mods was what I was looking to do, but I don't know how to write a MM cfg that changes the :NEEDS[] bit of a part's definition.

5 minutes ago, blowfish said:

@Rhedd Create a single patch that's :FOR[TacLifeSupport] and MM will believe that it's there.  If that's really what you want.

Hey, that worked! And it's super easy. Thanks!

Edited May 7, 2016 by Rhedd
Tested suggestion

[sarbian]

Do Not edit other PATCH or cut corners . That s a recipe for disaster. If you want your mod to emulate tac then you add a FOR. 

[Rhedd]

@sarbian

That's what I did, thanks.

It's still going to be a mess to update all the parts to a working state, but I needed the parts to BE there, first.

[Jenyaza]

Strange igea... really strange... what if check condition inside condition?

+PART[DummyPart]:NEEDS[Kerbalism]
// or even harder, @PART[DummyPart]:NEEDS[Kerbalism,!TacLifeSupport]

{
	MODULE[dummyModule]:FOR[TacLifeSupport] { }
}

 

[blowfish]

6 minutes ago, Jenyaza said:

Strange igea... really strange... what if check condition inside condition?

+PART[DummyPart]:NEEDS[Kerbalism]
// or even harder, @PART[DummyPart]:NEEDS[Kerbalism,!TacLifeSupport]

{
	MODULE[dummyModule]:FOR[TacLifeSupport] { }
}

 

Not sure what you're trying to accomplish here.  FOR is meaningless outside of top-level nodes.  Maybe you wanted NEEDS, which does work on subnodes (example).

Edited May 7, 2016 by blowfish

[NecroBones]

 

I think a lot of people get confused as to what "FOR" and "NEEDS" do. @Jenyaza, a "NEEDS" statement is a condition check. When you use a "FOR", it basically tells ModuleManager that this patch belongs to a mod with that name, and is not a condition check.

[Jenyaza]

Oh, i'm just blow up some brains. Sorry .

Quote

FOR is meaningless outside of top-level nodes

I meant FOR (that can "create" new mod), that will be executed only if NEEDS is true.

NEEDS, which does work on subnodes.

And this is meaningful, thanks. I didn't know it.

 

Can we use FOR in any condition, even in main line (next)

@PART[something]:FOR[TACLS]:NEEDS[Kerbalism]

Does TACLS will be created only if Kerbalism found? As far as i know, first, what MM checking is NEEDS[], and it remove all that has missing NEEDS. No?

Edited May 8, 2016 by Jenyaza

[blowfish]

@Jenyaza Could you state in words what you're trying to accomplish?  I think there's probably a simple solution

23 minutes ago, Jenyaza said:

Can we use FOR in any condition, even in main line (next)

@PART[something]:FOR[TACLS]:NEEDS[Kerbalism]

Does TACLS will be created only if Kerbalism found? As far as i know, first, what MM checking is NEEDS[], and it remove all that has missing NEEDS. No?

I don't believe this would work the way you think.  MM goes through at the beginning and generates a list of FOR matches which it considers to be installed mods.  Dependency checking and actual patching is done later.

[Jacke]

15 hours ago, NecroBones said:

 

I think a lot of people get confused as to what "FOR" and "NEEDS" do. @Jenyaza, a "NEEDS" statement is a condition check. When you use a "FOR", it basically tells ModuleManager that this patch belongs to a mod with that name, and is not a condition check.

Perhaps it would have been better if FOR was called PROVIDES.

EDIT: Thinking this one over yet again, PROVIDES wouldn't be an improvement, because the FOR[NAME] block indicating the mod means the MM script is effectively part of mod NAME because it changes mod NAME.  That can mean there's other files and stuff, like .cfg's or a .dll,  Or not, and this MM script is all there is to mod NAME.  PROVIDES would be more misleading in the first case, the more common case.  FOR is about as best a single word to express both cases as exists in English.

Edited May 8, 2016 by Jacke

[sarbian]

Yes, it would be. But it works that way now and I won't break all the mods just for that. No everyone need to write mm patch and once you know how it works you are fine