Jump to content

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

ialdabaoth

By ialdabaoth
in KSP1 Mod Releases

 Share

Recommended Posts

ialdabaoth

ialdabaoth

Posted
Posted (edited)

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


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


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.

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]
  {
     ...
  }
}

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.

Edited by sal_vager
Link to comment
Share on other sites
zzz

zzz

Posted
Posted

Can I use such code in some "my.cfg" to add or change something in stock parts, like


@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)

Link to comment
Share on other sites
ialdabaoth

ialdabaoth

Posted
  • Author
Posted
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.

Link to comment
Share on other sites
ialdabaoth

ialdabaoth

Posted
  • Author
Posted

Dump it all into {KSP}/GameData/

this should result in:


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


{KSP}/GameData/gameData.cfg
{KSP}/GameData/Ialdabaoth/Plugins/ModuleManager.dll

The .DS_Store is GitHub (source control) stuff, you can delete or ignore those.

Link to comment
Share on other sites
ialdabaoth

ialdabaoth

Posted
  • Author
Posted
...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.

Link to comment
Share on other sites
zzz

zzz

Posted
Posted (edited) 

@RESOURCE[ElectricCharge]
}
	@amount = 100	
	@maxAmount = 100

}

Is this correct syntax?

And can I use // comments in this configs?

Edited by zzz
Link to comment
Share on other sites
SteamTrout

SteamTrout

Posted
Posted

The .DS_Store is GitHub (source control) stuff, you can delete or ignore those.

.DS_Store is actually Mac OS file which contains information similar to Thumbs.db and folder(?).ini on Windows. So no, it's not git info and you should not even have it in your repo.

Link to comment
Share on other sites
ialdabaoth

ialdabaoth

Posted
  • Author
Posted
Excuse me for asking, but what does this do?

There's actually two mods installed here - one is for users, the other is for developers.

So, you know how certain mods (like FAR and CrewManifest and Kethane and RemoteTech) each need you to modify your stock part.cfg files, and if you wan to install more than one of them you have to figure out yourself how to do it?

ModuleManager fixes that, by letting developers specify what parts of each file need to be modified, and then letting my mod do the actual modification.

That's ModuleManager. ModularFuelTanks is a user-level plugin, that defines several new fuel types:

LiquidH2 (very light, but dissipates over time)

LiquidOxygen (more efficient Oxidizer)

NuclearFuel (nuclear engines use this + LiquidH2 instead of a fuel+oxidizer)

Then, it configures most of the stock fuel tanks so that you can click on that fuel tank in the Action Group window in the VAB, and specify what (and how much) resources to load the fuel tank with. It also lets you click on most of the engines in the Action Group window in the VAB and lets you specify what kind of fuel you want them to use - for example, LiquidFuel+Oxidizer, LiquidFuel+LiquidOxygen, or LiquidH2+LiquidOxygen. Different fuel mixes will adjust the engine's Isp and thrust - LiquidFuel+LiquidOxygen will slightly thrust and Isp, while LiquidH2+LiquidOxygen will significantly increase Isp at the cost of decreasing maximum thrust.

Link to comment
Share on other sites
ialdabaoth

ialdabaoth

Posted
  • Author
Posted

UPDATE: ModuleManager.dll now resides in the root of /GameData, along with gameData.cfg - this is so that other mod authors can distribute ModuleManager.dll without having to muck with the /GameData/Ialdabaoth directory.

This means that /GameData/Ialdabaoth is now entirely the ModularFuelTanks mod, while /GameData/ModuleManager.dll and /GameData/gameData.cfg are now entirely the ModuleManager system.

Here is a ModuleManaged version of Ferram Aerospace, as an example of how to distribute your mod using ModuleManager instead of patching part.cfg files.

Link to comment
Share on other sites
Fel

Fel

Posted
Posted

/me still would like wildcards or other selectors

It is nice that you're working closely with Mu; but as I do most of my own mod handling (meaning even if a mod included a change config file, I'd change the changes) this only makes it easier to uninstall, but not to install.

Link to comment
Share on other sites
Frostiken

Frostiken

Posted
Posted
Dump it all into {KSP}/GameData/

this should result in:


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


