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

[funk]

Don't use FINAL in a mod. It is for users customization.

Explain your use case.

Sry, I wouldn't use FINAL in a mod. It's like I said, but replace me and FINAL, with anyone else who has his own desires/personal configs.

E.g. MKS/OKS tells its parts to use CTT technodes, MCM wants that they are unresearchable, SETI instead wants that, lets say 4 of the parts are researchable with dedicated technodes, and anyone want to use 3 of the 4 parts. I hope it's clear what I mean. Take the view of MCM pls.

Edited March 10, 2015 by funk

[futrtrubl]

Ah, ok if that is correct, that means no one can tell to @PART:wink: after mymod. It would be just :FINAL?

So what would be the correct expression, if for example mod1 tells his parts to use technodes of Community Tech Tree, but mymod tells, that's unresearchable. Now there comes SETI and want to change the technode too and I've my personal cfg with FINAL.

FINAL is not really for mod makers but for end users for their own configs.

The question is: in what order do you want those things to occur?

[funk]

FINAL is not really for mod makers but for end users for their own configs.

The question is: in what order do you want those things to occur?

yep I know, but I'm assuming to use FINAL for my own personal cfgs. Or anyonelse can do with FINAL his own personal cfgs. The order should be mod1 > mymod > mod2 > personal cfg. So how to express from the view of mymod? Mymod doesn't know mod2.

[futrtrubl]

yep I know, but I'm assuming to use FINAL for my own personal cfgs. Or anyonelse can do with FINAL his own personal cfgs. The order should be mod1 > mymod > mod2 > personal cfg. So how to express from the view of mymod? Mymod doesn't know mod2.

Then use AFTER[Mod1]

[funk]

Ok, then mod2 goes with AFTER[mymod], but how would he know that mymod is doing patches without defining FOR[mymod]

[Tarheel1999]

Ok, then mod2 goes with AFTER[mymod], but how would he know that mymod is doing patches without defining FOR[mymod]

If what you are trying to accomplish is for mymod not to run certain patches in the presence of mod2 you would use a NEEDS. Something like NEEDS[!mod2]. If you don't want mod2 to overwrite your patches it would be AFTER[mod2]. Otherwise, I'm not sure what you are looking for.

[funk]

OK, seems to be a little confusing.

1. I know the use case of FIRST,FINAL,NEEDS.

2.

I don't believe FOR and AFTER can be used together. FOR tells it to do the patch during Mymod's time while the AFTER is telling it to do it right after mod1's time.

But AFTER still runs even if mod1 is not detected. So it needs NEEDS.

As futrtrubl mentioned, there is no use case for FOR and AFTER at the same time. So my question is, how can a third mod (mod2) refer to mymod, if MM doesn't know that mymod exists, because I didn't use FOR[mymod]?

[futrtrubl]

OK, seems to be a little confusing.

1. I know the use case of FIRST,FINAL,NEEDS.

2. As futrtrubl mentioned, there is no use case for FOR and AFTER at the same time. So my question is, how can a third mod (mod2) refer to mymod, if MM doesn't know that mymod exists, because I didn't use FOR[mymod]?

Oh, you said mod2 knows nothing about mymod. In that case add a dummy config change with FOR[mymod].

[funk]

Ah, thx then I perhaps missed something. Does MM connects every config in a subfolder of Gamedata to the existing dll in that subfolder? And does this work for example if there is /gamedata/allmymods/mymod1.dll and the config is in /gamedata/allmymods/mymod1/xyz.cfg?

Edited March 10, 2015 by funk

[undercoveryankee]

Ah, thx then I perhaps missed something. Does MM connects every config in a subfolder of Gamedata to the existing dll in that subfolder?

MM generates a list of mod names from three sources:

• All loaded DLLs, regardless of their location under GameData.
  
• All direct subfolders of GameData.
  
• Any name by which a patch identifies itself in a :FOR[] clause.
  

Once it has assembled the list of mod names, it runs a set of :BEFORE, :FOR, and :AFTER passes for each mod name.

Any patch that doesn't specify :FIRST, :FINAL, :BEFORE, :FOR, or :AFTER runs in a pass called :LEGACY between :FIRST and the first :BEFORE. The location of the config file is irrelevant so that config files can be installed anywhere and you can always tell by looking which pass a patch will run in. But a folder called "MyMod" will always generate a set of BEFORE/FOR/AFTER passes for "MyMod", even if none of the config files in that folder run anything in the :FOR[MyMod] pass.

