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

[sarbian]

No logs => No support

What is ModuleManager

ModuleManager ( by Sarbian and Blowfish ) is mod that let you write patch file that edit other part at load time. With is you can edit squad (and other mod) part without overwriting their file.

ialdabaoth gave me his blessing to maintain Module Manager while he is away.

Licence & Source

Module manager source is under a "CC share-alike license" under the term specified by ialdabaoth here. He is the original creator of Module Manager.

The source code for this version is available here : https://github.com/sarbian/ModuleManager

What's New

The DLL name contain the version number, and even with 2 version present only the newest will run. This makes install of addons using it easier since you don't have to check date on the file when overwriting it.

There is also some code to warn you if an old version of MM or my MMSarbianExt is present and to ask you to delete them.

Version 2.0.x Read the list of change by ialdabaoth at the end of the 2nd post

Version 2.1.x Many changes by Swamp_ig. Documentation update is in progress. This version parse your save game just before the main menu. It can take some (lot) of time if you have a bunch of olds saves. I'll try to find a way to limit that.

Version 2.2.0 Build for KSP 0.24 - Beware that the Save Game Fixer of previous version was disabled since 0.24 include fix that make it less usefull.

Version 2.3.1 A lot of under the hood code change. There is a ingame DB reload/dump menu you can open with ALT-F11 while in the spaceport screen (be aware that it mess up R&D unlock, as the stock reload does)

I strongly advise to delete any 2.2.x version laying around as 2.2.1 and 2.2.2 don't deactivate themselves properly when a newer version is around (but they don't break anything either)

Version 2.3.3 Module Manager is now integrated with the loading screen. You'll see the info message a bit later in the loading process. Fix the /= and -= operator (the argument where inverted)

Version 2.3.4 Fix the long loading time

Version 2.3.5 Fix perf related problem when using a lot of regex. It's the one bundled with B9.

Version 2.5.0 KSP 0.25 Compatibility and changes I'll document later.

Version 2.5.1 Version bump to fix a mistake in my build script.

Version 2.5.2 Add a cache of the patched config so it's loaded faster after the first load. The cache is deleted if any .cfg changes in your Gamedata (excluding those under PluginData).

Version 2.5.3 Fix a big with the variables implementation.

Version 2.5.4 Rebuild for 0.90

Version 2.5.5 Bug fix for value with dot or dash in their name

Version 2.5.6 Fix my stupidity.

Version 2.5.7 Bug fix for value with '&' in their name

Version 2.5.8 Improve feline handling and feeding

Version 2.5.9 Disable VSync while in the loading screen.

Version 2.5.10 Some debug code to catch a bug. If you get "Exception while checking needs" lines in your log please report them

Version 2.5.13 New compare test and # operator to copy-paste nodes

Version 2.6.1 Rebuilt for 1.0 and VSync trick removed since it is now stock

Version 2.6.2 Allow for modded Techtree to be used.

Version 2.6.3 Allows the patching of Physics values with a PHYSICSGLOBALS node

Version 2.6.5

- Clear the partDatabase.cfg if the module manager cache is expired