{KSP}/GameData/gameData.cfg
{KSP}/GameData/Ialdabaoth/Plugins/ModuleManager.dll

The .DS_Store is GitHub (source control) stuff, you can delete or ignore those.

Outstanding, thank you.

Link to comment
Share on other sites
ialdabaoth

ialdabaoth

Posted
  • Author
Posted
Outstanding, thank you.

One minor update: I've moved ModuleManager.dll to /GameData/ so you don't have to go into /GameData/Ialdabaoth/ (that way the redistributable files stay separate from my own mods)

So now you should just get:


{KSP}/GameData/gameData.cfg
{KSP}/GameData/ModuleManager.cfg

Users still have to do one line of editing whenever they install a new mod; {KSP}/GameData/gameData.cfg needs an include={ModDirectory}/{configFilename.cfg} line for each ModuleManager config file (hopefully this can change for 0.20.1).

Link to comment
Share on other sites
Fel

Fel

Posted
Posted (edited)

WildCards means

PART[cl_*] {

}

to select any part that includes cl_

a selector would be

(crewcapacity) {

}

to select any part that has the variable "crewcapacity"

To note, you aren't CHANGING "crewcapacity" you're just checking to see if the variable is there.

So you wouldn't "Change" the "MODULE[ModuleEngine]"

You would just check to see that is HAS a "ModuleEngine"

*** I tend to think of this like CSS / HTML / RegEx so

http://www.w3.org/TR/CSS2/selector.html

Might be a bit of an example

Edited by Fel
Link to comment
Share on other sites
ialdabaoth

ialdabaoth

Posted
  • Author
Posted
WildCards means

PART[cl_*] {

}

to select any part that includes cl_

a selector would be

(crewcapacity) {

}

to select any part that has the variable "crewcapacity"

To note, you aren't CHANGING "crewcapacity" you're just checking to see if the variable is there.

So you wouldn't "Change" the "MODULE[ModuleEngine]"

You would just check to see that is HAS a "ModuleEngine"

Aha, understood.

I'll think about this for awhile and get back to you.

Link to comment
Share on other sites
Iansoreta

Iansoreta

Posted
Posted

You know what, I have a question before I attempt to do it. The new version of Kerbal Space Program now has separate folders for the stock parts. If you took a closer look at the separate folder, does that mean I can install it from any folder except the folder named "Squad"?

Link to comment
Share on other sites
Fel

Fel

Posted
Posted
Aha, understood.

I'll think about this for awhile and get back to you.

Thanks :)

I know that it is beyond the capabilities of the current ConfigNode system to do "naturally" (At least you can iterate over them; but you might end up having to build a stronger system than is provided.) Yet I think it would greatly complement the system. [Maybe even exceed what 0.20.1 does ;p]

Link to comment
Share on other sites
Frostiken

Frostiken

Posted
Posted (edited)

http://i.imgur.com/cuRBDko.png

Hmm.

EDIT: Never mind. I changed the name of the mod folder to 'ModularFuelTanks' because I didn't trust myself to remember what the hell idraborathrrtarath was. I updated the gamedata.cfg but apparently the plugin is dependent on folder structure.

Question before I start mucking with the modular tanks - how will they function if I later remove the mod?

Edited by Frostiken
Link to comment
Share on other sites
ialdabaoth

ialdabaoth

Posted
  • Author
Posted (edited)

Tanks on existing ships SHOULD keep whatever resources were specified when you configured the tank.

Tanks on new ships will simply operate like normal tanks.

Also! I've removed gameData.cfg altogether; I discovered a technique for pulling all the mod nodes straight from GameDatabase - so you no longer need to maintain a gameData.cfg - from now on, if a mod has any ModuleManager patch nodes, they'll automatically get applied. The ONLY thing you need to make it work is /GameData/ModuleManager.dll.

So, mod authors: if you want to write any kind of mod that needs to change another mod's part.cfg file, just write a .cfg file using the specification in the OP and include /GameData/ModuleManager.dll in your release.

Edit: Fixed a minor bug in the interaction between ModuleManager and ModularFuelTanks. New ModularFuelTanks mod here.

Edited by ialdabaoth
Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...