So if the list of active mods is "ModuleManager", "Foo", "Bar", "Baz", then the sequence of passes goes like:

1. :FIRST
   
2. :LEGACY
   
3. :BEFORE[ModuleManager]
   
4. :FOR[ModuleManager]
   
5. :AFTER[ModuleManager]
   
6. :BEFORE[Foo], :FOR[Foo], :AFTER[Foo]
   
7. BEFORE/FOR/AFTER[bar]
   
8. BEFORE/FOR/AFTER[baz]
   
9. :FINAL
   

If you're writing a patch that needs to run before or after a patch that comes with another mod, the first step is to inspect the patches you need to interact with and make a note of what passes they're running in. If they run in :LEGACY because they don't specify :BEFORE/:FOR/:AFTER anything, then :FIRST runs before :LEGACY and :BEFORE/:FOR/:AFTER anything at all runs after :LEGACY.

If the patch you need to come before or after specifies :FOR[something], then you can run in that mod's :BEFORE or :AFTER pass as designed. The only tricky part comes if you need to run before a patch that's already in a :BEFORE pass or after a patch that's already in an :AFTER pass. At that point, you'll need to look at the order that MM is going through mod names in the KSP log and find one of the involved mods whose :BEFORE or :AFTER pass happens at the right time.

[funk]

Big fat THX this helps a lot!

[Motokid600]

Okay... so im a linux user running KSP on Kubuntu. Games has been running perfectly up until this very moment. MM hangs up on FINAL at patch number 9960. LOTS of mods. But the game has been running exceptionallly. So.. what happened between last night and now? How can a piece of software break after having done nothing to it?

Player.log

"OutOfMemoryException" at the end of the log... what?! Lol, no.. one cannot be out of memory after having been playing the game for weeks straight with no issues. And if anytihng ive been removing mods little by little.

Another note. I was seeing a promt to update the DockingPortAlighment indicator. Never got around to doing that, yet now that prompt isnt there. So i dont what going on with that, but maybe its part of the issue here?

PS: Download links in the OP seem to be broken.

Edit: Now its hanging up on random AIES parts... same patch number. Idk...

Edit2: Removed the engines KSP hangs up on. Now the hangup is back on FINAL again. Im stuck. Cant imagine what couldve possibly happened. 9660 is nothing. I had KSP running on over 13,000 configs for awhile.

Edit3: I suspect this is relavent as well.

KSP LOG

Could KSP really be hanging up on Blackheart's fairings? Uhh.. ill try removing them, but again this is all very strange to me.

Edit4: And now the game decided to load upon the removal of those fairings... Ive been playing with them for weeks.

Edited March 10, 2015 by Motokid600

[futrtrubl]

Ah, thx then I perhaps missed something. Does MM connects every config in a subfolder of Gamedata to the existing dll in that subfolder? And does this work for example if there is /gamedata/allmymods/mymod1.dll and the config is in /gamedata/allmymods/mymod1/xyz.cfg?

if there is a mymod1.dll then you don't need to create a dummy config with FOR[mymod1] for MM to create a pass for it.

MM does no connection if the cfgs don't have FOR, BEFORE or AFTER. It doesn't need to.

[AccidentalDisassembly]

Had a question about using MM to change part stack node sizes - I figure I am doing this wrong somehow, but I can't figure out what exactly I have botched. Here's my code - it's for IR parts.

+PART[iR_Pivotron*]

{

@name ^= /$/_Large/

@title ^= /$/ - Large/

@rescaleFactor *= 4

@node_stack_top[6] = 4

@node_stack_bottom[6] = 4

@mass *= 36

MODULE

{

name = TweakScale

type = Rework_Standard

}

}

The goal is copying the part, but larger and with larger stack nodes. Everything does indeed work correctly except node sizes. Larger node sizes don't break anything if I make a new part config manually and change stack node sizes.

Using the red code, I'm trying to select the 7th entry on the node_stack_top/bottom lines (the node size entry) and change it to 4 rather than 1, which is what is copied over when the part is duplicated. I read what you wrote about the bits inside the brackets a few pages back - I thought just putting [6] meant that MM looks for the 7th comma-separated value on that line.

A typical node_stack_whatever looks like this:

node_stack_top = 0.0, 1.25, 0.0, 0.0, 1.0, 0.0, 1

