[1.8-1.9] Modular Fuel Tanks v5.13.1

[taniwha]

Thanks, I've pushed it to github.

[phoenix_ca]

Why do the tank definitions have what appear to be useless arrays? Like these three for the Fuselage type:

TANK
{
name = Oxidizer
amount = 0.0
maxAmount = 0.0
}
TANK
{
name = MonoPropellant
amount = 0.0
maxAmount = 0.0
}
TANK
{
name = XenonGas
amount = 0.0
maxAmount = 0.0
utilization = 56.0
note = (pressurized)
}

Those appear to define fuels, but at the same time limit maxAmount to 0 for them effectively making them unnecessary. Unless I'm missing something here. If I'm right though, then it's just a lot of extraneous text that doesn't need to be there and only serves to make the tank definitions harder to read.

Edit: And a short description of the mod and what it does would be nice in the OP. It actually took me a while to figure-out what it is intended to do.

Edited May 14, 2014 by phoenix_ca

[taniwha]

They're not useless: you cannot add random resources to a tank (the tank must support the resource). Those maxAmount = 0 entries define the support but set the default amount to 0.

[phoenix_ca]

Well that's confusing naming. O.o

[ExavierMacbeth]

I don't know if this has been asked but I couldn't find an answer.

Is there a way to define a custom split configuration? For example you have by default the very convenient button that automatically fills Liquid Fuel & Oxidizer 45/55.

It would be useful for things like life support or other mods that add alot of extra resources to have set balanced configs. Manually setting up a tank to hold a little bit of each life support resources (6 total for TAC if you want it hold a little of everything and their byproducts) can get a little tedious. Would be nice to be able to hit 1 button and get 16% of all 6 instantly

[phoenix_ca]

I'm still confused. A "maxAmount = 0" line doesn't lock the maximum amount of the fuel in the tank to 0 units, it actually locks it to 100% but doesn't start the tank with it. Why isn't that just controlled by "amount"? Or why don't those entries I presented before read "maxAmount = 100%"? If I read things correctly, since they come after the Liquid Fuel and Oxidizer arrays the maxAmounts adding to more than 100% gets ignored.

This is all still very confuddling. If I understand you right taniwha, that means that when "maxAmount = 0" it doesn't actually mean the max amount of that fuel is 0, but 100%. It's breaking my brain.

Edited May 15, 2014 by phoenix_ca

[MrWizerd]

I'm still confused. A "maxAmount = 0" line doesn't lock the maximum amount of the fuel in the tank to 0 units, it actually locks it to 100% but doesn't start the tank with it. Why isn't that just controlled by "amount"? Or why don't those entries I presented before read "maxAmount = 100%"? If I read things correctly, since they come after the Liquid Fuel and Oxidizer arrays the maxAmounts adding to more than 100% gets ignored.

This is all still very confuddling. If I understand you right taniwha, that means that when "maxAmount = 0" it doesn't actually mean the max amount of that fuel is 0, but 100%. It's breaking my brain.

