Tweakable fuel tanks

[BubbaWilkins]

Don't get me wrong, I absolutely love every change and addition in .23, the science changes make career mode a lot more challenging and enjoyable, the RAPIER engine is absolutely genius, and the tweakables-system is for the most part as good as or better than I expected. There's one thing about it that made me just a little sad, though.

It doesn't seem to be possible to fill any of the tanks with a combination of fuel of your choosing, it merely lets you remove some fuel before launch. I was under the impression that we'd be able to, for example, fill a large orange fuel tank with xenon if we really want to for some reason, which doesn't seem possible right now. It pains me to be forced to take a fuel tank into space with my SSTO spaceplane that's only 2/3 filled with fuel, since I won't be needing most of the oxidizer and there's no way to fill the empty portion with liquid fuel.

Is this working as intended and won't be expanded upon, or will we be able to do what I described at some point in the future?

Remember that fuel and oxidizer have vastly different volumes and masses per unit. It's not a 1:1 swap and even if they did allow it, you probably wouldn't gain much additional liquid fuel in trade. BUT, what the current implementation does allow is for you drop the excess oxidizer you don't need. You still have a full tank of liquid fuel, you just have shed the excess mass you don't need increasing overall performance due to the lighter weight of the craft.

[Themohawkninja]

(1) Is always a very good reason to do something. I don't agree with your assumption, I think one would be able to fit a lot more xenon in there, as the xenon shouldn't replace the liquidfuel 1:1 in volume.

True, I just wanted to use the easiest assumption.

(2) This is incorrect, drag is dependent on mass. Ten 1 ton tanks have as much drag as one 10 ton tank.

As I understand it, the way KSP currently models drag makes it so two Rockomax-32 tanks has more drag than one Rockomax-64. Is this not the case?

[numerobis]

My bet: making two sliders took about an hour to design, implement, and test. Adding a UI for setting ratios and changing propellant types and etc would take a lot longer to program, would require some iterating to make sure it's usable, requires some thinking about densities and so on, and would change the game balance some (the bipropellant tanks have low dry mass compared to other tanks) -- easily a week of work to get it all straightened out. If I were the boss, I'd have trouble OKing the week-long project rather than OKing the hour-long project and then having another 39 hours to work on other stuff.

Hopefully at some point the week-long project bubbles up to be on the top of the priority list. I won't hold my breath, and will enjoy whatever Squad did in the other 39 hours.

[Retread]

...the week-long project rather than OKing the hour-long project and then having another 39 hours to work on other stuff...

I get the funny feeling the dev team works a lot more than 40 hours a week...

[CaptainArchmage]

It should be possible to alter the volume allocated to fuel and oxidizer in the tanks. You set the ratio in the VAB or Spaceplane hanger, and these values are then fixed after you hit the launch button. The ideal ratio for fuel tanks for the liquid rockets in KSP is 45% liquid fuel and 55% oxidizer. According to the wiki, the fuel and oxidizer densities are the same at 5kg/l.

In the VAB and Spaceplane hanger, you can now put a thrust limiter on solid boosters, but after you hit "launch" the thrust is fixed and cannot be changed.

Edited December 18, 2013 by CaptainArchmage

[JumpsterG]

I feel like I'm being pulled in a few directions as I read through this discusson. Some observations:

There are a few separate but related features being discussed:

1) Changing the named resource stored in any given tank. (Jet Liquid tank -> Oxidizer or Liquid/Oxidizer -> Liquid/Xenon)

2) Adding/removing any number of individual named resources stored in any given tank. (Jet Liquid tank -> a Liquid/Oxidizer or Liquid/Oxidizer -> Oxidizer, or Liquid/Oxidizer -> Liquid/Oxidizer/Monoprop)

3) Changing the ratio of different resources stored in any given tank while still filling the tank to it's maximum volume. (55%/45% Liquid/Oxidizer -> 90%/10% Liquid/Oxidizer)

2 kind of necessitates 3 (requiring whichever resource added/removed gets a percentage of the tanks full volume), but 3 could be implemented without 2 (allowing only ratios of existing combo tanks to be adjusted).

