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

[Kowgan]

I created a Module Manager Handbook page on the MM wiki, mostly based on the first page of this thread. It covers most basics, but it got quite big, and I can't find a proper place to split it into two different pages. So I threw it all there.

I'll start making the Math part and follow-ups on a separate page. I'd like to ask someone to review it and point or fix any errors found. Thanks.

[Starwaster]

Looks good, but minor gripe (No, not a gripe, a nitpick and one I'm guilty of myself occasionally)

What are being referred to as Variables should more properly be referred to as Fields because that's what they're generally being loaded as in the actual code.

Edit clarification: Only referring to usage of term Variable in the recent pages, not the MM variables as described here: http://forum.kerbalspaceprogram.com/threads/55219-Module-Manager-2-3-5-%28Sept-14%29-Loading-Speed-Fix?p=1416253&viewfull=1#post1416253

Edited January 14, 2015 by Starwaster

[Kowgan]

Thanks for pointing. Though, I took that name from Sarbian's first posts in this thread. I'll leave it like this until he agrees that this should be changed.

Post on how to use variable in MM

foo = <value> creates a new variable called 'foo'(...)

Edit clarification: I don't get it.

Edited January 14, 2015 by Kowgan

[sarbian]

Use field. What I now call variable was not in MM at that time and it will make things easier to use a different name.

Edit : well ... technicaly the game call them value so we could use that.

[Crzyrndm]

Edit : well ... technicaly the game call them value so we could use that.

Value to me implies whatever follows an '=' sign (ie. One "field" == "key = value"). Using it to refer to the full entry would be rather confusing

[Kowgan]

Value to me implies whatever follows an '=' sign (ie. One "field" == "key = value"). Using it to refer to the full entry would be rather confusing

Agreed. 'Value' seems way more confusing than 'variable' for profane programmers like me.

[drtedastro]

Hello to all.

Did anyone have a chance to look at logs (post #2042)?

I just want to see where I missed it telling 'which' part or file was the error.

thanks for any help...

Cheers.

[sarbian]

Sorry I forgot about it.

[ModuleManager] Skipping a patch with unbalanced square brackets or a space (replace them with a '?') :
@PART[XSMALL

So search for the line that starts with @PART[XSMALL in the cfg. I guess you ll find a space.

[NathanKell]

While they should be considered key/value pairs, in KSP's code both sides are called a value, i.e ConfigNode.Value is the pair and ConfigNode.Value.name and ConfigNode.Value.value are the two sides.

Oy.

I would suggest we call them key/value pairs, but if y'all want to say 'field', why not.

[Kowgan]

"ConfigNode.Value.value"

With all due respect, this sounds ridiculously funny.

"Key" sounds good enough. But since it's Sarbian's mod, I'll keep it as "field", until he says otherwise.

Thanks for the info.

[sarbian]

let s go for key.

[nightingale]

Got a new one for you guys. I have the following MM config:

@CONTRACT_TYPE
[*]
{
    @PARAMETER
[*]
    {
        @PARAMETER[Orbit]
        {
            @minPeA *= 6.4
        }
    }
}

Acting on the following config node data, gives the following results:

[TABLE=width: 0]

[TR]

[TD]Before[/TD]

[TD]After[/TD]

[/TR]

[TR]

[TD]

CONTRACT_TYPE:NEEDS[RemoteTech]
{
    name = MM_TEST
    PARAMETER
    {
        name = CommSat1
        PARAMETER
        {
            name = Orbit
            minPeA = [COLOR=#ff0000]600000[/COLOR]
        }
    }    
    PARAMETER
    {
        name = CommSat2
        PARAMETER
        {
            name = Orbit
            minPeA = [COLOR=#ff0000]600000[/COLOR]
        }
    }    
}

[/TD]

[TD]

CONTRACT_TYPE
{
    name = MM_TEST
    PARAMETER
    {
        name = CommSat1
        PARAMETER
        {
            name = Orbit
            minPeA = [COLOR=#ff0000]3840000[/COLOR]
        }
    }
    PARAMETER
    {
        name = CommSat2
        PARAMETER
        {
            name = Orbit
            minPeA = [COLOR=#ff0000]600000[/COLOR]
        }
    }
}

[/TD]

[/TR]

[/TABLE]

I was expecting it to modify both the CommSat1 and CommSat2 nodes, but CommSat2 remained untouched. Is this a bug? If you want to see the full configurations (significantly bigger, I reduced it down to the bare minimum to show the problem):

• Module Manager Config
  
• Config File
  

Also, the Orbit Parameter node could hypothetically be directly under CONTRACT_TYPE, under one PARAMETER parent, under two, etc.... How much effort would be involved in getting some new form of "search" that'll traverse recursively down into children looking for the given node? In other words, instead of the above config, I would've liked to have written something like this:

@CONTRACT_TYPE
[*]
{
    @PARAMETER[Orbit]:TRAVERSE
    {
        @minPeA *= 6.4
    }
}

Which would match CONTRACT_TYPE/PARAMETER[Orbit], CONTRACT_TYPE/PARAMETER/PARAMETER[Orbit], CONTRACT_TYPE/foo/PARAMETER[Orbit]. (I couldn't think of a better name than "TRAVERSE", but you get the idea).

[NathanKell]

@PARAMETER[*],*

The first to say 'match any' and the ,* to say 'match all nodes that meet this filter.'

[Kowgan]

How much effort would be involved in getting some new form of "search" that'll traverse recursively down into children looking for the given node?

Impossible. This would break the mod.

If I had:

PART
{
    [COLOR=#0000ff]PARAMETER[/COLOR]
    [COLOR=#0000ff]{[/COLOR]
        [COLOR=#0000ff]name = Orbit [/COLOR]
    [COLOR=#0000ff]}[/COLOR]

    PARAMETER
    {
        name = Surface
        [COLOR=#008000]PARAMETER[/COLOR]
        [COLOR=#008000]{[/COLOR]
            [COLOR=#008000]name = Orbit[/COLOR]
        [COLOR=#008000]}[/COLOR]
    }
}

... and wished to edit only the blue one, it would be impossible, or would require me adding unnecessary ",numbers".

Edited January 16, 2015 by Kowgan

[tjsnh]

What is the easiest way to totally disable a part, using modulemanager?

[sarbian]

Reading the answer I posted to your other post ?

[nightingale]

@PARAMETER

[*],*

The first to say 'match any' and the ,* to say 'match all nodes that meet this filter.'

Ah, thank you, can't believe I missed that in the documentation post!

Impossible. This would break the mod.

If I had:

PART
{
    [COLOR=#0000ff]PARAMETER[/COLOR]
    [COLOR=#0000ff]{[/COLOR]
        [COLOR=#0000ff]name = Orbit [/COLOR]
    [COLOR=#0000ff]}[/COLOR]

    PARAMETER
    {
        name = Surface
        [COLOR=#008000]PARAMETER[/COLOR]
        [COLOR=#008000]{[/COLOR]
            [COLOR=#008000]name = Orbit[/COLOR]
        [COLOR=#008000]}[/COLOR]
    }
}

... and wished to edit only the blue one, it would be impossible, or would require me adding unnecessary ",numbers".

That hardly seems mod-breaking. I'd argue that if you only want to edit the blue one in your example, then you have enough information about the structure of config you're expecting that you really don't want to be using a deep search, or you can use a HAS[] block to filter out what you don't want.

Regarding my initial suggestion, given that ,* is the operator for "apply to all nodes", then I would suggest ,** as the one that "applies to all nodes at any depth":

CONTRACT_TYPE
[*]
{
    @PARAMETER[Orbit],**
    {
        @minPeA *= 6.4
    }
}

[sarbian]

That hardly seems mod-breaking. I'd argue that if you only want to edit the blue one in your example, then you have enough information about the structure of config you're expecting that you really don't want to be using a deep search, or you can use a HAS[] block to filter out what you don't want.

It would make it harder to predict the result outside the mods it was written for. I won't add more entropy to the fine art of MM patching.

[Eddie Rod]

Nvmd I got it all taken care of.

Edited January 17, 2015 by Eddie Rod
Fixed the issue myself

[NathanKell]

nightingale: It's confusing because one does *not* have to do @PART[*],* (sarbian? insight?)

[Gribbleshnibit8]

Decided to give the Stock Part Revamp mod a look and I really like a lot of the new changes, but not all the new changes. Since that mod uses one giant MM file to change everything, it's not possible to write a quick batch file to just remove the edits I want. I'd prefer to not have to edit the file itself, for compatibility reasons with updating, so my question is:

Is it possible to stop a modification of another MM patch before that patch happens?

I'm going to guess no, since that mostly would defeat the purpose of MM, so I think I'll plan to just copy all the parts that I don't want changed into a new MM and just add :FINAL to them to revert the changes.

EDIT:

Also, how would one go about disabling or such any part added with the copy operators?

Edited January 17, 2015 by Gribbleshnibit8

[Kowgan]

@Gribbleshnibit8: Take a look at this. It should answer most of your questions about MM usage.

In short, you can create a MM patch using a :Final suffix to apply your changes after the mod's changes. So you can put things back the way you want them.

[sarbian]

A couple of days ago I activated the Nvidia ShadowPlay FPS counter on my PC. So I had the frame rate displayed while loading KSP and seeing it caped at 60fps (I have VSync On) that reminded me that the game loading use co-routine and so loads only 1 item per frame. So no more than 60 items per seconds on my PC.

So I had an idea : disabling vsync while in the loading screen and setting it back to the user setting when the game reach the menu. It worked fine and my stock Dev KSP loaded about 10s faster (from about 48s to 37s). A nice improvement for 6 lines of code.

This morning I had to launch KSP a bit more than usual while struggling with some MJ code. I had not converted that install textures to DDS since 0.90, so to make things a bit faster I did it. And I launched with the new MM code that disable vsync.

KSP loaded in 13s

So I guess some may want this

Module Manager 2.5.9. The only change is the vsync disabling in the loading screen.

ModuleManager.2.5.9.dll

ModuleManager-2.5.9.zip

[smjjames]

Is it okay if I grab the newer version of module manager even though the mods that I have don't use it yet? I mean, will it screw anything up?

[sarbian]

It's ok. The mods won't see the difference. Delete the old MM and install the new one.