Jump to content

[1.8.x-1.10.x] Module Manager 4.1.4 (July 7th 2020) - Locked inside edition


Recommended Posts

Hi!

How can I use specific values from atmosphereCurve? Like get second value from the key where fist value=0.

I want to do something like this:

%minThrust = #$maxThrust$
@minThrust *= #$atmosphereCurve[key,0[1, ]]$
@minThrust /= #$atmosphereCurve[key,1[1, ]]$

(derive engine minThrust from its Isp drop, so vaccuum engines become more throttleable than lifter engines)

Link to post
Share on other sites

Been trying to find an example of a MM patch that will target a specific module if the part has multiple copies of the same module.  I want to reduce the gimbal on a part that has this.  

	MODULE
	{
		name = ModuleGimbal
		gimbalTransformName = EngineGimbal_L
		gimbalRange = 20
		useGimbalResponseSpeed = true
		gimbalResponseSpeed = 6
	}

	MODULE
	{
		name = ModuleGimbal
		gimbalTransformName = EngineGimbal_R
		gimbalRange = 20
		useGimbalResponseSpeed = true
		gimbalResponseSpeed = 6
	}

I tried a few things, but all I can get is the first one to change. 

 

Link to post
Share on other sites
54 minutes ago, eberkain said:

Been trying to find an example of a MM patch that will target a specific module if the part has multiple copies of the same module.  I want to reduce the gimbal on a part that has this.  

Spoiler

	MODULE
	{
		name = ModuleGimbal
		gimbalTransformName = EngineGimbal_L
		gimbalRange = 20
		useGimbalResponseSpeed = true
		gimbalResponseSpeed = 6
	}

	MODULE
	{
		name = ModuleGimbal
		gimbalTransformName = EngineGimbal_R
		gimbalRange = 20
		useGimbalResponseSpeed = true
		gimbalResponseSpeed = 6
	}

I tried a few things, but all I can get is the first one to change. 

@PART
{
    @MODULE[ModuleGimbal],*
    {
    	@gimbalRange /= 2
    }
}

 

On 1/12/2018 at 2:01 PM, Psycho_zs said:

Hi!

How can I use specific values from atmosphereCurve? Like get second value from the key where fist value=0.

I want to do something like this:

%minThrust = #$maxThrust$
@minThrust *= #$atmosphereCurve[key,0[1, ]]$
@minThrust /= #$atmosphereCurve[key,1[1, ]]$

(derive engine minThrust from its Isp drop, so vaccuum engines become more throttleable than lifter engines)

You're close.  I think you need

#$atmosphereCurve/key,0[1, ]$

On 1/12/2018 at 6:16 AM, Citizen247 said:

Is it possible to use a variable to control whether a patch is applied?

If so, how?

Assign the variable to some value, then check for the value later in a :HAS block

Link to post
Share on other sites
5 hours ago, blowfish said:

You're close.  I think you need

#$atmosphereCurve/key,0[1, ]$

Thanks! So, will this line get the key by it's first value (0) or by key's position (0)? I've looked at the configs in my GameData, key 0 comes first everywhere, but is it safe to assume that?

Link to post
Share on other sites
1 minute ago, Psycho_zs said:

Thanks! So, will this line get the key by it's first value (0) or by key's position (0)? I've looked at the configs in my GameData, key 0 comes first everywhere, but is it safe to assume that?

key,x refers to the xth key value in the node (where x is 0-indexed)

Link to post
Share on other sites
3 hours ago, blowfish said:

key,x refers to the xth key value in the node (where x is 0-indexed)

Is there a way to extract second value by first value, not by position, or is that an overkill? I mean, in case some mod somewhere assigns the curve positionally backwards:

atmosphereCurve {
  key 1 290
  key 0 315
}

or has more keys in the curve:

atmosphereCurve {
  key 0 315
  key 0.5 301
  key 1 290
}

#$atmosphereCurve/key,1[1, ]$ would return undesired data.

Link to post
Share on other sites

Unsure how to do this, I'm trying to add onto the possible things to switch to in FSFuelswitch. Specifically adding ExoticMinerals and RareMetals in the USI Kontainer parts that have both an FSFuelswitch and an FSTextureSwitch2 that needs them added onto the end, but I'm not good at this kind of stuff.

Edited by Crimor
Link to post
Share on other sites
8 hours ago, Psycho_zs said:

Is there a way to extract second value by first value, not by position, or is that an overkill? I mean, in case some mod somewhere assigns the curve positionally backwards:

or has more keys in the curve:

#$atmosphereCurve/key,1[1, ]$ would return undesired data.

I don't think so, unfortunately.

Link to post
Share on other sites

If I can not extract by value, then I will just filter out potential weird curves.

How do I use a curve value in selector? With a second set of brackets for value?

