ialdabaoth

Updated; new modular version appears to work better. (Note that I am in no way affiliated with ferram, and any colossal screw-up on my part should i no way reflect on the excellence and skill of FAR). Managed FAR, now with 20% less weirdness!

oops... I copied a config file wrong. Teach me to work at 4 AM with no sleep... I'll go over everything and make painfully sure that it matches ferram's now. EDIT: AHA! I forgot these lines on each part: @dragModelType = override @maximum_drag = 0 @minimum_drag = 0 @angularDrag = 0 So basically, the one I posted last night applied the default KSP drag PLUS FAR's drag model, which is clearly terribly wrong. I'll test this now side-by-side with FAR's and repost in an hour or so if they're identical.

Yes, I just grabbed the FAR plugin, created a .cfg file, added my ModuleManager, and zipped it up. Install all that straight into GameData, so you have: /GameData/ModuleManager.dll /GameData/gameData.cfg /GameData/FerramAerospaceResearch/FerramAerospace.cfg /GameData/FerramAerospaceResearch/Plugins/FerramAerospaceResearch.dll /GameData/FerramAerospaceResearch/Plugins/FerramGraph.dll /GameData/FerramAerospaceResearch/Plugins/PluginData/FerramAerospaceResearch/FAR.cfg

Here you are: FAR without the part.cfg files, using ModuleManager

Yes! Enjoy!

Hello! This is one of the mods I specifically wrote my ModuleManager for! You can build a compatibility pack without having to edit Squad's files, now.

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.

Ferram - Regarding the windows: could I convince you to do something like I did with one of my mods, and have the control surface configuration window ONLY appear in the ActionGroup editor menu? Here's how I did it: // public void OnGUI() { EditorLogic editor = EditorLogic.fetch; if (!HighLogic.LoadedSceneIsEditor || !editor || editor.editorScreen != EditorLogic.EditorScreen.Actions) return; if (EditorActionGroups.Instance.GetSelectedParts ().Contains (part)) { Rect screenRect = new Rect(0, 365, 430, (Screen.height - 365)); GUILayout.Window (part.name.GetHashCode (), screenRect, engineManagerGUI, "Configure " + part.partInfo.title); } } Using "Rect(0, 365, 430, (Screen.height - 365))" means that the window precisely fills the empty bottom half of the ActionGroups window. Checking "if (!HighLogic.LoadedSceneIsEditor || !editor || editor.editorScreen != EditorLogic.EditorScreen.Actions) return;" means that if the user isn't in the Action Group editor menu, your window doesn't show. Checking "if (EditorActionGroups.Instance.GetSelectedParts ().Contains (part)) {" means that it ONLY shows your window if they've selected your part. This conforms to the UI paradigm that people are already used to: go to the Action Group menu, click on a part, start tweaking it. It means that your control surfaces will "feel like" part of the official game, rather than something tacked on.