- Add some some useful log for all modders (search for "[ModuleManager] ModuleManager env info"

- "-nyan-nyan" option detection for the true believers

Version 2.6.6

- Add a Quick Reload for ALT F11 menu (skip PartDatabase.cfg generation)

- Ignore the cache (and force a PartDatabase.cfg generation) on KSP version change

Version 2.6.7

- log now displays the SHA256 of all loaded dll and the KSP exe

- at the end of the patching MM will notify mods that needs it. cf this post for the details

Version 2.6.8

- Fix a bug with nested :NEEDS when the top node also used a :NEEDS

Version 2.6.9-2.6.12

- Bug fixes and AssemblyReloader support. Thanks to the submiters for their patch

Version 2.6.13

- Built for 1.0.5. No change. Some 1.0.5 specific changes will come soonish

Version 2.6.14/15/16

• @key,* = xxx applies to all presents key value

• @key[1] += 1 will apply the math to the 2nd component in a comma separated vector.  "key = 0,1,0,1" will be " key = 0,2,0,1"

• @key[*] += 1 will add 1 to all elements of the vector.  "key = 1,2,3,4" will be changed to "key = 2,3,4,5"

• @key,*[1, ] += 1 will do it on all the key

Version 2.6.17

• Add a warning for users on build 1024
• @nightingale proof
• Log added/deleted/changed cfg files. Search for "[ModuleManager] Changes :" in the log

Version 2.6.18

• Fix a bug with the cache and the loading of the PHYSICGLOBAL node.

Version 2.6.19

• Add new features for looping and editing value outside the current node

Version 2.6.22

• 1.1 build. And some other stuff I forgot  

Version 2.6.23

• @blowfish patch to add & operator: insert only if it doesn't already exist
• Fix for the insert NODE at position keeping the index in the node name that blowfish found
• fix for nested constraint not looking past the first result

Version 2.6.24

• 1.1.2 build

Version 2.6.25

• Fix Exception for variable searching a value that does not exist

Version 2.7

• 1.2 ready - High fidelity cat and text rendering

Version 2.7.1

• 1.2 ready
• Allow value name that include multiple comma, as long as none has a number as its first char
• Display the number of exception and the file that generated those exception
• Better feeback on what MM is working on
• lower garbage a bit

Version 2.7.2 

• Fix the @value,* = xxx

Version 2.7.4 

• Fix operations on multiple values

Version 2.7.5

• Reloads Kerbal traits config after the patching

Version 2.7.6

• Fix PartUpgrade System patching by @Shadowmage

Version 2.8.0

• KSP 1.3. Big thanks to @blowfish for his 1.3 patch and endless support in the thread

Version 2.8.1

• Improve some exception catching and logging 
• add -ncats command line option (to be combined with -nyan-nyan)

Version 3.0.0

• Huge rewrite and code cleanup by @blowfish
• Patch loading (without cache) is faster.  About 10-30% depending on the number and composition of mods involved.
• Code changes made here will make it much easier to add new features in the future.
• Many tests have been added which can be run after ModuleManager is compiled.  This will help ensure that future changes don't break existing functionality.

Version 3.0.1

• Fix NEEDS checking for inner nodes/values 
• Add a -mm-dump cmd line option and redo the export

Version 3.0.2

• Allow 0 or many spaces before operator
• Fix :NEEDS patch order

Version 3.0.3

• Fix non-US Linux decimal separator

Version 3.0.4

• Allow operator-like character in value name

Version 3.0.5

• Fixed the Cats for KSP 1.4. Clearly a matter of uppermost urgency.

Version 3.0.6

• Rebuild for 1.4.1 and some minor fixes

Version 3.0.7

• NEEDS now allows subdirs (NEEDS[SquadExpansion/MakingHistory])
• Allow parentheses in value name
• Allow spaces in value names
• Bug fixes

Version 3.1.0

• more Internal code improvement by @blowfish
• more detailed log about what works™ but should be written differently.

Version 3.1.1

• more Internal code improvement by @blowfish

Version 3.1.3

• Add a workaround for the 1.6.0 PartDatabase / Editor bug

Version 4.0.0

• @blowfish worked his magic once more and now MM does the patching while the game loads the models and textures.

Version 4.0.1

• Fix tech tree and modded physics

Version 4.0.2

• Allow assemblies to add to mod list (Fix for Kerbalism compatibility)
• Add -mm-dont-copy-logs command line flag if you do not want to copy MM log back into the game log
• Fix for KSP runs in debug mode.

Version 4.0.3

• Logging:
  • Fix context not showing up for exceptions in logs
  • Remove datestamps from log messages (only put time), instead write date at top of logs
  • Have timestamps on logs reflect when the log message was created rather than when it was written to the log
• Fix files with a space before the extension breaking the cache
• Fix tabs and newlines (\t and \n) getting stripped out of values

Version 4.1.0

• KSP 1.8

Version 4.1.2

• Add an Exception interceptor to catch ReflectionTypeLoadException and properly blame broken DLLs

Version 4.1.3

• Cleanup the  Exception interceptor code and remove the double exception logging and improve the badly worded warning

Version 4.1.4

• Fix a bug with LAST[modx] when modx is not present
• some code cleanups

Version 4.2.0

• Part loader now relies on physics values (for e.g. minimum rigidbody mass), so we want to set modded physics earlier

Version 4.2.1

• Fix a bug introduced in the previous version

Version 4.2.2

• Support wildcards in nodetype matching so you can do @*,* {}
• Support # in value names since loc names start with #
• Tell Localizer to reload the language after MM finishes

Version 4.2.3

• Fix the dll hashing when the dll is already opened. by @linuxgurugamer
• Fix for MM loading the wrong physics file when when when using the faulty PDLauncher workaround

Version not listed here ? Check the Jenkins Server. If it is there then you can use it without fears of triggering the end of the world. by @siimav

Downloads :

For KSP 1.8.0 - 1.12.x

ModuleManager-4.2.3.zip

 

ModuleManager.4.2.3.dll

For KSP 1.4.0 - 1.7.x

ModuleManager-4.0.3.zip

ModuleManager.4.0.3.dll

 

Last version for KSP 1.3.x

ModuleManager-4.0.2.zip

ModuleManager.4.0.2.dll

ModuleManager-3.0.4.zip

ModuleManager.3.0.4.dll

Last version for KSP 1.2.x

ModuleManager.2.7.6.dll

ModuleManager-2.7.6.zip

SHA256 : 0bc14c3e0dbd8191dfb9aff5b8408c377e0bc74d508ed10fe4b4371ab569f95c

Doc and patch file format in the second post.

A Documentation Wiki is in progress

Post on how to use variable in MM

Community examples and useful patch

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 formated 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 to exclude 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 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 took the easy way out and just add a button.

How to install

You just have to put the dll in your KSP/GameData folder. Then you can put you patch .cfg file anywhere. I would create a folder for your personal patch, but it's up to you.

As mentioned earlier you can have multiple version of it. But you can clean up too

Edited July 3, 2023 by sarbian

[sarbian]

You can now override specific lines in a ConfigNode (what the game's code calls the format inside a .cfg file), on a line-by-line basis, and you don't have to specify lines that you don't want to change. The new format looks like this:

Single Part and editing format

@PART[SomePart] // change Some PART
{
  @mass = 0.625 // change SomePart's mass to 0.625
  @description = SomePart: now uses Xenon!

  @MODULE[ModuleEngines] // change SomePart's ModuleEngines MODULE
  {
     @maxThrust = 2.25  // change maxThrust to 225

     @PROPELLANT[LiquidFuel] // change its LiquidFuel propellant
     {
        @name = XenonGas // use XenonGas instead
        @ratio = 1.0 // change the ratio
     }
     !PROPELLANT[Oxidizer] {} // remove the Oxidizer propellant completely.
  }

  RESOURCE // add a new resource to this part
  {
     name = ElectricCharge
     amount = 100
     maxAmount = 100
  }
}

Let's break this down.

If you make a .cfg file with an entry that looks like this:

PART
{
  name = myPart
  ...(stuff)
}

you're defining a new part. Then, if another .cfg file somewhere does this:

@PART[myPart]
{
  ...(stuff)
}

That says "at the PART named myPart, add the following additional stuff..."

There's two ways you can do this:

1. @PART[myPart] {...} is for plugin developers, who need to add new modules and resources to stock parts.

2. @PART[myPart]:Final {...} is for "tweakers", who want to release a set of reconfigurations of other peoples' parts that changes gameplay, or personal patch. The change with :Final are applied after all others are done.

inside the curly brackets, you have several options:

@foo = <new value> changes foo to <new value>.

!foo = DELETE deletes foo completely.

foo = <value> creates a new variable called 'foo'; if there was already a variable called 'foo', now there's two of them.

if there are two or more variables called foo, you can refer to them like this:

@foo,0 = <...> finds the first one (this is the same as @foo = <...>)

@foo,1 = <...> finds the second one, @foo,2 = <...> finds the third, and so on.

The same thing works for !foo,0 etc.

@NODE[foo] {...} modifies the node which has type 'NODE' and name = foo. 'NODE' is a MODULE {} or a RESOURCE {} or a PROP {} or something like that.

!NODE[foo] {} deletes node foo completely.

NODE {

name = foo

...(stuff)

} creates a new node of type NODE. If there was already a node of type 'NODE', now there's two of them.

for nodes, instead of using a numeric index to identify between multiple nodes, you search by its <tag = ...> line. So if you do

@NODE[foo,bar] {...}

that will find and modify the first node that was defined like this:

NODE
{
  name = foo
  tag = bar
}

Right now 'tag' isn't being used by anything, but in the future if you need to add multiple nodes, adding a 'tag' field isn't a bad idea. It'd look something like this:

PART
{
  name = EngineSABRE
  module = Part
  ...
  MODULE
  {
    name = ModuleEngines
    tag = Atmosphere
    ...
  }
  MODULE
  {
    name = ModuleEngines
    tag = Vacuum
   }
}

and then someone could access the second node by going:

@PART[EngineSABRE]
{
  @MODULE[ModuleEngines,Vacuum]
  {
     ...
  }
}

Multiple Parts

You can also apply a change to multiple part.

Use a wildcard search for all "name" inside brackets :

All PART whose name start with "B9_"

@PART[B9_*]
{
  ...(stuff)
}

Search for specific module

All PART who have a ModuleEngines

@PART[*]:HAS[@MODULE[ModuleEngines]]
{
  ...(stuff)
}

will search for part that looks like :

PART
{
   MODULE
   {
   	name = ModuleEngines
   }
}

Or the absence of a module

All PART who have NO ModuleCommand

@PART[*]:HAS[!MODULE[ModuleCommand]]
{
  ...(stuff)
}

Search for properties

All PART whith "category = Utility"

@PART[*]:HAS[#category[Utility]]
{
  ...(stuff)
}

will search for part that looks like :

PART
{
   category = Utility
}

Or the absence of a properties

All PART whithout TechRequired

@PART[*]:HAS[~TechRequired[]]
{
  ...(stuff)
}

Search for module with a specific configuration

All PART who have a ModuleEngines using XenonGas as a propelant (space for clarity)

@PART[*]:HAS[  @MODULE[ModuleEngines]:HAS[ @PROPELLANT[XenonGas] ]  ]
{
  ...(stuff)
}

Combine search

All PART who have a ModuleEngines and have a SolidFuel ressource (space added for clarity)

@PART[*]:HAS[  @MODULE[ModuleEngines] , @RESOURCE[SolidFuel]  ] 
{
  ...(stuff)
}

It works at lower level too :

All PART who have a ModuleEngines using XenonGas and ElectricCharge as a propelant (space added for clarity)

@PART[*]:HAS[  @MODULE[ModuleEngines]:HAS[ @PROPELLANT[XenonGas] , @PROPELLANT[ElectricCharge] ]  ]
{
  ...(stuff)
}

Use wildcard search at lower level

All PART without ElectricCharge as a ressource but with any other.

@PART[*]:HAS[!RESOURCE[ElectricCharge],@RESOURCE[*]]
{
  ...(stuff)
}

Some usefull exemples

Add a tech level to all PART who don't have any

@PART[*]:HAS[~TechRequired[]]:Final
{
	TechRequired=advScienceTech
}

Add the Mechjeb module to all command pods who don't have it

@PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[MechJebCore]]:Final
{    
    MODULE
    {
        name = MechJebCore
    }
}

All the exemple use PART but it works on other nodes too :

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

You can also search the old threads for use case :

http://forum.kerbalspaceprogram.com/threads/31342-0-20-ModuleManager-1-3-for-all-your-stock-modding-needs

http://forum.kerbalspaceprogram.com/showthread.php/41616-Extension-for-ModuleManager-with-wildcard-and-conditional-v0-2-24-july-2013

Change for v2.x

New features:

MATH!

  @PART[*]:FOR[Realism] {
    @mass *= 0.25
    @maxTemp -= 500
    @scale += 2
  }

PROPER INDEXING!

  @PART[*]:HAS[MODULE[MultiModeEngine]]:FOR[Pony] {
    @MODULE[ModuleEngineFX],1 {
      @PROPELLANT[Oxidizer]
      {
         @name = LiquidOxygen
      }
    }
 }

PER-MOD PARSE PASSES!

@PART[fuelTank]:BEFORE[RealFuels]
{
   @RESOURCE[LiquidFuel] {
     @amount *= 5
     @maxAmount *= 5
   }
}

@PART[fuelTank]:AFTER[RealFuels]
{
   !RESOURCE[LiquidFuel] {}
   !RESOURCE[Oxidizer] {}
}

DEPENDENCY CHECKING!

@PART[fuelTank]:AFTER[RealFuels]:NEEDS[RealSolarSystem,!RealKerbalSystem]
{
   @scale *= 4;
}

If it detects a loaded DLL, it assumes it's a mod and creates a :BEFORE, :FOR and :AFTER pass for it.

If you use underscores to specify your mod's version in the filename, ModuleManager will regrettably think that these are part of the filename, because I can't tell the difference between "MyMod_1_3_6" and "Mod_1337s_Cool_Stuff". On the other hand, if you use periods to specify your mod's version, then "MyMod.1.3.6" will correctly be identified as "MyMod".

This means that there will always be the following passes:

:FIRST

:BEFORE[Assembly-CSharp]

:FOR[Assembly-CSharp]

:AFTER[Assembly-CSharp]

:BEFORE[ModuleManager]

:FOR[ModuleManager]

:AFTER[ModuleManager]

:FINAL

Specifying ':FIRST' is optional; I just named the 'main' pass so that the log file is clearer.

If your mod includes a DLL put all your MM patch nodes in the :FOR[yourMod] pass.

If your mod does not include a DLL, then pick a name for your mod THAT DOES NOT CONFLICT WITH ANY OTHER MOD'S DLL, and then put all your MM patch nodes in the :FOR[yourMod] pass.

If you do this, other mods can use :BEFORE[yourMod] and :AFTER[yourMod] to politely modify things furthr at the correct sequence.

The following parameters are currently implemented:

:BEFORE[ModName] - execute this patch BEFORE ModName executes its patches.

:FOR[ModName] - I am ModName, and these are my patches.

:AFTER[ModName] - execute this patch AFTER ModName executes its patches.

:NEEDS[ModName1] - execute this patch only if ModName1 is installed.

:NEEDS[!ModName2] - do not execute this patch if ModName2 is installed.

You can combine NEEDS nodes like this:

:NEEDS[ModName1, !ModName2]

You can match subnodes in one of seven ways:

@NODE[name] // will wildcard match name (so you can do ModuleEnginesFX or ModuleEngines*), and apply itself to the first NODE it finds.

@NODE[name],index // will wildcard match name, and apply itself to the indexth NODE it finds.

@NODE[name],* // will wildcard match name, and apply itself to ALL matching NODEs.

@NODE[name]:HAS[criteria] // will wildcard match name and apply itself to all matching NODEs which also meet the :HAS criteria

@NODE:HAS[criteria] // will apply itself to all matching NODEs which also meet the :HAS criteria

@NODE,index // will apply itself to the indexth NODE it finds

@NODE,* // will apply itself to ALL NODEs

These apply to @, ! and % nodes. $ nodes are necessarily single-application, and thus will always apply to the first node they find.

Edited December 4, 2014 by sarbian

[Crater]

I'm a little concerned about needing to have a copy of the ModuleManager.dll in every sub-tree that has ModuleManager config files in it. My reasoning is that I have seen several mods which do not use ModuleManager themselves, but provide ModuleManager config files to ease inter-operation with other mods.

For example, Kethane does not use ModuleManager, but ships with a ModuleManager config file to integrate the Kethane resource into ModularFuels. This will silently fail under the new scheme unless the user either adds a copy of ModuleManager.dll into the Kethane folder, or moves the Kethane resource definition file (which has the @TANK def) out to somewhere that has ModuleManager.dll already.

I think that ModularFuels compatability is likely to be the biggest one, here, but there could well be others.

However, I completely understand the concern regarding addons dropping older versions into the GameData root, and messing up the entire install.

As an alternative, how about simply including the dll version number in the filename? So you could have GameData\ModuleManager_1.4.dll

If you then up-version to GameData\ModuleManager_1.5.dll it will never overwrite the old one, and will be easy to see what versions are installed. You would then still be able to process the entire tree from a single instance of your DLL, and users could be told to simply delete all but the newest version number from GameData?

Anyhow, thanks for working on this, I don't quite know what I would do without it I'll be testing the new one out tonight (carefully, and installed in 3 places, as needed), and I'll give feedback if I find any problems.

[Athlonic]

Excellent !!!

Will test this with my LCD mod asap.

Making each instance of MM only process patch file in the subdirectory where its installed is a very good idea and may avoid many of fears/issues some users have.

Thanks a lot.

[HoneyFox]

I'm a little concerned about needing to have a copy of the ModuleManager.dll in every sub-tree that has ModuleManager config files in it. My reasoning is that I have seen several mods which do not use ModuleManager themselves, but provide ModuleManager config files to ease inter-operation with other mods.

For example, Kethane does not use ModuleManager, but ships with a ModuleManager config file to integrate the Kethane resource into ModularFuels. This will silently fail under the new scheme unless the user either adds a copy of ModuleManager.dll into the Kethane folder, or moves the Kethane resource definition file (which has the @TANK def) out to somewhere that has ModuleManager.dll already.

I think that ModularFuels compatability is likely to be the biggest one, here, but there could well be others.

However, I completely understand the concern regarding addons dropping older versions into the GameData root, and messing up the entire install.

As an alternative, how about simply including the dll version number in the filename? So you could have GameData\ModuleManager_1.4.dll

If you then up-version to GameData\ModuleManager_1.5.dll it will never overwrite the old one, and will be easy to see what versions are installed. You would then still be able to process the entire tree from a single instance of your DLL, and users could be told to simply delete all but the newest version number from GameData?

Anyhow, thanks for working on this, I don't quite know what I would do without it I'll be testing the new one out tonight (carefully, and installed in 3 places, as needed), and I'll give feedback if I find any problems.

+1 with this... such plugin used by multiple mods should go to GameData folder as a common base, thus easier for players to keep it up-to-date. Otherwise we need to copy the plugin to lots of mod folders, which is quite tedious, much tedious than manually checking the version and judge if older version should be replaced.

[a__gun]

Would it not be best for ModuleManager and ALL module manager cfg files to have their own dedicated folder, like other mods do? Any mods that come with module manager cfgs would just have to place them in gamedata/moduleManager.

The user is left with one copy of ModuleManager to update, and one folder to view all cfgs, removing the risk of having lots of distributed cfgs or dlls that could be conflicting. The moduleManager.dll would continueto only look within its own subdirectory, but there would only be one instance.

An example:

User has 3 mods which all come with module manager cfgs. Each individual mod would come bundled as follows:

\gamedata

      \mod
            \modfiles

      \moduleManager
            \modChanges.cfg

And when all are installed the user would have this:

\gamedata

      \mod1
            \mod1files

      \mod2
            \mod2files

      \mod3
            \mod3files

      \moduleManager
            moduleManager.dll
            mod1Changes.cfg
            mod2Changes.cfg
            mod3Changes.cfg

Edited October 25, 2013 by a__gun

[Crater]

Would it not be best for ModuleManager and ALL module manager cfg files to have their own dedicated folder, like other mods do? Any mods that come with module manager cfgs would just have to place them in gamedata/moduleManager.

The user is left with one copy of ModuleManager to update, and one folder to view all cfgs, removing the risk of having lots of distributed cfgs or dlls that could be conflicting. The moduleManager.dll would continueto only look within its own subdirectory, but there would only be one instance.

An example:

User has 3 mods which all come with module manager cfgs. Each individual mod would come bundled as follows:

\gamedata

      \mod
            \modfiles

      \moduleManager
            \modChanges.cfg

And when all are installed the user would have this:

That just makes it more work to remove a mod, since it is no longer totally contained in its own folder, and does nothing to resolve the issue of installing a mod that comes with an old version of ModuleManager.dll that overwrites the one already in GameData\ModuleManager.

Many users are put off by having to track down dependencies that they see as "should be bundled", so mod authors who depend on MM for their functionality will want to (and rightly so) bundle the MM version that is current at the time they created their mod.

[NathanKell]

I just want to chime in about the new subdirectory plan--I too think, while it's a neat idea, it'll cause more problems than it solves.

Also, might that not also break handling of the :Final command?

[Gaius]

Otherwise we need to copy the plugin to lots of mod folders, which is quite tedious, much tedious than manually checking the version and judge if older version should be replaced.

That shouldn't be necessary, those mods should have their own copies in their folders already, and you shouldn't replace them, since they may be dependent on the particular version they shipped with -- replacing them with a newer version is begging for problems. It's like replacing a library DLL that ships with a program with a newer version of that library -- it might work, but it's generally a very bad idea. If it was designed to run with version X, don't replace it with version Y. Leave well enough alone...

[mwlue]

This version don't seems work with the mod that add engineer redux to all pods.

[Kaa253]

First off, let me strongly applaud the work on ModuleManager. It has become a really important addon to KSP for me. Well done.

This version seems to have a lot of bugs (as expected perhaps), but I may also be doing something wrong. I found it got very messy, very quickly to have the mod in all the required subdirectories (5 in all). I think it was better to have just one in the GameData folder. Unfortunately, the reload of the database on the debug menu function did not appear to work. It would be so good if it was reliable.

I was unaware of the earlier wildcard extension. It's awesome! I have fallen back to using that for now. I will keep an eye on this developement and would be happy to do some more testing/feedback.

[Raptor831]

I can confirm that this is working for me at the moment. I've added MechJeb to all command pods/probe cores using the wildcard and the HAS function. Works as advertised for that. I only have 1 or 2 .cfgs in one folder that this is working on, so nothing too complicated.

[Starwaster]

I'm a little concerned about needing to have a copy of the ModuleManager.dll in every sub-tree that has ModuleManager config files in it. My reasoning is that I have seen several mods which do not use ModuleManager themselves, but provide ModuleManager config files to ease inter-operation with other mods.

For example, Kethane does not use ModuleManager, but ships with a ModuleManager config file to integrate the Kethane resource into ModularFuels. This will silently fail under the new scheme unless the user either adds a copy of ModuleManager.dll into the Kethane folder, or moves the Kethane resource definition file (which has the @TANK def) out to somewhere that has ModuleManager.dll already.

I think that ModularFuels compatability is likely to be the biggest one, here, but there could well be others.

However, I completely understand the concern regarding addons dropping older versions into the GameData root, and messing up the entire install.

As an alternative, how about simply including the dll version number in the filename? So you could have GameData\ModuleManager_1.4.dll

If you then up-version to GameData\ModuleManager_1.5.dll it will never overwrite the old one, and will be easy to see what versions are installed. You would then still be able to process the entire tree from a single instance of your DLL, and users could be told to simply delete all but the newest version number from GameData?

Anyhow, thanks for working on this, I don't quite know what I would do without it I'll be testing the new one out tonight (carefully, and installed in 3 places, as needed), and I'll give feedback if I find any problems.

I concur except that I'm going to use the word horrified rather than concerned.

One of the things that was great about ModuleManager was it only augmented the way config files worked. It didn't alter the behavior on such a fundamental level.

Config files are supposed to function no matter where they are. Also, one use of MM config files is as tweaks. I think quite a few of us as non-modders keep our tweaks in a separate sub-folder (i.e. MyTweaks). Now I'll need to copy the dll in there even though it's located elsewhere and should be functional?

I submit that the issues that these changes are intended to address were never very serious issues to begin with and didn't merit such a drastic response. They should have either been treated as non-starters or given very SERIOUS fore-thought before altering the way in which ModuleManager works.

That shouldn't be necessary, those mods should have their own copies in their folders already, and you shouldn't replace them, since they may be dependent on the particular version they shipped with -- replacing them with a newer version is begging for problems. It's like replacing a library DLL that ships with a program with a newer version of that library -- it might work, but it's generally a very bad idea. If it was designed to run with version X, don't replace it with version Y. Leave well enough alone...

Leaving well enough alone would have been a great response to not making such sweeping changes to ModuleManager to begin with. Accidentally overwriting files when installing over them has always been a risk with software. It requires some caution when installing software and nothing more.

Edited October 26, 2013 by Starwaster

[mwlue]

MM 1.4 seems having problem to add engineering redux to all pod.

http://forum.kerbalspaceprogram.com/threads/18230-0-22-Kerbal-Engineer-Redux-v0-6-1-3?p=731065&viewfull=1#post731065

[sarbian]

edit : I ll think more.

Edited October 26, 2013 by sarbian

[Starwaster]

An amendment to my prior post.

If it's not enough to direct the burden of resolving versioning issues onto the modding and player community and a fix really is required (which I re-affirm that I don't think one is because the problem is non-existent)

then the solution should be that ModuleManager periodically (every few hours tops or just once a day) should check online for updates. It's easier to resolve a version issue for a plugin living in a single location than one that resides in multiple locations. Because sooner or later, with this system, players will have to worry about resolving version issues only they'll have to do it individually one by one across multiple mods.

Right now, how many version of ModuleManager are there that we think we have to worry about? By now they should really be down to two. The latest official one which practically everyone is using and Sarbian's version from a few months back which corrected an issue where the plugin might not execute properly or cause other plugins not to execute. And of course his extensions. Aside from that, it shouldn't be an issue at this point in time.

And, going forward, how much updating do you anticipate doing, Sarbian? Aside from fixing bugs in the software or fixing future compatibility issues arising from KSP updates there really shouldn't be much updating going on. If there is, then let the plugin 'phone home' as Kerbal Alarm Clock does. And update once at a single location rather than updating many.

[Frederf]

My reaction to the proposed change to MM:

1. I understand the motivation

2. The potential problem is not serious/unavoidable

3.There is a better way to achieve what you want

4. Functionality takes a huge hit from this change

There is the phrase "do not let the animals run the zoo." Modders are concerned that their code isn't unchangeable by other code is just a power fear not a flaw. Only allowing the local instance of MM to apply config from its local source does not prevent conflict since the locally-sourced config is applied globally. Changes-after-changes to the same value is a feature of the MM system. To prevent undesirable out-of-order config overwrite what is needed is a robust and open versioning scheme which is able to reliably discriminate "first" and "second" config patches without hindering the natural open-endedness of the design.

Instead, put the sequencing information into the cfg patches themselves. This way a modder can opt-in to enforced sequencing for data integrity purposes. For example the config patch for Kethane 0.7 might say "patchClass=Kethane; patchClassVersion=0.7" and then Ke0.8 might introduce a config patch with an increased version. Then MM can compare the config patches, see they are the same patchClass, then compare version numbers to see if it should apply or not. I cannot see how to expand data protection beyond this level without unfairly allowing one modder to lock down the data for others which is against the MM purpose.

[Arrowmaster]

Now I don't know anything about C# but for World of Warcraft addons in Lua when we ran into the shared library issue we created a method of detecting during loading if the shared library was already loaded and only loading the rest of the file to replace it if we had a newer version. Can you store a version number and disable/unload all but one of the latest version?

[asmi]

Can you also fix it so it would work with part names containing spaces (i.e. BobCat's mods)? Maybe use quotes to indicate where strings starts and ends, like it's common in OS's command shells?

[Starwaster]

Can you also fix it so it would work with part names containing spaces (i.e. BobCat's mods)? Maybe use quotes to indicate where strings starts and ends, like it's common in OS's command shells?

It's a Unity3D issue with ConfigManager. It does not like whitespaces. They're illegal within its URL specification. If you look at a save file you'll note that they're converted to periods. or dots if you prefer. So internally it doesn't even preserve the spaces, it seems like it just works around them. sorry that's wrong. Underscores are the ones converted.

I've tried to get it to handle spaces myself btw by escaping them but it doesn't seem to respect accepted escape characters.

Edited October 26, 2013 by Starwaster

[Gaius]

Leaving well enough alone would have been a great response to not making such sweeping changes to ModuleManager to begin with. Accidentally overwriting files when installing over them has always been a risk with software. It requires some caution when installing software and nothing more.

Or one could simply refrain from overwriting them when it's not needed. When I install a new Unity-based game, I don't have to worry about it breaking another Unity-based game I have installed, as long as both authors follow best-practices in this area and have their own copies of whatever version of Unity they used in their own directories with the game, just like KSP does. This creates none of the nightmare scenarios people seem to be fearing for some reason, nor any upgrade problems when new versions of Unity are released (the kind of problems that would be created if they were trying to use Unity as a shared resource). Each game has its own copies of needed libraries in whatever versions they were designed to use, and problems are avoided, not caused, by the fact that they may be using different versions at the same time.

then the solution should be that ModuleManager periodically (every few hours tops or just once a day) should check online for updates. It's easier to resolve a version issue for a plugin living in a single location than one that resides in multiple locations.

That's actually how you cause problems, rather than avoid them. Avoiding these kinds of version issues is most easily done by isolating each mod so that it can use whichever version works for it, and not be affected by future updates that might change things in ways that were not known at the time the mod was made. As long as you don't have the plugin in one single location, trying to cope with many config files, each potentially written under a different version of the plugin, you greatly simplify the problem and simply avoid the kind of compatibility problems that crop up any time shared resources are used. Resource sharing can be a great boon in many situations, but is ModuleManager such a large and memory-hungry plugin that it really benefits from it? Trying to share it rather than treat it like a local library for each mod that wants to take advantage of it seems like it creates more headaches for no real benefit...

Edited October 27, 2013 by Gaius

[Starwaster]

Or one could simply refrain from overwriting them when it's not needed. When I install a new Unity-based game, I don't have to worry about it breaking another Unity-based game I have installed, as long as both authors follow best-practices in this area and have their own copies of whatever version of Unity they used in their own directories with the game, just like KSP does. This creates none of the nightmare scenarios people seem to be fearing for some reason, nor any upgrade problems when new versions of Unity are released (the kind of problems that would be created if they were trying to use Unity as a shared resource). Each game has its own copies of needed libraries in whatever versions they were designed to use, and problems are avoided, not caused, by the fact that they may be using different versions at the same time.

That's actually how you cause problems, rather than avoid them. Avoiding these kinds of version issues is most easily done by isolating each mod so that it can use whichever version works for it, and not be affected by future updates that might change things in ways that were not known at the time the mod was made. As long as you don't have the plugin in one single location, trying to cope with many config files, each potentially written under a different version of the plugin, you greatly simplify the problem and simply avoid the kind of compatibility problems that crop up any time shared resources are used. Resource sharing can be a great boon in many situations, but is ModuleManager such a large and memory-hungry plugin that it really benefits from it? Trying to share it rather than treat it like a local library for each mod that wants to take advantage of it seems like it creates more headaches for no real benefit...

This isn't multiple mods as you're trying to describe it. This is (or WAS, pre-1.4) a single mod whose plugin executes once during KSP startup. It looks through the config nodes (which have already been loaded into memory. All of them. No matter where they are.) and if they use MM syntax it interprets them and applies those changes to the config nodes whether they're parts or resource nodes, whatever. And currently does that rather well.

The changes being discussed haven't even been given proper testing nor discussion as to the consequences before pushing them out.

[Frederf]

What I'm not understanding is where the problem with a unitary MM is. Presumably any sufficiently sophisticated implementation of a unitary MM is just as good as a fragmented array of MMs. If the goal is to load config patches under a specific version of MM then that is just as well done with a MM that handles different config patches differently. I'm also incredulous about MM changing so drastically that running an old config patch won't be handled properly and even so having mods go out of date isn't so bad. The old config patch should be able to be brought up to the modern MM format quickly and easily in the unlikely event it needs to be.

What happens in KSP 0.25 when your mods using MM of five distinct versions have varying levels of compatibility with that version of KSP start bugging out? It's a troubleshooting nightmare. MM does one task. Do not let it diversify into a loose formation of different versions. Mods will conform to a single leading standard.

[Starwaster]

What I'm not understanding is where the problem with a unitary MM is. Presumably any sufficiently sophisticated implementation of a unitary MM is just as good as a fragmented array of MMs. If the goal is to load config patches under a specific version of MM then that is just as well done with a MM that handles different config patches differently. I'm also incredulous about MM changing so drastically that running an old config patch won't be handled properly and even so having mods go out of date isn't so bad. The old config patch should be able to be brought up to the modern MM format quickly and easily in the unlikely event it needs to be.

What happens in KSP 0.25 when your mods using MM of five distinct versions have varying levels of compatibility with that version of KSP start bugging out? It's a troubleshooting nightmare. MM does one task. Do not let it diversify into a loose formation of different versions. Mods will conform to a single leading standard.

the changes are driven by a few people worried about what happens if the solitary copy of module manager is overwritten by an older copy. the format of the configuration files isn't really relevant because it's driven by the game's confignode format. So unless that changes there shouldnt be a reason to expect such changes between different versions of modulemanager.

[Kaa253]

Can you also fix it so it would work with part names containing spaces (i.e. BobCat's mods)? Maybe use quotes to indicate where strings starts and ends, like it's common in OS's command shells?

Modders (and all programmers for that matter) really, really should NOT assign variables to contain whitespaces! Especially part names. Sorry, its something that wastes my time at work as well, so I have a big issue with it. (Purely plain text messages excepted. e.g. title and description variables in the part.cfg files.)