Universal Storage 1.4.0.0 (For KSP 1.4.x) 13th March 2018

[Paul Kingtiger]

Isn't it also tied to solar panel efficiency based on the cells distance from the sun?

Solar panels appear to have their own system based on how much of the panel is exposed to sunlight (1 being facing the sun).

It might be the same system in the background though.

[panarchist]

First off, Paul - great mod, love it!

Finding information on food amounts in space is annoyingly difficult. In the end I looked at lots of pictures of meals for the ISS, space shuttle and Apollo. The shuttle was the most helpful as the meals come prepacked in a tray which you can easily estimate the size of. I came up with the value of 2000cm3 or 2 liters of food per day (assuming 2 meals per day).

With a wedge having a maximum size of 122 liters that is about 60 days of food (a little less to make room for packing and structure. I think my current placeholder value is 50 days food per wedge.

For water I've gone for 3 liters a day for drinking and washing (assuming there is some additional water content in the food). That limits your mission times until you put a water purifier on your craft, although a fuel cell helps.

3 liters / day is (IMO) a bit light for human scale, and possibly high for Kerbal scale. Your go-to for stupidly detailed info on Life Support should be NASA's Advanced Life Support Baseline document. It's available in PDF format here.

Inputs:

* Oxygen - 0.835 kg/day

* Water - 3.909 kg/day

* Food - 0.617 kg/day

Total: 5.361 kg/day

Outputs:

* CO2 - 0.998 kg/day

* "Waste" - 0.109 kg/day

* "Wastewater" - 4.254 kg/day

Total: 5.361 kg/day

TAC-LS assumes Kerbals use resources at 1/2 the human rate, which would be 1.95 liters of water/day.

NASA assumes 0.367kg/L density for food (including packaging), which is 1.68 liters of food/day for humans (0.84 liters/day for kerbals assuming 1/2)

For a wedge of 122 liters, assuming human use, that's ~70 days of food (72.6 - structure) or a maximum of 60 days of water (62.6, but given water's greater mass, more structure is required)

Sorry for the late remarks - just starting to plug myself into the discussion on a number of these threads.

[biohazard15]

Nice mod, installed it after DMagic Orbital Science update (US science tools, with asteroid science support!).

Will there be more parts for those of us who don't use realism-oriented mods? KAS containers, batteries, solar panels, RTGs, monopropellant tanks, science parts, etc?

[BananaDealer]

Nice mod, installed it after DMagic Orbital Science update (US science tools, with asteroid science support!).

Will there be more parts for those of us who don't use realism-oriented mods? KAS containers, batteries, solar panels, RTGs, monopropellant tanks, science parts, etc?

Read the OP. KAS and TACLS packs are planned.

[Paul Kingtiger]

....

Thats a great link, thanks for sharing. I'll take a look at it tonight and review the numbers.

I can say now that my values are based on human requirements, I haven't halved them, so there will be differences there (although usage rates are set entirely in TAC, we're just providing resources)

For the food I looked a ton of pictures of food for the space shuttle and the ISS and tried to estimate the volume of the pre-packaged meals. It's much easier with the shuttle because they used pre-packaged meal trays which you could easily measure. With the ISS it seems a lot more free form, great for the crew, not so good for me.

Your link is hard data though and will be really useful.

Nice mod, installed it after DMagic Orbital Science update (US science tools, with asteroid science support!).

Will there be more parts for those of us who don't use realism-oriented mods? KAS containers, batteries, solar panels, RTGs, monopropellant tanks, science parts, etc?

KAS containers, Monoprop and an Apollo style science bay (where you can mount science parts) are all planned.

[panarchist]

Thats a great link, thanks for sharing. I'll take a look at it tonight and review the numbers.

I can say now that my values are based on human requirements, I haven't halved them, so there will be differences there (although usage rates are set entirely in TAC, we're just providing resources)

Human metabolic values (the ones I put in my post for inputs and outputs) are on document page 27 (page 39 in the PDF numbering). Towards the end of that doc, they break down specific details on mass and power requirements for all of the individual life support components - way too detailed for most of us, but useful if you want to compare to RL values for individual parts to determine realistic scaling, etc.

Winchell Chung's Atomic Rockets site quotes this pub extensively among others. NASA published it in 2004 for Mars mission requirements, and it's the most recent *official* publication with those values - they will differ from Apollo and STS, less so with ISS, but they incorporate the technical state of the art for 2004. The data is still 10 years old, but it at least has the benefit of 40 years of NASA, ESA and RSA real-world data.

