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

Gordon Dry

Gordon Dry

Posted
Posted

@blowfish thanks... I hope that's all for now ...

Then it will be: 

@PART[*]:HAS[@MODULE[ModuleGimbal],~gimbalResponseSpeed[]]:NEEDS[!RealismOverhaul]:FINAL
{
	@MODULE[ModuleGimbal]
	{
		%useGimbalResponseSpeed = true
		%gimbalResponseSpeed = 6
	}
}

@PART[*]:HAS[@MODULE[ModuleGimbal],@MODULE[ModuleEngines]]:NEEDS[!RealismOverhaul]:FINAL
{
	@MODULE[ModuleGimbal]
	{
		@gimbalRange /= #$/mass$
		temp = #$gimbalRange$
		tempb = #$../MODULE[ModuleEngines]/maxThrust$
		@gimbalRange /= #$tempb$
		@gimbalRange *= 100
		@gimbalRange /= #$temp$
		@gimbalResponseSpeed /= #$/mass$
	}
}

@PART[*]:HAS[@MODULE[ModuleGimbal],@MODULE[ModuleEnginesFX]]:NEEDS[!RealismOverhaul]:FINAL
{
	@MODULE[ModuleGimbal]
	{
		@gimbalRange /= #$/mass$
		temp = #$gimbalRange$
		tempb = #$../MODULE[ModuleEnginesFX]/maxThrust$
		@gimbalRange /= #$tempb$
		@gimbalRange *= 100
		@gimbalRange /= #$temp$
		@gimbalResponseSpeed /= #$/mass$
	}
}