Opinion - Liquid/Oxidizer tanks, Liquid-only tanks, xenon tanks, etc. should be visibly distinquishable from one another. It's cooler that way, for one thing. Being able to trade out the resources of any tank to whatever you want will cause an identification problem when looking at a ship (your own or someone else's). I should be able to see someones lander and immediately recognize it's missing RCS tanks or that a rover carries Xenon and therefore is ion-powered. This applies to resource ratios as well. If you've brought an orange tank's oxidizer capacity to zero and made it part of a space station, you (or someone else in multiplayer or loading it into their persistant file or viewing a screenshot) can't tell from looking at it that they won't be able to get or store oxidizer in it upon docking. It's a simple reason, but that puts me in the camp of not wanting to arbitrarily allow fuels to go into whichever tanks or change capacity ratios.

Opinion - Decreasing your oxidizer to zero in order to increase your liquid fuel to fill the remaining space seems unnecessary. If you need more liquid fuel than a tank can carry, why not go with a larger tank or use an additional one? Sure it seems like there is wasted space in the tank but you've still lost the dead weight of the oxidizer which is generally more significant than the added dry mass of the larger/extra tank. It's possible this extra dry mass accumulates as you scale up, but is this much different than our other engineering concerns? Just like anything else there's a tradeoff using a tank designed for Liquid fuel/Oxidizer for only one of the two. This may birth the need for some new tanks with specialized roles, which may be considered bloating the parts list, but I don't think it's a bad trade. Still opinion (and a weaker one, I know, as it results in seemingly less efficient designs), but I err on the side of simplicity.

My question is: Is it worth added GUI complexity and the loss of on-sight recognition of tank capabilities to be able to compress different kinds of fuels into the smallest possible spaces?

[Firov]

Just like anything else there's a tradeoff using a tank designed for Liquid fuel/Oxidizer for only one of the two. This may birth the need for some new tanks with specialized roles, which may be considered bloating the parts list, but I don't think it's a bad trade.

It IS a bad trade, since no trade off would be required by simply allowing us to use the entire tank's volume for liquid fuel or oxidizer. Indeed, the whole reason the developers supposedly implemented tweakables is so they wouldn't have to have a bunch of duplicate tank parts for different purposes. Now in this version of tweakables it's failed pretty badly at that, but I'm hopeful they'll fix this.

As for your complaint about not being able to see RCS tanks, I'm not sure why this is important since you wouldn't be forced to use standard tanks for RCS, but I'd argue that what you complain about is already possible. Plenty of people already clip the round external RCS tanks into larger fuel tanks and/or command pods so that they're not visible. Personally, I put RCS tanks in service modules using procedural fairings, so it's impossible to see my RCS tanks either.

My question is: Is it worth added GUI complexity and the loss of on-sight recognition of tank capabilities to be able to compress different kinds of fuels into the smallest possible spaces?

Yes. Yes it is. Especially since the GUI needed for this is already 90% there with the current implementation of tweakables. Assuming you were only aiming to have the entire tank's volume usable, the current GUI would be fine. Just have one slider affect the other one and you're set.

If you want to be able to add other resources, then you'd need a bit of added complexity, but not a huge amount. Besides, it's not something everyone would have to be concerned about, since tanks would, by default, come with liquid fuel and oxidizer. If a newer player didn't understand fuel ratios yet, then they wouldn't have to worry about it until they're ready.

[lajoswinkler]

If any tank can have any fuel, what's the point of having different tanks? While I'd be opened to the idea about tweaking the fuel/oxidizer subtank sizes, I find the notion of putting any kind of fuel in any tank absurd.

[Eric S]

If any tank can have any fuel, what's the point of having different tanks? While I'd be opened to the idea about tweaking the fuel/oxidizer subtank sizes, I find the notion of putting any kind of fuel in any tank absurd.

As long as the fuel types are fixed in the VAB and not tweakable while in flight, I don't see a problem with this. Since different types of tanks have different volumes and dry weights, they'd have to take that into account, but as long as they do that, it's fewer parts and more flexibility.

I don't know if the devs have changed their minds on this, but this ability to change the type of fuel in a tank was mentioned as one of the things they had planned when they first started talking about tweakables. Later on, this type of tweakable was mentioned as what they were waiting for before switching over to atomic engines that don't use oxidizer. Because removing oxidizer would reduce reaction mass, they'd be severely nerfing atomic engines if they did that without giving us tanks that could hold more liquid fuel without dealing with the dry mass of combined tanks that just aren't holding oxidizer.