[SpacedInvader]

Have you ever thought about converting this to some sort of procedural creation? My thinking is that you could make the central support conform to specific size / shape values to keep the wedges a single size and shape, and then allow for the outer surface and doors to conform to the outer diameter of the final part a la procedural fairings. Not sure if it would even be worth the effort, but this could allow for more options in vehicle size, and would get rid of the lobing you end up with on the large base. Just a thought... still a great mod as is .

[Daishi]

Have you ever thought about converting this to some sort of procedural creation? My thinking is that you could make the central support conform to specific size / shape values to keep the wedges a single size and shape, and then allow for the outer surface and doors to conform to the outer diameter of the final part a la procedural fairings. Not sure if it would even be worth the effort, but this could allow for more options in vehicle size, and would get rid of the lobing you end up with on the large base. Just a thought... still a great mod as is .

I'm not sure, procedural tanks use pretty simple geometry and textures that can be scaled and stretched easily to fit whatever form you like - our stuff is a little more complex, and involves animations and toggles that depend on a static baked mesh. We'd have to axe a fair few features and visual fidelity to make procedural parts work, and i'd rather not tbh.

I agree that there is a place and need for larger wedges - so once the entire mod is finished i'll see what i can do for potential future packs.

[Tallinu]

Just found this mod and immediately squealed and installed it.

Looks like you're already discussing something along the lines of what I was just thinking about, too. What about instead of toggling the wedges between just "fairings" and "no fairings", offer more than two options - for example, "1.25m-fitted fairings", "2.5m-fitted fairings" and "no fairings"? Would it be possible to have two separate meshes like that, with no more than one of them shown at a time, based on the VAB setting?

[Daishi]

Just found this mod and immediately squealed and installed it.

Looks like you're already discussing something along the lines of what I was just thinking about, too. What about instead of toggling the wedges between just "fairings" and "no fairings", offer more than two options - for example, "1.25m-fitted fairings", "2.5m-fitted fairings" and "no fairings"? Would it be possible to have two separate meshes like that, with no more than one of them shown at a time, based on the VAB setting?

... I guuesss? That's entirely possible with the external model .cfg code referenced a few pages back (essentially stacking multiple models in one part) but its a large investment to re-make everything to work like that at this stage. Would be an elegant way to get around the scalloping, giving you the option to have a purely cylindrical 2.5m section or just revert it back to look like a early Saturn if you wanted too. I'd need some kind of .dll or .cfg switch that could pull different models from different folders as they're needed though, and unload the old ones from memory. I'm not sure KSP is capable of that though.

As it stands i'm currently considering remaking the external structure (more efficient UVs, reducing poly count and fragmenting the mesh for easier customisation on a per-part basis). It's the oldest asset, made when i was still learning, so it's due for a revamp. I'll look into setting up the file hierarchies, so if we can work this out, future fairing changes will be easy to include.

(+1 for mod-induced squealing)

[Tallinu]

Pretty sure KSP won't unload models but I don't think you'd really want that anyway, since you could have 1.25m and 2.5m cores full of modules in the same scene, if not on the same vessel, so you'd likely need both fairing shapes loaded.

I thought I'd read that the fairings were being hidden by rescaling them to 0% but maybe that was someone else's. If it was these, that approach could just be applied to two meshes instead of one, is what I was thinking. But i'm not familiar with the exact details of how your plugin works, so perhaps that wouldn't be as simple as it sounds.

Scalloped fairings or not, I'm looking forward to what I can make with these, and to the KAS containers and empty bay parts as well as whatever improvements you come up with next!

[Daishi]

Ok that's brilliant - not sure if this is what you meant or not. Having the fairings on the cores and not the wedges! I foresee issues with per-part door animations though and being able to toggle them when full of wedges, but still, massive savings in RAM and polycount there! Will have to look into that.

Yeah they do rescale to 0% but i have a hunch they are still actively being rendered by the game, so having 1.25 and 2.5m variants in the same wedge at the same time might slow things down a bit. Cant hurt but try though - once i reorganise these parts again with the new structure UVs, i'll drop in an extra fairing mesh and do some tests. Not sure how two door animations would work on separate meshes with one button though... hmm.

Edited April 30, 2014 by Daishi
rewording

[Daishi]

Might just pay to leave extra fairings out of it for now - did some tests with some really high poly (7.2million tri) fairings, and scaling them to 0% didn't remove them from the game (ie, the game kept lagging like hell). If we start including tons of variants in every wedge, it will really start effecting people's computers when each wedge's polycount silently increases by thousands of tris.