When I use those lines in the MM patch, the part ceases to have any stack nodes at all. When I comment those lines out, it regains its stack nodes, but size 1.

Is something going on because the node_stack_top values are separated by commas and spaces, or something? Is there a way to edit only one of the node_stack_whatever values like I'm trying to do?

EDIT: Thought I found the problem, but neither [6] nor [7] nor [7, ] nor [7,, ] works either...

Edited March 12, 2015 by AccidentalDisassembly

[sarbian]

You need to rebuild the whole node with the variable system :

 @node_stack_top = #$node_stack_top[0]$, $var$, $node_stack_top[2]$, $node_stack_top[3]$, $node_stack_top[4]$, $node_stack_top[5]$, 4

[AccidentalDisassembly]

You need to rebuild the whole node with the variable system :

 @node_stack_top = #$node_stack_top[0]$, $var$, $node_stack_top[2]$, $node_stack_top[3]$, $node_stack_top[4]$, $node_stack_top[5]$, 4

EDIT: OK, I figure it out, nevermind all that. This may not be the most elegant, but it accomplished what I wanted:

@node_stack_top = #$node_stack_top[0]$, $node_stack_top[1]$, $node_stack_top[2]$, $node_stack_top[3]$, $node_stack_top[4]$, $node_stack_top[5]$, 4

@node_stack_bottom = #$node_stack_bottom[0]$, $node_stack_bottom[1]$, $node_stack_bottom[2]$, $node_stack_bottom[3]$, $node_stack_bottom[4]$, $node_stack_bottom[5]$, 4

@rescaleFactor *= 4

The trick was applying rescaleFactor after the fiddling with the nodes instead of before.

Edited March 12, 2015 by AccidentalDisassembly

[Net-burst]

Okay... so im a linux user running KSP on Kubuntu. Games has been running perfectly up until this very moment. MM hangs up on FINAL at patch number 9960. LOTS of mods. But the game has been running exceptionallly. So.. what happened between last night and now? How can a piece of software break after having done nothing to it?

Player.log

"OutOfMemoryException" at the end of the log... what?! Lol, no.. one cannot be out of memory after having been playing the game for weeks straight with no issues. And if anytihng ive been removing mods little by little.

Another note. I was seeing a promt to update the DockingPortAlighment indicator. Never got around to doing that, yet now that prompt isnt there. So i dont what going on with that, but maybe its part of the issue here?

PS: Download links in the OP seem to be broken.

Edit: Now its hanging up on random AIES parts... same patch number. Idk...

Edit2: Removed the engines KSP hangs up on. Now the hangup is back on FINAL again. Im stuck. Cant imagine what couldve possibly happened. 9660 is nothing. I had KSP running on over 13,000 configs for awhile.

Edit3: I suspect this is relavent as well.

KSP LOG

Could KSP really be hanging up on Blackheart's fairings? Uhh.. ill try removing them, but again this is all very strange to me.

Edit4: And now the game decided to load upon the removal of those fairings... Ive been playing with them for weeks.

http://img.pandawhale.com/87703-Mark-Wahlberg-confused-speechl-iGn8.gif

Its a bug in Texture Replacer apparently. If you have it installed, update it to at least 2.2.6.

[civilwargeeky]

Hi! I wanted to change the MKS/OKS parts so that they start with appropriate labels and are all grouped together alphabetically.

For some reason, my first two patches work, but my other two do not.

//This should prepend all MKS/OKS Parts with their proper names

//Works. (~title because some parts already start with "MKS"

@PART[MKS_*]:HAS[~title[MKS*]]:FINAL

{

@title = #MKS $/title$

}

//Works

@PART[OKS_*]:FINAL

{

@title = #OKS $/title$

}

//Does not work?

@Part[uraniumTank]:FINAL

{

@title = #OKS $/title$

}

//Does not work?

@Part[MK3_*]:FINAL

{

@title = #MK3 $/title$

}

If someone could explain why the first two work but the second two do not, that would be great

Edit: I added my whole file because I noticed the bottom two were not working at all, even though the first two did.

Edit 2: I'm really dumb. I was editing the wrong file (I originally posted because the "~title[MKS*]" wasn't working). I had the one in my old install opened :\. I still have issues though.

Edited March 15, 2015 by civilwargeeky

[Crzyrndm]

Mk3 patch is failing because @PART is case sensitive, dunno about the HAS

[civilwargeeky]