It was also brought up when Claire was doing KSPX. The devs didn't want to color code tanks according to what fuels were in the tank because by their plan at the time, the fuel types of any given tank wouldn't be fixed. Sadly, that thread was one that went poof back in April.

As I said, they may have changed their minds. They may have also done this as the first pass on tweakables and they're not done adding features to tweakables yet. Either way, at some time, the devs had intended to do just that, the only difference is whether or not they still intend to do that.

[Sethnizzle]

As far as coding difficulty, I suppose it comes down more to GUI design and expected behavior. Adding two sliders is pretty easy, but when you are able to affect the values of one by sliding the other things get a bit hairy, especially when you deal with different densities (and maximums at that point). Then you need a reset button, how to allow reset from sliders, increment steps, what is intuitive, etc... It's not actually that much more code for sure, but making it playable takes some thought. Refinement may come with time.

There is the matter of a nod to realism that Retread brought up, I think that's a much more compelling argument.

No, that is not a good argument at all. Do you think NASA would be spending extra resources (fuel, time, money, mass, volume) to send up an empty, or partially empty internal oxidizer tank? No, they would just design the internal oxidizer tank to be smaller so that they could either A) Reduce the overall size of the fuel tank or Increase the size of the internal liquid fuel tank to meet design specs (which is what we want to do).

Each fuel tank needs a maximum amount of volume, a default ratio between oxidizer and liquid fuel, and the ability to adjust that ratio. An easy UI choice would be to add a ratio slider. Or get rid of individual sliders and have only one bar that represents the max volume with two adjustment points that works similar to a percentage bar graph. 1 adjustment would change the ratio between oxidizer and liquid fuel, the other adjustment would be to change the amount of the max volume used.

Edited December 18, 2013 by Sethnizzle

[JumpsterG]

It IS a bad trade, since no trade off would be required by simply allowing us to use the entire tank's volume for liquid fuel or oxidizer. Indeed, the whole reason the developers supposedly implemented tweakables is so they wouldn't have to have a bunch of duplicate tank parts for different purposes. Now in this version of tweakables it's failed pretty badly at that, but I'm hopeful they'll fix this.

As for your complaint about not being able to see RCS tanks, I'm not sure why this is important since you wouldn't be forced to use standard tanks for RCS, but I'd argue that what you complain about is already possible. Plenty of people already clip the round external RCS tanks into larger fuel tanks and/or command pods so that they're not visible. Personally, I put RCS tanks in service modules using procedural fairings, so it's impossible to see my RCS tanks either.

Yes. Yes it is. Especially since the GUI needed for this is already 90% there with the current implementation of tweakables. Assuming you were only aiming to have the entire tank's volume usable, the current GUI would be fine. Just have one slider affect the other one and you're set.

If you want to be able to add other resources, then you'd need a bit of added complexity, but not a huge amount. Besides, it's not something everyone would have to be concerned about, since tanks would, by default, come with liquid fuel and oxidizer. If a newer player didn't understand fuel ratios yet, then they wouldn't have to worry about it until they're ready.

The particular goal of avoiding duplicate parts doesn't necessarily mean there shouldn't be unique containers for certain resources. Batteries, for instance, are implemented the same way as tanks, and nobody is suggesing we have the ability to trade electric charge for something else. That said, I wouldn't be wholly against the idea of choosing what kind of fuel is being stored. The nuclear engine has been discussed specifically in this regard. We've happily been using the Liquid/Oxidizer tanks for those since they've been introduced, so that's a good example of a container that could hold liquid fuel OR nuclear fuel. This could swing either way or compromise somewhere in the middle (All containers unique, All containers potential store any resource, Some containers can switch between specific resources).

I retain the opinion that it would be nice to identify a tank's purpose and capability at a glance, but I admit after thinking about it that it's probably not as important as the actual functionality. As you stated, many players do go to great lengths to hide unsightly parts and it's more important to them to simply add the resources they need to one container, rather than be required to slap on 2 or 3 single-purpose ones that ruin the look they were going for.