TANK_DEFINITION
{
    name = Default
    basemass = 0.000625 * volume
    TANK
    {
        name = LiquidFuel
        amount = full
        maxAmount = 45%
    }
    TANK
	{
		name = LqdMethane
		amount = 0.0
		maxAmount = 0.0
	}
    TANK
    {
        name = Oxidizer
        amount = full
        maxAmount = 55%
    }
//snip...

When you set the maxAmount to equal something more than 0 than the tank will default to have that amount of fuel. So when you look at the default tank scheme from my tanktypes you will notice that the LiquidFuel and Oxidizer are at a 45% and 55% respectively, this is due to the fact that default tanks will start with a default split of 45%/55%. Basically maxAmount=max Starting Amount. So if I were to say want all my default tank types to start with 10% monopropellant I could change the maxAmount fields on LiquidFuel and Oxidizer to 40%/50% and then change the monopropellant to 10% from the default 0. this will give any tank with the "default" tank type tab 40%/50%/10% when you put it on your ship in the VAB. So if you think of it as the maxStartingAmount it makes a little more sense I guess, if I am right it also allows those tank types to use that resource type(i.e. add a tank for that resource in the GUI). I see were your getting confused, I had to think about it when I was redoing my tanktypes.cfg to have all the resources from KSPI. Now I don't know if this is something that is set in the game, or in the mod, I just know how it relates to the parts in game.

If I am wrong, I am sure that someone much more knowledgeable than me can correct me I am still learning a lot about the modding process.

Edited May 15, 2014 by MrWizerd

[NathanKell]

In a TANK node, amount and maxAmount control, respectively, the default amount and maxAmount of the resource in the tank. They are given as they are to correspond *exactly* with the amount and maxAmount in the RESOURCE node that MFT will create from the TANK entry.

However, so as to support proportional amounts, MFT will allow you to specify a percentage in the maxAmount field. Instead of specifying an maxAmount for that RESOURCE in units, it will specify it as a proportion of the total volume available in the part.

Further, due to this added support, amount behaves somewhat differently than in a RESOURCE node. Instead of requiring you to specify exactly the number of units the RESOURCE will have, it instead is read as a portion of maxAmount. amount = 1.0 (or amount = full) means that the RESOURCE's amount will be set equal to its maxAmount. At 0.5, it will be half full; etc.

[phoenix_ca]

Basically maxAmount=max Starting Amount.

Goodness! Then why isn't it called that? Calling the variable startingAmount would be much clearer.

...or at least that's what I thought, until Nathan confused me again. O.o Because from what you're saying, wouldn't that mean that whenever maxAmount = 0, that resource cannot take any more volume than 0% of the tank's volume?

Or am I just confused by my experience with Python where naming variables and functions isn't nearly this arbitrary?

[NathanKell]

phoenix_ca: those are *default values*. Each TANK, because it is essentially a wrapper for a RESOURCE, has an amount and a maxAmount. You know RESOURCE nodes in part cfgs have amount and maxAmount values? Well, so do TANKs, because TANKs are wrappers for RESOURCEs. While the various other values in the TANK are permanent, amount and maxAmount are merely the default values used when converting the TANK to a RESOURCE. You can make them whatever you like ingame.

I don't get why you think this is arbitrary: you have to think of a TANK as, essentially, a wrapper for the RESOURCE node in a cfg.

[Tiron]

Goodness! Then why isn't it called that? Calling the variable startingAmount would be much clearer.

...or at least that's what I thought, until Nathan confused me again. O.o Because from what you're saying, wouldn't that mean that whenever maxAmount = 0, that resource cannot take any more volume than 0% of the tank's volume?

Or am I just confused by my experience with Python where naming variables and functions isn't nearly this arbitrary?

Quite simply, they're the resource arrays for each possible resource you can put in them. The presence of the nodes indicates that it's possible to put that resource in the tank, the maxamount=0 simply means that you haven't actually added a tank for that resource.

The amounts in the .cfg files are the default tank setup. If the ones set to 0 weren't present, you'd have to somehow add the node in order to change the tank setup. Changing the nodes in the file normally requires a database reload, so it's probably just a workaround because of the way KSP loads parts.

Edited May 16, 2014 by Tiron

[phoenix_ca]

My confusion is coming from the entry "maxAmount" not actually meaning "maximum amount". In a stock RESOURCE node, the maxAmount value means "maximum number of units of this resource that can be stored". With MFT, the same maxAmount value means "the default starting amount". Hence the confusion. It is poorly named. I can appreciate that from a programming standpoint this might make a lot of sense, especially if you have knowledge of the code being used (as you described this as a sort of wrapper), but from a usability standpoint...I'm not seeing it. It's very, very confusing to have the value be named one thing but mean another.

It actually might be worthwhile to add your own values that are clearer about what they actually do, and then handle that in the plugin by renaming them internally if you have to. If only to avoid this sort of confusion between TANK nodes and RESOURCE nodes, which have values that are named exactly the same, but mean something entirely different.

[NathanKell]

No, they really don't mean something entirely different. In fact, they mean the same thing. Let me try again.

You get that TANK is a wrapper for RESOURCE, right? It's like a RESOURCE node with some extra information. If you open a saved craft (or your SFS file) you will see all the various TANKs in your tank part, with their correct amounts and maxAmounts. When you edit the TANK in a TANK_DEFINITION, however, you are editing the default values. Then, and only then, can amount and maxAmount do some extra helpful things. But then and always, they correspond (and thus share the name) with those in RESOURCE nodes (that are, in fact, generated from TANK nodes).

[phoenix_ca]

I think I understand what you're saying (finally), but you still have values that mean two different things depending on the circumstances surrounding them. I find that very confusing. It's something I've always avoided as if it were the black plague in any code I've written, because it inevitably leads to confusion.

Unless because of some weird KSP vagaries it's impossible to do, I don't see what would be lost by making that value more specific, so it is clearer about what changing it does.

Edited May 16, 2014 by phoenix_ca

[taniwha]

phoenix_ca: thare are no dual meanings.

(note, in the following, bold text indicates keywords in the cfg files)

For any part that has a ModuleFuelTanks MODULE node, MFT deletes any RESOURCE nodes that are present. It then goes through the TANK_DEFINITION specified by the MODULE node's type entry, adding any RESOURCE nodes for each TANK with non-zero maxMamount. Those RESOURCE nodes have their maxAmount value set to reflect the maxAmount value in the TANK node (if %, then percent of total tank volume (as specified in the MODULE node), otherwise as-is). MFT then sets the RESOURCE's amount value appropriately for the TANK's amount: % is percentage of maxAmount, full is equivalent to 100%, or an absolute value (bounded to be inclusively between 0 and maxAmount).

Now, if there is no TANK node in the TANK_DEFINITION, then MFT does not allow that resource to be added to the tank. So the way to allow optional resources is to provide TANK nodes with a maxAmount of 0, as these will not cause RESOURCE nodes to be added to the part.

[phoenix_ca]

I don't suppose there's any chance of explaining this in...any documentation? The readme doesn't cover it in detail (note the link to the readme in the OP is dead), and Taranis' post only says what it is, not how it works.

I'm going to have to draw a flow-chart to get a grasp on this logic though. O.o (Sorry, but I can't decipher what you're trying to say. I appreciate you trying though. )

Edited May 16, 2014 by phoenix_ca

[PolecatEZ]

1. MF parses the PART configs for everything.

2. If it sees a resource it recognizes (as defined in its own config), it deletes that resource module and uses its own logic.

3. The MaxAmount of the deleted resource(s) on the part becomes the default MaxAmount total for any modular resources that can be used. If multiple resources were deleted, these are added up.

4. Specific Parts can have a config over-ride defined, MF will use those settings instead of the Max Amount it calculated based on the original part's Max Amount. Often these are the same thing, but can be tweaked.

5. The override config can also define a Tank type (TANK_DEFINITION), which restricts which fuels can be placed and/or adds multipliers (and/or base additives) to the mass or volume of the fuel when put in that tank...the total of which cannot exceed the "MaxAmount" as defined or calculated.

[Tiron]

I don't suppose there's any chance of explaining this in...any documentation? The readme doesn't cover it in detail (note the link to the readme in the OP is dead), and Taranis' post only says what it is, not how it works.

I'm going to have to draw a flow-chart to get a grasp on this logic though. O.o (Sorry, but I can't decipher what you're trying to say. I appreciate you trying though. )

I see what you're having trouble with now.

The thing you have to remember here is that MFT is a mod, not part of the default game. The reason it's 'maxAmount' and not something else... is because that's what it is in the default game, which isn't designed for modifiable tanks. It's the maximum storable amount for *that particular resource*, not the tank as a whole. The default game doesn't even need to *consider* the volume of the tank as a whole, just how much of each particular resource can be held.

The key thing you have to remember is that as a general rule, anything within a pair of { } brackets is self-contained. They're called 'modules' for a reason: they may affect other things, but what goes in the brackets is, as a general rule, its own thing, independent of other modules. The way to read it is as 'Tank for Resource <x>, which can hold a maximum of <y> units, and presently holding <z> units.'

It may help to think in terms of a real rocket, which inside a given stage has to has a separate tank for each thing it wants to store. They may share a bulkhead to save weight, but they're independent volumes. In our case it doesn't help that there's two different types of 'tank' going on: the structural container around the outside, and the actual storage area inside it are both called 'tanks', which can be a little confusing.

The total volume for the outer, structural bit you put the tanks in is defined, rather appropriately, with the 'volume = ' line, outside of the TANK{} modules...because it defines how much room there *is* for TANK{} Modules to use in the first place. It's added to the tanks with a modulemanager config file.

As far as documentation goes, keep in mind that Taniwha isn't the original creator, but in fact the second maintainer *after* the original creator. He's got a bunch of other mods he works on too, and in the case of this one is mostly just taking care of it.

Edited May 17, 2014 by Tiron

[Aedile]

The big orange KW tank is set as Cryogenic, which does not exist anymore.

[Tiron]

The big orange KW tank is set as Cryogenic, which does not exist anymore.

It actually still does exist...in realfuels. There's no need for it in MFT because it doesn't include the cryogenic fuels or boiloff. And checking the CFG shows *two* of the KW tanks are set to Cryogenic.

To fix it yourself(and thus not having to wait for Taniwha to do it) just open KW_modularFuelTanks.cfg in your text editor of choice and change 'Type = Cryogenic' to the appropriate tank type (probably 'Default' given they're set to Cryo.)

[taniwha]

It's fixed it git. I need to find out MFT's status (there are a few chefs doing this broth) and do a release.

[phoenix_ca]

<words>

I knew all that already. But I still think my point has merit. It's a bad idea to have similar (or exactly the same name) variables that mean very different things. Just because it seems clear that it's different because it's in an entirely different place doesn't mean it is clear that that is so. For the purposes of someone trying to edit the tank definitions or add to them, something like defaultTankSize or defaultTankMaxAmount would make much more sense. Then you don't even have the issue with someone (like me) looking at it and having trouble divorcing maxAmount over *here* from maxAmount over *there*. Just because the value later gets mapped to maxAmount in an in-game resource node doesn't mean that that confusion should be exposed for people editing the configs to have to deal with.

Not to be a Python fanboy, but I'll point you to this, namely "Explicit is better than implicit." What we've got here is an implicit meaning for a variable depending on the node its in. It's not immediately apparent that it will do something very different than a maxAmount in a resource node when its in a tank definition node until you (a) understand this leap of logic that it means very different things depending on which node its in, and ( note which node it is a part of every time you look at a maxAmount. Instead, why not use a different variable entirely, one that more clearly in-and-of-itself, without any sort of implicit meaning afforded to it by the array it's in, relates to what it actually does?

The same for could be said for the amount variable. Something like "defaultTankAmount" or "defaultTankFill" would be more explicit, and more clearly, in-and-of-itself, relate to the MFT function in-game of changing the tank sizes via the GUI.

Edited May 17, 2014 by phoenix_ca

[taniwha]

pheonix_ca: the thing is, the do mean exactly the same thing. maxAmount is the maximum that amount can be.

[Tiron]

pheonix_ca: the thing is, the do mean exactly the same thing. maxAmount is the maximum that amount can be.

Also, as I said previously, they're the *stock variables* used by the unmodified game. Nobody in this thread has control over how they're named. In the unmodified game, they're not confusing at all because there's literally nothing else to confuse them with. Only MFT's addition of the ability to modify tankage on the fly makes them potentially confusing.

Changing the names of the stock variables, *if even possible*, is NOT a good idea regardless of 'best practices', because you'll probably break compatibility with anything you don't personally modify to use whatever you changed it to. You'd have to insure that *every single mod including a fuel tank* was getting updated to the new variable name. In the event you found some way to make it so that the old name still worked, it'd STILL be bad, because anyone that knows the stock variable names is probably just going to use those instead of whatever you changed it to (especially as using the new one would be incompatible with stock!)

The simple thing you need to understand here is that 'maxAmount' comes from Squad, who have ZERO reason to change it and every reason not to. MFT is an addon, which has to comply with stock naming conventions and rules, regardless of how confusing that can make things.

[phoenix_ca]

Changing the names of the stock variables

Not what I was suggesting (at all; whatever gave you that impression? O.o ). I haven't read through the entirety of the code, but there's even suggestion that someone had the forethought to design for this, on lines 275-276 of ModularFuelTanks.cs :

                amountExpression = node.GetValue("amount");
                maxAmountExpression = node.GetValue("maxAmount");

Assuming that does what I think it does.

Edited May 17, 2014 by phoenix_ca