[1.8-1.9] Modular Fuel Tanks v5.13.1

[taniwha]

Well, last I used it, tweakscale was an evil mess of issues, so I haven't been following it and thus was unaware there was a new one. It seems I need to roll a new KAE, too :/

[futrtrubl]

I have made a MM config thats very useful to convert all tanks for Modular Fuel Tanks. Basically it is adding up fuel recurses present in a PART config.

// Give every PART with a resource a modul ModuleFuelTanks (except PARTS with IntakeAir or a Command Module)
@PART[*]:HAS[!MODULE[ModuleFuelTanks],!MODULE[ModuleCommand],!RESOURCE[IntakeAir],@RESOURCE[*]]:NEEDS[modularFuelTanks]:FIRST
{
	MODULE
	{
		name = ModuleFuelTanks
		volume = 0
		type = Default
	}
}
@PART[*]:HAS[@MODULE[ModuleFuelTanks],@RESOURCE[LiquidFuel]]:NEEDS[modularFuelTanks]
{
	@MODULE[ModuleFuelTanks]
	{
		@volume += #$../RESOURCE[LiquidFuel]/amount$
	}
}

@PART[*]:HAS[@MODULE[ModuleFuelTanks],@RESOURCE[Oxidizer]]:NEEDS[modularFuelTanks]
{
	@MODULE[ModuleFuelTanks]
	{
		@volume += #$../RESOURCE[Oxidizer]/amount$
	}
}
@PART[*]:HAS[@MODULE[ModuleFuelTanks],@RESOURCE[MonoPropellant]]:NEEDS[modularFuelTanks]
{
	@MODULE[ModuleFuelTanks]
	{
		@volume += #$../RESOURCE[MonoPropellant]/amount$
	}
}
//Divide XenonGas tanks by 56
@PART[*]:HAS[@MODULE[ModuleFuelTanks],@RESOURCE[XenonGas]]:NEEDS[modularFuelTanks]
{
	@MODULE[ModuleFuelTanks]
	{
		@volume += #$../RESOURCE[XenonGas]/amount$
		@volume /= 56
	}
}
//Divide LiquidHydrogen tanks by 56
@PART[*]:HAS[@MODULE[ModuleFuelTanks],@RESOURCE[LiquidHydrogen]]:NEEDS[modularFuelTanks]
{
	@MODULE[ModuleFuelTanks]
	{
		@volume += #$../RESOURCE[LiquidHydrogen]/amount$
		@volume /= 56
	}
}
@PART[*]:HAS[@MODULE[ModuleFuelTanks],@RESOURCE[Karborundum]]:NEEDS[modularFuelTanks]
{
	@MODULE[ModuleFuelTanks]
	{
		@volume += #$../RESOURCE[Karborundum]/amount$
	}
}
// If tank volume is still zero than non of the above resources where present and we delete ModuleFuelTanks
@PART[*]:HAS[@MODULE[ModuleFuelTanks]:HAS[#volume[0]]]:FINAL
{
	!MODULE[ModuleFuelTanks] {}
}

Actually those amount$ should be maxAmount$ as there are tanks that are created empty but they are still tanks and take space.

Also Karborundum depends on Karbonite plus mod and so should have KarbPlus added to NEEDS.

You want to divide xenon or liquid hydrogen tanks by 56 but unfortunately you end up dividing them AND all previous tanks by 56. Eg. you have a tank that hold monoporop, xenon and liquid hydrogen. You end up with at tank size equal to monoprop/3136 + xenon/3136 + liquidhydrogen/56. You need to use an intermediate variable there.

Not as important:

You have missed out electriccharge, which takes up space but doesn't give space with your config.

You have Karborundum but not Karbonite etc.

[FreeThinker]

Question, does Modular Fuel tanks have any intention of allowing changing the tanks contents outside the VAB, in other words, in flight?

I myself modified (fireSpitter) FSFuelSwitch to work correctly outside the VAB, allowing them to change in flight after emptying them. I wonder if anyone has attempted to do the same for Modular Fuel Tanks

Edited March 24, 2015 by FreeThinker

[fatcargo]

Now THAT would be GREAT ! Similar functionality already exists in Multipurpose Colony Modules for MKS/OKS , but MFT's resource re-allocation method is way more flexible. I hope plugin authors notice this idea.

Additionally, resource-switching in MCM for OKS/MKS is done via context menus, so it's open to some degree of automatation by kOS, now you can imagine what that would mean.

Edited March 24, 2015 by fatcargo

[taniwha]

I think such is beyond the scope of MFT. One important issue is different resources can require different tank masses.

[FreeThinker]

I think such is beyond the scope of MFT. One important issue is different resources can require different tank masses.

You could simply allow only the resource of the current tank mass, that way you still have some flexibility.

[fatcargo]

You could simply allow only the resource of the current tank mass, that way you still have some flexibility.

Or you could allow switching among resources that require same tank mass or LESS. That way you keep realistic part and make it more flexible.

Hmmm, maybe allowing player to change tank mass in editor by adding a single unit of resource that requires max tank mass (and add all others that are of real interest), thus making it usable for all other resources in flight. BUT, once resource compartments in tank are defined and tank is launched (for exmaple 1234 unit of LF, 4567 units of LOX etc) they STAY locked and can only be used by another resources, their basic volume is fixed.

Another round-about way of doing this would be to drag the whole tank using KAS (or risk recycling the whole vessel) to a MCM skydock and recycle it, then use a "blueprint" from SPH/VAB/subassembly list and rocket parts to recreate it with new resources.

[funk]

I love the idea of switchable resources in flight. I was randomly searching if MFT has the same ability as Firespitter has.

A way to implement this could be as already mentioned to determine the tank mass in VAB/SPH. In flight you could switch to the desired resource, but only up to a max amount, which has a relation to tank mass and/or to previous tank setup, eg for a pressurized resource a tank has max amount of 1000l and a tank mass of 0.5t --> switch to --> non-pressurized resource tank has max amount 1000l (you can use all possible volume) if the tank mass is greater than needed. But a switch in the other direction would mean you can only store 50l of the pressurized resource, because the tank isn't designated to hold pressurized resources.

The issue with Firespitter is, that it doesn't play well with tweakscale and in some cases I don't want all the resources of a predefined tank. So this could help to reduce part count in the editor and could improve gameplay.

[fatcargo]

Now that you mention it, author of Multipurpose Colony Modules for MKS OKS has already solved it for its own resources.

More to the point the "Multipurpose Storage Module" is what we should be looking at.

At a glance the difference is that MCM (an OKS/MKS extension) can only switch among predefined sets of resources (further derived from Regolith framework), but it can do it in-flight (there even was a resolved bug with module type switching lockout because "old" resources were left inside a module).

As for volume limiting, i agree. But i have a problem with the following :

But a switch in the other direction would mean you can only store 50l of the pressurized resource, because the tank isn't designated to hold pressurized resources.

If this happens in-flight, the player could be locked out of efficiently using a tank. The above action should preceeded by a warning dialog or note to player about degrading tank to lower usage.

A side question : i've seen in MKS configs some MM references to MFT, but i've found no editor option "Show UI" for relevant MKS parts. Should MKS provide this ability or do i have a bug in my GameData ?

[funk]

The cfg includes mostly additions to tank definitions of MFT and don't change the part configs. Here http://forum.kerbalspaceprogram.com/threads/91706-0-90-Freight-Transport-Technologies-v0-3-1-2014-12-24?p=1560066&viewfull=1#post1560066 is a cfg for FTT parts, which could be easily rewritten for MKS parts.

I'm thinking of using Wildbluetools for switching resources,too, at least in the VAB/SPH. It's able to switch modules and resources in and out, perhaps it's possible to switch MFTmodules and textures...

Sry for off topic! I think there needs to be a new thread about this.

[fatcargo]

One last bit :

Usually i add new packs and then immediately run game to check what was added and changed (yes, there are "readme" sections but sometimes i find them too obscure for quick addon tests).

Couple of days ago i was adding several plugins and have found new MFT-configurable resources (related to life support) that have been added to parts like fuel tanks. I suspect TAC-LS did this as it has quite extensive MM configs utilizing MFT modules.

To conclude :

I'm aiming at having a tank that can be rescaled, has Regolith/MKS resources and its volume (re)allocated with MFT. And TAC-LC configs came darn close to that. That way, when doing orbital construction at my LKO station, i won't have to add too many resource containers to station, they will be large enough to build entire SOI-to-SOI transfer ships, not capable of surface landing. I just haul one or two mega-sized shipments of rocket parts to station and start building.

In-flight resource reallocation is attractive for players that know how to minimize number of parts for colonies and/or know how to do advanced colony re-tasking. For now, having MFT/Regolith/Tweakscale config in VAB/SPH will do fine for the time being.

The mention of other plugins and off-topic was inevitable since MFT works on such a basic level as resources.

[futrtrubl]

One last bit :

Usually i add new packs and then immediately run game to check what was added and changed (yes, there are "readme" sections but sometimes i find them too obscure for quick addon tests).

Couple of days ago i was adding several plugins and have found new MFT-configurable resources (related to life support) that have been added to parts like fuel tanks. I suspect TAC-LS did this as it has quite extensive MM configs utilizing MFT modules.

To conclude :

I'm aiming at having a tank that can be rescaled, has Regolith/MKS resources and its volume (re)allocated with MFT. And TAC-LC configs came darn close to that. That way, when doing orbital construction at my LKO station, i won't have to add too many resource containers to station, they will be large enough to build entire SOI-to-SOI transfer ships, not capable of surface landing. I just haul one or two mega-sized shipments of rocket parts to station and start building.

In-flight resource reallocation is attractive for players that know how to minimize number of parts for colonies and/or know how to do advanced colony re-tasking. For now, having MFT/Regolith/Tweakscale config in VAB/SPH will do fine for the time being.

The mention of other plugins and off-topic was inevitable since MFT works on such a basic level as resources.

Regolith+ProceduralParts+MFT I would say gives you even more flexibility for tanks.

[fatcargo]

Thanks, i've tested the latest proc part pack and my old problem with displaced attachment nodes seems to have disappeared. I love the Life Support and EL tanks, these will do great !

[Papa_Joe]

Hey all, I have a question I hope has been or is known.

I've read most of the thread, and it would "seem" that the LF/O consumption rate of 0.9/1.1 is a KSP constant.

With that assumption, then all custom resources fall within this Stock behavior? Based on looking at the MM configs, it appears that all fuels and oxidizers map to their stock counterparts...

For example if you create a resource named Methane, and it is used in place of LF, then M/O consumption percentage is still 0.9/1.1, correct?

I'm asking, as I'm preparing to support multi-resource transfers in ShipManifest, and I want to be sure I'm correctly supporting Real Fuels and MFT...

[futrtrubl]

Hey all, I have a question I hope has been or is known.

I've read most of the thread, and it would "seem" that the LF/O consumption rate of 0.9/1.1 is a KSP constant.

With that assumption, then all custom resources fall within this Stock behavior? Based on looking at the MM configs, it appears that all fuels and oxidizers map to their stock counterparts...

For example if you create a resource named Methane, and it is used in place of LF, then M/O consumption percentage is still 0.9/1.1, correct?

I'm asking, as I'm preparing to support multi-resource transfers in ShipManifest, and I want to be sure I'm correctly supporting Real Fuels and MFT...

That would be Real Fuels and not MFT. This just allows you to change tanks, it doesn't add other resources like RF. I believe that even in RF the ratio depends on the fuel/oxidizer combo used, the engine pack used and maybe even the engine used.

[Papa_Joe]

That would be Real Fuels and not MFT. This just allows you to change tanks, it doesn't add other resources like RF. I believe that even in RF the ratio depends on the fuel/oxidizer combo used, the engine pack used and maybe even the engine used.

Thanks! I'll post in the Real Fuels thread and then peruse the code as well.

[NathanKell]

Papa_Joe: It's down to whoever writes the engine cfg (or engine patch cfg); stock engines are generally (but not always) 9:11 LF/Ox, but MFT doesn't make any assumptions, it just pulls from the engine modules themselves. RF uses that same logic, but on the cfg side as mentioned the ratios are all over the map.

[Papa_Joe]

Papa_Joe: It's down to whoever writes the engine cfg (or engine patch cfg); stock engines are generally (but not always) 9:11 LF/Ox, but MFT doesn't make any assumptions, it just pulls from the engine modules themselves. RF uses that same logic, but on the cfg side as mentioned the ratios are all over the map.

Thanks for the feedback!

interesting. Based on that, I'm thinking that using the resource tank sizes to determine ratio may work for my purposes. For example, the LF and Ox tank capacities could be 45/55%, respectively or not. So If I did a calc against the 2 selected resources in the part, I could determine the ratio expected. I'm thinking this would serve the purpose, as it would assure a consistent transfer, based on the source tank ratios. I would then not need to concern myself with the engines, as it would be the responsibility of the ship designer to have the ratios expected of the engine. I'm not so much concerned with the consumption rate as the tank to tank ratios.

This also negates any need to "manage" the ratios, as they are defined within the part...

Edited April 20, 2015 by Papa_Joe

[NathanKell]

Yes, it would make sense to, given a destination part, pull in the ratio the destination part has. Note that the source part may well not have the same ratio (for instance, 2.6:1 kerolox vs 2.23:1 kerolox, err, that's by mass, volumes would be like 65-35 for the former and 60:40 for the latter)

[Whizzkid]

Does this work with 1.0? it is listed as incompatible on the loading screen

[etheoma]

Does this work with 1.0? it is listed as incompatible on the loading screen

No its completely broken as far as I can see, module manger has not disabiled it as it still had the options to remove tanks etc but getting up the console is broken it's not much of a supprise considering we have moved into the official release because a lot of stuff behind the scenes has changed as Beta is for bug fixing and optimization mostly which you can see from the system resources utilization alone that there has been a lot of stuff done under the hood.

This one if he has started already will probably take some time to fix I highly doubt a simply re-compile will suffice, however from now on any updates really shouldn't break nearly every single mod fingers crossed.

Well simple part mod which add new parts are usually fine between releases but anything which add something that taps deeper in than just adding a part with the default mechanics has broken every update, But I would assume they wouldn't do any more deep stuff to KSP anymore, adding new modules and maybe getting a stable 64 bit build will probably be the extent of it.

Maybe weather and other things like that but that shouldn't really break any mods apart from the beatification and visual realism mods, which are nice but they are not integral to game play which now I find things like Modular fuels are, because of silly missing things from the base game like pure liquid fuel mk2 adapters etc.

Also Modular fuels helps to make mods play together nicely.

Edited April 28, 2015 by etheoma

[taniwha]

I have MFT working locally. I will do a release soon.

[Enceos]

I have MFT working locally. I will do a release soon.

You're so awesome !

[taniwha]

Ok, MFT 5.5.0 released.

[etheoma]

Ok, MFT 5.5.0 released.

WOOT WOOT!!! This is SUPER HEALTHY SPACE, Omega good job!!!

Now I only have to wait for FAR and Deadly Reentry and KSP 1.0 will actually be playable.

Then B9, KSPI-E or KSPI-M or perhaps Fractal comes back and that will make KSP fun for me.

Edited May 1, 2015 by etheoma