GUI would not be too bad, I'm sure. A selection of resources available and an automatic determination of the maximum capacity based on density plus the ratio slider that has been mentioned would pretty much do the trick. The argument I make is really not about the difficulty of implementation, but how much clicking is required to navigate the new features and how much the player may need to keep track of in the situation where any fuel tank could literally contain any resource and the only way to know what is to right-click and check.

Just to be clear, I'm not incapable of being convinced one way or the other. I really think more freedom with what goes in tanks would be awesome, but I also think it might complicate an otherwise solid system. By all means, prove me wrong!

[Eric S]

We've happily been using the Liquid/Oxidizer tanks for those since they've been introduced, so that's a good example of a container that could hold liquid fuel OR nuclear fuel.

Just to be clear, atomic engines currently run off of both liquid fuel and oxidizer as you said, but after this change, it would run off of just liquid fuel, not some special atomic fuel. Atomic engines work by using the heat produced by the atomic pile to heat up a gas/liquid to the point that it expands enough to provide more exhaust velocity than burning the fuel would have.

So, in order to make the atomic engines work the way that they do in reality (a goal the devs have expressed a desire for), we would either need to have duplicates of all the fuel tanks with no oxidizer but more liquid fuel (something the devs have stated that they want to avoid), or we use tweakables on the existing tanks. If tweakables can't be used to increase the amount of liquid fuel in a tank, just to reduce the oxidizer, thats a nerf to atomic engines because it means we have less than half the reaction mass that we have from the same tanks now, but all the size and dry mass. The dry mass may not sound like much, but if you look at some of the number crunching that's been done concerning how much delta-v you can get out of a given engine, the dry mass plays a very large role in the max delta-v you can get out of any particular engine in a single stage.

Basically, the solutions to this would be:

1) to leave everything as it is. This goes against the dev's goals.

2) to change the engine but leave the fuel tanks as is. Big nerf.

3) to change the engine, increasing its ISP, leaving the fuel tanks as is. That would be hard to balance and wouldn't feel very realistic.

4) to duplicate all the fuel tanks in "liquid fuel only" versions. Again, this goes against the dev's goals.

5) to allow tweakables to have greater effect over the contents of a fuel tank.

Obviously, none of these situations beats all the others in all ways. #5 is my preference, because I don't think of our designs as being entirely made from off-the-self components that can be in no way modified. Most of the people that object to #5 here tend to say that #4 is the proper solution, but that goes against the stated dev goals, though it is possible that the devs have changed their minds on that subject.

[KITTYONFYRE]

People asking about oxidizer less tanks - is that not the same as jet fuel? I thought jets ran off of the same liquid fuel as engines, but got their oxidizer from air intakes.

[illusori]

Tweakables are clearly not the final product, arguing about them isn't going anywhere. Like everything in KSP, a features gets added and then gets iterated on. This is very clearly just a first step.

The reason you can't change the maximum values for fuel or types of fuel is because the system they have implemented only allows you to change the dynamic properties of objects: you can only make an object start in a state that it could otherwise have reached at some point later in the flight.

Why do that? Because it's the implementation route that's least likely to introduce game-breaking bugs and lets you concentrate on making sure that you've implemented a sane UI, that you're saving the tweaked states correctly in the craft files, and that the tweaked state actually starts out on the launchpad correctly, that there's no crazy unexpected side effects like engines suddenly thinking they have no fuel or gear raise/lower toggles failing.

Once they're satisfied that all that works without breaking things, or that they've fixed the things its broken, then they can move onto making the system more complicated.

Like testing and building a rocket, sometimes you really really want to limit the number of things you change at one time, so you can have some clue about what change had what effect.

This version of tweakables was fairly obviously the version that allows them to test the core concept of tweakables with the least number of changes.

[Eric S]

People asking about oxidizer less tanks - is that not the same as jet fuel? I thought jets ran off of the same liquid fuel as engines, but got their oxidizer from air intakes.

That's correct, in fact one of the reasons I'd like to see this is to get more variety in fuel tanks for jets.

Tweakables are clearly not the final product, arguing about them isn't going anywhere. Like everything in KSP, a features gets added and then gets iterated on. This is very clearly just a first step.

That's been my opinion as well, though I'm not sure I'd say that it's clearly not the final product.

[z26]

