Jump to content

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


sarbian

Recommended Posts

1 hour ago, Psycho_zs said:

That's what I ended up with for now:

An interesting problem. I couldn't find a solution to filter the same key for various exact matches, so I came up with a patch that adds a new key with identical values for all matches:

@PART[*]:HAS[@MODULE[ModuleDockingNode]:HAS[#nodeType[size?]]]:BEFORE[stockSizeDockingPortPatch]
{
	@MODULE[ModuleDockingNode]:HAS[#nodeType[size0]],*{stockSizeDockingPort = true}
	@MODULE[ModuleDockingNode]:HAS[#nodeType[size1]],*{stockSizeDockingPort = true}
	@MODULE[ModuleDockingNode]:HAS[#nodeType[size2]],*{stockSizeDockingPort = true}
}
@PART[*]:HAS[@MODULE[ModuleDockingNode]:HAS[#stockSizeDockingPort[true]]]:FOR[stockSizeDockingPortPatch]
{
	@MODULE[ModuleDockingNode],*
	{
		// If you want X degrees wide margin, use cos(0.5*X) as captureMinRollDot
		// 0.5 degrees = 0.99999048
		// 1 degree    = 0.99996192
		// 2 degrees   = 0.9998477
		// 3 degrees   = 0.99965732
		// 5 degrees   = 0.99904822

		%captureMinRollDot:NEEDS[!DockRotate] = 0.99996192

		// more relaxed version to use with DockRotate
		%captureMinRollDot:NEEDS[DockRotate] = 0.99904822

		%snapRotation = true
		%snapOffset = 30
	}
}
@PART[*]:HAS[@MODULE[ModuleDockingNode]:HAS[#stockSizeDockingPort[*]]]:FINAL
{
	@MODULE[ModuleDockingNode],*{!stockSizeDockingPort = true}
}

( stockSizeDockingPort is key I made up, not a real one.)

I'd really like to see a more elegant solution.

Link to comment
Share on other sites

Or does not work in a :HAS block (only a :NEEDS block)

It's something I would like to work on eventually, but the code is not currently in a state where I would feel comfortable making that change without potentially breaking something else.

Edited by blowfish
Link to comment
Share on other sites

1 hour ago, blowfish said:

Or does not work in a :HAS block (only a :NEEDS block)

It's something I would like to work on eventually, but the code is not currently in a state where I would feel comfortable making that change without potentially breaking something else.

Interesting. Well thanks for the definitive answer. 

Link to comment
Share on other sites

I have an question. Say the there is a mod. Now I want to add a patch to that mod. Straight forward.

Now say the mod does something like this:

Spoiler

BLAH:NEEDS[MOD1|MOD2|MOD3|MOD4|MOD5|MOD6|MOD7]
{
    name = Foo
    name1 = value1
    name2 = value2
    name3 = value3
    name4 = value4
    name5 =
}
@BLAH[Foo]:NEEDS[MOD1|MOD2|MOD3|MOD4|MOD5|MOD6|MOD7]
{ @name5 ^= :$: name5a value5a;: }
@BLAH[Foo]:NEEDS[MOD1]
{ @name5 ^= :$: name5b value5b; name5c value5c; name5d value5d; name5e value5e;: }

 

Normally I would do something like:

Spoiler

@BLAH[Foo]
{
    %name5 ^= :$: name5f value5f; name5g value5g; name5h value5h;:
}

Now say I have MOD8?

If I have both MOD1 and MOD8 I would:

Spoiler

@BLAH[Foo]:NEEDS[originatingMOD&MOD8]:AFTER[MOD8]
{
    %name5 ^= :$: name5f value5f; name5g value5g; name5h value5h;:
}

If I do not have or cannot be sure that I have any of MOD1-7, I tried:

Spoiler

%BLAH[Foo]:NEEDS[originatingMOD&MOD8]:AFTER[MOD8]
{
    %name1 = value1
    %name2 = value2
    %name3 = value3
    %name4 = value4
    %name5 ^= :$: name5f value5f; name5g value5g; name5h value5h;:
}

Which threw me an error, "Error - replace command (%) is not valid on a root node:"

I am thinking that what I could do is test to see if BLAH[Foo] does not exist and create it.

Then I can do my @BLAH[Foo] since either BLAH[Foo] was created by originatingMOD or just now by my patch.

Does my question make sense? Am I correct in my approach to the solution? How do I write the test? Forgive me if this is something trivial, I am learning about patches but this is a new issue for me.

 

Link to comment
Share on other sites

4 minutes ago, Apaseall said:

I have an question. Say the there is a mod. Now I want to add a patch to that mod. Straight forward.

Now say the mod does something like this:

  Reveal hidden contents

BLAH:NEEDS[MOD1|MOD2|MOD3|MOD4|MOD5|MOD6|MOD7]
{
    name = Foo
    name1 = value1
    name2 = value2
    name3 = value3
    name4 = value4
    name5 =
}
@BLAH[Foo]:NEEDS[MOD1|MOD2|MOD3|MOD4|MOD5|MOD6|MOD7]
{ @name5 ^= :$: name5a value5a;: }
@BLAH[Foo]:NEEDS[MOD1]
{ @name5 ^= :$: name5b value5b; name5c value5c; name5d value5d; name5e value5e;: }

 

Normally I would do something like:

  Reveal hidden contents

@BLAH[Foo]
{
    %name5 ^= :$: name5f value5f; name5g value5g; name5h value5h;:
}

Now say I have MOD8?

If I have both MOD1 and MOD8 I would:

  Reveal hidden contents

@BLAH[Foo]:NEEDS[originatingMOD&MOD8]:AFTER[MOD8]
{
    %name5 ^= :$: name5f value5f; name5g value5g; name5h value5h;:
}

If I do not have or cannot be sure that I have any of MOD1-7, I tried:

  Hide contents

%BLAH[Foo]:NEEDS[originatingMOD&MOD8]:AFTER[MOD8]
{
    %name1 = value1
    %name2 = value2
    %name3 = value3
    %name4 = value4
    %name5 ^= :$: name5f value5f; name5g value5g; name5h value5h;:
}

Which threw me an error, "Error - replace command (%) is not valid on a root node:"

I am thinking that what I could do is test to see if BLAH[Foo] does not exist and create it.

Then I can do my @BLAH[Foo] since either BLAH[Foo] was created by originatingMOD or just now by my patch.

Does my question make sense? Am I correct in my approach to the solution? How do I write the test? Forgive me if this is something trivial, I am learning about patches but this is a new issue for me.

 

Seem that you have made a complicated case. I usually use :NEEDS to test if one or several relevant mods exist or not, depending of what I want to achieve. That way you can have a create node, and a modify node based on which case you are hitting.

Link to comment
Share on other sites

Thanks for the reply @Warezcrawler

hmm I immediately thought something like:

Spoiler

BLAH[Foo]:NEEDS[originatingMOD&!MOD1|!MOD2|!MOD3|!MOD4|!MOD5|!MOD6|!MOD7]

But I doubt if that will work as it wants to manipulate BLAH[Foo].

I wonder if I can move up a step like:

Spoiler

originatingMOD[BLAH]:HAS[!Foo]:NEEDS[originatingMOD]
{
    BLAH
    {
        name = Foo
        name1 = value1
        name2 = value2
        name3 = value3
        name4 = value4
        name5 =
    }
}

Any ideas on if that would work? Currently in the game I want to mod, so cannot or don't want to test it ASAP lol.

Link to comment
Share on other sites

To answer my own question, read back a few posts, this appears to be the solution:

Spoiler

@originatingMOD:HAS[!BLAH[Foo]]:NEEDS[originatingMOD&MOD8]:AFTER[MOD8]
{
    BLAH
    {
        name = Foo
        name1 = value1
        name2 = value2
        name3 = value3
        name5 =
    }
}

@BLAH[Foo]:NEEDS[originatingMOD&MOD8]:AFTER[MOD8]
{
    @name5 ^= :$: name5f value5f; name5g value5g; name5h value5h;:
}

 

The original question goes something like this;

How to write a patch to add additional name value pairs to name5. In this case I am adding support for MOD8 which did not exist or was not supported when originatingMOD was written/updated. I do not want to bother the originatingMOD author, hence writing my own patch.

The problem is that in the originatingMOD the node BLAH[Foo] is only created if its own :NEEDS are satisfied. Again MOD8 is not tested in originatingMOD, so BLAH[Foo] is not created for MOD8.

Thus depending on which other mods were present, when my patch runs there may or may not be BLAH[Foo].

My solution is to check if BLAH[Foo] exists, create it if it does not and then add the additional name value pairs to name5.

The observant will note that this is not a PART. No dll for originatingMOD exists. :FOR is not used in the originatingMOD. BLAH only exists in terms of BLAH[something1], BLAH[something2] etc. BLAH is not a sub node, other than being a .cfg file named BLAHs in the folder originatingMOD.

For the curious, here is the ModuleManager.ConfigCache entry:

Spoiler

UrlConfig
{
    name = Foo
    type = BLAH
    parentUrl = originatingMOD/BLAHs
    BLAH
    {
        name = Foo
        name1 = value1
        name2 = value2
        name3 = value3
        name5 = name5f value5f; name5g value5g; name5h value5h;:
    }
}

This appears to be of the same format and structure of the preexisting unmodified entries for other BLAH[something1], BLAH[something2] etc.

Feel free to tell me if I am making an incorrect assumption, going about this in an inappropriate way or anything else.

Edited by Apaseall
Link to comment
Share on other sites

On 02.04.2018 at 2:10 PM, sarbian said:

Hi friends! I play on 1.3.1 with 130mods and MM-2.8.1. I some mods updated, and in archive i find new MM-3.0.4. If i used this new version, on load screen module manages show errors.

Is this mean, all installed mods, for correct working, needs updated for MM-3.0.4?

Link to comment
Share on other sites

13 minutes ago, nickicool said:

Hi friends! I play on 1.3.1 with 130mods and MM-2.8.1. I some mods updated, and in archive i find new MM-3.0.4. If i used this new version, on load screen module manages show errors.

Is this mean, all installed mods, for correct working, needs updated for MM-3.0.4?

The entire time, MM has been quiet about bad syntax. From 3.0, MM stopped being quiet. That's all. The modding community particularly needs a siren to blow at it for the misuse or :FOR, :sticktongue: and attempts to use :BEFORE and :AFTER in the same patch config.

Link to comment
Share on other sites

4 hours ago, JadeOfMaar said:

The entire time, MM has been quiet about bad syntax. From 3.0, MM stopped being quiet. That's all. The modding community particularly needs a siren to blow at it for the misuse or :FOR, :sticktongue: and attempts to use :BEFORE and :AFTER in the same patch config.

Are you telling me that I can not be afraid that something will stop working just because of using the MM-3.0.4 instead of the MM-2.8.1? Even if there were error messages like this? Screenshot  https://yadi.sk/i/qJKTrhuQ3U94fu

 

Link to comment
Share on other sites

3 minutes ago, nickicool said:

Are you telling me that I can not be afraid that something will stop working just because of using the MM-3.0.4 instead of the MM-2.8.1? Even if there were error messages like this? Screenshot  https://yadi.sk/i/qJKTrhuQ3U94fu

 

The errors were there in 2.8.x; you just didn't know about them.  Since you weren't afraid of what was happening in MM-2.8.x, when you didn't see the errors, you don't need to be ANY MORE afraid of the additional information revealed by MM-3.x.

Link to comment
Share on other sites

@nickicool

To put it even more bluntly than @TranceaddicT, using an older version of MM is the equivalent of burying your head in the sand and pretending the errors don't exist.

The errors are still there in 2.8 even if you don't see them.

The correct solution is for the problematic configs to be corrected. Something that wasn't possible before you knew about the errors.

Go forth now and report the errors to SETIRebalance. (check first that they aren't already aware of the problem in case it's already been fixed)

You're welcome :wink: 

Edited by Starwaster
Link to comment
Share on other sites

 

4 minutes ago, Dr Farnsworth said:

My computer is not liking the .3.0.6.dll at all.

Windows defender is saying that it has the "Trojan:Win32/Critet.BS" malware in it.

 

Please advise.

 

On 3/16/2018 at 2:59 PM, sarbian said:

Defender marked a bunch of KSP file as a virus : 

Update your definition manually and it should be gone: https://www.microsoft.com/en-us/wdsi/definitions

 

Link to comment
Share on other sites

All the custom patches I have that use @PART are working, but for some reason I can't get edits to EXPERIMENT_DEFINITION to work. For testing purposes, I've tried this and it doesn't work:

@EXPERIMENT_DEFINITION[*]:HAS[#id[temperatureScan]]:FINAL
{
	@baseValue = 4000
	@scienceCap = 4000
}

The thermometer still gives the stock science value. Any ideas?

Edited by Kwebib
Link to comment
Share on other sites

1 hour ago, Kwebib said:

All the custom patches I have that use @PART are working, but for some reason I can't get edits to EXPERIMENT_DEFINITION to work. For testing purposes, I've tried this and it doesn't work:


@EXPERIMENT_DEFINITION[*]:HAS[#id[temperatureScan]]:FINAL
{
	@baseValue = 4000
	@scienceCap = 4000
}

The thermometer still gives the stock science value. Any ideas?

Try to remove "[*]" from the patch.

Link to comment
Share on other sites

On 4/8/2018 at 3:38 PM, Dr Farnsworth said:

My computer is not liking the .3.0.6.dll at all.

Windows defender is saying that it has the "Trojan:Win32/Critet.BS" malware in it.

 

Please advise.

 

You good now? I can advise further if you need.

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.

×
×
  • Create New...