COS Storage module

[Jimbodiah]

I'm made a COS storage module for my JPL patches for use on stations and my ATV cargo module. There is no crew, just resources. Maybe it might be a good part for SSTU instead? It's a COS hab with everything torn out and an SSTUVolumeContainer added which can be edited in the VAB just like the MFT.

Might be a cool way to store large(r) quantities of fuel and/or LS supplies.

[shadowmage45]

While I have no problem with the concept of a COS storage part -- I do have problems with identical parts in the editor.

Sadly, I'm unsure of any way to solve the problem (combining the crew and storage parts), without massive amounts of additional plugin code (and there is always the stock bugs regarding dynamic crew capacity that would still be there).

I'll have to give this some thought. I might be less opposed to it if the parts looked visually distinct in the editor list -- this could be accomplished by giving the 'storage' parts a different default texture set assignment (hit me up if you need info on how to set that up in the new parts). Even with that, I would have to think on it a bit.

^^^ Hmm.. instead of having 2,3,4,etc different 'COS-Storage' parts, how about adding those models as a new 'variant set' for the MFT-A tank? So it would end up with Kerolox, Hydrolox, Cryo, Framed, and COS. Thoughts? (this would also give it diameter adjustment, though it would lose the docking port options)

[Jimbodiah]

I have moved them to the fueltanks list, so they do not show up next to the habs.

Having that as an MFT option is great, one part with scalable size instead of four seperate ones is always prefered. But how would the docking ports behave?

This could also link in with your question about 3.75 and 5m station core parts? MFT-COS?

[shadowmage45]

Having that as an MFT option is great, one part with scalable size instead of four seperate ones is always prefered. But how would the docking ports behave?

There would be no docking ports. Its an either-or- scenario; either they use the MFT module and get combined into a single part + diameter scaling, OR you use the ModularStationCore module and get dockin g ports.

I personally would prefer them added into the MFT tanks (integrated docking ports still being problematic/buggy; will not be doing any more parts with integrated docking ports until those problems are solved).

^^ Actually working on a commit right now that will do just that -- add them as an MFT-A 'tank set' variant. You can give it a try from the new 'mft-cos-additions' branch ( https://github.com/shadowmage45/SSTULabs/tree/mft-cos-addition ) (can download it from there and give it a try if interested; I'll try to test it when next I have time to launch KSP, likely thursday/friday/over the weekend)

[Jimbodiah]

Cool, I will check that add-on out right now!!!

BTW: Was going to make a new issue... the COD/DOS parts, when no docking port is selected, still have the "decouple port x" GUI option which will separate them as if there were a port. Gives funny situation on stations "hmmm, I wonder what happens if I press this button anyway...".

Maybe it's not a bad idea to let go of separate ports. From a game play perspective it is easier to have them as separate parts anyway so they are easier to select as targets or undocking, specially with the hubs.

[Jimbodiah]

WOw... this open up possibilities.... If you add these COS parts as a nose, you could make a one piece ATV with an MFT where you take a small tank for the main core, add the COS nose and voila... insta-ATV.

[shadowmage45]

Indeed; and with my upcoming mini-mod that adds a 'disable docking port' function, the docking ports will be even less damaging for performance.

It was an interesting experiment (and I thought for a bit that it would work out), but as with all things KSP-Module-switching-at-runtime related, runs into problems with the stock code that make it less-than-desirable when actually implemented.

I'll probably still integrate docking ports where it makes sense (command modules), but it seems very likely that I'll be removing the 'switchable' docking ports from the station-core lineup in the near future.

[Jimbodiah]

Re the test version (just did a gamedata wipe and installed just this sstu version) I see the patch files for the tank types and ModelData, but can not select it in the GUI. Is that plug-in related?

[shadowmage45]

It should be another variant on the 'Variant' selection list.

Other than that... no clue, will have to test personally when I have time. Anything in the logs during either the boot-up initialization, or when you pull the part out of the editor list?

Sadly we are in the middle (end?) of a buyout-transition at work, so will be working late probably the rest of the week, and likely won't have time until friday night/weekend for any testing.

[Jimbodiah]

I only get the 4 standard ones, not the COS. Nothing in the log but some texture errors on non related parts.

[shadowmage45]

I found out what is going on...

The COS is only available at specific lengths, so you need to select one of those lengths first (0.25x, 0.50x, 0.75x, 1.00x). With one of those lengths selected, you can then select the COS from the 'variant' menu.

As I already had to define new models, I should probably add a couple compound models and fill in the MFT-COS line of sizes so that they can be selected at any size. 8x COS module (40m x 5m)? hehehe

[Jimbodiah]

Yeah, but that would solve your issue for larger station parts as I found somewhere under issues ;) SO look on the bright side. Now all you need to do is make Kerbals into resources (hmmm, soylent green?), and you have an MFT-HAB ;)