There are several different propositions out there. Personally, i'd think being only able to set a rocket fuel tank to have its two sections set to ethier liquidfuel/ox, liquidfuel/liquidfuel or ox/ox would be ideal (while not something that's top priority to implement). While being able to swap monoprop, liquid fuel, oxidizer and xenon sounds appealing, I don't really know if in real life, fuel tanks for these different propellant types are similar enough that you can just swap them like that.

The main thing I have an issue with is changing the tanks ratio. While wanting procedural tanks to replace the prebuilt ones we have now is a totally respectable position, there seem to be people that don't want procedural tanks, but still want ajustable ratios, and thats just illogical. To ajust the ratio, you NEED to change the tank's shape, meaning there isn't many arguments that can be made against procedural tanks you can't make against variable ratios as well. (unless if in real life, you could somehow design a tank with an internal separator you could easily slide around for adjustements, but I don't think this is possible)

As for me, I'm already satisfied with these "limited" tweakables, they save me a lot of time. I don't know if it is easy to mod them, but if it is, that would just be awesome. It would give many more possibilities for people to make new parts.

Edited December 19, 2013 by z26

[_Aramchek_]

You can alter the ratios without changing the external shape/size of the container, there is nothing "procedural" about it, and people overuse that word incorrectly in context to this idea.

[JumpsterG]

Just to be clear, atomic engines currently run off of both liquid fuel and oxidizer as you said, but after this change, it would run off of just liquid fuel, not some special atomic fuel. Atomic engines work by using the heat produced by the atomic pile to heat up a gas/liquid to the point that it expands enough to provide more exhaust velocity than burning the fuel would have.

...

Thanks for the clarification on that point. If this was being modeled, The atomic engine would use only a single resource (be it just the same liquid fuel or some other unique resource). To use the existing tanks for it then would therefore require some way to fill them completely with the needed resource.

You laid out the options nicely. You are right then that the choices available for implementation are unique tanks for atomic fuel or using the same tanks we have, able to fill completely with atomic fuel vs. liquid/oxidiser.

Perhaps, a compromise would be to allow us to select from various resource combinations? Maybe the devs would be interested in implementing alternate textures for tanks depending on which role has been selected for it? That would address the problem I have with eyeballing a tank's purpose and allow one part to fill multiple roles.

For example: Take the largest tank, still using just one model and one space in the VAB list, but allow us to cycle between container type:

-Liquid/oxidiser - default orange texture and filled with liquid/oxidiser

-Jet Fuel - white with flammable icon and filled with liquid only

-Atomic - yellow with radiation hazard icon (I know, the propellent is probably not radioactive by itself...) and filled with atomic fuel only (if different from regular liquid fuel)

...

Maybe not a perfect solution. It does have problems:

-Doesn't allow arbitrary combinations of resources

-doesn't address the desire to change maximum capacity ratios in combo tanks.

-Any combinations they don't create would be conspicuous in their absense (no xenon or oxidizer only options?!)

-Requires additional artwork for all the new textures

Edited December 19, 2013 by JumpsterG

[JSD]

Why not scrape the whole existing tank part section as it is (doesn't really fit together). Build a random selection of different shapes and sizes and let the amount AND the type of fuel tweak-able for the end user. Why add all kind of different tanks with a different fuel type? Only thing you do is filling up the part count..

[Eric S]

Perhaps, a compromise would be to allow us to select from various resource combinations?

That's definitely possible, and I've been thinking about it for the last few days, and I think that might actually be easier on both play balancing and new players. You could do a pulldown list showing all the variations of the tanks, their max capacities, and if it changes, the dry mass. We'd lose the ability to top off the tank if we weren't using the standard fuel balance for that variation, and while nice, I think that's a reasonable loss as the only time it would matter is if you have different types of engines feeding off the same tank (or a dual mode engine). Without it, you could still vary the max capacity and dry mass, but it would have to update as you moved the ratio slider, which may come as a surprise to people that aren't used to it.

[Firov]

That's definitely possible, and I've been thinking about it for the last few days, and I think that might actually be easier on both play balancing and new players. You could do a pulldown list showing all the variations of the tanks, their max capacities, and if it changes, the dry mass. We'd lose the ability to top off the tank if we weren't using the standard fuel balance for that variation, and while nice, I think that's a reasonable loss as the only time it would matter is if you have different types of engines feeding off the same tank (or a dual mode engine). Without it, you could still vary the max capacity and dry mass, but it would have to update as you moved the ratio slider, which may come as a surprise to people that aren't used to it.

This isn't a horrible compromise and it's definitely better than what tweakables currently are, but it would eliminate the ability to make, for example, an integrated service module by having one tank contain liquid fuel, oxidizer, and monopropellant.

Still, it remains to be seen just how far the developers want to take this concept. Ideally, we'll have almost limitless options within the volume limitations of each tank. It's certainly possible, as the modular fuel systems mod has managed to do it, but that might not be what the developers have in mind. I hope it is though. It would add a lot of flexibility.

[JumpsterG]

Yeah, in the end, I feel the developers will need to throw a dart at the board to pick exactly which implementation to go with, but just about any suggestion here would be an improvement, so I'm not too worried.

[Eric S]

This isn't a horrible compromise and it's definitely better than what tweakables currently are, but it would eliminate the ability to make, for example, an integrated service module by having one tank contain liquid fuel, oxidizer, and monopropellant.

Still, it remains to be seen just how far the developers want to take this concept. Ideally, we'll have almost limitless options within the volume limitations of each tank. It's certainly possible, as the modular fuel systems mod has managed to do it, but that might not be what the developers have in mind. I hope it is though. It would add a lot of flexibility.

Agreed on both counts. Service modules are the only place where this is that much of an issue (referring to wanting tanks that don't conform to the regular fuel types, not just the balance) because you either wind up using parts other than the fuel/oxi tank that are larger than you need, or radial mounted stuff which doesn't look right when you're trying to make an aerodynamic craft, or use part clipping to put the radial stuff inside something else. I'm loving nothke's S6 Service Compartment mod for Service Modules, but it would be nice if it were stock.

EDIT: On further contemplation, I think that the shortest 1.25m and 2.5m tanks are the only ones that should go so far as to not be restricted to current fuel combinations. Yes, swithing fuel types and maybe ratios on all tanks is fine, but adding a third content may not be in all cases. The idea doesn't work if someone wants to take an orange tank and fit in a little monopropellant, batteries, life support (if and when it gets added to stock), even I'll admit that that would be too close to procedural-everything-but-engines-and-capsules.

The devs haven't directly commented on this in some time, so it's possible that they've changed their mind enough that this isn't what they're doing.

Edited December 19, 2013 by Eric S

[Wheffle]

It IS a bad trade, since no trade off would be required by simply allowing us to use the entire tank's volume for liquid fuel or oxidizer. Indeed, the whole reason the developers supposedly implemented tweakables is so they wouldn't have to have a bunch of duplicate tank parts for different purposes.

Uh, I thought tweakables was just to let you start rocket with landing gear down, and facilitate switching between modes with the RAPIER. Correct me if the developers stated otherwise...

My opinion is that tweakables shouldn't go so far as to basically streamline the whole part system. I enjoy the part diversity and their limitations. If each tank's volume could be 100% customized to hold whatever combination of fuel the player wanted, all tank diversity besides shape would be rendered obsolete. Might as well go back to gray unity blocks.

[Eric S]

Uh, I thought tweakables was just to let you start rocket with landing gear down, and facilitate switching between modes with the RAPIER. Correct me if the developers stated otherwise...

The first time I'm aware of the devs talking about tweakables was over a year ago, and in a context that relates specifically to what's being debated here. Someone suggested that to be more realistic, the atomic engine shouldn't use oxidizer, just liquid fuel, and the devs responded that they didn't want to do that until they had tweakables in place so that they didn't have to come out with two versions of every fuel tank. When people started asking about tweakables, they gave switching landing gear and such in the VAB as another use for it. Dual mode engines came out of nowhere compared to this, the first time I saw anything official on dual mode engines was about a month ago when it turned up in the tuesday devnotes summary.

I don't think this version of tweakables is what they were referring to there, because if it was, they would have changed the atomic engine over to use just liquid fuel. If they did switch over the atomic engine with this version of tweakables, it would be one heck of a nerf to atomic engines because of the increased dry weight of using bipropellant tanks and just not filling one of the two tanks. Basically, one of my simple atomic engine probes I made a long time ago would lose over 1100 delta-v even after I added more fuel tanks to make up for the missing reaction mass.