I think we better stay on the straight and narrow, and stick with our current system, or else i'll be remaking everything and getting nowhere in development towards TAC. I'll be making adapter plates to lessen the effect of the scalloping if it annoys anyone.

[OOZ662]

Personally I don't see anything wrong with the visuals anyhow. Quite the contrary.

[CoolBeer]

f we start including tons of variants in every wedge, it will really start effecting people's computers when each wedge's polycount silently increases by thousands of tris.

You could release a drop in very simple wedge model, say just an outer shell of a wedge, that people with crappy computers could use as a replacement if it became a problem. It could probably be done in less than 250 triangles and with some clever normal mapping you could even keep a lot of detail.

This way the people that want a bit of extra performance of their 2000 part rocket could get it and the ones wanting bling gets that as well.

-

Kolbjorn

[Tallinu]

Having the fairings on the cores and not the wedges! I foresee issues with per-part door animations though and being able to toggle them when full of wedges, but still, massive savings in RAM and polycount there! Will have to look into that.

Might not work so well - how do you open the door on a specific wedge then? And what about wedges with different fairing or door designs, like DMagic's science parts?

Might just pay to leave extra fairings out of it for now - did some tests with some really high poly (7.2million tri) fairings, and scaling them to 0% didn't remove them from the game (ie, the game kept lagging like hell). If we start including tons of variants in every wedge, it will really start effecting people's computers when each wedge's polycount silently increases by thousands of tris.

Ouch. Yeah, that's no good. What about optionally-installed wedge part variants with fairings shaped for the 2.5m core? Still involves the work of creating those meshes, but if you find a good way to switch a part model on the fly without the rescaling hack, I doubt the work would be wasted.

I agree about getting the TAC and KAS packs finished first though. This would primarily be a "nice to have" cosmetic feature, not one that really adds any functionality like those would. My only potential concern is FAR aerodynamics and the collider meshes, which probably wouldn't be changing anyway unless you did offer 2.5m-fairing versions as separate parts. And I doubt that would really be a problem anyway.

[Tommygun]

I'm getting this massage from Module Manager during loading.

It only started after I upgraded to ModuleManager 2.0.7 and I'm using UniversalStorage 0.61 .

Has anyone seen this? The game loads and the parts seem to work.

[Mecripp]

I'm getting this massage from Module Manager during loading.

It only started after I upgraded to ModuleManager 2.0.7 and I'm using UniversalStorage 0.61 .

Has anyone seen this? The game loads and the parts seem to work.

http://i.imgur.com/10tec0Q.png

By looking at the file at the buttom you see

@RESOURCE_DEFINITION[O2 Candle] <---- here has a space in name make it look like O2?Candle

{

isTweakable = true

}

and reload.

If you want here is a edited file https://www.dropbox.com/s/242hapen0370enz/US_ECLSS.cfg

Edited May 1, 2014 by Mecripp2

[DMagic]

Might not work so well - how do you open the door on a specific wedge then? And what about wedges with different fairing or door designs, like DMagic's science parts?

Keeping compatibility with my parts probably shouldn't be too much of a priority, but I agree that there are some problems with trying to make a single core + fairing piece with the wedges placed inside (or maybe the fairings would go on after the wedges).

You could make multiple door animations on the fairing, but I don't know of any way to determine which right-click button would apply to which door, clicking anywhere on the part would always bring up every door button. It's probably possible to make a gap in the collider of the fairings and then have the wedge control the animation for the nearest door, but that wouldn't be simple to setup and would still be awkward to actually select the right part.

I think the easiest option is making a tapered core (and maybe a special, double-tapered core for single layer stacks) that I think has been brought up before. That could be put at the bottom and top of a stack to make it look a little nicer. I actually kind of like the way it looks now, there are some cases where it might look a little odd, like when the part above or below it is hollow, but that's not a big deal.

[Tallinu]

After playing around with the parts in the VAB for a while, I realized the scalloping's indentation effect isn't nearly as extreme as I'd been picturing. The only parts I've tried that I could actually see into from outside were the KW Rocketry pancake tanks with the very thin, wider-than-usual outer walls. Even the stock 2.5m SAS module was thick enough to avoid that.

And I actually like how the special decouplers look when attached to the 2.5m cores full of wedges (those projecting pieces fit right into the triangular gaps - very well done). It's a PITA to get them to attach via the correct node sometimes. But it fits very well with the Mark 1-2 pod.

