You once told me how to allow changing the MFT setup in-game, but for the life of me I can't find it. Could you please tell me how to do this?

I said the same in the forum thread, but this is not something I'm terribly concerned with, since it's just not a thing.

Since you have said that some sort of "construction yard" is a goal (both planetary and orbital), it seems like the solution would be that the EPL-like code allows craft docked to the "yard" part to be cannibalized for parts. Ie: tank dry mass converted to rocket parts, or whatever the resource is.

I don't think you chould consider "realism" here, just in-game functionality. I often have miners that would benefit from being able to refit instead of having to have 5-6 different versions docked.

The game still starts to freak out when you get too many craft (50+ which now with comsats is less than you think for actual game-play) in your game, kraken starts appearing etc. Still the reason why I never have large end-game saves, as they always go completely nuts.

So the idea behind this is fewer ships/parts to do what you need to. For me it is always near the end of the techtree when I get into scifi stuff where I would like to configure my tanks to hold an amount of resources to ship from one place to another; i.e. 200 hypergolics, 2000 supplies, 250 fertilizer, 4000 lithium, and upon return outfit it for 8000 mulch, 500 monoprop, etc.

Yeah, which is why in the long term a construction yard a la EPL makes more sense. You'd take all those craft that might clutter things up, and scrap them on orbit were they become rocket parts within an existing part. A more sophisticated system might even keep parts as parts in a list (an inventory of available stuff), but it might as well be abstracted, IMO.

Note that earlier career stuff, before you have an orbital drydock, you could have a small part that is like a COS module with airlock and maybe a robot arm (doesn't have to work, it's for looks). That part might be allowed to scrap things, and build only certain parts. Those certain parts might be "wet labs," so that you can scrap a tank, and turn it into something like COS.

Since you have said that some sort of "construction yard" is a goal (both planetary and orbital), it seems like the solution would be that the EPL-like code allows craft docked to the "yard" part to be cannibalized for parts. Ie: tank dry mass converted to rocket parts, or whatever the resource is.

I don't personally have any plans to make EPL-like code or functionality. My plans are, and always have been, to use EPL for its functionality.

Thankfully EPL supports mostly that same setup -- it has parts called 'recyclers' where you can grind up old parts and turn them into back rocketparts. From there you would just select the 'shipyard' (EL-construction dock), and create your new fuel tank. Use your station tugs to dock it in place.

Slightly more roundabout than simply changing an existing tank's contents -- but also slightly more realistic (ignoring all of the stuff about humans having lack of zero-g deconstruction/fabrication experience).

EPL can be patched to be more efficient, i.e. scrapping makes more ScrapMetal and the ISRU for ScrapMetal -> RocketParts can ofcourse also be tweaked, as right now there are huge losses and I;ve never gotten how the ratios were determined for transforming resources in EPL.

Just not sure if it's possible to store any fuels when a ship is scrapped, that would solve losing any reactor material (Uranium or other 3rd party fuels).

Gotcha. I remember seeing a post about it ages ago. I guess I conflated your desire for better looking parts (?) with doing your own (when maybe it was just to make an EPL part or 2).

Still, that sort of functionality achieves the desired goal without making work for you, and is more realistic into the bargain. I haven't messed with EPL in a while, but it requires inputs, and engineers, right? I have no idea if the EPL parts can include any limits, or if they are all or nothing (I'll go read up in that thread this weekend). If they can be constrained at all, then there are possible part options... you could have an EPL wet lab part that allows converting tanks to habs only (i.e.: it can only build COS parts and docking ports, but can recycle whatever at a high efficiency).

There are certainly abstractions for this.

I can't wrap my head around taking the inside of a Dragon or Cygnus, etc, and magically making it a fuel tank, though.

EPL can be patched to be more efficient, i.e. scrapping makes more ScrapMetal and the ISRU for ScrapMetal -> RocketParts can ofcourse also be tweaked, as right now there are huge losses and I;ve never gotten how the ratios were determined for transforming resources in EPL.

To be fair -- whatever mechanism I would develop for 'in-flight' fuel changing will -also- require that the fuel tank

• be completely empty -- cannot work on a fuel tank if it still has stuff in it
• will require some additional resources for 'tooling'/etc. These are beyond the resources required for the change in mass, and will essentially be 'consumed' for the conversion. With USI/MKS, will likely be the 'specialized parts' or whatever the 'rare' construction resource is.
• will require high-level engineers. Didn't think Jeb was going to refit the tanks with just his toothbrush did you?

