Not sure this is possible or desired from your end... Just another brainfart I thought I'd share.

re SSTUVolumeContainer, the ability to define a fixed resource amount.

i.e.
Container [fixed]

• 1000 ElectricCharge
• 150 Monoprop

Container [*]
... same as current system to fill up remaining volume left after Container [fixed]

This would save a lot of tuning when you try to add these to the MFT-A when you need some RCS and solar power as example.

LOL, I end up messing around with ratios until I get something in the ballpark of what my target is.

This proposed functionality seems rather like the MUS support tank setting.

You can already define a number of seperate containers within the SSTUVolumeContainer (like in the MUS), but they are all ratios of the defined total volume, never a fixed number.

For tanks that can differ in diameter and size, that ratio is never the same if you want a certain number of Ec/MP/X units as the "support". Otherwise you could make a fuel definition and list the fuels + ratios there (like Hydrolox, Hypergolic, LFO does right now).

As the entire system is built on ratios -- this won't work without a complete overhaul of... everything. Seriously, the backing persistent data is simply a list of unit ratios for each resource, and a total volume of the part.

Essentially I would need to rework the data to store 'volumes' rather than ratios. But then you run into the reverse problem -- how to cleanly specify a unit ratio, e.g. for propellant containers? Gets really messy when you need to convert from units -> volume -> calculate ratios -> convert back to volume -> units -> finally write the value into the config.

At one point I did allow for specifying the container setup in either ratios -or- volumes (had to use one or the other consistently) -- but it ran into problems when trying to use it on parts that can be re-scaled, notably, when the scale goes so low that you can no longer fit the specified 'volume' into the part.

No guarantees on this. I'll only be implementing it if I find the need for it (code or specific parts). Currently I don't need it, nor can I foresee any actual need arising. I'm able to specify parts' resource layouts just fine by using ratios (though, granted, it could make specific uses in non-scale-able parts much easier to be able to specify specific volumes for the sub-containers; currently it takes a giant spreadsheet to calculate the LS supplies for the StationCore parts for example).

It's mainly for support for Ec/MP and similar 3rd party resource such as LS type of supplies where it takes a lot of fidgetting to get the ratios about right. I can imagine two systems being a pain for scalable parts, and indeed needing check to see if the set amount will even fit inside.

I can imagine two systems being a pain for scalable parts, and indeed needing check to see if the set amount will even fit inside.

Indeed. Not really solvable either. If someone specifies 'mandatory 100 liters of resource X', there is no proper way to handle that case if the current part configuration has less volume. If you truncate the volume to that which is available in the part, you have violated the 'config contract' (that config values should be used properly when they are specified in the config file). If you squish the resource into the part anyway, you've violated physics. Obviously one of those two solutions would have to be implemented if this were a feature, but they are both 'wrong'.

I just thought I would throw it out there.

But: The Tardis is real! ;)

Should I close this?

Leave it open for the time being. It is a valid request, I'll just need to find a way to properly handle a few of the edge cases.

Thanks for checking back in on it though :)

I have changed the volume-container definitions from being volume+percentage based, to being purely volume based. Resources are still specified as a unit ratio between the resources in the tank.

While you still can't directly specify # of units of a resource, you no longer have to guess at what the volume of any given subcontainer is.

Anything further than this would require a complete rewrite of the fuel tank system, as well as exposing some (unsolvable) problems regarding 'conservation of space' (e.g. breaking reality).

Looking forward to seeing how that works :)