Oh wow. How did I not notice that? Thanks so much. I figured out my HAS wasn't working because I was editing the wrong file (I hoped I could edit before anyone saw )

[BudgetHedgehog]

Ok, so I'm over my head..

Having been inspired by Atlas V, I want to triple the gimbal range of engines (but only those with gimbal range of 1 or less) and then make them use KM gimbal. Sarbian gave the last part of the code but it uses the current gimbal range. So I'm thinking:

@PART[*]:HAS[@MODULE[ModuleGimbal]]:BEFORE[km_Gimbal]:AFTER[StockRebalance]
{
  MODULE
  {
    gimbalRange *= 3
  }
}

would do it, but how to restrict it to engines with ranges of 1 or less? Is it #gimbalRange[<1]? Can MM read </>? Would it be better to write [1|0.5] or something and hope no engines appear that have a gimbal range of 0.75? Where would this go in the HAS section?

The last part of the code, written by sarbian, is

PART[*]:HAS[MODULE[ModuleGimbal]]
{
  @MODULE,*[ModuleGimbal]
  {
    @name = KM_Gimbal_3
    %yawGimbalRange = #$gimbalRange$
    %pitchGimbalRange =#$gimbalRange$ 
  }
}

which would be great, but I'm still limited to the existing range, hence the first bit that I'm stuck on..

[linuxgurugamer]

Hi,

while doing some work with the new Contract Configurator, I came across the following problem:

Reloading the module manager database causes an almost instant crash. This is on OSX, KSP 32 bit.

According to CKAN, it is 2.5.10, which I verified by looking at the GameData directory. There are no other ModuleManager Dlls on in the game.

What would you need to debug this?

Thanks

[sarbian]

I would need the logs

[hhh]

The "hidden items" message is a good thing. If you're missing parts in Interstellar, you probably don't have the custom tech tree loaded, but you'll have to ask in that thread.

I'm aware how late I am to this but I'm having the same "problem" if you'd call it that - although it's with BahamutoD's Armory. Everything was fine until about 2 days ago - the game crashed (after I crashed my plane:( which carried the mk82 bomb) and now I don't have that one part, and I'd prefer to have it back so I can blow stuff up. Is there a way to do this or is it gone forever?

OS: Windows 8.1

8G RAM, 8 CPU

x32 KSP

error.log -

https://drive.google.com/file/d/0B8JcwRV_HVk0TzUtNGRnUkxyYzQ/view?usp=sharing

output_log.txt -

https://drive.google.com/file/d/0B8JcwRV_HVk0LWIyY0o2dFhjWW8/view?usp=sharing

crash.dmp -

https://drive.google.com/file/d/0B8JcwRV_HVk0ZUtFa1BSTTFKZEk/view?usp=sharing

[Enceos]

I've been trying to master variables of MM.

Here's a config I was trying to make for transition from KAS to KIS.

By design it should add to parts with KAS containers a KIS container type.

I'm trying here to get the maxSize from KASModuleContainer in a part and add ModuleKISInventory with values based on old KAS values.

I'm not sure of how to return the value of variables and how to get it rounded for the slotsY line if the maxSize value wasn't a multiple of 10.

After running the script my ModuleManagerCache shows in part configs that I'm missing the lines where I tried to return the calculated variables, like slotsY = #$svar$.

Where did I make a mistake?

@PART
[*]:HAS[@MODULE[KASModuleContainer],!MODULE[ModuleKISInventory]]:NEEDS[KAS,KIS]
{
    mvar = #$/MODULE[KASModuleContainer]/maxSize$
    svar = #$mvar$
    @svar *= 10
    @mvar *= 0.01
    mvaro = #$mvar$
    @mvaro += 0.05    

    MODULE
    {
        name = ModuleKISInventory
        maxVolume = #$mvar$
        externalAccess = true
        internalAccess = true
        slotsX = 3
        slotsY = #$svar$
        slotSize = 50
        itemIconResolution = 128
        selfIconResolution = 128
        openSndPath = KIS/Sounds/containerOpen
        closeSndPath = KIS/Sounds/containerClose
        defaultMoveSndPath = KIS/Sounds/itemMove
    }


    MODULE
    {
        name = ModuleKISItem
        volumeOverride = #$mvaro$
        editorItemsCategory = false
    }

    !mvar = null
    !svar = null
    !mvaro = null
}

Edited March 20, 2015 by Enceos