Page 1 of 162 1231151101 ... LastLast
Results 1 to 10 of 1618

Thread: [0.25] Module Manager 2.5.1 (Oct 08) - "Win64 must die edition"

  1. #1
    Senior Rocket Scientist
    Join Date
    Apr 2013
    Location
    France
    Posts
    1,467

    [0.25] Module Manager 2.5.1 (Oct 08) - "Win64 must die edition"

    What is ModuleManager
    ModuleManager 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 his 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
    Mostly this is a merge of ModuleManager and my extension for it.
    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.

    Downloads :
    ModuleManager.2.5.1.dll
    ModuleManager-2.5.1.zip



    Doc and patch file format in the second post.
    A Documentation Wiki is in progress



    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

  2. #2
    Senior Rocket Scientist
    Join Date
    Apr 2013
    Location
    France
    Posts
    1,467
    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

    Code:
    @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:

    Code:
    PART
    {
      name = myPart
      ...(stuff)
    }
    you're defining a new part. Then, if another .cfg file somewhere does this:

    Code:
    @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:
    Code:
    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:

    Code:
    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:

    Code:
    @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_"
    Code:
    @PART[B9_*]
    {
      ...(stuff)
    }
    Search for specific module
    All PART who have a ModuleEngines
    Code:
    @PART[*]:HAS[@MODULE[ModuleEngines]]
    {
      ...(stuff)
    }
    will search for part that looks like :
    Code:
    PART
    {
       MODULE
       {
       	name = ModuleEngines
       }
    }
    Or the absence of a module
    All PART who have NO ModuleCommand
    Code:
    @PART[*]:HAS[!MODULE[ModuleCommand]]
    {
      ...(stuff)
    }
    Search for properties
    All PART whith "category = Utility"
    Code:
    @PART[*]:HAS[#category[Utility]]
    {
      ...(stuff)
    }
    will search for part that looks like :
    Code:
    PART
    {
       category = Utility
    }
    Or the absence of a properties
    All PART whithout TechRequired
    Code:
    @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)
    Code:
    @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)
    Code:
    @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)
    Code:
    @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.
    Code:
    @PART[*]:HAS[!RESOURCE[ElectricCharge],@RESOURCE[*]]
    {
      ...(stuff)
    }

    Some usefull exemples

    Add a tech level to all PART who don't have any
    Code:
    @PART[*]:HAS[~TechRequired[]]:Final
    {
    	TechRequired=advScienceTech
    }
    Add the Mechjeb module to all command pods who don't have it
    Code:
    @PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[MechJebCore]]:Final
    {    
        MODULE
        {
            name = MechJebCore
        }
    }
    All the exemple use PART but it works on other nodes too :
    Code:
    @EXPERIMENT_DEFINITION[*]:HAS[#id[gravityScan]]
    {
        @baseValue = 5
        @scienceCap = 10
    }
    You can also search the old threads for use case :
    http://forum.kerbalspaceprogram.com/...-modding-needs
    http://forum.kerbalspaceprogram.com/...2-24-july-2013


    Change for v2.x

    New features:

    MATH!
    Code:
      @PART[*]:FOR[Realism] {
        @mass *= 0.25
        @maxTemp -= 500
        @scale += 2
      }
    PROPER INDEXING!
    Code:
      @PART[*]:HAS[MODULE[MultiModeEngine]]:FOR[Pony] {
        @MODULE[ModuleEngineFX],1 {
          @PROPELLANT[Oxidizer]
          {
             @name = LiquidOxygen
          }
        }
     }
    PER-MOD PARSE PASSES!
    Code:
    @PART[fuelTank]:BEFORE[RealFuels]
    {
       @RESOURCE[LiquidFuel] {
         @amount *= 5
         @maxAmount *= 5
       }
    }
    Code:
    @PART[fuelTank]:AFTER[RealFuels]
    {
       !RESOURCE[LiquidFuel] {}
       !RESOURCE[Oxidizer] {}
    }
    DEPENDENCY CHECKING!
    Code:
    @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.

  3. #3
    Lithobraking Specialist
    Join Date
    Sep 2012
    Location
    England
    Posts
    264
    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.
    Per amnesia ad ...somewhere?

  4. #4
    Sr. Spacecraft Engineer Athlonic's Avatar
    Join Date
    Apr 2013
    Location
    France
    Posts
    336
    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.
    Mobo: Asus Formula VI | CPU: Inteli7 4770K | RAM: 16GB G.Skill p2400 | GC: GTX780 Gigabyte GHz edition 3GB | PSU: Corsair AX860i | OS: Win 8.1pro x64 | Controllers : Xbox360 pad or X-55 Rhino

    [Plugin][0.25] Athlonic Electronics / LCD - Launch CountDown v1.7.3 [11 Oct. 2014]
    [Plugin][0.25] Chatterer v.0.7.1 [08 Oct. 2014]

  5. #5
    Quote Originally Posted by Crater View Post
    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.

  6. #6
    Sr. Spacecraft Engineer a__gun's Avatar
    Join Date
    Oct 2013
    Location
    Hampshire, UK
    Posts
    276
    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:

    Code:
    \gamedata
    
          \mod
                \modfiles
    
          \moduleManager
                \modChanges.cfg
    And when all are installed the user would have this:

    Code:
    \gamedata
    
          \mod1
                \mod1files
    
          \mod2
                \mod2files
    
          \mod3
                \mod3files
    
          \moduleManager
                moduleManager.dll
                mod1Changes.cfg
                mod2Changes.cfg
                mod3Changes.cfg
    Last edited by a__gun; 25th October 2013 at 10:02.

  7. #7
    Lithobraking Specialist
    Join Date
    Sep 2012
    Location
    England
    Posts
    264
    Quote Originally Posted by a__gun View Post
    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:

    Code:
    \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.
    Per amnesia ad ...somewhere?

  8. #8
    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?

  9. #9
    Quote Originally Posted by HoneyFox View Post
    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...

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •