Jump to content

[1.8-1.9] Modular Fuel Tanks v5.13.1

taniwha

By taniwha
in KSP1 Mod Releases

 Share

Recommended Posts

AccidentalDisassembly

AccidentalDisassembly

Posted
Posted (edited)
No, MFT will continue to remove unlisted resources. What I was proposing was making it so that tanks could have resources that cannot be edited.

It really is quite feasible to add every possible resource a command pod might have: stock pods have only ElectricCharge and MonoPropellant. Non-stock pods that add other resources can accept their responsibility and add those resources to the relevant tank definition. The same goes for mods like TAC-LS that add other resources.

The problem is that TAC-LS needs to determine if you have other mods too, like DRE, and ALSO add those resources to its tank types - so TAC-LS would have to make a tank type for every conceivable combination of mods that add stuff to command pods. The minute you have more than one mod with more than one resource, things get messy. But adding an option to just "keep = thisresource" or something would make all of that much easier, or having two different types of MFT tanks: one that replaces, one that just adds. Otherwise, what happens when putting MFT first in the application of MM patches and adding RESOURCE{} stuff after it? Maybe that would work?

Edited by AccidentalDisassembly
Link to comment
Share on other sites
techno65535

techno65535

Posted
Posted

So, I'm trying to make an MM config to add electric charge back to the command pods when using MFT and TACLS. Made a definition and a config to add it but it's either I manage to add in electric charge while removing the lifesupport tanks, or it doesn't. Not sure what I'm doing wrong at this point.