@PART[*]:HAS[@MODULE[ModuleGimbal],#gimbalResponseSpeed[>15]]:NEEDS[!RealismOverhaul]:FINAL
{
	@MODULE[ModuleGimbal]
	{
		@gimbalResponseSpeed = 15
	}
}

@PART[*]:HAS[@MODULE[ModuleGimbal],#gimbalResponseSpeed[<6]]:NEEDS[!RealismOverhaul]:FINAL
{
	@MODULE[ModuleGimbal]
	{
		@gimbalResponseSpeed = 6
	}
}
	
@PART[*]:HAS[@MODULE[ModuleGimbal],@MODULE[ModuleEngines]]:NEEDS[!RealismOverhaul]:FINAL
{
	@MODULE[ModuleGimbal]
	{
		!temp = delete
		!tempb = delete
	}
}

@PART[*]:HAS[@MODULE[ModuleGimbal],@MODULE[ModuleEnginesFX]]:NEEDS[!RealismOverhaul]:FINAL
{
	@MODULE[ModuleGimbal]
	{
		!temp = delete
		!tempb = delete
	}
}

// Ferram Aerospace Research
//
// ATTENTION:
// You have to delete the following config:
// GameData\FerramAerospaceResearch\stockEngineGimbalIncrease.cfg
//
// @PART[*]:HAS[@MODULE[ModuleGimbal]]:NEEDS[!RealismOverhaul,FerramAerospaceResearch]:FINAL
// {
	// @MODULE[ModuleGimbal]
	// {
		// @gimbalResponseSpeed *= 1.5
	// }
// }

 

Link to comment
Share on other sites
Gordon Dry

Gordon Dry

Posted
Posted (edited)

Why are all three of these saying "[ModuleManager] Error - pass specifier detected on an insert node (not a patch):" ?

I learned that BEFORE, FOR or AFTER is not okay, but FINAL?
  

PART[*]:HAS[@MODULE[TacSelfDestruct]]:NEEDS[TacSelfDestruct]:FINAL
{
	@MODULE[TacSelfDestruct]
	{
		@timeDelay = 10.0
	}
}

PART[Tank*,tank*,*Tank*,*tank*]:HAS[!MODULE[TacSelfDestruct]]:NEEDS[TacSelfDestruct]:FINAL
{
     MODULE
     {
        name = TacSelfDestruct
        timeDelay = 10.0
        canStage = false
     } 
}

PART[*]:HAS[!MODULE[TacSelfDestruct],@MODULE[ModuleCommand]]:NEEDS[TacSelfDestruct]:FINAL
{
     MODULE
     {
        name = TacSelfDestruct
        timeDelay = 10.0
        canStage = false
     } 
}

Edit:

Removing FINAL works, but I still wonder why. Should work with it. IMHO.

Edited by Gordon Dry
Link to comment
Share on other sites
blowfish

blowfish

Posted
Posted
1 hour ago, Gordon Dry said:

Why are all three of these saying "[ModuleManager] Error - pass specifier detected on an insert node (not a patch):" ?

I learned that BEFORE, FOR or AFTER is not okay, but FINAL?
 

Spoiler 


PART[*]:HAS[@MODULE[TacSelfDestruct]]:NEEDS[TacSelfDestruct]:FINAL
{
	@MODULE[TacSelfDestruct]
	{
		@timeDelay = 10.0
	}
}

PART[Tank*,tank*,*Tank*,*tank*]:HAS[!MODULE[TacSelfDestruct]]:NEEDS[TacSelfDestruct]:FINAL
{
     MODULE
     {
        name = TacSelfDestruct
        timeDelay = 10.0
        canStage = false
     } 
}

PART[*]:HAS[!MODULE[TacSelfDestruct],@MODULE[ModuleCommand]]:NEEDS[TacSelfDestruct]:FINAL
{
     MODULE
     {
        name = TacSelfDestruct
        timeDelay = 10.0
        canStage = false
     } 
}

Edit:

Removing FINAL works, but I still wonder why. Should work with it. IMHO.

I think you want @PART - just PART creates a new one

Link to comment
Share on other sites
Gordon Dry

Gordon Dry

Posted
Posted (edited)

Is this possible? 

@PART[*]:HAS[@MODULE[ModuleGimbal],@MODULE[ModuleEngines]]:NEEDS[!RealismOverhaul]:FINAL
{
	@MODULE[ModuleGimbal]:HAS[#gimbalRange[>0]]
	{
		temp = #$gimbalRange$
		@gimbalRange /= #$/mass$
		tempa = #$gimbalRange$
		tempb = #$/MODULE[ModuleEngines]/maxThrust$
		@gimbalRange /= #$tempb$
		@gimbalRange *= 500
		@gimbalRange /= #$tempa$
		@gimbalRange *= #$/mass$
		@gimbalResponseSpeed /= #$/mass$
	}
}

@PART[*]:HAS[@MODULE[ModuleGimbal],@MODULE[ModuleEngines]]:NEEDS[!RealismOverhaul]:FINAL
{
	@MODULE[ModuleGimbal]:HAS[#gimbalRange[>#$temp$]]
	{
		@gimbalRange = #$temp$
	}
}

Especially this portion in the 2nd patch: 

HAS[#gimbalRange[>#$temp$]]

Edit:

or even this variant: 

HAS[#gimbalRange[>#temp]]

 

Edited by Gordon Dry
Link to comment
Share on other sites
PiezPiedPy

PiezPiedPy

Posted
Posted (edited)

@sarbian Would you be able to add temp variables syntax to MM that are internal/local to a patch but are not added to a node, key , value etc

eg: 

@PART[*]:HAS[@MODULE[ModuleGimbal]]
{
	`temp = 23   //  this would not be added to the part but only for temporary storage of a value
	@range *= `temp

	`somevalue = #$speed$
	`somevalue += 200
	`somevalue /= `temp
	@topspeed = `somevalue
}

I hope you understand what I'm trying to explain ;)  btw I used the ` character as just an example, any other character that is not already used in syntax could be used.

Also an If-Then-Else type of syntax would be nice.

Edited by PiezPiedPy
Link to comment
Share on other sites
blowfish

blowfish

Posted
Posted
1 hour ago, Gordon Dry said:

Is this possible?

...

Not currently possible.  But you can use the fact that x > y is equivalent to x - y > 0 (store the difference in another variable and check whether it's greater than zero)

Link to comment
Share on other sites
linuxgurugamer

linuxgurugamer

Posted
Posted

I'm working on a small issue here.

I have a mod which makes some changes.  currently, the part line looks like: 

@PART[InlineBallute062]:NEEDS[RealChute]:BEFORE[FerramAerospaceResearch]

But this also makes it require Ferram to be there.  I want the patch applied either way, but IF Ferram is there, then to apply it BEFORE Ferram.

I'm looking into this now, so far I don't have a good solution other than to have two copies, one for FAR and one without

Link to comment
Share on other sites
blowfish

blowfish

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

But how to achieve the same for a setting in setting.cfg?

You can’t.  Physics.cfg has special handling to allow this.  Modifying settings in a patch would be problematic anyway since it’s contents can be modified by the game.

1 minute ago, linuxgurugamer said:

But this also makes it require Ferram to be there.  I want the patch applied either way, but IF Ferram is there, then to apply it BEFORE Ferram.

I'm looking into this now, so far I don't have a good solution other than to have two copies, one for FAR and one without

Is there a specific reason it needs to be applied right before FAR and not earlier?

Edited by blowfish
Link to comment
Share on other sites
linuxgurugamer

linuxgurugamer

Posted
Posted
2 minutes ago, blowfish said:
3 minutes ago, linuxgurugamer said:

But this also makes it require Ferram to be there.  I want the patch applied either way, but IF Ferram is there, then to apply it BEFORE Ferram.

I'm looking into this now, so far I don't have a good solution other than to have two copies, one for FAR and one without

Is there a specific reason it needs to be applied right before FAR and not earlier?

Probably not

Link to comment
Share on other sites
theJesuit

theJesuit

Posted
Posted

@blowfish, I too have a MM question for the B9_TANK_TYPE.

Is it possible to remove them with module manager? I am setting up my own configs for Extraplanetary Launchpads, but I keep having the conflicts with the EL vanilla resources that aren't used as I don't have CRP installed either.

I tried this morning with variations on: 

!B9_TANK_TYPE[SSPXMetalOre] {}

I use this alongside removed the B9 modules from the containers as well, 

@PART[sspx-cargo-container*]
    {	!MODULE[ModuleB9PartSwitch] {}
	}

as an example, but it didn't seem to work.  The container patch works fine and ready to put in my own tank types etc, but I'm uncertain whether I can (or need a different work around like having but hiding unused resources and just removing any mention of them from elsewhere).

Thanks!

 

Link to comment
Share on other sites
blowfish

blowfish

Posted
Posted
2 hours ago, theJesuit said:

@blowfish, I too have a MM question for the B9_TANK_TYPE.

Is it possible to remove them with module manager? I am setting up my own configs for Extraplanetary Launchpads, but I keep having the conflicts with the EL vanilla resources that aren't used as I don't have CRP installed either.

I tried this morning with variations on: 


!B9_TANK_TYPE[SSPXMetalOre] {}

I use this alongside removed the B9 modules from the containers as well, 


@PART[sspx-cargo-container*]
    {	!MODULE[ModuleB9PartSwitch] {}
	}	

as an example, but it didn't seem to work.  The container patch works fine and ready to put in my own tank types etc, but I'm uncertain whether I can (or need a different work around like having but hiding unused resources and just removing any mention of them from elsewhere).

Thanks!

 

Sorry, exactly which piece isn't having the intended result.  Also unused B9_TANK_TYPE entries won't really affect anything.

Link to comment
Share on other sites
theJesuit

theJesuit

Posted
Posted
6 hours ago, blowfish said:

Sorry, exactly which piece isn't having the intended result.  Also unused B9_TANK_TYPE entries won't really affect anything.

Your advice did work wonders, and a day at work gave me a chance to reflect and come back with fresh eyes!  Got it sorted.

I was  actually trying to be clever and do  

!B9_TANK_TYPE[SSPX*] {}

instead.  Which wasn't working - knocking the EPL resources out sorted it!

Thanks and Peace!

Link to comment
Share on other sites
Gordon Dry

Gordon Dry

Posted
Posted (edited)

@blowfish I tried to find good examples how to use indices, but besides the MM syntax wiki page I didn't find anything worthy...

I try to check for all parts with ModuleEngines* and ModuleRCS* which also have the propellant ElectricCharge, then add a module.

I tried variants of this: 

// ionized gas propelled engines need EC
@PART[*]:HAS[@MODULE[ModuleEngines*]:HAS[@PROPELLANT[ElectricCharge],*]]:AFTER[Kerbalism]
{
  MODULE
  {
    name = PlannerController
  }
}

// ionized gas propelled RCS thrusters also need EC
@PART[*]:HAS[@MODULE[ModuleRCS*]:HAS[@PROPELLANT[ElectricCharge],*]]:AFTER[Kerbalism]
{
  MODULE
  {
    name = PlannerController
  }
}

And this: 

// ionized gas propelled engines need EC
@PART[*]:HAS[@MODULE[ModuleEngines*]:HAS[@PROPELLANT[*]:HAS[#name[ElectricCharge]]],*]:AFTER[Kerbalism]
{
  MODULE
  {
    name = PlannerController
  }
}

// ionized gas propelled RCS thrusters also need EC
@PART[*]:HAS[@MODULE[ModuleRCS*]:HAS[@PROPELLANT[*]:HAS[#name[ElectricCharge]]],*]:AFTER[Kerbalism]
{
  MODULE
  {
    name = PlannerController
  }
}

I tried moving the ,* to one side of a bracket or the other etc. pp.

Because of engines or RCS thrusters that also use ElectricCharge as a 2nd propellant, I try it with the index...
This patch should be as generic as possible to avoid overlooking parts where the propellant ElectricCharge is not on the 2nd position or even parts with more than 2 propellants in total incl. EC.

Edited by Gordon Dry
Link to comment
Share on other sites
blowfish

blowfish

Posted
Posted

@Gordon Dry you can't use indices in a HAS clause.  I'm confused about your use case though ... :HAS[@PROPELLANT[ElectricCharge]] will be true for anything that has any PROPELLANT node with name = ElectricCharge, it does not have to be the first one.  So why does the position matter at all?  And why would you want to rely on things being in a particular order?

Link to comment
Share on other sites
Apaseall

Apaseall

Posted
Posted

I thought I would post this here;

Spoiler

@PART[CT250?]:HAS[@MODULE[InterstellarResourceConverter]]:NEEDS[InterstellarFuelSwitch]:FINAL

{
    @MODULE[InterstellarResourceConverter]:HAS[#primaryResourceNames[LqdXenon]]
    {
        %MYMMmaxPowerMul = 10        // create variable my_mm maxPower Multiplier 1.0 = same as stock IFS

        @maxPowerPrimary *= #$MYMMmaxPowerMul$
        @maxPowerSecondary *= #$MYMMmaxPowerMul$
        
        !MYMMmaxPowerMul            // delete variable
    }
}

 

Why?

Well after reading the available docs and 38 pages of this thread I just winged it and hoped.

Please Please update the docs with an example of nested :HAS.

Also and example with multiple instances of the same module name within a part, where like above only a key pair within those modules differentiates them.

Yes I was patient up to a point, hope you will make the changes so that others will have a shorter hunt.

Thanks.

Oh yes, the code is tested and works.

Link to comment
Share on other sites
Gordon Dry

Gordon Dry

Posted
Posted

And again - :wacko: this patch does not apply: 

@PART[*]:HAS[@MODULE[ModuleScienceExperiment]]:NEEDS[Bluedog_DB]:AFTER[Kerbalism]
{
  @MODULE[ModuleScienceExperiment]:HAS[#experimentID[bd?GeigerCounter]]
  {
    @experimentID = geigerCounter
    @experimentActionName = Log Radiation Data
    @resetActionName = Discard Radiation Data
    @reviewActionName = Review Radiation Data
    @dataIsCollectable = True
    @collectActionName = Take Data
    @usageReqMaskInternal = 1
    @usageReqMaskExternal = -1
  }

  MODULE
  {
    name = Sensor
    type = radiation
	pin = pinanim
  }
}

The original experimentID is bd_GeigerCounter, which also does not apply.

Is a ? not allowed in a HAS with a # in it?
And a _ is even not allowed, so this part CAN NOT be patched as long as the experimentID is not renamed in the original config?

Link to comment
Share on other sites
Apaseall

Apaseall

Posted
Posted

Hi folks. I am looking for some guidance with how to handle variables.

I have this patch;

Spoiler

// ----------------------------------------------------------- MM Patched Here ----------------------------------------------------------------------------------------------

// This patch adds changes the rate at which a liquid turns into a gas in IFS Cryogenic Tanks
//        needs to run after InterstellarFuelSwitch as it alters parts created by it
//        InterstellarFuelSwitch runs at some point

@PART[CT250?]:HAS[@MODULE[InterstellarResourceConverter]]:NEEDS[InterstellarFuelSwitch]:AFTER[WildBlueTools]
{
    @MODULE[InterstellarResourceConverter]:HAS[#primaryResourceNames[LqdXenon]]
    {
        %MYMMmaxPowerMul = 1000        // create variable my_mm maxPower Multiplier 1.0 = same as stock IFS

        @maxPowerPrimary *= #$MYMMmaxPowerMul$
        @maxPowerSecondary *= #$MYMMmaxPowerMul$
    }
}
@PART[CT250?]:HAS[@MODULE[InterstellarResourceConverter]]:NEEDS[InterstellarFuelSwitch]:AFTER[WildBlueTools]
{
    @MODULE[InterstellarResourceConverter]:HAS[#primaryResourceNames[LqdXenon]]
    {
        !MYMMmaxPowerMul            // delete variable
    }
}


// ----------------------------------------------------------- Just Notes Below Here ----------------------------------------------------------------------------------------
// Notes    MODULE
// Notes        {
// Notes            name = InterstellarResourceConverter
// Notes            primaryResourceNames = LqdXenon
// Notes            secondaryResourceNames = XenonGas
// Notes            maxPowerPrimary = 10
// Notes            maxPowerSecondary = 10
// Notes            primaryConversionEnergyCost = 95.586
// Notes            secondaryConversionEnergyCost = 17.2958 // 108.099 * 0.16
// Notes        }
// Notes
// Notes    :FINAL is a cop out and should be avoided if possible
// Notes    :AFTER[InterstellarFuelSwitch] ? Do we need to wait for anything else to act upon IFS before this patch?
// Notes    :AFTER[WildBlueTools] Assuming any WBI mod is installed, WildBlueTools is processed near the end of the mod processing list

The present problem is that MYMMmaxPowerMul is present in ModuleManager.ConfigCache

I am wondering why that is?

Another question is, if I move the creation of MYMMmaxPowerMul up one node, like;

Spoiler

@PART[CT250?]:HAS[@MODULE[InterstellarResourceConverter]]:NEEDS[InterstellarFuelSwitch]:AFTER[WildBlueTools]

{

    %MYMMmaxPowerMul = 1000        // create variable my_mm maxPower Multiplier 1.0 = same as stock IFS

    @MODULE[InterstellarResourceConverter]:HAS[#primaryResourceNames[LqdXenon]]
    {
        @maxPowerPrimary *= #$MYMMmaxPowerMul$
        @maxPowerSecondary *= #$MYMMmaxPowerMul$
    }
}
@PART[CT250?]:HAS[@MODULE[InterstellarResourceConverter]]:NEEDS[InterstellarFuelSwitch]:AFTER[WildBlueTools]
{
        !MYMMmaxPowerMul            // delete variable
}

Would creating MYMMmaxPowerMul in such a place allow the variable to be used in the sub node? Or is it bound into the node level it was created in?

I am considering moving the variable to such a place, because I may wish to use the conversion factor for more that just XenonGas. This is not critical for the moment and I am quite happy to expand out the code on a case by case basis for any additional gas conversion rates that I wish to change.

I want to avoid using :FINAL as a means of forcing the deletion, is :FINAL the only way to ensure the variable is removed.

Does anyone have some helpful comments that can share?

 

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