Ferram: Have you seen my ModuleManager? I actually designed it with you in mind, so you could apply FAR modules to stock parts without having to override .cfg files. Also, I'm working with Mu to get it incorporated into 0.20.1 so it'll be part of the basic functionality of the game. Instead of editing Squad's part.cfg files, you just create one single file within GameData/FerramAerospaceResearch/ called FerramAerospace.cfg, that looks like this: @PART[AdvancedCanard] { MODULE { name = FARControllableSurface S = 1 AoAmax = 25 MAC = 0.5 AR = 8 e = 0.9 IsSmallCtrlSurf = 0 MidChordSweep = -15 maxdeflect = 15 b_2 = 2 TaperRatio = 0.1 } } @PART[StandardCtrlSrf] { MODULE { name = FARControllableSurface MAC = 0.5 e = 0.9 nonSideAttach = 1 maxdeflect = 20 MidChordSweep = 0 b_2 = 2.8 TaperRatio = 1 } } @PART[airScoop] { MODULE { name = FARBasicDragModel S = 1 upVectorName = forward CdCurve { key = -1 0 key = 0 0.3 key = 1.0 0 } ClCurve { key = -1 0 key = -0.5 -0.03 key = 0 0 key = 0.5 0.03 key = 1 0 } CmCurve { key = -1 0 key = -0.5 -0.01 key = 0 0 key = 0.5 0.01 key = 1 0 } } } @PART[CanardController] { MODULE { name = FARControllableSurface S = 1.76 AoAmax = 30 MAC = 1.1 AR = 2.91 e = 0.8 IsSmallCtrlSurf = 0 MidChordSweep = 20 ctrlaxis = pitch maxdeflect = 20 b_2 = 1.6 TaperRatio = 0.5 } } @PART[deltaWing] { MODULE { name = FARWingAerodynamicModel S = 7 AoAmax = 25 MAC = 2 AR = 3.5 e = 0.75 IsSmallCtrlSurf = 0 MidChordSweep = 22 ctrlaxis = none maxdeflect = 0 b_2 = 3.5 TaperRatio = 0.1 } } @PART[Mark1Cockpit] { MODULE { name = FARControlSys } MODULE { name = FARBasicDragModel S = 4 CdCurve { key = -1 0.05 key = 0.2 0.3 key = 1.0 0.05 } ClCurve { key = -1 0 key = -0.5 -0.03 key = 0 0 key = 0.5 0.03 key = 1 0 } CmCurve { key = -1 -0.1 0 0 key = -0.5 -0.1 0 0 key = 0 -0.1 0 0 key = 0.8660 0 0 0 key = 1 0.1 0 0 } } } @PART[Mark2Cockpit] { MODULE { name = FARControlSys } MODULE { name = FARBasicDragModel S = 6 CdCurve { key = -1 0 key = 0 0.3 key = 1.0 0 } ClCurve { key = -1 0 key = -0.5 -0.03 key = 0 0 key = 0.5 0.03 key = 1 0 } CmCurve { key = -1 0 key = -0.5 -0.01 key = 0 0 key = 0.5 0.01 key = 1 0 } } } @PART[Mark3Cockpit] { MODULE { name = FARControlSys } MODULE { name = FARBasicDragModel S = 9 CdCurve { key = -1 0 key = 0.2 0.3 key = 1.0 0 } ClCurve { key = -1 0 key = -0.5 -0.03 key = 0 0 key = 0.5 0.03 key = 1 0 } CmCurve { key = -1 0 key = -0.5 -0.01 key = 0 0 key = 0.5 -0.01 key = 1 0 } } } @PART[Mark1-2Pod] { MODULE { name = FARControlSys } MODULE { name = FARBasicDragModel S = 16 CdCurve { key = -1 0.25 0 0 key = 0 0.1 0 0 key = 1 0 0 0 } ClCurve { key = -1 0 key = -0.5 -0.03 key = 0 0 key = 0.5 0.03 key = 1 0 } CmCurve { key = -1 -0.1 0 0 key = -0.5 -0.2 0 0 key = 0 -0.3 0 0 key = 0.5 -0.2 0 0 key = 1 -0.1 0 0 } } } @PART[mk1pod] { MODULE { name = FARControlSys } MODULE { name = FARBasicDragModel S = 4 CdCurve { key = -1 0.25 0 0 key = 0 0.1 0 0 key = 1 0 0 0 } ClCurve { key = -1 0 key = -0.5 -0.03 key = 0 0 key = 0.5 0.03 key = 1 0 } CmCurve { key = -1 -0.1 0 0 key = -0.5 -0.2 0 0 key = 0 -0.3 0 0 key = 0.5 -0.2 0 0 key = 1 -0.1 0 0 } } } @PART[smallCtrlSurf] { MODULE { name = FARControllableSurface S = 0.5 AoAmax = 30 MAC = .5 AR = 4 e = 0.9 maxdeflect = 20 nonSideAttach = 1 b_2 = 1 TaperRatio = 1 } } @PART[structuralWing] { MODULE { name = FARWingAerodynamicModel S = 3.06 AoAmax = 30 MAC = 1.7 AR = 2.12 e = 0.7 MidChordSweep = 45 IsSmallCtrlSurf = 0 maxdeflect = 0 b_2 = 1.8 TaperRatio = 0 } } @PART[sweptWing] { MODULE { name = FARWingAerodynamicModel S = 8.33 MAC = 1.7 e = 0.9 IsSmallCtrlSurf = 0 MidChordSweep = 10 ctrlaxis = none b_2 = 4.9 TaperRatio = 0.78 } } @PART[tailfin] { MODULE { name = FARWingAerodynamicModel S = 1.82 AoAmax = 25 MAC = 1.4 AR = 1.86 e = 0.75 IsSmallCtrlSurf = 0 MidChordSweep = 22 b_2 = 1.3 TaperRatio = 0.4 } } @PART[wingConnector] { MODULE { name = FARWingAerodynamicModel S = 5.61 AoAmax = 35 MAC = 3.3 AR = 1.03 e = 0.7 IsSmallCtrlSurf = 0 MidChordSweep = 0 maxdeflect = 0 b_2 = 1.7 TaperRatio = 1 } } @PART[winglet] { MODULE { name = FARWingAerodynamicModel S = 1.65 AoAmax = 35 MAC = 1.1 AR = 3.3 e = 0.7 IsSmallCtrlSurf = 0 MidChordSweep = 25 maxdeflect = 0 b_2 = 1.5 TaperRatio = 0.2 } } @PART[R8winglet] { MODULE { name = FARControllableSurface S = 1.95 MAC = 1.3 e = 0.7 IsSmallCtrlSurf = 0 MidChordSweep = 10 maxdeflect = 15 b_2 = 1.5 TaperRatio = 0.6 } } @PART[winglet3] { MODULE { name = FARControllableSurface S = 2.1 MAC = 1.4 e = 0.6 IsSmallCtrlSurf = 0 MidChordSweep = 15 maxdeflect = 15 b_2 = 1.5 TaperRatio = 0.6 } } It basically lets you apply a "patch" to part configNodes, replacing any value or node specified by a @NODE[name] {...}, deleting any value or node specified by !NODE[name] {}, and adding any value or node specified the normal way by NODE {name=...}

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.

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.

It is. I fixed it. Also: updated the .zip to include a config file that applies ModularFuelTanks data to KSPX parts.

That is, in fact, its primary purpose.

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

Of course, all of this depends on having a brain that comprehends the concept of "discreteness", which may not be necessary. It might be possible to construct valid mathematical systems that operate entirely on principles of continuum, with no capacity for "counting".

What does your REMOVE node look like? It should look something like this: PartName { REMOVE { RESOURCE = resourceName MODULE = moduleName } } Paste your .cfg file and I'll try debugging it.

Neither do I, in principle... in practice, all I can do to make it work is call the function and then hope that .20 fixes the problem. That's basically the reason. I intend to add a bit to the Settings menu to allow users to select alternate .cfg sets.

That would all be amazing, but unfortunately there are limitations to 0.19's resource definition system (namely, I can't really extend it or even iterate through it). I MAY be able to detect if a resource is undefined, and if so remove it; but note that even the main game isn't that fault-tolerant.

No, although that would be cooler. I mean that in the VAB, you can click on an engine and set it to use different blends of fuel, each of which has a predefined Isp and Thrust rating.

You're right. I need to rebalance the NTR's.

Done! The "Configure to {ratio} for {engine}" button is now a "Configure remaining volume to {ratio} for {engine}" button; if you want to configure the whole tank, click "remove all tanks" before clicking "configure to {ratio} for {engine}". As for figuring out volume and basemass, volume is just fuel+oxidizer like you said. I tend to put basemass at 0.0003125 * volume, and then set the volume for LF and Ox at 0.0003125, because this adds up to the amount that KSP set for their tanks (which is 0.00625 * volume) while allowing H2 tanks to be a bit lighter.

Funny enough, it DOES handle that "simplified" method - I'll edit the OP to note that.

Update: Modular Fuel Tanks has now been updated to use the Module Manager; from now on, use the Module Manager download link to download both plugins.

UPDATE: Link unchanged, but I've fixed a few bugs, and added config files for the following mods: stock KSP ModularFuelTanks KW Rocketry RemoteTech IonCrossLSS KSPX Also, the ModularFuelTanks plugin is now included with the release.

Use FXMonger.Explode() instead of part.explode and you don't need to spawn new parts.