Page 1 of 35 12311 ... LastLast
Results 1 to 10 of 341

Thread: [0.20] ModuleManager 1.3 - for all your stock-modding needs

  1. #1

    [0.20] ModuleManager 1.3 - for all your stock-modding needs

    [Mod Comment - A new version is available here]

    Current Version: 1.3 (2013-06-15 12:30 UTC)
    Plugin Authors, Get the ModuleManager DLL here.

    Plugin developers and other modders have my explicit permission to redistribute this dll with their own works, so long as you give credit to me and provide a URL back to this forum post.




    Mods using ModuleManager:
    ModularFuelTanks (Official) - by Ialdabaoth (me!)
    FerramAerospaceResearch. (Official) - by ferram4
    IonCross Crew Support System (Official)
    Here is a ModuleManager .cfg for RemoteTech. (Unofficial) - does not contain plugin DLL or custom RemoteTech parts, only modification cfg for stock probes & antennae



    What the hell is ModuleManager?
    So, you want to install FerramAerospaceResearch. Awesome! Trouble is, it modifies Squad's part.cfg files.

    And you want to install IonCrossLifeSupport... which modifies Squad's part.cfg files.

    So now you have to slog through, figure out what each mod changes in each file, and painstakingly craft a "merged" file by hand.

    But not anymore!

    A LOT has changed for 0.20.0. After a long talk with Mu, I completely redesigned my "configNode overloader" format to more closely match his.


    For anyone who wants to tweak stock parts for any reason (or even non-stock parts that you didn't create!), and redistribute those tweaks in a way that won't stomp all over someone ELSE'S tweaks, ModuleManager is for you.

    What this means: 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:

    Code:
    @PART[SomePart] // change SomePart
    {
      @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.

    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]
      {
         ...
      }
    }
    NOTE: As of 1.3, the ModuleManager now runs at the loading screen, before parts are parsed. Patches get applied during the loading screen instead of during the main screen, which will reduce loading lag and - more importantly - gets rid of bugs like what happened with ExsurgentEngineering. From now on, KSP is handling everything the way it should be; ModuleManager merely adjusts the cfg files before KSP loads them instead of ModuleManager trying to re-load them itself.

    ModuleManager cannot tell if you've gone into the debug menu and reloaded all config files! If you do this, you will wipe out all mods.
    Last edited by sal_vager; 26th January 2014 at 10:58.

  2. #2
    Sr. Spacecraft Engineer zzz's Avatar
    Join Date
    May 2013
    Location
    Russia
    Posts
    261
    Can I use such code in some "my.cfg" to add or change something in stock parts, like

    Code:
    @PART  mk1pod {
    
    MODULE ModuleGenerator
    {
    	isAlwaysActive = true
    	OUTPUT_RESOURCE
    	{
    	   name = ElectricCharge
    	   rate = 0.75
    	}	
    }
    
    
    @RESOURCE (do not understand the  change amount  sintax)
      {
         @name = ElectricCharge
         @amount = 500
         @maxAmount = 500
      }
    }
    
    
    @PART  Mark2Cockpit
    {
    .....
    }
    (Just example.)
    Or this only for use in plugins code somehow.(to be sure I understand it correct)

  3. #3
    Quote Originally Posted by zzz View Post
    Can I use such code in some "my.cfg" to add or change something in stock parts
    That is, in fact, its primary purpose.

  4. #4
    Sr. Spacecraft Engineer zzz's Avatar
    Join Date
    May 2013
    Location
    Russia
    Posts
    261
    That's very nice. Thanks.

  5. #5
    Wait, I thought this was a core feature that was currently broken. Huh?

  6. #6
    Quote Originally Posted by Frostiken View Post
    Wait, I thought this was a core feature that was currently broken. Huh?
    It is. I fixed it.

    Also: updated the .zip to include a config file that applies ModularFuelTanks data to KSPX parts.

  7. #7
    So, do I just dump all this in the root KSP folder or what? What's this .DS_Store file in every folder? Where does gamedata.cfg hang out?

  8. #8
    Dump it all into {KSP}/GameData/

    this should result in:

    Code:
    {KSP}/GameData/gameData.cfg
    {KSP}/GameData/Ialdabaoth/ModularFuelTanks.cfg
    {KSP}/GameData/Ialdabaoth/ModularFuelTanks_Engines.cfg
    {KSP}/GameData/Ialdabaoth/KSPX_ModularFuelTanks.cfg
    {KSP}/GameData/Ialdabaoth/PluginData/TankTypes.cfg
    {KSP}/GameData/Ialdabaoth/Plugins/ModularFuelTanks.dll
    {KSP}/GameData/Ialdabaoth/Plugins/ModuleManager.dll
    {KSP}/GameData/Ialdabaoth/Resources/ResourcesFuel.cfg
    if you don't want to use my modularfueltanks, but JUST want moduleManager, you can pare all that down to:
    Code:
    {KSP}/GameData/gameData.cfg
    {KSP}/GameData/Ialdabaoth/Plugins/ModuleManager.dll
    The .DS_Store is GitHub (source control) stuff, you can delete or ignore those.

  9. #9
    Mad (social) scientist Mihara's Avatar
    Join Date
    Apr 2013
    Location
    Moscow, Russia
    Posts
    1,156
    Quote Originally Posted by ialdabaoth View Post
    It is. I fixed it.
    ...but will it be fixed in the same way when 0.20.1 rolls in? I.e will the configs made according to your instructions continue working?

  10. #10
    Quote Originally Posted by Mihara View Post
    ...but will it be fixed in the same way when 0.20.1 rolls in? I.e will the configs made according to your instructions continue working?
    I'm working closely with Mu, so I believe the answer will be "yes". Obviously, Squad can choose to do what they want, but Mu's the guy in charge of this part of the system and he seems to like what I've done.

Posting Permissions

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