TANK_DEFINITION
{
	name = ElectricCharge
	basemass = -1
	TANK
	{
		name = ElectricCharge
		amount = full
		maxAmount = 100%
	}

@PART[*]:HAS[#CrewCapacity[1],@MODULE[ModuleCommand]]:Final
{
	MODULE
	{
		name = ModuleFuelTanks
		type = ElectricCharge
		basemass = -1
		volume = 250
	}
}

@PART[*]:HAS[#CrewCapacity[2],@MODULE[ModuleCommand]]:Final
{
	MODULE
	{
		name = ModuleFuelTanks
		type = ElectricCharge
		basemass = -1
		volume = 350
	}
}

@PART[*]:HAS[#CrewCapacity[3],@MODULE[ModuleCommand]]:Final
{
	MODULE
	{
		name = ModuleFuelTanks
		type = ElectricCharge
		basemass = -1
		volume = 450
	}
}

@PART[*]:HAS[#CrewCapacity[4],@MODULE[ModuleCommand]]:Final
{
	MODULE
	{
		name = ModuleFuelTanks
		type = ElectricCharge
		basemass = -1
		volume = 550
	}
}

@PART[*]:HAS[#CrewCapacity[5],@MODULE[ModuleCommand]]:Final
{
	MODULE
	{
		name = ModuleFuelTanks
		type = ElectricCharge
		basemass = -1
		volume = 650
	}
}

@PART[*]:HAS[#CrewCapacity[6],@MODULE[ModuleCommand]]:Final
{
	MODULE
	{
		name = ModuleFuelTanks
		type = ElectricCharge
		basemass = -1
		volume = 750
	}
}

Should probably mention this is my first time trying to make an MM config. Crossposting with MM thread.

Link to comment
Share on other sites
fatcargo

fatcargo

Posted
Posted

Taniwha, i have a problem with multiple ModuleManager entries referencing same parts causing them to have multiple MFT items in context menu. Parts are from Space Plane Plus package which is now under Squad's parts folder.

In following example, in MM patch file "Squad_modularFuelTanks.cfg" there are 3 different entries :


@PART[mk2SpacePlaneAdapter]
{
	//!RESOURCE[LiquidFuel] {}
	//!RESOURCE[Oxidizer] {}
	//!RESOURCE[MonoPropellant] {}
	MODULE
	{
		name = ModuleFuelTanks
		volume = 80
		type = Fuselage
	}
}

@PART[mk2SpacePlaneAdapter]
{
	MODULE
	{
		name = ModuleFuelTanks
		volume = 300
		type = Default
	}
}

@PART[mk2SpacePlaneAdapter]
{
	MODULE
	{
		name = ModuleFuelTanks
		volume = 300
		type = Default
	}
}

And in MM patch file "SPP.cfg" :


@PART[mk2SpacePlaneAdapter] { 
    MODULE { 
        name = ModuleFuelTanks
        volume = 300
        type = Default
    }

}

This causes part to have MFT context menu items with varying available units of space and selecting two out of 4 "remove all" items causes remaing two to stay "stuck" in menu.

Have a look :

1JOrZmT.png

So, which patch is the right one ? There are several parts with similar (mostly two identical entries per part) problems.

Link to comment
Share on other sites
AccidentalDisassembly

AccidentalDisassembly

Posted
Posted

Here is a link to an updated Squad_modularFuelTanks.cfg that I made. It removes duplicate entries with former SPP parts and merges everything from SPP into it. Can remove SPP.cfg entirely with this version.

Link: https://dl.dropboxusercontent.com/u/59567837/Squad_modularFuelTanks.cfg

Link to comment
Share on other sites
NonWonderDog

NonWonderDog

Posted
Posted (edited)

I think we can actually replace most of the config files with this now:


// generic tank replacement
@PART[*]:HAS[@RESOURCE[LiquidFuel],@RESOURCE[Oxidizer],!MODULE[ModuleFuelTanks]]:FINAL {
    MODULE {
        name = ModuleFuelTanks
        volume = #$../RESOURCE[LiquidFuel]/maxAmount$
        @volume += #$../RESOURCE[Oxidizer]/maxAmount$
        type = Default
    }
}

@PART[*]:HAS[@RESOURCE[LiquidFuel],!RESOURCE[Oxidizer],!MODULE[ModuleFuelTanks]]:FINAL {
    MODULE {
        name = ModuleFuelTanks
        volume = #$../RESOURCE[LiquidFuel]/maxAmount$
        type = Fuselage
    }
}

@PART[*]:HAS[@RESOURCE[MonoPropellant],!MODULE[ModuleCommand],!MODULE[ModuleFuelTanks]]:FINAL {
    MODULE {
        name = ModuleFuelTanks
        volume = #$../RESOURCE[MonoPropellant]/maxAmount$
        type = RCS
    }
}

@PART[*]:HAS[@RESOURCE[XenonGas],!MODULE[ModuleFuelTanks]]:FINAL {
    MODULE {
        name = ModuleFuelTanks
        volume = #$../RESOURCE[XenonGas]/maxAmount$
        type = Xenon
    }
}

@PART[*]:HAS[@MODULE[ModuleFuelTanks],@MODULE[ModuleEngines]]:FINAL {
    @MODULE[ModuleFuelTanks] {
        %basemass = -1
    }
}

@PART[*]:HAS[@MODULE[ModuleFuelTanks],@MODULE[ModuleEnginesFX]]:FINAL {
    @MODULE[ModuleFuelTanks] {
        %basemass = -1
    }
}

@PART[*]:HAS[@MODULE[ModuleFuelTanks]]:FINAL {
    !MODULE[FSfuelSwitch] {}
}

I'm still working out all the files I need to change, nosecones, special tanks and the like. I haven't tested this yet.

EDIT: It should work as a patch to existing installs now.

Edited by NonWonderDog
Link to comment
Share on other sites
AccidentalDisassembly

AccidentalDisassembly

Posted
Posted (edited)
I think we can actually replace most of the config files with this now:


// generic tank replacement
@PART
[*]:HAS[@RESOURCE[LiquidFuel],@RESOURCE[Oxidizer],!MODULE[ModuleFuelTanks]] {
    MODULE {
        name = ModuleFuelTanks
        volume = #$../RESOURCE[LiquidFuel]/amount$
        volume += #$../RESOURCE[Oxidizer]/amount$
        type = Default
    }
}

@PART
[*]:HAS[@RESOURCE[LiquidFuel],!RESOURCE[Oxidizer],!MODULE[ModuleFuelTanks]] {
    MODULE {
        name = ModuleFuelTanks
        volume = #$../RESOURCE[LiquidFuel]/amount$
        type = Fuselage
    }
}

@PART
[*]:HAS[@RESOURCE[MonoPropellant],!MODULE[ModuleFuelTanks]] {
    MODULE {
        name = ModuleFuelTanks
        volume = #$../RESOURCE[MonoPropellant]/amount$
        type = RCS
    }
}

@PART
[*]:HAS[@RESOURCE[XenonGas],!MODULE[ModuleFuelTanks]] {
    MODULE {
        name = ModuleFuelTanks
        volume = #$../RESOURCE[Xenon]/amount$
        type = Xenon
    }
}

I'm still working out all the files I need to change, nosecones, special tanks and the like. I haven't tested this yet.

EDIT: It should work as a patch to existing installs now.

That sounds like a good idea! I am not familiar enough with regex (?) to interpret some of what's in there, but I assume there would also be a way to replace a xenon tank with the "Default" tank type by dividing the amount of XenonGas present in a part by 56 (I think) to get the right volume for liquid fuel / oxidizer...? And to do the same for things like NearFuture resources (divide LiquidHydrogen by 2.5, I think, ArgonGas by something crazy), and really anything else?

Reason I ask is because I've patched the Default tank type to be pretty much universal - can have ElectricCharge, Xenon, ArgonGas, Karbonite, Metal, RocketParts, etc. etc.

It would be really cool to have just one config like that, matched to volumes/densities/whatever as laid out in CRP or some such.

Edited by AccidentalDisassembly
Link to comment
Share on other sites
NonWonderDog

NonWonderDog

Posted
Posted (edited)

Alright, this didn't actually take very long (I'm glad I learned Vim).

Delete every .cfg except for MFSSettings.cfg and Propellants.cfg from your ModularFuelTanks directory, and drop in the "Tanks" folder below. You can just leave it as a subdirectory ('ModularFuelTanks/Tanks/zzGeneric.cfg', etc.).

http://www./download/iu9p1ds2rtc2y8e/GenericModularFuelTanks.zip

This should have exactly the same tanks as before, but will also apply generic Modular Fuel Tanks to every tank from every mod that isn't already covered.

This uses the variable support that was added to ModuleManager recently. Basically, ModuleManager can now read config files as well as just edit them. This config tells it to find out how much fuel, oxidizer, monoprop, or xenon each part carries, and to generate a modular fuel tank of that size.

Edited by NonWonderDog
Link to comment
Share on other sites
AccidentalDisassembly

AccidentalDisassembly

Posted
Posted

So would this do what I'm looking for? Which is:

1. Find a part with LiquidHydrogen in it

2. Apply MFT to that part, but

3. Set the "volume" of the MFT tank to be the amount of LiquidHydrogen divided by 2.5:

@PART

[*]:HAS[@RESOURCE[LiquidHydrogen],!MODULE[ModuleFuelTanks]] {

MODULE {

name = ModuleFuelTanks

volume = #$../RESOURCE[LiquidHydrogen]/amount$

volume /= 2.5

type = Default

}

}

Reasoning being that LiquidHydrogen, for better or worse, seems to have about 2.5 times the units in the same volume as something with liquid fuel (so that it will balance about right with NFT tanks)

Link to comment
Share on other sites
NonWonderDog

NonWonderDog

Posted
Posted
So would this do what I'm looking for? Which is:

1. Find a part with LiquidHydrogen in it

2. Apply MFT to that part, but

3. Set the "volume" of the MFT tank to be the amount of LiquidHydrogen divided by 2.5:

That should do it. You probably want to define a cryogenic tank for that, though.

Link to comment
Share on other sites
AccidentalDisassembly

AccidentalDisassembly

Posted
Posted (edited)

Not sure what the difference between a cryogenic tank and other tank is (in real life I understand, but not in KSP), but here's what I've come up with.

The reasoning behind the numbers is to approximate the amount of Xenon, Argon, or Liquid Hydrogen you get in a Near Future tank when compared to a stock tank of the same volume. This necessitates changing MFT's Xenon utilization to 14.5 rather than 56 (!). The 56 number is based exclusively (I think) on the small stock stackable Xenon tank, and is wildly more than you get in the same volume from a NFT tank. Opinions may vary on the right numbers.

I use the Default tank type because I have patched it using an MM config to include NearFuture, EPL, and maybe some more resources - slight mass penalty for stuff like LiquidHydrogen or ArgonGas that probably need a bit more robust tanks (or cryogenic or whatever) to store.

I added :Final to all of this because I figure that way, if I forget to delete any configs, these will run last and the check for !MODULE[ModuleFuelTanks] will avoid accidental duplication. Some mods have their own MFT definitions in their own directories, so I thought the MFT directory and its patches might get applied first, etc. etc.

// generic tank replacement

@PART

[*]:HAS[@RESOURCE[LiquidFuel],@RESOURCE[Oxidizer],!MODULE[ModuleFuelTanks]]:Final {

MODULE {

name = ModuleFuelTanks

volume = #$../RESOURCE[LiquidFuel]/amount$

volume += #$../RESOURCE[Oxidizer]/amount$

type = Default

}

}

@PART

[*]:HAS[@RESOURCE[LiquidFuel],!RESOURCE[Oxidizer],!MODULE[ModuleFuelTanks]]:Final {

MODULE {

name = ModuleFuelTanks

volume = #$../RESOURCE[LiquidFuel]/amount$

type = Default

}

}

@PART

[*]:HAS[@RESOURCE[LiquidHydrogen],!MODULE[ModuleFuelTanks]]:Final {

MODULE {

name = ModuleFuelTanks

volume = #$../RESOURCE[LiquidHydrogen]/amount$

volume /= 2.5

type = Default

}

}

@PART

[*]:HAS[@RESOURCE[ArgonGas],!MODULE[ModuleFuelTanks]]:Final {

MODULE {

name = ModuleFuelTanks

volume = #$../RESOURCE[ArgonGas]/amount$

volume /= 16.5

type = Default

}

}

@PART

[*]:HAS[@RESOURCE[MonoPropellant],!MODULE[ModuleCommand],!MODULE[ModuleFuelTanks],!MODULE[ModuleDockingNode]]:Final {

MODULE {

name = ModuleFuelTanks

volume = #$../RESOURCE[MonoPropellant]/amount$

type = RCS

}

}

@PART

[*]:HAS[@RESOURCE[XenonGas],!MODULE[ModuleFuelTanks]]:Final {

MODULE {

name = ModuleFuelTanks

volume = #$../RESOURCE[Xenon]/amount$

volume /= 14.5

type = Default

}

}

@PART

[*]:HAS[@MODULE[ModuleFuelTanks],@MODULE[ModuleEngines]]:Final {

@MODULE[ModuleFuelTanks] {

%basemass = -1

}

}

@PART

[*]:HAS[@MODULE[ModuleFuelTanks],@MODULE[ModuleEnginesFX]]:Final {

@MODULE[ModuleFuelTanks] {

%basemass = -1

}

}

Edited by AccidentalDisassembly
Link to comment
Share on other sites
NonWonderDog

NonWonderDog

Posted
Posted (edited)

Hmm... ModuleManager tells me that my generic file has 77 errors, which is impressive since there are only 45 lines. It doesn't tell me what any of those errors are, though...

"RESOURCE[Xenon]" should read "RESOURCE[XenonGas]". That fixes 8 of them.

"volume += #$../RESOURCE[Oxidizer]/amount$" needs a '@' in front of it. That's the rest of them -- it wasn't adding the Oxidizer volume to the modular tank.

I did have to add ":FINAL" to the generic config for mod compatibility, as well. The proper way would be for the other mods to use '%MODULE[ModuleFuelTanks]' to override the generic tank if necessary, but that's not going to happen.

I've updated my zip: http://www./download/iu9p1ds2rtc2y8e/GenericModularFuelTanks.zip

I think I might end up branching either this or RealFuels on GitHub and trying to make a generalized 6.4x-focused NearFuels out of it.

Edited by NonWonderDog
Link to comment
Share on other sites
NathanKell

NathanKell

Posted
Posted

NonWonderDog: MM reports the number of times *applying* the patch errors out, not how many errors are in the patch. That means it failed for 77 attempts (and there's what, 9 patches in the file? So something like 8 parts it failed on?)

Also, be careful: MFT will change the mass of parts it's applied to unless you tell it not to, so parts that should keep their dry mass (like service modules, pods, etc) need special handling.

Link to comment
Share on other sites
AccidentalDisassembly

AccidentalDisassembly

Posted
Posted
NonWonderDog: MM reports the number of times *applying* the patch errors out, not how many errors are in the patch. That means it failed for 77 attempts (and there's what, 9 patches in the file? So something like 8 parts it failed on?)

Also, be careful: MFT will change the mass of parts it's applied to unless you tell it not to, so parts that should keep their dry mass (like service modules, pods, etc) need special handling.

Sorry if this is a dumb question, but just to make sure I understand: let's say I apply the "Default" TANK_DEFINITION to a part. It has within it "basemass = 0.000625 * volume", so that means that anything with that MFT definition applied to it will have this new base mass, right? Not that this basemass = X will be added to the part, but instead it will be recalculated? And then specific TANK definitions could also add mass, like:

TANK

{

blah blah blah

mass = 0.000625 // adds 0.000625 tons per unit of volume, so every 1,000 liquid fuel capacity (for ex.) would add an ADDITIONAL 0.625 tons to the basemass = 0.000625*volume thing

}

Is all of that correct?

Link to comment
Share on other sites
AccidentalDisassembly

AccidentalDisassembly

Posted
Posted

OK, found the source of at least SOME of the errors in that MM config - one bit needs an @:

@PART

[*]:HAS[@RESOURCE[LiquidFuel],@RESOURCE[Oxidizer],!MODULE[ModuleFuelTanks]]:Final {

MODULE {

name = ModuleFuelTanks

volume = #$../RESOURCE[LiquidFuel]/amount$

@volume += #$../RESOURCE[Oxidizer]/amount$

type = Default

}

}

Link to comment
Share on other sites
NathanKell

NathanKell

Posted
Posted

AccidentalDisassembly: correct. When basemass is not set to (in the TANK_DEFINITION) nor overridden (in the MODULE) to -1, then MFT will set the mass of any part it is added to as:

basemass + SUM(for each tank, tank.maxAmount / tank.utilization * tank.mass)

When basemass is -1, MFT does not mess with mass.

basemass can be set via one of two forms: if it is just a number, that is the basemass in tons; if it is given as some_number * volume, then the basemass of the part will be that product.

Link to comment
Share on other sites
NonWonderDog

NonWonderDog

Posted
Posted
OK, found the source of at least SOME of the errors in that MM config - one bit needs an @:

I'd updated my post #366 a few times yesterday to say I'd fixed all the ModuleManager errors, sorry if you wasted time looking for them.

Also, be careful: MFT will change the mass of parts it's applied to unless you tell it not to, so parts that should keep their dry mass (like service modules, pods, etc) need special handling.

Understood, but I still think it's better to support all tanks by default and call out special cases as they come up than to leave everything unsupported until someone gets around to fixing it, especially if I end up adding CRP resources as I'm currently trying to spec out.

Link to comment
Share on other sites
mreadshaw

mreadshaw

Posted
Posted

Awesome mod! So very useful. One question though, whenever I see this mod in a video they always talk about how you can auto-configure the tanks based on engines but I don't seem to have that option. Was the feature removed or is something wrong with my install?

Link to comment
Share on other sites
mreadshaw

mreadshaw

Posted
Posted

Hmm not coming up for me. I've tried on both my modded install and my stock backup and neither one gives me the option. I'll try again with a complete re-download from steam to make sure that my backup isn't messed up someway. Otherwise the mod works flawlessly, The UI comes up and everything can be hand edited just fine.

Link to comment
Share on other sites
rynak

rynak

Posted
Posted (edited)

What's the reason for the MK1 fuselage not showing the option in SPH to edit the fuel types?

I looked through the configfiles, but found nothing unusual specified about them. Is this hardcoded into the plugin?

EDIT: Nevermind, my mistake. The part wasn't the stock one.

Edited by rynak
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
 Share
Go to topic listing
×
×
  • Create New...