Speaking of SAS modules and wedges... You're already talking about adding monopropellant storage wedges and empty bays - how about a solid "blank" wedge model ("No user-serviceable parts inside", haha) that people with no modeling skills could use (perhaps with a default texture, or their own) to make custom parts that would fit into these cores? Things like an SAS module you could drop in pairwise if you have more bays than you really need, or don't like the flimsiness of thin stacked components like the stock 2.5m SAS...

[Tommygun]

By looking at the file at the buttom you see

and reload.

If you want here is a edited file https://www.dropbox.com/s/242hapen0370enz/US_ECLSS.cfg

That worked, thank you.

[Paul Kingtiger]

And I actually like how the special decouplers look when attached to the 2.5m cores full of wedges (those projecting pieces fit right into the triangular gaps - very well done). It's a PITA to get them to attach via the correct node sometimes. But it fits very well with the Mark 1-2 pod.

Speaking of SAS modules and wedges... You're already talking about adding monopropellant storage wedges and empty bays - how about a solid "blank" wedge model ("No user-serviceable parts inside", haha) that people with no modeling skills could use (perhaps with a default texture, or their own) to make custom parts that would fit into these cores? Things like an SAS module you could drop in pairwise if you have more bays than you really need, or don't like the flimsiness of thin stacked components like the stock 2.5m SAS...

We've talked about redoing the decouplers, making them a bit taller to reduce the node issues.

For the blank part, there are some parts planned for the TAC pack that could easily be used for other things. By the time we've finished there will be models for Solid, Liquid and Gas resources, and between those three you should be good to go if you want to create custom part.cfg files.

[TerLoki]

Just wanted to pop in and mention that even though the KAS pack isn't out yet the 2.5m hub works pretty well as-is with the KAS A-type containers. You just need a little spacer on the top and bottom to prevent clipping, a 1.25m battery or SAS module will do.

[Tallinu]

We've talked about redoing the decouplers, making them a bit taller to reduce the node issues.

The larger one is nearly perfect, it just needs to have the node which attaches to non-US-core components (such as a command pod) raised so it's nearly level with the rim of the model. As is, any normal cylindrical part "sinks in" quite a bit.

The smaller decoupler looks like just a downscaled version, which doesn't seem to fit the smaller core as nicely as the larger ones go together... That one does seem like a good candidate for a redo, although the shape of the rim still looks nice.

Speaking of the larger core though, it's an amazingly detailed model... Even in places where that detail seems practically wasted, like the "docking ports" on the top and bottom. It's beautiful - and only ever seen in the VAB or briefly once that decoupler fires. So many polygons going unappreciated... I do love the implied crew tunnel, but most parts just have texture art for the hatches...something to consider if you're ever in a must-lower-poly-count kind of mood.

Edited May 1, 2014 by Tallinu

[Daishi]

The larger one is nearly perfect, it just needs to have the node which attaches to non-US-core components (such as a command pod) raised so it's nearly level with the rim of the model. As is, any normal cylindrical part "sinks in" quite a bit.

The smaller decoupler looks like just a downscaled version, which doesn't seem to fit the smaller core as nicely as the larger ones go together... That one does seem like a good candidate for a redo, although the shape of the rim still looks nice.

Yeah it pretty much is a rescaled version - I've learned so much since making those, i'll be doing them again to better utilize their maps and to keep a consistent texture density. The larger 2.5m one only really needs deepening (i like to leave a little room to interface with the pod, or provide space for heat shields), and the 1.25m one needs simplifying down. Should be able to get it into a 128px map easy.

Speaking of the larger core though, it's an amazingly detailed model... Even in places where that detail seems practically wasted, like the "docking ports" on the top and bottom. It's beautiful - and only ever seen in the VAB or briefly once that decoupler fires. So many polygons going unappreciated... I do love the implied crew tunnel, but most parts just have texture art for the hatches...something to consider if you're ever in a must-lower-poly-count kind of mood.

Aw thanks! Hah I've already optimised it twice since 0.61 - retextured it to be "smoother" and less patchy, while adding specular to the glass in the door. Then went back and knocked 1300 tris off its polycount Looks exactly the same so win-win.

I was tossing up just making that docking hatch a flat texture - but to be honest that would be taking another shortcut that KSP doesn't really deserve. Triangles are cheap, and too many of KSP's stock parts are just simple skinned cylinders. Little details matter when it comes to immersion and getting drawn into a game

Edited May 5, 2014 by Daishi