@PART[*]:HAS[@MODULE[ModuleEngines*]:HAS[@PROPELLANT[Oxidizer],#minThrust[0],#atmosphereCurve/key,0[0, ][0],#atmosphereCurve/key,1[0, ][1]]]:FINAL

 

Link to post
Share on other sites
6 minutes ago, Psycho_zs said:

If I can not extract by value, then I will just filter out potential weird curves.

How do I use a curve value in selector? With a second set of brackets for value?

@PART[*]:HAS[@MODULE[ModuleEngines*]:HAS[@PROPELLANT[Oxidizer],#minThrust[0],#atmosphereCurve/key,0[0, ][0],#atmosphereCurve/key,1[0, ][1]]]:FINAL

 

You also can't index a multipart value in a :HAS block (you can however assign what you want to another value and then check it later.

Link to post
Share on other sites
48 minutes ago, blowfish said:

you can however assign what you want to another value and then check it later

A nested selector then, something like that?

@PART[*]:HAS[@MODULE[ModuleEngines*]:HAS[@PROPELLANT[Oxidizer],#minThrust[0]]]:FINAL {
	vacKey = #$atmosphereCurve/0,[0, ]$
	seaKey = #$atmosphereCurve/1,[0, ]$
	@MODULE[ModuleEngines*]:HAS[#../vacKey[0],#../seaKey[1]] {
		...
	}
}

 

Edited by Psycho_zs
Link to post
Share on other sites
8 hours ago, Psycho_zs said:

A nested selector then, something like that?

@PART[*]:HAS[@MODULE[ModuleEngines*]:HAS[@PROPELLANT[Oxidizer],#minThrust[0]]]:FINAL {
	vacKey = #$atmosphereCurve/0,[0, ]$
	seaKey = #$atmosphereCurve/1,[0, ]$
	@MODULE[ModuleEngines*]:HAS[#../vacKey[0],#../seaKey[1]] {
		...
	}
}

 

It would have to be a separate patch (or you could assign the keys within ModuleEngines and then have another @MODULE that checks for them).

Link to post
Share on other sites

Hi Guys, This has certainly been said/posted elsewhere, but I could not find it:
I'm on KSP 1.2.2 (RSS/RO/RP-0) so MM 2.8. Work is being done to migrate all that to KSP 1.3.1.
I'm looking for a reference of all syntax changes between MM 2.8 and 3.0.1, do you know where I could find that?

Edited by Garlik
duplicates
Link to post
Share on other sites
4 hours ago, Garlik said:

Thanks! I Of course know the wiki, but it does not seem to hold a page of the exact changes on 3.0+
since we have tens (if not hundreds) of .cfg to edit, I 'need' to at least know exactly what I am searching for, I want to automate these script updates

Then there is this at the bottom of the OP:

Changes :

- merged with my wildcard extension

- add a "~" operator to check for missing properties

- let you use wildcard search in other part than the name of the part

- let you patch other things than PART (this was working with MM but not with MMExt)

- handle badly formatted cfg file better

- include Majiir workaround for KSPAddon bug

- a bit more verbose and all log line start with [ModuleManager] to make search easier

- you can have multiple MM dll installed in the root of gamedata, only the newest will run

- a special tag allow excluding MM from processing a folder

- % operator for value and node that edit if the value/node is present and add it its not

- $ operator that duplicate it (It does not work for a root node, ie a PART)

- @NODENAME,2 {} let you select the third node of that name. Be careful when you delete or add a node as the index will change.

Todo :

- re-apply patch when you reload the database from the debug menu. It's quite a useful feature but won't change much for mod use.

No promise for this. I had something working but it failed at the second reload. KSP code makes this quite hard. I may take the easy way out and just add a button.

Then there is this:

- a special tag allow excluding MM from processing a folder

I would love to know more about.

Link to post
Share on other sites
10 hours ago, Garlik said:

Thanks! I Of course know the wiki, but it does not seem to hold a page of the exact changes on 3.0+
since we have tens (if not hundreds) of .cfg to edit, I 'need' to at least know exactly what I am searching for, I want to automate these script updates

3.0 did not change the syntax. The parser now strictly follow the documentation. Patch that used bad syntax that where somehow parsed by the old MJ are now rejected. The log wll tell you what is wrong and the last few page documents the more common "wrongs".

Link to post
Share on other sites

I have a simple script that worked under 2.8.1 but doesn't work under 3.0.1. I'm testing within a completely fresh game with no other mods. If I run with MM 2.8.1 it works, if I update to 3.0.1 it doesn't work. It's supposed to increase the science return to 100% the possible return rather than just a portion of it.

@EXPERIMENT_DEFINITION[*]
{
    %baseValue = #$scienceCap$
}
 

I also tried a version that targets a discreet experiment as shown below and that doesn't work anymore either:

 

@EXPERIMENT_DEFINITION[*]:HAS[#id[mysteryGoo]]
{
    @baseValue = 10
    @scienceCap = 10
}

 

Any advice?

Edited by Tyko
Link to post
Share on other sites
11 minutes ago, Tyko said:

I have a simple script that worked under 2.8.1 but doesn't work under 3.0.1. I'm testing within a completely fresh game with no other mods. If I run with MM 2.8.1 it works, if I update to 3.0.1 it doesn't work. It's supposed to increase the science return to 100% the possible return rather than just a portion of it.

@EXPERIMENT_DEFINITION[*]
{
    %baseValue = #$scienceCap$
}
 

I also tried a version that targets a discreet experiment as shown below and that doesn't work anymore either:

 

@EXPERIMENT_DEFINITION[*]:HAS[#id[mysteryGoo]]
{
    @baseValue = 10
    @scienceCap = 10
}

 

Any advice?

I don’t think you need [*] anymore 

Link to post
Share on other sites

So, I'm delving into the deeeeeep end of MM and that means maths.

USI Sounding Rockets (the Aerobee series) specifies entryCost = 0.  I want to modify all SR_* items to reflect an entryCost equal to 3x the cost value of the part (Squad standard).

This?

@PART[SR_Payload_*]
{
    %entryCost = cost * 3
}

Link to post
Share on other sites

Trying to remove tweakscale from all engines, except SRBs, just not getting it.  I anyone could tweak this to make it work I would be grateful.   

@PART[*]:HAS[@MODULE[ModuleEngines*]]:HAS[!RESOURCE[SolidFuel]]:FINAL 
{
    !MODULE[TweakScale] {}
}

 

Link to post
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.

×
×
  • Create New...