[shadowmage45]

Hmm.. one problem I had not previously considered -- the rescaling of the ladders on the COS models. For me that is pretty much a deal-breaker. Giant ladders (or hatches/windows) = can't use it.

So, will have to think up some other options.

• I could possibly make a COS-like set of MFT textures. Workable, but that is a lot of memory use for the feature.
• Re-export the COS models minus the ladders, create a new set of texture-set defs with a blank/placeholder AO texture. Very little memory use, probably faster than making a new set of MFT textures, but does add yet-more model assets and configs to be managed.
• A new/separate MFT-COS part that is only setup with the MFT-COS models, and limited to min/max diameter of 2.5m. You would still get the body and nosecone switching, but it would limit the diameter properly. No model or texture work needed for this one, but it would be a fair amount of config work to get it all set up.
• ??

[Jimbodiah]

I'd say #3: Just make a single SC-MFT-COS that has only 4 lengths (XS/S/M/L) and a single 2.5m diameter. Probably the least amount of work as well? You can always go full modular in a future release. Best not spend too much time on this part.

This could be a good time to start making parts without the docking ports, and possibly it could be a model for a future modular COS hab?

[Jimbodiah]

For MFT in general, is there a way to define the starting amount of resources, i.e. if I want to start with 0 units instead.

[shadowmage45]

Yes ( example from the ST-CFG USI-LS patches ):

        CONTAINER
        {
            name = Supplies
            percent = 7.08
            tankageVolume = 0
            tankageMass = 0
            defaultModifier = standard
            defaultResources = Supplies,10,1;Mulch,10,0
            resource = Supplies
            resource = Mulch
            resource = Fertilizer
            modifier = standard
        }

Note the definition on the 'defaultResources' line. It is of the format:
ResourceName, Ratio, FillPercent; Where FillPercent is a decimal value between 0 (empty), and full (1). It could be 0.50 if you want that resource to start half-filled.

[Jimbodiah]

OK, But not for any of the other resources, ie fertilizer in your example, when I don't want that as my default resource? The reason I ask is that I want to use an AntiMatter type of resource which can only be generated in game.

[shadowmage45]

Sorry for the (extremely) late response -- nope, you can only enforce the 'empty' status on the 'default' resources. The user is free to fill-up the empty resource in the editor if they desire. I have no intention to enforce KSPI's 'antimatter cannot be loaded in the editor' silliness (or K+'s Karborundum, or any of the other exotic fuel resources). (would consider accepting a PR for such a feature if someone were to write it up and it did not interfere with the rest of the functioning of the volume-container system; this isn't a note so much for you Jimbodiah, as I know you don't write code, but is more for anyone else watching the thread)

Re: The MFT-COS additions -- still a bit torn on how best to handle these.

Hmm... seems like the options are:

• New MFT-COS fuel tank part. Re-uses existing meshes/textures. Allows for selecting body length, end-caps/nose/mount, and fuel types. Limited to 2.5m diameter. Does not allow for rescaling -- would see very limited (probably zero) use in my games; I would simply use the standard fuel tank (that allows rescaling...).
• New models added to existing MFT-A. Re-use existing COS textures. Would allow for selecting body length, rescaling, end-caps, etc -- all the standard MFT features. Would lack the ladders, and would be a simple cylinder with COS paneled textures. This part might actually see some use, in places where I thought the texture was more appropriate than the other fuel tank textures (industrial looking stations / interplanetary craft).
• Use existing models + textures and add them to the existing MFT-A, and 'just deal with' the ladder-rescaling problem. If they were available as variant options, I might well use them in places where appropriate, within a narrow range of scales (1.875m <-> 3.75m would probably be my personal limit), but I still see this as a less-than-ideal scenario.

[Jimbodiah]

Can be closed now?

[shadowmage45]

Still debating on how to best implement a COS-like storage part... as none of the options that I've come up with are ideal.

Probably will end up making up some COS-like models minus the ladders/handgrips. So it can retain the textures and still allow for scaling.

[Jimbodiah]

Awesome! I still use my patched versions right now ;-) Also made an ISRU etc with those COS parts ;)

[shadowmage45]

Have decided that I'll create some new NRM maps for the existing MFT-A/B/C/CF tank models; likely two variants, one simple paneled, one with the 'cross panels'.

Preliminary tests show that the UV mapping is... adequate... for this use of textures. Not perfect, but will work.

Will try and squeeze these into today/tonights update, but no guarantees. They will appear as a new texture set for the MFT-A/B parts when they are available.

[shadowmage45]

Erm.. actually.. nevermind. The UV mapping simply won't work for any sort of paneled texture on these parts as they are randomly split inbetween panels.

(I really should redo all of the UV mapping for the main tanks to split them into discrete length chunks, rather than randomly split up as they are now; would make using patterned textures like this actually doable)