So the functional difference is really just in the %'s you get on return. (and yes, pretty sure you can patch EPL to have 100% returns on recycles)

I haven't messed with EPL in a while, but it requires inputs, and engineers, right? I have no idea if the EPL parts can include any limits, or if they are all or nothing (I'll go read up in that thread this weekend).

EPL is an 'all or nothing' type setup. It takes entire .craft files that you build in the VAB/SPH, and constructs them on-site. The amount of resources required to construct the craft are determined by the crafts' dry mass. When constructed, they are initially empty of resources, and must be filled/fueled by the constructing station/base (or whatever crazy mechanism you favor for refueling).

There is no way to restrict EPL to only certain functions as far as I'm aware (e.g. only tank conversion). But I'm fine with that. Just fine. (I have no problem with personal limitations and practicing restraint if I feel the need for 'house rules' regarding a specific function or feature).

True, people can role-play as they see fit. I always forget that part, lol.

As in, allowing editing of the resources in the tank while in-flight? (outside of the editor)
Or as in setting up the config file from in-game?

The first... might... be supported (will look at the code). The latter, certainly not.

In-flight editing of resources creates problems due to the mass of the tank being dependent upon what resources it contains; so by allowing in-flight editing of resources, it breaks conservation of mass (unless I were to add in code that would consume/refund RocketParts/MaterialKits on tank changes.

Looking at the code, it appears that I dropped whatever partially written support that I had. So the answer would be 'no' for now.

In-Flight... I had it working once, you told me how to do it by adding a parameter in the cfg that is not used normally as you were still wanting to test it. I went through 16 pages of issues on github and even tried the KSP forum search (never use the KSP forum search!!!!), but can't find it anymore.

I once asked you about it as WildBlue has a similar function, and you confirmed it was possible. But I think that was in 1.1 or something.

Yeah, I think the feature was removed during the 1.3 update as I had never used it, and it wasn't officially supported (or even fully implemented/working).

I'm willing to discuss and layout out what would be needed to get the function implemented properly for the future. I think it could be quite handy for dynamic storage on bases, freighters, and stations. But it will have to come at a cost, and include provisions for conservation of mass.

Yes, particularly on ATV, miners, transports and even station storage tanks.

I think the only things that would be required for this to be a usable feature for me would be the conservation of mass. If you change to resources that would require a heavier tank, you must add in the extra mass through using RocketParts/MaterialKits/whatever. If you change to a tank that would be lighter, it would refund the difference in mass as RocketParts/MaterialKits/etc.

Possibly even with a config-specified inefficiency. So you might only get 90% of your mass back, the rest either being lost, or converted into a lower-down-the-chain primitive resource. Might also take ~110% of the 'extra mass' when kitting out from a lighter to a heavier tank (possibly returning the ~10% as a more primitive waste resource).

At the very least, the usage and return of a resource seems mandatory.

One final thought would be to require an engineer to make the changes (config/difficulty option to allow all classes). Possibly even with a specific config/difficulty set level/rank needed to perform the changes. Could possibly even link changing the 'tank type' (lightweight, zbo, etc) to require an even higher-level engineer (as well as its existing requirements for specific techs to be unlocked for the tank types).

Sounds like a cool game mechanic to be honest. Have RP at a station with an engineer, and convert tanks there. It would allow you to retrofit tanks on any orbital ship and need you to supply RP via a resupply mission.

PS: Want me to make a patch for an ISRU that has SSTU fuels? I don't think you can convert to any of the current fuels like LH2/Hypergolics.

I can see if I can get it to work with CryoTanks (also uses LH2 and I think adds LH2 to the ISRU). You can always check if CryoTanks is present and skip the LH/O parts. Alternative would be to make a copy of the ISRU and dedicate it to SSTU and stock fuels only, so it will not get crowded.

For my own gameplay I have an XS-sized COS with ISRU for the resources I need, looks way better than the clunky stock part and fits into 2.5m ship cores.

I'm not opposed to creating a distinct part using some of the SSTU models. Would really like to differentiate it from the other parts that use those models in some fashion (new texture perhaps?).

Will give that a bit of thought as it very cleanly solves the patching problems :)

Maybe an idea to make something that is modular like an MFT, so it can be used inline and blend in with the ship instead of looking fugly like the stock stuff. You could scale up efficiency by the volume of the part, ie a smaller part meaning it will be slower. A fixed size is always difficult to incorporate into a ship without it looking like it's from the Lego movie.

I'll give some thought to the ISRU -- I don't want it to conflict with other mods that do the same (Near Future, possibly USI).

Hmm... is there a way to check if the converter module already has an entry for a specific resource output, and only apply the patch if/when needed? Sounds sad, but I'm still learning all the MM syntax and capabilities...

Hmm... I like the idea (module needed for refit), but I'm not sure if I'm fond of the implications. Requiring an engineer is a fairly 'stock-alike' feature, but requiring specific parts/modules is far more into the realm of MKS/EPL/etc.

Trying to avoid the creation of entirely new mechanics like that (for now at least); but will give it some thought. Should be easy enough to add in at a later time once I start working on base/station mechanics/gameplay features.

I suppose the entire feature is a bit of a 'new mechanic' though, as stock has nothing similar; the closest stock comes is letting you jettison ore from ore tanks.

The only mod I've used that allowed resource swapping was in WildBlue DSEV.

At one point USI allowed for in-flight 'repainting' of its Kontainer series of parts (using FireSpitter texture/resource switching modules). It would change both the texture and the resources. It may or may not have required an engineer, and I think later revisions of the feature also had a 'specialized parts' cost associated with it as a refit cost mechanic.

USI never had dynamic dry-mass-based-on-resource-mass though, so was a much simpler implementation. The downside of the simplicity was that using the containers for less dense resources (LH2) was prohibitive, as the dry mass of the container often exceeded the mass of the resources contained within. Just fine when switching between similar density heavier resources (LFO->MP), but far from ideal when adding LH2 and other less-dense resources.

That is the problem that I'm trying to avoid / solve. SSTU's containers' dry-mass depends on what resources (and ratios) are contained in the part, which may or may not be balanced for whatever the new resource load-out would be when changed in-flight.

Requirements:

• Allow changing of resources while in-flight.
• Add/remove dry mass from the container to reflect the new resource setup.
• Add/remove resources to account for the change in dry mass (kit out)

Code:

• Config-specifiable 'kit out' resources. Should default to 'RocketParts', use MatKits/Specwtfe when USI is installed.
• Needs flight-accessible button to enable changing of resources.
• Tank must be completely empty before changing resources?
  • Alternatively, could allow to shrink any resource volume to the current filled volume of that resource.
  • In flight -- will need to keep existing resource loadout / do not zero out / fill up resources. Easiest to just mandate an empty tank before doing any changes....
  • Need a 'jettison contents' button to allow for manual emptying of a tank.
• When new resource selection is chosen, need to validate that there are enough kit-out materials available and/or there is enough space for the materials to-be-returned.
• This will require that updates to the parts' actual resources be delayed until the user has pressed the 'change resources' button.
  • Might require a new GUI setup and entirely new system to handle this resource setup.
  • User-specified desired changes should persist even if they close the GUI (persist for run-time session only; lost at load/save).
  • Add a button to 'reset to current tank state'.

Optional:

• Allow only engineers to do the refit on fuel tanks.
• Lossy conversion -- higher level engineers are more efficient at the kit-out process,

+1 for needing the engineer.

Maybe even have a module in the DOS/COS parts that is needed as well for the retrofit (sort of like the EPL workshop).

Laying out what needs to be done in order for this feature to become reality:

• VolumeContainer GUI needs to have a 'delayed update' mode, where all changes are delayed until finalized.
  • Perhaps a second, specialized, GUI for in-flight resource changing -- after-all, it will require additional display to inform the user of the 'cost' of the reconfiguration, and of the change in mass/etc of the tank.
• What should be the cost of resource changing (beyond the additional/refunded resources for the change in dry mass)?
  • Should have some EC cost (non-refundable cost)
  • Should require a (high level) engineer (training cost)
  • Should require some small amount of material resources (mass), that are turned into less useful resources (waste mass, recyclables, etc).
• Should allow for changing tank-modifier-type in flight? -- probably not, at least not initially. If/when it is available, it should come at a fairly steep cost (specialized parts, some for changes in mass, some of which are 'lost' and turned into waste).